18 Sep 2014

feedPlanet KDE

Mathematics that you can touch

These last months have been intense, so intense I needed a bit of a distraction. I've always felt some kind of curiosity for the world of 3D printing and, as I've said in different occasions, I always push KAlgebra to the limit when I have the occasion.

I had been researching, I've never had a 3D printer and I probably won't have one in years, but I still wanted to figure out how to get do something there. First, I went through many 3D printing services and looked through the different supported formats. To be honest, I implemented the one that looked the simplest, it happened to work quite similar to how OpenGL works internally, so it seemed like a safe bet.

Once I had a working export algorithm, I chose an extremely good looking plot (thanks Percy ;-)) and then I uploaded it over to one of those 3D printing services. The website showed me a preview, it seemed like their software understood the format, so it looked like my job was done. I fiddled with it to get it printed in a reasonable size and submitted it to print and send. For the curious, here's the formula I used:

piecewise { x^2+y^2+z^2<35 ? 2-(cos(x+(1+5^0.5)/2*y)+cos(x-(1+5^0.5)/2*y)+cos(y+(1+5^0.5)/2*z)+cos(y-(1+5^0.5)/2*z)+cos(z-(1+5^0.5)/2*x)+cos(z+(1+5^0.5)/2*x)), ? 1 } = 0

A couple of weeks later a box arrived to our office. To be honest, it was a bit weird. I was very excited, but then nobody else was when I showed it. Because it's math I guess, and it's boring. I felt a bit like when I used to spend my nights hacking KAlgebra around then show it around. Anyway, I'll say it. A 3D plot, in my hands, to play with them. How cool is that? :D

** crickets **

Now I'm sure you're excited and willing to try it. It will be available in the next version of KAlgebra, that will be released in the KDE Applications 2014.12, which by the way will be the first KAlgebra release based on Qt5 and KF5, and will be featuring many other new features.
And of course, it's free software developed in an open community! If you're feeling adventurous or you just know how to build KDE software, feel free to pull analitza and kalgebra repositories and give it a try! :)

18 Sep 2014 12:47am GMT

16 Sep 2014

feedPlanet KDE

digiKam Software Collection 4.3.0 released...


Dear digiKam fans and users,

The digiKam Team is proud to announce the release of digiKam Software Collection 4.3.0. This release includes some new features:

read more

16 Sep 2014 9:43pm GMT

Reprise of Akademy 2014: KCM for network manager

Based on a BoF workshop and discussions during the Akademy 2014, we present a proposal for discussion how to integrate the network manager settings into KDE's system setting.

Keep on reading: Reprise of Akademy 2014: KCM for network manager

16 Sep 2014 7:22pm GMT

Sitting on the Shoulders of Giants

I could write a whole series of blog posts about my Akademy 2014 experience, but

  1. I'm not motivated to do that
  2. You might get bored half-way through

Therefore I'll try to summarize some of my impressions (and provide insight into the "rusty trombone conspiracy").

The Talks

First of all, the talks: The two keynotes were both awesome!

Sascha Meinrath told us about the strong connection between Free Software and political activism in the opening keynote, and how crucial our work in Free Software is for a future where citizens are still free instead of constantly being watched and manipulated by companies and governments. I found it very inspiring, because its political implications are one of the major factors that draw me to Free Software.

Cornelius Schumacher's community keynote taught us how we all benefit from our involvement with KDE and why he and other long-time KDE contributors are doing what they're doing. It's always great to hear the stories of "the elders". It's a bit like grampa telling stories from WWII. ;)

Of course there were countless other great talks, too (see also the summary of day 1 and day 2 on the Dot, and the program for video recordings and slides).

The Story Behind the Rusty Trombone

Those of you who have attended Akademy or watched the talks by Àlex Fiestas, Björn Balazs or Jens Reuterberg and myself may have wondered why a certain term came up in each of them: rusty trombone. This sounds innocuous at first, but a quick trip to your ever-helpful Urban Dictionary will reveal that, while "harmless", it isn't a term you should utter at a dinner party if there is a chance someone at the table might know what you are referring to.

