The Road to KDE 4: Job Progress Reimagined

Wednesday, 24 January 2007  |  Tunrau

Have you ever had your taskbar filled with 10 applications all doing something that involved waiting for a task to finish?
Document Printing Progress, a K3b CD burning dialogue, Audio Encoding via KAudioCreator, File Transfers in Konqueror, Kopete, KTorrent, checking email in KMail... The new Jobs support in KDE 4 will unify the display of progress for these tasks, making it easy to see and manage what is happening on your system. Read on for details.

Picture it as a cross between the Firefox download manager and the KDE printer queue, except that there is no real restriction on what type of jobs can be monitored. The way it works is that each KDE 4 app that has a progress dialog adds a flag for something called an Observer. Then, a separate application can observe any running Jobs, displaying progress and even adding certain actions (like "Cancel Download") which can be submitted back to the application that actually has the progress dialog. So the applications like K3b, which already have very good progress reporting, will not lose their existing dialogs, but rather additionally permit this new applet to observe its progress so that all the progress bars can be pulled into a convenient place.

What started as a mocked up KDE 4 Improvement via KDE-Look.org has turned into a full-fledged KDE 4 integration project, thanks to Rafael Fernandez Lopez. And there's been a lot of progress to the point where applications are already being adapted to the new infrastructure. Last Tuesday's "Binary Incompatible Changes" day saw much of the changes officially committed to the KDE 4 repository.

Below is the original mock up, done by KDE user and KDE-look.org contributor kiras, used with permission. Click to see the full-sized mockup.

mockup from kde-look.org by kiras, with permission

Please keep in mind that the above is a mockup, and does not necessarily reflect the ultimate look-and-feel goals of KDE 4, Plasma or Konqueror.

Currently, it is being prototyped as a standard system tray applet (similar to the printer queue in KDE 3.5.5) which would allow interoperability with GNOME's tray implementation as well. However, at this point only KDE applications can be observed, so monitoring download progress from Firefox for instance, is not currently supported. That is not to say it cannot be made to happen in the future since progress is observed using the standard D-Bus interprocess communication architecture. There are intentions to collaborate with the GNOME project's Mathusalem team, a project of similar scope as this one.

Here is a screenshot of the current appearance of the monitoring application as it would appear when clicking on the tray applet. As you can see, it's already looking very useful.

uiserver screenshot, KDE 4

As you can see, the Kopete buttons are mostly just placeholders at the moment, and only exist for testing purposes. However, when you click on one of those buttons, it actually sends a signal back to Kopete, and Kopete itself pops up that smaller dialog you see.

The Konqueror download progress bars you see being monitored represent an actual file download in progress. They continue even after Konqueror is closed. Useful action buttons like "Abort Download" are in the works.

If you'd like to get involved in KDE 4 development, adding support for the new KJobs progress monitoring is a fairly easy entry point to KDE programming. It takes only a few lines of code to adapt an application to display progress, and a few more lines to make the action buttons useful.

This new progress monitoring technology will be able to be integrated into Konqueror (like in the mockup), desktop applets, and anything else that uses D-Bus. I can even imagine a small web-app that lets you monitor progress remotely...

Rafael's goal after the initial implementation is completed is to add persistence, such that when a job is complete, it would optionally stay listed until closed by the user. He is also looking for feedback on this tool and its implementation for future improvements.

Look forward to more feature articles showcasing more great technologies for KDE 4.

A quick note on methodology: I make sure to use the KDE defaults for all of my screenshots, even if it's ugly, since then you can get a better sense of progress as KDE 4 evolves and grows from week to week. As a rule, all of the features I've demonstrated so far are publicly available in SVN, and anyone can reproduce my results. In today's article, I had to uncomment a single line of code to enable this in-development feature, which is an exception to my normal rules. Additionally, the Kopete progress support is not yet in the official KDE SVN repository, but Rafael uses it to test features.

Comments:

Now we just need the plasmoid - tikal26 - 2007-01-23

ok so this is great I begin looking foward tot he day when things like this would start poping up. I guess all that we need now is the bar plasmoid and some polish to make it great.

Re: Now we just need the plasmoid - kollum - 2007-01-23

