KDE Opportunities

[Aaron J. Seigo]

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

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080312/2a33fd12/attachment-0001.pgp