Sogatori wrote:I think he's asking how easy/difficult this API will the creation of new decorations. Similar to how most people had to use the (relatively) limited qtcurve engine to create new themes, because it was the only way to make themes easily. There was no other way to create global themes without C++.

You mean like using dekorator, smaragd or aurorae?

To answer the question: the decoration plugin is very abstract and written in c++
You need c++ skills to write a deco plugin.

BUT:
such decoration plugin itself can provide skinning, like forementioned plugins did (and I expect at least some of them being ported to KF5)
Just "Oxygen" was the "Oxygen" style and not the "Bring your own look" style - it is / was not meant to act as a theme engine (unlike the forementioned deco plugins ...)

So basically the lazyit's question is wrong.
You could always bring your own deco plugin.
You could always bring your own deco theme.
But Oxygen in particular was never meant to be a themable deco plugin - and will unlikely be in the future (nor probably breeze?)

Okay, so now the question which people here will probably be most interested in: What are the chances that there will be a theming engine plugin which people who don't have C++ skills can use but which doesn't have all the problems Martin mentions in his blog post about why Breeze isn't the default for 5.0?

It is possible but just hasn't been done yet, or will flexible theming engines which allow e.g. QML always have serious drawbacks compared to a hard-coded theme like Oxygen was and Breeze will be?

I am betting your right arm that Martin (also/especially) wants to make the Aurorae engine usable by KDecoration2.
I also expect theming engined to be ported (moved to kdecoration2 or not)

Writing a deco plugin (or anything else) in an imperative language (c++) will systematically be more powerful than doing a theme in any declarative language (be it QML, SVG or an ini file and a fistful or png's) but the major issues with the present QGraphicsScene driven Aurorae engine should be addressed by the kdecoration2 API.

colomar wrote:It is possible but just hasn't been done yet, or will flexible theming engines which allow e.g. QML always have serious drawbacks compared to a hard-coded theme like Oxygen was and Breeze will be?

A theme engine can never be as powerful or optimized as a native theme. You either have to restrict what's possible in the design or have drawbacks in performance. E.g. with KDecoration2 it will be possible that all Breeze decorated windows have the same shadow - one copy in memory with a highly compressed image. With a theme engine that's just impossible as the theme engine cannot know how the shadow looks like - it could contain a gradient depending on size. The theme engine has either to forbid it, of hold the memory for each of the shadows.

I hope that kind of explains why Breeze has to be in C++, it needs to be high performant to be the default decoration - that's something I communicated since January

And yes Thomas is right, I want to have Aurorae ported to new KDecoration2. It will again not be the most performant piece of code, but that's how it is.

Thank you both for the answers, I think that should make it clear for us

I just looked over the Kanboard and all tasks there look like development work to me. Is there anything else designers with no coding skills an still help with?

colomar wrote:Is there anything else designers with no coding skills an still help with?

sure, e.g. all the metrics are needed. How large should which offset be, how large should a button be, how does a button scale. Even with very very limited developer knowledge it might be possible to fix misalignments in the new Breeze deco. Yes it's code, but not that different to how the QML code looked like (I did copy and pastes from the QML theme ).

oh and just in case if it's not clear: the board is color coded - only the red items are for KWin. Everything else is not scary KWin code

Sogatori wrote:

mgraesslin wrote:

lazyit wrote:I wanted to ask if @mgraesslin for the new kdecoration it is possible to easily change themes, so that users can then indulge in creating new themes and customize, I think it would be important, and Oxygen has never done ...

I do not really get your question. Of course it will be possible to change the decoration. What I don't get is what Oxygen has to do with it...

I think he's asking how easy/difficult this API will the creation of new decorations. Similar to how most people had to use the (relatively) limited qtcurve engine to create new themes, because it was the only way to make themes easily. There was no other way to create global themes without C++.
Gtk+ based desktops have this great amount of diverse themes available because it has a easily accessible powerful theming engine. CSS is more widely know than c++ after all. So he's asking how these themes are being created.

I could be wrong though, maybe he meant something else.

I apologize for my bad English, but @Sagatori played almost exactly my thought, probably because it is still a very common thought among users

mgraesslin wrote:

colomar wrote:It is possible but just hasn't been done yet, or will flexible theming engines which allow e.g. QML always have serious drawbacks compared to a hard-coded theme like Oxygen was and Breeze will be?

A theme engine can never be as powerful or optimized as a native theme. You either have to restrict what's possible in the design or have drawbacks in performance. E.g. with KDecoration2 it will be possible that all Breeze decorated windows have the same shadow - one copy in memory with a highly compressed image. With a theme engine that's just impossible as the theme engine cannot know how the shadow looks like - it could contain a gradient depending on size. The theme engine has either to forbid it, of hold the memory for each of the shadows.

I hope that kind of explains why Breeze has to be in C++, it needs to be high performant to be the default decoration - that's something I communicated since January

And yes Thomas is right, I want to have Aurorae ported to new KDecoration2. It will again not be the most performant piece of code, but that's how it is.

Thank you for you throughout explanation. The only problem I see is that we'll have to bug some C++ developer every time we want to change something/maintain the decoration. Not that we can do much about that, as you have laid out.

Just to satisfy my curiosity: Do you happen to know how other DEs handle this? They don't exactly seem like a memory hog either, but then, maybe they don't allow some features our APIs have.

Sogatori wrote:Just to satisfy my curiosity: Do you happen to know how other DEs handle this? They don't exactly seem like a memory hog either, but then, maybe they don't allow some features our APIs have.

most are extremely limited. For example I heard from the GNOME camp that they needed client-side-decorations to be able to have antialised borders - we solved that problem back in 2009.

and another update in a blog post - it's now fully functional and integrated into KWin in branch "graesslin/kdecoration2", only window tabs are missing.

Exciting times mgreasslin!

I know we owe you a layout spec for the window decoration. I'll post something here in the next couple days.

alake wrote:Exciting times mgreasslin!

I know we owe you a layout spec for the window decoration. I'll post something here in the next couple days.

I don't know how good your compile skills are: but if you manage to compile breeze, kdeocration and kdecoration-viewer you could also just try to set the proper layout yourself. I hope I got the code readable and it's not that much different to the QML variant

My dev environment isn't quite set up yet but I'm working on it so I can help with any refinements.

Till then, here's a quick spec for the spacing and margins:



It's probably just a touch different from the current QML code but I think the current QML code has some weird binding loops anyway.

Hello developers,

in the thread about muon discoverer the question arose if there will be a way for applications to use KWin's window tab feature like normal tabs:
[quote=EraX]
If/whet app will be able to place tabs on the titlebar it could look like:
https://dl.dropboxusercontent.com/u/633 ... _multi.jpg
https://dl.dropboxusercontent.com/u/633 ... ch_tab.jpg[/quote]
Is this possible?