"...blicly available in SVN, and _anyone_ can reproduce my results..." I try but I don't manage. Seems to fail during the build of kdelibs. But, the day befor yesterday, Qt didn't compile, know it does, so.... :) Nice article, and not so ugly sreen shot compared to mockups. Pre alpha software may be not so smart, because it cause a "I whant one" thing in you, but if theire were ugly things, I would try to compile too :) just for fun.

Re: Now we just need the plasmoid - Inge Wallin - 2007-01-24

Don't try to build kdelibs during a monday. That's the day when incompatible changes are introduced. And remember that monday takes 48 hours, since it covers all of the globe in 24 different time zones.

Re: Now we just need the plasmoid - Andreas Leuner - 2007-01-24

>Don't try to build kdelibs during a monday. Or: Don't try to build a monday's checkout of kdelibs. :-) -> svn co -r { [perhaps saturday's date] } URL is your friend.

Re: Now we just need the plasmoid - Thiago Macieira - 2007-01-24

This time of the year, the globe has 25 timezones, not 24. New Zealand is actually now in GMT+13 (more than half a day ahead of GMT) because they are in Daylight Savings Time. Trivia of the year...

Re: Now we just need the plasmoid - Thomas Zander - 2007-01-24

> This time of the year, the globe has 25 timezones, not 24. > New Zealand is actually now in GMT+13 (more than half a day ahead of GMT) > because they are in Daylight Savings Time. They are actually in summer time but the GMT+13 is correct, yes ;) Quite near where the EU goes one back to summer time, they go to DST and the difference suddenly jumps from 12 to 14 hours. ok, straying too far off topic ;)

Re: Now we just need the plasmoid - Thorsten Schnebeck - 2007-01-24

... not 14 but 10 hours. (Geetings to my sister in New Zealand from Germany ;-) Bye Thorsten

Re: Now we just need the plasmoid - MamiyaOtaru - 2007-01-25

10 in one direction, 14 in the other (the world is round after all) :D

Digg this - Tsiolkovsky - 2007-01-23

Help spread the news about this great feature by digging here: http://digg.com/software/The_Road_to_KDE_4_Job_Progress_Reimagined_Screenshots

Original Idea - Marc - 2007-01-23

I saw this idea by Amaury Chamayou on the old kde-artists forum. Do someone know where all these beautiful mockups are gone ?

Re: Original Idea - Christian L. - 2007-01-24

You can find some of the stuff from the old kde-artists forum here: http://e-gandalf.net/wiki/index.php/KDE4_Features

Re: Original Idea - Lee - 2007-01-24

Yep, I came up with the idea, and Amaury mocked it up. It was very disappointing to have our hard work disappear, along with lots of other peoples' :/ Nice to see it back, in some form! :) It's a pity my other idea, about having audio volumes on a per-application-type basis, rather than on a hardware basis (so, volumes for background music, games, im notifications, etc.), didn't survive (or did it??). I was much more interested in seeing that in KDE4 ;)

Re: Original Idea - Lee - 2007-01-24

That said... the other mockup post referenced above has a great new idea, of having konqueror show file progress IN the file browser. As long as that's not the only place it's available (since I don't use konqi as a file browser all that often), it's really nice.

Re: Original Idea - Christoph - 2007-01-24

"It's a pity my other idea, about having audio volumes on a per-application-type basis [...] didn't survive (or did it??)." Phonon will probably be able to support this, it has categories for different types of audio, so it should not be difficult to set the volume according to that category. see http://phonon.kde.org/cms/1030

Re: Original Idea - superstoned - 2007-01-24

it'll support it, already does... i see now several categories in kmix from KDE 4 ;-)

Tanks for this series - stepan - 2007-01-24

I really like this KDE4 series, it's brilliant. Tanks

Re: Tanks for this series - Robert Knight - 2007-01-24

Thanks for keeping everyone informed Troy :) (Event though as a compulsive kde/trunk builder, I have seen much of it before)

Re: Tanks for this series - terracotta - 2007-01-24

Yeah it's really nice, and it just shows that KDE 4 is not just a hype, but that a lot of the stuff promised is going to be there.

which is to be noted - eMPe - 2007-01-24

as an incredible achivement of flexible libraries and forward-looking development. Wow, KDE does rule *soo* much..

Re: Tanks for this series - Joergen Ramskov - 2007-01-24

++ These articles have been amazing, can't wait for the next one :)

IF we had more developers - chri - 2007-01-24

KDE 4 would already have been released !

Re: IF we had more developers - Felix - 2007-01-24

Yes, and if we had even more developers, it would have been released in the middle of the last year. But the question is: If we had even even more more developers, is it possible to release kde before the first release and feature plan was made ?

Re: IF we had more developers - superstoned - 2007-01-24

of course!!! we would have had KDE 4 in 1995... :D

Re: IF we had more developers - Birdy - 2007-01-24

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Re: IF we had more developers - x - 2007-01-24

Actually some or all of that isn't applicible to Open Source Development.

Re: IF we had more developers - reihal - 2007-01-24

Could you extrapolate a bit on this? ( I am actually interested. )

Thanks - Daniel - 2007-01-24

Thanks a lot! This series definitely has me psyched!

please no vertical running text - cies - 2007-01-24

vertial running text is a design flaw in many case; allthough we can do it quite easily with oure strong qt backend i argue against all its use (in horzontal languages). there are about 3 words we can easily read vertical: B A R , H O T E L and S E X the others take significantly more time to recognise. (ok i understand that my examples are not exactly fit for use in this arguement :-/ sorry, i hope you get my point though...)

Re: please no vertical running text - Mark Kretschmann - 2007-01-24

Hehe :)

Re: please no vertical running text - Carlo - 2007-01-26

While funny, he's absolutely right. In some apps you use more often, you simply memorize in which region you have to click to change the sidebar view. But actually having to read the labels on these vertical tabs, sucks. It would be much better to spend a bit more horizontal space and use well chosen pictograms, instead labels. Problem is the (non-)accessibility of pictograms.

Re: please no vertical running text - winter - 2007-01-24

It's not the same kind of vertical text. That text is rotated, which is easier to read than vertical text, IMO.

Re: please no vertical running text - cies - 2007-01-25

indeed, that's what i meant by: > > i understand that my examples are not exactly fit for use in this argument still the other kind of vertical that is used in the mock-ups is not quickfast readable/recognizable. people even tend to turn their head for these kinds of tasks: really!

Re: please no vertical running text - Cerulean - 2007-01-25

I think entries are meant to be primarily recognised by their icon. In that case tilting your head to read the text seems fairly acceptable as it shouldn't be happening too often.

Re: please no vertical running text - Henk - 2007-01-26

In fact, I did turn my head! I see the space saving, but it is not read at glance.

Queued tasks - Leo S - 2007-01-24

In many programs there is the concept of queued tasks, (downloading usually) and in others, it would be really useful to have this feature. The one that I run into time and time again is copying a file on the local hard drive. Suppose I need to copy two large files to different locations on the same physical hard drive. They each have different start and destination locations. In konqueror (and any file manager) I can copy one, and it starts copying at a decent speed. Then I copy the next one and both slow down by an order of magnitude because now the disk is thrashing back and forth doing two transfers. If each transfer on its own would have taken 2 min, I would now be waiting probably 30 min for both of them to complete. What we really need is a way to queue file transfer operations for media that has issues with two operations at the same time. HTTP downloads can already do this, if you start more downloads than the server will allow from your IP, then some of them will not start until the others finish. I guess implementing this is more in the scope of konqueror, and not this job manager.

Re: Queued tasks - Rudd-O - 2007-01-24

This is not true. Modern Linux and UNIXes have advanced disk scheduling algorithms based on "elevators" (think of an elevator sweeping up and down a building) that avoid the thrashing and in practice two or three files copied simultaneously have almost no impact in total disk throughput. They also minimize the effects of disk fragmentation (though not so much).

Re: Queued tasks - Leo S - 2007-01-24

Well it sure is true on my system. Maybe I don't have this disk scheduling enabled or something. But just try it, if you copy two files on the same disk at the same time, they don't slow down more than 50% each? I find that hard to believe, as it completely contradicts my experience on every system I've ever seen. Can anyone back this up?

Re: Queued tasks - lanroth - 2007-01-24

I can back you up - it's an annoyance. Performance drops through the floor when copying multiple large files simultaneously. It would be great if this job progress manager allowed one to pause a job until another one had finished. Maybe: RMB->file copy job->pause this job until this job has finished->another file copy job This would have other benefits - you could start downloading a large .tar.gz, ask ark to extract it and then pause the task until the download had finished.

