The 2019 incarnation of foss-north is less than a month away. This year we’re extending the conference in two directions: a training day and a community day. This time, I wanted to write about the training day.

The training day, April 10, is an additional day for those who want to extend
the conference with a day of dedicated training. I’m very happy to have two experienced and well known trainers on side: Michael Kerrisk and Chris Simmonds. Both has years of training experience.

Michael will teach about the details in dynamic linking. The topic may seem trivial, but when you start scratching the surface, there are a lot of details to discover such as how to handle version compatibility, how symbol resolution really works, and so on. You can read more about the Building and Using Shared Libraries on Linux training here.

Chris will run a getting started with embedded Linux training. Using BeagleBone Black devices the participants will learn how to build linux for the target, how to get devices such as GPIO and i2c working and more. You can read more about the Fast Track to Embedded Linux training here.

The best part of enrolling for training at foss-north is that you also get full access to the two conference days, and that you help fund the conference itself. If you are interested, check out the tickets page.

The old among us might remember KDE4 and something one could call the “Pink Phase”, when people explored how “interesting” they could make their digital workplace by applying certain colors and themes… don’t most of us sometimes need a fluffy and color-intensive world to escape to… if only to learn to value reality again, when things get too fluffy

The most outstanding work useful for that had been done once by Florian Schepper who created the Plasma theme “Fluffy Bunny”, which won hearts over on first sight. Sadly though the theme bundle got lost, was recovered, only to then by the times getting lost again from the stores. Time to repeat that, at least the recovering

And so last week the internet and local backups had been scanned to restore the theme again, to quick first success:

Well, besides the regression Plasma5 has over the old Plasma With only thin & non-tiled border themes trendy and used the last years, sadly current Plasma has some issues, also does it assume that borders of panels are rectangular when creating the default BlurBehind mask. Some first patches (1, 2, 3) are already under review.

Get the initial restored version from your Plasma desktop via System settings/Workspace Theme/Plasma Theme/Get new Plasma Themes…/Search “Fluffy Bunny” or via the Web interface from store.kde.org and enjoy a bit of fluffy Plasma

Next up: restoring the “Plasma Bunny” theme from the once drafted “Fluffy” linux distribution… less flurry, but more pink!
Update: First version of new named “Unicorn” is now up in the store for your entertainment.

Week 62 for KDE’s Usability & Productivity initiative is here, and we didn’t let up! We’ve got new features, bugfixes, more icons… we’ve got everything! Take a look:

New Features

• The System Settings Desktop Session page now lets you reboot directly into the computer’s UEFI setup screen, if applicable (Kai Uwe Broulik, KDE Plasma 5.16.0):
  
  
• Gwenview now has full touchscreen support, with gestures for swiping, zooming, panning, etc. (Steffen Hartlieb, KDE Applications 19.04.0)
• Okular’s presentation mode now allows you to optionally navigate both backwards and forwards using a touchscreen (Oliver Sander, KDE Applications 19.04.0):
  

Bugfixes & Performance Improvements

• When using multiple Virtual Desktops, Task Manager tooltips once again indicate the Virtual Desktop that a task is on, and sorting tasks by Virtual Desktop once again works (Eike Hein, KDE Plasma 5.15.3)
• Fixed a bug that could cause certain GTK themes to display huge icons in the System Settings GTK configuration page (Aleix Pol Gonzalez, KDE Plasma 5.15.3)
• KInfoCenter once again activates list items with a single-click even when using the systemwide double-click mode for files and icons (Harald Sitter, KDE Plasma 5.15.3)
• When when using X11 and the KWin window manager’s compositing is interrupted or stopped in the middle of the Present Windows effect, mouse and keyboard input no longer get disabled (Vlad Zagorodniy, KDE Plasma 5.15.3)
• In the Application Dashboard, Ctrl+a now selects all search text even after the context switches (Eike Hein, KDE Plasma 5.15.3)
• Discover no longer lets you pull down on the updates page to refresh while it’s already refreshing (Aleix Pol Gonzalez, KDE Plasma 5.15.4)
• Discover once again displays the proper background colors on the app list, search, and updates pages (me: Nate Graham, KDE Plasma 5.15.4)
• The login and lock screens’ clock no longer sometimes displays some of the numbers clipped off at the sides (Krešimir Čohar, KDE Plasma 5.16.0)
• The qtquick2 style framework is now listed as a runtime dependency for Plasma, which should hopefully provide a helpful hint to packagers that it needs to be installed and reduce the incidence of people who use certain distros seeing ugly user interfaces on QML/Kirigami apps (Kai Uwe Broulik, KDE Plasma 5.16.0)
• The Baloo file indexing service should now crash much less often (Valeriy Malov, KDE Frameworks 5.57)
• When a move or copy operation is canceled in the middle, the half-finished destination file is now automatically deleted (Chinmoy Ranjan Pradhan, KDE Frameworks 5.57)
• Fixed another memory leak in Dolphin (David Hallas, KDE Applications 19.04.0)
• Dolphin’s Information Panel’s context menu is now correctly positioned on Wayland when using two screens (Méven Car, KDE Applications 19.04.0)
• When downloading new Yakuake skins from the Get Hot New Stuff window, the newly-downloaded skins actually appear as options you can choose (Lionel Chauvin, Yakuake 3.0.6)

User Interface Improvements

• Discover’s update notifier no longer opens a little pop-up when you click on it; now it just opens Discover itself, which fixes problems with the notifier and the app disagreeing over how many updates are available (Aleix Pol Gonzalez, KDE Plasma 5.16.0)
• Cleaned up and re-organized the Task Manager context menus (me: Nate Graham, KDE Plasma 5.16.0):
  
  
• Task Manager tooltips that display album art now look much better (Tranter Madi, KDE Plasma 5.16.0):
  
• When using a vertical panel, the Digital Clock’s date display now takes up the full amount of available horizontal space (Antny Zilla, KDE Plasma 5.16.0):
  
• In Kate, KWrite and other apps like KDevelop that use the KTextEditor framework, text selection now works like it does everywhere else: when text is selected, the left arrow key moves the insertion point one character to the left of the beginning of the selection, and the right arrow key moves the insertion point one character to the right of the end of the selection (Loh Tar, KDE Frameworks 5.57)
• In Kate, KWrite and other apps like KDevelop that use the KTextEditor framework, text drag-and-dropped onto the left border inserts it at the beginning of the line (Loh Tar, KDE Frameworks 5.57)
• Various icons throughout KDE software such as in Dolphin and System Settings now look better when using a fractional systemwide scale factor (Kai Uwe Broulik, KDE Frameworks 5.57)
• The Breeze applications-gaming icon is now visible against dark background, and just looks better in general (Noah Davis, KDE Frameworks 5.57):
  
• KIO and Dolphin now display thumbnails for PCX files (Kai Uwe Broulik, KDE Applications 19.04.0)
• Spectacle’s filename template chooser now has clickable tokens (David Redondo, KDE Applications 19.04.0):
  
• The “Find” action in Yakuake, the embedded terminal in Dolphin and Kate, and any other users of the Konsole KPart now has a keyboard shortcut by default (Nicolas Fella, Yakuake 3.0.6)

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.

Now that we have a way to access realtime public transport data this needs to be integrated into KDE Itinerary. There’s three use-cases being looked at so far, described below.

Realtime information

The first obvious use-case is displaying delays, platform changes, etc in the timeline and reservation details views, and notifying about such changes. This is already implemented for trains based on KPublicTransport, and to a very limited extend (gate changes) for flights using KPkPass for Apple Wallet boarding passes containing a working update API endpoint.

Train delay and platform changes in the train trip details page

For KDE Itinerary to check for changes you either need to use the “Check for Updates” action in the global action drawer, or enable automatic checking in the settings. KDE Itinerary will not reach out to online services on its own by default.

When enabled, the automatic polling tries to adapt the polling frequency to how far away an arrival or departure is, so you get current information within minutes without wasting battery or bandwidth. This still might need a bit of fine tuning and/or support for more corner cases (a departure delay past the scheduled arrival time was such a case for example), so feedback on this from use in practice is very much welcome.

Whenever changes are found, KDE Itinerary will also trigger a notification, which should work on all platforms.

Train delay notification on Android

Querying online services for realtime data might result in additional information that were previously not included in the timeline data, geo coordinates for all stations along the way for example. KDE Itinerary will try to augment the existing data with whatever new information we come across this way, having realtime data polling enabled will therefore also result in more navigation options or weather forecasts for more locations being shown.

Alternative connections

The second integration point currently being worked on is selecting alternative train connections, for example when having missed a connection or when having an unbound reservation that isn’t specific to a trip to begin with.

This is available in the context drawer on the details page of the corresponding train reservation. KDE Itinerary will then query for journeys along the same way as the current reservation, and allows you to pick one of the results as the new itinerary for this trip. Realtime information are of course shown here too, if available.

Three alternative connections options for a train trip, the first is expanded to show details

While displaying the connections already works, actually saving the result is still missing. Nevertheless feedback is already useful to see if sensible results are returned for existing bookings.

Filling gaps

The third use-case is filling gaps in the itinerary, such as how to get from the airport to the hotel by local transport. Or similarly, determining when you have to leave from your current location to make it to the airport in time for your flight. This would result in additional elements in the timeline containing suggested public transport routes.

Implementation on this hasn’t started yet, technically it’s a variations of the journey query already used in the previous point. The bigger challenge therefore will likely be on presenting this in a usable and useful way.

Contribute

This is all work in progress, so it’s the best point in time to influence things, any input or help is very much welcome of course. See our Phabricator workboard for what’s on the todo list, for coordinating work and for collecting ideas. For questions and suggestions, please feel free to join us on the KDE PIM mailing list or in the #kontact channel on Freenode or Matrix.

If you happen to know a source for realtime flight information that could be usable by Free Software without causing recurring cost I’d also be thankful for hints :)

I’ve been playing around with type meta-tagging for my Voy reactive streams library (more on that some other time) and realized how useful it is to be able to check whether a given type is an instantiation of some class template, so I decided to write a short post about it.

Imagine you are writing a generic function, and you need to check whether you are given a value or a tuple so that you can unpack the tuple before doing anything with it.

If we want to check whether a type T is an instance of std::tuple or not, we can create the following meta-function:

template <typename T>
struct is_tuple: std::false_type {};

template <typename... Args>
struct is_tuple<std::tuple<Args...>>: std::true_type {};

The meaning of this code is simple:

• By default, we return false for any type we are given
• If the compiler is able to match the type T with std::tuple<Args...> for some list of types, then we return true.

To make it easier to use, we can implement a _v version of the function like the meta-functions in <type_traits> have:

template <typename T>
constexpr bool is_tuple_v = is_tuple<T>::value;

We can now use it to implement a merged std::invoke+std::apply function which calls std::apply if the user passes in a tuple, and std::invoke otherwise:

template <typename F, typename T>
auto call(F&& f, T&& t)
{
    if constexpr(is_tuple_v<T>) {
        return std::apply(FWD(f), FWD(t));
    } else {
        return std::invoke(FWD(f), FWD(t));
    }
}

Up one level

The previous meta-function works for tuples. What if we needed to check whether a type is an instance of std::vector or std::basic_string?

We could copy the previously defined meta-function, and replace all occurrences of “tuple” with “vector” or “basic_string”. But we know better than to do copy-paste-oriented programming.

Instead, we can increase the level of templatedness.

For STL algorithms, we use template functions instead of ordinary functions to allow us to pass in other functions as arguments. Here, we need to use template templates instead of ordinary templates.

template <template <typename...> typename Template,
          typename Type>
struct is_instance_of: std::false_type {};

template <template <typename...> typename Template,
          typename... Args>
struct is_instance_of<Template, Template<Args...>>: std::true_type {};

template <template <typename...> typename Template,
          typename Type>
constexpr bool is_instance_of_v = is_instance_of<Template, Type>::value;

The template <template <typename...> allows us to pass in template names instead of template instantiations (concrete types) to a template meta-function.

We can now check whether a specific type is an instantiation of a given template:

static_assert(is_instance_of_v<std::basic_string, std::string>);
static_assert(is_instance_of_v<std::tuple, std::tuple<int, double>>);

static_assert(!is_instance_of_v<std::tuple, std::vector<int>>);
static_assert(!is_instance_of_v<std::vector, std::tuple<int, double>>);

A similar trick is used alongside void_t to implement the detection idiom which allows us to do some compile-time type introspection and even simulate concepts.

I’ll cover the detection idiom in some of the future blog posts.

XlsxWriter is a Python module for creating files in xlsx (MS Excel 2007+) format. It is used by certain python modules some of our customers needed (such as OCA report_xlsx module).

This module is available in pypi but it was not packaged for Fedora. I’ve decided to maintain it in Fedora and created a package review request which is helpfully reviewed by Robert-André Mauchin.

The package, providing python3 compatible module, is available for Fedora 28 onwards.

Okteta, a simple editor for the raw data of files, has been released in version 0.26.0. The 0.26 series mainly brings a clean-up of the public API of the provided shared libraries. The UI & features of the Okteta program have been kept stable, next to one added new feature: there is now a context menu in the byte array viewer/editor available.

