Collating proposed changes to 1.9e

[Julian Adams <julian adams gmx net>]

-----BEGIN PGP SIGNED MESSAGE-----

I've been collating all the recent proposed changes to the spec (post 1.9e)
which I have been able to find from the archive. I hope to cover all the
proposals in this email. If I've missed anything then *sorry* it isn't
intentional - pls post it.

It seems that there are at least 2 implementations of this spec already, and
that these are incompatible due to ambiguity in the spec. If only these small
points could be agreed then an initial spec would be basically complete.

I have no idea who or what would 'ratify' the spec, but agreement on this list
would be a start.

The text below is borrowed from the original authors.

#1 Workspace addition / removal:
--------------------------
There is a clear ambiguity in the spec, and 2 solutions have been proposed:

>First solution allows for Insertion/Deletion of the desktops in/from
> the middle of the list, but is more cumbersom, as it involves burden of
>tracking what Desktop Name, root background, etc. goes with what desktop.
>Second option is much simplier, but allows only for addition/deletion
> of desktops to/from the tail of the list:
>
> APPROACH 1:
>  Add property :
> <quote>
> _NET_ACTIVE_DESKTOPS, CARDINAL[]
>
> This property MUST be set by WM to list numbers of all accessible virtual
> desktops.
> This Property must be updated whenever new desktop is added or removed.
> </quote>
>
> all the other per-desktop properties will have the same length, and Ns
> element of any of those properties, will cary information related to
> the desktop number stored in Ns element of _NET_ACTIVE_DESKTOPS property.
> This approach will allow for dynamic adding/removing of the desktops
> in any order, sequence and with any number, at the same time it will
> inform any Pager or other app, if there are any gaps in desk numbering,
> that can indicate that some desk was removed from the middle of the list.
> Pagers may provide users with some visible signs in such a case.
>
> More that that  - it will provide information on what's been delete to
> Pager/windowmanager in case it restarts, and all internal logs are lost.
> It will also allow for that piece of info to be carried over to other WMs
> if user changes WM without exiting X.
>
> _NET_WM_DESKTOP of any window in that case will be refering to the desktop
> number whithin this list, thus making making situations when desktop is
> deleted from the middle of the list much easier to handle, making
> reparenting and updating of this property on ALL the windows placed
> on the desk, after the one being deleted unneeded.
>
> Also add something like:
>
> <quote>
> When desktop is being deleted all the clients from this desktop must be
> moved to the next available desktop
> with smaller number. If it is not available - then to the next available
> desktop with higher number. If no other
> desktops are available - request will be denied.
> </quote>
>
> *****************************************************************
> APPROACH 2:
>
> Instead of :
> <quote>
> A Pager can insert or delete a certain desktop by sending
> a _NET_{INSERT/DELETE}_DESKTOP client message to the root window.
> </quote>
>
> Specs should read :
>
> <quote>
> A Pager can request change in the desktops number by sending
> a _NET_SET_NUMBER_OF_DESKTOPS message to the root window:
>
> NET_SET_NUMBER_OF_DESKTOPS
>   window = target app window
>   message_type = _NET_SET_NUMBER_OF_DESKTOPS
>   format = 16
>   data.s[0] = new_desktops_number
>
> Window Manager is free to honor or reject this request. If request is
> honored
> _NET_NUMBER_OF_DESKTOPS will be adjusted to the new number of desktops. If
> request is honored, then _NET_VIRTUAL_ROOTS (if supported) has to be
> adjusted to
> store new number od desktop virtual root window IDs. _NET_DESKTOP_NAMES
> property
> may remain unchanged as it represents pre-configured static information.
> If number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the
> new range
> of of available desktops, then current desk must be changed to the very
> last available
> desktop from the new set, and _NET_CURRENT_DESKTOP must be adjusted
> accordingly.
> If number of desktops is shrinking then clients that are still present on
> desktops,
> that are out of the new range, must be moved to the very last desktop from
> the new
> set.
> </quote>
>
> also the following change has sence IMHO, as desktop names are rather
> independent from the fact that we increasing or decreasing number of
> desktops.As far as it is likely to be preconfigured, and if you first
> shrink
> desktops list and then grow it  - you will ewant to use same names as
> you used before. By keeping this property unchanged you save some
> time from unneccessary udates of it.
>
> So Instead of :
> <quote>
> _NET_DESKTOP_NAMES
>
> The names of all virtual desktops in UTF8 encoding. This property MAY be
> changed by a Pager or the Window Mangaer at any time. When a desktop is
> added or
> removed, the Window Manager MUST update this list.
> </quote>
>
> specs should read :
>
> <quote>
> _NET_DESKTOP_NAMES
>
> The names of all virtual desktops in UTF8 encoding. This property MAY be
> changed by a Pager or the Window Mangaer at any time.
> </quote>


