Re: My comments on the WM spec (fwd)

[Julian Adams <julian adams gmx net>]

-----BEGIN PGP SIGNED MESSAGE-----

Hi Bradley - I've put up a new version of the spec on freedesktop.org  - or at
least I've sent it to Havoc - it will be version 1.0 pre 3 when it appears.

I note your implementation differs from the current proposal (see below). would
you be able to update the spec. Do you think this would be ok ?

On Mon, 02 Oct 2000, Bradley T. Hughes wrote:
>On 1 Oct 2000 otaylor fresnel labs redhat com wrote:
>
>> I've been having a few problems with my mail recently, and going
>> through the log files, it looks like I managed to lose a message
>> from you:
>>
>>  From bhughes trolltech com  Sat Sep 30 13:29:38 2000
>>    Subject: Re: My comments on the WM spec
>>
>> (I don't see this in the wm-spec archives, so it looks like it
>> was a private mail to me.)
>
>Hmm... seems it was... I thought I had sent it to both you and the list
>(grumble grumble pine grumble)
>
>> Do you happen to still have a copy around?
>
>Forwarded for your viewing pleasure :)
>
>> Sorry for the inconvenience,
>>                                             Owen
>
>--
>Bradley T. Hughes <bhughes trolltech com>
>Waldemar Thranes gt. 98B N-0175 Oslo, Norway
>Office: +47 21 60 48 92
>Mobile: +47 92 01 97 81
>
>---------- Forwarded message ----------
>Date: Sat, 30 Sep 2000 19:27:12 +0200 (CEST)
>From: Bradley T. Hughes <bhughes trolltech com>
>To: Owen Taylor <otaylor redhat com>
>Subject: Re: My comments on the WM spec
>
>On 25 Sep 2000, Owen Taylor wrote:
>
>>
>> Following up on the discussion over the last few days, and
>> also because people are interested in finalizing the
>> spec, I just took a careful pass over the WM spec looking
>> for remaining issues, and actually, I found quite a few.
>>
>> I'm still working on adding support for the hints into the
>> GTK+ codebase, so I may find a few more issues over the
>> next few days, but I wanted to get these out as soon
>> as possible.
>>
>> A lot of the following is basically editorial for the spec -
>> suggesting clarification or pointing out missing information.
>> But there are a few places where I think the actual protocol
>> needs to be changed as well.
>
>I don't think changing the protocol and/or semantics of anything in the
>spec is justifiable.  KDE 2 is due out within 2-3 weeks, which gives up
>very little testing time.
>
>> Regards,
>>                                         Owen
>>
>> _NET_DESKTOP_GEOMETRY
>>
>>  Its probably worth saying that this size must be equal or
>>  greater than the actual dimensions of the screen
>>  as determined by ScreenWidth, ScreenHeight.
>>
>>  [ Current proposals to make it possible to change the size of the
>>  screen on the fly might cause this to be momemtarily violated when
>>  changing screen size ]
>>
>>  The specification of the format for _NET_DESKTOP_GEOMETRY
>>  client messages is missing.
>
>My implementation uses:
>
>	e.xclient.type = ClientMessage;
>	e.xclient.message_type = net_desktop_geometry;
>	e.xclient.window = root_window;
>	e.xclient.format = 32;
>	e.xclient.data.l[0] = desktop;
>	e.xclient.data.l[1] = new_width;
>	e.xclient.data.l[2] = new_height;

is this really per desktop ? or is the spec more correct ?

>
>>  Also, I would recommend making this section correspond to
>>  _NET_NUMBER_OF_DESKTOPS by saying that the window manager is not
>>  required to honour _NET_DESKTOP_GEOMETRY client messages.
>
>Agreed.
>
>> _NET_DESKTOP_VIEWPORT
>>
>>  Might also be useful to specify the constraints that
>>
>>   0 <= x < desktop geometry width - ScreenWidth
>>   0 <= y < desktop geometry height - ScreenHeight
>>
>>  Somewhere, the spec should to specify whether coordinates for client
>>  windows when mapping the window or in ConfigureRequest are taken with
>>  respect to the viewport origin or the desktop origin. I believe the
>>  standard is to use the desktop origin, but would have to check what
>>  various window managers do.
>>
>>  Again the client message format is missing
>
>For completeness, the format I use:
>
>	e.xclient.type = ClientMessage;
>	e.xclient.message_type = net_desktop_viewport;
>	e.xclient.window = root_window;
>	e.xclient.format = 32;
>	e.xclient.data.l[0] = desktop;
>	e.xclient.data.l[1] = new_x;
>	e.xclient.data.l[2] = new_y;

