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 |
(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. Where is this minimum coming from? Our site says: https://www.libreoffice.org/get-help/system-requirements/ 1024x768 resolution (higher resolution recommended), with at least 256 colors
(In reply to Buovjaga from comment #8) > Where is this minimum coming from? https://wiki.documentfoundation.org/Design/Guidelines/MenuBar
(In reply to Heiko Tietze from comment #9) > (In reply to Buovjaga from comment #8) > > Where is this minimum coming from? > https://wiki.documentfoundation.org/Design/Guidelines/MenuBar Ok, so 1024x768 was correct still.
(In reply to Buovjaga from comment #10) > Ok, so 1024x768 was correct still. The UI is designed to be usable with at least WXGA resolution; XGA is not sufficient.
(In reply to Heiko Tietze from comment #11) > (In reply to Buovjaga from comment #10) > > Ok, so 1024x768 was correct still. > The UI is designed to be usable with at least WXGA resolution; XGA is not > sufficient. https://en.wikipedia.org/wiki/Display_resolution#Common_display_resolutions WXGA 16:9 is 1280x720 while 16:10 is 1280x800. I skimmed the MenuBar article too quickly, it refers to a resolution that is a hybrid of XGA and WXGA: 1280x768px. I'll bring this to the ESC this week as clearly we have cleaning up to do.
Wait, the issue is *not* our current minimum 1024x768px at 100% resolution, rather it is the way each DE implements display scaling. Stéphane had pointed this out: https://bugs.documentfoundation.org/show_bug.cgi?id=160937#c10 Effectively we design for 1024x768px at 4:3--though I actually think it should be at a 16:9 or FWXGA 720p (1360/1366x768px) since we provide Impress template graphics at 16:9--but in reality the stated system display requirement must be recalculated upward by user when simple x1.5, x2, or x3 affine transform scaling is in use by the users DE. That needs to go into the system requirements. Windows WDM, either scaling mode, handles the subframes correctly. So little noise from that group of users. Don't know about the other back ends/DEs.
(In reply to Buovjaga from comment #12) > (In reply to Heiko Tietze from comment #11) > > (In reply to Buovjaga from comment #10) > > > Ok, so 1024x768 was correct still. > > The UI is designed to be usable with at least WXGA resolution; XGA is not > > sufficient. > > https://en.wikipedia.org/wiki/Display_resolution#Common_display_resolutions > > WXGA 16:9 is 1280x720 while 16:10 is 1280x800. > > I skimmed the MenuBar article too quickly, it refers to a resolution that is > a hybrid of XGA and WXGA: 1280x768px. > > I'll bring this to the ESC this week as clearly we have cleaning up to do. Wiki and website content now harmonised to 1280x800.
(In reply to Buovjaga from comment #14) > > Wiki and website content now harmonised to 1280x800. Sure path of least resistance 16:10, but what is the actual supported display metric 1024x768 (4:3) 1366x768 (16:9) or 1280x800 (16:10)? And what we'd need to use for our raster artwork/template design? Also, recall that for Hardware Acceleration keeping the raster frame size below 2^20px made the 16:9 HD at 1360x768 (16:9) resolution framing appealing--needing just 1MP of memory for accelerated graphics. Which the 1280x800 (16:10) also achieves. While 1366x768 bumps HA requirement above 1MP.
WXGA at 1366x768px at ~16:9 is the more common laptop display resolution, 1280x800px at 16:10 is kind an oddity, and native hardware is unlikely in use. But, could argue that layout and graphics designed for 16:10 is appropriate for the macOS community. Anyhow, don't think it makes *too* much difference if folks understand the impact that DE scaling can have. https://en.wikipedia.org/wiki/Display_resolution_standards#WXGA
1280x800 used to be a common resolution of laptop screens fifteen-ish years ago, but probably not very many of them are still in use. Laptops with 1336x768 screens, however, are still in use in non-trivial numbers. According to Statcounter, 1366x768 currently accounts for 12.54% of desktops: https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide Even on Steam, 3.42% of users have a 1366x768 screen: https://store.steampowered.com/hwsurvey IMO, for supporting old hardware, supporting 1336x768 screens is currently more important than supporting the remaining users of Windows 7 and 8, for example. 1280x720 would be a safe baseline for supporting anything remotely modern, but I'm not confident that all dialogs in LO would currently fit in that space in terms of vertical space.
OTOH if a menu or a dialog is too complex to fit on screen in 720p, maybe it's not ideal from usability point of view in any resolution, anyway, and would benefit from reorganisation...