Re: Update

[Matthias Clasen <clasen pong mathematik uni-freiburg de>]

> Perhaps people could explain what is the problem with implementing the
> current spec.
> 
> Mark

Mark, this is not directly related to implementation, but here is what
I wrote to raster when I first read the current wm spec in December :

Matthias 
 
-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: clasen@mathematik.uni-freiburg.de
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg



Raster, I have read through your Gnome wm documents and
after a recent reread of the ICCCM (R5 version, have there
actually be any changes in R6 ? Some are recommended in the R5
version.), I have taken the time to write up some remarks/questions
of mine. Care to comment ?

Matthias

PS Sorry for the length of this mail, I hope it is worth reading.


Notes on 1.1
------------

why is _WIN_SUPPORTING_WM_CHECK of type CARDINAL ???
  should better be of type WINDOW, since it is a window IDs.

  what is the rationale for the more complicated setup using
  a dedicated window rather than a simple GNOME_WM_RUNNING
  property on the root window ? Safe-guarding against leftover
  properties after a wm crash, I suppose ?

Notes on 1.2
------------

why _WIN_PROTOCOLS ???
  The layer, state, hints, app-state, expanded-size, icons (?)
  stuff are no really protocols of any kind, their presence
  simply tells clients that the wm will try to make use of their
  corresponding hints. Who cares, they are just hints and the
  client can set them up regardless of *any* wm running.

  For the workspace stuff and winlist stuff, pagers and the like
  can actually benefit from their absence (by refusing to run :-),
  but they can just as well check for the corresponding root
  properties directly. And wouldn't it be really sufficient to
  have just one property for the workspace stuff? What would it
  mean to support workspace-count, but no workspace ?

Notes on 1.3
------------

why is _WIN_CLIENT_LIST of type CARDINAL ???
  should better be of type WINDOW (like eg WM_COLORMAP_WINDOWS)
  since it is a list of window IDs.

perhaps should clarify that "Client window" here and elsewhere
means nontransient nonoverride-redirect toplevel window. Or should
they also apply to transient ones ? WIN_STATE_HID_TRANSIENT seems to
imply this, but most of the flags are useless for
transient windows.

Should perhaps clarify that the content of _WIN_WORKSPACE_NAMES
is a list of zero-terminated strings, or is it zero-separated ?

Notes on 2.1
------------

The name _WIN_HINTS is a bit misleading, since all these properties
are really hints to the wm. It is a bit dubious what properties are
read/written by whom. _WIN_HINTS seem to be written be the client/read
by the wm, but _WIN_LAYER, _WIN_WORKSPACE seem to be read/written by both.
This is ugly and I imagine it could also lead to race conditions and
other properties. Example concerning _WIN_WORKSPACE:

* client writes new value
* pager sees this first, thinks it reflects the state of the client
  and updates its display.
* wm sees it next, but for some reason decides not to fulfil
  the clients request (ICCCM: clients should cooperate with the wm
  by accepting the resources they are allocated even if they are not
  those requested) and changes it back to its old value.
* pager sees this and updates its display again.

result: unnecessary work, flickering.

I would prefer to see them grouped in two properties:
* a hint property which is set by the client and watched by the wm
* a state property which is written by the wm to reflect the clients state
  and is read by whoever needs the information (pager, sm, winlist,
  client,...)
[
  Later comment: I have now discovered that you do use a secure scheme for
  writing the properties:

  * client writes properties when unmapped, otherwise sends ClientMessage
  * wm writes properties when mapped
  * the exception is _WIN_HINTS which is always written by the client and
    never by the wm (making the name HINTS appropriate after all).
]

On to individual entries:

_WIN_STATE flags:

  WIN_STATE_HIDDEN:
   What is the "taskbar" here ? Is it a kind of icon area ? If so,
   the hint is pointless, since the wm will hide the icon when the window
   is mapped anyway. If it is a kind of winlist created by another client,
   this hint is not to the wm at all and should not be mixed with wm hints.

  WIN_STATE_HID_WORKSPACE:
   Isn't this redundant, given that the client can as well just
    set client._WIN_WORKSPACE != root._WIN_WORKSPACE ?

  WIN_STATE_HID_TRANSIENT: please explain!

  WIN_STATE_FIXED, WIN_STATE_ARRANGE_IGNORE:
   Are these really a good idea? After all, arrangement and positioning
   of windows are the foremost job of the wm, why should the client mess
   with this ? Or are these just hacks to make the panel and wm live
   together ?

_WIN_HINTS flags:

 WIN_HINTS_SKIP_WINLIST, WIN_HINTS_SKIP_TASKBAR:
  See my comment about WIN_STATE_HID_TASKBAR, this are not wm hints
  at all, they are directed at the client responsible for creating
  winlists or taskbars (which *may* be the wm). Do "window list" and
  "taskbar" have sufficently clear meanings to gain separate flags
  here ? I'd say a taskbar is just a special kind of winlist...

 WIN_HINTS_SKIP_FOCUS:
  First I thought that this would interfere with the input focus model
  setting achieved through WM_HINTS.input and WM_TAKE_FOCUS, but
  now I think that there is a different concept behind this waiting
  to be explained:

    WM_HINTS.input and WM_TAKE_FOCUS determine how the wm should behave
    if it is asked to transfer focus to a user-determined (by mouse-motion
    or click) client. Wms may also offer a way to transfer the focus to
    some other, not explicitely specified client (this is typically bound
    to Alt-TAB). Wm's will maintain a list of clients accepting focus
    and use it to determine the next client to receive the focus.
    WIN_HINTS_SKIP_FOCUS is a way to exclude clients otherwise accepting
    focus from this list. They can still reseive focus, but only through
   explicit user action.

 WIN_HINTS_FOCUS_ON_CLICK:
  Isn't this part of wm policy where the client has no say in ? And it
  is a bit arbitrary to represent focus-on-click and not also
  sloppy-focus, number-of-buttons, has-handles and whatever per-window
  configuration a wm may have.

_WIN_WORKSPACE, _WIN_LAYER:
  See my previous comments on read-write properties. how is the layer supposed
  to interact with transient windows which would normally appear
  on top ? What happens if I raise an app that started
  in LAYER_NORMAL, is it just raised above all LAYER_NORMAL
  windows or is the app promoted to some higher layer ?


_WIN_APP_STATE:
  is not detailed in the document, but is this the crap with about 100
  semi-meaningless arbitrary states defined as atoms which can be used to make
  the wm chose a somewhat different decoration (especially if the app is
  iconized) ?

  IMHO this should be dropped completely. If an application wants to indicate
  progress while being iconized, the ICCCM provides a perfect means for it:
  icon windows. They give you all that _WIN_APP_STATE could and more.

  All that would be needed would be perhaps a little widget to ease the
  combination of a pixmap and a mini-progressbar into a nice icon window. That
  widget could also provide visual indication for all the values that have
  been proposed for _WIN_APP_STATE by superimposing some indicator over the
  normal app icon.


Notes on 2.2
------------

I do not understand how a client can change its own desktop. You give

   xev.type = ClientMessage;
   xev.window = client_window;
   xev.message_type = XInternAtom(disp, XA_WIN_WORKSPACE, False);
   xev.format = 32;
   xev.data.l[0] = new_desktop_number;
   XSendEvent(disp, root, False, SubstructureNotifyMask, (XEvent *) );

as an example for changing the currently active desktop,
ie root._WIN_WORKSPACE. From the other examples and the description I would
assume that the code changes the desktop the client lives on, ie
client._WIN_WORKSPACE. Perhaps you intended to write:

   xev.window = root;

in the above example ?



A general comment on the code examples: You sometimes miss the
variable name after a cast, eg:

XSendEvent(disp, root, False, SubstructureNotifyMask, (XEvent *) );

should probably read:

XSendEvent(disp, root, False, SubstructureNotifyMask, (XEvent *) &xev);