Re: Fwd: Draft 1

[Matthias Ettrich <ettrich troll no>]

[snip]

> > _NET_WM_LAYER
> > 
> > #define _NET_WIN_LAYER_DESKTOP                0
> > #define _NET_WIN_LAYER_BELOW                  2
> > #define _NET_WIN_LAYER_NORMAL                 4
> > #define _NET_WIN_LAYER_ONTOP                  6
> > #define _NET_WIN_LAYER_DOCK                   8
> > #define _NET_WIN_LAYER_ABOVE_DOCK             10
> > #define _NET_WIN_LAYER_MENU                   12
> > 
> > Type CARDINAL, format 32
> 
> OK. Same as currently.

yep, I just copied that. However, I don't understand whether we need the layers
in between, or what sense these make. Any rationale? Or was this just designed
for more flexibility? 


>  
> > _NET_WM_STATE
> > 
> > #define _NET_WM_STATE_STICKY (1<<0) /* the window sticks on the screen even when the virtual desktop scrolls */
> > #define _NET_WM_STATE_OMNIPRESENT (1<<1) /* the window is visible on all virtual desktops */
> > #define _NET_WM_STATE_MAXIMIZED_VERT (1<<2)  /* the window is vertically maximized */
> > #define _NET_WM_STATE_MAXIMIZED_HORZ (1<<3)  /* the window is horizontally maximized */
> > #define _NET_WM_STATE_SHADED (1<<4)  /* the window is shaded */
> > 
> > A window manager honors _NET_WM_STATE whenever a withdrawn window
> > requests to be mapped.  When being in another state (iconified or
> > mapped), the client can request a change by sending a _NET_WM_STATE
> > client message to the root window. (window is the respective window,
> > type _NET_WM_STATE, format 32, l[0]=<mask>, l[1]=<new values for masked
> > bits> )
> 
> Icewm also supports HIDDEN state. This would cause window not to appear
> on the taskbar or have desktop icon, but otherwise be equivalent to
> minimize. I believe other WMs also have hidden state (wmaker?).

What's the difference between this HIDDEN state and the standard ICCCM
withdrawn state?  How does an application get into HIDDEN state and what's the
advantage?

If an application withdraws a window, it should go into withdrawn state (which
also implies that the WM should destroy the decorations and reparent the window
back to the root window). At least this is my undertstanding of ICCCM.


[snip]

> > _NET_WM_MOVERESIZEGRIP
> > 
> > Defines an array of childwindows that serves as move or sizegrips. The
> > windowmanager may install a passive button grab on these windows to
> > takeover the resize or move handling. The property is handled when a
> > window becomes mapped the very first time (map request). Type
> > XA_WINDOW, format 32.
> > 
> > The default is resize to bottom right. But the grips may define an
> > additional property _NET_WM_MOVERESIZE_DIRECTION of Type XA_CARDINAL,
> > Format32 with the following values:
> > 
> > #define _NET_WM_MOVERESIZE_DIRECTION_TOPLEFT 0 /* towards the top-left */
> > #define _NET_WM_MOVERESIZE_DIRECTION_TOP 1 /* towards the top */
> > #define _NET_WM_MOVERESIZE_DIRECTION_TOPRRIGHT 2 /* towards the top-right */
> > #define _NET_WM_MOVERESIZE_DIRECTION_RIGHT 3 /* towards the right */
> > #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMRIGHT 4 /* towards the bottom-right*/
> > #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOM 5 /* towards the bottom */
> > #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMLEFT 6 /* towards the bottom-left */
> > #define _NET_WM_MOVERESIZE_DIRECTION_LEFT 7 /* towards the left */
> > #define _NET_WM_MOVERESIZE_DIRECTION_MOVE 8 /* only movement */
> 
> This seems messy. Couldn't the app just send the message to the WM when
> it wants move/resize to start. This would simplify things a lot. (and
> speed things up since WM would not have to grab things). A message
> containing the necessary info (above+click x,y,xr,yr) would be sent to
> the root window. This would also allow apps to implement special resize
> by keyboard, not just clicks.

Is this required, startin resizing with the keyboard? Usually WMs already offer
shortcuts for that, so I don't see much need.

We just saw the problem, that on MS-Windows (and Mac) windows have a nifty
resize grid and thought about supporting it as easy as possible. The passive
grab solution is extremely simple to implement and works fine in practice
(KDE/Qt does this for a while).

My first approach was just a simple boolean RESIZE_GRIP property, but Raster
asked for more flexibility, so we came up with the direction property in
addition.

