About a half a year a go i spend a lot of time trying to to create a custom style for KDE but in the end I just give up... I had two options:
1) Use One of the available engines that allow customization
2) Create my own theme engine...

As I don’t have enough knowledge to create my own engine I dismissed the second option since it would take to much time to actually learning the basics and the end result would be probably very poor.
So I decided on the first option that pretty much limited me to two engines Qtcurve and Bespin, both are customizable with build in editors to make them as easy as possible. Unfortunately there are not customizable enough, those editors are just getting in the way and because kde apps are made with oxygen in mined there is almost allays something not right with the final result...

A while back I created skins for Opera browser they had a nice skin system, it showed it's age but it was flexible and still worked pretty nice.
With those in mined I thought about a new theme engine that would be powerful and designer friendly(not average joe friendly but designer friendly).
It took me 6 months before i actually decided to write about i here...

The main concept is simple a theme engine that actually allows loading themes ;P
A Theme could be an archive file containing a description file and images – similar to opera skins, but this is where the similarities would end. At least the basic version because it could be expanded to color schemes, cursors etc.
A description file is a file containing the authors/theme name, theme version etc. plus the actual style(or file name pointing to the style).
Opera used an ini syntax to describe the look of the browser

Code: Select all

[section B]
Clone = Section A
Color=#000
Type = BoxStretch
Stretchborder = 0 18 10 1
Tile Center = /path/to/the/image.png
Padding=0 0 10 10

Clone takes properties from other section
Type specifies how the image(tile center) should be treated, in this case BoxStretch, the Stretchborder describe he width of the image borders.

The rest is self explanatory.

I think that a css-like syntax would be better because many people are familiar with it, there are a lot of tools enchanting the workflow with css that could be reused, and qt already has a css support on which the theme engine could be build(probably ;P).
I'm not talking about full css support just a similar syntax.
Same hierarchy, selectors and some properties[color, background, margin, padding etc.] with the BoxStretch types and some other things.
Previous example in css like syntax

Code: Select all

.SectionA, SectionB{Some common proprieties}
.SectionB{
Color: #000;
Background: url('/path/to/the/image.png') BoxStretch 0 18 10 1;
Padding: 0 0 10 10;
}

The other thing that would be very interesting is parent-chiled relationship between themes(i would limit it to one, two levels – a child theme cannot be a parent theme – just to make it simpler). It would be very helpful to build styles for different environments or just to apply some changes to a theme that you like. For example create a main theme for the desktop and then make a child theme that just adds bigger padding and other small changes for touch devices. One main theme for the desktop +child themes for other devices.

One last thing that could be interesting, different applications have different purposes that that could require focus on different parts of the UI, it would be nice if the engine applied a little different look of the skin(specified in it) depending how the application 'presents' it self.
For example if the app presents it self as a graphic editor then it will get a darker look of the theme(if the author of the theme specifies the look for that type, if not it would fallback to the default) with more focus on the canvas.
There could be few predefined types eg. default, multimedia/graphic, office, system for which the author of the theme could specify some modifications.

I wrote here just the basic sketch, there is a lot more that I would like to see for example some basic variables in the style file that user could change directly in the theme manager(something similar to the unity3d game engine)and a simple if /else statements witch would make those themes more customizable.
Example:

Code: Select all

var main_color = #ff0000:color;   //it would display in the theme manager as a color picker with the caption 'Main Color:'
var border_width = 5px:int;      //text input/ slider
var visible_border = false:bool;      //checkbox

If  visible_border==true
.sectionA{border:none;}
else
.sectionA{border: border_width solid main_color;}

All that plus some prerendering/caching would make a perfect theme engine
Here is a little mockup that i made to show how powerful it could be https://dl.dropboxusercontent.com/u/63396655/KDE_window/index.html
If you know css than you can play with it by editing the style, applying few predefined styles, checking the parent child relation.

Why a new advanced theme engine:
- because the trends change fast and I believe that it would be easier to just build a new theme instead of a whole engine and in the meantime enhancing the engine with new features.
- It could result in a lot of unique themes – today the only difference that we see betwean most distros is a different plasma theme...
- Because programers have a **** taste ;P and it's better to separate their work from the designers.
- It would result in creating guidelines for the application authors, with those other engines would benefit also
- All new features would work in all themes from that engine – for example the window grouping works only with oxygen...
- Since the beginning of kde4 I haven't found a theme that would satisfy me and with the proper tools I could finally make my own ;P
- And a few other things that i forgot because writing this post took me more time then making that mockup

I didn't read all your post (sorry, I'm sleepy right now) and opened your mockup (I always wanted something like that!) but if I got your idea, you might be interested in this:

viewtopic.php?f=90&t=88098

It's something I've been clamoring about for ages. I really don't know how will be things with the change to Qt5 backend (nobody has given me a satisfactory answer... heck, nobody has given me an answer!). Maybe you can give me support about asking devs about that (there's a bug reported about that in https://bugs.kde.org/show_bug.cgi?id=164955, you could ask for re-opening it or maybe even opening a new one): as you see, in both bug report and forum thread people left me asking alone.

