Extender grouping and notification images

Last week I’ve spent some time on adding grouping support to extenders, and laid the foundation for grouping jobs in the plasma systemtray.

The grouping support for extenders is accomplished through the new ExtenderGroup class. ExtenderGroup is a subclass of ExtenderItem that adds an expand/collapse button to show or hide all ExtenderItems that belong to this group. You can add ExtenderItems to a group by calling setGroup on the items.

The grouping support for jobs currently uses this feature to show the total progress of all jobs. By expanding the group you can view all individual jobs. See this screenshot to see what this currently looks like:

Extemder grouping

The green arrow (we’ll need a better icon for that) hides the 2 jobs, keeping only the “2 running jobs” part. The nice thing about this is that by default you’ll only see this total progress when copying stuff, which doesn’t take up as much space as the detailed individual jobs. You can also notice the just added support for showing custom images in plasma styled notifications, which is used here to show a contact image. The oldschool passive popup notifications supported this, but the plasma notifications didn’t until now.

The handling of jobs in the systemtray could still use some more work (the layout of the individual jobs could still use some improvement, and maybe the global job progress should show a little bit more information), but you can see the direction we’re taking here.

Also notice the plasma theme that’s used here: Air, which will be the default for 4.3. The progressbars need some work (yes, you can see how far the bar has progressed if you look very good, and no, this isn’t very clear atm to say the least), but then again it’s still a work in progress. It’s starting to look very slick though.

Advertisements

