Various comments, mostly on Implementation Notes

[Owen Taylor <otaylor redhat com>]

I noticed problems with a few sections of the draft spec recently,
mostly for the Implementation Notes section.

> _NET_WM_STATE
> 
> A list of hints describing the state window. ....

That should be "window state", no?

> _NET_WM_PING

[...]

> A participating Client receiving this message MUST send it back to the
> root window immediately, by setting window = root, and calling
> XSendEvent.

While my opposition to this protocol in general is on record, more
specifically, I think there is a problem with "MUST ... immediately".
Am I incompliant with the spec if I don't get scheduled by the kernel?
I'd suggest changing "immediately" to "as soon as possible" or
"at its soonest possible convenience."

Implementation notes section:

> File Manager desktop
>
> This spec suggests implementing the file manager desktop by mapping a
> desktop-sized window (no shape) to all desktops, with
> _NET_WM_WINDOW_TYPE_DESKTOP. This makes the desktop focusable and
> greatly simplifies implementation of the file manager. It is also
> faster than managing lots of small shaped windows. The file manager
> draws the background on this window. There should be a root property
> with a window handle for use in applications that want to draw the
> background (xearth).
> 
> Several GNOME file manager developers have accepted this model 

The last line can be deleted. It doesn't belong in a standard.

(It wasn't very accurate before, but since Nautilus is using the
big-window model, I guess it is now accepted. There is a problem in
that we need a way of marking a window unmoveable, currently, e.g.,
alt-drag in Sawfish has the nice property of moving these windows...)

> Implementing enhanced support for application transient windows
> 
> If the WM_TRANSIENT_FOR property is set to None or Root window, the
> window should be treated as a transient for all other windows in the
> same group. It has been noted that this is a slight ICCCM violation,
> but as this behaviour is pretty standard for many toolkits and window
> managers, and is extremely unlikely to break anything, it seems
> reasonable to document it as standard.

This is wrong. The "traditional" behavior was to decorate the window
as if it was transient for another window, but not impose stacking
order or other relationships commonly associated with the transient-for
relation. Making it transient for the entire group breaks legacy
apps. 

[...]

> Window Movement
> 
> According to the ICCCM, applications should not see unnecessary
> differences between running with or without a window
> manager. Therefore window movements for already mapped windows, such
> as ones requested by XMoveWindow(Display, Window, X, Y) have to move
> the window Window to the coordinates (X, Y) and not cause the window's
> window manager frame window to end up at (X, Y).

This is just in complete disagreement with the ICCCM, which says:

| Clients can resize and reposition their top-level windows by using the 
| ConfigureWindow request. The attributes of the window that can be altered 
| with this request are as follows:
| 
|  - The [x,y] location of the window's upper left-outer corner
|  - The [width,height] of the inner region of the window (excluding borders)

[...]
 
| Client configure requests are interpreted by the window manager in the
| same manner as the initial window geometry mapped from the Withdrawn
| state, as described in section 4.1.2.3.

and section 4.1.2.3 is pretty explicit in saying that X,Y should only
be the upper left hand corner of the window when win_gravity is
static.

Having this behavior be predictable is quite important... I don't want
to have to try and guess in GTK+ whether I have a "ICCCM complaint WM"
or a "Net WM Spec compliant window manager.

(The current Java JDK tries to make this guess and falls flat, flat on
its face.)

Regards,
                                        Owen