It’s exactly 20 years ago to the day, that on an equinox as well the first announcement of a KDevelop snapshot, the 0.1 Alpha, was made:

List: kde-announce
Subject: ANNOUNCE: kdevelop-0.1.tar.gz
From: konold () alpha ! tat ! physik ! uni-tuebingen ! de
Date: 1998-09-22 15:50:19

Dear KDE Enthusiast,

the KDE Team is pleased to announce the availability of:

kdevelop-0.1.tar.gz

It can be found at
ftp://ftp.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz

and at our U.S mirror site
ftp://ftp.us.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz.

it will probably appear firstly at
ftp://ftp.de.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz.

Here follows the LSM:

Begin3
Title: KDevelop
Version: 0.1 Alpha
Entered-date: 22 Sep 1998
Description: an IDE for X/Qt/KDE
Keywords: IDE, KDE, X11, Qt, development
Author: Sandy Meier, Stefan Heidrich, Stefan Bartel
Maintained-by: Sandy Meier
Primary-site: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/kdevelop-0.1.tar.gz
Home-page: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/index.html
Original-site: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/kdevelop-0.1.tar.gz
Platform: Linux, needs Qt 1.4 and the kde libs
Copying-policy: GNU Public License
End

20 years of getting feature by feature, sometimes first of its kind, being partially rewritten, getting ported from Qt1 to Qt2 to Qt3 to Qt4 to now Qt5, being made run on non-Linux platforms, seeing hand-overs of maintainers.
At its 20th anniversary KDevelop, now to be called an extensible cross-platform IDE for C, C++, Python, PHP and other languages, continues to provide developers a very reliable and powerful environment to get their code work done. While being inviting to enhance their tool, KDevelop, itself, being a FLOSS software and with no company agenda attached.

I have been a happy user of KDevelop all the years, and currently am giving back to it by doing some development and feature additions.
Be a happy user as well, and then one giving back.
Looking forward to more 20 years, and then some.

KDevelop, ensuring development equity, by day and night.

As part of the research project on “The Interaction between Open Source Software and FRAND licensing in Standardisation”, a workshop was organised by the European Commission, Joint Research Centre (JRC) in collaboration with Directorate General Communications Networks, Content and Technology (CONNECT) to present and discuss the intermediate results to date. The workshop took place in Brussels on September 18, 2018. I presented a set of observations from the research on the case studies performed as part of the project that are outlined below. Other speakers where Catharina Maracke on the issue of legal compliance between Open Source and FRAND licenses, Bruce Perens on “Community Dynamics in Open Source”, and Andy Updegrove on “Dynamics in Standardisation”.

I had the awesome opportunity to attend Akademy in Vienna this year. First off, a big thank you to the organising  team for pulling off this years Akademy without a hitch.

This Akademy was a bit more special, since it was decided to switch up the format, which in my opinion worked quite well. There were training’s that ran alongside the talk’s and BoF’s, which I think was a great idea. I signed up to the Public Speaking Training and the Non Violent Communication training, which I think were run exceptionally. I hope that these training sessions are run again next Akademy because I found them exceptionally valuable.

I also used this opportunity to sit down with TL Lim from Pine64 to discuss the needs of the Pine64 community and how KDE and Pine64 could work together to provide a great experience on Pine64 products such as Pinebook. This eventually led to the release of the KDE Neon image for the Pinebook in the past week, which everyone seems to be quite happy about

Overall, I’d say this was a very productive Akademy for me personally, and I thoroughly enjoyed it.

Since this blog is starting after the beginning of my contributions to KDE, the first few regular posts will be explaining my prior contributions, before moving into the present.

Continuity, right?

I’d also like to outline how I got involved in development, as an entry-level/non-programmer. I hope this will be helpful for those interested in helping, but unsure how to go about doing something useful.

I was introduced to the idea of developing for KDE by Nate Graham and his Usability & Productivity goal. I was immediately drawn to the idea of polishing the applications, like I stated in my first post. But how do I get started? I mean, besides the technical stuff. How do I find something easy to work on? I’m not a programmer by trade, so while we do have the Junior Jobs, a lot of those seemed out of my reach. So what to do?

One of the Usability & Productivity posts from Nate mentioned icons being added to the menus in an app. I looked at the linked code that was changed, and noticed how simple it was! I can do that! So I searched through the Junior Jobs, and Phabricator (KDE’s development and code review platform) for applications that needed some icons added to their menu. I found some tasks, and set to work:

• Adding icons to Gwenview menus
• Changing Gwenview navigation icons
• Standardizing Gwenview menu icons

Check out the screenshots in those links! Here is an example:

It really makes the app look nicer, right? If you scroll down in those pages and look at the code changes, you will see they are basically simple one-liners that are copy/pasted from elsewhere, with a different icon name. Easy!

You could help do easy tasks like this too!

Visit KDE’s Get Involved page for more information, or contact me!

Recently a KDE neon image for the Pinebook was announced. There is a new image, with a handful of fixes, which the KDE Plasma team has been working on over the past week and a half.

Pinebook running KDE neon

Here’s a picture of my Pinebook running KDE neon — watching Panic! At the Disco’s High Hopes — sitting in front of my monitor that’s hooked up to one of my openSUSE systems. There are still some errata, and watching video sucks up battery, but for hacking on documentation from my hammock in the garden, or doing IRC meetings it’s a really nice machine.

But one of the neat things about running KDE neon off of an SD card on the Pinebook is that it’s portable — that SD card can move around. So let’s talk about multiboot in the sense of “booting the same OS storage medium in different hardware units” rather than “booting different OS from a medium in a single hardware unit”. On these little ARM boards, u-boot does all the heavy lifting early in the boot process. So to re-use the KDE neon Pinebook image on another ARM board, the u-boot blocks need to be replaced.

I have the u-boot from a Pine64 image (I forget what) lying around, 1015 blocks of 1024 bytes, which I can dd over the u-boot blocks on the SD card, dd bs=1k conv=notrunc,sync if=uboot.img of=/dev/da0 seek=8, and then the same SD card, with the filesystem and data from the Pinebook, will boot on the Pine64 board. Of course, to move the SD card back again, I need to restore the Pinebook u-boot blocks.

KDE neon Pinebook edition running on a Pine64, with console output

Here’s a picture of my Pineboard (the base is a piece of the garden fence, it’s Douglas pine, with 4mm threaded rods acting as the corner posts for my Pine64 mini-rack), with power and network and a serial console attached, along with the serial console output of the same.

The nice thing here is that the same software stack runs on the Pine64 but then has a wired network — which in turn means that if I switch on the other boards in that mini-rack, I’ve got a distcc-capable cluster for fast development, and vast NFS storage (served from ZFS on my FreeBSD machines) for source. I can develop in a high(er) powered environment, and then swap the card around into the Pinebook for testing-on-the-go.

So to sum up: you can multiboot the KDE neon Pinebook image on other Pine64 hardware (i.e. the Pine64 board). To do so, you need to swap around u-boot blocks. The blocks can be picked out of an image built for each board, and then a particular image (e.g. the latest KDE neon Pinebook) can be run on either board.

Today, on September 18th, 2018, the Russian-speaking KDE community launches its updated website on KDE.ru.

The new website serves as the main page for the Russian-speaking community. It provides localized information about the community, product download links and the list of social network pages we maintain. It is also meant to help new members get involved in KDE’s projects, particularly in our translation and promotion efforts.

The website was created by me and Alexander Potashev on top of Jonah Brüchert‘s work for plasma-mobile.org. It uses Jekyll and is now hosted on official KDE servers. It replaces the old forum that has significantly lost its users in the past years.

If you like our work, please share the website with your friends and subscribers! If you find mistakes, report them in VK group messages, contact me or open a Phabricator revision with a fix.

We would like to thank Ben Cooksley for his help with website deployment, all the users who participated in beta testing, and everyone who helped polish the content.

Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn’t mean we don’t care for it while we still need to. KDE4 was released on January 11th, 2008 — I still have the T-shirt — which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C++11 — certainly the availability of compilers with C++11 support. The language has changed a great deal in those ten years since the original release.

The platforms we run KDE code on have, too — FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we’re seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That’s a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio’s KDE1 efforts, though)

So, while we’re counting down to removing KDE4 from the FreeBSD ports tree, we’re also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there’s lots of code that does list.contains(element) > 0 .. this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn’t comparable to the integer 0. Suffice to say I’ve spent more time reading KDE4-era code this month, than in the past two years.

However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it.

KGraphViewer, your favourite visualiser of .dot files, has a new update.

• Switch KgvPageLayout to QPageSize for page size handling
• Avoid double top-level layout in KGVSimplePrintingPageSetup
• Fix layout of page layout & size dialog
• Remove unused dependency KIO
• Fix minor typo
• Update kgraphviewer docbook
• Make sure the Graphviz library directories are known to the linker

Thanks to Pino, Michael, Yuri, Berkhard, Ben and translators for their continued gardening of this project.

Git tag v2.4.3a 4ff52f959f03291659db58554901d536356764e2

Tar https://download.kde.org/stable/kgraphviewer/2.4.3/kgraphviewer-2.4.3.tar.xz

