Subscribe to Planet KDE feed
Planet KDE -
Updated: 3 min 3 sec ago

GSoC Status report - Okular

Thu, 06/29/2017 - 22:00

In this post, I want to show you what I did during my first two weeks of the Google Summer of Code.

Okular before adding support for HiDPI

Okular before adding support for HiDPI

As you can see in the screenshot, Okular unfortunately is one of the applications that still has rendering problems on HiDPI screens. That’s bad for me, because I use Okular regularely for reading scientific papers. To be fair, there is a workaround to create a wrapper script which unsets QT_SCREEN_SCALE_FACTORS, but this also means everything is displayed unscaled.

So I decided to focus on the applications in the kdegraphics module - beginning with okular in the first phase of the GSoC program.

And - drum roll please! - this is the result of two to three weeks coding:

Okular after adding support for HiDPI

Okular after adding support for HiDPI

As you can see, the rendering does now work (if you don’t see the difference, open the images in fullscreen). :-)

This took more time then I hoped it would, due to two reasons:
Most of the code that is responsible for the rendering dates back to 2005 - a time, where Qt still belonged to Trolltech and Qt 3.3 was just released. Of course it was ported over to Qt5 and still works, but sometimes I thought there would be a more efficient/simpler solution today. Unfortunately this was out of scope for this project, so there are still many places where the pixels of QImages are modified directly.

The painting of the individual pages also turned out be be difficult to understand. It basicially happens in one, big, complicated, 1000 line long function. This function contains many if statements to handle special cases - e.g. there are many blocks that are only executed if there is a tile manager, or if the image needs to be back-buffered (if it contains highlighting or annotations), or if the page is not yet loaded and a loading icon is drawn (with, again, a fallback if this fails too).

That means testing will also not be that straightforward - in the coming days, I will make sure that all the features still work as expected: all the different document types, with annotations, while zoomed in…

If you want to try this out, the patch is already up on phabricator. Please also leave feedback after testing, this would help me tremendously.

Okular in kdevelop

I'm sure there are still a few bugs in here - the first person to spot one will get a beer at Akademy

At this point I wanted to tell you about gwenview - the next application I’m tackling in the kdegraphics module. But unfortunately, my patch isn’t ready yet and has to wait for the next blog post…

Kube’s dependency situation is finally resolved

Thu, 06/29/2017 - 12:45

We’ve worked on this for the past two years and have finally reached an acceptable state where we don’t end up pulling in hundreds of packages.

While initial implementations of things like the email message parser and the DAV and IMAP library brought huge dependencies like KIO, DBus and even Akonadi (that would arguably have been resolvable on a packaging level, but… not a great situation anyways). With all that removed Kube now depends on ~75 packages less (the exact number will depend on factors such as your distros packaging), as well as drastically reducing it’s runtime entanglement (we no longer need dbus, klauncher, external KIO processes, …).

The new dependency situation looks approximately like this:

  • Qt: (We’ll bump that soon to 5.9 for some Qt Quick Controls2 improvements, and then plan on staying on this LTS release)
  • KIMAP2: Used for IMAP access, depending on KMime and Qt.
  • KDav2: Used for DAV access, depending on Qt.
  • KAsync: A pure Qt library that is extensively used in Sink.
  • KMime: Used for mailparsing, depending on Qt.
  • KContacts: Used for parsing VCard, depending on Qt.
  • lmdb: Our key value-store that is a simple C library.
  • flatbuffers: Also part of our storage and a simple self-contained C++ library.
  • QGpgme: Part of gpgme, used for crypto stuff.
  • KCodecs: A tier1 framework used for some parsing tasks.
  • KPackage: A tier2 framework for packaging qml.
  • KCoreAddons: A tier1 framework that we need for KJob.
  • libcurl: Currently used for its SMTP implementation.

And that’s about it. This means we’re now in a situation where each and every dependency that we have is justified and there for a reason. We’re also in a position where most dependencies can be individually replaced should there be a need to so.
This not only makes me much more confident that we can maintain this system in the long run and makes porting to other platforms feasible, it’s also just a much, much healthier situation to be in for a software project.

In case you are wondering, here’s an incomplete list of packages that we used to depend on and no longer do (based on Fedora 25 packaging, check out rpmreaper to recursively query dependencies):

grantlee-qt5 kdepim-apps-libs kf5-akonadi-contacts kf5-akonadi-mime kf5-akonadi-search kf5-akonadi-server kf5-akonadi-server-mysql kf5-grantleetheme kf5-kauth kf5-kbookmarks kf5-kcalendarcore kf5-kcompletion kf5-kconfig-gui kf5-kconfigwidgets kf5-kdbusaddons kf5-kded kf5-kdelibs4support kf5-kdelibs4support-libs kf5-kdoctools kf5-kemoticons kf5-kiconthemes kf5-kidentitymanagement kf5-kimap kf5-kinit kf5-kio-file-widgets kf5-kitemmodels kf5-kldap kf5-kmailtransport kf5-kmbox kf5-knewstuff kf5-knotifications kf5-kparts kf5-kpimtextedit kf5-krunner kf5-kservice kf5-ktextwidgets kf5-kunitconversion kf5-kwallet-libs kf5-kwidgetsaddons kf5-kwindowsystem kf5-kxmlgui kf5-libgravatar kf5-libkdepim kf5-libkleo kf5-messagelib kf5-pimcommon kf5-solid-libs kf5-sonnet-ui kf5-syntax-highlighting kf5-threadweaver libaio libical libsphinxclient lsof m4 mariadb mariadb-common mariadb-config mariadb-errmsg mariadb-libs mariadb-server mariadb-server-utils net-tools perl-DBD-MySQL perl-DBI perl-Math-BigInt perl-Math-Complex perl-Storable postgresql-libs qt5-qtbase-mysql rsync sphinx

