This is a new tab style for breeze.
This is my first patch to KDE, so tell me if I did anything wrong. ;)
Closes T12842
Details
Details
- Reviewers
abstractdevelop - Group Reviewers
VDG Breeze - Maniphest Tasks
- T12842: Improving tab style in Breeze
T13054: Unify how Breeze communicates checked/current/selected states
This is a new style with a top line which should look good with both mutable and nonmutable tabs.
Diff Detail
Diff Detail
- Repository
- R31 Breeze
- Lint
Lint Skipped - Unit
Unit Tests Skipped
| kstyle/breezestyle.cpp | ||
|---|---|---|
| 5608 | Yeah we shouldn't be overriding this. documentMode is something that the widget itself can have set depending on the context. AFAIK the plan is to use documentMode to determine the style:
documentMode: false means it's a "non-editable" tab used to switch between tool views (e.g. the tabbed sidebars in Okular or Gwenview, a tabbed view in a settings window, etc) | |
Comment Actions
Address comments.
(Those were just some things I was playing around with, but everybody was right and they weren't necessary)
Comment Actions
In general I think this is a good direction to move in. However I don't think it's quite ready yet.
Small nitpick: this will result in framed tab views having rounded bottom corners, but at least one pointy top corner:
That should be easily fixable though.
I think the blue line on top is an improvement and brings the tabs closer to the Plasma appearance, which is desirable from a Goal: Consistency point of view. However I'm finding that the current tab just doesn't look distinct enough from un-focused tabs anymore. I would suggest to re-add the darkened background for inactive tabs, but then we run into T13054: Unify how Breeze communicates checked/current/selected states. Using only color to communicate the "current tab" state would jive with that, but then I start to think that we don't have enough color here and that it should look more like a Plasma tab, with a thicker highlight bar and the whole background colored. But then if we do that, we're fully abandoning @cblack's idea to make tab appearance dependent on the type of view (editable/document vs non-editable/tool view).
Bottom line, I think we need to discuss what we really want here before we move forward with implementation anymore, to avoid wasting your time!
Comment Actions
+1
I think it would still look fine with the 1px color line rounded at the top
2x
Maybe it could even be extended to the top of the outline so it's 2px, but that might be slightly hacky and/or inconsistent
Using only color to communicate the "current tab" state would jive with that, but then I start to think that we don't have enough color here and that it should look more like a Plasma tab, with a thicker highlight bar and the whole background colored
Hmm, I think that might look out of place seeing how breeze mostly uses
1px lines. I also believe that instead of coloring the entire tab background
with the highlight color, it should just use contrasting colors (selected tab
and content with view bg, the slightly darker inactive tab bg and the
outline of the tabs should work)
Comment Actions
Sorry everybody for not seeing all the new comments sooner! :D
Ok, it seems like the some corners being rounded is a common complaint, so we should address it. I agree that it looks a little out of place in System Settings. The only trouble is doing this in a way which respects the line at the top.
As for the inactive tab background, the problem is that I can't seem to find a QPalette color which is not too light/dark. The current one (QPalette::Disabled, QPalette::Window) is the best I could find, but we can go back to using the rather extreme dark one as is used in the current tabs, which IMO doesn't look good with this style. We could also make the current tab background *lighter* instead, as in manueljlins mockups where it is almost white. But that appears to be an issue left to colorshemes and not to the code. ;)
Comment Actions
The tab widget's active tab background color is something that can be played with in code--and already is, in fact. With the default Breeze color scheme, observe how it has a subtly lightened background color compared to the rest of the view background.
Since everybody loves @manualjlin's mockups, faithfully implementing those always seems like a good idea to me. :)
Comment Actions
Would you mind moving this to invent.kde.org? You'll just need to fork the breeze repo, add your fork as a remote to the existing repo you're working on and push your branch to the fork. For instance, this is what I do for myself:
git remote add ndavis_fork git@invent.kde.org:ndavis/breeze.git git push ndavis_fork
After you push, you can make a Merge Request. A link to make a merge request will even show up in the terminal when you push.
Comment Actions
Please note that should you have a KDE Developer account, then you can use a work branch instead of forking the repository.
For more information on these please see my email to kde-devel and kde-cvs-announce.
Comment Actions
Invent link in case it's useful for anyone: https://invent.kde.org/plasma/breeze/-/merge_requests/6