KDE Opportunities

[pinheiro]

A Thursday 13 March 2008 00:37:20, Aaron J. Seigo escreveu:
> (no, i'm not going to cross post to three lists =)
>
> On Wednesday 12 March 2008, Matthew Woehlke wrote:
> > I'm pretty sure you're not the first to complain about plasma's coloring
> > and how it's out-of-place with the rest of the desktop.
>
> oddly enough this is the work of the oxygen artists.
>
> > What probably
> > needs to happen (assuming the colors can be changed; if not, this needs
> > to be a major priority!)
>
> well, let's try and keep some perspective on the problem.
>
> > is integration with the color kcm, the same way
> > WM colors tag along despite being not part of the application (i.e.
> > QPalette) palette.
> >
> > As the maintainer of the color kcm, that probably means I'll be doing
> > some of the needed coding. What's been done already on the plasma side?
>
> there are two things:
>
> a) svg themes
> b) optional colourization of svg's designed for that
> c) svg theme specific kcolorscheme files
>
> (b) might be able to be done better: right now it does post-rendering
> colouraization of the resulting bitmap. it would probably be nicer to do
> replacements in the svg data itself, but .. yeah .. this works for now.
>
> and yes, (b) responds to desktop colour scheme changes.
> no the default theme is not colourizable. it might be if we either replaced
> it with something else or (b) were improved.
>
>
>
> there's a deeper challenge here, though, and i'll go on for a bit about it
> though it's not strictly on-topic for this thread:
>
> personally, i think it's a real shame that we have a multiple theming and
> colouring systems and then try and sync them all together. i think it's
> really suboptimal to have no conversation between themes and colour
> schemes, for instance. having them as two completely separate system and
> expecting them to just work together ignores some basic artwork facts, such
> as "not all possible themes work nicely with all possible colour schemes".
> this is not because the theme is 'obviously buggy' but simply because not
> all gradients, not all shapes and not all combinations of rendering
> possibilities will work with the same stock palette colours equally well.
>
> this is compounded by the fact that our palettes are treated as if they are
> both semantic ("base") and literal ("dark") making it pretty well
> impossible to consistently use the palette without working around the fact
> that "dark" actually contrasts with "base" but only some of the time (e.g.
> often not with "dark" colour schemes).
>
> i think what makes the *most* sense long term is to tie colour schemes and
> widget styles together. i think it's fine to let any colour scheme and any
> style be "forced" together, but it should be made clear in the dialogs
> which go together.
>
> in fact, i'd go so far as to suggest that the style kcm ought to take care
> of general colour scheme setting and the colour scheme kcm be used by those
> who would like to tweak said schemes or set an "untested" pairing of scheme
> and style.
>
> and yes, there are styles which can use any colour scheme, and that
> wouldn't pose a problem with this system.
>
> moreover, i think we ought to include svg data that can be used by, e.g.
> plasma, along with styles. that way style authors can create entire L&F
> packs that can easily be set with one click.
>
> imho it really comes down to us exposing all the implementation details to
> the user (widget styles are a type of C++ plugin, colorschemes are stored
> in a separate file, window manager styles are another type of C++ plugin
> and desktop themes are a pack of svgs... so go to four different places,
> please!)
>
> and let's not even talk about cursor themes, sounds, wallpapers ...
>
> it would be great if we had a simple, unified system that drew all these
> separate pieces into one place.
>
> the detail level kcms could go into their own "app" (a system settings with
> a different set of kcms?) called Desktop Visual Tweaker or something
> equally exciting.
>
> > (Can someone remind me what I need to run to get plasma stuffs in a
> > Xephyr window?)
>
> just launch a kde4 session? or start a xephyr session and run "plasma"? or
> you could just run plasmoidviewer $SOME_APPLET and see the colours of the
> theme as used by the applet.
>
> > I don't watch panel-devel; please CC me on any replies not also sent to
> > k-c-d and/or kde-u7y. (How come panel-devel isn't listed at
> > http://kde.org/mailinglists/?)
>
> dunno. *shrug*

well bffffff... wen I was thinking plasma decorations i wanted to meke them 
reverse form the wiindow decorations, couse in essence plasmoids are very 
difrent from a normal window,,,

About theming plasmoids..... i never ment for all plasmoids to look alike I 
think a nice set of similar plasmoids would be nice but all of them look the 
same no... Think that kde-look will provide more plasmoids than the ones we 
can bare to look at in a short periud o time... and like superkaramba some 
will fit a style other another and people will chose what they like best...

Making them themable is also not a vey good idea IMO, they are really and they 
are extremly themable  just that you have to edit the svg.And in doing so 
create a new plasmoid. But creating a engine that can change them all at the 
same time is a path to visual disarter. And a much more complex plasma, that 
cuts alot of creative fredom from the artists/codors ... 

Matthew you know how hard it is to make a theme that looks nice in lots of 
color variations and we have a very limited set of widgets, imagine that 
multiplied by infinity cuse thats all you can do in an svg hardtimes infinity 
makes it prety imposible, unless you trim infinite, and that is far worst IMO

-- 

core oxygen icon designer