Gsoc Week 3 & 4

Thu, 06/29/2017 - 06:05
Quite a few changes were introduced during this time period
  • Keyboard navigation was fixed for the GridView of AlbumView and OverviewPage.
    • The GridView was not getting focusScope because of the Kirigami’s ScrollablePage, which was corrected by Marco Martin in the Kirigami repository.

  • Introduced corner action for selection of collections and images same as that in Dolphin file manager.

    • Selecting a collection (before clicked) Selecting a collection before clicked

    • Selecting a collection (after clicked) Selecting a collection after clicked

  • Made visibilty of the selectionHighlight dependent on the selection of the collections.
    • As soon as a collection is clicked, the index is inserted into the m_selectionModel (SortModel).
    • And the visibilty status of the selectionHighlight is dependent on whether the index is selected or not in the m_selectionModel

  • Completely removed Baloo from the application as it was not very useful according to the application requirements.

  • The implementation of ImageFolderModel is changed a little bit.
    • Now the ImageFolderModel’s implementation is based on KIO framework.

  • A new model ImageListModel is created to store just the list of images. That is each row of the model will be a single image.

Moving forward! - Dialing phones, and designs featuring Kirigami

Wed, 06/28/2017 - 19:42

Hello everyone, it's been all-too-long!
I am proud to announce the end of the semester! Exams are finally all done, but that only means the real fun can start. And so many things to come and do!

I'm also happy to announce one of the first new features! Marble Maps now supports in-app phone calls! If you're browsing the map, and come across a nice looking shop, you can easily access their phone number, and give them a call right there!
This task has been very useful to establish a lot of the inner workings, and also gave insight to a lot of UI elements that could be structured differently.

But with that question of layouts and design decisions, came the question of what tools to use to achieve them. On that note:
Behaim Globe with KirigamiKirigami is a QtQuick based components set that brings a lot of useful reusable components to QtQuick UI's. Among these we're easy to create menus, unit based scaling, drawers and all sorts of navigation options. It was a lot of fun exploring all these pieces we could fit together to create a user-friendly interface. As a way of getting to know Kirigami, I was tasked with giving the Behaim Globe app a small redesign using these components.
The info bar now comes in an overlay form (with a small black tint), which makes it clear that it's the focus point (and doesn't compete for space with the globe), and should be closed for easier navigation on the globe. It is also now flickable, which allows the user to easily close it, even with one hand, without having to find the exact button. The button to open the menu previously moved from the top left to the bottom right depending on the orientation of the screen, is now fixed at the top left to avoid confusion.

The Behaim Globe app.
The redesigned app.
Kirigami has a lot of interesting solutions and components, one of these being the OverlayDrawer, which I used to replace the old bottom menu. Below I have highlighted some other features that Kirigami offers, that may prove to be very useful.

Button styles, notifications, and menu variations, such as the OverlayDrawer.
Progression markers, and swipe-revealed secondary actions. Also note the central "Main Action" button, as another great way of guiding the user to the main purpose of the page.
Side menu, with checkable items, submenus; context-based actions that are relevant to the current page.
Kirigami provides several menu solutions, such as context-based actions, which the Kirigami Gallery app showcases better than the few examples I have provided ever could.Pros of using Kirigami

  • Navigational options are readily available and easy to use, including actions, context-based menus, drawers and sidebars
  • Units make scaling more intuitive
  • Several components that can be used "out-of-the-box", such as headered lists with different varieties on how the header stays or moves out of view, secondary actions on swiping, progression meters for both defined, and undefined amounts of time
  • Since the built Kirigami files need to be included in the app, this requires another step to be added to the compilation process (namely installing Kirigami as detailed here, to the same folder as the build of our app). 
Overall this experience has led me to have a strong support of Kirigami, and I think it would be a very useful tool to use in crafting an even better Marble Maps. Stay tuned to hopefully see how some of these tools come together in action! See you on the next post!

LabPlot getting "live support"

Wed, 06/28/2017 - 15:59
As I told you guys in my previous post, I'm here now to show you some new, cool stuff about LabPlot. First let me introduce you the synopsis of my project's proposal: 
"Currently, the visualization and analysis of data is only possible on static data that was imported into or generated in one of LabPlot's data containers. The goal of the project is to add support for streaming data. At the moment LabPlot has no support for this kind of data processing even though it is very important for this feature to be available in a scientific data plotting software."
As you can see one of the main tasks here is to be able to handle changing, streaming data. Somebody may plug in their physical device and then watch as their datas are being plotted. For this to work nicely and user friendly, we collected a handful of options to control this kind of data source. The first thing you want to do is to create a new FileDataSource, you can do that this way:
FileDataSource creation

After this you get this nice looking dialog with the new options, controls. We decided to support more types of live data sources, as you can see in the picture below.

FileDataSources optionsFor "File or named pipe" source type we have the following options:

File or named pipe options

This kind of source consists of reading from a local ascii or binary file or a named pipe. A named pipe is a bit more than a traditional pipe because it has a name and unlike the traditional one it can last till the system is up. In Unix systems one has to explicitly create a named pipe using mkfifo or mknod. After creation one process can write to it and one can read from it by name. Also for "Local socket" live data source type we have the same options, but this consist of reading from a local socket using QLocalSocket. To work with QLocalSocket we just need the name of the server the socket is connected to.
The next type of live data source is the Network socket one. The following options we have right now to configure this kind of live data source:
 Network socket options

A network socket is an endpoint for sending/receiving data in a computer network. In our situation we want to read from it. To access a socket we must have the socket host's address and port number. 
The last type of live data source for now is the Serial port one. In the following picture you can see the options for this kind of data source:
Serial port options
This kind of live data source consist of reading from a port to which a physical device is connected. We just have to select the port our device is connected to, set the baud rate and voilá, it should work nicely soon. We use QSerialPort to access, work with serial ports. Using QSerialPortInfo class we can have informations easily about the available ports on our system. Also the supported baud rates can be acquired using QSerialPortInfo.
These options are necessary to set up the wanted kind of live data source. Beside this we must have some control above this kind of data source, right now we have the following options to control the update a FileDataSource:

Update optionsHere you can see that we have two types of updates. The "Time interval" one will update the curves on a specified time interval (every second, every five seconds or so) which is a value in milliseconds. The "New data" update type will update the curves only when there's new data available. In the "Update frequency" we set the interval between the updates when using "Time interval" update type. The "Keep last N values" will control how much of the data we want to update. For this kind of data source one usually want to observe how the data is changing, to take a snapshot of their data. 
Another thing we might want is to have control over this kind of data source even after creation. For this we'll have a dock widget, it's not yet used, but currently it looks like this in Creator:
FileDataSource dock widget
With these options we will be able to modify the number of values we want to keep on every update, the time between updates. If the user uses a long interval between the updates then a functionality like the "Update now" button will provide it's very useful because there might be moments we didn't think we'd need to check the actual state of our data. Also the pausing and stopping the updates/data reading helps in the control of this kind of data source.
I have created a demo video which shows the creation of a FileDataSource, setting the X and Y axis data of some xy curves. Then a python script writes Brownians motion data to a file on which the FileDataSource was created. We can see there the curves being updated on new data:

An issue you can see here is that I have to set for every curve separately the X and Y value columns. We will use the PlotDataDialog which is used for plotting spreadsheet columns to solve this issue. PlotDataDialog is a very user friendly dialog which can be accessed from the spreadsheet's context menu. In this dialog we can select the X data and Y data for any curves we might want to plot from spreadsheet column data. This is the PlotDataDialog:

This is for now, hope you guys enjoyed it! The next step is to implement all the logic behind these options and make them do their job. A greater step after implementing the options will be to optimize our code on larger amount of data. Thanks to my mentors, Alexander and Stefan for their great help. Every time I am unsure on something they take their time to talk about it so together we can make LabPlot even cooler than it is right now :).  

See you guys soon again! Have fun on your GSoC project!

Kubuntu Artful Aardvark (17.10) Alpha 1

Wed, 06/28/2017 - 06:01

Artful Aardvark (17.10) Alpha 1 images are now available for testing so we can release the alpha on Thursday.

The Kubuntu team will be releasing 17.10 in October.

This is the first spin in preparation for the Alpha 1 pre-release. Kubuntu Alpha pre-releases are NOT recommended for:

  • Regular users who are not aware of pre-release issues
  • Anyone who needs a stable system
  • Anyone uncomfortable running a possibly frequently broken system
  • Anyone in a production environment with data or workflows that need to be reliable

Kubuntu Alpha pre-releases are recommended for:

  • Regular users who want to help us test by finding, reporting, and/or fixing bugs
  • Kubuntu, KDE, and Qt developers

Getting Kubuntu 17.10 Alpha 1

To upgrade to Kubuntu 17.10 pre-releases from 17.04, run sudo do-release-upgrade -d from a command line.

Download a Bootable image and put it onto a DVD or USB Drive

See our release notes:

Please report your results on the Release tracker:

How to play around with Python and Mock

Wed, 06/28/2017 - 03:15

Once upon a time, I started an internship program. On that program, I needed to program in Python and also write tests. Based on my short experience with Python, I already hated to write tests. I didn't have enough abstraction to learn to write useful tests. After a really long and painful process of learning, I [...]

Let there be color!

Tue, 06/27/2017 - 18:39
I've contributed to KDevelop in the past, on the Python plugin, and so far working on the Rust plugin, my impressions from back then were pretty much spot-on. KDevelop has one of the most well thought-out codebases I've seen. Specifically, KDevPlatform abstracts over different programming languages incredibly well and makes writing a new language plugin a very pleasant experience.The Declaration-Use ChainThe Declaration-Use Chain stands at the core of this. It's a simple enough concept: there are things in the language which are declared somewhere and used in other places. Declarations are a generalization of programming language constructs: structs, struct fields, functions, methods, locals, etc. Declarations can open contexts and any declarations in a child context are valid in that context only. For example, functions open a new context for declarations inside the function body. Uses are, well, what you'd expect: instances where these language constructs are used.
Obviously, there's some details I skipped here, but the beauty in all of this is that KDevelop can figure out a lot of things for you if it simply has access to this information.The Rust CompilerThe Rust compiler is also really well designed in that it allows accessing the internals such as the syntax parsing library. It's not necessarily the nicest thing, as the internals are intentionally marked unstable, but given that a lot of other tools for working with Rust source code like RLS also depend on compiler-internal libraries, I think this is an acceptable compromise.
These will likely stabilise over time, especially given the amount of effort being put into the save-analysis API. Speaking of which, one thing missing that would be very useful is to be able to get the full span of declarations that have an internal context (e.g. the span that covers the body of a function).
My main effort on the Rust side is trying to expose a C API to the compiler structures that is more independent from the compiler internals themselves. Think libclang. I think something like this would make adding support in other IDEs easier. I'm currently looking into hooking into the various stages of the compiler in order to get both the pre- and post-expansion AST, as well as type information inferred by the compiler (though I'll likely try to implement this myself first for the learning experience :)).Building the DU Chain for Rust codeAnd now the fun part: how these fit together. Here is a before and after:
Much better. Going forwardThere are things still missing here; as you may have noticed, uses are not highlighted. I have to admit, I fell about a week and a half behind schedule due to a university group project which was more time consuming than I initially expected as well as my attempt to think through how to best expose certain things as a C API from Rust before writing a significant amount of code. Thankfully, I accounted for some delays like this in my original timeline, so this should be recoverable from.
Right now, I'm aiming to finish adding the missing elements of the DU Chain by the end of this week and then I'll start looking into code completion. 

