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.

Fractal and Quaternion side-by-side

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

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 ?

• Download the latest AppImage
• Make it executable (in a terminal: chmod +x ) or from your file manager
• Test it!

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:

• Audio thumbnails in timeline eat up lots of memory, and can cause a freeze if large audio files are used, you can disable them as a workaround in larger projects
• Motion tracker not usable yet

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

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.

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:

Tarball:

https://download.kde.org/stable/plasma-pass/plasma-pass-1.0.0.tar.xz

Checksum:

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

Signature:

0ABDFA55A4E6BEA99A83EA974D69557AECB13683 Daniel Vrátil <dvratil@kde.org>

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

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<std::false_type> {
    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.

Conclusion

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.

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 https://github.com/cutelyst/cutelyst/archive/v2.7.0.tar.gz

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

• The System Settings Window Decorations page has been completely rewritten, bringing it into greater conformance with the modern visual style and fixing a huge number of bugs in the process (Valerio Pilo, KDE Plasma 5.16.0):
  
• Dolphin now lets the user choose which split view will be closed by the “Close Split” button (Angelo Oliveira Jr., KDE Applications 19.04.0)
• Okular gained a command-line argument to open a file and instantly highlight all occurrences of a given string (Joao Netto, KDE Applications 19.04.0)

Bugfixes & Performance Improvements

• The Weather widget now correctly displays weather alert text when there’s either a watch or a warning, but not both at the same time (Chris Holland, KDE Plasma 5.12.8)
• Fixed the most common crash-on-launch issue in Discover that was plaguing many users who have devices capable of being updated with fwupd, but had not actually applied the update yet (Dan Leinir Turthra Jensen, KDE Plasma 5.14.5.1)
• Icons on Discover’s Updates page no longer glitch out when using the three-column widescreen view and clicking on the “More Information” button for the selected package (Jonah Brüchert, KDE Plasma 5.15.1)
• The Digital Clock widget’s 12-hour/24-hour toggle now works again (Chris Holland, KDE Plasma 5.15.1)
• By default, the Task Manager now only shows tasks from the current virtual desktop (Aleix Pol Gonzalez, KDE Plasma 5.16.0)
• Ported the System Settings Audio Volume page to QtQuickControls2 and Kirigami, which makes it look good when using a fractional scale factor (me: Nate Graham, KDE Plasma 5.16.0)
• GTK 3 applications no longer spew zillions of warnings to the console (Andrzej Broński, KDE Plasma 5.16.0)
• Scrollbars in Kirigami apps now behave the same as other scrollbars: left-clicking in the trough does a PageUp/PageDown action, and middle-clicking will zoom directly to the clicked location (Marco Martin, KDE Frameworks 5.56)
• Restoring manually-saved Plasma sessions now works with all apps again (David Edmundson, KDE Frameworks 5.56)
• Long wallpaper names can no longer blend into one another (Filip Fila, KDE Frameworks 5.56)
• Plasma can no longer crash when BZip2 support abruptly disappears (David Edmundson, KDE Frameworks 5.56)
• The Baloo file indexing service now correctly indexes folders that were moved from a non-indexed location to an indexed location (Igor Poboiko, KDE Frameworks 5.56)
• Wide characters such as some Emojis are now displayed properly in Konsole (Mariusz Glebocki, KDE Applications 19.04.0)
• When a folder is opened in a new tab in Dolphin, the new tab is placed immediately to the right of the current one instead of always on the end of the tab bar (David Hallas, KDE Applications 19.04.0)

User Interface Improvements

• The Networks widget is now faster to refresh wifi networks, and more reliable at doing so (Valerio Pilo, KDE Plasma 5.16.0)
• In System Settings, the Look and Feel page is now a top-level item, because it affects everything (Björn Feber, KDE Plasma 5.16.0):
  
• When you hide the Desktop Toolbox, an informational message tells you how to return to the configuration window without it (me: Nate Graham, KDE Plasma 5.16.0):
  
• Inline buttons in Kirigami lists are now real ToolButtons, so they change their appearance appropriately when hovered over or clicked (me: Nate Graham, KDE Frameworks 5.56):
  
• When a Kirigami app sends a low-priority transient notification of the type that automatically disappears after seven seconds, the countdown timer now only starts when the parent window has focus, so you don’t miss the notification if the window was behind another one or minimized or something (Kai Uwe Broulik and me: Nate Graham, KDE Frameworks 5.56)
• Konsole now has an on-by-default option to display close buttons on individual tabs, like most other tabbed apps do nowadays (KDE Applications 19.04.0)
• Much more image metadata is now displayed clearly in apps like Dolphin (Alexander Stippich, KDE Applications 19.04.0)

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.

• 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?

• Plasma >= 5.15
• Latte git version
• Latte Window Colors Script in order for KWin to communicate with Latte

Appearance (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

Epilogue

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




Donations

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 Dock 
• Latte Spacer
• Window Title Applet
• Window Buttons Applet
• Window AppMenu Applet

• 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,    

• Latte Dock 
• Latte Spacer
• Window Title Applet
• Window Buttons Applet
• Window AppMenu Applet
• Dock and TopBar, Latte layout

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.

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 share.kde.org.

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!

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.

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 www.kde.org, one social media platform too many for this small world.

by