Hi,
Good news for Mac users: we finally have a new version of GCompris for OSX !

The last version of GCompris for OSX was 0.52 from 3 years ago. Since then, no one in the team could update it because of the lack of hardware. Thanks to Boudewijn from the Krita Foundation, we have now a little mac mini, old but good enough to build our packages. It took me several days of dedicated work to learn this new platform and update the build system to produce a distributable package.

This package was built and tested on OSX 10.13. If you can try it on a different OSX version, please let us know if it works.

The .dmg installer is available on the download page.

This time we decided to stop distributing it from the app-store. About the iOS version, it will take some more time before I can look at it, and we still don’t have any device to test.

Notes: this package is based on GCompris version 0.95. It is built with the latest version of Qt (5.12.0) which introduced some regressions. We fixed all of those issues, but some of those fixes are only in the development version for now. A few activities are broken (checkers, braille, braille_alphabet, algorithm), but we will make a new release next month that will also address those little issues.

Thank you all,
Timothée – GCompris team

There was a snag in the KookBook 0.2.0 release, and 0.2.1 is available.

Get it here: kookbook-0.2.1.tar.xz

Btw, anyone can tell me the purpose of

git archive --prefix=foo

compared to

git archive --prefix=foo/

When would anyone use the former?

There’s a nice post by Ryou about the projections feature of Eric Niebler’s ranges that we’re going to get in C++20.

I’ll try to provide a more general look at what projections are – not only in the context of ranges. I recommend reading Ryou’s post before or after this one for completeness.

Tables have turned

Imagine the following – you have a collection of records where each record has several fields. One example of this can be a list of files where each file has a name, size and maybe something else.

Collections like these are often presented to the user as a table which can be sorted on an arbitrary column.

Tables are everywhere

By default std::sort uses operator< to compare items in the collection while sorting which is not ideal for our current problem – we want to be able to sort on an arbitrary column.

The usual solution is to use a custom comparator function that compares just the field we want to sort on (I’m going to omit namespaces for the sake of readability, and I’m not going to write pairs of iterators – just the collection name as is customary with ranges):

sort(files, [] (const auto& left, const auto& right) {
                return left.name < right.name;
            });

There is a lot of boilerplate in this snippet for a really simple operation of sorting on a specific field.

Projections allow us to specify this in a much simpler way:

sort(files, less, &file_t::name);

What this does is quite simple. It uses less-than for comparison (less), just as we have with normal std::sort but it does not call the operator< of the file_t objects in order to compare the files while sorting. Instead, it only compares the strings stored in the name member variable of those files.

That is the point of a projection – instead of an algorithm testing the value itself, it tests some representation of that value – a projection. This representation can be anything – from a member variable, to some more complex transformation.

One step back

Let’s take one step back and investigate what a projection is.

Instead of sorting, we’re going to take a look at transform. The transform algorithm with an added projection would look like this:

transform(files, destination,
          [] (auto size) { return size / 1024; }, &file_t::size);

We’re transforming a collection of files with a &file_t::size projection. This means that the transform algorithm will invoke the provided lambda with the file sizes instead of file_t objects themselves.

The transformation on each file_t value in the files collection is performed in two steps:

• First, for a file f, extract f.size
• Second, divide the result of the previous step by 1024

This is nothing more than a function composition. One function gets a file and returns its size, and the second function gets a number and divides it by 1024.

If C++ had a mechanism for function composition, we would be able to achieve the same effect like so:

transform(files, destination,
    compose_fn(
        [] (auto size) { return size / 1024; },
        &file_t::size
    ));

Note: compose_fn can be easily implemented, we’ll leave it for some other time.

Moving on from transform to all_of. We might want to check that all files are non-empty:

all_of(files, [] (auto size) { return size > 0; }, &file_t::size);

Just like in the previous example, the all_of algorithm is not going to work directly on files, but only on their sizes. For each file, the size will be read and the provided predicate called on it.

And just like in the previous example, this can be achieved by simple function composition without any projections:

all_of(files,
    compose_fn(
        [] (auto size) { return size > 0; },
        &file_t::size
    ));

Almost composition

The question that arises is whether all projections can be replaced by ordinary function composition?

