[linux-audio-dev] cross-toolkit host/plugins: significant news

2003-11-18 Thread Paul Davis
its been a productive evening/night. or has it?

i hacked up a small test that runs Qt as a host, and loads a shared
object that uses GTK+ as its GUI. the host loads the shared object,
and runs its GUI, in addition to its own. cool, eh?

well, not so fast. i am now wondering what in the hell all the fuss
was about in the first place. and as the main progenitor of you can't
do this, i feel responsible for cleaning up the mess.

why? i don't see anything in what i've done that is at all clever. the
only slightly tricky part is running the GTK+ GUI in its own thread,
and routing requests to instantiate a new GUI to that thread via a
pipe that is hooked into the GTK+ event loop. i can't see any reason
why *any* toolkit couldn't be used in this way (assuming it can do
this kind of add an fd to the event loop thing, and AFAIK they all
can). i even removed all the stuff i added to open a dedicated X
Display - it just isn't necessary. Qt and GTK+ both have their own
connection to the X Server, and there are separate event loops
handling windows created by each toolkit, each running in its own
thread. all you have to avoid is a plugin calling QApplication::exec()
or gtk_main() etc., which will different and odd effects on each
toolkit. 

AFAICT, there are two things the host can't really do. one is to snoop
on events for other toolkit's loops. so, a host that relies on
snooping keyboard events (e.g. ardour) is out of luck when it comes to
events occuring in plugin GUI windows using a non-host-toolkit. the
host also cannot get access to the toplevel windows of the
non-host-toolkit, so it can't add the kind of generic widgets that you
tend to see on TDM/VST plugin GUIs for bypass, save and so forth.

but to return to the core issue here. what the f*ck have i been
ranting on about all this time?  unless its just the issue of globals
in Xlib, but i really don't believe they are there anymore, at least
not in XFree86 ... yes, the toolkits can't share an X Display, but fer
chrissakes! they don't even try to!!

to put in bluntly, it appears that i have been totally and utterly
full of crap, and have unnecessarily delayed the advent of decent
plugin GUIs on linux by a year or more.

if anybody wants to see the code for my little demo, i'll tar it up. i
hate the way Qt takes over the build process. It reminds me too much
of Oracle in this respect. Anyway, i need to get to bed. I feel glad
that this can be made to work, but embarrased about what i may have
done here.

--p


Re: [linux-audio-dev] cross-toolkit host/plugins: significant news

2003-11-18 Thread Fred Gleason
On Tuesday 18 November 2003 02:14, Paul Davis wrote:

 to put in bluntly, it appears that i have been totally and utterly
 full of crap, and have unnecessarily delayed the advent of decent
 plugin GUIs on linux by a year or more.

So, book yourself a guilt trip, and when you return, life will go on...  :)


 i hate the way Qt takes over the build process. It reminds me too much
 of Oracle in this respect. 

It's not that difficult to build Qt apps without resorting to Qmake.  I 
typically do the following in Makefile.am:

# Define the dependency for the Meta Object Compiler
MOC = $(QTDIR)/bin/moc
moc_%.cpp:  %.h
$(MOC) $ -o $@

# Then, lay out the dependencies like so:
bin_PROGRAMS = myprog
dist_myprog_SOURCES = myprog.cpp myprog.h
nodist_myprog_SOURCES = moc_myprog.cpp
myprog_LDADD = -lqui

This will work with vanilla Autoconf/Automake, and will ensure that the MOC 
gets called at the correct time, while also autocleaning the MOC output when 
building dists and such.  It does require that your environment contain the 
path to your Qt installation in QTDIR, but that is a standard part of a 
correct Qt installation, as per Trolltech.

Oh, and thank you, Paul.  The work you do is *very* appreciated around here...

Cheers!


|-|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development  |
|   | Salem Radio Labs|
|-|
|  No woman can endure a gambling husband, unless he is a steady winner.  |
|-- Lord Thomas Dewar |
|-|