On 11/24/10, Martin Gräßlin <k...@martin-graesslin.com> wrote: > Hi Joseph, > > On Wednesday 24 November 2010 02:38:21 Joseph Krahn wrote: >> Currently, it is the window-managers job to remember the original >> geometry to restore upon de-maximization or de-shading. It seems very >> practical to have this remembered geometry available as a window >> property, for example _NET_WM_NORMAL_GEOMETRY. It is not really >> essential, but it seems practical. > why would a client need that information? I cannot think of any usecase > where > a client (or toolkit) needs this information. Could you please provide a > usecase for this property? To me this looks like a property which should > only > be relevant to the window manager. > > And it raises some questions for me: > * Who sets the property? I assume the window manager, but what if the client > sets it? > * Should the WM restore to a geometry set by the client? > * Should a WM restore a currently maximized client if the client changes it? > * How should this be handled when the client is not maximized/shaded? Should > the client be moved to that geometry? Should it be ignored? > * Would the WM have to update the property whenever the window is moved or > resized? > > From a KWin point of view it would not be a trivial change to set this > property and keep it in sync. The "normal" geometry is used for more than > just > maximization/shading and keeping the property in sync (especially if the > client might change it) seems like a non-reasonable change for hardly any > usage for a client. > > Cheers > Martin Gräßlin > KWin Maintainer > It is reasonable to claim that window geometry should be controlled by the window manager, and not client utilities. However, why then are the MAXIMIZE and SHADE states made available to clients? IMHO, the stored geometry while in an size-modifying state is equally relevant to making that state information available to clients.
My proposal is that the WM sets _NET_WM_NORMAL_GEOMETRY whenever it sets a _NET_WM_STATE flag that causes a window geometry change that can be undone to restore the remembered geometry. This property would be deleted whenever the WM clears the geometry-affecting state flag. Client modification of _NET_WM_NORMAL_GEOMETRY would follow the same rules as modification of _NET_WM_STATE, which I believe is to ignore changes by clients. The WM would just set/clear the property whenever the relevant _NET_WM_STATE flags are modified. Gnome blocks window resize requests when the maximize state flags are set, I don't think the wm-spec covers this. It seems reasonable that a resize request could be honored, and the maximize flags cleared. A WM that block resizing could honor the request, but only update the de-maximize restore geometry, and also update the _NET_WM_NORMAL_GEOMETRY property. I came across this working on a utility to snapshot and later restore the layout of multiple windows. It is reasonable to simply claim that it simply should not be used on maximized windows. I could also de-maximize the window, check it's geometry, and then restore it. So, it is definitely not essential, but just seems reasonable to expose along with the geometry state flags. One other situation where this could be useful is if additional geometry-modifying states are defined. The presence of _NET_WM_NORMAL_GEOMETRY can then be tested to see if any of the current state flags are modifying the geometry. Thanks, Joe Krahn _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
