Re: layer and strut hints are unnecessary



On Wed, Oct 27, 1999 at 06:46:23PM +0100, Michael ROGERS wrote:
> 
> >  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.

Possible, but unnecessary complexity in my eyes.

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

Yes, I misunderstood the struts idea.  I thought the
areas were global.

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

In a separate mail I tried to explain why I think that
a 'sticky layer' is unnecessary.

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

No problem at all.  Works perfectly without the dock layer.

> I would like to be able to move windows under the panel while keeping
> them raised above other "normal" windows.

Please refer to my second mail on why I don't see a real
reason why this would be a usability enhancement.

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

Like Netscape?

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

8-)

Bye

Dominik ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de



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