RSI (Repetitive strain injury) is not an uncommon disorder in the geek world. It can range from a slight tiredness to a very unpleasant pain.

I don’t know how it should really be treated, but I know two things - it should not be ignored, and you should not, when you stop ignoring it, try to relax and rest your fingers by playing guitar after not playing it for more than a year. Air guitar should be fine if you don’t overdo it. :)

One of the first things I started doing as a precaution was to switch the mouse hand every once in a while, and to lessen the number of clicks by making a no-click application launcher.

The last step I took was a few days ago. Mainly because this summer is going to be very stressful for my hands, and my fingers don’t seem up to it at the moment. The last step was to remove the resistance of the keys on my keyboard. That is, to replace the keyboard with something else.

As you can see, I have replaced it with a virtual one (xvkbd) running on the exopc tablet under plasma active. It controls my main computer.

I expected it to be quite a productivity killer at first, but it turned out to be quite a pleasant exercise both for my hands (different motions, no resistance) and by mind (thinking of the shortest way to type a variable name by using the fuzzy completion of the vim’s YouCompleteMe plugin - haven’t typed more than three letters per variable in a whole day).

All in all, a rather fun setup. The only issue I’m having is that xvkbd is not meant for multi-touch so if somebody knows of a full-qwerty+special keys virtual keyboard that can be shown on one display and control a different one, I’d be much obliged.

The last post showed how to create a modern and safe d-ptr (pimpl) idiom. There were a few questions regarding the purpose of such a thing, when you can directly use std::unique_ptr or QScopedPointer. The main reason is that it provides additional safeguards from abuse by making the interface minimal. Most importantly, it does not provide an interface to get the raw pointer. (note: it does, but if you are able and want to write something like delete d.operator->() who am I to stop you)

Today, we’ll talk about something evil - singletons. Or, more precisely, the lesser evil brother of a singleton that lasts only while someone holds a pointer to it. Again, it is not something that is difficult to implement, even in old C++, but thanks to the new smart pointers of C++11 it starts to be more elegant.

template <typename Target>
class shared_singleton {
public:
    static std::shared_ptr<Target> instance()
    {
        auto ptr = s_instance.lock();

        if (!ptr) {
            ptr = std::make_shared<Target>();
            s_instance = ptr;
        }

        return ptr;
    }

private:
    static std::weak_ptr<Target> s_instance;
};

template <typename Target>
std::weak_ptr<Target> shared_singleton<Target>::s_instance;

There’s room for improvement (thread safety, interface), but it works quite well as it is.

And yes, I’m aware that it can be done with Qt’s pointer classes, or QShared* ones. :)

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 :)