Introducing my GSoC project

Who am I?

Hi, I’m Salomon Sickert, a twenty year old, computer science student from Munich, Germany. I’m very happy, to be accepted to this year Summer of Code. I will work on this little feature for the GNOME Desktop. Here is a short introduction.

Improving the desktop experience with the “Task” and “TaskMonitor” D-Bus API

Abstract:

The central idea is to export all information related to a running task (e.g. a download, a synchronisation, a transcode) and make them available to other applications. This allows various things like the removal of many redundant progress dialogues, the contextual display of progress information and an even more intelligent power management.

Status Quo

A quick look at a recent GNOME desktop reveals following picture: Every application performing a “Task” [see definition at end] draws its own GUI (window, applet) with its own design and has a varying degree of integration in infrastructure like the notification system or power management. Also other application cannot use the information related to these tasks.

This causes inconsistencies and often leads to bad designed dialogues. A short overview

The Vision

(Note: This list isn’t exhaustive, more a collection of various possibilities for using the proposed infrastructure)

(Note2: The Mockups only illustrate the idea, how the information exposed by the D-Bus API could be used)

Improvements for users: (for more Mockups)

• Removal of the many differently styled and stand-alone progress dialogs. Instead of these all tasks are displayed in a central location. These can be located in various places (GNOME-Shell, Standalone application, …)
• Contextual placement of progress information, cross-application integration (In this Mockup: Nautilus and Epiphany)
• Integration with the notification system
• Integration with power management (e.g. automatic pause and resume of tasks, block suspend if there are non pause-able tasks, …)
• Zeitgeist integration: “What was I’m doing, while I burned that CD?”

Improvements for developers:

• Developers don’t have to deal with the creation of dialogues for their tasks any more
• Integration with various infrastructures like the notification system or power management comes for free
• Easy migration

Realising the Vision

Overview

To achieve this goal there are roughly these steps:

• Creation of a set of D-Bus APIs, which allows to expose information about running tasks.
• Creation of a support library, which enables developer to easy add support for the Interface without messing around with D-Bus.
• Creation of a central GUI, where the user can get a short overview of running tasks and perform basic actions on them. (Standalone application or more preferably integration with gnome-shell (See Mock-up section))

Technical Details

D-Bus Interfaces and Services

There are three parties involved in the concept:

• Applications, which actually perform the task: called Worker, they expose the D-Bus Task Interface
• A central service, which keeps track and draws the standard GUI: called TaskMonitor
• Third Party Applications, which observers the progress of the Tasks and can perform basic actions on them

The Support Library (called libtask)

The support library has two functions:

• Exporting the information of the task through the Task Interface.
• Taking care of showing the progress, spawn an entry in the Central Task Control or GNOME-Shell, depending on the available service or alternatively falling back to a simple progress dialogue, if no such service is available.

Notes:

• The Worker application is still in charge of the error handling
• The Worker can also announce the availability of an more advanced dialogue. (e.g. specialised information for a torrent download)
• Also an CLI interface will be provided for integration in scripts.
• Various Bindings thanks to GObject Introspection support

FAQ

Message Tray Mode

[Disclaimer: These are my own design ideas, how to design the user-interface. I will discuss and refine these with the responsible designers.]

• What happens when the task is started? Will the notification be displayed immediately or is there some user action necessary? I think it would be confusing when the user starts an operation but doesn’t see a progress.First of all I think, it is a bad idea to fully rely on the message tray to show the progress information. In my opinion the user-experience should be similar to the existing. For example the user starts a disc burning task with Brasero:

  After the user hits the “Burn” button, the wizard will be closed and the cumulative progress dialogue (a.k.a. “Central Task Control”) pops up with the according task entry highlighted. This gives the user the direct feedback for his operation. After that the user can decide whether he closes the window or not.

  Additional an icon is placed in the message tray to give access to the tasks and the dialogue.

• What happens during the task? Will the notification hide itself?During the run of the task there are no notifications of the progress. But the user can check the current progress of his tasks in the message tray or in the central task control (or in any other piece of software, which supports the API)
• What happens when the task finishes? Will it pop up once again?I think it is sufficient to show a notification. Another pop-up is – in my opinion – annoying and distracts the user to much from his work.
• In conclusion, this shouldn’t disturb the user and it should be clear what happens behind the scenes.Yes, I totally agree.

Error Handling

• Failing tasks: Could the error message be displayed along with the progress? Having another dialog pop up sounds like failure to me. Think about thinks like questions to overwrite/skip files, I would want to see this near the progress bar.Yes, these are good points. In my draft I tried to keep these things out of the API, as things become more complicated. For example skipping/overwriting files: At the moment Nautilus only displays basic information in case of conflicts. But I think it would be awesome, if more information (e.g. size) is added and more actions are provided (renaming files to solve conflict). As I don’t think there is a solution, which covers all possible cases, it’s better to let the performing application (worker) handle this.

  So I propose a trade-off, the worker application emits a signal in case of an error, with a description and a callback function. A notification and visual hint in the task overview is displayed. (e.g. changing the icon, altered description, highlight) If the user clicks on that, the according pop up will be hovered.

Some Additional Notes

If you are located around Munich, you maybe also want to have look at this page: GNOME Local Hackfest (only in German for now, sry).

If you want to contact me: my site in the GNOME wiki

Posted in: Uncategorized