Re: My comments on the WM spec

[otaylor redhat com]

Sasha_Vasko osca state mo us writes:

> > _NET_NUMBER_OF_DESKTOPS
> > 
> >  I find the language
> > 
> >    _NET_VIRTUAL_ROOTS MUST be set  store the new number of desktop
> >    virtual root window IDs
> > 
> >  a bit confusing.
> > 
> >  I would suggest:
> > 
> >    The contents of _NET_VIRTUAL_ROOTS MUST be altered so that the
> >    number of window IDS it contain is new_desktops_number.
> 
> It makes it sound as if any kind of Window ID can be there :)
> perhaps like so: 
>
> The contents of _NET_VIRTUAL_ROOTS MUST be updated so that the
> number of virtual root window IDS it contain is new_desktops_number.

If you put a window ID in _NET_VIRTUAL_ROOTS, then it
is, by definition a virtual root window ID, right? But sure,
your wording is OK too.
 
(But we should make sure that everybody agrees that this
is the right interpretation of _NET_VIRTUAL_ROOTS)

> > 
> >  (If that is the proper interpretation; I'm not completely sure
> >  about _NET_VIRTUAL_ROOTS, see below)
> > 
> >  I would also suggest that language be added indicating that
> >  if _NET_CURRENT_DESKTOP need to be changed or windows need
> >  to be moved to a different desktop, these changes must
> >  be changed _before_ _NET_NUMBER_OF_DESKTOP is changed.
> 
> Well, good practice would be to see what exactly you are about to do:
> If you are shrinking the list of desktops - then you have to update
> property PRIOR to actually removing desktops and moving windows, 
> so that Pagers and whoever else, will not attempt to use desktops that are
> about to be removed.
> If you are expanding list of the desktops - then yes,  you have to 
> create desktops first and THEN update property.
> 
> All of that comes from the standard practice that you have to create 
> resource prior to actually advertising it, and you have to stop 
> advertising 
> prior to dropping resource. Dunno if it is actually worse mentioning 
> in the specs, even thou there are some rather unaducated ppl writing 
> window managers ( remmebering myself few years ago ).

Well, there will always be race conditions where a pager can try
to use a desktop that has just been removed. We can't solve
that race condition. What I think should be avoided is the 
window manager ever advertising "I have 3 desktops and window
X is on desktop 4". This is why I suggested the ordering
that I suggested - not to avoid race conditions, but to avoid
inconsistent properties.

Of course, both pagers and window managers  need to be written
to be robust against members of the other set that advertise
strange values, so maybe there is no real need to guard
against temporary inconsistencies.

> > _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.
> 
> I'd prefer it to be a ScreenWidth * multiplier1 , 
> ScreenHeight * multiplyer2, sine it would allow for whole number of 
> viewports(screens) on each desk in each direction.
> But this is not really critical since window manager is allowed to ban
> any illigal sizes that it chooses not to support, besides one does 
> not want to restrict specs like that.

No real opinion here. whole number of screen sizes do seem to be
pretty much universal currently. I would note that you don't get
a good user interface for changing properties if some settings
are just randomly ignored. (IMO, configuring the WM through
the WM spec protocol is just silly, but that is just IMO.)

> >  [ 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 ]
> 
> Any app that reads this or any other property should be prepared for 
> possible misconfiguration. But yes allowed ranges for values should be 
> mentioned in the specs.
> I double that.

[...]

> > _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.
> 
> That is actually major pain in the neck.
> Normal practice is to map window on current viewport, so if your window 
> requests +100+100 and your currect viewport is +1024+768 then resulting 
> position in virtual space will be +1124+868, position reported back to 
> window will still be +100+100 (with adjustments for frame size/gravity )
> untill viewport is changed.

OK, then this needs to be specified in the specification; something
like:

  Window coordinates are given with respect to the origin of
  the current viewport. This means that the origin of windows
  will change when the viewport origin changes. 

It seems to me that this will be inconsistent with the coordinates
when using virtual root windows, since in that case, the natural
thing to do is simply to move the virtual root window instead
of moving the clients with respect to the virtual root window.
(I forget what enlightenment does in this regard.)

> >  Again the client message format is missing
> 
> _NET_DESKTOP_VIEWPORT
>         message_type = _NET_DESKTOP_VIEWPORT
>         format = 32
>         data.l[0] = new_vx
>         data.l[1] = new_vy
> 
> Window Manager MAY choose to ignore that message, in which case 
> _NET_DESKTOP_VIEWPORT property will remain unchanged.

Hmmm, I guess we can allow this to be ignored, though this
is a bit different than ones that are affecting configuration.

I think on this one, I'd prefer to say something like:

 If new_vx and new_vy define an acceptable position for the
 viewport, the window manager SHOULD change the viewport 
 so that its origin is at new_vx, new_vy and update the 
 viewport accordingly.

That is, say that the window SHOULD (but not MUST) obey
the message if it makes sense.

> > _NET_DESKTOP_NAMES
> > 
> >  The type and format are not specified. Is this the standard
> >  NUL-separated list of strings?
> 
> _NET_DESKTOP_NAMES, UTF8_STRING[]
> 
> NULL separated list of strings in UTF-8 encoding, 
> with additional NULL at the end of the list (to match other standard X 
> properties ).

Hmmm, but the ICCCM, in the discussion of class hints (section 4.1.2.5) says:

 "Note that the WM_CLASS strings are null-terminated, and thus differ 
  from the general conventions that STRING properties are null-separated.
  This inconsistency is necessary for backwards compatibility."

> > _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.
> 
> I don't know of anyone that does it either. At least AfterStep does
> not do that (heh, sounds like another piece of work todo).
> It really sound cleaner to use selections for this purpose
> Perhaps the following target on selection WM_Sn :
> 
> _NET_SUPPORTED  ATOM            list of atoms identifying supported hints.
> _NET_VERSION    INTEGER two numbers identifying supported 
>                                         version of specs.

the window manager name should probably also be a target.

> I don't think its nice to do such a change so close to final release,
> at the same time if it is not done, then future versions of this specs
> will either have to stick to current way, or will have to mandate both 
> ways for compatibility purposes.

Yes, that was a concern of mine too. Basically, I just noticed
this in the ICCCM for the first time, and wanted to point out
that it did exist, though everybody either seems to have missed
it or ignored it.

> > _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.)
> 
> Problem is that Virtual roots are the only way to correctly implement
> multiple virtual desktops. All other ways are either ICCCM incompliant
> (those that unmap windows when desktops are switched ), or has to do wierd
> window moving , in order to get them off screen.

Why do you think unampping windows when desktops are switched is
not compliant with the ICCCM? Yes, there are consequences for an
application if the frame window is unmapped (it may, for instance,
lose pointer grabs), but the application needs to handle these
circumstances for iconification in any case. 

> Virtual roots are no different from other frame decorations, and as such 
> conform to ICCCM. After all ICCCM says that clients should not try and 
> determine how much and what kind of frame  decorations they have, and 
> try to move/resize itself, based on this information. 
> So the problems with virtual root arrise only in specific apps that tryes 
> to do "illegal" ( from point of view of ICCCM ) things - namely
> file managers that tries to place icons on desktop, and apps like
> xident - that grab pointer on root in order to let user choose any 
> particular

Section 4.1.5 makes the claim that an extension is needed. It doesn't
give much of a rational, but a number of the provided clients with
the X distribution do the things you are calling "illegal" (e.g.
xwininfo), and I think the model that the writers of the ICCCM
clearly had in mind was one frame window per app.

> client. Both of this apps has to know what virtual roots are in order to 
> work correctly. Since those things are usual part of any desktop 
> environment,

Actually, most desktop environments _don't_ have virtual roots
currently... (with the exception of E.)

> then the list of virtual roots advertised by window manager is must-have
> if this specs choose to support virtual desktops.

I haven't found anything in GTK+ that I _can't_ do with the current E
equivalent to _NET_VIRTUAL_ROOTS, but it certainly makes some things a
lot more difficult. (In many cases, for instance, you have to walk up
the window heirarchy instead of calling XTranslateCoordinates().)

> > _NET_CLOSE_WINDOW
> > 
> >  There is a formatting problem with client message format
> >  specification.
> 
> it should be :
> _NET_CLOSE_WINDOW
>         window = target_client_window
>         message_type = _NET_CLOSE_WINDOW
>         format = 32
>         data.l[0] = 0 /* may be used later */
> 
> > 
> > _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.
> 
> it may be sufficient to say that client should not grab pointer,
> or release garb if it already has one, prior to sending this message 
> to the Window Manager

