wm-spec 1.9f

[Sasha_Vasko osca state mo us]

>Hi,
>
>Julian kindly made some revisions to the spec based on discussion
>here. I've added them to the "official draft."

It all seems to be very clean and clear now. Good job.

>
>Appended is his message, and the diff.
>
>Havoc
>
>Message from Julian:
>
>I've collated all the traffic on the list, and come up with a new 1.9f
version
>of the spec. Hopefully by the time this gets posted Havoc will have it on
>www.freedesktop.org. I've tried to make changes where there was a clear
>direction. In the case of uncertainly or the lack of a definitely better
>solution I've tried to follow the principle of least change, and clarity.
>
>
>Remaining comments:
>_NET_MOVE_RESIZE still has a PDW comment - "what are the click
co-cordinates
>relative to ?" This needs to be answered. Implementers ?

Two possible approaches here:

1)
Actually when moving/resizing windows what you need is not acoordinates of
mouse click, but coordinates difference vector between two adjucent mouse
click
events. For example user clicks in (530, 180) and then moves mouse into
(535, 170).
In that case all you need to know is that difference is (+5,-10), and you
can then go about applying it to whatever corner/hotpoint/grip you want.

2)
Otherwise you must have an events that indicates beginning, and ending
of move/resize process.
For example first _NET_WM_MOVERESIZE received by window manager will not
cause any actuall moves/resizes - it will put WM into waiting mode, and it
will
wait for following events to do actuall move/resize relative to the point
in first event. Accordingly, it will stay in wait mode untill special
message
arrives, signaling that process is complete. It seems to be a good idea,
for this last message to have coordinates same as previous message.

Approach #2 has advantage that it allows window manager to change cursor
when
it enters move/resize mode, thus indicating user that it is actually doing
something. Disadvantage is that it makes protocol more complicated, and
there is
a possibility that client will initiate process, without correctly
terminating it
( like segfault in the middle ), thus leaving WM in undefined state.

Advantage of approach #1 is that the communication protocol is fault proof
and is
much simplier, althou it adds neccessity for client to provide indication
to user,
about  the fact that we are moving/resizing atm.


Cheers
Sasha Vasko