06 Feb 2016

feedPlanet KDE

Plasma 5.5.4 and Calligra Suite 2.9.11 now available

The 4th update for KDE's Plasma 5.5.x series is now available to all Chakra users. According to the release schedule, unless new issues occur, this will be the last update for this series before 5.6 gets released next month.

Plasma 5.5.4 as usually includes a month's translations and bugfixes, with the authors highlighting the improvements for handling multi-screen setups.

The Calligra Suite also receives a bugfix update to version 2.9.11, which mainly provides fixes for krita and kexi.

It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue in relation to this update, please ask or report it on the related forum section.

Most of our mirrors take 12-24h to synchronize, after which it should be safe to upgrade.

06 Feb 2016 7:49pm GMT

Cantor migrating to Phabricator: which tools our contributors must to use

Projects and software developed by KDE community are going to migrate for a new tool to manage our code, commits, reviews, tasks, and more. This tool is Phabricator and you can visit the instance for KDE projects in this address.

Since November 2015 we are migrating Cantor to Phabricator. After our first successful review code some days ago, I decided to write a post about which tools our contributors must to use while the migration process is not finished.


Phabricator has an app to project management where we can to put some useful information and make coordination of tasks. The page for Cantor project is online and configured.

Other interesting feature is the possibility to join in a project or watch the activities of a project. If you have a KDE Identity, login in KDE Phabricator and follow us!


KDE provides an application to manage tasks using a kanban board, the KDE TODO. Despite it is a nice tool, we never used that.

Projects app in Phabricator has an application to this same objective, Workboard. We are using it currently to track tasks of SoK student Fernando Telles. I intent to use it to manage the development of Cantor for each new release.

Tasks, bugs, wishes

The Phabricator app named Maniphest is the tool to create and track bugs, tasks and wishes (feature requests).

But in KDE we have a heavily customized Bugzilla, so for the moment there is not a decision about how to migrate our bugs reports tool.

Therefore, KDE Bugzilla is our bugs reports tool yet. However, I invite the contributors to use Maniphest to submit wishes of new features. We never used Bugzilla for this last objective, so there is no problem if we begin to use the new tool for it.


Like the most of KDE Projects, Cantor has their source code managed by git. Phabricator has an application named Diffusion to navigate and see a lot of data about a source code repository.

This application is configured for Cantor and it is available in this link.

Code review

The Phabricator app to code review is called Differential and it is available to Cantor as well.

However, there is not a decision about the migration and the shutdown of the current code review tool used by KDE, Reviewboard. Therefore our contributors can to use one or other tool (please, not both together!), but I strongly recommend to use Differential.


Yes, Phabricator has an own application to wiki pages, named Phriction. Currently Cantor has a wiki page just in Userbase. We are not using wiki pages at the moment, so we will decide if Phriction will be our tool for wikis just at some point in the future.


Ok, Phabricator also has a tool for communication, Conpherence. However, Cantor contributors can continue to use our current communication tools provide by KDE Edu, the #kde-edu IRC channel at Freenode network and the KDE Edu mail list.