GSoC - Week 3- 4

Tue, 06/27/2017 - 11:30

Hi everyone, how is it going? Fine, I hope.

Today, I will talk about my work on Krita during the week 3-4 of the coding period.


I implemented two new plugins, canvas size plugin and filter manager (applier) plugin. The first is a plugin to change image size (not scale) and to adjust the top and left edge to selected documents also. The second is a filter applier to the document or nodes, then you can select a node or the document and apply a filter to them.

Canvas Size Plugin

GUI Mockup

I drew a simple mockup to define some direction for my implementation. As you can see, it's something close to the current implementation, but without a canvas preview, we have a list of the opened documents, though.


C++ and SIP implementation

I have to provide offset properties (xOffset, yOffset) to document API and a updating to the resizeImage method to include the new parameters. I implemented these properties and your respective SIP signatures. I also wrote documentation to each method implemented in .h files. Click here to take a look.

GUI implementation with PyQt

At the end, I implemented the GUI and all your interactions and validations. How you can see below, we have a confirm button that resizes the image to selected documents.



Below, you can see the plugin working.

Before After GSOC GSOC

Filter Manager Plugin

GUI Mockup

I didn't draw a GUI mockup, but the main idea here is to have a tree showing documents and your nodes and a list of the application's filters.

C++ and SIP implementation

I don't changed the C++ code, I fixed some bugs in the API, though.

GUI implementation with PyQt

You can see below the final result of my work. The tree was implemented using Model-View pattern. You can apply filters from the list to specific node or to all document (all top level nodes).



Below, you can see the image before and after the application of the "desaturate" filter.

Before After GSOC GSOC What will I do in the next week?
  • Simple scripts of the previous plugins
  • Plugin to take a list of images (inputted list) and apply rotate/scale
  • Script to export all the layers (batch)
  • Script to Duplicate image
  • Script to Export to jpg X% quality.

That’s it for now, until the next week. See ya!!

Daemons and friendly Ninjas

Mon, 06/26/2017 - 20:19

Image of Beastie + NinjaThere’s quite a lot of software that uses CMake as a (meta-)buildsystem. A quick count in the FreeBSD ports tree shows me 1110 ports (over a thousand) that use it. CMake generates buildsystem files which then direct the actual build — it doesn’t do building itself.

There are multiple buildsystem-backends available: in regular usage, CMake generates Makefiles (and does a reasonable job of producing Makefiles that work for GNU Make and for BSD Make). But it can generate Ninja, or Visual Studio, and other buildsystem files. It’s quite flexible in this regard.

Recently, the KDE-FreeBSD team has been working on Qt WebEngine, which is horrible. It contains a complete Chromium and who knows what else. Rebuilding it takes forever.

But Tobias (KDE-FreeBSD) and Koos (GNOME-FreeBSD) noticed that building things with the Ninja backend was considerably faster for some packages (e.g. Qt WebEngine, and Evolution data-thingy). Tobias wanted to try to extend the build-time improvements to all of the CMake-based ports in FreeBSD, and over the past few days, this has been a succes.

Ports builds using CMake now default to using Ninja as buildsystem-backend.

Here’s a bitty table of build-times. These are one-off build times, so hardly scientifically accurate — but suggestive of a slight improvement in build time.

Name Size GMake Ninja liblxt 50kB 0:32 0:31 llvm38 1655kB * 19:43 musescore 47590kB 4:00 3:54 webkit2-gtk3 14652kB 44:29 37:40

Or here’s a much more thorough table of results from tcberner@, who did 5 builds of each with and without ninja. I’ve cut out the raw data, here are just the average-of-five results, showing usually a slight improvement in build time with Ninja.

Name av make av ninj Delta D/Awo compiler-rt 00:08 00:07 -00:01 -14% openjpeg 00:06 00:07 +00:01 +17% marble 01:57 01:43 -00:14 -11% uhd 01:49 01:34 -00:15 -13% opencacscade 04:08 03:23 -00:45 -18% avidemux 03:01 02:49 -00:12 – 6% kdevelop 01:43 01:33 -00:10 – 9% ring-libclient 00:58 00:53 -00:05 – 8%

Not everything builds properly with Ninja. This is usually due to missing dependencies that CMake does not discover; this shows up when foo depends on bar but no rule is generated for it. Depending on build order and speed, bar may be there already by the time foo gets around to being built. Doxygen showed this, where builds on 1 CPU core were all fine, but 8 cores would blow up occasionally.

In many cases, we’ve gone and fixed the missing implicit dependencies in ports and upstreams. But some things are intractable, or just really need GNU Make. For this, the FreeBSD ports infrastructure now has a knob attached to CMake for switching a port build to GNU Make.

  • Normal: USES=cmake
  • Out-of-source: USES=cmake:outsource
  • GNU Make: USES=cmake:noninja gmake
  • OoS, GMake: USES=cmake:outsource,noninja gmake
  • Bad: USES=cmake gmake

For the majority of users, this has no effect, but for our package-building clusters, and for KDE-FreeBSD developers who build a lot of CMake-buildsystem software in a day it may add up to an extra coffee break. So I’ll raise a shot of espresso to friendship between daemons and ninjas.

(Image credits: Beastie by Marshall Kirk McKusick on, Ninja by irkeninvaderkit on deviantart)

First coding month

Mon, 06/26/2017 - 03:46
Heading towards the first evaluation:

Even the exams and graduation project work this month, heading towards the first evaluation according to timeline with the planned UI ready for further development and started the search with examining a similar tool in gimp, and had more insights about the details of how the “Image Editor” works on a deeper level and how I should work to get to my next milestone of static parts cloning supporting the variable radius within the next 11 days.


Go support in KDevelop. GSoC week 4. DU-Chain time!

