Re: Pending EWMH additions

[Matthias Clasen <maclas gmx de>]

> 
> Hi,
> 
> Here is a patch that tackles some of the issues.
> 
>  - I cleaned up the _NET_DESKTOP_LAYOUT patch a bit 
>    (but wasn't sure what issues were left, maybe I didn't 
>     address them)

No, not really. Here they are again:

1) I don't think we should introduce the term "workspace switcher" here.
The rest of the spec
    speaks consistently about "pagers".

2) If we end up adding this, the introduction has to be fixed. It still
says:

This spec doesn't cover any of the following:

[...]

Geometry between desktops.

Clients appearing on a proper subset of desktops.


3) There should be some hint about what wms are expected to do with the
layout information
    (electric borders, straddling windows, etc)

4) How should wms behave if _NET_DESKTOP_LAYOUT is not present ? Suppress
electric
    borders, become layout master themselves, or what ?

>  - Added _NET_SHOWING_DESKTOP root window property and client 
>    message

This looks simple, but may soon get complicated when you try to work out how
this should interact with MapRequests: Should no new windows be mapped as
long as the desktop is shown, or only dialogs (_NET_WM_TYPE_DIALOG), or only

urgent dialogs (UrgencyHint) ?

And does the wm reject state changes during this time or simply queue them ?
Ie if I deiconify a window while the desktop is shown, will it be restored
as iconic
or normal when the desktop gets "unshown" ?

Or do we leave all this unspecified ?
 
> 
>  - Added _NET_WM_STATE_STAYS_ON_TOP (I like FLOATING more, but since
>    KWin uses STAYS_ON_TOP already maybe it's not worth changing)

As far as names are concerned, I would prefer FLOATING, but I'm a bit
concerned
about this addition, regardless how we name it. We basically reintroduce the
old
Gnome-hints style layering for normal windows.

>  - Added _NET_WM_STATE_STUCK_TO_GLASS (this is for onscreen keyboards, 
>    but doesn't fully cover their needs; the other thing they need is 
>    to never be focused when clicked. I'm not sure what the right 
>    thing here is, just throwing out an idea.)

Do we really need this ? Can't we simply say that floating docks should
behave like this ? Regarding focus, we already demand that wms must
follow the ICCCM which already allows to specify this.

> Of the other issues, I would like to sort out the saving-window-states
> thing, but only a couple people commented, so I don't feel like we
> have consensus. Still it's a big practical problem IMO. Well, rather,
> if we do nothing the "applications are responsible for it" solution
> will just happen by itself. So if people prefer another solution we
> should cover this.

I'll have to re-read that thread again.

> 
> I would say the multihead/Xinerama discussion can be saved for a later
> version of the spec. I'm not sure yet how many issues there are.

Agreed. Obvious issues are maximization and per-head workarea.

Matthias

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net