Bug 403059 - shrinking size of tabs
Summary: shrinking size of tabs
Status: NEEDSINFO WAITINGFORINFO
Alias: None
Product: konsole
Classification: Applications
Component: tabbar (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-10 08:52 UTC by slybzh
Modified: 2024-03-24 01:20 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attachment-9453-0.html (1.50 KB, text/html)
2019-05-20 15:38 UTC, tcanabrava
Details
attachment-28802-0.html (1.39 KB, text/html)
2019-05-21 09:49 UTC, tcanabrava
Details
attachment-31502-0.html (1.51 KB, text/html)
2019-05-21 11:29 UTC, tcanabrava
Details
restore the tabbar sizing behavior as of 18.08 (380 bytes, patch)
2019-08-28 20:54 UTC, Sok Ann Yap
Details

Note You need to log in before you can comment on or make changes to this bug.
Description slybzh 2019-01-10 08:52:03 UTC
SUMMARY
I am used to open a lot of tabs in konsole while working, and to use directory names that are quite long. Back in time (a few weeks/month ago) konsole was shrinking the size of the tabs and it was possible to fit a lot of them in one window, now after opening just around 10 tabs, some of them become "hidden". 
I understand that this feature was introduced to keep the tab names complete, but would it be possible to have an option to restore the previous behavior? 

STEPS TO REPRODUCE
1. Create a directory called "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
2. Open 4/5 tabs in this directory (depending on screen size, I guess)

OBSERVED RESULT
One of the tab become "hidden" and scroll is needed to see it again

EXPECTED RESULT
Shrinking the name of the directory to fit all tabs in the window. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Archlinux
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

ADDITIONAL INFORMATION
Comment 1 tcanabrava 2019-01-10 10:45:51 UTC
Hm, I don't think so. But we can try to solve that in another way.
first, if the tabs where small the name on it didn't really matter, so
you can rename your tabs to something that fits. Having only the icon
to identify a tab is not userful and you where switching via mental
model: you remember what's on each tab, so you can switch.

I'll implement a ctrl tab behavior to show all tabs as a list just as
it happens on kate and plasma when you do alt + tab, so switching
multiple tabs are easier.

On 1/10/19, slybzh <bugzilla_noreply@kde.org> wrote:
> https://bugs.kde.org/show_bug.cgi?id=403059
>
>             Bug ID: 403059
>            Summary: shrinking size of tabs
>            Product: konsole
>            Version: unspecified
>           Platform: Other
>                 OS: Linux
>             Status: REPORTED
>           Severity: wishlist
>           Priority: NOR
>          Component: tabbar
>           Assignee: konsole-devel@kde.org
>           Reporter: mailingprigent@gmail.com
>   Target Milestone: ---
>
> SUMMARY
> I am used to open a lot of tabs in konsole while working, and to use
> directory
> names that are quite long. Back in time (a few weeks/month ago) konsole was
> shrinking the size of the tabs and it was possible to fit a lot of them in
> one
> window, now after opening just around 10 tabs, some of them become "hidden".
>
> I understand that this feature was introduced to keep the tab names
> complete,
> but would it be possible to have an option to restore the previous behavior?
>
>
> STEPS TO REPRODUCE
> 1. Create a directory called
> "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
> 2. Open 4/5 tabs in this directory (depending on screen size, I guess)
>
> OBSERVED RESULT
> One of the tab become "hidden" and scroll is needed to see it again
>
> EXPECTED RESULT
> Shrinking the name of the directory to fit all tabs in the window.
>
> SOFTWARE/OS VERSIONS
> Linux/KDE Plasma: Archlinux
> KDE Plasma Version: 5.14.5
> KDE Frameworks Version: 5.53.0
> Qt Version: 5.12.0
>
> ADDITIONAL INFORMATION
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
Comment 2 slybzh 2019-01-10 11:25:31 UTC
Such a ctrl-tab behavior would be awesome!
And yes, I thought about renaming all tabs, and keeping only the icon but before I was using the first letters of the directory to know where I was without needing the entire name. 
The option you propose would really be great (and probably useful not only for me ^^)

(In reply to tcanabrava from comment #1)
> Hm, I don't think so. But we can try to solve that in another way.
> first, if the tabs where small the name on it didn't really matter, so
> you can rename your tabs to something that fits. Having only the icon
> to identify a tab is not userful and you where switching via mental
> model: you remember what's on each tab, so you can switch.
> 
> I'll implement a ctrl tab behavior to show all tabs as a list just as
> it happens on kate and plasma when you do alt + tab, so switching
> multiple tabs are easier.
> 
> On 1/10/19, slybzh <bugzilla_noreply@kde.org> wrote:
> > https://bugs.kde.org/show_bug.cgi?id=403059
> >
> >             Bug ID: 403059
> >            Summary: shrinking size of tabs
> >            Product: konsole
> >            Version: unspecified
> >           Platform: Other
> >                 OS: Linux
> >             Status: REPORTED
> >           Severity: wishlist
> >           Priority: NOR
> >          Component: tabbar
> >           Assignee: konsole-devel@kde.org
> >           Reporter: mailingprigent@gmail.com
> >   Target Milestone: ---
> >
> > SUMMARY
> > I am used to open a lot of tabs in konsole while working, and to use
> > directory
> > names that are quite long. Back in time (a few weeks/month ago) konsole was
> > shrinking the size of the tabs and it was possible to fit a lot of them in
> > one
> > window, now after opening just around 10 tabs, some of them become "hidden".
> >
> > I understand that this feature was introduced to keep the tab names
> > complete,
> > but would it be possible to have an option to restore the previous behavior?
> >
> >
> > STEPS TO REPRODUCE
> > 1. Create a directory called
> > "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
> > 2. Open 4/5 tabs in this directory (depending on screen size, I guess)
> >
> > OBSERVED RESULT
> > One of the tab become "hidden" and scroll is needed to see it again
> >
> > EXPECTED RESULT
> > Shrinking the name of the directory to fit all tabs in the window.
> >
> > SOFTWARE/OS VERSIONS
> > Linux/KDE Plasma: Archlinux
> > KDE Plasma Version: 5.14.5
> > KDE Frameworks Version: 5.53.0
> > Qt Version: 5.12.0
> >
> > ADDITIONAL INFORMATION
> >
> > --
> > You are receiving this mail because:
> > You are the assignee for the bug.
Comment 3 Sok Ann Yap 2019-04-19 23:37:03 UTC
Hi Tomaz, in https://bugs.kde.org/show_bug.cgi?id=396726#c4, you said:
> Any rework brings new bugs so I'm not worried and I'm activelly trying to fix the ones that are open

and I would consider this as a regression bug.

Similar to slybzh, my workflow involves opening 15~20 tabs, and relying on the previous auto-shrinking behavior to have all tabs visible without scrolling. Tabs would be spatially "grouped" together, allowing me to have let's say (from the left to right) root tabs + ansible tabs + project A tabs + project B tabs, all available and selectable visually, without having to do any manual renaming.

I am not that familiar with the code base. Are you saying that after the change to use QTabBar, it is technically not possible to get back the previous auto-shrinking behavior (e.g. due to Qt limitation)? Thanks
Comment 4 Cyp 2019-05-20 14:36:15 UTC
Tried calling setUsesScrollButtons(false), which made the scroll arrows disappear, but made the window wider than the screen instead of making the tabs narrower.

Suggestion from IRC is to use style sheets — a workaround is to create a file containing this, and set it as a style sheet in Settings/Configure Konsole/TabBar:
> QTabBar::tab {
>     width: 100px;
> }
Comment 5 tcanabrava 2019-05-20 15:01:18 UTC
What I meant is that if you have a tab that don't actually display a meaningfull information this is broken by design. (like the tabs on chrome and firefox are broken by design). 

I implemented a `ctrl + tab` feature a while ago, that will show every tab in a vertical list, that's easy to click. it's still in review tougth.

Another thing that I migth implement is a search for open tabs so it's easy to switch. But also remember that more people sending patches to fix stuff, the faster it is to add something to a software.
Comment 6 Cyp 2019-05-20 15:30:42 UTC
Having all tabs always on the screen at once with each at a fixed position can be more useful than having meaningful information, at least for some users. It's like having multiple desktops, where you know which you want to use at any time, even though it's just a grid of squares without meaningful information. If having 20 tabs in the same directory, it's hard to come up with any kind of meaningful information for them other than their order, anyway. Maybe it would be useful to have a way of adding separators between tabs, to make it easy to group tabs by category.
Comment 7 tcanabrava 2019-05-20 15:38:26 UTC
Created attachment 120202 [details]
attachment-9453-0.html

we can set tabbar->useScrollButtons(false) and each tab will still be
visible. @Nate Graham <nate@kde.org>  what you think?

On Mon, May 20, 2019 at 5:30 PM Cyp <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=403059
>
> --- Comment #6 from Cyp <cyp561@gmail.com> ---
> Having all tabs always on the screen at once with each at a fixed position
> can
> be more useful than having meaningful information, at least for some users.
> It's like having multiple desktops, where you know which you want to use
> at any
> time, even though it's just a grid of squares without meaningful
> information.
> If having 20 tabs in the same directory, it's hard to come up with any
> kind of
> meaningful information for them other than their order, anyway. Maybe it
> would
> be useful to have a way of adding separators between tabs, to make it easy
> to
> group tabs by category.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 8 Nate Graham 2019-05-20 17:08:45 UTC
Yeah, in general I think that's better usability. Scrollable tabs are pretty horrible to use. +1.
Comment 9 tcanabrava 2019-05-21 09:49:42 UTC
Created attachment 120215 [details]
attachment-28802-0.html

https://phabricator.kde.org/D21316

can you guys test and see if it helps?


On Mon, May 20, 2019 at 7:08 PM Nate Graham <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=403059
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>      Ever confirmed|0                           |1
>              Status|REPORTED                    |CONFIRMED
>
> --- Comment #8 from Nate Graham <nate@kde.org> ---
> Yeah, in general I think that's better usability. Scrollable tabs are
> pretty
> horrible to use. +1.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 10 Cyp 2019-05-21 11:17:00 UTC
Seems to help — now up to 24 tabs can squash to fit, like before. However, with 25 or more tabs, it makes the window wider than the screen (which is 1920 pixels wide), though.

I note that it's possible to scroll in the tabs with Ctrl+(Shift+)Tab, but the order seems random. Shift+Left/Right still works normally.

(In reply to tcanabrava from comment #9)
> https://phabricator.kde.org/D21316
> 
> can you guys test and see if it helps?
Comment 11 tcanabrava 2019-05-21 11:29:00 UTC
Created attachment 120217 [details]
attachment-31502-0.html

That's the best I could come up with. The tabs seems to have a minimum
width that I was not able to shrink.
*maybe* it's something we can fix inside of the breeze theme but I
sincerely don't know.


On Tue, May 21, 2019 at 1:17 PM Cyp <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=403059
>
> --- Comment #10 from Cyp <cyp561@gmail.com> ---
> Seems to help — now up to 24 tabs can squash to fit, like before. However,
> with
> 25 or more tabs, it makes the window wider than the screen (which is 1920
> pixels wide), though.
>
> I note that it's possible to scroll in the tabs with Ctrl+(Shift+)Tab, but
> the
> order seems random. Shift+Left/Right still works normally.
>
> (In reply to tcanabrava from comment #9)
> > https://phabricator.kde.org/D21316
> >
> > can you guys test and see if it helps?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 12 Sok Ann Yap 2019-05-22 04:29:29 UTC
> > Seems to help — now up to 24 tabs can squash to fit, like before. However, with 25 or more tabs, it makes the window wider than the screen (which is 1920 pixels wide), though.

> The tabs seems to have a minimum width that I was not able to shrink.

In konsole 18.08.3 (before the QTabBar change), by default, the scrollbar also starts to appear with 25 or more tabs, on a screen that is 1920 pixels wide.

Based on the phabricator change, I am able to get back the exact 18.08.3 behavior (scrollbar appearing after 25 or more tabs) with:

--- src/DetachableTabBar.cpp.orig       2019-05-22 11:24:43.341450877 +0700
+++ src/DetachableTabBar.cpp    2019-05-22 11:24:54.491383649 +0700
@@ -31,7 +31,9 @@
     dragType(DragType::NONE),
     _originalCursor(cursor()),
     tabId(-1)
-{}
+{
+    setElideMode(Qt::TextElideMode::ElideLeft);
+}
 
 bool DetachableTabBar::droppedContainerIsNotThis(const QPoint& currentPos) const
 {
Comment 13 Sok Ann Yap 2019-05-22 04:56:13 UTC
Additional info..

With the 1 line TextElideMode change above, combined with the change from https://bugs.kde.org/show_bug.cgi?id=401864, when there are 24 open tabs, I can now see "...<8 characters>" on a tab title, compared to just "...<5 characters>" with konsole 18.08.3. So it is actually a good improvement :)
Comment 14 Sok Ann Yap 2019-08-28 12:22:30 UTC
I didn't realize https://phabricator.kde.org/D21316 was already merged into the master branch, while soliciting feedback in this bug report. A couple of comments:

1. In my use case, ElideLeft is better than ElifeMiddle, as I don't really need to know what's on the left (either root or my username), but any extra character on the right will be helpful to tell the tabs apart (either cwd or hostname).

2. As mentioned above, with `setUsesScrollButtons(false)`, the window will get resized to be wider than the screen width. This can be confusing such that a newly opened tab won't be visible on the tabbar when the latter overflows. Furthermore, after closing some tabs to make the tabbar width smaller than the screen width again, the window won't get resized back.
Comment 15 tcanabrava 2019-08-28 14:21:08 UTC
Can you send patches?
Comment 16 Sok Ann Yap 2019-08-28 20:54:55 UTC
Created attachment 122407 [details]
restore the tabbar sizing behavior as of 18.08

This diff restores the tabbar sizing behavior as of 18.08:
- when a tab shrinks in size, the last bits of the title is shown (i.e. ElideLeft)
- when there are too many tabs to be shown in the window, a scrollbar appears in the tabbar (this is not great usability-wise, but still beat window auto-resizing, particularly when the window is already maximized)
Comment 17 Nate Graham 2019-08-29 01:35:04 UTC
Nice. Would yo like to submit a merge request here: https://invent.kde.org/kde/konsole/merge_requests
Comment 18 Sok Ann Yap 2019-08-29 05:02:00 UTC
Thanks, submitted as https://invent.kde.org/kde/konsole/merge_requests/25
Comment 19 Kurt Hindenburg 2019-08-29 13:05:30 UTC
Thanks for the patch - I think we used ElideMiddle so that the left and right would be shown in the theory they would be unique.
Comment 20 Kurt Hindenburg 2019-08-30 00:45:04 UTC
Git commit f79ee976fb9cefc1e365a455c56e0754cc92ddba by Kurt Hindenburg, on behalf of Yap Sok Ann.
Committed on 30/08/2019 at 00:44.
Pushed by hindenburg into branch 'master'.

Add scrollbuttons for tabs when tabbar is full

When there are too many tabs to be shown in the window, a scrollbar
appears in the tabbar (this is not great usability-wise, but still
beat window auto-resizing, particularly when the window is already
maximized)

This is part of this merge request
https://invent.kde.org/kde/konsole/merge_requests/25
I'll leave changing TextElideMode for later review.
FIXED-IN: 19.08.1

M  +0    -1    src/DetachableTabBar.cpp

https://invent.kde.org/kde/konsole/commit/f79ee976fb9cefc1e365a455c56e0754cc92ddba
Comment 21 Kurt Hindenburg 2019-08-30 00:45:14 UTC
Git commit f79ee976fb9cefc1e365a455c56e0754cc92ddba by Kurt Hindenburg, on behalf of Yap Sok Ann.
Committed on 30/08/2019 at 00:44.
Pushed by scmsync into branch 'master'.

Add scrollbuttons for tabs when tabbar is full

When there are too many tabs to be shown in the window, a scrollbar
appears in the tabbar (this is not great usability-wise, but still
beat window auto-resizing, particularly when the window is already
maximized)

This is part of this merge request
https://invent.kde.org/kde/konsole/merge_requests/25
I'll leave changing TextElideMode for later review.
FIXED-IN: 19.08.1

M  +0    -1    src/DetachableTabBar.cpp

https://commits.kde.org/konsole/f79ee976fb9cefc1e365a455c56e0754cc92ddba
Comment 22 Kurt Hindenburg 2019-08-30 00:59:22 UTC
Git commit ed44f288c2d26213e31c5b69b30a9e56ecfe8633 by Kurt Hindenburg, on behalf of Yap Sok Ann.
Committed on 30/08/2019 at 00:55.
Pushed by hindenburg into branch 'Applications/19.08'.

Add scrollbuttons for tabs when tabbar is full

When there are too many tabs to be shown in the window, a scrollbar
appears in the tabbar (this is not great usability-wise, but still
beat window auto-resizing, particularly when the window is already
maximized)

This is part of this merge request
https://invent.kde.org/kde/konsole/merge_requests/25
I'll leave changing TextElideMode for later review.
FIXED-IN: 19.08.1
(cherry picked from commit f79ee976fb9cefc1e365a455c56e0754cc92ddba)

M  +0    -1    src/DetachableTabBar.cpp

https://invent.kde.org/kde/konsole/commit/ed44f288c2d26213e31c5b69b30a9e56ecfe8633
Comment 23 Kurt Hindenburg 2019-08-30 00:59:26 UTC
Git commit ed44f288c2d26213e31c5b69b30a9e56ecfe8633 by Kurt Hindenburg, on behalf of Yap Sok Ann.
Committed on 30/08/2019 at 00:55.
Pushed by scmsync into branch 'Applications/19.08'.

Add scrollbuttons for tabs when tabbar is full

When there are too many tabs to be shown in the window, a scrollbar
appears in the tabbar (this is not great usability-wise, but still
beat window auto-resizing, particularly when the window is already
maximized)

This is part of this merge request
https://invent.kde.org/kde/konsole/merge_requests/25
I'll leave changing TextElideMode for later review.
FIXED-IN: 19.08.1
(cherry picked from commit f79ee976fb9cefc1e365a455c56e0754cc92ddba)

M  +0    -1    src/DetachableTabBar.cpp

https://commits.kde.org/konsole/ed44f288c2d26213e31c5b69b30a9e56ecfe8633
Comment 24 Kurt Hindenburg 2024-03-24 01:20:43 UTC
Let us know if you still have this issue on a recent version.