Subject: Re: [linux-audio-dev] Poll about linux music audio app usability
From: Paul Davis (pbd_AT_op.net)
Date: Wed Jun 12 2002 - 15:40:35 EEST
>Paul: didn't you write some sort of a GUI
>widget for Ardour ?
>What do you think about this ?
gtkmmext contains several relevant widgets, the most relevant of which
is Gtkmmext::MotionFeedback. this takes a set of pixmaps, a
Gtk::Adjustment and a few other arguments, and uses the set of pixmaps
to display the current value of the adjustment. Mouse motion initiated
by a click on the widget can be used to alter the value of the
adjustment, which in turn affects the pixmap displayed. It doesn't
care how many pixmaps are involved, what the value ranges are etc. It
also has an option to display the numeric value of the adjustment in
addition to the pixmaps.
I also made a GTK+ widget from GLAME more general purpose, the
GtkPixScrollbar, which takes two pixmaps, and slides one over the
other. It figures out whether they should be horizontal or vertical
from their aspect ratios. I think this may have been fed back into
GLAME, but its also gtkmmext.
Based on this, there is Gtkmmext::SliderController which comes with
builtin MIDI control capabilities. This is a hard one, because its
mostly a GUI widget, but it has to know about MIDI, which means it
really belongs in a library all by itself. Right now, its still in
gtkmmext, but uses libmidi++. The inheritance tree looks like:
Gtkmmext::[VH]SliderController HAS-A PixScrollbar and IS-A
Gtkmmext::SliderController IS-A
Gtkmmext::Controller IS-A
MIDI++::Controllable IS-A
I think I planned to put a MIDI-controlled version of MotionFeedback
in there at some point, but I don't seem to have done that yet.
There is also GtkLevelHold, and its counterpart Gtkmmext::LevelHold,
which is mostly written by Eric Tiedemann, and is the level meters you
see in screenshots of Ardour. It needs rewriting as a Canvas item,
IMHO. There is also GtkMarkedCurve/Gtkmmext::MarkedCurve, which I used
to use in Quasimodo for envelope editing, Gtkmmext::HexEntry which I
use for manual entering of hexadecimal data such as raw MIDI bytes and
a few others.
For Ardour, most of the custom "widget" work has been Canvas items,
which include:
canvas-waveview: takes a generic object that can fetch raw+peak
data for a mono waveform and renders it
directly to the canvas RGB buffer,
caching chunks of it for fast updates.
loosely modelled on GtkWaveView by David
Bartold, but drastically altered to use
externally computed peak data and to
render directly to RGB. Extremely,
extremely fast and efficient (assuming
access to the underlying data is quick)
canvas-simple{rect,line}: extremely efficient drawing of
rectangles and lines into the canvas
RGB buffer
The {Gtk,Gnome}Canvas is a thing of beauty and people should get to
know it and probably its Qt counterparts well.
But I've said before that the wave display stuff is the hardest to
generalize. How it works depends a lot on the basic design of the
application using it. GtkWaveView, for all of its elegant design,
didn't work for me because it was based on a model of an editor like
snd, or audacity or sweep. Its likely that you would not be able to
use the GtkCanvasWaveView item for such an editor without modifying it
in ways that I haven't thought of. In addition, there is a big
difference between the basic model of a CanvasItem and a widget, and
although a simple description of each would sound similar, they are
not really interchangeable (which is a shame). There are rumblings in
the GTK+ camp that a distant version of GTK+ might switch entirely
to the canvas model, and all widgets would just be canvas items that
drew themselves onto the canvas RGB buffer. But this is a long way
off, if in fact it ever happens. The end result for now is that you
can't mix-n-match CanvasItems with widgets, and I suspect this is true
for Qt and other toolkits as well.
--p
This archive was generated by hypermail 2b28 : Wed Jun 12 2002 - 15:30:17 EEST