Bug 356037 - Unclear indication of active tab when there are only two tabs
Summary: Unclear indication of active tab when there are only two tabs
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: QStyle (show other bugs)
Version: 5.4.3
Platform: Fedora RPMs Linux
: NOR minor
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
: 423837 434673 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-28 18:28 UTC by kdebuac.rhn
Modified: 2021-03-20 16:45 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.22
Sentry Crash Report:


Attachments
Ambiguous visual cues stemming from the lack of "active" color. (3.55 KB, image/png)
2015-11-28 18:30 UTC, kdebuac.rhn
Details
Tab focus indication that doesn't rely on tab content style (4.92 KB, image/png)
2015-11-29 23:56 UTC, kdebuac.rhn
Details
Gedit in breeze-dark gtk port (69 bytes, text/plain)
2015-11-30 17:07 UTC, kdebuac.rhn
Details
Gedit in breeze-dark gtk port (8.39 KB, image/png)
2015-11-30 17:17 UTC, kdebuac.rhn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kdebuac.rhn 2015-11-28 18:28:48 UTC
Tabs are not marked with the "active" color, making it difficult to understand which option is selected in some cases - extremely confusing with Konsole.


Reproducible: Always

Steps to Reproduce:
1. Open 2 tabs with Konsole
2. Try to guess which is currently active

Actual Results:  
Visual cues are there, but aren't clear

Expected Results:  
Visual cues are unambiguous

Using the dark version of the theme
Comment 1 kdebuac.rhn 2015-11-28 18:30:02 UTC
Created attachment 95790 [details]
Ambiguous visual cues stemming from the lack of "active" color.

Try to guess which tab is active.
Comment 2 Hugo Pereira Da Costa 2015-11-29 18:22:49 UTC
Not sure if there is any way to fix this: as long as you only have two tabs, and since they will always differ, you will not be able to know (out of nowhere) which one is the active one and which on is not. Meaning: since there is no link between the tab and the window content, "active" is only a relative concept. Or maybe you have a suggestion that would allow to unambiguously decide which one is active ? 

In any case, this of course changes when you have more than 2 tabs.
Also, the actual color convention is the same as in all other tabbars of the widget style, and for which there is a better indication about which tab is active, because it usually is effectively attached to the tabbar content. (see, e.g. Dolphin).
So that I would hope that people would get "used" to which convention is used for active and which for inactive.
Comment 3 Hugo Pereira Da Costa 2015-11-29 18:26:19 UTC
PS: one possibility would be to slightly dim the foreground color for inactive tabs. I'll give it a try.
Comment 4 Hugo Pereira Da Costa 2015-11-29 18:30:56 UTC
PS: There is no "active" color, as far as I know.
(There is: focus, hover, highlight, which is for text selection). All being shades of blue.
Comment 5 kdebuac.rhn 2015-11-29 23:55:21 UTC
This "active" confusion stems from naming in the System settings->Colors naming - it's sometimes called "Selected x" and sometimes "Active x". I suppose it just means "focus".

I believe using that color in a particular way would clear up the confusion - see attached screenshot from how Clearlooks did this with GTK.
This has the benefit of consistency - following the "focus" color from the top to bottom level will determine exactly what is shown on the screen, and also the placement on the edge will be visually distinct from custom event indications coming from the app (Konversation & Konsole change text color on tab activity).
Comment 6 kdebuac.rhn 2015-11-29 23:56:35 UTC
Created attachment 95811 [details]
Tab focus indication that doesn't rely on tab content style

