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