Today part of “what to expect in 4.10 in QML components”: Dialog. The Dialog components have been introduced in plasma since sone time, and are documented in the usual page. The components that may be used to create a dialog are:

• Dialog: unsurprising name: it creates a Plasma themed window with space for a title, a content and buttons. You have to create all of them, you’re on your own, but provides the window management and methods such as open(), close(), accepted() and rejected(). You usually don’t want to use this, unless you want some strange custom things in the titlebar area or in the buttons area.
• CommonDialog: is a Dialog, but provides a titlebar and the buttons, you want to use this in the 90% of the cases when you want to display custom content in a dialog.
• SelectionDialog: presents the user a list of items to chose from, useful to create menus when you want to modally ask “what of those items do you want?”
• QueryDialog: probably the most useful: is a simple dialog with text and two buttons. Used for things like confirmation dialogs like “are you sure you want to delete this item?”. It displays a text and two buttons, that default as “Ok” and “Cancel”, but their text is customizable.

It’s a while this API exists, but in 4.10 there was an important change in its look and feel in 4.10: Now if it’s possible the dialogs looks “inline”. It will be done on the same window as the plasmoid (i.e. on the “desktop”) and if provided with a visualParent property, it will have a comic balloon tip pointing to it. As usual, an image is worth a thousand words:

But what about if there isn’t enough space? For instance the dialog may be displayed from a Panel, where is impossible to have an inline dialog. Fear not, in this case the dialog will become a separate window, still working everywhere:

An “inline” behavior for dialogs is preferred because in this way questions are semantically and visually grouped with the object they belong to, and most important the desktop layer must not “interrupt” the user, it’s just background information.

The switch between an inline behavior and an external window is completely automatic, as usual, something that the plasmoid should never have to worry about.

Last post was about a new QML component available in Plasma workspace 4.10 with an important design pattern that comes with it: Lazy loading everywhere when possible.

Next couple of posts will be about other new and old components and the UX concept behind them.

A very important thing in Plasma is to have extremely coherent elements all across the screen, both in graphics appearance and behavior. The fact that two things together in the screen are done by two different plasmoids is something that shouldn’t really matter to the user (it’s a bit of a fail the very moment they even notice, actually). I’ll go in a future blog entry on why seamlessy melting into the environment is absolutely preferable to coming out with “clever” ideas that stick out, even if it seems counter intuitive.

Today: IconItem. From 4.10 there is a new element available in org.kde.plasma.core It’s used whenever you need to represent an icon in a plasmoid (or an active application).

This describes semantically an icon: as everything in plasma you should only describe it, and not care at all how it looks (that’s the task of the component, of the themes, of the final platform and of the global settings). Also, as common in QML, it’s just a painter, doesn’t have any event management whatsoever (so you will do it in a MouseArea for instance if needed).

To use it you just have to do:

import QtQuick 1.1
import org.kde.plasma.core 0.1 as PlasmaCore

PlamaCore.IconItem {
    width: theme.iconSizes.dialog
    height: width
    source: "go-previous"
}

And that’s it. A PlasmaCore.IconItem can load:

• It can load: freedesktop spec icon names (like “go-previous”, or konsole”). It is the preferred way
• QIcon instances (useful when the data comes from C++, such as a QStandardItemModel)
• QImage or QPixmap instances (again. useful pretty much only when the data arrives from a c++ part)

Some behavioral properties:

• If the icon name has been provided, it will try to load the “best” icon it can find: it tries first a plasma themed monochrome SVG icon from the theme. If doesn’t find it, it then falls back to the classical oxygen icons.
• For small sizes, (from 16×16 to 64×64) it renders the icon to the nearest “right” size for which there is actually a n image for it on the disk, without trying to stretch it: no more blurry-looking icons! This is also the behavior for all panel icons in 4.10, so your panel will look way sharper.
• If you set the property enabled to false it will look grayed-out with the same effect as all the disabled icons around KDE applications.
• If a mouseover highlight effect is needed, set the property active to true (also a property binding like active: mouseArea.containsMouse is fine). It will have the same highlight effect as all across KDE applications.
• State changes, like enabled/disabled or active/normal or icon changes, will have a short fade animation, that is coherent with the highlight animation of the icons in the panel, like the launcher.

So you should use it always when you have to represent a simple icon in a plasmoid. It is always preferable to the QIconItem component in org.kde.qtextracomponents (the latter should be used only when you can’t really depend from plasma).

You should not use it when your icon is actually meant to be a standalone clickable button. in this case you should either Button or ToolButton from org.kde.plasma.components. For instance, if you icon is in a delegate of a ListView and is the main “decoration” for the delegate (not a small button on a side), IconItem is the way to go, regardless if the delegate itself is clickable or not.

Internally, both Button and ToolButton of org.kde.plasma.components use IconItem to load their (optional) icon, so you are ensured a consistent look and behavior.

Let’s finish with a screenshot of an example where this new IconItem component is used: the system tray.

KDE Plasma Workspace 4.10 will have a system tray completely rewritten in QML (a lot of kudos to Dmitry for this!) and looks like this:

Don’t see any difference? yep, that’s the point 😉 It looks exactly the same without losing any feature, it just behaves better, its layout is more reliable and the code is an order of magnitude simpler.

Btw, in this post, as well the last post by Aaron, there is also a little taste of something else… different.