Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content
Planet KDE -
Updated: 12 hours 52 min ago

Konsole and Wayland

Tuesday 18th of June 2019 12:00:00 AM

Wayland needs a different mindset when you are programming, you cannot just assume things works the same way as in as X11. One of my first patches to konsole was the rewrite of the Tab Bar, and a different way to deal with Drag & Drop of the tabs. In my mind - and how wrong I was - I could assume that I was dragging to a konsole main window by querying the widget below the mouse. Nope, this will not work. As Wayland has security by default, it will not give you anything global. What if I was a spy app trying to record another one to send to NSA? Security in Wayland is much stricter, and because of that I had to redo my drag & drop patch.

Konsole should work now with drag & drop of tabs in Wayland, as soon as the patch hits master. I also have other patches waiting that will make the wayland transition smoother, I’ll write about them in due time.

New Style Signal/Slot Connection

Monday 17th of June 2019 09:16:58 AM

Yes, I know. The last post on the assistants is rather boring. And yet these days I have been working on the snapshot docker, though it still seems a little (just a little, you see) unfinished as Dmitry is said to experience a relatively high delay when switching between snapshots. However this is not what I can reproduce on my older laptop, so I am really waiting for his test results in order to further investigate the problem.

But there is something interesting happening just when I am randomly testing things. FromKrita’s debug output, I saw QObject::connect() complaining about the arguments I passed, saying it is expecting parenthesis. “Okay,” I thought, “then there have to be something wrong with the code I wrote.” And that was quite confusing. I remember having used member function pointers in those places, got a compile-time error since KisSignalAutoConnectionsStore did not support the new syntax,then switched back to the SINGAL() and SLOT() macros. KisSignalAutoConnectionsStore is a helper class to quickly (dis)connect a group of connections. One can use the addConnection() method to add a connection, and use clear() to remove all connections made before.

Well, everything good, apart from the fact that I missed the parenthesis, which I did not discover until I looked into the debug output. So I asked Dmitry why not add the new syntax to KisSignalAutoConnectionsStore, and he said we should.

What is good about the new syntax is compile-time checking. We probably do not want our connectionsto fail to be made only when you run the program, just because there is a typo in the signature. That is definitely tiring and hard to catch (hmm, I did not notice the problem until today I randomly glanced at the command line; it might be worse if I shipped the snapshot docker together with those careless bugs).

The modification to the code seems straightforward. All what happens is in the KisSignalAutoConnection class. In its constructor, the connection is made using QObject::connect(); in its destructor, the connection is removed by passing the same sets of arguments to QObject::disconnect() currently in master. The signature is just KisSignalAutoConnection(const QObject *, const char *, const QObject *, const char *), as SIGNAL() and SLOT() macros are but to append their arguments to the string "1" and "2" respectively.

So the problem we have is we do not want the arguments that specify the signals and/or slots to be just strings. We want them to be pointers to member functions, or maybe lambdas. According to QObject document, the signature for new-style connect() is:

QMetaObject::Connection QObject::connect(const QObject *sender, PointerToMemberFunction signal, const QObject *context, Functor functor, Qt::ConnectionType type = Qt::AutoConnection)

Okay, so we know that sender and receiver should be pointers to QObjects, and either the type of signal or functor we do not know. Now let’s make our KisSignalAutoConnection constructor a template function:

template<class Signal, class Method>
inline KisSignalAutoConnection(const QObject *sender, Signal signal,
const QObject *receiver, Method method
Qt::ConnectionType type = Qt::AutoConnection);

But when these parameters are passed to QObject::connect(), we get a compile-time error, saying there is no matching overload for connect().


The answer is the Qt documentation is simplifying, if not hiding, the truth. The real definition for connect() is found in Line 227 of qobject.h:

template <typename Func1, typename Func2>
static inline QMetaObject::Connection connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal,
const typename QtPrivate::FunctionPointer<Func2>::Object *receiver, Func2 slot,
Qt::ConnectionType type = Qt::AutoConnection)

And tracking down the definition of QtPrivate::FunctionPointer, we get it in qobjectdefs_impl.h:

template<class Obj, typename Ret, typename... Args> struct FunctionPointer<Ret (Obj::*) (Args...)>
typedef Obj Object;

And seeing what we have passed to KisSignalAutoConnection (in the test code):

KisSignalAutoConnectionsStore conn;
conn.addConnection(, &TestClass::sigTest1,, &TestClass::slotTest1);

We can see that Func1 is a member function of TestClass, so QtPrivate::FunctionPointer<Func1>::Object is just TestClass. But the constructor of KisSignalAutoConnection receives a const QObject *. The problem here is that connect() is expecting a const TestClass *, but we give them a const QObject *. A base class pointer cannot be implicitly converted to a derived class pointer, so we have that error.

The resolution seems pretty simple, as we only need to include the types of sender and receiver into the template, and pass everything as-is to QObject::connect():

template<class Sender, class Signal, class Receiver, class Method>
inline KisSignalAutoConnection(Sender sender, Signal signal, Receiver receiver, Method method,
Qt::ConnectionType type = Qt::AutoConnection);

Sounds viable. But how can we store the four parameters? It might be intuitive to make another base class, say, KisSignalAutoConnectionBase(), and make KisSignalAutoConnection a template class, so we can store sender, receiver, etc.

But wait, isn’t this just too complex? First of all, we do not have any overridden functions except for the destructor. What is more, we do not seem to have any valuable things in that base class – it would be an empty class. The use of inheritance here is ugly and useless.

And, we do not need to store the four parameters at all. QObject::connect() returns a QMetaObject::Connection, which can be used later to disconnect() it. So instead of the parameters passed to connect(), we just store the Connection object. And that is not part of the template:

