[desktop themeing]: simplify current solution

[star-buck]

make it easier for users to make nice and consistent looking basic themes (for main visible UI components like panel, menu, plamoids) without too many options or complicated svgs

that could help to offer simplified themes for phone, too.

@eikehein @notmart : you could work on this in a team with JensR.

[eikehein]

We could maybe implement something similar to Mozilla's Persona stuff into the Look-and-Feel system, or look into more procedural techniques similar to Sailfish's ambience stuff.

[star-buck]

I was thinking of simplifying the actual plasma desktop themeing rather than introducing yet something else on top or besides. Lets not make Looknfeel a big obfuscated container for hiding suboptimal solutions "under the carpet". ;)

[eikehein]

Well, the Mozilla Persona stuff is a simplified theme format, and procedural techniques simplify themes by autogenerating much from little, so that's what I meant too. Simpler themes = less powerful themes, so you have to find ways to compensate / not sacrifice quality.

[eikehein]

(And to explain how Look and Feel comes into that: That was more an implementation detail thing aimed at Marco, because on a tech level, the code to load Persona-like assets has to be somewhere and a lot of those places are factored out into the LnF package these days.)

[star-buck]

So the idea then would be to try and make themeing easier with current Looknfeel + personas?

The "Looknfeel" concept is great, but imo "rings" or feels" not quite 100% right, so if we re-think parts of the underlying plasma themeing and use it with current "looknfeel" to make things easier, the result could be labelled "super-theme" (or something similar). A "super-theme" has superpower, but is also supereasy to configure for the main parts (like basic colors, basic window deco, basic plasma theme). So marketing wise, saying kde now allows switching the overall look with a "super-theme" sounds better than with a "looknfeel package" (the latter somehow sounds like a heavier package with many extracted parts inside, of course in the end its just marketing). Or the supertheme is some kind of personas, where colors, widgets and plasma themeing would be combined, whereas looknfeel = Total Conversion (like windows or mac, where also panels placements, etc. would change). Looknfeel and supertheme somehow are different things...

[eikehein]

I think it's important that we distinguish between the technology side and the communication side here.

Let's talk about what goes into Plasma theming right now:

• The system color scheme.
• The system icon theme.
• The wallpaper package.
• The workspace theme (this also specifies some colors and provided tray icons, and can specify a default for the wallpaper package).
• The Look and Feel package, which contains factored-out UI elements (e.g. the UI layout for the lock screen) as well as can specify a default for the workspace theme.

Purely from a technology POV all of these are needed (don't freak and bear with me), because they combine to the majority of what you see on screen in Plasma. They are needed because the alternative to not having them is hard-wiring things in code, which means they can't be changed in deployed systems. Reducing the number of hard-wired things leads to better-modularized code and more flexibility.

However, being technically needed does not:

a) ... have to mean they have to exist in the above configuration. For example, why does the theme specify the wallpaper default, but the look and feel package specifies the theme default? Because the former predates the latter; it grew organically, it wasn't "designed" that way. The dividing lines and responsibilities between these different systems can be reassessed and shifted around to some degree.

b) ... have to mean they need to be exposed to the user - either at all, or directly. The user-facing abstraction can be very different from the implementation reality; how users think about themes and how the code needs to implement themes doesn't have to be the same. Perhaps there is a trade-off there between making the system more intuitive and keeping it transparent, perhaps not.

There's third audience, and that's theme developers and their authoring experience.

Let's compare the above with, say, Mozilla Firefox:

• Firefox has a complex theming system that lets you write themes that are essentially code plugins that can contain ... essentially anything. JS, XML, CSS, PNG, SVG; heck you can even write C++. This used to be the primary way to develop Firefox themes, and there are popular themes that are the result of months of complicated development work by people with a wide array of skills. If combined with the Firefox extension system, third-party developers can ultimately replace most of the Firefox UI. This is overall quite comparable with a combo of our entire Plasma bullet list + containment plugging system.
• But to lower the barrier to entry for theme authors they also augmented their default theme to be able to load a simpler pixmap-based theme format called Personas that essentially ... themes the default theme, i.e. adds some imagery or color or pattern to an UI that mostly remains the same.

Let's compare it to Sailfish OS:

• Sailfish also has all of this low-level theming stuff under the hood, although it's not really well-maintained because it's not open to third-party themers in the way Plasma or Firefox theming is, much less to users.
• Instead they have a default theme that procedurally auto-derives things like colors from the wallpaper the user picks and a short list of other choices.

[star-buck]

here is the idea:

1. plasma-themeing: should be reduced, no need to set wallpapers, iconthemes etc. apart from we already have wallpaper chooser, icon theme chooser etc. I understand where thats coming from, but we should simplify plasma themeing first, then do something like personas to the remaining elements mainly for UI components theming. So plasma theme devlopers can do so much easier provide nice plasma themes, without wallpapers, icontheme, etc. Example would be "cinnamon themes" (or spices what they call them): http://cinnamon-spices.linuxmint.com/themes
2. supertheme: a combined easy setup for plasma-theme, widget-style, colors (and eventually window decoration). A supertheme would combine several elements to match and fit configs of a desktop together, so this is similar to what Plasma theme tried but ultimately failed to do consistent, and now is too complicated for making just a simple and consistent plasma theme SKIN. Also, supertheme would add more than current plasma theme, like widget theme and colors kcm (but just dropdowns, not the detailed config of each). So it hides the details of each component, but allows easy swicthing between all installed of each component (like with dropdown boxes).
3. looknfeel: expand the looksnfeel to include a supertheme + panel sizes + panel orientation, etc. to make for a Total Conversion. Example would be Zorin Look Changer: https://www.youtube.com/watch?feature=player_detailpage&v=hVNCsTUCS_8#t=77

