Not thinking anymore this has a purpose since, as Marco said, there are more important things to do. And the API doesn't need to change in order for us to later change the FSVG.
But, here are the answers... for the record, and as a thought experiment :) > +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 So, the texture Marco mentioned. For me, a texture is in background, not an overlay. So, kinda misused most of the time. > 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). I know it is. Just listed it as an example of a feature that was invented to do something real in a hacky way that our way of theming wasn't really meant to do :) > 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. With this I agree. Nevertheless, that shouldn't mean (like it is now) that coders who do design well (two of them come to mind that are involved in this thread - btw, this is the reason I started it - http://www.notmart.org/index.php/Graphics/A_UX_manifesto,_universe_and_eve :D ) >> - 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 ... FrameSVG is a rectangle. Popup with a triangle is not :D (we talked about this some time ago - is it possible to make something like this by adding more power into FSVG, and we abandoned the idea since it would look quite ugly or underpowered) Maybe I could draw it at T6. > >> - differently presenting items (tasks for example) in panels that are >> vertical, horizontal, etc. > > not sure this is related to themes? Imagine a theme that tries to make a 3D dock (like some proprietary OSs do, a few people try this, and I was even sponsored to do it at one time... I felt dirty). So, the tasks background ought to be 3D as well (http://tipsfromgeek.com/wp-content/uploads/2010/03/cairo-dock.jpg). For the top panel, this 3D perspective would be *ugly*. So you want something different - create a different panel bg for the top... check... create a task bg that fits it - you can't. >> - 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. This is not about different backgrounds for different widgets (nor client-side window decorations :) ) - it is about making a consistently-looking theme that doesn't show all widgets as equals. Currently, we have translucent folder views, post-it looking notes as a special cases which don't break the consistency. For example - changing the border that is near to the edge of the screen, changing the 3d perspective based on the position of the widget to achieve a real 3D effect, or a real shadow etc. > 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. Agreed. > 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. +1 -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