Despite I have some criticism about Phabricator (for instance, I don't like the Application -> Project architecture; I prefer Project -> Application), it is a very nice tool for projects management and it has a lot of applications for specific tasks. In this text I listed several of them, but there are many others to be explored and evaluated.

I hope this post can help Cantor contributors about which tool must to be utilized for some task of the project. Maybe the text can to present some news to future Phabricator users and help KDE developers in the path of the migration.

The impact of Phabricator in KDE community is something to be analyzed in the future. This tool has a lot of applications and it can change the way how the KDE subprojects are organized. Let's see what the future will say for us.

06 Feb 2016 7:28pm GMT

Kdenlive's sprint report

Last week-end, Vincent and me met in Lausanne for a Kdenlive sprint. One of our goal was to merge Gurjot Singh Bhatti's GSoC work on curves for keyframes. This was more work than expected and we spent many hours trying fix the curves and make keyframes behave correctly. Not much time was left for sleep, but we still managed to get outside to make a group (!) picture in the woods above Lausanne.

The code is working and in git master but cannot be used yet - we want to make sure older projects convert properly to the new keyframe system before enabling it - hopefully in less than a week. Below is a small demo of the feature:

Currently, only 1 dimension parameters are supported, but we hope to extend this to the transitions for the 16.04 release, allowing to move and resize the video using smooth interpolation instead of the current linear way.

During our meeting, we also discussed several UI changes that were initiated at Randa 2015, and hope to make some progress on that for the april release.

Next friday, the 12th of february (at 11am CET time), the 3rd Kdenlive café will be an occasion to discuss and exchange about Kdenlive's developments and community.

06 Feb 2016 7:06pm GMT

Jekyll 3.x

I've just upgraded this blog to Jekyll 3. There were quite a few hurdles along the way, but all should be ok now.

I've found three different types of transition issues (it is cool to look at these in a project I do not upgrade on a daily basis like Plasma and the rest of the KDE software).

Type 1: Issues that break the build

API for plugins has changed. This means that plugins I wrote for this blog stopped working (some of them).

This was the most painful one to fix, since I had to investigate the changes in the plugin system in a programming language that I really do not like (Jekyll is written in ruby).

Type 2: Sneaky behaviour changes

The second type of issues were small changes in behaviour like, say, changing how the permalinks are generated, changing a few things that were lowercase-only to uppercase and similar.

These issues were more annoying than the type 1. With type 1, you know where you are at - your build is broken, and you need to fix it.

The type 2 you can discover only by actually checking whether the pages are generated properly or not (in the end, I diffed the whole generated site to see what were the changes).

Type 3: Ruby GSL

The third issue was not really because of Jekyll upgrade, but it did appear at the same time.

Ruby GSL library relies on an ancient version of GNU Scientific Library which even Debian does not use anymore (Debian testing). And while building the site with jekyll, you get absolutely no information that your setup is broken. The build does not crash because of a missing library, because of incompatible library symbols, it just keeps building.

And keeps building.

And building.

At some point you realize that even ruby is not that slow and that something is wrong…


While it is nice to get speed improvements and all, we should pay attention not to break things.

In Plasma, we do create breakages in major releases because sometimes transitioning the configuration to the new architecture is hard, or impossible.

I just hope we will not have a good reason to do it again anytime soon. :)


06 Feb 2016 5:18pm GMT

kdev-python on Windows: try it!

I spent the last two or three days playing around with KDE on Windows, with the aim of getting my Python language plugin for KDevelop to run there. In the end, it wasn't that hard to get this to work - not as hard as I would have expected it to be, anyways. Several things needed to be fixed in kdev-python, the build system required a bit of tickling, but finally I produced an installer for KDevelop 4.90.92 which contains kdev-python:

http://files.svenbrauch.de/kdevelop-x86-setup-4.90.92.exe (SHA256: aa12f8b695c391b5b51fbba112d1ea3d10e9f032262cb8181be634387cd75fcc)

Don't consider this a beta release or something. It's just the current state of things.

You can just run this installer, launch KDevelop, and it should all work. To get completion for the Python standard libary, you need to have a Python interpreter (e.g. from python.org) installed and in your PATH before you start KDevelop. The kdev-python debugger currently does not work (or actually it does work, but the toolbar to control it is missing *grin*). Also it's probably all a bit slow, because I built some components in debug mode … I think.

Note that KDevelop on windows still has a few quirks, and kdev-python on windows probably has a few extra quirks on its own, so don't expect this to be too stable. That said, I loaded large amounts of code into it and it didn't crash and seemed to work just fine.

Here's a few screenshots:

completionCode completion outlineOutline view runRun program (make sure to have python.exe in your PATH or provide the full path to the python interpreter in the "Configure launches" dialog) tooltipvariable tooltips

Let me know if this works for you, or what problems you encounter.

Kudos to Kevin Funk for doing lots of work on KDevelop on Windows and helping me set this up!

06 Feb 2016 3:19pm GMT

FOSDEM 2016 and ownCloud, Kolab, KDE and more

Devices at our booth
After rocking SCALE, FOSDEM was next and a great event. Killing, too - two days with about 8000 people, it was insane. Lots of positive people again, loads of stuff we handed out so we ran out on Sunday morning - and cool devices at the ownCloud booth.


