This does not seem like much, but, trust me, it is.

The KActivitiesStats library now supports mixing contacts (documents, etc.) that are linked to the current activity (aka favourites, or pinning), with the recently or frequently contacted ones.

This will be quite usable in other places as well - think of application launchers and such.

It was quite a big patch.

As previously mentioned, I’ve been working on a YAML-based replacement for QML that would allow using JavaScript alternatives in QtQuick applications.

But, it is not only about a different syntax. It also allowed me to make some improvements to make the life easier.

Less typing

One of the things that I find tedious in QML is the verbosity of some parts like the anchoring system. For example, when you want to anchor everything to the parent, it is trivial (anchors.fill: parent), but when you want to anchor all but one side, you need to write quite a bit more:

left:  parent.left
top:   parent.top
right: parent.right

PUCK will allow you to shorten definitions like these:

PUCK                            |  QML
width,height: Settings.screen_  |  width:  Settings.screenWidth
                                |  height: Settings.screenHeight

And even:

PUCK               |  QML
^bottom: parent._  |  left:  parent.left
                   |  top:   parent.top
                   |  right: parent.right

Alternative id definition

Another thing I tried to improve is the id specification of QML items. In QML, you would do something like this:

Rectangle {
    id: root

    // :::
}

The id looks like an ordinary attribute, but it is not. It must be unique, you can not override it, etc. I think it should be more prominent.

In PUCK, the id definition is moved to the same place where you specify the type You can use the 'as' syntax like in the import statements, or, if you prefer trailing types, you can just write the id and the type after it.

Rectangle as root:
    // :::

root Rectangle:
    // :::

If you don’t like this, and prefer defining the id inside the object like in QML, nothing will stop you - PUCK supports that as well. It will just show a warning to suggest changing your style.

Some experiments

I’ve also experimented with wide arrows, but I’ll probably remove this option in the future.

root <= Rectangle:
    // :::

Rectangle => root:
    // :::

And also for imports:

imports:
  - QtQuick 2.2 as Qt
  - Particles <= QtQuick.Particles 2.0
  - org.kde.plasma => Plasma

Just imagine there is a system in Plasma that tracks which contacts you chat with often. Just imagine that also happens to people you often send e-mails to.

Now, imagine there is a system that connects the people from your addressbook, with the people from your IM application.

Lastly, imagine an applet that connects all these by showing the people you write to most often.

A long time ago, I joked about Raptor mode for Lancelot. The idea was plausable thanks to a tool I started developing to make the Lancelot development easier. It was PUCK - the Plasma UI Compiler (as named by Danny Allen). It generated C++ code from the XML-based UI definition.

After a while, I stopped working on PUCK since Lancelot’s UI stopped changing that much. I even removed it from the build system.

Now with QML, the need for a tool like that disappeared.

One thing that I do not like when QML is concerned is its use of JavaScript.

An alternative

An idea I got some time ago is to create a simple format that compiles to QML, that would allow the user to write code in any language that is compilable to JavaScript. I decided to base the format on YAML (since every language I know of has a parser for it, and it is not XML :) ).

YAML has its limitations, and some of them are making it a bit problematic for this use-case, but all in all I think this can work.

PUCK - the new one

Since the old PUCK haven’t been used for a long time, and the new project is kinda related, I decided to reuse the old name.

To cut a long story short, I’ll just post an example of what the current syntax looks like. I’ll write more details later (along with a small manual), when the syntax becomes stable enough. I’m still planning to make a few small changes that will make PUCK a desirable alternative to QML not only for the ability to replace JavaScript.

This is an example reimplementing the first part of samegame.qml from the Qt5 demos (I’m overly lazy to actually reimplement the whole example).

imports:
  - QtQuick 2.0
  - QtQuick.Particles 2.0
  - ^content/samegame.js as Logic
  - ^content

Rectangle:
    id: root

    width: Settings.screenWidth
    height: Settings.screenHeight

    properties:
      - int acc: 0

    functions:
        loadPuzzle: |
            @coffee
            Logic.cleanUp() if game.mode != ""

            Logic.startNewGame(gameCanvas, "puzzle",
                               "levels/level" + acc + ".qml")

        nextPuzzle: |
            @lang=livescript;global=acc
            acc = (acc + 1) % 10
            loadPuzzle()

    children:
      - Timer:
            id: gameOverTimer

            interval: 1500
            running : gameCanvas.gameOver && gameCanvas.mode == "puzzle"
            repeat  : false

            onTriggered: |
                @coffee
                Logic.cleanUp()
                nextPuzzle()

      - Image:
            source: ^content/gfx/background.png
            anchors.fill: parent

Error reporting

One of the great things about the compilation to QML is that you’ll get script errors during the build of your project and not at the runtime.

The compilation errors get reported to the console output along with the code that failed, but also inside the resulting QML as well.

Console output of a failed CoffeeScript function:

Error: Compilation failed
Source:
   1 function === without arguments
   2
Error message:
 [stdin]:1:1: error: reserved word 'function'
function === without arguments
^^^^^^^^

Insides of the QML file:

function error_coffee_function() /*
[stdin]:1:1: error: reserved word 'function'
function === without arguments
^^^^^^^^
*/

Supported languages

Currently, CoffeeScript, LiveScript and (obviously) JavaScript are supported, but this can be extended in the future. I will probably add the support for linters and minifiers in the near future.

As I have written previously, the activities manager service now supports creating private activities.

But it is not exposed in the UI at the moment.

Now, that is not the only problem that the current settings module for Activities has. A few things have improved in the previous few versions, but there is always more room for improvement.

One of the common complaints was that the activities settings module does not actually allow you to create, modify or delete activities.

Both issues will be fixed in the next release of KActivities framework.