From the previous two examples, it looks like the answer to this question is “yes” – the function composition allows the algorithm to “look” at an arbitrary representation of a value just like the projections do. It doesn’t matter whether this representation function is passed in as a projection and then the algorithm passes on the projected value to the lambda, or if we compose that lambda with the representation function.

Unary function composition

The things stop being this simple when an algorithm requires a function with more than one argument like sort or accumulate do.

With normal function composition, the first function we apply can have as many arguments as we want, but since it returns only a single value, the second function needs to be unary.

For example, we might want to have a function size_in which returns a file size in some unit like kB, KiB, MB, MiB, etc. This function would have two arguments – the file we want to get the size of and the unit. We could compose this function with the previously defined lambda which checks whether the file size is greater than zero.

N-ary function composition

sort needs this to be the other way round. It needs a function of two arguments where both arguments have to be projected. The representation (projection) function needs to be unary, and the resulting function needs to be binary.

Composition needed for sorting

Universal projections

So, we need a to compose the functions a bit differently. The representation function should be applied to all arguments of an n-ary function before it is called.

As usual, we’re going to create a function object that stores both the projection and the main function.

template <typename Function, typename Projection>
class projecting_fn {
public:
    projecting_fn(Function function, Projection projection)
        : m_function{std::move(function)}
        , m_projection{std::move(projection)}
    {
    }

    // :::

private:
    Function m_function;
    Projection m_projection;
};

The main part is the call operator. It needs to project all the passed arguments and then call the main function with the results:

template <typename... Args>
decltype(auto) operator() (Args&&... args) const
{
    return std::invoke(
               m_function,
               std::invoke(m_projection, FWD(args))...);
}

This is quite trivial – it calls m_projection for each of the arguments (variadic template parameter pack expansion) and then calls m_function with the results. And it is not only trivial to implement, but it is also trivial for the compiler to optimize.

Now, we can use projections even with old-school algorithms from STL and in all other places where we can pass in arbitrary function objects.

To continue with the files sorting example, the following code sorts a vector of files, and then prints the files to the standard output all uppercase like we’re in 90s DOS:

    std::sort(files.begin(), files.end(),
              projecting_fn { std::less{}, &file_t::name });

    std::copy_if(
              files.cbegin(), files.cend(),
              std::ostream_iterator<std::string>(std::cout, " "),
              projecting_fn {
                  string_to_upper,
                  &file_t::name
              });

Are we there yet?

So, we have created the projected_fn function object that we can use in the situations where all function arguments need to be projected.

This works for most STL algorithms, but it fails for the coolest (and most powerful) algorithm – std::accumulate. The std::accumulate algorithm expects a function of two arguments, just like std::sort does, but it only the second argument to that function comes from the input collection. The first argument is the previously calculated accumulator.

Composition for accumulation

This means that, for accumulate, we must not project all arguments – but only the last one. While this seems easier to do than projecting all arguments, the implementation is a tad more involved.

Let’s first write a helper function that checks whether we are processing the last argument or not, and if we are, it applies m_projection to it:

template <
    size_t Total,
    size_t Current,
    typename Type
    >
decltype(auto) project_impl(Type&& arg) const
{
    if constexpr (Total == Current + 1) {
        return std::invoke(m_projection, std::forward<Type>(arg));
    } else {
        return std::forward<Type>(arg);
    }
}

Note two important template parameters Total – the total number of arguments; and Current – the index of the current argument. We perform the projection only on the last argument (when Total == Current + 1).

Now we can abuse std::tuple and std::index_sequence to provide us with argument indices so that we can call the project_impl function.

template <
    typename Tuple,
    std::size_t... Idx
    >
decltype(auto) call_operator_impl(Tuple&& args,
                                  std::index_sequence<Idx...>) const
{
    return std::invoke(
            m_function,
            project_impl
                <sizeof...(Idx), Idx>
                (std::get<Idx>(std::forward<Tuple>(args)))...);
}

The call_operator_impl function gets all arguments as a tuple and an index sequence to be used to access the items in that tuple. It calls the previously defined project_impl and passes it the total number of arguments (sizeof...(Idx)), the index of the current argument (Idx) and the value of the current argument.

The call operator just needs to call this function and nothing more:

template <typename... Args>
decltype(auto) operator() (Args&&... args) const
{
    return call_operator_impl(std::make_tuple(std::forward<Args>(args)...),
                              std::index_sequence_for<Args...>());
}

With this we are ready to use projections with the std::accumulate algorithm:

std::accumulate(files.cbegin(), files.cend(), 0,
    composed_fn {
        std::plus{},
        &file_t::size
    });

Epilogue

We will have projections in C++20 for ranges, but projections can be useful outside of the ranges library, and outside of the standard library. For those situations, we can roll up our own efficient implementations.

These even have some advantages compared to the built-in projections of the ranges library. The main benefit is that they are reusable.

Also (at least for me) the increased verbosity they bring actually serves a purpose – it better communicates what the code does.

Just compare

sort(files, less, &file_t::name);
accumulate(files, 0, plus, &file_t::size);

and

sort(files, projected_fn { less, &file::name })
accumulate(files, 0, composed_fn { plus, &file_t::size });

We could also create some cooler syntax like the pipe syntax for function transformation and have syntax like this:

sort(files, ascending | on_member(&file::name))

… but that is out of the scope of this post :)

---

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

Professor Igor Steinmacher, from Northern Arizona University, is a proeminent researcher on several social dynamics in open source communities, like support of newcomers, gender bias, open sourcing proprietary software, and more. Some of his papers can de found in his website.

Currently, Prof. Igor is inviting mentors from open source communities to answer a survey about task assignment in projects. See below the description of the survey and take some time to answer the questions – the knowledgement obtained here can be very interesting for all of us.

Hello,

My name is Igor Steinmacher, and I am a professor at Northern Arizona University.

Along with some other researchers we are currently studying the strategies that mentors use to assign tasks to newcomers to Free/Open Source projects.Your experience is very important to us given the limited number of people that mentor or guide newcomers in FOSS projects.

You are therefore, a perfect person to get feedback for our research.

We would really appreciate if you could spare about 5 minutes of your time to answer a brief survey about your experiences.
The survey is here: https://goo.gl/forms/qCzgoG3Uc4O0w9da2I would like to emphasize that, if shared, your insights will play a prominent role in creating a better understanding of the mentors’ strategies to assignment tasks for newcomers, serving as input for heuristics, and helping other mentors. Thank you very much in advance for your time, and please contact me if you have any question.

Regards,

Igor Steinmacher

I got a bit traction on KookBook and decided to fix a few bugs, mostly in the touch client, and add some features.

Get it here: kookbook-0.2.0.tar.xz

KookBook is now also available in Debian, thanks to Stuart Prescott

KRecipe converter
Some people has a large recipe collection in KRecipe and would like to try out KookBook. I wrote a convertion python script now available. It works in “current directory” and reads the krecipe database from there and outputs KookBook markdown files in same repository. It has so far been tried on 1 database.

Bug fixes

• Fix install of touch client
• Fixes in desktop files
• Fixes in touch client’s file open dialog
• Touch client now show images in recipes
• You could end up with no dock widgets and no toolbar and no way to recover in the desktop client. This is now fixed
• Build fixes

Future
Some people have started talking about maybe translation of the interface. I might look into that in the future.

And I wouldn’t be sad if some icon artists provided me with a icon slightly better than the knife I drew. Feel free to contact me if that’s the case.

Happy kooking!

This week in KDE’s Usability & Productivity initiative, something big landed: virtual desktop support on Wayland, accompanied by a shiny new user interface for the X11 version too. Eike Hein, Marco Martin, and the rest of the Plasma hackers have been working on this literally for months and I think they deserves a round of applause! It was a truly enormous amount of work, but now we can benefit for years to come.

We’ve also kicked off the Plasma 5.15 beta period. Here’s how you can test it with KDE Neon or Kubuntu.

Bug reports have already started to come in and we’re fixing them as fast as possible to ensure a smooth release next month on February 12th!

New Features

• The digital Clock widget now lets you change the date formatting however you please (Chris Holland, KDE Plasma 5.15.0):
  
• The Devices Notifier widget now has a button that lets you unmount all mounted disks at once (Thomas Surrel, KDE Plasma 5.16.0):
  

Bugfixes & Performance Improvements

