Re: Collating proposed changes to 1.9e

[Julian Adams <julian adams gmx net>]

After all that collation here are my views on which we should adopt:


> #1 Workspace addition / removal:
> --------------------------

I prefer approach 2. It's simpler, but less flexible. It would suffice
for basic desktop management, which is what IMHO we are after. It could
get annoying if the user wants to add / remove desktops in the middle of
the list a lot, but I don't think this is an overriding concern. (I'm
prepared to be proved wrong). 

If a particular window manager (but not the others) really wanted more
functionality I could implement it for a specific pager *but basic
desktop management* could be common to all.

> > *****************************************************************
> > 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 -
> ---------------------------------------------------------------
Makes sense.

> 
> #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.
> 
Does it catch all cases ? If you implementers are happy with this then
it's fine by me. _NET_SUPPORTING_WM_CHECK can be used to see if the spec
is supported at all.

> #4 _NET_WM_WINDOW_TYPE
> --------------------------
The original (1.9e that is) spec reads:
<quote>
This MUST be set by the Client before mapping, to a list of atoms
indicating the functional type of the window. 
... <snip> ...
The Client SHOULD specify
window types in order of preference (the first being most preferable),
but MUST include at least one of the basic window type atoms from the
list
below. This is to allow for extension of the list of types, whilst
providing default behaviour for window managers that do not recognise
the
extensions. 
</quote>

I read from this:
1) a window can only have one type
2) a window specifies a list of types it would like (if supported?) in
order of preference.

If this is true then we should keep the list. OTOH if the window is
guaranteed to get it's first choice, then the list could be dropped. 

Whether the list should be of atoms or values should depend on X
convention (it occurs to me that someone out there must know this -
didn't Jim Gettys already comment on this ?) If no one has a better idea
then Id' suggest leaving the meaning of the current spec, but clarifying
the wording.

> 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

For the bitfield / list argument I'd be inclined not to change the spec,
unless the X convention was broken. Or performance was practically
compromised. Clarity over all.

> 
>  And we added a StaysOnTop (i.e. AlwaysOnTop, OmniPresent, ...)
> 
>  StaysOnTop      = 1 << 6
> 

For the StaysOnTop issue - isn't the Urgency notes in the spec enough:
<quote>
Dialog boxes should indicate their urgency level (information or
warning) using the urgency bit in the WM_HINTS.flags property, as
defined in
the ICCCM. 
</quote>
If not then lets add a _NET_WM_STATE_URGENT. (I'm not proposing to add
this unless there is a reason.)

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

If we change to a bitfield this would be fine.

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

Again I don't hack X every day, but I can read a spec. All of the
solutions given previously would work (as far as I can tell) to fix
holes in the spec. For the technical trade-offs of the above I can't be
sure. But from experience of telecoms and protocols and conventions I
know that coherence, adherence to convention (when not blatantly stupid)
and clarity are of the utmost importance when trying to tie down a spec
which people can implement and then have interoperate (which here is the
whole point).

I'd be willing to put this stuff into the sgml over the next week if you
guys come back to me with a clear signal that you'll be (more) able to
live with it, or amendments which you can live with :) 

Julian