Sun, 06/25/2017 - 16:24
During this week, I decided to spend more time on language support: code completion, highlighting and so on. This part is provided by DU-Chain. Du-Chain stands for Definition-Use chain which consist of various contexts, declarations in these contexts and usages of these declarations.

First change improved declaration of variables in parameters of anonymous functions. In Go language, it is possible to define anonymous function and assign it to variable, pass as parameter (people use it for various callbacks for example) or simple call it. Before my change, parameters of anonymous functions were treated as declarations only in case of assigning that function to variable. Thus, if, for example, you typed the example of Gin web framework usage:
package main
import ""
func main() {
r := gin.Default()
r.GET("/ping", func(c *gin.Context) {
c.JSON(200, gin.H{
"message": "pong",
r.Run() // listen and serve on
}you would end up with “c” not being highlighted / treated as variable. After my change, parameters of anonymous functions are treated as variable declarations in all three cases: assigning, passing and calling (see screenshots).

Second change is under review and is aimed at adding code completion from embedded structs. In Go language, there is no such thing as inheritance – composition is preferred over it. Composition often has drawback – we need to pass all calls to “base” methods so there will be a lot of boilerplate code. In Go this problem is solved using “embedding” structs so their fields and methods are added to top-level struct. For example, struct A has a method Work and struct B embeds struct A. So both B.Work() and B.A.Work() are correct. Because of that we need to travel over all embedding tree for retrieving all possible completions – this is what my second change is aimed at.

Third change added errors of parsing as problems in “Problems” view.

Fourth change fixed misplacing usage information in wrong context. Before that change, information of variable usages was placed in top context, which had led to not working semantic highlighting – variable declarations had different colors but usages were all same. Therefore, while improving overall correctness of generated DU-Chain I also fixed that issue and now variable usages are colored too (see screenshots)!
Before After

Apart from DU-Chain improvements I got merged a basic project manager plugin which offers a template of simple console Go application and allows to build Go projects easier.

Looking forward to next week!

That’s one small step for a man, one giant leap for GSoC project.

Sun, 06/25/2017 - 15:33

For the last month the main time I took the exams, because of this I did not do much for my project. Nevertheless, I implemented the basic primitives and tested them.

Let me tell you about them.

Wet map.

Water is the main part in watercolors. That’s why I started with this.

Wet map contains 2 types of information: water value and speed vector. If the first parameter is clear, then the second one needs explanations. Speed vector needs for rewetting our splats (take it in mind, I will explain what this later).

All this values Wet map contains in KisPaintDevice:

KisPaintDeviceSP m_wetMap;

As the color space was chosen rgb16:

m_wetMap = new KisPaintDevice(KoColorSpaceRegistry::instance()->rgb16());

And there are information about water value and speed vector in pixel data.

But in this form Paint Device can’t visualize wet map correctly:

So I transorm Paint Device for visualizing wet map correctly (because it will be important for artists, I think). And now it looks like this:


My implementation is based on a procedural brush. Every brush stamp is a union of dynamic splats. Here you can see the behavior of splats:

Also I tested reweting (when splat go to flowing state from fixed state):


And as a final test I made splat generator for simulating strokes:


What next?

It’s high time to get splats to work in Krita. So I’m going to finish my plugin, and test splats behavior. But it will be primitive:

  1. Clear canvas for updating splats
  2. No undo/redo
  3. Stupid singleton for splat storage

The achievements during the first GSoC period in KStars

Sun, 06/25/2017 - 07:56

I was able to do major improvements to the build system of KStars. I think more and more open-source projects should pick up these low-hanging fruits with CMake and Clang:

- CCache: Speed-up the development time and working with git branches by caching the compiled object files.
- Unity Build: This simple "hack" can reduce the build time dramatically by compiling temporary C++ meta files in which the normal C++ files are included. The build time can be speeded up to 2x-3x for bigger projects.
- Clang Sanitizers: Use undefined behavior and address sanitizers to hunt down memory handling errors. Although the executable must be recompiled with Clang and special compiler flags, the resulted binary will run with minimal slowdown. It is not a complete replacement, but these sanitizers can catch most of the problems found by Valgrind during normal runtime.
- Clang Format: Format the source code with a real compiler engine.

More details are on our wiki page:

GSoC preparation - Plasma Toolicons - A journey down the rabbit hole

Sat, 06/24/2017 - 22:00

Before writing about my actual Summer of Code experiences, I wanted to briefly share what I worked on before the official coding start.

Plasma Toolicons

Plasma toolicons

Can you see these ridiculously small toolicons next to the Media frame plasmoid? I’m talking about the icons which allow you to Resize, Rotate and Remove the Plasmoid. Compared with other icons, these are clearly too small.

So, as preparation for GSoC, I wanted to know why this happens, and what would be required to make them bigger. Thus my journey into the (Plasma) rabbithole began…

Tracking down where the containment is defined was relatively easy, and shortly after i found the code responsible for the ActionButton:

PlasmaCore.ToolTipArea { id: button location: PlasmaCore.Types.LeftEdge mainText: action !== undefined ? action.text : "" mainItem: toolTipDelegate //API property QtObject svg property alias elementId: icon.elementId property QtObject action property bool backgroundVisible: false property int iconSize: 32 [...]

Huh, the iconSize is 32px? Well, that was wasy to fix, surely this should be set to units.iconSizes.small and this problem is gone…

… or so I thought. No, this didn’t improve the situation, back to square one.

Is it overwritten by the look and feel theme? plasma-workspace/lookandfeel/contents/components/ActionButton.qml at least doesn’t - and it also happens with the style set to Oxygen.

While looking at this, I also noticed that units.iconSizes.small returned 16px on my system. This seemed odd, because the scale factor was set to 1.8x, so I would have expected bigger icons.

Where is this icon size calculated? Ah yes, in the file units.cpp, method Units::devicePixelIconSize.

int Units::devicePixelIconSize(const int size) const { /* in kiconloader.h enum StdSizes { SizeSmall=16, SizeSmallMedium=22, SizeMedium=32, [...] }; */ // Scale the icon sizes up using the devicePixelRatio // This function returns the next stepping icon size // and multiplies the global settings with the dpi ratio. const qreal ratio = devicePixelRatio(); if (ratio < 1.5) { return size; } else if (ratio < 2.0) { return size * 1.5; } else if (ratio < 2.5) { [...] }

Ok, my devicePixelRatio is 1.8 and therefore the icon size of a small pixmap gets multiplied by 1.5 and a request for a small (16px) pixmap should return a 24px pixmap.

But it doesn’t…

Debugging suggested that my devicePixelRatio is NOT 1.8, but rather around 1.4. How did that happen, isn’t the scale factor from the KDE settings used?

Oh, the comment in updateDevicePixelRatio() mentions that QGuiApplication::devicePixelRatio() is really not used:

void Units::updateDevicePixelRatio() { // Using QGuiApplication::devicePixelRatio() gives too coarse values, // i.e. it directly jumps from 1.0 to 2.0. We want tighter control on // sizing, so we compute the exact ratio and use that. // TODO: make it possible to adapt to the dpi for the current screen dpi // instead of assuming that all of them use the same dpi which applies for // X11 but not for other systems. QScreen *primary = QGuiApplication::primaryScreen(); if (!primary) { return; } const qreal dpi = primary->logicalDotsPerInchX(); // Usual "default" is 96 dpi // that magic ratio follows the definition of "device independent pixel" by Microsoft m_devicePixelRatio = (qreal)dpi / (qreal)96;

Hmm, yes, that was the case in earlier Qt versions when devicePixelRatio still returned an integer - but nowadays the value is a real number.

So, instead of calculating dpi / 96 I just changed it to return primary->devicePixelRatio().

Which now, finally, should return a devicePixelRatio of 1.8 and therefore result in bigger pixmaps.

Compiled it, and confident of victory restarted plasmashell… only to notice, that it still didn’t work.

What could there still go wrong?

So I got back to debugging.. to notice that primary->devicePixelRatio() returns a scale factor of 1.0. Huh? Isn’t this supposed to just use the QT_SCREEN_SCALE_FACTORS environment variable, which gets set to the value of the “Scale Display” dialog in the Systemsettings? If you want to know, the code for setting the environment variable is located in plasma-workspace/startkde/startplasmacompositor.cmake.

But why isn’t the problem gone, is there something in Plasma that overwrites this value?

Yes, of course there is!

The only way this value can be overwritten is due to the Qt attribute Qt::AA_DisableHighDpiScaling.

Grep’ing for that one pointed me to plasma-workspace/shell/main.cpp - the base file for plasmashell:

int main(int argc, char *argv[]) { // Devive pixel ratio has some problems in plasmashell currently. // - dialog continually expands (347951) // - Text element text is screwed (QTBUG-42606) // - Panel struts (350614) // This variable should possibly be removed when all are fixed qunsetenv("QT_DEVICE_PIXEL_RATIO"); QCoreApplication::setAttribute(Qt::AA_DisableHighDpiScaling);

I looked into the mentioned bugs. What should I do now? Re-enabling the HighDpiScaling-flag so the real devicePixelRatio is returned in Qt, and therefore I can use this value to calculate the sizes icons should be and then have the bigger Plasma ToolIcons? At least QTBUG-42606 seems to be fixed…

Oh boy, what have I gotten into now…

It was time to talk to my mentor!

David Edmundson quickly noticed that there should be no mismatch with the dpi / 96 calculation. Something fishy seems to be going on here…

What is this dpi value anyway? This is the one reported by xrdb -query |grep Xft.dpi and managed in the file $HOME/.config/kcmfonts.

And that value - as you probably can guess by now - did not make any sense. It didn’t match the expectation of being scaleFactor * 96, the value it should have been set to.

On we go to the location where the scaling configuration is set - scalingconfig.cpp in the KScreen KConfig Module.

void ScalingConfig::accept() { [...] fontConfigGroup.writeEntry("forceFontDPI", scaleDPI()); [...] } qreal ScalingConfig::scaleDPI() const { return scaleFactor() * 96.0; }

This scaleDPI is then applied with xrdb -quiet -merge -nocpp on startup.

So Xft.dpi is set to 1.8 * 96.0, or 172.8.

Have you spotted what is going wrong?

I did not, but David noticed…

The X server can only handle real values - and therefore 172.8 is simlpy discarded!

A few moments later this patch was ready…

Plasma Toolicons

… and I was finally able to enjoy my icons in all their scaled glory! And you can too, because this patch is already in Plasma 5.10.

Latte Dock accepts donations, what is coming...

Sat, 06/24/2017 - 18:12

Hello again...
because there are users that requested a way in order to support Latte even further and donate for the project, we created a donation page at pledgie:

and we added also a donate button in our main page at:

 Latte Dock and make a donation at !

to cheer you up a bit for the upcoming 0.7 version which is scheduled for the end of August or maybe earlier ;) based on the effort...
some of the features already implemented and some that are going to land:
  • support layouts and change them with one click (we enhanced our export/import configuration mechanism to layouts. We provide already 5 predefined layouts and the user can add as many wants to)
  • provide two layouts for the configuration window (Basic/Advanced)
  • set the dock transparency per dock and enable/disable its panel shadows
  • global shortcuts, Super+No (unity way), Super+Ctrl+No (new instance), Super+` (raise the hidden dock)
  • support from libtaskmanager the libunity interface in order to show progress indicators and item counters such as unread e-mails etc... this needs libunity9 installed. +expose independently our own simpler dbus interface to show counters for tasks if there are programmers out there that dont want to use the libunity way
  • tasks audio streams indicator (increase/decrease volume with scroll whell and mute with clicking it)
  • the new Places exposer for your tasks/launchers that plasma 5.10 offers
  • dynamic dock background (show the background only for maximized windows and choose also if you want the dock shadow to be shown in that case)
  • copy your docks easily with one-click (extremely useful in multi-screen environments that want the same dock between different screens)
  • sync your launchers between all your docks (global launchers, they do not erase your per dock launchers if you disable them)
  • wayland tech preview (there is already code implemented for this and landed in our master)
  • support fillWidth/Height applets like the plasma panel
  • substitute the Latte plasmoid with your favourite plasma taskmanager (having implemented proper fillWidth/Height for the applets we can now provide this)
  • support separators everywhere and work correclty with the parabolic effect
  • various improvements for launchers start up, animations etc....

Latte 0.7 will be compatible with plasma>=5.9 and qt>=5.7

thanks everyone once more for your support...

GSoC’17-Week #2

Fri, 06/23/2017 - 14:09

Week 2 of GSoC’s coding period was pretty dope :D. After all the hard work from the last week, I got my downloader to pull data from the website As from the Week #1’s work status update, we have all discussed what all classes and functions were required to get this running. I was able to get it done and the downloader started downloading the data from the website.

PS: To get my project up and running we need KNewStuff framework version to be 5.29+. KNS team has done a lot of work in the area creating things to move pretty much good. (They have isolated KNSCore and KNS3 from then).

Before I proceed, I would love to mention the immense support and help given to me by Leinir for understanding how KNS and KNSCore works. If he didn’t notice my blog post which I posted at the starting of my project and official coding period, I would be lost at every single point of my project :P. As well as my Krita community people &#55357;&#56898;

As we had discussed the different classes I have created for the project to proceed, we have used certain KDE primary level framework/APIs in order to complete the GUI and get things working as planned.

Some of them, I have listed below.

  • Kconfig

The KConfig framework offers functionality around reading and writing configuration. KConfig consists of two parts, KConfigCore and KConfigGui. KConfigCore offers an abstract API to configuration files. It allows grouping and transparent cascading and (de-)serialization. KConfigGui offers, on top of KConfigCore, shortcuts, and configuration for some common cases, such as session and window restoration.

  • KWidgetsAddons

KWidgetAddons contains higher-level user interface elements for common tasks. KWidgetAddons contains widgets for the following areas:

  • Keyboard accelerators
  • Action menus and selections
  • Capacity indicator
  • Character selection
  • Color selection
  • Drag decorators
  • Fonts
  • Message boxes
  • Passwords
  • Paging of e.g. wizards
  • Popups and other dialogs
  • Rating
  • Ruler
  • Separators
  • Squeezed labels
  • Titles
  • URL line edits with drag and drop
  • View state serialization
  • KRatingWidget

This class is a part of KWidgetAddons class. It displays a rating value as a row of pixmaps. The KRatingWidget displays a range of stars or other arbitrary pixmaps and allows the user to select a certain number by mouse.

Hence, till now I have implemented order by functionality to sort data items accordingly. Have included functionalities to sort according to categories. While the categories get populated according to the knsrc file. We have options to rate each item on star basis according to the likes of the user. We also have the option to see the expanded details of each item. Revised a methodology to view items in a different mode such as icon mode and list mode. Also, Function to search between the items is also working just fine.

To see all the changes and test it visually, Created a test UI and shows how things work out and pull in data from the site. I will attach it here:

2017-06-21Content downloader with the basic test UI, which does look like the existing KNewStuff. Next step is to change it to our own customizable UI.

Plans for Week #3

Start creating the UI for the resource downloader which will be customizable hereafter. We just need to tweak the existing UI to our need.

Untitled drawing (3)Here is what we actually need.

After that, This week is being followed by the first Evaluation of our work so I have mostly done my part well. Completed the tasks as required in time. As well as my Krita community too. So, after evaluation for the first phase gets over, I will be doing the following.

  1. Give the work done till now a test run with the new and revised GUI for the content downloader.
  2. Fix any bugs if there exists or noticed at the testing phase in the content downloader and fix some of the bugs which might exist in the Resource Manager after discussing it with the Krita community.
  3. Meanwhile, these are going through, will be documenting the functions and classes created and changed.

Here is my branch were all the work I am done is going to.

Will be back with more updates later next week.

Cheers. &#55357;&#56832;

Understanding Xwayland - Part 1 of 2

Fri, 06/23/2017 - 14:00

In this week’s article for my ongoing Google Summer of Code (GSoC) project I planned on writing about the basic idea behind the project, but I reconsidered and decided to first give an overview on how Xwayland functions on a high-level and in the next week take a look at its inner workings in detail. The reason for that is, that there is not much Xwayland documentation available right now. So these two articles are meant to fill this void in order to give interested beginners a helping hand. And in two weeks I’ll catch up on explaining the project’s idea.

As we go high level this week the first question is, what is Xwayland supposed to achieve at all? You may know this. It’s something in a Wayland session ensuring that applications, which don’t support Wayland but only the old Xserver still function normally, i.e. it ensures backwards compatibility. But how does it do this? Before we go into this, there is one more thing to talk about, since I called Xwayland only something before. What is Xwayland exactly? How does it look to you on your Linux system? We’ll see in the next week that it’s not as easy to answer as the following simple explanation makes it appear, but for now this is enough: It’s a single binary containing an Xserver with a special backend written to communicate with the Wayland compositor active on your system - for example with KWin in a Plasma Wayland session.

To make it more tangible let’s take a look at Debian: There is a package called Xwayland and it consists of basically only the aforementioned binary file. This binary gets copied to /usr/bin/Xwayland. Compare this to the normal Xserver provided by, which in Debian you can find in the package xserver-xorg-core. The respective binary gets put into /usr/bin/Xorg together with a symlink /usr/bin/X pointing to it.

While the latter is the central building block in an X session and therefore gets launched before anything else with graphical output, the Xserver in the Xwayland binary works differently: It is embedded in a Wayland session. And in a Wayland session the Wayland compositor is the central building block. This means in particular that the Wayland compositor also takes up the role of being the server, who talks to Wayland native applications with graphical output as its clients. They send request to it in order to present their painted stuff on the screen. The Xserver in the Xwayland binary is only a necessary link between applications, which are only able to speak to an Xserver, and the Wayland compositor/server. Therefore the Xwayland binary gets launched later on by the compositor or some other process in the workspace. In Plasma it’s launched by KWin after the compositor has initialized the rendering pipeline. You find the relevant code here.

Although in this case KWin also establishes some communication channels with the newly created Xwayland process, in general the communication between Xwayland and a Wayland server is done by the normal Wayland protocoll in the same way other native Wayland applications talk to the compositor/server. This means the windows requested by possibly several X based applications and provided by Xwayland acting as an Xserver are translated at the same time by Xwayland to Wayland compatible objects and, acting as a native Wayland client, send to the Wayland compositor via the Wayland protocol. These windows look to the Wayland compositor just like the windows - in Wayland terminology surfaces - of every other Wayland native application. When reading this keep in mind, that an application in Wayland is not limited to using only one window/surface but can create multiple at the same time, so Xwayland as a native Wayland client can do the same for all the windows created for all of its X clients.

In the second part next week we’ll have a close look at the Xwayland code to see how Xwayland fills its role as an Xserver in regards to its X based clients and at the same time acts as a Wayland client when facing the Wayland compositor.

Made with Krita: Bird Brains

Fri, 06/23/2017 - 12:51

Look what we got today by snail mail:

It’s a children’s nonfiction book, nice for adults too, by Jeremy Hyman (text) and Haude Levesque (art). All the art was made with Krita!


One of my favorite illustrations is the singing White-throated sparrow (page 24-25). The details of the wing feathers, the boldness of the black and white stripes, and the shine in the eye all make the bird leap off the page.

I love the picture of the long tailed manakins (page 32-33). I think this illustration captures the velvety black of the body plumage, and the soft texture of the blue cape, and the shining red of the cap. I also like the way the unfocused background makes the birds in the foreground seem so crisp. It reminds me of seeing these birds in Costa Rica – in dark and misty tropical forests, the world often seems a bit out of focus until a bright bird, flower, or butterfly focuses your attention.

I also love the picture of the red-knobbed hornbill (page 68-69). You can see the texture and detail of the feathers, even in the dark black feathers of the wings and back. The illustration combines the crispness and texture of the branches, leaves and fruits in the foreground, with the softer focus on leaves in the background and a clear blue sky. Something about this illustration reminds me of the bird dioramas at the American Museum of Natural History – a place I visited many times with my grandfather (to whom the book is dedicated). The realism of those dioramas made me fantasize about seeing those birds and those landscapes someday. Hopefully, good illustrations will similarly inspire some children to see the birds of the world.


My name is Haude Levesque and I am a scientific illustrator, writer and fish biologist. I have always been interested in both animal sciences and art, and it has been hard to choose between both careers, until I started illustrating books as a side job, about ten years ago while doing my post doc. My first illustration job was a book about insects behavior (Bug Butts), which I did digitally after taking an illustration class at the University of Minnesota. Since then, I have been both teaching biology, illustrating and writing books, while raising my two kids. The book “Bird Brains” belongs to a series with two other books that I illustrated, and Iwanted to have illustrations that look similar, which is full double page illustrations of a main animal in its natural habitat. I started using Krita only a year ago when illustrating “Bird Brains”, upon a suggestion from my husband, who is a software engineer and into open source software. I was getting frustrated with the software I had used previously, because it did not allow me to render life-like drawings, and required too many steps and time to do what I wanted. I also wanted my drawing to look like real paintings and also get the feeling that I am painting and Krita’s brushes do just that. It is hard for me to choose a favorite illustration in “Bird Brains”, I like them all and I know how many hours I spent on each. But, if I had to, I would say the superb lyrebird, page 28 and 29. I like how this bird is walking and singing at the same time and I like how I could render its plumage while giving him a real life posture.

I also like the striated heron, page 60 and 61. Herons are my favorite birds and I like the contrast between the pink and the green of the lilypads. Overall I am very happy with the illustrations in this book and I am planning on doing more scientific books for kids and possibly try fiction as well.

You can get it here from Amazon or here from Book Depository.

ISO Image Writer

Thu, 06/22/2017 - 19:14

ISO Image Writer is a tool I’m working on which writes .iso files onto a USB disk ready for installing your lovely new operating system.  Surprisingly many distros don’t have very slick recommendations for how to do this but they’re all welcome to try this.

It’s based on ROSA Image Writer which has served KDE neon and other projects well for some time.  This adds ISO verification to automatically check the digital signatures or checksums, currently supported is KDE neon, Kubuntu and Netrunner.  It also uses KAuth so it doesn’t run the UI as root, only a simple helper binary to do the writing.  And it uses KDE Frameworks goodness so the UI feels nice.

First alpha 0.1 is out now.

Download from

Signed by release manager Jonathan Riddell with 0xEC94D18F7F05997E. Git tags are also signed by the same key.

It’s in KDE Git at kde:isoimagewriter and in, please do try it out and report any issues.  If you’d like a distro added to the verification please let me know and/or submit a patch. (The code to do with is a bit verbose currently, it needs tidied up.)

I’d like to work out how to make AppImages, Windows and Mac installs for this but for now it’s in KDE neon developer editions and available as source.


Facebooktwittergoogle_pluslinkedinby feather