>>>> "Glynn" == Glynn Clements
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
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
> what you are given." As far as I can tell, that's what XEmacs
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.