I'm not sure whether a message-based solution would be better, I doubt it. It's
the same problem as with the root window: one application gets the click,
another application should process it. The standard X way to solve this, is to
use a passive grab. This doesn't even require a context switch when the drag
starts.

But there's another big advantage of the passive grab solution: applications
(or toolkits) can easily support a manual resize-grip. If the window manager
doesn't support the sizegrip protocol, the manual solution will be used
automatically. No need to ask for a protocol, etc.


>  
> > _NET_WM_STRUT
> > 
> > An array of struts. Strut[0] is the global strut, i.e. it appears on
> > all virtual desktops. The optional following struts appear only on
> > their respective virtual desktop.  A strut is defined as 4-tupel of
> > cardinals, one for each border of the screen. The order of the borders
> > is left, right, top, bottom. The client may change this property
> > anytime, a window manager therefore has to watch out for property
> > notify events. A strut is valid when the window is mapped relatively
> > to its virtual desktop.
> > 
> > Type _NET_WM_CARDINAL, format 32.
> 
> Please explain this more.

I will soon (I'll try to find some older mails first).

[snip]

> > 
> > Array of two Cardinals (type CARDINAL, format 32 ) that defines the
> > width and height of each desktop in pixel. If a client wants to change
> > the desktop geometry, it can send a _NET_DESKTOP_GEOMETRY client
> > message to the root window (type _NET_DESKTOP_GEOMETRY, format 32,
> > l[0]=<new width>, l[1]=<new height> ).
> 
> Are all desktops the same?

This is implied, yes. I'm not sure if that's sufficient. kwm doesn't support
pages yet and I doubt I will put it in. So those who write the wms with page
support (and those who use it) are challenged here :-)


>  
> > _NET_DESKTOP_VIEWPORT
> > 
> > Array of two Cardinals (type CARDINAL, format 32 ) that defines the
> > toplevel corner of the current view. For window managers that don't
> > support paged desktops, this is always (0,0). If a client wants to change
> > the desktop viewport, it can send a _NET_DESKTOP_VIEWPORT client
> > message to the root window (type _NET_DESKTOP_VIEWPORT, format 32,
> > l[0]=<new x>, l[1]=<new y> ).
> 
> Can this be unset in non-supporting WMs?

Sure, if the property doesn't exist, (0,0) is assumed. Windowmanagers like kwm
that don't support pages will set (0,0) as well and simply ignore the client
messages.


[snip]

> > _NET_DESKTOP_NAMES
> > The names of all virtual desktops. Text Property.
> 
> Who sets this? Who can change it?

Good question, I'm not sure about this yet. The current KDE solution is that
the WM sets it (and restores it in the next session) and everybody
can change it.

It's just that many apps like to display the names, the windowlist, a pager,
the wm, the taskbar (when using sendToDesktop) etc. So it's good to have a
common place to store it.

[snip]

> > 
> > _NET_CLOSE_WINDOW
> > 
> > Clients that wish to close another client ( typical examples are
> > pagers or taskbars ), shall send a _NET_CLOSE_WINDOW client message
> > request to the root window (window is the respective window that shall
> > be closed, type _NET_ACTIVE_WINDOW, format 32, l[0]=0 /*may be used
> > later*/ )
> > 
> >   Rationale: A window manager might be more clever than the usual
> >   method (send WM_DELETE message if the protocol is selected,
> >   XKillClient otherwise). It might introduce a timeout, for example.
> >   Instead of duplicating the close code, the WM can easily do the job.
> 
> OK. Should there be other window management commands: MIN,MAX,HIDE,...?

I'd say we shouldn't double protocols. Minimize is already supported by ICCCM
with XIconifyWindow (WM_STATE), maximize is supported with _NET_WM_STATE.



> 
> I think it would also be useful to have two things, 
> 
> root:_NET_PROTOCOLS (like current  _WIN_PROTOCOLS):
>   - list of all properties that WM supports
> 
> client:_NET_PROTOCOLS (new proposal)
>   - list of all properties that WM should handle/set on the window. This
> would be a speed optimization, because WM only has to handle the hints
> that application requires (even standard ICCCM and MWM hints could be
> included here).

Sounds good. For simplicity we may group the hints. Some of the hints are
constructed in a way that it is more than likely that if a wm supports one it
will also support the other.

> 
> Also needed: WORKAREA handling. (do we need this per-workspace?).

Please elaborate.

Matthias