Since the port to Qt5 & KF5 Okteta has not seen work on new features. Instead some rework of the internal architecture has been started, and is still on-going.

Though this release there is a small feature added again, and thus the chance to pick up on the good tradition of the series of all-new-features-in-a-picture, like done for 0.9, 0.7, 0.4, 0.3, and 0.2. See in one quick glance what is new since 0.9 (sic):

Introduction and approach

Fuzz-testing, also called Fuzzing, is an essential tool inside the tool-box of software developers and testers. The idea is simple yet effective: simply throw a huge amount of random test inputs at the target program, until you manage to get it to crash or otherwise misbehave. This crashes are often revealing some defects in the code, some overlooked corner-cases that are at best annoying for the end-user if she stumbles upon them, or at worse dangerous if the holes have security implications. As part of our refactoring efforts of the main components of Kdenlive, this is one of the tools we wanted to use to ensure as much stability as possible.

One of the most commonly used fuzzing library is called LibFuzzer, and is built upon LLVM. It has already helped finding thousands of issues in a wide range of projects, including well tested ones. LibFuzzer is a coverage based fuzzer, which means that it attempts to generate inputs that creates new execution paths. That way, it tries to cover the full scope of the target software, and is more likely to uncover corner-cases.
Building a library (in this case Kdenlive’s core library) with the correct instrumentation to support fuzzing is straightforward: with Clang, you simply need to pass the flag -fsanitize=fuzzer-no-link. And while we’re at it, we can also add Clang’s extremely useful Address sanitizer with -fsanitize=fuzzer-no-link, address. This way, we are going to detect any kind of memory malfunction as soon as it occurs.

Now that the library is ready for fuzzing, we need to create a fuzz target. That corresponds to the entry point of our program, to which the fuzzer is going to pass the random inputs. In general, it looks like this:

// fuzz_target.cc
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
    DoSomethingWithData(Data, Size);
    return 0;
}

Now, the challenge is to come up with a good fuzzing function. Utilities that read from stdin or from an input file, like ffmpeg, any compression tool, any conversion tool, etc., are easy to fuzz since we just need to fuzz the data we feed them. In the case of Kdenlive, we also read project files, but this represents only a tiny amount of what a full editing software is supposed to do, and further-more our project opening loading logic is mostly deferred to third-party libraries. So, how to fuzz the interesting parts of Kdenlive? Well, if you look at it from a distance, Kdenlive can more or less be summed up as a “just” a (rich) GUI sitting on top of existing video manipulation libraries. That means that our most prominent source of inputs is the user: at the core, what Kdenlive must excel at is handling any kind of action the user may want to perform.

During the rewrite of our core modules, we changed a bit the architecture so that there is a clear separation between the model, which handles all the actual logic, and the view (written in QML), which is designed to be as thin as possible. Essentially, this means that any action executed by the user corresponds exactly to one or several call to the model’s API. This makes our life easier when performing fuzzing: in order to effectively push Kdenlive to its limits, we simply need to call random model functions in a random order with random parameters.

The plan is getting clear now, but one crucial piece is missing: how do we turn the input provided by LibFuzzer (a random string) into a random sequence of model actions?

Generating a maintainable script language

One obvious idea would be to define a scripting language that maps text to actions, for example move 0 3 4 could move clip 0 on track 3 at position 4. However, writing such a scripting language from scratch, and then an interpreter for it, is a daunting task and is hard to maintain: each time a new function is added in the API it must be added in the script language as well, and any change in the API is likely to break the interpreter.

Basically, we want to generate the script language and its interpreter programmatically in a semi-automated way. One way to do this is to use reflection: by enumerating all the methods in the API, we can figure out what is a legal operation, and interpret it correctly if it is indeed an existing operation. As of today, C++ still lacks native reflection capabilities, but there are some great libraries out there that allow you to fill this gap a little. We used RTTR, which is a Runtime reflection library. It requires to register the functions you want to make available: in the following snippet we register a method called “requestClipsUngroup” from our timeline model:

RTTR_REGISTRATION
{
    using namespace rttr;
    registration::class_("TimelineModel")
        .method("requestClipsUngroup", &TimelineModel::requestClipsUngroup)
               (parameter_names("itemIds", "logUndo"));
}

Note that specifying the names of the parameter is technically not required by RTTR, but it is useful for our purposes.

Once we have that, our script interpreter is much easier to write: when we obtain a string like “requestClipDoSomething”, we check the registered methods for anything similar, and if we find it, we also know which arguments to expect (their name as well as their type), so we can parse that easily as well (arguments are typically numbers, booleans or strings so they don’t require complicated parsing).

For Kdenlive, there is one caveat though: the model is, by design, very finicky with the inputs its receives. In our example function, the first parameter, itemIds is a list of ids of items on the timeline (clips, compositions,…). If one of the element of the input list is NOT a known item id, the model is going to send an abort, because everything is checked through an assert. This behavior was designed to make sure that the view cannot sneak an invalid model call without us knowing about it (by getting an immediate and irrevocable crash). The problem is that this is not going to play well within a fuzzing framework: if we let the fuzzer come up with random ids, there is little chance that they are going to be valid ids and the model is going to be crashing all the time, which is not what we want.
To work around this, we implemented a slight additional thing in our interpreter: whenever the argument is some kind of object id, for example an item id, we compute a list of currently valid ids (in the example, allValidItemIds). That way, if we parse an int with value i for this argument, we send allValidItemIds[i % allValidItemIds.size()] to the model instead. This ensures that all the ids it receives are always going to be valid.

The final step for this interpreter to be perfect is to automatically create a small translation table between the long API names and shorter aliases. The idea behind this is that the fuzzer is less likely to randomly stumble upon a complicated name like “requestClipUngroup” than a one letter name like “u”. In practice, LibFuzzer supports dictionaries, so it could in theory be able to deal with these complicated names, but maintaining a dictionary is one extra hassle, so if we can avoid it, it’s probably for the best. All in all, here is a sample of a valid script:

a 
c red  20 1
c blue  20 1
c green  20 1
b 0 -1 -1 $$ 0
b 0 -1 -1 $$ 0
b 0 -1 -1 $$ 0
e 0 294 295 0 1 1 0
e 0 298 295 23 1 1 0
e 0 299 295 45 1 1 0
e 0 300 296 4 1 1 0
e 0 299 295 43 1 1 0
e 0 300 296 9 1 1 0
l 0 2 299 294 1 0
l 0 2 300 294 1 0
e 0 299 295 43 1 1 0
e 0 300 296 9 1 1 0
e 0 299 295 48 1 1 0
e 0 294 296 8 1 1 0
e 0 294 295 3 1 1 0

