Sure, I know the problem only is present if we want to get user interactions. Drawing in itself never have been a problem. Naive question: did anybody try to create an executable with 2 threads. In the first thread you run a simple GTK application, in the second thread you run a simple QT app. Being each in its own thread, and opening their own XDisplay. Would this work or is it really time I got and get my pill?
Sebastien (hoping XLib is not full of ugly global variables...) ----- Original Message ----- From: "Paul Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 05 February, 2003 15:18 Subject: Re: [linux-audio-dev] PTAF link and comments > >>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. > > and to put this a different way, you are also fine if you use a > "drawing kit" (such as OpenGL). these don't have event loops per se - > they just provide ways to draw things on an XDrawable. > > --p >
