Subject: Re: [linux-audio-dev] LADSPA and JACK
From: David Olofson (david_AT_gardena.net)
Date: Wed Mar 06 2002 - 05:54:02 EET
On Tuesday 05 March 2002 16.14, Paul Davis wrote:
> >I still think there is, but I'm not so sure it's actually
> > something that can be implemented with a reasonable amount of
> > work. I believe the problem with any new toolkit of the
> > traditional kind is that it would either be too restrictive, or
> > too hard to learn. (Most) plugin coders want to hack DSP code,
> > and GUI designers usually don't know much about programming. Both
> > (to the extent that plugin coders care at all) still want their
> > GUIs to look way cool and support all sorts of custom widgets -
> > and they don't want to spend days or weeks trying to understand a
> > new toolkit, and hacking (messy) code for it.
> >
> >So what do we need?
> >
> >Well, basically this:
> >
> > * No restrictions!
> > * No learning curve!
> > * No code!
> > * Great results!
>
> I don't think that any of these are in the requirements set. The
> basic requirement is:
Maybe not.
Then again, Free/Open Source software in general isn't exactly known
for great user interfaces, and certainly not for chrome. I was just
guessing that the reason for that is that most hackers prefer hacking
*real* code to GUI code...
> * works with any host/plugin combination
Oops, forgot about that one. Or rather, I kind of took it for granted
after all discussion on the matter.
> I haven't heard of anyone who has a problem learning a new GUI if
> they have to. We've got people on this list who like GTK, FLTK, Qt
> and others. The problem is that choosing any of the available
> toolkits instantly makes the plugin/host incompatible with some
> desirable targets.
Well, that is next to impossible to fix, it seems. If I were to
create a Chrome Toolkit, it would be designed in a way that allows it
to be implemented on top of a "canvas" widget, or as a native widget
of any of those toolkits, or directly on top of X, SDL or whatever.
I have a few ideas for how to "run" the GUIs, and how to communicate
with them, none of which involve the traditional
event-loop-inside-toolkit approach.
> The problem isn't making chrome easy. It isn't the available
> widgets. Its the presence of an event loop that is incompatible
> with another toolkit. At least, thats the problem that I see and
> was referring to.
Yeah, I know. I was just losing focus while trying to cover too much
at the same time - as usual. ;-)
Anyway, *why* are people doing this "hidden event loop" thing over
and over again...? I've implemented several simple GUI toolkits for
various environments, and I haven't really seen a case where chosing
between that model and an "open" read_event() + process_event() style
interface is critical to the implementation. It's basically just a
matter of wrapping some parts of the loop up as API calls, and then
moving the loop into the application. I have yet to see a platform
where it's not possible to use either approach.
What do toolkit designers want to achieve by "stealing" the control
from the application? I believe a state machine can take care of any
of the "weird" stuff a hidden event loop might do, unless it's just
looping { read_event(); process_event() } - not that I can see what
that would be...
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
This archive was generated by hypermail 2b28 : Sat Mar 09 2002 - 17:16:09 EET