Re: WIP: wm-spec 1.9b

[Tim Janik <timj gtk org>]

On Thu, 16 Sep 1999, Dominik Vogt wrote:

> On Sun, Aug 22, 1999 at 06:55:00PM +0200, Marko Macek wrote:

> > An array of all X Windows managed by the window manager.
> > 
> > _NET_CLIENT_LIST has mapping order
> 
> What should this be good for? Why should some application need to
> know the internal order of windows in the WM? Isn't the stacking
> order enough?
> 
> > _NET_CLIENT_LIST_STACKING has stacking order
> >
> > [[This is simple. Does anyone feel we need a faster mechanism based  on
> > incremental updates? (based selection query + ADD/REMOVE updates, we
> > must  be careful about race conditions if we do this)?
> 
> Hm, I don't think we need this. This just makes the code on client
> and WM side more complicated. And what would be the use model behind
> this? Are we trying to provide a 'remote' window managing interface?

i agree here, i don't see the point behind _NET_CLIENT_LIST_STACKING, if
_NET_CLIENT_LIST could be sorted according to the window stacking.
however, providing the stacking order in one way or the other is
*required*, you don't really want a pager to query the X window tree
each time it refreshes, or to at least monitor X window tree changes
and cache the stacking order internally. this currently produces huge
extra overhead upon any window tree changes (e.g. focus changes or
desktop/area switches).

> > _NET_DESKTOP_NAMES
> > 
> > The names of all virtual desktops. Text Property. Can be changed by
> > anyone (by pager for example, when renaming desktops).
> > 
> > [[Should WM update this when modifying desktop count?]]
> > [[What does this mean with respect to Unicode if anything?]]
> 
> Wow, what will happen if you have multiple pagers and one
> changes the names? I don't see why the WM should be involved
> in naming desktops.

if one pager changes this property, the others will simply update their
internal data. however the wm should make sure that this property is
properly set, e.g. contains names for all desktops, even if a pager
only sets the name for the first desktop (or ther first 3 or whatever).
thus i think updates of this property should actually be done through
client messages as well.

> Since the WM doesn't need the information
> itself, why should this be in the scope of a WM spec?

some window managers do indeed provide (default) names for desktops,
and one application also has to make sure that the names persist throughout
different sessions, it is definitely within the scope of a window manager
implementation, especially since the window manager is actually the application
that provides the multiple desktops.

> > _NET_WORKAREA CARDINAL[][4]/32
> > 
> > Readonly property set by WM upon calculating the work area for each
> > desktop. (the first quadruple = desktop 1, etc).
> > Contains the left,right,top,bottom coordinates for each desktop.
> > Work area is used for maximizing windows and by the desktop to place
> > desktop icons appropriatelly.
> > 
> > Work area refers to current page minus space occupied by panels, docks
> > etc.  The purpose is to ensure that maximised applications do not cover
> > panels, and so that desktop icons don't get put under panels. 
> > 
> > [[IMHO having different work areas on different desktops is messy,
> > although flexible]].
> 
> If the hint gives you the size of the desktop, why is it called
> ...WORKAREA? And what do you mean with 'the first quadruple' when
> there are only four values? Am I missing something?

yes: CARDINAL[][4]/32, this is an array of quad values, each being
32 bits wide. thus you end up with n_desktops*4 values.

[...]

> They *only* situation where I recognize the value of layers is
> when the user *really knows* the layer concept and explicitly
> asks an application to use a certain layer. No application is
> allowed a 'program specified' layer hint, i.e. *all* applications
> (including taskbars and panels) start on the NORMAL layer unless
> the user modified their configuration.

and newly mapped applications would then automatically cover the pager,
taskbar or panel?

> Well, even if you disagree totally with the last two paragraphs,
> please consider the following very carefully:
> 
> At the fvwm-workers mailing list we have spent several months know
> trying to implement stacking order code that is able to handle the
> current GNOME layer hints, transient and override redirect windows
> properly. Perhaps you know fvwm's philosophy that states that we
> try to provide the user with every option he asks for, and especially
> we try to make it work with any application, regardless of how badly
> broken it is. Just an example: KFM uses 'override redirect' for its
> icons. If you restart fvwm while KFM is running, all these icons
> end up atop all other fvwm windows. But we don't tell the users
> "sorry, KFM is very broken, just use a different file manager", but
> we are working on a hack that alleviates the problem.
> 
> With this is mind now look at the complexity of the stacking order
> code. At the moment it must handle (but doesn't):
> 
>  1) Layer hints to the WM given in the WM config file.
>  2) Layer hints set by the application.
>  3) Layer hints set by the user in the application's config.

