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):
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