So how did this term enter our talks? Well, it happened as follows: On Thursday morning, yours truly boarded a train in Langen, suspecting nothing. I had read about a group of Akademy attendees organizing a trip from Berlin to Brno that day, but since my connection did not go via Berlin itself, I thought I'd have nothing to do with them. Therefore I was - of course pleasantly - surprised when I saw Mirko Boehm and Patrick Spendrin at Dresden train station. I then learned that there were quite a few more fellow KDEians on that train, among them Paul Adams. Paul always has an odd story or two to tell, one of those was about a contest which was once held to find a combination of two words which, when entered into Google, would only yield Urban Dictionary or pages linking to it as the top results. One of those was "rustry trombone". None of the other people in the cabin new what it meant (or at least pretended not to know), so Paul explained it to us, in a vivid-enough way.

Fast forward to Saturday night. We had planned to have dinner together with everyone from the visual design and usability groups (namely Andrew Lake and his husband, conveniently also named Andrew, Jens, Björn, Heiko Tietze and myself), and Àlex decided to join us, too. When I told the others about my trip to Brno, the "rusty trombone" story came up, too. Nobody had heard the term yet (or at least pretended not to have heard it) and of course they wanted to know what it meant. I found just telling them to be too easy, so instead we turned it into a quiz. It took the group quite a while to find out what rusty trombone means, and of course the most fun part were the ideas people came up with what it could be.

After the mystery was solved, someone from the group had the idea that since most of us were giving a talk the next day, we all should try to incorporate "rusty trombone" into it. Andrew chickened opted out because - as his husband confirmed - he would not be able to continue his talk afterwards with even the least amount of seriousness. All the rest promised that all our talks would contain the magic words at least once.

I don't want to spoil the fun for you by telling you how we (or actually everyone but myself, because I thought that having Jens mention it in our combined talk would be enough, to Björn's utter disappointment) managed to integrate "rusty trombone" in our talks. Just watch the talks (linked above) and look and listen carefully. Àlex, Björn and Jens really mastered the art of injecting the words into their talks in a way that people who didn't know what they meant (there were fewer and fewer of those with each of our talks, of course) probably wouldn't have noticed anything suspicious.

Tales from the User Interface Design Room

For Monday and Tuesday, we had booked a room specifically for user interface design topics. The idea was that anyone could come to us to get input on their user interfaces from visual and interaction designers.

Three people used that opportunity: Jan Grulich for the Network Management System Settings module, Michael Bohlender for his email client which we now codenamed "NextMail", and Friedrich Kossebau for "Workspace-wide services on non-file objects". All three design sessions were very productive. In all of them, we aimed at striking the best balanced between "as simple as possible" and "as complex as necessary", which isn't easy when dealing with complex matters such as setting up a VPN or dealing with multiple email accounts each with a complex folder hierarchy or with mailing lists vs. regular email conversations, or with a theoretically unlimited number of services which can be offered for dealing with any object (such as an address in a text, or an image in a PDF). More details about the results of these sessions will surely pop up somewhere on Planet KDE over the next weeks.

Another very interesting session was "Human-Centered Design for the KDE HIG": In that session, we applied one of the standard methods in human-centered design, the usability test, to the KDE Human Interface Guidelines. We had two developers (Frederik Gladhorn and Kai Uwe Broulik) test the HIG as its users. They could choose a task for which they would consult the HIG and then try to complete it live, while the HIG team observed them and then discussed with them why they got lost at a given point and which information they could not find. Friedrich Kossebau offered additional input.

The results from this are very helpful for optimizing the usability and usefulness of the HIG for developers. Some of the findings were that our users would prefer visual examples for first orientation, and text only for details which cannot be well communicated visually, that the structure of the main page should be optimized, and that more cross-linking between related articles would be helpful.

Community from the Perspective of a Temporarily Walking-Disabled Member

One of the most memorable experiences from this year's Akademy has to do with an injury I suffered there. At some point during my travel to Brno, I got a small graze at the back of my right foot. Nothing serious, I thought, so I didn't pay much attention to it. Unfortunately, some germs must have entered the blood stream through that graze, causing a serious inflammation. The foot got more and more swollen and walking started to hurt. It got better with each night, but worse during the days. On Sunday evening, I decided to stay in the hotel and visit a doctor the next morning. When I told Dan Vrátil about my inflamed foot the next morning, he had to laugh at first, because the exact same thing happened to Jan Grulich during last year's Akademy. Last time, Jan had to be taken to the hospital and elsewhere by car, now he was the one driving me around.

