January 08, 2018

Tobias and Raphael have spent the past month or so hammering on the Qt 5.9 branch, which has (finally!) landed in the official FreeBSD ports tree. This brings FreeBSD back up-to-date with current Qt releases and, more importantly, up-to-date with the Qt release KDE software is increasingly expecting. With Qt 5.9, the Elisa music player works, for instance (where it has run-time errors with Qt 5.7, even if it compiles). The KDE-FreeBSD CI system has had Qt 5.9 for some time already, but that was hand-compiled and jimmied into the system, rather than being a “proper” ports build.

The new Qt version uses a new build system, which is one of the things that really slowed us down from a packaging perspective. Some modules have been reshuffled in the process. Some applications depending on Qt internal-private headers have been fixed along the way. The Telegram desktop client continues to be a pain in the butt that way.

Following on from Qt 5.9 there has been some work in getting ready for Clang 6 support; in general the KDE and Qt stack is clean and modern C++, so it’s more infrastructural tweaks than fixing code. Outside of our silo, I still see lots of wonky C++ code being fixed and plenty of confusion between pointers and integers and strings and chars and .. ugh. Speraking of ugh, I’m still planning to clean up Qt4 on ARM aarch64 for FreeBSD; this boils down to stealing suitable qatomic implementations from Arch Linux.

For regular users of Qt applications on FreeBSD, there should be few to no changes required outside the regular upgrade cycle. For KDE Plasma users, note that development of the ports has changed branches; as we get closer to actually landing modern KDE bits, things have been renamed and reshuffled and mulled over so often that the old plasma5 branch wasn’t really right anymore. The kde5-import branch is where it’s at nowadays, and the instructions are the same: the x11/kde5 metaport will give you all the KDE Frameworks 5, KDE Plasma Desktop and modern KDE Applications you need.

Could you tell us something about yourself?

I’m a 30-year-old housewife and mother living in New Mexico in the United States. I’ve always had an interest in becoming a storyteller, and visual art is the most appealing way for me to do it.

Do you paint professionally, as a hobby artist, or both?

Right now I would call myself a hobbyist, as I’ve never published anything professionally. I hope for that to change. What I need is to somehow find the time and energy to crank out images at high volume!

What genre(s) do you work in?

I’ve always been interested primarily in fantasy, although much of my work has consisted of humorous cartoons. Humor creeps into whatever I try to make whether or not I intend for it to be there. My goal for the next decade is to begin a serial, consistent fantasy world as portrayed through cartoons.

Whose work inspires you most — who are your role models as an artist?

My first and largest influences are the old-fashioned Disney animated films from the 20th century, as exemplified by the work of artists like Bill Tytla. I also consider cartoonists and illustrators like Bill Watterson, Maurice Sendak, and Hal Foster to be very influential on my style. Fantasy illustrators like Frank Frazetta inspire me on an emotional level.

How and when did you get to try digital painting for the first time?

I began using digital tools purely as a form of practice a few years ago. To me it was very casual; I was figure drawing and making fan art referencing in-jokes from a favorite podcast of mine called “We Hate Movies.” I didn’t intend to pursue it seriously, but found myself returning to it more and more often.

What makes you choose digital over traditional painting?

Traditional painting definitely produces the most beautiful results, but it’s a pain in the neck. Not only does it take up more time and physical space, it’s far more expensive and wasteful. I don’t like the “digital look,” and it will take a lot of practice to minimize that. However, I believe that real artists should never blame their tools for any failure.

I’d almost always drawn pictures with only a pencil before, but digital painting allows me to ink and color my images much more easily. It also opens up options for experimentation when I can simply recolor anything I don’t like. The hardest part has been trying to learn the kind of control with a stylus that I have with my own hand.

How did you find out about Krita?

My husband is an engineer who works frequently with Linux and is familiar with the open-source world. He suggested Krita to me when I was looking for a digital painting program not called Photoshop.

What was your first impression?

Krita was the most professional-looking Photoshop alternative that I’d come across. It also played nicely with my stylus and tablet in a way that some other software didn’t. Krita did have some bugginess and crashing, though.

What do you love about Krita?

That it’s free! I think it’s remarkable that the open-source community could create something of this quality without a money spigot. Given Adobe’s outrageous pricing scheme for Photoshop, you’d think that software like this couldn’t exist anywhere else. Krita is a much better option.

What do you think needs improvement in Krita? Is there anything that really annoys you?

Bugs and crashes come with the territory in open-source projects, but those are likely to be reduced over time. The real problem is how inaccessible Krita is to lay people. When I was looking to download the program for the first time, I had to follow a completely unintuitive chain of links that, to somebody like me, appeared to be made up of Seussian nonsense words (AppImages for cats? What’s a Gentoo? Why is it bloody?). Idiots like myself just want a giant button that says “GET THE LATEST STABLE VERSION OF KRITA HERE!” The way things are now, the less technically literate will give up on trying Krita before they have even started.

What sets Krita apart from the other tools that you use?

Krita has a great community of support that will ensure that it gets better year by year. It has the right priorities, i.e. essential tools like layers and brushes get implemented before more obscure features. Other than occasional crashes, I can just jump in and use it.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

I made this page in Krita in order to see whether I could use it for a webcomic I plan on creating. The experiment was a success, and I believe that my skills will continue to grow. This proves that I can use Krita to tell the kinds of stories that I have plans for.

What techniques and brushes did you use in it?

I mostly use a basic round brush that I resize accordingly. Line brushes are convenient for separating the panels. I think that skills are more important than tools, and I want to train myself to use the simplest tools that I can.

Where can people see more of your work?

I’m shy about publishing, but I realize that this is something I need to change about myself. Once I’ve worked up a sizable volume of content, which should be within the next year, I will be posting a regular webcomic called The Unknown Engine.

Anything else you’d like to share?

I’m grateful that the Internet and the open-source movement affords artists like me the opportunity to create and publish in new ways. I often think about Bill Watterson’s long fight with his syndicates, and how different it would have been for him if he was able to publish Calvin and Hobbes on the Internet under his own control. I’m nowhere near his level of course, but I want to improve my own skills until I get there.

January 07, 2018

2017 began with the once-in-a-lifetime trip to India to speak at KDE.Conf.in. That was amazing enough, but the trip to a local village, and visiting the Kaziranga National Park were too amazing for words.