• The NOAA Picture Of The Day wallpaper source works again (Tagore Chandan Reddy, KDE Plasma 5.15.0)
• Fixed a bug that could cause in-titlebar menus do disappear after restoring a session (David Edmundson, KDE Plasma 5.15.0)
• Info Center’s USB devices section now displays all USB devices (Alexandre Ferreira, KDE Plasma 5.15.0)
• All the hands on the Analog Clock widget now cast a shadow (me: Nate Graham and Shubham, KDE Plasma 5.16.0):
  
• Long tooltips in QML/Kirigami apps and windows no longer get cut off at the edge of the window (me: Nate Graham, KDE Frameworks 5.55):
  

User Interface Improvements

• The clock in the System Settings Date & Time page now looks good when using a fractional scale factor (me: Nate Graham, KDE Plasma 5.12.8):
  
• The wallpaper chooser view now looks good with all default wallpaper plugins when using a fractional scale factor (me: Nate Graham, KDE Plasma 5.15.0):
  
• The Network Monitor widget now features a clearer legend for its graph (me: Nate Graham, KDE Plas,a 5.15.0):
  
• It’s now easier to find and use KRunner’s time plugin (Aleix Pol Gonzalez, KDE Plasma 5.15.0):
  
• When searching for an app in KRunner, if Discover is opened as a result, it displays a search field as expected (Dan Leinir Turthra Jensen)
• KMail now lets you turn off the unread count badge on its Task Manager icon, which can be useful for people whose email workflows leave a lot of messages unread (Laurent Montel, KMail 5.11.0)
• Dolphin now warns you if you try to quit while the terminal panel is open with a still-running program (Roman Inflianskas and me: Nate Graham, 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 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.

I recently configured Travis CI to build Nanonote, my minimalist note-taking application. We use Jenkins a lot at work, and despite the fact that I dislike the tool itself, it has proven invaluable in helping us catch errors early. So I strongly believe in the values of Continuous Integration.

When it comes to CI setup, I believe it is important to keep your distances with the tool you are using by keeping as much setup as possible in tool-agnostic scripts, versioned in your repository, and making the CI server use these scripts.

Ensuring your build scripts are independent of your CI server gives you a few advantages:

• Your setup is easier to extend and debug, since you can run the build scripts on your machine. This is lighter than running an instance of your CI server on your local machine (nobody takes the time to do that anyway) and more efficient than committing changes in a temporary branch then wait for your CI server to build them to see if you got it right (everybody does that).

• It keeps the build instructions next to your code, instead of being stored in, say, Jenkins XML file. This ensures that you can add dependencies and adjust the build script in one commit. It also ensures that if your build script evolves, you can still build old branches on the CI server (for example because you have a fix to do on a released version).

• If your CI server is Jenkins or something similar, you spend less time cursing against the slow web-based UI (yes, I know about Jenkins Pipelines, but those have other problems...).

• It is easier to switch to another CI server.

With this in mind, here is how I configured Nanonote CI.

Create a Build environment using Docker

The first element is to create a stable build environment. To do this I created a Docker with the necessary build components. Here is its Dockerfile, stored in the ci directory of the repository:

FROM ubuntu:18.04

RUN apt-get update \
    && apt-get install -y -qq --no-install-recommends \
        cmake \
        dpkg-dev \
        file \
        g++ \
        make \
        ninja-build \
        python3 \
        python3-pip \
        python3-setuptools \
        qt5-default \
        qtbase5-dev \
        qttools5-dev \
        rpm \
        xvfb

COPY requirements.txt /tmp

RUN pip3 install -r /tmp/requirements.txt

ENTRYPOINT ["/bin/bash"]

Nothing really complicated here, but there are a few interesting things to point out nevertheless.

It installs dpkg-dev and rpm packages, so that CPack can build .deb and .rpm packages.

It also installs the xvfb package, to be able to run tests which require an X server.

Finally it copies a requirements.txt file and pip install it. This is to install qpropgen dependencies. This requirements.txt is in 3rdparty/qpropgen, which Docker cannot reach (because it only sees files inside the ci directory), so I created a simple ci/build-docker script to build the Docker image:

#!/bin/sh
set -ev
cd $(dirname $0)
cp ../3rdparty/qpropgen/requirements.txt .
docker build -t nanonote:1 .

This gives us a clean build environment, now lets create a build script.

The build script

This script is ci/build-app. Its job is to:

1. Create a source tarball
2. Build and run tests from this source tarball
3. Build .rpm and .deb packages

You may wonder why the script creates a source tarball, since GitHub automatically generates them when one creates a tag. There are two reasons for this:

1. GitHub tarballs do not contain repository submodules, making them useless for Nanonote.
2. I prefer to rely on my own build script to generate the source tarball as it makes the project less dependant on GitHub facilities, should I decide to move to another git host service.

Reason #1 also explains why the script builds from the source tarball instead of using the git repository source tree: it ensures the tarball is not missing any file necessary to build the app.

I am not going to include the script here, but you can read it on GitHub.

Travis setup

Now that we have a build script and a build environment, we can make Travis uses them. Here is Nanonote .travis.yml file. As you can see, it is just a few lines:

dist: xenial
language: minimal

services:
- docker

install:
- ci/build-docker

script:
- docker run -v $PWD:/root/nanonote nanonote:1 /root/nanonote/ci/build-app

Not much to say here: - We tell Travis to use an Ubuntu Xenial (16.04) distribution and Docker. - The "install" step builds the Docker image. - The "script" step mounts the source tree inside the Docker image and runs the build script.

Travis runs this on all branches pushed to GitHub. I configured GitHub to refuse pushes to the master branch if the commits have not been validated by Travis. This rule applies to all project contributors, including me. Since there is not (for now?) a large community of contributors to the project, I don't open pull requests: I just push commits to the dev branch, once Travis has checked them, I merge dev into master.

Releases

When it's time to create a release, I just do what Travis does: rebuild the Docker image then run the build script inside it.

Since the source tree is mounted inside the Docker image, I get the source and binary packages in the dist directory of the repository, so I can test them and publish them.

Travis has a publication system to automatically attach build artefacts to GitHub releases when building from a tag, but I prefer to build them myself because that gives me the opportunity to test the build artefacts before tagging and it prevents me from becoming too dependent on Travis service.

Conclusion

That's it for this description of Nanonote CI setup. It's still young so I might refine it, but it is already useful. I am probably going to create similar setups for my other C++ Qt projects.

I hope it helped you as well.

Facebook’s AccountKit is an authentication service that can use your email or phone number to login to your services, it doesn’t require that the user has a Facebook account, just a valid email or phone.

The cool thing about it is that it sends SMS for free, and although sending SMSs is cheap being free of charge is something you might want to look when creating a new App, in fact here in Brazil some big Apps do make use of it.

So long story short story I wanted to add this to my Qt Android App.

Thanks to the great help of Kai Uwe Broulik who had give some tips on the past on how to call Java code I started with this same approach:

• Create a Java file
• Put the Java code of AccountKit there
• Call the static function of Java from C++

And… it did work BUT I was unable to get the result, this is because the Java code starts a new Activity and returns the result on a method that must be implemented on the code that Qt creates for starting your activity, so this means I’d need to change the XML manifest to call my subclass instead of what Qt provides, and would need to do a bunch of other stuff myself, basically would get more maintainance work to do.

So another option would be to do all of this from C++, which Kai said it would be better at first, but doing a bunch of JNI scared me a bit, also I hadn’t found the reference page to their API (which he found after the work was done lol). There’s a tool called javap that can dump the Java signature of what is inside the package you got, so with the help of this we went on porting all the calls to AccountKit API to C++/Qt, this way we can call QtAndroid::startActivity() passing a pointer to a class that will handle the result of the new Activity, all in C++ .

There were some initial issues with the Enums used (aparently some new Java7 stuff), but the code now doesn’t require a single line of Java code, which is great when integrating in Qt Android Apps.

The result is on GitHub, so if you need this just copy the integration class, it has IFDEFs so if you are testing on !Android it will compile fine. (You still need to follow the Gradle and manifest integration that’s on their dev site), feel free to make PR for fixes and features

https://github.com/ceciletti/third-party-qt-utils

I totally missed that last week marked the one-year anniversary of my documentation and guidance of KDE’s Usability & Productivity initiative. I think we’ve achieved a lot over the course of that year!

Note that this is NOT an exhaustive log of everything that happened this week in the entire KDE community, or even in all of Plasma. The actual number of commits and improvements is always vast and enormous–too much to comprehend, really. The KDE Community is staggeringly productive.

Rather, this is always a curated list of only the user-facing improvements I believe are directly relevant to the Usability & Productivity initiative. And speaking of it, this week we got an interesting assortment of new features, bugfixes, and UI improvements–many of which I didn’t mention but will ultimately be appreciated when taken together. Check it out:

New Features

• Okular now features support for viewing and verifying digital signatures in PDF files(Chinmoy Ranjan Pradhan, KDE Applications 19.04.0):
  
• Gwenview now supports large 512 px thumbnails (Martin T. H. Sandsmark, KDE Applications 19.04.0)

Bugfixes & Performance Improvements

• Discover’s search on the Installed Apps page now works properly when the Snap backend is installed (Aleix Pol Gonzalez, KDE Plasma 5.15.0)
• The KWin window manager no longer crashes when a window is minimized via a script (David Edmundson, KDE Plasma 5.15.0)
• Header text throughout Plasma and KDE apps is no longer very thin–sometimes almost illegibly so–when using Qt 5.12 (Filip Filla and Krešimir Čohar, KDE Frameworks 5.55)
• Apps written in Qt that don’t use KDE Frameworks no longer get ugly ampersands inserted into user interface controls (Albert Astals Cid, KDE Frameworks 5.55))

