Re: [linux-audio-dev] Small example of GUI in .so-files and a more thorough descripting of previous post

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Small example of GUI in .so-files and a more thorough descripting of previous post
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe maalis 10 2000 - 18:24:02 EST


>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).

There's no question that doing this with a given toolkit is easy -
I've done this before, and sure, it works well.

The challenge I want to solve is where the plugin cannot assume that
the host runs any particular toolkit. The kind of thing I would love
is something a bit like Glade's "abstract" specification of the GUI
that gets turned into real GTK objects when loaded, but I want to do
it without *writing* another "layer" over one or more toolkits.

Here is an old quote from gtk-list that sort of describes my thinking:

   Date: Mon, 18 Oct 1999 00:05:16 +0200
   To: gtk-list_AT_redhat.com
   From: redhog_AT_mini.dhs.org
   Subject: [gtk-list] Foreign events
   Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog_AT_lysator.liu.se>

   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA1

   I have created a program that, with the help of a GtkSocket, embedds a
   window of another application into it. In this program, I would like to be
   able to show a menu, if the user clicks with some button and some
   modifiers somwhere in the embedded window. It is an easy task to set the
   event mask for that window, but the Gtk main-loop will happily discard
   that event, whilst it does not come from a widget, and is not a property
   delete event. How do I work around this, or is it something I've overseen?

   Anyway, why isn't there a way for the user program to collect all events
   discarded by the gtk main loop with some type of general event-handler?
   UIs this something that does exist, but I haven't figured out. If it
   doesn't exist, is it planned for future gtk-releases?
   W.b.r.,
   Egil Möller

>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).

I don't think this can work. Both of these toolkits assume that
*their* inner loop is running for event collection and dispatch. That
implies 1 thread per toolkit PLUS a clever low-level X event
dispatcher than sends X events to the right place. That isn't easy,
not easy at all :) Yes, someone has recently done a GTK wrapper for Xt
widgets, but I suspect that if we told someone in either the GTK group
or the Qt group that we wanted to write a program that used *both*
toolkits, we'd be laughed at, really hard, deep down belly laughing :)

>I did really like your XML-example, BTW, I think that it is the way to go
>for a lot of plugins.

Thanks.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST