Subject: Gnome compliance

From: Jason L Tibbitts III <[email-masked]>
Date: 02 Dec 1998 22:16:46 -0600

Well, the document describing the hints that a window manager needs to
support to be Gnome compliant is out.  It's badly written in the usual
Rasterman style.  The support actually seems relatively simple; most of it
is geared towards supporting a pager and a taskbar.

The document is at http://www.gnome.org/devel/gnomewm/.  Obviously this
isn't appropriate now, but it would be nice to have it in the relatively
near future.  If nothing else, someone who knows what they are talking
about (i.e. not me) should look at the document to see if there are things
in there that are unworkable.

 - J<

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 02 Dec 1998 23:29:17 EST

> in there that are unworkable.

I've read the document and I had several concerns which I sent both to
raster and the gnome internal development list. I tried to be
unbiased, but maybe someone wants to read the document with more of an
fvwm slant. I am also willing to be the contact person for fvwm2 on
issues related to this if people don't feel this is an unacceptable
conflict of interest or whatever, and will gladly forward on any
fvwm-specific concerns and advocate them as strongly as the ones I've
already reported. To avoid duplication of reporting problems and
asking for clarification, here is the message I sent to raster.

 - Maciej Stachowiak

---------------------------

Hi,

I just read the latest Gnome window manager compliace spec, and mostly
I like it very much. I have a few questions/suggested changes, however.

* Chapter 1 Section 1 calls for setting the value of
_WIN_SUPPORTING_WM_CHECK to be set to the ID of a special window
created for this purpose. Is there a reason for doing this, instead of
just having the window manager set this property to nothing when it
starts up, and delete it when it exits? I can't see anywhere else in
the spec where that window is used.

* Chapter 2 Section 2 says a client should request state changes by
sending a client_message to its own window giving the new state
settings. Wouldn't it be simpler to have the client set the same
property on its own window that it set for the initial state setting
request? I believe that window managers must listen for PropertyNotify
on all managed clients anyway to comply with other standard window
manager protocols. Race conditions between the window manager and
client can be avoided by doing one of the following:

** always doing a grab, read, update, ungrab sequence

** forbidding the client to change its own state except when unmapped
(I believe some standard ICCCM or Motif protocols specify this).

** Using a different property for the last client request and the
current state, and having the format for the request property contain
the appropriate bitmask of what should be changed.

I dislike using client messages for window manager protocols because
it adds complexity, since most other protocols are handled solely with
properties.

The above two suggestions would personally make my life easier. The
following are questions on interpretation and semantics of the
document:

* what does WIN_STATE_HID_TRANSIENT mean? The comment says "/*owner of
transient is hidden*/" but I am not sure what it means - does this
indicate that the window is transient for a window that is hidden?
If so, shouldn't the window manager be able to tell that otherwise?
And if not, what is the window manager supposed to do when this bit is
set?

*The following bits may be hard for some window managers to implement
(not mine), should they just be ignored?

** WIN_STATE_MAXIMIZED_VERT 
** WIN_STATE_MAXIMIZED_HORIZ 
** WIN_STATE_SHADED

* What is the "taskbar" mentioned in the comment for WIN_STATE_HIDDEN:
is this meant to include only task bars per se, or also window
lists/windowlist menus, which are essentially vertically stacked
taskbars? Also, I have to say that I don't like this property - I
don't think a window should be able to say that it doesn't appear on a
window manager's takbar if the wm is managing it. Why wouold this be
useful?

* The following bits in _WIN_HINTS are described as settable only by
the app, but many window managers allow the user to set these
preferences in other ways. Should the window manager refuse to do such
operations for windows with this hint, or should they do them anyway
but not update the hint?

#define WIN_HINTS_SKIP_FOCUS      (1<<0) /*"alt-tab" skips this win*/
#define WIN_HINTS_SKIP_WINLIST    (1<<1) /*do not show in window list*/
#define WIN_HINTS_SKIP_TASKBAR    (1<<2) /*do not show on taskbar*/
#define WIN_HINTS_FOCUS_ON_CLICK  (1<<4) /*app only accepts focus if clicked*/

The last in particular, the difference between click-to-focus and
mouse-focus, is something that has traditionally been decided by
window managers.

* _WIN_EXPANDED_SIZE is described as an array of 4 CARDINALs but its
semantics are not described anywhere.

* _WIN_APP_STATE and _WIN_ICONS are mentioned in Chapter 1 Section 2
but their format and semantics are not explained anywhere.

Finally, a concern that does not apply to me directly at all (since I
don't plan to implement the hints in C): what is the license status of
the example code? I think X-style or public domain is best, since some
WMs are under X-like or BSD-like licenses.

Thanks for the excellent standard and I hope to hear back about these
issues.

 - Maciej Stachowiak