SuggestedPackagesForFiletypesSpec
|
Size: 1968
Comment: dumped the discussion status
|
← Revision 20 as of 2008-08-06 16:37:32 ⇥
Size: 6300
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec//suggest-packages-for-filetypes * '''Contributors''': MichaelVogt, MattZimmerman, JeffWaugh * '''Packages affected''': natilus, gnome-app-install |
* '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/suggest-packages-for-filetypes * '''Contributors''': MichaelVogt, MattZimmerman, JeffWaugh, IanJackson * '''Packages affected''': nautilus, gnome-app-install |
| Line 9: | Line 9: |
| 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. |
|
| Line 10: | Line 12: |
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. |
|
| Line 13: | Line 17: |
| 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. |
|
| Line 14: | Line 20: |
Modifications to gnome-app-install and nautilus packages need to be done. |
|
| Line 17: | Line 25: |
| * maybe use update-desktop-database to build the database (if possible?) | 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. |
| Line 19: | Line 27: |
| * user clicks on a unsupported file: | 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. |
| Line 21: | Line 29: |
| - dialog opens and asks gnome-app-install if it has support for it | 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). |
| Line 23: | Line 31: |
| - it needs to be very fast so we need to cache the data (probably just pickle it) and pre-cache it when the package is build | 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. |
| Line 25: | Line 33: |
| - if we have something to install display a dialog with the information and ask the user if he wants to install it - this should most likely bring up gnome-app-install in a special mode without "sections" and "search" and a header with a explaination. open issue: what to do when there is only something in "unsupported" but "unsupported" is unchecked in the g-a-i checkbox. we bring up a text that explains that a component is not checked and expand/show when the checkbox is checked - make sure that commerial stuff (vmware-player, realplayer) does the right thing (display license uri etc) - the dialog invokes gnome-app-install via dbus/commandline and installs the stuff - sort by popularity ranking! - when the application is installed, it is launched with the file that was requested (so g-a-i needs the filename too) - we need a commandline interface (for e.g. firefox that does not use dbus) and optionally a dbus interface * make a nicer dialog if a unknown file-type comes up (instead of the current "Couldn't display '%s'"). Probably "there is no application available to view: '%s'") |
The .desktop data is already collected in the gnome-app-install package including application name, MIME types, and pocket. |
| Line 41: | Line 37: |
| === Code === | 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. |
| Line 43: | Line 39: |
| === Data preservation and migration === | == Security considerations == |
| Line 45: | Line 41: |
| == Outstanding issues == | 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. |
| Line 47: | Line 43: |
| == BoF agenda and discussion == | 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. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/suggest-packages-for-filetypes
Contributors: MichaelVogt, MattZimmerman, JeffWaugh, IanJackson
Packages affected: nautilus, 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 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
- 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.
SuggestedPackagesForFiletypesSpec (last edited 2008-08-06 16:37:32 by localhost)