Planet KDE

Syndicate content
Planet KDE -
Updated: 35 min 31 sec ago

Interview with Baukje Jagersma

57 min 27 sec ago

Could you tell us something about yourself?

Hey! My name Is Baukje Jagersma, I’m 22 years old and live in the Netherlands. I studied game design and recently started doing freelance, to try and make a living out of something I enjoy doing!

Do you paint professionally, as a hobby artist, or both?

Both: I’ve always enjoyed creating my own stories and worlds with drawing and recently started doing freelance work as well.

What genre(s) do you work in?

Most if not all of my work has something to do with fantasy. To me that’s the best part of drawing, you can create things that don’t exist and make them look believable. Besides that I mostly work as an illustrator and concept artist.

Whose work inspires you most — who are your role models as an artist?

There are a lot of sources where I get inspiration from, art in games for example, movies or art sites.

A few artists that are really worth mentioning would be Grzegorz Rutkowski, Ruan Jia and Piotr Jablonski.

How and when did you get to try digital painting for the first time?

Probably when I first discovered Deviantart. I was already familiar with GIMP, which I used to create photo-manipulations with. But seeing all the amazingly talented artists on there made me want to try out digital painting for myself.

What makes you choose digital over traditional painting?

I feel like traditional has more limitations and can get messy. In digital you can easily pick any color you like, or undo something that doesn’t work. For me it just works a lot faster.

How did you find out about Krita?

Somewhere around 2013-2014 when an artist posted his Krita art on a GIMP forum.

What was your first impression?

I really didn’t know where to start, haha! There were just so many more options than I was used to in GIMP, especially with all the individual brush engines. It really took me a while to get comfortable with the program.

What do you love about Krita?

Now I’ve just grown to love the multiple brush engines! The wrap-around mode, animation tool, brush smoothing options, symmetry options, assistant tool and the different layer and mask options are probably the key features that I love about it. It’s a program that just has so much to offer which makes it a lot of fun to explore with!

What do you think needs improvement in Krita? Is there anything that really annoys you?

Probably the only thing that really bugs me is the text tool, which seems to have a few weird issues right now. I’d also love to see the possibility to import and use vector layers and an alternative to the pattern brush option to make it work less repetitive (something similar to Photoshop’s dual brush perhaps).

What sets Krita apart from the other tools that you use?

Kinda mentioned it earlier already, it has a lot to offer which makes it fun to explore with! Besides that it’s available to everyone and works just as well as any other ‘professional’ digital painting program.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

Probably one of my few non-illustrative works. I really wanted to try out the animation tool so I decided to try out a run cycle. I had little knowledge of animating beforehand- but I like how the animation and design turned out in the end.

What techniques and brushes did you use in it?

I made a few different style concepts beforehand, where I chose a design from and later on used as a reference. I first made a sketch version of the animation which I then refined and colored. I actually made a little video about it which I posted on youtube.

Where can people see more of your work?


Anything else you’d like to share?

I’d like to thank the Krita team for developing this amazing program and making it available to everyone! I’m very excited to see how Krita will further develop in the future!

Categories: FLOSS Project Planets

This week in Usability and Productivity, part 2

Sat, 2018-01-20 12:39

This is your weekly status update for the KDE community’s progress in the Usability and Productivity initiative. KDE contributors have been busy, and here’s a sampling of features, improvements, and bugfixes relevant to the initiative that KDE developers landed over the past week-and-a-half (subsequent reports will be weekly, but I wrote the first one in the middle of a week):

  • KIO file copy speed (e.g. in Dolphin) is now 4.5x faster (KDE bug 384561)
  • Fixed a layout glitch in Open & Save file picker dialogs (KDE bug 352776)
  • KMail gained the ability to badge its Task Manager app icon with the count of unread emails (KDE Phabricator revision D9841)
  • Notification badges on Task Manager app icons now show up in Task Manager tooltips, too (KDE Phabricator revision D9825) and look better for huge numbers (KDE Phabricator revision D9827):
  • The Audio Volume widget now looks good with Dark themes (KDE bug 388766)
  • KSysGuard’s CPU column now has a pretty little CPU use graph in the background for each process (KDE Phabricator revision D9689):
  • Every KDE app’s “Settings > Configure [app]” menu item now has a universally consistent keyboard shortcut: Ctrl+Shift+Comma (KDE Phabricator revision D8296)
  • The PDF thumbnailer is able to generate thumbnails in Dolphin for more types of PDFs (KDE bug 388288)
  • Dates are no longer formatted like numbers (i.e. as “2,018”) in some places in Dolphin (KDE Phabricator revision D9887)
  • The menu you get when right-clicking on KAddressBook’s icon now includes a “New Contact…” item (KDE Phabricator revision D9926)
  • Dolphin’s main view now properly regains focus after you close the inline terminal pane (KDE bug 298467)
  • Window titlebar buttons now show tooltips (KDE bug 383040)
  • Plasma’s notifications no longer leak memory when created (KDE bug 389132)
  • Baloo indexer now actually excludes directories that are marked as excluded from indexing (KDE bug 362226)
  • A whole class of app crashes caused by typing or deleting characters in search fields using Qt QML components (such as in Discover and System Settings) was traced to a Qt bug–and KDE developer Aleix Pol has submitted a patch!

There’s also been a ton of work in Discover, particularly in Snap and Flatpak support. You can read about it here.

If any of this seems cool or useful, consider helping us out by becoming a KDE contributor yourself. If donating time isn’t your cup of tea, we always appreciate donations of money, too. We can’t do this without your support!

Categories: FLOSS Project Planets

Fun (?) with symbol visibility...

Fri, 2018-01-19 16:13
KDE Project:

In the last days I had to deal with loading plugins via dlopen.
I learned so far already a lot about symbols on Linux.

I expected, that if I have an executable, and load a plugin into it, that the stuff inside the executable (i.e. object files and static libraries) won't be used to resolve missing symbols in the plugin.
But that's wrong, by default, all symbols are visible, and so all the symbols in your executable are visible to a plugin.
I didn't find the relevant blogs or mailing list entries from the KDE devs, back in the KDE2 days when all the plugin-infrastructure was added to kdelibs. But also others had to find out:

So, even if your executable links a library as static, its symbols are visible to plugins.
This can be fixed by setting the visibility to hidden, which can be done either using -fvisibility=hidden or the visibility-attribute.

One more thing I didn't expect, is that even if no shared library is involved, the symbols, i.e. code in your executable is still visible to a plugin. Assume your plugin defines a class with the same name and the same method name, i.e. the same symbol.
You create an instance of that class in your plugin and call some function from it.
I didn't expect that at runtime the plugin might call code from the executable instead of the class just built into the plugin (i.e. not being pulled in from a shared lib).
Again, making symbols hidden helps, in general.
Here's something related:

Today I once ended up in a state where all the correct functions from the plugin were called, e.g. the correct ctor, but later on, when a virtual function of that object was called, it was the virtual function from the executable and not from the plugin. Weird. How could that happen ?

I added a little project in github for playing around with such stuff:

My conclusion so far is that in general you probably always want to build executables and static libraries with visibility=hidden. Not sure why this is not the default...

Categories: FLOSS Project Planets

Linux and Qt in Automotive? Let’s meet up!

Fri, 2018-01-19 03:36

For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly ;-)

If you want to come, please register here.

Categories: FLOSS Project Planets

What about AppImage?

Fri, 2018-01-19 00:40

I see a lot of people asking about state of AppImage support in Discover.

It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager

This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.

It’s the same model. For 20 years, there was no centralized Mac App Store because this distribution model doesn’t require it. Apple did eventually create one, but it’s a shadow of the iOS version, and a lot of popular Mac developers never got on board, continuing to distribute software themselves and update it in the way they choose (often with Sparkle).

