Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content
Planet KDE -
Updated: 11 hours 59 min ago

Creating a Plasma Mobile application

Wednesday 20th of February 2019 09:16:15 PM

From February 4th until February 9th I attended a Plasma Mobile sprint in Berlin, Germany. I met a lot of people that share the vision of an open, privacy-friendly mobile platform. However, we all agree that such a platform can only succeed if there are enough people sharing that vision creating suitable apps for it. There already is a nice amount of mobile-friendly Linux apps, many of them created by the KDE Community, but of course we need more

One app that is essential for my use case is an app that allows me to check departures and routes for public transport. Since I’m not aware of any existing one I decided to do my own and share my road here. The purpose of this is to be educating for both me and you and to inspire you to create your own mobile-friendly Linux apps.

Like the other KDE mobile apps I’m going to use QML/QtQuick and Kirigami. QML is the declarative UI language from the Qt project. Unlike the older QWidgets it is designed with (embedded) touch systems in mind and thus is ideal for mobile apps. Kirigami is a set of QtQuick components designed for creating convergent mobile/desktop apps.

Unlike other KDE projects I’m not going to use C++ for the business logic. Instead I’m going to use Python, which is now officially supported by Qt. Since my Python skills are fairly basic this will be a fun challenge for me. Therefore take everything I write with a grain of salt and feel free to point out anything that is wrong or can be improved.

This won’t be a 100% complete reference for developing for Plasma Mobile, but I’ll try to cover as many different aspects as fit into the concept of this app. I’ll also try to focus on one aspect/feature/goal per post. Also most of this will not be specific to Plasma Mobile but will work on any desktop or mobile Linux.

So lets get started

Part 0: Basic application

Before getting started we need to install a few things. First of all we need Python (obviously) and Qt for Python. Qt for Python was formerly known as PySide2. You can install it via ‘pip install pyside2’. Next there is Kirigami. On Ubuntu you can install it via ‘sudo apt install qml-module-org-kde-kirigami2’.

After that we can start coding. The following file is creating an app and loading the UI from a .qml file. The exact details are not too important at this point.

#!/usr/bin/env python3 from PySide2.QtGui import QGuiApplication from PySide2.QtQml import QQmlApplicationEngine if __name__ == "__main__": app = QGuiApplication() engine = QQmlApplicationEngine() context = engine.rootContext() engine.load("qml/main.qml") if len(engine.rootObjects()) == 0: quit() app.exec_()

Next we need to define our UI in a QML file. To keep things organized we are going to put our QML files in a qml/ subfolder. Our first main.qml is rather simple

import QtQuick 2.2 import QtQuick.Controls 2.4 import org.kde.kirigami 2.0 as Kirigami Kirigami.ApplicationWindow { width: 480 height: 720 Label { text: "Hello world!" anchors.centerIn: parent } }

width and height are a bit arbitrary since the window will always be maximized on the phone, but this way we get a somewhat realistic window on the desktop. Executing the python file should result in something like this

In the next post we are going to fill this window with more life using QtQuick and Kirigami components. Stay tuned

The source code will be available at

Plasma 5.15.1 arrives in Cosmic backports PPA

Wednesday 20th of February 2019 09:49:33 AM

We are pleased to announce that the 1st bugfix release of Plasma 5.15, 5.15.1, is now available in our backports PPA for Cosmic 18.10.

The release announcement detailing the new features and improvements in Plasma 5.15 can be found here, while the full 5.15.1 bugfix changelog can be found here.

Released along with this new version of Plasma is an update to KDE Frameworks 5.54. (5.55 is currently in testing in Disco 19.04 and may follow in the next few weeks.)

To upgrade:

Add the following repository to your software sources list:


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

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

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

and packages then updated with

sudo apt update
sudo apt full-upgrade


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

Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

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

Networking in Berlin: Qt World Summit 2018

Tuesday 19th of February 2019 07:20:20 PM

Two months ago a small group of KDE enthusiasts, namely Adriaan, Roman, and me traveled to Berlin to attend Qt World Summit 2018.

Me posing at the KDE booth at Qt World Summit

At our little booth we showcased Plasma running on a variety of devices, ranging from a Nexus 5X running Plasma Mobile through two ARM laptops to the powerful KDE Slimbook. Plasma was praised for its performance and reliability and since the focus of the event was mostly on embedded systems, we could easily demonstrate with our selection of devices that Plasma and the KDE Frameworks are a viable option for an endeavor in this area, too.

It was very interesting to see the diverse set of people presenting their products and roaming the stalls, to see where Qt is in use today without you even realizing. We were approached by several companies evaluating using KDE Frameworks in their products and also tried to lay a foundation for an eventual partnership. And then there was Daimler who just parked an A-Class in the hallway, whose MBUX infotainment system is also powered by Qt.

Give Milian, author of hotspot (a profiler GUI we use a lot for Plasma), any device and he immediately starts profiling! What’s inside? The large box isn’t a 5¼” HDD but the battery

The star of our stand, however, was the MNT Reform DIY Laptop which is a retro-style ARM laptop running Plasma with a mechanical keyboard and even a real trackball! Its case was 3D-printed just the day before, including a rubber band to hold the screen shut, and for educational purposes sported a transparent bottom cover so you could look inside. What got us very excited was the fact that it ran mainline Debian and a super recent kernel version, something that’s quite uncommon when it comes to ARM devices. Even better: its i.MX 6 SoC let Plasma fly and we didn’t even do any adjustments for the device. It really shows that our hard performance work and focus on polishing the stack over the past years is paying off.

Qt Design Studio 1.1 released

Tuesday 19th of February 2019 12:57:01 PM

We are happy to announce the release of Qt Design Studio 1.1 !

Qt Design Studio is a UI design and development tool that enables designers and developers to rapidly prototype and develop complex UIs. Both designers and developers use Qt Design Studio and this makes collaboration between the two a lot simpler and more streamlined. To get an impression, you should watch this video.

Since the Qt Design Studio 1.0 release last year we worked hard on bug fixes and new features.

The most notable addition to Qt Design Studio 1.1 is the availability of Linux packages and merging when using the Qt Photoshop Bridge.
To learn more about the improvements and fixes, you can check out the change log.

Qt Design Studio 1.1 is available for Linux

This means that developers using Linux e.g. for embedded development can use Qt Design Studio 1.1 directly on their development system.

Qt Photoshop Bridge and updating to Qt Design Studio 1.1

The Qt Photoshop bridge allows sanitizing documents

We updated the Qt Photoshop Bridge for Qt Design Studio 1.1 and we fixed many issues.

Unfortunately, the format for the annotations by the Qt Photoshop Bridge in the PSD and the custom .metainfo file format have changed.

We will try to avoid such breakages in future, but we had to work around some limitations of Photoshop.