Generating a corpus

To work optimally, Libfuzzer needs a initial corpus, which is an initial set of inputs that trigger diverse behaviors.
One could write some scripts by hand, but once again that would not scale very well and would not be maintainable. Luckily, we already have a trove of small snippets that call a lot of model functions: our unit-tests. So the question becomes: how do we (automatically) convert our unit-tests into scripts with the syntax described above?

The answer is, once again, reflection. We have a singleton class Logging that keeps track of all the operations that have been requested. We then instrument our API functions so that we can log the fact that they have been called:

bool TimelineModel::requestClipsUngroup(const std::unordered_set& itemIds, bool logUndo)
{
    TRACE(itemIds, logUndo);
    // do the actual work here
    return result
}

Here TRACE is a convenience macro that looks like this:

#define TRACE(...)                                                                                                                                             \
    LogGuard __guard;                                                                                                                                          \
    if (__guard.hasGuard()) {                                                                                                                                  \
        Logger::log(this, __FUNCTION__, {__VA_ARGS__});                                                                                                        \
    }

Note that it passes the pointer (this), the function name (__FUNCTION__) and the arguments to the logger.
The LogGuard is a small RAII utility that prevents duplicate logging in the case of nested calls: if our code looks like this:

int TimelineModel::foo(int foobaz) {
    TRACE(foobaz);
    return baz * 5;
}

int TimelineModel::bar(int barbaz) {
    TRACE(barbaz);
    return foo(barbaz - 2);
}

If bar is called, we want to have only one logging entry, and discard the one that would result from the inner foo call. To this end, the LogGuard prevents further logging until its deleted, which happens when it goes out of scope, i.e when bar returns. Sample implementation:

class LogGuard{
public:
    LogGuard()
        : m_hasGuard(Logger::start_logging()) {}
    ~LogGuard()
    {
        if (m_hasGuard) Logger::stop_logging();
    }
    // @brief Returns true if we are the top-level caller.
    bool hasGuard() const { return m_hasGuard; }
protected:
    bool m_hasGuard = false;
};

Once we have a list of the function calls, we can generate the script by simply dumping them in a format that is consistent with what the interpreter expects.

This kind corpus is very useful in practice. Here is the output of LibFuzzer after a few iterations on an empty corpus

#1944	NEW    cov: 6521 ft: 10397 corp: 46/108b lim: 4 exec/s: 60 rss: 555Mb L: 4/4 MS: 1 ChangeBit-

The important metric is “cov”, which indicates how well we cover the full source code. Note that at this point, not a single valid API call has been made.

With a corpus generated through our unit tests, it looks like this

#40	REDUCE cov: 13272 ft: 65474 corp: 1148/1077Kb lim: 6 exec/s: 2 rss: 1340Mb L: 1882/8652 MS: 2 CMP-EraseBytes- DE: "movit.convert"-

The coverage is more than twice as big! And at this point at lot of valid calls are made all the time.

Summary

In a nutshell, here are the steps we went through to be able to efficiently fuzz a complex application like Kdenlive:

• Structure the code so that model and view are well separated
• Generate a scripting language using reflection, to be able to query the model
• Trace the API calls of the unit-tests to generate an initial script corpus
• Fuzz the model through the script interface
• Profit!

For us at Kdenlive, this approach has already proved useful to uncover bugs that were not caught by our test-cases. See this commit for example: https://invent.kde.org/kde/kdenlive/commit/fcd1ccd6250aea6a977a0856a284a9ac1f5341ee. Note that our logger is able to emit either a script or a unit-test after an execution: this means that when we find a script that triggers a bug, we can automatically convert it back to a unit-test to be added to our test library!

In week 61 for KDE’s Usability & Productivity initiative, the MVP has got to be the KDE community itself–all of you. You see, Spectacle has gotten a lot of work thanks to new contributors David Redondo and Nils Rother after I mentioned on Reddit a week ago that “a team of 2-4 developers could make Spectacle sparkle in a month“. I wasn’t expecting y’all to take it so literally! The KDE community continues to amaze. But there’s a lot more, too:

New Features

• On Wayland, the System Settings Libinput touchpad page now allows you to configure the click method, switching between “areas” or “clickfinger” (Atul Bisht, KDE Plasma 5.16.0)
• The slideshow wallpaper now displays the actual images that are inside the folders you’ve chosen (David Redondo, KDE Plasma 5.16.0):
  
• The System Settings Color page now has a search bar and filtering feature so for example you can show only light or dark themes (Kai Uwe Broulik, KDE Plasma 5.16.0):
  
• File overwrite operations now copy to a temporary file and then replace the destination file at the very end, so canceling an overwrite in the middle no longer destroys the destination file (Chinmoy Ranjan Pradhan, KDE Frameworks 5.57)
• Spectacle now has an optional setting for Rectangular Region mode to auto-accept the dragged box instead of allowing you to adjust it first and then accept (Nils Rother, KDE Applications 19.04.0):
  
• Spectacle now lets you change the level of compression for lossy image formats (Nils Rother, KDE Applications 19.04.0):
  

Bugfixes & Performance Improvements

• Spactacle’s “Capture the current pop-up only” feature now works again (Kai Uwe Broulik, KDE Plasma 5.15.3)
• When using multiple virtual desktops and saved sessions, the last-used virtual desktop is now remembered and restored when you start up the session again (Vlad Zagorodniy, KDE Plasma 5.15.3)
• On-screen displays showing volume level etc no longer jerkily flicker as they fade out when using Qt 5.12 ( Krešimir Čohar, KDE Plasma 5.15.3)
• File open/save dialogs spawned by apps using the XDG portal (such as firefox) now look good when using a fractional scale factor (Kai Uwe Broulik, KDE Plasma 5.15.3)
• Task switcher previews now look good when using a fractional scale factor (David Edmundson, KDE Plasma 5.16.0)
• Fixed case where copying files could cause Dolphin to crash (David Hallas, KDE Frameworks 5.56)
• The grid items in many new-style System Settings pages now display content that is sharp and crisp rather than blurry (David Edmundson, KDE Frameworks 5.57):
  
• Symlinks to mounted NTFS disks are once again visible in Dolphin (Wolfgang Bauer, KDE Frameworks 5.57)
• The scrollable list-within-a-sheet present in the System Settings Languages page no longer escapes from the bounds of the parent view when scrolled (Marco Martin, KDE Frameworks 5.57):
  
