Wanted: theme manager

[Aaron J. Seigo]

On Friday 21 March 2008, Matthew Woehlke wrote:
> Aaron J. Seigo wrote:
> > On Friday 21 March 2008, Matthew Woehlke wrote:
> >> (I would say, rather, the default theme
> >> should be obviously configurable, where by "configurable" I mean
> >> consists of a sane set of fully-customizable colors. It looks like at
> >> most four are needed.)
> >
> > no, the default does not need to be colour customizable. that is why we
> > provide the ability to *switch themes*.
>
> We do? Oh... ok, it's under 'configure desktop'? And not /anywhere/
> under System Settings... um...

nope, not under system settings. to answer the implied, "why not?" it's 
because that dialog is speciic to the DefaultDesktop containment, not generic 
to plasma. the idea is to work towards the generic version we envision and 
push that out as a kcm only then.

> Incidentally, I tried "heron"... really bad flickering :-(.

during the update? or forever? or?

> And my menu  seems to have gotten lost.

neat.

> > having "must be colourizable" as a
> > requirement for the default really removes much of the benefit of such a
> > highly themable system.
>
> I still think such a theme should /ship with plasma/ (i.e. kdebase).

extragear is "with plasma". we release it along side kde releases.

> Anyway, what is this 'follows the system colors' theme I hear about? I
> don't seem to have found it yet. What's a theme that supposedly does this??

Aya

> > no, the default does not need to be colour customizable. that is why we
> > provide the ability to *switch themes*.
>
> Why *shouldn't* it be, at least the current default theme? As I said, I
> see at most four colors being used. I don't see why it would be so hard
> to make those configurable, i.e. make the current default theme
> customizable.

you're asking the wrong person. i'm the messenger here, the artist is the 
author.

> > i can't find them atm, but will be sure to do so in the future.
> > essentially, all of our dark colour schemes seem to give people problems
> > when painting dark() text on a base() background.
>
> Ahh... why is this being done? 'Dark' really isn't meant as a text role
> (it's meant to for "dark" edges of 3d elements), especially when there
> are eight "actual" text roles to choose from. This feels like a case
> where you rather want to either use 'Inactive' or paint the normal text
> color at 50% opacity.

the text is not inactive, however, and i'm concerned that painting it as such 
will send incorrect visual cues and look poorly with yet other colour themes. 
50% opacity might work ... 

but honestly, i was just plain surprised that palettes aren't treated more 
semantically. in any case, the docu then need to adjustment (which would 
probably screw over others).

e.g., BrightText is documented as: "A text color that is very different from 
WindowText, and contrasts well with e.g. Dark. Typically used for text that 
needs to be drawn where Text or WindowText would give poor contrast, such as 
on pressed push buttons. Note that text colors can be used for things other 
than just words; text colors are usually used for text, but it's quite common 
to use the text color roles for lines, icons, etc."

doesn't sound like the "dark edges of a 3d element" to me.

and Dark itself is labelled simply: "Darker than Button"

i guess we could move to KColorScheme for greater variety in choices...

i still contend that our palette definitions in Qt are very circumspect.

> >> Hmm, *something* that looks like a theme manager seems to be in
> >> systemsettings...
> >
> > it's a collection of the individual control panels. that's great for
> > tweakers, but it provies no coordination whatsoever between style, deco,
> > colour etc.
>
> Are we looking at the same thing? 

nope =)

> I'm looking at "theme manager", which 
> sure looks like it sets fonts, colors, widget style, icon theme, and
> even screensaver (I'm a bit dubious on that last one, actually...).

ah, there it is.. nestled in the middle of 6 other items =/ hrm. it seems 
rather broken, but yes .. that's edging at least a bit closer ... but sort of 
the "other way" around:

these themes are arbitrary collections of colours and various theme plugins to 
make a nice harmonized set (in theory anyways =).

what i'm suggesting is letting styles themselves hint what colour schemes work 
well with them, for instance. so you don't have to rely on someone else 
putting together an ad hoc collection (and hoping that the "right set" is put 
together), but that conversely you aren't confronted with lots of useless 
options (e.g. colour schemes that simply Don't Work(tm) with a given theme, 
or non-Oxygen widget styles for the Oxygen window decoration)

-- 
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/20080321/a8eaa505/attachment.pgp