template<class Sender, class Signal, class Receiver, class Method>
inline KisSignalAutoConnection(Sender sender, Signal signal, Receiver receiver, Method method,
Qt::ConnectionType type = Qt::AutoConnection)
: m_connection(QObject::connect(sender, signal, receiver, method, type))

inline ~KisSignalAutoConnection()

QMetaObject::Connection m_connection;

And with the test code mentioned above, we do make sure that the new implementation works well with both syntaxes.

So, great, krita developers, we can use the new syntax for auto connections as well.

PS: There will soon be another post on my work of the snapshot docker – it’s almost finished!

KBibTeX 0.9 released

Sunday 16th of June 2019 08:02:43 PM

Finally, KBibTeX 0.9 got released. Virtually nothing has changed since the release of beta 2 in May as no specific bugs have been reported. Thus ChangeLog is still the same and the details on the changes since 0.8.2 as shown on the release announcement for 0.9-beta2.

Grab the sources at KDE&aposs download mirrors.


International number formats

Sunday 16th of June 2019 03:01:14 PM

KMyMoney as a financial application deals with numbers a lot. As a KDE application, it supports internationalization (or i18n for short) from the very beginning. For accuracy reasons it has internal checks to verify the numbers a user can enter.

The validation routine has a long history (I think it goes back to the KDE3 days) and we recently streamlined it a bit as part of the journey to use more and more Qt standard widgets instead of our own.

This led to the replacement of the KMyMoneyEdit widget with the newer AmountEdit widget. Everything worked great for me (using a German locale) until we received notifications that users could only enter integer numbers but no fractional part. This of course is not what we wanted. But why is that?

The important piece of information was that the user reporting the issue uses the Finland svenska (sv_FI) locale on his system. So I set my development system to use that locale for numbers and currencies and it failed for me as well. So it was pretty clear that the validation logic had a flaw.

Checking the AmountValidator object which is an extension of the QDoubleValidator I found out that it did not work as expected with the said locale. So it was time to setup some testcases for the validator to see how it performs with other locales. I still saw it failing which made me curious so I dug into the Qt source code one more time, specifically the QDoubleValidator. Well, it looked that most of the logic we added in former times is superfluous meanwhile with the Qt5 version. But there remains a little difference: the QDoubleValidator works on the symbols of the LC_NUMERIC category of a locale where we want to use it the LC_MONETARY version. So what to do? Simply ignore the fact? This could bite us later.

So the next step was to check what happens within the testcases: Using the current code base they fail. Ok, good news I caught the problem. Using the plain QDoubleValidator and running the testcases again showed that all were positive. So no problem? What if a locale uses different symbols for the decimal point and the thousands separator? Does such a locale exist? Looking at all of them seemed a bit tedious, but tedious work is something for a computer. Here’s the little script I wrote (for simplicity in Perl):


So, they do exist. Bummer, we need to do something about it. On my box, I collect 484 locales where 110 show differences. That’s close to 25% of the locales, too much to simply ignore the problem. Since some of the locales where present in multiple formats (e.g. br_FR, br_FR@euro and br_FR.utf8) I concentrated on the utf8 versions and the ones that contained an at-sign in their name). This modified the figures to 37 with differing values out of 182 locales checked. Still 20%. Here’s that list. <> denotes an emtpy string, and _ denotes a blank in the locale. If I would not replace those values one could not see a difference in a terminal session.

Locale dp mon_dp sep mon_sep aa_DJ.utf8 . . <> _ aa_ER@saaho . . <> , be_BY@latin , . . _ be_BY.utf8 , . . _ bg_BG.utf8 , , <>   bs_BA.utf8 , , <> _ ca_AD.utf8 , , <> . ca_ES@euro , , <> . ca_ES.utf8 , , <> . ca_FR.utf8 , , <> . ca_IT.utf8 , , <> . de_AT@euro , , . _ de_AT.utf8 , , . _ es_MX.utf8 . .   , es_PE.utf8 , . . , eu_ES@euro , , <> . eu_ES.utf8 , , <> . gez_ER@abegede . . <> , gl_ES@euro , , <> . gl_ES.utf8 , , <> . hr_HR.utf8 , , <> _ it_CH.utf8 , . ' ' it_IT@euro , , <> . it_IT.utf8 , , <> . mg_MG.utf8 , , <> _ nl_BE.utf8 , , . _ nl_NL@euro , , <> _ nl_NL.utf8 , , <> _ pl_PL.utf8 , , <> . pt_PT@euro , , <> . pt_PT.utf8 , , <> . ru_RU.utf8 , .     ru_UA.utf8 , . . _ so_DJ.utf8 . . <> _ sr_RS@latin , , <> . tg_TJ.utf8 , . . _ tt_RU@iqtelif , . .   182 locales processed, 37 locales differ.

Next I went in and tried to figure out what differences exist. A bit of UNIX foo (i.e. combining the tools of your toolbox) shows the results:

./checklocales | tr '\t' ':' | cut -d: -f2- | tr ':' '\t' | sort | uniq | grep -v "mon_dp" | grep -v "process"

reveals the following result (I added the header here manually):

dp mon_dp sep mon_sep , , <> _ , , <> . , , . _ , . . _ , . . , , . .   , . ' ' . . <> _ . . <> , . .   , , , <>   , .    

Running this additionally through “wc -l” shows 12 different combinations. The last one is strange, because it does not show anything in the last two columns. Looking at the full table shows that this is the entry produced by ru_RU.utf8. Why is this now? Running

LC_ALL=ru_RU.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep

we get

decimal_point="," mon_decimal_point="." thousands_sep=" " mon_thousands_sep=" "

which looks just fine, but why did we not see the underbar for the blanks in the thousands separator? Running the above output through our friend od we see why:

