On Monday, June 4, 2012 20:51:31 Ivan Cukic wrote: > - non-stretch borders or center > is there any important theme really using this?
i think one or two themes are ... but we could just settle on or the other and say "that's how it is now" > - mask > ok, this serves some purpose - defines the mask for blur and overlay > (see next item) > > - overlay > introduced for a single purpose - to show circles in the Air theme. > Later, to show rectangles. Now not used by the theme it was designed for at > all. I do use it in one of mine, but I'm still for dropping it. +1 .. overlay was a neat idea, but i agree that it could be removed with the following provisions: * we document what we learned from the experiment * if we bring it back, we do it better > - applying colour scheme > introduced for Aya so that it can emulate the application style. no, this is still often requested. it could be implemented in a better way (in fact, when we go all-singing-and-dancing-opengl-with-shaders, we can definitely do it better). > - background as one element with borders on top > (this is one of my favourite features and will hurt anyone who > removes it :) ) :) > So, IMO, some of these are consequences of wanting to do a lot of features > without doing programmable theme engines. Now that QML will be in the > background, most of them could be done in a different way. agreed; there are other options open for us .. but i am still dead set against anything involving designers needing to include snippets of code. it must be a 100% visual process, and it must use tools artists are familiar with as much as possible. > We have issues that aren't a direct consequence of FSVG, but fixing them > would make it a lot more complicated, and tailored to special cases. > > - visually connecting the popups with the applets > example: http://kde-look.org/CONTENT/content-pre1/53086-1.png > or a 'triangle' pointing to the applet or anything else that people can > devise > (yeah, this is my main issue) i don't see the connection, tbh :) educate me ... > - differently presenting items (tasks for example) in panels that are > vertical, horizontal, etc. not sure this is related to themes? > - (just so that Aaron has a reason to kill me) custom rotating animations on > task hover and similar :) > > - setting different coloured backgrounds for different applets neither of these things will ever be supported for reasons that were beaten to death 2+ years ago now. > > > The issue with the current usage of it (and we are all to blame for > > > this one - it *is* a nice tool that covers a lot of use-cases) is that > > > it exists as a first class citizen - if you just want a simple > > > round-corner rectangle painted, you still need to use svgs. (iirc, > > > > * where is that written? > > What do you mean? It is not written that coders need to use FSVG, but if you > are a theme maker, you can't just say "i want a simple rectangle for the > background of an applet", you need to make a 9-element svg. ah, you mean for artists.. yes, this is not efficient, and a matter of tooling rather than the implementation. coders don't write in assembler either anymore. > > * what are the real performance issues with this? (as in: has anyone > > measured? i did a bunch of measurement a couple years ago so that we got > > to > > the current acceptable point...) > > The official issue *was* (don't know how relevant it still is - needs to be > checked) that amarok started slower because of plasma theming. i would definitely want to see #s. not only did amarok do all sorts of wild and interesting things with libplasma, theming performance improved considerably over time. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel