Reconstructing Plasma

Desktop Workspace with Widgets Explorer
Desktop Workspace with Widgets Explorer
We are currently in the process of porting bits and pieces that make up Plasma Desktop to QtQuick2, KDE Frameworks 5 and Plasma 2. In this endeavour, we are going over all the basic components, such as Kickoff, the task manager, the pager, the system tray, battery and network management widgets, and of course the clock. We are also porting other workspace components such as the powermanagement policy daemon (powerdevil), the KDE Daemon (kded) and the splash screen.

For Plasma components, this work involves first porting C++ portions of the code to Qt5 and adjusting the build-system to build this code against Qt5 and Frameworks 5 libraries, which have been split up. C++ code has to be moved into imports, which can then be used from QML code.
Configuration dialogs in Plasma 2 are something, we have redesigned. As all other UI code, the configuration dialogs seen in Plasma are also moving to QML. In Plasma 1, the configuration is done using traditional widgets. This made it hard for developers to provide complex configuration user interfaces without having to write these portions in C++. In Qt 5.1, QtQuick Controls have arrived, and are further polished in Qt 5.2. QtQuick controls are traditional widgets, done in QML instead of hand-written C++ layouts or Qt Designer .ui files. They reuse the widget styling engine (the Oxygen style, for example), but you can write these in QML. This allows us to keep the user experience. Plasmoids in Plasma 2 now use QtQuick, and get the full possibilities along with that.

Desktop settings and Toolbox
Desktop settings and Toolbox

Over the past years, we have already moved most of the standard elements of a Plasma workspace to QML, which greatly simplifies porting. To the user, this will not feel like a rewrite, but like an update of the user experience.
In many ways, Plasma 2 will be very similar to what is known today, and that’s a good thing. Familiar interfaces that have been developed and polished over the years provide great value, we definitely want to keep the work that has gone into that, but we also want to elevate its possibilities going forward to a new level. While going over the code, we often improve things here and there, so it’s not just a “stupid port” but provides actual value to the user. From a UI point of view, we expect Plasma 2 to be an evolutionary release, which, while keeping existing workflows intact gives us greater flexibility in how the system is set up, and used. The move to Plasma 2 means that we can improve on things that have been nagging us architecturally, so we can get rid of some accumulated baggage. Then, there is of course Wayland, which we aim at fully supporting in Plasma 2.

In the screenshots, you can see a few of our widgets that make up the desktop, just to give you an idea of what is there right now. Some elements have just seen straight ports (the network management and battery widgets, for example), others are in the process of being reimplemented. One of the things that we will likely improve it the layout of the widgets explorer, which you can see in the first screenshot. The horizontal list does not work very well in practice (in theory it really does! ;-)), as it is harder for a human brain to scan a horizontal list, compared to a vertical one.

When looking at the screenshots, keep in mind that this is all very much work in progress, and that almost all the work has been done on the underlying architecture (KDE Frameworks 4 and the Plasma Framework), and that we are only now starting to shift towards more UI-oriented work. For that purpose, we will have a meeting on IRC later this week to hash out further strategies and take the pieces we have now to make it One. More on that, however, later.

As an exercise to the reader, what improvements and bugs and missing things can you notice? :)

Kickoff Launcher
Kickoff Launcher
Network Mangement
Network Mangement
Battery Monitor
Battery Monitor
Notification Area a.k.a System Tray
Notification Area a.k.a System Tray

