(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
_______________________________________________
gnome-list mailing list
gnome-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gnome-list
