Re: WIP: wm-spec 1.9b

[Dominik Vogt <dominik vogt fvwm org>]

On Fri, Sep 17, 1999 at 12:17:44PM +0200, timj@gtk.org wrote:
> > 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?

Yes, of course. I can't imagine a reason why they should not be
able to do so. If you don't want them, then just provide hints that
a certain application like a panel doesn't want to be overlapped
by new windows. Specifying a layer is an extreme method of achieving
this. And it regularly annoys the user as soon as he (or she) takes
over control of the already placed window.

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

Well, that sounds easy, but the common practice with fvwm is to use
layers only to make GNOME applications work as a normal window. That
is the opposite of what you suggest.

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

Again, personally I hate these 'clever' windows that think they know better
where I want them. I always swicth automatic raising of transients off.
And so do many other fvwm users. And I don't see any need why this
should be so. Did you never have a transient window you wanted to
paste something into from its 'parent' window?

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

No, not important, but it makes the code much more complex.

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

It's hardly this easy. If you lower A again, B will be stuck on the higher
layer.

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

Hrm, I think it's a silly restriction to transient windows. While forcing
transients on the same layer doesn't affect their actual placement above
or below the transient for. The ICCCM makes no statements of where
transients have to be placed. Doing so in this spec will annoy users
in the future. Isn't this what this spec is all about: finding a new
convention to improve the usability of X/WMs/DEs? I can see no
improvement with the current layer hints. Quite the contrary: users
keep complaining about layers because the applications using them think
they know better what the user wants and take control away from him
(ort her).

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, dominik_vogt@hp.com