Here's a proposal for a tiny protocol extension (one request other than
QueryVersion) that would help a lot in making inter-client embedding
robust.
I'm willing to do the work in implementing this for XFree86, though
I might need help in checking the protocol for sanity and figuring
out how to implement it. (A separate library for one request seems
like overkill, but I'm not sure that adding it to XLib would be
legitimate.)
Does this proposal make sense?
Thanks,
Owen
ChangeSaveSetValues
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match
Sets the save-set values for WINDOW. window must be in the client's
save-set or Match error occurs.
The value-mask and value-list contain the attributes to change. The
possible values are:
target: WINDOW or None
map-action: { Nothing, Map, Unmap }
x-offset: INT16
y-offset: INT16
When the client's resources are destroyed, if window is an inferior of a
window
created by the client,window is:
Reparented to the target value window, or if None, to the closest
ancestor such that window is not an inferior of a window created
by the client.
Mapped if map-action is Map, unmapped if map-action is Unmap.
Moved such that if the original root-window location of the client's
upper left corner is x,y then the new location is x + x-offset,
y + y-offset.
The default component values when a window is added to the client's save-set
correspond to the core protocol behavior and are:
Component Default
-----------------------
target None
map-action Map
x-offset 0
y-offset 0
Rationale:
Being able to set the target is important when doing-interclient
embedding as in the XEmbed protocol.
(http://www.freedesktop.org/standards/xembed.html.) If the
embedder is unexpectedly killed, the behavior of the core protocol is to
reparent the client to the window manager's frame and map it. Since the
window manager then destroys its frame, the client window is not saved,
and the client application will likely crash. The client application may
have a separate toplevel (e.g. an application with a status docklet in
the desktop's panel) or windows embedded elsewhere, so this is highly
undesirable.
Setting the map-action so that the window is unnmapped rather than
mapped is desirable to keep the window from temporarily being visible as
a child of the root window. (Note that unmapping and reparented back to
the root window not result in a "lost" window, since this is the normal
termination of the XEmbed protocol and clients are required to watch for
it.)
x-offset and y-offset can be used by a reparenting window manager so
that if it is killed unexpectedly then when a new window manager is
started, windows appear in their original location, rather than offset
by the frame thickness.
Possible Issues:
Allowing the target to be a WINDOW may complicate implementation to
handle the case where the target is destroyed between the
ChangeSaveSaveSetValues call and the client being destroyed. An
alternative which handles the use case is to make it an enumeration with
the possible values { NearestParent, Root }.
The save-set values are per-client, per-window rather than per-window.
I think being per-client is more logical and probably easier to
implement since the save-set itself is per-client.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
