My laptop resolution is 1366x768. kcm_kscreen configuration window does not fit into my screen as it is 567x791 at minimum -- I do not see "Defaults" "OK" "Cancel" etc. If I unroll advanced settings, it is even worse: 561x840. This should be redesigned, so it fits into today standard resolutions. Reproducible: Always
I concur that the layout of kcm kscreen should be landscape oriented given today's screen resolutions (and given I want to stack second screen on top of default, so it's a bit cumbersome to drag the top screen in an already vertically crowded interface).
*** Bug 355440 has been marked as a duplicate of this bug. ***
Three comments: 1. This is reproducible always under Kubuntu 15.10. 2. Not only is the window height too high upon loading kcm_kscreen, but the window is not shrinkable. 3. By way of workaround, if you access the display configuration module via System Settings (cli systemsettings5), there is no problem with resizing or resolution.
*** Bug 357751 has been marked as a duplicate of this bug. ***
*** Bug 360251 has been marked as a duplicate of this bug. ***
That's a general problem with kcmshell not having scroll bars; affects for example energy settings as well.
*** Bug 362850 has been marked as a duplicate of this bug. ***
*** Bug 363692 has been marked as a duplicate of this bug. ***
*** Bug 364982 has been marked as a duplicate of this bug. ***
*** Bug 369133 has been marked as a duplicate of this bug. ***
*** Bug 370219 has been marked as a duplicate of this bug. ***
*** Bug 372122 has been marked as a duplicate of this bug. ***
*** Bug 372115 has been marked as a duplicate of this bug. ***
Just to make sure that the status of this problem is clear: I'm reworking this settings module and will fix this bug in the process.
*** Bug 372632 has been marked as a duplicate of this bug. ***
*** Bug 374839 has been marked as a duplicate of this bug. ***
*** Bug 374622 has been marked as a duplicate of this bug. ***
This bug has been open since 2015? I think the priority should be raised. It's a simple fix: use a UI layout that adds scrollbars. I think this ticket does not describe the issue in a way that expresses how bad it is, the user can permanently lock themselves (assuming a user that doesn't know terminal commands) out of making system changes. Here is a paste from my duplicate ticket #374839: "The Displays dialog does not show scrollbars when its size exceeds the available space. So if you change to a lower resolution, one that hides OK/Apply, it becomes impossible to change display options from then on. This bug is complemented by the fact that scaling options only apply after a reboot, the user can trap themselves"
You can move a window with Alt+LMB, so you are not locked out.
(In reply to Christoph Feck from comment #19) > You can move a window with Alt+LMB, so you are not locked out. I tried this just now, pressing Alt-L, Alt-M, and Alt-B with the screen settings open, to see what would happen. It didn't move the window, but just changed some stuff in it. Even if there is a way to move the window, it will be unknown to most, so in effect one can be ‘locked out’ because of this issue. Perhaps reducing the standard (minimal?) height of the screen layout canvas provides an easy, although perhaps not ideal fix? Not much is needed to satisfy the 786-pixel height restriction that is still common. I've noticed that this canvas scales with the window size, so people with large enough screens can still create a large canvas if they so desire.
https://en.wikipedia.org/wiki/LMB
(In reply to Christoph Feck from comment #21) > https://en.wikipedia.org/wiki/LMB That works. Anyway, “Even if there is a way to move the window, it will be unknown to most, so in effect one can be ‘locked out’ because of this issue.” still stands. For all the others that don't know the abbreviation: LMB = Left Mouse Button
@MN Simply raising the priority doesn't do much, and it shouldn't be done based on how long a bug is open alone. So we have been working on a redesigned KCM for KScreen, but it's a lot of work and not many hands helping. I've been chugging at it for some weeks, and I'm not nearly finished since other (kscreen) tasks take a lot of time as well, going over bugreports, answering them, fixing problems that prevent users from working and all that. Something that would definitely make a difference is someone helping with the work on the new KCM, or more people like Christoph who help with bug triaging. Making sure that kscreen works in all its aspects is very much a shared responsibility, and while I'm the maintainer of these components, I can only do so much on my own. The new KCM, when it lands (not before 5.10 for sure), is supposed to fix this and a series of other UI problems, improve wayland support and make the code more maintainable in the long run. On top of that, there's some more work on general usability aspects involved. Doing this without regressions is a time-consuming task costing lots of work, so help is very much welcome. You're saying that the solution is to simply add scrollbars (if I interpret it correctly, if not, please clarify). These scrollbars are in fact automatically added when you run the KCM in system settings, but kcmshell5 doesn't have this feature (a known bug). It's wrong to just add the scrollbars in kscreen's kcm as that would lead to double scrollbars in system settings, and instead of adding complex conditional magic, perhaps fixing kcmshell5 is the better option.
(In reply to Sebastian Kügler from comment #23) > > So we have been working on a redesigned KCM for KScreen, but it's a lot of > work and not many hands helping. Your and Christoph's work is much appreciated, KDE received a small donation from me triggered by your message. > It's wrong to just add the > scrollbars in kscreen's kcm as that would lead to double scrollbars in > system settings, and instead of adding complex conditional magic, perhaps > fixing kcmshell5 is the better option. I understand that adding scroll-bars is not a viable fix. However, the window is just a tad bit too high for 768 pixel height screens (namely, 801 pixels here), which I guess is the most common ‘small’ vertical resolution still in the wild in large quantities. To fix this issue for this group of users until your major reworking lands, it would be enough to gain just about 33 pixels vertically. As I indicated above, I think this can be done by making the minimal height of the screen display canvas (the rectangle where the display layout is shown) a bit smaller. It grows when the vertical height is increased, so I guess other users (with taller screens) will not be impacted. I'm curious, what is the vertical resolution of people affected by this bug (and on the Cc list)? Are there people with less than 768 pixel tall screens?
The math in Comment 24 may be a little off (one should account for the height of the default KDE task manager bar (around 32 pixels, I believe) but the general idea is absolutely correct. The screen display panel can be smaller, and, in case it is considered small for the expected use (actually I consider it too big currently), the rectangles representing the screens can be scaled down as well, without any loss of usability.
@Nikos Yet, it's more complex than that. The height of the module also depends on the font size, so that can change as well. Also, we can't just make the draggable preview smaller, since that would mean that in some cases (e.g. 1920x1080 and 1920x1600) the snapping of displays wouldn't work anymore (there are certain thresholds for that, which require a certain minimum size). I get that from a superficial point of view, it seems easy enough. If you look a bit closer, those "simple" solutions usually bring their own share of problems.
On my system I have the same problem. However, one can change the window size to some smaller size manually and it still seems to be usable. Why not implement something like if the height of a window is not fitting the screen, set the size of the window to screen size? I cannot overlook all the consequences, but isn't that a desired behavior in any case?
*** Bug 379770 has been marked as a duplicate of this bug. ***
*** Bug 380281 has been marked as a duplicate of this bug. ***
*** Bug 383648 has been marked as a duplicate of this bug. ***
So, if scrollbars can't be added to kscreen since systemsettings adds it's own set of scrollbars, what about adding scrollbars to KCMultiDialog same way it's done it systemsettings (via QScrollArea)? This theoretically should take care about systemsettings modules. kcm_kscreen specifically takes some time to initialize, which causes "kcmshell5 kscreen" to start in a very small window if scrollbars are added, but this seems like something that should be fixed in kcm_kscreen (perhaps through size hint?) However, KCMultiDialog is also used outside of systemsettings (e.g. kdepim), and those might have their own scrollbars? Also, bug 366299 and bug 360260 seem to be related/duplicates
Git commit 54090d12b3b72a07b57c17d22b15bd0f80b3c55d by Albert Astals Cid, on behalf of Valeriy Malov. Committed on 05/09/2017 at 20:18. Pushed by aacid into branch 'master'. Make KCMultiDialog scrollable Summary: Put KCModuleProxy into a QScrollArea the same way SystemSettings does This should make kcmshell and other users of KCMultiDialog a bit more friendly to small screens However, this assumes that KCMs don't have their own scrollbars (at least sytsemsettings ones don't) and preferably have a size hint (only a few or none actually have; at least kscreen needs patching) Also, reorder headers of the unit Test Plan: doesn't break systemsettings/kcmshell/kmail settings kcmshell kscreen takes some time initializing so it starts very small (patch ready) Reviewers: #frameworks, davidedmundson Reviewed By: davidedmundson Subscribers: davidedmundson, wbauer, broulik Tags: #frameworks Differential Revision: https://phabricator.kde.org/D7487 M +25 -18 src/kcmultidialog.cpp https://commits.kde.org/kcmutils/54090d12b3b72a07b57c17d22b15bd0f80b3c55d
*** Bug 366299 has been marked as a duplicate of this bug. ***
*** Bug 385680 has been marked as a duplicate of this bug. ***
*** Bug 385540 has been marked as a duplicate of this bug. ***
Sadly the fix for this issue caused Bug 389585, which is racking up a lot of duplicates. Valeriy, any chance you could look into why the KCMs' sizes aren't being propagated through to the scrollview?