Clearlooks/Darklooks GTK.
Comment 7 Hugo Pereira Da Costa 2015-11-30 15:07:01 UTC
(In reply to kdde.rhn from comment #6)
> Created attachment 95811 [details]
> Tab focus indication that doesn't rely on tab content style
> 
> Clearlooks/Darklooks GTK.

Hi, 

thanks for the screenshot. 

My argument is that in the "similar" breeze screenshot, the active tab would be as distinguishable as in these screenshot. (it is the one that is connected to the tab content, and has the same color), without needing to add the top coloured band. You agree ? 

The same is true when you have more than two tabs in konsole, and really the problem is there only for the case that you mention: only two tabs, and no tab content. I would find it a pitty to have to change the "default" look everywhere (and adding what I'd consider clutter), just for this one case. I'd rather rely on people getting "used to" how the active tab looks ...
Comment 8 kdebuac.rhn 2015-11-30 16:47:25 UTC
I'm not an UI specialist, and I haven't read the UI guidelines for any major project, but I can tell you about my experience.
I found that after a few days of using Konsole & Konversation, I still haven't gotten used to the two-tab case. More than that, three tabs have been confusing as well, but I blame it on years of using themes where highlight would make the focused tab stand out from the dark background (i.e. be lighter). Currently, it blends in with the rest of the window.
I'm sure this is possible to learn & remember, but it's not a pleasant experience and very confusing initially with the rather common 2-tab scrollview use case.

From a design staindpoint, I think it's a bad idea to bet on the content of the tab to be of a certain type, because Qt is a generic toolkit and tab content can be anything (terminal window, bitmap, scroll view, map, etc.). Therefore no, I do not agree - the theme doesn't cover a lot of the use cases of the toolkit it's built for, so it doesn't matter that it works with certain use cases.

Interestingly, Breeze-dark-gtk uses active color line on the focused tab.
Comment 9 Hugo Pereira Da Costa 2015-11-30 16:58:22 UTC
(In reply to kdde.rhn from comment #8)
> I'm not an UI specialist, and I haven't read the UI guidelines for any major
> project, but I can tell you about my experience.
> I found that after a few days of using Konsole & Konversation, I still
> haven't gotten used to the two-tab case. More than that, three tabs have
> been confusing as well, but I blame it on years of using themes where
> highlight would make the focused tab stand out from the dark background
> (i.e. be lighter). Currently, it blends in with the rest of the window.
> I'm sure this is possible to learn & remember, but it's not a pleasant
> experience and very confusing initially with the rather common 2-tab
> scrollview use case.
> 
> From a design staindpoint, I think it's a bad idea to bet on the content of
> the tab to be of a certain type, because Qt is a generic toolkit and tab
> content can be anything (terminal window, bitmap, scroll view, map, etc.).
> Therefore no, I do not agree - the theme doesn't cover a lot of the use
> cases of the toolkit it's built for, so it doesn't matter that it works with
> certain use cases.
> 
> Interestingly, Breeze-dark-gtk uses active color line on the focused tab.

Can you post a screenshot of this ? 
Do you mean, like in http://wstaw.org/m/2015/11/30/plasma-desktopkK3525.png ? (but dark)
Comment 10 kdebuac.rhn 2015-11-30 17:07:27 UTC
Created attachment 95820 [details]
Gedit in breeze-dark gtk port

The line underneath the tab indicates focus, even though tabs all share the same color.
Comment 11 Hugo Pereira Da Costa 2015-11-30 17:09:43 UTC
(In reply to kdde.rhn from comment #10)
> Created attachment 95820 [details]
> Gedit in breeze-dark gtk port
> 
> The line underneath the tab indicates focus, even though tabs all share the
> same color.

Wrong attachment it seems (the one I get by clicking is just some random text)
Comment 12 kdebuac.rhn 2015-11-30 17:17:04 UTC
Created attachment 95822 [details]
Gedit in breeze-dark gtk port

fixed
Comment 13 Hugo Pereira Da Costa 2015-11-30 17:27:53 UTC
(In reply to kdde.rhn from comment #12)
> Created attachment 95822 [details]
> Gedit in breeze-dark gtk port
> 
> fixed

Thanks !
Most instructive. I guess it was made so to match the tabs in kate (which are not the "official" ones. 
Still, my view on it is that it adds mostly clutter. 

Ok. I guess I'll try to think more about it and find a solution that makes both happy.
(note that we've had many complain about the same topic for oxygen too. I'm not sure what's wrong with this konsole tabbar, but it keeps being problematic!)

Note that the screenshot I sent before (with the blue line) is what you get when the tabbar has focus (meaning, for instance that you can navigate through tabs with the arrow keys). 

See how this somewhat conflict with using the same "highlight" color for active tab
As well as with the "light blue" you get when you mouse-over an inactive tab, to make it active.

Bottomline, I would really like to try find a solution that does not use the highlight blue, to symbolize the active tab ...
Comment 14 kdebuac.rhn 2015-11-30 18:00:20 UTC
I just looked at the tabbar focus indicator (mine is white) and came up with a solution:
If the tabbar is in focus, use one color, otherwise use another for the line [on the selected tab]. This way, there's different indication for which tab is selected and also for tabbar focus, while selected tab is clearly indicated at all times.
The line would also be consistent with the Activity Bar Plasma widget.
Comment 15 kdebuac.rhn 2015-11-30 18:23:32 UTC
After some thinking, I have another thing to add.
If I remember right, Breeze is the default theme shipped with KDE, and is the first theme newcomers are going to use. I agree that it needs to be beaufiful (no clutter) to make people want to use the software, but I'd argue that it's even more important for it to be understandable and discoverable, so that people don't get turned away from using the software at a later stage.
kde-look.org could solve part of this, but I personally found it confusing and nearly unuseable. This is a topic for another conversation though.
Comment 16 Nick Cross 2020-03-09 09:16:04 UTC
I've found it hard to distinguish (I use the Breeze Dark theme on Fedora 31 with 5.17.5) but then discovered its possible to use css to alter it:

QTabBar::tab
{
    font: 8pt;
    height: 15px;
    padding: 5px;
    border: 0px;
    min-width: 100px
}

QTabBar::tab:selected
{
    background: qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1, stop: 0 #1e5799, stop: 0.01 #2989d8, stop: 0.11 rgb(45, 45, 45));
    color: #4F89CC;
    /* Enable this to remove the blue line on selected tab */
    /* background-color: rgb(45, 45, 45); */
}


QTabBar::tab:hover
{
    text-decoration: underline;
}
Comment 17 Nate Graham 2020-07-07 19:27:51 UTC
*** Bug 423837 has been marked as a duplicate of this bug. ***
Comment 18 Nate Graham 2021-03-20 15:16:08 UTC
*** Bug 434673 has been marked as a duplicate of this bug. ***
Comment 19 Nate Graham 2021-03-20 16:18:01 UTC
Git commit 7d3c5c9b6c0ea8330462cd7999c370db764649a5 by Nate Graham, on behalf of Jan Blackquill.
Committed on 20/03/2021 at 16:17.
Pushed by ngraham into branch 'master'.

[kstyle]: Give active document tabs a thick highlight

M  +21   -2    kstyle/breezehelper.cpp
M  +4    -1    kstyle/breezehelper.h
M  +11   -2    kstyle/breezestyle.cpp

https://invent.kde.org/plasma/breeze/commit/7d3c5c9b6c0ea8330462cd7999c370db764649a5