GPG Signature https://download.kde.org/stable/kgraphviewer/2.4.3/kgraphviewer-2.4.3.tar.xz.sig

Signed by Jonathan Riddell GPG key fingerprint ‘2D1D 5B05 8835 7787 DE9E  E225 EC94 D18F 7F05 997E’

by

There’s some discussion on D15383 about the use of editorconfig in our sources, I belive that we should have this little file in *all* of our projects (actually I would put this in *every single project that exists*. This is a small file that handles common code conventions per project, for instance the tab vs spaces thing.

Before adopting it in my company my life was not good: I had to manually change tabs vs spaces in the configuration of kate multiple times a day. Working with python? spaces. working with c++? tabs. And a few projects here have those two files at the same parent-project, after adopting it life is collorfull again.

The linked branch has a working editorconfig, I beg you fellow developer, this will help windows developers, mac developers, vim / emacs developers and visual developers as editorconfig has plugins or is directly integrated in many developer tools.

Yeah I am not in the picture, but I was there! You can find me over on the left there, where several of us were cut off Akademy was held in the lovely city of Vienna, Austria this year. Hats off to the akademy team for a great job!

This year at akademy I spent much of my time catching up with the Blue Systems team and meeting with the KDE Sysadmin team. I am happy to report Ben Cooksley is real! Due to my flights, I missed the first and last day. It was still a productive akademy. I attended some good sysadmin and KDE Neon BoFs . I also did a bit of volunteering

Even though I am mostly packaging for Debian directly these days, KDE Neon is still near and dear to my heart. I hope to be able to merge debian packaging into Neon soon so that we can have better collaboration within the team.

I met with Ben in regards to getting back into sysadmin/CI work. I am working on Appimage tooling for KDE Binary factory to begin. I hope to utilize the craft tooling to make everyone’s lives easier. This of course is on my free time, but do keep an eye out!

https://binary-factory.kde.org/

Despite my shortened akademy, I still am happy with the results. It was great to see everyone! See you again next year!

Two Latte panels in Unity mode using properly the Unity Ambiance plasma theme

• Most important fix is the new implementation for multi-screen environments. Frustrated as I was from the previous one I decided to make it more robust. With new architecture onPrimary docks/panels have always higher priority that the explicit ones. That change creates a more consistent behavior with Plasma. 
  
  At the same time a highly sophiticated code that was messing things has been totally removed. Latte was trying to be too smart and never let you without a taskmanager in a multi-screen environment. That was creating more issues than it was solving. In the future when such case for the user occurs a dialog can appear to ask the user what it would prefer to do.
• Fixes for plasma theme support:
  - draw properly plasma theme panel backgrounds based on the edge that the dock or panel is present, e.g. Unity Ambiance, Nilium
  - do not double paint plama theme background when the theme does not contain a shadow
• Fix previews for grouped windows (follow plasma design for window previews)
• do not move explicit dock on primary screen
• consider "not show background" case as full transparency
• consider preferredSize(s) only for >0 values (case of locked analog clock disappearing at a vertical panel)
• if there is not any active window at all, dodge set docks should reappear
• do not crash in wayland when right clicking with touchpad
• identify maximized window screen differently
• place correctly a new copied dock in a multi-screen environment
• enable blur for solid theme panels
• fix for missing global shortcuts '9' badge
• support unified or not global shortcuts in case the user does not want to use the Latte unified system for its applets. In master version this can be set separately for every dock/panel from its Dock Settings but for v0.8 you should follow:
  https://github.com/psifidotos/Latte-Dock/wiki/Tips-&-Tricks#q-can-i-disable-unified-global-shortcuts-feature-introduced-with-v08

Greetings, KDE-loving humans! This week’s Usability & Productivity is a heavy one in terms of importance. We scored awesome fixes and improvements through the KDE software stack for subjects as varied as Libinput mouse and touchpad device handling, Task Manager icon sorting for LibreOffice, and a snazzy new unified mailbox in KMail. Have a look:

New Features

• KMail can now display a unified inbox (Daniel Vrátil, KDE Applications 18.12.0):
  

Bugfixes

• Fixed a wide variety of problems with touchpad and mouse configuration resetting or becoming overridden when using the common Libinput driver. This fix will require testing, so please check out the Plasma 5.14 beta! (Roman Gilg, KDE Plasma 5.14.0)
• When pinned to a Task Manager, LibreOffice and other apps that inappropriately change their WM_CLASS values no longer jump around after being launched (Eike Hein, KDE Plasma 5.14.0)
• Fixed a case where Plasma could hang after losing connectivity to a mounted remote location (Oleg Solovyov, KDE Plasma 5.14.0)
• The Plasma Task Manager now respects virtual desktops when deciding how to group multiple instances or windows of a running application (Eike Hein, KDE Plasma 5.14.0)
• When Dolphin is used outside of KDE Plasma, the Ctrl+T shortcut no longer falsely generates “ambiguous shortcut” warnings (Jaime Torres Amate, KDE Applications 18.08.2)
• Spectacle now marks an image’s filename with the timestamp from when the image was created, not when it was saved (Kyle Utecht, KDE Applications 18.12.0)
• Fixed some issues with Bash and Perl syntax highlighting in Kate, KDevelop, and other similar KDE apps (Nibaldo González, KDE Frameworks 5.51)

UI Polish & Improvement

• The interface for installing other programs from within KDE apps now has an improved user interface with fewer levels of hierarchy (Nicolas Fella, KDE Framewotks 5.51):
  
• The Baloo file indexer now excludes by default various file formats used for bioinformatics that may be extremely large and useless to index (Nicolas Fella, KDE Frameworks 5.51)
• The controversial turquoise line underneath the titlebar is now off by default (Fabian Vogt, KDE Plasma 5.14.0)
• The Printer plasmoid is now only visible on the panel when something is actually printing, and only visible in the pop-up when there are any printers configured (Kai Uwe Broulik, KDE Plasma 5.14.0)
• KRunner now uses less technical and more consistent terminology for “Suspend” and “Hibernate” (me: Nate Graham, KDE Plasma 5.14.0)
• KRunner’s settings page now offers links to open the spellchecking and web shortcuts settings from their plugins (Kai Uwe Broulik, KDE Plasma 5.14.0)
• The Track Mouse desktop effect’s settings window received a user interface overhaul and now allows the effect to be triggered with both a keyboard shortcut and by holding down modifier keys (Vlad Vagorodniy, KDE Plasma 5.14.0):
  

Next week, your name could be in this list! Just check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters.

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

Let’s write a mail viewer with Rust and Qt. This is another blog about Rust Qt Binding Generator, the project that lets you add a Qt GUI to your Rust code, or if you will, add Rust to your Qt program.

Rust Qt Binding Generator (Logo by Alessandro Longo)

Previous blogs about Rust Qt Binding Generator covered the initial announcement, building a simple clock, and making a todo list. Now, I’ll show a bit of how to make a more complex application: an email reader.

But first: Rust Qt Binding Generator takes an unusual approach to bindings. It is not a complete binding from the Qt API to Rust because I think that that is impossible: the C++ Qt API does not have all the safety guarantees that Rust has. So the binding API would be full of unsafe negating a big advantage of using Rust.

Instead, Rust Qt Binding Generator generates a binding for just your code to make your Rust code available to a Qt GUI.

In the first tutorial, we showed a clock. The model shared between Rust and Qt had three simple properties: hour, minute and second. The second blog was about a todo application. There, the model was a list of todo items shared between Rust and Qt.

Getting the code

This time, we move on to a more complex object: a tree.

A mail viewer written with Rust and Qt

We’re keeping with the theme of personal information management and are writing an email viewer. It can read mail from MailDir folders and IMAP servers. It is completely readonly and will not even change the state of your messages from unread to read. I feel comfortable using it on my own mails alongside my real mail programs.

The code is available in my personal KDE space. It requires Rust, Cargo, Qt, CMake, OpenSSL, and ninja (or make). You can retrieve and compile it with

git clone https://anongit.kde.org/scratch/vandenoever/mailmodel
mkdir mailmodel/build
cd mailmodel/build
cmake -GNinja ..
ninja

The code is about 2200 lines of Rust and 550 lines of QML. Parsing mails and communicating over IMAP is done by three crates: mailparse, imap-proto and imap.

The shared data model

In an email application there are usually two prominent trees: one shows the email folders and the other shows the messages in the selected folder.

First we model the list of folders. Here is the JSON object from bindings.json that does this.

{
    "MailFolders": {
        "type": "Tree",
        "itemProperties": {
            "name": {
                "type": "QString"
            },
            "delimiter": {
                "type": "QString"
            }
        }
    }
}

The type of MailFolders is Tree. Each node in the tree has two properties: name and delimiter. Rust Qt Binding Generator generates Qt and Rust code from this. The Qt code (Bindings.cpp and Bindings.h) defines an implementation of QAbstractItemModel. This is the same base class as in the todo example. This time, it holds a tree instead of a list.

There is also Rust code generated. The file interface.rs is the binding to the Qt code. It defines a trait MailFoldersTrait that the developer needs to implement in a struct called MailFolders.

We’ll discuss some parts of the Rust implementation file.

The implementation should be backed by a structure. There are two structures: MailFolder which represents a node in the tree and MailFolders which contains all the nodes in a Vec and interfaces for communicating with other parts of the program.

/// Nodes in the tree
struct MailFolder {
    name: String,
    delimiter: String,
    /// position of the parent node in `folders` Vec
    parent: Option<usize>,
    /// position of child folders in the `folders` Vec
    subfolders: Vec<usize>,
}

/// Rust-side implementation of QAbstractItemModel via MailFoldersTrait
pub struct MailFolders {
    /// interface for emitting signals from any thread to the UI
    emit: MailFoldersEmitter,
    /// interface for emitting signals from the UI thread to the UI
    tree: MailFoldersTree,
    /// all nodes in the tree
    folders: Vec<MailFolder>,
    /// interface for sending new data to this object
    data: Arc<Mutex<MailFoldersData>>,
}

In the tree, each node has a unique index. The index is used by Qt to find out information about the node, like how many children (rows) it has or to get out data like the name.

These functions correspond to the C++ virtual functions in QAbstractItemModel.

impl MailFoldersTrait for MailFolders {
    /// Returns the name for a particular node
    fn name(&self, index: usize) -> &str {
        &self.folders[index].name
    }
    /// Returns the number of rows for a node with a given index.
    /// To get the number of root nodes, call `row_count(None)`.
    fn row_count(&self, index: Option<usize>) -> usize {
        self.folders[index.unwrap_or(0)].subfolders.len()
    }
    /// Returns the index for n-th row in parent.
    /// To get the index of the n-th root node, call `index(None, n)`.
    fn index(&self, parent: Option<usize>, row: usize) -> usize {
        self.folders[parent.unwrap_or(0)].subfolders[row]
    }
    /// Returns the index of the parent node or `None` if there is no parent.
    fn parent(&self, index: usize) -> Option<usize> {
        self.folders[index].parent
    }
    /// Returns the row number of a node with given index.
    fn row(&self, index: usize) -> usize {
        if let Some(parent) = self.folders[index].parent {
            // iterate through the parents list of children to find index
            self.folders[parent]
                .subfolders
                .iter()
                .position(|i| *i == index)
                .unwrap()
        } else {
            0
        }
    }
}

Doing the work in a thread

The user interface should stay responsive. So intense and slow work like reading and parsing email is done in a separate thread. The user interface starts a thread to do the hard work and sends commands to it via a channel.

When new data is available, the UI needs to update. This must be done by the UI thread. When the processing thread has new data it emits a signal to the UI thread. The UI thread then aquires accesses the data via a mutex that is shared between the two threads.

Communication between GUI and processing threads

QML for the folders

The Rust-implemented model is used from the QML. The connection between the TreeView and the model is made by the line model: mailmodel.folders. Each node is rendered according to the Text delegate. When the user selects a different folder the model is notified of this by handling the onCurrentIndexChanged event.

TreeView {
    id: folders
    model: mailmodel.folders
    TableViewColumn {
        title: "Name"
        role: "name"
        width: folders.width - 20
        delegate: Text {
            text: icon(styleData.value) + " " + styleData.value
            verticalAlignment: Text.AlignVCenter
        }
    }
    onCurrentIndexChanged: {
        //...
        mailmodel.currentFolder = path;
    }
    style: TreeViewStyle {
        highlightedTextColor: palette.highlightedText
        backgroundColor: palette.base
        alternateBackgroundColor: palette.alternateBase
    }
    headerVisible: false
    frameVisible: false
}

Other parts

The list of folders is one of five object defined in the model. The others are the tree for the message threads in a folder (middle pane in the screenshot above), the current email (right pane), the list of attachments for the current email and an overall object that contains all the other ones. The latter, MailModel, is the initial entry point for the user interface. The user-initiated commands are sent to the processing thread from that overall object.

Trying it out

Create a configuration file for MailDir or IMAP.

{
    "MailDir": {
        "path": "/home/user/mail"
    }
}

The path for the MailDir configuration is the folder that contains .inbox.directory.

{
    "IMAP": {
        "domain": "imap.electronmail.org",
        "username": "username",
        "password": "v3ry53cur3",
        "port": 993,
        "ssl": true
    }
}

and run the code

./mailmodel configuration.json

Concluding

This GUI is built with QML via Qt Quick Controls. One might as well write one with Qt Quick Controls 2, QWidgets or Kirigami. The majority of the code, the Rust code, could stay the same. With the appropriate abstractions one might even use a different GUI framework and still keep the core application logic. Just imagine: KDE and GNOME joined together by Rust.

In the previous post on writing custom data extractors for the KItinerary framework, I mentioned we are augmenting extracted data with knowledge from Wikidata. This post will cover this aspect in more detail.

Static knowledge refers to information that with near certainty don’t change for the duration of your trip, or during a release cycle of our software. That’s things like name, location and timezone of an airport, or the country it belongs to, as opposed to dynamic knowledge like departure gates or platforms, delays, etc.

Use Cases

There’s two main use-cases for static knowledge here:

• Detecting and translating human-readable identifiers of for example countries or airports into something more suited for machine use. As a human I know ‘Charles de Gaulle’ refers to the main airport of Paris, for the software the IATA airport code ‘CDG’ is much more useful. Similar, we want ISO 3166-1 codes for countries rather than possibly localized human-readable names, and so on.

• Augmenting or completing partial information. Usually the booking confirmation data we extract doesn’t contain geo coordinates (useful for navigation to/from the airport/station), the timezone (essential for correctly converting arrival/departure times) or the country (needed for our power plug compatibility check), so we need to obtain that from elsewhere.

Data Sources

Currently we are basing this on the following free and open data sources:

• The Unicode Common Locale Data Repository (CLDR) and iso-codes, for translating between localized country names and ISO 3166-1 codes (part of KContacts API).

• The timezone shapefiles based on OpenStreetMap and the IANA timezone database, for looking up timezones by geo coordinate or by country (in the cases where that’s unique).

• Wikidata for everything else, such as airport and train station names, locations and identifiers, as well as information about countries such as driving direction or used power plugs.

Offline Data

One aspect that might be a bit counter-intuitive at first is that we don’t query this information online, but bake it into the program code. This has a number of advantages:

• Privacy. Your email client would otherwise produce a predictable online access when opening an email containing a travel booking. Even with transport encryption this activity would still be observable on e.g. an open WiFi network, not ideal.
• Speed. The data is encoded in the shared read-only data section of the KItinerary library, in a way that is directly usable without any parsing or additional memory allocations.
• Offline support. That’s something quite handy when traveling, as you might be forced into flight mode or are outside of data roaming coverage.

Obviously there are some downsides to this approach as well, but they are comparatively small:

• Outdated data. You’d need a software update to roll out data changes. This is however why we limit this to “static” data, ie. information that should be stable within one release cycle (3-4 month) with a very high certainty.
• Size. Obviously this data needs space. It’s however surprisingly little, about 600kB for the localized country name to ISO 3166-1 mapping in KContacts, and about 400kB in KItinerary for the airport and train station databases.

Contribute

There’s an easy way to help in this area too, by improving the Wikidata content. Our code extracting the relevant knowledge from Wikidata is warning about some issues such as missing or conflicting data. These issues are usually easy to research and fix, so that might be a nice entry point into Wikidata editing (it definitely was for me).

Since the data quality is actually very good, the below is the complete list of remaining issues at this point, for the few ten thousand objects we are looking at.

The following airports have two geo coordinates assigned to them that differ by more than 20 kilometers. Few airports are that large, more commonly that’s a simple typo. A quick look on a map is often enough to determine which is the right coordinate.

• Mar de Cortés International Airport (PPE)
• Abbs Airport (EAB)
• Albuq Airport (BUK)
• Chiquimula Airport (CIQ)
• El Naranjo Airport (ENJ)
• Leribe Airport (LRB)
• Laucala Airport (LUC)
• Ascencion De Guarayos Airport (ASC)
• Horizontina Airport (HRZ)
• Nuevo Casas Grandes Airport (NCG)
• Tunta Airport (KBN)
• Nakhon Ratchasima Airport (NAK)
• Lancang Airport (JMJ)
• Dourados Airport (DOU)
• Presidencia Roque Sáenz Peña Airport (PRQ)
• San Ignacio de Moxos Airport (SNM)
• Rukumkot Airport (RUK)
• Songyuan Chaganhu Airport (YSQ)
• Santana do Livramento Airport (LVB)
• Dolisie Airport (DIS)
• Sikasso Airport (KSS)
• Auguste George Airport (NGD)
• Ángel Albino Corzo International Airport (TGZ)
• Gedaref Airport (GSU)
• Gobernador Edgardo Castello Airport (VDM)
• Goodland Municipal Airport (GLD)
• Aripuanã Airport (AIR)
• Kakamega Airport (GGM)
• Tazadit Airport (OUZ)

Similarly, the following airports have no geo coordinate specified:

• Papa Stour Airport (PSV)
• South Galway Airport (ZGL)
• Wondoola Airport (WON)

The list of train stations missing geo coordinates is a bit longer and therefore in a separate file.

A bit more elaborate are the following train stations with IBNR conflicts (an ideally unique station identifier). In the easiest case it’s just two duplicate objects that can be merged, in other cases this might require some understanding on which part of a larger station is actually addressed by the identifier.

• IBNR 8089107: Q464094 vs Q22284853
• IBNR 8012583: Q50884707 vs Q46954645
• IBNR 8001978: Q54878964 vs Q2657895
• IBNR 8011167 and 8089100: Q567079 vs Q22284875
• IBNR 8089045: Q664036 vs Q22291719

And finally there is a more conceptual issue with Gares & connexions IDs for international destinations on SNCF tickets, as described in task T8830.

Edoarda

Some seeds take a while to grow, and what a while. I’v met Karina Mochetti five years ago when I moved to Campinas, back then I had just started working at Intel and I had finished one of my most glorious software developer tasks, good subversive terrorist that I’m, I made Linus Torvalds program in C++ and talking with a friend that lives in Rio de Janeiro I heard “I have a programmer friend in Campinas, wanna meet?”, well, yes, always.

Fernando

Then I met Karina, a really shy programmer about her habilities, finishing her doctors in Cryptography and Quantum Computers, and I was like “wow, and you feel that you don’t have habilities?”, I’v shown her some stuff that I work on, she regozijed. And time passed. I moved to a really welcoming place with lots of culture, arts, craft, programmers called Munich, and she moved to a really welcoming place with lots of culture, arts, craft, programmers called Niteroi. We lost contact.

Untill we got contact again a few months ago, and we talked about a ~partnership~ between KDE and UFF, the  Unversity that she’s now a professor, and now I can say: We have 9 students from the Fluminense Federal University working on 5 applications from kde-edu.

First we have two students that are almost finishing the university and choosed to work on KDE software for their Projects:

Joao

Lukas is already working on Minuet and plans to have code for understanding sounds and giving you the note that you played, This can really boost Minuet’s hability to teach music theory as it can discover when you got it wrong.

Carlos is taking a go in Kalzium and trying to fix bugs, modernizing it’s codebase and trying to improve avogrado integration.

Carlos

He’s a computer scientist that loves movies, food and cold nights. Has a hate/love relationship with computers since childhood and is clumsy as a panda. Eager to do things that will actually matter to the world in general.

Edoarda and Hugo are tackling Kiten, trying to rethink it’s user interface for the modern user keeping mobile and desktop in mind. it’s not a easy task as kitten has many powerfull features hidden behind a really clean interface.

Luan and Fernando are reviving my Pet Project, Rocs, a Graph Theory teaching tool that for many years was maintained by me and Wagner Reck, later by Andreas Cord-Landwehr. It’s really good to see an University taking that project again.

Joao and Marcelo are working in KTurtle with the blessing of the KTurtle ex maintainers, they are full of energy and ideas.

Karina Mochetti

Hugo

Lucas

I’ve started contributing to Clang, in the hope that I can improve the API for tooling. This will eventually mean changes to the C++ API of Clang, the CMake buildsystem, and new features in the tooling. Hopefully I’ll remember to blog about changes I make.

The Department of Redundancy Department

I’ve been implementing custom clang-tidy checks and have become quite familiar with the AST Node API. Because of my background in Qt, I was immediately disoriented by some API inconsistency. Certain API classes had both getStartLoc and getLocStart methods, as well as both getEndLoc and getLocEnd etc. The pairs of methods return the same content, so at least one set of them is redundant.

I’m used to working on stable library APIs, but Clang is different in that it offers no API stability guarantees at all. As an experiment, we staggered the introduction of new API and removal of old API. I ended up replacing the getStartLoc and getLocStart methods with getBeginLoc for consistency with other classes, and replaced getLocEnd with getEndLoc. Both old and new APIs are in the Clang 7.0.0 release, but the old APIs are already removed from Clang master. Users of the old APIs should port to the new ones at the next opportunity as described here.

Wait a minute, Where’s me dump()er?

Clang AST classes have a dump() method which is very useful for debugging. Several tools shipped with Clang are based on dumping AST nodes.

The SourceLocation type also provides a dump() method which outputs the file, line and column corresponding to a location. The problem with it though has always been that it does not include a newline at the end of the output, so the output gets lost in noise. This 2013 video tutorial shows the typical developer experience using that dump method. I’ve finally fixed that in Clang, but it did not make it into Clang 7.0.0.

In the same vein, I also added a dump() method to the SourceRange class. This prints out locations in the an angle-bracket format which shows only what changed between the beginning and end of the range.

Let it bind

When writing clang-tidy checks using AST Matchers, it is common to factor out intermediate variables for re-use or for clarity in the code.

auto valueMethod = cxxMethodDecl(hasName("value"));
Finer->addMatcher(valueMethod.bind("methodDecl"));

clang-query has an analogous way to create intermediate matcher variables, but binding to them did not work. As of my recent commit, it is possible to create matcher variables and bind them later in a matcher:

let valueMethod cxxMethodDecl(hasName("value"))
match valueMethod.bind("methodDecl")
match callExpr(callee(valueMethod.bind("methodDecl"))).bind("methodCall")

Preload your Queries

Staying on the same topic, I extended clang-query with a --preload option. This allows starting clang-query with some commands already invoked, and then continue using it as a REPL:

bash$ cat cmds.txt
let valueMethod cxxMethodDecl(hasName("value"))

bash$ clang-query --preload cmds.txt somefile.cpp
clang-query> match valueMethod.bind("methodDecl")

Match #1:

somefile.cpp:4:2: note: "methodDecl" binds here
        void value();
        ^~~~~~~~~~~~

1 match.

Previously, it was only possible to run commands from a file without also creating a REPL using the -c option. The --preload option with the REPL is useful when experimenting with matchers and having to restart clang-query regularly. This happens a lot when modifying code to examine changes to AST nodes.

Enjoy!

0.3 Beta Release of Elisa Music Player

Elisa is a music player developed by the KDE community that strives to be simple and nice to use. We also recognize that we need a flexible product to account for the different workflows and use-cases of our users.

We focus on a very good integration with the Plasma desktop of the KDE community without compromising the support for other platforms (other Linux desktop environments, Windows and Android).

We are creating a reliable product that is a joy to use and respects our users privacy. As such, we will prefer to support online services where users are in control of their data.

New Features and Improvements

The main improvements are the following:

• Hide stars when there is no rating by Diego Gangl ;

• Various fixes for the Windows support by Matthieu Gallien ;
• Implement interface of Baloo to watch renamed files by Matthieu Gallien ;
• Upgrade some code using deprecated features in KDeclarative framework by Alexander Stippich ;
• Align the action buttons with the big icon in the views header by Diego Gangl ;
• Allow the playlist to be hidden when browsing your music by Diego Gangl ;

• Always display the title of the playlist entries by Matthieu Gallien ;
  

• Internal improvements to various non graphical components to allow future improvements to the header bar by Matthieu Gallien ;
• Resize track metadata view dynamically by Alexander Stippich ;
• Improvements to the header of the play list by Diego Gangl ;
• Add a mode where Elisa can show only the header but in the full window by Carl Schwan. Welcome to the project. This was a junior task identified in the Elisa workboard ;
• Optimize the data methods of model and use QAbstractItemModelTester (see the blog from Giuseppe D’Angelo) by Matthieu Gallien ;
• Makes KIO and KFileMetaData be optional dependencies by Matthieu Gallien. This a preliminary step to allow building Elisa for Android with as few dependencies as possible.

New Mode with only the Player Header Visible

This feature improves two different cases. The first is to allow usage of Elisa with a small window. In this case, only minimal information is shown in a possibly small window. The second is to implement the “party” mode that was originally designed by Andrew Lake.

Other Improvements to the Interface

As already said, there have been various improvements to the interface.

How You Can Help

We are preparing for the next stable release. As such, there is a feature freeze and an ongoing effort to squash as many bugs as possible.

We really appreciate any feedback on the current state via bugs.kde.org. We welcome bug report or feature suggestions.

You can get the next release by building from source or by using the flatpak package provided by KDE. The windows installer is also available here (thanks a lot to the Craft and binary-factory teams).

More long and thoughtful posts like the prior one will be coming. But right now I have an important announcement! I have resurrected the KDE Bugsquad, and we have our first official Bug Day on Saturday!

The KDE Bugsquad is back! We can think of no better way to celebrate than joining forces with the Krita team as part of their Squash All the Bugs fundraiser!

We will be holding the first Bug Day on September 15th, 2018, focusing on bugs reported on Krita. Expect events to kick off at 10:00 AM EDT.

This is a great opportunity for anyone, especially non-developers to get involved!

1. Check out our Bug Triaging guide for a primer on how to go about confirming and triaging bugs.
2. Log into KDE Phabricator and join the Bugsquad!
3. Join the #kde-bugs IRC channel on Freenode to chat with us in real-time as we go through the list.
4. Open the shared Etherpad for this event (use your KDE Identity login) to select your block of bugs and cross them off.

If you need any help, contact me!