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 > [email protected] > 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