Re: Queued tasks - Zan Lynx - 2007-01-24

Reminds me of the time I ran Nautilus (GNOME file-manager for you KDE guys :) on a multi-processor system, on a CDROM mounted directory. Now, someone was smart and made Nautilus launch thumbnail generators in parallel, one for each CPU, and that is a good thing. Worked great on hard disk or network folders. However, on the CDROM I thought the system was going to crash, it got so laggy. Read a bit of file here, seek, seek, seeeeeeeeeeek, read a bit of file over here, seeek, seeeeeeek, seeeeeeeek, repeat. :)

Re: Queued tasks - Corbin - 2007-01-25

In my experience it's often the opposite of what you state (1 transfers at X MB/s, 2 at 1.5 X MB/s which often confuses me, though at some point adding more does cause it to go slower), though I think that a configuration option (probably would have to be in Konqueror, with the options based on the kio-slave) to say the number of concurrent transfers before queuing up new ones (with an option to allow 'infinite')

Re: Queued tasks - anonymous - 2007-01-24

you are wrong. although the elevator algorithm is rather good, you will still loose a lot of performance when copying two sequential files. reason being that for a single sequential file copy there is no seek time at all and the seek time is significantly larger than the time it takes to read a whole cylinder (ie. multiple sectors). this problem becomes more significant as hdd size increases.

Re: Queued tasks - superstoned - 2007-01-24

with a modern (>2.6.18) linux kernel and using the (default) CFQ scheduler, the performance difference will be very small (eg a few % max). so, not to worry about.

Re: Queued tasks - giu73 - 2007-01-24

Can you expand on this? I don't really know how CFQ works, but, the "Fair" in its name makes me think that it would not be the best choice for this scenario. Basically, we have two large tasks, with a very high switching cost between the two. To optimize performance, we should minimize the number of switches, that is serving each task for a very long time interval before switching to the other (the best being serving one task until it is completely finished and then going to the other). This does not sound "Fair", to me.

Re: Queued tasks - superstoned - 2007-01-24

but it is what CFQ does, both ensuring task interactivity AND increasing throughput. compared to the previous kernel scheduler, cfq uses longer timeslices, but has some logic to ensure reads don't slow down, and there are maximum waits for apps who want to read and write data.

Re: Queued tasks - Diederik van der Boor - 2007-01-24

If your system becomes really slow with copying files, verify whether you have DMA enabled. The Linux kernel does a decent job of scheduelling IO. In fact, once I had to copy a lot of files in Windows and back in Linux. Windows Explorer and IE froze while copying, and the disk made a lot of noice. Linux was very quiet, and only showed short disk activity after 5 files (~30MB). Copying the files took 3 times longer in Windows because it used the disk very inefficiently.

Re: Queued tasks - riddle - 2007-09-08

Yet another example of inefficient M$ products :)

The taskbar! - Luke - 2007-01-24

It'd be great if the taskbar were updated to take advantage of this so that each application could display at least one progress bar there, and maybe a mouseover would show you all of the progress bars for that application, as well as let you select the the one to be always displayed. While I'm asking, it'd be nice to see progress bars in the tab bar for every page that is loading :)

Re: The taskbar! - riddle - 2007-09-21

Agreed. That would make perfect sense. Something like this? https://addons.mozilla.org/en-US/firefox/images/preview/1122/3

Thank you all guys - Rafael Fernández López - 2007-01-24

Hi, I just want to thank you all your feedback. I am really glad to see people in general like what is going on at KDE trunk, and for KDE 4 series in general. * The plasmoid is the idea. When plasmoids specification are available, I'd like to write some kind of plasmoid for this, or maybe move what I have right now there, we will see. But I think you can bet for a plasmoid about jobs. * The queuing. Well, it can be implemented in the kuiserver, and I really think it would make sense here. I think it is really possible, and that I'm going to improve it to let you have an option for "Queue transfer jobs as they arrive", with the possibility to "Resume" the one that you want if you want to have some jobs on parallel. I really appreciate all your opinions and ideas. Thank you all again, Rafael Fernández López.

Re: Thank you all guys - A.C. - 2007-01-24