It's not sufficient. The ButtonRelease may occur before the
window manager receives the ClientMessage, so the window manager
must deal with the fact that it may not receive the button
release.

> >  (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.
> 
> hmm, Mouse Button is indeed needed if window managers wants to grab 
> correct (pressed) button.

> >  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.
> 
> I'm not so sure, this message identifies part of the client window,
> and you never call left border of the window its West side.

Speak for yourself :-)

> > _NET_WM_NAME
> > 
> >  The property type for this property isn't specified - I would
> >  suggest UTF8_STRING. _NET_WM_ICON_NAME is missing.
> 
> my opinion is that both of those properties are redundand and 
> WM_NAME /WMICON_NAME should be used instead, but what do I know.

This would be incompatible with switching between window managers
compliant with the new spec and legacy window managers, since
we would be adding new possible types for WM_NAME that are not allowed
by the ICCCM.

> > _NET_WM_STATE
> > 
> >  I don't have concrete suggestions here, but I will note that
> >  this property feels very hackish to me:
> > 
> >   - It groups together different things
> > 
> >     - current state of the window (SHADED/MAXIMIZED)
> >     - the way the window should be treated
> >       (modal, skip taskbar, sticky)
> 
> The only questionable part here is skip_taskbar, but since
> it really is a status of the window vs. its type - it should be here.

Why skip-taskbar status not type? (I just don't follow the argument)

> >   - 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.
> 
> "unset" and "not specified" in this context really means the same - 
> unset. By default all of those flags considered to be unset, 
> user may selectively turn them on, but you never really expect user to 
> come up and say "Hey I really want to prvent this window from starting up
> in Shaded state, no matter what my window manager thinks!", even if it is 
> so - 
> its more like window manager configuration problem.

For shaded, that's probably the case. But I don't understand how
"modal" is determined - surely it isn't that the user clicks
on the dialog's window menu and selects "make dialog modal..."

> >   - The concept that exactly two properties may be changed
> >     together seems very odd to me.
> 
> its not exactly - its up to.
> merely a convinience feature. So if you need to maximize window - 
> you don't have to send 2 events, one for horizontal, another for vertical.
 
Well, that's not exactly a convenience feature - you really want to
keep the user from seeing the window first maximize vertically, and
then horizontally. So, I think it is a necessary hack.  But this
basically violates the "1 or n" rule of interface design - that is, if
an interface supports more than 1 of something, it should support any
number of that thing.

> >   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.
> > 
> >   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.
> 
> there is no sense in default status. Status of the window is dynamic
> property and is evolving over time, based on user actions. The only 
> correct way to unset it to default would be to withdraw window and 
> map it again, thus causing WM to forget its history.

But we _allow_ a default status because we say that the property
is honored on map. 

> > 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).
> 
> GRRRR
> I'll never get it right. Here is another attempt :

> When interpreting both initial geometry when transfering window from 
> Withdrawn state, and (x,y) position in XMoveWindow( w, x, y) requests, 
> window manager will first convert (x,y) into the client reference point - 
> (ref_x, ref_y) based on gravity, and then will move frame window based on 
> changes in this reference point and gravity again.
> 
> reference point is calculated like so :
> Gravity                                 ref_x value
> 
> West                                    x
> Static                          x+border_width 
> East                                    x+border_width+width+border_width
> Other(Center or missing)        x+border_width+(width/2)

I believe this is still not correct: the definition in the ICCCM is that
the window is positioned so that the upper left corner is at X,Y,
and then offset so the reference point stays put when the frame
is added.

With your algorithm, a X geometry specification of -0-0 would
result in a window that was partially off-screen on the lower left.

Also, the saying "Center or Missing" is confusing since it sounds
like you are saying that the default gravity is Center [ it is
NorthWest ], though I know that is not what you are saying

Using the same ref_x, ref_y convention, the way I would present
it, is a table like:

                          ref_x              ref_y        
NorthWest                   x                  y
North                   x + width/2            y
NorthEast               x + width              y
West                        x               y + width/2
Center                  x + width/2         y + width/2
East                    x + width           y + width/2
SouthWest                   x               y + width
South                   x + width/2         y + width
SouthEast               x + width           y + width
Static                      x                  y

then describe, exactly as you do, what part of the frame
(or for StaticGravity, window) should be positioned at
ref_x and ref_y.

Regards,
                                        Owen