Keith Packard <[EMAIL PROTECTED]> writes:
> > ChangeSaveSetValues
>
> I think all you need is the ability to reparent to the root. As the
> embedded window isn't override-redirect, the remapping will be redirected
> giving the window manager a chance to peer at the window. A suitable WM
> convention could be developed to get the embedded window moved to its
> final resting place. As you say in your proposal, other alternatives
> involve significantly more error checking and validation at many points in
> the server.
Since I don't actually need anything but reparenting to the root, and
I can't think of any good reason for reparenting to an arbitrary window,
I'm happy to simplify things in that area.
I'd rather avoid getting the window manager involved too much here;
perhaps the "two's company, three's a crowd" principle applies when
trying to make things robust. What I'd like to achieve is that when
the embedder dies, the embedding protocol ends simply and cleanly; if
we need to extend the X protocol, we might as well solve the problem
completely (if it's only a few lines of extra code) rather than also require
a new window manager convention, and a cooperating window manager.
Also, I think adding window manager conventions like "don't map windows
with the _XEMBED_INFO property on them" is a little dubious ... I think
conventions are best when, if the window manager doesn't support them
the fallback behavior is reasonable.
> This would also eliminate the need for x-offset/y-offset values, so the
> extension could contain only a single request identical to ChangeSaveSet
> with an additional mode (SetModeInsertRoot).
The x-offset/y-offset addition is really quite separate thing, with
the only connection being that had been pointed out to me as a problem,
and it was very easy to fix at the same time.
The problem basically is that the ICCCM specifies positioning adjustments
on startup and shutdown (gravity point on unmanaged and managed
windows should be on the same place) and the shutdown adjustments won't
be made if the window manager terminates abnormally.
It could certainly be fixed without any X additions if window managers
consistently supported looking for some _NET_WM_CRASH_OFFSETS property
at start. Ugly, but it certainly better than extending the X protocol
just for this reason. But, it seemed to me that if we could fix it
easily here we might want to do it.
Since the only people who regularly switch window managers, or have
their window manager crash notice problems here, and the problems
(drifting windows) aren't severe, it's not really a problem for
end-users.
I'm certainly not strongly attached to either:
a) Making it a separate request instead of a ChangeSaveSet replacement
b) Using a fixed set of parameters rather than a ChangeGCValues
They are just fairly arbitrary protocol design issues; the basic
I reasons I had for them were:
a) Reuse as much existing API as possible. (And the x-offset/y-offset
values are likely to need to be changed if things like the window
manager
b) There were four parameters that could be set; this is enough
that it doesn't seem like a "fixed number", but rather a
variable quantity.
> Are there other WM related extensions that we could usefully merge with
> this extension? I'd like to solve any outstanding issues all at once,
> rather than with a zillion tiny extensions.
The main other area where I'm aware of where an extension might be
needed is in some issues related to selections ... it would take me a
while to remember all the issues, but when I was trying to figure out
how to fix some of the problems with implementing a full-featured
clipboard in X, there were issues that were really hard to deal with
without notification of selection ownership changes.
This doesn't really seem very related, but I suppose we could make a
"client communication" extension that just contained "random" things
related to ICCCM / desktop issues and plan to increase the minor
number as necessary if we add more stuff in the future.
Regards,
Owen
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
