KDE 4 news: Plasma icons, Solid information and taskbar mockups

kde-logo-official
KDE 4 gains more and more speed these days, and it is hard to keep on track with all news and changes: Plasma introduced interactive icons, Solid now takes over the media, and the first taskbar mockups have been revealed

Plasma Icons

From the beginning of the reworking of the KDE desktop there were always people asking for interactive icons. The basic concept for this idea is outlined in this PDF file.

The Commit Digest issue showed a screen cast showing exactly that feature in Plasma:

In the screen cast you can see how the icon itself shows another icon when the user hover the mouse over it. Since this is a development version some things are still missing – like more “edge icons” like they have been proposed in the PDF file.

The more technical side of this Plasma implementation was covered by Aaron Seigo. He shows that the icon animations and all Plasma animations in general, while appealing, can be deactivated in a certain way, making it possible to also use KDE 4 and Plasma on thin clients or over a network connection.

Btw., as you can see drag and drop is already working. As a user you don’t have to take care about anything when you want to have Plasma enabled icons, it will simply work.

Solid

The same Commit Digest issue also covered some interesting parts about the current state of Solid. The kioslave medianotifier has been initially ported to Solid. Also, the mount/umount/eject functions of the desktop are reworked for Solid, featuring a more abstract attempt which might lead to support of cryptical or other more complex devices:

more portable, and that can do more than simply mount, think crypto volume, or unmount, think about ipods which need an eject

That reminds me of a bug I filled a long time ago regarding the auto-recognition of cryptfs/LUKS devices. I would be very pleased to see this in KDE 4!

Panel mockups

Nookie showed mockups of his idea of the KDE 4 taskbar:

Nookie’s panel mockup, part one

Nookie’s panel mockup, part two

The basic idea is that your bar is split in two parts: on the left hand you have the window bar, and on the right hand you have the system tray. The content of each bar is only coming up when you hover the mouse over it.

I particularly like the idea of breaking at least a little bit with the usual way of showing and viewing task bars: the idea to place the menu in the middle kind of makes sense since the most important bit should be in the middle – and for most people (not for me, I don’t use it at all!) the menu is most important.

But this mockup also reminded me of one of the basic ideas of Plasma: with Plasma writing your own task bar should be much easier, which is in contrast to today where kicker is said to be a nightmare (from a developer point of view).
So I really hope that there will be more than one task bar to choose from with the start of KDE 4 – at least two. That would please many power users and would also show the immense capabilities of KDE 4 and its new base technologies.

About these ads

