Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: David Olofson (david_AT_gardena.net)
Date: Sat Jun 22 2002 - 08:13:43 EEST
On Friday 21 June 2002 19.29, Vincent Touquet wrote:
[...]
> On Wed, Jun 19, 2002 at 11:20:20PM +0200, David Olofson wrote:
> >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.
>
> Lets put this on the table then :)
> Could you draw a class diagram
> or something to show us your model ?
Well, I'll try to explain the basic ideas.
First of all, we have a "canvas" object, quite similar to the
GnomeCanvas. It's basically a drawing area onto which you can place
visual objects, such as lines, circles, polygons, images and so on.
(The "image" part I'm thinking about might be different from that of
GnomeCanvas, though. I'm thinking along the OpenGL lines; textured
polygons - although there probably won't be any Z coordinates, and a
very simple transformation "matrix", if any.)
By mentioning the visual objects, I've already moved on to the layer
above the canvas. As opposed to any canvas I've seen so far, this
layer will also contain "logic objects" - objects that are invisible,
and serve as a physical "skeleton" behind the scenes.
The point with these "logic objects" is that you'll be able to
connect nodes (vertices) of visual objects to them in various ways.
For example, you'd connect the "center" node of a knob image to a
"logic line" in order to construct a slider. The "logic line" would
track and restrict the movement of the knob, so that the user can
drag the knob, and the application can move it by simply passing a
value to the "logic line". (That is, from the application POV, the
"logic line" object appears to be the actual widget.)
> >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. :-)
>
> Well, we could just skip this
> at first as premature optimization
> is the root of all evil :)
Yep.
> >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'... ;-)
> >
> :) you have a point.
>
> We have here a large based of knowledgeable
> coders though and a potential userbase.
> So involving LAD in this seems sensible enough.
Yeah - the idea is more or less to create a toolkit specifically for
*audio* appications.
> And hey, I'm interested.
> I hang around here, for the same
> reason as I hang around on other lists,
> to learn. I like to read the code.
> And I like to make code, even though
> I need some project that will tickle my mind.
> Such as this :)
Well, I'll try to get started before you get bored... ;-)
//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 - 17:24:26 EEST