31 Responses to “Extender grouping and notification images”

  1. Diego Says:

    Looks really good to me! Good job!

  2. xyz Says:

    good job
    one stuff i don’t like about kde 4.2.1 is that kopete notifications stay there until i ignore them, they don’t disappear after a while like kde 3.5…

  3. anon Says:

    I personally hope the progress bar will be turned in a solid line. Those fixed size progress blocks never made sense and just makes it harder to see any progress if it is going slowly.

    Other than that: nice progress! (no pun intended)

  4. rscheepmaker Says:

    @xyz: well, a notification that somebody said something to you is supposed to be persistent. (the way I remember it that was also to case in kde 3.5) So if you get back to your computer after you’ve been away for a while, you can directly see who tried to say something to you in your absense. Whenever you click one of the buttons, or when the chat window get’s focus, the notification will disappear.
    Problem in 4.2 is that every time somebody says something to you, a new notification is added, which means that you could come home to an enormous stack of notifications, which might not even fit into your screen. In trunk however, multiple notifications are combined (notice the +”14 messages” in the screenshot), so that isn’t a problem anymore.

  5. Sergio Pistone Says:

    Looks nice. I really like where things are going.
    A couple of minor quirks I found with current notifications:
    a) The “0B/s” speed indication for copy operations. I see it all the time, probably because it’s used whenever there’s no clue on what the current speed is. In that case, it’s not only uninformative, it’s confusing as it suggest a stalled operation when that’s almost never the case. I would suggest replacing the speed indication altogether with an ETA estimation, but that’s likely more work than just hiding the label when speed is 0.
    b) The file notifications remain for a while after the actual job is finished. That’s ok (and probably wanted) for most notifications but in this case it makes telling when the real job is completed more difficult than it needs to, because the notifications icon keeps showing in the tray bar (suggesting the operation is still ongoing) and, since the popups are hidden after a while, you have to click the icon to see if they are finished or not. Maybe there should be a way to flag notifications for immediate removal?

  6. Nikos Says:

    Hi, nice work 🙂 The theme is also very nice, but I think the inside parts of the notifications (single elements and layout) need some refactoring. “From/To” is more direct and compact and less technical than “Source/Destination”. Also, I believe these should be left aligned, it looks awkward as it is now. The progress bar looks a bit too retro for such a modern looking theme and the bitrate+progress in written form would look much better under the progress bar in a more tidy fashion.

  7. rscheepmaker Says:

    @Sergio:

    a) A very valid suggestion,

    b) The solution we discussed at Tokamak is replacing the job widget by a notification that also allows you to open the file. This will look different (no progress bar, different text, an open button), so it’s immediately obvious it it completed.
    Something we might do is grouping them under a different group (“3 completed jobs….”), where the group widget has a button to clear them all… a bit like how firefox handles downloads in a way. This is something that we still need to discuss some more.

  8. rscheepmaker Says:

    @Nikos: don’t worry, we’re still working on improving that. 🙂

  9. AdeBe Says:

    Fallout2.iso 🙂
    Great game, I’ve played (and finished) it more than 10 times.

  10. Jeff Says:

    I like where things are headed. I do have a question though. Not sure how to best phrase it, so please bear with me.

    I’m using openSUSE’s Factory:Desktop repo (4.2.x snapshots). I fairly regularly have copy operations going on with the notification applet (from fish://foo to /bar/). When I click the applet, they hide themselves. Let’s say I have Kopete running, and I get a little pop-up saying someone is now $STATUS. That pop-up makes the copy dialogs reappear. But, when the $STATUS notification goes away, the copy dialogs remain up, so that I have to click the applet to hide them again (kind of a pain when playing videos). Has that been addressed? Or is that a distro issue?

  11. Harry Says:

    Looks really nice, but I miss the remaining time on the copy progress notification.

    Regards, Harry

  12. David Says:

    @rscheepmaker:
    Kopete notifications could be hidden, without discarding them, as with file operations. When you return to the screen, you would click on the notification tray icon and see what is there.

    The problem it solves is that when I am in do-not-touch-mouse-or-other-app mode, the notifications disturbe my work, very much.

  13. IAnjo Says:

    The plasma notifications DID support images, though it was a bit of a hack :). It worked because plasma notifications accepted html, so the img tag was fair game.

    See:

    http://trac.gajim.org/ticket/4749

    But hey, proper support is even better 😀

  14. xyz Says:

    @rscheepmaker mmm…right, groups in the kopete case will help a lot. actually the problem is not when you go afk, in that case is useful to know that there are new notifications. The problem is when you currently use the pc and a lot of people send you messages, the notifications increase quite a lot and fast. Ok that you can focus the windows to make them disappear, but if you’re doing something else you have to change focus everytime.

    What do you think of make the notifications persistent in the case you go afk, and make them disappear automatically after N seconds when you’re at the pc? i think that it’s easy to know this, when you use the keyboard/mouse you’re at the pc, when you’re not using them you’re not using the pc 🙂

    The automatically disappear would be also useful with full screen apps, like when you watch a movie (you’re not writing/moving the mouse, but you don’t want to pause the movie, and ignore the message, or for e.g. some other apps, like full screen games or other)
    What do you think?

    (i know that in the movie case or when you’re doing something critical the better choice would be close kopete 🙂 )

  15. Mark Says:

    Looks really nice and would be a great improvement if there is a central notification system. Will it be able to pick up notifications from apps with growl support? What I worry about is space, I think the notifications could be displayed more condensed.
    How are notifications organised internally? I was just thinking about the way facebook does them. There is this notification feed where are able to configure what notifications are presented to. Of course what facebook has is not good enough, but they idea is good. You get a small red icon in the panel telling you about the amount of the last notifications you did not see. Then you click out in and see a short list and if you want to the “the history” or configure them you can see the whole notification feed. Facebook is also able to notify you via mail. This may sound funny on your desktop pc, but it may be an interesting function to relay the most important notification to another location via SMS or mail, when you are not there.

  16. rscheepmaker Says:

    Thanks for all the suggestions. Exactly how we’ll tackle some of the issues that came up is something that we’ll need to discuss among the developers. It’s always good to know what the primary usability issues are.

    @Mark: currently it picks up any KNotification, which means it works for any KDE app. Unfortunately the world of notification specs is a bit… ehm… chaotic at the moment. We lack a freedesktop.org standard. There’s galago, which for some weird reason thought it was ok to claim org.freedesktop.notification, even though it’s not a fdo standard and has some issues. There’s our own VisualNotification which is quite similar to galago, without some of it’s stupidities. And then there’s mark shuttleworth who seems to have it’s own idea with regard to notifications.
    But the systemtray is written with extensibility in mind so it’s easy to add support for other notification systems to the plasma systemtray.
    Also, we do want to provide some form of notifications log, so you can view previous notifications.

  17. Luis Says:

    The notification system is outstanding, but I personally believe tasks and notification should have some difference in their presentation.

    Also (of course, that’s not up to you, the plasma team) you have to get rid of the non-sense ignore notifications, if you don’t click them, that’s truly call ignoring.

    Also, they should have 1 actions, and some others any action.

    My point, is that tasks could have much more actions and be presented differently, while notifications (like a future integration with media players) should be presented different (using the same system, but maybe pop-up with different shape or something).

    Cheers to all Plasma and KDE developers.

  18. null Says:

    How about merging both Shuttleworth’s and kde design. Non intrusive notifications like (brightness, volume up, volume down) shown at the top or with a different color and notifications that require user action like kopete message or user came online bottom/different color.

    The copy process bar definitely needs a cancel button along with pause/start buttons, there have been a number of times when i wanted to cancel the copy but i just couldnt. why can i just start and pause, a cancel button is also definitely needed

  19. Sebastián Benítez Says:

    Nice, except the Air stuff going into kde 4.3 as default. It’s horrible :S

  20. rscheepmaker Says:

    @Luis: by tasks you mean jobs? We talked about wanting to add one action for finished jobs, (in case of file transfers that would be open). I don’t agree about the difference in presentation. I’m all for consistency. Or do you have any concrete idea?

    @null: hmm, I don’t think I really like the idea of having 2 different types of notifications.
    About the cancel button: it’s there…. that stop button right next to the pause button…

    @Sebastian: well, lucky enough for you there’s still a lot of other themes to choose from.

  21. Nueva funcionalidad para los plasmoides: ExtenderGroup | KDE Blog Says:

    […] Mas información: Pindablog […]

  22. Luis Says:

    @rscheepmaker: Yes, I meant jobs.

    The reason why I think two different presentations (one for job and other for nofications) are needed is because they are, in fact, two different things.

    Notifications: They should disappear after a given time. Usually they don’t need to have an action (a button to press), instead, clicking the notification itself should trigger the action. No need of a “view messages” and “ignore”. If I click it, then it brings the conversation to focus otherwise, it doesn’t. In some cases, notification could have two actions, in such a case, button are needed, but most of the time, Notification don’t have more than 1 action, if any.

    Jobs are different, usually, you want to see the progress of you job, If you’re burning a CD, rendering a video or copying files. You don’t want them to disappear unless you command them to.

    That why I though it could be a good idea to have different presentations. But, of course, you could still use the same shape for both, I think it could confuse some users (maybe I’m being paranoid).

    Anyway, congrats for the plasma devs 🙂

  23. null Says:

    Hmm the last time I tried hitting the ‘stop’ button, but I think it just leaves the partially copied file in the destination? is this the current method?

    what I meant was cancel (meaning the partial-destination file gets deleted) like when you click cancel on the downloads on firefox for example.

    or is this what the cancel button does now?
    cheers

  24. rscheepmaker Says:

    @Luis: yes, jobs have some difference in behavior. Still I think it’s more important to have a consistent look and feel.

    @null: ah, ok, then I understand what you mean. No cancel keeps you’re partially completed file. Indeed it might make sense to delete partially completed transfers, but that’s up to kio.

  25. Freddie Says:

    Any chance of adding the capability to remove items from the notification list?

    For example, if you have a file transfer in progress, and the app doing the transfer (kget, for example) crashes, then you are left with a file transfer notification until you reboot or logout/login. Very annoying!

    Sometimes, restarting the crashed application will clear out the stuck notification, but not always.

    I’ve had kget and ktorrent notifications stuck onscreen for several days, and it’s annoying/frustrating to have to keep clicking the icon in the systray to hide them all the time.

  26. null Says:

    so can we have another button for ‘cancel’ please?, it is a pain especially after copying half-way you realise you already have the file in another location. and because file transfer dialogs always had ‘cancel’ that deleted the partial destination files

  27. rscheepmaker Says:

    @Freddie: note that the solution here is not to add a close button, but to make sure the job also disappears when the app doing the transfer crashes (or just make sure apps never crash 😉 ). Hmm, actually, that shouldn’t be too hard, I might take a look at it this weekend.

    @null: I don’t think adding an extra button for that is a good idea. (stop AND cancel? a bit… overkill and confusing) It’s probably just what the stop button needs to do, but again, this kind of stuff needs to be handled by kio for things to be handled properly, and that’s not really my area of expertise. The plasma widget just tells kio that it should terminate that job. You can of course always open a wish at bugs.kde.org… Oh, and the cancel in the old school dialogs does exactly the same thing here btw (not deleting partially copied files) Maybe you have some distro specific patches that take care of that?

  28. Freddie Says:

    Heh, if only it was as easy as “make sure apps never crash”. That would be the best solution. 🙂

    Until then, having the notification go away when the app goes away would be good.

  29. «Nuovo dispositivo» in Plasma, perché non un extender? « pollycoke :) Says:

    […] Effettivamente però è proprio l’idea di un plasmoide tutto dedicato alla sola funzione di notificare nuovi dispositivi che mi puzza. Perché non sbarazzarsene per utilizzare invece gli ormai comodissimi extenders? Guardate qui cos’ha pubblicato Rob Scheepmaker: […]

  30. a c Says:

    Hello, I hope it’s not too late to make a suggestion. I’m using KDE 4.3.2 and an auto-hiding panel.

    First, all notifications pop up above the coordinate where the panel would be visible (when not hidden), which is annoying – afterall, that’s why I have an auto-hiding panel, to make full use of screen space. All notifications should pop up above the panel, when it is visible and at the bottom of the screen, when the panel is hidden (it’s a bottom margin panel).

    Next, I desperately need some notifications to remain on the screen, independent of any timeout – in other words, truely persistent notifications.
    Take Kopete for example. When a new conversation is started by somebody else and I am not paying attention to the screen during the notification display time, hours can pass before I realise there’s some aggitation in the system tray (given the fact that the panel remains hidden).
    Don’t you think that persistent notifications should remain ON THE SCREEN at least when the panel is hidden? Since there is a grouping mechanism in place, I don’t suppose it can endanger the screen space in the case of a prolonged user absence 😉

    In KDE 3.5 persistent notifications where always staying on the screen until I took some action with respect to them.

  31. rscheepmaker Says:

    @a c:
    For the first suggestion there’s actually an open wish on bugs.kde.org. It’s a fair suggestion, it’s just that right now I’m lacking time to implement that. I’m hoping to be able to implement it in time for 4.4, but no guarantees. Patches are always welcome!

    The second suggestion: that’s intended behavior. You can disable the autohiding behavior in the system tray’s settings under Auto Hide. In that case persistent notifications will stay on screen, non persistent notifications will still dissappear normally after their timeout.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: