One plasmoid 3 platforms

Software

I already extensively talked on this blog about the new QML declarative AppletScript that will be present in the upcoming 4.6 release of the KDE Platform and how is important especially in the light of the QtComponents project.

A little new feature got in some days ago: in technical terms, is a fallback chain for Plasma::Package

Wait, a what? wtfbbq?

Let’s see what this means with this video ๐Ÿ˜‰ Here you see some further developments over the RSS reader we seen the last time, like a search as you type filter bar and a bookkeeping of read/unread feeds (done with Plasma::Storage, a projects of the last Google summer of code).

OGG version

But wait, there are 3 rss readers shown in that video!

The other two, shown as standalone windows, they have a very similar and coherent behavior compared to the one on the desktop, but they look completely different and have some important differences in their behavior.

They are a version targeted to MeeGo Handheld and MeeGo Tablet (the one with a two column layout, that is possible in a larger screen)

Those two version, use a (very early and under heavy development) version of QtComponents for MeeGo, that in turn uses the MeeGo touch framework theming system to have applications with the same look and feel of native MeeGo touch apps, but with a QML declared interface.

What is really neat is that those are not 3 plasmoids: it’s only one, in a package that weighs less than 80Kb ๐Ÿ˜‰

Also, the proper version is automatically chosen at startup by the Plasma package system (at the moment depends from an environment variable) in the code you won’t have to put explicit switches to discover what platform you’re on. You just have to provide the files for the proper platform in the proper directory, and they will be automatically chosen respecting the specified fallback chain.

Once this is in “full steam”, we will be able to have a set of plasmoids that are:

  • Traditional desktop widgets
  • more reduced widgets for the Plasma Mobile workspace
  • “Full apps” on standard MeeGo handset and tablet
  • “Full apps” on a different mobile system, for instance one completely based on Plasma Mobile.

How this can be done?

Plasmoids are distributed in packages, with a certain filesystem structure. In the javascript code you have, when asking for a certain resource, that can be an image, a javascript file, a QML file, you just ask for a particular include, you just have to ask for an “image” called “foo.svgz” for instance (plasmoid.file(“images”, “foo.svgz”) without having to worry about the actual path.

Now, (actually depending of environment variables) the actual path of the files depend from the device used, so you can decide for instance, that when you are working in a mobile environment to replace one of the package files with other one.

Files are searched from the more device specific to the more generic ones. In the example of the video there is the chain: MeeGo tablet (or handheld) -> “MeeGo generic” -> “completely generic” (where the Plasma-desktop case is treated as the most generic one right now since is the most common).

They can be qml files, images, ui files, svgs, whatever.

if the replacement is done carefully, you will be able to have even completely different user interfaces (in this example, MeeGo handheld and MeeGo tablet) but sharing the logic of the program, that can be Javascript, if the application is simple enough, or C++ modules if needed.

5 thoughts on “One plasmoid 3 platforms

  1. Ahmed

    This is great!!

    I have two questions:
    1) Given the recent advance of qml, what is the future outlook for .ui files? Will they be totally (preferably) replaced by qml in the future… or will they have separate use cases? When will someone use ui and not qml or vice versa, for example?

    2) How will qml interact with, for example, pyside bindings and other similar qt language bindings?

    Reply
  2. Marco

    I still can’t understand a thing about QML..Is it compiled like c++, or it’s interpretated like javascript?

    In the second case wouldn’t plasma show a performance slow down ?

    Reply
  3. Eduardo Fleury

    @mart
    Cool stuff ๐Ÿ˜› Let’s keep the work ๐Ÿ™‚

    @Marco (Anonimous)
    Think of QML today as a QGraphicsScene populated with items plus some Javascript gluing things together.

    The QML file itself is just a way of describing a QGraphicsScene, the items it has, plus some state machines, etc. This is parsed and interpreted upon loading, at runtime. After that, most of the logic (painting, event handling, etc) is compiled C++.

    You also have some glue in JS as I mentioned. This is interpreted but you have all the JS tricks behind the scenes ( JIT compilation for instance ).

    One thing Qt Quick falls behind standard C++ Qt coding is the fact it relies heavily on properties, strings, QMetaObject, etc. This represents an overhead in terms of string handling, table lookups, etc and memory usage since everything is QObject, you have tables, etc.

    However, one important advantage Qt Quick has over standard QGraphicsScene is the fact it raises the abstraction to a higher level. It is possible for Qt to keep the QML syntax compatibility while completely rewriting the internals and implementation, thus making it wayyy fast ๐Ÿ˜› More on that here:
    http://labs.qt.nokia.com/2010/10/08/qt-scene-graph-round-2/

    Cheers,
    Eduardo

    Reply

Comments are closed.