When we still had stickers and Jan still liked me
We had quite a team at the booth, with Frank Karlitschek, Philippe Hemmel, Jan-C Borghardt, Lukas Reschke and myself. Lukas visited his first FOSDEM and even though he started to complain a bit on Sunday about having had to many social interactions, he enjoyed it. Philippe was at his first ownCloud booth but has helped out at booths before so that went entirely smooth and Jan - well, he's so popular, people were nice to me a few times thinking I was Jan. I had to disappoint them, Jan was often to be found in the Design devroom where he gave a talk about how we do design at ownCloud (see also our earlier blog about 6 ownCloud User Interaction Design Principles).

Lukas and cameras don't go together well
My experience was the usual FOSDEM rush with so many people already there at 9:30 on Saturday (even though it is supposed to start at 10:00) that you barely have time to think, eat & drink or walk around and talk to old friends. I already had a long day on Friday as I went to a community statistics workshop by Bitergia but I'd even be tired after FOSDEM if I had a week to sleep in before...


Frank pushes press away ;-)
We had lots of stuff at the booth. Our usual stickers, flyers and some posters as well as my laptop where people could see ownCloud and sign up to our newsletter (80 new readers, yay). We also had some very cool devices, 2 prototypes from our friends at Western Digital and a spreed.me box, stay tuned as we have some cool news coming from there soon ;-)

Unfortunately, I hadn't brought enough stickers and flyers, we ran out in the morning of Sunday already, as Jan couldn't help but tell me over and over again. Yes, I brought over twice as much as last year but I guess I didn't factor in the growth in popularity of ownCloud... I'll double up again next year. Maybe triple.

It was great to talk to people about ownCloud, the devices, give them stickers and, in rare cases, explain what ownCloud is. Most people who walked by the booth already used ownCloud (yeah, techie crowd!) or are planning to, just one out of 10 has not heard of it. In general, my biggest regret at FOSDEM is that there are still people walking by whom we didn't manage to talk to. Perhaps more of those don't know the awesome that is ownCloud and are put off by the busyness at our booth - at many times, there was a row of 3-4 people thick in front of the booth and three of us were each talking to several people at once. Did I mention it was insanely busy?

Other booths

I did have some time to walk around and meet people at other booths, like the KDE, openSUSE and Kolab booths close by, as well as the FSFE stand. And I will promise myself, again, that I'll walk past all booths next year. Next year... Looking forward to it already!
FSFE let you send postcards to your favorite projects! A really nice initiative.
KDE showing their 'convergence'. The had Plasma Desktop running on an oDroid C1, quite smooth, and a mobile phone running Plasma Mobile! And very nice name stickers, too.
Happy Kolab team
Selfie with Markus Feilner - now at openSUSE. Their booth was close to ours, good to see so many old friends there again, including a strong Greek delegation!

Give me a shout if you want to help out at the ownCloud booth at FOSDEM or other events as we can always use more helping hands...

06 Feb 2016 10:40am GMT

05 Feb 2016

feedPlanet KDE

libotp - email rendering in kube

The important part of a mailreader is rendering an email. Nobody likes to read the raw mime message.
For kube we looked around what we should use for mail rendering. and came to the conclusion, that we will use parts of kdepim for that task. But the current situation was not the usable for us, because is was tangled together with other things of the mailviewer (like Akonadi, Widgetcode,...) , so we would end up depending on nearly everything in kdepim. What was a nogo for us. But after a week of untangeling the rendering part out of messageviewer, we end up with a nice library that does only mail rendering called libotp branch dev/libotp. But for the moment it is just a working name. Maybe someone come up with a better one?

Why a lib - email rendering is easy?

encrypted mail Well if you look from the outside, it really looks looks like an easy task to solve. But in detail the task is quite complicated. We have crypted and signed mail parts, html/not html mailparts, alternate mime structure, broken mail clients and so on. And than we also want user interaction, do we want to decrypt the mail by default? Do we want to verify mails by default? Do we allow external html links? Does the user user prefer html over non html? ...

