I would like to explain some of the work I’ve done some more, so I can address some questions people have asked, and hopefully give people a better idea what this is all about.
First to make clear: the kuiserver itself is just a visualization of kjobs. A kjob can be anything that takes some time: file transfers, checking of email, rendering of fractals, stuff like that. Most applications currently use a simple progressbar or a dialog as visualization of kjobs. With kuiserver, they can also register a kjob with the kuiserver so it can display the job.
An application explicitly needs to register a job with kuiserver to avoid a lot of entries in the kuiserver where the user is probably not interested in. For example: A mail client can, if you have multiple mail accounts, only register the parent job for all those mail accounts to kuiserver, and have only that job shown in kuiserver, while still showing the progress of the different accounts in the application itself. A way to visualize subjobs in kuiserver might also be neat, but I’m not yet sure about this part.
In my branch I’ve changed one line in kdelibs (I love abstraction layers!) to make every kio job (kio jobs also inherit kjob of course) register to kuiserver instead of using the standard dialog based job tracker. Other applications will need to make similar changes to be able to be shown in kuiserver.
Yesterday I’ve actually made the pause/cancel/resume work, (in the screenshot in my previous blogentries the buttons are there but didn’t actually do anything) so the kuiserver is now already pretty much good enough for my daily needs. What it could still use is letting old, not detached entries, expire after some time (the list could grow quite large otherwise). Also it could be a bit more pretty and polished, and maybe display some more information (speed, amount transfered etc.), but that isn’t my main priority now. But the kuiserver dataengine I’ve made makes all that information available and adding it is mainly figuring out a way to display this information without resorting to make it an ugly load of text. But I’m sure the great oxygen people can figure out a nice final design before 4.2.
There’s more interesting stuff that could be added to kuiserver (showing progress in drag handle, let applications register custom actions), but first I’m going to focus some more on the extender side of things. After all, that is where my summer of code project is about, and kuiserver is just a convenient test case.
Ooh, little screen of the kuiserver with actual working pause/resume/cancel buttons (and a little bit of other polish):
More kuiserver and extender goodness
The reason why the middle finished transfer still shows a stop button is because that’s the way to remove the item from the kuiserver. But once I’ve changed kuiserver to let finished jobs ‘expire’, that won’t be needed anymore. The middle transfer is also ‘collapsed’ so it takes up less space. By clicking the icon, you can expand/collapse items.
Now I’m going to focus on reviewing the extender api. I’m looking for feedback on the api as it exists currently, so it can be improved. If you’re interested, the current api is on the plasma-devel mailing list (subject: Extender api review). After this review I will merge the extender branch into svn so it will become easy for anybody running trunk/ to test the extender api and kuiserver applet.
Tags: Add new tag
pindaBlog 
July 24, 2008 at 7:49 pm |
I’m waiting this feature. Actually I’m waiting more 4.2 now.
Is it possible to detach one job from list as separeted plasmoid? I like the idea how the finished jobs stays on the list, so when you come back later, you can see them finished and you dont forget them.
And I just got question in my mind, for me it feels that KDE has got lots of popularity now when KDE4 was released (first betas etc) but what happens on future when we are on 4.3 or 4.4? Are we still as active commenters? 🙂
July 24, 2008 at 8:01 pm |
@Fri13: Yes, detaching jobs is easy, since they are just extender items. You can just drag them away and drop them somewhere in the panel or on your desktop. And the kuiserver applet doesn’t have to do anything special to make that happen. And don’t worry, if I’m adding the expire functionality it will be configurable so you can choose if finished jobs stay or disappear after a while.
July 24, 2008 at 8:35 pm |
Great, I’m looking forward to that feature.
Just a quick theoretical question: What happens if someone goes barking mad and decides to remove that nifty plasma applet? Will he still get any hints, i.e. is there a fallback to the old ugly progressbar dialogs?
July 24, 2008 at 9:03 pm |
Hi,
awesome work… 😉
should the finished Job in the “collapsed Mode” show the name of the file or task?? if there is only a “Finished” as description and i’ve got many downloads, i don’t recognize where my desired file is !?
cu
July 24, 2008 at 9:38 pm |
cool. An extra history window would be cool also. This could just be a listview were you could look up to which folder you actually copied that file ( I admit that happens sometimes to me) 😀
July 24, 2008 at 10:43 pm |
@Milian: At the moment it doesn’t fallback (if you haven’t got a kuiserver runner, you won’t see any transfers). However, it wouldn’t be very difficult to have it fallback to the old dialogs. So that’s definitely coming…
@els: Yeah, that would probably be a good idea.
@teezee: hmm, or maybe the kuiserver applet could use 2 extenders, one with the running tasks, and one which shows the completed task. That way items can still be detached.
July 25, 2008 at 3:03 am |
@els+pinda: How about making the finished (and collapsed) task automatically expand during mouseover? Then it would be easily visible what this particular task was and nothing gets closed accidentally.
@teezee+pinda: There could be a kuiserver history that is accessible from the systray icon and which includes closed tasks.
Also, queing policies would be great. I.e. the ability to set that only a certain number of (certain kinds of) jobs can run parallely. Right now, for example, multiple file copy tasks happen at the same time which can be quite annoying performance wise.
July 25, 2008 at 3:07 am |
Yet another idea: when discussion nepomuk moths ago, sebas talked of the possibility to automatically tag files downloaded from the internet or received by email with the original address or name of sender. I am not sure where such functionality would be implemented, but it would make sense to me if tagging of kjob objects would be done by the kuiserver.
July 25, 2008 at 3:15 am |
I still hope there’s gonna be more info shown on the progress windows… like speed and remaining time, etc…
But it looks good so far 🙂
July 25, 2008 at 6:58 am |
Tagging of files downloaded should probably go in the application that initiates the KJob, because it has the actual useful information, i.e. if KMail is saving a file to the disk the kuiserver wouldn’t know that it was sent from X, the subject Y, and at time Z. There might be some information kuiserver could add, but the application would be in the best spot.
I’m definitely looking forward to getting rid of those little file transfer dialogs that pop up every now and then (like when you open Get Hot New Stuff). Keep up the awesome work!
July 25, 2008 at 9:36 am |
Is the API already in svn somewhere so I can test it, adapt to it?
July 25, 2008 at 10:47 am |
Just in a word … GORGEOUS!!!!
Thanks Rscheepmaker the graphics is much and much better than the first screenshot. I got what you stated about the sub-progresses, maybe someday the kuiserver will grow, maybe not… but the most important thing is to merge it in svn and have it for 4.2 release. The OS community will do the rest.
I think that this concept is going to get a ton attention from the desktop makers and become a standard for all desktops (including proprietary ones).
I’m really excited to play with extenders too, can you make a youtube about them?
July 25, 2008 at 11:56 am |
Have you considered some kind of indentation? This would give more relevance to the title.
I don’t know why, but the progress text/bar look a bit detached from the title. Maybe you should somehow group them together… with a border… with a gradient… with a line
July 25, 2008 at 1:34 pm |
@mutlu: queing policies, and nepomuk tagging would be something that would have to be done by the application that creates the kjob. Not only does the application have more information available, kuiserver is only a visualization for kjobs so it’s not really an appropriate task.
@Sebastian: the api is posted on the plasma-devel mailing list and up for review. After the review I’ll merge it into svn so you can test it. If you’re really curious you can also fetch my git branch from git://gitorious.org/plasma-extenders/mainline.git . Be warned that this branch is still based on beta 1 though.
@Murdock: yeah, the look of the kuiserver could improve a lot. But that’s something I’ll leave to the oxygen guys, who rock at that sort of thing. Oh, and I’ll probably make a little screencast today or tomorrow.
July 25, 2008 at 1:59 pm |
“Also, queing policies would be great. […]ight now, for example, multiple file copy tasks happen at the same time which can be quite annoying performance wise.” (mutlu)
Not directly related but it reminds me this nice utility that I used to use with Windows.
http://ultracopier.first-world.info/
It seems they are rewriting it in QT now… :).
July 27, 2008 at 2:11 pm |
This looks just cute.
Maybe the following idea is usefull and implementable:
Please add an option which adds the possibility of changing one files destination-folder or name.
Why?
Because sometimes when I download a huge file to a specific folder and name (lets say “~/Documents/spec.pdf”) I find out, that another location would be more appropriate. Of course I could cancle the download and start again or fire up dolphin or konsole to change it manually after the download, but I think clicking on the job and selecting s.th. like “switch-destination” and entering “~/Programming/ada-spec.pdf” would be easier and more comfortable.
Greetings from germany.
Benjamin
July 29, 2008 at 10:40 pm |
Great idea !
My 2 cents :
Why not making a kind of “universal events on my computer viewer” ? Actually, the API seems specificated for “duration” events : file transfert, cd burn… A start point, progress, and operation is finished.
Why not adding “one time” event. By exemple a mail arrived and the plamoid show the title and who sent the mail. KTorrent finished a transfert, I may see the information in this plasmoid instead of the ugly popup in the corner. “On time event” automaticaly disapeared after ” a certain amount of seconds”.
Example of “one time” event : mail recieved, torrent downloaded, adept has completed the update (adpet ha its own progress bar, but most of the time I don’t want to see the progress. I only want to know when the installation is done).
Or I can be noticed of an appointment (by a flashy color).
Another kind of event : something append on my computer and I need to be informed until this information is valable. By exemple, the network shut down. The information is noticed in the plasmoid until the network is ok.
This plamoid would be the “wizard” of the desktop. And it would be great if this plasmoid automatically closed when there is nothing to show. I don’t need to bother my desktop with an empty box when there is nothing to show.
Greetings for France/Bordeaux
Christophe
August 1, 2008 at 7:44 pm |
Hey, “Christophe Durandeau” has an interesting idea. Knowing a little more about the underpinnings of KDE, I’ll put it more concretely: What about adding libknotify support? I don’t know if there is a KNotify plasmoid yet, but since KJobs and KNotify events have some things in common (They both display the calling application, and they mainly display temporary things.) it might be worthwhile to see if they could share a plasmoid, or if not, make the plasmoids look similar. (To provide the user a consistant look for messages from Applications.)
But obviously, please, I just want something/anything for KDE 4.2, so as awesome as some feature ideas are, I’d be happy with just something that showed file copying, K3B, and downloads for 4.2.