• An erroneous overwrite warning dialog is no longer presented when using a case-sensitive filesystem and renaming an item by just changing its case (Robert Hoffman, KDE Frameworks 5.57)
• In KDE Neon and other distros that default to the Noto Sans font with Noto Symbols2 as a fallback for characters not present in Noto Sans, typing in the lock and login screens’ password field no longer causes the field to become slightly taller (Marco Martin, KDE Frameworks 5.57):

  Next step is to use a different glyph for the black dot, since the one we’re using appears too high in the text field. For more information, see https://github.com/googlei18n/noto-fonts/issues/1468

• When using two screens, Spectacle’s help text in Rectangular Region mode now shows up in the middle of the primary display, rather than split between the screens (Nils Rother, KDE Applications 19.04.0)
• Konsole once again correctly displays the underline-style cursor (Wolfgang Bauer, KDE Applications 19.04.0)

User Interface Improvements

• The logout screen now clearly indicates which option is selected (KDE Plasma 5.16.0)
• Discover’s sources menu now shows the version number for each different source for that app (Aleix Pol Gonzalez, KDE Plasma 5.16.0):
  
• It’s once again possible to disable the tooltips that show up when hovering over a window decoration button like Maximize, Minimize, Close, etc. (Vlad Zagorodniy, KDE Plasma 5.16.0)
• The Media Frame’s settings window was thoroughly updated and modernized (me: Nate Graham, KDE Plasma 5.16.0):
  
• The Web Browser widget now has a bigger default expanded size and uses an icon that becomes monochrome at small panel heights (Ilya Ostapenko, KDE Plasma 5.16.0):
  
