Planet KDE

Syndicate content
Planet KDE -
Updated: 1 day 3 hours ago

Q&A with the board of KDE e.V. at Akademy

Sat, 2014-08-30 16:13

Only a few days left until Akademy. I’m looking forward to meeting old friends again and making new ones. There are many exciting talks in the program that I want to see. Have a look!

The board is going to do a Q&A session on Saturday afternoon. We want to give more people a chance to ask questions than just the ones attending Akademy. I started a wiki page to collect them and we’ll try to answer as many as we can.

Categories: FLOSS Project Planets

Understanding Icons: Participate in survey ’7 of 9′ (or more)

Sat, 2014-08-30 15:09

With this next icon test we take a look at the Elementary icon set. Please, again, participate and help us to learn more about the usability of icon design.

Keep on reading: Understanding Icons: Participate in survey ’7 of 9′ (or more)

Categories: FLOSS Project Planets

UX @ Akademy 2014

Fri, 2014-08-29 18:46

We are going to Akademy 2014.

Keep on reading: UX @ Akademy 2014

Categories: FLOSS Project Planets

Lazy declarative programming in C++11

Fri, 2014-08-29 18:05
KDE Project:

make does it, Haskell does it, spreadsheets do it, QML can do it and below I explain how to do it with C++11: declarative programming. And not just any declarative programming, but my favorite kind: lazy evaluation.

I have written a few C++ classes that wrap imperative C and C++ functions into functional expressions. A simple example illustrates the difference between the common imperative programming and declarative programming.

