[linux-audio-dev] PTAF link and comments

Paul Davis paul at linuxaudiosystems.com
Wed Feb 5 08:54:01 UTC 2003


>> its not to do with limitations of XWindow. in fact, the most positive
>> reason has to do with the most notable feature set of XWindow: total
>> network transparency. as steve has already noted, its easy to come up
>> with scenarios (well, once you leave the home studio behind) where you
>> want to run the GUI on a different display than the one attached to
>> the host where the DSP is running.
>>
>
>Both Windows and OSX provide a way to do this too (Win32 provides an API
>named Terminal Services and Apple developed something equivalent for OSX
>Server). Network Transparency of the actual rendering doesn't mean you have
>to giveup a good programing paradigm, it is even the oposite: it should
>simplify the framework for the programmer.

for the GUI programmer, sure. even for the plugin programmer sure.
but for the host programmer: it means that you can't assume that a
"plugin" includes DSP code *and* GUI code that should both be
executed in your process context.

>> >the toolkit so that they can coexist gracefully. Motif allready provides
>an
>> >API for other toolkits to hook into the event system, the others should
>> >start doing the same.
>>
>> i don't think you understand this point deeply enough (that's OK: most
>> people don't). all the toolkits do what Motif does. what none of them
>> do (or do well enough) is to be able to take advantage of the presence
>> of these hooks. GTK offers way to let Qt hook into the event loop, but
>> Qt can't use them. Qt offers GTK the same, but GTK can't really use
>> them. etc. etc.
>>
>
>Can you elaborate on the reason why they can 't use the hook? I often talk
>with a very knowledgeable XWindow programmer and he never mentioned that
>they can't use the hook.

i've spoken about this often here. the toolkits all assume that *they*
own the event loop. this is the critical problem. they provide ways
for other APIs to hook into it, but they don't provide ways to be
hooked in. moreover, some of the toolkits simply have no idea what to
do with events that are delivered by XWindow that correspond to an
XWindow that they (the toolkit) did not create. this creates a
multiway problem: the better toolkits can dispatch events to other
handlers, but none of the toolkits have the relevant handlers; the
worst toolkits can't dispatch events to other toolkits, and can't be
patched into the dispatch of better toolkits.

GTK has made some progress in this area with the move to GTK2. this
comes mostly from the use of glib and its abstractions. the X server
connection is just another event and/or i/o source, and they have
decomposed the various stages of the event loop into functions that
can be called from other places if desired. the last time i looked,
however, it would still be more or less impossible to merge a Qt GUI
with a GTK event loop or vice versa.

>> well, there is a bit of a problem here. nobody but us chickens (people
>> writing shared objects with their own somewhat independent GUIs)
>> notices this problem. it doesn't affect traditional applications, and
>> it doesn't affect the more traditional "plugin" systems that don't
>> come with per-plugin GUIs. there is very, very, very little pressure
>> on the developers of toolkits to fix this problem.
>>
>
>It sure does for every application that proposes a plugin system. I have
>been programing maya plugins profesionally and having the ability to use any
>toolkit I want for my GUI certainely counts. Same goes for photoshop
>plugins, FCP plugins, etc... I know the sort answer to this question from
>unix people is always "you can't do this", period. Browser plugins have the
>same problem too, in fact the lack of flexibility prevented people from
>doing it but I'm pretty sure they would have done it a lot more if it was
>available.

the point here is that not that there is any problem with XWindow. if
you are willing to use Xlib directly, you can do all this stuff with
no problems at all. the problems all arise from toolkits being too
egocentric and thinking that they will inevitably control the event
loop. if you cut toolkits out of the picture, and scribble on XWindows
and XDrawables using XDraw* functions and stuff like that, the
problems all go away. the problem is, nobody really wants to work at
that level, it seems.


>> >XML + Scripting language is very nice but not flexible enough.
>>
>> you might be suprised to know that i agree with you :) thats partly
>
>Oh, that's a surprise for sure! :-D.

otoh, i am the author of an XML schema for such purposes too :)

--p



More information about the Linux-audio-dev mailing list