Description: The menu is far too long to be practical, unless it's organized. Steps to Reproduce: 1. Open the Open dialog. 2. In the lower right, see a menu of file types. 3. Scroll through the menu items. Actual Results: There are roughly 175 menu items. They are not alphabetized or otherwise organized in any obvious manner. Except for the top few items, the menu is impractical to use. Expected Results: An organized menu. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Please organize the menu items by some reasonable system, add nonselectable headings within the menu to make the organization comprehensible, and duplicate the headings near the top of the menu (perhaps with indents for readability) to serve as a table of contents for the menu. The table of contents likely should be below the 8th item, Database Documents, and before the 9th, ODF Text Document. I am not set up to test in a later version, but this version is still being offered.
Created attachment 154968 [details] screenshot of file types Nick, screenshot shows the file types in File => Open => File Types. Yes, it is a lot, but I don't think that it is chaotic. Is your file list different from mine (in this case please add a screenshot)? I used Version: 6.4.0.0.alpha0+ (x64) Build ID: 460908269972fd1f89312a1e62897ed1503e9e98 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-30_09:18:03 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded => NEEDINFO
The listbox is sorted and organized but in a generic manner to allow os/DE to parse as needed--alternative would require project to implement and maintain GUI widget cross platform which we try to avoid. Have a closer look, the list sequence is actually well organized. Starts with generic All formats, then all formats by modules. And then lists specific import filter formats by module, with the most prevalent filter format starting the block--but in the same general sequence per block. There is a separator inserted in the list between each module's filter formats. So that if for example you want to import a PDF document into Impress (rather than import it into Draw) the PDF filter is at the end of the block "PDF - Portable Document Format (Impress) (*.pdf)". Up to the os/DE to style the listbox and separators. The project just provides the list content. IMHO => NAB and no changes needed.
While my menu has no separators and no parenthetical list of extensions and is far longer (perhaps your screenshot was only of an excerpt), I'll take the word of both of you that it's implicitly well-organized, but that's not obvious (several Mac formats are separated and so are several Excel formats although I can see the possibility that the list is well-organized even for those) and understanding it at just one glance will require user geekiness, and LO is evidently (per its website) meant to be installed for ordinary users who expect the computer to just work and will be overwhelmed by figuring this out, and won't realize they even can. Thus, this is a usability issue for ordinary users (business executives, secretaries, students, et al.). By the way, your screenshot seems to be cut off on the right, which is okay, or your menu cuts off content on the right, which it shouldn't. If the latter, you might want to file a bug report about it. My menu does not have that problem.
Not clear what os/DE the OP is working with, but the listbox is styled by DE. Certainly no issue with Windows builds. IMHO => NAB and nothing to be done. UX-advise?
This issue is reported repeatedly with different aspects. For example * bug 56696 No option to make recent documents list show items for just the currently active LibO module, * bug 69739 There is no option to make File Open by default only show the type of the active document, instead of all file types, * bug 79803 Open file dialog should list files relevant to the open module, * bug 100502 The sequence in the "File Type" listing can be confusing when picking a filter/module to use to import a document, * bug 41000 FILEOPEN - Filter Selection dialog needs structure and preselection I'm pretty sure there is a better fitting request, maybe resolved as WONTFIX. But I agree that filter options with all possible types is more marketing than usability as 'all files' would cover the rarely used options.
I'm the OP. I use Fedora 30 Linux, kept evergreen, and Gnome 3.32.2. If a proposal is to delete some filters because All Files is an option, I disagree. Maybe writing a filter wasn't worth the effort, but, once someone has gone to the trouble of writing it for a rarely-used option that's not never in demand, we should retain it for people with specialized needs that LO already satisfies this way. I'm not a fan of removing features unless they're broken.
(In reply to Nick Levinson from comment #6) > ... to delete some filters because All Files is an option, I disagree. As Stuart pointed our in comment 2 and 4, the list has a reasonable good sorting. What exactly would you change if not the number of items?
(In reply to Nick Levinson from comment #3) > While my menu has no separators and no parenthetical list of extensions and > is far longer Please add also a screenshot of your menu. Perhaps that would make it easier to understand the problem.
Created attachment 155138 [details] Full menu from OP.
I attached a .png combination of screenshots of the whole menu, with an overlap of only one menu item per original screenshot, from my platform, described above. If menu item sequences differ according to OS or desktop environment, it would probably be clearer if one sequence were enforced for all installations, or if one sequence were the default for all OSes and DEs, and other sequences could be chosen as options. Solutions I like (I don't know enough about implementation problems to suggest workarounds): Add labels to tell users how it's sorted. Put a label above each group of menu items that should form a group. Make each label visually distinct from nonlabels. The visual distinction can be perhaps by dimming a label as a noncommand or perhaps by putting dashes in front of it and having it do nothing if selected or show a generic message if selected or perhaps by some other way. My menu (seen in the screeenshot) begins with a lot of blank lines; if that's not an anomaly for my installation, perhaps move some blank lines down to separate the groups, although that could make the menu look broken and it wouldn't explain the grouping. Or, add menu items only near the beginning to explain how the rest of the list is organized.
(In reply to Nick Levinson from comment #10) > I attached a .png combination of screenshots of the whole menu, with an > overlap of only one menu item per original screenshot, from my platform, > described above. Looks strange, but now I understand your problem. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build.
I went to https://dev-builds.libreoffice.org/daily/master/ and followed breadcrumbs but did not see an explanation distinguishing between TDF and TDF-dbg so I assume they're identical except that one shows debugging information that I probably don't need. As I dug down from the first URL, I selected the latest available, and that led me to appproximately 372 choices, roughly half for "deb" and almost all of the rest being "rpm". I can likely figure out which of those two to choose, but, other than that, I didn't see a file name ending with anything I recognized as meaning 'the whole thing'. If I decide to try this, what do I do? Which file do I install? Is there a page with instructions for this? I might get to it on Sunday.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Nick Levinson from comment #12) > I went to https://dev-builds.libreoffice.org/daily/master/.. *dbg are build with debug information, don't care. Also ignore *.helppack, and you are not looking for *sdk. So these two files are what you are looking for https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF/current/master~2019-10-20_16.31.31_LibreOfficeDev_6.4.0.0.alpha1_Linux_x86-64_deb.tar.gz (for deb based Linux) or https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF/current/master~2019-10-20_16.31.31_LibreOfficeDev_6.4.0.0.alpha1_Linux_x86-64_rpm.tar.gz (in case of RPM) Some time ago I made a script for myself, and while it's not working IIRC, it shows the procedure. https://wiki.documentfoundation.org/User:Htietze#Extract_daily_build On topic: there is still the preference to set it as resolved/NAB.
On Windows there are the separators which make it a bit easier to sort for the eyes. What I'd like is that at the beginning you have grouped selections which can be improved to have - Images (png, jpeg, ...) - pdf - ODT (to show all LibrO files) - MSO (to show all MSO files) ... Second point would be it would be nice if you see in the first sections after the grouped section the file types from the app where you click open. Now the first items are always writer formats, but when you click in impress open the user is focused on impress files.
Created attachment 155234 [details] File Type names It could be helpful to update the Names Before Word 2007-365 (*.docx) Word 2003 (*.doc) Microsoft Word 6.0/95 (*.doc) After MS Word 2007-365 (*.docx) MS Word 2003 (*.doc) MS Word 6.0-95 (*.doc) So with consistent company labels it would be easier to read and if you could grayed out the extension you don't need the () and the visible noise will be less.
In Bug 108894 the wording of Microsoft file formats was changed the last time, e.g. the term "MS" or "Microsoft" was deleted. Please don't go round in circles.
After Word 2007-365 (*.docx) Word 2003 (*.doc) Word 6.0-95 (*.doc)
The side-topic of getting daily builds is why I always recommend an appimage: https://libreoffice.soluzioniopen.com/ No byzantine puzzles to solve, just grab the file for the version you want, make it executable and run it.
We talked about this topic in the design meeting and agree with comment 2, the list is well-organized (except the potential bug, see comment 11 => needinfo). Alternatives: + drop the rarely used in favor of all files -> disagree (Nick) + non-clickable section "header" entries (Nick) -> uncommon UI and increasing the list length + put more similar types into groups like all ODF, all Microsoft, etc. and remove individual entries (Andreas) -> becomes a long text (Cor) + rename (Andreas) -> reverts previous effort (Ilmari) UX recommends to close as WFM (keeping open for c11).
Created attachment 155380 [details] full menu in LODev v6.4.0.0-alpha1+ from OP
The menu is virtually the same in the master build as it was when I originally reported this problem. Test: My installation (Fedora) is RPM-based. The RPM link in comment 14 yields a 404 error, so I went back to the original URL for the master and dug again, this time skipping helppack, langpack, and sdk files, leaving master~2019-10-25_20.30.28_LibreOfficeDev_6.4.0.0.alpha1_Linux_x86-64_rpm.tar.gz and I installed from that; installation was simple, per the readmes (the Dev readme erroneously refers the reader to the stable-version readme so we have to use both). I opened LibreOfficeDev Writer and, as a first-time user, I saw nothing relevant in the release notes (https://wiki.documentfoundation.org/ReleaseNotes/6.4#Writer). The About box says "LibreOfficeDev"/"Version: 6.4.0.0.alpha1+ Build ID: 706afd3e765e98489a2b43934a259626f9f0be01"/"CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3;"/"TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-10-25_20:30:28"/"Locale: en-US (en_US.UTF-8); UI-Language: en-US"/"Calc: threaded". File > Open > file types menu now operates nonconventionally, in that it has a downward-pointing arrowhead on the right but clicking it does not directly open the menu. Once I opened it, I found it a bit hard to control, either rapidly overscrolling or underscrolling, which makes it easy to miss a needed filter. Combined with the look of disorganization, the menu becomes more annoying than useful. Nongeeks will not be able to find most of the filters with reasonable speed and will mainly be frustrated. Apart from the test of the master build, my distro recently provided a new LO version and the menu in that appears to be essentially the same. It's now "Version: 6.2.8.2"/"Build ID: 6.2.8.2-2.fc30"/"CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3;"/"Locale: en-US (en_US.UTF-8); UI-Language: en-US"/"Calc: threaded". Solutions: Nonselectable menu items are unusual, but having around 176 items in one menu is also unusual. Adding nonclickable items need not add much to overall menu length. For example, you could add these group labels after the first few menu items: --- LibreOffice and OpenDocument --- --- Microsoft including Office --- --- Macintosh and Apple --- --- WordPerfect --- --- IBM and Lotus --- --- OpenOffice.org and StarOffice --- --- Claris --- --- Adobe --- --- Databases, Generic --- --- HTML --- --- Text, Generic --- --- Graphics, Generic --- --- Other --- It occurs to me that I'm using brands and you're using major types. You may be right to do so, but many people use spreadsheets to hold databases even where they have a DBMS. Nonclickable major-types labels would take even less room. I regret that omitting MS's name from items was already decided on. I despise Windows and when I get another computer that has it preinstalled I am so thorough in deleting it that deletion takes me about 1 1/2 days around the clock (I sic DBAN on it, set for thoroughness). But users may not recognize Word Pro unless you say IBM Lotus in front of it. Ditto MS. That it's advertising is less important than that it's informative to users who just want to get their work done and need the right filter and don't care about whether MS should be tarred and feathered when they want to open documents. I wouldn't even use abbreviations like MS or MSO (I didn't even recognize "MSO"); most ordinary users don't recognize "MS" but they know the full name. It's okay to say "ODT" but not as a substitute for "LibreOffice"; perhaps say "LibreOffice" before "ODT". Instead of killing the enhancement request as not a bug, maybe its importance should be downranked in comparison to other enhancements, and gotten to eventually.
Adding UX team to reply to comment 22
(In reply to Nick Levinson from comment #22) -1, little functional value for a lot of label churn. IMHO => remains WFM/WONTFIX
(In reply to Nick Levinson from comment #22) IMHO, nice to have but little benefit for a lot of work. +/-0
(In reply to Xisco Faulí from comment #23) > Adding UX team to reply to comment 22 See comment 20
(In reply to Heiko Tietze from comment #20) > UX recommends to close as WFM (keeping open for c11). So can we close this report and open a new perhaps for c11 (but I'm not sure, what this potentiasl bug is about)?
(In reply to Dieter from comment #27) > So can we close this report and open a new perhaps for c11 (but I'm not > sure, what this potentiasl bug is about)? No further comment during the last months => RESOLVED WORKSFORME as recommended in comment 20