jensreuterberg wrote:Marco: Concerning git, go for it handsome!

http://quickgit.kde.org/?p=scratch%2Fma ... -theme.git

right now it has the air theme (of which most of the elements are needed)
some of those present there may be dropped, but i suggest to start from the most important going down (widgets/background, dialog/background, widgets/button, etc)

also would be nice if somebody "takes" icons/ to care(i suggest to put the new icons in the current files, that already have the stylesheet stuff in it)

If somebody has problems cloning the repo, please ask

sorry for being a little bit late to the show and not quoting anything here

As there is some discussion about window decorations I wanted to give a small overview of what's possible from a technical perspective and what's required from a default theme. Basically KWin provides an empty canvas to the window decoration which can be drawn in any way it's wanted. The canvas consists of two parts: an area for shadows and an area for the actual decoration. The second part is used for snapping windows to each other. The shadow part is only available if compositing is available. This is basically the only constraint on the decoration. Apart from that the deco can do whatever it wants. If it wants to put some buttons to the bottom and others to the left, that's all possible. So my suggestion to you: feel free to think outside the box

So far we required from a default decoration that it supports non-translucency. On that point I might be very relaxed for Plasma.Next. It should not look broken, though, but I don't require you to come up with a design working well without shadows.

KWin currently supports the following decoration buttons:

