The TaskView GSoC Project
Long time no post, but the project is quite active.
Current Status
What works?
- The support library is complete, it is quite lite and easy to use and takes care of mist things, like calculating the throughput and the remaining time (only for IO-based Tasks)
- There is a basic control UI, mostly oriented at the current nautilus progress dialogues.
- Telepathy Filetransfer Integration (yeah, the first fully integrated application, although the strings need some love)
What’s on the road?
- Documentation and sample code
- Nautilus Integration
- Bindings (GObject Introspection)
- GNOME Shell Integration
- Application Integration, as the library is quite easy to use, I think it is quite easy to add support. I will concentrate on the core applications of the GNOME ecosystem
- A fallback solution (has low priority, as D-Bus is omnipresent)
Call for the UI designers!
I must admit the UI doesn’t look very sexy! But that’s your chance to say, what’s wrong with it! What should be changed? I’m looking forward to hear you comments and constructive criticism.
KDE Integration
I was often asked to make my project compatible with the existing solution found in KDE. I’ve looked at the API, but after some discussion I decided not to implement their schema.
This is not a NIH syndrome, it’s basically a technical decision. The D-Bus API has several shortcomings I don’t want to copy (e.g. my API is complete stateless – no need for registering and it also allows thirdparty apps to access the information, e.g power management)
However it would be possible to write adapters. Furthermore I would like to cooperate with KDE developer to create a crossdesktop solution.
More Information and Code
Just have a look at my portfolio page: http://live.gnome.org/SummerOfCode2010/SalomonSickert_Tasks
The location of my code: http://github.com/ssickert/TaskView
ssickert's Blog 
Marcus
July 10, 2010
Cool! Keep up the good work and let me know if you have problems with the nautilus integration.
ssickert
July 10, 2010
That’s great, thanks for your offer, I will contact you!
Kai Mast
July 10, 2010
Awesome! I always dreamed of something like this
anon
July 10, 2010
This is looking great! Just a few comments about the UI, though:
1) How about changing the titles (e.g. “duplicating fedora.iso”) to use bold font? Right now they are a tad hard to spot. Also a little bit more vertical white-space between the different tasks would be great.
2) How about showing the last N (some number) operations that have been completed? Kind of like Firefox’s download dialog, but limiting the history to N so it doesn’t grow to large and unsightly…
3) Taking another queue from Firefox, how about adding a search box?
ssickert
July 12, 2010
Thanks for your suggestions!
1) How about changing the titles (e.g. “duplicating fedora.iso”) to use bold font? Right now they are a tad hard to spot. Also a little bit more vertical white-space between the different tasks would be great.
You’re right, I will try it.
2) How about showing the last N (some number) operations that have been completed? Kind of like Firefox’s download dialog, but limiting the history to N so it doesn’t grow to large and unsightly…
The scope of this UI is the presentation of all tasks, which are running at the moment. But I’m planning to write a little task history viewer based on zeitgeist, which gives you access to all tasks performed in the past.
3) Taking another queue from Firefox, how about adding a search box?
I will add that to the history viewer.
Harsh
July 10, 2010
Great work.
manolin
July 10, 2010
So as always we GNOME are moving away from crossdesktop, and then KDE will has to catchup, always same history like with DBus, Notifications, etc
foo
July 11, 2010
Nice.
Now GNOME just needs a multi-protocol file transfer client like Telepathy is a multi-protocol IM framework.
Danielle
July 12, 2010
Telepathy supports file transfer over IM protocols.
Then there is nautilus-sendto, a Nautilus plugin that can use plugins of its own to support file transfer over different systems, e.g. Bluetooth, Email, Telepathy.
Seif Lotfy
July 11, 2010
Dude this is awesome. I was looking for a way to figure out what is being moved or copied wher for zeitgeist. I would like to talk to you about the API. @zeitgeist we could extend the applications we cover to support your work.
Keith
July 12, 2010
I wonder, why didn’t you want to implement KDE’s schema? Is it because it’s KDEs and not GNOMEs? This is one thing I do not like about GNOME developers. They never implement anything KDE does. But wants KDE to implement everything GNOME. Can GNOME developers ever meet half way or is this all KDE users get is BS like this? I don’t mean to offend but I believe this is the truth.
asdf
July 12, 2010
“The D-Bus API has several shortcomings I don’t want to copy” – in other words, you’re too lazy to create workarounds like everyone else does. Why do people always think they can do better?
NIH truly, with “here” defined as “in your mind.” Rather than working within the system, you invented something else. And then you’ll patch a selection of the “core” applications, push the maintenance burden on to their developers after you hie for greener pastures.
I can’t believe your GSoC mentor green-lighted your project.
ssickert
July 12, 2010
I wonder, why didn’t you want to implement KDE’s schema? Is it because it’s KDEs and not GNOMEs?
No. As I stated above, this decision was purely technical and also discussed with my mentor and other developers. This is not related to any kind of GNOME vs. KDE flame war.
you’re too lazy to create workarounds like everyone else does
Why should I waste my time with building workarounds? Instead of that, I think it’s better to start from scratch and make it better. E.g. the wireless stack of the linux kernel was rewritten several times, as the developers noticed problems and design faults in the current approach.
My design features several things, which are missing from the KDE solution:
– Stateless (in other words, more error tolerant)
– Use of D-Bus Properties
– Support of non IO based Tasks
– extensible
– modular
– no kuiserver lock-in
I also want to add, that is possible to write an adapter which bridges the two systems together.
Lester
July 12, 2010
Thank you for your hard work! The Pause button is just awesome! Can’t wait when such long awaited feature in gio becomes real.
Chani
July 12, 2010
er… did you ever consider talking to the maintainers about improving the API?
also, I don’t understand the “no kuiserver lock-in” comment – it’s a dbus API, anyone can implement it.
“I think it’s better to start from scratch and make it better” – er, there are times when that’s appropriate, but I don’t think this is one of them. what if everyone took that approach? linux would become a tangled mess, layers upon layers of adaptors… (*cough*audio*cough*)
dbus itself has technical shortcomings, but KDE switched to it for the sake of compatibility with gnome. I do wish I could see that same spirit of co-operation a bit more often.
then again, the gnome-keyring and kwallet people are co-operating… tracker and strigi (or nepomuk? I get those mixed up) are working together on things… so, maybe it’s not completely hopeless 😉
ssickert
July 12, 2010
did you ever consider talking to the maintainers about improving the API?
Yeah, yesterday I started my third try to get hold of one of them.
I don’t understand the „no kuiserver lock-in“ comment – it’s a dbus API, anyone can implement it
Of course everybody can implement the interface. However only one application can claim the name “org.kde.JobViewServer” and therefore only this application gets updates. There is no way for other applications to get this information (judging from the D-Bus interface spec).
there are times when that’s appropriate, but I don’t think this is one of them
Ok and what’s your proposition? The current design is flawed and has shortcomings. Should I invest my time in making the same mistake? Or in searching for better solutions?
dbus itself has technical shortcomings
I’m just curious, what shortcomings?
I do wish I could see that same spirit of co-operation a bit more often
Of course I’m interested in cooperation. If I were not interested in this, I wouldn’t discuss. 😉
Cheers
Chani
July 12, 2010
“However only one application can claim the name “org.kde.JobViewServer””
this is the same method that’s used for stuff like org.freedesktop.ScreenSaver, no? and you can choose what program you use for your screensaver, the only restriction is that you can’t have two programs claiming to be the scrensaver at once. same thing for media players, notifications, systray… the only difference I see here is a lack of freedesktop namespace 🙂
“Ok and what’s your proposition? The current design is flawed and has shortcomings. Should I invest my time in making the same mistake?”
you should try to get the current design improved.
it sucks that you’ve had trouble contacting the maintainers – maybe you could have worked with them.
…ooh, and there you are on irc! *waves* 🙂
Marco Martin
July 12, 2010
Of course everybody can implement the interface. However only one application can claim the name “org.kde.JobViewServer” and therefore only this application gets updates. There is no way for other applications to get this information (judging from the D-Bus interface spec).
That’s fine, because we need only exactly one running.
the desktop starting will start its own, occupying the bus name, then the apps, regardless KDE or GNOME will use it. that’s exactly the same thing it happens with notifications or with the dbus based systemtray
nud
July 15, 2010
Chani, the key difference is that it doesn’t make sense to have more than a screensaver running. It might not make sense to run more than a single “task server” as well, but what makes sense is to allow more than one consumer for that data. For instance, the file manager might want to use that data to display download progress on actual files (that’s one of the mockups)
Also, the kde jobs interface is bound closely to kioslaves and to what they are doing, ie basic io stuff. The scope of this project is *not* io stuff, it’s long running tasks in general (burning a CD, running make, fetching mails, or finding the 100000000st decimal of pi) The screenshot above just inadequately only considered such tasks because they are the most common ones.
pablog
July 12, 2010
Hi Salomon.
Congrats for your work in the GSoC 🙂
I was thinking… can we prioritize someway one of the transfers?
An use case: Let’s say for example that I’m backing up my data and that remaining time is 2 hours. In the meanwhile a friend arrive to my place and he wants me to copy in his pendrive a movie and he’s in hurry.
Also, what about a button to open the destination folder?
Regards
ssickert
July 12, 2010
Congrats for your work in the GSoC
Thanks
I was thinking… can we prioritize someway one of the transfers?
I must admit, I don’t have a profound knowledge of the internals of GIO (the component, which actually makes your copy).
But I think, it is not possible at the moment to pause or prioritise transfers.
James
July 13, 2010
Looks nice! The random comment I wanted to add was that perhaps there could be a global “x minutes till all complete” type notification somewhere, perhaps even as the window name text. hth!
_J
Tshepang Lekhonkhobe
September 20, 2010
Look seriously good! I can’t wait for Nautilus integration. Any ETA?
PS: Please use real hyperlinks next time.
Tshepang Lekhonkhobe
September 20, 2010
I only noticed now that there’s already a git branch for Nautilus integration.
fred
September 27, 2010
some people on the Ubuntu Ayatana ML have been working on mockups for a menu-style UI to this, something like a Progress Menu in the GNOME Panel, headed by a symbolic icon to indicate ongoing activity.
¹ https://wiki.ubuntu.com/Ayatana/ProgressIndication
this is something many of us have been waiting for, thanks so much for making it real!