questions/suggestions about changes in 1.0pre2

[Sasha_Vasko osca state mo us]

> I've been looking over the new "1.0pre2" spec that is on 
freedesktop.org,
> and I thought I should ask about some of the changes that have been made
> (I didn't see some of them discussed on this list)
>
> _NET_NUMBER_OF_DESKTOPS:  when I implemented the spec, a client could
> change this by sending a client message to the root window with
> message_type = _NET_NUMBER_OF_DESKTOPS, but now the spec says
> _NET_SET_NUMBER_OF_DESKTOPS.  This is the only root window message that
> uses a different message_type from the property itself.  I think this
> should be changed back to the original.

I agree - there is no need to create one more atom.

>
> _NET_DESKTOP_GEOMERTY:  <pedantic> The type should probably be
> CARDINAL[][2]/32 (same as _NET_DESKTOP_VIEWPORT) instead of just saying
> CARDINAL[2]/32... extra clarity</pedantic>

No that is incorrect. Every desktop is assumed to have the same size.
_NET_DESKTOP_VIEWPORT is not the size of viewport, but POSITION of the
viewport on any particular desk. This position can be changed all the time
and it can be different on each desk. Althou I personally think that only 
viewport of the current desk matters. 

>
> _NET_WM_VISIBLE_NAME_STRING:  The _STRING should be dropped off the end,
> to keep consistent naming (WM_NAME, _NET_WM_NAME,
> _NET_WM_VISIBLE_NAME).  My implementation uses _NET_WM_VISIBLE_NAME.

I agree here

>
> _NET_WM_WINDOW_TYPE:  I think the _NET_WM_WINDOW_TYPE_TOOLBAR type 
should
> be simply _NET_WM_WINDOW_TYPE_TOOL.  Floating toolbars should still use
> this type, but it causes less confusion for windows that aren't 
toolbars,
> but which should be drawn with less decorations (a small color grid for 
a
> painting program probably shouldn't have full decorations/menus
> etc... just a small titlebar and a close button probably)

does not really matter as I see it - any way is fine with me

>
> _NET_WM_STATE: I think this should be a bitfield.  We are assuming that
> all state value are boolean flags (since we have set/unset/toggle
> commands).  As extensions are made and things added, this will become
> quite a large property for storing nothing but boolean flags.  I suggest
> this:

as was disscussed before, and it will become immediately usefull - 
atom list is preferable here, since extensions are likely to be added
( including StaysOnTop etc. ) so the atoms are needed in order to avoid 
clashes between different extensions. 
The size of this property is unlikely to become big, since each particular 

window will only use fraction of available states, at the same time number
of extensions can be unlimited. 
With your proposal there will have to be a body in place to coordinate all 

the different extensions, besides it is limiting extensions number to 
32-4=28, 
which is fairily large number, but taking on account number of existing 
window managers, even if each will implement only 1 extension - you'll use
it all up in no time.
Also since complete set of atoms can be retrieved from the server via 
1, at most 2, requests, it does not really matter even if it'll grow even 
to
a number of 32 (which is a max number of properties in bitfield.
Even if you have like 100 clients running on server ( which I doubt 
anybody 
will ever have) it will keep you under 3K of server memory. At the same 
time 
this property will be only seldom updated, thus not generating any 
sugnificant
network traffic.

>
>       _NET_WM_STATE, CARDINAL/32
>        Modal        = 1<<0
>       MaxVert      = 1<<1
>       MaxHoriz     = 1<<2
>       Shaded       = 1<<3
>
> Note that the state information has been trimmed down to include only
> useful state information (common UI elements).  These are simply hints
>
> The argument made against StaysOnTop also holds true for Sticky and
> SkipTaskbar.  These hints/states dictate policy, which should be done
> "through the window manager configuration".  If a particular
> implementation wants to use Sticky, SkipTaskbar or StaysOnTop, it should
> be done outside the _NET namespace (as I have been told *many* times).

I agree on that, and I've said that before. Reason why I was not as 
radical 
here is becouse those two are much better defined then StaysOnTop. But 
yes,
those are better to be left for window manager to decide.

>
> This is the part where people get pissed off.  Some feel that Sticky and
> SkipTaskbar are essential hints for working with the desktop.  If enough
> people Sticky and SkipTaskbar, then I feel that StaysOnTop should also 
be
> included.  Either we include nothing in the spec that describes policy
> (like Sticky, StaysOnTop and SkipTaskbar do) or we include all 
reasonable
> policy.
> 
> Give me one good reason that Sticky or SkipTaskbar should be included but
> StaysOnTop should not.  One dictates fixed position in the x/y
> coordinates, the other fixed position in the z coordinate.

Not that I'm for inclusion of those states, but just a little explanation:
Sticky - means that window should follow viewport and desk changes ( 
appears 
on all desks/viewports in exactly same position ), so no, x/y coordinates
are always changing in virtual space/but remain fixed in physical space.
SkipTaskbar is not even window manager related, since its taskbar who 
should be checking it.

Again, if _NET_WM_STATE is an atom list - then all thmentioned properties 
could be 
excluded from the specs, but implemented as an extensions in any 
particular
environment, thus satisfying everybody.

> 
>  --
> Bradley T. Hughes <bhughes trolltech com>

Cheers
Sasha Vasko