SuggestedPackagesForFiletypesSpec
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec//suggest-packages-for-filetypes
Contributors: MichaelVogt, MattZimmerman, JeffWaugh
Packages affected: natilus, gnome-app-install
Summary
Ubuntu does not install packages for every file type in the world. If a user wants to open a document that is not supported out-of-the-box there should be a option to install the required package(s) to work with that file type.
Rationale
We have the information about the suppported mime-types for most packages via the desktop files already. This information should be used to present a user-friendly way to install packages.
Use cases
- Alice clicks on a .xxx document and gets a error message that this file-stype is not supported. She is frustrated by the lack of options.
Scope
Modifications to gnome-app-install and nautilus packages needs to be done.
Design
The information about the supported filetypes is part of the desktop file for the applications. We generate a cached version (pickle?) of the desktop-files database that contains the required information for gnome-app-install.
If a user clicks on a unsupported filetype with nautilus it should talk to gnome-app-install (either via dbus or the commandline) and make it show a dialog of the applications that could possibly open that file-type. Those applications should be ranked with the popcon information and it should be a subset of the normal gnome-app-install window (without the sections on the left and the search field on the top). Nautilus needs to pass the mime-type and the actual path to the file to gnome-app-install. When the user selects "install" and it is installed, g-a-i should open the file with the just installed application.
The interface should honor the "show unsupported", "show restricted" selections of the user. If that results in not showing any application to the user we need to show a entry that explains that with the current view setting nothing can be displayed but that this can be changed with the view settings. If the user selects a proprietary application (like RealPlayer) the usual dialog about adding Channels/LicenseUri comes up. Note however that at present data will only be available for supported software (see Security, below).
The actual interaction can be done with the commandline because some packages (like firefox) do not support dbus. But additional dbus support should be added.
The best currently available way to collect the desktop file data for every application is an ad-hoc archive scan.
Implementation
No code has been written yet.
Security considerations
If we would be installing an unsupported program there are problematic security implications: if any unsupported program has a vulnerability to bad data then the user could easily be induced to install the vulnerable program by the presence of the malicious data.
Therefore for now we will support this only for main. (This also makes collecting the .desktop data easier.)
To support this for universe, where there is no security support, we need a way to query (dynamically) whether a particular program is considered suitable for autoinstallation and use in this way. The minimum requirement to consider a program appropriate is that (a) we have a way to find out about security problems in it (this means also that the program must be fairly widely used) and (b) we are willing to disable the automatic installation offer for it.
There are also privacy issues with these interfaces. They should be arranged so that we only query online after we have already determined by local lookup that there is likely to be a candidate program.
Open issues
The lookup if the mime-type can be supported needs to be very fast (and pre-cached) because if we actually do not have any package that supports the given mime-type we need to tell nautilus so that it can display a error dialog. That one should be better worded than the current: "Couldn't display '%s'". Something like "There is no application available to view: '%s'" is more appropriate.