17 Nov
2003
17 Nov
'03
12:47 p.m.
On Mon, Nov 17, 2003 at 04:04:46PM +0000, Steve Harris wrote:
It doesn't depend on the host's support in any way. The host doesn't even
have
to be an X client - the same library can be called by for example an internal
JACK client.
The shared library creates a thread for the X code, connects to the X-server
as a new client, and provides a set of widgets (C++ classes actually) and some
other code as a dedicated 'mini-toolkit'. It also provides methods for lock-free
communication with the audio code. The X-connection and thread are shared by all
plugins.
Plugin code remains relatively simple since most of the hard work is done by the
library. But it has to be C++.
Maybe I'll present this in Karlsruhe next year. ATM it's 'for personal use
only'
as it touches on too many sensitive areas, and I don't want to start new GUI /
toolkit / language wars. :-)
--
FA
I see, but I still dislike the idea FWIW :)
Well if you want the functionality (and I do) I see no other way,
except by doing something that would break the existing API.
I have some
plugins that are able to create their own GUI (by using a shared
library that makes them look like a single client to the X-server, and that
also provides a standard set of widgets). Clearly, all instances that belong
to the same module should share the same GUI. The proposed way of using
the standard 'lifecycle' functions enables them to do this correctly.
This is a valid point, and and interesting technique, does it work with
arbitrary host toolkits? How do you bypass the hosts connection to the X
server?