Hi Rafael, First of all, THANKS. You're doing an awesome job of an already nice idea and I'm highly looking forward to seeing your work make my life with the KDE desktop (even) easier. :) Speaking of optionally queueing tasks: shouldn't that be based on the *ressource* being used, where ressource would be 'disk I/O' or 'network I/O' and such? Sometimes it makes sense to download as much as half a dozen things at the same time, while moving no more than one local file at once. Well, hope I'm not talking out of my ass anyway... Thanks again!

Re: Thank you all guys - Carlos - 2007-01-24

Rafael, the job you've done is great, but don't you think there's way too much space used for each task? Imagine 10 tasks at a time and you'd have a huge scrolling bar.

Re: Thank you all guys - Troy Unrau - 2007-01-24

The application you see is an initial prototype useful more to prove the backend work is functional. When the plasmoid data engine is done, the applets should be able to format this information however they see fit.

Re: Thank you all guys - Shamaz - 2007-01-24

Thank you for your work Rafael ! About I/O job queuing, you may find some ideas here : http://sourceforge.net/projects/supercopier/ I DO know this is a Windows application, but it has interesting features : transfer speed control, transfer resuming (and pausing) and the possibility to change queue order. This kind of feature already exists in many http or ftp client. This is really something I miss for simple disk to disk transfer :(. Good luck !

Re: Thank you all guys - Max - 2007-01-24

Nice to see KDE is doing this via D-Bus, so even Gnome programs con benefit in the future. I've made two mockups for Gnome but perhaps you are even interested in it: This one shows the progress directly in the Icons: http://hagemaenner.de/stuff/gnome/ActiveIcons.png And this one in the Taskbar: http://hagemaenner.de/stuff/gnome/gTask.png

Re: Thank you all guys - Thiago Macieira - 2007-01-24

