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

[audio-mobster]

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 at lists.linuxaudio.org
> 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