Development of more sophisticated and effective mechanisms for finding the right software package for a specific task.


Right now we only have the package description to describe what the package is about. More information and a nicer interface is needed.

Scope and Use Cases

  • Malone looks for a game for his daughter. He wants to see some screenshots and possibly visit the homepage of the application.
  • Paul wants to know what graphic application is the most popular in Ubuntu and then install it.

Implementation Plan

There are three areas where improvement is needed. One is the gnome-app-install application that does not scale very well for large amounts of applications and does not provide a lot of meta-information about the packages it displays. The second area is the lack of installation from a web-browser. The launchpad website will provide a lot of information about all available packages in all distributions released via launchpad. A user browsing (or searching) this website should be able to install any application if it is available for it's distribution with a single click on a button in launchpad. The third area is the usage of mime-type information. If a unknown mime-type is found by nautilus or Firefox they should offer the option to search for software that is able to deal with this mime-type.

Goal 1

Extending gnome-app-install to include additional meta-data such as links to the homepage, screenshots as well as user-ratings and comments. It should use python-apt, pygtk and pymozembed. The idea is to have rich package information on the server (using the data provided by Launchpad) and display them in a nice web page (HTML-based) that is rendered in the client. This should provide various ways to see the packages. Like "most popular" or "by section". The install happens by clicking on a link that is intercepted by the application and will install the program using the stock apt mechanism (and using the authentication mechanism by apt itself). It should also support CD-ROMs and other offline media as well as working correctly when no network connection is available on the used computer.

A medium term goal should be to support the addition of sources.list entries and update only those from this application.

It's important that all code is written with a clean separation between the GUI and the backend. This is important for the Kubuntu project so that they can easily write there own GUI that works without gtk.

Goal 2

A file with some meta-information needs to be provided by launchpad when the user clicks on a "Install" button with his web browser. The file must contain the all distributions (hoary, breezy), components (main, universe) and versions of this package in all distributions. A local application that is called on that mime-type will be run and checks if the given package is available in the current apt database. If not, it is checked if it is available in a different component of the installed distribution or in a new distribution (using the meta-release file that is available for update-manager). The user is informed about that then (with a possible option to do a upgrade or to add the component).

Goal 3

The mime-type information is available in the .desktop files of most desktop applications. This information should be used by the package manager application. Hooks needs to be written so that external programs can be called when a unknown mime-type is found in firefox and nautilus. The application should provide a option to install the available packages that can deal with the mime-type.

Packages Affected

This includes:

  • pygtk

  • python-apt (this needs to be updated to the latest baz version from MichaelVogt)

  • pymozembed (this needs to be packaged first) -- JorgeBernal: gtkmozembed is inside the python2.4-gnome2-extras package

  • nautilus
  • firefox
  • synaptic

User Interface Requirements

Build with pygtk + pymozembed

Outstanding Issues

A prototype with pygtkmozembed was written, everything else is missing. pymozembed needs to be packed, a patch for Mozilla/Mozilla-Firefox needs to be applied to register various types correctly (it is using G_POINTER instead of G_STRING).

The i18n of the interface needs to be reviewed. The problem is that the server side of the application needs to be i18ned too. This can either be addressed by generating the webpage in the client with gettext and just use gecko to render it, or by generating server pages depending on request of the client. The problem here is that the pages either needs to be generated dynamically or a lot of them statically.

UDU BOF Agenda


  • There are additional scope/use cases that have been discussed. Please let me know if this isn't the correct spec/function to provide those. Specifically, a way to distinguish in the interface (and quickly access) applications which have been certified for Ubuntu and/or are provided from partners. Also (I think this already exists), the ability to see, for example, all the education apps. JaneSilber

  • Could HelperPackagePage specs be of interest to anyone? Would be excellent with some comments! Smile :) DagRuneSneeggen

  • There is a mockup with some ideas at

CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/FindingPackages (last edited 2008-08-06 16:29:17 by localhost)