Tag Archives: real life

Making plasmoids QML API better

Software

For the next iteration of Plasma, we are not only revising the user experience, but also making better the developer story.

This article is pretty long (sorry no pretty pictures this time ;), and is probably easy to just TR;DL it, but it will give some important guidelines if you will ever interested to write a plasmoid for Plasma Next, such as “how the hell can I make my plasmoid have a correct size in the panel.”

First of all I’ll start with a short personal note: I just started with a new position in Blue Systems, where I’ll work towards making the next iteration of the Plasma technologies, both as a framework and as a desktop ready for prime time, aiming to give the best experience possible on the all new Qt5, Frameworks5 based Plasma Desktop by KDE.

Plasmoid and attached properties

In QML1 plasmoids, you had a global object accessible from everywhere in the plasmoids called with much imagination, “plasmoid”
This is useful to access everything that is related with the ambient it’s loaded in, the scene and the containment, so you can read things like:

  • The formfactor: are we in the desktop? panel? is it horizontal or vertical?
  • The title/icon etc:data for the plasmoid: you can set a different title, which a containment can decide to show (such as in the new system tray) or the icon, that will be used when the plasmoid is iconified in a panel
  • Configuration: the whole mechanism for handling the configuration for plasmoids is abstracted in a neat object “plasmoid.configuration” that is usable as any JavaScript Object: configuration keys are accessible as members or as keys of an associative array. It’s possible to write or read on them, and the QML property binding mechanism will work, even when the configuration is modified by somebody else (such as the desktop scripting)
  • The compact and the full representations
  • And much more

Wait, what are “The compact and the full representations”? to find out, skip to the next paragraph πŸ˜‰
In Plasma Next, besides the global plasmoid object, accessible from anywhere (any item and any qml file in the plasmoid), we have also an attached object, called “Plasmoid” (uppercase) that provides the full plasmoid api (is the same object, really) as QML attached properties of the root Item of your plasmoid, so you can have a very, very convenient way to read and write properties, and to do signal handlers.

import QtQuick 2.0
import org.kde.plasma.plasmoid 2.0 //needed to give the Plasmoid attached properties
import org.kde.plasma.core 2.0 as PlasmaCore

