Re: Fwd: Draft 1

[Marko Macek <Marko Macek gmx net>]

Matthias Ettrich wrote:
> 
> [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?

Yes.

Most of the time you only need DESKTOP,NORMAL,DOCK anyway. Currently in
icewm the Dock layer implies the do-not-cover hint. This will probably
not be desirable with new implementation (struts) anymore.

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

It has nothing to do with withdrawn state. 

It implies that there are two ways to access the window:
  - first level: taskbar,desktop icons,iconbox (always visible)
  - second level: window menu/list

In icewm user can select Hide from window menu (or click hide titlebar
button if enabled) and window will only be accessible from the
winlistmenu/window list.
 
> [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.

Not essential, but perhaps nice to have.
 
> 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.

Who handles the mouse pointer changing on mouse-over? The application?
Or should WM do this too by changing the window attribute?
 
> 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.

But this will not work with toolkits that only use only a single window
(toplevel) 
(Java+Swing, JX, and even gtk+ doesn't have a window for each widget).

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

I agree with you (not implementing this :)

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

Agreed. But we need an update strategy. If nothing else, just
XGrabServer (but I'd like to avoid it if there is a better way).

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

OK

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


I missed something VERY important: _NET_PROTOCOLS must always be set by
clients that use these hints, otherwise WM will ignore all these hints.
This is essential if we want the speed improvement.


I have to do some benchmarking with icewm how much of an improvement
this is? Anyone has a WM benchmark program (should map/unmap windows,
mostly)?
 
> 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.

When the WM determines the maximization rectangle (from the struts --
when you explain how), it sets a property with this rectangle.

Icewm currently sets _WIN_WORKAREA=x,y,w,h. This is not good enough for
WMs that want to have different work areas on different workspaces
(icewm workarea is the same on all workspaces).

Perhaps:

root:_NET_WORKAREA = array of [x,y,w,h] for each desktop
    Set/changed by WM. If unset, workarea is the entire desktop.

Mark
-- 
... GUI: WPS.
------------------------------------------------------------------------
Marko.Macek@gmx.net                 http://www.kiss.uni-lj.si/~k4fr0235/