Re: Proposal: client property for de-maximize geometry

[Joseph Krahn <joseph krahn gmail com>]

On 11/24/10, Martin Gräßlin <kde 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