Ubuntu Wiki

This is a partial specification for the graphical interface of SessionInstaller and Aptdaemon. For the most part, Aptdaemon should have no UI of its own, with progress displayed in a separate program such as Ubuntu Software Center or Update Manager. But when there are errors, or when a non-specialist application (such as a media player) asks for installation of a particular package, Aptdaemon should present its own UI to maximize consistency and thoroughness.

See also aptdaemon error messages.

Data for packages

A package is presented to humans using information derived from the app-install-data package, the archive index, and the package’s Debian control file. Ubuntu Software Center, Update Manager, file managers (“Open With…”), and Aptdaemon should share the code they use to calculate this information.

# The icon should be the icon supplied for the application by your current theme, if there is one; otherwise the icon provided by app-install-data, if there is one; otherwise the generic package icon. This may be enhanced later for more specialized generic icons.

# The title should be the application Name, if there is one; otherwise the package synopsis (the first line of the Description field) with its first word capitalized. If this leaves multiple packages with the same title, the package name should be appended in brackets to the title of each of them: “{Previous Title} ({package name})”. (This is the same approach used for disambiguating account names in Ubuntu’s session menu.) Test case: In Ubuntu Software Center, search for the “backintime-gnome” package. The item should have the title “Back In Time (backintime-gnome)”.

# The short name should be the application Name, if there is one; otherwise the package name. (This is for use in more technical contexts than the Title; for example, in Ubuntu Software Center’s “History” section.)

# The summary should be the application Comment, if there is one; otherwise the package synopsis (with at least its first letter capitalized), if the application has a Name but not a Comment; otherwise the package name (because if you’re looking at a non-application package in the first place, you’re fairly likely to be the sort of user who wants to know the package name).

# The license label for an item should be:

• “Open source”, if it is in Main or Universe;
• “Proprietary”, if it is in Restricted or archive.canonical.com;
• “Unknown”, if it is anywhere else (including Multiverse and standalone packages).

This license info should be expanded.

Searching for an application to open a file

The file type string for a file should start with its Mime type. If a human-readable name for this type is known, this should be followed by a space and then that human-readable name in brackets. For example, “model/vnd.gs-gdl”, or “image/jpeg (JPEG image)”.

When asked to find an application to open an invalid filetype (e.g. “unknown”), SessionInstaller should present an error alert, with title “Application Search”, primary text ‘Ubuntu can’t search for applications to open this file, because the file type is not recognized.’, and secondary text “File type: {file type string}”.

When asked to find an application to open a valid filetype, SessionInstaller should open a progress window.

If no applications are available, the progress window should morph into an error alert, with primary text ‘Sorry, no applications were found that could open “{filename}”.’, and secondary text “File type: {file type string}”.

If any applications are available, the progress window should morph into a dialog asking you which application to install.

If you select an application and choose “Install”, the dialog should morph into the progress window for installation.

Data for other operations

Each operation should have:

• Type — install, reinstall, update, remove, or purge.

• UI mode — whether progress is displayed by the calling program, or whether Aptdaemon should display it in a separate window.

• Status text — the current progress in human-readable form.

• Progress — how much of the task is currently complete, as a fraction from 0 to 1 (or -1 if it is waiting for other tasks).

• An optional window belonging to the program that requested the operation, so that any authentication or error alert can be made modal to that window.

General UI for all other operations

When any package operation is requested:

1. If the requesting program has not signalled that it provides its own progress UI (as Ubuntu Software Center and Software Updater do, for example), a progress window should appear… TBD
   

2. Session exit should be inhibited (bug 842799). Can we customize the explanation the user sees if they try to log out?

3. If necessary, an authentication alert should appear.

4. If there are any tasks ahead of this one in the queue, the progress should be set to the waiting value, and status text set to “Waiting for other tasks to complete…”.

5. If apt (/var/lib/apt/lists/lock) or dpkg (/var/lib/dpkg/lock) is locked by something other than aptdaemon (STATUS_WAITING_LOCK) for more than 30 seconds, an alert should appear once, “{calling application} can’t install or remove software until {locking program} exits.”, with “Cancel” and “Keep Waiting” buttons. “Cancel” should cancel the operation. If the lock is cleared while the alert is open, its buttons should become insensitive for two seconds, then it should close.
   

6. If the dpkg binary cache is damaged, progress should be set to the waiting value, with status text “Repairing package cache…”, while the cache is repaired.

7. If there are any incomplete or failed installations, progress should be set to the waiting value, with status text “Repairing previous failed installations…”, while those tasks are recovered. If the repair fails, an error alert should appear, with primary text [saying what?] and an “OK” button.

8. The task should be performed, as specified below: installing, reinstalling, updating, removing, or purging.

9. Once the task completes (successfully or unsuccessfully), session exit should no longer be inhibited (unless there are further tasks waiting).

If any confirmation or error alert is shown for any task, and a window was specified for the task:

• The error alert should use, as its icon, the icon of the application that window belongs (or belonged) to.
• If the window is still open, the error alert should open modal to that window, and should not have its own title.

If any error alert is shown and a window was not specified for the task — or if it was, but that window is no longer open — the the error alert should have a title of the form “Installation Error”, “Update Error”, “Removal Error”, etc.

