<div dir="ltr">On Wed, Jul 16, 2008 at 12:36 PM, Nikolaj Hald Nielsen <<a href="mailto:nhnfreespirit@gmail.com" target="_blank">nhnfreespirit@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> Firstly we are using svg's but we are rendering them the wrong way.<br>
> Every svg that has corners and is scaled in some way should be done in<br>
> several pieces and in a way that everything is scaled but the corners<br>
> or they loose their aspect and result in something not nice. Seems<br>
> like we are using svgs in a lot of places and are not doing it the<br>
> sane way.<br>
<br>
</div>This is true for some svgs ( mainly the ones used in the playlist ),<br>
but at these only ever change their width, and not their height, 3<br>
parts to each should be enough. For many of our svgs, such as the ones<br>
used for sliders and volume control and such, we actually do have<br>
multiple parts ( again, as the height is fixed, we use 3 parts ).<br>
<br>
For the plasma applet background, we basically use ( except for the<br>
new black applets ) the standard plasma way of drawing backgrounds,<br>
and this actually correctly renders 9 different parts. If you look in<br>
the src/theme/context/Amarok-Mockup/widgtets/bckground.svg file, which<br>
is what is used as the background for most applets, you will notice<br>
that it actually contains 9 parts, even if it is just plain white. So<br>
the extremely poor caling of the new album applet is simply because it<br>
draws its own background and does not use a sane background theme ( I<br>
think it will look much better when all applets use a simmilar theme )</blockquote><div>This will not be a problem for the CV, as nikolaj mentioned. It is not a matter of architecture (or lack thereof), but rather of the individual SVGs that exist for some of the applets---like the Current Track one. So artists can create the 9-part scaling friendly background and the CV will (through plasma) render it correctly. </div>
<div></div>
<div>The issue is that applet developers and artists have to be aware of this fact. Maybe we should make it more clear? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> Other problem is that by using monochromatic svg themes and then<br>
> tinting them doesn't work very well, apart that then artists are very<br>
> limited to create themes, themes won't be very well adapted to the<br>
> current desktop theme. By using svgs in a lot of places makes it very<br>
> difficult that the application looks integrated with the environment<br>
> since it's not only about colours but other things like button's<br>
> shapes for instance.</blockquote><div></div><div>On the other hand, for the great majority of users tinting to match the color scheme does work pretty well IMHO. I'm not saying this is why we should do it this way, but i just want to make the point that i think plenty of people would be happy if Amarok matched their color scheme, but the button corners were the wrong sort of ellipse. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The use of svg file to theme Amarok is actually one of the things I<br>
personally really like about the app at this point, even though I<br>
accept that it does make some things more difficult. Amarok 2.0.0 is a<br>
bit of a testbed for us, so we will likely rethink many things when we<br>
start to figure out where to go next.<br>
<br>
Also, in the future, there is really no reason that we could not have<br>
a system that made it possible to tint svgs with the correct gradients<br>
based on their position within the app, if we know exactly what rules<br>
oxygen applies. In fact, this would fit quite nicely into the current<br>
svg tinting/caching system.</blockquote><div></div><div>This would be pretty complex though :-/ </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> And finally since we are using plasma for the context view, qt<br>
> graphics view framework for the playlist on the right and qt widgets<br>
> for the collection browser it results very difficulty to make the<br>
> application visually coherent and also very difficult for artists to<br>
> collaborate since they need to be working on three different things<br>
> that work different from each other.<br>
</blockquote><div></div><div>I think it is more than that--- the header, the CV, and the playlist are all using SVGs to theme themselves. So an artist can control all of that simply with SVGs. Yes, the left tab is native Qt---this can pose a problem in how it fits with the res of it. I don't really have a good answer here, other than to say that the Qt widgets can be modified with CSS (which is pretty hacky). But having 2 independently themes things, instead of 3, does make a difference.</div>
<div> </div><div>leo</div><br>-- <br>______________________________________________________<br>Leo Franchi <br>7016 Wandering Oak <a href="mailto:lfranchi@kde.org" target="_blank">lfranchi@kde.org</a><br>Austin <a href="mailto:leonardo.franchi@tufts.edu" target="_blank">leonardo.franchi@tufts.edu</a> cell: (650) 704 3680<br>
TX, USA home: (650) 329 0125<br>
</div>