Literal highlight of last year were the eclipse and trip to see it with my son Thomas, and Christian and Hailey's wedding, and the trip to participate with my daughter Anne, while also spending some time with son Paul, his wife Tara and my grandson Oscar. This summer I was able to spend a few days in Brooklyn with Colin and Rory as well on my way to Akademy. So 2017 was definitely worth living through!

This is reality, and we can only see it during a total eclipse

2018 began wonderfully at the cabin. I'm looking forward to 2018 for a lot of reasons.

First, I'm so happy that soon Kubuntu will again be distributing 17.10 images next week. Right now we're in testing in preparation for that; pop into IRC if you'd like to help with the testing (#kubuntu-devel). https://kubuntu.org/getkubuntu/ next week!

Lubuntu has a nice write-up of the issues and testing procedures: http://lubuntu.me/lubuntu-17-04-eol-and-lubuntu-17-10-respins/

The other serious problems with meltdown and spectre are being handled by the Ubuntu kernel team and those updates will be rolled out as soon as testing is complete. Scary times when dealing with such a fundamental flaw in the design of our computers!

Second, in KDE we're beginning to ramp up for Google Summer of Code. Mentors are preparing the ideas page on the wiki, and Bhushan has started the organization application process. If you want to mentor or help us administer the program this year, now is the time to get in gear!

At Renton PFLAG we had our first support meeting of the year, and it was small but awesome! Our little group has had some tough times in the past, but I see us growing and thriving in this next year.

Finally, my local genealogy society is doing some great things, and I'm so happy to be involved and helping out again. My own searching is going well too. As I find more supporting evidence to the lives of my ancestors and their families, I feel my own place in the cosmos more deeply and my connection to history more strongly. I wish I could link to our website, but Rootsweb is down and until we get our new website up......

Finally, today I saw a news article about a school in India far outside the traditional education model. Called the Tamarind Tree School, it uses an open education model to offer collaborative, innovative learning solutions to rural students. They use free and open source software, and even hardware so that people can build their own devices. Read more about this: https://opensource.com/article/18/1/tamarind-tree-school-india.

Hello devs! Happy new year!

It is common to use the new year date to start new projects or give new directions for old ones. The last one is the case for Cantor.

Since when I got the maintainer status for Cantor, I was working to improve the community around the software. Because the great plugins systems of Qt, it is easy to write new backends for Cantor, and in fact in last years Cantor reached the number of 11 backends.

If in a hand it is a nice thing because Cantor can run different mathematical engines, in other hand it is very common developers create backends, release them with Cantor upstream, and forget this piece of software after some months. The consequence of this is a lot of unsolved bugs in Bugzilla, unexpected behaviours of some backends, and more.

For instance, R backend is broken from some years right now (thanks Rishabh it was fixed during his GSoC/KDE Edu Sprint 2017 but not released yet). Sage backend breaks for each new release of Sage.

Different backends use different technologies. Scilab and Octave backends use QProcess + Standard Streams; Python 2 uses Python/C API; Python 3, R, and Julia use D-Bus.

In addition to these, remember each programming language used as mathematical engine for Cantor has their respective release schedule and it is very common new versions break the way as backends are implemented.

So, yes, the mainternhip of Cantor is a hell.

In order to remedy it I invited developers to be co-maintainer of these respective backends, but it does not have the effect I was suposed to. I implemented a way to present the versions of programming languages supported in the backend but it does not work well too.

So, my main work in Cantor during these years was try to solve bugs of backends I don’t use and, sometimes, I don’t know how they work, while new features were impossible to be planned and implemented.

If we give a look to Jupyter, the main software for notebook-based mathematical computation, it is possible to see this software supports several programming languages. But, in fact, this support is provide by the community – Jupyter focus effort in Python support only (named the ipython kernel) and in new features for Jupyter itself.

So, I would like to hear the KDE and Cantor community about the future of Cantor. My proposal is split the code of the others backends and put them as third-party plugins, maintained by their respective community. Only the Python 3 backend would be “officially” maintaned and delivered in KDE Applications bundle.

This way I could focus in provide new features and I could to say “well, this bug with X backend must be reported to the X backend community because they are accountable for this piece of software”.

So, what do you think about?

January 06, 2018

Latte Dock v0.7.3   has been released containing many important fixes and improvements! Soon at your distro repos or...

Go get   v0.7.3  from, download.kde.org*

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

Fixes/Improvements (v0.7.3)

shadows with size:100% and opacity:100%
  • support RTL languages
  • translated to twenty one different languages
  • fix crash from audio badges
  • improve shadow behavior and calculations for corner cases
  • support "nomad systray" and "kdeconnect sms" in Latte heuristics
  • expand applets when clicked at neutral areas
  • shrink a bit the task number
  • support Fitt's Law in more corner cases
  • execute Latte at the same time between different users
  • ignore X11 signals that are sent with no reason
        (e.g. Firefox 57 upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1389953)
  • take into account the applets shadow size for mask calculations

Latte Git - development version (v0.7.75)

smart dynamic background

Work on the next major version has already started and for those that want to live on the edge these are the features that have landed:
  • New Smart Dynamic Background
        ( https://github.com/psifidotos/Latte-Dock/issues/810 )
  • Panel / Dock options in Settings window to switch easy and fast between them
  • New settings for Active Indicator and Glow
  • Support multiple internal separators for Tasks plasmoid and assign them to different Activities
  • Download window for Latte Layouts found at store.kde.org website,
        ( https://github.com/psifidotos/Latte-Dock/issues/807 )
  • Slide out/in the dock when changing edge or screen
  • Enhance command line options to load and import layouts on startup
  • open and close Settings window with global shortcut
  • Increase the tasks that can be executed from global shortcuts from nine to nineteen 
dock/panel options

Plans for v0.8
  • Pre-Load Multiple Layouts.
        ( https://github.com/psifidotos/Latte-Dock/issues/808 ) 
Latte v0.7 introduced multiple layouts that change based on Current Activity user changes. This was the first step to see what users can do with it and if such a solution is realistic. The feedback is very positive and even though the audience is small, there are users that have reported very interesting workflows. At the same time some users reported that they would like to have these layouts pre-loaded based on the Active Activities. In such scenario switching between Activities the specific Latte Layouts will be instantly available. When the user activates a new Activity then its layout is loaded automatically and when an Activity is closed that layout is off-loaded from memory. Technologically this is very challenging and pushes our current implementantion to the limits but on the other hand it is possible. If you want to participate in the discussions feel free to join the above thread.

Latte Development Team

For a few months I am the only active developer and maintainer of Latte and I would love to have  more people contributing and sharing the Latte development process! Feel free to join and participate, I dont bite :) ! 

that's all for now, have fun everyone....

michail <psifidotos>

Click here to lend your support to: Latte Dock and make a donation at pledgie.com !

Latte Dock is preparing its next stable version (0.7.3) which you will be able to get the next days and of course new features at its git version. I wont describe now the fixes, improvements and new features both versions contain because this article is for another reason.

KDE Project

Latte for a few months now is part of the kde community and it is also an official kde project. I am very proud of it and we dont hide it :), our kde origins that is. As such please consider donating at the kde fundraising which helps maintain the quality and innovation in our fantastic community!!!

LibAlkimia is a base library that contains support for financial applications based on the Qt C++ framework. One of its main features is the encapsulation of The GNU Multiple Precision Arithmetic Library (GMP) and so providing a simple object to be used  representing monetary values in the form of rational numbers. All the mathematical details are …

January 05, 2018

It's been 5 months since I came to GCompris community, but it feels it was a few days back. I came here as a newbie in open source, not even knowing how to ask sensible questions (that's very important which I learned during my works in GCompris), not even knowing how and where to begin. …

