Subject: Re: [linux-audio-dev] PTAF link and comments
From: Sebastien Metrot (meeloo@noos.fr)
Date: Wed Feb 05 2003 - 14:08:58 EET
----- Original Message -----
From: "Paul Davis" <paul@linuxaudiosystems.com>
To: <linux-audio-dev@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
This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 14:20:33 EET