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

Go get  v0.9.10  from*

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


The new code that ignores ALL plasma popups has a side effect to ignore also KRunner and Yakuake. For v0.9.x unfortunately I can not add any workaround, for v0.10~ users this is already fixed.

  • dodge all windows, work properly after the dock becomes hidden and not show inappropriately when any window touches the dock
  • fix mask calculations for NO COMPOSITING environments
  • fix blur for Latte panels when exiting edit mode
  • protect LastActiveWindow application data updating in multi-screen environments and dont assign faulty application name and icons to irrelevant last active windows
  • fix right click context menu for Group plasmoid. Take note that Group plasmoid can only be used in Single Layout mode and NOT in Multiple Layouts mode. It is scheduled to be fixed in next major stable version
  • fix Indicators positioning when a Task is bouncing or requires attention
  • x11: smart way to ignore all plasma popups
  • wayland: smart way to ignore all plasma popups but first Plasma needs to update its popup flags in order to work correctly
  • support Chromium/Chrome audio channels for Tasks previews and context menu


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

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


26 March, 2020

Today we’re finally releasing Krita 4.2.9! It’s been one of the most complicated releases we’ve ever attempted. When we updated the version of Python that’s embedded in Krita, scripting broke on Windows. When Apple updated its notarization protocol, building broke on macOS. And then we updated to a newer version of some of the libraries we build Krita on, and that broke all kinds of things. And then we needed to figure out a new way of packaging Krita for the Windows Store, which unfortunately broke our nice icons…

Krita 4.2.9 however is really stable after all the testing it had during the beta period. And there are even some new features to enjoy!

  • Dmitry improved the brush outline: it no longer flickers when you hover over the canvas:
  • He also added “Airbrush” and “Airbrush Rate” to the Color Smudge brush, and a new Ratio setting, also for the Color Smudge brush, which allows making the shape of the brush flatter using the different sensors. Ramón Miranda has even made a video demonstrating these features:
  • New contributor Saurabh Kumar added a “Split Layer into Selection Mask” feature:Layer Split Dialog

