On Monday 04 March 2002 15.02, Paul Davis wrote:
[...]
> if you search the archives, i think you will find that defining a
> toolkit is pretty much a lost cause under Linux. i was all ready to
> implement the VSTGUI for Linux (via GTK), but the more i reflected
> upon it, no such solution will work for us, IMHO.
Is there a theoretical solution that could work, at least for *most*
of us, and if so, what would it be?
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!
Sounds ridiculous, of course, but at least in theory, it should be
possible to get a lot closer to that than most current GUI toolkits
can, even with the help of visual editors. Every single toolkit I've
seen so far - with or w/o visual editors - have been designed for
normal (boring) desktop applications, and are far from suitable for
flashy multimedia applications with lots of chrome. Practically all
toolkits need application code behind the scenes to do anything
useful.
Sure, there are scripting language bindings, but learing another
scripting language doesn't exactly fit with the "No learning curve!"
requirement - especially not for a GUI designer w/o programming
experience! There most probably *will* be a need for some sort of
scripting, or at the very least, expression evaluation, to do
anything useful, but I don't think throwing in any standard scripting
language, originally designed for other purposes, is going to help.
As to the actual toolkit, I don't believe in the traditional OO
model, with tons of different widgets for specific things; at least
not for the kind of GUIs we're talking about here. IMHO, it should be
based on a very small set of "building blocks", which can be used to
construct actual widgets. These "building blocks" will need more
advanced interaction capabilities than what's available in
traditional GUIs; more like the "objects" used in visual game
development tools and the like. (You basically add objects to the
world, tell them what to look like, what to do, and how to interact
with other objects. Very easy to use, and still quite powerful, even
without scripting.)
By coincidence, I'm playing around with closely related stuff (when
I'm not hacking audio code :-), and I'm starting to see parallels
between the way things work in games, and the way it *could* work in
a multimedia GUI toolkit. Besides, I already have a 2D graphics
engine, a simple extensible embeddable language (named "EEL") and
some other stuff, so fun toys may not be all that far away... :-)
Anyway, yeah, I'm nuts! It's a required qualification for dealing
with this kind of stuff. ;-)
//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 -'
