Published
in the Prog C++ section,
on 22 June 2013
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;
};
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 :)
Me again. I haven’t been online for a week - went on some pub crawls in Dublin
) - so I haven’t been able to reply to the comments to my last post which showed some nice things coming to Plasma.
BSmith1012: _I love the simplicity and extra effort you put into making it flexible. I know how much you hate icon views, and yet still made it possible to use in your example, so I appreciate that.
http://forum.kde.org/viewtopic.php?f=83&t;=89572
I posted this in the kde Brainstorm ages ago. If you release something like the screenshot that can include all of my favorite applications as Icons, I’d prolly be happy with that and I feel like many others will appreciate it as well. Thanks for all of the hard work!_
Answer: True, I’m not a fan of icon views, but there were a lot of requests to have those in both lancelot and kickoff. This didn’t take much effort now that we have QML. When this is finished, it will be rather easy to recreate kickoff, kickoff with icon view, or any other launcher you are used to. I do intend to create a few different layouts that will be shipped by default with the main launcher.
Fitzcarraldo:Lancelot (currently 1.9.5) is my launcher of choice, so I am interested to read about Lancelot 2. Can you give us a rough idea when Lancelot 2 might be released?
Answer: I’m not sure when it will be released. I don’t really expect it for the next version of KDE Plasma. I might publish a preview version out-of-kde-sc-schedule for testing purposes.
sir_herrbatka:Where the code is hosted? I would like to test it.
Answer: The code is currently at kde:scratch/ivan/lancelot-qml. The main applet is mostly for testing the infrastructure I’m making. In terms of features, it is nothing close to the current version of Lancelot, though it does look similar.
The important thing is that it will not screw up your regular installation - the applet is differently named.