At the hospital, the foot got bandaged and I was told not to walk. Not the ideal condition for a conference. This is where I experienced first-hand the helpfulness of our wonderful community. Whenever someone from KDE was near, I was supported while hopping about, and Àlex even carried my through the venue like like a bride over the door sill. We also found that office chairs can be repurposed as makeshift wheelchairs (including the fun of pushing someone around on one, of course).

The most difficult part, though, was the day trip to the water reservoir on Wednesday. Originally, I had thought I'd stay at the hostel during the day trip because I couldn't even get to the reservoir without walking too much and Jan was not available to drive me there.

When asking on the mailing list whether it was possible to get there without much walking, I got two replies from people willing to give me a ride (Martin Klapetek and Teo Mrnjavac). In the end, it was Martin who took me to the reservoir (and also to the tram station the next morning). I was happy that I could take part in the day trip and take the ferry together with the group, but I had already accepted that I wouldn't be able to get up to the castle we were visiting (castles are not exactly known for being easy to reach, right?).

When the ferry landed and I said I'd wait there for the group to return from the castle, Frederik Gladhorn said something along the lines of "No, we won't leave you behind, we can get you there!". I couldn't really imagine how, until I found myself first on Frederik and Martin's arms, then on Friedrich Kossebau's and then Frederik's shoulders. There are some KDE members which, due to their compact size, might be relatively easy to carry on one's shoulders. At about 1,85m in height, though, I'm not exactly one of those, so it must have looked really funny when a fully grown man sat on another's shoulders. I'll add a photo as soon as I get one. The foot is now better, though it will take a few more days of rest and antibiotics to fully heal.

This was an example of what KDE means to me (and surely many others): We always help each other out, and even if something seems impossible, together we find ways to make it happen.

Thank you all for making Akademy 2014 such a wonderful experience!

Filed under: KDE

16 Sep 2014 3:00pm GMT

Back from Akademy 2014

So last week-end I came back from Akademy 2014, it was a loooong road, but really worth it of course!
Great to meet so much nice people, old friends and new ones. Lots of interesting discussions.

I won't tell again everything that happened as it's been already well covered in the dot and several blog posts on planet.kde, with lots of great photos in this gallery.

On my part, I'm especially happy to have met Jens Reuterberg and other people from the new Visual Design Group. We could discuss about the tools we have and how we could try to improve/resurrect Karbon and Krita vector tools.. And share ideas about some redesign like for the network manager…

Then another important point was the BoF we had with all other french people, about our local communication on the web and about planning for Akademy-Fr that will be co-hosted again with Le Capitole du Libre in Toulouse in November.

Thanks again to everyone who helped organize it, and to KDE e.V. for the travel support that allowed me to be there.

PS: And Thanks a lot Adriaan for the story, that was very fun.. Héhé sure I'll think about drawing it, when I'll have time.. ;)

16 Sep 2014 10:04am GMT

Just Arrived

GSoC 2014 completion certificate

16 Sep 2014 9:36am GMT

15 Sep 2014

feedPlanet KDE

KDE Telepathy 0.9-beta

We have released a beta of KDE Telepathy 0.9, and libkpeople 0.3.0

Features include:

Tarballs are available here and here.

If you're interested in developing and contributing follow our quick start git installation guide

Please report back any bugs so we can make 0.9.0 a great release.

15 Sep 2014 8:49pm GMT

What's coming to Green Island: part 1

I want to share with you some of the progress I recently made.
This is not all, more will come in another post.

Multi output support: part 1

Green Island now supports multiple outputs.

QtCompositor only support one output so in order to do this I did a little abstraction to enumarate outputs and played with QML to show them in the compositor window.

How does it work?

It's pretty simple: it has a ScreenModel that provides data such as name, primary boolean flag and geometry. The main QML file has a repeater using this model to create an OutputView for each output.

Every OutputView has layers to stack different kind of windows (panels, lock screen, workspaces), one of the layers is HotCorners which contains 8 hot corners.

