I work with multiple SSH servers at the same time and I use yakuake with multiple tabs opened. At my work place, I have a monitor with a large resolution that is able to fit all of the tabs horizontally, but when I unplug the monitor the horizontal resolution of my laptop and consequently the length of yakuake is not enough to fit all of the tabs. I can still navigate through the tabs by using shift+right/left arrows, but I cannot see which one is selected or I cannot click on the specific tab when using the mouse. Reproducible: Always Steps to Reproduce: Open many new tabs in yakuake until the horizontal tab bar of yakuake is full. Open more tabs after the bar is already full. Actual Results: After a certain amount of tabs, new tabs open but they are out of the screen. You can still navigate to them by using keyboard shortcuts, but they are not visible so you cannot click on them with the mouse. Expected Results: Horizontal tab bar should be scrollable when more tabs than the ones fitting yakuake's length are present.
Created attachment 89691 [details] A first approach to fix this bug This is an approach to fix this bug. Introduced a "dryRun" parameter in the drawButton() function. When dryRun is set to "true", the drawButton function will not actually draw anything. It will calculate the width of the tabs instead. In the paintEvent, we first run a dryRun and check if the tabs can fit to the tabbar. If not, we find the selected tab and make sure it is visible by shifting the rest of the tabs to the left. If the selected tab is the last one (the one with the last tab index), then it will appear an the very edge of the tab bar (right before the Close Session "-" button). If not, then the selected tab + 1 will appear on the edge so that the user is aware that at least on more non-visible tabs exists. This approach works really nice and produces a good result when you move through the tabs with the shortcuts or the mouse wheel, but it doesn't have a very good visual effect when you click on a tab in the case that more tabs than those can fit the tabbar exist. When a user clicks on a tab, they expect that the tab will simply be activated (and the text become bold) but stay at the same position. In this case, since the tabbar is redrawn as described above, if the user clicks on a tab, the tab will be activated and potentially redrawn at a different position in the tabbar.
Created attachment 89692 [details] Fixed a bug in the previous patch I was not using the indexOf m_selectedSessionId, so if the tabs were not removed in order from the last one, we has some problems with the next redraw.
I think the overall idea + result is good, but maybe the code would be cleaner if we simply painted the tab bar into an offscreen buffer, noted down the relevant coordinate while doing that, and then draw it to the widget at the right offset with a clip mask? It'd get rid of the extra loop and all the dryRun checks (and could lead to further improvement, e.g. it'd be fairly easy at that point to add some sort of means to scroll the overflow since we could cache that intermediate pixmap and just redraw it at different coordinates).
I will try to see if I can implement something based on your suggestion for improvement. Thanks for the feedback.
Proposed fix here (took some time): https://phabricator.kde.org/D7727