Re: svg and some ui ideas (was: Re: new icons [attached this time])

[Tim Janik <timj gtk org>]

On Wed, 8 Sep 2004, [iso-8859-5] °àâÕÜ ¿ÞßÞÒ wrote:

> > as long as you can produce a png file, basically everything is important,

eek, s/important/usable/

> > even povray (and we'll definitely not supprot that natively ;) so if
> > you want to produce svg files, go ahead.
>
> povray graphics natively, NOW THAT'S AN IDEA but not for beast, for the
> whole desktop! :)) lol

> > btw, i have been pondering for some while and stefan also has been nagging me,
> > about cooking up new dial, knob, scale and slider/fader widgets that support
> > scaled pixmaps.
> > that'll take some time to code though, but then still, we need decent pixmaps
> > to render those widgets (and we're both third-class artists ;), so if you are
> > interested in helping out on the pixmap side of this, i'll try to cook up a
> > proposal in the next few weeks on the image and coordinate format, so we can
> > toss around ideas on producing fancier faders and other widgets.
>
> I think widgets must be drawn programmatically, as they should not be
> graphics intensive (also usability in mind).

that doesn't give you the looks provided by most professional music
applications though, for instance, take a look at the different skins in:

	http://www.gtk.org/~timj/q10skins.gif

apart from that, gtk+ doesn't even have:
- knobs
- dial widgets (beast comes with a pumped up version of the gtk tutorial one)

using pixmaps doesn't need to decrease usability, that is, once you
managed to keep functionality like resizing working despite using pixmaps.
(of course, it's ok if you don't want to help out with this)

> What would be nice by the
> way is the possibility to create per-module interface dialog. So the
> ADSR can have vertical sliders, oscillator can have the knobs layed out
> in a table, etc. I think it's impossible to construct such a gui
> automatically in practice, so an ui constructor implementation is
> required.

beast already has such a GUI editor. it's just so experimental at the
moment (the rack editor), that the code is currently disabled.

> However, this could be simplified to the ground if the ui dialog code
> would have an implementation of automatic binding of controls to
> properties. So the code may look like this:
>
> void
> construct_ui ()
> {
> 	...
> 	knob1 = knob_new (<bse_object_property>);
>
> 	or even better:
>
> 	knob1 = knob_new (min, max, etc.);
> 	knob_bind_to_bse_property (<bse_object_property>);
> 	// should also track property changes not only set them
> 	...
> }

the rack editor is supposed to provide that, just GUI editable without
the need to write code. that's because you will want to create such
GUIs for entire networks, and musicians can't be bothered to write code
for that.


> something like this... The ui constructor creates persistent window of
> course, beast simply shows and hides it later. BUT a problem arises
> here: bse becomes gtk dependent... a way to split module ui from module
> is required... a ladspa[-like] xml gui description, thing to figure
> out...

bse won't become gtk or even toolkit dependant at all. the GUIs created
by the rack editor are stored with BSE obejct as a list of serialized
properties again, so they also can be saved in BSE files and later
edited. (that is, once the code is complete, some older versions of
beast have an older rack editor version enabled, and support a preliminary
version of this.)


> Another approach might be the introduction of per-module module_ui
> classes. This has an advantage of more precise control->property
> relationship management with signals, etc. suitable for complex widgets
> like curve from the compressor discussion, the ADSR widget (useless, but
> is a good example)... Could this allow creation of a visual scope
> module?

the per-module classes are not neccessary once the rack editor is finished.

scopes are a different issue though, i've yet to design an scope interface for
GUI plugins (non-BSE, toolkit specific).

>
> --Artem.
>

---
ciaoTJ