5 Feb
2003
5 Feb
'03
10:30 a.m.
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" <paul(a)linuxaudiosystems.com>
To: <linux-audio-dev(a)music.columbia.edu>
Sent: Wednesday, 05 February, 2003 15:18
Subject: Re: [linux-audio-dev] PTAF link and comments
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
>>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.