Re: [linux-audio-dev] PTAF link and comments

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. 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. 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. otoh, i am the author of an XML schema for such purposes too :) --p