Created attachment 42600 [details] screenshot Initially filed at http://qa.openoffice.org/issues/show_bug.cgi?id=105705 Two issues: - when exporting to PDF, there is a listview widget inside an expander at the bottom of the GTK filechooser that is *always* open/shown by default. This is not the case with the GTK filechooser that shows up when you do a normal file "save as" operation - more importantly: this widget is completely useless when using the GTK filechooser dialog, because it replicates exactly the same thing as the comboboxthat allows you to set the mimetype, just above. This is a precious waste of screen real estate, especially on netbooks, and is also a bit confusing because the same functionality is presented twice.
(In reply to comment #0) > Created an attachment (id=42600) [details] > screenshot > > Initially filed at http://qa.openoffice.org/issues/show_bug.cgi?id=105705 > > Two issues: > - more importantly: this widget is completely useless when using the GTK > filechooser dialog, because it replicates exactly the same thing as the > comboboxthat allows you to set the mimetype, just above. > No, it is used in other gtk apps. For instance, see Gimp (Save As dialog). I think we shouldn't try to fix this issue :)
First, GIMP doesn't have problem #1 (it does not expand the mimetype thing)*. Second, "GIMP does it" is most certainly not a good design argument. Third, the fact of the matter is, it *is* 100% redundant with the combobox just above. The contents are always the same. There is no reason at all for it to be there. Not when using the GTK filechooser. *: note that problem #1 only affects PDF export, not "save as" dialogs. But problem #2 solves problem #1 at the same time.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Note that the PDF export dialog opens the mimetype expander by default, whereas the file saving dialog does not auto-expand it. Nonetheless, when using the gtk filechooser, that expander shouldn't even show up, as it is redundant with the mimetype combobox widget.
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval. Thank you and apologies for the noise
*** Bug 79860 has been marked as a duplicate of this bug. ***
The filetype list is also visible/open when you click File > Export. Sad that this is 3.5 years old and should be an easyhack to fix.
Created attachment 101758 [details] export to pdf dialog of LO 4.3 under CentOS 5.10 It's important to understand why this feature was added (back in 2007). Old versions of the GTK file picker were collapsed by default, thus not showing the type combo-box by default (see the screenshot). This is still the case for CentOS 5, which is still officially supported. So someone needs to take a decision here whether it's OK to cause a regression for CentOS 5, while improving the situation for more recent distros. (Or maybe there is a way to check this at runtime?) link to the original bug, where it was added: https://issues.apache.org/ooo/show_bug.cgi?id=68219
In my bug i was asking that it not be opened by default, similar to the Save dialog. With regards to Maxim's screenshot, i definitely wouldnt agree that it should be eliminated. LibO already has functionality that if you dont set the file type and it will automatically select the correct type according to the file extension you set on the file. And if users dont know which filetype they want to use, they can easily open up the file type list if they need it.
@Jay: Note that the apache bug I referenced, was about expanding this list by default. The list itself was there before (since i#46800), but in an unexpanded state (which is the behavior you propose). So the difference between the Save dialog and the Export dialog is intentional. (And BTW the apache bug has the patch the caused this behavior, so the previous behavior can be easily restored by reverting these changes.) In fact there is a huge difference between these dialogs. The default type used by the Save dialog is obvious. It's the same as the type of the open document, or OpenDocument in case of a new document (or other type explicitly selected in Tools->Options...->Load/Save->General->Always save as). So in many cases a user would simply type a name and hit "Save" (unless he decides to use another type). However the default type used by the Export dialog is a random one. For example I get pdf in writer, html in calc, wmf in impress, and xpm in draw. And there is no indication about which type is going to be used (the types combo-box has "All formats" by default), so a user *must* use one of the lists to select some type. Also even if some user remembers the default type, there are less chances that this randomly pre-selected type is exactly the one that he wants to use. So most chances the user will need to use the list anyway. And you can't tell users to always add an extension manually, since it's much easier to select from a list. That's the reason it makes sense to have the list open by default, in case of CentOS 5. So from my point of view, the main question here is: How much should we care about such detail in an old (but still supported) system, when it doesn't fit so well in newer systems. But for the PDF export dialog I totally agree. There is only one format, and we don't need that list at all. And to solve the CentOS 5 case, we could simply change the title of that dialog to "Export to pdf" or something similar. (BTW I changed some fields that I forgot to change previously.)
It seems Centos5 is still the baseline. Bjoern/Caolan: thought you might be interested in this one (UI dialog/old system baseline could be a problem)
re the baseline, I'm not so hung up on pandering to the ancient UI of gtk2 in CentOS5. So, sure, if someone now wants to clean this up and remove the "strange" filter list widget in favour of using the glob filter that's fine by me and there's no need to overly be concerned about the rhel-5 era gtk2 file filter IMO anymore. Firstly though, a fallback position of http://cgit.freedesktop.org/libreoffice/core/commit/?id=75ffeadb55a6c422fb246bfee3870d9035d250e2 to hide the filter list for cases like pdf export where there is only one option to select.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b398581f387dd98e02d709dbdc8000e6ce4deb1 hide it always