Re: AW: xemacs trouble maximizing window

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. 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.