Subject: [linux-audio-dev] 'chromed' widgets [was Re: poll about linux music audio app usability]
From: Lance Blisters (geoff_AT_lek.ugcs.caltech.edu)
Date: Wed Jun 12 2002 - 17:53:16 EEST
This is how we build skins in gdam.
We have a number of pixmap-based gtk+ widgets:
gtkpixscrollbar - a slider where a 'handle' is drug along a 'trough'
appropriate for a volume slider or position indicator
gtkpixsplitbar - a slider which splits area between a 'background'
and 'foreground' pixmap, the value determines the
split point. good for volume meters
gtkpixbutton - a pixmap for each state - default, prelight, pressed,
etc.
gtkpixdial - a pixmap with an array of images; the image shown is
determined by the value. click on the dial and move
the mouse to change value. We use this for knobs,
jog wheels, etc
they can be seen in action here:
http://gdam.ffem.org/images/ladspafilters.jpeg
(chrome-looking skins bug me, mine are more playdough-looking
than photorealistic :)
all of the above are pure gtk+ widgets with no dependency on gdam.
code is here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gdam/gdam/skin/
also find gdamskin-pixwidgets.[ch] which contains the create_func
methods to tie these widgets into the glade graphical gtk+ gui builder.
i am quite happy using glade to lay out all my skins for gdam; by
default glade lets you tie signals to functions in your code by
entering signal/handler strings into glade dialog boxes. we register
our own function to process signal/handler string, which lets us
tie widgets directly into gdam's arg system (gdamskin.c). in glade i can
say "make this scrollbar control the left gain filter's 'volume'
arg over a range of 0.0 to 4.0 with logarithmic response curve"
or "when this button is control-clicked, take the current value of
'delay' and double it"
one current shortcoming of glade is that my custom widgets aren't loaded
and rendered at the layout stage. you can create them and assign bindings
using the "custom" widget type, but you have to load the skin in the app
to see how the pixmaps line up. however glade skins are just xml
files, and there is no recompiling required. so it is very easy
to run the app and glade side-by-side, after every change in glade
just relaunch the skin to see the effects.
in all, now that our skin and arg system is in place i find it
quick, easy, and downright fun to develop shiny new skins for gdam.
-geoff
> > 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...)
> >
>
> Actually, Instead of writing another GUI toolkit i think the best is
> to write widgets that would go well for audio programs in some
> existing widget set such as GTK.
>
> >
> >
> > > >We do have very powerful tools, but i have to admit that for most
> > > > of them we have to learn some script programming.
> > >
> > > Some people think this is a good thing because the tools are
> > > ultimately more capable and less limiting. Others disagree.
> >
> > I'd like both... Fiddle knobs and draw curves until you get the
> > basic sound, and then, if required, unscrew the chrome panels to
> > hack same more complex logic and/or math in. :-)
> >
> > Doesn't make things easier, does it?
> >
>
> Personally I'd rather move knobs than trying values. I write my apps
> usually in the userfriendly way becuse of this.
>
> Juan Linietsky
>
This archive was generated by hypermail 2b28 : Wed Jun 12 2002 - 17:45:46 EEST
