----- Original Message -----
From: "Paul Davis" <paul(a)linuxaudiosystems.com>
To: <linux-audio-dev(a)music.columbia.edu>
Sent: Wednesday, 05 February, 2003 12:49
Subject: Re: [linux-audio-dev] PTAF link and comments
>I think LAD people wants to enforce this because
of the limitations of
the
>XWindow system which is a bad reason. The good way
of doing this is to
FIX
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.
>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.
> Isn't it what opensource is all about:
taking the time
>to fix wrong designs instead of rushing the apps out of the door to
satisfiy
>short term customers? Apple had the exact same
problem in the classic
API:
>the event management was totaly centralised inside
an application, and
they
>fixed it when developping Carbon. If even apple
can fix their wrong
designs,
everybody can
:-).
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.
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.
--p
Sebastien