Feature requests

[trmdi]

Some guys would love a transparent blur titlebar for Konsole, like what SierraBreeze and BreezeBlurred can do. Will you add such an option ?

[tsujan]

With BreezeEnhanced, there's no need to that ;) If you want all title-bars to be opaque but Konsole's title-bar to be translucent (and blurred), please try this:

(1) Add this overrdie:

(2) then add this one to the top of it:

BTW, today, I'll add an option to remove macOS buttons, although they will be the default. The reason is that macOS buttons may not be good with all themes.

[tsujan]

Oh, don't forget to make the title-bar translucent in the above experiment!

[trmdi]

Btw, I think you can make this decoration much better by supporting theming. Something like aurorae engine of kde, but it seems to be buggy and lacks maintenance.

[tsujan]

Btw, I think you can make this decoration much better by supporting theming.

What do you mean by theming? If you mean the buttons, I'll add an option, as said above. If you mean the gradient/color, I think they should follow KDE color scheme, But if you mean optional buttons or background images, that's not possible with Breeze, as far as I saw its code.

Did you do the above experiment? If it worked, please close this issue (it worked here).

[trmdi]

Yes, I mean the buttons.
I'm not sitting in front of my computer so I can't test it now. I will tell you the result tomorrow.

[tsujan]

Yes, I mean the buttons.

With Breeze, buttons are drawn in the code. So, there aren't many options.

I will tell you the result tomorrow.

Take your time! Since it worked here, it should also work there :)

[trmdi]

Yep, I can do it.

But how can I apply that effect only to the main window of Konsole?
If I do like you told me, it also applies to other windows/dialogs... of Konsole.
Can you make BreezeEnhanced's window-selection like the Kwin's one ? It lacks Window Role, Window type...

[trmdi]

With Breeze, buttons are drawn in the code. So, there aren't many options.

What about button color and horizontal space between buttons ? And add other macOS style buttons like Keep above, Keep below...
Some guy like @kupiqu would like that: ishovkun/SierraBreeze#50

[tsujan]

Can you make BreezeEnhanced's window-selection like the Kwin's one ? It lacks Window Role, Window type...

This is a good idea. I'll think about it.

IMO, adding codes for specific apps like Konsole is wrong.

What about button color and horizontal space between buttons ?

Colors are mild gradients that are carefully selected for both dark and light themes. I experimented with various intensities and found out that macOS had chosen the best colors. So, I'm afraid they couldn't be optional.

I agree that it'l be good to add an option for the space between buttons; will think about it.

And add other macOS style buttons like Keep above, Keep below...

I had added them at first but found them like an overkill: the title-bar was filled with colored circles and looked really weird. So, later I decided to leave the "secondary" buttons as they were -- I just made them a little smaller with non-macOS buttons.

BreezeEnhanced was started only a few days ago; most of its features were added in the last 2 days ;) Other features may be added later and I'll look forward to your suggestions. However, please note that I work on several other projects too: 4 programs of mine as well as the LXQt project. Therefore, to bring quality to development, I should do things little by little, program by program.

[trmdi]

Therefore, to bring quality to development, I should do things little by little, program by program.

It should be like that. I just drop my idea here when it appears in my head in case I forget it afterwards. :D

Ah, another thing is, do you think the buttons of inactive windows should be gray? Look at my screenshot above, too many colored circles there. An option may be good for everyone :p

[kupiqu]

And add other macOS style buttons like Keep above, Keep below...

I had added them at first but found them like an overkill: the title-bar was filled with colored circles and looked really weird.

Maybe if they all are in the same side, but I find them fine if keep above and show in all desktops appear on the left and the rest on the right, which is what I use. Perhaps these could be made optional, but IMO, if you don't like color buttons there is no reason to use Mac style decorations in the first place.

do you think the buttons of inactive windows should be gray? Look at my screenshot above, too many colored circles there. An option may be good for everyone :p

Certainly, I find this confusing about the active window (and more overkill color issue than adding colors for keep above and show in all desktops).

But just my 2cts.

Congrats btw for the animation, I really find it very nice

[tsujan]

@trmdi

I reopen this page because it contains ideas to be implemented.

I just drop my idea here when it appears in my head

And please keep on doing so!

do you think the buttons of inactive windows should be gray?

I had experimented with that too. There was a problem: the buttons couldn't be distinguished from each other. All people could get used to Red → Close, Green → Maximize, Yellow/Orange → Minimize. But gray buttons might cause confusion to some.

@kupiqu

... if you don't like color buttons there is no reason to use Mac style decorations in the first place.

My decision wasn't final. I might return to this later.

[tsujan]

Look at my screenshot above, too many colored circles there

That's a good point too. Maybe, I should gray out the inactive buttons a little more.

[trmdi]

There was a problem: the buttons couldn't be distinguished from each other. All people could get used to Red → Close, Green → Maximize, Yellow/Orange → Minimize. But gray buttons might cause confusion to some.

Can you make the buttons display the color when the mouse is inside the titlebar region, and gray if not ?

[tsujan]

Can you make the buttons display the color when the mouse is inside the titlebar region, and gray if not ?

