https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c3 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #3 from Stefan Hundhammer --- Unlike the simple YaST Qt control center, the YaST Qt UI (libyui-qt) does not save its window size and position to a config file and restores it upon the next restart; rather, it has a quite elaborate algorithm to calculate the initial size of "default size" (wizard-style) windows: https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQUI.cc#L360-L407 The starting point of this is whatever Qt considers the "primary screen": https://doc.qt.io/qt-5/qguiapplication.html#primaryScreen-prop So it will take the size of your primary screen, and since all of your screens are larger than 1024x786, it will use 70% of it for both dimensions. This usually works well. But if the dimensions or, as in your case, even the orientation of a multi-screen setup are radically different, problems like the one you described can occur: The initial calculation can be way off. The problem may be that Qt made a wrong decision what exactly is your primary screen. Maybe that can even be configured somewhere (in KDE? With xrandr?), but if yes, I don't know where. As a workaround (admittedly a kludge) I could offer using the -geometry command line option when starting a YaST module from the command line; like this: yast2 -geometry 1000x800 module_name or yast2 -geometry 1000x800+0+0 module_name -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c5 --- Comment #5 from Stefan Hundhammer --- I am not sure if a generic method to avoid this situation wouldn't backfire for a number of other users. If we limit the size to the smaller screen, I could imagine users of embedded systems running into the opposite problem: If you have a very small display and a decent-sized one, would you really want to limit everything to the size of that small one, in many cases making YaST windows unusable? Before we start working on a dramatic change, please check if you can configure what Qt considers its "primary screen". It might be a setting in your KDE desktop somewhere. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1192148 Jos� Iv�n L�pez Gonz�lez changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED URL| |https://trello.com/c/n0tcEE | |LH Assignee|yast2-maintainers@suse.de |yast-internal@suse.de -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c8 --- Comment #8 from Stefan Hundhammer --- Robert, I understand you, and in a use case such as yours it's not optimal; fully agreed. But I fear when we start tinkering in this area, for every user we make happy (or let's say a little bit happier), there will be 5-10 that will become unhappy instead with a changed behaviour. We have to cover a lot of use cases. A very common one used to be laptop users who connect an external monitor; some of them won't use the laptop display at all when the external monitor is connected, some may use it, if only as a secondary display for their IRC client or some similar secondary task. If the laptop display has significantly less resolution, the user will probably want to disregard it for this initial size calculation. Similar with smallish displays for embedded devices (RasPI etc.) that also have an external monitor. So it's not easy at all what to consider for those initial dimensions; we can't simply iterate over all screens and limit our size to the smallest one (in both dimensions, of course). We have to choose carefully which ones should influence that decision and which ones should be disregarded. Your use case is extreme; we could at least try to limit the size to a normal aspect ratio: 9:16 (i.e. 16:9 in portrait orientation) with really large resolution is not useful for any YaST module. And then there are our friends, the HiDPI monitor users, who introduce yet another completely different aspect into this equation: They do use insane resolutions, and they need them to make fonts and icons big enough so they can read anything and recognize the icons. It's difficult; we are trying a one-size-fits-all approach here, and that's not so easy if you have to consider dwarves as well as giants as well as normal people. Or, as in your case, a Siamese twin consisting of a giant and a dwarf at the same time. ;-) -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c10 --- Comment #10 from Robert Simai --- Once more many thanks for all the background, I understand there's no easy solution and I at least know how to work around for my setup. One correction however, in my case it's not Siamese twins but triplets ;-) -- You are receiving this mail because: You are on the CC list for the bug.