Closed trmdi closed 5 years ago
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.
Oh, don't forget to make the title-bar translucent in the above experiment!
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.
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).
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.
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 :)
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...
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: https://github.com/ishovkun/SierraBreeze/issues/50
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.
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
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
@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.
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.
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 ?
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.
... 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).
@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 :)
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.
... 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.
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.
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.
@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.
I just try SierraBreeze, it can do it somehow ???
I just try SierraBreeze, it can do it somehow ???
Really?! I'll see its code; perhaps I'm missing something.
I just try SierraBreeze, it can do it somehow ???
Really?! I'll see its code; perhaps I'm missing something.
Oh, SierraBreeze's author has done something very simple that I didn't dare to do :D It came to my mind but I was afraid it might have side effects.
I'll experiment with it under different circumstances. If it doesn't have side effects, I'll add it.
And thanks for making me do it :)
Added button spacing in the latest commit. As far as I tested, it didn't have any side effect; even absurd settings, like those in this screenshot, work fine:
I should have been braver ;)
By the way, I don't understand why people think this is a macOS title-bar -- I read some comments about that here and there. BreezeEnhanced is what its name says: an enhanced version of Breeze. Yes, its default buttons are macOS-like -- because macOS buttons are elegant -- but that's optional and there's nothing else related to macOS.
Never mind, because they don't like the macOS style. That's all. But many others like that. There is not any problem when we learn good things from others. You're doing everything very well !
because they don't like the macOS style
Strange! macOS has been always elegant. Their style developers know what they do. Anyhow, tastes differ...
Personally I like both macOS dark and light themes. Btw, what is the Kvantum theme above? Look quite nice !
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.
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.
There are any plans to update it to 5.14?
The new shadow they implemented looks gorgeous
@Luwx I tried reducing the Shadow strength to 25% and got the similar effect.
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.
Right now, https://download.kde.org/stable/plasma/5.14.0/ can't even be opened ;)
You can use the Github mirror: https://github.com/KDE/breeze/tree/Plasma/5.14?files=1
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.
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
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 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 :)
@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).
@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: https://github.com/FFTW/fftw3/issues/130).
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
@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.
Oh, my big mistake! FFTW is included in cmake modules (which didn't exist before). Will wrestle with it tomorrow.
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....
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.
Some guys would love a transparent blur titlebar for Konsole, like what SierraBreeze and BreezeBlurred can do. Will you add such an option ?