/** * This is our business logic. */ int sum(int a, int b) { return a + b; } /** * In the imperative example, c and d are just storage locations for the results. */ void imperative() { int a = 3; int b = 4; auto c = sum(a, b); auto d = sum(a, c); // correct std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; a = 4; // error: c and d have not been updated std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; } /** * In the lazy example, c and d are defined by the function sum() * and the actual values of c and d are determined when these variables * are accessed. Any C or C++ function can be used, but the outcome * should depend only on the input values. */ void lazy() { InputValue<int> a = 3; InputValue<int> b = 4; auto c = makeLazy(sum, a, b); auto d = makeLazy(sum, a, c); std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; a = 4; std::cout << a << " + " << b << " = " << c << std::endl; std::cout << a << " + " << c << " = " << d << std::endl; }

The function makeLazy() which turns imperative functions to functional use, relies on a new feature in C++: variadic templates. Variadic templates give C++ great flexibility in the use of functions in templates. The example above shows that the functions can be chained.
The biggest advantage of this style of programming is that the programmer does not have to worry about whether the results are up to date. Programming like this feels like writing a spreadsheet: you give the logic and the computer takes care of how and when to get the result. It is nice to see that clean lazy functional programming can be done in C++ too.

Categories: FLOSS Project Planets

scaling the UI by screen DPI

Fri, 2014-08-29 10:03
tl;dr version
  • default DPI settings are usually wrong under
  • thankfully, they can be easily configured
  • KScreen ought to manage that configuration along with the other screen information
  • EDID is right often enough to allow autoconfiguration when paired with user configuration
  • fonts are not an accurate surrogate for DPI
The longer version ...(Before we get into this topic, I should note that I wrote on this same topic almost exactly one month ago. In retrospect, I realized that that blog entry was really not clear enough, so I'm going to give it one more try ...)

The Plasma team decided that for Plasma 5 they would scale the user interface in relation to the size of the font being used in the UI.  The goal is to have the UI look nicely proportional and remain usable across screens with different DPI. Why fonts, and not simply use the DPI of the screen?

The developers note that the information that comes from device hardware which holds that information (the EDID block) is sometimes incorrect and so you get bad data from the device. They also point to the output of QScreen in Qt5 and note that it gives wrong values in default configurations and assert that the least-worst solution is to just use font sizes to scale against.
Font size is actually just a DPI surrogateThe reason font sizes "work" for scaling the UI is that the user typically configures the fonts to something "reasonable" for the screen. So one can generally assume, or so the theory goes, that the font size is a good indicator of screen DPI. (We'll see later why this isn't so, but let's accept this assertion for now.)
The easiest way to get your fonts to a readable size on a high-DPI screen is to go into the fonts control panel define the DPI directly.
This way you don't have to tweak any of the actual font settings. (Well, except in a handful of applications with broken font handling, which tend not to be KDE applications.) When you plug into a lower DPI screen (e.g. a project, beamer or TV) you then change the one DPI setting to match the screen's actual DPI and everything is back to normal size. Yes, this means changing it over and over again and knowing what the DPI of your screens are.

The alternative is to change each font size in every application, and that just doesn't make much sense. Not only is it a lot more effort, mostly because far too many applications have their own custom font settings, but when a new screen with a different DPI is used you have repeat the whole lengthy process all over again. It's much more sensible to just hit that DPI setting.

So when managed in this fashion, font size is really responding to a DPI setting. This means that font size is just a surrogate for the DPI setting. In fact, QScreen reports this value quite correctly as the logical DPI. In fact, I use that API in one project I am working on to scale a window to a physical size (i.e. in mm) on the screen, and it works very reliably.

So QScreen does work when fonts are set using the DPI setting, and in that case the font size is just a surrogate for DPI. So why not use the DPI directly to determine the scaling factor?
An old enemy: default settingsQScreen reporting what the DPI setting is makes sense, but it assumes things are sanely configured. On my "high-DPI" laptop with the default configuration as shipped in openSUSE, even though the EDID block on the built-in screen is absolutely correct, defaults to a typical low-resolution DPI by default The monitor-edid tool, which is a hundred or so lines of perl, manages to accurately report the DPI as 277 using the EDID information. So the machine is reporting correctly, but doesn't seem to be using that information. That's pretty odd, isn't it?
Fortunately there is a tool in Plasma's arsenal that automatically manages screen settings: KScreen. It remembers user settings and tries to guess as best it can what a sensible default setup should be. It would be pretty easy to extend KScreen to use the EDID information to take a reasonable guess at a sensible scaling factor for the screen, just as it tries to figure out a sensible default resolution and position for a new monitor.
So while default settings tend to render QScreen useless, a little work in KScreen could fix that.Perfect is the enemy of goodOf course, some screens misreport the necessary information in their EDID block. Some devices are just broken, and some devices, such as projectors/beamers simply can not present this information. Consider: what is the physical size of the screen of a projector/beamer? Depends on how far from the surface (e.g. a wall or projector screen) it is.
It is these "bad DPI information" cases that are cited as a reason not to even try to use EDID information. Forget that the majority of devices actually do report this information correctly, it's those devices that get it wrong that wreck it for everyone! Right? Wrong. This is a case of perfect being the enemy of good.
In many of the "wrong information" cases it is possible to detect that this is the case because the results make no sense. The trusty monitor-edid tool manages to do this. In such situations, defaulting to no scaling and assuming it is just a lowly old low-resolution display, at least by default, would be enough.
If KScreen does guess it wrong, what can be done? Well, the same thing that is done when it guesses the resolution wrong, or guesses where you want the screen to be placed wrong ... the user configures it and KScreen remembers it for the next time. Yes, this is not a perfect situation, but it would be far better than the current recommendation of going to the fonts panel every time you plug into a different monitor and manually adjust that setting.
In other words, it's already pretty bad. By trying to use EDID based information it will only get better in most cases and when it isn't any better it's only as bad as it is now. Having KScreen oversee the DPI setting would be an improvement even if fonts continued to be used as a scaling metric, since at the very worst configuration would be a one-time thing and at best it wouldn't be necessary at all. In fact, for every single screen in the house right now (televisions, laptops, desktop LCDs, tablets...) it would Just Work(tm) and no configuration would be necessary.So why not fonts if they are a surrogate for DPI?If fonts are a surrogate for DPI, then why not just use them? Because in reality they are not a surrogate for DPI. They are only an approximation for DPI in the common case
For people with various sight related disabilities, cranking up the font size often helps quite a bit. For these people, the size of the font has very little to do with the DPI of the screen.
Additionally, when I'm viewing content on the TV screen from across the room, I like the fonts to be unreasonably large given the DPI of the screen. Again, in this case the font size is completely divorced from the screen DPI.
In both of these cases, if one scales the UI to the font size, you end up with cartoonishly poor UI sizing. Having giant window shadows or excessive margin padding is entirely inappropriate in many of these cases.
So if one can get to the DPI of the screen to guess a default, and allow the user to quickly and easily tweak that behavior when needed, then using the DPI directly will deliver better results in more cases.In hopes for a better Plasma Desktop experience ...I finally got around to installing a full Plasma Desktop 5 environment on a test system  this past week. Truthfully, it is not ready to be my default desktop, but it shows promise. It did remind me of the scaling-to-fonts situation, though, as I keep running into DPI related annoyances. I re-read my posting from last month and realized I really wasn't clear enough. Meanwhile, commits that keep pushing this scale-to-font-size idea into more and more places in Plasma (such as a new branch in plasma-framework just today that fiddles with icon sizes) which doesn't really address the situation properly at all. So I thought I would take one more run at it. Hopefully someone will pick up the task and this will be one less thing that Microsoft Windows and MacOS X does better than Plasma Desktop.
Categories: FLOSS Project Planets

Scripting GDB to execute commands at particular breakpoints

Fri, 2014-08-29 08:02

This might be old news for the more experienced programmers out there, but yes, we can script GDB to do $stuff whenever it hits a breakpoint. With GDB's logging to file feature this can be super handy when trying to get a backlog of backtraces whenever a certain event arises.

Example use-case

Let's consider the following problem we'd like to debug: In KDevelop (Frameworks branch) we always got this annoying warning from Qt when exiting the application:

Output: QMutex: destroying locked mutex

Now, we can easily find out by grepping the Qt code base that this message is printed in qmutex.cpp:201 (which is inside ~QMutex). So, in order to figure out who's calling the destructor of QMutex and causing this output, let's put a breakpoint on qmutex.cpp:201 and re-run KDevelop and try to close it.

(gdb) break qmutex.cpp:201 Breakpoint 1 at 0x7ffff58f04bf: file /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp, line 201.

This leads to the following backtrace:

Breakpoint 1, QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 201 qWarning("QMutex: destroying locked mutex"); #0 QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 #1 0x00007ffff51638aa in __cxa_finalize (d=0x7ffff3428b78) at cxa_finalize.c:56 #2 0x00007ffff33f1573 in __do_global_dtors_aux () from /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/ #3 0x00007fffffffd830 in ?? () #4 0x00007ffff7dea73a in _dl_fini () at dl-fini.c:252

Unfortunately, the QMutex is destroyed during static deinitialization (notice the __do_global_dtors_aux call in the backtrace). Now, due to backtrace, we still don't know which QMutex in our code base got destroyed while being locked. We see that it is being statically initialized and must come out of, but nothing more.

Problem: How do we find out which QMutex this was? Well, we need to check where this particular QMutex was first constructed.

GDB scripting to the rescue

I'd now like to print a backtrace each time we encounter the QMutex constructor (thus, QMutex::QMutex)

(gdb) break QMutex::QMutex Breakpoint 2 at 0x7ffff58f040e: file /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp, line 178.

Additionally, I want to print a backtrace each time the breakpoint is encountered:

(gdb) command 2 Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >backtrace 10 >continue >end

The command function makes GDB do the following each time it hits breakpoint 2: Print a backtrace limited to 10 frames and continue. (You can put whatever you need inside the command/end block.)

Furthermore, I'd like to get this logged to a file:

(gdb) set logging file gdb.txt (gdb) set logging on Copying output to gdb.txt. (gdb) set pagination off

Now, let's restart KDevelop and close it again

(gdb) run

We'll again hit the breakpoint when printing the QMutex warning when static deinitialization happens:

Breakpoint 1, QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 201 qWarning("QMutex: destroying locked mutex"); #0 QMutex::~QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, __in_chrg=) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:201 #1 0x00007ffff51638aa in __cxa_finalize (d=0x7ffff3428b78) at cxa_finalize.c:56 #2 0x00007ffff33f1573 in __do_global_dtors_aux () from /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/ #3 0x00007fffffffd830 in ?? () #4 0x00007ffff7dea73a in _dl_fini () at dl-fini.c:252

Duly note the this pointer of the QMutex destroyed from the backtrace (QMutex::~QMutex (this=0x7ffff3428ba0 ...): It's 0x7ffff3428ba0

Note that in gdb.txt we now have the following contents (some parts replaced by ... for increased readability):

(...) Breakpoint 2, QMutex::QMutex (this=0x7ffff7dd8b78 <(anonymous namespace)::resInit+24>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff7dd8b78 <(anonymous namespace)::resInit+24>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff7be0e29 in (anonymous namespace)::ResInitUsage::ResInitUsage (this=0x7ffff7dd8b60 <(anonymous namespace)::resInit>) at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolvermanager.cpp:166 #2 0x00007ffff7be2067 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolvermanager.cpp:237 #3 0x00007ffff7be2096 in _GLOBAL__sub_I_k3resolvermanager.cpp(void) () at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolvermanager.cpp:815 #4 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #5 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #6 _dl_init (...) at dl-init.c:126 #7 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ #8 0x0000000000000003 in ?? () #9 0x00007fffffffde39 in ?? () Breakpoint 2, QMutex::QMutex (this=0x7ffff7dd8b98 , mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff7dd8b98 , mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff7be68fe in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolverstandardworkers.cpp:97 #2 0x00007ffff7be6956 in _GLOBAL__sub_I_k3resolverstandardworkers.cpp(void) () at /home/krf/devel/src/kf5/frameworks/kdelibs4support/src/kdecore/k3resolverstandardworkers.cpp:1049 #3 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #4 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #5 _dl_init (...) at dl-init.c:126 #6 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ #7 0x0000000000000003 in ?? () #8 0x00007fffffffde39 in ?? () #9 0x00007fffffffde62 in ?? () Breakpoint 2, QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff33f23ba in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:29 #2 0x00007ffff33f24ab in _GLOBAL__sub_I_foregroundlock.cpp(void) () at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:235 #3 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #4 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #5 _dl_init (...) at dl-init.c:126 #6 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ #7 0x0000000000000003 in ?? () #8 0x00007fffffffde39 in ?? () #9 0x00007fffffffde62 in ?? () (...a lot more...)

Every time QMutex::QMutex was encountered, GDB printed a backtrace and logged it to the file.

Now, in order to find out where the QMutex comes from we simply search the string 0x7ffff3428ba0 inside gdb.txt and we'll find:

Breakpoint 2, QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 178 QMutex::QMutex(RecursionMode mode) #0 QMutex::QMutex (this=0x7ffff3428ba0 <(anonymous namespace)::internalMutex>, mode=QMutex::NonRecursive) at /home/krf/devel/src/qt5/qtbase/src/corelib/thread/qmutex.cpp:178 #1 0x00007ffff33f23ba in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:29 #2 0x00007ffff33f24ab in _GLOBAL__sub_I_foregroundlock.cpp(void) () at /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:235 #3 0x00007ffff7dea13a in call_init (...) at dl-init.c:78 #4 0x00007ffff7dea223 in call_init (...) at dl-init.c:36 #5 _dl_init (...) at dl-init.c:126 #6 0x00007ffff7ddb30a in _dl_start_user () from /lib64/

Frame 2 shows: This mutex comes from /home/krf/devel/src/kf5/extragear/kdevelop/kdevplatform/util/foregroundlock.cpp:29, which says QMutex internalMutex;

We've found it!

At this point we can finally start solving our original problem of the destruction of a locked mutex, because now we at least know which mutex is causing this.

Other use-cases Tracing ref-counting issues

You know that some object (for example QCoreApplication in Qt5) has a refcount higher than zero when exiting the application, but you don't know which object is still keeping a reference on it.

How to debug: Print backtraces each time we call the hypothetical ref() and deref() (for example QCoreApplication::{de}ref()). Now simply check which object never calls deref() in the GDB output file.


GDB's scripting capabilities can be tremendously useful when attempting to debug issues where the backtrace at the point of crash or some other event just isn't enough.

This helped me to fix several issues in KDevelop already, which would have been hard to tackle otherwise.

Also see:

Categories: FLOSS Project Planets

Kubuntu on LinkedIn

Fri, 2014-08-29 05:43

We can sit in our own nerdy world in open source communities too much so at Kubuntu we have been setting up social media forums and we have just added a LinkedIn page for Kubuntu which should get the usual news stories of new releases and updates.  There is also a Kubuntu Users group on LinkedIn if you want to share experiences with people who like to take more of a business approach to their computers than users of other social media websites.

14.10 Beta 1 is out, you can give us feedback on Google + or Facebook or Twitter or Linkedin

Categories: FLOSS Project Planets

Intermediate results of the icon tests: Tango

Fri, 2014-08-29 05:37

With a series of icon tests we currently study effects on the usability of icon design. This article however does not focus on these general design effects but presents findings specific to the Tango icon set.

Keep on reading: Intermediate results of the icon tests: Tango

Categories: FLOSS Project Planets

Kubuntu 14.10 Beta 1, Adds Plasma 5 Preview Option

Thu, 2014-08-28 17:10

Kubuntu 14.10 beta 1 is out now for testing by early adopters. This release comes with the stable Plasma 4 we know and love. It also adds another flavour - Kubuntu Plasma 5 Tech Preview.

Categories: FLOSS Project Planets

Visual Design Stuff at Akademy 2014

Thu, 2014-08-28 14:10

For planet readers, this post is written by Andrew Lake.

I'm so excited to participate in my first Akademy this year! I'll finally get to meet other KDE folks I've only interacted with online from all the way in Seattle, my home. I'm especially looking forward to meeting some of our other VDGers like Thomas Pfeiffer and Jens Reuterberg.

I'll also be doing a session on Community Design and the KDE Visual Design Group where I'll share some insights on how the concept of community design works in the VDG, how we hope it will help to sustain visual design as a core competency in the KDE community, how to ensure the quality of the design output, and the lessons we are learning along the way. If you've ever interacted with the VDG, good or bad, or if you're just wondering how the VDG is working today or will in the future, you're certainly encouraged to stop by.

I'll also be hosting a workshop on Visual Design and QML where we'll cover using QML as a visual design tool by working through an example design. No previous QML experience is required - just a willingness to learn something new.

If you need any help or feedback with a design, you can find VDG folks in the User Interface Design Room identified on the BoF schedule.

I'm truly looking forward to this. My Czech is non-existent but I'm trying to learn a few phrases. My German is barely-existent but I'm trying to learn as well. So if you see this guy

or these guys
in the middle of a heated argument with Brno taxi driver, know two things:

  1. I probably insulted his dear mother without realizing it, and
  2. For goodness sake, help a brother out!
Looking forward to Akademy 2014!
Categories: FLOSS Project Planets

LaKademy 2014

Thu, 2014-08-28 11:31

Hi again,

I am a bit absent from blogging due to personal issues. Fortunately, I am on vacation from my real life work since last weekend then I am going to have more time for one of the things a like most: working with KDE software and friends :-)

As you may know the Latin-american KDE meeting (LaKademy) is happening right now in São Paulo city, more precisely at Free Software Competence Center of IME-USP [1] and I here too. After a long time I am back to São Paulo city for more time than just taking connection flights hehe.

Yesterday was the first LaKademy's day and we had some presentations for the general public. During this second day Sandro Andrade is presenting his Qt programming course. In the next two days we will have hacking sessions on KDE software and as Plasma Network Management maintainer I am interested in making networking easy for KDE users.

Although I have not been pushing that much commits to network management repos [2] I used to do years ago I am still working on some improvements for the new Plasma NM, mostly non-visual changes though. Jan Grulich, Björn and Thomas Pfeiffer are doing a great job on Plasma NM's GUI so this task is in good hands.

My yesterday's LaKademy presentation was about what I am doing in Plasma NM and NetworkManager for that matter. Basically I am working on improving Eduroam support in Plasma NM with these two tasks:

  1. Passing more error information to the user so he/she can know if the problem is with his/her login, password, certificates, or with the local or the remote infra-structure, etc. With this information in hand the user can contact the correct person to solve connection issues, being the local network administrator or the network administrator of his/her university, who with Eduroam may not be the same person.
  2. Importing configuration file to make creating Edurom connections easier. Eduroam uses WPA2 Enterprise and as such its connections requires several technical details to be filled before you can use it. Check this connection dialog for my test Eduroam connection for instance, too many details:

The aim for task #2 is importing a xml file that contains all the information above, well, except the password, of course. There is already configuration importing support for OpenVPN and VPNC connections in Plasma NM, so this will be the third connection type that Plasma NM will suport that. This implementation may be used for other WPA2 Enterprise connections as well.
To implement task #1 I have been digging into wpa_supplicant and NetworkManager souce code in the last months (during my spare time). I already have a patch that gets the data from wpa_supplicant and now I am implementing code to set up the correct structures in NetworkManager. The code is generic and the result can be used by other NetworkManager clients as well, of course. When the patch is ready I am going to send it to NetworkManager's developers for reviewing.

[1] USP stands for University of São Paulo, the biggest and one of the most important Brazilian universities.

[2] there are networking code in plasma-nm, libmm-qt, libnm-qt, kdelibs, and kde-runtime repos and also in (the already deprecated) networkmanagement repo.
Categories: FLOSS Project Planets

Understanding Icons: Participate in 6th survey ‘Take a breeze’

Thu, 2014-08-28 04:35

Our next icon test features the Breeze icon set, that might (or will?) become the default KDE icon set. Please, again, participate and help us to learn more about the usability of icon design.

Keep on reading: Understanding Icons: Participate in 6th survey ‘Take a breeze’

Categories: FLOSS Project Planets

The KDE Randa 2014 meeting, in easy-digestible video format!

Thu, 2014-08-28 04:00

In case you were wondering what was going on in Randa, here are some first hand impressions. The video was produced by Françoise Wybrecht (alias Morgane Marquis) and Lucie Robin, and the people in it are the actual participants of the event. It was also created using KDenlive, one of the awesome Free Software tools a team has been working on at the Randa meeting itself. The video introduces the faces and personalities of the contributors and their different backgrounds and origins. Many thanks to our brand new ad-hoc media team for producing this video!

(In case the embedded video does not show up, see here:

Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt Tagged: Creative Destruction, FLOSS, free software communities, KDE
Categories: FLOSS Project Planets

New class in kcoreaddons: Kdelibs4ConfigMigrator

Thu, 2014-08-28 01:50

Config files are stored now in .config5, so we need to migrate it.

I created a new class (committed in kcoreaddons) named Kdelibs4ConfigMigrator. I allows to migrate all config files and all ui file for a specific application (for example I have 4 uirc files to migrate in kmail) and 2 config file to migrate in kmail (kmail2rc + kmail2.notifierc)

This class is very easy to use:

Example for sieveeditor:

int main(int argc, char **argv)
Kdelibs4ConfigMigrator migrate(QLatin1String(“sieveeditor”));
migrate.setConfigFiles(QStringList() << QLatin1String(“sieveeditorrc”));
migrate.setUiFiles(QStringList() << QLatin1String(“sieveeditorui.rc”));


I put it directly before to start application.

I will look at if we need to migrate and start after that the application.

Thinking to use it in your application when you port your application to kf5.

Categories: FLOSS Project Planets

What’s new in porting script ?

Thu, 2014-08-28 01:44

I committed another very old script.

This script allows to remove all not necessary includes. It’s not perfect yet but it allows to clean up a lot of files.

Yes indeed it’s not a clang script but it was created for 4.0 and perl/shell was a good idea for me.

What’s new in script:

I added a new script “” which try to convert all KLocal::Global::formatDate/formatTime/formatDateTime etc.

Another one “” I improve convert kfiledialog class to QFileDialog

During this week I still improve, I improve search local variable, I fixed a lot of bug etc.

So I continue my work on script for kf5.

Categories: FLOSS Project Planets

KDevelop master is now frameworkified

Wed, 2014-08-27 19:25

Hello all!

Kevin just announced it on the mailing list, the CI is still shaking it’s head, and we are all very curious about the coming weeks: KDevelop’s master branches are now depending on KF5!

For more information, see:…

Cheers, happy hacking and hope to see some more patches :)

Categories: FLOSS Project Planets

GSoC: Thumping the Malaria and voyaging in cosmos with KStars

Wed, 2014-08-27 16:02
KDE is taking new shape now a days, porting most of its application to KF5. Meanwhile I completed my GSoC project in KStars, ameliorating it by enhancing the tools like Moon Phase Calendar, Almanac and Solar System Viewer and adding a super cool QML based tool Astrophotograph Browser. 

It all started with preparing proposal, I was using KStars since more than one year and had fixed many minor bugs already. I prepared first draft of proposal for GSoC in January (yeah I was super excited ;-) and mailed it into mailing list of KStars. I was not sure if anyone would bother to look into it, but kde developers are awesome people, I received many interesting comments on it and Rafal Kulaga in particular. I started refining my proposal under his guidance, and prepared seventh and final draft of proposal in February. It proved to be best decision to prepare proposal month before the deadline of submission as I was diagnosed with Malaria, just week before the submission deadline. 

Let's talk about my project now. KStars is desktop planetarium application under KDE Education Projects. I developed QML based cool interface to enable users to browse through image database of community of astrophotographers (i.e. which contains more than 1,20,000 (number is increasing everyday) real time and very high resolution images along with various information related to them (i.e. Date on which image was captured, Bortle Dark-Sky Scale, RA Centre, DEC Centre, Telescope or Camera used, Description added by astrophotographer etc). I am sure that this browser will enthrall school children by showing them real time images of stars and galaxies located at hundreds of light year far from earth.

I also developed image editor to enable user to mark sky objects and and write their name or other details on image to make it more intuitive before saving it.

The Moon Phase Calender tool was revamped by replacing early less accurate moon phase images with more accurate ones, adding lunar phase name in window title bar and adding the option to choose between Northern hemisphere and Southern hemisphere.
Yet another interesting feature was added to Almanac tool just after the mid term evaluation i.e. Live Weather Info tool. This tool uses Open Weather API to fetch the weather information like temperature, humidity, pressure, wind speed, wind direction, cloud density, precipitation etc, for the selected location. The tool is developed for amateur astronomers to help them in planning the sky observations.

The time for accomplishing most exciting task was to come with Randa Meeting 2014 and Malaria attacked me again. I spent almost a week in hospital, planning for Randa meeting in bad. My strong desire to return to project helped me a lot to recover quickly. After recovery I accomplished the task of refurbishing the Solar System Viewer tool in Randa Meeting with the help of Artikulate developers Andreas Cord-Landwehr. The tool earlier gave the 2D view of solar system for particular date. I added option to visualize asteroids based on magnitude selection in the first stage. Then added the distance measurement feature to measure the distance (in km and AU) between any two solar bodies. This feature makes KStars unique tool for measuring distance between planets and asteroids.

In all, I enjoyed a lot working on this project. Let me thank my coolest friend Punit Mehta for motivating me to apply for GSoC. I'd also thank Rishabh Arora for enlightening me about possible ideas to work upon in GSoC at, organised in my institute and of which I was one of the co-ordinator. My best thanks is to Rafal Kulaga for his continuous motivation, support and appreciation at  my every little advancement in project. One of the best thing about Rafal is he always replies to my mail like a friend rather than a mentor. And not to forget, Thanks KDE Community.
Categories: FLOSS Project Planets

Plasma Active Ported to KF5

Wed, 2014-08-27 11:40

The GSoC might have come to an end, but I am very happy with the progress that we have made porting the Plasma Active to KF5. In my previous blogposts i have describe some of the stuff which they have been ported. So at the moment a lot of the basic features have come back to the  Plasma Active, so yes it is at a usable state :) One of the big changes is that Nepomuk has been replaced with Baloo.  Despite the fact that a lot of the Nepomuk stuff has been ported, there are still some things left,  for example the timeline and tag support on the active-filebrowser.

Plasma Active on Action!

Unfortunately  my exam period is starting soon so I will not be able  to work more on Plasma Active for the time being. But I will be back when it will be over, which is in the end of September.

You can find us on irc on the #plasma channel on

Categories: FLOSS Project Planets

Akademy 2014: What I Plan To See

Wed, 2014-08-27 08:35

So… …and here’s the talks I’m most looking forward to! Day 0: Friday, September 5 OK, so the day before Akademy is set aside for the AGM of KDE eV. “The eV” is the organisation that orchestrates the logistics of the KDE community: finances, legal shizzle, marketing etc. It is an organisation whose membership is a very diverse set of… Read more →

Categories: FLOSS Project Planets

Intermediate results of the icon tests: Nitrux

Wed, 2014-08-27 08:13

With a series of icon tests we currently study effects on the usability of icon design. This article however does not focus on these general design effects but presents findings specific to the Nitrux icon set.

Keep on reading: Intermediate results of the icon tests: Nitrux

Categories: FLOSS Project Planets