Bug 33598 - Don't show mimetypes / file format lists twice in the GTK file chooser dialog
Summary: Don't show mimetypes / file format lists twice in the GTK file chooser dialog
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other Linux (All)
: medium normal
Assignee: Caolán McNamara
Whiteboard: BSA target:4.4.0
: 79860 (view as bug list)
Depends on:
Blocks: PDF-Export-File-Dialog
  Show dependency treegraph
Reported: 2011-01-27 08:44 UTC by Jeff Fortin Tam
Modified: 2017-10-08 20:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

screenshot (95.29 KB, image/png)
2011-01-27 08:44 UTC, Jeff Fortin Tam
export to pdf dialog of LO 4.3 under CentOS 5.10 (58.31 KB, image/png)
2014-06-25 19:20 UTC, Maxim Monastirsky

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Fortin Tam 2011-01-27 08:44:15 UTC
Created attachment 42600 [details]

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.
Comment 1 Lucas Baudin 2011-01-27 11:35:43 UTC
(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 :)
Comment 2 Jeff Fortin Tam 2011-01-30 16:33:35 UTC
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.
Comment 3 Björn Michaelsen 2011-12-23 11:46:46 UTC Comment hidden (obsolete)
Comment 4 Jeff Fortin Tam 2013-06-26 01:30:17 UTC
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.
Comment 5 Joel Madero 2014-02-27 22:55:05 UTC
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
Comment 6 Maxim Monastirsky 2014-06-25 14:14:43 UTC
*** Bug 79860 has been marked as a duplicate of this bug. ***
Comment 7 Yousuf Philips (jay) (retired) 2014-06-25 15:13:32 UTC
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.
Comment 8 Maxim Monastirsky 2014-06-25 19:20:53 UTC
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:
Comment 9 Yousuf Philips (jay) (retired) 2014-06-26 00:39:03 UTC
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.
Comment 10 Maxim Monastirsky 2014-06-26 22:46:38 UTC
@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.)
Comment 11 Julien Nabet 2014-09-02 20:17:01 UTC
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)
Comment 12 Caolán McNamara 2014-10-21 14:16:13 UTC
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.