Krueger, Wulf wrote:
> We've had problems for a number of years with maximising
> running under window managers such as metacity.
Well, for me at least, Xemacs (currently 21.5.26 from cvs) hates
metacity, kwin and compiz and has been misbehaving for years. While I
can forgive XEmacs' compiz headaches, I don't understand what causes
conflicts with KDE's kwin. Especially since XEmacs is the only
application I've ever seen showing these phenomena.
I don't experience any flashing but strange re-sizing (while XEmacs
should in fact be simply maximised) and mysterious movements of the
XEmacs window after switching to another virtual desktop.
There are several issues:
1. XEmacs specifies a resize increment based upon the size of the
default font, so that the WM will resize the window such that the
window has an integral number of character rows and columns.
2. XEmacs changes the base size (i.e. the size of a 0 x 0 window)
whenever GUI elements (e.g. scrollbar, modeline, gutter) are inserted
or removed (e.g. due to splitting or removing windows).
3. XEmacs also specifies an absolute size (PSize flag); whenever the
WM resizes the window, it recomputes this size to be the closest size
to the new size which satisfies the gridding constraints.
My guess is that the WM makes the window the full size of the screen,
ignoring the gridding constraints, XEmacs recomputes the correct size
according to the gridding constraints, and the WM then resizes the
window to the new size.
XEmacs probably shouldn't be specifying an absolute size. At least, it
shouldn't be changing it when the window gets resized; it will be
specified at startup to match the geometry resource setting. OTOH, the
WM should probably ignore XEmacs' requested size when the user has
chosen to maximise the window.
XEmacs will correctly handle the case where the it doesn't get the
requested size, leaving some blank space at the right and bottom
Glynn Clements <glynn(a)gclements.plus.com>