Agree with you, KDE Plasma / Frameworks is flexible in everything except this. Kind of sucks.

I agree that a new theme engine is in order. I like the bespin engine as it generally looks the nicest and feels more current-generation. I also appreciate the QtCurve engine's flexibility (within its constraints) and gtk portability but as far as that flexibility goes, all QtCurve themes are still identifiable as QtCurve and generally look previous-generation.

I'm not a designer, I just appreciate having a nice looking desktop; but it seems to me that a good css (qss?) based theme engine (that cooperates properly with color schemes, with accompanying gtk theme engine for unified look and feel) would encourage more better-looking themes.

There was also an SVG-based theme engine called QuantumStyle that has had sporadic development over the years. The idea is really interesting with the potential that tools could be built around it, but it needs work (esp. in cooperating with your chosen color scheme, as well as in accompanying gtk themes), and I would guess that svg-based themes might require a bit more expertise+effort than css (or qss) based themes (I could be wrong though)

If the theme engine would use qss or it's own system(parser?) i don't really care, that is for someone with the necessary knowledge to decide i only would like it to be customizable and efficient.

Color schemes are a little problematic if your using images, but even so, there could be an option to specify if the current theme can use system color schemes or it's own. Of course there are ways around it but that would depend on the theme author.

I would say that now is the best time to create that kind of engine with the whole redesign of KDE.

Personally i think that the current situation is idiotic(delicately speaking)... Changing a theme engine shouldn't be made as a customization option but as an advanced/ last resort option... for different platforms and specific situations.
And because of that 80% of the engines are legacy ones that weren't updated for ages, we have two somewhat customizable engines and oxygen that may or may not land with all the other legacy engines. Since i can't stand the look of oxygen i won't cry when/if it's replaced.

But i see that there is not much interest in this thread, we'll probably end up with another theme for the next 5/10years that some will love and some will hate... with little alternatives. Hope i'm wrong ;P

I think the idea is good, it's just another "it would be great if somebody did this" idea. And those are generally not a very successful concept

So, to get something moving, have you contacted the author(s) of the existing styles which go in that direction? Could they be adapted to be more flexible, or could something be based on them? Could you imagine starting some work on this yourself?

Well if not counting the actual mockup and thinking about some of the quirks that would be necessary to overcome then no, actually if i had the necessary programing knowledge or at least if there would be some how to guides than i would already be doing it myself...
I'm aware that this is one of those "it would be great if somebody did this" ideas and that was the main reason why i haven't posted earlier about this. But of course if someone would pick it up i would like to participate in the development process.
With the creation of VDG i decided to give it a try because i also wanted to know their opinion on this, so this is the first place that i wrote about it.
I haven't contacted any authors yet but i would like to fined out what they think about this, so i try to contact some of them and point them to this thread.

The main point of this would be to create a customizable/flexible MAIN engine to make all the others if not obsolete then at least less useful... and to give the necessary tools to those who want to make an actual theme and don't want to mess with programing. One to rule them all

ps. All the currently shipped by default theme engines could be easily recreated with this.

To recreate e.g. Oxygen your engine would have to be extremely flexible, especially regarding animations. Look at all the fade effects Oxygen does when you e.g. hover a button; that's not trivial to recreate with a pure CSS/SVG driven theme engine. It's surely possible, but it certainly raises the requirements.

EraX,

Always feel welcome to share your visual design ideas. Yes, all ideas have a much greater chance of success when there is someone willing and able to implement them - even better when the person with the idea also has the skills to implement it. But sometimes it takes someone with great idea to share it for someone with ability to feel inspired to implement it.

A simple flexible, theme engine for the vast number of current generation QStyle apps is sorely needed, so keep sharing your Ideas to inspire those with the ability to think about how it could be achieved. This is perhaps the last KDE frontier to have design-at-runtime themeing. Window decorations, Plasma desktop themes, icons are all design-at-runtime. Next-gen QtQuick application widgets/controls will be design-at-runtime. Current-gen QStyle themes require compilation - a major hurdle to creating full theme packages. A capable theme engine would be a welcome step to achieving KDE visual design goals.

scummos wrote:To recreate e.g. Oxygen your engine would have to be extremely flexible, especially regarding animations. Look at all the fade effects Oxygen does when you e.g. hover a button; that's not trivial to recreate with a pure CSS/SVG driven theme engine. It's surely possible, but it certainly raises the requirements.

I have no idea how hard it would be to implement it in the engine but with pure css it is actually pretty easy to make simple transition effects(faide in/out smooth color/padding/margin change etc - that is probably more than enough). I'm aware that creating that kind of engine is not an easy task because if it was we would probably already have a few

Yes, sure -- don't feel deprived from discussing ideas by my intervention! I was just trying to explain a likely reason for the lack of interest on the topic.

QtCurve is very flexible. Maybe extending QtCurve to be even more flexible would be an easier way to achieve these goals than creating a new engine?

Greetings!