When a format’s primary advantage is decentralization and independence, you don’t need a centralized piece of software like Discover do manage it. Of course, it would be nice to be able to have a centralized location to browse AppImage vendors, but a simple website could accomplish that.

AppImage isn’t currently a part of our design because Software Stores aren’t a part of AppImage’s design. We don’t oppose it–nothing of the sort! But the format isn’t relevant to what Discover does. If you want to use AppImage, go ahead! It’s a great format, and you don’t need our help to do it.

Categories: FLOSS Project Planets

Introducing my new friend: a Slimbook

Thu, 2018-01-18 15:48

Probably most of you will understand me if I tell you I consider my laptop almost like a partner, like my father feels about his car, or kind of. I cannot help but feeling attached to a machine I use many hours a day. So when you have to change it, it is kind of a drama.

It is also a risky decision. I travel quite often and work from home. I have no workstation. This means that I need a powerful and lightweight machine, with high-resolution but also high autonomy, good keyboard and the right combination/amount of outputs… in summary, a good machine.

After a happy journey with Dell, I switched to Lenovo which has been my choice for some years. Not just my former working laptop was a Lenovo but my personal one and my tablet as well.

Why Slimbook

I have been following Slimbook for some time now. As you probably know, they ship a KDE laptop that is very cool, with KDE Neon pre-installed. They have attended to a couple of events I have attended to so I have been able to test their laptops, get feedback from buyers and ask them questions directly. The fact that they are a Spanish company was a beautiful surprise, We do not have that many hardware integrators and vendors in Spain.

But what definitely caught my attention was the fact that they pay a lot of attention to the software. They ship the laptops with Linux pre-installed. Ok, that is not new any more. But they do pre-install several different distros. Now, that’s uncommon. But news do not stop there.

They have created a community of customers that help each other to ensure that you get help beyond their contract responsibilities. They pay attention to this point which makes the pre-sales decision easier, by the way. They also sell peripherals that work on the chosen distro and they welcome tests and reports about them from customers who has installed Linux distributions they do not pre-install.

On the hardware side, Slimbooks are powerful, with a modern look and many cool features.

Based on the above in addition to my KDE colleagues feedback, I decided in October 2017 to go for one. I bought a PRO2 with customised with some high end components. A machine to work with the coming years.

You need to consider that Slimbook is not a big corporation so they do not have much stock. If you want something special, it will take them some days to ensemble it, test the hardware, install and configure the chosen distro and deliver it.

Evaluation… so far.

Let me start by saying I have no commercial relation with them. I write this post as a way to support the effort Slimbook and some of my colleagues are doing to bring KDE to the hands of Slimbook customers.

The purchase process in my case required some back and forth because I wanted to install openSUSE and it was not by then in the list of officially supported distros. They were kind enough to take the opportunity to install it for me and check that everything worked fine. It did. A different story was the dock station available in their store, which I bought. They reported me they could not make it work at 100% with openSUSE Leap 42.2 before sending it so I ended up not buying it.

So as outcome of this process, Slimbook now supports openSUSE Leap and they do not recommend this dock station to buyers that request that pre-installed. This was a a huge time saver for me. Also, I was travelling during the arrival date of the laptop. They managed to ship it so it arrived when I was at home, in between trips, the day I requested.

Slimbook demonstrated they understand what customer service really means.

Sadly I completely forgot to mention to them I needed the hard disk encrypted so I had to reinstall the OS again. This time I went directly for openSUSE Leap 42.3. Everything worked out of the box or was trivial to fix:

  • As usual, the high-resolution of the screen provides some headaches when booting the KDE desktop for the very first time (everything is tiny) which is a plus for having the distro pre-installed.
  • I had to go to Yast to finish the configuration of the sound card. Another reason for buying a machine with the distro pre-installed.

On a side note, I will highlight how painful it is to manage resolutions and font dpi when working with a dual screen configuration with a big difference in supported resolutions between screens (laptop vs monitor). This is the first time I have a laptop with a very high-resolution screen so it was like going back to the bad old days when Linux users had to manually configure screens, projectors… This has nothing to do with Slimbook though.

As usual, configuring a working machine takes quite a long time. There are so many things to install and configure… I am still discovering small pain points and highlights of my PRO2 in working conditions.

I have written to Slimbook a couple of times with suggestions to consider for their store and future high-end models. Nothing really important except maybe the battery capacity, which I consider short for heavy travellers (not for occasional ones).

This point was  not a surprise for me though. Based on the info provided by Slimbook on their website, I could research about it up front. tlp is something you might consider to install and learn how to manage in order to significantly increase the working time with your laptop while on battery.

I get very pity with the location and number of outputs in every laptop I’ve ever had. I must say they are not too bad on this PRO2. Or maybe it is just that I am usually so annoyed that not being too disappointed this time seems like a good sign.

The laptop has so many highlights that I will not go over them. Take it as a good sign.


Do I recommend you the PRO2 with my configuration?

No. My needs might not be yours. You have to get what you need/want. Slimbook allows you to customise your machine which in my case it is a good thing. I considered other laptops from Lenovo or Dell, by the way. I even considered a MacBook.

Do I recommend you Slimbook?

The purchase of a laptop has to be evaluated after a couple of years to be absolutely fair. I am confident about this purchase though based on the customer support I have already received, which is more than what I can say in other cases with well established vendors.

So if you require a good-looking and powerful laptop, you have many options. If you also want to customise it with different components, then the options gets reduced. If on top of that, you are looking for a machine with a Linux distro pre-installed, the number of possibilities are small and, depending on the distro you want, close to none.

If on top of all the above, you want a healthy community of consumers that help each other, well supported by the vendor itself, then Slimbook becomes a good option. An if in addition, you want to work with people that understands how important it is your laptop for a professional, the machine you work with everyday, which necessarily means the vendor must provide a good customer support, then I recommend you to talk to these guys. You will find them, for instance, in most major Open Source events that take place in Spain.

As I have said before, the times for hardware/electronic vendors to “fire & forget” are over, or will be shortly. Updating the software and providing maintenance and support to your consumers, way beyond the law obligations, is not just a differentiation factor, but a must.

Based on my experience so far, Slimbook gets it.

Categories: FLOSS Project Planets

Videos on Samba shares

Wed, 2018-01-17 12:06

A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.


For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.

KDE does have a KIO-aware video player that could do the job: DragonPlayer. Unfortunately, it’s not actively developed, and a bug prevents this from working.

That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!

The problem

…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.

The solution

Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.

Unfortunately (but understandably), the MPV developers denied the request. But the VLC developers didn’t, and actually implemented KWallet support in VLC 3.0! But when I tested it using nightly builds of VLC 3.0, I found that it didn’t work, and had even regressed from version 2.

Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.

Behold, the power of QA!

Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:

After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.

Lessons learned

QA is important. If people don’t test features, apps could ship broken.

Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.

The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.

This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.

Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.

Categories: FLOSS Project Planets

A Fistful of Ports Updates

Wed, 2018-01-17 04:14

