Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: David Olofson (david_AT_gardena.net)
Date: Fri Jun 21 2002 - 17:59:39 EEST
On Friday 21 June 2002 16.05, Vincent Touquet wrote:
[...]
> >It's like replacing the graphics of a game; drawing a bunch of
> > images for each object, whereas normal ("GTK+ style" themes
> > consist of generic textures and images used by all widgets.
>
> Thats exactly what I'm aiming at :)
> I didn't mean themeability in the themes.org sense of the word.
Ok; then we're thinking along the same lines, basically. :-)
> Just an abstraction of functionality:
> - sliderbars
> - rotational knobs from 1-10
> - rotational knobs without beginning and end
> ...
Yes... Although I'm trying to figure out a way to design a slightly
lower level abstraction, where it's more like assembling a very small
set of logic building blocks into widgets.
For example, a slider bar would be a draggable object tied to a
"path" object, that restricts it's movement. A rotational knob would
be an object pinned to the background with a single point "patch"
that restricts movement to nothing, but allows rotation.
> Just how far you can go, I don't know.
Same here - but I think you can do a great deal with a sensible
design. If you can create a whole game (well, not another Q3A, but
anyway) without hacking a single line of code, one would assume that
visual GUI building could be slightly more powerful than the Delphi
or Visual Basic variants. (BTW, Delphi isn't that far off - if you're
into databases... The actual GUI toolkit is still rather "stupid" and
restrictive, though.)
> Someone mentioned that the xmms coding style was
> to be avoided.
Actually, I have to agree, although it's not as simple as "XMMS is
bad". There are two parts; the GUI and the window management. XMMS
messes with *both*, for no good reason, and it doesn't even result in
a good user interface. The bypassing of the window manager is just
stupid and pointless in this case, and has XMMS integrate poorly no
matter what desktop you're using. It doesn't provide anything of use,
but it *does* disable most of the nifty features of your favourite WM.
There are applications that should preferably use their own internal
WM - in some cases, maybe even a whole desktop enviroment, but they
are few, and your average media player (which is just supposed to
play music while you're hacking :-) is *not* one of them.
> I was thinking about some callback model:
> you provide the callback to redraw your
> knob after you changed the parameters.
That's one way, and I definitely think there should be hooks like
that.
However, I think about 95% of the work can be done by the toolkit,
without any application code at all. This goes for the interaction
between "logic objects" as well, but I actually think the rendering
is the *easy* part in this regard.
If you have a rendering library with the usual shapes, images,
textures etc, the actual rendering is just a matter of passing it a
list of operations with arguments. (Heard of OpenGL display lists...?)
Throw in some very basic flow control (iterators, simple conditionals
etc), and you have a simple "scripting language" for which code can
easilly be generated by something like a structured drawing program.
You just draw your GUI as a structured image, and then you select
visual objects and connect them to logic objects in various ways to
make the GUI dynamic and interactive.
> This way you could plug the functionality
> of the knobs etc. in your program,
In my design, you'd "ask" certain logic objects about some of their
properties. (In the slider example; "Knob, where on the path object
are you now?" or "Knob, tell me where on the path object you are
whenever you're dragged.")
> just
> by providing the graphics and using
> the toolkit you want...
Yes. Provide some data generated by that "dynamic structured
graphics" (DSG :-) drawing program I'm talking about, and there's not
much code left for you to hack WRT the GUI. And anyone can grab your
DSG data and start fiddling around with the objects in the editor,
pretty much like you can fiddle around with the data of a game.
Oh, and it should be possible to implement this on top of any toolkit
that supports basic "drawing area" widgets. (I plan to do it for SDL,
OpenGL, GTK+ - and possibly Borland's VCL, if I'm bored some day.)
> Obviously I must have missed all the difficult parts ;)
Well, any design takes at least three times as long to implement as
you could possbly imagine - if it works out at all, that is.
So, check back in a few years, and I might have something to demo! ;-)
//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 : Sat Jun 22 2002 - 07:31:06 EEST