Installing software

When one or more package installations are requested:

1. If any of the packages conflict with installed packages, a confirmation alert should appear (bug 704155): ‘“{title}” can’t be installed unless these items are removed:’, or “This software can’t be installed unless these items are removed:”. Any affected applications, followed by any other affected packages, should be listed alphabetically in an inset list that does not allow selection but is focused by default. The alert should have “Cancel” and “Remove & Install” buttons, with “Cancel” being the default. Test case: Install notification-daemon or notify-osd, whichever you don’t currently have installed.
   
   

2. While the software is being downloaded, the status text should be “Downloaded {amount} of {total}”, or “Downloaded {amount} of {total} ({rate})” if the download rate is stable (bug 524690). For example, “Downloaded 15.6 MB of 131.0 MB (24 MB/s)”.

3. While the packages are being installed, the status text should be the latest line of the dpkg output.

Reinstalling software

TBD

Updating software

When one or more package updates are requested:

1. If any of the new package versions conflict with other installed packages, a confirmation alert should appear (bug 430197): ‘“{title}” can’t be updated unless these items are removed:’ or “These updates can’t be installed unless these items are removed:”. It should have “Cancel” and “Remove & Update” buttons, but otherwise be identical to the equivalent alert when installing a new package.

2. While the updates are being downloaded, the status text should be “Downloaded {amount} of {total}” (bug 864134), or “Downloaded {amount} of {total} ({rate})” if the download rate is stable. For example, “Downloaded 15.6 MB of 131.0 MB (24 MB/s)”.

3. While the updates are being installed, the status text should be the latest line of the dpkg output.

Errors common to installations and updates

Broken/unsatisfied dependencies

Test case: sudo apt-get install 4g8 && sudo dpkg --force-depends -r libnet1, then try to install anything. Afterwards, if necessary, use sudo apt-get remove 4g8 libnet1 to recover.

If software can’t be installed because existing software has broken or unsatisfied dependencies, a confirmation alert should appear. It should have primary text “New software can’t be installed, because there is a problem with the software currently installed. Do you want to repair this problem now?”

The secondary text should vary depend on whether fixing the problem requires downloading (not just installing, but downloading) software, and whether or how much software needs to be removed:

Following the secondary text, a “Details” pane — collapsed by default — should list the software that will be installed and removed, before “Cancel” and (default) “Repair” buttons.

Downloading fails

If, during an installation or update, a package fails to download (ERROR_PACKAGE_DOWNLOAD_FAILED), then:

1. If the computer is no longer connected to the Internet, an error alert should appear. It should have primary text “{title} can’t be downloaded because there is no Internet connection.”, secondary text “Connect to the Internet and try again.”, and buttons “Cancel” and “Try Again”. If an Internet connection begins while the alert is open, its buttons should become insensitive for two seconds, then it should close itself and the download should start again automatically.

   

2. Otherwise, if there is an Internet connection, the package list should be reloaded immediately. If that fails too, an error alert should appear. It should have primary text “{title} can’t be downloaded because the software channel is not available.”, secondary text “Try again later.”, a secondary “Details” expander control that reveals a text frame containing the libcurl error message, and buttons “Cancel” and “Try Again”.

   

3. If the package list download succeeds, and the URL of the file has changed, the task should be tried again immediately. If it still fails, or if the URL of the file has not changed, an error alert should appear. It should have primary text “{title} can’t be downloaded at the moment, because the software is missing from the server.”, secondary text “Tray again in a day or two.”, a secondary “Details” expander control that reveals a text frame containing the dpkg error, and buttons “Cancel” and “Try Again”.

   

Downloading the package list fails

If downloading the package list fails (ERROR_REPO_DOWNLOAD_FAILED), then:

1. If the computer is no longer connected to the Internet, an error alert should appear, with primary text “The software catalog can’t be updated because there is no Internet connection.”, secondary text “Connect to the Internet and try again.”, and buttons “Cancel” and “Try Again” (bug 484466). If an Internet connection begins while the alert is open, it should close itself and the download should start again automatically.

2. Otherwise, an error alert should appear with primary text “The software catalog can’t be updated right now.”, secondary text any error from apt, and buttons “Cancel” and “Try Again”.

Removing software

When a package removal is requested:

1. If the relevant package is part of the ubuntu-desktop metapackage, a confirmation alert should appear: “{title} is a core item in Ubuntu. Removing it may cause future upgrades to be incomplete.” The alert should have “Cancel” and “Remove Anyway” buttons; neither button should be the default.

2. If you request to remove a package that is part of any other metapackage, a confirmation alert should appear: ‘If you uninstall {title}, future updates will not include new items in the “{metapackage title}” set.’ Again, the alert should have “Cancel” and “Remove Anyway” buttons; neither button should be the default.

3. If you request to remove a package that is depended on by any other package, or an application that shares a binary package with any other application, a confirmation alert should appear: “To remove {title}, these items must be removed as well:” — with any affected applications, followed by any other affected packages, listed alphabetically in a list that does not allow selection but is focused by default. The alert should have “Cancel” and “Remove All” buttons; neither should be the default.
   
   

4. If the item is represented in the Launcher, it should immediately disappear from the Launcher.
5. The package should be removed.

Purge