Re: Collating proposed changes to 1.9e

[Sasha_Vasko osca state mo us]

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

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

I vote for approach 2


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

I vote for that

>#3 _NET_PROPERTIES Can be dropped -

I vote for that

>#4 _NET_WM_WINDOW_TYPE
>--------------------------
>Could be changed from a list of atoms to an enumerated value for
*simplicity*:
>
>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.

I agree with objection.
List, or ORed combination of bits is much better.


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

I vote for that

> And we added a StaysOnTop (i.e. AlwaysOnTop, OmniPresent, ...)
>
> StaysOnTop      = 1 << 6
>
>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)?

I vote against StaysOnTop

>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 vote in favor of urgency hint.

>Julian

Thanks for summing it all up :)