SuggestedPackagesForFiletypesSpec

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 already have the information about the supported MIME-types for most packages via the desktop files. This information should be used to present a user-friendly way to install packages.

Use cases

  1. Alice clicks on a .xxx document. Instead of getting a error message that this file-type is not supported and being frustrated by the lack of options, she is presented with a dialog asking if she wants to install the application she needs to view the document.

Scope

Modifications to gnome-app-install and nautilus packages need 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 security-supported software (see Security, below).

The actual interaction with gnome-app-install can be done using command line arguments because some packages (like firefox) do not support invoking it using dbus. But additional dbus support should be added.

The .desktop data is already collected in the gnome-app-install package including application name, MIME types, and pocket.

Implementation

The current gnome-app-install tree on http://people.ubuntu.com/~mvo/bzr/gnome-app-install/gai--main/ supports a "--mime-type=" argument that will show only packages matching that mime-type. The optimizations are not done yet because it turns out that using the pyxdg module to generate the menu makes matters not as easy as was hoped initially.

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 primarily for main.

To support this for universe, where there is no security support, we adopt the following solution:

  • gnome-app-install will contain a whitelist of non-main programs for which this functionality will be enabled
  • for a program to be in the whitelist, we promise at least to take steps to be aware of any security problems that appear in it (eg, by following upstream announce list) and to fix the problem if they do.
  • Here `fix' can and often will mean issuing a new gnome-app-install in edgy-security which removes the package from the whitelist.

The result will be that the automatic suggestion and installation will occur for packages in main and a small subset of packages in universe. For users who are insane (or expert) and want to have it for all packages in universe, there will be a gconf key (not settable via the UI) to trigger installation for all available packages regardless of the whitelist.

When a program is not offered due to lack of a whitelist entry, the "cannot open this file" message will be different, so that the user can distinguish "we do not know any application for this file" and "no application with sufficient security assurance could be found".

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.

File formats and interfaces

/usr/share/app-install/gai-mime-map.gdbm is a gdbm database which maps the mime type to a space-separated list of component/packagename strings.

/apps/gnome-app-install/mime-whitelist-components is a gconf key, a list of strings, defaulting to just main.

/usr/share/gnome-app-install/mime-whitelist-packages and /etc/gnome-app-install/mime-whitelist-packages are optional text files whose lines are package names. Both of these files may contain #-comments.

nautilus invokes gnome-app-install --mime-type=... uri urifordisplay which looks up the mime type and does the appropriate thing: either launching itself to offer applications, or displaying an error dialogue box. (Without uri, the dialogues are replaced by messages on stderr with an appropriate exit status.) If an application is installed then the file is opened again.

gnome-app-install --mime-type=.... has the following defined exit statuses: 4 - no entry found; 5 - entries found but not in whitelist; 6 - we displayed an error dialogue box.

CategorySpec

SuggestedPackagesForFiletypesSpec (last edited 2008-08-06 16:37:32 by localhost)