January 04, 2018

The 5th and final bugfix update (5.11.5) of the Plasma 5.11 series is now available for users of Kubuntu Artful Aardvark 17.10 to install via our Backports PPA.

This update also includes an upgrade of KDE Frameworks to version 5.41.

To update, add the following repository to your software sources list:


or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

sudo add-apt-repository ppa:kubuntu-ppa/backports

and packages then updated with

sudo apt update
sudo apt full-upgrade

Upgrade notes:

~ The Kubuntu backports PPA includes various other backported applications, so please be aware that enabling the backports PPA for the first time and doing a full upgrade will result in a substantial amount of upgraded packages in addition to Plasma 5.11.5.

~ The PPA may also continue to receive updates to Plasma when they become available, and further updated applications where practical.

~ While we believe that these packages represent a beneficial and stable update, please bear in mind that they have not been tested as comprehensively as those in the main Ubuntu archive, and are supported only on a limited and informal basis. Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

1. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
3. Kubuntu PPA bugs: https://bugs.launchpad.net/kubuntu-ppa

January 03, 2018

We are happy and proud to announce the immediate availability of Zanshin 0.5.0.

After 0.4.0 one year and a half ago and 0.4.1 last year (which wasn't publicly announced), this new release introduce new features. The 0.4 series was mostly about the Qt 5 port and stabilization, now we can be a bit more ambitious again.

So what's in store for that new release?

  • Errors coming from the system are now displayed properly in the main window;
  • Tasks scheduled in the future can be filtered out;
  • A task can be picked up as the "currently running" showing a nice overlay at the top of the screen, this is a reminder of what you're supposed to focus on;
  • Projects are now displayed grouped by their containing collection which can help separate better visually between work and personal projects;
  • Attachments are now supported for tasks (which nicely complete the "create todo" feature from KMail);
  • Tasks with recurrence are now supported (although we have a simple recurrence model for now);
  • And of course also a couple of minor GUI adjustments and bug fixes.

Under the hood, we also did some improvements:

  • Some error handling has been improved;
  • Some duplicated code has been factorized;
  • Some dead code has been cleaned up;
  • Issues pointed out by krazy and clazy have been addressed;
  • Feature level tests have been reworked and are better insulated from each other;
  • Our code related to dates have been ported to the new KCalCore ABI introduced in 17.12;
  • The biggest architectural change has been the introduction of a cache which speeds up our accesses to akonadi and allowed to adress a few bugs (we had some views exhibiting duplicated items, this is now gone).

So quite a lot of nice things in this release. We increased the features and polish of what you experience while improving the code base itself. All in all, this should be a very nice release.

As usual, you can grab 0.5.0 while it is fresh! Packages for KDE Neon and openSUSE Tumbleweed are already available, it's only a matter of time until the other distributions catch up.

Plasma 5.11.5 KDE Neon


Now available in KDE Neon User Edition!


After a very long time, the KMyMoney development team is about to start the release cycle for the first release of its personal finance manager application based on KF5/Qt5. Various reports show us that people are already using the master branch in their production environment, as several team members have also done for at least …

Community Goals Over the second half of 2017, KDE has been going through the ambitious effort of having its community propose and choose goals for the next 3-4 years. These goals have been set now, and I was thrilled to learn that my proposal on Streamlined onboarding of new contributors was chosen and many other KDE contributors believed this was a goal worth pursuing in the near future and voted for it.

January 02, 2018

First of all: Happy New Year! Second, I think that I need to update you on Atelier and AtCore. There are about two months now that AtCore reached its beta stage and we release it with the test client.  On my Docker Hub account, the image of AtCore(Master and Beta) was pulled more than 30... Continue Reading →

After a beta version in September and a release candidate in October, there is finally a release of KBibTeX 0.7.
A tag has been set and tar balls have been published.

The only changes compared to the release candidate are attempts to fix online search issues with Google Scholar and IEEE Xplore.

Read more... )

comment count unavailable comments

KDE’s Visual Design Group recently put some thought into shadows in Breeze. Right now, the default shadows are rather small, and can be almost entirely invisible on the left edge:

We decided to make them larger and deeper by default, and center them horizontally so that there’s a shadow on the left edges of windows and menus as well. I was honored to produce the patch, and I’m happy to report that it’s been accepted and merged! Starting in Plasma 5.12, here’s how shadows will look:

These are just default settings of course; if you don’t like big shadows, you can tweak to your heart’s content (System Settings > Application Style > Window Decorations > [click on the little menu button in the corner of the Breeze entry] > Shadows). But this new default setting provides a much greater sense of depth that I think most users will find quite welcome.

FreeBSD is getting more serious about license metadata in the packages produced by the project — that is, the binary distribution of software produced from licensed source code. A lot of software in FreeBSD “proper” is (naturally) BSD-licensed, and a lot of Free Software packaged by FreeBSD is (also naturally) GPL licensed. But the different licenses carry different obligations, so it’s good to keep track of the exact licensing applied to each bit of software.

To this end, there’s the LICENSE= line in each port’s Makefile. Its meaning is “this software has such-and-such a license”. For conciseness, SPDX identifiers are used, so that you can write


and we know what you mean. Because licenses can carry textual obligations (e.g. the GPL expects you to receive a copy, and the BSD licenses generally require you to include the copyright notice with distributions), there’s
an additional setting to include the actual text, called LICENSE_FILES:


There’s a third source of license information, and that is the headers of the sources themselves. Usually you put a copyright-and-license header at the top of each file; some licenses such as the MPL even require some administration in there. The reuse.software site (by the FSFE) provides good guidance and best-practices information for providing licensing metadata in software packages.

Anyway, for KDE Frameworks 5 I was going through the ports Makefiles and adding LICENSE information. The KDE Licensing Policy tells me that frameworks should be licensed LGPL21+, with a few variants allowed; an interesting one is (at your option) “LGPL21 or LGPL3 or any later version approved by KDE e.V.” Right now, in 2017, this choice is the same as LGPL21+ because no later versions exist, but it is not always-in-the-future-same, so I hesitate to write


for KDE Frameworks until I’ve checked the files. The license text is usually included, but it’s not quite consistently named, so I need to look into the tarballs anyway. And as a double-check, I read a couple of source headers to see if the license named in the code, matches the license text elsewhere (e.g. some files say LGPL 2.1 only).

It’s a bit of a slow process — one which upstream (that is, the source code) could support a little better with consistent naming. It’s also a process that needs to be monitored continually, to ensure that the whole body of software remains properly and consistently licensed — hopefully following best practices, too.

Anyway, as of today only ten of the KDE Frameworks 5 ports in the official FreeBSD ports repository  have all their licensing information set, to the best of my ability to check their accuracy. As an ongoing project in keeping-license-info up-to-date it’s not very high-priority but something that gets done in-between other things.

Challenges with cloud messaging for embedded devices has inspired the Kaltiot & SnowGrains teams to create a cross-platform Qt API which enables easy push messaging from and to embedded devices. The API is called the Qt Cloud Messaging API and it is built with flexibility and extensibility in mind.

We have decided to target other Qt areas, too, and make the API easily extensible to any service provider instead of being for embedded only. This enables developers to use the same API for both mobile and desktop development.

There is a vast number of push messaging providers for mobile and web development nowadays. Yet in industries like automation, automotive, robotics and for other embedded devices there has not really been any providers for this type of service. The need is increasing at a rapid pace as embedded and IoT devices are pushed more and more messages by the device owners, car service providers, telemetry, cloud and many others.

The Qt Cloud Messaging API is simple to adopt and take into use.

Let’s take a sneak peek at how to utilize the API for embedded systems and Android mobile platforms. We’ve integrated the Kaltiot Smart IoT SDK and the Firebase C++ SDK into the backend, and with the Qt Cloud Messaging API we can easily create e.g. a chat application on top of it.

Kaltiot Smart IoT is a service for scalable and secure messaging between devices and services. It provides bi-directional and always online, yet battery optimized communication. The client SDK is designed to work even in constrained low-end devices in poor wireless network conditions. Kaltiot Smart IOT is available for Linux32, Linux64, Raspberry Pi, Mac, Android.

How to use the Qt Cloud Messaging API for embedded devices:

 First, clone the qtcloudmessaging repository: git clone https://codereview.qt-project.org/qt/qtcloudmessaging

Service provider


  1. Get the Kaltiot SDK to your embedded device from (e.g. Linux or Raspberry Pi SDK) https://console.torqhub.io
  2. Get the API key for sending channels or/and creating server-side implementation
  3. Add following line to your application .pro file: QT += cloudmessagingembeddedkaltiot
  4. Define KALTIOT_SDK path to your application.pro
  5. Add following includes to main.cpp
#include <QtCloudMessaging>
#include <QtCloudMessagingEmbeddedKaltiot>
  1. Add following QtCloudMessaging configs to main.cpp
// Instantiate CloudMessaging library
QCloudMessaging *pushServices = new QCloudMessaging();

// Add provider for Kaltiot Embedded systems
QCloudMessagingEmbeddedKaltiotProvider *kaltiotPushService = new QCloudMessagingEmbeddedKaltiotProvider()

// Provider based init parameters are given with QVariantMap
QVariantMap provider_params;

provider_params["API_KEY"] = "Your API key from the Kaltiot console for server communication";
// Creating name for provider which can be used cross your app.

pushServices->registerProvider("KaltiotService", kaltiotPushService, provider_params);

QVariantMap client_params;

client_params["address"] = "IOTSensor1";
client_params["version"] = "1.0";
client_params["customer_id"] = "Kaltiot";

// Creating default channels to listen
QVariantList channels;
client_params["channels"] = channels;

// Connect IoT sensor client to system
pushServices->connectClient("KaltiotService", "IOTSensor1", client_params);

//! Automatically subcribe to listen one more channel e.g. WindInfo.
pushServices->subsribeToChannel("WindInfo", " KaltiotService ", " IOTSensor1");
  1. Provide context of cloud messaging to QML in main.cpp
//! Provide context to QML

engine.rootContext()->setContextProperty(“pushServices”, pushServices);

QML Part:

in main.qml catch the messages coming from the Kaltiot service.

  1. Receiving messages
target : pushServices

//! Message is received as string and needs parsing to JSON
  1. Sending messages:
//! Sending a broadcast message e.g. from the weather station:
//! Message structure for embedded devices is easy:
//! define payload json:
//! {
//!   “payload_type”:”STRING”,
//!   “payload”: encodeURI(JSON.stringify(payload))
//! }
//! Payload is your application specific. E.g:
var payload =
city: “Oulu”,
forecast: “full sunlight for whole next week”

//! Capsulate payload to message and send it via QtCloudMessaging API:
var payload_array = [{“payload_type”:”STRING”,”payload”: encodeURI(JSON.stringify(payload))}]

pushServices.sendMessage(JSON.stringify(data), ”KaltiotService”, ”IOTSensor1”, ””, ”weather_broadcast_channel”);

Using the Qt Cloud Messaging API for Android / iOS mobile development with Google Firebase service provider


  1. Create new project into Google Firebase console: https://firebase.google.com/
  2. Download Google Firebase C++ SDK  and add the Firebase configuration file for Android Gradle:
DISTFILES += \android/google-services.json
  1. Add following line to your application .pro file:
QT += cloudmessagingfirebase

Define Google firebase path into your application.pro file with

GOOGLE_FIREBASE_SDK = <Path_to_Firebase_SDK>
  1. Add following includes to your main.cpp
#include <QtCloudMessaging>
#include <QtCloudMessagingFirebase>
  1. Add following QtCloudMessaging setup to main.cpp:
// Instantiate CloudMessaging library
QCloudMessaging *pushServices = new QCloudMessaging();
QCloudMessagingFirebaseProvider *firebaseService = new QCloudMessagingFirebaseProvider();
QVariantMap provider_params;

