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