spec needs some corrections/clarifications

From: Dominik Vogt <dominik vogt fvwm org>
To: wm-spec <wm-spec-list gnome org>
Subject: spec needs some corrections/clarifications
Date: Sun, 7 Jan 2001 13:02:18 +0100
Reading the released spec for the first time in a very long time,
I noticed that a number of paragraphs are phrased confusingly,
lack some important information or are unnecessarily strict.
Changing these is mostly cosmetic but will reduce the possibility
of misinterpretation by the reader.  However, there are a few
severe inconsistencies in the spec, namely in (all of this is
explained in detail further down in this mail).

_NET_CLOSE_WINDOW

  Much too strict, easy to fix.

_NET_WM_NAME, _NET_WM_VISIBLE_NAME, _NET_WM_ICON_NAME, _NET_WM_VISIBLE_ICON_NAME

  Enforce UTF8 implementation, easy to fix.

_NET_WM_WINDOW_TYPE

  Rules out almost all applications from being compliant, e.g.
  xterm.  Hint is too strict, easy to fix.

_NET_WM_DESKTOP

  Really asks for a race condition.  Can easily be prevented by
  defining when the WM has control over the property and when the
  client has control.

I think only the UTF8 problem may require a change in existing
applications and none of these should affect existing window
manager implementations.

My comments are marked with ">>"

--

Shading

Some Desktop Environments offer shading (also known as rollup) as
an alternative to iconfication. A shaded window typically shows
only the titlebar, the client window is hidden, thus shading is
not useful for windows which are not decorated with a titlebar.

>> This is the personal opinion of the person who wrote this.  Of
>> course shading windows without a title is useful.  Without the
>> title bar you will just see the rolled up border and will not
>> be able to access the title buttons or read the title.
>> Nonetheless it is a nice way to get the window out of the way.
>> For example it can be used to 'hide' a button bar, leaving only
>> the border visible.

--

_NET_SUPPORTED

 _NET_SUPPORTED, ATOM[]/32

...

>> Why doesn't this tell *which* features are defined?

--

_NET_NUMBER_OF_DESKTOPS

...

If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is
out of the new range of of
                     ^^^^^
>> one 'off' is enough

available desktops, then this MUST must be set to the last
                              ^^^^^^^^^
>> same for 'must'

--

_NET_DESKTOP_GEOMETRY

 _NET_DESKTOP_GEOMETRY width, height, CARDINAL[2]/32

Array of two cardinals that defines the common size of all desktops. This property SHOULD be set by the Window Manager. 

>> It is not clear at all if this is the geometry in *pixels* or
>> the geometry in pages (e.g. 2x2 or 2048x1536).

--

_NET_WORKAREA

 _NET_WORKAREA, x, y, width, height CARDINAL[][4]/32
         
This property MUST be set by WM upon calculating the work area for
each desktop. Contains a geometry for each desktop. These
geometries are specified relative to the viewport on each desktop
and specify an area that is completely contained within the
viewport. Work area SHOULD be used by desktop applications to
place desktop icons appropriately. 

The window manager SHOULD calculate this space by taking the
current page minus space occupied by dock and panel windows, as
indicated by the _NET_WM_STRUT property set on client windows. 

>> It is not clear if this has to be set only for the current
>> viewport or for *all* viewports on all desktops.  In the latter
>> case, some WMs may have to configure 4294967295 desktop
>> geometries :-)

--

_NET_CLOSE_WINDOW

 _NET_CLOSE_WINDOW

Pagers wanting to close a window MUST send a _NET_CLOSE_WINDOW
client message request to the root window: 

...
The Window Manager MUST then attempt to close the window specified. 

>> Is there any good reason why a window manager MUST adopt this
>> kind of pager to WM interaction?  I can imagine a lot of good
>> reasons why this may not be wanted.  SHOULD is enough here.
>> For example there may be windows that an admin does not want to
>> be modified by the user in any way.  Closing these is clearly
>> unwanted.  Demanding a MUST is a severe limitation of the spec
>> in many business applications.

--

_NET_WM_MOVERESIZE

...