User Interface Improvements

• On the Activities page in System Settings, the buttons are now vertically centered and no longer let you futilely try to delete the last activity, which is not deletable (David Edmundson and me: Nate Graham KDE Plasma 5.12.8):
  
• The System Settings Login Screen page received a number of visual improvements: The default Breeze theme’s image preview was updated to reflect its current appearance, the background color of the preview is now color-scheme-aware, and the sizes and margins were tweaked to make sure that everything fits without being cut off (Filip Fila, Björn Feber, and me: Nate Graham, KDE Plasma 5.15.0):
  
• The System Settings page for choosing window decorations buttons received a visual overhaul, fixing many bugs in the process (Valerio Pilo, KDE Plasma 5.15.0)
• The Devices Notifier no longer lets you futilely try to unmount the root partition when configured to display all disks rather than just removable disks (Thomas Surrel, KDE Plasma 5.15.0)
• Ported the System Settings Desktop Effects page to QtQuickControls 2, which fixes a number of issues such as bad fractional scaling appearance, ugly dropdown menu checkboxes, and the window size being too small when opened as a standalone app (me: Nate Graham, KDE Plasma 5.15.0):
  
• When using Discover to launch an installed app, the cursor now shows the “launching” animation (if one is configured) so you can tell that something is actually happening (Aleix Pol Gonzalez, KDE Plasma 5.15.0)
• The Plasma Device Notifier now shows a busy indicator while a device is unmounting (Thomas Surrel, KDE Plasma 5.15.0)
• Improved the padding and appearance of notification pop-ups (Krešimir Čohar, KDE Plasma 5.15.0):
  