again is this really per desktop ?

>
>> _NET_DESKTOP_NAMES
>>
>>  The type and format are not specified. Is this the standard
>>  NUL-separated list of strings?
>
>I have implemented them this way.  This makes reading the property very
>straight forward
>
>> _NET_SUPPORTING_WM_CHECK
>>
>>  "set with the same value" is potentially unclear. Better to say
>>  "also set to the ID of the child window". And I think it
>>  is useful to extend the rational here: the property on the
>>  child window is used so that an active window manager can
>>  be distinguished from a stale _NET_SUPPORTING_WM_CHECK
>>  property that happens to point to another window. If the
>>  _NET_SUPPORTING_WM_CHECK window on the client window is missing
>>  or not properly set, clients should assume that no conforming
>>  window manager is present.
>>
>>  Reading over the ICCCM again, I realized that this really
>>  is the wrong way of doing things - really we should be
>>  working on top of the selection mechanism described in
>>  sections 2.8 and 4.3. The X selection mechanism is meant
>>  the way in X to control ownership of shared resources,
>>  and the ICCCM describes how starting one window manager
>>  should cause the previous window manager to cleanly give
>>  up control of the root window. Of course, I don't know if any window
>>  managers actually conform to the ICCCM in this respect.
>>
>> _NET_WORKAREA
>>
>>  Should say that the coordinates here are taken with respect
>>  to the the current viewport. (If they are.)
>
>I agree with Sasha that the coordinates are taken wrt to the screen.

that should be made explicit in the spec.
>
>> _NET_VIRTUAL_ROOTS
>>
>>  Is this a) an (unordered) list of all virtual root windows other
>>  than the real root window, or b) a list of the window that
>>  corresponds to each desktop, either real or virtual?
>>
>>  I'm a little nervous about including this since it is known
>>  that using virtual root windows introduces a number of problems
>>  for various operations (the ICCCM claims that a protocol
>>  extension would be needed to properly implement virtual root
>>  windows.)
>>
>> _NET_CLOSE_WINDOW
>>
>>  There is a formatting problem with client message format
>>  specification.
>
>Again, my implementation:
>
>    e.xclient.type = ClientMessage;
>    e.xclient.message_type = net_close_window;
>    e.xclient.window = root_window;
>    e.xclient.format = 32;
>    e.xclient.data.l[0] = window;
>    e.xclient.data.l[1] = 0l;
>    e.xclient.data.l[2] = 0l;
>    e.xclient.data.l[3] = 0l;
>    e.xclient.data.l[4] = 0l;

could you update the spec ?