#2 _NET_WM_MOVERESIZE   Could be changed for consistency from 16 to 32 -
---------------------------------------------------------------

#3 _NET_PROPERTIES Can be dropped -
----------------------------------
 This was not implemented and should be removed from the
 specification. This list of atoms would require a round-trip to
 the X server to get the list of supported
 hints/properties/messages, and then we would have to have
 another round-trip to fetch the data that we wanted from the
 client window.  With the design, we can         do this in one round trip,
 because the X server will report back what does and doesn't
 exist.


#4 _NET_WM_WINDOW_TYPE
--------------------------
Could be changed from a list of atoms to an enumerated value for *simplicity*:

 Window Types:

 Normal  = 0
 Desktop         = 1
 Dock    = 2
 Toolbar         = 3
 Menu    = 4
 Dialog  = 5

The same usage and explanation still applies.

Much commentary has questioned whether this is simpler : esp -
>This needs to be a list of values to allow for extensions to the list of
>types later - if an app which is using an extended type encounters a window
>manager which only recognises basic types, a list of values allows the app to
>specify an extended type and a "fallback". An enumerated value leaves the
>window manager with no clues if it doesn't recognise the requested type.


#5 _NET_WM_STATE
-----------------
 Again, this has been changed from a list of atoms to a bitfield of
 the following values (OR'ed together)

 States:

 Modal           = 1 << 0
 Sticky          = 1 << 1
 MaxVert                 = 1 << 2
 MaxHoriz        = 1 << 3
 Shaded          = 1 << 4
 SkipTaskbar     = 1 << 5

 And we added a StaysOnTop (i.e. AlwaysOnTop, OmniPresent, ...)

 StaysOnTop      = 1 << 6

 Changing State:

 To change state, send a ClientMessate to the Root window as
 follows:

 message_type = _NET_WM_STATE
 format = 32
 window = <client window>
 data.l[0] = <new state>

Much commentary has questioned whether this (the bitfield) is simpler than a
list.

It has also been questioned whether StayOnTop should be added:
>I think this should be left out. One of the best features of the new spec is
>that clients don't dictate stacking order - that decision is left up to the WM
>based on the type of window (_NET_WINDOW_TYPE plus urgency bit, etc). Also I
>don't think StaysOnTop is the same as OmniPresent... doesn't one hint specify
>stacking order and the other specify viewport/desktop location (unclear
>which)?

A possible solution would be to add an *urgent* message,either to this, or to _NET_WM_WINDOW_TYPE
which the WM *could* implement as stay-on-top.

---------------------

I hope we can use the above to agree on an acceptable spec, as really there is
not much left to agree on !

Julian





-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 2ObI/m5mxS5P8a8HCPtbCJBB+p5/sVdT

iQA/AwUBOVp0R5JAqFTwwbGuEQJ7KwCggLHizbJI+ovMWYvqCnYPDmDxOKsAoL5e
e/yvA8nhU0p0R8eIV+lnEFAE
=KTw2
-----END PGP SIGNATURE-----