Re: layer and strut hints are unnecessary

[Dominik Vogt <dominik vogt fvwm org>]

On Wed, Oct 27, 1999 at 06:58:25PM +0200, Marko Macek wrote:
> Hi!
> 
> >  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: 
> 
> I agree about dropping the requirement for layer hint. If we drop layers,
> we need a few hints:
>     - desktop (stays below other windows)
>     - fullscreen (window can occupy the entire screen, not just the
> WORKAREA).
>     - on-top
> 
> Does anyone see the need to keep the layer support as a requirement?
> (We could specify it as a completely optional feature).

Finally someone agrees with something I say :-)  At least
there is progress.  Please refer to my longer mail why I
think that 'on-top' is not necessary.

> >    1) A 'do not cover screen area' hint. 
> 
> This is exactly what STRUT hint is. It is set on each app window and the
> WM calculates the resulting WORKAREA from all the hints.
> 
> I don't think we need a do-not-cover hint.

Not really.  As I mentioned im my original posting it would
only be a convenience aid.  The application wouldn't need
any knowledge of the size of WM decorations.

> >  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. 
> 
> This is needed. There are two problems: 
>   - geometry isn't really known until the window is reparented and that
> can't (???) be done without showing the window (or it's icon).

I had a hard time to implement this in a fvwm module (FvwmButtons).
The solution is horrible:

  - When the button bar starts up, it creates the application
    window it wants to use as a panel.  To prevent a flash the
    window must be mapped somewhere off screen (e.g. at
    -32767-32767).  This may require some configuration on 
    WM side.
  - When the window is created, fvwm tells the module the
    window id of the new window.  In the process of swallowing
    the panel window FvwmButtons unmaps the window.
  - Before the window is mapped, FvwmButtons sets the user
    specified size hints to make sure the window is placed
    off screen at first (yuck!).
  - The window is mapped by the module.
  - When FvwmButtons slides out the window, it climbs up the
    window hierarchy until it finds the topmost parent (except
    the root window of course).  It takes the parent's geometry
    and the offset of the window itself to calculate the start
    and end positions of the animation.
  - The window is animated as required.

And to further complicate this, the WM frame is destroyed
when the window is unmapped, so you can't even remember the
the size of the decorations between two animations :-(
And of course the X server must be grabbed during the
whole operation.

>   - there are lots of geometry variations possible (with MWM hints,
> non/resizable windows, _NET_DECORATION, ...)

Why does this matter?

> Java really suffers because of this problem, because it needs to set the
> entire frame size and that just can't be done in X right now without
> guessing.

Yes, that's true.  Even with my solution it is theoretically
possible that the top level window is not the WM frame window.

Bye

Dominik ^_^

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