21 Feb 2019

feedPlanet KDE

Alternatives to rioting

The KDE Community has just announced the wider integration of Matrix instant messaging into its communications infrastructure. There are instructions on the KDE Community Wiki as well.

So what's the state of modern chat with KDE-FreeBSD?

The web client works pretty well in Falkon, the default browser in a KDE Plasma session on FreeBSD. I don't like leaving browsers open for long periods of time, so I looked at the available desktop clients. Porting Quaternion to FreeBSD was dead simple. No compile warnings, nothing, just an hour of doing some boilerplate-ish things, figuring out which Qt components are needed, and doing a bunch of test builds. So that client is now available from official FreeBSD ports. The GTK-based client Fractal was already ported, so there's choices available for native-desktop applications over the browser or Electron experience.

Screenshot of two Matrix IM clients

Fractal and Quaternion side-by-side

For about twenty years, irssi in screen, accessed via ssh, was my preferred chat method. (Well, irssi didn't exist on SunOS in the mid-90s, so I must have used something else originally). Quassel has replaced it on my desktop, and has a nice phone client (QuasselDroid) too if I need to check IRC while on a train. But now there's Matrix clients as well.

Here in the screenshot, Fractal (on the left, background) looks pretty slick, like a phone-based chat application would. Quaternion reminds me a lot more of .. well, of Quassel. It even has little brutalist buttons to pop up the raw JSON content of messages, I don't know why. I haven't gotten around to porting other Qt-based Matrix clients; it's hard to tell what would be worthwhile to try. For now I'll go back to plain IRC, because for me the lack of stickers is a feature, not a bug. #GetOffMyLawn

21 Feb 2019 11:53pm GMT

Ready to test?

If you followed Kdenlive's activity these last years, you know that we dedicated all our energy into a major code refactoring. During this period, which is not the most exciting since our first goal was to simply restore all the stable version's features, we were extremely lucky to see new people joining the core team, and investing a lot of time in the project.

We are now considering to release the updated version in April, with KDE Applications 19.04. There are still a few rough edges and missing features (with many new ones added as well), but we think it now reached the point where it is possible to start working with it.

Testing day tomorrow

This is why we are organizing a test day event tomorrow, 22nd of February 2019, from 17:00 to 22:00 CET, so you can try it, report the problems you encounter and help us shape the future.

How to join ?

More tech-savy users can alternatively compile it with debug flags following this guide and send backtraces

Give us your feedback

During the event, some team members will be reachable on our #kdenlive channel on irc/freenode or via the kdenlive telegram group, and you can also leave your feedback in this Phabricator task.

Known issues

There are a couple of known problems that will be solved before release:

21 Feb 2019 6:10pm GMT

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.

Generic Programming Language Support

In Qt Creator 4.8 we introduced experimental support for the language server protocol. This enables editing support for a wide range of programming languages through a common protocol. In 4.9 we add support for the document outline, find usages, and also for code actions, which allow the language server to suggest fixes or refactoring actions at a specified place in the code. If the language server of your favorite programming language supports these features, they are now available in Qt Creator as well. Enable the LanguageClient plugin in Help > About Plugins (Qt Creator > About Plugins on macOS) and configure your server in Tools > Options > Language Client to check it out.

Highlighting is still provided by the generic highlighter in these cases. We changed our highlighter to be based on the KSyntaxHighlighting library, which is the library used in KDE for this purpose. Many thanks to the maintainers of KSyntaxHighlighting for making it available to a wide range of uses.

C++ Support

The UI for diagnostics from the Clang analyzer tools got many improvements. They are grouped by file now. Diagnostics from the project's headers files are now also included.
Fix-its show details on what they do when applied. We also added a guard against applying Fix-its to files that have changed in the meantime. In the Clazy configuration you can enable or disable individual checks.

If you enabled a diagnostic to be shown inline in the code editor, you can disable individual checks via a button in the diagnostic's tool tip.

QML Support

We updated our QML parser to Qt 5.12, adding support for ECMAScript 7.


Perf is a powerful performance profiling tool for software running on a Linux system. Profile your application via perf with Analyze > Performance Analyzer, after enabling the plugin in Help > About Plugins. The integration in Qt Creator is available for applications running on a local Linux system, and also for applications running on a remote Linux system from a Linux or Windows host.

Generic Projects

Similar to our support for deploying files to a remote system for CMake-based projects, you can now add a QtCreatorDeployment.txt file to your generic project, to specify the necessary information about where to deploy which files.

If your project needs some special compiler flags to be correctly handled by the code model, you can now specify these in a .cxxflags or .cflags file.

Other Improvements

For Windows, we added support for MSVC 2019. On macOS we added a Touch Bar if you run Qt Creator on a MacBook.

For remote Linux targets, we exchanged our Botan-based SSH backend by use of OpenSSH tools. You need to install the tools separately (if you have not already) to be able to benefit from a wide range of encryption and authentication features in Qt Creator. We also added a rsync-based deployment method, as well as support for Run in Terminal.

Version control support has also received many fixes and improvements. The Git Branches view has a new Push action and Git tracks detached HEADs.

Get Qt Creator 4.9 Beta

The opensource version is available on the Qt download page under "Pre-releases", and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.9 Beta is also available under Preview > Qt Creator 4.9.0-beta1 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.9 Beta released appeared first on Qt Blog.

21 Feb 2019 12:22pm GMT

QMacTouchBar has landed

QMacTouchBar has landed

Recent Apple MacBook Pro models contain an entirely new hardware feature, the touchbar. The touchbar is a touch-sensitive OLED strip sitting above the standard keyboard, where the function keys used to be. macOS uses it for some of the physical buttons that used to be located there, such as volume controls, but it is also possible to use the touchbar yourself, both as a graphical output device, and to trigger various activities.

Not a lot of packaged software makes use of it yet, but of course Apple's own applications as well as recent versions of Microsoft Office and various Adobe packages use this to the fullest.

Support for Qt Developers

Qt developers were left out up until now, since there was no support in Qt for this. This has now changed, however, since KDAB just contributed QMacTouchBar, a widget in the QtMacExtras module that was written by KDABian Christoph Schleifenbaum, and that is already being used in some of KDAB's own internal tools.

This is a welcome addition since Apple is not making interfacing with its system components from C++ particularly easy. This requires code written in Objective-C, one of Apple's favorite programming languages, to interface with the built-in Cocoa libraries, as well as the necessary glue code written in C++ to make the touchbar appear as a perfectly ordinary Qt widget to Qt applications.

Currently supported are QTabBar, QMessageBox, QDialogButtonBox (Apple is using the touchbar a lot to show the buttons that close a dialog, such as "OK" and "Cancel"), and QWidgetAction, and it is possible to mark a QAction as the principal action as well as the escape action. Action icons are already supported, and further additions are planned.

Until QMacTouchBar has been merged upstream, you can find it here.

The post QMacTouchBar has landed appeared first on KDAB.

21 Feb 2019 9:37am GMT

20 Feb 2019

feedPlanet KDE

Creating a Plasma Mobile application

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 main.py 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()

    if len(engine.rootObjects()) == 0:

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

    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 https://invent.kde.org/nicolasfella/kstraba

20 Feb 2019 9:16pm GMT

Plasma 5.15.1 arrives in Cosmic backports PPA

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: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
3. Kubuntu ppa bugs: https://bugs.launchpad.net/kubuntu-ppa

20 Feb 2019 9:49am GMT

19 Feb 2019

feedPlanet KDE

Networking in Berlin: Qt World Summit 2018

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.

19 Feb 2019 7:20pm GMT

Qt Design Studio 1.1 released

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

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 bride allows sanitizing documents

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 States, Timelines, MouseAreas, Anchors, Alias 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

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

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.

19 Feb 2019 12:57pm GMT

Plasma Pass 1.0.0

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 <dvratil@kde.org>

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

19 Feb 2019 10:00am GMT

Template meta-programming: Some testing and debugging tricks

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:


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

invalid use of incomplete type 'class print_types<

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(PRODUCER, ping_process,
                              transform("(λ tests_multiprocess.cpp:91:26)")),
                   transform("(λ tests_multiprocess.cpp:82:38)"))),
                              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.