Item {
    id: root
    Plasmoid.title: "My custom plasmoid title"
    Plasmoid.onformFactorChanged: {
       if (plasmoid.formFactor == PlasmaCore.Types.Horizontal) {...
      // My custom JavaScript handler code to react to a formfactor change
    }
//rest of your plasmoid code
}

Compact and full representations

two important new properties of the Plasmoid object are compactRepresentation and fullRepresentation: plasmoid can collapse in an icon when they are resized to a too tiny size for their usual UI to make sense: in this case you usually get an icon that will show the full plasmoid in a popup when clicked.
The plasmoid will switch at a size that you can set with the properties

Plasmoid.switchWidth
Plasmoid.switchHeight

For those properties you should use preferably not pixels, but dpi independent measures, provided by the “Units” system, as explained here.

By default, you’ll have an icon (that’s one of the things the “icon” property of the plasmoid object is for) as the compact representation, and the whole root object is taken as the full representation.

But in some cases, an icon is not enough, you may want something more complex, like in the case of the clock.
To do that, you just have to define a cutom one.
Imagine you implemented your digital clock in a file called DigitalClock.qml:

import QtQuick 2.0
import org.kde.plasma.plasmoid 2.0
import org.kde.plasma.core 2.0 as PlasmaCore

Item {
    id: root
    Plasmoid.switchWidth: theme.mSize(theme.defaultFont).width * 10
    Plasmoid.switchHeight: theme.mSize(theme.defaultFont).height * 15
    Plasmoid.compactRepresentation: DigitalClock {}
//rest of your plasmoid code
}

One thing that is neat, being compactRepresentation a Component, it doesn’t actually get instantiated until you actually need it.. why wasting memory on the graphical representation of the icon if it will never be iconified for its whole lifetime?

at the same time, it’s realistic that a plasmoid can sit in your panel (or , in Plasma Next is also possible to collapse them when in the desktop) for hours before you have to open it, if at all: why it should take startup time to instantiate its contents? (and why they should always take memory if they are not used?)

In Plasma Next, you can assign the full representation too, so to redo the previous example, if you want to show a calendar when you click on the clock:

import QtQuick 2.0
import org.kde.plasma.plasmoid 2.0
import org.kde.plasma.core 2.0 as PlasmaCore

Item {
    id: root
    Plasmoid.switchWidth: theme.mSize(theme.defaultFont).width * 10
    Plasmoid.switchHeight: theme.mSize(theme.defaultFont).height * 15
    Plasmoid.compactRepresentation: DigitalClock {}
    Plasmoid.fullRepresentation: Calendar {}

//rest of your plasmoid code, only data model related items, there won't be any graphics object here anymore
}

Plasmoid.fullRepresentation will probably usually contain the most complicated code since it may be abig and complex UI, but when it’s in the panel it won’t get created until the user opens it, so it won’t cut on precious startup time.

Therefore, in Plasma Next, the recomended way to write a QML plasmoid is:

  • Write a root Item as simple and lightweight as possible
  • Use the default icon as compact representation when possible (to have that just don’t define any compactRepresentation, it will take the default)
  • Put all of the UI under Plasmoid.fullRepresentation
  • Under the root object, put all the dataengines and the models that you need to access from both representation, but only and always non graphical pure data model stuff.

Making your plasmoid to behave well in a layout

Since Qt 5.1, QML2 has a new set of components: the Layouts.
Those are similar to the good ol’QWidget layouts, we have linear (row and column) and grid layouts. This makes construction of plasmoids and containments way easier.
What i want to talk about here, is the size hints that those layout provide.
As the Plasmoid object that I wrote about before, is now available another attached object called Layout, and is documented here.
You can define one inside of any Item, and when/if that item will find itself in for instance a RowLayout, the layout will respect the size hints defined as attached properties (minimumWidth, maximumWidth, fillHeight etc).

We are using the same attached properties for the plasmoids themselves.
If toy define the Layout sizehints properties inside either the compactRepresentation of the fullRepresentation of the plasmoid, they will be used for several things:

  • when the fullRepresentation is in a popup, the popup will never be smaller than the Layout.minimumWidth/Layout.minimumHeight of the fullRepresentation
  • If the plasmoid is collapsed in the panel, all hints of the compactRepresentation will be respected by the panel layout
  • Same thing for the fullRepresentation: for instance the taskbar is a plasmoid that always stays in fullRepresentation, which has the Layout.fillWidth property set to true: this way the taskbar will always take all the available space there is left in the panel.

Let’s add this to the usual clock example:

import QtQuick 2.0
import org.kde.plasma.plasmoid 2.0
import org.kde.plasma.core 2.0 as PlasmaCore

Item {
    id: root
    Plasmoid.switchWidth: theme.mSize(theme.defaultFont).width * 10
    Plasmoid.switchHeight: theme.mSize(theme.defaultFont).height * 15
    Plasmoid.compactRepresentation: DigitalClock {
        //make sure the collapsed clock is at least 5 "M" wide in panels
        Layout.minimumWidth: theme.mSize(theme.defaultFont).width * 5
    }
    Plasmoid.fullRepresentation: Calendar {
        //make sure the popup is at least 10x10 "M"
        Layout.minimumWidth: theme.mSize(theme.defaultFont).width * 10
        Layout.minimumHeight: theme.mSize(theme.defaultFont).height * 15
    }

//rest of your plasmoid code, only data model related items, there won't be any graphics object here anymore
}

KDE, what next?

BlaBla

Let me tell you a little story, a story about our vision since a while, a story about what happened the last week, a story about what will happen now and why it will matter for you.

Let’s start with a digression. I started to write this entry several days ago on the bus, from the Milan airport to Turin, after some days in Germany (more on that below) the return in Italy was so typical and so contrasting with the German aim for precision. The highway was closed in three different points, the bus had to take diversions that made the journey some hours longer. Max respect to the driver btw, he managed so well things that were going wrong in an epic way.

But in the end we arrived where we wanted, I decided to not get angry but take the occasion to think and write this lengthy blog entry…

This remembers to me some other story, that wasn’t always easy as well…

Uh, has it something to do with KDE?

14 years ago, the KDE community was born with a very bold vision: give to everybody a cool, attractive, easy to use desktop environment, now we are a worldwide community with hundreds of members, we provide a very strong foundation with the kdelibs framework, many apps, the Plasma Desktop workspace and the Plasma Netbook workspace.

In the end, why we work on the KDE software? Probably everybody has a different answer, in my case i can say, free software, done on top of what i think is the best technology available today is giving to people something that can make their lives slightly better, so the world slightly better as well.

But this to be true it must reach as many people as possible and be really useful on their today’s needs, otherwise it remains just a nice coding exercise.

Every now and then some group feels that a new kind of jump is needed.

  • How many expectations we did deliver?
  • Do we need something more to be able to be where we want?
  • How much the world is changing?

Sometimes in the arc of just one or two years, things are changed so much that you have to question your answers (pun intended?): are the questions still the same?

Many things happened in the last few years since the adventure of the 4th iteration of our platform started (that’s roughly when I joined this strange family: in retrospective I think one of the reasons was that it was one of those “dare to dream” moments).

Some of the things that happened have influenced the future of computing in general (the mobile shift that happening in recent years is only one of them), some others more near to KDE, some things happened were not so good, some were very good.

On the mobile

Not a lemonWhat didn’t change is my (ours) certainty on the goodness of the KDE platform, even when seemed a weight for some, it’s an amazing toolbox that I know it will be there in the whole device spectrum, giving not only a consistency in look and feel and behavior for the user, but also for the developer.

Some says that the desktop days are over, some says that the desktop world won’t change that much. There is truth in both. desktop is here to stay, there are so much tasks that simply can be done just there (this is confirmed as well by desktop sales going significantly up last year)

But there is as well another truth. often, and for more and more tasks, a more “human”, portable and ergonomic device is way more appealing, smartphones and tablets are an example, and that’s why all our efforts in this direction started.

We have several projects already in the mobile space, like the Plasma mobile workspace, Kontact touch, Marble, Calligra.

Can we do better? Can we have more mobile applications? But most important, can we provide a direction, an unified vision that would make KDE lead and be innovative in the mobile space?

In the end, have an unified, compelling story that would be interesting enough to make KDE the natural choice in the mobile world to both users, and who actually wants to sell a device and has to choose between the various platforms he can ship (and how much freedom he will have when he wants to build a customized, fine tuned experience)

I know what you did last week

Last week some KDE people did met up and started to discuss a bit about those very issues, challenging ourselves and taking a step back to see what we could do to improve our outreach

What we realized is that what is missing is for sure a lot, but on the other hand, we are so near as well.

So expect new entries about it in the near future, we are thinking on it πŸ™‚

A mobile Tokamak

Software

Suse officesSo another Tokamak went by, it is always sad to leave from this amazing group of people, but there are also two good things on that: 1) you know you will see them soon. 2) you know a really impressing amount of work has been done.