LC_ALL=ru_RU.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c 0000000 d e c i m a l _ p o i n t = " , 0000020 " \n m o n _ d e c i m a l _ p o 0000040 i n t = " . " \n t h o u s a n d 0000060 s _ s e p = " 302 240 " \n m o n _ t 0000100 h o u s a n d s _ s e p = " 302 240 0000120 " \n 0000122

Ah, “302 240” octal: that is some UTF-8 encoded character presented as a blank in my default locale. Ok, since it is the same no big deal. But there are two more:

, . .   . .   ,

Going into the long list we see that these are the results of tt_RU@iqtelif and es_MX.utf8. Looking at od’s output we see:

LC_ALL=tt_RU@iqtelif locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c 0000000 d e c i m a l _ p o i n t = " , 0000020 " \n m o n _ d e c i m a l _ p o 0000040 i n t = " . " \n t h o u s a n d 0000060 s _ s e p = " . " \n m o n _ t h 0000100 o u s a n d s _ s e p = " 342 200 202 0000120 " \n 0000122 LC_ALL=es_MX.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c 0000000 d e c i m a l _ p o i n t = " . 0000020 " \n m o n _ d e c i m a l _ p o 0000040 i n t = " . " \n t h o u s a n d 0000060 s _ s e p = " 342 200 211 " \n m o n _ 0000100 t h o u s a n d s _ s e p = " , 0000120 " \n 0000122

so again just some special chars which are shown as blank, but they differ between numeric and currency representation in the said locales.

While trying a few things I stumbled across the following output. See for yourself:

LC_ALL=C.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep decimal_point="." mon_decimal_point="." thousands_sep="" mon_thousands_sep="" LC_ALL=C locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep decimal_point="." mon_decimal_point="" thousands_sep="" mon_thousands_sep=""

What? The C locale (non UTF-8 version) has no monetary decimal point defined? This may end in strange results, but since nowadays we talk about UTF-8 I simply put it aside.

Back to the original problem: the AmountValidator. Looking at the results above, it seems not to make sense to simply use the QDoubleValidator version. Would it make sense to allow both versions? To use the QDoubleValidator we would need to replace the currency versions of the two characters with their numeric version. The question is: would that lead to false strings in any of the locales? Looking at the long list, we find the following where both characters are different:

Locale dp mon_dp sep mon_sep be_BY@latin , . . _ be_BY.utf8 , . . _ es_PE.utf8 , . . , ru_UA.utf8 , . . _ tg_TJ.utf8 , . . _ tt_RU@iqtelif , . .  

es_PE.utf8 seems to be the worst candidate. The meaning is simply reversed. Let’s add this locale to the testcases and see how it performs.

Looks like it works out of the box. Strange, I expected a different result. Anyway, the changes to KMyMoney are now committed to the master branch and I can continue with the next problem.

KDE Usability & Productivity: Week 75

Sunday 16th of June 2019 05:01:06 AM

Week 75 in KDE’s Usability & Productivity initiative is here! It’s a little lighter than usual because we’re all feverishly preparing for the dual Plasma and Usability & Productivity sprints nest week in Valencia, Spain. I’ll be there, as well as the whole Plasma team, a bunch of VDG people, and a number of folks who have stepped up to work on apps for the U&P initiative. Sprints like these promise the kind of face-to-face contact needed for big projects, and should be a fantastically awesome and productive time! I’d like to offer a special thanks to Slimbook (makers of the KDE Slimbook II laptop) for hosting the sprint!

Anyway, here’s the week’s report:

New Features Bugfixes & Performance Improvements User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a donation to the KDE e.V. foundation.

The state of Terminal Emulators in Linux

Sunday 16th of June 2019 12:00:00 AM

We are seeing a strange trend nowadays: The terminal is being more widely used in windows, after they fixed the broken cmd.exe and MS is actually actively promoting their terminal applications like Visual Studio Code and the new Windows Terminal, but on the other hand the Unix world was always terminal based, even if you tend to use the Desktop Environment for your daily needs you probably also had a Terminal open somewhere.

And because we had always been terminal users, there are a lot of terminals for Linux, But it’s not easy to keep a terminal up to date, it’s usually fragile code and hard to maintain, that means that a lot of projects, good projects, are abandoned.

Good terminals that unfortunately didn’t make it
  • Tilix: Is one of the best terminal emulators out there, it’s a shell written in D, on top of VTE, the author lacks the time to continue working on it.
  • Terminator: I don’t know if this one is abandoned as there’s no news on the web about it, the news that I know is that version 2 is scheduled for release in 2017, never happened though.

If you are sad that your favorite terminal is without a maintainer, try to maintain it, free software depends on developers.

The state of Konsole:
  • Konsole is receiving more reviews, more code and more contributors in the last year than it got in the past 10 years.
  • In the past, the project is kept alive by Kurt, and he did an awesome job. But a project as big as konsole needs more people.
  • Three new developers joined konsole and are activelly fixing things over the past year, no plans to stop.
  • Terminator / Tilix split mode is working
  • A few features to be completely equal to minix / terminator is missing, but not hard to implement

Now it has more developers and more code flowing, fixing bugs, improving the interface, increasing the number of lines of code flowing thru the codebase. We don’t plan to stop supporting konsole, and it will not depend on a single developer anymore.

We want konsole to be the swiss army knife of terminal emulators, you can already do with konsole a lot of things that are impossible in other terminals, but we want more. And we need more developers for that.

Konsole is, together with VTE, the most used terminal out there in numbers of applications that integrate the technology: Dolphin, Kate, KDevelop, Yakuake, and many other applications also use konsole, so fixing a bug in one place we are helping a lot of other applications too.

Consider joining a project, Consider sending code.

New features for

Saturday 15th of June 2019 09:35:35 AM

In the last week, there have been various small improvements to the website.

Search bar in

KDE has a lot of applications and with the last update to made by Jonathan Riddell, all these applications are now displayed on the website.

