User:Chani/WayOfThePlasma/Categories/Theming

Will there be other themes included with plasma?

Conclusion

Yes, the plan is to have around 3-5 nice, high-quality themes included with plasma. They will go in extragear in order to keep the size of kdebase/workspace down.

There is now a contest underway to get artists to contribute themes.

Original Text

Andrew Lake

Is there any desire to include a few plasma themes like we did with wallpapers and colorschemes? (Yeah

Aaron Seigo

absolutely. besides being nice for the users, this will help the developers keep on our eyes on variances in themes to make sure we don't break anythign too, too much ;)

i'd like to see these go into extragear, though, to keep workspace/smallish, under the same "essentials in workspace/, other stuff in extragear".

perhaps 3-5 nice themes would be a good target to aim for. your Aya theme is quite nice; i really like Ivan's theme as well .. *thinks* would you be willing to take on the task of looking for and selecting quality plasma themes for inclusion in extragear? (you don't have to, of course, it's just a question ... you seem to have an interest in this and an eye for it, though)

Sources

pannel-devel archive (2008-03)

Contest announcement thread on panel-devel

Contest announcement on the dot

Search for "(for theme contest)" in the plasma themes category on kde-look.org for entries (kde-look's search uses post, so no link, sorry).

Which fonts does Plasma use?

Conclusion

Plasma needs a set of fonts defined within libplasma for its various unique uses. But this is not implemented yet.

Original Text

Sebastian Kuegler

Right now, Plasma::Widget::font() returns QApplication::font(), so it ignores KGlobalSettings, and especially the settings from it that would be relevant to Plasma: desktopFont() and taskbarFont().

Aaron Seigo

probably what we need is:

• a set of fonts defined within libplasma for various uses. right now we have just the one, but going through the various use cases and picking out a set of font use cases probably makes sense. (more on that in a bit)

• a way for the application to set the fonts. probably via defaults that fall back to QApplication::font() but which read from the application's configuration file (plasmarc for plasma). this is similar to how we handle the SVG theming as well.

so ... font sets... use cases that spring to mind:

• default clock fonts
• taskbar font
• desktop widget font (akin to QApplication::font() really)
• small widget font (e.g. for use in the pager to put numbers/names there)
• ALI font? (does it make sense for that to be different?)
• ...?

Sources

panel-devel archive (2008-02)

Why does Plasma not use KDE's system colors?

Conclusion

Plasma can colorize themes to match the system colors if the theme supports it.

Plasma is styled using SVGs. Proper runtime modification of colors in complex SVGs requires manual tweaking of the files. We cannot expect artists to be able to do that. If the artist intends the theme to be colored he can add a hint to the SVG.

Another approach to the issue of non-matching colors and SVGs is to include a color theme with a plasma SVG theme.

Original Text

Lubos Lunak

I think that KWin should keep using system colors, and Plasma should do so as well.

Aaron Seigo

configuring the plasma colours actually makes very, very little sense since the whole point of them is to harmonize with the svg's.

...

but the *real* issue imho is that there is a complete separation between the widget theme and the svg theme. it would make a lot more sense, at least to me, if widget themes shipped with an SVG theme that was then used by plasma, et al. that way the widget theme could harmonize naturally with the SVG theme.

...

likewise, the colour scheme should come with the widget style. applying random colour schemes to widget styles is not in line with reality. for super flexible styles, they could advertise themselves as accepting any colour scheme, of course.

with that in place, then it might be possible to talk about how to do colourization of svg's since it would then be under control / moderation of the artists. and that, really, is the heart of the issue here.

you can't just go around colourizing svg's up without limiting what is possible colour wise. you can tint greyscaled svg's, but that's a very blunt instrument. you can colorize based on intensity or what-not (i remember reading a paper on these sorts of algorithms some time ago, but none of the details =/ ) and those are better, but nothing will approach color-for-color literals in the svg's themselves without limiting oneself to a small (and often uninteresting) subset of possibilities.

Olivier Goffart

The SVG should follow the configurable desktop color sheme. This may sound crazy. But i'm sure this is possible.

Chani

in theory I'd like to agree, but in practice... well, my panel has a black background and oxygen's default text colour is also black. that's just one example of conflicts between plasma's svgs and kde's colours. in theory you could solve that by making the panel have a light background by default instead, but... eew. personally I think that would look really bad. and then what happens to, say, the fluffy bunny theme? at a minimum plasma's text colours have to suit its svg backgrounds.

I don't think that limiting the svgs is a good answer here. I do wish I could do *some* configuration of plasma colours without having to understand themes, though.

Marco Martin

maybe it would be somehow feasible with vector-only svg (that would require phisically modifying the colors saved in the svg, is that possible with qsvg?)

pinheiro

possible yes but i gess one would have to edit the svg code by hand. (artists are not big on that), and the svg code tends to be a bit messy at times.. so finding all the gradients that use a certain color is not trivial.. also in svg i rairly use a color but rather use an gradient so that makes it twice as complicted. couse changing all the stops in a gradient to match a new color is not simple at all.

Jamboarder

What about adding a hint element to plasma svg themes ("hint-use-system-colors" or something similar). If the element exists plasma would paint the svg with system colors (using tinting or whatever).

Aaron Seigo

hm. yes, i suppose we could do that. this would have to go into Plasma::Svg and only happen when d->themed but.. could work.

Jamboarder (Andrew Lake)

This patch allows plasma themes to react to changes in the current color scheme. Note that theme authors must specifically add the "hint-apply-color-scheme" element to the svgs for the color to be applied. This patch does not affect svgs that do not have this hint.

Sources

panel-devel archive (2008-02)

panel-devel archive (2008-02) - add a hint

patch allowing Plasma to colorize SVG files if the hint is present

panel-devel archive (2008-02) - discussion of literal vs semantic interpretation of color names

Should parts of KDE match Plasma's look?

Conclusion

The user perceives some parts of KDE as belonging together. These should have the same look.

Original Text

Sebastian Kuegler

In any case, what would be a nice way to make KWin and plasma blend in more nicely?

Lubos Lunak

I don't see why it should stop using the standard way to get colors and instead use a Plasma-specific replacement.

Sebastian Kuegler

My gut feeling is that the 'desktop' is made out of a couple of components, i.e. 'those that are not windows': panel, desktop-space (what kdesktop did, basically) and window manager. So basically the things that are not apps but visible to the user. For example, the boxswitch of the window manager is very much like the pager, or the taskbar... Grouping them visually makes sense to me, this is done by using the Plasma colorscheme.

Aaron Seigo

the difference is:

• user uses it as ...
• the code perceives it as ...

implementation and interface must cooperate at the technical level, but allowing implementation drive interface is really very stupid and something we need to get away from in general.

Sources

panel-devel archive (2008-02)