>> _NET_WM_MOVERESIZE
>>
>>  A thing to be careful about here is that this operation is
>>  essentially talking about transferring a pointer grab from
>>  one window to another. It needs to be pointed out that the
>>  window manager has no guarantee of getting the release from
>>  the mouse click that started the operation, and needs to
>>  check the state field of motion events to safely know when
>>  to release the grab.
>>
>>  (With this protocol there is no way of getting around the fact
>>  that a fast press/release/press can be misinterpreted.)
>>
>>  For proper operation, I think you really should include
>>  the mouse button that started the operation, not just the
>>  x and y coordinates.
>>
>>  The name of the enumerations probably really should use
>>  North,South,East,West, instead of top,right,...to correspond with
>>  similar names used in X elsewhere.
>>
>> _NET_WM_NAME
>>
>>  The property type for this property isn't specified - I would
>>  suggest UTF8_STRING. _NET_WM_ICON_NAME is missing.
>>
>> _NET_WM_STATE
>>
>>  I don't have concrete suggestions here, but I will note that
>>  this property feels very hackish to me:
>
>That makes 2 of us :)
>
>>   - It groups together different things
>>
>>     - current state of the window (SHADED/MAXIMIZED)
>>     - the way the window should be treated
>>       (modal, skip taskbar, sticky)
>>
>>   - When mapping a window, does a missing atom mean
>>     that the state should is "unset" or "not specified" -
>>     this doesn't matter so much for, say, SHADED,
>>     but for MODAL and SKIP_TASKBAR, it is quite likely
>>     that the window manager may, e.g., determine automatically
>>     determine that a window should be MODAL by examining,
>>     for instance, its WINDOW_TYPE and/or TRANSIENT_FOR
>>     properties.
>>
>>   - The concept that exactly two properties may be changed
>>     together seems very odd to me.
>>
>>   Assuming that we want to keep mixing all these types of "state"
>>   together, the way I would do this property is to make it
>>   a bitfield, or actually, two bitfields - one for the bits
>>   that are present, and one for the the state of these
>>   bits.
>
>I have done similar things with Blackbox, and it seems to work.
>
>>   The client message would then include a bitfield, and an
>>   operation - set, clear, toggle, and unset_to_default.
>>   But I really don't understand the coherence of the different
>>   atoms currently in the property.
>>
>> _NET_WM_ICON_GEOMETRY
>>
>>  How do we resolve who sets this property? What if there
>>  are multiple task lists?
>
>The SelectionOwner for _NET_WM_ICON_GEOMETRY? ... but that doesn't solve
>the problem of multiple tasks lists (which seems a bit odd conceptually,
>but i wouldn't be surprised if someone did run 2 task lists/bars)
>
>> _NET_WM_ICON
>>
>>  It currently says that 1 byte should be each of the width and height
>>  I think this is probably a typo and it is supposed to be the
>>  first two elements. (This would correspond to the format being 32.)
>>  If it isn't a typo, it should be changed, since while 256x256
>>  is just barely big enough for icons for the forseeable future,
>>  it is limiting, and we might want to use image specifications
>>  like this elsewhere.
>>
>>  Using CARDINAL for the property type is a bit suspect, since the type
>>  of the data is really something a lot more specific than
>>  just a bunch of cardinals - its a simple image format.
>>
>>  Using a specific type also is a little more forward looking since we
>>  could later add additional formats, and only require changes
>>  to window managers, and not to clients.
>>
>> _NET_WM_HANDLED_ICONS
>>
>>  What's the format (and contents?) of this property?
>>
>> _NET_WM_PING
>>
>>  Is the window field of the event really supposed to be
>>  set to the root window? Leaving it set to the client window
>>  is
>
>is...?
>
>One of the things that I have kept uniform throughout my impementation is
>keeping the window field set to the client window for messages to a client
>and set to the root window for messages to the window manager.
>
>This allows for one implementation to handle both client and window
>manager tasks (which I have done).
>
>>  A problem through out the spec is that the event mask for sending
>>  events to the root window is not specified. But it isn't possible
>>  to receive ClientMessage events without setting a mask in
>>  XSendEvent. Probably this should be specified as
>>  SubtructureNotify|StructureRedirectMask, as it is for similar
>>  events in the ICCCM.
>>
>>  As noted before, "immediately" should be replaced by
>>  "as soon as possible".
>>
>> Implementation Notes:
>>
>> As noted before, interpreting WM_TRANSFIENT_FOR pointing to the
>> root window to mean transient for the group breaks legacy applications.
>> The statement "is extremely unlikely to break anything" is just
>> wrong; and we should not require or even recommend this
>> behavior. (To repeat the argument as to why it is wrong,
>>
>> Such hints should either be ignored or be treated to be equivalent to
>> using "_NET_WM_WINDOW_TYPE_DIALOG" without any explicit
>> TRANSIENT_FOR properties.
>>
>> The Window Movement section needs some fixing:
>>
>>  If you move a window with, for insance, NorthEastGravity to (x,y), the
>>  effect is _not_ to move the upper left corner of the frame to
>>  (x,y). Instead, if the size of the window is (width, height)
>>  _excluding the frame_, then the effect is to move the upper left
>>  corner of the frame to (x+width,y).
>>
>>  Also, the list is missing North,South,East, and West gravity.
>>
>> For "Killing Hung Processes", it needs to be noted that if a window
>> does not respond to _NET_WM_PING, it does _not_ necesarily mean that
>> the process is dead, and window managers MUST ask for confirmation
>> from the user before proceeding to kill the process.
>>
>> Throughout the document we have "UTF8" - I would suggest writing this
>> as UTF-8 instead, as this is the way that it is officially written by
>> the Unicode consortium.
>>
>> The document needs a references section for at least the Unicode
>> standard and the ICCCM.
>>
>> _______________________________________________
>> wm-spec-list mailing list
>> wm-spec-list gnome org
>> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>>
>
>--
>Bradley T. Hughes <bhughes trolltech com>
>Waldemar Thranes gt. 98B N-0175 Oslo, Norway
>Office: +47 21 60 48 92
>Mobile: +47 92 01 97 81
>
>
>
>
>
>
>
>_______________________________________________
>wm-spec-list mailing list
>wm-spec-list gnome org
>http://mail.gnome.org/mailman/listinfo/wm-spec-list
--




-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: VQoBzk5Dg64f6VCYmUdC1wZfcXHJLBus

iQA/AwUBOdo4S5JAqFTwwbGuEQJttACfQT+5hzIMmpLaSaL7l2P5zFKiK0EAoKqB
POe8koj3UAD5aUZgHdTneLS+
=3gE9
-----END PGP SIGNATURE-----