49 thoughts on “KDE 4 news: Plasma icons, Solid information and taskbar mockups

  1. Corner digest could be a good idea, but it’s too hard for user: the one should remember, which action every corner represents and also remember that those actions are different for different filetypes. Too complex, like lots of things in KDE.

    Panel is even worse. Unusable, actually. I don’t want to move anything to see what applications am I running at the moment. And it’s even more bad with systray. System tray should stand for notification area. How am I supposed to see it something changed there if it’s hidden?

  2. About the corner digest: the actions would not only be indicated by the corners but also (and maybe that’s the main part) by the colours of the icon in the corner and the simple texture visible there.
    I doubt that this would be to hard to get for average computer users – most of them do know how to use the right mouse click to access different actions in a file manager and therefore coloured icons in separate corners is not more difficult.

    What facts or sources do you base on your estimations? I work as a Help Desk and have to deal with several different kinds of computer users and judging by that coloured icons in different corners is much more accessible for users than a right-click menu.

    About the task bar: I don’t need the task bar to know which apps are running, I only need it to access them faster. I usually know which apps are running anyway. I’m not sure at this point how the average users sees that but therefore I raised the idea to have more than one solution available with KDE 4.
    And about the system tray: it is common these days that system tray apps which do need your attention or want you to notice something open a message bubble. So no, the system tray is not the notification area, the bubbles are the notification area! This is common among at least Windows, Gnome and KDE and makes much, much more sense then looking at tiny task bar applications.

    And in case of a hidden system tray than the tray applet might come up automatically.

  3. “and for most people (not for me, I don’t use it at all!) the menu is most important.”
    ? huh, post screenshot of your desktop! pleas :)

  4. I dislike having the menu in the center. There’s a usability rule that says that the 5 easiest places to move the mouse to are the top left, top right, bottom left, bottom right, and where the mouse is currently. The problem with having the menu in the middle is that it doesn’t harness the ease of being in a corner: if it’s in the corner, to open the menu it’s just a quick, imprecise move away…

  5. I don’t use my systray like you do. I prefer having static icons that simply change when something else does. I *hate* those popups. Static icons means that I can always see the status of those elements just by looking down there, and not have to move my mouse. I don’t want to have to move my mouse to find out whether or not my trackpad (and its scrolling functions) are disabled or not.

    Will we at least be able to disable this version of the taskbar and go back to what we have now?

  6. Looks great.

    I like the idea of combining the taskbar and systray. Apps like Amarok would be fine with a single icon. But I never thought it out very thoroughly.

  7. I’m with sheepbat – I hope that there will be a means to make the systray icons be static. I’m all making things look nicer, but the popup systray icons feels like adding additional unnecessary steps that hurt the overall usability.

  8. I agree with rusty_angel, Chippy and sheepbat. Those mockups are pretty bad usability-wise, for all the reasons they list. Additionally, I presume that there would be some smooth sliding animation when the window list/system tray appears, which would take time, and reduce the usability of a window list even further. i.e. To even see which windows you have open, and switch to one, you have to wait for the list to open, then read it and react, rather than just reading it while you move your mouse to the bottom of the screen, and then acting.

    But it looks pretty, which is the most important thing. ;-)

  9. It looks cool, and I think a lot of the ideas will come out great, but like a lot of people I’m slightly concerned about the usability of some bits (i.e. taking me an extra second to find out something that I can find out immediately now).

    Also, I’d echo the person who pointed out that the corners are the easiest part of the screen to reach with the mouse, but then maybe the menu could be tied to a keyboard short-cut and we wouldn’t need the mouse at all!

  10. Pingback: Agent Ultra
  11. I’m not so sure i’d like the dynamic icons either, but given how i’ve never used them before, i can’t really judge. And really, anything that conveniently gives me more screen space for the things i’m using at that moment is a good thing, whether it be dynamic, or static.

    I think you guys need to remember that KDE is built around being flexible and customizable. Sure, the default icons might be horrific, but unlike with some os’s, they’re easily changed. and you can have that k-menu button anywhere you’d like.

  12. Thanks for the comments so far. However, please remind that the shown mockups are just mockups, nothing else.
    Also, the author is open for comments so you might want to visit his homepage directly and place your comments there.

  13. Need to have far more virtual desktops than the 16 limit. With computers having tons of memory, 16 is a constraint… I have to use Enlightenment, as its the only GUI that can do more than 16 virtual desktops.

  14. Everything looks great, I like the style, this has the potential to become a greater desktop than the actual KDE and be prettier than OSX’s desktop.

    I have one question though, and maybe I’m completly over my head here but here it goes. What happens when the animation hasn’t finished playing in the enterHover event and the exitHover event executes, the new animation abruptly interrupts the first one or does it play in correspondence to the one already playing (Example: in the case of the fade, if it hasn’t appeared entirely does it suddenly look completely opaque and then starts to fade out or does it finish to fade in and then starts to fade out?)

    Just curious, it’s looking good anyway.

    Regards,
    Albert

    PS: I’m not a native english speaker so please be gentle if I made any mistakes while typing this.

  15. @Albert: I have no idea what happens in such situations. You might ask Aaron about that (his original post is linked at the top) or join the plasma development e-mail list or the IRC discussions.

    And, btw., I’m also not a native English speaker…

  16. The only thing i hate about KDE is that big toolbar icons and general waste of space with oversized details.

  17. “the idea to place the menu in the middle kind of makes sense since the most important bit should be in the middle”

    Gak, no!

    The most important visual elements could arguably be better off towards the centre. But the most important interactive elements like menu buttons should be out in the corners, where they’re easier to quickly aim a mouse at.

  18. I will enjoy the new “addiction.” Small misspelling, but very funny.

    Good job on the new feature. Very useful and simple to use.

  19. These mockups still consume far too much real-estate appear to actually _increase_ mouse useage. KDE will wear its own users out!

    Firstly, screen area is increasingly valuable these days – it’s vital to recognise this – as more people want to see and do more on computers. Just having the panel bar floating 10 pixels about the base of the sceen suggests that the interface is considered more important than the work done with it. The space between the ends of the panel and the screen edges is not useable for anything – that’s dead space. Bad!

    Ultimately we should ask ourselves: Why is the panel visible by default at all?

    Is it as a container for the brand (for the KDE logo)? Not wanting to intimidate the user used to a bar being there – a sort of command-control desk?

    Why not just hide the main menu under a ALT-RMB-click or simply do with it being bound to the Windows key. This way people don’t have to use the mouse – untertaking these additional cognitive steps of moving a remote control device (the mouse) to move a small cluser of pixels (the cursor) over a small area of their screen (the menu icon) – to do something primary with their computer. KDE4 has a great opportunity to move beyond the WIMP interface and explore a future beyond this: .

    People’s hands are already on the keyboard! Don’t make them take their hand off to use the mouse all the time! Use this fact to productive advantage and place core functionality under keyboard events not the pointer device!

    This makes even more sense given the fact more and more people work on laptops these days: the pointer device on a portable computer offers less control than that of a full-hand-held pointer device.

    If you’re worried about how to communicate these keybinds to the user, just use balloons or invent a sexy looking notification/feedback system – like a translucent text overlay at the botton the screen (“ALT-F1 activates menu – show this message next time?” or similar).

    If, for whatever reason, you believe must have mouse-activated core functionality. not take the same logic you’re taking with the mimetypes-corners on the icons and activate different corners of the screen with core functionality? You place the mouse over or near the left corner and the start menu pops up along the bottom. Right: task and window list. Top right file-system browser, Top left commonly used/last-used applications. Symphony OS could be a model here perhaps.

  20. @black: you do know that you can configure all this stuff in KDE?

    @Julian: please read again: mockups! These are thoughts how something could look like. Also, Plasma is designed to make it easy to replace such things.
    And no one said that the panel is visible by default when application windows are opened.
    However, about the “mouse” part: In my experience (read: help desk for normal people) the mouse is the main interface – the keyboard is there for writing only! To me it seems that most people don’t get that you can control your computer with the keyboard alone, that is left to the geeks.
    However, as already pointed out: KDE 4, or better said: Plasma is supposed to give you the flexibility to easily create a new task bar with the functions you like. So you can easily exchange everything there as you like.

  21. \o/ Cool ! I’m just “retiring” from Win, and starting using Linux, but I’ve already decided for KDE instead of Gnome (the 2 most famous)… and with this new features, it’s really beat all the others…

    Nice Post

  22. liquidat: I think you’ll have to stress mockup even louder in the article next time to avoid these silly comments. :) It was an artists’ mockup too, so they generally make things that look pretty but aren’t incredibly useful.

    I too agree that having the taskbar and systray hidden will be a very bad thing (as windows flash on the taskbar or tray to get your attention, or change icon to indicate status), as well as the fact that the corner is the easiest place to hit. The mockup looks pretty, and some of the artwork can inspire the actual artwork later on, but I honestly doubt that the final version will have much in common with this image.

    About the plasma icons: these icons are like 3 days old, and were created as a prototype for an idea previously created in a mockup. It is not the final solution (yet) and is likely to be significantly reworked. The idea is a good idea as long as it doesn’t introduce new usability problems… imagine an icon with four corner actions – and trying to drag that icon to move it… does it still drag if you accidentally start from one of those corner actions? etc… Can you CTRL-click to select anywhere on the icon, or can it only be on the cross in the centre that isn’t part of the corner actions… These are all problems this implementation will face that have not yet been tackled. If the problems are too great, then the corner actions are likely to be reverted.

  23. Troy, yes, I should create some blinking flash thing saying (and per audio even screaming) MOCKUP, or sometimes DEVLOPMENT, depending on the background. Well, next time…

  24. I have been using my kicker from the right side of the screen rather than the bottom for years. The reason is simple – vertical space is more valuable than horizontal space for two reasons:
    1. There is more horizontal space than vertical space.
    2. Most apps that involve documents (which is a lot of them) need more vertical space that horizontal space by nature.
    This becomes even more pronounced when you add the growing popularity of wide aspect screens. Tools I think naturally belong next to your work. Like silverware when you eat. Reaching up and to the right also seems like a near instinctive move as well.

    That’s my $.02 on desktop usability. FWIW

  25. I think this is the worst video I have ever seen. Reading text from this text editor and constantly scrolling is, how should I put it, idiotic.

  26. Instead of having mini-icons pop up in the corners when an icon is selected, why not simply have the current right-click context menu simply appear.

    Advantages:
    1. More actions can be listed.
    2. Makes a bigger target to click on.
    3. The text appears next to the icons.

    That way, options in the right-click menu are visible for new users, without them needing to click tiny little mini-icons in the corners.

  27. I don’t like the little corners. They’re bad for untrained users ( “I clicked the icon, why did (Action) X happen?” ) and bad for people with visual or motor impairments. They are tiny targets close to big targets that are clicked on…easy to hit but accident, easy to miss when wanted.

    The animation system however looks fun…makes me want to write some animations :)

  28. A little suggestion. Can you make those iconlets appear with the press of, say, “Super” key (the Windows key)? To say, if I want to use iconlets, I press Super, and they appear. This may sound illogical and may appear like an usability nightmare, but the whole concept of Super-activation may be used through all KDE 4 (and marketed :P), and is a thing that I imagine to be a feature I will not be able to live without. Imagine “A desktop changing with the press of a key”, for a marketing phrase.

    Also, you will solve the biggest problem with the actual design: dragging and dropping. And if you make suboptions optional, there isn’t any problem to hide the entire icon with them. You can make, say, 4 icons, with different actions, different colors and different designs, even occluding the main icon, if you make the iconlets appear with the press of Super.

  29. Alejandro: as pointed out inn the post, I’m merely the reporter, not the developer. But Aaron appreciates all suggestions, I guess.

  30. Maybe there should be a small box explaining the word “mockup” every time, since some people obviously don’t understand it :-/
    I thought they were beautiful! (Although I agee with the person who said the logo shouldn’t be in the middle…)

  31. I think that the average user’s mode of operation is:
    “I want to do something, so I look at the monitor to see what is available”. Therefor the most important options should be visible all the time and not only when hovering over the icons.

    The logical next step would be: micro-icons when we hover over the mini-icons.

  32. More and more people have graphics tablets rather than mice. The old “edges and corners” rules for easy locations for mice just don’t apply well to most graphics tables, in fact it can be quite difficult to position exactly at the edge.

    zone-based (e.g.”shade-hover” / “flyout”) interactions, where things happen depending on you pointing or moving the pointer across regions , however, work well.

  33. what is so revolutionizing about the plasma icons ? clipping the icon to a rectangle with two separate states, one state the clip is rgba 255 255 255 255 AND the other 255 255 255 0 does the magic transition effect. any modern canvas can do this.

  34. bored: The main point are the corner icons proposed in the PDF file and implemented in the example code.
    Another very important part is that the effects can be “scaled down” meeting your needs or possibilities.

  35. I love the icons corner idea, it’s faster than right click. In the case you’ll drag and drop it’ll be the same as now (in KDE things OPEN WITH ONE CLICK, but if you don’t release it, it won’t open, that simple).

    The mockup looks beautiful. I find that menu is in a better position, the Mouse is usually around the center of the screen. What I DON’T find useful is have the taskbar and systray hide, it’s a waste of time.

    BTW: Having panels that autohide by the default it’s not useful, your taskbar should be most of the time (if not all) visible.

  36. This looks great. I was somewhat agitated by some of the comments so get ready for an overly lengthy post.

    Troy Unrau: To answer a few of your questions (from a general development standpoint, I know nothing about kde4′s implementation), knowing the difference between a click and a drag is actually quite easy, if a user is clicking on something they will almost always click and release inside the button as opposed to a drag where they may click inside the button but will start to move the mouse before they release.
    Solving the Ctrl+click problem shouldn’t be too hard either, just figure out why a user usually does this. I would imagine users only use Ctrl+click to select multiple items which would mean I just disable the corner icon actions if a user has Ctrl held down.

    bored: I don’t know if you were implying that only revolutionary things are useful but I’d bet KDE’s final goal is not to be something completely new, but something nice to look at, easy to use, easy to customize, and something with a lot of functionality.

    A word on useability: I’d bet most users are more interested in something that looks good and is easy to use over something incredibly useable; this is why many graphical applications exist in the first place. I can navigate and run apps much more productively on the command line where I can hammer out 80+ words per minute and write out just about anything’s name by typing the first three letters and then hitting tab. However it’s not important to me to save seconds here and there, if I have to aim my mouse to hit the menu button it’s not a big deal (especially since I can just go download a different toolbar).

    I think how KDE looks is just as important as useability, most programmers are more interested in useability so it will come no matter what we start out with (also KDE has a history of being completely configurable), however looks are what pull in many new users.

Comments are closed.