Version: 4.0.2 (KDE 4.0.2) (using 4.0.2 (KDE 4.0.2), Kubuntu packages) Compiler: gcc OS: Linux (i686) release 2.6.22-14-generic I find the new konq 4 tab behavior to be much less usable than the old konq 3 behavior. Before, I liked how adding more tabs would cause the tabs to shrink, rather than adding the scroll widget for the tabs. The scrollbar just makes it very difficult to select tabs. It looks like in konq 4 there is _no_ shrinking of tabs at all, so I get the scrollbar with the 5th tab I open. Firefox 2 also adds a scroller, but there is shrinkage of the tabs first, and I can get 9 tabs open before the scroller comes up. So --- I think there should either be a configuration option to never show the tab scroller, or there should be some shrinkage of tabs so that at least 8 or 9 tabs can be open before the scroller comes up.
I don't understand why tabs being too wide is a bug in konsole (Bug 157201) but a wish for konqueror.
I fully agree! Opera never shows any scroll-arrows but just squeezes the tabs, so one should be able to do the same. But even if scrolling is considered useful after a certain amount of tabs (much higher than the current number) it does not make sense to display the scrolling arrows at the right of the tabs because if one scrolls left one has to move all the way to the left again to actually get to the tab one scrolled to. The latter is the reason why firefox places the arrows on the side they are meant to scroll to.
http://doc.trolltech.com/4.3/qtabwidget.html#usesScrollButtons-prop There is a bool that can disable the scrolling, which is suboptimal, because it should rather be fixed to squeeze more and make scrolling usable, but at least this would get back the 3.5 usability.
Seems to work in trunk (2008-05-01) without close buttons shown on the tabs, but still doesn't work correctly when the close buttons are enabled.
Changing this to be a bug, because insufficient calculation of tab sizes *is* actually a bug. The following patch also solves the case with close buttons shown, but not in the totally cleanest way. Should I apply this anyways (after all, it solves a real issue) or do you have an idea on how to implement it in a cleaner way?
Created attachment 24583 [details] A patch solving the case with close buttons enabled. Not the cleanest patch ever, but it works.
Reassigning to kdelibs, as KTabWidget is in kdelibs/kdeui and probably affects more applications than just Konqueror.
Bah, why doesn't that "assigned" mail address change if I reassign the component? Anyways. Also, CC'ing Peter Penz as he wrote the current close button and also uses it in Dolphin. (Hi Peter, and thanks for the super nice close button and tabs in Dolphin!)
SVN commit 804578 by jpetso: If someone wants to properly factor the size calculation of the additional space for the close button from KTabWidget to KTabBar (where the close button is drawn), please do so by any means. For now though, I just want tab icons + close button to autoshrink correctly in my Konqueror (only adding tab scroll arrows when they're actually needed), and this makes it work. BUG: 159951 M +4 -0 ktabwidget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=804578