KDE is now doing almost everything over D-Bus. Remember that since last May, D-Bus is the official IPC/RPC mechanism for KDE 4. One thing I want to do in the near future (whenever I find the time) is to port KIO's own protocol to D-Bus. This would expose the ioslaves to D-Bus, if necessary. That's one of the two remaining non-D-Bus IPC mechanisms that I can remember right now (the other one being the communication between klauncher and kdeinit, but we won't change that). Now, I'd like to point out that this is not an unified VFS mechanism that many people are clamoring for. But it may be a start, if it proves useful, and it may pave the way to a real implementation.

Re: Thank you all guys - Sebastian Kügler - 2007-01-24

It could be done by adding an option "Start when [other_job] is finished", where [other_job] is a dropdown with all active jobs, for example. Jobs that let you pause them can have this feature enabled then. Just an idea, anyway. Thanks for the great article and this cool new feature which will reduce clutter significantly!

Re: Thank you all guys - Jens Rutschmann - 2007-01-24

Or by selecting multiple entries in the list, then Rightclick->"Queue Us" or something like that. Anyway I think this is a really cool feature !

Konqueror - Martin - 2007-01-24

Will we also see the lower part of the screenshot implemented, where Konqueror implements its own observer to show download progress in-place?

Re: Konqueror - superstoned - 2007-01-24

will depend on konqi, i guess... won't be very hard with the whole infrastructure in place, tough.

This is great! - Kevin Colyer - 2007-01-24

This is good news - I like this idea very much. It answers that question why do I have so many progress dialogs floating all over my desktop. I often need to know how a print job is progressing, how a file transfer is going. Having it all in one place will be so much clearer for me and new users. Ever seen a newbie look for info on a print job on any OS let alone KDE? Will it be easy to make hooks for CLI apps? I guess with Dbus it could be. I would love a hook to rsync so I can see how a my home brewed backup is going!

Re: This is great! - Thiago Macieira - 2007-01-24

If rsync -- or any tool -- outputs a percentage, it should be quite simple to write a bash script reads from a pipe, creates an entry in the uiserver and updates it. An example tool I can think of right now is cmake & KDE's own build. How cool would it be to see the KDE build percentage progress in the uiserver? :-) If you need to implement actions like "pause", "cancel", etc., you will find that bash+qdbus won't suffice. Scripting languages like QtScript, Ruby or Python will come in handy then.

ideas - me - 2007-01-24

It would be great if you could pause a job, reboot and continue it later (session management This might not be the uiserver's responsibility, but when copying a lot of files, is it possible to FIRST ask for confirmations for all to-be-copied files (do you really want to overwrite etc.) and THEN start copying? That way, I can leave the computer and be sure its done when I come back! The copying-two-files-at-the-same-time-becomes-too-slow-problem is even worse when you're reading them from a cd/dvd!

Re: ideas - boemer - 2007-01-24

Great Idee, one of the things that most irritate me, having a directory moved under windows and for every thumb.db, it starts to ask again, if I'm sure... I know it is windows... But watching this progress for KDE 4 makes me feel better every time....

Conflict resolution dialog - Boris - 2007-01-28

"is it possible to FIRST ask for confirmations for all to-be-copied files (do you really want to overwrite etc.) and THEN start copying?" Better yet, it would be great if the system popped up a conflict resolution window where you could check which files you want to overwrite and which you don't want to overwrite. Then it would be very simple to select all, and perhaps uncheck a couple.

Re: Conflict resolution dialog - Anon_Poster - 2007-02-02

I really like that idea. Perhaps a two-pane view file1.jpg 2/1/07 102K <-> file1.jpg 12/27/06 99K document.ods 2/1/07 73K <-> document.ods 12/29/06 99K where if you hover over the filerow you get a thumbnail comparison of those documents. With option to view details (which opens up in appropriate app). thumbnail \/ __________________________ | _______ _______ | | | | | | | | | PIC 1 | | PIC 2 | | | |_______| |_______| | | View det View det | |__________________________| Really ugly above I know but?

KDE4 looks incredible - Stromek - 2007-01-24

I cannot wait for the beta/RC and release. It is so wonderful, it is going to be so biiiiig improvement to desktop experience. I wish all the people to use KDE desktop!

Re: KDE4 looks incredible - wish - 2007-01-25

My wish is a peacefull world where everybody can do what he/she wants to (accept harming somebody AND something else). Why should all people use KDE? There is no meaning full reasing for such a wish. Wasn't that something good about all the Linux/BSD/Unix/KDE/GNOME/Fluxbox/... thingy? Use what best fits to you.

Re: KDE4 looks incredible - cirehawk - 2007-01-25

Yes, freedom of choice is one of the great things about open source. But I see his/her wish that everyone use KDE as an expression of excitement about the upcoming KDE4 (and KDE in general). There is nothing wrong with that. I didn't take it as trying to mandate that everyone use KDE.

Programmer queston - Diederik van der Boor - 2007-01-24

When I see examples like today at PlanetKDE (http://www.ereslibre.es/?p=11), I get a bit annoyed to see such generic name as "Observer" being used for this. How about a name like JobObserver or KJob::Observer?

Re: Programmer queston - Thiago Macieira - 2007-01-24

It's KIO::Observer right now. The name may change if it moves out of libkio into libkdecore.

Re: Programmer queston - Diederik van der Boor - 2007-01-24

Thanks!

This is very good - ra1n - 2007-01-24

I like this, it's not a new concept, you can see this in beos tracker and mac os finder, but limited to file transfers, now a good point would be interoperability, like you said there are already some talks with gnome folks, but I think that a further step would be some kind of freedesktop job queue with common API that can be implemented in every DE, so if I run kde and want to run gftp for example I could see gftp's jobs run in kde tasks.

Re: This is very good - superstoned - 2007-01-24

read the article: it'll be d-bus based, and they are already working on standardizing the d-bus interface.

Re: This is very good - ra1n - 2007-01-25

well it's not too obvious from the article, there are talks with gnome folks and the use of d-bus, but nothing it's decided yet, especially on the other side of the desktop ;-)

"Cancel" will finally mean something - oldschool - 2007-01-24

It seems this is a great use of multi threading - being able to cancel a long operation. Most Qt3 and KDE3 apps, even if they have a cancel button your are at the mercy of the event loop before if and when it decides to accept the cancel callback. I think this will go along way in making KDE 4 more user friendly. May I suggest that it be designed to not only work with DBus for interprocess communications but internal to the app itself. The goal being to make it simpler for programmers to do multi threading for simple thins like a "cancel" operation Way to go Rafael

Re: "Cancel" will finally mean something - Thiago Macieira - 2007-01-24

I hope to make it possible to use D-Bus to do that, so the integration is seamless. No promises though.

does it integrate with virtual desktops? - testerus - 2007-01-24

How is this supposed to work with multiple desktops? Is it going to be like the taskbar: "Show progress information from all desktops", "Group similar jobs", etc.?

The looks of the mockup are great. - Tom Corbin - 2007-01-24

Is that an existing look or something planned or just blue sky?

Re: The looks of the mockup are great. - Troy Unrau - 2007-01-24

Mostly just a mockup - kiras has some ideas of how he would like KDE 4 to evolve, which is good as some of the ideas are sound. Other ones are less likely to be implemented from his mockups. You see the little configure button on the window titlebar - well, his idea would be that when you click that button, the window flips over using OpenGL and displays the options on the backside. Not likely to happen for a variety of technical and usability reasons, but! the mockup sure looks sweet :) Konq at the moment looks pretty much like KDE 3's konq, except with improved HTML/Javascript rendering :)

This is great!! - kwilliam - 2007-01-24

I loved the mockup screenshot when I first saw it on KDE-look.org. I am totally excited to see that this awesome screenshot transforming into actual code! It's also bolstered my confidence that Konqueror will include improvements from some of the KDE4 mockups on KDE-look.org. This progress applet will be so cool! A huge THANKS to all the KDE4 developers out there!

mockup - vicko - 2007-01-24

http://www.kde-look.org/content/show.php?content=36385 http://www.kde-look.org/content/show.php?content=28476

Job Progress Applet - Alex - 2007-01-24

Um, I'd like to point out that some apps, like KTorrent may have multiple tasks waiting to finish... Are we going to have drop-down lists of subtasks for each app? and display an 'overall progress' bar at the top of the list when it's collapsed? Just an idea for making the app useful for one more potential user.

Re: Job Progress Applet - riddle - 2007-09-21

That should be fairly easy to implement... You're thinking like this, right? -------------------------------- -Konqueror file1 copy: [========= ] file2 copy: [============= ] +K4B +KTorrent -------------------------------- (Ugly, I know)

Re: Job Progress Applet - riddle - 2007-09-21

Oops, I just checked out the latest beta. It already supports that. Smile ;)

