Re: [LAD] Phat and pyphat 0.4.1, help needed for future widgets.

Christian Schoenebeck schrieb:
> Es geschah am Monday, 14. May 2007 09:16 als Loki Davison schrieb:
>>> Loki, there are inaccuricies in the files as Inkscape isn't exactly
>>> a precision tool. Plus you need to rotate some parts and either move
>>> fills or do some masking. So I think the use of drawing operations
>>> is the way to go.
>> Can anyone else comment on this? Are svg widgets a good way to go or
>> pixmapped?
>
> What Thorsten tried to say is, that a .svg is usually* a static vector
> graphic. So when you just draw a .svg file in your GUI you just have a *dead*
> graphic, but at least a scalable one - in contrast to common pixmap based
> skins where you even get ugly artifacts just when trying to enlarge the
> pixmap.
>
> But in general you often also want to tweak parameters of the vector graphic
> at runtime by i.e. scaling only certain parts of the vector graphics,
> modifying colors or alpha (translucency) of certain parts of the vector
> graphic etc. So usually* you cannot do that with simply loading one
> single .svg file, or in other words there is always some coding involved to
> get dynamics into the vector graphics for your specific GUI application
> purpose. But that does NOT mean a vector graphic based approach for widgets
> is a bad solution or even not feasible. It just means you might have to
> realize some parts of the vector drawing directly in your code, but not in
> the classical form of "draw pixel at pos x,y", more like "draw circle /
> rectangle / Beziér curve .... with parameters foo ..... with 60%
> translucency ..... dashed border .... at pos x,y". So this is still on a
> higher, more abstract level, thus (usually) involves less coding effort and
> is especially easier / faster to create nice graphic results with.
>
> Of course doing all the vector graphics on code level is not a good idea,
> because often a good developer is not a good graphic artist and vice versa,
> and last but not least drawing graphics in a drawing application is far more
> faster than trying to "code" an image.
> But fortunately you don't have to do all vector graphics operations on code
> level. You could also i.e. simply load a normal .svg file as background
> graphic and do only few fancy dynamic vector graphics operations on code
> level.
>
> So IMO it would be a good idea to implement those proposed widgets using the
> vector graphics approach.
>
> CU
> Christian
>
> * ( the .svg format as defined by the w3c also allows to define animations [1]
> and interaction [2], but so far I don't know of any vector drawing
> application or vector graphics engine that supports that ... at least AFAIK)
>
> [1] http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html
> [2] http://www.w3.org/TR/2003/REC-SVG11-20030114/interact.html
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
>
btw

I had some progress with implementing the widgets from thorstens site.
Stopping the knob flipping from min to max works.
Start and stop are configurable by defines. With a big step width you
get kind of a switch.

Anyone interested, tell me.

Uli
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Received on Tue May 15 00:15:02 2007