In any KCM where the options available cannot fit in the available window size, scrollbars appear, and we can scroll to access other options. In KCMs with multiple tabs, the tab bar too gets hidden when we scroll (examples of KCMs with multple tabs are 'Input devices > mouse' and 'power management > energy saving'). This behaviour is present when we access the KCM by browsing through the 'system settings' application, and also when we launch the KCM alone from krunner. It would be better to have the tab area stay visible no matter where we scroll, and scroll only the area containing the options presented by the currently active tab.
This is why I was not happy with the recently added scrollbars in kcmshell. Pages that needed a scrollbar should have explicitely adding them inside the tabs. Hopefully this will resolve over time with the ongoing KCM redesign.
Should be solved when we fix Bug 389585, so I'm marking it as a duplicate. *** This bug has been marked as a duplicate of bug 389585 ***
No, it won't if the tabs stay inside the scroll area, instead of the other way around.
If we make the scroll area respect the size hint, then the tabs shouldn't get cut off unless you manually resize the window to be small, right?
No. The sizeHint of powerdevil exceeds the screen size for many users.
So my thought for conceptually how to fix this would be to size the scrollview according to the sizeHint of the KCM within it, bounded by the screen size. So in the case of the powerdevil KCM for example, people with 1366x768 screens would get a vertical scrollbar instead of having the bottom cut off like it was before. But they wouldn't get a horizontal scrollbar that would result in tabs getting cut off, because the whole thing can fit within the 1366 horizontal pixels that they have. Does that sound sane?
Created attachment 114315 [details] Screenshot showing the issue @Nate As you can see in the attached screenshot, the tabs get cut off even when we scroll vertically. Ideally, the scrollbar would only scroll the stuff below the tab bar, leaving the tab bar always on top. I don't think this should be marked as a duplicate of bug 389585.
Ah, I see what you mean now. However, there is no possible way to fix that with the current approach of putting the content (which includes the tab view) inside a scroll view. It seems that Christoph is right, and the real solution is to redesign the KCMs to never have a minimum height that's taller than about 700 px, so they'll never get cut off on anyone's screen. At that point, we can remove the scrollview. Kishore, do you think you could collect a list of KCMs that are too tall to fit without a scrollview? Then we can focus our efforts there.
Created attachment 114330 [details] Touchpad KCM, which shows the ideal behaviour While looking through the various KCMs, I noticed that input devices > touchpad (image attached) has what I would consider the ideal behaviour (there is a scroll area inside each tab). The following KCMs did not fit without a scrollbar on a 768 px tall screen, of which maybe 20 pixels were taken up by the panel. The available height would probably be even smaller for people who don't hide titlebars and borders for maximised windows. Desktop behaviour > virtual desktops (I have 16 virtual desktops, so that might be the reason. I think the default is 9, which would *just* fit there) Display and monitor > displays (There are no tabs here, so there is no problem) Multimedia > audio volume (Not on my setup, but it could become too tall if there are 4–5 applications playing audio. I'm not sure what would happen then) Power management > Energy saving Input devices > touchpad (this behaves properly, as seen in the attached image) I'm not sure about the 'printers' KCM, since I don't have any print service installed.
Even Window Management > Window behaviour (specifically the 'focus' tab) wouldn't have fit on the screen without a scrollbar if I'd had a large panel and a titlebar.
Unfortunately I think Christoph is correct: this issue is irresolvable without redesigning the individual KCMs that have top-level tabs. The current approach of putting possibly-too-large KCMs inside a scrollview odes not allow for the possibility of solving the issue because the tabs are already insize the scrollview. :( The best we can do is enforce a maximum height for KCMs that use tabs such that when opened in kcmshell, no vertical scrollbar will ever be needed to fit the whole thing. This guideline is one that I am enforcing for new KCMs, so rest assured that over time the situation will improve. For now I'm afraid I have to close this bug since it's not really actionable all by itself. I hope you understand. Allow me to once again emphasize that this will be solved over time as the KCM redesign project progresses.
(In reply to Nate Graham from comment #11) > The best we can do is enforce a maximum > height for KCMs that use tabs such that when opened in kcmshell, no vertical > scrollbar will ever be needed to fit the whole thing. Is there some technical issue that prevents putting the scrollbars inside the tabs like in the touchpad KCM, or is that what you mean by enforcing a maximum height?
In fact that's the plan. But because it involves re-doing individual KCMs, there's no one solution we can use this bug for tracking. If you want to follow the KCM redesign project, see https://phabricator.kde.org/tag/plasma_kcm_redesign/
In Settings > Window Management > Window Rules, the windows that open when we click 'new rule' and 'modify rule' are also too big, and should have scrollbars. This particular window doesn't seem to be mentioned in the Phabricator page linked for the KCM redesign.