Amarok look

[Leo Franchi]

On Wed, Jul 16, 2008 at 12:36 PM, Nikolaj Hald Nielsen <
nhnfreespirit at gmail.com> wrote:

> > Firstly we are using svg's but we are rendering them the wrong way.
> > Every svg that has corners and is scaled in some way should be done in
> > several pieces and in a way that everything is scaled but the corners
> > or they loose their aspect and result in something not nice. Seems
> > like we are using svgs in a lot of places and are not doing it the
> > sane way.
>
> This is true for some svgs ( mainly the ones used in the playlist ),
> but at these only ever change their width, and not their height, 3
> parts to each should be enough. For many of our svgs, such as the ones
> used for sliders and volume control and such, we actually do have
> multiple parts ( again, as the height is fixed, we use 3 parts ).
>
> For the plasma applet background, we basically use ( except for the
> new black applets ) the standard plasma way of drawing backgrounds,
> and this actually correctly renders 9 different parts. If you look in
> the src/theme/context/Amarok-Mockup/widgtets/bckground.svg file, which
> is what is used as the background for most applets, you will notice
> that it actually contains 9 parts, even if it is just plain white. So
> the extremely poor caling of the new album applet is simply because it
> draws its own background and does not use a sane background theme ( I
> think it will look much better when all applets use a simmilar theme )

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.
The issue is that applet developers and artists have to be aware of this
fact. Maybe we should make it more clear?


>
>
> > Other problem is that by using monochromatic svg themes and then
> > tinting them doesn't work very well, apart that then artists are very
> > limited to create themes, themes won't be very well adapted to the
> > current desktop theme. By using svgs in a lot of places makes it very
> > difficult that the application looks integrated with the environment
> > since it's not only about colours but other things like button's
> > shapes for instance.

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.


>
> The use of svg file to theme Amarok is actually one of the things I
> personally really like about the app at this point, even though I
> accept that it does make some things more difficult. Amarok 2.0.0 is a
> bit of a testbed for us, so we will likely rethink many things when we
> start to figure out where to go next.
>
> Also, in the future, there is really no reason that we could not have
> a system that made it possible to tint svgs with the correct gradients
> based on their position within the app, if we know exactly what rules
> oxygen applies. In fact, this would fit quite nicely into the current
> svg tinting/caching system.

This would be pretty complex though :-/

>
> > And finally since we are using plasma for the context view, qt
> > graphics view framework for the playlist on the right and qt widgets
> > for the collection browser it results very difficulty to make the
> > application visually coherent and also very difficult for artists to
> > collaborate since they need to be working on three different things
> > that work different from each other.
>
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.

leo

-- 
______________________________________________________
Leo Franchi
7016 Wandering Oak lfranchi at kde.org
Austin leonardo.franchi at tufts.edu cell: (650) 704 3680
TX, USA home: (650) 329 0125
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20080716/f129cf6a/attachment.html