this is simply a matter of precedence, the layer hints in the WM config
file should only affect windows that don't request a specific layer from
the wm itself, thus 1) is a fallback value for the window manager.
2) and 3) are actually the same thing on the window manager side, if
an applications config file comes with layering information, that
should override the applications default values, but it the end, it
will only send one layer request to the wm, and that should take
precedence over layer information from the wm config file.

>  4) Broken override redirect windows (like KFM's).
>  5) Transient windows.

transient windows need to always stay on top of the window they are
transient for, thus their layer is always at least the layer of the
window they are transient for, and need to be raised above that window
if they are in the same layer.

>  6) Transients of transients of transients of ...

same applies here, that the window the transient is transient for
is itself transient is actually not important.

>  7) Transients on a different layer than the 'parent'.

outlined above, honour the layer hint as long as it's >= the parents
layer, and raise the transient above its parent if the layer is the same.

>  8) Layer hints changing while a window is mapped.

reenforce the above constrains and you are set.

>  9) Raising or lowering windows that are or are not obscured by
>     others (th Z order provided by X doesn't help much here).
> 
> And in the future:
> 
>  10) Applications requesting to be raised or lowered.
>  
> Okay, this looks simple at first. But let's take an application with
> a transient window that maps the transient on a higher layer (5, 7).
> Now it requests to change its own layer (8). The user already asked
> the application to map of layer x (1). To make it even worse the
> transient has its own transient. Don't laugh. That is really no
> unusual setup. With netscape you can have transients of transients.
> GNOME panel changes its layer at run time and it does create popup
> menus.
> 
> It's *extremely* difficult to code (you won't believe it until you
> tried to code it yourself). If you don't believe me, try to answer
> this question:
> 
>   If you have an application window A on layer x with a transient
>   B on layer y (both specified in the WM configuration). Now A changes
>   its layer to x+3. Where should windows A and B end up?

for
A - window, requests layer x
B - transient, requests layer y
the layers should initially be:
lA = x;
lB = MAX (lA, y);
if (lA == lB) raise_above_within_layer (B, A);

if then A changes layer to x+3, you do the same thing again:

lA = x+3;
lB = MAX (lA, y);
if (lA == lB) raise_above_within_layer (B, A);

so B may initally end up in a layer >y or at least later in a layer >y,
but that's simply because it's transient nature should take precedence.

>   Some suggestions:
> 
>    - both on layer x+3?
>    - A on x+3 and B on y?
>    - A on x+3 and B on y+3?
>    - A on x and B on x?
>    - A on x and B on y?
>    ...
> 
> So to make the layer hints manageable at all (if I can't convince
> anybody that the whole idea isn't good) it suggest the following
> severe restrictions for layer hints:
> 
>  1) Transient windows *must not* set layer hints. If they do the
>     WM must ignore them. Instead the WM uses the layer hint of
>     of the 'parent' (recursively if necessary).
>  2) Applications may only change their layer while in withdrawn
>     state.
>  3) The WM always places transients on the same layer as the
>     'parent'.

i don't see the need to impose those restrictions, for the implementation
side and for the spec, it'd be enough to adhere to the mentioned constrains,
i.e.

- a transient layer hint will only be honoured if the layer specified is
  the same as its parent's layer or above that.
- transients that are on the same layer as their parent will always be raised
  to stay above their parent within that same layer.

we could express a recommendation though, to usually not set layer hints
on transients, since window managers will automatically keep them above
their parents.

> 
> Bye
> 
> Dominik ^_^
> 

---
ciaoTJ