Re: [linux-audio-dev] Poll about linux music audio app usability

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: David Olofson (david_AT_gardena.net)
Date: Wed Jun 12 2002 - 04:17:47 EEST


On Tuesday 11 June 2002 12.29, Alexander Ehlert wrote:
> > That's basically why I think inventing Yet Another, Although Much
> > Cooler Looking GUI Toolkit would be worth the effort, if it could
> > help cutting GUI development time without dropping chrome and/or
> > features. (Whether or not it's possibly is another issue. Guess
> > I'll just have to try it...)
>
> Oh no, please not. Not another GUI toolkit... Better waste your
> time writing
> some kewl wave editor/display widgets with a good API for qt or
> gtk.

Maybe - but what would be the point? I'm not a supernatural
programming genious, and I can't spend 12+ hours a day hacking, so
why would my GTK+/Qt/WhateverTk be any more successful than the other
sequencer projects? I don't think betting on the same concept *again*
sounds like a great idea. It's still seems to be failing, and despite
the increasing interest in Linux, I don't see countless hackers
coming this way to help.

There are a bunch of sequencer projects already, but the complexity
of such an application seems to be a major issue, since most of the
projects seem to be failing to produce anything like Cubase, Cakewalk
or Logic. I've written this kind of code before, and my experience
only confirms the 80/20 (or 90/10) rule; nearly *all* development
time is spent getting seemingly trivial GUI stuff to work properly.

As to toolkits, the most useful widget usually turns out to be the
basic "canvas", on top of which you implement your own custom widgets.

For example, you can't really use a normal toolkit to construct a
clip oriented "song view". What you do is just implement it from the
drawing and blitting level and up, on top of some very basic "widget".

The way I'd like to do it is by throwing "live" objects into the
canvas, assign various graphic shapes or images to them, and then
connect them to the logic through callbacks, events or whatever. The
point is that "basic" stuff like catching clicks, handle dragging,
control Z order etc, should be handled by the *toolkit*; not
application code or custom widgets.

//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 -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jun 12 2002 - 04:16:47 EEST