• close
• icon (acts as KWin menu)
• application menu (opens the app's menu)
• keep above others
• keep below others
• On all Desktops
• Resize
• Shade
• Help
• Maximize/Restore
• Minimize

So far we required from a default decoration that it supports all buttons, though I think Resize has been broken for quite some time thus it might happen that I remove it The default button layout is provided by KWin and split into two groups. Decorations are encouraged to use that but it's not a requirement and I'm open to change the default layout.

Resizing: the default in KWin is to resize from all borders and to not restrict it to an edge or something like that. In addition we support resizing further than the edge of the decoration. That's used in Oxygen with the option "No Side Border". Again it's not restricted to certain borders, it can be used everywhere.

The caption is provided by the window and KWin hardly has control over it. Furthermore we do not know which application the window belongs to. This constraints us in what we can show and also in the icon. I have ideas to fix that but it needs collaboration from the toolkits so we might be constrained to have that only for KF5 based applications.

Speaking of development: if you need anything KWin doesn't provide I need to know in the next two weeks. Otherwise it will be too late for the first release due to feature freeze. So if you have ideas no matter how crazy they are, please check with me Send me a mail, ping me on IRC or just start a new thread here on the forum and notify me about it. Please explain very precisely why you need something and how it should work, etc. etc. I'd ask for it anyway

One rather obvious problem for the window decoration is that we don't know how the window looks like (at least KF5 apps can tell us the color scheme they use). We don't know whether it's a Qt4 or Qt5, GTK or even worse Some styles fix that by just having both widget and KWin style (e.g. Oxygen, QtCurve). For the first releases we have to assume that Oxygen will still be used for lots of Qt4 applications as a new widget style would probably be for Qt 5. An idea to solve this is to have the application tell KWin which decoration to use. If you think that's a good idea I again need a "Yes, please" pretty fast as that needs changes in KWin and Oxygen (Qt4).

Now some words on implementation: decoration rendering is really expensive and affects the performance. This adds constraints on the default decoration: it needs to be implemented in C++ and that's not the most easy thing to do (rendering code is really ugly to write) and very painful to change. Aurorae themes are completely unsuited for a default decoration - it's outside the scope of the theme engines (I wrote it and having it in default deco quality was explicitly not a design target) and also unfixable. Nevertheless I recommend you to start with an Aurorae theme and I would even suggest to ship it in the first release but not to default to it due to the strong Oxygen usage which we will have in it. After we have gathered some feedback the theme should get implemented with C++ and then can become the default for the second release.

notmart wrote:http://quickgit.kde.org/?p=scratch%2Fma ... -theme.git

Some things i added in that repo:
* in the metadata desktop file the theme is now called "next" so makes easy to test
* the colors file has colors taken from the first post that defined a palette
* in tools/ there is an inkscape extension that automates the boring renaming of the 9 elements svgs needed to do frames (again if somebody wants to try to use it and doesn't know how, please ask
* still in tools/ there is a script that is use to "massage" the svg files that are intended to use system colors (sometimes inkscape does it wrong, using that script ensures is correct)
* in widgets/slider.svgz there is a pretty much complete slider that follows the mockups look, it also follows the system color scheme, so use it as an example on how to do the rest

this is how it looks running in an actual plasmoid:


(i know, the middle one has rendering artifacts, there are certain situations in which qml2 still doesn't render correctly sadly, ignore it

notmart wrote:http://quickgit.kde.org/?p=scratch%2Fma ... -theme.git
If somebody has problems cloning the repo, please ask

Thanks much Marco!

Since this thread helped us flesh out enough of a general direction for the Plasma theme, and given it's more immediate need, I went ahead and started a thread specifically for the Plasma theme development here. Anyone interested, please join us there to share any tips, thoughts and ideas regarding the Plasma theme.

mgraesslin wrote: So my suggestion to you: feel free to think outside the box

Ooooh, sweeter words a designer has never heard!

mgraesslin wrote:Speaking of development: if you need anything KWin doesn't provide I need to know in the next two weeks. Otherwise it will be too late for the first release due to feature freeze. So if you have ideas no matter how crazy they are, please check with me Send me a mail, ping me on IRC or just start a new thread here on the forum and notify me about it. Please explain very precisely why you need something and how it should work, etc. etc. I'd ask for it anyway

Most everything we've come up with so far should work with KWin as is I think - best WM in the biz. One thing I can think of that was mentioned in the public area is application menu button:
- The ability for the windec to render the application menu button in a different size/aspect ratio from the other window buttons.
- The ability for the windec-rendered application menu button to display text (e.g. "Menu" or some such).

Also, Fabian(plusfabi) had an idea for an application search button in one of his mockups. That probably requires hooks into the toolkit, but I imagine the idea is that if the application declares it has a search function, KWin could display the button which, when clicked, would signal the application to display its search UI.

Not sure how feasible or desirable any of this is, but I thought I'd mention it. Personally, if the application menu button thing is feasible, I'd definitely dig it.

mgraesslin wrote:One rather obvious problem for the window decoration is that we don't know how the window looks like (at least KF5 apps can tell us the color scheme they use). We don't know whether it's a Qt4 or Qt5, GTK or even worse Some styles fix that by just having both widget and KWin style (e.g. Oxygen, QtCurve). For the first releases we have to assume that Oxygen will still be used for lots of Qt4 applications as a new widget style would probably be for Qt 5. An idea to solve this is to have the application tell KWin which decoration to use. If you think that's a good idea I again need a "Yes, please" pretty fast as that needs changes in KWin and Oxygen (Qt4).

I'm ambivalent on this one. I'm thinking that it be worth just identifying a short term solution using an existing application widget style (like the QtCurve settings file suggested here) that'll work well enough with the new, non-default windec. My main thought is that this kind of non-explicit coupling might be difficult or challenging when the user really does want to use different windec and application widget styles. Besides the user will have to actively choose the new windec anyway. May as well also select the new widget style like they're already used to doing.

mgraesslin wrote:Now some words on implementation: decoration rendering is really expensive and affects the performance. This adds constraints on the default decoration: it needs to be implemented in C++ and that's not the most easy thing to do (rendering code is really ugly to write) and very painful to change. Aurorae themes are completely unsuited for a default decoration - it's outside the scope of the theme engines (I wrote it and having it in default deco quality was explicitly not a design target) and also unfixable. Nevertheless I recommend you to start with an Aurorae theme and I would even suggest to ship it in the first release but not to default to it due to the strong Oxygen usage which we will have in it. After we have gathered some feedback the theme should get implemented with C++ and then can become the default for the second release.

Excellent! We've already started an Aurorae theme with the understanding that it'll eventually need to be ported to C++. One thing I haven't figured out how to do with the Aurorae theme right now is different shadow sizes for active and inactive windows. No worries if we have to wait till the C++ port to do that though.

alake wrote:Most everything we've come up with so far should work with KWin as is I think - best WM in the biz. One thing I can think of that was mentioned in the public area is application menu button:
- The ability for the windec to render the application menu button in a different size/aspect ratio from the other window buttons.
- The ability for the windec-rendered application menu button to display text (e.g. "Menu" or some such).

No problem at all, KWin doesn't add any restrictions on how the buttons are rendered, that's completely up to the decoration

alake wrote:Also, Fabian(plusfabi) had an idea for an application search button in one of his mockups. That probably requires hooks into the toolkit, but I imagine the idea is that if the application declares it has a search function, KWin could display the button which, when clicked, would signal the application to display its search UI.

Not sure how feasible or desirable any of this is, but I thought I'd mention it. Personally, if the application menu button thing is feasible, I'd definitely dig it.

Such an extension could easily be implemented in the decoration first, without any extension in KWin

alake wrote:Excellent! We've already started an Aurorae theme with the understanding that it'll eventually need to be ported to C++. One thing I haven't figured out how to do with the Aurorae theme right now is different shadow sizes for active and inactive windows. No worries if we have to wait till the C++ port to do that though.

If you can point me to the QML files I can have a look at it and also tweak it.

This is a complete aside but am I completely mental when I suggest having a long hard look at the suggested applications in Plasma?

I mean "Amarok"? Doesn't seem supported and compared to Tomahawk it's very dated. Dragonplayer? I don't know if it is supported but its like death by ten thousand buttons in there.
Dolphin can be edited to hide all but the most essential details and the IM program is also kinda light. Kmail is the big stone in the shoe and System Settings. But all these imagine if we could get them all to look the same... To follow the same design pattern.

@mgraesslin:

mgraesslin wrote:No problem at all, KWin doesn't add any restrictions on how the buttons are rendered, that's completely up to the decoration

Cool. So I guess that answers my question from before; if you look at the mockup below you'll see that some buttons are drawn on a blue background, I guess it's possible to have buttons (e.g. the application icon) without a background, correct?

alake wrote:

mgraesslin wrote:If you can point me to the [Aurorae] QML files I can have a look at it and also tweak it.

The quick Aurorae theme I did up was svg (old Aurorae?) here. We would love some guidance for how to construct it in QML or maybe just an example QML Aurorae theme would be a great start!

Hans wrote:if you look at the mockup below you'll see that some buttons are drawn on a blue background, I guess it's possible to have buttons (e.g. the application icon) without a background, correct?

yes, sure

alake wrote:

mgraesslin wrote:If you can point me to the [Aurorae] QML files I can have a look at it and also tweak it.

The quick Aurorae theme I did up was svg (old Aurorae?) here. We would love some guidance for how to construct it in QML or maybe just an example QML Aurorae theme would be a great start!

The reference QML Aurorae theme is "Plastik", you can find it here (kde-workspace.git/kwin/clients/aurorae/themes/plastik).

The QML format is not yet really documented as I still want to be able to change it.

I've just done a runthrough of the available software we have going and although this is waaaaay into the future - I gotta say that when comparing them that there is a lot of nice room for improvement over the standards visually.
By working on the options we have we can perhaps influence the larger softwares OR be really sneaky and simply go "This is the Vanilla Desktop and the Vanilla Apps"

Amarok --> Tomahawk
Well this felt like a no brainer, its prettier, cleaner, supported and with an active community. Compared to Amarok it also feels like a modern UI to some extent (although it could be cleaned up further)

Dolphin --> Konqueror
Aside from the weird web browser detail it is soooo much more uncluttered and simple in its approach and the default is actually usable. Set a "menu bar" button on it and suddenly you have one of the cleanest filebrowsers I've seen with still plenty of nice friendly buttons.
Appearently it's not supported any more (?) which is a shame and tbh this is what I think Dolphin should have looked like and if only the Dolphin devs would get in line with it it would be awesome.

Dragon Player --> Bangarang
Again a no brainer. Actually it doesn't HAVE to be Bangarang just that it felt good to test considering Andrew was active in it. But compared the rather confusing UI in Dragon Player it is awesome!

Ignore the weird mixed folder icons in Konqueror!



So if we look at System Settings, Kmail and the chat application perhaps we can see where there is room for improvement and sort of work towards that?

> I've just done a runthrough of the available software we have going and
> although this is waaaaay into the future

This is really out of the scope and out of the influence radius of this group and its members.

> Amarok --> Tomahawk
BTW, Amarok is not a KDE default, distributions are making it a default. And it became that on its own - nobody actually sad 'you ought to ...'.

Another thing is that Tomahawk is not a KDE project.

> Dolphin --> Konqueror
Not gonna happen. The reason why dolphin exists is that konqueror is overly complex. It is just the default setup which makes this look the other way round.



> Dragon Player --> Bangarang
IIRC, a new version of Dragon is (was?) being developed.

I don't think we should see it as beyond our scope. Rather the opposite.

The reason why is because we can use it as good examples on why standard applications should follow a design spec. By contacting the individual groups (Dolphin, whatever and whatever else) we can perhaps allow for changes to happen and create something solid instead of just letting it go.

Considering the fact that we have rather high goal already (the theme and stuff being only the slim beginnings) we shouldn't balk at this attempt to try to work on the base stack of applications. If they stick to the "More buttons than a spaceship" design it doesn't matter how much we work on the theme and extra things.

"work on the base stack of applications" is fine.

Replacing them with other applications is not. That is, I don't think we could pull it off, even if we all reached consensus. (which I don't think we would anyhow)

Design guidelines are fine and well. But it will always be up to the maintainer of the application to decide whether he wants to follow them or not.