Virtual Desktops and Pagers (Was: Re: Is this list alive?)

[Sasha_Vasko osca state mo us]

Sorry for breaking the thread by changing the Subject, but old one no longer
reflects idea of this disscussion.

>> Ok, we are missing the whole point here.
>

What you write in here raised a whole slew of questions that I never really
thought
about before, but that are important nevertheless.

I'd like to establish two common sense things before proceeding any further:
1) Any spec should be kept to a minumum, and be as unrestrictive as it is only
possible
in order to accomplish desired goal.
2) Support for virtual desktops does no require support for naming of those
desktops.
Naming is a good addition to virtual desktop support, but virtual desktops can
be
implemented without it.

Now if we will look at the part of the specs that is related to _DESKTOP_ stuff
we will see that all of it is needed exclusevily for Pager-WindowManager
interaction,
and is designed to make Pager's developer life easier. It all comes at the
expense
of additional code burden that has to be implemented in those WindowManagers
that are
unlucky enough to not have it already  implemented for its own needs.
At the same time spec mandates that either we accept _DESKTOP_ mess as a whole,
or we bail out of it completely, and leave user pondering as to why the hell
AfterStep
supports virtual desktops, but Gnome/KDE Pager does not work with it .
You are with us, or your are against us.  Like in good old Soviet times.

Now, having established the (2) I would like to go ahead now and explain how
spec may implement finer gradation by allowing only part of it supported by
WindowManager, in order to make Pager work :

To provide user with virtual desktops you MUST implement the following :
I) Functionality to switch in between desktops
II) Functionality to be able to determine what window is on what desktop.
( _NET_WM_DESKTOP does just that, except for the fact that NONE of the
general purpose apps will ever use it, except for 0xffffffff value of it, which
would be much more
sensible to move into something like _NET_WM_DESKTOP_STICKY in _NET_WM_STATE,
It is only usefull for WindowManager-Pager interaction )
III) Functionality to  be able to move window from one desktop to another.
( desktop/viewport size is also important thing but it is out of the scope of
this discussion)

That's it. Everything else is optional and can be implemented using this three
basic
components, or is purely a nice eye candy :
IV)Desktop names list - this is nice service, but that is not something that you
must have.
And it can be implemented on Pager's level, without demanding WindowManagers to
add user options and code to do that. If WindowManager provides this service -
then fine,
if it does not - then Pager should take care about it.
V)INSERT/DELETE desktop functionality.
Specs dose not include any description of what should be done in event ofany of
those
messages received by Window Manager. What should happen to windows on the
desktop being deleted? What shell I do to the background used for this desktop ?
What shell I do with the name of this desktop ( If I have any )? You would
probably want
to preserve background/name for the desktops that are remains, thus effectively
creating
a whole in internal WindowManager's desktops list. What should happen id new
desktop
gets inserted in place of previously deleted one ? Would you want me to reuse
name/background
and other attributes for it from deleted one ? What if I insert two desktops in
place of one ?
This is a huge mess, and will produce different results on different Window
Managers, as everybody will
implement it differently and amount of possibilities is far beyond this specs.
Why do we need this whole mess ?
Just for the sake of being able to hide/unhide/add desktop representations shown
on Pager.
But Pager can do all of it by itself, the only functionality needed here from
WindowManager is
being able to add desktops to the end of the list and remove desktops from the
end of the list.
All Pager has to do to hide desk in the middle of the list is merely request
move of all the
windows from this desktop to other desktops, and when it is done - hide this
damn subwindow/image
that is representing particular desk. From user perspective hiding desktop in
Pager is equal to
hiding it completely. All said boils down to the fact that we really need 4
optional messages instead
of two mandatory : ADD/REMOVE_LAST  and HIDE/UNHIDE. Window Manager may choose
to ignore
those completely.

VI)  Mapping between WindowManager's internal desktop numbering and Pager's
desktop numbering
What all this is needed for is to know what desktop has what Name from the list
of available. But since naming
of desktop is optional (IV)- then this item is optional as well. Besides since
there cannot  be DELETE
message for desktops inside the list (V) - that takes this issue out completely.
The only important thing
is that desktop numbers used in different places must be the same.

So here is the proposal :
1) Make _NET_DESKTOP_NAMES optional, make it static, since in practice user will
specify only
fixed amount of desktop names.
2) remove mandatory INSERT/DELETE desktops messages.
3) add optional ADD/REMOVE_LAST messages to add to the end of the desktop list/
remove from
the end of the desktop list.
4) add optional HIDE/UNHIDE desktop messages to hide/unhide desktop from the
user.
5) allow _NET_NUMBER_OF_DESKTOPS to be set to 0xffffffff thus indicating that
window manager
does not limit desktop numbers and Pager is free to use as many desks as user
requested it to.
BTW - this is not something that I came up with, this concept was created long
ago and is used in such a
veteran as fvwm. So by honoring it specs would show not only farsightedness, but
also a curtesy and
respect for the traditions.
6) add   _NET_WM_DESKTOP_STICKY to _NET_WM_STATE and make _NET_WM_DESKTOP
 modifiable only by Window Manager.
*******************************************************************************************************************
>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.

Since there should not be a DELETE message for desktop inthe middle of the list
-
that is not needed

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

Again I cannot update nor set _NET_DESKTOP_NAMES as I don't have any
configuration options for user to set names on desktop - this is left out
of Window Manager and into the Pager's domain.

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

Yes this is horrible mess, and I don't want to clatter Window Manger with
functionality, that can easily
be implemented in Pager with some additional effort.

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

Pager must be able to request a move of the window from Window Manager
without it - it is not a Pager. If Window Manager denies such a move - all
Pager has to do is to submit and cancel operation requested by User.
Again there should not be any deletes of the desktops from the middle of the
list, unless we want to wreak a havoc, and deletes from the end of the list
does not break desktop sequence. Again Order in which Pager represents
desktops is not  correlated with Window Manager numbering of the desktops,
In fact Window Manager should not care at all about how Pager represents those
as the result Pager is free to play with it at will, without bothering Window
Manger.
Virtual Desktop from the point of view of Window Manger is nothing but a logical
unit
that is not related to other virtual desktop logical units. Therefore any
geometrical
representations of desktop order is purely artificial

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

Like I said. If it was up to me I would choose an easy line and go with this
suggestions,
but we must think of users, and users will be very unhappy with this decision.

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

I would have to add configuration options for allowing user to define
desktop names, which would conflict/duplicate AfterStep's own Pager options
I would have to honor dubious DELETE/INSERT desktop options, thus forcing
AfterStep's own Pager to go this way as well,  And I would have to clatter
AfterStep
with sugnificant amount of overhead and illogical code in order to support said
mess.
It's not that I'm lazy, it's just that evry thingle piece that you add to
already big program
decreases its maintainability on the long run, and thus I would put my life into
preventing
any change that is not absolutely must have, and is not a logical extension of
existing
infrastructure from entering it.

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

Yes I agree with that  - that is essential for overall operation.
Again as I stated above - app should not be able, and does not need
to set this property. It must be purely Window Manager domain property.

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

Please don't allow desktops have different geometry!!!!!
That would extremely complicate things, and use of it is quite dubious.

>Michael

Sasha