For inactive windows? I should see if there is such a property ("cursor inside title-bar")... Will tell you about it.

[kupiqu]

... if you don't like color buttons there is no reason to use Mac style decorations in the first place.

My decision wasn't final. I might return to this later.

Sounds good!

Btw, "you", above, was general, referred to a potential final user, not specifically to you as developer. I should have wroten "if one doesn't like color buttons...".

Again, that's just my opinion (I guess that's why I'm still using SierraBreeze decoration, but I see a lot of good progress here, congrats).

[tsujan]

@kupiqu I try to follow users' opinions AND practicality. The practical side isn't strong in the case of colorized secondary buttons, while it is important with gray inactive buttons. So, in the first case, I can forget about my taste but, in the second case, I should find a middle way :)

[kupiqu]

In SierraBreeze, hovering buttons of inactive windows show "x" for close, "-" for minimize, etc. I guess there is a way to instead replace gray by the color (red, yellow/orange, etc) on hovering, if you'd like that (minimalist) option.

[tsujan]

... I guess there is a way to instead replace gray by the color (red, yellow/orange, etc) on hovering

This seems to be the best compromise. I'll go with it.

[tsujan]

I made inactive macOS-like buttons gray with a formula that derives the gray lightness from the background color:

The next step will be making secondary buttons macOS-like.

[tsujan]

macOS secondary buttons are added. All of them are pale blue except for the menu button, which is orange. Their symbols appear on mouse-over, so I don't think there can be any problem, especially because users wouldn't remember various colors. Tests would be appreciated.

The main features mentioned on this page are added. I should think about the other features thoroughly and read some codes. So, I close this.

[tsujan]

@trmdi
As for the space between buttons, I investigated it and found that, unfortunately, it's hard-coded in kdecoration -- among several other parameters -- based on font size and other things. So, it can't be changed inside Breeze.

However, IMHO, the defaults of kdecoration are good enough.

[trmdi]

I just try SierraBreeze, it can do it somehow ???

[tsujan]

I just try SierraBreeze, it can do it somehow ???

Really?! I'll see its code; perhaps I'm missing something.

[trmdi]

I just try SierraBreeze, it can do it somehow ???

Really?! I'll see its code; perhaps I'm missing something.

Yep: https://streamable.com/18v4u

[trmdi]

Personally I like both macOS dark and light themes.
Btw, what is the Kvantum theme above? Look quite nice !

[tsujan]

Btw, what is the Kvantum theme above?

Its name is weird: KvSimplicityTurquoise. Its roots are in the mac style; it's derived from KvSimplicity, which is derived from OS X Yosemite.

[tsujan]

Now that I'm more adventurous, I added a new commit, with which Konsole and other apps can have translucent title-bars more easily.

Just remove the previous setting about ".*" and add a value to the new spin-box "Override opacity" in the exception dialog. The following screenshot shows that for QTerminal (a Konsole fork I use under LXQt):

Of course, you could also create a color scheme and assign it to Konsole in System Settings.

The box "Opaque title bar" is kept for the ease of use. If checked, it disables the opacity override.

I'll think about dialogs later.

[Luwx]

There are any plans to update it to 5.14?

The new shadow they implemented looks gorgeous

[trmdi]

@Luwx I tried reducing the Shadow strength to 25% and got the similar effect.

[tsujan]

There are any plans to update it to 5.14?

As soon as a newer versions of KWin comes to Manjaro Testing (soon after it comes into Arch), I'll check the difference between Breeze versions and, if needed, will apply them to BreezeEnhanced.

With Arch based systems, that's fast. Previously, I used Debian sid and should wait for weeks.

[tsujan]

Right now, https://download.kde.org/stable/plasma/5.14.0/ can't even be opened ;)

[trmdi]

You can use the Github mirror: https://github.com/KDE/breeze/tree/Plasma/5.14?files=1

[tsujan]

You can use the Github mirror....

I know but I prefer not to deal with unstable versions. The latest version of BreezeEnhanced (mentioned in the file NEWS) should be for the latest stable version of KWin (with a delay of one week or so).

And that's why I could never publish a release -- only the latest git version will be valid.

[trmdi]

I know but I prefer not to deal with unstable versions.

Oh, I thought they tagged it as 5.14 means that it's the stable release ? Here is the release schedule: https://community.kde.org/Schedules/Plasma_5

Sorry, I don't understand that very well. Just give you the link in case you weren't aware of it. :D

[tsujan]

Oh, I thought they tagged it as 5.14 means that it's the stable release

It means it'll be released as a stable version soon. https://download.kde.org/stable/ shows the last stable version.

[Luwx]

@Luwx I tried reducing the Shadow strength to 25% and got the similar effect.

You can get close but what breeze uses right now is not a true box shadow.

Well, 5.14 is pretty much stable now, but I guess it doesn't hurt waiting a few more days :)

[tsujan]

@Luwx Yes, Breeze::BoxShadowHelper is new. It'll be straightforward to apply changes to BreezeEnhanced once 5.14 gets stable (and comes to my distro).

[tsujan]

