Re: layer and strut hints are unnecessary

[Matthias Ettrich <ettrich troll no>]

>    
> > 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.
> 
> Sigh!!! Believe me or not, as long as there is still active
> fvwm development going on, fvwm will always be more configurable
> than KDE and all its applications together.  I guess one of the
> first spec related patches to fvwm will be to make fvwm ignore
> the layer hints of spec compliant applications completely.  So
> I don't care at all if this might make fvwm less usable.
> 
> Okay, you like it to have your windows buried below taskbars,
> panels, clocks, transient popup windows and whatever else.
> Nobody wants to deny you this.  But why should your personal
> taste - under the guise of usability - force everybody who is
> not adept enough to configure his window manager be forced 
>  

Dominik, you seem to try best to missunderstand me. At fIrst, your claim "more
configurable than KDE and all its application together" is not very helpful. In
fact it's plain wrong, insulting and compares apples and oranges. Never mind.
The purpose of this list is not to convince other people what's best but to
find a common denominator to serve our all users.

If you followed the rest of the discussion you would have noticed that we (at
least I) interpreted the layer hint as a semantic hint to indicate that a
window is meant to be a docking application. 

I repeated it several times and will continue you do so: It's up to the window
manager (and it's configuration) to define a stays-on-top policy or whatever.
That's not part of the specs. KDE will most certainly have a configuration
dialog to define whether the panel shall be always-on-top or not, btw.

I have no clue where you got the idea from that the WM spec definition forces
WMs to keep desktop panels always on top. The whole idea of logical layers is
to avoid "visual" hints like "stays on top" in order to give window managers
more possibilities to control the feel of the desktop.

For the same reason I wanted to have a logical decoration hint that defines
window classes (like toolbar, toolwindow, etc.) rather then let the application
decide what buttons should be visible in the decoration frame or how large the
border shall be.

*sigh*

Matthias

btw: regarding the KDE-1.x panel: Up to the 1.1 release the panel wasn't
stay-on-top. As a result I got hundreds of mails to change that, so I did it.
Unfortunatly I lacked the time back then to make it configurable....