Steve Frécinaux

Google Summer of Code acceptance

I’m very glad to announce my Google Summer of Code application got accepted, with Raphaël as a mentor. As people carry on asking me explanations, here are my submission details:

Long Running Task Manager & Nautilus/Epiphany Download Integration

Description

The idea is to have a common place for all long running tasks to be visually shown, instead of a whole lot of progress windows everywhere. This way it wouldn’t clutter the user desktop (since these background task shouldn’t by essence be intrusive) while allowing other applications to get information about these tasks (ie progress state, files involved, etc.) over dbus.

This place would take place as a notification area icon, hidden when there is no task. On click, a list of task and progress will be shown, along with some possible actions like ‘pause’, ‘stop’ or ‘options’ (it’s up to the application to provide these actions, since for instance some tasks are not pausable). As an alternative, a regular window (looking like epiphany’s current download manager) should be shown if no notification area is available. An optional libnotify notification of begining/end of tasks would allow one to keep informed of what tasks are currently running.

[Mockup] Task List Notification Icon and Running Task List Mockup

In a first glance, the API side should be pretty simple, since the applications should be able to register, update or destroy task information (including progress or performable actions), query the task list (for instance to see whether a file is currently involved in a task) or ask to be notified of a particular task state change.

The actual use case I’ll implement is the one of downloading files from Epiphany, and showing the state in Nautilus. Here is how the session would take place:

  1. The download is started. Epiphany register the running task in the task manager, and sends status update on a regular basis.
  2. Nautilus notices a new file and sees from the manager that the file is involved in a file transfer. So the right emblem (‘downloading xx %’) is shown.
  3. When the download is finished, the task is unregistered, thus Nautilus is notified and the emblem is removed.

Other possible use cases for such a task list would be:

  • Document printing;
  • File operations (moving, copying);
  • CD/DVD recording;
  • Email operations (retrieving, moving or sending mails);
  • CD ripping or multimedia transcoding/compression;
  • Software updates (synaptic);
  • Filesystem scanning (antivirus, indexing);
  • PDA synchronisation;
  • Bittorrent downloading;
  • File sending/receiving through IM;
  • Connection progress for IM, wi-fi, and so on;
  • Application loading (instead of modal splash screens);
  • Scheduled maintainance tasks,
  • etc.

Benefits to the GNOME Community

This would make the desktop more usable by containing the invasion of progress dialogs. These progress dialog are often not needed since their only purpose is to tell you ‘I’m performing some background task which is not yet finished’, but there is usually no need for you to wait until the end of those tasks before doing anything else.

On the developper side, it will provide a quick way of showing progress (without the need of reimplementing a progress dialog for each app), while allowing other applications to be notified of running task progresses, which can be handy for file- or device-related tasks.

Beside my own trick, I will keep an eye on a few other summer projects which I find look really exciting. First one is obviously the Improving Emblems in GNOME thing since it is somewhat related to my own project, but also Muntyan’s work on what should become GtkSourceView 2.0 or the support for annotation in Evince look really exciting. Maybe more on these later.

Update: It looks like there is another gedit-related SoC project sponsored by Ubuntu: a Source Control Plugin for gedit, probably focused on Bazaar. No details about it yet, but I hope the guy will come and discuss it with us on #gedit to avoid work duplication.