During test and development one often need to fake outputs to test several different configurations without having real monitors, but this requires a dedicated backend and a configuration format.

So ScreenModel has its own backend code, one of the backends is based on QScreen and the other is for fake outputs.

Studying the problem and doing some prototype made me realize that QScreen has a very limited API (for example it doesn't detect when the primary output changes) and that this matter was already implemented with libkscreen.

It happens to be a framework that doesn't pull in undesired dependencies, so now Green Island is using it and I have to say it saved me a lot of work.

In the video below you can see a Green Island window with two 1024x768 outputs side by side, at some point the first one (which is also primary) is removed and all the windows are migrated to the other output that is now the new primary output.

Multi output support: part 2

A single big fat window for all the outputs is not such a great idea, it was good enough to continue the development keeping multiple outputs in mind but it's not the solution in the long run.

Such a solution may hit hardware limits pretty, plus outputs can have a different refresh rate so they really should not be done this way.

QtCompositor handles only one window so I patched it to be aware of multiple outputs with one window for each of them.
The patch targets the dev branch and at the time of this writing is in the review queue.

All the QML code was reused except for the Repeater and the logic to move windows when an output goes away was moved to C++.
This means that almost none of the code previously wrote was removed.

The hard part came when I needed to figure out how to show the same surface on multiple output windows.

Considering that QQuickItems cannot be shared between multiple windows I had to create a view for each output.

When a shell surface is created for a surface, the compositor creates a view that inherits from QQuickItem, the output is assigned based on the mouse pointer coordinates. No other view is created at this time because the position is calculated to be within output bounds considering the surface size.

More views are created on demand when the surface is mapped.

As windows are moved all views are moved accordingly, global coordinates are mapped to the output coordinates so that windows are shown only where they are meant to be.

Unresponsive applications

Wayland offers a ping/pong API that compositors use to know whether a surface is responsive or not, even with CSD (in the past there was some concern about this).

When a window is clicked, Green Island ping the surface and if it doesn't reply with a pong within 200ms it marks it as unresponsive and apply a colorize effect, draw some explanatory text, and intercepts mouse input. It also adds a couple of push buttons, one to wait for the application to become available again and the other to brutally murder the application.

15 Sep 2014 5:28pm GMT

Snippets in Kate 5

Recently I spent some time to port and clean up the Snippets plugin and the underlying template interface for Kate 5. It's now fully working again and more powerful than ever. The template code was originally written by Joseph Wenniger and most of what I show here is still working like originally implemented by him. Still, there were some improvements I would like to show; also, I'm sure many readers might not be aware of this great feature at all.

Classical snippets use case: insert a for loop witout having to type the iterator variable three times.

The template interface, which is part of the long-time stable KTextEditor API, was heavily cleaned up and now just consists of a single function

    bool insertTemplate(const KTextEditor::Cursor& insertPosition,
const QString& templateString,
const QString& script = QString());

which inserts a template into a view at the given position. It's very easy to use and still powerful -- if you write an application which uses KTextEditor, it might be worth to spend a moment thinking about how you might be able to make use of it.
I also heavily refactored the implementation of the interface. More than 1000 lines of code were removed while effectively enhancing functionality.

Core functionality changes

I changed the language of the snippets a bit to make it more clear and easy to use. In the following, I want to give a short overview of how it works now.

The heart of the templates (or snippets) are editable fields (shown in green). They are created in the template string by writing ${fieldname}. They can have a default value, which can be any JavaScript expression. Pressing Tab jumps between the fields of a template. Whenever such a field is changed, all so-called dependent fields are updated. Those can simply be mirror fields (created by having a second field with the same name), or can do something which depends on the contents of the other fields in the template, such as perform replacements or concatenations. Again, you can have arbitrary JavaScript expressions doing that.

An example snippet (not very useful in practice) which has three editable fields (find, replace and sample_text) with a default value for each. Changing the values will update the result in the red "dependent" field in real-time.

Noticeable improvements over the previous functionality (from KDE 4 times) is that you can have fields with arbitrarily complicated default values which are still editable, and that the dependent fields can use all other fields as input (not just one like in KDE 4). It is now also possible to have inline JavaScript doing simple operations in the template.

The Shortcuts feature for the snippets now actually works in Kate.

Snippets now also have proper undo; in KDE 4, only a single character typed could be undone at once while editing a snippet. Now, undo grouping works like it always does.

User interface improvements

For easy testing of your snippets, the "Edit Snippet" dialog has a "Test snippet" button now, which lets you test your snippet on-the-fly.
The user interface was simplified by removing unneeded options, and an inline quick-help feature was added which introduces the user to the most important features of the snippet language. Just click the "More" button.

Inline documentation on how snippets work

An example: C++ Header guards

As an example for how this feature works, let's look at how to create a snippet to generate a C++ header guard. First, create a repository for your C++ snippets:

Open the Snippets toolview and click "Add Repository".

Then, enter a name and specify that you want this only for C++ files:

Create your new repository.

Then, add a snippet:

Add a snippet. Easy.

You can retrieve the document's file name from the editor, make it upper-case and replace dots by underscores automatically to get a nice header-guard-suitable format by using code like this:

Example code for how you can create C++ header guards fully automatically.

If you do not want the guard field to be editable, just create a function which does the upper(fileName...) stuff, and have three fields which call the function (like ${func()}) instead of the two mirror fields and one default-valued editable field. If you do that, the template handler will immediately exit and not present any editable fields.
The ${cursor} variable can be used to place the cursor after all fields were filled. When you type something there, the handler will exit.

Click Ok. Now, to use your snippet, either press the shortcut you defined (if any), click it in the snippets toolview, or use code completion:

Snippets appear in code completion.
Result after executing our new header guard script. A sensible default value was selected automatically. Pressing Escape or Alt+Enter will exit the template handler and place the cursor at the point marked with ${cursor} in the template.

That should hopefully equip you with most of the knowledge you need to write your own snippets. If you like, you can use the full kate scripting API to write snippet code -- it for example allows you to retrieve the text in the current selection and similar useful things.

Some more examples on what you can do

Here's a few snippets demonstrating the features of the engine while partly being of debatable practical relevance. I'm sure you can come up with better use cases for some of those things though.

Write a clean regular expression in a comment and have the snippet mirror it with added extra-backslashes and removed spaces in a QRegularExpression variable. Makes regular expressions even more write-only than they already are.
Get the file encoding from the editor and use it as the coding of a python file header.

Some base64 in the selection ...

... decoded by a snippet which takes the selection and inserts the base64-decoded result.

Next steps

My next step will be to make this plugin loadable in KDevelop as well -- which should be quite easily possible due to the awesome work done in kate to make the plugin infrastructure more generic. If you have further ideas on how to improve the snippets, let me know :)