The problem is that it’s now difficult to search for a specific application, so I added a search bar to this page. See Merge request 5 kde-org-applications

Support multiple screenshots per application

According to the AppStream specification, an application can have multiple screenshots. If before only the first screenshot was displayed, now all screenshots are displayed in a carousel. See Merge request 3 kde-org-applications

Adding information

The application page now contains some additional metadata information. This can help search engines to better understand the content of the webpage. See Merge request 7 kde-org-applications

Improving the Plasma product page

With Plasma 5.16, we now have a new wallpaper, so I changed the wallpaper displayed at Problem: the contrast between the text and the background wasn’t great. So I added a small breeze like window, created only with CSS and HTML.

Junior jobs

There still are a lot of things that can be improved, and we would appreciate some help to do it. If you always wanted to contribute to KDE, but don’t have any knowledge in Cpp and Qt, then you can also help with web development.

If you are interested, I listed some junior jobs.

  • The carousel used to display the application screenshots still has some problems. The next and previous buttons don’t use the same theme as the carousel shown on the homepage. Also, when screenshots have a different size, the transition is not perfect. For more information, see bug 408728.

  • We need to add a description for each page in This will improve the SEO used for KDE. First we need to define the new variable in aether, use it, and then we can start adding descriptions. This task needs to be done in cooperation with kde-promo and this should help with Search Engine Optimization (SEO).

I wrote a small installation instruction on how to setup your local development environment. And if you need any help, you can as always contact me in Mastodon at or with matrix at

Meet KDE in València

Friday 14th of June 2019 06:58:22 PM

During the next days, we’ll be having several sprints in València.

First we’ll be having the KDE e.V. Board on Monday and Tuesday then we’ll be having two big sprints:

  • Plasma, where we’ll be planning and working on the features for the next year (or more!)
  • Usability & Productivity goal’s that will look into different applications and components in KDE that need attention to work properly and improve them.

If you are around and you’d like to meet the different groups, we’ll be having open dinners so you can join and ask us anything.

  • The Board dinner will be next Monday 17th June at 20:30.
  • The Plasma & Usability dinner will be next Saturday 22nd June at 20:30.

Send me an e-mail to saying when you’d like to come.
The location will be decided depending on the amount of people who ends up coming.

Last but not least, big thanks to Slimbook for hosting us for this sprint!

Done with boost

Friday 14th of June 2019 06:46:56 PM

This would start with a quote: Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. Description Update

Friday 14th of June 2019 12:52:46 PM

The KDE Applications website was a minimal possible change to move it from an unmaintained and incomplete site to a self-maintaining and complete site.  It’s been fun to see it get picked up in places like Ubuntu Weekly News, Late Night Linux and chatting to people in real life they have seen it get an update. So clearly it’s important to keep our websites maintained.  Alas the social and technical barriers are too high in KDE.  My current hope is that the Promo team will take over the kde-www stuff giving it communication channels and transparancy that doesn’t currently exist.  There is plenty more work to be done on website to make it useful, do give me a ping if you want to help out.

In the mean time I’ve updated the front page text box where there is a brief description of KDE.  I remember a keynote from Aaron around 2010 at Akademy where he slagged off the description that was used on  Since then we have had Visions and Missions and Goals and whatnot defined but nobody has thought to put them on the website.  So here’s the new way of presenting KDE to the world:

Thanks to Carl and others for review.


June 2019 Krita Development Update

Thursday 13th of June 2019 07:41:24 AM

Time for another development update. The last one was in April. We skipped reporting on May, because doing a release takes a lot of time and effort and concentration! And then we had to do a bugfix release in the first week of June; the next release, Krita 4.2.2, will be out by the end of this month.

We’re still fixing bugs like crazy, helped by long-standing community member Ivan Yossi, who started fixing bugs full-time in May, too.

But then, we’re also getting a crazy number of bug reports. Honesty compels us to say that many of those reports are not so very valuable: there are many people with broken systems who report problems that we cannot solve in Krita, and many people report bugs without telling us anything at all. Hence we created a manual page on reporting bugs! But there are also many helpful bug reports that give us a chance to improve things.

So, how does Krita’s development work these days? Well, there are the many people who work on Krita as volunteers, which has always been the mainstay of Krita development. Then there are this year’s four Google Summer of Code students, who are all making good progress in their projects.  Krita has participated in every edition of Google Summer of Code since the beginning.

But these days, there are four people working on Krita full-time, thanks to donations, the development fund (which we’re working on to revamp a bit and make it more useful to supporters, too), the Windows Store and the Steam Store. None of us is exactly getting rich, but we’re getting by. And we’re doing stuff that would otherwise be hard to do: projects that take several weeks or months to complete, fixing lots of bugs all over the place, doing janitorial stuff like fixing warnings and so on.

Since this is a development update, we’ll just in passing mention all the great work that’s been done on this website, the manual, and all the work supporting our users on places like the forum or reddit.

We’re all hanging out on the Krita IRC channel, which is the main place where contributors to Krita come together to discuss whatever needs to be discussed. We have a weekly meeting every Monday from 14:00 to 15:00 CE(S)T — which means that if you’ve got a question about Krita, that’s probably not the right time to join the channel.

In August, we’ll have another Krita Sprint, a big one, with 25 people attending. Half of the people coming to the Sprint are contributors, half are artists and half are both.

So, that’s how our community in general works — but what did we do specifically, since the release? Since 4.2.0, we released 4.2.1 with a bunch of bug fixes already, and the fixing has not abated. Tiar has finished most of the work on making Krita report back any and all failures when saving an image. Dmitry has been fixing some severe issues in the layer stack, GPU canvas and tool handling, Boudewijn has been fixing bugs all over the place and Ivan has been busy with animated brush tips (that is, Gimp Image Hose files).

