No Subject

[Marko Macek <Marko Macek gmx net>]

>Since everybody else is getting into the act, I thought 
>I should type up my notes I made while reading the 
>spec a while ago. 


> * We should replace the MWM hints completely. They were 
>   never formally specified. Window managers would presumably 
>   honor the MWM hints in the case where the new hints 
>   were not set. 

Maybe. What functionality from MWM spec do we need? Modal windows, window
decorations, maybe window functions. How about MWM_MENU, ...?

> * Several places comments in the spec worry about bit fields 
>   not being extensible without changing the spec. I don't see this 
>   as a problem - window managers should not add to these 
>   fields in a non-standard fashion. 

Since this spec is shared at least between GNOME and KDE, I strongly feel
it should be easily extensible in a compatible way.



>  * _NET_CLIENT_LIST _NET_CLIENT_LIST_STACKING: 
>    What is the interpretation of these properties with respect 
>    to windows on multiple desktops? Are windows on all desktops 
>    listed? 

Yes, all windows are listed.

>What is "STACKING" order for windows on different desktops? 

Probably unspecified. 

> * _NET_NUMBER_OF_DESKTOPS _NET_DESKTOP_GEOMETRY: 


>    The ability for a client to change the number of desktops 
>    insert/delete desktops or change desktop geometry seems like a 
>    bad idea. 

It would be nice to have at least the ability to add/remove desktops (at
least empty ones).

> There are a lot of unresolved questions about 
>    what happens to client windows on a deleted desktop or area. 

They should stay visible on the new current desktop/area.

>    This strikes me as being more WM configuration then something 
>    a client should care about. 

Clients should not normally care about this.


> * _NET_ACTIVE_WINDOW: 
>  
>    What is an "active" window? How does this differ from 

Active=focused.

>    focused window? What does "activating" a window on a 
>    different desktop mean since you can't give it the 
>    input focus? Should WM implementations switch desktops? 

That or bring the window on the current desktop. Perhaps there should be a
WM option (and the hint in the message) for this.

> * _NET_WM_MOVERESIZE: 
>
>
>    What is the rational for needing this? 

Applications without borders/titlebars (undocked toolbars, ...) should not
move/resize themselves. Instead they should tell the WM what the user wants
and the WM should start an appropriate action.

>    How does the "MOVE" part of this work? 

What do you mean?

>    There probably should be the ability to not specify 
>    a resize direction. (Many window managers have some 
>    way of starting a resize other than dragging on the 
>    border) 

OK.

> * _NET_WM_LAYER: DESKTOP. 
>
>
>    Unless the spec is going to _mandate_ the use of a huge 
>    file manager bg window (pissing some WM authors off), 
>    the use of this layer for shaped desktop icons should be 
>    mentioned as well. 

Personally I find that desktop icon support in both KDE and GNOME
currently sucks (KDE marginally better). To make the desktop usable we really need
to have a standard file manager icon view with exactly the same behavior
everywhere. Everything will just lead to code duplication and will suck. You
can't have multiple multiple file managers doing desktop icons anyway unless
you put much more support in the WM (arranging icons, ...)

I agree, if the file manager uses lots of little windows, they should have
this hint set (if we keep the layers).
  
> * _NET_WM_SIZEMOVE_NOTIFY: 
>
>
>    There are some alternative ways, such as queueing to get 
>    the performance increase without causing the complexity 
>    overhead. Is this really needed? 

I don't know... IMHO the apps should just be very very fast :)
Matthias?

Mark

-- 
Sent through Global Message Exchange - http://www.gmx.net