// Server API key is not recommended to store inside to the application code due security reasons.
// But if you do, make sure it is inside compiled C file or if you are doing a server side implementation with C++ & Qt.
// SERVER_API_KEY Is needed to be able to send topic messages from the client without Firebase application server.

provider_params["SERVER_API_KEY"] = "Get your SERVER API KEY from the google firebase console";

// Registering the Google firebase service component.
pushServices->registerProvider("GoogleFireBase", firebaseService, provider_params);

/*! Connected client is needed for mobile device.
\param Service name "GoogleFireBase"
\param Client identifier name to be used inside the application
\param Parameters for the client. No params for firebase client.
pushServices->connectClient("GoogleFireBase", "MobileClient", QVariantMap());

//! Automatically subscribe to listen one example topic
pushServices->subsribeToChannel("ChatRoom", "GoogleFireBase", "MobileClient");
  1. Provide context of cloud messaging to QML in main.cpp
//! Provide context to QML
engine.rootContext()->setContextProperty(“pushServices”, pushServices);

QML Part:

in main.qml catch the messages coming from the google firebase

  1. Receiving messages
target : pushServices
//! Message is received as string and needs parsing to JSON
  1. Sending messages:
//! For firebase, message structure needs to have data as whole message.
//! Notifications are shown in the Android/iOS notification center.
function sendMessage(notification_titile, notification_msg, msg){
var data = { “data”:{
“message”: {“text”:msg } },
“notification” : {
“body” : notification_msg,
“title” : notification_titile

//! Give data and service provider identifier as well as client name defined in the C++ code.

You can play around with the Qt Cloud Messaging API + firebase from the sample


The Qt Cloud Messaging API provides cross-platform API to enable us to include new providers and still keep the development API as same.

The Qt Cloud Messaging API has been developed to be easily extensible to any service provider. Take a sneak peek at ongoing development from the https://codereview.qt-project.org/qt/qtcloudmessaging and contribute your own backend service to the community.

Kaltiot has been developing and hosting IoT cloud services since 2008. Trusted e.g. by Microsoft, Kaltiot passes through 10M messages every hour. (www.kaltiot.com)

SnowGrains provides Full Stack Software Solutions On The Rocks.(www.snowgrains.com)

Ari Salmi is multi-technology developer and Qt enthusiast.

The post Qt Cloud Messaging API Available for Embedded Systems appeared first on Qt Blog.

Good evening fellas,

Happy New Year to all! The year 2017 has been a rollercoaster, to be honest. Well, it was rich and prosperous year regarding in technical terms. It was a beautiful year of great learning, splendid travel and got to network with some fantastic folks all around the globe.

The best reason for making this 2017 incredible for me is KDE. One of the exciting community I have ever seen! It all started at the end of 2016, I got intrigued by the Tagline of KDE, “Experience freedom”. I started contributing to various projects inside KDE. My initial start was with Konsole, system settings, KIO and various educational suite programs. Moving on, I came across a student program organized by KDE named KDE-SoK and I was selected for it, yay!!!

The project was with KStars(KDE’s amateur astronomy software which provides real-time and an accurate graphical simulation of the night sky, from any location on Earth.) to collect a new set of images from NASA/ESO catalogs along with orientation and pixel scale (arcsecs/pixel) from the whole set of Messier Catalog (which is a collection of 110 astronomy objects in the night sky). Images were processed for overlay in KStars using OpenCV, so to have transparency and to modulate according to the software.

After the successful completion of the project, I was invited as a speaker to give a talk on “Object-Tracking Using OpenCV and Qt” at KDE India Conference held at IIT Guwahati in March 2017. Again, yay!! :P. There I met a lot of enthusiastic KDE people out there. ��

Later on, I was selected as a Google Summer of Code (2017 edition) intern funded by Google. I contributed to  Krita(Krita is a professional and open source painting program) of KDE. The project was to Integrate share.krita.org. 

Share.krita.org is a place where users can share Krita scripts, images, brush packs and more. This project has two parts: integrate with the KNSCore part of the KNewStuff framework (or reimplement the protocol) and create a GUI for sharing. The second part is improving the support for creating and editing bundles. Bundles can contain brushes, patterns, gradients and so on. Also, Krita needed basic support for creating and editing bundles.

Thus said, the entire journey with KDE last year was splendid!! The community as such is a group of awesome and enthusiastic people from all around the globe. To do more than I could last year — I hope to be a part of this great venture in 2018.

Here’s to a productive year, and looking forward to the same in 2018. You can see more of what happened in KDE in 2017 on the KDE year-end fundraiser page. Please do show some of your support to the community and its developers through the fundraiser to built your favorite software ��

Some of my blog post regarding my work last year:

To the awesome year coming right your way,


January 01, 2018

At the beginning of 2017, I was a programmer (mostly Python, and a little bit of C++) and spent most of my day at my desk, with an IDE open and a cup of coffee at hand. At the end of 2017, I’m a programmer (mostly C++, and a little bit of Python) and spend most of my day at my desk, with an IDE open and a cup of espresso at hand.

At some level of abstraction, not much has changed this year.

Of course, now I spend my entire day working on Free Software, in three different but partly-overlapping communities: KDE, FreeBSD, and Calamares. Basically you can track everything I do each day by looking in the relevant repositories on GitHub (read-only mirrors in the case of FreeBSD and KDE). Inspired by Michael, Krita, Matthieu Gallien (with the this-week-in-Elisa series) and Dominik Haumann, I’ve collected a list of things I did this year, in no particular order:

  • Released two versions of the proprietary application I worked on previously, and quit my job. Started working for BlueSystems and other organizations as a free-lance yet full-time programmer.
  • Updated Nethack in FreeBSD, and discovered I no longer have the Nethack chops to ascend half of the games I start. Updated Unnethack on FreeBSD, and fixed a clang-related bug upstream. Yay for roguelikes.
  • Released a dozen Calamares versions with regular bugfixes and small features. Worked together with the KDE VDG, Jens in particular, to figure out some of the UI choices — thanks for plying me with ideas.
  • Updated CMake a couple of times in FreeBSD and chased lots of weird CMakeLists code in unrelated applications.
  • Massaged KDE on FreeBSD under the expert guidance of Tobias and Raphael.
  • Attended three weeks of KDE-related sprints or meetings and a week of Akademy.

Here’s to a productive year, and looking forward to the same in 2018. You can see more of what happened in KDE in 2017 on the KDE year-end fundraiser page.

December 31, 2017

A central place to track KDE development is the kde-commits@kde.org mailing list. To this mailing list, all code changes are sent, containing the log message as well as the diff that quickly shows what really changed. In the early days of KDE development, the changes were maintained by the CVS version control system. Later, this was changed to subversion. Nowadays, KDE mostly uses git, but some svn modules are still around.

Since KDE is developed by many contributors, the  kde-commits@kde.org mailing list obviously has high traffic, ranging from ~100 mails up to 400 mails a day (see marc.info for statistics).

Many developers are subscribed to this mailing list. However, due to high traffic and possibly many changes that are unrelated to your pet project, a commit filter was invented, which was available on https://commitfilter.kde.org for a long time. Essentially, this commit filter allowed to easily setup filters in terms of regular expressions, such that you’d only get mails for changes you are interested in. While this was convenient, the commit filter also had its drawbacks: Instead of getting all KDE changes, you missed a lot possibly interesting conversations: Since post-code reviews are often done by others through email conversation directly on the code changes.

Nowadays, the commit filter is not available anymore, mostly for security reasons since it was unmaintained for a long time.

What does that mean? I’m subscribed to kde-commits@kde.org again, getting all changes. In fact, I am enjoying skimming quickly through the changes, even doing a code review here and there.

I recommend every KDE contributor to subscribe to this mailing list, since it is very interesting to see which projects are actively developed and who really contributes to KDE in person. Even better, sometimes there are discussions on this list, helping you to learn things you didn’t know. Of course, nowadays we also have many code reviews on phabricator, but still the commit mailing list is a nice addon to track KDE development.

The year is about to end and so is Cutelyst v1 series, I wasn’t planning for another release this year but Matthias added some nice new features that I decided to roll 1.12 in 2017 branching 1.x.x series and master is now officially Cutelyst 2 with no stable API/ABI until 2.0.0 is tagged.

HTTP/2 support will hopefully be part of Cutelyst 2.0.0, there aren’t any drastic changes in v2, most important thing is fixing MSVC builds and removing deprecated API.

Back to this release it includes a new CSRF protection plugin, with a Grantlee tag similar to what Django has. Add to this many fixes and the epoll event loop dispatcher is now even faster and got many fixes, performance wise it’s great advantage is when dealing with many simultaneous connections, it can lead to 2-3 times faster than default glib one.


Happy new hacking year!

December 30, 2017

Playing with emojis

At some point, I needed to copy paste emojis, but couldn’t find a good way to do it. So what does a good hacker do?
Scratch an own itch. As I wrote about in the past, all these projects should be shared with the rest of the world.
So here it is: https://cgit.kde.org/scratch/sune/aubergine.git/

It looks like this with the symbola font for emojis: Screenshot

It basically lets you search for emojis by their description, and by clicking on a emoji, it gets inserted into the clipboard.

As such, I’m not sure the application is really interesting, but there might be two interesting bits in the source code:

  • A parser for the unicode data text files in /usr/share/unicode/NamesList.txt is placed in lib/parser.{h,cpp}
  • A class that tries to expose QClipboard as QML objects placed in app/clipboard.{h,cpp}. I’m not yet sure if this is the right approach for that, but it is the one that currently makes most sense in my mind. If I’m receiving proper feedback, I might be able to extend/finish it and submit it to Qt.

And of course, now it is simple to describe fancy cooking:

�� �� ��
(aubergine) (hocho) (fire)

I ❣ emoji

December 29, 2017

Not goodbye, but hello to a new music player on my desktop. It is already packaged for FreeBSD and has a long development history.

Music players stand or fall per individual user whether they satisfy the user’s needs — no duh there, but it means I should note what my use cases are before enthusing about some music player in particular. I would be fine with playing music from the command-line, most of the time: mpg123 --shuffle /mnt/music/*/*/* is just about right (except it fails with an argument list too long error in the shell). This is for music-while-I-hack, so I don’t listen too closely, it’s not hi-fi at all, basically I want “play in a genre until I switch it off“. Tagging is largely done when ripping my CDs (I still buy physical media!) and I don’t care for album art (I can look in the jewel case if I want that, and they’re all stacked in boxes upstairs). So play, pause, stop .. and if it can avoid mixing Mahler with Morrissey and Mötorhead, that’s a bonus.

Screenshot of Sayonara main windowOff to the left here is Sayonara, which describes itself as:

Sayonara is a small, clear and fast audio player for Linux written in C++, supported by the Qt framework. It uses GStreamer as audio backend. Sayonara is open source and uses the GPLv3 license. One of Sayonara’s goals is intuitive and easy usablility. Currently, it is only available for Linux.

Clearly that’s not true, because it’s available for FreeBSD as well �� . I forget how I configured it; there’s a File > Open Directory entry and I probably filled in /mnt/music and it went and found everything that gstreamer will sensibly play. The screenshot is of the minimal playlist-only view. It can be broadened to include a library view which is a bit chaotic, but which searches reasonably well (e.g. for Mudhoney). Sayonara is actually where I discovered the luxury of stay-on-genre autoplay: when I started on some Dutch punk and it kept pretty close to that, wandering off to de Kift occasionally — but no Drs.P.

I contributed a few small fixes to get Sayonara building on FreeBSD, cleaning up the CMakeLists for newer CMake, that kind of thing. Now that it runs on my Plasma desktop all day, I can spot some more  minor issues — the system tray media player control doesn’t interact with Sayonara at all, for instance. For my use-case, that’s not so important, since the fire-and-forget genre play does it for me until I hit pause in the main UI.

I’m looking forward to KDE music players Elisa and Babe, for comparison purposes: maybe they tick my requirements-boxes just as well, or better. Certainly Elisa seems to be fairly playing-music-focused. I’ve even got a FreeBSD port for Elisa ready, just waiting for Qt 5.9 to show up on my doorstep (I can get it to compile against 5.7, but it won’t run due to QML runtime thingies).

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

I enjoy working on the elisa music player. I hope some people enjoy using it. All of this would not have been possible without the KDE community. There is an ongoing fundraising campaign. Please support it.


Not much have been done due to Christmas and end of year holidays.

The following things have been integrated in Elisa git repository:

  • Disable shadows when no artist image is present by Diego Gangl ;
  • Unify track delegate handling by Alexander Stippich ;
  • Fix missing assignment of music listener for MediaArtistAlbumView by Alexander Stippich ;

There are also some pending diff request in phabricator.

We have also some ongoing work to organize work with KDE VDG. Some future changes following their feedback is planned.

I am also driving an effort to more clearly communicate what elisa is about (inspired by the work on KDE goals and plasma vision). I hope to be able to also have a vision for elisa and to derive some goals aligned with those of the KDE community.

The CMake port on FreeBSD is in the hands of the KDE-FreeBSD folks (since KDE was an early adopter), and generally it falls to me to do the CMake update while Tobias is still wrestling with Plasma and Raphael massages Qt 5.9 into our way of building. 3.10 was released five weeks ago, and it took a while to update the port.

It doesn’t take long because of CMake — they’re great, the code builds flawlessly, and there has been a real effort on the part of the KitWare folks recently to absorb our downstream patches so that we have less work in future (During the delay packaging CMake 3.10.0 Kitware even put out 3.10.1, which re-started some processes). It doesn’t take long because of new FreeBSD-specific features in CMake — you can now use CPack to create native FreeBSD packages, just in case you don’t want to go through the ports system or poudriere.

Nope, the problem is the 2000-odd ports using CMake. These generally behave, but every CMake update brings with it some ports that suddenly don’t build. So I spent a day on things like openvsp and scalapack, which fall over with 3.10 (and didn’t with 3.9). The causes of these failures is diverse; sometimes bad local CMake modules that don’t add all the right linking flags, sometimes bad C++ code, sometime stuff that has nothing to do with CMake at all but just happens to be newly triggered, and therefore my problem.

CMake 3.10.1 landed in the official ports tree with r457041, just before Christmas.

Naturally, there are some cases that fall out after an update, that are not caught before the update is committed. I’m told that FreeBSD on PowerPC doesn’t have a C++11-capable compiler installed by default, so I’ll need to massage that a little. Boost 1.66 came out very shortly after CMake 3.10.1, and that leads to new kinds of breakage. I’ve spent a half day compiling and re-compiling ceph, a distributed filesystem, trying to get that to work. It’s amazing sometimes how shifting one brick can bring down a whole house, and how we ever built the house in the first place.

First and foremost, 2017 ends well. We will end this year putting Krita 4.0 in string freeze, which means a release early next year! In 2017, we’ve released several versions of Krita 3.x. We’ve gained a lot of new contributors with great contributions to Krita. We’ve got money in the bank, too. Less than last year, but sales on the Windows Store help quite a bit! And development fund subscriptions have been steadily climbing, and we’re at 70 subscribers now! We’ve also done a great project with Intel, which not only brought some more money in, but also great performance improvements for painting and rendering animations.

It’s been a tough year, though! Our maintainer had only just recovered from being burned out from working full-time on Krita and on a day job when the tax office called… The result was half a year of stress and negotiations, ending in a huge tax bill and a huge accountant’s bill. And enough uncertainty that we couldn’t have our yearly fund raiser, and enough extra non-coding work that the work on the features funded in 2016 took much, much more time than planned. In the period when we were talking to the tax office, until we could go public, Boudewijn and Dmitry were supported by members from the community; without that support the project might not have survived.

But then, when we could go public with our problems, the response was phenomenal. At that point, we were confident we would survive anyway, with the work we were doing for Intel, the Windows Store income and private savings, but it would have been extremely tight.  The community rallied around us magnificently, and then Private Internet Access (who also sponsor KDE, Gnome, Blender and Inkscape, among others) contacted us with their decision to pay the bill!

From nearly broke, we went to be in a position to start planning again!

We reported about those plans before, but to recap:

  • We will to release Krita 4.0 with Python scripting, SVG vector layers, a new text tool, the stacked brushes feature (now renamed to masking brush) and the lazy coloring brush, and many more features. String freeze December 31st 23:59:59, release planned for March!
  • We want to spend next year working on bug fixes, performance improvements and polish
  • But there will also be work on a new reference images tool, improved session management and other things.
  • We will look into the possibility of porting Krita to Android and iOS, though the first attempts have not been promising.
  • We will do another fund raiser, though whether that will be a kickstarter hasn’t been decided yet.
  • After being constrained from attending open source conferences in 2016 and 2017, we intend to have at least someone present at the Libre Graphics Meeting and Akademy. We shouldn’t get disconnected from our roots!

Akademy is the yearly KDE community conference, and Krita has always been part of the KDE community. And KDE has always been more than a desktop environment for Linux and other Unix-like operating systems. As a community, KDE offers an environment where projects like Krita can flourish. Every developer in the KDE community can work on any of the KDE projects; the level of trust in each other is very high.

These days, judging by the number of bugs reported and closed, Krita is the second-most used KDE project, after the Plasma desktop shell. Without KDE, Krita wouldn’t be where it’s now. Without KDE, and the awesome job it’s volunteer sysadmins are doing, we wouldn’t have working forums, continuous integration, bug trackers or a project management platform. Sprints would be far more difficult to organize, and, of course, Krita depends heavily on a number of KDE framework libraries that make our coding life much easier. KDE is currently having the annual End of Year Fundraiser!

Our contributor sprint in 2016 was partly sponsored by KDE as well. With all the bother, it looked like we wouldn’t meet up in 2017. But with the project back on a sound footing, we managed to have a small sprint in November after all, and much vigorous discusion was had by all participants, ending up with firm plans for the last few 4.0 features that we were working on. Next year, we intend to have another big contributor sprint as well.

And, of course, lots of lovely releases, bug fixes, features, artist interviews, documentation updates, and the please of seeing so many people create great art!

It’s time for the end of 2017 KDE fundraiser, and so this is good a time as any during the year to take a step back and publish a retrospective on the work we’ve individually done in 2017.

For those maintaining a module or two this isn’t too hard to figure out what you’ve done with some git magic. But if you’ve made contributions to more than a few modules it can be a bit unwieldy trying to figure out what work you’ve actually done.

While it’s probably not too difficult to craft a find(1) command to search recursively under a common directory for git modules, and then run git-log to look for commits with a given author, it can take a significant amount of time to go through that list if you have a set of checkouts like mine.

Instead, I used kdesrc-build to help, using the --query flag I blogged about a few days ago.  Using kdesrc-build to query for a source directory isn’t very helpful here compared to raw use of find(1).  Rather, it allowed me to allow use kdesrc-build’s own facilities for filtering through modules to build so that I could eliminate git modules I know I’ve had nothing to do with in a way that isn’t as easily expressible using find flags.

In my case, I used a command like this:

kdesrc-build --query source-dir --resume-from extra-cmake-modules | \
    cut -f 2 -d ':' | \
while read dir ; do \
    [ -d "$dir" ] && cd "$dir" && \
    git --no-pager log --since='2017-01-01' \
        --pretty="tformat:$(basename $dir): %s" \
        --author='mpyne@kde.org' --committer='mpyne@kde.org' ; \

What this does is to run kdesrc-build and have it generate its module list as normal, using the --resume-from command to skip over a bunch of large modules I had nothing to do with, and output a line for each of those modules in the form “ki18n: /kdesrc/src/kf5/frameworks/ki18n”.

Each line is fed to cut(1), which prints just the part after the colon (sed(1) would work as well). This path is fed into the while loop, which extracts each input line into the $dir variable, and uses that variable to make sure the directory is actually checked-out and if so, runs git-log in that directory.

Git then actually does the search for any commits since the date given (2017-01-01) by the author(s) or committer(s) you pass.  I use the --no-pager flag before the git subcommand so that I don’t have to pipe to cat(1) to avoid the automatic interactive result display.

Finally, I use the --pretty flag to cause git to also include the basename of the directory when it is showing each commit.  This helps organize where you did your work in a form that’s easy to slice-and-dice later.

So, what did I do this year?  It was split up among these major categories:

  • The kdesrc-build changes I already mentioned.
  • KCoreAddons: Minor fixes, including to improve desktop entry specification parsing and legacy KDE service type handling. I then fixes a similar issue in KConfig.
  • KI18N: Mark .h files generated by uic as ineligible for CMake’s AUTOMOC (fixes a warning of a new CMake policy)
  • KF5: Make it compile with Alpine Linux (which uses musl).  This work was actually to support kdesrc-build in a Docker container, but I never got around to publishing that… :(.  This touched KIO, Solid, KInit, KSysGuard.
  • KWallet: Coverity fixes (on that note, we need someone to start running Coverity builds again…)
  • and finally… completed Kacper Kasper’s port of JuK to KF5!  This work was released with KDE Applications 17.12.  There are still things missing but in some important internal ways, the port is even more complete than the port of JuK from KDE3 to KDE4 was.  Unlike the KDE4 version which always used kde3support, JuK now doesn’t use any compatibility libraries, not even Kdelibs4Support, and should compile without warnings (deprecated uses or otherwise).

While it has been (and continues to be) difficult to find time to make a meaningful impact with a full-time job outside of software development and a growing family, I hope to be at least as productive in the year to come in 2018.

Happy New Year’s everyone and if you have some spare change lying around, please don’t hesitate to support the KDE fundraising drive!  Every bit goes to work on something important, and each contribution helps.

December 28, 2017

KMarkdownWebView 0.4.0 has been released.

Example: KMarkdownWebView KParts plugin used by Ark

The KMarkdownWebView software is for the rendered display of Markdown documents, using web technologies (native wrapper around a webpage with a JavaScript library which creates HTML from the plain text handed in).
The software contains

  • a KParts plugin for rendered display of Markdown files, which enables KParts-using applications (like the archiving tool Ark or the file manager Krusader) to show Markdown files in the target format.
  • a Markdown file KIO thumbnail generator plugin, which allows KIO-powered file managers & dialogs to show thumbnails and previews of files in Markdown format in the target format (currently only available when building against QtWebKit)

The KMarkdownWebView KParts plugin is also prepared for improved experience with the KTextEditor Document Preview plugin for KTextEditor-based applications like the editor Kate and IDE KDevelop.

KMarkdownWebView can be built both with QtWebEngine (preferred by the build system) and QtWebKit. Pass -DUSE_QTWEBKIT=TRUE to CMake to enforce the use of QtWebKit.

Changes since 0.3.0

  • New feature in KParts plugin: show hovered link in status bar
  • Fix: KParts plugin appstream metadata had wrong type
  • Translations updated for some languages (cs, da, de, en_GB, fr, ko, pl, sr@ijekavian, sr@ijekavianlatin, sr@latin, sr, zh_CN)

Download sources

Download from: https://download.kde.org/stable/kmarkdownwebview/0.4.0/src/

sha256: 38b72ba6fa4b513002e7873d2b774e50d676fc878a38b18e6eb9636b53b4c29d kmarkdownwebview-0.4.0.tar.xz

Signed with my new PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau

Krita is not widely known in Latin America. In Colombia, we found that people are interested in knowing more about how to use it. This year, in April 2017, the program of the Latin American Free Software Install Fest included a workshop by David Bravo about Krita. The workshop was fully booked and inspired us to create this course.

colombia krita course participants

Left to right: Mateo Leal, Angie Alzate, David Bravo (teacher), Lina Porras, Lucas Gelves, Juan Pablo Sainea, Javier Gaitán

During 4 sessions of 3 hours each, David Bravo guided a group of six students through their first steps in Krita, including sketch, canvas, digitalization, lines, curves and brush, light and shadow, digital color, painting and color palette, texture, effects, exporting files for digital media and printing.

David Bravo and his drawing

David Bravo (front). The projected drawing is his work.

This course was made possible by the cooperation of three organizations: Onoma Project, Corre Libre Foundation and Ubuntu Colombia. The cost for the students was about 16 USD; all of the proceeds were donated to the Krita Foundation.

Lucas Gelves' work

Lucas Gelves teaching himself to draw.

We think that we can offer an intermediate course in 2018. And of course we want to say thank you to the Krita Foundation for sending gifts for the course students and for staying in touch with us. We hope to cooperate in the near future for future courses!

onoma logoDavid Bravo is a digital and multimedia designer from Colegio Mayor de Cundinamarca, currently working in multimedia freelance projects with a focus on traditional animation, 3D and visualization in virtual environments. He is also the leader of the Onoma Project, an online free platform that is under development. The main objective of this project is to provide tools for easy and secure learning of FLOSS for design.

Ubuntu Colombia logoUbuntu Colombia acts as coordinator and communicator of the course. Ubuntu Colombia is a community with 12 years of history in spreading Ubuntu and FLOSS in Colombia; the Krita course was part of this year’s efforts of the community to promote education on FLOSS tools, as were LaTeX courses and LPIC preparation courses.

Corre Libre Foundation is an NGO created in 2008. Its objectives are:
– to promote the creation of free/open knowledge
– to sponsor free technological projects with social impact
– to promote and spread the use and development of technologies that contribute to human freedom
– to promote and spread collaborative work.

They support Orfeo, which is documentary software. For this course they provided a place to work, which would otherwise have been too difficult and expensive to find in our city.

Older blog entries



Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.