Re: Pending EWMH additions

[Havoc Pennington <hp redhat com>]

Matthias Clasen <maclas gmx de> writes: 
> 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.
>

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

I don't think the spec requires anything along these lines. So it
would be a "here is what you could do for example" note at most.

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

Again, up to the WM IMO.
 
> 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 ?

I think it can all be left unspecified. I don't see a reason apps
would need to know the policies here - it's part of WM policy.
 
> 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.

Yeah I know. I don't know how to deal with the "xmms/gkrellm" problem
though, otherwise.

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

Docks are different, they are below fullscreen windows, can be below
other docks, can be below dialogs.

The problem with the ICCCM input=FALSE flag is that for accessibility
you have to be able to "focus" any window to perform window
operations, such as minimize. So you can do "fake focus" (focus
according to the WM but no XSetInputFocus()). e.g. I need to be able
to open the window menu for "xclock" using only the keyboard.

However, also for accessibility, you don't want to focus the onscreen
keyboard at all, not even in this "fake focus" sense. So the ICCCM
really doesn't express the required semantic.

I know this is a corner case, but it's a fairly important one for
people that use onscreen keyboards.

Don't know the best answer.

Havoc