@Luwx How did you compile kdecoration 5.14? I added BoxShadowHelper to BreezeEnhanced but, for a successful compilation, I had to change find_package(FFTW REQUIRED) to find_package(FFTW3 REQUIRED) and also comment out a line in FFTW3Config.cmake (the second issue is reported here: FFTW/fftw3#130).

[trmdi]

I'm not @Luwx but I guess you can use Arch PKGBUILD, e.g. https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kdecoration

[tsujan]

@trmdi It wouldn't make a difference. I compiled BreezeEnhanced with BoxShadowHelper only by tricking (but didn't install it). As far as I see, kdecoration 5.14 can't get stable in its current form.

[tsujan]

Oh, my big mistake! FFTW is included in cmake modules (which didn't exist before). Will wrestle with it tomorrow.

[tsujan]

I couldn't wait until tomorrow (actually, it's tomorrow here). I added Breeze::BoxShadowHelper to BreezeEnhanced here and compiled it against KWin 5.13. Shadows look better now but the default intensity is changed from 35% to 100% -- I think KDE users will get confused when 5.14 comes out. Moreover, the new shadow can't be made more intense.

This is the ordinary Breeze 5.13 with a 30% shadow:

And this is the new BreezeEnhanced (not uploaded) with a 100% shadow:

The new shadow looks more realistic to me.

The changes could be uploaded so that the new BreezeEnhanced could be compiled with both 5.13 and 5.14 but I prefer to wait until 5.14 gets stable. I'm ready for it, thanks to @Luwx's comment :)

BTW, I found a way of publishing releases. When 5.14 comes out, I'll release 5.13, and the same for other versions....

[tsujan]

Oh, the new shadows have a bug when made large: they are a mess with small message-boxes. I think no one has seen it yet. The medium size is OK though.

EDIT: The problem I see may be because I use KWin 5.13.

[tsujan]

Plasma 5.14 should be released today and will come to my distro with a short delay. I still think that those box shadows have a problem when they're large but I'm ready to upgrade BreezeEnhanced as soon as Plasma 5.14 comes to Manjaro testing.

[trmdi]

/OT
Sorry to bother you, do you have a way to make this be true? https://bugs.kde.org/show_bug.cgi?id=399757
Read Chris Holand's comments. After hours played with C++ and Qt, KDecoration, I can not find one, because I'm not very good at them. I see you very good at those, can you give me some insights to continue playing with it. :P

We can get it to draw a non-animated button. Unfortunately, it's not animated.

https://gist.github.com/Zren/40f657da96e4d8a29b13d74b74e956c5

What I want is to have animated buttons (from BreezeEnhanced) to be shown with QML.

[tsujan]

You're asking that from someone who hates QML and QtQuick ;) I'm serious; IMO, QML is the worst thing happened to Qt.

[tsujan]

This is one explanation: lxqt/lxqt#1433 . There are others.

[trmdi]

Then I want to ask a Qt question.

I'm not saying about the only buttons like in the picture above. This time I created a fully client that has titlebar, window, border... from QML code, and it has the hover effect on close/min/max buttons like a normal window.

But when I try: connect(m_button, &KDecoration::DecorateButton::onHoveredChanged, [] () { qDebug() << "hmm..."})
it didn't work as expected when I move the mouse in and out of the buttons.
m_button is a object of BreezeButton class.

What am I understanding/doing wrong with connect() ? Or those buttons are not objects of BreezeButton class?

• I added that connect in this section: https://github.com/KDE/kwin/blob/master/kcmkwin/kwindecoration/declarative-plugin/previewbutton.cpp#L116

[tsujan]

@trmdi See here:

BreezeEnhanced/breezebutton.cpp

Line 57 in 4269128

connect( this, &KDecoration2::DecorationButton::hoveredChanged, this, &Button::updateAnimationState );

[trmdi]

Yes, I mean this. But no qDebug() msg is out ???
(There are some typos in my comment above)

For example, can I create an small console app that show a qDebug message when I hover on those BreezeButton everywhere ?

(A stupid idea that I didn't test yet)

// sorry, I just started to learn C++ and Qt so I'm asking so stupid questions.

[tsujan]

For example, can I create an small console app that show a qDebug message when I hover on those BreezeButton everywhere ?

I can't be sure about anything related to QML because I run away from it ;) However, if you use qDebug() in a Qt/C++ program and if debug messages aren't suppressed on you system (they aren't by default), you'll usually see the message in the terminal.

That also depends on what you do in the terminal. If the program is an app and you run it from the terminal, you'll see the message. If it's a library and you run an app that uses it, it may or may not be seen because the app can suppress it.

[tsujan]

BTW, Qt Creator suppresses qDebug() messages in its own output. I don't know whose idea it was but it was a very bad idea.

[tsujan]

Maybe a real example could help:

I use a lot of qDebug() in Kvantum when doing complex things (and remove them later). kvantumpreview and many other apps show the debug messages when I run them in the terminal but, for example, smplayer shows nothing.

I think no Qt dev codes without qDebug() ;) It's the best tool for finding and fixing bugs.