• All search fields in Plasma and System Settings are now consistent in their use of text and ellipses (Krešimir Čohar, Filip Filla, and Björn Feber, KDE Plasma 5.15.0 and KDE Frameworks 5.55)
• Gwenview’s filter-by-name feature is now invokable using the ctrl+i shortcut, matching the behavior in Dolphin (me: Nate Graham, 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 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.

The first release of Nanonote, my minimalist note-taking app, was a bit rushed: I broke indentation shortly before tagging version 1.0.0... meh.

So here is version 1.0.1. It fixes the indentation and adds the ability to indent or unindent whole lines with Tab and Shift+Tab, in addition to the existing Ctrl+I and Ctrl+U shortcuts.

In addition to these changes, the build system can now generate Debian and RPM packages, making the application easier to install.

These packages are generated by CPack inside an Ubuntu 18.04 Docker. This means they work on my machine, but do not have the same level of quality as packages crafted by real packagers. I am especially looking for feedback regarding the RPM packages, which I haven't tested.

You can find them on the project release page.

There aren't any other end-user changes in this release but I worked on infrastructure a bit: I added unit tests and set up Travis CI for continuous integration. I am probably going to write an article about this next. In the mean time, enjoy Nanonote 1.0.1!

TL;DR; Get your tickets from here!

For the fourth year running, foss-north is taking place. Now bigger than ever.

It all started as a one day conference in a room with too much people in it. We gathered ten speakers and started something that continues to this day.

110 ten people in a room for 110 people.

Back then we, the three organizers: Jeremiah, Mikael and myself, joked over beers that we should have trainings, conference, community rooms and much more. A moderated FOSDEM was a crude description of what we wanted to build. But this was only us dreaming away.

During the past years we’ve tried different venues. We’ve gone from one day, one track to two days and two tracks. This year we decided to go for it all: four days, trainings, a community day and the conference.

Organizing a conference is to manage a chicken and egg type problem. You need speakers to get sponsors, and you need sponsors to get speakers to the venue. The same applies to the audience – visistors wants speakers, speakers wants visitors. This is why it takes time to establish a conference.

Last year we felt that we reached a tipping point – the call for papers was so full that we had to extend the conference with an additional day. We simply could not pick the right contents for a single day. This means that we feel that the conference part is established. If you want to speak, the call for papers is still open.

That takes us to the next steps. The community day consists of various projects and groups organizing workshops, hackathons, install fests, development sprints and whatnot throughout the city. We find venues (usually conference rooms) and projects and hope that people will come visit the various events. Again, starting from zero projects, zero venues and no real idea how many visitors to expect, we are trying to put this together. At the time of writing, it looks great. We have 7 projects and 5 venues fixed, but we are still looking for both projects and venues. If you want to join in, look at our call for projects.

The same logic applies to the training. Now we have training contents, all we need are visitors. The great thing is that our teachers, Michael Kerrisk and Chris Simmonds, are great to work with and understand our situation. Now we just have to work hard to make sure that we find students for them.

The final piece of the puzzle, which is not always visible to speakers and visitors, is the hunt for sponsors. Venues does not come for free, and we believe in compensating our speakers for their costs, thus we need sponsors. We offer the opportunity to host a booth during the conference days and the chance to meet our audience. We also believe that helping a conference focused on free and open source, is a way to contribute to the free and open source movement. For this we have a network of sponsors that we’ve worked with in the past (thank you all!) but as the conference grows, we need more help. If you want to join in, have a look at our call for sponsors

I’ve written a lot about speakers, sponsors and projects. Now all we need are visitors – lots and lots of visitors. So bring your friends to Gothenburg and join us at foss-north. The early bird tickets are available now. Get yours here!

With the ongoing work on realtime data access in KDE Itinerary we need a way show notifications in case of delays or other trip changes. That’s what KF5Notifications is for, which unfortunately isn’t supported on Android yet. Since an Android specific code path in KDE Itinerary for that would be quite ugly, I did look into adding Android support for KF5Notifications. How hard can it be? ;)