In total you have to keep many things in the mind while rendering a mail. And we are not talking, that we also want a pluginable system, where we be able to create own rendering for special types of mails. All these thing a already solved by the messageviewer of kdepim: We have high integrated crypto support, support for many different mime types and it was already used for years, additionally the test couverage is quite high. Like you see in the image above we are already been able to decrypt and verify mails.


libotp is a library that renders emails to html. Maybe you ask, why the hell html? I hate html mails, too :D But html is easy to display and back in time there was no alternative, to show something that is that dynamic. Nowadays we have other solutions like QML, but still we have html message, that we wanna be able to display. Currently, we have no way, to try out QML rendering for mails, because the output of libotp is limited to html. I hopefully can also solve this to give libotp the ability to redner to different output formats, by splitting the monolithic task of render an email to html into a parse step, in which the structure of the email is translated into the visible parts (a signed part is followed by a encrypted one, that has as child a html part,...) and the pure rendering step.

If you follow the link libotp branch dev/libotp, you may wonder, if a fork of messagelib is happening. No the repo is created, to use libotp now in kube and I made many shortcuts and use ugly hacks to get it working. The plan is that libotp is part of the messagelib repo and currently I have already made it to push the first part of (polished) patches upstream. If everything went fine, I will have everything upstreamed by next week.

How to use it ?

At the moment it is still work in process, so it may change. Also if other step up and give input about the way they wanna use it.
Let's have a look how kube it is using kube/framework/mail/maillistmodel.cpp

// mail -> kmime tree
const auto mailData = KMime::CRLFtoLF(file.readAll());  
KMime::Message::Ptr msg(new KMime::Message);  

first step - load the mail into KMime to have a tree with the mime parts. file is a mail in mbox format located in a local file.

// render the mail
StringHtmlWriter htmlWriter;  
QImage paintDevice;  
CSSHelper cssHelper(&paintDevice);  
MessageViewer::NodeHelper nodeHelper;  
ObjectTreeSource source(&htmlWriter, &cssHelper);  
MessageViewer::ObjectTreeParser otp(&source, &nodeHelper);  

now initalize the ObjectTreeParser. Therefore we need


return htmlWriter.html();  

After initializing the Otp we can render the mail. This is done with otp.parseObjectTree(msg.data());. Around that we need to tell htmlWriter that a html creation has begun and ended afterwards.

As you may noticed, except the ObjectTreeParser and the NodeHelper kube has overloads of the objects. This makes libotp highly configurable for others needs already.

next steps

After the week of hacking now the current task is to push things upstream, to not create a fork and focus on one solution to render mails for kmail and kube together. After upstreaming I will start to extract the parts of libotp out of messageviewer (currently it is only another cmake target and not really divided) and make messageviewer to depend on libotp. With that libotp is a independent library that is used by both projects and I can focus again to polish libotp and messageviewer.


Here you see kube can now render your spam now nicely:
rendered spam

