Bug 157201

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

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

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.

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

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

Maybe if you set a constant int max size for tabtext, you should set also a max size for tabBar member widget.

Right, I follow you now.

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.

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

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.

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

Feel free to beautify the code and if you like the result, just commit it.

Any news about this one? Did you test my proposal Robert?

It's june 09 , and I proposed a patch in February 09. 
And still no answer.

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

I threw up a patch at reviewboard.kde.org/r/2503 if anyone wants to try it / comment on it.

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

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

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

I liked your solution.
Maybe I could fine time to code it and give you a patch to test it.

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

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.

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