Bug 157201 - tab names in konsole should have a maximum size
Summary: tab names in konsole should have a maximum size
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 157363 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-05 13:05 UTC by manolis
Modified: 2010-09-10 04:24 UTC (History)
3 users (show)

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


Attachments
demonstration of the wrong text clip (38.01 KB, image/png)
2008-05-06 16:56 UTC, manolis
Details
Uninformative tab text when trimmed (166.12 KB, image/png)
2008-07-10 19:33 UTC, Alexey Charkov
Details
proposed patch (1.55 KB, patch)
2009-02-03 19:09 UTC, manolis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description manolis 2008-02-05 13:05:49 UTC
Version:            (using KDE 4.0.0)
Installed from:    Gentoo Packages
Compiler:          gcc 
OS:                Linux

The tab names in konsole I think should have a maximum size option , so if someone uses for the tab name the %directory, it will not be too long for another tab to fit in the tab bar.
Comment 1 Robert Knight 2008-02-07 21:38:52 UTC
*** Bug 157363 has been marked as a duplicate of this bug. ***
Comment 2 Robert Knight 2008-03-18 03:40:13 UTC
SVN commit 786861 by knight:

Limit tab names to a maximum of 20 characters to prevent one or two tabs
from taking up the entire width of the tab bar and requiring the user to scroll
to see more.  Longer tab titles are trimmed to the right-most 20 characters
with an elide inserted at the front.

BUG: 157201


 M  +14 -1     ViewContainer.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=786861
Comment 3 manolis 2008-05-06 16:25:51 UTC
The fix works ok, but it is also ugly.
The correct way is to :
use a QFontMetric for QFont of tabText (Really how can you query for the QFont of QTabBar ? )

crop the over-laying characters by comparing with tabRect , and add the "..." if a crop is done.

Now as the fix is, even with only one tab and a big space, the name is being cropped to 20chars.
Comment 4 Robert Knight 2008-05-06 16:52:07 UTC
> use a QFontMetric for QFont of tabText (Really how can you query for
> the QFont of QTabBar ? )

QWidget::font()

> crop the over-laying characters by comparing with tabRect ,
> and add the "..." if a crop is done. 

The size of the rect returned by tabRect() depends on the length of the tab's text.  In other words, tabRect() expands to accommodate the text.   

> The fix works ok, but it is also ugly. 

It looks fine from my perspective.  If you can attach a screenshot showing the problem I'll see if I can come up with a solution.  
Comment 5 manolis 2008-05-06 16:56:46 UTC
Created attachment 24648 [details]
demonstration of the wrong text clip

As you can see the space is enormous, and yet the tabname, is righted on
20chars.

ps. Didn't know that about tabRect, .... :-) so it's useless to use that QRect
Comment 6 manolis 2008-05-06 17:06:57 UTC
Maybe if you set a constant int max size for tabtext, you should set also a max size for tabBar member widget.
Comment 7 Robert Knight 2008-05-06 17:43:53 UTC
Right, I follow you now.
Comment 8 Alexey Charkov 2008-07-10 19:33:04 UTC
Created attachment 26019 [details]
Uninformative tab text when trimmed

