Subject: [linux-audio-dev] Small example of GUI in .so-files and a more thorough descripting of previous post
From: Lars Thomas Denstad (larsde_AT_telepost.com)
Date: pe maalis 10 2000 - 16:43:50 EST
> >For plugins that need or could benefit from more control, like a
> 3D mixing
> >application, you can supply a .so-file which holds actual GUI
> code, and make
> >the link from the .so-file holding the plugin-code to the
> .so-file holding
> >the GUI-code.
> >
> >Other obvious pros of taking this kind of approach are: You can have
> >multiple frontends to the same plugin, one using GTK+ and one using Qt if
> >you must. You can also in .so-files have frontends that takes
> special care
> >when it comes to linking in to the host-application.
>
> Stop for a moment and try to think about how this could work. I did
> earlier today, and I got the sense that although I had believed the
> same thing you say here, this is actually very, very difficult to get
> right. Explain in detail how the plugin's shared library GUI code gets
> connected to the X server, which thread runs it, how different
> toolkits interact with each other ... i don't this is very easy at all.
Ok, I see I might not have been specific enough, so I've attached an example
of what I mean.
You don't really need to do connections to the X-server the way you
describe, this is how I propose:
If the host application wants to map a coded GUI-file to a plugin (as
opposed to making a GUI based on exposed ports from the plugin), the host
loads the user interface (.so-file) specified by the user.
Linking to the widget library is a trivial task, as the host application
itself needs to link to one (or more(?)) widget libraries in order to show
itself.
The example I have attached, which is really simple, uses GTK+. The host
application links staticly to the GTK-libraries using -lgtk -lgdk, the
GUI-plugin is compiled using --shared -fPIC, and just the stubs with minimal
functionality (opening a window, setting a callback and displaying a button
with the label "Hello, host!" compiles to just below 8KB (look below for
complete instructions on how to compile/run).
I've also sketched out a system where the plugin tells the host about its
requirements, so that the host doesn't try to initialize the GUI and/or
open/close it before it knows that it can supply the GUI code.
Please note that this implementation is only capable of having a single
instance of the GUI at a given time, this is easy to extend. The interface
also needs functions to pass pointers to the actual plugin-instance that
it's associated with.
(Most of the host code is a blatant copy from "man dlopen", most of the GTK+
is lifted straight from "GTK+/Gnome Application Development".)
Please look at this approach, because I would love to see the GUI and
algorithm code separated.
Also, the requirements passed from the plugin should/could be considered an
OR-list, that is, the user should in the host application be able to specify
which toolkit he/she prefers. This leaves you with the possibility of
implementing for instance both a GTK+ and a Qt-interface in the same code
(and the host-application needs not link to both GTK+ and Qt-libraries if
you specify RTDL_LAZY). Having all GUI-code in a single file that is
separated from the algorithm seems nice to me. It will also to some extent
allow you to reuse the GUI for plugins sharing the same interface (different
chorus-algorithms, for instance).
I did really like your XML-example, BTW, I think that it is the way to go
for a lot of plugins.
Compiling the mygui.so-file:
$ gcc --shared -fPIC -o mygui.so gui.c -I/usr/lib/glib/include
Compiling the host:
$ gcc -o host host.c -ldl -lgtk -lgdk -I/usr/lib/glib/include
Starting the example:
$ export LD_LIBRARY_PATH=.
$ ./host
Larsylars.
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST