button for _NET_WM_MOVERESIZE; new property _NET_WM_ORIGIN

[Gregory Merchan <merchan phys lsu edu>]

The online version of the wm-spec does not include a button in the
_NET_WM_MOVERESIZE client message. Without this is seems the window
manager would have to track ButtonPress and ButtonRelease events to
pair them so that only a Release without a Press would end the move
or resize; and I'm not sure that would work. Unless I've missed
some detail of X programming, a new data member should be added for
this to the client message yielding:

  _NET_WM_MOVERESIZE
     window = window to be moved or resized
     message_type = _NET_WM_MOVERESIZE
     format = 32
     data.l[0] = x_root 
     data.l[1] = y_root
     data.l[2] = direction
     data.l[3] = button

(I still can't check CVS. ;-)

It is useful to provide an origin for mapping which can also serve
as a destination for unmapping. With this the "bottled genie" effect
seen on MacOS X, or perhaps something more subtle and less nauseating,
can be produced. This provides a workalike for window managers
that don't use icon windows but interact with window lists provided
by other clients. 

This is already provided by the _NET_WM_ICON_GEOMETRY property. However
there is a potential conflict here. For example, a file manager should 
be able to set this property, perhaps through a command line argument
or an environment variable, before the initial mapping or the final
unmapping of a window. If the same property were set by a file manager
and a window list, then there might be odd occurances such as animation
to the file manager destination triggered by the window list or
vice-versa.

If a _NET_WM_ORIGIN could be provided as type WINDOW, this conflict
would be resolved. WINDOW is recommended instead of the CARDINAL
quadruple to reduce the amount of interclient communication and because
the quadruple would be insufficient for operations between workspaces,
across large workspaces, or across multiple screens. If CARDINAL[]
were used, it could require a sextuple (adding workspace and screen)
and could cause problems with coordinates in large workspaces. It would
also require repeated updates as the origin point moved. Using WINDOW
allows for the property to be set once in most cases and for geometry
to be determined only when needed; the property would change only in
the event of a window change which could happen at the toolkit level
or as a result of the top-level being unmapped - in this latter case the
property would change to an ancestor in the object hieracrhy such as the
window representing a parent folder of the origin.

This will allow for a more object-oriented user interface, because
views shouldn't randomly appear but should be tied to the other view
which spawned them. An object whether shown as a file manager icon
or as a editable WYSIWYG view is still the same object and an animation
to or from an origin (often the icon) reinforces that connection.
The same property could be used for closing a view. As I recall, this
behavior can be seen in the OS/2 WorkPlace Shell.

(Please CC if you need a reply from me. I'm not on the wm-spec-list
 but will check the archives for responses.)

Cheers,
Greg Merchan