This message allows an application to initiate window movement or
resizing. This allows the application to define its own move and
size "grips", whilst letting the window manager control the actual
move/resize. This means that all moves / resizes can happen in a
consistent manner as defined by the WM. 

When sending this message, x_root and y_root MUST indicate the
position of the mouse click with respect to the root window and
direction MUST indicate whether this is a move or resize event,
and if it is a resize event, which edges of the window the size
grip applies to. 

>> This hint lacks a MUST/SHOULD/MAY hint for the WM.  I suggest
>> SHOULD according to my reasoning above.

--

_NET_WM_NAME

 _NET_WM_NAME, UTF-8_STRING

The Client SHOULD set this to the title of the window in UTF-8
encoding. If set, the Window Manager should use this in preference
to WM_NAME. 

>> It must be clarified that this is no replacement for WM_NAME.
>> The client MUST still set a proper WM_NAME because the WM is
>> not required to honour this hint.

--

_NET_WM_VISIBLE_NAME

 _NET_WM_VISIBLE_NAME, UTF-8_STRING

If the Window Manager displays a window name other than
_NET_WM_NAME the Window Manager MUST set this to the title
displayed in UTF-8 encoding. 

>> Gee, if I choose not to implement UTF8 support in _NET_WM_NAME
>> then this MUST forces me to implement UTF8 support for the
>> _NET_WM_VISIBLE_NAME hint.  This MUST has to be changed to a
>> SHOULD.  It's rather silly to demand that all compliant window
>> managers support UTF8 titles.  A taskbar can still fall back to
>> using the provided _NET_WM_NAME or WM_NAME.  Otherwise this
>> will rule out a number of window managers without UTF8 support
>> for no good reason.  The same holds true for the corresponding
>> icon titles.

--

_NET_WM_DESKTOP

 _NET_WM_DESKTOP <desktop>, CARDINAL/32



Cardinal to determine the desktop the window is in (or wants to
be) starting with 0 for the first desktop. A Client MAY choose not
to set this property, in which case the Window Manager SHOULD
place as it wishes. 0xFFFFFFFF indicates that the window SHOULD
appear on all desktops/workspaces.

The Window Manager should honor _NET_WM_DESKTOP whenever a
withdrawn window requests to be mapped. 

A Client can request a change of desktop for a non-withdrawn
window by sending a _NET_WM_DESKTOP client message to the root
window: 

 _NET_WM_DESKTOP
   window  = the respective client window
   message_type = _NET_WM_DESKTOP
   format = 32
   data.l[0] = new_desktop



The Window Manager MUST keep this property updated on all windows.

>> Since the client is allowed to change this at any time, the WM
>> can not make this sure, regardless of if you say MUST, SHOULD
>> or MAY.  The client MUST NOT modify this property only if it
>> is in a different state than withdrawn state.  Furthermore this
>> sentence makes not much sense:

A Client MAY choose not to set this property, in which case the
Window Manager SHOULD place as it wishes.

>> Of course the window manager will place it where it wishes if
>> the client does not specify the hint.  SHOULD --> will.

Here is a corrected version of the hint (changes set off in
asterisks):

------------ snip -----------
_NET_WM_DESKTOP

 _NET_WM_DESKTOP <desktop>, CARDINAL/32



Cardinal to determine the desktop the window is in (or wants to
be *created in*) starting with 0 for the first desktop. A Client
MAY choose not to set this property, in which case the Window
Manager *will* place as it wishes. 0xFFFFFFFF indicates that the
window SHOULD appear on all desktops/workspaces.

The Window Manager *SHOULD* honor _NET_WM_DESKTOP whenever a
withdrawn window requests to be mapped.  *The client MUST NOT
change this property if it is not in withdrawn state to avoid
race conditions with the window manager.  The window manager MUST
NOT change this property while the window is in withdrawn state. *

A Client can request a change of desktop for a non-withdrawn
window by sending a _NET_WM_DESKTOP client message to the root
window:

 _NET_WM_DESKTOP
   window  = the respective client window
   message_type = _NET_WM_DESKTOP
   format = 32
   data.l[0] = new_desktop
------------ snip -----------

--

