AW: xemacs trouble maximizing window

[Stephen J. Turnbull]

>>>>> "Glynn" == Glynn Clements <glynn at gclements.plus.com> writes:

    Glynn> Hehe; I've just written pretty much the same thing, before
    Glynn> having read this.

Yeah, I saw that.  I got a chuckle out of it.  I sympathize with the
users' predicament, but they're wrong.  Maybe I should just see if I
can fix metacity.  If Havoc takes a patch, the rest of 'em are going
to come under huge pressure whether he calls it a "bugfix" or a
"defensive feature".  :-)  Nah, first I'm going to work on the patch
suggested below.  Then I'll have more credibility when I submit a
metacity patch.  :-)

    Glynn> I don't /think/ that Xt rules are relevant here.

The reason I mention them is that geometry negotiation can go *up*
from where it starts.  That implies a request to the WM, eventually.
If that happens in the middle of a WM configuration change, who knows
what the result might be?

    Glynn> I'm assuming that shell widgets handle resize requests by
    Glynn> changing WM_NORMAL_HINTS rather than calling
    Glynn> XResizeWindow() etc.

AFAICT, ours do.

    Glynn> The WM doesn't know what's going on within the client;
    Glynn> there isn't a right-time/wrong-time for changing property
    Glynn> settings.

Oh, are you that sure that the WM is correctly implemented? ;-)

    Glynn> There's no endpoint where the client can't request a resize
    Glynn> from the WM until the processing is "complete", but can do
    Glynn> so after that point.

Assuming that the WM authors understand that is a bit iffy IMAO. X-P

    Glynn> I suspect it depends upon whether the code which sets the
    Glynn> hints can figure out why it's setting them.

    Glynn> If you can distinguish the case where the parameters have
    Glynn> changed because of a WM-driven resize from the case where
    Glynn> they have been changed internally, you can avoid changing
    Glynn> the hints in reponse to WM actions.

What *should* happen is that in the case of a WM-driven resize, size
changes should propagate unidirectionally downward via widget Resize
methods.  Parents may XQueryGeometry their children, but then they
*command* the resize they think best via Resize.  Children must never
XtConfigureRequest their parents.  That latter is what I'm afraid is
happening, in EmacsManagerChangeSize, called from EmacsFrameResize.

It is true that EmacsFrameResize always does a x_wm_set_variable_size.
However, this *always* ratifies the size demanded (in char cell units,
which presumably is what confuses the WMs), and a well-behaved WM
should ignore that in this case.

There's also a comment in EmacsFrameResize which I interpret to mean
that this change is intended to be entirely internal to XEmacs until
the "next resize".  Ah, but that can't be true.  XEmacs doesn't own
the WMShell resources, Xt does, and x_wm_set_variable_size does an
XtSetValues on those resources.  So that does propagate to the
WMShell, and it must have a hook which does the WM protocol---how else
to implement that?

    Glynn> That's how xterm behaves. If you resize the window using
    Glynn> the WM, the PSize doesn't change. If you select a different
    Glynn> font size from the Ctrl-RMB menu, it changes the PSize.

AFAICT, XEmacs _never_ changes the PSize per se.  When you say "PSize"
do you include the case where one or more of base size, increment, or
char cell dimensions change?

    Glynn> If the WM implements the concept of "maximised" windows, it
    Glynn> should probably ignore the WM_NORMAL_HINTS property for
    Glynn> such windows.

The WM authors obviously disagree.

    Glynn> The former should result in the hints being changed, the
    Glynn> latter shouldn't. The WM has just told you what size you're
    Glynn> getting; requesting a specific size /in response/ seems
    Glynn> likely to be the cause of the troubles.

    >> Anyway, the Xt model is simply "ask for what you want, and take
    >> what you are given."  As far as I can tell, that's what XEmacs
    >> does.

    Glynn> At the client<->WM level, it seems that it's the other way
    Glynn> around, i.e. every time it's given something, it replies
    Glynn> with what it would have rather had instead.

OK, let's try simply not doing the x_wm_set_variable_size call in
EmacsFrameResize.  AFAICT that should have the effect of only changing
the WM hints when XEmacs initiates the change.

Thanks!  I'm not sure I can reproduce (the 21.4.17 or so patch did fix
for me on Mac OS X), but at least I can make sure that normal behavior
isn't impaired.  Then I'll post a patch.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.