Color is random, left and right hands come one after the other, and hand direction  is dependent on drawing direction. Image by Ivan Yossi.

Not for 4.2.2, but 4.3 (which should be out in September) are two new features already: the palettize filter by Carl Olsson, still work in progress, but that’s fine, 4.3 isn’t done yet, and the High Pass filter by Miguel Lopez:

Allows interactively painting in truecolour while viewing matched to palette, with optional pattern-based dithering. Image by Carl Schwan

At the Libre Graphics Meeting, which was attended by Boudewijn, Wolthera and Tiar, several projects presented the history of their project with cool graphs. Well, since Krita officially turned twenty on June 8th (which we completely forgot to celebrate, because of all the release work), we thought it might be interesting to analyze the history of Krita’s codebase a bit as well.

Interestingly, this commit isn’t even in Krita’s git repository anymore: a lot of history was lost over the years. Krita started out as KImageShop in KDE’s CVS repository. Then, after KImageShop had been renamed to Krayon and Krita, the CVS repository was converted to Subversion. Then the subversion repository was converted to git, and the git repository split into a KOffice, a Calligra and a Calligra-History repository.  And then the Krita repository was extracted from the Calligra repository. Still, let’s take a look at what we found out.

We used theseus-of-git to analyze the repository. Here’s the number of lines of code written by the top twenty-five developers.

Another interesting graphic shows how long code survives over the years. Just as in the previous graph, there’s a huge peak of code that quickly disappears, and that’s when KOffice/Calligra was being developed together with Nokia for the Maemo document viewer application. When Krita was separated from Calligra, all that code was no longer necessary.

The type of files in the repository is pretty constant: it’s .cpp and .h files, meaning, that Krita is and always has beem mostly C++. The funniest thing is maybe the enormous number of lines of code in .xmi files. That’s Umbrello‘s file format, and it represents UML diagrams of Krita’s codebase. Those had to be updated manually, and at one point, we just deleted them because they had gotten useless.

A new door opens: MBition GmbH

Wednesday 12th of June 2019 08:10:05 PM

This month of June I have started a new adventure. I have joined MBition, GmbH, a 100% owned subsidiary of Daimler AG focused on …

“MBition focuses on Infotainment-Software, Navigation-Software, Cloud-Software and UI-Software. ” (extracted from the MBition website).

Automotive is one of those industries that is going through disruptive changes. I think it is a very interesting place to be right now if you are looking for some excitement.

Back in 2018, I did a talk at the Autonomous Vehicle Software Symposium, in Stuttgart, Germany, where I said something like this, when referring to software platforms for automotive in the autonomous driving era:

  • What the industry is doing today will not work then.
  • What the industry knows today in this field will not be enough.
  • Learning fast becomes the only suitable strategy to succeed.

Then I asked if OEMs and Tier 1s were learning fast enough. I still believe today that in general no they are not.

Will we at MBition be able to make a positive impact in the way Daimler is learning about how to design, develop, deliver and maintain a software stack that meets the current and future industry requirements, providing at the same time a premium experience to customers, developers and partners?

I will work to answer YES to that question. It will be an outstanding challenge to face during the coming months. I am very excited about it.

Thanks Gregor, Johan and the rest of the MBition crew for giving me this opportunity. A new journey begins.

I will remain in Málaga working remotely for now but visiting Berlin frequently since MBition’s office is located there.

GSoC 2019 – Week 2 with the Titler Tool

Wednesday 12th of June 2019 06:15:46 AM

Hello again!

In the last week, I gained progress with the QML rendering library (see the code here)

It is doing what it is supposed to do – it renders an input QML file to output frames of a specified format and renders it as quick as possible (with QQuickRenderControl). If you want to test it out – there is CLI access to it through an executable (which is one of the things I’ve been working in the last week) for the library in the test directory here (make sure you read the READMEs along the way!)

So let’s try to understand what really happens at the core of the library i.e. the rendering part.

To render QML, the obvious approach is to take ‘screenshots’ of each frame using a grab() method which would grab all the pixels at each instant of time and then render it – not only is this darned slow and expensive, it is also not possible to render at a custom frame rate that way.

Here’s where QQuickRenderControl comes into the picture. QQuickRenderControl is used for rendering Qt Quick content (read QML) onto something in a very controlled manner. If you read the official documentation, that ‘something’ is an ‘offscreen render target’ – emphasis on ‘offscreen’ – which means we can tell our dummy window or surface to render our QML onto something else (a QOpenGLFramebufferObject to be specific) and that too, in a very quick process as well!

That was in words, now let’s see some code – I do not want to confuse you (further) but this is essential because at the core of this library is this rendering.

Before we start rendering, we need to setup QQuickRenderControl :

1) Set up the the format of the surface on which we will be doing the rendering on.

QSurfaceFormat format;

2) Set up the OpenGL context

m_context = std::make_unique<QOpenGLContext>();

3) Set up the surface (dummy)

m_offscreenSurface = std::make_unique<QOffscreenSurface>();

4) Set up RenderControl and target window (dummy)

m_renderControl = std::make_unique<QQuickRenderControl>(this);
m_quickWindow = std::make_unique<QQuickWindow>(m_renderControl.get());

5) Create frame buffer object, and tell QuickWindow to render to this object

m_fbo = std::make_unique<QOpenGLFramebufferObject>(m_size * m_dpr, QOpenGLFramebufferObject::CombinedDepthStencil);

And with that, we can begin rendering but there’s a catch – we cannot render at a custom frame rate yet, as I said before (and that is exactly what the blog that I had earlier mentioned was trying to primarily address). To achieve this, we need to tweak the animation driver – we create our own animation driver and advance frames at our own pace:

void advance() override
m_elapsed += m_step;

With that, and the next 4 lines (in an event driven loop, of course)


