22 Feb
2011
22 Feb
'11
1:43 p.m.
On Mon, Feb 21, 2011 at 09:26:09PM -0500, David Robillard wrote:
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.
Toolkits that can't
* extract the underlying type (in this case a X window ID) from their
own data structures or
* use such information as a parameter when creating a new window of
their own type
are simply deficient.
Ciao,
--
FA