Re: Is this list alive?

[Michael ROGERS <M Rogers cs ucl ac uk>]

> Ok, we are missing the whole point here.

Yes, I'm afraid I still don't understand what you're saying. Let me 
lay out the situation as I see it, then please point out where I have 
gone wrong.

Does AfterStep keep track of which AfterStep desktop each window is 
on? I suppose it must do.

AfterStep also has to keep track of the _NET_WM_DESKTOP property for 
each window, and ensure that if the property changes, either the 
window is placed on the requested desktop or the property is changed 
to reflect the desktop the window was placed on.

AfterStep must therefore maintain a mapping between its own desktops 
and the desktops referred to by clients, pagers, the spec etc. Any 
desktop which is mentioned in a _NET_WM_DESKTOP hint on any window 
must correspond to an AfterStep desktop, so that when the pager says 
"Move window X to desktop Y", the window manager knows which desktop 
the pager is referring to. Conversely, any AfterStep desktop which 
contains windows must have a corresponding _NET_WM_DESKTOP value, so 
that the pager can know which desktop every window appears on.

The AfterStep desktop list may contain "holes" - for all I know  
there may be three AfterStep desktops numbered 1, 2 and 400. I don't 
care and neither does the pager. The spec desktop list may not 
contain holes, so if there are three spec desktops they must be 
numbered 0, 1 and 2, and _NET_NUMBER_OF_DESKTOPS must be set to 3. If 
spec desktop 1 is deleted, spec desktop 2 must therefore be 
renumbered 1. The _NET_WM_DESKTOP property for every window on spec 
desktop 2 must be changed to 1 by the window manager. The window 
manager must also update _NET_DESKTOP_NAMES, _NET_DESKTOP_VIEWPORT 
and _NET_WORKAREA on the root window, removing one entry and 
shuffling the rest along, and it must decrement 
_NET_NUMBER_OF_DESKTOPS.

Yes, this is a horrible mess. I'd like to repeat that I argued 
against including this stuff in the spec.  ;)

> Idea is that Window Manager might choose not to care about number 
> of user's desktops, its naming, etc., etc., etc. at all. It simply 
> allows user to do anything he/she wants. Pager therefore has rights 
> to do anything it wants, unrestricted by Window Manager imposed 
> limits.

You can't just let the pager do what it wants - the window manager is 
responsible for actually moving windows, deleting desktops etc in 
response to the pager's requests, so the pager's concept of which 
desktops exist (and in what order) must correspond to the window 
manager's concept.

> For example as far as AfterStep does not care about the number of 
> desktops used by user, and it does not have any configuration 
> options to mandate number of those, and names of those, it would 
> simply go and set  _NET_NUMBER_OF_DESKTOPS to the number of 
> supported desktops, which would be 0xffffffff, and it would leave 
> list of desktop names blank, since it does not know and does not 
> care about desktop names. That kind of setup would definately break 
> Pager, if it does not anticipate such an occasion.
> 
> That is a valid behavior and it should be allowed by the specs, 
> unless we want to see wierd Pager behaviour, whenever it gets into 
> the situation like that.

If you really don't want to bother about desktops as the pager sees 
them, I think the closest you can get under the current specs is to 
leave _NET_WM_DESKTOP, _NET_DESKTOP_NAMES, _NET_WORKAREA, 
_NET_CURRENT_DESKTOP, _NET_DESKTOP_GEOMETRY and _NET_DESKTOP_VIEWPORT 
out of _NET_SUPPORTED... in other words, opt out of supporting 
multiple desktops as the spec defines them. The pager should 
recognise this and quit with an error message.
 
> Otherwise it will not be possible to make Window Manager compliant 
> without effectively crippling it down. I don't think that crippling 
> down Window Managers is the goal of this specs.

I don't understand how the spec is limiting the user's options in any 
way. You might need some extra (nasty) code to AfterStep to map 
AfterStep desktops to spec desktops, but how does that cripple the 
window manager?

By the way, I would like to propose another clarification of the 
spec: under _NET_WM_DESKTOP, can we insert the following:

"It is the responsibility of the Window Manager to ensure that this 
property corresponds to an existing desktop. If a Client requests 
that its window is placed on a nonexistent desktop, the Window 
Manager MUST update this property to reflect the desktop on which the 
window was placed. If a desktop is inserted or deleted, the Window 
Manager MUST update this property on all affected windows."

Similar warnings are needed for other hints which may be affected by 
a desktop being deleted or inserted, but I can't be bothered to write 
them.  :o/  _NET_DESKTOP_GEOMETRY also needs clarification - is it a 
list of sets of dimensions for each desktop, or one set of dimensions 
for all desktops?


Michael