KF5Notifications on Android

C++/Java Integration

How to do notifications with the official Android Java API is widely documented, and also matches the model of KF5Notifications well enough. This would however be the first KF5 framework using Android Java API for its backend, so I’ll focus on these integration bits here.

On the code level this means we need to be able to call Java code from C++ (to trigger a notification), and vice versa (to handle user interaction with the notification), and we need to be able to pass data back and forth.

The mechanism for this is the Java Native Interface (JNI), of which Qt abstract some parts via QAndroidJniObject. Qt itself contains a number of examples on how to use this, and you can look at the KF5Notifications code in D17851. The JNI signature syntax takes a bit of getting used too due to its built-in traps (like a different way of writing fully qualified class names compared to Java code), but at least you usually get helpful debug output at runtime in case of a mistake.

Building and Deployment

The build system integration turned out to be the most challenging part, as the framework consists of a Java part and a native part now. The general idea is that the framework builds and installs a Java library next to the native library, and provides a meta data file that tells androiddeployqt to also integrate the Java part when linking against the native part.

This is done in several Qt modules, but using qmake rather than CMake. Also, Qt only does this for Java code using the official Android Java API, not for using the Android support libraries, which is needed in case of notifications to simultaneously provide compatibility with older Android versions and to comply with requirements of very recent Android versions or the Google Play Store.

