7:54 p.m.
I finally got back to looking at the redisplay issue that I found around
New Year's. I'm still seeing weird behavior if I have multiple windows
in a frame and I try to drag a modeline--the modeline doesn't track the
mouse location like I expect.
I added some instrumentation to mouse-drag-modeline, and it appeared
that the Y pixel coordinate for the events was always larger than I
expected. So I wrote this function, which confirmed that the Y pixel
coordinate was roughly 20 pixels (a little more than one row) larger
than I expected.
(defun mdk-event-test ()
"Manual test for reporting events.
To use, invoke this function, then click and hold. Events will be
reported until the button is released."
(interactive)
(let (event run report type x y xcol yrow)
(setq run t)
(setq report nil)
(while run
(setq event (next-event event))
(if (button-release-event-p event)
(setq run nil))
(if (button-press-event-p event)
(setq report t))
(when report
(setq type (event-type event))
(cond ((eq type 'magic)
(message "magic"))
((mouse-event-p event)
(setq x (event-x-pixel event))
(setq y (event-y-pixel event))
(setq xcol (event-x event))
(setq yrow (event-y event))
(message "%s %d %d (%d %d)"
type x y xcol yrow))
(t (message "unknown")))))))
Further investigation showed that this depended on whether the buffer
tabs were being displayed at the top of the frame. If they were, the Y
value was larger than expected. If the buffer tab wasn't visible, the Y
value was what I'd expect.
This is not something I introduced: I get the same behavior on a binary
that doesn't include my redisplay hacks.
The mouse-drag-modeline function compares the mouse's Y location--as
reported by event-y-pixel--with the bottom of the window--as reported by
window-pixel-edges. window-pixel-edges excludes the top gutter (as
documented), while event-y-pixel includes the top gutter.
So... what's the right fix here? Does mouse-drag-modeline need to
account for whether there's a top gutter visible? (If yes, how?)
Should event-y-pixel be changed to exclude gutters, for a better
impedance match to window-pixel-edges? Or should there be a new set of
event functions that return pixel locations, excluding gutters?
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:21 a.m.
Mike Kupfer writes:
So... what's the right fix here? Does mouse-drag-modeline need
to
account for whether there's a top gutter visible?
I hope not, but there may be no alternative.
What probably should be done is to review all the geometry code, and
improve the documentation and regularize the internal APIs. An emacs
frame is an unholy mix of widgets (which have their own X windows, and
draw themselves in redisplay) and gadgets (which are rectangular areas
of a widget, and are drawn by the parent). Widgets include Emacs
windows (not to be confused with X windows), the menubar and popups,
and the scrollbars. The modelines, echo areas, toolbars, and gutters
are gadgets, children of an Emacs window. The tabs and progress bars
are widgets, usually -- but not always -- children of a gutter.
Not your job, but I wanted to throw it out for discussion.
Should event-y-pixel be changed to exclude gutters, for a better
impedance match to window-pixel-edges? Or should there be a new set of
event functions that return pixel locations, excluding gutters?
I don't understand why dragging an object should care about what
pointer positions are relative to. The object should know where it
is, and then you just add the relative pointer movement to that
position. If that doesn't work, the low-level object geometry
management is broken and should be fixed, not the high-level function.
(Of course, you do need to know the reference object to identify which
subobject is being dragged, but you are not seeing bugs there IIUC.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:08 a.m.
Stephen J. Turnbull wrote:
I don't understand why dragging an object should care about what
pointer positions are relative to. The object should know where it
is, and then you just add the relative pointer movement to that
position. If that doesn't work, the low-level object geometry
management is broken and should be fixed, not the high-level function.
(Of course, you do need to know the reference object to identify which
subobject is being dragged, but you are not seeing bugs there IIUC.)
Hmm. mouse-drag-modeline works by identifying the window that the
modeline is for, and then shrinking or growing the window by 1 or more
lines. It calculates the number of lines to grow/shrink by comparing
the Y position of the mouse with the current boundaries of the window.
So maybe there are better primitives for mouse-drag-modeline to be
using...
I'll see if mouse-drag-modeline can be made to work with
event-window-y-pixel. That seems closer to the model you describe. But
after doing "M-x apropos event" and "M-x apropos modeline", it's
the
only function that looks like it might be better. I guess that makes
sense, given that the modeline is a gadget, not a widget. (So IIUC,
it's the enclosing window that needs to be adjusted, rather than
"moving" the modeline.)
Let me know if I seem to be going off in the wrong direction here.
thanks,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:46 a.m.
Mike Kupfer writes:
Hmm. mouse-drag-modeline works by identifying the window that the
modeline is for, and then shrinking or growing the window by 1 or more
lines. It calculates the number of lines to grow/shrink by comparing
the Y position of the mouse with the current boundaries of the window.
Doesn't that seem like a hack to you? IMO, a real GUI app would
simply move the modeline by as many pixels as you dragged the mouse,
and clip the Emacs windows accordingly (perhaps leaving partial lines
exposed).
I'll see if mouse-drag-modeline can be made to work with
event-window-y-pixel.
So how about a model where the modeline moves by 1 line after the
mouse moves a threshold number of vertical pixels? Can't that be done
with event-window-y-pixel?
The threshold could be configurable to the user's taste, or it could
be a fraction of the line height. The main problem with this approach
is that for a multiple line drag, the pointer would slip off the
modeline, which might feel odd. I guess you could hide the pointer
and display a motion glyph in the modeline. Or you could adjust the
threshold dynamically to account for line height.
That seems closer to the model you describe. But after doing
"M-x
apropos event" and "M-x apropos modeline", it's the only function
that looks like it might be better. I guess that makes sense,
given that the modeline is a gadget, not a widget. (So IIUC, it's
the enclosing window that needs to be adjusted, rather than
"moving" the modeline.)
Well, it's not really about "what" needs to be adjusted, it's that
some objects (such as the modeline) don't know about themselves, and
can't adjust themselves; you need to query and use methods of their
parents. So the programming model for menus and such is quite object-
oriented, but that for the modeline is procedural. Ie, the model is
inconsistent. This makes it hard for people to learn this stuff.
Let me know if I seem to be going off in the wrong direction here.
Hard for me to say without seeing a patch, as I know almost nothing
about the mouse code (I don't use the mouse much in XEmacs).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:18 p.m.
>>>> On January 28, 2011 Stephen J Turnbull
<stephen(a)xemacs.org> wrote:
Mike Kupfer writes:
> Hmm. mouse-drag-modeline works by identifying the window that the
> modeline is for, and then shrinking or growing the window by 1 or more
> lines. It calculates the number of lines to grow/shrink by comparing
> the Y position of the mouse with the current boundaries of the window.
Doesn't that seem like a hack to you? IMO, a real GUI app would
simply move the modeline by as many pixels as you dragged the mouse,
and clip the Emacs windows accordingly (perhaps leaving partial lines
exposed).
that's easily achievable by dropping this line in mouse-drag-modeline:
(setq growth (/ growth default-line-height))
and calling enlarge-window-pixels rather than enlarge-window.
but please keep the default to move by whole line increments.
> I'll see if mouse-drag-modeline can be made to work with
> event-window-y-pixel.
that seems like it will not be an easy to make work or an improvement
in code quality; you'll be getting y-positions relative to each motion
event's window, which will not necessarily be the same as the original
mouse button event's window, or even the same from motion event to
motion event.
So how about a model where the modeline moves by 1 line after the
mouse moves a threshold number of vertical pixels?
that's what's happening now, in the line mentioned above when we
divide by default-line-height.
The threshold could be configurable to the user's taste, or it
could
be a fraction of the line height. The main problem with this approach
is that for a multiple line drag, the pointer would slip off the
modeline, which might feel odd.
again that's how it works today.
Greg
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:57 a.m.
Greg Klanderman writes:
that seems like it will not be an easy to make work or an
improvement
in code quality; you'll be getting y-positions relative to each motion
event's window, which will not necessarily be the same as the original
mouse button event's window, or even the same from motion event to
motion event.
Is that really a problem, given that there are unlikely to be any
other windows near the modeline?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:21 a.m.
Stephen J. Turnbull wrote:
Greg Klanderman writes:
> that seems like it will not be an easy to make work or an improvement
> in code quality; you'll be getting y-positions relative to each motion
> event's window, which will not necessarily be the same as the original
> mouse button event's window, or even the same from motion event to
> motion event.
Is that really a problem, given that there are unlikely to be any
other windows near the modeline?
Well, there's the window immediately below the one whose modeline is
being dragged. If the code is able to move the modeline quickly enough,
the mouse won't end up over that other window, but relying on that in
the modeline code is going to make for brittle code. If you
click-and-hold over the modeline, then jerk the mouse down, it shouldn't
be hard to get the mouse over that other window. And I suppose that if
you have multiple small windows (a few lines each), you could even end
up with the mouse over a window that isn't even adjacent to the original
one. Bleah.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:26 a.m.
Mike Kupfer writes:
Stephen J. Turnbull wrote:
> Greg Klanderman writes:
>
> > that seems like it will not be an easy to make work or an improvement
> > in code quality; you'll be getting y-positions relative to each motion
> > event's window, which will not necessarily be the same as the original
> > mouse button event's window, or even the same from motion event to
> > motion event.
>
> Is that really a problem, given that there are unlikely to be any
> other windows near the modeline?
Well, there's the window immediately below the one whose modeline is
being dragged.
Well, in practice that's not clear, actually, which is why I asked.
In fact, IIRC in XEmacs there's only *one* big X window, which
*directly* handles events for all of the echo area, the toolbars, the
modelines, the gutters, and the Emacs windows in the frame. The
exceptions are the "native widgets" (in practice, tabs and progress
gauges) which might appear in the gutter (or very rarely if ever in
practice, as glyphs attached to buffer extents). But I doubt you're
going to be moving the modeline when a progress gauge is active, and
tabs are almost always at the top of the frame.
If that is correct, then the pixel distance will have a consistent
reference point throughout the drag, which is why I suggested this
calculation.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:57 a.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> Well, there's the window immediately below the one whose
modeline is
> being dragged.
Well, in practice that's not clear, actually, which is why I asked.
In fact, IIRC in XEmacs there's only *one* big X window, which
*directly* handles events for all of the echo area, the toolbars, the
modelines, the gutters, and the Emacs windows in the frame.
But whatever the X window hierarchy looks like, the number returned by
event-window-y-pixel is relative to the Emacs window. I added
event-window-x-pixel and event-window-y-pixel calls to my event tester.
If put 2 Emacs windows in the frame, start the event tester, and then
move the mouse from the top window, across the modeline, and into the
bottom window, the Y value resets to 0 as the mouse passes from the
modeline into the bottom window.
If that is correct, then the pixel distance will have a consistent
reference point throughout the drag, which is why I suggested this
calculation.
I do want a consistent reference point, but I'm starting to think I'm
going to have to add some functions to event.c or window.c to get it.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:22 a.m.
>>>> On January 28, 2011 Stephen J Turnbull
<stephen(a)xemacs.org> wrote:
Is that really a problem, given that there are unlikely to be any
other windows near the modeline?
Yes, I tested it before sending that reply, and it was trivial to
cause this to happen - you can easily move down fast enough; you only
have to get half the modeline-width ahead of an elisp event loop. As
Mike clarified, event-window-y-pixel is relative to the Emacs window,
not an X window.
Greg
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:39 a.m.
Had meant to add that I actually added and fixed a bunch of
the pixel- based display primitives about fifteen years ago..
so at one point I knew that stuff pretty well. But I've been
doing mostly air-travel search (www.itasoftware.com) for the
last 12+ years (in lisp, and using xemacs).
Greg
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:09 a.m.
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> Hmm. mouse-drag-modeline works by identifying the window that the
> modeline is for, and then shrinking or growing the window by 1 or more
> lines. It calculates the number of lines to grow/shrink by comparing
> the Y position of the mouse with the current boundaries of the window.
Doesn't that seem like a hack to you? IMO, a real GUI app would
simply move the modeline by as many pixels as you dragged the mouse,
and clip the Emacs windows accordingly (perhaps leaving partial lines
exposed).
Yeah, I guess it's sort of a hack, but it might be the best that's
possible given the object model and the available primitives. I haven't
gotten my head wrapped around all this well enough to say anything more
definite.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5044
days inactive
5048
days old
11 comments
3 participants
participants (3)
-
Greg Klanderman -
Mike Kupfer -
Stephen J. Turnbull