Re: My comments on the WM spec

[Sasha_Vasko osca state mo us]

[snip]

>> > _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.

There are 2 possible approaches to implement virtual desktops without 
using virtual roots.
1) move all the windows from "hidden" desks off the screen into some wierd
location, say -10000, -10000.
2) unmap frame window without unmapping client window.

First approach is nasty and dirty, it it may not work if window will 
choose
to size itself verry large, ( say 100x11000 ). Any window that relies 
on its position on the screen ( say transparent Eterm or aterm ) will have 
to 
perform some computations (of potentially sugnificant size) in order 
to adjust for each move. Some other problems comes up. There are of course 

workarounds, but it does not make this approach any cleaner.

Second approach is what, I belive, is used in most window managers.
Problem is that it directly contradicts ICCCM (4.1.4):

"Conversely, if a reparenting window manager renders the client's window 
unviewable by 
unmapping an ancestor, the client's window is by definition in the Iconic 
state and must 
also be unmapped."

So such an approach leaves client in undefined state - nor Normal nor 
Iconifyed, thus potentially causing troubles. Note that iconifying client 
in this situation does not work since WM represents iconifyed windows 
differently,
thus creating confusing situation for user, when all windows on inactive 
desks 
are somehow iconified.

I must agree that in real life second approach works without major 
headaches, but
any WM that employs it may not claim ICCCM compatibility, since it does 
contradicts it.

>
>> 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.

I must agree that anyway you implement it  - virtual desktops are 
non-standard
and break some things, but virtual roots are the less incompatible way, 
and at 
least does not directly contradicts ICCCM.

Lets say that writers of those apps had not much choice but to assume 
that there are no virtual root windows. Since virtual desktops are 
non-standard 
extension, its responsibility of those WMs who introduce it to, provide 
user with 
tools, instead of those rendered useless but this extention. That is why 
it 
is important to add this property to specs, since it will move development 
of such 
tools in to the domain of desktop environments, where it belongs.

>
>> 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.)

that is a pity, as I mentioned above.

>> 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().)

Several things :

- Drawing on root window (XEarth and likes)
- xroottail
- as you mentioned - xwininfo
- whenever you desire *ah*oh* to get the size of frame decorations - 
  you can't do that without knowing where in win hierarchy virtual root 
is.

>
>
>> > _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.

Or even worse - button pressed, the released and then pressed again
( maybe even in different location ).
There definately has to be more complicated mechanism in place.
The least we need is the time of press event to be passed along to WM.

>
>> > _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)

This is extremely nasty question, when you come down to it 
State and Type are extremely intermixed.
While iimplementing all that in AfterStep I finally got the the 
following definition :

Window Type is the property of the window that cannot be changed
using any of the iterface controls available to user - supplied by WM, 
Pager, Taskbar, whatever. 
On the contrary Window Style is something that can and will be changed
by the user, via any of the available interface elements.

As per this definition, modal and skip taskbar both should go as the 
Type properties, you are absolutely right. Althou I don't think there 
is time to change specs in this regards - may be in future.

>
>> >   - 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..."

yep, see my comments above.

>
>> >   - 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.

I must agree with that, althou I don't see clear way out for now.

>
>> >   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.

What I mean is that you cannot really unset_to_default - what is the 
default? status of the property when window was mapped ? or last changed 
by the client ? Confusing.

>
>> > 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,

(X,Y) are coordinates of the OUTER edge of the window, don't forget
about initial border width of the window.
What that means is that you get X,Y,Width,Height,Border_Width from
XGetGeometry request, And the way XGetGeometry returns it is that
X,Y are position of the outer border edge, so the actuall client is 
in X+Border_Width, Y+Border_Width.

>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.

nope. X geometry specification must be preprocessed by client:
firstly : -0-0 means SouthEastGravity
secondly: client will map itself not at (0,0) but at 
( ScreenWidth-1-border_width-width-border_width, 
  ScreenHeight-1-border_width-height-border_width ) 

Applying my algorithm, that would place reference point at :
(ScreenWidth-1, ScreenHeight-1) (which is right bottom corner of screen)
and for SouthEastGravity that will be the location of outer Bottom-right 
corner of the frame window. As the result we'll get client window 
right in the corner - where expected.

>
>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

well, yes, its kinda nasty, but what can I do since gravity does not 
clearly
has any x and y component. What Missing means is that this component of 
gravity
is undefined ( even thou other component of gravity may be defined )
Its wierd in words, but quite clear in actuall algorithm.

>
>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

you are forgetting initial border width of the client, which is mandated
by ICCCM.

>
>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


Cheers
Sasha Vasko