I think... - David - 2007-01-25

that the main panel buttons should reflect this. Whereas the windows taskbar buttons flash blue when the window wants attention, we could turn those buttons into miniature progress bars that would scroll their text.

What about YOU? - great - 2007-01-25

Hey user, ever thought abiut your role in this story? Your are not a programmer and you have no idea what you can do? You can contribute in many ways by donations and thinks like that. Help the developers to cover their affords and give them something since they have spended a lot for you. They need money for meetings, textbooks, travel cost, ... . KDE is a community project ... and you are the community! Here is how you can support KDE: http://www.kde.org/support/ But what do I see here? http://www.kde.org/support/donations.php What do I have to read? Last donation on Nov 28, 2006? Oh dear, isn'that poor? Remember, some little helps if a lot of people help a little! ;)

Really nice thought - Georg Grabler - 2007-01-25

I'm working daily with kde / kate to work off my development tasks. Though, it sounds very interesting, but the possibility to suppress those other windows from even opening would be worth a thought. I'm thinking on developing on a machine with kate, code being on another machine (compilefarm / testing), connecting by fish. By opening thos files, a hundret and three dialogs open which i don't really want to see. I'm aware that this is not what this interface is supposed to do, but still worth the tought. The folding idea on subtasks sounds interesting, like "program groups", as application you see on the right side on the screenshot (processing x tasks and on a closer look the list). Besides all those other projects i work on i could even imagine on getting my hands on this, since it could be a important feature for daily work, to see status of downloads copies transfers cd buring or ripping collected, without openeing one after the other application just to take a short look. Kind regards, Georg

new GUI - Anton - 2007-01-27

All of those improvements are good but I think it will be too hard to release on the current system. When I look at the mockup I understand that something looking like this is unreal without HTML+CSS-like technology. I think the better GUI improvement of KDE that can be is an ability to use XML+XSLT+CSS for rendering windows.

Re: new GUI - asd - 2007-01-27

why do you think limiting the rendering to html would be a good idea? kde styles are written in c++. they are programmed. you can do almost everything you want in a kde/qt style right now, while they are still very fast. using html based rendering for styles would only make kde realy slow. just look at firefox and its memory usage.