Like the spam says (and spam can't lie) - get the party started!

05 Feb 2016 12:03pm GMT

foss-gbg goes foss-north

As some of you might know, I run a group that meet and learn new stuff about foss month - foss-gbg. Today it's official that this summer foss-gbg goes foss-north and it is going to be awesome. So I welcome you all to the wonderful city of Gothenburg to a day filled with talks on a wide variety of topics around free and open source technology. It is going to be awesome!


05 Feb 2016 8:02am GMT

04 Feb 2016

feedPlanet KDE

The Emperor’s New Clothes or for breeze with inkscape

Inkscape get full breeze icon support.

git clone kde:breeze-icons

and test the new inkscape icons. They are not only an monochrome icon from the original so feedback is very welcome.



Do awesome thinks, join the VDG.

04 Feb 2016 11:01pm GMT

Logo for “Automobilismo Italiano”

Today I want to show the logo I made for "Automobilismo Italiano" a facebook page that talks about news and previews on the Italian car models.

I was inspired by the simplicity of the Fiat Punto logo.
punto-logoWith inkscape I used the grid, guides, and the skeleton view in order to have a better and more precise distribution of letters.

503 504

I decided to try two variants, one the dots represent the heads of hypothetical people who make up the logo.
The other version, without the dot on the "i" is more classical and minimal.Having arranged this, I colored the logo with the colors required by the Facebook page administrators.


Then I turned off the grill and here's the result.

Thanks inkscape, without you I would be lost !!

ciao biNbi

04 Feb 2016 1:05pm GMT

Krita 2.9.11 and the second 3.0 alpha build!

Today, we're releasing the eleventh bugfix release for Krita 2.9 and the second development preview release of Krita 3.0! We are not planning more bug fix releases for 2.9, though it is possible that we'll collect enough fixes to warrant one release more, because there are some problems with Windows 10 that we might be able to work around. So, please check closely if you use Krita on Windows 10:

And now for the fixes in 2.9.11!

2.9.11 Changelog

Go to the download page to get your updated Krita!

3.0 pre-alpha Changelog

For 3.0, we've got a bunch of new features and bug fixes.

There is still one really big issue that we're working hard on: OSX and the latest Intel GPU drivers break Krita's OpenGL support badly. On OSX, you will still NOT see the brush outline, symmetry axis, assistants and so on. On Windows, if you have an Intel GPU, the Krita window might turn totally black. There's no need to report those issues.


We recommend building Krita from git, not from the source zip file. Krita for OSX is build from a separate branch.


Download the zip file. Unzip the zip file where you want to put Krita..

Run the vcredist_x64.exe installer to install Microsoft's Visual Studio runtime.

Then double-click the krita link.

Known issues on Windows:


Download the DMG file and open it. Then drag the krita app bundle to the Applications folder, or any other location you might prefer. Double-click to start Krita.

Known issues on OSX:


For the Linux builds we now have AppImages! These are completely distribution-independent. To use the AppImage, download it, and make it an executable in your terminal or using the file properties dialog of your file manager. Another change is that configuration and custom resources are now stored in the .config/krita.org/kritarc and .local/share/krita.org/ folders of the user home folder, instead of .kde or .kde4.

Known issues on Linux:

04 Feb 2016 11:27am GMT

How Qt Signals and Slots Work - Part 3 - Queued and Inter Thread Connections

This blog is part of a series of blogs explaining the internals of signals and slots.

In this article, we will explore the mechanisms powering the Qt queued connections.

Summary from Part 1

In the first part, we saw that signals are just simple functions, whose body is generated by moc. They are just calling QMetaObject::activate, with an array of pointers to arguments on the stack. Here is the code of a signal, as generated by moc: (from part 1)

void Counter::valueChanged(int _t1)
    void *_a[] = { Q_NULLPTR, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) };
    QMetaObject::activate(this, &staticMetaObject, 0, _a);

QMetaObject::activate will then look in internal data structures to find out what are the slots connected to that signal. As seen in part 1, for each slot, the following code will be executed:

// Determine if this connection should be sent immediately or
// put into the event queue
if ((c->connectionType == Qt::AutoConnection && !receiverInSameThread)
        || (c->connectionType == Qt::QueuedConnection)) {
    queued_activate(sender, signal_index, c, argv, locker);
} else if (c->connectionType == Qt::BlockingQueuedConnection) {
    /* ... Skipped ... */
/* ... DirectConnection: call the slot as seen in Part 1 */

So in this blog post we will see what exactly happens in queued_activate and other parts that were skipped for the BlockingQueuedConnection

Qt Event Loop

A QueuedConnection will post an event to the event loop to eventually be handled.

When posting an event (in QCoreApplication::postEvent), the event will be pushed in a per-thread queue (QThreadData::postEventList). The event queued is protected by a mutex, so there is no race conditions when threads push events to another thread's event queue.

Once the event has been added to the queue, and if the receiver is living in another thread, we notify the event dispatcher of that thread by calling QAbstractEventDispatcher::wakeUp. This will wake up the dispatcher if it was sleeping while waiting for more events. If the receiver is in the same thread, the event will be processed later, as the event loop iterates.

The event will be deleted right after being processed in the thread that processes it.

An event posted using a QueuedConnection is a QMetaCallEvent. When processed, that event will call the slot the same way we call them for direct connections. All the information (slot to call, parameter values, ...) are stored inside the event.

Copying the parameters

The argv coming from the signal is an array of pointers to the arguments. The problem is that these pointers point to the stack of the signal where the arguments are. Once the signal returns, they will not be valid anymore. So we'll have to copy the parameter values of the function on the heap. In order to do that, we just ask QMetaType. We have seen in the QMetaType article that QMetaType::create has the ability to copy any type knowing it's QMetaType ID and a pointer to the type.

To know the QMetaType ID of a particular parameter, we will look in the QMetaObject, which contains the name of all the types. We will then be able to look up the particular type in the QMetaType database.


We can now put it all together and read through the code of queued_activate, which is called by QMetaObject::activate to prepare a Qt::QueuedConnection slot call. The code showed here has been slightly simplified and commented:

static void queued_activate(QObject *sender, int signal,
                            QObjectPrivate::Connection *c, void **argv,
                            QMutexLocker &locker)
  const int *argumentTypes = c->argumentTypes;
  // c->argumentTypes is an array of int containing the argument types.
  // It might have been initialized in the connection statement when using the
  // new syntax, but usually it is `nullptr` until the first queued activation
  // of that connection.

  // DIRECT_CONNECTION_ONLY is a dummy int which means that there was an error
  // fetching the type ID of the arguments.

  if (!argumentTypes) {
    // Ask the QMetaObject for the parameter names, and use the QMetaType
    // system to look up type IDs
    QMetaMethod m = QMetaObjectPrivate::signal(sender->metaObject(), signal);
    argumentTypes = queuedConnectionTypes(m.parameterTypes());
    if (!argumentTypes) // Cannot queue arguments
      argumentTypes = &DIRECT_CONNECTION_ONLY;
    c->argumentTypes = argumentTypes; /* ... skipped: atomic update ... */
  if (argumentTypes == &DIRECT_CONNECTION_ONLY) // Cannot activate
  int nargs = 1; // Include the return type
  while (argumentTypes[nargs-1])
  // Copy the argumentTypes array since the event is going to take ownership
  int *types = (int *) malloc(nargs*sizeof(int));
  void **args = (void **) malloc(nargs*sizeof(void *));

  // Ignore the return value as it makes no sense in a queued connection
  types[0] = 0; // Return type
  args[0] = 0; // Return value

  if (nargs > 1) {
    for (int n = 1; n < nargs; ++n)
      types[n] = argumentTypes[n-1];

    // We must unlock the object's signal mutex while calling the copy
    // constructors of the arguments as they might re-enter and cause a deadlock
    for (int n = 1; n < nargs; ++n)
      args[n] = QMetaType::create(types[n], argv[n]);

    if (!c->receiver) {
      // We have been disconnected while the mutex was unlocked
      /* ... skipped cleanup ... */

  // Post an event
  QMetaCallEvent *ev = c->isSlotObject ?
    new QMetaCallEvent(c->slotObj, sender, signal, nargs, types, args) :
    new QMetaCallEvent(c->method_offset, c->method_relative, c->callFunction,
                       sender, signal, nargs, types, args);
  QCoreApplication::postEvent(c->receiver, ev);

Upon reception of this event, QObject::event will set the sender and call QMetaCallEvent::placeMetaCall. That later function will dispatch just the same way as QMetaObject::activate would do it for direct connections, as seen in Part 1

  case QEvent::MetaCall:
    QMetaCallEvent *mce = static_cast<QMetaCallEvent*>(e);

    QConnectionSenderSwitcher sw(this, const_cast<QObject*>(mce->sender()),



BlockingQueuedConnection is a mix between DirectConnection and QueuedConnection. Like with a DirectConnection, the arguments can stay on the stack since the stack is on the thread that is blocked. No need to copy the arguments. Like with a QueuedConnection, an event is posted to the other thread's event loop. The event also contains a pointer to a QSemaphore. The thread that delivers the event will release the semaphore right after the slot has been called. Meanwhile, the thread that called the signal will acquire the semaphore in order to wait until the event is processed.

} else if (c->connectionType == Qt::BlockingQueuedConnection) {
  locker.unlock(); // unlock the QObject's signal mutex.
  if (receiverInSameThread) {
    qWarning("Qt: Dead lock detected while activating a BlockingQueuedConnection: "
             "Sender is %s(%p), receiver is %s(%p)",
             sender->metaObject()->className(), sender,
             receiver->metaObject()->className(), receiver);
  QSemaphore semaphore;
  QMetaCallEvent *ev = c->isSlotObject ?
    new QMetaCallEvent(c->slotObj, sender, signal_index, 0, 0, argv, &semaphore) :
    new QMetaCallEvent(c->method_offset, c->method_relative, c->callFunction,
                       sender, signal_index, 0, 0, argv , &semaphore);
  QCoreApplication::postEvent(receiver, ev);

It is the destructor of QMetaCallEvent which will release the semaphore. This is good because the event will be deleted right after it is delivered (i.e. the slot has been called) but also when the event is not delivered (e.g. because the receiving object was deleted).

A BlockingQueuedConnection can be useful to do thread communication when you want to invoke a function in another thread and wait for the answer before it is finished. However, it must be done with care.

The dangers of BlockingQueuedConnection

You must be careful in order to avoid deadlocks.

Obviously, if you connect two objects using BlockingQueuedConnection living on the same thread, you will deadlock immediately. You are sending an event to the sender's own thread and then are locking the thread waiting for the event to be processed. Since the thread is blocked, the event will never be processed and the thread will be blocked forever. Qt detects this at run time and prints a warning, but does not attempt to fix the problem for you. It has been suggested that Qt could then just do a normal DirectConnection if both objects are in the same thread. But we choose not to because BlockingQueuedConnection is something that can only be used if you know what you are doing: You must know from which thread to what other thread the event will be sent.

The real danger is that you must keep your design such that if in your application, you do a BlockingQueuedConnection from thread A to thread B, thread B must never wait for thread A, or you will have a deadlock again.

When emitting the signal or calling QMetaObject::invokeMethod(), you must not have any mutex locked that thread B might also try locking.

A problem will typically appear when you need to terminate a thread using a BlockingQueuedConnection, for example in this pseudo code:

void MyOperation::stop()
    m_thread->wait(); // Waits for the callee thread, might deadlock

// Connected via a BlockingQueuedConnection
Stuff MyOperation::slotGetSomeData(const Key &k)
    return m_data->get(k);

You cannot just call wait here because the child thread might have already emitted, or is about to emit the signal that will wait for the parent thread, which won't go back to its event loop. All the thread cleanup information transfer must only happen with events posted between threads, without using wait(). A better way to do it would be:

void MyOperation::stop()
    connect(m_thread, &QThread::finished, this, &MyOperation::cleanup);
    /* (note that we connected before calling quit to avoid a race) */

The downside is that MyOperation::cleanup() is now called asynchronously, which may complicate the design.


This article should conclude the series. I hope these articles have demystified signals and slots, and that knowing a bit how this works under the hood will help you make better use of them in your applications.

04 Feb 2016 10:18am GMT

03 Feb 2016

feedPlanet KDE

Hidden b.k.o-phab links

KDE Project:

Well, consider them unhidden now: if you missed a structured place to link bugs.kde.org big/wish reports with KDE Phabricator tasks, look no further.

One or more "See Also" fields of the bugzilla (top-right side) are useful points of integration. Example: link, see the screenshot below.

Unfortunately the opposite way does not work yet: Phabricator won't display bugzilla links. But if you use the "BUG:____" lines in your git commit messages they at least appear in summaries of Differential revisions (example).

Thanks to Ben who tirelessly enabled the links.

PS: These weeks mark end of my 13rd year in KDE!

03 Feb 2016 11:43pm GMT

So, why we are different?

Well, today I wrote 2 articles, and why not write another one?

On this week, I'm working very hard on my proposal to Google Summer of Code, and to say some things there, I needed to know better the others printers hosts open sources.

I choose 3 to start: PronterFace, MatterControl and Repetier Host.

Only opening this programms, I already get confused, cause, where are the settings? Where are the controls? Isn't easy to find.

So I made this comparisons between this softwares:

PronterFace PronterFace MatterControl MatterControl Repetier Host Repetier Host Br-Print3D Br-Print3D

Obviously, the actual state of the user interface of Br-Print3D isn't finished yet. Like the loading of the gcode file that have flaws that I want to resolve in a few weeks, but I think that you can see the difference between Br-Print3D and the above printer hosts.

And I feel that whe are making easy the way that the user can use a printer host. With the experiences that I had with this others, I really enjoy use Br-Print. But i'm a suspect to talk. =D

So, just looking at the pictures above, what do you think?

See ya!

03 Feb 2016 11:21pm GMT

Calligra 2.9.11 Released

We are pleased to announce availability of the Calligra Suite, and Calligra Active 2.9.11. It is recommended update for the 2.9 series of the applications and underlying development frameworks.

Support Calligra!

Bug fixes in This Release

You will find most of the improvements in Krita and Kexi. There are several others that may be not mentioned here.



Featured story: A commercially developed upgrade for MS Access (MDB) Import to Kexi has been donated by Jarosław Staniek (wish 277583). This also fixes import of primary keys (bug 336560). Large Access databases such as the Northwind sample now import better than ever.

Other Improvements:


Calligra Sheets


Try It Out

Download small

The source code of the release is available for download here: calligra-2.9.11.tar.xz.
Also translations to many languages and MD5 sums.
Alternatively, you can download binaries for many Linux distributions and for Windows (users: feel free to update that page).

What's Next and How to Help?

The next step after the 2.9 series is Calligra 3.0 which will be based on new technologies. We expect it later in 2016.

You can meet us to share your thoughts or offer your support on general Calligra forums or dedicated to Kexi or Krita. Many improvements are only possible thanks to the fact that we're working together within the awesome community.

(Some Calligra apps need new maintainers, you can become one, it's fun!)

How and Why to Support Calligra?

Calligra apps may be totally free, but their development is costly. Power, hardware, office space, internet access, travelling for meetings - everything costs. Direct donation is the easiest and fastest way to efficiently support your favourite applications. Everyone, regardless of any degree of involvement can do so. You can choose to:

Support entire Calligra indirectly by donating to KDE, the parent organization and community of Calligra: http://www.kde.org/community/donations.


Support Krita directly by donating to the Krita Foundation, to support Krita development in general or development of a specific feature: https://krita.org/support-us/donations.


Support Kexi directly by donating to its current BountySource fundraiser, supporting development of a specific feature, or the team in general: https://www.bountysource.com/teams/kexi.

About the Calligra Suite

Calligra Suite is a graphic art and office suite developed by the KDE community. It is available for desktop PCs, tablet computers and smartphones. It contains applications for word processing, spreadsheets, presentation, databases, vector graphics and digital painting. For more information visit calligra.org.

About KDE

KDE is an international technology team that creates free and open source software for desktop and portable computing. Among KDE's products are a modern desktop system for Linux and UNIX platforms, comprehensive office productivity and groupware suites and hundreds of software titles in many categories including Internet, multimedia, entertainment, education, graphics and software development. KDE's software available in more than 60 languages on Linux, BSD, Solaris, Windows and Mac OS X.

03 Feb 2016 9:58pm GMT

Why use ZIP instead of TAR?

I've been asked recently why ownCloud zipps its files instead of tarring them. .tar preserves file permissions, for one, and with tar.gz or tar.bz2 you have compression too.

Good question. Let me start by noting that we actually have both: zip and tar.bz2. But why zip?

A long time ago and far, far away

In the beginning, we used tar.bz2. As ownCloud gained Windows Server support, we added zip. Once we dropped Windows support, we could have killed the zip files. But we had reasons not to: tar is, sadly, not perfect.

Issues with Tar

You see, tar isn't a single format or a 'real' standard. If you have a platform other than plain, modern Linux, think BSD or Solaris, or the weird things you can find on NAS devices, tar files can get you in trouble. Unlike zip, tar files also can have issues with character format support or deep folders. We've had situations where upgrades went wrong and during debugging we found that moving to zip solved the problem miraculously... And, as ownCloud, we're squarely focused on the practical user experience so we keep zip, alongside tar.bz2.

See also the GNU tar manual if you want to know more about the various tar formats and limitations.

Sadly, sometimes it is impossible to find one thing that works for everyone and in every situation.

Tarred turtle pic from wikimedia, Creative Commons license. Yes, that's a different tar, I know. But - save the turtles!

03 Feb 2016 2:15pm GMT