Description: LibreOffice's GTK3 FileChooser has the nice ability to filter down the view by file type with semi-broad filters such as "Spreadsheets", which will include .ods, .xls, .xslx, .csv, etc. The problem is that it never remembers that it's actually what I want to see everytime instead of "All files", and all in all I think it should actually be the default behavior because it just makes more sense to filter file types to show only those relevant to the current running application (ex: LibreOffice Calc) where the FileChooser was called from (and users can always select "All files" in the rare cases where they actually need something else). Either that or it should remember if I chose one of those metafilters (Documents, Spreadsheets, Presentations,...) last time. This would reduce visual overload in the FileChooser and allow me to find relevant files much more quickly. I would also recommend vastly simplifying the choices in the mimetypes filtering combobox. Currently there's half a million choices, one for each type and one for each specific file format, and it's hard to use: the list is incredibly long, not sorted in a way that makes sense, and requires scrolling multiple screen heights. Nobody cares about such precision as specific file formats (or they would use the filechooser's search feature on top of filtering). I would say that you really only need these filters in practice: -------------------------------- - All files - Files LibreOffice can open -------------------------------- - Documents and master documents - Spreadsheets - Presentations - Images, drawings and formulas -------------------------------- - Web pages - Templates -------------------------------- Steps to Reproduce: 1. Open LOo Calc on Linux+GNOME (GTK3 version) 2. Ctrl+O 3. Navigate to some folder where you're looking for your spreadsheet to open Actual Results: You see a bunch of files unrelated to spreadsheet formats that LibreOffice can open Expected Results: Show only "Spreadsheets" type files (default to that in the mimetype filtering combobox at the bottom of the file chooser; if I wanted to see all possible files I would explicitly go there to show all files) Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
(In reply to Jean-François Fortin Tam from comment #0) > I would also recommend vastly simplifying the choices in the mimetypes > filtering combobox. Currently there's half a million choices, one for each > type and one for each specific file format, and it's hard to use: the list > is incredibly long, not sorted in a way that makes sense, and requires > scrolling multiple screen heights. Nobody cares about such precision as > specific file formats (or they would use the filechooser's search feature on > top of filtering). This is huge oversimplification based on ignorance. Usually bold statements like starting with "nobody" or "everybody" are such. Actually, choosing the right file type allows to make the application to apply specified import filter to a file (so that some ambiguous cases, like csv named dat, or xml, etc could be treated as user wants). It is not possible to do that using broad app-specific filters, because sometimes several filters exist that all convert to, say, spreadsheet, and only selecting the correct one helps in difficult cases.
Showing the various file types will likely not get removed as some users may want to filter the list based on the file type and other want to get an impression of the capabilities by looking over the list. But your idea with an additional group of files that can be opened is nice. And, as always, good ideas have been thought before. So closing as duplicate. Please check the "see also" references at the duplicate ticket about module specific and last used selections. *** This bug has been marked as a duplicate of bug 94177 ***
> This is huge oversimplification based on ignorance. I've been doing interaction design for about a decade in GNOME, and I've also seen people struggle with LibreOffice in all sorts of ways. I've been supporting everyday people, book authors, nurses and doctors, and I can tell from experience that pretty much nobody requires the level of "precision" that the current filtering combobox has. Maybe you should refrain from presuming I'm just "ignorant". "Opiniated", I'll give you that, but that's because I care about making LibreOffice better ;) > so that some ambiguous cases, like csv named dat, or xml, etc Then your file is broken and that's not the GTK FileChooser's job. And in such cases users can always decide to show "all files" and voilà. Or use the operating system's file browser. > some users may want to filter the list based on the file type That's what the proposed file format "category" filtering accomplishes much more quickly, and for more precise usecases (drilling down from inside the meta categories filtering) that's what the searchbar is for. > get an impression of the capabilities by looking over the list. Not an issue. Users just want to open a file, not "get an impression of the software's internal import filters capabilities" (that's what wikipedia and the LibreOffice website or wiki are for). And if you really really want to have the app's capabilities available on hand, then you could have a (?) help button that shows the relevant documentation page explaining the "supported formats". Still, the list of capabilities is typically something for organizational buyers and decision makers, not the actual office workers who need to do things quickly and efficiently... ...and showing a list of 176 items is NOT quick nor efficient for anybody. It's just overwhelming to the point of uselessness. I'm not exagerating that number by the way, I actually had to use the Gtk Inspector to count the list of items because the GtkCombobox widget spans 6 times the height of my computer monitor. Currently you're sacrificing usability by overloading the user with options that they don't care about, for the sake of an unlikely technical edge case that may affect 1% of scenarios (and those scenarios would have the easy workaround of showing "All files", so they're not even truly affected). Don't be afraid to make bold interaction design decisions in the best interest of the 99%, please. The GUI is a means to an end (productivity), not an end in itself. There are cases elsewhere in the LibreOffice GUIs where exhaustiveness is expected, but this is not one of them. Anyway, reopening not just because of the points above, but also because the first part of my request was about remembering what the users chose (or filtering to the relevant subcategory by default based on the application the FileChooser dialog is called from). I don't simply want more "choices" à la bug #94177, I want the app to help me get things done.
(In reply to Jean-François Fortin Tam from comment #3) > > so that some ambiguous cases, like csv named dat, or xml, etc > > Then your file is broken and that's not the GTK FileChooser's job. > And in such cases users can always decide to show "all files" and voilà. > Or use the operating system's file browser. Yes, that's what I'm saying. "Then your file is broken" - means that you just don't know what you are talking about, and don't care to try to understand. CSVs, for instance, often have industry-specific extensions (e.g., marksmanship), and that isn't "broken". XML doesn't always have (and required to have) all information required to unambiguously tell proper input filter. "And in such cases users can always decide to show "all files" and voilà. Or use the operating system's file browser." Again - "I didn't read you; didn't try to understand; but am arguing!". Choosing a filter in LibreOffice Open dialog doen't only filter files, but also (!) tells LibreOffice which open filter (import code) to use.
(In reply to Jean-François Fortin Tam from comment #3) > Anyway, reopening not just because of the points above, but also because the > first part of my request was about remembering what the users chose (or > filtering to the relevant subcategory by default based on the application > the FileChooser dialog is called from). I don't simply want more "choices" à > la bug #94177, I want the app to help me get things done. Too bad you ignored what was told by Heiko in comment 2: > Please check the "see also" references at the duplicate ticket about module > specific and last used selections. The "See Also" field of Bug 94177 has currently these 2 bugs: Bug 79803 - Open file dialog should list files relevant to the open module Bug 89360 - OS and LO custom file dialogs should retain filetype selection ... which is exactly what you asked in the first part.
(In reply to Mike Kaganski from comment #4) > (e.g., marksmanship) Sorry for wrong term (English is not my native) - Geodesy (surveying) is the one I needed to use (electronic theodolites and other equipment software often outputs data in CSVs having DAT extension, for example).
Putting back to RESOLVED DUPLICATED *** This bug has been marked as a duplicate of bug 94177 ***
I love your posts, you always share something out of the box. I was reading about https://www.essayuniverse.net/essayexpert-us-review/ site. And I mistakenly click on your post link. And from that day I always visit your post. Thank you for keeping us updated about new things.