[Telepathy] GSoC - Project Idea (refined)

[Salomon Sickert]

(I'm a potential GSoC-applicant looking for feedback on a project idea.)

Thanks for all the feedback. After reading through all this and
reviewing the source code of the Mathusalem Projekt¹, it becomes clear
to me, that my idea description was not precise enough. 

(As this is a cross-post, the original post is attached)

Some notes about the project idea for SoC:

     1. Creation of a set of simple D-Bus Interfaces, which allows the
        application developer to expose progress information about a
        running (background) task, which the user could be caring about.
        (e.g. Downloads, Burning, Backups, File Transfers, Printing
        Jobs, Cloning GIT, Syncing, ...) Things the user don't care
        about are not exposed. (e.g. updating locales-cache, rotating
        logs, ...)        
     2. This is NOT about moving all file/io functionality in a common
        structure (which was in my understanding the central idea of the
        Mathusalem Project). In many cases this is not possible and also
        requires a lot of hard work. There are simply to many different
        protocols with specialised code. Also the approach is
        cross-desktop and I doubt the KDE-People would like to switch to
        an patched GIO/gvfs from their KIO. Another point is that in
        many cases it becomes very hairy to do all the error handling.
        In my opinion it is much easier to add a D-Bus Interface instead
        of moving whole portions of the code. I think these are the main
        reason, why Mathusalem didn't got integrated.
     3. Integrating of my Interface should be fairly easy. A support
        library should allow the application developer to get done under
        one hour. The changes to the codebase should be minimal and
        trivial. 
     4. As the project aims to be ready for GNOME 3.0 (or 3.2 if the
        deadline is not met.), I will keep the thing simple and easy to
        migrate. In the case the project is accepted, I'm able to work
        much of my time on the project. I hope this enables me to have
        working base at the time for midterm evaluation and allows me
        then to concentrate on writing integration patches for other
        GNOME applications.

What are the benefits?
     1. It It is possible to create an central UI, where users can check
        the progress of his tasks. No more ten different dialogues,
        which clutter the workspace.  
     2. A more unified look'n'feel.
     3. It's cross-desktop! It doesn't matter if its GNOME, KDE or
        whatever. It even doesn't have to draw an UI, it only hast to
        export the Interface, the rest is done from my project. (e.g.
        wget with D-Bus interface)
     4. Integration with power management:
      * When the user hits the suspend button and there are non
        pause-able  tasks, he gets notified. All pause-able task are
        automatically paused and resumed. 
      * Running on battery will cause all pause-able jobs will
        automatically paused. Running von AC will cause that are
        resumed.
      * ...

I hope this clarify my ideas. In the very near future a more technical
detailed introduction can be found on my website, including a
Proof-of-Concept.²

As always feedback is appreciated, especially from Nautilus, Epiphany
and Empathy developers. (What are your needs, what information should be
exposed, how much logic should stay in the application, ...)

Sincerely

Salomon Sickert


¹ Unfortunate the original blog and git repository vanished, I used a
more recent fork found on http://code.google.com/p/gnome-mathusalem/ 

² When it's ready I will announce it here. Original url was:
http://home.in.tum.de/~sickert/file_transfer_progress




--------- Original Post -----------
Hi,

I'm a student aiming to get place in the GSoC program. While browsing
http://live.gnome.org/SummerOfCode2009/Ideas and
http://live.gnome.org/SummerOfCode2010/Ideas, I've got following idea:

Nautilus, Epiphany, Empathy and other programs, which have the ability 
to transfer files, could expose the progress of the transfer. This 
enables other applications to react accordingly and allows to create 
an unified overview on the progress of file transfers.

I've created a first more detailed draft, which can be viewed on
http://home.in.tum.de/~sickert/file_transfer_progress

Comments and discussion are appreciated.

Greetings

Salomon Sickert