Re: layer and strut hints are unnecessary

[Dominik Vogt <dominik vogt fvwm org>]

On Wed, Oct 27, 1999 at 08:48:31PM +0200, Matthias Ettrich wrote:
> 
> > 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?

You don't.  That's what this is all about (please read on before
you begin to laugh).  

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

Hm, strange, I asked several KDE users, and they all said that
this was the one thing that bothered them most about KDE.
Okay, let's try to analyse the situation.

I hope we can agree that 'usability' for most users is the
'ability to use' the desktop and applications that is fast,
simple, intuitive, and so on.  Furthermore I claim that most
users want to have some kind of control over what happens on
their desktop.  So, why does the user want to have a window
visible?  Possible reasons might be:

 v1) He wants to get some real work done.
 v2) He needs to do a small task and needs to activate
     something in the window (e.g. start an application).
 v3) It's visually pleasing.
 v4) ...

Now why does a user move a window?

 m1) It's in the way.
 m2) Some other window is in the way.
 m3) He wants to tidy up his desktop.
 m4) ...

Why does a user raise or lower a window?

 l1) It's in the way.
 l2) Some other window is in the way.
 l3) ...

Why does a user maximize or resize a window?

 r1) It's in the way.
 r2) He's working with it and wants to have a larger work
     area.
 r3) He wants to tidy up his desktop.
 r4) ...

I hope this table lists the most important reasons for each
task (except perhaps 'playing').  We have already agreed that
it is a 'good thing' that certain applications like panels
or taskbars are not covered by newly created windows.  So
how could it happen that a window obscures a 'panel'?

 o1) The user moved the window.
 o2) The user resized the window.
 o3) The user maximized the window.
 o4) The application moved/sresized its window.
 o5) The application maximized its window.

In my proposal, (o3) and (o5) are already considered.  Maximizing
a window won't cover the 'struts' unless the user explicitly
asked the WM for it (or indirectly through the choice of the WM).

Scenario o1:

  I'm willing to ignore (m3) here because moving a window over
  the panel is most likely not 'tidying up'.  So it must be
  (m1) or (m2).  If the window is in the way we won't care much
  where it ends up.  In this case it may really bother him if it
  obscures the panel:

   p1) Moving windows out of the way may obscure the panel.

  The solution for this is:

   s1a) Iconify or shade or lower the annoying window.
   s1b) Raise the window he wants to see.

  That's what these features were primarily invented for.
  On the other hand, if he simply wants to make the window
  visible the user won't care much if it obscures the panel.
  He just wants to see it and work with it (v1) and (v3).
  So what is left of is

   p2) A window the user previously worked with obscures the
       panel because he moved the window over the panel.

  Luckily there are two easy solutions to this probelm:

   s2a) Move the window away again.
   s2b) Raise the panel.  This might be appropriate if the
        panel is obscured by several windows.  He might even
        need to move a window away before he can see a pixel
        of the panel.

Scenario o2:

  The user has resized a window.  Obviously he made it larger in
  at least one direction or otherwise it would already have covered
  the panel.  So we can ignore (r1).  Probably (r3) doesn't apply
  because partially obscuring other windows can hardly be considered
  'cleaning up the desktop'.  So it must be (r2).  In other words,
  the user wants to see more of the application, because (v1) he
  has to do some real work with it or (v3) he wants to watch it.
  I see two possibilities how the application window could end
  up covering the panel if the user doesn't want it.

   p3) He resized it so it takes up the space that the hidden panel
       would need when it is shown again.
   p4) He hasn't got complete control over the pointer, e.g. because
       ha has a shaky hand or because he is working very fast.

  We already have a good solution for (p4):

   s4) SnapAttraction.

  I think it's even turned on by default in KDE and GNOME (correct me
  if I'm wrong).

Scenario o4:

  Well, if it's one of those applications that thinks it knows
  everything better than the user and the WM, that's bad.
  Most likely the user will have to enable some workaround in
  the window manager.  That's definitely a disadvantage of the
  solution I propose:

   p5) The user has to configure the WM to discipline applications
       that don't behave well.

  But wait.  It might be a resonable default for the window
  manager to constrain application windows that resize themselves
  to the available space.  This would solve the problem.  KWM
  could easily set this default and many WMs might do the same.
  Even better: no user interaction is required.

   s5) Default WM configuration that prevents applications from
       obscuring the panel by limiting the requested size/position.

Summary:

  From the above thoughts I conclude that there are two possible
  reasons why a window might obscure a panel:

   1) Because it was convenient at the time the user moved or
      resized the window over the panel (p2).
   2) Because he didn't care back then (p1).
   3) By accident (p3).

  The solutions (s2a) and (s2b) should allow him in all three
  cases to access the buried panel.  There's another nice
  solution that can help and that is strictly application
  internal:

   s2c) The panel raises itself whenever it receives an
        EnterNotify event.

  Thus, as long as a reasonably large portion of the panel
  remains visible (i.e. one that the user can still see),
  the user shouldn't be bothered too much.  That leaves the
  case where the panel is completely covered with other
  windows.  In case of (1) or (2), he can move the offending
  window away again (1 action with the mouse).  In most
  cases this should suffice to reveal at least part of the
  panel and fall back to one of the aforementioned solutions.
  Case (3) can't happen here because if he obscured the
  whole panel it can't be by accident anymore (p3!) he
  had the chance to see the remaining pixels of the 'hidden'
  border.

