Re: AW: xemacs trouble maximizing window

Stephen J. Turnbull wrote: Hehe; I've just written pretty much the same thing, before having read this. I don't /think/ that Xt rules are relevant here. Disobeying them might cause problems for internal geometry management, but ultimately it shouldn't matter externally. I'm assuming that shell widgets handle resize requests by changing WM_NORMAL_HINTS rather than calling XResizeWindow() etc. The WM doesn't know what's going on within the client; there isn't a right-time/wrong-time for changing property settings. That kind of thing can matter on Windows, where there is a defined beginning and end to the processing of a specific event (i.e. between entry to and return from the WindowProc), and within Xt. But at the inter-client level, the client gets the ConfigureNotify event and does whatever it wants with it. There's no endpoint where the client can't request a resize from the WM until the processing is "complete", but can do so after that point. That's my suspicion. I suspect it depends upon whether the code which sets the hints can figure out why it's setting them. If you can distinguish the case where the parameters have changed because of a WM-driven resize from the case where they have been changed internally, you can avoid changing the hints in reponse to WM actions. That's how xterm behaves. If you resize the window using the WM, the PSize doesn't change. If you select a different font size from the Ctrl-RMB menu, it changes the PSize. If you do both in that order, the change to the font size retains the updated character-cell geometry following the WM-driven resize[1], so it clearly notes the resize but doesn't update the hints until an internally-driven change forces it to notify the WM. [1] Except, using Cygwin's X server in rootless mode with the built-in WM, if the window is maximised, enlarging the font won't make the window any larger (Windows doesn't allow windows to be larger than the desktop), but will reduce the number of character cells instead. Clicking the restore button restores the window to its previous overall size (now with fewer cells due to the enlarged font). If the WM implements the concept of "maximised" windows, it should probably ignore the WM_NORMAL_HINTS property for such windows. I mean that it shouldn't change the hints when a resize occurs. It should change them if internal changes (changes to the font size, addition or removal of scrollbars, toolbars etc) require a new size. Without having looked at the code, I would suspect that the issue is that any change to size-related parameters results in the hints being updated, regardless of /why/ the parameters changed. E.g. set-frame-size updates the stored frame size, which causes the hints to be changed. WM-driven resize updates the stored frame size, which causes the hints to be changed. The former should result in the hints being changed, the latter shouldn't. The WM has just told you what size you're getting; requesting a specific size /in response/ seems likely to be the cause of the troubles. At the client<->WM level, it seems that it's the other way around, i.e. every time it's given something, it replies with what it would have rather had instead. -- Glynn Clements <glynn(a)gclements.plus.com&gt;