51 thoughts on “Reconstructing Plasma

  1. Beautiful!

    Can I haz plasma style scrollbars too instead of the not-so-beautiful one on Desktop settings screenshot? I guess notmart was also looking into it earlier in a G+ post…

    1. The desktop settings dialog’s scrollbar is Oxygen, the widget style for ‘traditional’ QWidget-based scrollbars, this would require a change in Oxygen. In these configuration dialogs we can actually mix-and-match, but I’m not sure that’s a good idea for consistency.

  2. Hey look at that. A vertical add widgets bar. Great progress, and I like the flatter look, but the icons now look slightly outdated in this combo. Are there plans for a clean up there?

      1. Nope, and certainly not me for this particular job. Was just some impression I had when looking at the screenshots.

        Eventhough the chances are small that I’ll meet this person to polish the icons, I’ll keep my eyes open :)

  3. Can we rename that “KDE Desktop” stuff to something like “Desktop by KDE” (or a little more sexy would be good). Just to support that the name of the Desktop isnt KDE anymore. the same for the “k-menu”s.. they should be “plasma menu” or just the real name.

    a good marketing way would be to talk do the distributors like suse/kubuntu/arch/magaya and everyone else. to get in this distributions as “KDE Kubuntu”, “KDE Suse”, “KDE Magaya” (in a sexier way of course). That would give the user a better feeling that the KDE are the people behind the software, not the software itself.

    and the last point is PLEASE unify svg objects in plasma styles. not name in this one “base-” in the next one “normal-“. Not on this file the hover is over the normal and in the next one the hover is below. not a extra button elemen in logout dialog, because there are buttons already in /widget and PLEASE (REALLY) make it possible to set for everything ain plasma an different icon theme as for the rest of the system.

    for example nor i want to change the icons for the weather widget because they are almost not visible in the widget ans my desktop background. Bug i cant do, because they are the same as in the rest of the system, wich is crap because i dont want to change my icon theme, just the icons for that widget.

    Another one is that because there is no diffrent, in all qml apps, the icons for amarok/ktorrent and so on are the same as the svg tray icons from the default plasma theme. so please … make it inpossible tho use the same icons everywher.

  4. How about something like Android 4.x does for widgets? I can think of a window or even a full screen application which is perhaps grouped in categories (like the notification sliders for example or checkboxes) and already provides previews of what the widgets actually look like and when you drag them the windows fades away and you can place the widget on the desktop. I would find that far more practical in contrast to the cumbersome scrolling list we currently have will have with any list be it vertically or horizontally since you have many similiar widgets and descriptions which are really confusing.
    With that approach you could even introduce a checkbox for “show me only the official ones which come with kde itself” or “show me the user installed ones” and so on.

    1. We try to avoid modal dialog in general, and more so in Plasma 2. They bring a whole slew of visibility problems and are quite distracting. Also, using a full screen interface isn’t necessary for desktops, and it makes drag and drop of widgets from the explorer onto wallpaper or panel unnecessarily hard. In the tablet UI we do use a modal / fullscreen-ish dialog, by the way. In general, instead of trying to unify user interfaces across devices, we swap out components on different levels in order to adapt the user interfaces to the devices they’re used on. Specification, instead of dumbing down onto the lowest common denominator.

    1. Martin is currently working on accelerators. I can’t really answer that. Also, the session setup is not complete, the screenshots you see are running a “bastard session” of KDE4 and KF5 services.

      1. On Wayland we will be able to support it. On x11 I think it’s better to keep it as it is.

    2. Given that there’s already a hack on to do exactly this, I don’t see why not. It just waits for the *release* of the meta key, without any other key having been pressed to launch the menu without compromising shortcuts using meta.

      Time to bring meta for the menu into mainline imo.

      1. I too would like to see the feature included :) You can at least workaround by installing ksuperkey for now.

  5. One long standing issue with plasma widgets that I have is that there is no standard for whether widgets staying open if they lose focus. The calendar widget stays open until you close it, while most widgets do not, while still others provide a toggle. It would be great if a standard was set for all widgets to follow (hopefully it would be that widgets close when losing focus) and if necessary a setting could be added to change the behavior.

    1. The calendar is the only widget that stays open when it loses focus. This is done for one reason that does not apply to any other Plasmoid that we know of: A primary usecase for the calendar is to act as a small reference window that one uses directly in conjunction with other applications. If it goes away when it loses focus, one can’t peak into it while filling out a form, for example. I agree that it’s slightly inconsistent, but if the calendar zip away too easily, it’s pretty annoying. In principle, popups from the panel go away when they lose focus. (Doesn’t work in Plasma 2 yet, of course. ;))

      1. Could a toggle be added to the calendar widget to not have it stay open? A final bug that always annoys me is when the tooltips that appear when hovering over widgets in the add widget dialog stay open if you hover over them. It’s completely inconsistent with the other tooltips in KDE and tooltips in general. Other than that, I think it looks great.

        1. How about adding a close button? Many become frustrated since there’s no visual clue for how to dismiss the widget.

      2. I use the dictionary, calculator and unit converter plasmoids also in conjunction with other applications, and I would like to be able to see the result of the word lookup or the calculation while continuing my work. So I would like to have the option (I don’t think it would be pleasant if the popup of the dictionary and calculator would always remain open) to let the popup stay open when losing focus.

        1. These usecases are actually served very well by KRunner, the mini-commandline. I use it all the time, try it. :)

  6. If you ask for bugs… ;)

    I hate it how buttons in configuration dialogs (e.g. very second image in post) are melted into background of window. Although it is visually appealing, it is usability disaster that break rule that was around since forever – elements that user can interact with MUST be clearly distinguishable.

    On related note, why are there “Edit connection” and wrench icon on network plasmoid? If they are used to perform different actions, it is not clear enough.

    1. The button background you note is indeed a bug, that’s one of the things that don’t work yet when we’re using the Oxygen style from QML. For that, we use QtQuickControls, which aren’t really mature yet. Maybe that’s something that we can fix in the style, though.

      I don’t really know the answer to your other question, I do know that our usability guys are looking after it, which has resulted in really good progress in usability the past months.

  7. Bugs I noticed:
    KDE branding extends a couple of pixels too high
    Session bar leaves no padding on the sides
    Box around the main kickoff sections at the bottom needs left padding and doesn’t extend down over the selected item

    Network Manager:
    Rounded corners on the bottom panel, despite it going all the way to the screen edge.
    No padding up to p above the system tray icons

    Desktop snapshot:
    Cashew and i circle overlap

  8. What about more complex configuration dialogs (that require custom widgets, probably still impossible to recreate using QML controls even from Qt 5.2)?
    Developers will need to create custom QML elements or need to call external applications to do more complex stuff?
    Or there will be no place for such complex stuff at all?

    1. In most cases, it’s quite easy to do complex widgets in QML. I personally find it much easier and pleasant to do than using QWidgets. We do have some catch-up to do, as not everything is working well enough hand complete yet, one of the things we’re thoroughly missing are FormLayouts for example. I’m sure it won’t take too long until QtQuickControls has caught up though. The developer experience is just so much nicer, it’s worth it.

      1. I just hope that this and other issues will be resolved properly before it will be too late (before APIs will be frozen). ;-)

        It would be nice to get at least one developer preview far before release intended for end users, so third party developers could check out APIs before they will be frozen, give some feedback etc.
        Not everybody has time to follow mailing lists, compile everything each week after browsing through git logs to find where to look for API changes etc. ;-)

        1. We’re trying to get a developer preview kind of release out in December. It still will be very rough, but showing what we’re doing.

          The vast majority of the APIs is not new, by the way. It’s the tried and proven stuff we’ve been improving on for many years, we have just cleaned out dependencies and the build system, so they’re easier to deploy and more useful in a wider variety of use cases.

          1. Sure, but not all of that was perfect in 4.x. ;-)
            Like workflow when using weather data engine directly, panels API, or that global shortcut thing for all applets…
            Also it will be completely different experience for those who used only C++ APIs for QGV based applets. ;-)

            It’s nice that there is going to be such a preview and I hope that it won’t be mistaken as a beta release by end users.

  9. Vertical Widget bar is really a nice improvement. Can it show additional info like ratings, etc on hover?
    Desktop settings, instead of clicking Apply, can it be done on selection or double-click?
    Any plans to port some of the good features of Lancelot into Kick-off menu?

    1. Expanding the widget vertically, before resorting to adding a scroll-bar, would be useful.

      1. The sizing is at this point hardcoded (one of the many bugs we have), it will need going over another time and fix that, then your issue should be addressed as well. The widget explorer has tooltips (in principle, another construction site).

        As to Lancelot, I don’t know about Ivan’s plans regarding that. Let’s just say that nobody is married to Kickoff, really, so maybe we’ll even see a replacement… :)

  10. An afterthought –
    I am not sure if you have seen this – – Cinnamon DE has an integrated website for applets, desklets, themes. It still lacks and lags behind KDE in terms of variety of widgets (Eg: Comic strip viewer, yawp, bumblebee indicator, etc) but making slow progress.

    I feel really needs some love. The repository that hosts widgets needs a modern UI. I am not sure whether bodega is the candidate for it.

    BTW, i love both KDE and Cinnamon. Kde for the power it gives, Cinnamon for its simplicity.

    1. We are currently discussing how we can use Bodega to Plasma’s benefit. It should not come as a surprise that Bodega matches our requirements very well, but we’ve not hashed out all the details yet. Stay tuned…

  11. Nice to see the progress but I’d also like to get rid of some visual annoyances that I already see for a long time:

    The buttons like the “Get new widgets” in the Vertical Widget bar or the “Wallpaper plugin in the second screenshot are too thin. I often notice different sizes of buttons which makes the whole appeal just UGLY! I hope I’m not the only one noticing this :-)

    1. I think there are a lot of alignment and sizing issues. I hope we’ll find the time to go over this whole topic and fix the living crap out of out layouts so this part of the user experience becomes a lot better.

      As always: Patches are welcome (really easy to do in QML, even). Not everyone notices this class of problems, so it needs trained eyes.

  12. Please improve notifications. It’s the one thing that put’s me off KDE 4. They are way to complex, and far from intuitive.

  13. In the Desktop Settings will the ‘alternative’ options for the wallpapers still be available or are they hidden under the dropdown menu? I mean things like setting a gradient as wallpaper or a slide show of pictures in a given folder? I really like the latter option personally.

    1. Wallpapers are done in QML, so there’s really no limit to what you can do. We won’t provide every single feature in Plasma2 from day one, so you pet peeve might be among it, or not, but the whole system allows for much easier creation of wallpapers and effects than anything else I’ve seen. Maybe get your hands dirty and start hacking a cool wallpaper? :)

  14. It looks very nice, but have you tried a grid view for the widget explorer ?

    I find today the widget explorer very unintuitive. When I add a widget, I would rather use all the screen to show more options, have the categories on the left and a space at the bottom to show more information on what is the purpose of the widget, maybe a link to a video.

  15. There are many ideas on KDE forum brainstorm and on KDE bugs wishlist and real bugs with important problems. Why not addressing them first and introduce something users really want instead of reinventing basics all over again. How many times you use widget explorer? While setting up your system and a view times more until next release, install and next setup or you stay with the same settings. Not that important for me at all.

    1. We need to have this architectural update in order to be able to fix bugs. Moving away from QGraphicsView will kill whole classes of rendering and layout problems, for example. It makes it easier to maintain and develop forward as well. I don’t expect everyone to understand this, but before trying to tell us what your priorities should be, this is important to keep in mind.

      Then, if you read this thread, to some users, the work on the widgets explorer is important, maybe not to you, but are you running around the Internet telling everybody who does something that is not that important for you to do something else?

      Maybe instead of telling those who do already work on Plasma what to do, tell people who are *not* working on it to help? :)

  16. Hi,

    First of all great work!

    I have one question: Why in the world do widgets like the “Tool Box” use normal icons and not ones defined by the theme?
    If you are using the default oxygen icons, everything is okay, as they are colorful and not monochrome, but if you use Icons like KFaenza you will get problems if you use a dark background.
    Is that likely to be changed in the future, so that plasma themes also include icons for that stuff (So dark themes would use white icons and vice versa)?
    As already pointed out earlier, those colorful buttons are not the best looking ones and don’t look very futuristic.
    And it would also make sense in terms of consistency, as for example since 4.11 the Grid effect uses theme defined buttons for adding and removing workspaces instead of the normal icon theme buttons.
    Is that a known issue? Should I open a bug report?

    Thank you very much!

  17. Another bug I’ve noticed is that panels that are set to auto fide are sometimes covered by panels set to always show, the same thing happens with panels that go bellow. I like to have some things on my panel hidden until I mouse over them and this is the easiest way to do it, but they get stuck behind other panels.

    1. Is that a bug in Plasma2? In general, this class of bugs often vanishes like ice in the sunshine just by moving to QtQuick2.

      1. It’s a bug I’m experiencing currently on 4.11. Glad to here that these kind of small things are getting addressed.

  18. Oh no, I liked the way the widget explorer was.

    And – Start Menu without search box? I’d leave KDE if that ever happened :D.

    1. “Start Menu without search box”

      I’m sure users will always have a choice what start menu to use.
      For example I’m using Lancelot (which has a search bar).

  19. You guys really need to hire some artists… I think GNOME 3 has better visual design and feel, specially in their webpage, every new version is published with a lot of visual elements and that’s good marketing.

    Maybe Nuno can help? actually there are a lot of DeviantArt artists (for example) that would love to participate on ellaborating new designs and stuff for KDE (at least I am pretty sure that someone would like to do that).

  20. The default font in KDE is beyond ugly. It is absolutely horrendous. Will we ever see KDE with beautiful default fonts?

    1. KDE’s default font is set by the distro (it’s a system-wide font). I agree on the account that most distros’ default fonts are not looking very good.

      By the way, you cannot judge this from the screenshot, as we have not integrated the settings for this kind of thing yet. What you see is much more a technological preview (look, we can get a complex UI up and running on top of these libs), rather than anything that resembles the final state.

Comments are closed.