Re: layer and strut hints are unnecessary




> Solution:
> 
>   Give up the idea of layer/struts hints.  A 'do not cover'
>   hints *is* enough to do what we want.  Matthias mentioned
>   that there is a problem with auto-hiding applications.
>   Let me explain how this problem can easily be solved:
> 
>     1) A 'do not cover screen area' hint.
>     2) A 'do not cover my window' hint.
>     3) A 'always keep below everything else' hint.
> 
>   Hint (1) allows applications to define a rectangle on the
>   screen that they do not want covered.  An auto-hiding
>   application would simply set the rectangle to the area it
>   would cover if it were not hidden. Hint (2) is just a
>   convenience hint for applications that never move or
>   resize their windows (i.e. 99% of all applications).
>   The hint is honoured whenever any window is mapped and
>   possibly if a window is maximized (depending on the user
>   preferences).  Could someone please fill in the technical
>   details for such a 'rectangle' hint?  My knowledge of these
>   X mechanisms doesn't suffice to do it myself :) Hint (3)
>   may be necessary for these kfm/gmc shortcut windows.

Hint 1) *is* exactly what struts are about.  Just that I think that it's easier
for applications (and WMs) to define/calculate borders.

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

How does one configure the thing to keep the dock applications on top?


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

Your "silly restrictions" are what most users call usability. I admit that I
don't get your point. If fvwm users don't want to use layers, that's perfectly
fine with everybody on this list. The layer hint is just a *hint*. Window
managers can most certainly offer users the possibility to ignore these.


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

They can't? They can easily define a "do-not-cover-screen-area" hint that keeps
the whole desktop clear.

Applications can *always* terrorize the user: the can eat-up all CPU, freeze
the X-Server, destroy other windows, kill random processes, create a million
windows and so on. Most applications don't do these things, but not because it
wasn't possible. They don't do these things because otherwise nobody would use
them.

[snip]

> Disadvantages of above solution:
> 
>   - Slower because the additional hints are window specific.

The strut hint is window specific as well, so there's no difference.

> 
> Note:
> 
>   - I do *not* propose to abandon layers completely.  All I say
>     is that there is no reason why an application should be able
>     to request a specific layer.  I.e. layers would be strictly
>     WM internal.

How shall an application tell the window manager that it likes to be on the
desktop layer? Popup a messagebox: "Dear user! I'm window id 748933,
caption xxx, classname xxxx. I would like to be on the desktop layer because
I'm a root icon. Please read the manual of your window manager and set the
right commands in the window manager resource file. Then restart your
desktop. Good luck! And btw.: If I am already on the desktop layer, please
excuse this message box. Simply click on CANCEL buttonbelow." ? 

Struts (of reserved space) and layers are essential to the specification *if*
we want KDE users to be able to run other window managers as well without
giving away desktop icons and the startup panel. The same is required for
Gnome. 

On the other hand I see Dominik's point that this goes a little bit further
into desktop integration, maybe too far for the current specs. 

What about putting these too things in a special paragraph of the spec, maybe
even with another prefix like _NET_DE_  ( desktop environment)?


Matthias



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]