19 Feb 2019 12:00am GMT

18 Feb 2019

feedPlanet KDE

Cutelyst 2.7.0 released, async is back!

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:

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:


Have fun https://github.com/cutelyst/cutelyst/archive/v2.7.0.tar.gz

18 Feb 2019 8:29pm GMT

Interview with Noemie Scherer

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: https://tarnoem.blogspot.com/
For finished art, sorted, go there: https://www.artstation.com/nolanfa
For art (including sketches and WIPS) posted on a semi-regular schedule: http://nolanfa.tumblr.com/
For (digital) art you can buy, and also games: https://fal.itch.io/
For tumblr-is-dying-and-instagram-is-more-fashionable-those-days: https://www.instagram.com/nolanfa_/

18 Feb 2019 7:33am GMT

17 Feb 2019

feedPlanet KDE

This week in Usability & Productivity, part 58

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 https://community.kde.org/Get_Involved, 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.

17 Feb 2019 7:01am GMT

16 Feb 2019

feedPlanet KDE

Latte and a Colors tale...


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:

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, Donate using Liberapay

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

16 Feb 2019 5:28pm GMT

Latte bug fix release v0.8.6

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

Go get v0.8.6 from, download.kde.org* or store.kde.org*

* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E



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

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

16 Feb 2019 1:36pm GMT

Opening Files with Qt on Android

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:

On Android so far we had to do the following:

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.

16 Feb 2019 9:45am GMT