Bug 356037

Created attachment 95790 [details]
Ambiguous visual cues stemming from the lack of "active" color.

Try to guess which tab is active.

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.

PS: one possibility would be to slightly dim the foreground color for inactive tabs. I'll give it a try.

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.

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).

Created attachment 95811 [details]
Tab focus indication that doesn't rely on tab content style

Clearlooks/Darklooks GTK.

(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 ...

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.

(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)

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.

(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)

Created attachment 95822 [details]
Gedit in breeze-dark gtk port

fixed

(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 ...

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.

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.

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;
}

*** Bug 423837 has been marked as a duplicate of this bug. ***

*** Bug 434673 has been marked as a duplicate of this bug. ***

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