In order to have an elegant way of switching plasma shells at runtime, we need to hide the process from the user. Is there a nicer way of doing that than showing a pretty splash screen on top of everything? (this is a rhetoric question - don’t answer, it has already been decided)

:)

This is aimed at Plasma Workspaces 2 and is pure Qt5/QML2 thingie. It will also be used as a base for the future versions of KSplashQML (aka TSP).

Here’s the obligatory looped gif showing what it looks like.

The KDE libraries (and some other parts as well) require that the code uses the so called d-pointer or pimpl (private implementation) idiom (see [1] and [2]). It makes it easier to keep the ABI unchanged, and it speeds up the compilation with insignificant runtime costs.

It usually goes like this - declare a Private class and a const pointer to it named d and (de)initialize it properly. Instead of having private class members, put them in that class. [2]

-- .h -------------------

class MyClass {
    <font color="silver">:::</font>
private:
    class Private;
    Private * const d;
};

-- .cpp -----------------

class MyClass::Private { <font color="silver">:::</font> };

MyClass::MyClass()
    : d(new Private())
{
    d->name = "I'm a private class member to replace m_name :)";
}

MyClass::~MyClass()
{
    delete d;
}

-------------------------

This works. But having explicit new and delete operators is generally frowned upon in the modern C++ world. It is quite easy to forget to add the delete d to the destructor. And it is nothing more than unnecessary boilerplate. The example at [1] improves this situation by using the QScopedPointer which automatically does the deletion for you.

With the new C++11 features (these are available since gcc 4.4), this can be made even cleaner.

.h ----------------------

class MyClass {
    <font color="silver">:::</font>
private:
    class Private;
    d_ptr<Private> d;
};

.cpp ----------------------------

class MyClass::Private { <font color="silver">:::</font> };

MyClass::MyClass()
{
}

MyClass::~MyClass()
{
}

No special handling of d, no new and no delete. Even if the Private class had a constructor with arguments, the implementation would be pretty:

.h ----------------------

class MyClass {
    <font color="silver">:::</font>
private:
    class Private;
    d_ptr<Private> d;
};

.cpp ----------------------------

class MyClass::Private {
    <font color="silver"></font>
    Private(t1 arg1, t2 arg2)
    { <font color="silver">:::</font> }
};

MyClass::MyClass()
    : d(arg1, arg2)
{
}

MyClass::~MyClass()
{
}

For the implementation of d_ptr class, you can see the d_ptr.h and d_ptr_implementation.h from kactivities repo [3].

Now, the code is perfectly safe. If you make a mistake, it will be detected by the compiler, and will not propagate to runtime.

[1] Library_Code_Policy:D-Pointers

[2] Binary Compatibility Issues With C++

[3] kde:kactivities

If you realize you don’t like JavaScript as much as everybody around you seems to, but still want to write platform-independent KWin scripts or effects, you can try out its most promising alternative - CoffeeScript

The code below creates a KWin effect that fades and zooms in the windows when a user switches the activities.

Edit: Fixed a small bug. Now it works quite well!

# Martin G. likes defining variables in a namespace,
# so we are not going to make him angry -
# we are creating a namespace that has only one
# variable in it - the duration

activitySwitchEffect =
    duration: animationTime(250)

# We don't really need anything else in the namespace
# for this simple example since we are about to abuse
# lambdas (aka anonymous functions) all over the place.

# We are connecting our function to the
# currentActivityChanged signal, and processing
# all the main windows we can find

effects.currentActivityChanged.connect (activity) ->
    effects.stackingOrder.map (client) ->
        if (activity in client.activities && client.visible)

            # If the client should be shown in
            # the current activity, we are starting
            # the animations - one to fade the window in
            # and another to scale it.

            animate(
                window: client
                animations: [
                    type:     Effect.Opacity
                    duration: activitySwitchEffect.duration
                    from:     0
                    to:       1
                ]
            )

            animate(
                window: client
                animations: [
                    type:     Effect.Scale
                    duration: activitySwitchEffect.duration
                    curve:    QEasingCurve.OutCubic
                    from:     0
                ]
            )

# And that's it!

Mind that this is only for demonstration - it has a few bugs in it :)

I always liked to keep the things clean, so the idea of having development environments for both KDE SC 4.x and KF5 on the same machine was not something that thrilled me. Apart from that, when I realized my versions of mesa+xcb are crashing the new plasma, I decided to go to the other side - the weird side.

My laptop is now dedicated to the new plasma developments, while my main system remains on the 4.x branch.

The problem is that the laptop is much slower than my main machine, has a small screen and keyboard which makes writing code on it painful. That is why I don’t use it directly - I work on my main system, while everything executes on the little guy. Everything, but compilation. Thankfully, the icecream distributed compilation system works without a glitch on any distribution although it was created by opensuse KDE people (kudos!).

I have to say that this is perfect - I can crash anything ranging from kded to kwin and plasma without interrupting my workflow, and can test plasma on a slower device so that I don’t introduce some big performance issues that I wouldn’t even notice on a real computer.

Since we are not using kao:ResourceScoreCache anywhere in core KDE software, Vishesh asked me to disable pushing those into Nepomuk.

This post is aimed to 3rd party developers that might have been using the RSC in their software or relying on file/document/resource scoring related to activities in any manner.

If you are one of those, contact me, and we’ll see whether we can do something about it that will satisfy both you and Vishesh :)