15 Sep 2014 12:49am GMT

14 Sep 2014

feedPlanet KDE

Takeaway from Akademy

[[ Way back in 2008 or so, at Akademy in Mechelen, most attendees stayed in a hostel with 4 bunks to a room, which meant that after a long day hacking we ended up talking. It may have been Kevin who first asked "Ade, tell us a story." This year, in 2014, at my first Akademy in four years, I received the same request. I've written down the story that I told this year. It was invented on the tram in Brno between Česká and Technologiky Park at 23:20 on the 9th of September 2014. When I got home I illustrated it. Text and illustrations licensed under CC-BY. If Timothéé feels like drawing it up better, by all means. This is a work of fiction. Any resemblance to people or rabbits, living or dead, is purely coincidental or a weak attempt at humor. ]]

The tale of Glenda the Plan 9 Rabbit

Once upon a time, Glenda the Plan 9 Rabbit was hopping through the forest. She was very happy, because she was free and hopping through the forest. The sun was shining and the birds were singing in the trees. Glenda was free because she had escaped from Bell Labs with a BSD license. That's not quite as good as a license to kill, but you hardly need one of those as a member of the lagomorphidae, do you? Glenda hopped amongst the trees and she hopped through the bushes and she was very happy. There was a forest path and she ignored the crossing lights and just hopped straight to the other side. She nibbled some grass and hopped onwards, through the trees, under the bushes and over the grass.

But then, suddenly, Glenda was stuck! She could not move her hoppy feet. She looked down, and there was a big black pool of tar. She tried to pick up her front left foot, but the tar was stuck to that. She tried to pick up her right front foot, but the tar was stuck to that too. Struggle as she might, her feet would not let go. Her left back foot sunk a little deeper into the tar. And then, with a glurpy sound, the tar made a great big tentacle that reached up and swayed in the crisp morning air. Glenda could still hear the birds singing as the tentacle squeezed her. With growing dread, Glenda realized that she would soon be stuck in a compressed tar archive. "That's it!" thought Glenda, and she pulled out the "j" she still had left over from jay-walking that morning. But it was BSD tar, and it doesn't understand the "j" option. Desperate now, Glenda the narcoleptic Plan 9 Rabbit (this is actually a useful power saving feature in all modern kernels) quickly fell asleep and with the help of those "z"s extracted herself from the terrible tar archive. She cleaned her feet on some chestnut leaves and hopped on through the forest. She hopped through the trees and under the bushes and over the grass. The sun was shining and the birds were still twittering. Glenda hopped over the grass again.

But suddenly, MROWR! A cat(1) ran out from the bushes towards her, with great terrible pointed teeth and sharp claws and Glenda jumped a foot in the air and turned and ran and ran and ran away from the cat(1) until she reached the edge of the sea and she ran across the beach and jumped into the water! Splash! The cat(1) could not get at her now, and it stayed on dry land, hissing and spitting. She swam and swam and there was a big red sailboat out on the sea. She swam until she got close and climbed up the ladder and there was a big man with a broad smile.

It was Larry O'Liason, the Irish gourmand who had grown fat by eating all the animals in the sea. "Welcome to my boat, O'Coral. An Irish name of the sea, I'm sure you'll see. Be welcome! Have something to eat!" And Glenda was very happy. There were no birds singing here, but gulls that screeched, and there was no grass to hop on, only 108 feet of teak from bow to stern. Still, Glenda was happy on board the O'Coral, and happier still because Larry gave her succulent grass to eat, and fresh crisp carrots. Soon Glenda was gaining weight, perhaps even becoming a little bloated. Her features, once sleek like a healthy forest rabbit, grew puffy. And Larry, she noticed, was watching her. Watching, while he sharpened a knife. But still she got her crispy carrots and succulent grass, and she hopped less on the teak deck. Until one day, Larry, with a grim smile, said "tonight, I dine on water-rabbit! I've not had that before."

And he pulled out his knife and gave out a cry and jumped at Glenda who shot a foot in the air and turned and ran and ran across the slippery teak deck and she ran to the bow and she ran back to the stern and she could hear Larry laughing behind her and he was gaining and she ran back to the bow and Larry was still gaining when THUMP! Another ship hove alongside! It was a crusty old galleon, and it had hoisted the black flag. The skull and crossbones! Larry gripped his knife between his teeth and turned to face this adversary. At the bow of the galleon stood a man with a long tangled beard and a wild look in his eyes. He held a scimitar in one hand and cried "O ho ho ho! I, Richard Boatsman, have come to thwart your terrible deeds, Larry O'Liason! And the railing rang as he leaped across and his scimitar was shining in the sun. It didn't flash, though Richard did gnash his teeth. He bore down on Larry and the terrified Glenda, who regarded him with great big bunny brown eyes full of awe and relief. Richard faced the opposite captain, glanced at Glenda, and said "oh, hang on, you're BSD licensed, aren't you. Well, carry on then." He turned and sailed off in his boat and Larry had Glenda for dinner and lived happily ever after.


14 Sep 2014 6:48am GMT

13 Sep 2014

feedPlanet KDE

Akademy 2014: Aiming higher

I am back from Akademy and this edition was particularly interesting in my opinion. Somehow it looks like there was a common theme hidden in this conference... let's go through what I consider the most noticeable events of Akademy 2014.

Even before the official start of the conference, during the KDE e.V. general assembly we had something interesting happening. We had elections for three out of five positions in the board. During the questions to the candidates (thanks all for stepping up!), it was clear that the membership was looking for people aiming at a higher efficiency and then improved KDE e.V. organization. We will see if our new board will live up to those expectations. It sounds like a new cycle of radical improvements will start after a (needed) period of consolidation and stabilization.

Then, the first keynote by Sascha Meinrath was an excellent reminder that we should be more proactive on the political landscape. If we stay in reactive mode just producing software, we won't be able to prevent centralized infrastructure, opaque Internet of Things and the panoptic surveillance system. Only by aiming at a higher political involvement can we avoid the raise of a digital feudalism age.

After this keynote, during the three days of talks and workshops, a surprising amount of sessions were focused on quality in a form or another. I was obviously guilty there with my craftsmanship cycle but Albert too. Add to those the talks from the VDG, the workshop on profiling by Milian and the one on unit tests by Shantanu to easily figure out that there's quite a few people wishing to see our contributors aiming at higher quality.

Last but not least, Paul's talk on community metrics was likely the most important one to attend this year. If you didn't attend it: go and watch the video now! I'll wait... This talk is really a wake up call in my opinion. We lost something and we need to get it back. He pointed out a silent crisis going on in the community. We still have time to get back on the right track, but we got to find the root causes and act as soon as possible. What Paul proposes is to aim at a higher cohesion in the community again. That will require a better shared technical vision, a stronger focus on our mission toward our users and a stronger focus on getting better in our contributions.

By now it is clear that the common theme of Akademy 2014 was that we ought to generally aim higher. Overall, we are in a good position today. Unfortunately, that is also a very fragile one as the community metrics and the quality related talks highlighted.

We're likely at the crossroads now. The decisions we'll take in the coming weeks and months will lead us either to regress or to strive. In my opinion, we can only strive by improving in the areas mentioned above. In some way, that is very good news! We are mostly in control of those areas to improve. It means that success is reachable if we have enough collective willpower to do what's required to seize it.

13 Sep 2014 10:13pm GMT

KDevelop 4.7.0 Released

Hello all!

It's my pleasure to finally announce the availability of KDevelop 4.7.0:


This is a special release, as it marks the end of the KDE 4 era for us in terms of feature development. We will continue to support this release in the long-term with bug fixes though. New things and fundamental changes will only happen in the frameworkified master branches from now an.

Many thanks to all contributors!


13 Sep 2014 6:50pm GMT

Kate and KTextEditor 5 after Akademy 2014

The yearly KDE conference Akademy just ended, so it's time to look at what changed in the holy Kate in the Frameworks 5 land.

KTextEditor Framework

Kate Application

Kate Document Switcher

A big thanks to the organizers of this year's Akademy, and a big thanks to all our sponsors and supporting members. The location was amazing and the venue allowed us all to have a very productive week! Looking forward to next year! :-)

13 Sep 2014 11:15am GMT

12 Sep 2014

feedPlanet KDE

profiling is not understanding

When software goes slow, generally, the first reaction is to profile. This might be done through system tools (like Instruments on OS X, perf/valgrind/etc on Linux, VTune, etc). This is fine and good, but just because you have the output of a tool does not necessarily correlate to understanding what is going on.

This might seem like an obvious distinction, but all too often, efforts at improving performance focus on the small picture ("this thing here is slow") and not the bigger picture ("why is this so slow"). At Jolla, I had the pleasure of running into one such instance of this, together with Gunnar Sletta, my esteemed colleague, and friend.

As those of you who are familiar with Jolla may know, we had been working on upgrading to a newer Qt release. This also involved quite a bit of work for us, both in properly upstreaming work we had done on the hurry to the late-2013 release, and in isolating problems and fixing them properly in newer code (the new scenegraph renderer, and the v4 javascript engine in particular have been an interesting ride to get both at once!).

As a part of this work, we noted that touch handling was quite slow (something which we had worked around for our initial release, but now wanted to solve properly). This was due to the touch driver on the Jolla introducing touchpoints faster than the display was updating, that is, while the display might be updating at 57 hz (yes, the Jolla is weird, it doesn't do 60 hz) - we might be getting input events a lot more frequently than that.

This was, in turn, causing QtQuick to run touch processing (involving costly item traversals, as well as the actual processing of touch handling) a lot more frequently than the display was updating. As these took so much time, this in turn slowed rendering down, meaning even more touch handling was going on per frame. A really ugly situation.

Figure 1: Event tracing inside the Sailfish OS Compositor

Figure 1 demonstrates this happening at the compositor level. The bottom slice (titled "QThread") is the event delivery thread, responsible for reading events from evdev The peaks there are - naturally - when events are being read in. The top thread is the GUI thread, and the high peaks there are touch events being processed and delivered to the right QtQuick item (in this case, a Wayland client, we'll get to that later). The middle slice is the compositor's scenegraph rendering (using QtQuick).

With the explanation out of the way, let's look at the details a bit more. It's obvious that the event thread is regularly delivering events at around-but-not-quite twice the display update. Our frame preparation on the GUI thread looks good, despite the too-frequent occurrence of event delivery, though, and the render thread is coping too.

But this isn't a major surprise - the compositor in this case is dead simple (just showing a fullscreen client). What about the client? Let's take a look at it over the same timeframe...

Figure 2: Event tracing for the client (Silica's component gallery, in this case)

Figure 2 focuses on two threads in the client: the render thread (top), and the GUI thread (bottom). Touch events are delivered on the GUI thread, QtQuick processes them there while preparing the next frame for the render thread.

Here, it's very clear that touch processing is happening way too often, and worse than that, it's taking a very long time (each touch event's processing is taking ~4ms), not leaving much time for rendering - and this was on a completely unloaded device. In a more complicated client still, this impact would be much, much worse, leading to frame skipping (which we saw, on some other applications).

Going back to my original introduction here, if we had used traditional profiling techniques, we'd have seen that touch handling/preparation to render was taking a really long time. And we might have focused on optimizing that. Instead, thanks to some out-of-the-box thinking, we looked at the overall structure of application flow, and were able to see the real problem: doing extra work that wasn't necessary.

As an aside to this, I'm happy to announce that we worked out a neat solution to this: QtQuick now doesn't immediately process touch events, instead, choosing to wait until it is about to prepare the next frame for display - as well as "compressing" them to only deal with the minimal number of sensible touch updates per frame. This should have no real impact on any hardware where touch delivery was occurring at a sensible rate, but for any hardware where touch was previously delivering too fast, this will no longer be a problem as of Qt 5.4.

(Thanks to Gunnar & myself for the fix, Carsten & Mikko for opening my eyes about performance tooling, and Jolla for sponsoring this work.

P.S. If you're looking for performance experts, Qt/QML/etc expertise or all round awesome, Gunnar and myself are currently interested in hearing from you.)

12 Sep 2014 6:06pm GMT

My Family…

… is the best in the whole wide world!

12 Sep 2014 3:33pm GMT

On normal people using linux, part 3 – Annia Zacchi

Another friend approached me to get rid of Windows, the problem was vulnerabilities and virus. She was an artist for life and paint, so I explained to her that Adobe no more and she didn't really feel moved by that so I tougth "hm… this can work out".

So, I got archl inux[1] installed on her computer, explained her a bit of the stuff and told her "anything you need, just ask.", strangelly, nothing she asked for one month, and since I had moved from jobs to another state, I tougth that she had come back to the windows-side of the force. "Hey annya?", "Hey", "How are things up there with linux?", "Well, it's great actually. I'm using windows only to play LoL", "oh, cool, I tougth you hade come back to windows because you never asked me anything, actually", "No, that wiki that you pointed me out is really good. so I started reading it a lot, and krita, OH GOD. that program is amazing."

I was shocked. Literally shocked. I know that linux is not that easy for newcommers, and I'v installed linux for a lot of newcomers, but this was the first newcommer that didn't had trouble using it because SHE HAS READ THE WIKIS AND TRIED TO LEARN. What if everybody could do that, this could go soooo beautiully.

"And you didn't had any problems?", "Well, my tablet doesn't work with the system libraries, so I went to the website, got the drivers source, compiled and blacklisted the system ones, so nothing anymore." whow. WHOW.

I really wanted that all my users were like her. This is also a plus, what krita can do if you are a good artist, drawings by Annia Zacchi

annia-krita tauriel-krita tribute-to-kiev

Usually I write more, but my broken feet is hurting so much that I can't think straigth. :)

12 Sep 2014 3:27pm GMT