Created attachment 183058 [details] Screenshot of file type/import filter listbox with GTK3 When opening a file in LibreOffice, one can select among several dozens of file formats. This is good, but - the selection uses a plain listbox, which: 1. has no scrollbar 2. doesn't let you search by substring 3. fills your whole monitor height because it's so big 4. doesn't even have an obvious sort order that's bad. Seeing this on Linux with gtk and kf5 VCLs. Build ID: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: a09c5c69e3b5fbf448cae1d6c476f39067e40023 CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
Created attachment 183059 [details] Screenshot of file type/import filter listbox with KF5
This is particularly annoying when you want to open a PDF file, and not have it opened in Draw, i.e. auto-detect doesn't do what you want.
And? For Windows os/DE the default "All files (*.*)" lists the filters and they can be scrolled. And os/DE provided search is limited to "first character". The list are the import filters. Autodetection is done by the document model for the module with edit focus. Opening with any other import filter requires selection from the listbox. The list is organized, grouped by LO module, with separators supplied for visual que. That organized list of filters is provided crossplatform and integrated into os/DE norms. Absence of scrollbar or ability to search is an os/DE issue. We only control LibreOffice's Internal File dialog (set from Tools -> Options -> General checkbox 'Use LibreOffice dialogs') (bug 88180). It is default on the vcl=gen. But it provides a scroll of the filters. Yes there are a lot of filters, but doing more would require we either force use of the Internal File dialog (won't happen, i.e. bug 114484) or that we extend the native dialogs of each os/DE more than is currently integrated. We now provide our filter list and a small set of filter controls. Doing more would require too much native code and offer no real benefit. Some curating of the list of filters and additional filter controls is possible, but the long list filters is not going away. IMHO => NAB
I should also mention that, with GTK3, one cannot even navigate the list by typing the prefix of the desired item. (In reply to V Stuart Foote from comment #3) > For Windows os/DE the default "All files (*.*)" lists the filters and they > can be scrolled. And os/DE provided search is limited to "first character". Possible; I should have marked this bug as Linux-specific, and now I have. > The list is organized, I disagree. Or rather, it can't really be organized, as users's expectations of order will differ, or probably be not well-enough defined. > grouped by LO module, No,, they aren't grouped by LO module. But I'm not complaining about that. > with separators supplied for visual que. No separators - see the screenshot. But that's not what I'm complaining about. > Absence of scrollbar or ability to search is an os/DE issue. Perhaps, but - that doesn't matter. That is, LO needs to provide the user with a usable file open dialog, and a non-scrollable list box for dozens and dozens file types / import filters is extremely inconvenient. The OS/DE may not consider this to be a bug, since it may be making the assumption that the list is not very long - expecting apps not to have as many options, or to use additional controls to narrow the list down etc. And the fact that two difference VCLs have the same issues strengthens the possibility that this is the assumption. That's why this can't simply be dismissed as NOTOURBUG. We should first consider whether we should use additional filtering controls in the file open dialog (which are available IIANM); and we should also contact the authors of GTK and KDE Frameworks respectively about this issue. > We now provide our filter list and a small set of filter controls. Doing > more would require too much native code and offer no real benefit. Which small set of filter controls?
It's the file open dialog from the OS/DE and your DE provides scroll interactions on top and bottom. Other systems, if used with this small screen size, might behave differently. But in any case we cannot change this (unless we remove some filters and use different commands like "Save As Microsoft Document", "Save as Adobe Document" etc. which is bad since users prolly don't know who owns Lotus these days, for example.
(In reply to Heiko Tietze from comment #5) > But in any case we cannot change this > (unless we remove some filters and use different commands like "Save As > Microsoft Document", "Save as Adobe Document" etc. which is bad since users > prolly don't know who owns Lotus these days, for example.) Ah, but we can change this - by instituting two-level filtering! We add another list, of input filter categories; and reset the filters in the OS/DE dialog based on the selection in that list. Most/all categories will now be small enough to fit nicely on the monitor.
Such a multi-step selection would be very annoying for users who know what they do, eg. scroll down a couple of items to pick the filter "Foo". We would not only change a familiar workflow, and make it cumbersome for simple tasks but also have to categorize the list into chunks that works better - which I doubt is possible, as commented before. => NAB/WF
(In reply to Heiko Tietze from comment #7) > Such a multi-step selection would be very annoying for users who know what > they do, eg. scroll down a couple of items to pick the filter "Foo". 1. But they can't do that. They have to scroll down several screens to get to what they want. And sometimes, they can't even scroll and have to press a bottom-of-screen arrow button. 2. The default higher-level selected item would be something like "common filters" or "recently-used filters" etc. > We would not only change a familiar workflow, A bad workflow. That is, it's not what we usually do. Usually, we just let the app auto-detect the filetype. Otherwise, on average, you have to scroll through half the list. > and make it cumbersome for simple tasks It's currently extremely cumbersome to perform the simple task of filter selection.