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

[Артем Попов <tfwo mail ru>]

...
> > > icons even for icons we already have).
> > >
> > ok... What do you think about redoing all icons in svg? (they can be
> > rendered in png at least until beast can handle them natively)
> 
> hm, that'd mean we can also throw them out in different sizes, right?
> i don't have much experience with svg, so, what (free software) tools
> do you use for editing?

inkscape (http://inkscape.org) and hand-creating+scripts. Inkscape's own
native format is svg with a namespace) itself. And yes, svg icons are
scalable for sure [particulary useful in zooming in/out the meshes :)]

> as long as you can produce a png file, basically everything is important,
> 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). 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.

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
	...
}



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...

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?

A fallback to the old way may be possible if there's no ui class for a
module (also allows gradual refactoring).

--Artem.