Re: Draft 1.9b - some comments

[Marko Macek <Marko Macek gmx net>]

Hi!

> Dropping MWM hints has another advantage: one roundtrip less since 
> _NET_WM_DECORATION will of course be integrated with the other  
> properties. 

It is fine by me, as long as we specify that it overrides the MWM hints.
But MWM also has hints for functions, not just decorations, so that the
buttons can be disabled for example... How do we handle this.

. 


> The property isn't complete, though. What's still lacking is a read-only

> property on the root window, created by the window manager, that
propagates the 
> maximum rectangle that can be used by applications ( i.e. the geometry a

> maximized window on a certain desktop would get ). 

_NET_WORKAREA is intended for this. I just needed an explanation of how
the STRUT mechanism should work. Thanks!

Two questions:

- should windows with NET_STRUT... be on-top automatically?

- Perhaps it would be nice to have a hint that apps could set to map
inside workarea?

I also have a few other points listed here (reading from my Palm, I don't
have the time to update the spec document fully):
   - it would be nice to have NEW_WM_STATE as a list of Atoms, because
this would make it more extensible (otherwise I'd like to add a few states like
minimized and hidden). This needs a new update mechanism (ADD/REMOVE/SET
state)
   - same for NEW_WM_HINTS, except there is no reason to have SET. I
believe that hints should follow the same mechanism for updating as state. (stuff
that changes behaviour should be modifiable by the WM).

Summary: 

NET_WM_STATE contains (overridable by the WM):
    NET_WM_DESKTOP
    NET_WM_STATE
    NET_WM_HINTS
    NET_WM_GEOMETRY (removed after read by WM, there is XGetGeometry)
    
NET_WM_HINTS contains:
    NET_PROPERTIES
    NET_WM_STRUT
    NET_MINI_ICON
    NET_WM_DECORATION
    WM_PROTOCOLS
    (perhaps we could add other X11 hints here)

   - _NET_MINI_ICON = _KWM_WIN_ICON

   - NET_FRAME_GEOMETRY set by application to enable more ways to set the
geometry (full frame, client+titlebar, or just client area) (Java
desperately needs this or complicated ways to get frame decoration dimensions (which
can differ between window states, ... messy))).

   - if we drop layers we need hint for:
      - desktop (stay below other windows)
      - fullscreen hint that ignores the WORKAREA
      - no-raise-on-click (for desktop)
      - "on-top" and maybe "below" (above desktop)


>feature is to get more space for applications. Now consider the
>following race 
>condition: you move the mouse over the hidden panel, the panel >slides
in. Then 
>you maximize a window _before_ the panel slides back again. What >size
will that 
>maximized window get? 

The current GNOME panel has just this bug. It should not set Layer=Dock
when set to AutoHide (set to AboveDock instead, but this will overwrite a few
pixels of the application space).

Mark


-- 
Sent through Global Message Exchange - http://www.gmx.net