You’re rendering frames! (if you want to see this code in practice, please have a look at root/QmlRenderer/src/)

That’s how it works – in my work so far here, I have made the above mentioned code, almost production ready.

For the next week, I’ve already started writing unit tests to make sure the library works fine at all points in the future. And after that, I’ll start tinkering with MLT and writing a MLT producer.

And here’s a question you might be having by now, why develop this as an independent library? Why not just directly integrate it with MLT?

a) Modularity : Easier to test an independent piece of code and make sure it works.
b) Easy integration : It’s easier to integrate a module with a framework – as there are discussions regarding MLT’s future in Kdenlive.

That’s it for this week, let’s hope for the best!

KDE neon 5.16 Out

Tuesday 11th of June 2019 05:34:30 PM

KDE neon 5.16 is out featuring Plasma 5.16. Download the ISO now or upgrade your installs.

With Diversity in mind this edition features an Ice Cold themed wallpaper to make those in the southern hemisphere feel included.

Plasma 5.16 for Disco 19.04 available in Backports PPA

Tuesday 11th of June 2019 03:23:29 PM

We are pleased to announce that Plasma 5.16, is now available in our backports PPA for Disco 19.04.

The release announcement detailing the new features and improvements in Plasma 5.16 can be found here

Released along with this new version of Plasma is an update to KDE Frameworks 5.58. (5.59 will soon be in testing for Eoan 19.10 and may follow in the next few weeks.)

To upgrade:

Add the following repository to your software sources list:


or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

sudo add-apt-repository ppa:kubuntu-ppa/backports

and packages then updated with

sudo apt update
sudo apt full-upgrade


Please note that more bugfix releases are scheduled by KDE for Plasma 5.16, so while we feel these backports will be beneficial to enthusiastic adopters, users wanting to use a Plasma release with more stabilisation/bugfixes ‘baked in’ may find it advisable to stay with Plasma 5.15 as included in the original 19.04 Disco release.

Issues with Plasma itself can be reported on the KDE bugtracker [1]. In the case of packaging or other issues, please provide feedback on our mailing list [2], IRC [3], and/or file a bug against our PPA packages [4].

1. KDE bugtracker:
2. Kubuntu-devel mailing list:
3. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on
4. Kubuntu ppa bugs:

KIOFuse: 32-bit Support

Tuesday 11th of June 2019 12:20:13 AM

The first two weeks of the GSoC coding period are now over.

Firstly, a mapping between KIO errors and FUSE errors has now been established. Previously all KIO Job errors were simply sent back to FUSE as EIO, which isn’t entirely accurate. The mapping now provides more accurate error replies.

A major new addition is 32-bit support. KIOFuse did not compile on 32-bit but these compilation errors have now been alleviated. They mostly stemmed from the fact that size_t has a different size on different architectures, and that file sizes should always be represented as off_t anyway.

Another big question was whether files larger than 4GiB could be sent without data corruption. A switch from the C standard I/O functions to UNIX I/O functions was necessary to avoid data corruption. However, this alone was not sufficient. On 32-bit files larger than 4GiB I noticed that no write call was occurring, although it occurred on 64-bit and on 32-bit with smaller files. I couldn’t point this down to anything in KIOFuse (seeming as KIOFuse simply responds to requests passed by FUSE, what can we do if we don’t receive the necessary request?). Luckily one of my mentors, fvogt, spotted a kernel bug report, which fortunately was fixed about a month ago. This bug was the cause of the problem I was seeing. This means that transferring of files larger than 4GiB via KIOFuse is now supported on distros running kernels 5.1.5+ only. Because of this, we do not recommend packaging or using KIOFuse on kernels less than the mentioned version, due to likely data corruption when transferring large files. This patch is still not in master and is under active review. It is being looked into whether adding a unit test is feasible.

I’d like to thank my mentors, fvogt and chinmoy for their help and guidance so far and look forward to improving KIOFuse further. Over the next week, signal handling and password change/unmount (if necessary) support are the features that will be worked on.

Nextcloud Login Plugin for PlaMo

Tuesday 11th of June 2019 12:10:56 AM

With the completion of my first milestone for my GSoC project: Nextcloud Integration on Plasma Mobile, plasma mobile accounts settings now enables the users to add their nextcloud accounts via webview.

Well! didn’t accounts setting already provide the method to add nextcloud/owncloud accounts? Yes, this functionality was already implemented by the owncloud plugin in kaccounts-providers project. Then, why did I re-implement the same thing?
As I mentioned, now accounts can be added via webview.

Why using WebView approach for login is better?
This approach is not only more convenient to implement but, it also makes sure that the application never stores the user’s password. The users can be ensured that their credentials can’t be misused.

Work Flow
Clicking on Add new Account button shows all the accounts plugin options declared by files in providers folder of kaccounts-providers.

On choosing nextcloud option, Nextcloud Wizard shows up. On clicking the login option, the server address entered by user is checked and then the WebView is initiated.

On the final login the server redirects to a url of the following format:
From this URL login name and password that the application must use to login and store securely is fetched. The control is passed back to the wizard. The user is given option to choose whether or not (s)he wants to synchronize the contacts from the server. This is further facilitated and managed by kaccounts-mobile. Once the login is complete, the username, the password and the other data stored in json object is passed to kaccounts-integration. It manages storing all the accounts and displaying saved accounts on plasma-settings Accounts.

Kate & C++ Developer Survey

Monday 10th of June 2019 08:45:00 PM

While browsing the ISO C++ homepage I stumbled over the results PDF of the Second Annual C++ Foundation Developer Survey “Lite”.

I was astonished that Kate made it into the “Which development environments (IDEs) or editors do you use for C++ development?” results.

;=) Seems not only I use it as my normal editor for working on C++ code.

And heads up, KDevelop is there, too!

