Description: Issues like tdf#160937 are filed for the dialogs that do not fit on the screen. While this one may be improved and fixed later in specific settings with putting less contents on a page of the dialog, this is not always the case. As I have described on tdf#160937 comment 8, with a display that uses 2x or 3x scaling, you may find many dialogs go out of the screen, and there is no easy way to use the main buttons. Steps to Reproduce: 1. Use a HiDPI display with Linux. 2. Set 2x or 3x scaling (or even more) in GNOME settings. 3. Use gtk3 UI for LibreOffice, which should be the default one. 4. Try opening dialogs like "File > Properties", or "Tools > Options". Actual Results: Main buttons of the dialog may fall out of the screen, and there is no way to see them. You can use them blindly by using tab, but that is hard. Expected Results: All parts of the UI should be visible and usable by the user. In case it is hard to make it happen, at least some sort of fallback should be provided. For menus, there is a scrolling mechanism that does that. But there are no workarounds for dialogs. Additional Info: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Possible solutions: There are many solutions that can be suggested. Both for the design, and also for the fallback mechanism. For the design, the way "Settings" in GNOME 40+ is implemented, and also the way "Settings" in Windows 11 is implemented can be inspiring. They use 2 scroll areas, one for the section names+icons, and another one is each of the pages. In this way, settings will be usable on most display configurations. GNOME Settings: Utility to configure the GNOME desktop https://apps.gnome.org/Settings/ Windows 11 settings page https://windowsreport.com/windows-11-your-microsoft-account-settings/ For the fallback, there are many options, from resizing, to scrolling, scaling and even moving. I hereby describe some of these: Scrolling: use scrollbars for each an every dialog, so that when it is too big, it can be at least scrolled. This may be done in the code, and not with changing each and every UI files. Resizing: Make the dialog resizable if it does not fit on the screen. It may need scrolling. Scaling: scale the UI, partially or selectively, to make the dialog fit on the screen. Moving: move the dialog, when user moves the mouse to the edges of the dialog, or when tab key is used to jump to a control that is off the screen. This is actually used in some UI toolkits.
Minimum requirements are 1400x900px at 100% scaling. We cannot guarantee that our (non-responsive) UI works on all environments.
(In reply to Heiko Tietze from comment #1) > Minimum requirements are 1400x900px at 100% scaling. We cannot guarantee > that our (non-responsive) UI works on all environments. OK, it seems that my screen is less than that when I divide the width and height by 2. But, what do you think about the fallback mechanism?
Thought there was a duplicate ticket but cannot find any. Caolan, what do you think about some automatic scrolling window as fallback solution?
The specific case of tdf#160937 is really just a bug in that particular dialog, there should be at least an explicit scrollarea in its description page. Note that f.e. under GNOME the file open and file save dialogs are not "our" dialogs, but the stock ones, and we have no power to put their content into a scrollable region, so I don't think there is any point worrying about anything smaller than those dialogs. If those don't fit on screen, then presumably basically nearly every application on the desktop has dialogs that don't fit on screen. The options dialog is a pain point in that there are so many possible pages that it basically has a hard coded size (unlike the others which auto-size to fit what their contents need) which people keeping bumping up larger and larger :-( It would be nice to back out the series of size bumps and fix the individual reasons for those increases. I kind of feel scrollable dialogs are a bit of a bodge and better to see it as a warning that the dialog is nasty and needs fixing.
(In reply to Caolán McNamara from comment #4) > I kind of feel scrollable dialogs are a bit of a bodge and better to see it > as a warning that the dialog is nasty and needs fixing. I agree, I think it's good we have a minimum resolution we need to support without the need for scrollbars, and a dialog (or menu) overflowing means we need to improve it by reviewing the layout, keeping things brief, moving features to a more suitable spot, or considering if anything needs culling. If users need a larger scaling for readability / accessibility reasons, there are alternatives like GNOME's Zoom tool. But maybe Michael also has an opinion on the accessibility aspect?
(In reply to Stéphane Guillou (stragu) from comment #5) > (In reply to Caolán McNamara from comment #4) > > I kind of feel scrollable dialogs are a bit of a bodge and better to see it > > as a warning that the dialog is nasty and needs fixing. > I agree, I think it's good we have a minimum resolution we need to support > without the need for scrollbars, and a dialog (or menu) overflowing means we > need to improve it by reviewing the layout, keeping things brief, moving > features to a more suitable spot, or considering if anything needs culling. > > If users need a larger scaling for readability / accessibility reasons, > there are alternatives like GNOME's Zoom tool. > > But maybe Michael also has an opinion on the accessibility aspect? The above sounds reasonable to me.
Created attachment 194722 [details] Paragraph properties with vertical tabs Assuming we change the dialog layout we end up with dialogs like this. I could imagine to have only one column of controls and a scrolled window behind (perhaps with an expander). Meaning: Tabs | Options | Preview | | | | v |