22 Feb
2011
22 Feb
'11
6:52 p.m.
On Tue, 2011-02-22 at 12:43 +0000, Fons Adriaensen wrote:
On Mon, Feb 21, 2011 at 09:26:09PM -0500, David
Robillard wrote:
Bingo. You said yourself, "or the equivalent if the basic system is not
X". In other words, the UI API should not be X11 based. In other other
words, the UI API needs to be toolkit agnostic, which it is. Yay.
I fully agree with everything you have said here, otherwise.
-dr
It is obviously not useful to have hundreds of
plugin UI windows open at
once anyway.
Unless they are embedded instead of being separate top level windows.
If you're on an X11 system, then you can use
X11 as a base to support
several toolkits in exactly the way you described (if those toolkits use
X11, of course). The experiment you described is an implementation
strategy, and possibly one we should use in the aforementioned library
to avoid the out-of-process overhead. The source code would be useful.
However, there is no need or even benefit to
forcing UI and/or host
authors to deal with X11 directly. That is simply a poor API design, and
a nuisance for everyone.
I think you misunderstood things a bit. Neither the host nor the plugin
has to deal with X11 directly, each of them uses whatever toolkit they
like. The essential point is that what is exchanged (once) between
them is something that is common to both - an X window ID in the case
of X11 systems or the equivalent if the basic system is not X. The
plugin uses this as the parent for its own window. Which means that
the plugin window's position, visibility, etc. are now under control
of the host.
The code needed to do this can be part of a plugin support library on
both sides.