• Kate’s “search wrapped” message no longer appears right in the center of the view where it obscures the search result (Loh Tar, KDE Frameworks 5.57)
• When quitting, Kate no longer annoys you by prompting you to acknowledge files that were modified on disk by something other than you, such as a source control change (Loh Tar, KDE Applications 19.04.)
• Text file thumbnails now actually show syntax highlighting for the text inside the thumbnail (Friedrich Kossebau, 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.

pulseaudio-qt 1.0.0 is out!

It’s a Qt framework C++ bindings library for the PulseAudio sound system.

It was previously part of plasma-pa but is now standalone so it can be used by KDE Connect and anyone else who wants it.

https://download.kde.org/stable/pulseaudio-qt/

sha256: a0a4f2793e642e77a5c4698421becc8c046c426811e9d270ff2a31b49bae10df pulseaudio-qt-1.0.0.tar.xz

The tar is signed by my GPG key.

by

I’ve released libqaccessibilityclient 0.4.0.

Changes:

• bump version for new release
• Revert “add file to extract strings”
• add file to extract strings
• Set include dir for exported library target
• Create and install also a QAccessibilityClientConfigVersion.cmake file
• Create proper CMake Config file which also checks for deps
• Use imported targets for Qt libs, support BUILD_TESTING option
• Use newer signature of cmake’s add_test()
• Remove usage of dead QT_USE_FAST_CONCATENATION
• Remove duplicated cmake_minimum_required
• Use override
• Use nullptr
• Generate directly version
• Add some notes about creating releases

Signed using my key: Jonathan Riddell <jr@jriddell.org> 2D1D5B0588357787DE9EE225EC94D18F7F05997E

6630f107eec6084cafbee29dee6a810d7174b09f7aae2bf80c31b2bc6a14deec libqaccessibilityclient-0.4.0.tar.xz

https://download.kde.org/stable/libqaccessibilityclient/

What is it?

Most of the stack is part of Qt 5, so nothing to worry about, that’s the part that lets applications expose their UI over DBus for AT-SPI, so they work
nicely with assisitve tools (e.g. Orca). In accessibility language, the applications act as “servers” and the screen reader for example is a client.

This library is for writing clients, so applications that are assistive, such as screen readers. It currently has two users: KMag and Simon with Plasma also taking an interest. KMag can use it to follow the focus (e.g. when editing text, it can automatically magnify the part of the document where the cursor is. For Simon Listens, the use is to be able to let the user trigger menus and buttons by voice input.

by

KDevelop 5.3.2 released

Folks offered a lot of feedback on my article on headerbars last year, some of which was skeptical or critical. I’d like to address some of the arguments people made in this follow-up:

It doesn’t really matter that there’s less visible or actual window drag space

People pointed out that you can drag on the UI controls, or use the hidden Alt-drag shortcut. Other people questioned how useful it is to drag windows around anyway, preferring to maximize everything or use window tiling keyboard shortcuts. I will address these responses:

“Just drag on the controls in the headerbar”

First of all, dragging controls to drag the window isn’t very intuitive. What other controls outside the headerbar allow you to move the window when dragging on them? Sure, you can learn it, but this isn’t the same as a good user interface that re-uses familiarity with existing elements rather than making you learn new modes.

Second, you can’t drag the window by dragging on controls that themselves implement draggable behaviors–such as tab bars, comboboxes, pop-up menus, and sliders. So those controls can’t be put on the headerbar without reducing the drag area and violating the “you can drag the window by dragging on the controls” rule. In the original post, I gave an example of Firefox’s horrendous CSD that puts draggable tabs in the headerbar, reducing the drag area for the window itself to almost nothing. Ensuring draggability by only using controls that are not themselves draggable reduces developer flexibility compared to a traditional titlebar. It’s just not a problem if you have a separate titlebar.

“Just alt-drag the window or move it with keyboard shortcuts”

This somewhat flippant answer describes a workaround, not a general-purpose solution for everyone. Most users drag their windows around all the time and probably don’t know any of those shortcuts. For them, adequate window draggability is important–especially if your desktop happens to be targeting these people as the #1 user group.

“Just maximize the window and then there’s plenty of visible drag space on the headerbar”

it depends on the implementation (e.g. Firefox’s CSD is perfectly capable of having almost no drag space when maximized), but this is broadly true. However, what if you’re not the kind of user who maximizes all of their windows? In any event, window draggability is least important for maximized windows. The whole point of dragging a window around is to move it somewhere else, which requires that it be smaller than the area in which it’s moved.

—

Taken together, these issues demonstrate that reduced draggability reduces developer flexibility and can be a real problem. It can’t just be dismissed as much ado about nothing.

You don’t need menubars anyway

A lot of people expressed many variants of this argument:

“You don’t need menubars anymore because actions and commands can be located inline, available contextually”

This works, but imposes a high bar in UI design, and results in frustrating and awkward software when implemented by a team without at least one person with A+ UI design skills who everyone else actually listens to. This approach is also very labor-intensive and bug-prone as by definition it’s custom-made for each app and requires a lot of code. It may not scale well for content with many actions you can perform on it, since there’s a limited amount of space in the content view to put contextual actions. It furthermore throws away users’ existing familiarity and muscle memory; for example when cut/copy/paste/find are always available in the same place in the Edit menu, users never need to re-learn how to cut, copy, and paste, and find text in each app. Finally, this approach doesn’t help the user learn keyboard shortcuts.

So yes, this approach works, but results in significant drawbacks. It’s definitely not a 100% slam-dunk superior user interface.

“Menubars are overkill for simple apps”

This is a reasonable argument. Most of the items in the average menu bar pertain to text manipulation, file handling, and view adjustment. An app that doesn’t have any text manipulation or file handling can probably get away with putting what’s left in toolbar buttons. In fact KDE’s Discover already does this, for just those reasons. A number of other simple mouse-centric KDE apps like the games could probably do the same.

But the thing is, you don’t need to implement a CSD headerbar to get rid of your menubar! You can do it with a traditional toolbar and a traditional titlebar, and gain all the advantages of those individual user interface elements: guaranteed space to drag the window, a legible window title, a user-customizable toolbar that can include draggable UI elements, and so on. No need to throw the baby out with the bathwater.

“Menubars don’t exist on mobile and mobile is the future therefore we need to get rid of them on the desktop or else people under 25 will perceive us as stogy old farts and won’t want to use our apps”

I see no evidence that the under-25 crowd hates desktop apps with menubars. A lot of KDE’s most active members are young, and all fully understand the productivity benefits of real desktop apps with traditional user interfaces.

The truth is, mobile phones are really only good for communication, travel, controlling portable hardware (cameras, drones, etc) and content consumption that doesn’t benefit from a large screen. Other than these use cases, mobile apps are universally worse to use than traditional desktop apps–especially for productivity. They are slower, more awkward, have fewer features, take longer to accomplish the same tasks, are harder to multi-task with, have user interfaces that are constantly in a state of flux, and are an absolute nightmare for anything that requires precise text manipulation or formatting.

Most of these limitations are imposed by the hardware’s own input and output capabilities. This means that the only way to improve the situation is to plug in a big screen and some faster, more precise input devices–essentially turning the mobile device into an underpowered desktop computer. Not coincidentally, KDE’s Kirigami user interface toolkit explicitly supports this use case anyway.

I think Star Trek nailed the ideal mobile/desktop split decades ago: people use their mobile devices for communication, information gathering, and relaxing, but when they need to be productive, they use the huge desktop-computer-style consoles built into the walls of their ships. The bigger devices offer speed, power, precision, and good multi-tasking. When you need to get something important done, those are more important features than being able to have the device in your pocket or purse all the time.

The lesson is clear: portable mobile devices are for convenience, not productivity. Mobile isn’t going to kill the desktop any more than air freight killed rail freight. They’re just for different things.

“Menubars are old and clunky and clumsy and obsolete and a relic of the past”

If this is true, why haven’t we come with anything better yet after more than two decades of user interface experimentation?

• MS Office style Ribbons take up much more space than the combination of a menubar and toolbar they replace, make it harder to find what you’re looking for when the context sensitivity feature isn’t implemented perfectly, and don’t teach the user keyboard shortcuts.
• Hamburger menus in the toolbar have to leave out most functionality or else they become too cluttered. Most also don’t make any effort to teach the user keyboard shortcuts.
• Action drawers that slide in from the left or right are basically just hamburger menus, with all the same drawbacks.
• Inline controls were already addressed above.

I have yet to encounter a feature-rich, high-functionality desktop app that completely does away with the concept of the main menubar without feeling awkward, crippled, slow, or like something has been left out. I’m sure someday we will kill the menubar after we’ve invented something genuinely better that doesn’t feel like a regression in any way, but we’re not there yet.

And in the meantime, you don’t declare something to be dead before you’ve actually killed it.

The menubar isn’t dead yet for desktop apps because we haven’t yet come up with anything that’s universally better. The GTK & GNOME approach has a hamburger menu on the toolbar that holds global controls, coupled with a limited number of inline editing controls. most of which are only available via a hidden UI (the right-click context menu or undiscoverable keyboard shortcuts). This is not a solution, it’s a regression: many features must be removed or hidden to make it not visually overwhelming; the inline controls are invisible unless you think to right-click everywhere; and it’s impossible to learn keyboard shortcuts at the moment of use. This is a steep price to pay for visual cleanliness and approachability.

Displaying a title is an application-specific issue

Only when there’s no titlebar.

When the window manager guarantees your window a titlebar, app developers don’t have to reinvent the wheel by implementing custom labels to solve the same problem over and over again; they just set the title appropriately and move on.

Iff you implement a headerbar but want to put a title in it, it competes for space with the rest of the items in the headerbar. That means it can’t be very long unless your app has almost no UI controls exposed on the headerbar, which is a problem for any application that could benefit from showing a long title–like web browsers, where the titlebar has traditionally showed the website’s title (imagine that).

When you use a traditional discrete titlebar, you don’t have any of these challenges to solve, so you can focus on more important parts of your app.

Headerbars were meant for simple apps; it’s okay for complicated professional apps to not use them

Some people defend headerbars by arguing that the menubar is obsolete, then say that complicated apps can and should still have menubars. This doesn’t work: either menus are obsolete, or they aren’t. If they aren’t, then removing them is a mistake.

The better argument is that headerbars are only intended for very simple apps that don’t really benefit much from a menubar anyway because most of the default entries are inapplicable and would be disabled placeholders. I already acknowledged that it’s probably fine to remove the menubar for very simple apps that don’t have selectable text or do any file handling. But as I mentioned before, there’s no reason why you need to implement a CSD headerbar if your app doesn’t have a menubar.

It’s KDE’s fault for not supporting client-side decorations properly, so nobody should avoid them just to work around KDE brokenness

There is a kernel of truth here: KDE developers have indeed opted not to support GTK client-side decorations as they are currently implemented.

However, this is only because that implementation utilizes optional extensions to the standard that are very challenging for KWin to also implement. Many of KWin’s architectural design decisions reflect the original spec, and not this optional extension to it. Adding support is very technically challenging, and was judged to present an unacceptable risk of breakage.

At this point, GTK developers may be thinking, “Well, that’s not my problem that you wrote KWin in such an inflexible way.” But it’s not quite kosher to extend a spec with an optional single-vendor extension and then blame other people for not adopting it. That’s not really following the spec.

Nonetheless, there are rumblings of being able to support GTK CSDs in Wayland. For now though, the situation on X11 is unfortunate but pretty much unavoidable. You can’t break a spec and then ask everyone else to support your brokenness; it defeats the entire purpose of having a spec in the first place.

Anyone interested in more of the technical details can read through the comments in the following bug reports:

https://bugs.kde.org/show_bug.cgi?id=379637

https://bugzilla.gnome.org/show_bug.cgi?id=csd

https://gitlab.gnome.org/GNOME/gtk/issues/499

https://gitlab.gnome.org/GNOME/gtk/issues/489

https://gitlab.gnome.org/GNOME/gtk/issues/215

https://gitlab.gnome.org/GNOME/gtk/issues/488

The bottom line is that it’s not fair to blame KWin and its developers for not supporting the GTK developers’ decision to implement client-side decorations without extending the X11 window manager spec so that everybody could follow it.

—

I hope this post helps to clarify my position on CSDs. I suspect that these rebuttals won’t put the issue to rest because CSD headerbars have always been more about aesthetics and vertical space savings than functionality, power, and flexibility. That’s fine! all of these arguments I’m making are sort of a roundabout way of saying that I prefer the latter traits to the former ones. I think it’s a good thing that we have choice in the desktop space–real choice, where well-implemented competing visions and design goals appeal to different sorts of people. And that’s what we’re all doing here: empowering people to find what works best for them so their needs and desires can be provided by high-quality open-source software that respects their privacy, freedom, and need for highly usable and productive applications.

It’s time for week 60 for KDE’s Usability & Productivity initiative, and this one is positively overflowing with goodies! Will you even be able to handle it? I THINK NOT!!! But read it and see:

New Features

• KMenuEdit now has a search field that can be used to find items in the list if applications (Aidan Sojourner, KDE Plasma 5.16.0):
  

  Note that this was a 16 year-old feature request; old enough to drive in many countries!

• Kate (and other apps using the KSyntaxHighlighting framework) can now show highlighting for many more languages inside markdown formatting (Jos van den Oever, KDE Frameworks 5.56)
• Kate can now optionally show all invisible whitespace characters, not just some (Aleix Pol Gonzalez, KDE Applications 19.04.0):
  
• Kate’s status bar now has a menu with options for the current dictionary language and spellchecking (Loh Tar, KDE Applications 19.04.0):
  
• Okular now supports editing LaTeX documents in TexStudio (Yuri Chornoivan, KDE Applications 19.04.0)

Bugfixes & Performance Improvements

• KDE open/save dialogs accessed via the XDG Portal (e.g. in Firefox) now allows multi-selection (Jan Grulich, KDE Plasma 5.15.2)
• KWin no longer crashes upon launching a game in certain circumstances (Vlad Zagorodniy, KDE Plasma 5.15.2)
• While using Discover to install an app that’s available from multiple sources, the sources menu no longer changes its text to null during installation (Aleix Pol Gonzalez, KDE Plasma 5.15.2)
• The Picture of the Day wallpaper configuration interface now looks good when using a fractional scale factor (me: Nate Graham, KDE Plasma 5.15.2):
  
• KInfoCenter’s “Help” button now works again (Harald Sitter, KDE Plasma 5.15.2)
• When using the KDE open/save dialogs via the XDG Portal (e.g. in Firefox), trying to overwrite a file now displays a confirmation dialog instead of just silently doing it and then closing (Kai Uwe Broulik, KDE Plasma 5.15.3)
• In Discover’s sources lists, text containing the repo name now gets elided rather than overlapping the inline buttons when there’s not much room (Aleix Pol Gonzalez, KDE Plasma 5.15.3)
• When Dolphin is unable to create a file or folder whose name is too long, the resulting error message no longer inappropriately resizes the parent window (me: Nate Graham, KDE Frameworks 5.56):
  
• Fixed some visual glitches in Kate, KDevelop and other apps using the KTextEditor framework that could cause dots show up at on deleted lines at the end of a document or make the bottom few pixels of text lines get clipped off (Christoph Cullmann, KDE Frameworks 5.56)
• Dolphin no longer crashes when a file in the trash is drag-and-dropped back into the trash (David Hallas, KDE Frameworks 5.56)
• The Baloo file indexing service no longer causes crashes in apps used to access tags:/ (Jonathan Marten, KDE Frameworks 5.56)
• Konsole can once again render bold text (Mariusz Glebocki, KDE Applications 19.04.0):
  
• Fixed a memory leak in Dolphin (David Hallas, KDE Applications 19.04.0)

User Interface Improvements

• Discover’s Sources dropdown menu now makes each item look like it’s an exclusive radio button, and uses a better icon for distro sources (Aleix Pol Gonzalez, and me: Nate Graham, KDE Plasma 5.15.2):
  

  Yeah, we’re aware that the Flatpak icon isn’t great either. That will be fixed in https://bugs.kde.org/show_bug.cgi?id=404810

• It’s now possible to switch to an alternative Task Manager from the context menu even when the entire thing is full of tasks and there’s no empty space (me: Nate Graham, KDE Plasma 5.15.3):
  
• Category labels in Plasma configuration windows now become multiline strings instead of taking up 100% of the available horizontal space and looking glued to the edges (Filip Fila, KDE Plasma 5.15.3):
  
• The 12/24 hour clock setting in the Digital Clock widget’s settings window now has a sensible user interface (me: Nate Graham, KDE Plasma 5.16.0):
  
• A number of Plasma settings windows have been ported to QtQuickControls2 and given a user interface overhaul (Filip Fila and Krešimir Čohar, KDE Plasma 5.16.0):
  
  
• Throughout Plasma, the word “Sleep” is now used in place of “Suspend” (Me: Nate Graham, KDE Plasma 5.16.0):
  

  Doesn’t that just look great with our new moon icon, too?!

• KSysGuard’s search field now displays a tooltip when hovering the mouse over it that reveals som if its power and features (Simone Gaiarin, KDE Plasma 5.16.0):
  
• The Kirigami convergent UI toolkit gained a standardized text-field-with-inline-actions component, which means that all of our QML software will soon be able to have a totally consistent look and feel for search fields (Carl Schwan, KDE Frameworks 5.56)
• Kate’s file tree now has a “Show Containing Folder” entry in the document view (Kai Uwe Broulik, 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.

Hi,
We are pleased to announce the release of GCompris version 0.96.

This new version includes updated translation for several languages, and a few bug fixes.

Translations that received a big update:

• Brazilian Portuguese (100%)
• Breton (100%)
• Finnish (90%)
• Indonesian (100%)
• Norwegian Nynorsk (97%)
• Polish (100%)

This means we have now 19 languages fully supported: British English, Brazilian Portuguese, Breton, Catalan, Catalan (Valencian), Chinese Traditional, Dutch, French, Galician, Greek, Hungarian, Indonesian, Italian, Malayalam, Polish, Portuguese, Romanian, Swedish, Ukrainian.

We still have 15 partially supported languages: Basque (78%), Belarusian (68%), Chinese Simplified (69%), Estonian (62%), Finnish (90%), German (84%), Hindi (76%), Irish Gaelic (82%), Norwegian Nynorsk (97%), Russian (77%), Scottish Gaelic (70%), Slovak (62%), Slovenian (56%), Spanish (93%), Turkish (73%).

We decided again for this release to keep the translations that dropped below 80%. It would be sad to have to disable 10 languages from the application, but if no one updates the following translations, they will be disabled in next release: Basque, Belarusian, Chinese Simplified, Estonian, Hindi, Russian, Scottish Gaelic, Slovak, Slovenian and Turkish.

For the windows version, we added a new entry in the start menu called GCompris (Safe Mode) to launch it with software rendering mode. This was needed as the auto-detection of OpenGL support was not reliable. Now, users can easily choose between OpenGL and software rendering without changing the configuration file.

Known issues:

• The progress bar for downloads doesn’t work anymore. This is a side effect from our switch to https for hosting the files. We are looking to improve this for next release.

As a side note dedicated to GNU/Linux distribution packagers, this new version now requires OpenSSL to be able to download voices and additional images.

As usual you can download this new version from our download page. It will also be available soon on the Android and Windows store.

Thank you all,
Timothée & Johnny

• One single but important fix. New users reported that were installing Latte but Latte did not appear afterwards. Probably some of the last updates in the upstream packages broke the proper "latte" directory creation in users ~/.config folder. This is fixed now and all new users should not have any issue with this.

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

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

One of the larger missing pieces for KDE Itinerary is access to dynamic data for your current mode of transport. That is delays or other service interruptions, gate or platform changes, or finding a specific connection for e.g. an unbound train booking. At least for ground-based public transport we have been making some progress on this in the last few months, resulting in a new library, KPublicTransport.

Data Model

The information we are talking about here are essentially how to get from A to B, and whether a given journey from A to B is on schedule. Stop and route schedule information are often found in the same context, but since we don’t need that for KDE Itinerary those aren’t considered here.

A bit less abstract and following how Navitia names things, this gives us the following objects to work with:

• Location: A place identified by a name, geo coordinates and/or a data source specific identifier (such as UIC station codes). While generic places are usually supported, we are mostly interested in a specific sub-type, stop areas or stop points. That is places a public transport line stops, such as train stations or bus stops.
• Lines and Routes: A line is a set of stops connected by a public transport service (e.g. “Circle line”), a route is specific service on that line, typically identified by the direction.
• Departures and Arrivals: That is, information about when and where a specific service arrives or leaves from a stop.
• Journeys: A journey consists of multiple sections, that combined describe how to get from location A to location B, using public transport services, but possibly also containing walks to and from a stop, or transfer instructions.

The properties these objects can have vary depending on the backend providing the information, ranging from basic things like human-readable names, times or geo coordinates to things like the CO2 impact of a journey or facilities found at a station or inside a train.

To obtain this information, we need the following query operations:

• Given two locations and a timeframe, find a set of possible journeys.
• Given a stop and a timeframe, query departures or arrivals.
• Disambiguate or auto-complete locations. That’s essentially querying locations by name. This is needed if all we have as a destination is e.g. “Berlin”, which could refer to dozens of train stations.

Depending on the backend, those queries may support additional parameters, such as preferred modes of transportation or your walking speed.

This model is largely based on the most complex case, local public transport. Long-distance railway services tend to be closer to flights (using per-day unique service identifiers), but can be represented by this as well. Flights are out of scope here.

To simplify the implementation, this is also closely following what Navitia and other vendor-specific APIs provide, rather than the needs of KDE Itinerary. We’d for example be much more interested in querying delays and disruptions for a given journey section, rather than for a given stop. This can however be achieved using the above building blocks.

Online vs Offline

All this isn’t exactly new though, the KDE4-era public transport plasmoid had this already. However that focused on GTFS as a data source in its later stages. GTFS is a Google-defined standard format for providing the entire base schedule of a public transport network. This has the advantage of being fully offline capable, once you have transferred the data set once. While this somewhat works on desktop, the disk space and bandwidth cost for mobile devices might already be to high. Things get even worse when looking at GTFS Realtime, which is designed for providing live data on an entire public transport network, in the extreme case containing high frequency position updates for all vehicles in the network.

GTFS was designed to feed this information into applications like Google Maps, not for direct consumption by every single user. From a user point of view we would like to only deal with the data for the journey we are interested in to conserve disk space and bandwidth usage, even if that means giving up the possibility for offline support. Offline support however cannot work with realtime data anyway, and that’s one of the most valuable features here.

So, what we would need is a network service that aggregates base schedule and realtime information provided by public transport networks via GTFS or any other format, and that allows us to query for the data we are interested in. And that’s exactly what Navitia does.

Online Backends

Unfortunately reality is slightly more more complicated, as it’s not enough to just support Navitia as a backend. While Navitia has extensive coverage, some important providers are missing and are not providing data that could be fed into Navitia. SCNF is one such case that is relatively easy to support, they are running their own Navitia instance. Others such as Deutsche Bahn have their own APIs.

So we need a system that can use several Navitia instances as well as vendor specific APIs as backends. While the concepts map fairly well to the services I have seen so far, aggregating results from different backends brings in new challenges such as aligning different naming and identification of lines or stops.

Implementation

The code used to be part of KDE Itinerary until this week, but has now been moved to its own repository and library, KPublicTransport. Having this as a standalone framework makes sense as there are other use-cases for it beyond the irregular travel scenario covered by KDE Itinerary, such as helping with your daily commute.

Next to the implementation, this also contains three example applications to trigger the three types of queries mentioned above, two of which are shown below. There’s also some initial API documentation.

Example application showing departures information for Brussels Gare de Midi with local and long distance trains, and realtime platform change information.

Example application showing a journey from Vienna airport to the Akademy 2018 accommodation, with realtime delay and platform change information.

What’s next?

While KPublicTransport is at a point to build prototypes with it, there are of course still many things to do. Besides completing and extending the implementation, provider coverage outside of Europe is something to look into too, the current backends and test-cases are all largely Europe-centric. If you come across GTFS datasets not integrated into Navitia’s dataset yet, pointing the Navitia team to those is an easy way to help. Integration into KDE Itinerary is another big subject, I’ll write a separate post about that.