Re: new GUI - Anton - 2007-02-10

Why limiting? And why html? I meant just the stylesheet model but not the html self. Yes, you can do everything you want in a kde/qt style. But why then a lot of kde applications looks so ugly and awkward? And why all the kde mockups are so differ from their realizations? Because C++ programmers in most cases are unable to make good UI and good designers cant use C++. I'm saying this as a web-developer and a former C++ programmer. Firefox is not so slow as efficient with all of its extensions written by many enthusiasts. And firefox styles are also programmed ;)

KDE4 development - Pebete - 2007-01-27

"If you'd like to get involved in KDE 4 development, adding support for the new KJobs progress monitoring is a fairly easy entry point to KDE programming. It takes only a few lines of code to adapt an application to display progress, and a few more lines to make the action buttons useful." How can I get involved?

Re: KDE4 development - Troy Unrau - 2007-01-27

Contact ereslibre on irc.kde.org... he may be able to help you out with an example application or somesuch.

Re: KDE4 development - Pebete - 2007-01-27

Thank you.

Notifications too? - Colin - 2007-01-28

Its great that we will finally get a unified and tidy way of displaying and keeping task progress together and I'm sure this framework will make lots of developer's lives easier. I currently use Metamonitor (http://metamonitor.sourceforge.net) for getting notifications of certain events through system logs (such as plugging in USB devices and my backup scripts running, etc). Would it be possible to combine this functionality with this progress manager? They're both concepts that require a dialog to be shown for a certain period of time, usually near the system tray area for neatness and consistency and may be stacked up with several other dialogs. I also think it would be useful for it to show a recent history of notifications too as you can sometimes miss what these notifications say because of the popup auto-close (which is normally a good feature IMHO). Applications/services such as Kopete and KBluetooth could then use the same framework for their notifications.

Re: Notifications too? - Rafael Fernández López - 2007-01-28

Hi, First of all. This app is really great. I find it very useful. Well, all the available methods you can call are on kdelibs/kio/kio/observer.h. I don't recommend you to use them right now, because they can suffer strong modifications from monday to monday. Anyway you can take a look there and see what you find :) Bye, Rafael Fernández López.

One suggestion - Maciej Cencora - 2007-02-01

That's great idea. But please add an option "Shutdown computer after all jobs are finished" so user could go sleep, not waiting for printing/downloading/file copying being finished :) Can't wait for KDE 4 release.

I Know this doesn't have anything to do with this - dan - 2007-02-02

But what about doing something about the taskbar hell???? I Believe Steve Jobs got it right with Just showing icons for launchers, and then when you launch them they get an arrow to show they're active, and if you click it it shows the windows. Of course there is expose for kde, and its great, but I think kde guys should try to think something to improve the taskbar hunting hell... virtual desktops helps... sometimes... sometimes its more dificult to look for each desktop looking for the window you want. My biggest friend now is expose for kde because the taskbar is so slow to use. Let's learn from the masters! KOOLDOCK for everyone, or something even better? Some brainstorming in this area is needed!!!!

Re: I Know this doesn't have anything to do with this - JohnFlux - 2007-02-07

Feel free to make some mockups :-)

Window - Vladsinger - 2007-06-09

It would be nice if this could be implemented in a way that looks a bit more like the mockup, with a clean, borderless menu. That would be perfect.

Re: Window - Jonathan - 2007-06-10

It's look will be plasma's job. Just wait for it, I'm sure it will come

Job inerface for simply playing soundfiles? - Erik - 2007-08-25

This job progress interface can also be used to simply play a soundfile from the file manager, without opening a bloated media player with playlists and such, right? As far as I understand, the interface even supports buttons, such as pause and seek (for example the "Pause" and "Cancel" buttons in the dialog for the download of "install-x86-universal-2005.1.iso" in the screenshot).

Please conserve screen space - Anders Troberg - 2007-09-19

Looking sweet, and something I have wanted for a long time. However, the mockups, while looking good, do waste a lot of screen space and could be smaller. Also, without knowing anything about the underlying API's, it would be nice if it was possible to hook into it and listen to the status information. For instance, it would allow such things as adding LED bars on the computer case as status bars. Not only practical, but cooler than a great white shark with shades.