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

Christian Schoenebeck cuse at users.sourceforge.net
Mon May 14 16:03:32 UTC 2007

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 

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 

So IMO it would be a good idea to implement those proposed widgets using the 
vector graphics approach.


* ( 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

More information about the Linux-audio-dev mailing list