This is actually the second survey, I missed to notice the first one last year. The results PDF from last year shows Kate did show up already there.

We shouldn’t be that proud of only having less than three percent usage, but still, we are there at all. I hope we can rise here a bit in the future.

At least we work on supporting modern C++ standards in the highlighting, e.g. see the recent C++20 improvements (Phabricator + Commit). Thanks to Jonathan Poelen for the patch!

Language Server Protocol (LSP) would help, too, but my initial work is far from usable, help appreciated. Beside a hacked “goto definition” nothing works at the moment (and it is hardcoded to just start clangd, no other LSP server).

First week of GSOC, Piece Table Implement

Monday 10th of June 2019 03:00:00 PM

Hi! Last week was start of the GSOC coding period. So I started my project. Also I opened my code on the KDE git.

If you are interested in my project feel free to look and give me some advices.

Parser using Spirit::x3

First, I started to make the markdown parser using the Boost Spirit X3.

Spirit makes easy to express grammar using the PEG. But it’s templet based library so it was hard to find out which part is wrong. Also documentation of spirit was limited.

So I had a lots of trial and error to get compilable source code.

this two slides was really helpful for me.

Markdown AST Structure

if we type markdown document like this

# hello > > 1. - **sadf** - > > > > sadf > > asdf

we will get result like this.

Markdown document’s can be splited in each lines. line is the smallest unit of the markdown document. Also line can be expressed attributes, string, emphasizes.

  • attributes : Line’s attribute that change the block style. There are two types of attribute.
  • Single Attribute : # header. Style applied only once.
  • Multiple Attributes : > BlockQuote, Lists. Sytle applied recursively.
  • String : Content of the document. It contains only string.
  • Emphasize : Bold, Cancleline, Underline… It contains index of string to be emphasized

All line can be parsed in parallel on multiple threads. Because each line is independent from other lines. After parsing seperatly it can be reassembled after parsing phase.

So we can express this grammar with the Spirit grammar like this

auto const Line_def= Header[pushFunc] >> String[setContent] | (MultipleAttribute)* >> EmphasizeString[getEmphStr]; Piece Table

I had a hard time to implementing the Emphasize String.

All String Emphasize token should be paired. If tokens not paired it should be inserted in original points

**this is paired example** **This token -> -- is not paired**

Like this exampled -- should be inserted in middle of the string as the normal character.

We can simply using insert method but it has performance issue.

If there is a original string length N and another string length M to be inserted in position P.

First split the original string at position P and shift the splited string as mush as M.

Then put the string length M in position P. It takes almost O(N).

If there are alot of non-paired tokens, It will consume more time.

So I found the VSCode team’s article about reimplementing text buffer using the Piece Table.

The main idea of the Piece Table is seperate the original buffer and added buffer.

And split the strings in a small pieces containing position to insert and the string length.

Make a table about how to make new string using each pieces.

So I applied this structure in appending non-paired emphasize tokens.

const auto EmphasizeString_def = +(omit[Emphasize[setEmp]] | Content[setEmpText]);

In my grammar definition, it do not check the pairness of Emphasize token.

Basically Emphasize token are temporary stored in Emphasize Stack to check pairness.

First If there is token can be paired, add token in Emphasize vector and clean the non-paired tokens.

Or there are not tokens can be paired just push the token in the Emphasize Stack and push token’s string value in the buffer vector.

Strings are also added in the buffer vector and inserted in the Piece Map.

Piece Map works same as Piece table but effective on find the piece on some position.

Piece Map is multimap that use Piece’s index and Piece as key value.

So we can iterate whole pieces and make new string with non-paired tokens.

namespace AST { struct Piece { int start = 0, len = 0; int bufIdx = 0; }; struct Emphasize { int start = 0, end = 0, bufIdx = 0; EmphasizeType empType = EmphasizeType::DEFAULT; }; using PieceMap = std::multimap<int, Piece>; using PieceMapIter = PieceMap::iterator; class EmphasizeString { private: int currPos = 0, addedTokenLen = 0; std::vector<std::string> buffer; std::vector<Emphasize> empSt, emps; PieceMap pieceMap; private: int clearNonComplete(std::vector<Emphasize>::iterator ); public: EmphasizeString(); void addEmphToken(EmphasizeType empt); void appendText(const std::string& text); std::string getString(); const std::vector<Emphasize> &getEmphasizes() const; }; };

You can check my whole code on KDE git.

After first week

I think it was good starting for me. But this week and next week is my final exam in the school.

So me and my mentors Eike and SungJae planned to refactor the code and make view of markdown.

They also mentioned adding the licensing policy and following the KDE’s codding convention.

Thank you for reading my article and I’ll write next article after my final finish.

KDE ISO Image Writer – Revamping the UI

Monday 10th of June 2019 10:14:54 AM

As part of GSoC 2019, I am working on KDE ISO Image Writer which is a tool to write ISO images to USB flash drives.

The main goals that I set for this GSoC are:

  • Rework the user interface (following this design).
  • Improve and extend the ISO verification mechanism.
  • Thoroughly test the software to identify bugs.
  • Package the application for Linux, Windows and macOS.
First Attempt at Revamping the UI

When I first looked at the design, I thought I would rewrite the UI in the shape of a wizard using QWizard.

The application would have three main screens that would guide the user through the process of writing an ISO image into a USB flash drive:

  • Select an ISO image
  • Select a USB flash drive
  • Write to USB flash drive

I made the following sketches to illustrate my idea for the user interface:

Select ISO image Select USB flash drive Write to USB flash drive

I started implementing this idea using Qt’s QWizard with the idea of having a QWizardPage for each of the above screens:

KDE ISO Image Writer using QWizard The Way Forward

