Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: David Olofson (david_AT_gardena.net)
Date: Thu Jun 20 2002 - 00:20:20 EEST
On Wednesday 12 June 2002 11.17, Vincent Touquet wrote:
> I have never done any GUI programming before.
>
> Writing these comprehensive widgets
> with cool knobs, smooth slides,
> graphical equalizers etc. seems
> difficult though.
GUI programming is not really difficult IMHO, but the difference
between the first estimation of development time and the time it
actually takes to hack is probably the bigger than for any other kind
of programming. It looks like it would be a fast and easy hack, as
everything's so visually "obvious" and intuitive, but that's just an
illusion...
> I think an effort should be undertaken to
> get a group of people to write these damn things :)
Yes, but how about motivation, and getting the right people to do
their best?
> I fear model-view-controller separation
> doesn't apply here, as we are entirely
> in the view realm.
I don't agree there. The major difference is probably that there's
much more "logic" inside the GUI part - not that there all of a
sudden is a good reason to mix things that don't belong together.
In fact, the separation between engine and UI is an absolute
*requirement* for real time audio/MIDI applications, as you simply
cannot make them work reliably if there are too many places where the
UI may interfere with the timing of the engine.
"Monolith GUI + modular engine" is a basic design idea that makes
sense here, IMHO. (A modular/plugin based GUI might work as well, but
then we're back in this "different toolkits won't mix" mess again...)
> So we are stuck basicly to implement
> these things for *all* the major toolkits,
> GTK, QT, etc.
Yes, but perhaps we can do something about that, as a part of
creating a VSTGUI style toolkit, more suitable for the kind of highly
interactive GUIs we need.
The design I have in mind could be implemented inside any toolkit
that provides access to the underlying "drawing toolkit" - or
directly on top of the rendering target or API (SDL, X, fbdev,
svgalib, GDI, DirectDraw, Direct3D/Graphics, OpenGL...), for that
matter.
The only truly required feature is a way of rendering rectangular
images into windows. All higher level stuff is just to allow certain
targets to use hardware acceleration for specific features - ie
performance hacks. (That is, stuff that optimization freaks can play
around with after the toolkit is implemented and working. :-)
If one can get away with designing such a toolkit that's actually
usable, any code that uses it will happily interact with any toolkit,
and it could also serve as a highly portable stand-alone toolkit.
[...]
Either way, the major issue here is not *how* we should go about
getting proper GUIs for more and larger Linux music application, but
how we should get anyone to do any serious GUI hacking *at all*.
There are a few exceptions, but the fact remains: The LAD community
consists mostly of *audio* hackers. (Makes sense, sorta'... ;-)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---------------------------> http://www.linuxdj.com/maia/ -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
This archive was generated by hypermail 2b28 : Fri Jun 21 2002 - 17:09:33 EEST