Re: layer and strut hints are unnecessary

[Michael ROGERS <M Rogers cs ucl ac uk>]

>  The user can't easily override strut and layer hints,
>  e.g. by raising an application over the 'dock' layer
>  and is possibly not able to move a window ove the
>  struts area.

This is possible by configuring the panel/dock/whatever to not use the topmost 
layer. Or, the window manager could ignore struts and layers as an option.

>  There is a problem with changing the
>  struts too: what happens with existing applications
>  if a new 'panel' (or whatever) that wants to enlarge
>  the struts is created (or destroyed)?  How does this
>  affect applications?  Shouldn't there be a central
>  instance that manages struts (some kind of 'strut
>  server')?  Otherwise the strut mechanism is prone to
>  race conditions (e.g. app. A wants to enlarge the bottom
>  strut at the same time as app. B shrinks it. I see no
>  way to prevent such a thing if applications are allowed
>  to set the absolute strut size).

The window manager should be the "strut server". An app could set a hint on its
own window which specified a part (up to the whole) of the window that it 
wanted to use as a strut. Eg, an auto-hiding panel would only specify the two
pixels at the screen edge as a strut. No other application will interfere with
these hints. Also a client message will be needed if the size of the strut
changes (eg the user changes the panel from "auto hide" to "always on top", so
now the strut covers the whole panel window).

>  Well, I have mentioned it several times before, but
>  nobody seems to take my concern seriously:  users *do*
>  want to have complete control over their desktops
>  (the many complaints about the layer hints that I get
>  on the fvwm mailing lists prove it).  Many users don't
>  think layers and struts are a usability enhancement.
>  Quite the contrary, they are desperately looking for
>  a way to override the layer hint.  I just can't
>  understand why layers are celebrated as the big leap
>  in usability (for a certain type of users) while the
>  loss of usability is continually being ignored (for
>  other users).

I agree - three layers (desktop features, normal windows, and sticky features)
are sufficient.

>Advantages of above solution:
>
>  - The user can raise or lower any window above/below the
>    'dock' applications without configuring anything.

I don't consider that an advantage - I would like to be able to maximise
windows without them covering the panel, but while covering other "normal" 
windows. I would like to be able to move windows under the panel while keeping
them raised above other "normal" windows.

>  - The user can move and resize his windows freely, without
>    any silly restrictions imposed by the WM or the DE or the
>    applications.

It's the job of the WM to impose a policy (== silly restrictions).  ;)

>  - Applications can't terrorize the user with windows that
>    request screen filling struts or layer 1000000 to make
>    sure they are always visible (just imagine web pages could
>    set this hint!).

If the strut can only be defined as part or all of the application's window,
the former won't be a problem. If there are only three layers, the latter will 
be less likely. In any case I would not use an application which behaved like 
that.

>  - The code to handle this is already in fvwm :-)

Aaaaaah.:)


Michael Rogers