One of the big focus points of this meeting was how we tackle the new mobile devices, from a Plasma and more general KDE perspective.

It was a bit strange for me, because it didn’t involve as much coding as usual, but a lot of work on getting the KDE build working well on a particular mobile device.

We had three Compal JAX10 devices loaned from Intel with installed an image of the Moblin environment, version 2.1. While both software and hardware wise they are still a bit far from a “commercial” release, but that’s exactly what makes them interesting.

Everybody hackingThis is a device with capabilities pretty near to a netbook, however it has a totally different set of limitations and requirements.

Here we don’t have a normal keyboard, but just a little slideout one, and we have to remember that some of the devices of this class won’t have a keyboard at all. Of course there is no mouse/touchpad as well, this means all cursor input is done via touch screen.

With a touch screen some interesting things happen: precision becomes really poor, so we need bigger targets. Moving the cursor and pressing the “mouse button” happens at the same time, so you can just click: anything that relies on mouse hover becomes immediately useless. Screen edges, the most reachable area with a mouse, becomes the less convenient one to use

Anyways, it was an interesting experiment: how far we can get, in a single week, starting from the bare libplasma to do an user interface for a device like that?

In the end we ended up not with one interface but with two: I adapted the Plasma Netbook interface to some of the quirks typical of a touch screen (a lot work still has to be done) and I obtained something that works quite well as a general launcher for touchscreen based tablets, that still can use an (adapted of course) version of desktop applications mixed with the “newspaper” concept (where “turning pages” will become a really natural concept) and Plasma Widgets that will run as a full screen application.

Here is a short video of the Search and Launch usage (a rough prototype had already been shown some days before Tokamak, now it’s starting to work really well): it shows the horizontal scrolling of the results when the little touchscreen is landscape and the drag and drop of items around: really important there since the little actions on mouse over don’t work there: also for deleting them a particular drop target with a little trashcan appears. Another important point is that now on a touchscreen a drag (being of the results view, of an icon around) begins with an enormous treshold compared to a desktop/netbook: in this way it adapts to the really low precision that a finger has on a touchscreen.

OGG version

And the last concept brings us to the design of the other user interface: on a really small mobile device, such a phone, it will become simply impossible to use the regular full applications (logic and ui will have to be decoupled). Many Plasma widgets have a quite small UI, so as far as real screen estate is concerned they can work suprisingly well on small screens, they also make extensive use of touchscreen friendly concepts, like flickable scrolling views and drag and drop (even some basic multitouch support, like pinch zooming, if ony X could :p)

Some widgets, like the Opendesktop plasmoid work really well already, with just some fixes to be done here and there.

Another advantage using the Plasma widget library is that being based on QGraphicsview, they are on top the same framework of Maemo 5 and Maemo 6 ui, allowing coherence and interoperability.

On devices like a phone, we will probably also need a different primary user interface, since the size will be even smaller, not only in terms of resolution but most important, in terms of real size (the JAX10 and the N900 are both 800×480, but the N900 has more dpi, so a smaller screen)

