Fwd: Amarok look

[pinheiro]

A Thursday 17 July 2008 09:56:31, você escreveu:
> ---------- Forwarded message ----------
> From: Leo Franchi <lfranchi at gmail.com>
> Date: Wed, Jul 16, 2008 at 7:35 PM
> Subject: Re: Amarok look
> To: amarok-devel at kde.org
> Cc: nuno at oxygen-icons.com
>

All I want is that yu guys are aware of the problems, and are ok with it....
Each solution has its hown set of problems/advantages.



> 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 ).

might as well use 9 for flexibility no??? From a artist point of view the 
amout of work is similar...

> > 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 )

somthing to be fixed there 2...(the corners are also bad)


> 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.

well but you should be aware it will NEVER look great decoration wise they are 
all very difrent, just compare osx to vista to plastic to oxygen... the main 
problem is that you will allways have a qt window around it so people espect 
it to look like the qt window.
aslo be aware  that many themes are not rely monocromatic dependent this meens 
they use atcual difrent colors in difrent points of the theme. so all we can 
do is mostly a monocomatic tinted version of it. and heven that is not 
trivila to do....

example... plastic makes the hover efct on butons by adjusting the gradient of 
the buton.. oxygen does that and reimplements the shadow to glow around the 
buton, vista does theyir hown thing and osx as well. If some one would hask 
me to kinda program all those difrences into a svg i would have no idea how 
to...

again somthing you should ba aware, its a limitation of the svg way.  

> > 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.

Dont get me wrong I loooooooooove svg been using it for the past 5 years bt 
dont ask of svg what svg cant do, Svg/plasma have to potential to be way more 
flexible than qtstyle is or hever will be, we are implementing things in 
plasma that would be near impossible in qtstyle.

But dont espect that svg will adapt to qtstyle couse it wont. Im having an 
hard time as his to make plasma (defoult) theme look more coerent with the 
oxygen widget theme and this is just a single case...  

> > 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 :-/

extremly.... for plastic the gradient stops are totaly diferent from oxygen 
this meens actualy changing the svg code, on the fly by software. And svg 
code is realy messy.

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

as a kinda resume svg themeing gives you alot of fredom but also alot of 
problems if you chose that path you will ever have a consystency with the qt 
window arround it ... 

some times i say in plasma just for fun ... plasma should replace kwin, and 
its  a bit of the prblems you guys have you have a rather free styley inside 
a very fixed style window , people expect consytency and that is a bit more 
than color consystency.

I can make amarok look prety decent on defoult kde 4.1 but f people use amarok 
in windows, osx or change the witdget theme in kde it wont look coerent, 
never will. are you guys ok with that???


> ______________________________________________________
> 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
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel



-- 

core oxygen icon designer