layer and strut hints are unnecessary

[Dominik Vogt <dominik vogt fvwm org>]

Sorry that I start a new thred about this, but the various
comments on this topic are in too many mails, so it would
be impractical to compose half a dozen replies to the
various mails.

Current status:

  Finally Matthias found the time to explain this 'struts'
  idea; and now we have two mechanisms (layers and struts)
  that are made to make one thing possible:  applications
  that are not covered by other windows.  Matthias states
  that a hint 'do not cover me' is not sufficient.

Problems:

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

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

  Matthias mentioned that the user wants it this way
  because (s)he started the panel/taskbar/... in the first
  place.  In my eyes this is nonsense.  Just because I
  start an application doesn't mean it does things in a
  way I like.  Perhaps its advantages are still more
  important to me than its disadvantages.  Or perhaps
  it's the only application that does what I want.

  Let me ask a question: how do users get the usability
  they had without struts/layers back?  If this list/spec
  is really about 'usability' then this question *has to
  be answered* before the final spec is made.  And the answer
  can't be: 'You have to open some cryptic config panel
  and click some button' or so.  Most computer users
  are idiots (including me) and don't even know these
  panels exist.

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.

Advantages of above solution:

  - The user can raise or lower any window above/below the
    'dock' applications without configuring anything.
  - The user can move and resize his windows freely, without
    any silly restrictions imposed by the WM or the DE or the
    applications.
  - 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!).
  - An application can still easily request not to be obscured
    by newly created windows (or maximized windows if you like).
  - The user could still request a specific layer via X resources
    (if the WM handles them).
  - Less configurability necessary to control this behaviour.
    It simply suits more users with the default settings.
  - No race conditions possible.
  - We need only one class of hints to handle this problem
  - The code to handle this is already in fvwm :-)

Disadvantages of above solution:

  - Slower because the additional hints are window specific.

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.

Open issues:

  - How can the application know which area it will cover when
    it is mapped?  This problem exists with my proposal as well
    as with the 'struts' idea.  Can probably be solved by my
    proposal below.

Another proposal:

  I think it would be a good idea to have properties for
  communicating information about the frame window.
  This would greatly simplify 'sliding' applications into
  view like CDE panels do.  Furthermore it would solve the
  problem mentioned above.  The required information would
  include the frame geometry, the offset of the application
  window within the frame and the window id of the frame
  window.

Bye

Dominik ^_^

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