I had a discussion with my mentor Jonathan Riddell and Nate Graham who is part of the KDE VDG about my plans on the user interface. They provided valuable comments about my approach. It was then clear to me that a wizard is not suitable for this use case and we agreed on the way forward, which is to implement the initial design.

More in Tux Machines

today's howtos

All Linux, all the time: Supercomputers Top 500

Starting at the top, two IBM-built supercomputers, Summit and Sierra, at the Department of Energy's Oak Ridge National Laboratory (ORNL) in Tennessee and Lawrence Livermore National Laboratory in California, respectively to the bottom -- a Lenovo Xeon-powered box in China -- all of them run Linux. Linux supports more hardware architectures than any other operating system. In supercomputers, it supports both clusters, such as Summit and Sierra, the most common architecture, and Massively Parallel Processing (MPP), which is used by the number three computer Sunway TaihuLight. When it comes to high-performance computing (HPC), Intel dominates the TOP500 by providing processing power to 95.6% of all systems included on the list. That said, IBM's POWER powers the fastest supercomputers. One supercomputer works its high-speed magic with Arm processors: Sandia Labs' Astra, an HPE design, which uses over 130-thousand Cavium ThunderX2 cores. And, what do all these processors run? Linux, of course. . 133 systems of the Top 500 supercomputers are using either accelerator or co-processor setups. Of these most are using Nvidia GPUs. And, once more, it's Linux conducting the hardware in a symphony of speed. Read more

Red Hat and SUSE Leftovers

  • Are DevOps certifications valuable? 10 pros and cons
  • Kubernetes 1.15: Enabling the Workloads
    The last mile for any enterprise IT system is the application. In order to enable those applications to function properly, an entire ecosystem of services, APIs, databases and edge servers must exist. As Carl Sagan once said, “If you wish to make an apple pie from scratch, you must first invent the universe.” To create that IT universe, however, we must have control over its elements. In the Kubernetes universe, the individual solar systems and planets are now Operators, and the fundamental laws of that universe have solidified to the point where civilizations can grow and take root. Discarding the metaphor, we can see this in the introduction of Object Count Quota Support For Custom Resources. In English, this enables administrators to count and limit the number of Kubernetes resources across the broader ecosystem in a given cluster. This means services like Knative, Istio, and even Operators like the CrunchyData PostgreSQL Operator, the MongoDB Operator or the Redis Operator can be controlled via quota using the same mechanisms that standard Kubernetes resources have enjoyed for many releases. That’s great for developers, who can now be limited by certain expectations. It would not benefit the cluster for a bad bit of code to create 30 new PostgreSQL clusters because someone forgot to add a “;” at the end of a line. Call them “guardrails” that protect against unbounded object growth in your etcd database.
  • Red Hat named HPE’s Partner of the Year at HPE Discover 2019
    For more than 19 years, Red Hat has collaborated with HPE to develop, deliver and support trusted solutions that can create value and fuel transformation for customers. Our work together has grown over these nearly two decades and our solutions now include Linux, containers and telecommunications technologies, to name just a few. As a testament to our collaboration, HPE has named Red Hat the Technology Partner of the Year 2019 for Hybrid Cloud Solutions.
  • Demystifying Containers – Part II: Container Runtimes
    This series of blog posts and corresponding talks aims to provide you with a pragmatic view on containers from a historic perspective. Together we will discover modern cloud architectures layer by layer, which means we will start at the Linux Kernel level and end up at writing our own secure cloud native applications. Simple examples paired with the historic background will guide you from the beginning with a minimal Linux environment up to crafting secure containers, which fit perfectly into todays’ and futures’ orchestration world. In the end it should be much easier to understand how features within the Linux kernel, container tools, runtimes, software defined networks and orchestration software like Kubernetes are designed and how they work under the hood.
  • Edge > Core > Cloud: Transform the Way You Want
    For more than 25 years, SUSE has been very successful in delivering enterprise-grade Linux to our customers. And as IT infrastructure has shifted and evolved, so have we. For instance, we enabled and supported the move to software-defined data centers as virtualization and containerization technologies became more prevalent and data growth demanded a new approach.
  • SUSE OpenStack Cloud Technology Preview Takes Flight
    We are pleased to announce that as of today we are making a technology preview of a containerized version of SUSE OpenStack Cloud available that will demonstrate a future direction for our product. The lifecycle management for this technology preview is based on an upstream OpenStack project called Airship, which SUSE has been using and contributing to for some time. This follows our open / open policy of upstream first and community involvement.

NSA Back Doors in Windows Causing Chaos While Media is Obsessing Over DoS Linux Bug

  • U.S. Government Announces Critical Warning For Microsoft Windows Users
    The United States Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA) has gone public with a warning to Microsoft Windows users regarding a critical security vulnerability. By issuing the "update now" warning, CISA has joined the likes of Microsoft itself and the National Security Agency (NSA) in warning Windows users of the danger from the BlueKeep vulnerability. This latest warning, and many would argue the one with most gravitas, comes hot on the heels of Yaniv Balmas, the global head of cyber research at security vendor Check Point, telling me in an interview for SC Magazine UK that "it's now a race against the clock by cyber criminals which makes this vulnerability a ticking cyber bomb." Balmas also predicted that it will only be "a matter of weeks" before attackers started exploiting BlueKeep. The CISA alert appears to confirm this, stating that it has, "coordinated with external stakeholders and determined that Windows 2000 is vulnerable to BlueKeep." That it can confirm a remote code execution on Windows 2000 might not sound too frightening, this is an old operating system after all, it would be unwise to classify this as an exercise in fear, uncertainty and doubt. Until now, the exploits that have been developed, at least those seen in operation, did nothing more than crash the computer. Achieving remote code execution brings the specter of the BlueKeep worm into view as it brings control of infected machines to the attacker.
  • Netflix uncovers SACK Panic vuln that can bork Linux-based systems