_NET_WM_WINDOW_TYPE

 _NET_WM_WINDOW_TYPE, ATOM[]/32



This MUST be set by the Client before mapping, to a list of atoms
indicating the functional type of the window.

>> Eeek!  This MUST makes 90% of all applications uncompliant to
>> the spec!  And it's completely unnecessary too.  Change this
>> to SHOULD.  Clearly, a missing hint indicates that the client
>> does not care about how the window manager treats it.  The
>> window manager will pick an appropriate window style itself.

This property SHOULD be used by the window manager in determining
the decoration, stacking position and other behaviour of the
window.

>> This sentence is a bit misleading.  I'd rephrase it like this:

This property SHOULD be used by the window manager.  It MAY
determine the decoration, stacking position and other behaviour of
the window.


The Client SHOULD specify window types in order of preference (the
first being most preferable), but MUST include at least one of the
basic window type atoms from the list below.

>> Remove this MUST too.

This is to allow for extension of the list of types, whilst
providing default behaviour for window managers that do not
recognise the extensions. 

--

_NET_WM_STATE

 _NET_WM_STATE, ATOM[]



A list of hints describing the window state. Atoms present in the
list MUST be considered set, atoms not present in the list MUST be
considered not set. The Window Manager SHOULD honor _NET_WM_STATE
whenever a withdrawn window requests to be mapped. A Client
wishing to change the state of a window MUST send a _NET_WM_STATE
client message to the root window (see below).

>> Add this sentence here: "The window manager MAY change state
>> according to this message."  I chose MAY because there are
>> many good reasons not to honour one or the other particular
>> hint, e.g. MODAL or SHADED for wms that do not support these
>> hints.

The Window Manager MUST keep this property updated to reflect the
current state of the window. 

--

_NET_WM_STRUT

 _NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32



This property MUST be set by the Client if the window is to
reserve space at the edge of the screen. The property contains a 4
cardinals specifying the width of the reserved area at each border
of the screen. The order of the borders is left, right, top,
bottom. The client MAY change this property anytime, therefore the
Window Manager MUST watch out for property notify events. 

>> This hint lacks a MUST/SHOULD/MAY for the window manager. I
>> suggest:

The window manager MAY use this property to determine the
behaviour of window movement, maximization, resizing, mapping new
windows and other behaviour.  If the window manager chooses to
honor this property it MUST watch out for property notify events.

--

_NET_WM_ICON_GEOMETRY

 _NET_WM_ICON_GEOMETRY, x, y, width, height, CARDINAL[4]/32



This optional property MAY be set by standalone tools like a
taskbar or an iconbox. It specifies the geometry of a possible
icon in case the window is iconified. 

>> Missing MUST/SHOULD/MAY. Suggestion:

The window manager MAY use this hint to display a nice animation
like morphing the window into its icon or other purposes.

>> Delete the Rationale.

--

_NET_WM_ICON

 _NET_WM_ICON CARDINAL[][2+n]/32



This is an array of possible icons for the client. This
specification does not stipulate what size these icons should be,
but individual desktop environments or toolkits may do so. The
Window Manager MAY scale any of these icons to an appropriate
size. 

>> What is the *contents* of these CARDINALS?  I *guess* these
>> are pixmap ids, but it's not clear.  Please clarify the spec.
>> Furthermore, why is the list length 2+n?  Last but not least,
>> there is no MUST/SHOULD/MAY again.  I suggest MAY.

This is an array of 32bit packed CARDINAL ARGB with high byte
being A, low byte being B. First two bytes are width, height.
Data is in rows, left to right and top to bottom. 

>> Ah, now I understand.  Is this the raw image coded in ARGB
>> format?  In this case there MUST be a link to a description of
>> this particular format.

--

_NET_WM_PID

 _NET_WM_PID CARDINAL/32



If set, this property MUST contain the process ID of the client
owning this window. This MAY be used by the Window Manager to
kill windows which do not respond to the _NET_WM_PING protocol. 

>> Does this imply that the WM MUST NOT use the pid for other
>> purposes?  If yes, say so.  If not, say so.

--

That's all, folks.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de
[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]