Here’s a list of KDE-related stuff (mostly official FreeBSD ports) the KDE-FreeBSD team handled recently. You could call it “a week in the life of some packagers”, packagers who are also otherwise busy with $work-work.

  • Updated otter-browser (a Qt webengine-based browser) to latest version 0.9.94
  • Added a GTK QPA
  • Updated latte-dock to latest released version 0.7.3
  • Clang6 fixes to older KDE and Qt software (out favorite #define nullptr NULL)
  • Reworked packaging of Qt 5.9 to fix a broken (generated) qconfig.h

And in area51, the unofficial ports tree where we do preparatory work (use the branch kde5-import, which supercedes the plasma5 branch; this one contains the current plan for adding Plasma5 to the ports tree and updating all the KDE Applications), we’ve also got:

  • Updated digikam to 5.8
  • Updated KDE Frameworks to 5.42 (this is waiting on an exp-run to move to official ports)
  • Improved powerdevil backend, thanks to Henry Hu
  • Added plasma5-browser-integration
  • Support Qt4 on aarch64, thanks to Fedora

As usual: you can run a full modern KDE desktop system with Plasma 5 and KDE Applications, from the area51 repository, from the kde5-import branch; official ports have the latest Qt and KDE Frameworks, but not the desktop.

Categories: FLOSS Project Planets

CIP related work during the second half of 2017

Tue, 2018-01-16 17:00

As you probably know by now, I have been involved in the Civil Infrastructure Project (CIP), a Linux Foundation Initiative formed in 2016, representing Codethink, a founder Member and coordinating the engineering work in two areas within the project:

  • CIP Kernel maintenance
  • Testing strategy and kernel testing tooling.

In the first front, Ben Hutchings, the Debian Kernel maintainer, a colleague at Codehtink, has been labelled as CIP Kernel maintainer until August 2018. Ben has released in December the latest version of the CIP Kernel 4.4.105-cip15 Currently he is working on releasing a new version, including fixes for Meltdown.

During 2017 until a little after ELCE, I have worked on defining the testing strategy for the CIP kernel and coordinating the efforts towards creating a tool to test it, based on Robert Marshall has been leading the technical efforts the last few months. The tools was finally called Board at Desk (B@D). Some days before ELCE 2017 CIP released first version of the tool, which is nothing but an integration in a VM of the infrastructure that allow testers to test kernels locally in a board connected directly to their machines. There is no need for a remote centralised infrastructure to collect, process and visualise the results. You can read more about it in the B@D 1.0 Release announcement.

A lot of the work my colleagues and I did for CIP got its visualization at the Embedded Linux Conference Europe 2017, that took place in Prague during the third week of October. A couple of articles summarise the activity:

Codethink’s involvement the last few weeks of 2017 and the beginning of 2018 is reduced to the CIP kernel maintenance so in parallel, I have also reduced my involvement to focus more in customer’s work. I plan to attend to the Open Source Summit Japan 2018 to support again CIP activities.

If you are interested in following the work the CIP is doing to bring Linux based systems to Industrial Grade products, I recommend you join the cip-dev mailing list. You can read a previous post I wrote about my CIP related activity.

Categories: FLOSS Project Planets

KWin/X11 is feature frozen

Tue, 2018-01-16 12:08

Yesterday the KDE Community released the Beta for Plasma 5.12 LTS. With that release the feature freeze for 5.12 is in place and also an eternal feature freeze for KWin/X11. To quote the release announcement: “5.12 is the last release which sees feature development in KWin on X11. With 5.13 onwards only new features relevant to Wayland are going to be added.” This raised quite some questions, concerns and misunderstandings in the social networks. With this blog post I try to address those question and explain why this change in policy is done.

Is KWin/X11 still maintained?

Yes! We are just in the process of releasing an LTS. Of course KWin is fully maintained in the LTS life time. While in 5.8 only X11 was maintained, now we are able to offer maintenance for both X11 and Wayland. For the maintenance we do not differentiate between windowing systems.

Will X11 bugs still be fixed?

As X11 is under maintenance, I expect bugs to still get fixed.

Does this mean that in 5.13 X11 will be unmaintained?

We are going to forward port bug fixes from the 5.12 branch to master. Thus any release after 5.12 will get all bug fixes from 5.12. Given that I would say 5.13 will also be maintained on X11.

Does this mean that in the next LTS X11 will be unmaintained?

We will decide when the time comes. Currently I do not expect that we would drop maintenance.

Does this mean Plasma 5.13 will default to Wayland?

This is about feature freeze for X11. Whether Wayland will be the default or not is completely unrelated to this.

Will X11 users not get any new features in KWin?

Of course there will be new features! Most functionality in KWin is independent of the windowing system. Any improvement to those areas benefit Wayland and X11 users. Currently we have a few improvements in the pipeline, for example tooltips on decoration buttons, improved blur effect, a rework of slide desktop effect, improvements to the cube effect and a few more. All of them will be available to both X11 and Wayland users.

How do you decide whether it’s an X11 only feature?

In the case of KWin this is very simple. There are areas in our code structure which are only get pulled in if run on X11, other areas are marked in an if (x11) section. If the new feature touches this code, it’s probably not going to be added.

Does this feature freeze also apply to other KDE software?

No, but personally I would recommend any maintainer to apply a similar feature freeze. I personally will not help developing any X11 specific feature any more and resigned as maintainer of various X11 specific frameworks this week.

What are you going to do if someone present a feature for X11?

It won’t be merged.

But why?

This requires a little bit more explanation. I had a look at the most prominent issues we had over the last years. Where are our stability problems, where are our quality problems, what costs most development time? I observed that it was always in new features specific to X11. Very often even for features we added to Wayland without causing problems.

So I started to look into why that’s so. The obvious answer that we don’t get bugs for Wayland because nobody uses is, is not the case. We get many bug reports for Wayland and many users are nowadays running Wayland. So the reason must be somewhere else.

On Wayland we are able to test the code. Let’s take an example: we get input events through libinput. For this we have unit tests through mocking. Thus we can automate the testing of the lowest layer. From libinput events are sent into KWin core through an internal API and that we can also use in the integration tests. So we can simulate everything from the point where libinput events would hit KWin core. We can test this properly, we know that we get all events (because KWin is the display manager) and we can test every aspect. We can lock the screen and verify how it works, we can make applications grab the pointer or keyboard and test this. We can invoke global shortcuts, etc. etc. It’s all just as if we get the events through libinput. The quality of these new areas in KWin feels really good.

A few weeks ago some commits I did hit the Linux media about KWin/Wayland without X11 starting too fast and due to that causing bugs. These issues were found through our test suite, before any user would ever be exposed to them.

What we did in the past was taking these new features and bring them to X11. But there we cannot test. There is no way on X11 to e.g. fake a touch screen. On X11 we cannot test how this behaves if we lock the screen or used Alt+Tab. We can write the code and manually test it. Hey it works, awesome! But that was mostly not the case. There were corner cases which caused trouble. And to this comes that the main devs run Wayland instead of X11. If features break they are not exposed to the bugs.

Could you give some examples of things that broke?

Sure! The first feature we backported to X11 was “modifier only shortcut”. We spent months fixing the fallout because of X11 weirdness. Another feature backported was panels on shared screen edges. It worked great for Wayland, but on X11 some corner cases were overseen and caused issues, which affected our users and required time to fix. We backported the touch screen swipe gesture on X11 which was a mess. On X11 touch screens are also mouse events, that made it difficult and created many corner cases.

The problem is not adding the feature. The problem is fixing the bugs created by the new features.

But if a new foo requires adjustments?

KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.

Categories: FLOSS Project Planets

Plasma 5.12 LTS beta available in PPA for testing on Artful & Bionic

Tue, 2018-01-16 11:21

Adventurous users, testers and developers running Artful 17.10 or our development release Bionic 18.04 can now test the beta version of Plasma 5.12 LTS.

An upgrade to the required Frameworks 5.42 is also provided.

As with previous betas, this is experimental and is only suggested for people who are prepared for possible bugs and breakages.

In addition, please be prepared to use ppa-purge to revert changes, should the need arise at some point.

Read more about the beta release at:

If you want to test then:

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

and then update packages with

sudo apt update
sudo apt full-upgrade

A Wayland session can be made available at the SDDM login screen by installing the package plasma-workspace-wayland. Please note the information on Wayland sessions in the KDE announcement.

Note: Due to Launchpad builder downtime and maintenance due to Meltdown/Spectre fixes, limiting us to amd64/i386 architectures, these builds may be superseded with a rebuild once the builders are back to normal availability.

The primary purpose of this PPA is to assist testing for bugs and quality of the upcoming final Plasma 5.12 LTS release, due for release by KDE on 6th Febuary.

It is anticipated that Kubuntu Bionic Beaver 18.04 LTS will ship with Plasma 5.12.4, the latest point release of 5.12 LTS available at release date.

Bug reports on the beta itself should be reported to

Packaging bugs can be reported as normal to: Kubuntu PPA bugs:

Should any issues occur, please provide feedback on our mailing lists [1] or IRC [2]

1. Kubuntu-devel mailing list:
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on

Categories: FLOSS Project Planets

This week in Discover

Tue, 2018-01-16 09:09

I guess I’m becoming a Discover developer, since it’s where I seem to spend most of my time these days. It’s just so darn fun since the lead Developer Aleix Pol is super easy to work with, there’s a lot of low-hanging fruit, and with Kirigami, it’s very simple to make consequential changes even when you’re a novice programmer and not very familiar with the codebase. That said, Aleix is still making about 99% of the code changes, and I’m mostly doing UI tweaks, bug screening, promotion, strategy, and work with apps to get their houses in order.

Anyway, here are the user-facing highlights of what we’ve done in the last week or so. There was a lot of work on Snap and Flatpak in particular.

  • Snaps now show their size correctly once installed (KDE bug 389024)
  • During installation of Snaps, the Install button changes so you can’t click it multiple times (KDE bug 388916)
  • Discover now shows the license for Snaps (KDE bug 388735)
  • Discover now shows the size for Snaps that aren’t installed (KDE bug 388734)
  • Discover no longer shows duplicate information in package changelogs for Debian-based distros (KDE bug 387041)
  • Discover now shows the version number for Flatpak apps that define information in their AppStream files (KDE Bug 388968)
  • Discover’s Home page now communicates that it’s a list of featured apps (KDE Phabricator revision D9868)
  • Discover now correctly removes the Tasks entry for an app if you cancel the installation (KDE bug 388915)

Let me share a video that shows a lot of the highlights:

We’ve got Kdenlive available from three sources. Version 17.08.3 is available from a distro, and version 17.12.1 is available straight from the developers via Flatpak. You can also get bleeding-edge development builds if you’d like to follow or participate in the development, or verify that a bug is fixed before the next release. You can install the one that suits you best, and change your selection as your needs and preferences evolve over time. It’s your choice.

You’re looking at the future of software delivery, folks.

Do you want to help make this happen? Instead of my usual spiel about becoming a KDE contributor or donating, consider helping app developers correct and expand their AppStream metadata. The video you just saw isn’t possible without it. Let’s go build the future.

Categories: FLOSS Project Planets

Sharing Files on Android or iOS from or with your Qt App – Part 2

Tue, 2018-01-16 07:27

Please read Part 1 of this Blog series about sharing Files on Android and iOS where I wrote about my experiences how to share Files or Content from your Qt App with native Android or iOS Apps.

In the meantime I did some UI tuning and added more info to make it easier to understand and to manage some more use-cases, so expect some more parts of this series next weeks.

Also I found out that not all Android Apps are good citizens of ACTION_EDIT – Intents with ResultCode. After editing and save per ex. Google Fotos sends correct RESULT_OK where other Apps are giving you RESULT_CANCEL. For our workflows it‘s important to know if a File was modified, so as a workaround I store the last-modified-Timestamp before starting the Intent and compare with current Timestamp when Result was handled. All of this is done under the hood and you‘re always getting the correct result code back from EDIT Action.

Some preliminary notes
  • Try it out: all sources are available at GitHub
  • Permissions not checked in Example App: enable WRITE_EXTERNAL_STORAGE manually
  • Current release is for Target SDK 23 ! (Android 7 requires FileProvider – will add later)
  • All Use-Cases are implemented to be used x-platform – currently Android and iOS

If you‘re looking for an Android-only solution please also take a look at AndroidNative project.

Android / iOS

First part covers sharing Files from your App with other Apps on Android and iOS.

This Blog Post is about sharing Files with your Qt App on Android (iOS will follow soon):

  • Use your App as Share Target to receive Content or Files from other Android Apps
  • Impacts on „Sharing Files from your App with other Apps“ (see Part 1)
Intent Filter

To tell the Android OS what kind of Files our App can handle we must add an Intent Filter to AndroidManifest.xml:

<activity … > <!-- Handle shared incoming urls --> <intent-filter> <action android:name="android.intent.action.SEND"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="*/*"/> </intent-filter> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="*/*"/> <data android:scheme="file"/> <data android:scheme="content"/> </intent-filter> </activity>

Now the App can receive Intents for all kind of MimeType using ACTION_VIEW or ACTION_SEND.

Custom Android Activity

To be able to get the Intent we must add some code to our main Activity, so extend the default QtActivity. To do so create a at this location:

<project>/android/src/org/ekkescorner/examples/sharex public class QShareActivity extends QtActivity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } }

As next change the Name in AndroidManifest.xml:

<activity ... android:name="org.ekkescorner.examples.sharex.QShareActivity" ...> Get the incoming Intent

Now the interesting part:
Our App can be opened by other Apps – how do we get the Intent data and read or copy the ‚foreign‘ File ?

This depends from current ApplicationState:
if the App is already running, Android OS will call onNewIntent() – if not our App will be launched and the Intent comes in from onCreate(). The best way is to check the Intent from both methods and then call another method to process the Intent.

Attention: there are some traps to watch !

To inform the UI about an incoming File as usual we want to use a SIGNAL.

If the App is already running we want to open our App exactly on the current Page. Imagine a DropBox-like App where you navigate deep into your File hierarchy and now you want to upload a new Presentation File into the current Folder, but you must edit the Presentation before. So you open PowerPoint or something else, create/edit the presentation and then want to share that File with your App. Of course the User wants to be exactly where he was before without the need to do deep File navigation again.

If our App will be launched by the incoming Intent, onCreate() was called from Android OS to deliver the Intent. Unfortunately at this moment the Qt App isn‘t ready and the SIGNAL will be lost. To avoid this don‘t process the Intent from onCreate() but remember that there‘s a pending Intent.

Later when the Qt App is ready check for pending Intents. HowTo know if the App is ready to process Intents ?

In our Example App we‘re checking the ApplicationState and first time the State becomes Active we ask for pending Intents.

In a real-life business App probably you must at first Login to your Server or get some data from Server, so you‘ll do the check for pending Intents later.

LaunchMode ‚singleInstance‘ vs ‚singleTask‘

As next I found out that the last opened Page wasn‘t shown – instead a white Screen comes up and an error was logged: ‚Surface1 null‘.

Reason was the Launch Mode. Most Android Intent examples are using ‚singleTask‘ so I also did it. Changing the LaunchMode to ‚singleInstance‘ in combination with ‚taskAffinity‘ works better for Qt Apps: now the App opens correct the last opened Page.

Here are the changes to AndroidManifest.xml:

<activity ... android:launchMode="singleInstance" android:taskAffinity="">

Some code snippets:

public class QShareActivity extends QtActivity { public static boolean isIntentPending; public static boolean isInitialized; public static String workingDirPath; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // now we're checking if the App was started from another Android App via Intent Intent theIntent = getIntent(); if (theIntent != null){ String theAction = theIntent.getAction(); if (theAction != null){ // delay processIntent(); isIntentPending = true; } } } // if we are opened from other apps: @Override public void onNewIntent(Intent intent) { super.onNewIntent(intent); setIntent(intent); // Intent will be processed, if all is initialized and Qt / QML can handle the event if(isInitialized) { processIntent(); } else { isIntentPending = true; } } public void checkPendingIntents(String workingDir) { isInitialized = true; workingDirPath = workingDir; if(isIntentPending) { isIntentPending = false; processIntent(); } } // process the Intent if Action is SEND or VIEW private void processIntent(){ Intent intent = getIntent(); // do something with the Intent } }

Check ApplicationState in ApplicationUI.cpp:

#if defined(Q_OS_ANDROID) void ApplicationUI::onApplicationStateChanged(Qt::ApplicationState applicationState) { if(applicationState == Qt::ApplicationState::ApplicationActive) { // if App was launched from VIEW or SEND Intent // there's a race collision: the event will be lost, // because App and UI wasn't completely initialized // workaround: QShareActivity remembers that an Intent is pending if(!mPendingIntentsChecked) { mPendingIntentsChecked = true; mShareUtils->checkPendingIntents(mAppDataFilesPath); } } } #endif Process the incoming Intent

Now let‘s take a look at processIntent() from to see how to read the File from the other Android App.

We‘re listening for VIEW and SEND Intent Actions. The ways to get the Uri are different:

Uri intentUri; String intentScheme; String intentAction; if (intent.getAction().equals("android.intent.action.VIEW")){ intentAction = "VIEW"; intentUri = intent.getData(); } else if (intent.getAction().equals("android.intent.action.SEND")){ intentAction = "SEND"; Bundle bundle = intent.getExtras(); intentUri = (Uri)bundle.get(Intent.EXTRA_STREAM); } else { return; }

As next we must check the Scheme to know if it‘s a ‚file‘ or ‚content‘ Scheme.

// content or file intentScheme = intentUri.getScheme(); if (intentScheme == null){ return; } if(intentScheme.equals("file")){ // URI as encoded string setFileUrlReceived(intentUri.toString()); // we are done Qt can deal with file scheme return; } if(!intentScheme.equals("content")){ return; }

To get the real FilePath from a Content Uri isn‘t so easy. Found many complicated examples and finally I got a great solution to extract the absolute FilePath from the Content Uri ��

Please take a look at

<project>/android/src/org/ekkescorner/utils/ public class QSharePathResolver { public static String getRealPathFromURI(final Context context, final Uri uri) { // ... } } checks if the content Uri comes from

  • ExternalStorageProvider
  • DownloadsProvider
  • MediaProvider: Images, Video, Audio
  • GoogleFotosUri

and tries to calculate the real path. Now it‘s easy to get the File from an Intent providing a Content Uri:

filePath = QSharePathResolver.getRealPathFromURI(this, intentUri); setFileUrlReceived(filePath); // we are done Qt can deal with file scheme return;

If the Uri couldn‘t be resolved from we try to read the InputStream. Please take a look at createFile(ContentResolver cR, Uri uri, String fileLocation)

filePath = QShareUtils.createFile(cR, intentUri, workingDirPath); setFileReceivedAndSaved(filePath);

Ok – we received the File from our custom Activity – how can we provide this to our QML UI where we‘re waiting for a SIGNAL from C++ ?

From Java (Activity) to C++ to emit the SIGNAL for QML

The methods setFileUrlReceived() and setFileReceivedAndSaved() are native methods:

public class QShareActivity extends QtActivity { // 'file' scheme or resolved from 'content' scheme: public static native void setFileUrlReceived(String url); // InputStream from 'content' scheme: public static native void setFileReceivedAndSaved(String url); }

Native Methods are implemented in C++ via JNICALL – see all details in AndroidShareUtils.cpp:

#ifdef __cplusplus extern "C" { #endif JNIEXPORT void JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_setFileUrlReceived(JNIEnv *env, jobject obj, jstring url) { const char *urlStr = env->GetStringUTFChars(url, NULL); Q_UNUSED (obj) AndroidShareUtils::getInstance()->setFileUrlReceived(urlStr); env->ReleaseStringUTFChars(url, urlStr); return; } JNIEXPORT void JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_setFileReceivedAndSaved(JNIEnv *env, jobject obj, jstring url) { const char *urlStr = env->GetStringUTFChars(url, NULL); Q_UNUSED (obj) AndroidShareUtils::getInstance()->setFileReceivedAndSaved(urlStr); env->ReleaseStringUTFChars(url, urlStr); return; } #ifdef __cplusplus } #endif

If you want to learn more about JNICALL and other ways to manage them, here‘s a great Blog Post from BogDan Vatra : qt-android-episode-5.

JNICALL is like a bridge from Java to C++:

void AndroidShareUtils::setFileUrlReceived(const QString &url) { QString myUrl; if(url.startsWith("file://")) { myUrl= url.right(url.length()-7); } else { myUrl= url; } // check if File exists QFileInfo fileInfo = QFileInfo(myUrl); if(fileInfo.exists()) { emit fileUrlReceived(myUrl); } else { emit shareError(0, tr("File does not exist: %1").arg(myUrl)); } }

This JNICALL enables us to emit the SIGNAL that we received an Intent from another Android App providing access to a File.

Test it !

Now it‘s a good point to test it. Open Google Photos, select an Image and ShareWith shows ‚ekkes SHARE Example‘ App as target:

Select ‚ekkes SHARE Example‘ and Android will open our App. If the App already was opened, the current Page will be displayed and include the Image:

onActivityResult() (JAVA) vs QAndroidActivityResultReceiver (JNI)

While writing Part 1 of this Blog series I didn‘t found a way to get the Result back if Intent was started with Result from (Workflow ‚A‘ – the JAVA way)

QtNative.activity().startActivityForResult(Intent.createChooser(viewIntent, title), requestId);

@hamalaiv comment pointed me to the right direction: to get the Result back a Custom Activity must be used.

Ok – we‘re now using a custom Activity ( – let‘s test it.

To get the Result back, we must be implemented this JAVA code:

public class QShareActivity extends QtActivity { public static native void fireActivityResult(int requestCode, int resultCode); @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { fireActivityResult(requestCode, resultCode); } }

and this C / C++ Code:

JNIEXPORT void JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_fireActivityResult(JNIEnv *env, jobject obj, jint requestCode, jint resultCode) { Q_UNUSED (obj) Q_UNUSED (env) AndroidShareUtils::getInstance()->onActivityResult(requestCode, resultCode); return; } void AndroidShareUtils::onActivityResult(int requestCode, int resultCode) { processActivityResult(requestCode, resultCode); } void AndroidShareUtils::processActivityResult(int requestCode, int resultCode) { if(resultCode == RESULT_OK) { emit shareEditDone(requestCode); } else if(resultCode == RESULT_CANCELED) { if(mIsEditMode) { // check Timestamp and emit shareEditDone(requestCode); // or emit shareFinished(requestCode); return; } emit shareFinished(requestCode); } else { emit shareError(requestCode, tr("Share: an Error occured")); } }

Testing the JAVA way sharing Files with other Android Apps now works as expected with or without ResultCode. I removed the workaround code from ApplicationUI.

But there‘s a Drawback: Testing the JNI way (Part 1, Workflow ‚B‘) using QAndroidActivityResultReceiver only works without ResultCode. If starting the Intent with ResultCode

QtAndroid::startActivity(jniIntent, requestId, this);

the QAndroidActivityResultReceiver wasn‘t called for the Result: instead the Result comes back via our custom Activity onActivityResult() method using a wrong RequestId.

Lesson learned: never use QAndroidActivityResultReceiver (C++, JNI) and onActivityResult() (JAVA Activity) together in one App.

To test this please comment or rename onActivityResult() and you‘ll see the JNI implementation alone works well.

There‘s another problem if we want to share one of our Files with other Apps, because now we‘re source and also target for same MimeTypes. This means: our own App will be listed as a target:

Tried some ways to workaround, but doesn‘t work well and selecting the own App as Target with Result crashed the App because there was a collision with LaunchMode ‚singleInstance‘.

Unfortunately there‘s no way to exclude targets using Intent Filter. So we have to create a custom Chooser without listing our own App as Target. Thanks to this thread at StackOverFlow I found a way to solve this. Please take a look at

public static boolean createCustomChooserAndStartActivity(Intent theIntent, String title, int requestId) { // ... }

Here‘s a short summary:

  • Create Intent as before and use as template
  • Context is QtNative.activity()
  • Get packageManager from context.getPackageManager()
  • Retrieve all Apps (List) for Template – Intent: packageManager.queryIntentActivities()
  • Sort Apps (List) by Label
  • From Apps (List) create List
    • Create Intent as Copy from Template – Intent
    • Add setPackage(targetPackageName)
    • Don‘t add Intent to list if Target PackageName equals own PackageName
    • If needed also watch a Blacklist

We created a List of Intents, where all Intents are based on our previously created Template – Intent with an extra PackageName added. This means each Intent will only detect one specific App as Target.

Now the tricky part:

We want to all collected Intents as EXTRA_INITIAL_INTENTS and we‘re using the last one from list of Intents as initializing Intent because the Chooser adds its initializing Intent to the end of EXTRA_INITIAL_INTENTS ��

Intent chooserIntent = Intent.createChooser(targetedIntents.remove(targetedIntents.size() - 1), title); if (targetedIntents.isEmpty()) { Log.d("ekkescorner", title+" only one Intent left for Chooser"); } else { chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS, targetedIntents.toArray(new Parcelable[] {})); } QtNative.activity().startActivityForResult(chooserIntent, requestId);

Now it works as expected: our own App doesn‘t appear in list of target Apps.

Attention: onActivityResult() (JAVA) sometimes is too fast compared with QAndroidActivityResultReceiver (JNI)

While testing Action SEND I noticed that Files are not copied to other Apps or not printed, because ‚File does not exist‘. This happens only if going the JAVA way getting the Result back from onActivityResult(), but not if using JNI and QAndroidActivityResultReceiver.
When getting the Result back I‘m deleting the File from Documents Folder (see Part1) and it seems that onActivityResult() sends the Result before File was fully copied / printed.
As workaround I added a Timer with 500ms delay in QML before deleting the File.

From now on I‘ll use the JAVA way (Workflow ‚A‘ in Overview) as default to share Files with other Apps, because it‘s much easier to implement specific behaviour (as our Chooser Intent) using JAVA instead of JNI. The pure JNI way still remains in the code to get a feeling HowTo solve it without JAVA code.

Share from other iOS Apps with our Qt App

As next I want to implement the same functionality for iOS – so stay tuned for Part 3.

My goal is always to provide easy-to-use x-platform solutions for Android and iOS. That‘s why I‘m using Qt ��

Some years ago I developed mobile business Apps for BlackBerry10 (BB10) where the InvocationFramework makes it easy to share content or files between Apps.

BB10 Customers are now (and next years) in transition from BB10 to Android, iOS or both and of course I want to motivate them to use Qt as their new Framework. Last two years I implemented most of my patterns using Qt and QtQuickControls2 for Android and iOS. Having features only for one platform is like having no solution. Step-by-step I‘m reaching feature-parity with BB10.

I‘m also blogging about all of this to make it easy for mobile devs to start with Qt.

Back to Sharing Example.

Need Help – offer Bonus

As I understand it right, iOS Extensions should be used to share Files or Content from other iOS Apps to our Qt App and it seems that this isn‘t supported yet our of the box from QtCreator. If there are some manual steps needed I need a description HowTo do this.

Remember: I‘m a mobile Business App Developer, not a Xcode expert and not an Obj-C expert and I‘m doing all my work from QtCreator – not commandline.

I‘m open for all tips and any help HowTo …

  • Open Qt App from other iOS Apps sharing Text Content or Files
  • Reopen Qt App from other iOS Apps at current Page if Qt App is already running
  • Emit SIGNAL about received Files or Text and copy Files into AppData location
  • Development workflow to solve this from QtCreator / Xcode

Bonus: If someone can provide a small sample project before I found out all the steps and blogged about, the first one will get a Bonus of 500 € from me. Please be aware that I‘ll modify and include code into my Share Example as Open Source code.

Have Fun

Now it‘s time to download current Version from Github, build and run the Sharing Example App.

The post Sharing Files on Android or iOS from or with your Qt App – Part 2 appeared first on Qt Blog.

Categories: FLOSS Project Planets

Plasma on ARM: State of the Union

Mon, 2018-01-15 19:13

For the past year at Blue Systems my colleagues and I have been working on getting Plasma 5 ready for ARMv8 systems such as the Pinebook. If you were at QtCon this year, you might have also seen our awesome team demo’ing these systems at the KDE booth along with Plasma on ARMv7 systems such as the ODROID C1.

A year ago, the state of Plasma on ARMv8 looked somewhat like this bench, covered in snow, not particularly inviting. Things worked, or at least appeared to, only to break as soon as you started digging deeper into the innards of the system. One of the biggest hurdles in the ARM space right now is getting graphics working on a Linux system. Working with the Pine64 and Pinebook was no exception.

While the X11 and DRM stacks are open source, the OpenGLES implementation is only provided as a proprietary blob. Better than nothing, but still not quite up to the quality that we were looking for.

Once we figured out where we could improve things, we started getting our hands dirty and improving things as best as we could and learning more about the graphics stack as a whole. This lead to improvements such as getting a working hwcursor (thanks David!) for the Pinebook, making sure we don’t have garbage on the screen when X11 gets started and a failed attempt to get Debian to rebuild Qt on ARM64 systems with GLES instead of OpenGL ( since there is no OpenGL on the Pinebook ).

We also bench marked important metrics that would affect our users such as time to login manager, time to desktop and the time it took to launch a file manager such as Dolphin. With these metrics in hand, the Plasma team at Blue Systems set out to improve these metrics by improving the various bits and pieces within the KDE product ecosystem. It’s important to note that all of the improvements that have been made will also benefit x86 users, though the impact will really be seen on ARM devices.

The future for Plasma on ARMv8 looks pretty bright from here on out to me. There’s still a lot of work to be done, but we’ve got a pretty good handle on it for now. There were massive improvements once we identified major pain points such as Qt using OpenGL instead of GLES and fixing issues within Qt itself.

I’d also like to take a moment and say a massive thanks to the Pine community as well. They’ve been an amazing group of people to work with. They even released a Wayland driver that could potentially become the building block to deliver a ARMv8 laptop that can run Plasma atop Wayland in the future! Thank you so much, it really is appreciated.

Categories: FLOSS Project Planets

Three old Plasma Weather applet TODO items gone for Plasma 5.12

Mon, 2018-01-15 17:15

Just when I thought to have missed yet another Plasma feature freeze deadline with the one for Plasma 5.12 LTS and thus a good(?) excuse to re-decrease priority of some planned work on the Plasma Addons Weather applet (from the kdeplasma-addons repo, not to be mixed up with clearmartin’s one from github/ once more and thus delay things even further to a day that may never come, the Plasma team found they need to shift the deadline by some weeks to be after the KDE Frameworks 5.42.0 release.
So excuse gone, no other quickly found… time to do a git pull and open the editor.

It’s almost two years ago that the old Plasma Addons Weather applet got ported to Plasma 5 with an initial release in Plasma 5.6. That activity resulted in some plans for further work, which then though met a sad fate of plans… staying on paper to some degree. Let’s revisit the points of the plan and their state:

  • Breeze-style weather state icons: done -> hurra for hard-working Ken
  • Overhaul of look: only cosmetic changes applied, bigger redesign never turned into code -> FAIL
  • support for more weather data providers: a template for provider plugins has been done and added, but no-one ever contributed a plugin for a new provider -> FAIL so far
  • also temperature displayed in compact widget variant, like on panel: got lost in layouting code -> FAIL
  • privacy control which weather data providers are queried on finding weather stations: never worked on -> FAIL

Add to that a Plasma 5 Porting TODO item from the code:

  • Restore night-style icons for observation weather conditions at night: never worked on -> FAIL

Living in some slightly northern of the northern hemisphere, right now the days are short and the temperature is often around the freezing point. Which makes the weather applet look slightly broken and useless: not showing the temperature directly on the panel for a quick glance to check whether it is slippery outside, but showing the weather observation report with the sun symbol in the icon when it is dark outside… who needs or wants that. Still the applet is working too well for just proposing to wipe it from the repos in favour of one of the alternative ones out there. Of course there is also that tiny bit of pride in the porting work done, which begs for throwing more good time after it…

So motivation collected, some coding time shuffled free: the fight against the new Plasma 5.12 feature freeze deadline was picked up. And to make the already too long story short, I can now happily report that with the help of Kai Uwe and some further random Plasma developers the last three items can now be checked off as Done starting with Plasma 5.12
(Well, almost, truth is that proper night-style icons are still not available for some stations/providers or delivered data, fixing needs a bigger redesign, which is left for another time)

Selecting which weather service providers to query for a location in the Plasma Weather applet. Spot also the optional temperature shown on both panels next to the weather state icon, as well as proper night-style weather state icon for England’s London during current CET night (sorry for German/English mix in UI, too sleepy for proper setup)

So some 2018 FLOSS contributions of mine done. Now I can slack off the rest of this year!
And watch you doing yours by implementing a plugin for your favorite weather data provider?
Which, BTW, will be also useful to any other Plasma applet which makes use of the Plasma Weather dataengine from the plasma-workspace repo.

Categories: FLOSS Project Planets

SoK Project – Week 1 & 2

Mon, 2018-01-15 09:07

With all the happiness after being selected for SoK 2018, I was looking forward to start working on my project with whole dedication. My project aims to complete port of a brain-boosting memory activity called “Railroad” (in which kids have to observe the given train and memorize it within given time and then try to rebuild it) from Gtk+ to Qt version. It is a part of project GCompris(a high-quality educational software suite, including a large number of activities for children aged 2 to 10). My mentors are Timothée Giet and Rudra Nil Basu, along with them I’d like to thank a lot to Johnny Jazeix and Divyam Madaan for helping me with my project. My SoK proposal can be found here –> SoK Proposal. And my progress can be tracked at –> Railroad branch.

I started with introducing myself to the GCompris community and discussing my implementation plans with the mentors. My mentors helped me to get my KDE developer account and setup git. First error which I encountered was during git clone, after googling about it and discussing with mentors I got to know that it was due to the firewall(thanks to my college).

My main task for first two weeks was to create a new layout for the activity, make the activity look better in small screen devices and remove horizontal scrolling. This activity was already started during previous SoK, so most of the code was already written. I compiled the activity and started understanding its code, my previous contributions on GCompris helped me to understand the code fastly. Previously it was hard-coded to have a fixed no. of wagons in fixed no. of rows which caused horizontal scrolling. I implemented a GridView based layout which helped to remove the need for horizontal scrolling and made UI look more beautiful.

1. For Horizontal Screens

2. For Vertical Screens

After working on UI, I created five levels based on increasing difficulty and fixed some issues in UI based on reviews from my mentors. Every error opened an opportunity for me to learn something new. I’ll be working on implementing keyboard navigations next week.

Some of the new things which I learned during this project so far
> Importance of Version Control System.
> Quality of code is more important than Quantity of code.
> Dividing a big task into small tasks and then proceeding.
> Using SSH keys.
> An image when opened with a text editor shows real mystery behind it.

In conclusion, SoK proves to be a great experience thus far, being a pleasure to work on a project focused mainly on Education. For further updates, stay tuned!

Categories: FLOSS Project Planets

How you can help drive Flatpak adoption

Sun, 2018-01-14 23:46

What happens in Discover in when an app is available from multiple sources–say, Flathub as well as your distro’s packages?

As long as both versions of the app provide the same AppStream ID, Discover will show a single entry and let you choose which one you want to install, like this:

But if any of the available versions use a different AppStream ID, they’ll show up separately:

Uuurgh, how awful. Which GIMP is the real GIMP? And why do they all have different names?! Flathub uses org.gimp.GIMP as the AppStream ID, while The GIMP developers provide gimp.desktop for distros to use as the AppStream ID. And the Snap version provides no AppStream ID, sadly.

So we need the GIMP developers to change their AppStream ID to the same one that Flathub uses (which actually follows the AppStream spec). I submitted a patch to fix it that was recently accepted, so this should be resolved with the next GIMP release. That will unify the first two, but the third–which comes from Snap–won’t get rolled up into it until Snap uses AppStream IDs. The Snap folks are on the case, but it’s still a work in progress.

But adopting AppStream only work as long as developers are populating their AppStream files with valid IDs! An AppStream ID is supposed to look like com.myurl.NameOfMyApp, not NameOfMyApp.desktop or com.myurl.NameOfMyApp.desktop. Flathub gets this right, but a lot of app developers themselves get it wrong, and it’s up to us to help them, and make sure the AppStream IDs in their files match those on Flathub.

I’ve started to submit patches for apps that unify their AppStream IDs:

What can I do to help?

See all those patches I submitted? You can do the same! If you use any apps that have AppStream IDs in their distro packaging that are incorrect and different from what’s in Flathub, then submit a patch to fix it! Keep in mind the following guidelines:

  1. Dashes/hyphens must be replaced with underscores: com.shutter-project.shutter is wrong and should be com.shutter_project.shutter
  2. Leading digits in the app name are not allowed: com.wildfiregames.0ad is wrong and should be com.wildfiregames._0ad
  3. If the AppStream ID used for Flathub is wrong, don’t replicate that wrongness with your patches; encourage developers to use correct AppStream IDs and file a bug for the app on Flathub, like this one.

For extra credit, you can also submit patches that add <release> information, too. This will make the app’s version string show up in Discover:

And here’s the properly formatted <release> information in HexChat’s AppStream file that provides it:

I know this isn’t the most immediately rewarding work, but it’s super important to make Flatpak (and later Snap) work properly in a mixed environment where you also have distro packages available. If you want the world to be Snappier or more Flatpacked, this is probably the easiest way to make it happen if you’re not a programmer or a packager. If you need a hand, you can email or check out the #flatpak IRC channel on

As always, if you find this work useful or valuable, please consider becoming a KDE contributor or donating to KDE! But do consider submitting patches for Apps that have sparse or incorrect AppStream data. You’ll be doing your part to pull Linux software distribution into the future.release

Categories: FLOSS Project Planets

Flatpak support in Discover

Sat, 2018-01-13 19:51

People often ask about the state of Flatpak in Discover, so today I’m going to write about that. Thew good news is that Discover’s Flatpak support is very good and getting better all the time. It’s fully production ready and we encourage you to use it!

To download Flatpak apps in Discover, you need to have the Flatpak backend installed. In many distros, it’s a separate package that doesn’t come installed by default. In Ubuntu-based distros, you can install it by running sudo apt install plasma-discover-flatpak-backend. in Discover 5.12, you’ll even be able to install different backends from within Discover itself, by searching for “Flatpak” or “Snap”. If you want faster Flatpak adoption, please petition your distros to install the Flatpak backend by default!

Once the Flatpak backend is installed, you need to add at least one Flatpak repo. Distros can provision this with default entries, but most don’t. Bug your distro if you want a better experience here! Until then, you can go to Discover’s Settings page and click the “Add Flathub” button to add Flathub as a source. After that, you can access Flatpak apps by browsing or searching through the app lists as normal. You can also go to the settings page and click on the Flatpak entry, which will show you just the Flatpak apps from that repo:

You can add multiple Flatpak repos; to do so, go to the Settings page, click the Hamburger menu button next to the text “Flatpak”, and click “Add Source…” Then enter the URL of the Flatpak repo you want to add. Discover also handles this properly when you click on a repo URL in your web browser.

Multiple Flatpak repos enable users to effortlessly switch between stable and up-to-date versions of apps, each version provided by a different repo. Right now, we’re generally stuck with one or the other, according to our distro’s packaging policy: Arch and other rolling distros say that you always get the latest version; Debian and Ubuntu and other stable release distros say that you always get a specific version that’s frozen in time. Sometimes that’s not right for you, because maybe the latest version has a bad bug, or an old stable version is missing features you want that were implemented in a later version.

Flatpak liberates us from this. You could add Flathub ( and also KDE’s nightly testing repo ( Then when you go to install a KDE app that’s present in both, you can choose the source! Maybe you want to live on the bleeding edge, but if you run into an issue, you can easily revert your installation to the stable version. It’s pretty awesome.

If any of this seems cool and useful, please don’t hesitate to join our team or make a donation to KDE. My next post shares some specific things you can do to help push Flatpak adoption, even without being a programmer.

Categories: FLOSS Project Planets

digiKam 5.8.0 is released

Sat, 2018-01-13 19:00

Following the release of 5.7.0 published in September 2017, the digiKam team is proud to announce the new release 5.8.0 of the digiKam Software Collection. In this version a lot of work has happened behind the scenes and in fixing bugs as usual, which does not mean there are no enhancements: a new tool to export collections to UPNP/DLNA compatible devices has been introduced.

Bugs Triage

Following the large update of bug categories processed before the previous release, we have been able to reassign entries to the right components. With the help of pre-release bundles computed each day, we have been able to provide a digiKam test version along with the fixes applied to close reports in bugzilla. The result with this release is a set of more than 200 entries officially closed.

Application Bundle Improvements

For each platform supported by the digiKam project, we propose a bundle package ready to use, which embed all the needs to have a suitable application. digiKam project confirm the support of The AppImage format as the best Linux bundle, which has been updated to last SDK available in build virtual machine based on Linux Centos. This one now permits to run the bundle under Firejail sandboxing technology for a better security level..

The Windows installer is now built with the latest NSIS version to be compatible with Windows 10. The installer code has also been cleaned to remove obsolete packaging plugins and to prevent false virus detections while installing. Note that all digiKam Windows bundles are fully built under Linux with the MXE cross-compiler and there is no risk to inject Windows viruses in the application.

All bundles, including the MacOS package build with the latest Packages, now include more optional features available on digiKam and also Showfoto, as some new low level libraries have been ported to pure Qt5, such as digital scanner support and events file support with export to Calendar tool.

Mysql Support Improvements

A lot of work has been done around the Mysql support with the help of end users testing step by step progress and the relevant fixes applied daily. For these hacking stages, the pre-release bundles have really helped a lot, by providing a ready to use beta version of digiKam including all debug statements necessary to investigate the dysfunctions, especially for the database schema update performed on older collections hosted on a Mysql or Mariadb server. The migration tools have also received many fixes, especially to move from Sqlite databases, when collections grow substantially and over time become more and more slow. Now, the migration tool can import and export better from/to Mysql or Sqlite without data-loss while databases are being converted.

Export to UPNP/DLNA devices

In September 2017, the digiKam team has been invited to take part in the Randa Meetings. In this tiny town in the Swiss alps a lot of KDE developers work on improving their software. We have focused the reunion on including the new media server dedicated to sharing collection contents on local networks with compatible DLNA devices or applications, such as tablets, cellulars, TV, etc. This tool is now available in all digiKam views through the main Tools menu and also in Showfoto.

There are plenty of DLNA applications available in digital stores like iTunes or GooglePlay. As the DLNA and UPNP protocols are standardized, we don’t need to develop dedicated applications for each client device that wants to access the digiKam/Showfoto contents.

Port DropBox Export Tools to OAuth2

Concerning digiKam export tools to remote Internet services, the port to OAuth version 2 is advancing steadily with more work planned in the course of the year. After porting the Flickr and Imgur export tools with the 5.7.0 release, the DropBox export tool is now ported to the new authentication API, so after a short time of dysfunction the tool is back and ready for use in production. In the future other tools, such as Facebook and GPhoto export, will be ported to OAuth version 2. This will probably be a subject for the students working with us for the upcoming Google Summer of Code 2018.

Final Words

As always, but especially noteworthy this time, you can look at the list of 231 resolved issues for detailed information.

digiKam 5.8.0 Software collection source code tarball, Linux 32/64 bits AppImage bundles, MacOS package, and Windows 32/64 bits installers can be downloaded from this repository.

Happy new year 2018 and happy digiKaming!

Categories: FLOSS Project Planets

Last Weeks Activity in Elisa

Fri, 2018-01-12 12:40

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

We are preparing for the next alpha release when the following features will be done. Alexander is working on a metadata view for tracks. I am working on cleaning the different grid views into a generic one.

Diego Gangl did several modifications of the interface as part of the interactions with KDE VDG.

All in all, Elisa now looks like that:

Snapshot of album view including the changed application menu

The following things have been integrated in Elisa git repository:

  • Fix modification of files with DatabaseInterface::modifyTracksList by Matthieu Gallien ;
  • This patch increases the blur in the headerbar background, increases contrast
    between background and text, and brings the labels closer together by Diego Gangl ;
  • Tune appearance of all albums and all artists views by Matthieu Gallien ;
  • Fix wrong id reference in FilterBar by Matthieu Gallien ;
  • In all models, calls base class roleNames before adding new role names by Matthieu Gallien ;
  • Simplify the definition of custom roles in all models by Matthieu Gallien ;
  • Allow MusicArtist to be stored in a QVariant by Matthieu Gallien ;
  • Allow to enqueue artist in MediaPlayList by using MusicArtist objects by Matthieu Gallien ;
  • Change height of delegate in GridView by Matthieu Gallien ;
  • Fix a typo in the imported tracks notification by Diego Gangl ;
  • Make shadows centered and slightly larger. Fits better with other shadows in the
    desktop (like dolphin and widgets), and it also aligns with the new shadows for
    breeze (D9549) by Diego Gangl ;
  • Fixes key arrow navigation in list and gridviews and implements enter and return key actions for delegates by Alexander Stippich ;
  • Allow elisa to open any external files, scan them and enqueue them by Matthieu Gallien ;
  • Syncs the windows theme file with the current main theme file. Removes bundled icons for windows which are not needed as proven by ViewSelector.qml, but also tested on windows by Alexander Stippich ;
  • Make the delegates more appealing when using a dark theme also add hover animations while keeping the loader component by Alexander Stippich ;
  • Fix keyboard navigation for album artist view too by Alexander Stippich ;
  • Move all icon and image definitions to theme file and make some consistency fixes. In anticipation of a colorized version of the artist image, there are two definitions which currently hold the same icon. Also enables the display of a default cover in context view by Alexander Stippich ;
  • qml profiler shows a few percent of cpu time spent just for the creation for simple buttons for the delegates. cut this by loading on demand by Alexander Stippich ;
  • Try to find png files for covers if jpegs do not exist can probably be made a lot smarter than this, but kept it simple for now by Alexander Stippich ;
  • Try to fix build (as seen on by Matthieu Gallien ;
  • Re-order menu items to fit better with the order used in other KDE applications by Diego Gangl.


Categories: FLOSS Project Planets