Idea: File Operation Indicator
Disclaimer: I’m not a member of the Ayatana team. I’m not affiliated with Canonical. I cannot guarantee that they’ll ever find this idea interesting enough to implement, or even read this thing.
Indicators are becoming more and more common with each Ubuntu release, as a part of the desktop notification mechanism, and a way to group alike applications running in the background. This is an idea of what I think could make a good generic indicator: file operations.
On today’s desktop, there are many applications doing file transfer in the background. Nautilus already uses an indicator for its file copy operations, but it’s specific to Nautilus. Other applications — web browsers, P2P clients, FTP clients, download managers — usually display progress in their main window, without a way to see the progress without switching to the application.
So, why not have a single menu where applications can add their entries when file operations are in progress? It can include information on the percentage completed, and maybe provide buttons to cancel and (if the application supports it) pause an operation. And an application whose sole purpose is to download files, like transmission or gwget, can live entirely in that indicator without cluttering the notification area with its own custom icon.
You mean this: http://live.gnome.org/SummerOfCode2010/SalomonSickert_Tasks ?
I don’t know if maybe that’s where you got the idea, but KDE has been doing this since at least 4.2 (year and a half ago).
…Okay. I didn’t know about that. But now I have questions:
Is that Tasks API GNOME-specific, or is there a chance for cross-desktop adoption?
Will it be integrated with indicators?
How well-integrated is the KDE implementation? (I don’t use KDE.) How many applications use it? Is it dependent on kdelibs?
It should not depend on kdelibs. KDE & GNOME use the same FreeDesktop.org specification for notifications. It’s simply that Dolphin (KDE’s filebrowser) puts out such notifications. I can’t at the moment remember whether KTorrent does as well.
If I’m not mistaken Mark Shuttleworth was considering the adoption of a “download indicator”, see:
http://www.markshuttleworth.com/archives/347
“[…] Similarly, all the calendar and alarm applications might fit into the Clock Indicator. And perhaps all the applications which have downloads might use a single category for that – there’s some discussion along those lines on the Ayatana list at the moment.”
Merging the download indicator and the file operation thing would make sense.
I’m pretty sure the KDE implementation is just D-Bus. If you’re interested in this, you should try to facilitate communication between the kdelibs developers and the Ayatana team.
Okay, where do I begin?
I’d like to start off by pointing out that KDE (Plasma) has had this for years and years. Since 4.0 was when it was made to look the best. It existed in a slightly different form even before this image: http://pindablog.files.wordpress.com/2008/11/kuiserverintegration.png
Before it was in Plasma, it was in kuiserver which used to be basically a window which had a listview of all the jobs going on. (that was an option btw: the alternative would be “1 dialog per transfer”).
Every KDE application that uses I/O in some form or another (kget, ktorrent, konqueror, dolphin, I think even k3b uses it too – along with many others) uses KIO. They can create any kind of custom job too, if they want. KIO then <steps omitted> calls into kuiserver which exposes a D-BUS interface for obtaining the currently running jobs.
It’s essentially a subscription-based dbus interface….anything interested in the information implements this interface and then signs up for any updates (new jobs, speed changes, job finishes, etc.).
Then the application (in this case, Plasma) can do whatever it wants to present that information. It’s all easy to implement too, because it contains what you would want with a job (size processed, size to go, if it’s suspendable, etc.).
By the way, this interface (and KIO) sees downloads and file operations as one in the same, essentially. Obviously the text that is displayed will be different and the way it is layed might be, but it is really displayed in the same manner regardless. Which is the whole point of I/O abstraction/transparency..to have the applications not care about whether or not a file is local or remote.
I think I covered “everything”..
Oops, forgot something…
@lucidfox.org
“How many applications use it?”
Every KDE application that uses I/O has the jobs displayed in this uniform place.
“Is it dependent on kdelibs?”
Yes and no. Yes to providing the actual jobs (e.g. nautilus doesn’t use KIO and there is zero integration with GIO->KIO. GNOME hasn’t put forth any interest or effort to integrate this, as far as I know…).
No towards obtaining the information. KDElibs isn’t needed (or wouldn’t be) just to get the information, since it’s over D-BUS.
It’d be great to get GNOME applications to integrate properly with respect to KIO, KIO has existed for years and we have been without any integration from GNOME apps for years. That’d be a great place to start, to make KDE & GNOME applications have a tighter relationship/integration.
“How well-integrated is the KDE implementation?”
For us, it looks like a regular notification except with a progressbar, pause/stop, and (and eta & size processed/remaining. But those are seen with the press of the “more” button). Upon the job’s completion, it collapses into what looks like any other notification and says that “file /home/shaun/blah.. has completed” or whatever.
Also, the last time I was on GNOME, I remember having a place in the panel/system tray which would display the file transfers, not entirely unlike what we have. Or was this what (one of you) meant by it being a Nautilus-only thing, basically?
It would be awesome if cp/mv could add to it too!
I’ve had a similar idea. I have sent a message on the Ayatana mailing list about standardizing windicators, and showing menus in the panels with the windicator content for all applications. Part of this proposal is a operation progress windicator, so my idea basically creates this sort of menu.
You can see it here:
https://lists.launchpad.net/ayatana/msg03075.html