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
I'll see if mouse-drag-modeline can be made to work with
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
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
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