Building JARs

The first attempt was following closely what Qt does, and just implement that with CMake. You’ll find the code in D17851. There’s already basic Java support in CMake that makes this pretty straightforward, it essentially just builds a JAR library from a given set of Java source files using the Java compiler directly.

This approach works as long as you just use the basic Android API and don’t need any dependency outside of the normal Android SDK. But as that’s not enough for notifications, we needed another way.

Building AARs

The Android support library (and presumably other higher-level dependencies) break this approach in two places:

• The canonical way of accessing dependencies on Android is via Maven repositories. Neither CMakre nor the raw Java compiler support that easily.
• Those libraries are not regular Java libraries (JAR files) but Android libraries (AAR files). That’s essentially a ZIP file bundling the JAR file as well as resources, manifest elements, and other things you might find in an Android APK. However, this is also not directly supported by the Java compiler.

In order to consume AAR files we use the default Android way, building with Gradle (which is also what androiddeployqt does when building APKs). Obtaining and running Gradle is hidden behind a small CMake macro for easy integration, but how to build the Java side is now specified in a build.gradle file rather than in CMake files. This means all Android development related tools and resources become applicable for us. Besides the automatic dependency handling and inbound and outbound support for AAR libraries also things like using Kotlin should be possible. This approach has been implemented in D17986.

Consuming the result in the application is almost identical to the JAR case, we only needed a minor tweak in the androiddeployqt template for this.

Conclusion

Starting with KF5 5.55 we will have basic support for notifications, notification interaction and notification actions on Android. There’s probably still a number of features and flags in KF5Notifications that can be better mapped to Android’s native system, and there’s still work to be done to improve compatibility with a wider range of Android versions, but it’s a good start. But maybe even more importantly, we now have a template for integrating Android Java code in KF5 frameworks.

A bit more than a year ago, the KDE community decided to focus on a few goals. One of those goals (the most important one as far as I’m concerned) is to increase the users’ control over their private data.

KDE developers and users have always been a privacy-minded bunch. But due to all the fun things that have happened in the recent years, we had to switch to the next gear.

We have seen new projects like KDE Itinerary (by Volker), Plasma Vault (by yours truly), Plasma Mycroft (by Yuri and Aditya), etc. There has also been a lot of work to improve our existing projects like KMail.

Now, this post is not about any of these.

It is about a KDE Privacy developer sprint organized by Sando Knauß.

The sprint will be held in Leipzig (Germany) from 22. 3. to 26. 3. and all privacy-minded contributors are invited to join.

Leipzig

---

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

As of a few minutes ago, i merged the code from Chinmoy Ranjan Pradhan's GSOC to support showing PDF Signatures and Certificates in Okular.



Signature handling is a big step for us, but it's also very complex, so i expect it to have bugs and things that can be improved so testers more than welcome.

Compiling is a bit "hard" since it requires poppler 0.73 that was released a few days ago.

But thanks to flatpak, there's no need to compile it, you can run the KDE Okular Nightly on your system to try it

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.okular

Note: if you have okular installed from another flatpak repo (for example flathub) this will switch you to the KDE Nightlies, you may want to switch back after testing.

And then you can try the adobe sample pdf
flatpak run --share=network org.kde.okular https://blogs.adobe.com/security/SampleSignedPDFDocument.pdf

And you should get stuff like this

It’s the second week of 2019 already, which means I’m curious what Nate is going to do with his series This week in usability .. reset the numbering from week 1? That series is a great read, to keep up with all the little things that change in KDE source each week — aside from the release notes.

For the big ticket items of KDE on FreeBSD, you should read this blog instead.

In ports this week (mostly KDE, some unrelated):

• KDE Plasma has been updated to the latest release, 5.14.5.
• KDE Applications 18.12.1 were released today, so we’re right on top of them.
• Marble was fixed for FreeBSD-running-on-Power9.
• Musescore caught up on 18 months of releases.
• Phonon updated to 4.10.1, along with its backends.

And in development, Qt WebEngine 5.12 has been prepared in the incongruously-named plasma-5.13 branch in Area51; that does contain all the latest bits described above, as well.