Here is a demonstration of how trimming the tab name makes the resulting text
completely uninformative (compare the window title to the first tab's title).
Probably it would be a better idea to make the visible portion of the string
dependent on the actual free space as suggested, or at least to provide an
option to configure/disable this kind of trimming?

Another crazy suggestion is to make the tab caption scroll by as mouse hovers
over the tab: moving the mouse towards the leftmost edge of the tab could make
the beginning of the title show, and vice versa. Moving the mouse out of the
tab area would then leave the last text shown.
Comment 9 manolis 2009-02-03 19:07:02 UTC
I propose a patch for this bug. 
the updateTitle() is not a good place to chop the text because on tabremoval it remains choped.
I propose a tabSizeHint patch to set the maximum size of the tabBar in an analog way for numOfTabs<5 and a constant size for >5.
This way in a removal of a tab, the others are using the extra space and are not trimmed.
Also notice the 0.5 factor inside the code that gives a tabSize/2 empty space on the left for numOfTabs<5 so the user can double click easily to create a new tab.

patch follows
Comment 10 manolis 2009-02-03 19:09:45 UTC
Created attachment 30928 [details]
proposed patch

I have an svn account, but because I don't have experience, I post here
the patch to review it and test it.
Comment 11 Robert Knight 2009-02-03 21:46:57 UTC
> I propose a tabSizeHint patch to set the maximum size of 
> the tabBar in an analog way for numOfTabs<5 and a constant size for >5. 

Minor style issue.  Magic numbers should generally be avoided because it isn't obvious where they come from and whether they have any significance other than 'this looks about right'.  Instead:

const int descriptionOfValue = < Some Integer Value >;

Comment 12 manolis 2009-02-03 21:58:21 UTC
Feel free to beautify the code and if you like the result, just commit it.
Comment 13 manolis 2009-03-19 18:44:15 UTC
Any news about this one? Did you test my proposal Robert?
Comment 14 manolis 2009-06-29 09:36:13 UTC
It's june 09 , and I proposed a patch in February 09. 
And still no answer.
Comment 15 Kurt Hindenburg 2009-12-30 05:20:17 UTC
The patch from #10 doesn't really work.  There needs to be a way to display the right most of the folder you are in (using %D).  I think the front string needs truncated as the original code had it with preprending "...".

I'll see if I can put something together for 4.4.1
Comment 16 Kurt Hindenburg 2010-01-05 06:19:49 UTC
I threw up a patch at reviewboard.kde.org/r/2503 if anyone wants to try it / comment on it.
Comment 17 manolis 2010-01-21 11:30:23 UTC
Agree that there was a need for ellides (...) .
The proposed patch I made was more for the sizeHint of the tabs, that is treated depending on the number of tabs.
Also as Robert Knight mentioned magic numbers are to be avoided so:
5 = maxVisibleTabs
Comment 18 Matthew Woehlke 2010-01-21 18:10:19 UTC
> 5 = maxVisibleTabs

I think you meant *min*VisibleTabs.

I have nine currently open in the Konsole instance on my other screen, with plenty of room for a tenth before scrolling needs to kick in. Making the /max/ five would be silly :-).
Comment 19 Matthew Woehlke 2010-01-21 18:27:15 UTC
Okay, so you all have made me think about this. The "arbitrary" sizeHint (as I think is already realized) isn't ideal. Better would be to allow one really long tab and two short tabs, when they can all fit. Unfortunately doing this is not very easy.

I think what needs to happen is this: whenever the tabs need to be re-layout (either resize, addition/removal, or text change), build a list of needed sizes from the text metrics plus the style metrics for how much larger than the text the tabs need to be. Add all these up and sort them.

If it is less than the size available, take the smallest one, and make it the size of the next smallest one, or increase its size so that the sum equals the available space, whichever is less. Continue this process until the sum is the available space. (In case of multiple equal-sized tabs at either end of the list, apply the resize to all of them. This goes for the other branch also.)

If it is more than the available size, take the largest one and make it the size of the next largest one, or decrease its size so that the sum equals the available space, whichever is greater. Continue this process until the sum is the available space. If at any point this would be making a tab smaller than some determined minimum size, use instead the minimum size and give up (allow scrolling of the tab bar).

Note that tabs whose text fits are allowed to be smaller than the minimum size. Also, at the 'give up and allow scrolling' stage, I wonder if maybe it would be good to allow the tabs to be larger than otherwise to show more of the text, or if that is still undesirable to maximize the number of visible tabs regardless of scrolling.

That said, don't get me wrong, I am in favor of something along the lines of the current patch as an improvement on the current situation; let's start with "better" and work toward "best", not get hung up on "it must be perfect". My only concern there is that the sizeHint is actually a *max* width and Qt will still make the tabs smaller as permitted by the text. This seems to be the intent, but I didn't actually test the patch to verify that it doesn't act as a minimum size instead (which, as per my previous comment, would be... undesirable).
Comment 20 manolis 2010-01-21 22:56:55 UTC
I liked your solution.
Maybe I could fine time to code it and give you a patch to test it.
Comment 21 Kurt Hindenburg 2010-04-17 23:35:00 UTC
SVN commit 1115895 by hindenburg:

Change the way the tab widths are calcuated and their text to allow better space usage.

Patches/comments to make this better welcomed. I wanted something committed for KDE 4.5.

CCBUG: 157201


 M  +24 -12    ViewContainer.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1115895
Comment 22 Stefan Becker 2010-09-05 19:40:17 UTC
I'm not sure, but I think what has been committed for KDE 4.5 has broken the tab code to use an excessive minimum tab size (see bug #166573).

Now konsole will not reduce the tab size below a certain size (145 pixels?) even if there is plenty of white space around the tab text. This is very annoying for people like me who use a LOT of tabs with short mnemonics to avoid tab scrolling.
Comment 23 Kurt Hindenburg 2010-09-10 04:24:28 UTC
SVN commit 1173668 by hindenburg:

Change the way tab width is determined by using min/max stylesheet.

BUG: 166573
BUG: 189847
BUG: 157201


 M  +3 -21     ViewContainer.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1173668