Re: My comments on 1.9b

[Matthias Ettrich <ettrich troll no>]

On Tue, 26 Oct 1999, Owen Taylor wrote:
> 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.
> 
> Regards,
>                                         Owen
> 
> 
>  * 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.

:-)

> 
>  * 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.
> 
> 1.
> 
>   * _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? What is "STACKING" order for windows on different desktops?
> 
>  * _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. There are a lot of unresolved questions about
>     what happens to client windows on a deleted desktop or area.
> 
>     This strikes me as being more WM configuration then something
>     a client should care about.
> 
>  * _NET_ACTIVE_WINDOW:
>  
>     What is an "active" window? How does this differ from
>     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's what I would say, yes. The "active" window is the window that has focus.
Making it active implies giving the focus to it. If that's impossible since the
window is on another desktop, it implies switching to the desktop. If the
window is iconified, it implies de-iconifying it.

It's basically the action that happens when you click on a taskbar entry. It
indicates that the user wants to work with this window. The WM should make this
possible.


> 
>  2.
> 
>  * _NET_WM_MOVERESIZE:
> 
>     What is the rational for needing this?
>     How does the "MOVE" part of this work?
>     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)

The rationale got lost between Draft1 and Draft1.9b. The idea is to make it
possible for toolkits to provide a sizegrip a la MacOS (or MS-Windows). A
sizegrip usually is a small triangular thing in the bottom right corner of a
status bar that can be used to resize a window. It's very practical, since
window borders are often too narrow and therefore hard to click on.

The problem with a pure toolkit implementation was that the sizegrip worked
differently than the rest (no outline mode even if the user wanted it).

So I proposed some kind of property to tell the window manager that this is a
sizegrip.  Raster extended the idea ( as usual ;-) to be able to provide
different sizegrips (for different directions) and even a move grip. 

I agreed since it is easy implementable and may be useful someday.

Marko replaced the size-grip property mechanism with a client message that is
sent to the window manager in the draft 1.9b. I must admit I like the idea.
It's very easy to use once the toolkit found out that the protocol is indeed
supported and it's even easier to implement on the WM side.


> 
> 3.
>  
>  * _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.

agree.

> 
>  
>  * _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 agree. Complex widgets should be able to deal with this (by using
timer-based iterative updates of their interal data structures). After all the
goal is to provide complete opaque resize.

> 
>  
> 6. File Manager desktop
>    
>   IMO, this should be left out of the initial spec since there is
>   not a consensus on this issue. (?)

As I see it, having a layer DESKTOP is sufficient for both Gnome and KDE's
needs regarding the WM protocol.  There's no need for more at this point.



Matthias