----- Original Message ----- From: "Paul Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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