As for the bugfixes… There are a lot of them, and this list isn’t even completely complete!

  • Fix transparency checkers looked white on HDR display bug 406698
  • Several fixes to file dialogs for overwriting and jpg files bug 412651
  • Fix Grow Selection expanding in one direction bug 414647
  • Fix crash using onion skins on non-animated layers bug 414668
  • Increase the limit in Layer Offset to 100k bug 414625
  • Fix crash opening .kra with incorrect clone source (related to bug 414699
  • Prevent crash on addition of color to deleted palette with colorpicker bug 413548
  • Make Add subbrush off on changing multibrush tool’s type from Copy Translate bug 415651
  • Improve rendering of predefined default Rect dab
  • Set the default location for restored files to QStandardPaths::PicturesLocation bug 415810
  • Don’t crash if remoteArguments is called when there isn’t a mainwindow bug 415794
  • On Android, default to TouchGesture for Kinetic Scrolling
  • Delay initialization of brush paintop widget state bug 415033
  • Reenable breeze: with the latest release, the bug with comboboxes has been fixed
  • Show the hand cursor if there is no colorize mask yet bug 415935
  • Fix logic for enabling/disabling options in stroke selection dialog bug 415896
  • ORA export, write entire layers instead of cropping them
  • Fix endless recursion when assigning a profile bug 414818
  • Fix a crash when cancelling Transform Tool action bug 414672
  • Fix an obviously wrong assert in the gradients bug 414550
  • Fix 1px brush offset in line tool bug 407405
  • Fix Layer Filter Combobox with Breeze theme bug 406595
  • Fix comparison of double spin box
  • Fix PaletteDocker not showing palettes bug 414890
  • Fix undo of replacing vector selection bug 412808
  • Separate krita log dialog from system information
  • Resource bundle: turn assert into check bug 399008
  • Fix the python Canvas.setRotation method bug 416126
  • Store and restore the geometry of the svg editor window bug 416097
  • Fix number of asserts with continued transform bug 415625
  • Fix Touch Docker save button not working on new files bug 407905
  • Fix blur Filter inconsistencies bug 416241
  • Fix border artifacts in layer styles bug 414582
  • Use Qt::Popup for color selectors popup widgets bug 410959
  • Always show color popup below the cursor bug 394139
  • Remove the strength compatibility with older paintop presets bug 416335
  • Fixed unneeded error message in Render Animation. bug 412599
  • Fix canvas offset calculation bug 416352
  • Layers with alpha channel disabled correctly export as “svg:src-atop” for ORA
  • Add icon to Close button of “About Krita” dialog box
  • Fix memory leak in preset history docker
  • Warn that Krita needs to be restarted after enabling/disabling plugins bug 416575
  • Workaround Qt 5.14’s colormanagement preventing png files from being saved bug 416515
  • Fixes with last used filter command. bug 416706
  • Fix Increase/Decrease Brush Size and Switch To Previous Preset buttons
  • Fix Warp and Cage transform in master bug 416505
  • Fix crazy snapping when resizing shapes bug 414336
  • Fix hiccups when doing canvas actions bug 414576, 415773
  • Fix animation rendering problem on small images (< 100px in size) bug 415367
  • Fix display of vector shapes when transformed with transform tool bug 417016
  • Fix hangup when loading image with generator/file layers bug 415891
  • Fix slowdown associated with the quick hide function of Shift+click on layer visibility icons
  • Fix canvas border color issue
  • Fix issue when saving preferences
  • Hide SubWindow decoration on macOS
  • A number of fixes with L*A*B* and CMYK thanks to L.E Segovia’s Season of KDE work
  • Android: Make it possible to select opengles
  • Set setRedirectPolicy as per discussion on KDE mailing lists
  • Fix crash when loading asl with tdta OSType
  • Make “Save Incremental Version” update recently used files
  • Correct logic for determining whether there are multiple backups requested bug 417914
  • Fix incorrect common curve in very old presets bug 417748
  • Fix layout issue in the history docker
  • Fix strobbing of the brush outline because of subpixel precision bug 374551
  • Make local selection outline visible on layer converted to selection mask
  • Fix freeze on vector layers bug 412746
  • Fix artifacts on filter masks applied to adjustment layers bug 417673
  • Fix ratio option on lower precision brushes
  • Fix opening Appimages bug 418230
  • Set image as modified after a legacy action (fix Channels docker not updating in some cases) bug 417992



If you’re using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.


(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)


Note: the gmic-qt is not available on OSX.

Source code


For all downloads:


The Linux appimage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key over https here: 0x58b9596c722ea3bd.asc. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos! With your support, we can keep the core team working on Krita full-time.

Plasma Bigscreen main menu.

Plasma Bigscreen is KDE's user interface for big TV screens.

Plasma Bigscreen powers the interface on a Single Board Computer and uses the Mycroft AI voice assistant to provide a Smart TV platform. Plasma Bigscreen will deliver not only media-rich applications, but also traditional desktop applications redesigned to fit the Bigscreen experience.

Advantages of Plasma Bigscreen

  • Free (as in Freedom) and Open Source: One of the most important goals of this project is to hand control over to the people and the industry so they can build and power smart devices without the limits of other closed TV environments. Plasma Bigscreen is completely Free and Open Source and gives everyone the freedom to use, acquire, change and redistribute the software how they see fit. It also gives people the freedom to create, innovate and improve on top of the Plasma Bigscreen and share their work with the world.
  • Innovative: Plasma Bigscreen transforms the traditional plasma workspace experience into something that is controlled with a regular TV remote control. This is new territory for KDE interface designers and requires a new thinking of how to layout applications and how to make it easy for people to interact with Plasma from their couches.
  • Voice Control: Talking of interacting from the couch, voice control provides users with the ultimate comfort when it comes to TV viewing. But most big brands not only do not safeguard the privacy of their customers, but actively harvest their conversations even when they are not sending instructions to their TV sets. We use Mycroft's Open Source voice assistant to solve this problem.

    For the current beta img, the team connects to Mycroft's Home server, which by default uses Google's STT (Speech to text) which sends anonymized utterances to Google. This, of course, is not ideal, but being Open Source, you can switch out the back end and use whatever you want, even self-hosted systems like Mozilla Deepspeech. Or you can de-activate voice recognition altogether. Your choice.

    With Mycroft AI, the Bigscreen team intend to give users all the comfort of a smart voice controlled assistant with the advantages of the control over you privacy you can only achieve with Open Source software.

  • Easy to Expand: Mycroft's AI uses what are called "skills". Skills allow the assistant to learn about and perform different tasks. A weather skill, for example, lets Mycroft know about the weather and tell you what the day is going to be like; a cooking skill retrieves recipes and instructions and you can then ask Mycroft to help you make a delicious meal. There are already many skills in Mycroft's library and Mycroft AI's graphical framework for skills is built on top of Qt and Kirigami, two mature development frameworks. This allows third-party developers to use Python and QML to develop rich voice skills for the platform, which means features on KDE Bigscreen will multiply and provide even more functionalities to viewers.

    Simple settings make Bigscreen easy to tweak.

  • Community Supported: Plasma Bigscreen was created and is being maintained by KDE developers. KDE is one of the oldest, largest Free Software communities in existence and builds and maintains literally hundreds of projects, spanning from a full-featured desktop environments and development frameworks, to educational software and creativity apps. With the support of KDE, Plasma Bigscreen will develop quickly and grow to have as many features as users require.

Coming to a Screen Near You

The upcoming beta release for Plasma Bigscreen is already working on the Raspberry Pi 4. It's targeted to run on a TV screen, but will also work fine on a regular monitor.

The interface is largely designed to be easy to use with a remote control. There is experimental support for HDMI-CEC in the beta image, so anyone with a TV that supports HDMI-CEC can choose to use their TV remotes.

The YouTube app.

As one of the key features of Plasma Bigscreen is Mycroft's voice-controlled applications/skills, it's recommended to use a USB/Bluetooth remote with a microphone to try it out. Some recommended generic USB remotes are the WeChip G20 / W2 remote controls. It can also be used with a keyboard / mouse and any USB microphone.

For a more in-depth look at Plasma Bigscreen, check out Marco Marin's and Aditya Mehra's write ups on this new project.

A Plasma Bigscreen Beta Image For Raspberry Pi 4

In this blog post I would like take you through an introduction to Mycroft GUI Skills and Voice Applications technology on Plasma Bigscreen and showcase some of the interesting stuff I have been working on for the Plasma Bigscreen Project which are available on the beta image release for the Raspberry PI 4. This beta image show cases not only media-rich voice applications but also applications specialised to fit the Bigscreen experience all developed under an open process, more information on them in the sections below.

Plasma Bigscreen is the free open-source user interface experience for those big TV Screens, It consist of KDE Plasma technology powering the User Interface with Mycroft AI’s voice assistance technology packaged together on the image to provide a Smart TV platform and is based on KDE Neon.

The experience when sitting 10 feet away from your TV just isn’t complete without having the ease of access to control it and that’s exactly the space in which Mycroft AI the open-source voice assistant experience fits right in to provide you with that hands free easy interaction.

Discover Mycroft AI GUI Skills

Mycroft AI skills allow the assistant to learn and perform different tasks. A weather skill, for example, allows Mycroft to discover the weather and tell you what the weather on a day is going to be like; a cooking skill retrieves recipes and instructions and you can then ask Mycroft to help you make a delicious meal. There are already many voice skills available in the Mycroft skill repository that you can explore and more being quickly developed everyday.

Mycroft AI Date-Time Skill
Mycroft AI Weather Skill

Mycroft AI’s graphical framework for skills is built on top of Qt and Kirigami, two mature development frameworks. This allows developers to use Python and QML to develop rich voice skills with graphical user interfaces for multiple platforms, Voice Applications featured on Plasma Bigscreen beta image are based on this combination of both voice and display technologies, where we expand Mycroft Skills with a GUI to also work as applications that can be controlled voice and physical key interaction.

A Look Into Voice Application

Voice can be a very powerful tool for interacting with applications, it can complement an application by reducing the number of actions required to execute a certain task by the user be it searching for a file or searching for music, simply asking an application for example to play a song can make things a lot simpler than opening an application, hitting the search tab / field, typing a song and hitting the play button.

Voice applications on the beta plasma bigscreen image are designed to be simple and powerful to use no matter what method is chosen to interact with them, let’s look at the Youtube Voice Application for instance.

The Youtube Voice Application is a GUI based skill for Mycroft AI, All of its logical functions are handled and called within its skill class, Adding a desktop entry and icon for the gui based skill is what partially turns the GUI skill into a Voice Application, the other bits include simply adding a landing page or the “homescreen” and registering it in the skill class using the gui event handler that is first presented to users when they execute the skill from the desktop entry, some more in-depth information on installation and this architecture can be read in the Voice Application Guidelines.

Simple Starting Point For Key Based Navigation in Mycroft Skills With A GUI Interface the “Homescreen”

The homescreen of a voice application can be considered the traditional equivalent of a home tab on a normal application, in the case of the Youtube Voice Application it consist of showing several categories of available videos, your recently watched history and search, It is presented to be navigable by simple arrow keys for selecting and browsing videos from the various video categories. The homescreen can be a simple page showcasing Mycroft Examples or as complex as the skill author requires the page to be as is the case above.

Youtube Voice App Homepage
Youtube Voice App Search Page
Simple Homepage With Skill Examples

The API documentation for developing Voice and GUI based skills and converting them to Voice Applications for Plasma Bigscreen is available on the following links below:

Aura Browser – Designed To Be Controlled By Just Your Remote

Aura Browser

I would like to introduce you to the Aura Browser, It is a new browser based on QtWebEngine that I had the opportunity to work on for the Plasma Bigscreen beta image, It is completely designed to work with simple arrow key navigation that complements browsing the web with just a Remote Control without the requirement of a physical mouse. It features a virtual mouse controlled by arrow keys with auto scrolling, has support for tab based browsing, basic bookmarks and basic downloads and permission management.

This browser in its early stages but is available on the Plasma Bigscreen beta image release for the Raspberry Pi 4. The browser source can be found at:

Aura Browser Start Page
Aura Browser – Website View With Virtual Mouse

Today I want to introduce a project I have been working on together (mostly in the background) with some colleagues of mine… Now with beta status reached, it’s time to more publicly talk about it: enter Plasma Bigscreen.

Smart TVs are becoming more and more complete computers, but unfortunately there the experience tends to be a tight walled garden between proprietary platform, services and privacy-infringing features. Features which are very cool, like voice control, but in order to not pose a threat to the user privacy should be on a free software stack and depending less on proprietary cloud platforms where possible.

Plasma BigScreen is a platform intended to use on smart TVs (trough a powerful enough small computing platform, such as the Raspberry Pi4, or any tiny computer if you need more power) with big remote-friendly UI controls, and Voice activation. What technology did we use for it? Plasma (of course!) and Mycroft.

Plasma Bigscreen main user interface

Plasma Bigscreen is an user interface for TVs providing a 10 foot UI for a smart TV experience (on TVs or any screen with an HDMI connection). It is a Plasma Shell, just like our beloved Plasma Desktop and Plasma Mobile.

It uses the familiar look and feel of Plasma but optimizes all the user interaction to be perfectly readable from the distance and controllable with ha simple basic remote control… from your couch.

Besides interaction with a remote control, it also supports a modern way of iteracting that is revolutionizing the UX on all kind of devices: voice interaction. Optionally, it can integrate seamlessy with Mycroft: an opensource project aimed to offer a completely free voice assistant.

Mycroft offers what are the so-called “skills”. Each skill, takes care of a particular voice interaction. there is an huge variety available, from the weather, do date/time and reminders, to online services clients such as soundcloud and Youtube, with comprehensive QML bindings to show a rich User Interface in a Plasma Environment.

We prepared a beta image for the Raspberry Pi4 for anyone to try, in which we pre-configured Plasma Bigscreen with Mycroft integration ready to go.

If you have a Raspberry Pi4, you can try this image immediately: you can find it here: just flash the file on a MicroSD and is ready to go on any Pi4.

Note that on that image, we point the device to the official Mycroft company’s “Mycroft Home” service, which internally uses the Google STT (Speech to text) which does use google but in a more anonymized fashion as this is not tied to your Google account (nor requires having one). Tough not ideal, it’s possible to configure the Mycroft core to use different services, even those you can self-host like Mozilla Deepspeech.

In here to emphasize voice controls, we prepared some skills (some preinstalled, some can come from the kde store) to fully show voice controls. In particular a Youtube client skill which is perfectly usable both from a remote control and voice only.

Youtube skill shipped in the image

As remote control, you can use the remote of your TV directly if it supports the CEC standard, or any of those remotes with an usb dongle which are “seen” as a keyboard with just few standard keys (some have also an integrated microphone, so giving voice commands is very easy).

In the next days, there will be more posts explaining the architecture and the technical choices we made, in the mean time, have a try and if you want to get in contact with us about the project, you can find directions here.


25 March, 2020

A unified theme? Why? Why not?

Nearly all KDE websites use a unified theme across the board. This is part of the consistency goal, chosen as a KDE goal at the last Akademy in Milano (Italy).

Using a unified theme has multiple advantages:

  • It strengthens KDE’s brand, since websites are more visible than applications or projects part of the KDE community. Websites with a unified look help visitors immediately identify an application or subproject as being part of a bigger organization.

  • It is easier to maintain only one theme and the tooling behind it than a theme for each project. We all wish Free and Open Source projects had unlimited budgets and manpower, but that is not realistic and maintaining a theme is not an easy task.

This doesn’t mean the KDE theme should be used for every KDE project, in fact, there are legitimate reasons not to. Sometimes an application under the KDE umbrella wants to create their own brand and does have the manpower and talent to design their own website. Krita is a good example here. The team has built a beautiful website that does not use the unified theme.

What theme does KDE use?

KDE is using the Aether theme. This is a theme designed and initially developed by Ken Vermette, the talented artist that is also behind most of the Plasma wallpapers and some interesting design concept like DWD.

This theme was originally based on one of the first Bootstrap 4 alpha version and later rebased on a stable Bootstrap 4 version. Using Bootstrap has its advantages and disadvantages.

The biggest advantage is that it has a large community and a lot of bootstrap themes exist for CMS and static site generators. It can be easily adapted to your specific needs without starting from scratch every time.

Another advantage is that Bootstrap is built using SASS and is designed to be extendable with tons of variables a developer can modify to globally change colors, layouts and a lot more. You can also specify the modules you want to use, and add your self-made components. For those interested in extending a Bootstrap theme, the official documentation is a great start. These capabilities were sadly not used when creating the Aether theme, but we are slowly moving to use more of the Bootstrap theming capabilities over time.

The problem with Boostrap is that, because it is so popular, in its default from it looks like a generic website without any personal identity. Changing only the colors won’t help to make your website more unique.

Building the websites

In KDE we use a lot of different web frameworks for our websites. Most of the applications websites are now using Jekyll or Hugo, but some are also using Wordpress, Drupal 7 and Drupal 8.

Jekyll has first-class support for creating a shared theme, so we created a Jekyll theme for KDE using the Aether theme that offers a lot of options. Here are two examples:

  • Should it display a Made By KDE logo? This is useful for application websites but shouldn’t appear on, for example, the KDE e.V. website.

  • Should it display a KDE logo or the application logo?

This allows for small customizations with only a few changes for each website without having to maintain different versions.

Some websites are using Hugo instead of Jekyll. The reason for this is that Hugo is faster when generating the webpages and has more advanced internationalization features included by default. The internationalization features are used for and the monthly application release announcements.

For my WIP replacement for the KDE Dot, I needed the performance of Hugo. With Jekyll, I gave up generating the website after 10 minutes, but with Hugo, it only took a few seconds to generate.

In the case of Content Management Systems, creating a theme is also well-supported but it isn’t as pleasant to do. I have a limited experience with Wordpress, but creating a theme was still possible and not too complicated. In the case of Drupal 7, creating a theme from scratch is almost impossible. It requires messing with a lot of PHP arrays and the security responsibility is on the side of the theme developer.

Deployment of the theme

To deploy the theme, I use Symfony Encore. Sympfony Encore is a webpack wrapper. I chose Symfony Encore because I’m very familiar with its PHP framework and I have been working with it since I was in high school (using Webpack alone would have been completely fine too).

Webpack is used to compile and optimize the SCSS and ECMAScript (aka JavaScript). After each commit to the master branch, a CI job compiles and deploys the compiled CSS and ECMAScript to a CDN host and the hosted CDN asset is then used by all the new KDE websites. This means that my changes are immediately propagated to all websites… or so I thought initially. In reality the CSS and JS files are cached for a long time and often visitors get an old version.

I’m solving this problem in two ways:

  • For dynamic websites: I also generate a versioned version of the assets and resolve the version in the backend. This is what I used in the MediaWiki plugin, for example.

  • For static websites: In this case, I can’t dynamically resolve the last version in the backend, so instead I add a GET parameter to the URL (e.g. main.css?v=10) and increase the number each time I fix a bug. This doesn’t happen often, so it is still easy to manage.

How you can help

We always need help with the websites, fixing papercuts, upgrading old websites to the new Jekyll/Hugo infrastructure, making sure information on the website is up-to-date, creating new beautiful home pages for your favorite projects and a lot more.

The Elisa maintainers are still looking for someone who wants to create a website and we created a junior job task for this. Maybe that someone could be you?

You can also join the web team through our Matrix channel, our IRC channel (#kde-www) or our Telegram channel.

rust is quite a neat language, isn't it? gigantic library ecosystem, memory safety, tons of developer-friendly tools in it. for Ikona, I decided to utilise this language, and instead of relying on binding generators that hide half the magic away from you, I wrote all bindings by hand.

rust –> C++ by hand: how?

obviously, rust and C++ are different programming languages and neither of them have language-level interop with each other. what they do both have is C. C—the lingua franca of the computing world. unfortunately, C is a very bad lingua franca. something as basic as passing arrays between programming languages becomes boilerplate hell fast. however, it is possible and once you set up a standardised method of passing arrays, it becomes far easier.

rust to C

so, in order to start going from rust to C++, you need to stop at C first. for Ikona, I put C API bindings in a separate crate in the same workspace. you have a few best friends when writing rust to C here: – #[no_mangle]: keeps rustc from mangling your symbols from pure C – unsafe: because C is ridiculously unsafe and Rust hates unsafety unless you tell it that you know what you're doing – extern "C": makes rust expose a C ABI that can be eaten by the C++ half – #[repr(C)]: tells rust to lay out the memory of a thing like C does – Box: pointer management – CString: char* management

memory management

Box and CString are your friends for memory management when talking to C. the general cycle looks like this:

pub unsafe extern "C" new_thing() -> *mut Type {
    Box::into_raw(thing) // for non-rustaceans, the lack of a semicolon means this is returned
pub unsafe extern "C" free_thing(ptr: *mut Type) {

into_raw tells rust to let C have fun with the pointer for a while, so it won't free the memory. when C is done playing with the pointer, it returns it to Rust so it can from_raw the pointer to free the memory.


for Ikona, I didn't bother attempting to convert Rust structs into C structs, instead opting for opaque pointers, as they're a lot easier to deal with on the Rust side.

an average function for accessing a struct value in Ikona looks like this:

pub unsafe extern "C" fn ikona_theme_get_root_path(ptr: *const IconTheme) -> *mut c_char {
    assert!(!ptr.is_null()); // make sure we don't have a null pointer

    let theme = &*ptr; // grab a reference to the Rust value the pointer represents

    CString::new(theme.root_path.clone()).expect("Failed to create CString").into_raw() // return a char* from the field being accessed

this is very similar to how calling methods on structs is bridged to C in Ikona.

pub unsafe extern "C" fn ikona_icon_extract_subicon_by_id(
    ptr: *mut Icon,
    id: *mut c_char,
    target_size: i32,
) -> *mut Icon {
    assert!(!ptr.is_null()); // gotta make sure our Icon isn't null
    assert!(!id.is_null()); // making sure our string isn't null

    let id_string = CStr::from_ptr(id).to_str().unwrap(); // convert the C string into a Rust string, and explicitly crash instead of having undefined behaviour if something goes wrong

    let icon = &*ptr; // grab a reference to the Rust object from the pointer

    // now let's call the method C wanted to call
    let proc = match icon.extract_subicon_by_id(id_string, target_size) {
        Ok(icon) => icon,
        Err(_) => return ptr::null_mut::<Icon>(),

    // make a new Box for the icon
    let boxed: Box<Icon> = Box::new(proc);

    // let C have fun with the pointer


enums are very simple to bridge, given they aren't the fat enums Rust has. just declare them like this:

pub enum IkonaDirectoryType {

and treat them as normal. no memory management shenanigans to be had here.

ABI? what about API?

C has header files, and we need to describe the C API for human usage.


since Ikona operates on opaque pointers, C just needs to be told that the type for a struct is a pointer.

typedef void* IkonaIcon;


enums are ridiculously easy.

pub enum IkonaDirectoryType {


typedef enum {
} IkonaDirectoryType;

not much to it, eh?


methods are the most boilerplate-y part of writing the header, but they're fairly easy. it's just keeping track of which rust thing corresponds to which C thing.

this declaration

pub unsafe extern "C" fn ikona_icon_new_from_path(in_path: *mut c_char) -> *mut Icon {


IkonaIcon ikona_icon_new_from_path(const char* in_path);

C to C++

once a C API is done being written, you can consume it from C++. you can either write a wrapper class to hide the ugly C or consume it directly. here in the KDE world where the wild Qt run free, you can use smart pointers and simple conversion methods to wrangle with the C types.


the big advantage for Ikona here is the library ecosystem for Rust. librsvg and resvg are both Rust SVG projects that Ikona can utilise, and both are better in many ways compared to the simplistic SVG machinery available from Qt. heck, resvg starts to near browser-grade SVG handling with a huge array of things to do to SVGs as well as general compatibility. Ikona barely taps into the potential of the Rust world currently, but future updates will leverage the boilerplate laid in 1.0 in order to implement new features that take advantage of the vibrant array, high performance, and fast speed of available Rust libraries.

what I would have done differently

writing a bunch of rust to C boilerplate isn't fun, especially with arrays. since glib-rs is already in the dependency chain of Ikona, I should have utilized the GList instead of writing my own list implementation.

tags: #libre

SoK ended finally on 17th February 2020. I am happy to share that I have completed the project “Add multiple datasets to several activities” and passed the final evaluation!!!

I was left with some work to complete as:

  1. To implement multiple datasets to balance scale with ounce.
  2. Test the activities on a different platform.

As now I have implemented datasets to all of the activities as mentioned in my proposal.


As these activities teach the child arthmetic operations by balancing the scales using pounds or ounce. So, I have added the datasets with five different configurations.


What after SoK ???

The day I started contributing to this project I have faced a lot of difficulty in the beginning as this was one of my first open source to which I have contributed. But now I am familiar with all of the concepts, principles, and codebase of GCompris. I am looking forward to adding multiple datasets to other activities and add a new activity “Garbage Recycle” to GCompris.

Once again a big thanks to all of my mentors Johnny, Emmanuel, Timothee for all of their help and support. I would also like to thanks the KDE community for conducting such a great program every year.

Deepak Kumar !!!

Finally, I am going to write about my experience as a student of Season of KDE 2020. A winter learning new things, learning what matters is not just writing code but writing good code. I would like to thank GCompris and KDE for giving me such an opportunity to be a part of the community and to try to bring happiness to people and kids using it around the world.

I had to complete the following tasks during this period:

  1. Improve multiple datasets of clock game activity.
  2. Add multiple datasets to balance scales.
  3. Add multiple datasets to balance scale with kgs.
  4. Add multiple datasets to balance scales with ounce.

Since few weeks are still left for SoK to come to an end. Till now, I have completed the following tasks:

  1. Implemented new multiple datasets to clock game activity which got merged to the multiple_dataset branch.
  2. Added multiple datasets to balance scales activity which is under review by the mentors.
  3. Added multiple datasets to balance scales with kgs activity which is under review by the mentors.

Clockgame Activity:

I started my work on this activity. The goal of this activity is to teach a child how to see the clock. Initially, this activity contains dataset only with two different level selections. I have added the multiple dataset to this activity with 5 different level selections to better fit to the french school learning programs.


I have also added a OK button to check the answer. Finally, the datasets has been merged to multiple_dataset branch.


Balance scales activity:

This activity goal is to teach the child about the arithemetic calculation by balancing the scales of different weights. The balance scales activity has 3 sub activities as mentioned above:

  1. Adding multiple datasets to balance scales.
  2. Adding multiple datasets to balance scales with kgs.
  3. Adding multiple datasets to balance scales with ounce.

I have added multiple datasets to balance scales and balance scales with kgs which is under review by the mentors. balance_d

I am left with the following work which I would complete in the coming weeks.

  1. To add multiple datasets to balance scale with ounce.
  2. Test the activities on a different platforms.

I am thankful to my mentor Johnny Jazeix and Emmanuel Charruau for giving me this opportunity and helping me always during the SoK period. I have learned a lot of things during this period and have a great learning experience as of development coding. I am looking forward to add multiple datasets to other activities after the end of the SoK period.

Deepak Kumar !!!

When placing this year’s foss-north event over a quarter break I knew that I would be busy both at work and at the conference. Little did I know what was beyond the horizon ;-)

As a consequence of the COVID-19 situation, the event has to be converted from a physical meeting to a virtual event. This means many things to an organizer: renegotiating all sponsorship contracts, renegotiating with the physical venue, setting up the infrastructure for a virtual event, rescheduling all speakers, and so on.

We at foss-north are lucky. All sponsors continue to stay with us and the venue was very cooperative when it came to rescheduling the event.

I have started to document our virtual conference setup so that other conferences in the same situation can learn. Pull requests are welcome!

This Sunday we decided to stress test the infrastructure by running the lightning talks. This is a good test case, as it involves a maximum number of speaker transitions, as well as more frequent QA sessions. From an organizer perspective, this is really like running a full day of the conference in 90 minutes.

I’m happy to tell you that the talks went well! You find them below. Following the links you find slides as well as recordings of the sessions.

Develop better software with usability testing by Andreas Nilsson
Running Android on the Raspberry Pi by Chris Simmonds
The Yocto Project 10 minute quick-start guide by Ron Munitz
Getting started with your smart, connected, vehicle project by Dimitris Platis
Seven years in Tibet^W^Wat Home by Kristoffer Grönlund
Linux on RISC-V by Drew Fustini
Singularity container platform by Anders Björklund

We’ve also been able to get most of the conference schedule in place and just have a few rough edges to fix before the big event. I am extremely pleased with how this has turned out. We still have a stellar speaker setup and I hope that you will all join in and watch the streams. The event is free for all and open to all and runs from March 29 – April 1.