Conclusion:

  If windows are not allowed to request a 'stay on top'
  hint, the user may have to move windows out of the
  way or raise the panel once in a while.  This is always
  a result of his interaction with the application/desktop/WM.
  This may happen more frequently if depending on the user's
  habits (moving windows instead of raising the window he
  wants to see).

   -> Minor user/WM interaction required in day to day work.
   -> Insisting on moving windows to make other windows
      visible doesn't work very well.  I guess this is not
      a very common situation.  Most people would get
      confused because their windows change places
      frequentsly.  Thus I believe that most people use
      shading/iconifying/raising.  As a last resort you
      can still configure the WM to keep the panel on top.

  What now is the drawback of having a 'stay on top' hint?

   -> The user is unable to move/resize windows over the
      panel if he wants to.  It is *not possible at all*
      for him to get this behaviour without changing the
      configuration of the WM or the application.

  In my eyes the consequences of having a 'stay on top' hint
  are by magnitudes more severe than thes consequences of not
  having one.  If you ever had a panel-like application that
  sticks at the top border of the screen you might be more
  willing to agree with me (the 'panel' keeps popping up
  frequently when you want to move/iconify/close a window at
  the top of the screen because the pointer gets too close to
  the border.  With the hint it's a problem that can't be
  solved without reconfiguration.  Without the hint there is
  a reasonable workaround available.

Epilogue:

  I have tried hard to stay objective in my analysis above.
  But I sincerely hope you regognize that I am not simply
  ranting about this but that I am genuinely concerned
  about the usability issue behind this.  Please, I'd
  appreciate if (for the first time on this list) someone
  would take this seriously.  Over that last few months
  I have got lots of replies that sound like "you are
  imagining things", "you can't stop progress" or
  "there is no usability issue with 'stay on top'".  That's
  about like saying that the user interface of Windows is
  the best one possible without reviewing the alternatives.

Another proposal:

  Most of the 'stay on top' applications auto-hide most of
  the time.  The usability issue that arises without the
  'stay on top' hint is that you might not be able to
  easily 'un-hide' it again.  I have an idea how to solve
  this problem (for hidden applications only):

  ------------------------------------------------------------------------
  When an application is hidden (either by user interaction
  or because a timeout expired) it sends a client message
  to the WM: 


    _NET_WM_WINDOW_HIDDEN

    When application 'hides' itself, it sends a message to the root window:

     window = target app window
     message_type = _NET_WM_WINDOW_HIDDEN
     format = 32
     data.s[0] = x
     data.s[1] = y
     data.s[2] = width
     data.s[3] = height

    The WM in turn sets up an invisible input only window with the
    specified geometry (usually the geometry of the remaining
    visible part of the window, but not necessarily).  When the
    mouse enters that area the WM 'reveals' the hidden window again
    (I'll explain how this works later).

  [[comment: One advantage of this solution is that windows can
    be 'revealed' even if they are buried below other windows.
    another is that the WM author can implement logic so that
    the window is not 'revealed' e.g. if the mouse still moves
    or if a button is pressen on a window title - in these
    cases it would be unwanted to 'reveal' the window.  There
    is still the problem that hiding interferes with flipping
    pages via mouse movement - but that is not a new problem.]]

   
    _NET_WM_WINDOW_REVEALED

    When the WM decides that the window has to be revealed (see
    above), it sends this message to the client window and
    removes the input-only window it created earlier.  If the
    application wants to reveal itself (e.g. because mail
    arrived) it *must* inform the WM by sending a
    _NET_WM_WINDOW_HIDDEN message with 'width' and 'height'
    set to zero so that the WM can delete the input-only
    window.
  
  [[comment: this mechanism would provide a common method for
    all applications to hide/reveal themselves.  Furthermore
    it could be used to define certain 'hot spots' that
    applications can act on.  Note that this can even be used
    when the window is not hidden.  The application could set
    up its whole window as the 'hidden area', and when the
    pointer enters the window it could raise itself.  But this
    might interfere with the focus policy though because the
    EnterNotify events for the windows below may be missed.]]
  ------------------------------------------------------------------------
  
> 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 
 
> >   - 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.

Nonsense.  If they do so, only *newly mapped* windows would honour it.
Obviously, if the WM can't satisfy all the requested 'do not cover'
areas, it won't kill the application or crash or whatever but instead
fall back to a different algorithm.
 
> 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.

Hm, are you saying that nobody uses Netscape because of these pesky
windows that keep respawning or try to cover your complete viewport?

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

Sorry if I misunderstood this.  Someone claimed this to be a global
property.

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

Oh please, stay objective.  Cynicism won't help.  If you read my proposal
carefully you will se that I didn't forget this case:

> >     3) A 'always keep below everything else' hint.

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

No that's not my point at all (see above).

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

Phew!  That's it.  (Perhaps I should write books ;-) )

Bye

Dominik ^_^

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