[eikehein]

plasma-themeing: should be reduced, no need to set wallpapers, iconthemes etc. apart from we already have wallpaper chooser, icon theme chooser etc.

Those actually already aren't required though. Plasma workspace themes can provide icons (to make sure the tray blends in with the panel design) and they can specify a default wallpaper, but they already don't need to, and many don't.

Most of these things support inheritance and falling back to defaults so themes can actually even just provide one changed element if they want to.

Edit: Breeze Dark is literally just a file specifying some different colors from normal Breeze for example, no SVG changes IIRC.

Example would be "cinnamon themes" (or spices what they call them): http://cinnamon-spices.linuxmint.com/themes

I think the real difference between Plasma theming and Cinnamon theming is really that Cinnamon uses CSS sheets and Plasma uses a series of SVG files (and some text for colors). The net capability is quite similar, but the authorship experience is different. Cinnamon's CSS properties map to hint elements in our SVG files, and so on. I think you can make the case that Cinnamon themes are easier to author because you can do a lot of it in one text file, while Plasma theming requires the use of an SVG editor and juggling many files. I don't think Plasma theming is hard, but it's possible some people lose steam in the process. One way to address this might be to strategically invest into theme authoring tools and documentation more.

Another difference is that our theme format is very generic, because we want to make sure the theme doesn't constrain what sort of UI we can implement. From what I remember of Cinnamon's theme format, they e.g. have CSS stuff that's highly specific to their particular launcher menu. That means it's easy to theme that menu, but hard to replace or change that menu without breaking themes (this is all from rough memory).

supertheme: a combined easy setup for plasma-theme, widget-style, colors (and eventually window decoration)

It might be worth noting here that this is roughly what we had in KDE 3, but it didn't quite work in practice. Theme authors would share "superthemes" that referenced other theme elements, but users would fail to collect them all and become frustrated and give up before achieving the look promised by the supertheme author's screenshot. This was before we really had GHNS, but even current GHNS is not up to handling this (no cross-referencing or dependency handling, etc).

Bundling everything into one theme so the user doesn't need to collect is still hard today e.g. because widget styles are usually done in C++, so you have all the usual problems with making binary packages for distros.

So it hides the details of each component, but allows easy swicthing between all installed of each component (like with dropdown boxes).

The Look and Feel KCM in some sense provides this workflow due to a trickle-down effect: A Look and Feel package can specify a default theme and the theme can specify a default wallpaper, so one switch switches a lot.

What I'm not sure about currently is how well Look and Feel packages currently support inheritance so you don't have to clone the UI stuff into a derived package if the roll-up change is all you want to do.

so this is similar to what Plasma theme tried but ultimately failed to do consistent, and now is too complicated for making just a simple and consistent plasma theme SKIN

Note that by definition a supertheme (with all of its constituent elements) will be more complicated than a Plasma theme because it contains more stuff. There's no free lunch there.

[eikehein]

Here's the old KDE 3 theme manager, for fun nostalgia: https://www.kde.org/screenshots/images/3.3/snapshot5.png

[notmart]

I think it's important to maintain backwards compatibility, both to not lose the current amount of themes and because it's a fairly complete system (moreover, going on a system that uses pngs right now that we are starting to support decently high dpi screens would definitely be a step back.)

Personally, what I was thinking may be a good thing done for this problem is a gallery application that shows all the elements in order of importance, from which is possible to have a live preview and launch and editor, creating new themes etc.

as if normal the current set of current elements is quite big, but 10% of the elements make for 90% of the stuff on screen at any given moment.

[notmart]

On simplifying the theme creation part, I'm writing this application: http://wstaw.org/m/2015/02/27/plasma-desktopwn1654.png (intended for who creates themes, not for final users)

is a simple gallery to show all the elements, with a description on what the element is for and how is used, the elements will be shown in order of "importance" (how often usually appear in a normal setup) so that will make easy for theme creators decide what to do before to have one that looks reasonably complete.

in the screenshot there are some elements with a little red dot. those are those that are not present in the selected theme and will fallback to the default one. the button "create in editor" will copy in the selected theme the default graphics and open it in inkscape for editing, making it very fast to complete.

[star-buck]

Looks nice! Please let Harald know the git location, so he can build packages in blueshellnext ppa.

[notmart]

sure. it will appear in the plasmate repo, together the similar tool for exploring icon themes. It will still take a while since is just started and is still in a branch and depends on another non merged yet branch in frameworks. But during next week should become possible to package it. as soon as all is merged will ask Harald to package it

[ohyran]

Is there anything I can help with Marco to make this come true? Also... you are the champion of champions dude :D

On Fri, 27 Feb, 2015 at 5:06 PM, Marco Martin notifications@github.com wrote:

sure. it will appear in the plasmate repo, together the similar tool for exploring icon themes. It will still take a while since is just started and is still in a branch and depends on another non merged yet branch in frameworks. But during next week should become possible to package it. as soon as all is merged will ask Harald to package it

— Reply to this email directly or view it on GitHub.

[notmart]

Things are merged, still many known bugs/crashers, still missing things like creation of a new theme/edit ui, but that can come when a preliminar version is running well. Told Harald to try to package it. ohyran: i guess mostly testing it as soon as is in an image, perhaps help in expanding the documentation that there is in the big json file that serves as data for the items to show.