libgtkui: Use application/octet-stream as the last option in the KDE code

We were previously using an std::set<std::string> to filter out mime type
duplicates, optionally adding the "application/octet-stream" mime type to
the set before joining all items as a single string to pass to the
kdialog invocation.

This used to work fine with the KDE4-based kdialog, whose underlying
KFileDialog ended up creating a custom file type filter with all entries and
suggesting the proper file extension. The KDE Frameworks 5-based kdialog
that was released a few months ago uses a simple QFileDialog, and the
filter's entries are added in the order they are passed to kdialog.

In practice, this means that downloading a PDF file (or any file whose mime
type ended up coming after "application/octet-stream" when iterating our
std::set) causes kdialog to be invoked like this:

    kdialog [...] --getsavefilename /path/to/Downloads/foo.pdf \
                  application/octet-stream application/pdf

KDE4 kdialog suggests "foo.pdf" as the name and adds "unknown, PDF
document", "unknown" and "PDF document" to the filter list. KF5 kdialog
suggests "foo.bin" as the name and adds "unknown" and "PDF document" to the
filter list.

We now make sure that "application/octet-stream" is the last mime type we
pass to kdialog so that any other more specific mime type is chosen as the
default and we do not always try to add the ".bin" extension to the files we
are saving.

Bug: 752375
Change-Id: I56a458042823c52beada9c1819c2ee4b8b8e5e30
Reviewed-on: https://chromium-review.googlesource.com/891160
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532556}
1 file changed