Re: Is this list alive?

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

> You see it poses a considerable difficulties - to grow and shrink a list of 
> used desktops. How can I know that desk is unused and I should remove it from 
> list ? That there are no windows in it ? That would be incorrect. For example 
> I may have more used desks, and lesser used desks, and those lesser used
> desks may have no windows on them for some time, but I still want to see
> them on my pager, and be able to switch to them using Pager, whenever I
> have a whim to do so. On the other hand user may erroneously hit the
> wrong key ( repeatedly ) and create bunch of unneeded desks, and
> clatter Pager in this way, if desk list is to grow dynamically.

I think desktops should only be created and destroyed by the user (as you 
say, I might want to keep a desktop around even when I'm not using it). If 
the user accidentally creates a bunch of desktops by holding down a key, the 
desktops will start to appear in the pager and the mistake will be obvious. 
The
user can then use the pager's or window manager's Delete Desktop command to 
remove them.

> >Sorry to get philospophical, but in what sense does a desktop exist before it
> >has a name or has some windows placed on it? Does the pager need to care 
> >about it? If not, maybe it should be kept internal to the WM and only get 
> >added to the list of desktops when it becomes "interesting".
> >
> 
> It exists in the sense that if user tells me as a WM to go and put some
> particular window on desk #256, I would humbly go and create virtual root for
> this desk, internal data structure and everything else, and place this window 
> on this desk. Again if Pager would ask me to switch to this desk - I would go 
> there without questioning Pager's autority.
> Before that happen - desktop existed only as a possibility - without occupying
> any resources, after - it exists as implementation.

Exactly - so unless the user specifically requests that a new desktop should 
be
created, no resources are wasted.

The only loophole that I can see is if the pager has Next Desktop / Previous 
Desktop buttons. If the user creates desktops 0, 1 and 256 through the WM, 
should the pager treat these as 0, 1 and 2 (flipping directly from 1 to 256 in 
other words) or 0, 1 and 256 (creating intermediate desktops as the user 
passes
over them, until 256 is reached)? I would say the former behaviour makes more 
sense, because otherwise desktops are being created without the user 
specifically requesting it (which is confusing and wastes resources).

There's still the question of whether we say that the pager "skipped empty 
desktops" or whether the intermediate desktops "don't exist". The spec isn't 
clear about how to treat "holes" in the list of desktops - I think it's 
assumed
that the list will be contiguous. However, it is possible to insert a new 
desktop between two existing desktops, so there is no need to have holes in 
the list. If I create desktops 0, 1 and 256 then for all the pager knows these 
are desktops 0, 1 and 2. If I later create desktop 127, a new desktop is 
simply
inserted between desktops 1 and 2.

So when a desktop is created by the WM, the size of _NET_NUMBER_OF_DESKTOPS 
should only be increased by 1, regardless of the number of intermediate 
desktops which exist "conceptually". The pager doesn't need to care about 
these
desktops.

I suggest this clarification to the spec:

"Desktops should not be inserted or deleted unless the user specifically 
requests it. For example, a desktop should not be removed automatically when 
the user removes the last window from that desktop. When a new desktop is 
created by the window manager, the value of _NET_NUMBER_OF_DESKTOPS should 
only
be increased by 1, even if the newly created desktop is not conceptually 
adjacent to an existing desktop. Intermediate desktops should be inserted as 
and when they are used.

The value of a _NET_INSERT_DESKTOP message should not be higher than the 
value of _NET_NUMBER_OF_DESKTOPS + 1. If the value of a _NET_INSERT_DESKTOP 
message is higher than _NET_NUMBER_OF_DESKTOPS, the WM should create a new 
desktop conceptually adjacent to (and above) the highest existing desktop. As 
stated above, the value of _NET_NUMBER_OF_DESKTOPS should only be increased by 
1."

> That also leads us to another problem - desks may not be numbered in order - 
> you may use desks 0, 10, 100 - in which cases I, as a window manager will 
> have to maintain some sort of crossreferece betwenn Pager's desk numbers and 
> my internal desk numbers,

Unfortunately I think that's inevitable, if the WM's desktop list allows holes 
and the pager's desktop list doesn't. It's only an extra 4 bytes for each 
desktop though.  ;)

> and also user might be dissatisfyed with the fact that Pager is showing 
> those desks as numbered 0,1,2 instead of wanted 0, 10, 100.

I think this is what the desktop names are for - so the window manager and the 
pager can agree on names for the desktops. So you can name desktops 0, 1 and 2 
"0", "10" and "100" if you want. (Maybe you should consider using the _NET 
names internally instead of numbers, so that when the user renames a desktop 
he sees consistent behaviour?)

> All said boils down to the fact that WM may desire to provide better 
> flexibility and freedom, by exporting decision making process out of self and 
> into Pager, and placing such an ungrounded restriction as to force a limited 
> fixed number of desks is something that can be done out of lazyness only.

I didn't realise the number of desks was supposed to be fixed - I thought it 
was just supposed to indicate the number of desktops the pager or window 
manager should currently be interested in.

I agree that exporting the WM's internals for the pager to play with is a 
messy
business, I argued against it, but there you go.  :)

> Another good reason to add this is that any sane Pager implementation
> would want to do some range checking on number of desktops any way, and 
> fallback on some predefined behavior it it exceeds some reasonable value. By 
> adding this provision to the specs you simply mandate this fallback behavior 
> to be standard among Pagers.

Sorry, I don't understand what you mean. I think the clarification above deals 
with the possibility of accidentally creating hundreds of desktops... if the 
user deliberately creates hundreds of desktops, then yes there must be a 
limit.
Maybe it should be part of the spec so that the WM and the pager set same 
limit?

How about 256? (Remember I'm talking about 256 actual desktops, not the 
highest index you can assign to a desktop.)

> >(a) The virtual root window is for drawing the background *only*. No client
> >(including the owner of the virtual root window) should expect its contents 
> >to be safe. Any drawing which needs to be kept safe from other clients 
> >should be done in children of the virtual root window.
> 
> I agree with that

OK, anyone vote for the other behaviour, or shall we add this clarification to 
the spec?


Michael