PSD files that already contain annotations from the Qt Photoshop Bridge 1.0, require to be sanitized.

Annotations are added whenever you export from a PSD file using the Qt Photoshop Bridge and when you explicitly use the UI of the Qt Photoshop Bridge to annotate a layer.

To remove such annotations you have to use Sanitize document in the Qt Photoshop Bridge.
After doing this you can export the PSD file and use it with Qt Design Studio 1.1.


Qt Photoshop Bridge and merging when importing

When re-importing from Photoshop to an existing Qt Design Studio project it is now possible to merge the existing QML files with the newly re-imported QML. This is very useful when the user made changes to the exported .ui.qml files using Design Studio.
Added StatesTimelinesMouseAreasAnchorsAlias Properties or Connections can now be preserved when re-importing from Photoshop and generating the new .ui.qml files.

By default, merging is not active and the importer will simply overwrite the .ui.qml file. You can enable merging using a checkbox in the import dialog.

You can find more information on the Qt Photoshop Bridge in the documentation.

The Photoshop Bridge now supports merging when importing into Qt Design Studio

Update projects from Qt Design Studio 1.0 to Qt Design Studio 1.1

If you have used Qt Design Studio before, you should update projects that you created with the wizards of Qt Design Studio 1.0 since the custom controls like shapes and effects are part of the project.

You have to update the project itself, to get the latest controls and effects.
This is possible by copying the controls from a newly created Qt Design Studio 1.1 project into the existing project from Qt Design Studio 1.0.
The folder you have to replace is “imports/QtQuick”. Replacing this folder will update the Qt Design Studio specific components that are used in your project.

Download and try out Qt Design Studio 1.1

The commercially licensed packages are available on the Qt Account Portal. You can try out and evaluate Qt Design Studio by registering for an evaluation license. We are also working on an open source version of Qt Design Studio and our target is have it out with the 1.2 release (May 2019).

Qt Design Studio 1.1 comes with new examples and updated documentation

Getting Started

You can find the latest online documentation for Qt Design Studio 1.1 here. The documentation is also available from inside Qt Design Studio.

The welcome page of Qt Design Studio contains examples and links to video tutorials to help you get started.

Please post issues you find or suggestions you have in our bug tracker.

The post Qt Design Studio 1.1 released appeared first on Qt Blog.

Plasma Pass 1.0.0

Tuesday 19th of February 2019 10:00:00 AM

Last year I wrote about Plasma Pass, a Plasma applet for the Pass password manager. Over the couple last months I got some emails from packagers from various distributions asking for a proper release so they can package it…so here it is, proudly announcing Plasma Pass 1.0.0.

Here’s a video of how it works:



SHA-256: 9821c5ad80e4370dce002855bd0300d234feec249258b01fafd9e3a9241cbc66 SHA-1: 8d877b4d4bbbbf12890ba77c03c5cdd62b8279d6 MD-5: 69928b6df32ba82d0436a6d0abf73a8a


0ABDFA55A4E6BEA99A83EA974D69557AECB13683 Daniel Vrátil <>

Feel free to report any issues or feature requests to KDE Bugzila.

Template meta-programming: Some testing and debugging tricks

Tuesday 19th of February 2019 12:00:00 AM

There are only a few things more fun in this world than doing template meta-programming (TMP) and reading all those long poems that the compiler writes out when we make even the smallest mistake.

While we don’t usually welcome these messages, there are ways to make them useful.

One of the main causes of errors in TMP code are unexpected types – types that the compiler is deducing instead of the types that we expect it to deduce.

This results in error messages occurring in seemingly random places in our code.

printf debugging

Just like it is sometimes useful to printf values in our program while debugging a problem, it can be useful to print types while debugging the problems in TMP code.

For this, here is one of my favourite meta-functions for C++:

template <typename... Ts> struct print_types;

It is a meta-function that takes several arguments, but has no implementation. Which means that every time we try to use it, the compiler will report an error along with some additional information like which Ts... we passed to the meta-function.

For example, if we wanted to know what are the exact types of std::vector<bool>::reference and friends, we could do this:

print_types< std::vector<bool>::reference, std::vector<bool>::value_type, std::vector<bool>::iterator >{};

And the compiler will print out an error message along these lines:

invalid use of incomplete type 'class print_types< std::_Bit_reference, bool, std::_Bit_iterator >'

The compiler printed out all three types that we requested it to print.

This can be used in conjunction with some compiler output post-processing – shortening some type names like std::basic_string<char> to string etc, replacing < and > with ( and ) and putting the output through clang-format to get a pretty readable and nice formatted output for complex types.

For example, this is the output generated for one expression template in my codebase:

expression( expression( void, expression(PRODUCER, expression(PRODUCER, ping_process, transform("(λ tests_multiprocess.cpp:91:26)")), transform("(λ tests_multiprocess.cpp:82:38)"))), expression( TRAFO, expression(TRAFO, expression(TRAFO, expression(TRAFO, identity_fn, transform("(λ tests_multiprocess.cpp:99:26)")), … Printing types several times

The problem with the previous approach is that you can call print_types only once – as soon as the compiler encounters it, it will report an error and stop.

Instead of triggering an error, we might want to try something else – something that the compiler reports without stopping the compilation – we could trigger a warning instead.

One of the easiest warnings to trigger is the deprecation warning – we just need to mark the print_types class as [[deprecated]].

template <typename... Ts> struct [[deprecated]] print_types {};

This way, we can use it multiple times and the compiler will generate a warning for each of the usages. Now, this works well with clang because it reports the whole type that triggered the warning. Other compilers might not be that detailed when reporting warnings so your mileage might vary.

Assertions on types

When you write TMP code, it is useful to assert that the types you’re getting have some desired property.

For example, it is a sane default (just like const is a sane default for everything) to expect all template parameters to be value types. For this, you could create an assertion macro and sprinkle it all over your codebase:

#define assert_value_type(T) \ static_assert( \ std::is_same_v<T, std::remove_cvref_t<T>>, \ "Not a value type")

Having the habit of adding assertions like these can make your life much easier down the road.

Tests on types

Just like the original print_types we defined stops the compilation when called, static_assert stops compilation as soon as the first one fails.

What if we wanted just to get notified that a test failed, without it stopping the compilation.

We can use the same trick we used to allow print_types to be called several times. We can use the [[deprecated]] annotation to get a warning instead of getting an error with static_assert.

This can be implemented in several ways. The main gist of all the solutions is to create a class template which is then specialized for false or std::false_type and that specialization is marked as deprecated.

Here is one of the more fun implementations:

template <typename T> struct static_test { static_test(std::true_type) {} }; template <> struct [[deprecated]] static_test { static_test(std::false_type) {} }; template <typename T> static_test(T x) -> static_test<T>;

And the usage is quite simple:

static_test int_is_int { std::is_same<int, int>::type{} };

Whenever a test returns std::false_type, we are going to get a deprecation warning.


Working with templates allows us to do awesome things but it can be quite tedious. Small tricks like these can make working with templates a breeze.

You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing.

Cutelyst 2.7.0 released, async is back!

Monday 18th of February 2019 08:29:25 PM

Cutelyst a Qt/C++ Web Framework just got a new version. This time bringing back proper async support.

Perl Catalyst Framework was conceived as a sync/blocking framework, due that the Mojolicious framework was created, NodeJS and a few other web frameworks have pushed the async programming to the web. Performance wise being async doesn’t mean you get faster response times, rather the opposite, the need to unroll stack and make extra calls makes a CPU bound application slower.

But depending on the problem to solve it allows you to serve more users at the same time, using the same CPU cores. A typical modern application might receive a request from a Phone App then do a REST API call to an external API which might take 2ms or 200ms for the reply. While waiting for the response, typical sync/blocking applications can’t process more requests, or have to spawn more threads increasing RAM consumption and leveraging concurrency to the OS scheduler. On an Async web application, you can process another request while you wait for the previous request, thus possibly making the first request reply to be sent back to the user at a later time than if there was a dedicated process just waiting for his reply.

So, both ways have pros and cons and IMHO I’d like to support them both. When I started Cutelyst I thought that if I ever need async I could have a local QEventLoop to wait for the reply and would be able to deal with async requests, not recently I found out that supporting QEventLoop was causing stack overflow due it being used in pipelined scenarios, after that I removed it’s usage and performance improved in PlainText tests of TechEmpower, so I advised against using it and marked Cutelyst as not async.

Recently I got the need to call a few APIs from a REST API I did with Cutelyst, QNeworkAccessManager is an async only API, so either I create a thread for it to mimic sync behavior or allow Cutelyst to be used in async mode, of course I did the latter. The Context class has now detachAsync() and attachAsync() methods.

When you c->detachAsync(), you tell the engine to not send the headers and body immediately to the client, this will also break the action chain, meaning an end() method won’t be called, then when you get your async reply you call c->attachAsync().

Once c->attachAsync() is called the action chain is resumed so the end() method that possibly would render the HTML can perform it’s job.

It’s important to always be child ( QObject->setParent(…) ) of the Context pointer as if the client closes the connection it might be deleted.

This release was not only made of async:

  • A helper UserAgent singleton was added so that you have a thread_local QNetworkAccessManager with static methods to do more common REST tasks like sending a QJsonObject (yes, eventually I find time to write a patch for QNAM)
  • A new Sql::Transaction class gives you a scoped SQL transaction, preventing the mistake of not rolling back when you leave the scope in case of an error.
  • A few Headers helpers like ETag and If-Match comparison
  • Sebastian Held added support for dealing with Front-End Proxy Headers
  • Improved Stats precision using QElapsedTimer::nsecsElapsed()

And finally Cutelyst is not “half modern” CMake anymore, if that can even exist. The include directories of the exported Targets are now properly exported, so that you can remove:

include_directories( ${Cutelyst2Qt5_INCLUDE_DIR} )

Have fun

Interview with Noemie Scherer

Monday 18th of February 2019 07:33:38 AM
Could you tell us something about yourself?

Hi! I’m a European Krita user.

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

I’m kind of in-between. I finished art school not too long ago, and I’m hoping to find a job or commissions so I could keep painting and actually earn money from it. I also do 3D and programming, but I’d love to keep doing all three without having to abandon any.

What genre(s) do you work in?

I like to try out different things, but for my main style, I’d say… illustrative? One thing’s for sure, though: my favorite theme is animals.

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

I don’t really have one artist that I look up to, but more like a series of temporary stylistic crushes. Right now I’d say oddsbod, the video game Transistor by supergiant games, illustrator and video games 3D artist Heather Penn  I also read a lot of webcomics, and I admire the style of paranatural, vainglorious, inhibit (that are all three really expressive and energetic), stand still stay silent (beautiful), and barbarous (a bit of both).

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

That was more than ten years ago. I was something like ten, maybe twelve at most. A friend of mine had a photographer father, so I went to their house and could try his drawing tablet, and it was really cool; some time later my parents got me one (one of those small A6 ones), and my brother downloaded Gimp, probably for a birthday (he was -still is- really into open source).

What makes you choose digital over traditional painting?

At first it was the novelty, and the ease with which you could have really vivid colours; then, it was the lack of waste when you drew something you didn’t like and the immateriality of what you spent to draw: no heavy expensive paper wasted, no limited supply of colours – I never finished a gouache tube or a pastel stick, but I could see the point where there would be no more. No so with digital art. And now I’m just more used to it.

I haven’t left traditional forever though, I still go to the zoo to draw in a sketchbook, and every so often I include painted textures to my digital stuff. I’d like to experiment more with traditional techniques at some point.

How did you find out about Krita?

I didn’t actually need another drawing software, so I wasn’t looking, but then my brother told me “look at that awesome new (open source) drawing software, they actually ask their artists what they want/need”. I didn’t change right away (switching softwares is always a bit of an investment), but I did eventually try it out and I loved the brushes and I stayed. I remember it was the year of the sheep, probably around February (Chinese New Year), so the first drawing I ever made in Krita was a sheep head with one of the sketch brushes.

What was your first impression?

I loved the brushes. I didn’t use the sketch ones so much, though they definitely were a fun introduction to Krita, but I fell in love with the soft kind of blur of the wet ones. There actually was the same thing in TVPaint (an animation software), which I used in my animation school, but I felt like krita had more options painting-wise.

What do you love about Krita?

The brush engines, definitely. They have incredible diversity. Also I learnt how the assistant tool worked a few weeks ago (it was one of those  things you know exist but never got around to actually check), and it looks really cool (it can be used for drawing perspective, geometric patterns in your image, and more). And the animation system is nice, and way better than photoshop’s (which I deeply hate). It still needs some tweaks to actually be efficient in short films (most of all a way to colour that would be semi-automated over the timeline instead of by frame) but I’ve read somewhere it’s on the todo list. And I recently started doing repeating patterns, and the wrap-around mode is very useful, as instead of offsetting and copying the image every time you’re finished with one step you can just… draw… without worrying about seams.

The way people are always there to help, on reddit, the Ask Krita website, or the IRC channel (even developers!).

Also the fact that since it’s open source, if I want to I can just add the functionalities I need, and then if it’s a good addition it’ll get added to the software and made available to everybody.

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

Like I said, the animation system needs improvement. The bases are solid, but since it’s still very young, it has room to grow.

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

Well, I do use it as my main art program, so I use no other (2D) programs to compare it to.

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

This one [tern.jpg]. I did it as a birthday gift to someone I was missing, so I’m emotionally attached to it. I also like the format and the feeling of
space it gives.

What techniques and brushes did you use in it?

I used a round wet brush (it gives better gradients than the gradient tool if you’re going for a painted look and have large surfaces to fill), and the
shape tool as an eraser. For the mountains, and the sea, I drew them on separate layers, locked the alpha, and used wide brush sweeps over the opaque parts.

You’re a Krita contributor; how did you get into that?

Short version: stuff needed doing (to be used in my workflow), I was able to do it, and nobody else was currently doing it.

Long version: Something like one year ago, I was doing a pixel art animation in krita, and I needed to export an animation into a spritesheet for a game. At first I did it manually, then pretty quickly when I grew bored of it I looked on the internet and found a plugin that did it for gimp. So I exported all my images, imported them into gimp and exported them again, through this plugin, as a spritesheet. It was pretty unwieldy, plus the plugin only exported as a single line so I had to actually change the code every time I wanted to change the options, and every time I changed the animation I had to do it all over again. But I knew there was to be the python plugin interface for krita, so I waited.

Then a few weeks back I actually had some time, so I checked nobody had done it in the meantime and I made the export to spritesheet python plugin. Then there was one part of it that was actually already included in krita, but lacked a small option to be completely functional, so I built krita and changed it.

And now that I worked on this very small change of krita’s source code, I actually feel confident enough to imagine doing bigger contributions.

Where can people see more of your work?

I have stuff all over the place.

For a bit of everything I do, finished and sorted, go there:
For finished art, sorted, go there:
For art (including sketches and WIPS) posted on a semi-regular schedule:
For (digital) art you can buy, and also games:
For tumblr-is-dying-and-instagram-is-more-fashionable-those-days:

This week in Usability & Productivity, part 58

Sunday 17th of February 2019 07:01:27 AM

Week 58 for KDE’s Usability & Productivity initiative is here! Hot on the heels of last week’s update, we’ve got lots of nice goodies to share:

New Features Bugfixes & Performance Improvements User Interface Improvements

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

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

Latte and a Colors tale...

Saturday 16th of February 2019 05:28:01 PM

A few months ago while I was scratching Latte Dock limits an idea came and haunted my thoughts. How Latte could give the colors freedom for panels and windows that an Android phone already provides? Questions like this arose and solutions appeared suddenly in many different places, but an important and concrete dream prevail in the end.

“Lets have panels and docks that understand their environment and adjust their colors and settings accordingly”

- youtube presentation -

How far would we like this dream to go, what are the limits?

An initial effort was landed at v0.8 through the Dynamic Background options but of course it was very limited. Step by step with patience the following goals appeared after version 0.8

Panels that:
  • can understand the underlying background independent of screen
  • color themselves according to the underlying background in order to provide the best contrast when they are transparent
  • can understand busy backgrounds (elementary style) in order to provide enough contrast
  • solidify themselves at some circumstances
  • understand when a window is touching them and paint themselves based on that window colors
  • can choose to be light or dark but at the same time to be based on the current plasma theme
  • provide an easy and elegant way to support the above features

Someone could ask, What nice features to have in my system but how long do you think it will be needed to provide them? one, two years?  who knows maybe never…
Well the thing is that this article does not describe the future but rather the PRESENT… All the above are currently supported from Latte git version. With their limits of course that arose from the current technology but nonetheless they are here…

What is needed in my system?

(advanced settings)
How can I enable these features in Latte git version?

After you install above requirements you can find these features at Latte Appearance settings. Latte Advanced settings has been reorganized and improved in order to provide you with a full screen height window at the edge of the screen. The new settings moto is:

“easy to find, simple to understand”

the settings work has not ended yet so more improvements will be presented in the future.

How can Latte understand which is the underlying background?

Latte tracks the plasma config files and discovers for each screen what is the current background used. It can understand only background image files or single colors. For each one it produces a brightness value for each different edge and at the same time if the background in that edge is busy. That means that a bottom dock can be light and a top panel can be dark in order for both to be presented correctly to the user. The same of course applies to different screens because screens can have backgrounds with different brightness.
In case you are using a gif animator or video playing for your background and the brightness is not identified correctly you could try the following. Make a representing screenshot from the mentioned video and assign that image as a background. You can afterwards reenable your background video because Latte will use that screenshot to identify the different brightness values for the edges.

Can a plasma theme choose to be dark or light dynamically?
Materia dark theme
in Latte Reversed Colors mode
Well the answer is by default it can not. Each plasma theme can be either light or dark and that is an important decision from its designer. Latte did not want to break the designer style so in order to solve this is trying the following.
Latte understands if a plasma theme is dark or light and independent of that it creates a reversed color palette. For example the background color will become the text color and the text color will become the background color. This way the colors used do not look too different.

At the same time in order for Latte to paint correctly a reversed colored background the plasma theme panel roundness needs to be known (how rounded are the panels in the corners). Latte already provides a file that describes the panels roundness for the most known plasma themes but if the theme does not exist in the file or the user just wants to bypass it he can adjust the plasma roundness in pixels through the Latte Preferences window.

How Latte can know what is the color scheme for each window?
The earlier mentioned KWin script sends through dbus the color schemes for windows that do not use the default applied color scheme. When these messages reach Latte are filed and thus Latte whenever needs to, can provide a proper color palette to be consumed by panels and applets.

What are the limits?

The new coloring mechanism needs to be supported from applets in order to be painted correctly at all cases. Currently there are four applets supporting it, Latte taskmanager, Window Title, Window AppMenu and Window Buttons . For the rest the user must choose whether the colorize effect should be applied or not. For example the plasma analog clock that is not monochromatic it should not be painted at all cases. The new option to disable the painting can be found at applet tooltip in edit mode.

left: analog clock with no painting / center: analog clock with painting / right: tooltip to disable painting


That is all for now, I hope you enjoy these new features, personally I love them...


You can find Latte at Liberapay if you want to support,    

or you can split your donation between my active projects in kde store.

Latte bug fix release v0.8.6

Saturday 16th of February 2019 01:36:03 PM

Latte Dock v0.8.6   has been released containing important fixes and improvements!

Go get  v0.8.6   from, download.kde.orgor*

-----* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E
  • fix previews that broke after kde frameworks 5.55 update
  • fix shortcuts behavior from plasma applets when using "Multiple" layouts


You can find Latte at Liberapay if you want to support,    

or you can split your donation between my active projects in kde store.

Opening Files with Qt on Android

Saturday 16th of February 2019 09:45:00 AM

After addressing Android support in KF5Notifications another fairly generic task that so far required Android specific code is next: opening files. Due to the security isolation of apps and the way the native “file dialog” works on Android this is quite different from other platforms, which makes application code a bit ugly. This can be fixed in Qt though.

Qt 5.12 and before

On most platforms, allowing the user to open a file in an application works like this:

  • Request the native file dialog via the corresponding widget or QML API, both of which go through the same internal platform integration plugin in Qt.
  • Retrieve a file path from the file dialog.
  • Open that path with QFile.

On Android so far we had to do the following:

  • Request the native “file dialog” (it’s essentially the file brower app) via an Intent.
  • Retrieve a content: URL from that Intent.
  • Use the Java ContentResolver API to open a file descriptor for that content: URL.
  • Pass that file descriptor to C++ and read it via QFile.

While the Intent details could be hidden behind the native file dialog abstraction in Qt, the problem then is still that the returned URL isn’t pointing to a local file that subsequent code might expect. There’s a good reason why Android does it that way though, as this allows applications to only access files that the user explicitly selected, without the need of full file system access permissions.

Qt 5.13 and beyond

A way to address this is a QAbstractFileEngine implementation to add support for content: URLs to QFile. This is the same approach taken already for e.g. asset: URLs. It’s actually not particularly complicated as all we need to do is obtain a file descriptor for a content: URL, and then hand over to the existing regualr file system backend, which implements everything else we need already.

KDE Itinerary is already using this approach as a testing ground, and this week this also landed upstream in Qt, to be included in the 5.13 release.

At the same time Nicolas added support for native file dialogs on Android, as well as content URL support in QML. With all that combined opening a file should (almost) work with identical code on all platforms.

One small caveat remains, the fact that you have to deal with URLs correctly throughout your file handling code. If you at some point convert to a local file path, this is going to break when encountering a content: URL.

The Long Road to Long-Term Goals

Friday 15th of February 2019 06:25:15 PM

If there is one thing you can learn from creative writing school, it is that you have to give your characters at least three good reasons before they should consider doing anything.

KDE Promo contributors recently completed drafting and editing a document that lays out the long-term goals for the Promo workgroup. This has proven a complex and tedious task, but we were compelled because we had those three good reasons:

  1. Having long-term goals laid out in front of us gives a clear direction in which to work.
  2. Concrete goals also help us differentiate between what is important and what is secondary; between what we can do with the resources we have, and what we may have to put on hold or even forget about completely.
  3. Goals help clarify to others why we do what we do. When our peers understand what we intend to achieve, it saves time because we don’t have to lay out every step of every process every single time to justify your actions.
But… what does “Long Term” mean to you?

After several back-and-forths on Phabricator, we ended up defining “long term” as “5 years”. We have also associated concrete numbers with each goal, things like “Promo intends to help increase the number of desktop end users by 2% over the next 5 years“, to provide specific baseline for each overarching action. This will help us assess the degree of success for each goal…

…or adjust our expectations to reality the next time we have to write something similar. Many of the numbers in the goals are dictated solely by what we currently feel is right. Since many of the goals have never been attempted, we can only speculate as to what they will take. Many of the baselines will probably have to change over time as we get more data that helps us make more realistic predictions.

How are you going to do it?

When you read through the list, you will see a pattern emerge: there is a lot of going to events, hoping to talk to head-honchos, sending emails into the void, getting in touch with people we have never met; lots of knocking on doors not knowing if we will have them slammed back in our faces.

Achieving goals through these means may sound like taking very long shots, but we do have a massive community on our side. For one, there’s the fact that, despite some exaggerated reports to the contrary, KDE is a force to be considered. I would not say that claiming you come on behalf of KDE will open every door, but it has helped us in the past, even when cold-calling, and it will continue to help us in the future.

Then there is the the friend-of-a-friend resource: in a community as large and with members in such far-flung places, from Korea to Kentucky, and from Norway to Nigeria, we want to be able to use members of our community as ambassadors to our cause. Thanks to our community, there will always be somebody who knows someone who can get us into meetings with the people we need to talk to.

And who are these people? Well, they are those who can help us reach ever larger audiences, while at the same time consolidating and helping us grow our community. We are talking about journalists, “influencers” (yes, I hate that word too), bloggers, vloggers, podcasters and so on. We also want to talk to businesses that may benefit from developing with our tools and frameworks.

The idea is to gradually expand our area of influence among users and companies beyond those that are already convinced of KDE’s virtues, even beyond those that are diehard Free software advocates and users. We want to reach more mainstream users, users and developers that may not even have heard of KDE.

This is where you can help: if you know a “celebrity”, influencer, or talented writer, a Youtuber, blogger, or good podcaster – introduce us! We want as much coverage as we can decently get, and content creators are often looking for topics they can talk about. We may be able to provide them with some juicy stories and get the word out to people we otherwise wouldn’t be able to reach. The same goes for journalists in mainstream or specialised publications, politicians, and decisions-makers in companies big, medium or small.

It may seem like the number of things we can do (tweeting, going to events, putting out press releases and blog posts, contacting journalists, talking to managers) is limited and very unexciting. This is true: there are no clever shortcuts or breakthrough techniques you can apply here. However, the fun is in the twists and turns you apply to these things.

You may have noticed we always try to a post an attractive picture with everything we send on to social media or publish on the Dot. We make meme jokes, jump on trending bandwagons, and often ask members from other workgroups and projects to let us look at what they want to submit to social media so we can give it a whirl. We believe you can always write and engineer a message in a way it can entice more people.

This sounds terribly conceited. How do you know you are right about this?

TL;DR: We don’t.

It is always hard to prove anything we do has a positive effect on KDE’s popularity and adoption. It stands to reason it be so, but there is no hard way to say for sure. The only thing we can do is look at the numbers over time and try to discover a correlation between actions and effects.

We monitor most social media platforms, regularly taking data from LinkedIn, Twitter, Mastodon, Facebook and so on. We also monitor Debian’s popcons (popularity contests) every week and store all the data in a folder on

This is where you can help: a lot of the data collection and processing is done by hand. There are services that could help us, but very often they are proprietary, tie us to their online storage services, and/or don’t cover all the bases, leaving out things like Mastodon, PeerTube or Diaspora.

We are also aware of how inadequate the sources we mine are. We really don’t have a good way of knowing, for example, how many times KDE software gets installed in distributions, so it is nearly impossible to figure out how many silent users are out there.

Point us to solutions and tell us about sources we can mine. This helps us get a better idea of how things are going for us on a global scale. It will also contribute to figuring out if what we are doing is helping or not.

We also need to know where we stand within our own community. Because of this, we are creating a survey that will help us understand better who our peers are. While the survey may confirm things we already suspect, it will also tell us about the big absences.

A good way to grow a community is by looking further afield, into audiences different from what we already have. As different people respond to different things, knowing who we are missing can help us shape activities to attract them.

This is where you can help: please answer our surveys! All information is anonymised and you obviously can ignore questions that you don’t want to answer. But even incomplete information will help us learn what sort of people we click with, and put us on the road to answering the question of why some people just don’t get bitten by the KDE bu–… er… dragon.

Notwithstanding, market research is far from a hard science, and it is frustrating not being able to confirm without a shadow of a doubt that we are doing a good job.

That must be annoying…

Talking of annoying, it is important to remember that most things in business fall through. Most meetings lead to nothing, most agreements end up producing nothing useful, most promises are broken. This is not because businesspeople are unreliable. The problem is priorities shift, other more urgent or more auspicious things pop up, and businesspeople are obliged to implement a better strategy for their companies if the opportunity arises, even if it means ditching an agreement with certain Free software communities.

But even a 90% failure rate is nothing to be disillusioned about. Quite the contrary: if you give up after a couple of let-downs, you are guaranteed not to succeed ever. Promo casts its nets wide and latches onto as many plausible-sounding agreements it can. We try to follow through until it is either clear it is going nowhere, it is not going to work in our favour, or it is no longer our business and we need to pass it on to someone who can sign on the dotted line — Promo does not have a say in the conditions of final agreements.

In fact, Promo has very little say in anything. If you read through the list of goals and how we intend to carry them out, it should be clear that Promo doesn’t dictate or even want to dictate what the rest of the community should do. We won’t even tell you to re-design your project’s website to make it more attractive and useful to your visitors. We will probably tell you that you _should_ re-design your site, and even help you do it, but we won’t tell you you have to.

We work with the things we have. We try to tell the rest of the world how KDE and our projects are attractive. We try and improve our hand by advising on wording in announcements, layouts on web pages, and communication at events. In short, we aspire to be the community’s PR firm.

This where you can help… Or, more precisely: we can help you. Come and visit us in our IRC channel, Telegram group or mailing list, and we can start working together to improve your online presence, get your project into the media, and grow your userbase.

We are already working consistently with Krita, Kdenlive, Atelier, Kontact, Plasma, Plasma Mobile and many others. As it is difficult to keep track of all the projects within KDE and the people behind them (this community is big), we often need you to come and tell us.

The point is, we are here for you… even if we don’t know who you are yet!

So the best way to get a handle on Promo is to read through the goals. And if things are still not clear or you need more details, come and talk to us. We at KDE Promo are a welcoming lot!

A mobile Plasma Sprint

Thursday 14th of February 2019 04:54:19 PM

I was last week in Berlin at the Plasma Mobile sprint, graciously hosted by Endocode, almost exactly 9 years after the first Plasma Mobile sprint in which we first started to explore Plasma and other software by KDE on mobile phones, which at the time were just starting to become powerful enough to run a full Linux stack (Hi N900!)

Now the project got a wide breath of fresh air: the thing that impressed me the most was how many new faces came at the sprint and are now part of the project.

Compared to 9 years ago, we have a way saner and more robust ecosystem to play on. Instead of a single (and quite underpowered) phone, which was the N900, now we can hack on a wide variety of phones, thanks to ARM being slightly less painful to work with compared to back then (even tough still a long way to go to be considered an open hackable system from nay point of view) Some devices are starting to get upstream mainline kernel support, and for those (unfortunately, most) who don’t there is the Halium project to the rescue, which provides an abstraction layer between the Android kernel and the “proper Linux” userland, making possible to use its graphjics drivers to drive a Wayland session, access audio and connectivity and so on.

We have a Neon version which supports a reference device (the old Nexus-5x) which can be easily adapted to other devices, and PostmarketOS, which is a distribution which supports many different phones and several user interfaces, Plasma Mobile being one of the official ones. At the sprint there were also some people from the PostmarketOS project: one of the things i love most of open source is when different projects collaborate so closely.

We had also some new toys to play with: people from Purism were also present, bringing development kits for their upcoming Librem5 phone, which will support mainline kernel and no need for closed Android drivers. Even tough a lot of work is stil lto do, Plasma Mobile already boots on the device.

Plasma Mobile running on a Librem 5 devkit.

As for Plasma Mobile software in itself, we did many bugfixes on the main shell/homescreen to have a better first impact, and a significant improvement came in KWin about high DPI scaling when running on an Halium system.

Also, many improvoements were done in the Kirigami framework, which is the main toolkit recommended to be used to build applications for Plasma Mobile: as developers of several applications that use Kirigami were present there, we could do very fast feedback and debug sessions.

G+ Takeout

Thursday 14th of February 2019 04:50:13 PM

Google+ does rather killoff the notion I had of Google as a highly efficient company who always produce top quality work.  Even using the takeout website to download the content from Google+ I found a number of obvious bugs and poor features.  But I did get my photos in the end so for old times sakes here’s a random selection.

A marketing campaign that failed to take off

Sprints in Munich thanks to the city council’s KDE deployment were always fun.

Launching KDE neon with some pics of my office and local castle.

One day I took a trip with Nim to Wales and woke up in somewhere suspiciously like the Shire from Lord of the Rings

KDE neon means business

Time to go surfing. This ended up as a music video.

That’s about it.  Cheereo Google+, I’ve removed you from, one social media platform too many for this small world.


Qt on CMake Workshop Summary – Feb 2019

Thursday 14th of February 2019 12:24:28 PM

Last Monday and Tuesday a few brave souls from both the Qt Company and KDAB gathered together in the KDAB Berlin office premises to work on the CMake build system for building Qt. There was Mikhail, Liang, Tobias, Kai, Simon (QtCompany) as well as Jean-Michaël, Albert, Volker and me (KDAB) sitting together in a tight room, focusing solely on the CMake port of Qt.

Excerpt of the top-level CMakeLists.txt in qtbase.git

All work done so far is out in public and can be checked out on Qt Gerrit.

About the CMake port

To put this a bit more into context, the Qt Project believes that building Qt with CMake is our best bet in Qt6 times and thus a group of people have started to build a CMake build system prototype. KDAB has a track record of helping out with the CMake support in Qt. For instance most of the “Modern CMake”-style support in Qt5 has been implemented by Stephen Kelly. As of today, we’re even largely responsible for maintaining the CMake support of Qt5. Since quite a few of our customers are actually heavily invested in CMake themselves, we’d also like to make sure Qt stays easy to use with it in future. Thus we’re continuing to invest in Qt’s CMake support and would like to help out with the early Qt6 build system exploration happening right now.

The central page where we’re currently collecting the progress made as well as the future roadmap is here:

On that page you’ll also learn which branch to check out from Gerrit in order to start playing around with the current state of the Qt/CMake build. Please make sure to have the prerequisites for building the branch (i.e. a current CMake build!).

Workshop Summary

As Simon mentioned in his workshop summary, sent to the qt-development mailing list, we were able to make good progress on multiple fronts the last few days. Let me just outline his notes part of that mail, with some additional comments of my own:

Quoting Simon
  • We were able to fix the artifacts of “make install” in qtbase to allow for building an external module (qtsvg) and sample apps. The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:
    1. In your application use either find_package(Qt5) or find_package(Qt6)
    2. Always use Qt::Core, Qt::Gui, etc. for linkage
    3. We want to add the “plain” Qt::Core, Qt::Gui, targets also to Qt5’s CMake support
  • The script to converting .pro files to CMakeLists.txt is becoming really good. The goal is to convert all scopes and (source) file names correctly. Right now the repo contains incremental conversions with hand-edits.
  • We’re working on installing the latest CMake (as required) in the provisioning setup, so that we can get a building CI as soon as possible.
  • We were able to verify that cross-compilation works well. The main challenge is ensuring that third-party libraries that used to be copied in src/3rdparty are either installed in the sysroot or can be found outside.
  • We discussed and experimented with different ways of making static builds robust. So static builds themselves work already, but what we’re looking into in particular is an automatic way of propagating Qt internal dependencies (such as double-conversion) correctly, to the build process of the application, that is not fragile.
  • We added a lot more plugins and platform support libraries to the build process and did many improvements to the finding of external libraries.
More than that
  • Additionally we’ve succeeded in generating CMake config files compatible with the current config files generated by the Qt/QMake build
    • For instance, we’ve been able to successfully compile KDAB’s GammaRay (which has a rather complex beast of a CMake build system) against the Qt/CMake build of qtbase
  • We were able to compile QMake using CMake in order to retain the support of using QMake to compile Qt projects for existing users of Qt/QMake
Outlook on the future
  • We’ll investigate ensuring a smooth Qt build process on macOS and Windows platforms for developers
  • We’ll add the CMake build system to other Qt modules (thinking of qtsvg (rather simple), qtdeclarative (rather complex))
  • We’ll add a super build which takes care of building multiple Qt modules in one go (cf. a top-level build off from qt5.git)
  • Test more cross-compilation configurations
  • Make sure static builds of Qt are not a pain to deal with for external users (like it is right now)
  • Make sure to continuously test the Qt/CMake build using basic CI build support.
  • QMake will likely still be around in future Qt6 times, as there’s still a lot of users out there. The difference will just be that QMake itself is built using CMake inside qtbase.git; and QMake’s module .pri files will get generated by CMake instead.
    • Obviously exactly the other way around to what it is right now in Qt5/QMake, where QMake generates the CMake config files for CMake!

If you have comments or if you want to help out, please ideally post feedback on the Qt Project infrastructure. Send a mail to the qt-development mailing list or comment on the wiki page dedicated for the CMake port. Or just join us in the IRC channel #qt-cmake on Freenode!

The post Qt on CMake Workshop Summary – Feb 2019 appeared first on KDAB.

Frameworks 5.55.0, Plasma 5.15.0, and Applications 18.12.2 by KDE are now available

Thursday 14th of February 2019 09:46:09 AM

@totte wrote:

Also available in French, Italian, Simplified Chinese, and Traditional Chinese.

The following updates have been tested, and are now available.

Name Version Frameworks 5.55.0 Plasma 5.15.0 Applications 18.12.2

Most of our mirrors synchronize with the central repositories on the origin server within 24 hours. Use the mirror status web page to see when your mirror of choice last synchronized. Run sudo pacman -Syu to update and upgrade your system. If you have any issues updating or upgrading, reply to this topic with the complete input and output in English, i.e. run LC_ALL=C sudo pacman -Syu.

konqi.png800×580 281 KB
“The KDE dragons” by Tyson Tan, Creative Commons BY-SA, made with Krita.

Posts: 3

Participants: 2

Read full topic

KDE neon on xenial/16.04 EOL

Wednesday 13th of February 2019 04:37:55 PM

KDE neon was rebased onto Ubuntu bionic/18.04 last year and upgrades have gone generally smooth. We have removed xenial/16.04 build from our machines (they only hang around for as long as they did because it took a while to move the Snap builds away from them) and the apt repo will remove soon. If you haven’t already upgrade now.

Month of KDE Applications Snaps

Wednesday 13th of February 2019 04:10:59 PM

Snaps is a fancy new package format for Linux which allows applications to be shipped which run on pretty much any Linux distro. This nicely solves one of the headaches with shipping software for Linux, that you have to package it a dozen times using a dozen different methods to get anyone to be able to install it.

The format and host for Snaps is made using Ubuntu and developed by KDE patron Canonical.

We have been working on building Snaps from the KDE neon builders for some time and they’re now at a quality where we can move them into the stable channel. (Snap software gets hosted in channels depending on the risk you want to take, others being candidate, beta and edge.)

If you’re a Plasma user you can use Discover to install the Snaps, but of course they work equally well on other desktops with other package managers or using the snap command.

This month the Snap team are highlighting KDE’s stable Snaps on their Twitter and Facebook feeds. Here’s what we’ve seen so far:

KTurtle is an educational programming environment from #KDE for #Linux. It features intuitive syntax highlighting, simple error messages, an integrated drawing canvas, slow-motion, and step execution.

snap install kturtle

— Snapcraft (@snapcraftio) February 11, 2019

Do you feel puzzled? No reason for that. Palapeli is a single-player jigsaw puzzle game from #KDE. Freely movable pieces, real persistency, and fun.

snap install palapeli

— Snapcraft (@snapcraftio) February 8, 2019

Krita is a professional FREE and open source painting program . It is made by artists that want to see affordable art tools for everyone . The latest version of Krita, built on #KDE is now available as a snap.

snap install krita

— Snapcraft (@snapcraftio) February 6, 2019

Remotely view and control your systems with the latest KRDC from #KDE. Supporting VNC and RDP protocols, this open source client for #Linux can connect to Windows Terminal Servers and many other platforms . Now available as a snap!

snap install krdc

— Snapcraft (@snapcraftio) February 4, 2019

A month of #KDE in snaps: Eyes on the files, please! Okular is a universal document viewer, with annotations, bookmarks, support for PDF, PS, DVI, EPub, and many other formats.

snap install okular

— Snapcraft (@snapcraftio) February 1, 2019

There’s still plenty of KDE apps that need tweaks before they can go in the Snap stable channel. If you’re an app maintainer then come and talk to us (in #kde-neon probably) about how your app can be distributed. We plan on doing some automated QA so they don’t need manual review before publishing and before long hopefully we can move much of the build details into the app repo rather than the KDE neon repo.

Skrooge 2.18.0 released

Monday 11th of February 2019 09:05:13 PM

The Skrooge Team announces the release 2.18.0 version of its popular Personal Finances Manager based on KDE Frameworks

  • Correction bug 403575: skrooge w/ -DSKG_WEBENGINE=ON: ui_skgtablewithgraph.h:15:10: fatal error: QtWebKitWidgets/QWebView: No such file or directory
  • Correction bug 403675: App crashes with segfault after second import
  • Correction bug 402330: error importing QIF File "SKGImportPluginQif::importFile() RC=[ERR-5]: SKGCategoryObject::addCategory failed because linked object is not yet saved in the database.
  • Correction bug 403725: import Quicken tags from QIF as Skrooge trackers
  • Correction bug 403985: kgbasegui/skgwebview.h:28:10: fatal error: qwebview.h: No such file or directory
  • Correction: Import KMYMONEY with non utf8 characters doesn't work (see
  • Correction: Import KMYMONEY of scheduled operations from the next operation to add instead of the first one (to avoid duplicate) 
  • Correction: Import KMYMONEY of shares with only one split must be done with the unit of the share
  • Correction: Nb occurrences and last date are not aligned on weekly schedules
  • Correction: Display all occurrences of a schedule in dashboard not only the first one 
  • Correction: Display the currency symbol at the right place in scheduled operations 
  • Correction: Display correctly the amount in "highlighted operations" in dashboard  
  • Correction: The advice "Advice are very long to compute" can now be rejected
  • Correction: Add date in "Bank (light)" widget in html mode 
  • Correction: Remove template from "Highlighted operation" widget 
  • Feature: Better help for "Internet code" of sources in unit page
  • Feature: New MSN source of download for quotes
  • Feature: File can be made anonymous in a reversible mode 
  • Feature: In "Operations" page, possibility to view all operations of an account + its credit cards associated
  • Feature: The number of years for forecasts based on scheduled operations can be choosen from settings 
  • Feature: Possibility to choose the max date of schedules in dashboard  
  • Feature: New action to skip scheduled operations
  • Feature: Possibility to skip scheduled operations from dashboard
  • Feature: Addition of options (Incomes, Expenditures, Transfers, ...) in contextual menu of graphs in "Account" page 
  • Feature: Addition of options (Days, Weeks, Months, ...) in contextual menu of graphs in "Account" page 
Get it, Try it, Love it...

Grab Skrooge from your distro's packaging system. If it is not yet included in repositories, go get it from our website, and bug your favorite distro for inclusion.

Now, you can try the appimage too !

If you want to help me to industrialise the windows version, you can get it from here:

Get Involved

To enhance Skrooge, we need you ! There are many ways you can help us:

  • Submit bug reports
  • Discuss on the KDE forum
  • Contact us, give us your ideas, explain us where we can improve...
  • Can you design good interfaces ? Can you code ? Have webmaster skills ? Are you a billionaire looking for a worthy investment ? We will be very pleased in welcoming you in the skrooge team, contact us !

More in Tux Machines

Server: HTTP Clients, IIS DDoS and 'DevOps' Hype From Red Hat

  • What are good command line HTTP clients?
    The whole is greater than the sum of its parts is a very famous quote from Aristotle, a Greek philosopher and scientist. This quote is particularly pertinent to Linux. In my view, one of Linux’s biggest strengths is its synergy. The usefulness of Linux doesn’t derive only from the huge raft of open source (command line) utilities. Instead, it’s the synergy generated by using them together, sometimes in conjunction with larger applications. The Unix philosophy spawned a “software tools” movement which focused on developing concise, basic, clear, modular and extensible code that can be used for other projects. This philosophy remains an important element for many Linux projects. Good open source developers writing utilities seek to make sure the utility does its job as well as possible, and work well with other utilities. The goal is that users have a handful of tools, each of which seeks to excel at one thing. Some utilities work well independently. This article looks at 4 open source command line HTTP clients. These clients let you download files over the internet from the command line. But they can also be used for many more interesting purposes such as testing, debugging and interacting with HTTP servers and web applications. Working with HTTP from the command-line is a worthwhile skill for HTTP architects and API designers. If you need to play around with an API, HTTPie and curl will be invaluable.
  • Microsoft publishes security alert on IIS bug that causes 100% CPU usage spikes
    The Microsoft Security Response Center published yesterday a security advisory about a denial of service (DOS) issue impacting IIS (Internet Information Services), Microsoft's web server technology.
  • 5 things to master to be a DevOps engineer
    There's an increasing global demand for DevOps professionals, IT pros who are skilled in software development and operations. In fact, the Linux Foundation's Open Source Jobs Report ranked DevOps as the most in-demand skill, and DevOps career opportunities are thriving worldwide. The main focus of DevOps is bridging the gap between development and operations teams by reducing painful handoffs and increasing collaboration. This is not accomplished by making developers work on operations tasks nor by making system administrators work on development tasks. Instead, both of these roles are replaced by a single role, DevOps, that works on tasks within a cooperative team. As Dave Zwieback wrote in DevOps Hiring, "organizations that have embraced DevOps need people who would naturally resist organization silos."

Purism's Privacy and Security-Focused Librem 5 Linux Phone to Arrive in Q3 2019

Initially planned to ship in early 2019, the revolutionary Librem 5 mobile phone was delayed for April 2019, but now it suffered just one more delay due to the CPU choices the development team had to make to deliver a stable and reliable device that won't heat up or discharge too quickly. Purism had to choose between the i.MX8M Quad or the i.MX8M Mini processors for their Librem 5 Linux-powered smartphone, but after many trials and errors they decided to go with the i.MX8M Quad CPU as manufacturer NXP recently released a new software stack solving all previous power consumption and heating issues. Read more

Qt Creator 4.9 Beta released

We are happy to announce the release of Qt Creator 4.9 Beta! There are many improvements and fixes included in Qt Creator 4.9. I’ll just mention some highlights in this blog post. Please refer to our change log for a more thorough overview. Read more

Hack Week - Browsersync integration for Online

Recently my LibreOffice work is mostly focused on the Online. It's nice to see how it is growing with new features and has better UI. But when I was working on improving toolbars (eg. folding menubar or reorganization of items) I noticed one annoying thing from the developer perspective. After every small change, I had to restart the server to provide updated content for the browser. It takes few seconds for switching windows, killing old server then running new one which requires some tests to be passed. Last week during the Hack Week funded by Collabora Productivity I was able to work on my own projects. It was a good opportunity for me to try to improve the process mentioned above. I've heard previously about browsersync so I decided to try it out. It is a tool which can automatically reload used .css and .js files in all browser sessions after change detection. To make it work browsersync can start proxy server watching files on the original server and sending events to the browser clients if needed. Read more