Another reason we can want a different ui for a real phone are the main use cases, for instance here i want to be able to reach the actual phone dialer with as less gestures as possible, and the target use case is even more “casual” for function that are not related to telephony itself.

We had some design sessions about the use cases, interaction paradigm and code design of it, then Nuno produced some really beautiful graphics and mockups. Artur and Alexis sat down and implemented a proper full featured plasma shell over that mockup and got it working in an impressive short amount of time. As I said, I couldn’t code much on that (but I plan to fix it in the next days;) because my job was mostly getting everything working on the JAX devices, so long sessions of building, patching, rebuilding testing, fixing and rebuilding again. Artur has a really interesting post on it too, as well as Alexis.

At the end of the week we produced a video that once released (will take some time to edit) will explain what we did and our plans in detail.

As a preview, here are two short videos that show what we got at the moment.

OGG version

OGG version

Tokamak, days 3, 4 and 5

BlaBla

Cashews!
Days at Tokamak are running out very quickly: last days we had a very frenetic activity: for me it was spent mostly around adapting aspects of the Netbook Search and Launch interface for touchscreens. It’s impressive how good it looks already with so little changes of code

.

Alongside of that, we are designing a different interface for another different kind of devices: smaller mobile devices, as small as smartphones (hello n900 πŸ™‚ or various ways on internet tables.

We have here some N900 and 3 little tablet devices lended by Intel (Compal Jax10 with a Moblin image installed on it actually). I must say the Moblin SDK is quite easy to use, I’m pretty happy with it.

It’s really important for us to actually get going on mobile devices, because with our platform as insanely flexible as it is, we can deliver a really coherent user experience across the board, starting from the desktop, going down to the netbook, to little tablets and cellphones.

Almost entirely different UI, but with an impressive amount of code shared between totally different form factors. That’s the beauty of having a clear separation between the logic and the ui, having a rich framework that helps to keep the ui layer as thin as possible.

We’ll also going to expand theming capabilities by offering the possibility for Plasma themes to offer custom animations…

What does it mean? It will be able to customize the user experience a lot, not only with different desktop themes, but also across different devices, where the interaction patterns and different resource constraints.

It will use of course Javascript, for usual requirements of multiplatform deployment without rebuild and more robustness/security/ease of writing.

In the short term what it means? Expect tasty screencasts in the next few days and new cool shiny toys to play and develop with in the next KDE SC releases.

Tokamak 4, day one

BlaBla

Arrived yesterday in Nuremberg with the rest of the italian Plasma gang (we wandered half an hour in the -wrong- building in searcch for the hotel reception, quite a surreal experience :p)

Today is the first “real” day, there were a lot of great talks, all of them revolving around our future direction, what’s coming for 4.5 and what’s coming beyond, so expect quite a bit of blog posts about that in those days πŸ˜€

I’ve talked abount, surprise surprise, the the Netbook shell πŸ™‚

I’ve talked about some technical details about the various components: what is the different between the Netbook and desktop shells themselved (just the tiny binary), how the search and menu of the Search and Launch interface are done, how is done the new shiny drag and drop, and everything about the newspaper

In brief, for the future, expect a big effort about polishing and bugfixing, to get an experience as smooth as possible (like a cache for the newspaper widgets when the device is offline) and expect some new features, like maybe free resizing of widgets in the newspaper.

CampKDE, return

BlaBla

I’m writing the first part of the first entry in Newark airport waiting for the connection (bloody networkmanager, why don’t you want to connect to the free access point?). This night didn’t went to sleep at all, some of us kept watching silly movies until 3am (then farewells and seeya next time, with the usual sweet/bitter taste), when I left for the airport.

First flight pretty tiring and the second one even more massive (long flights and carbon footprint ftw!)

Now that i get home there will still be a list of work that i really hope i will be able to do in time, some last minute refinements and bugfixes of the last minute before the 4.4 release, both in code and assuring all the artwork in plasma is up to the job, so hectic days ahead, yay!

CampKDE, day last

BlaBla

CampKDE is coming to an end, I’m writing this during the last tutorial session, Qt embedded is a quite different beast compared to what we’re used to, but cool stuff indeed

Those days have been pretty intense, many talks and tutorials, too much rain, too much beer, lots of “healthy” american food… so in the end, all good stuff, (except of course for the rain, since i was expecting the sunny California a little bit more well… sunny :p)

Seen several old friends, met some new dudes, too bad i’m about to leave (a plane in the eeearly morning is so much fun :p)

I never really manage to do much hacking on those meetings (much more code done in sprints) but many neat ideas come up for the future, by talking with great skilled people and some whiteboard sessions πŸ˜€

Anyways I managed to hack something, a new little block in the Plasma animation framework, (a class to do smooth pixmap based transitions) that will hopefully let us get totally rid of the old animator code and complete the migration by KDE 4.5