June 18, 2017

Hello! I am Mikhail Ivchenko, 19 years old student from Russia, and I am participating in GSoC this summer working on improving Go language support in KDevelop.

I did not have much time recently due to exams. Fortunately, I have successfully passed them all and ready to focus all my energy on project. So far, I already had some nice conversations with my mentors Sven Brauch and Aleix Pol and got some helpful advice from them.

During this week, I mostly worked on improving test coverage of the Go parser. I added tests for numbers, comments, loops, multi-line strings and short variable declarations. This allowed me to find issues in multi-line strings parsing: 1) in the Go language, a string wrapped in " quotes cannot be multi-line but it our parser allowed it and 2) a string wrapped in ` quotes can be multi-line but our parser did not parse it correctly. Fixing that required me to work with kdevelop-pg-qt - the KDevelop parser-generator. That wiki page was useful for me because it contains a lot of information about how kdevelop-pg-qt works in general and how to write grammar files in particular. With multi-line strings behavior fixed we are able to have a fuller description of multi-line string constants in “Code Browser” tool view (see screenshots).


That is why test coverage is important - it allows you to find some bugs easier. However, I think that there is one more idea behind that. When I started to work with that Go parser I was not able to judge its completeness at all. It looked good by manual testing but I just was not able to test by hand all features and check if they are parsed correctly. Therefore, having tests for the language parser provides you some kind of "guarantee" that it covers most of cases. It differs from regular applications because in that case you are able to test some scenarios by hand (hey! I am not saying you do not need to write tests. Test coverage is good anyways) but while working on language parsing you often cannot come up with all syntax variations / syntax possibilities and even if you can, the amount of test cases can be big for testing by hand. So, that is why I want to spend some more time on that at some point.

Looking forward to next week!
Mikhail Ivchenko

I really wanted to say that Krita was the first KDE Frameworks 5-based application available in the official FreeBSD ports tree (so that pkg install krita just works), but it turns out that labplot has been KF5-based for a month or more and no-one noticed.

Nonetheless, three cheers for Krita and Calligra, which have been updated to the latest, modernest versions.

This is the start of a whole flood of updates, although Plasma is still going to take a while. Several things have come together to make this update possible:

  • FreeBSD KDE CI is running, so we can keep a close(r) eye on upstream. (This is what runs in KDE’s CI system, for FreeBSD)
  • KDE FreeBSD CI is running, so we can keep a close eye on ourselves. (This is what runs in FreeBSD’s CI systems, for KDE)
  • Both KDE and FreeBSD have Phabricator review systems, one for changes to downstream packaging, one for changes to upstream code.
  • KDE FreeBSD ports development is happening in a GitHub fork of the official FreeBSD ports tree.

With good CI and a good review process, we’ve been much happier getting packaging-fixes upstream than ever before. The CI catches unpleasant changes (hey, k3b has turned red, what’s up? Patches forthcoming ..) before they are released. The packaging CI is good for keeping track of where we are in packaging things ourselves. Since there’s a fair amount of package-shuffling going on, that’s important to have in hand. Finally the move to a git clone of the official ports tree makes it much easier to do small topic branches (e.g. updating Frameworks), test, and merge than we ever could with the SVN-based tree.

There’s a handful of smaller updates in-flight, alongside the Great Big Plasma5 branch, which is now shrinking as parts of it start to show up in the official ports already.

KIO Slaves are out-of-process worker applications that perform protocol-specific communications. To provide local file handling file managers use the file ioslave(file:/). Up until now file management with root access was forbidden in file ioslave. But with this week’s work situation might just change for good.

During the past week and a half, I worked on getting polkit support to delete, copy, rename, symlink and mkdir function. My attempts at getting these file operations working correctly inside a read-only folder were almost successful. I was able to add polkit support to all but the copy file operation. To get the copy function working I needed to be able to open a file with elevated privilege in the KAuth helper and send back the file descriptor to file ioslave for further processing. It was the latter part that proved to be the major obstacle. Since file descriptors are non-negative integers it may be instinctive to embed them in QVariant and send them back to ioslave over D-Bus. However, they have more to them than just being an integer. Owing to this fact the integer value is pretty much meaningless outside its host process. Therefore, even though I was able to retrieve the file descriptor in ioslave, doing any kind of file processing ended in failure. Although unix local domain socket is apt for this task, due to my unfamiliarity with network programming and the unavailability of any equivalents in Qt, I had to postpone my work on the copy function for a while.

Coming back to changes. I had added polkit support to the delete function prior to sending my GSOC proposal as a proof of concept. So, during this time I mostly made it a bit modular and separated, what seemed to be, the boilerplate code. Getting polkit support to rest of the lot was simple as the code was similar to that of delete. After these successive changes, a KIO client can now perform the following tasks as a privileged user without having to start itself as root.

  1. Delete files and folders.
  2. Rename files and folders.
  3. Create folders.
  4. Create symbolic links.

You can view all of my changes in cgit.kde.org. To avoid any convolution in future I went for creating a separate branch for every file management function instead of a single, difficult-to-manage branch. Testing the upgraded ioslave needs some changes in dolphin as well. Since the changes are trivial and cloning dolphin seemed futile, I have hosted my patches for dolphin on github. Apart from the clone, I have some patches on phabricator as well, precisely D6197, D6198 and D6199. Apply them in order to test polkit support in delete file operation. So, if you are getting bored and looking forward to doing some unpaid labor you can review my patches, alternatively, you can also fork my kio clone and see the changes yourself. (:

Here’s a demo for the curious minds.

That’s all for this week folks.

June 17, 2017

Kubuntu 17.04 – Zesty Zapus

The latest 5.10.2 bugfix update for the Plasma 5.10 desktop is now available in our backports PPA for Zesty Zapus 17.04.

Included with the update is KDE Frameworks 5.35

Kdevelop has also been updated to the latest version 5.1.1

Our backports for Xenial Xerus 16.04 also receive updated Plasma and Frameworks, plus some requested KDE applications.

Kubuntu 16.04 – Xenial Xerus

  • Plasma Desktop 5.8.7 LTS bugfix update
  • KDE Frameworks 5.35
  • Digikam 5.5.0
  • Kdevelop 5.1.1
  • Krita 3.1.4
  • Konversation 1.7.2
  • Krusader 2.6

To update, use the Software Repository Guide to 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 already contains significant version upgrades of Plasma, applications, Frameworks (and Qt for 16.04), so please be aware that enabling the backports PPA for the 1st time and doing a full upgrade will result in a substantial amount of upgraded packages in addition to the versions in this announcement.  The PPA will also continue to receive bugfix and other stable updates when they become available.

~ 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], file a bug against our PPA packages [3], or optionally contact us via social media.

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

Some time ago, we got in touch with a team from Microsoft that was reaching out to projects like Krita and Inkscape. They were offering to help our projects to publish in the Windows Store, doing the initial conversion and helping us get published.

We decided to take them up on their offer. We have had the intention to offer Krita on the Windows Store for quite some time already, only we never had the time to get it done.


Putting Krita in the Windows Store makes Krita visible to a whole new group of people. plus…


And we wanted to do the same as on Steam, and put a price-tag on Krita in the store. Publishing Krita on the Store takes time, and the Krita project really needs funding at the moment. (Note, though, that buying Krita in the Windows Store means part of your money goes to Microsoft: it’s still more effective to donate).

In return, if you get Krita from the Windows Store, you get automatic updates, and it becomes really easy to install Krita on all your Windows systems. Krita will also run in a sandbox, like other Windows apps.

Basically, you’re paying for convenience, and to help the project continue.

And there’s another reason to put Krita in the Windows Store: to make sure we’re doing it, and not someone else, unconnected to the project.

For Free Software

Krita is free software under the GNU Public License. Having Krita in the Windows Store doesn’t change that. The Store page has links to the source code (though they might be hardish to find, we don’t control the store layout), and that contains instructions on how to build Krita. If you want to turn your own build into an appx bundle, that’s easy enough.

You can use the Desktop App Converter directly on your build, or you can use it on the builds we make available.

There are no functional differences between Krita as downloaded from this website, and Krita as downloaded from the Windows store. It’s the same binaries, only differently packaged.


We currently still have Krita on Steam, too. We intend to keep it on Steam, and are working on adding the training videos to Steam as well. People who have purchased the lifetime package of Krita Gemini will get all the videos as they are uploaded.

We’re also working on getting Krita 3 into Steam, as a new product, at the same price as Krita in the Windows store — and the same story. Easy updates and installs on all your systems, plus, a purchase supports Krita development.

Additionally, it looks like we might find some funding for updating Krita Gemini to a new version. It’ll be different, because the Gemini approach turns out to be impossible with Qt 5 and Qt Quick 2: we have already spent several thousands of euros on trying to get that to work.

Still, we have to admit that Krita on Steam is slow going. It’s not the easiest app store to work with (that is Ubuntu’s Snap), and uploading all the videos takes a lot of time!

Hi folks, it's been a while since my last post here. I had a hard time to start on GSoC but now that I have successfully graduated from the university (Computer Science BSc) I have all my time for my project. While learning for the exams and preparing for my final exam I've been talking to my mentors often to share our ideas about the project. Thanks to the fact that I have already worked previously (and continously after GSoC) on LabPlot I can implement the needed features much easier and quicker now than last year :) Now that I have my own branch and a few new classes added I can continue the adventure with LabPlot! See you soon! :)

“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”

For more info, head over to: kube.kde.org

Ever since we started working on Kube we faced the conundrum of how to allow Kube to innovate and to provide actual additional value to whatever is already existing out there, while not ending up being a completely theoretical exercise of what could be done, but doesn’t really work in practice. In other words, we want to solve actual problems, but do so in “better” ways than what’s already out there, because otherwise, why bother?

I put “better” into quotes because this is of course subjective, but let me elaborate a bit on what I mean by that.

Traditionally, communication and organization has been dealt with using fairly disjoint tools, that we as users then combine in whatever arbitrary fashion that is useful to us.

For instance:

  • EMail
  • Chat
  • Voice/Video Chat
  • Calendaring
  • Taskmanagement
  • Notetaking

However, these are just tools that may help us work towards a goal, but often don’t support us directly in what we’re actually trying to accomplish.

My goto example; Jane wants to have a meeting with Jim and Bob:

  • Jane tries to find a timeslot that works for all of them (by mail, phone, personally…)
  • She then creates an event in her calendar and invites Jim and Bob, who can in turn accept or decline (scheduling)
  • The meeting will probably have an Agenda that is perhaps distributed over email, or within the event description
  • A meeting room might need to be booked, or an online service might need to be decided.
  • Once the meeting takes place the agenda needs to be followed and notes need to be taken.
  • Meeting minutes and some actionable items come out of the meeting, that then, depending on the type of meeting, may need to be approved by all participants.
  • So finally the approved meeting minutes are distributed and the actionable items are assigned, and perhaps the whole thing is archived somewhere for posterity.

As you can see, a seemingly simple task can actually become a fairly complex workflow, and while we do have a toolbox that helps with some of those steps, nothing really ties the whole thing together.

And that’s precisely where I think we can improve.

Instead of trying to do yet another IMAP client, or yet another calendaring application a far more interesting aspect is how can we improve our workflows, whatever tools that might involve.
Will that involve some email, and some calendaring and some notetaking? Probably, but it’s just a means to and end and not an end by itself.

So if we think about the meeting scheduling workflow there is a variety of ways how we can support Jane:

  • The scheduling can be supported by:
    • Traditional iCal based scheduling
    • An email message to invite someone by text.
    • Some external service like doodle.com
  • The agenda can be structured as a todo-list that you can check off during the meeting (perhaps with time limits assigend for each agenda item)
  • An online meeting space can be integrated, directly offering the agenda and collaborative note-taking.
  • The distribution and approval of meeting minutes can be automated, resulting in a timeline of past meetings, including meeting minutes and actionable items (tasks) that fell out of it.

That means however that rather than building disjoint views for email, calendar and chat, perhaps we would help Jane more if we built and actual UI for that specific purpose, and other UI’s for other purposes.


So in an ideal world we’d have an ideal tool for every task the user ever has to execute which would mean we fully understand each individual user and all his responsibilities and favorite workflows….
Probably not going to happen anytime soon.

While there are absolutely reachable goals like Jane’s meeting workflow above, they all come at significant implementation cost and we can’t hope to implement enough of them right off the bat in adequate quality.
What we can do however is keeping that mindset of building workflows rather than IMAP/iCal/… clients and setting a target somewhere far off on the horizon and try to build useful stuff along the way.

For us that means that we’ve now set the basic structure of Kube as a set of “Views” that are used as containers for those workflows.


This is a purposefully loose concept that will allow us to transition gradually from fairly traditional and generic views to more purposeful and specific views because we can introduce new views and phase out old ones, once their purpose is helped better by a more specific view.

Some of our initial view ideas are drafted up here: https://phabricator.kde.org/T6029

What we’re starting out with is this:

  • A Conversations view:
    While this initially is a fairly standard email view, it will eventually become a conversation centric view where you can follow and pick up on ongoing conversations no matter on what medium (email, chat, …).


  • A People view:
    While also serving the purpose of an addressbook it is first and foremost a people centric way to interact with Kube.
    Perhaps you just want to start a conversation that way, or perhaps you want to lookup past interactions you had with the person.


  • A composer view:
    Initially a fairly standard email composer but eventually this will be much more about content creation and less about email specifically.
    The idea is that what you actually want to do if you’re opening the composer is to write some content. Perhaps this content will end up as email,
    or perhaps it will just end up on a note that will eventually be turned into a blogpost, chances are you don’t even know before you’re done writing.
    This is why the composer implements a workflow that starts with the starting point (your drafts) then goes over to the actual composer to create the content, and finally allows you to do something with the content, i.e. publish or store it somewhere (for now that only supports sending it by email or saving it as draft, but a note/blog/… could be equally viable goals).

The idea of all this is that we can initially build fairly standard and battle-tested layouts and over time work our way towards more specialized, better solutions. It also allows us to offload some perhaps necessary, but not central features to a secondary view, keeping us from having to stuff all available features into the single “email” view, and allowing us to specialize the views for the usecases they’re built for.

KTechLab, the IDE for microcontrollers and electronics has joined KDE. Below I’m summarizing its current status and plans.

June 16, 2017

New FAQ added to KDE neon FAQ.

KDE neon does continuous deployment of the latest KDE software which means there are nearly always new versions of our software to update to. We recommend using Plasma Discover’s updater which appears in your panel:

If you prefer to use the command line you can use the pkcon command:

  • pkcon refresh
  • pkcon update

This will install all new packages and uses the same PackageKit code as Plasma Discover. Some uses of apt do not install new packages which makes it less suitable for KDE neon.


Back in the day I started making a Plasma Wayland ISO to help people try out Plasma on Wayland.  Then we started Neon and the obvious way to create the ISOs became through the Neon infrastructure.  With Wayland becoming closer to be ready to use every day I’ve decided it’s time to scrap the dedicated Wayland ISOs and just install the Wayland session by default on the Dev Unstable ISOs. It’s not yet the default so to give it a try you need to log out, select Wayland session and log in again.  Or install the ISO and select it at login (you’ll need to switch back to X to install, Calamares doesn’t run in Wayland because it wants to run as root which is verboten).

Wayland is pretty much ready to use but the reason we can’t switch to it by default is mostly that some obscure graphics cards may not work with it and it’s hard to implement a detection and fallback for this.  The fonts may be a different size due to differences in the screen dots-per-inch detection and middle mouse button selection paste doesn’t yet work.

Grab the KDE neon Dev Unstable ISO now to try it out.


In the previous instalment we looked at the background for Qt 5.10’s upcoming Vulkan support. Let’s now start digging out into the details.

Obtaining a Vulkan-Enabled Qt Build

When building Qt from sources on Windows, Linux or Android, Vulkan support is enabled automatically whenever a Vulkan header is detected in the build environment. Windows is handled specially in the sense that the environment variable VULKAN_SDK – set by the LunarG Vulkan SDK – is picked up automatically.

Check the output of configure (also available afterwards in config.summary):

Qt Gui:
  Vulkan ................................. yes

If it says no, go to qtbase/config.tests/qpa/vulkan, run make, and see why it did not compile.

As mentioned in part 1, neither the QtGui library nor the platform plugins link directly to libvulkan or similar. Same applies to Qt applications by default. This comes very handy here: a Vulkan-enabled Qt build is perfectly fine for deployment also to systems without any Vulkan libraries. No headache with missing DLLs and such. Naturally, once it turns out Vulkan is not available at runtime, QVulkanInstance::create() will fail and will return false always. It must also be noted that the applications themselves can choose to link to a Vulkan (loader) library, if they have a reason to do so: all it takes is adding LIBS+=-lvulkan or similar to the .pro file.

Getting a Vulkan Instance

In Vulkan all per-application state is stored in a VkInstance object, see the the specification for a detailed overview. In Qt, Vulkan instances are represented by QVulkanInstance. This is backed by a QPlatformVulkanInstance following the usual QPA patterns. The platform plugins, at least the ones that are interested in providing Vulkan support, are expected to provide an implementation for it under the hood. As described earlier, this currently covers windows, xcb and android.

Following the familiar pattern from QWindow and the QOpenGL* classes, QVulkanInstance performs no initialization until create() is called. The loading of the Vulkan library (or the loader library which in turn routes to a vendor implementation) happens only at this point. (with a few exceptions, see below)

The resulting VkInstance can be retrieved via vkInstance().

Quite unsurprisingly, QVulkanInstance allows specifying the usual instance configuration options, like the desired API version, and, most importantly, the list of layers and extensions to enable.

While the Qt APIs allow including unsupported layers and extensions too – since it filters them out automatically – it may still be necessary in some cases to examine the names and versions of all supported layers and extensions. This can be done at any time – even before calling create() – via supportedExtensions() and supportedLayers(). These will naturally trigger an early loading of the Vulkan implementation when needed.

It is worth knowing that the surface-related extensions that are required for basic operation, such as VK_KHR_surface or VK_KHR_win32_surface, are automatically added to the list by Qt, and applications do not have to worry about these.

Typical main() Patterns

In the end the main() function for a Qt application with a Vulkan-capable window (or a Vulkan-capable window embedded into a QWidget hierarchy) will typically look like the following:

int main(int argc, char **argv)
    QGuiApplication app(argc, argv); // or QApplication when widgets are involved

    const bool enableLogsAndValidation = ...

    QVulkanInstance inst;

    if (enableLogsAndValidation) {

#ifndef Q_OS_ANDROID
        inst.setLayers(QByteArrayList() << "VK_LAYER_LUNARG_standard_validation");
#else // see Android-specifics at https://developer.android.com/ndk/guides/graphics/validation-layer.html
                       << "VK_LAYER_GOOGLE_threading"
                       << "VK_LAYER_LUNARG_parameter_validation"
                       << "VK_LAYER_LUNARG_object_tracker"
                       << "VK_LAYER_LUNARG_core_validation"
                       << "VK_LAYER_LUNARG_image"
                       << "VK_LAYER_LUNARG_swapchain"
                       << "VK_LAYER_GOOGLE_unique_objects");

    if (!inst.create())
        qFatal("Failed to create Vulkan instance: %d", inst.errorCode());

    MyVulkanWindow w;
    w.resize(1024, 768);

    return app.exec();

In most cases there will be a single QVulkanInstance. This can live on the stack, but has to be ready before creating the QWindow or QVulkanWindow-derived window objects since they will need to be associated with a QVulkanInstance. (more on this and other window-related topics in part 3)

The logging category qt.vulkan can be very helpful for troubleshooting. When enabled, both QVulkanInstance and, if used, QVulkanWindow will print a number of interesting things on the debug output, during initialization in particular. The hard-coded setFilerRules() call in the code snippet above is not necessarily the best approach always, but works well for platforms where environment variables (QT_LOGGING_RULES) are problematic. On Windows and Linux it is better to control this via the environment or configuration files.

When it comes to output from Vulkan and, first and foremost, the validation layers, QVulkanInstance offers the convenience of automatically redirecting these messages to qDebug. By default VK_EXT_debug_report gets enabled and redirection is active. If this is not desired, set the corresponding flag before calling create().

For example, the output from the hellovulkancubes example running on an NVIDIA Shield TV with Android 7.0 will look something like the following. If there were validation errors, they would show up too in a similar manner.

qt.vulkan: Supported Vulkan instance layers: QVector()
qt.vulkan: Supported Vulkan instance extensions: QVector(QVulkanExtension("VK_KHR_surface" 25), QVulkanExtension("VK_KHR_android_surface" 6), QVulkanExtension("VK_EXT_debug_report" 2))
qt.vulkan: Enabling Vulkan instance layers: ()
qt.vulkan: Enabling Vulkan instance extensions: ("VK_EXT_debug_report", "VK_KHR_surface", "VK_KHR_android_surface")
qt.vulkan: QVulkanWindow init
qt.vulkan: 1 physical devices
qt.vulkan: Physical device [0]: name 'NVIDIA Tegra X1' version 361.0.0
qt.vulkan: Using physical device [0]
Supported sample counts: QVector(1, 2, 4, 8)
Requesting 4x MSAA
qt.vulkan: queue family 0: flags=0xf count=16 supportsPresent=1
qt.vulkan: Using queue families: graphics = 0 present = 0
qt.vulkan: Supported device extensions: QVector(QVulkanExtension("VK_KHR_swapchain" 68), QVulkanExtension("VK_KHR_sampler_mirror_clamp_to_edge" 1), QVulkanExtension("VK_NV_dedicated_allocation" 1), QVulkanExtension("VK_NV_glsl_shader" 1))
qt.vulkan: Enabling device extensions: QVector(VK_KHR_swapchain)
qt.vulkan: memtype 0: flags=0x1
qt.vulkan: memtype 1: flags=0x1
qt.vulkan: memtype 2: flags=0x7
qt.vulkan: memtype 3: flags=0xb
qt.vulkan: Picked memtype 2 for host visible memory
qt.vulkan: Picked memtype 0 for device local memory
qt.vulkan: Color format: 37 Depth-stencil format: 129
Renderer init
qt.vulkan: Creating new swap chain of 2 buffers, size 1920x1080
qt.vulkan: Actual swap chain buffer count: 2 (supportsReadback=1)
qt.vulkan: Allocating 33423360 bytes for transient image (memtype 0)
qt.vulkan: Allocating 66846720 bytes for transient image (memtype 0)

Working with External Graphics Engines

Our final topic for this part is the question of integrating with existing, external engines.

During the lifetime of the Qt 5.x series, there has been a growing focus on making Qt Quick and the underlying OpenGL enablers more interoperable with foreign engines. This led to productizing QQuickRenderControl, the enhancements to QOpenGLContext for adopting existing native contexts, and similar improvements all over the stack.

In the same spirit QVulkanInstance allows adopting an existing VkInstance. All this takes is calling setVkInstance() before create(). This way every aspect of the VkInstance creation is up to the application or some other framework, and QVulkanInstance will merely wrap the provided VkInstance object instead of constructing a new one from scratch.

That’s all for now, stay tuned for part 3!

The post Vulkan Support in Qt 5.10 – Part 2 appeared first on Qt Blog.

There is a saying that persistence is the key to success. Not that I’m always following this advice, but I did luckily earlier this year when I had to decide if I wanted to apply again for a Google Summer of Code (GSoC) spot after my application in the last year was rejected by my organisation of choice back then. I talked about it in one of my last posts. Anyway, thanks to being persistent this year one of my project ideas got accepted and I now have the opportunity to work on a very interesting project concerning Xwayland, this time for the X.Org Foundation.

The project is kind of difficult though. At least it feels this way to me right now, after I’ve already spent quite some time on digging into it and getting a feel for it.

The main reason for the difficulty is, that various components of the XServer are in play and documentation for them is most often missing. Would I be on my own, I could basically only work with the code and try to comprehend the steps done one after the other. I’m not on my own though! With Daniel Stone I have one of the core developers of several key parts of the Linux graphic stack as my mentor, who seems to really want to help me to understand the difficult stuff on a large scale and still gives concrete advice on what to do next. He even drew a diagram for me!

I plan on publishing in future blog posts resources like this otherwise clearly underused diagram, since such material to understand the XServer code is otherwise only sparsely to find on the web. Additionally I’ll try to explain the idea of my project and the general structure of the code I’m dealing with in my own words. Regarding these future posts a nasty surprise for me was this week, that it’s expected from me to publish one blog post per week about my project. This somewhat spoils my plans for this blog, where I wanted to publish very few but in comparison more sophisticated posts. Nevertheless you can therefore expect to have frequent weekly posts until August. Next week I want to explain the basic idea of my project.

Besides Personal Information Mangement (PIM, which Christian Mollekopf will blog about soon) the big slogan for the Randa Meetings this year will be: Make KDE more accessible.

Accessibility is the big topic. But what does accessibility mean regarding KDE and what else do we want to make more accessible?

Per definition accessibility “refers to the design of products, devices, services, or environments for people who experience disabilities.” So our plan is to improve our software regarding keyboard usage (shortcuts, focus handling etc.), keyboard input in general, speech input and output and offering design, themes and user interfaces with different contrast levels and easy ways to change fonts.

Randa Meetings Konqi with Matterhorn and Edelweiss

But to fix problems in the code regarding these things we first need to know about them and what to look out for. So if you are a user of our software and see problems we need you as well. People who know the problems, use computers and can tell us what to fix are welcome too. Plus of course people who write and improve documentation with respect to keyboard handling etc. And if you know of other free software projects that should be in Randa: please poke them and/or us.

So what about other ways to make our software more accessible? Porting and integrating our software to new platforms is another way of helping. Or checking that different fonts and writing system different from the latin alphabet used in standard English are supported. Topics like right-to-left text display and input are a good fit for our topic this year as well, as are alternative input methods, like touch input (for kids or people who can’t read, type or write or just for convenience).

Oh and let’s not forget the different distribution channels that offer access to our software: GNU/Linux distributions, app stores, package formats, packaging efforts in general and even continuous integration.

There is so much work to be done and many possibilities for improvement. If you can, would and want to work on some of these topics, don’t hesitate to go to the KDE Events page and register yourself for the Randa Meetings this year. We would love to welcome you from Saturday, 10th to Sunday, 16th of September this year in Randa, Switzerland.
And don’t hesitate to contact us if there are any open questions or suggestions.
We’re reachable via IRC (in #randa on freenode.net) or via email (randa At KDE org).

Let’s make KDE more accessible together and bring your awesome KDE projects to more people!

Flattr this!

June 15, 2017

It is available at the usual place https://community.kde.org/Schedules/Applications/17.08_Release_Schedule

Dependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!

KDE Akademy 2017Akademy 2017

Yes, I fear I have let my blog go a bit defunct. I have been very busy with a bit of a life re-invented after separation from my 18 year marriage. But all is now well in
the land of Scarlett Gately Clark. I have now settled into my new life in beautiful Payson, AZ. I landed my dream job with Blue Systems, and recently moved to team Neon, where I will be back
at what I am good at, debian style packaging! I also will be working on Plasma Mobile! Exciting times. I will be attending Akademy, though out of my own pocket as I was unable to
procure funding. ( I did not ask KDE E.V due to my failure to assist with KDE CI ) I don’t know what happened with CI, I turned around and it was all done. At least it got done, thanks Ben.
I do plan to assist in the future with CI tickets and the like, as soon as the documentation is done!
Harald and I will be hosting a Snappy BoF at Akademy, hope to see you there!

If you find any of my work useful, please consider a donation or become a patreon!
I have 500USD a month in student loans that are killing me. I also need funding for Sprints and
Akademy. Thank you for any assistance you can provide!
Patreon for Scarlett Clark (me)

It’s still early days, and we have to say this up-front: these builds are not ready for daily work. We mean it, you might luck out, but you might also seriously lose work. Please test, and please report issues on bugs.kde.org! (But check whether your issue has already been reported…) That said…

Here are the first builds of Krita 4.0 pre-alpha!

This is as big, if not bigger a step than it was going from Krita 2.9 to Krita 3.0. No, we haven’t ported Krita to Qt6 (phew!), but we have replaced the entire vector layer system: instead of using the Open Document Graphics standard, Krita now uses the SVG standard to store vector information. This makes Krita more compatible with other applications, like inkscape. Krita can still load existing Krita documents with ODG vector layers, but will only save SVG vector layers. Once a file has been saved with Krita 4.0 pre-alpha, Krita 3.x cannot open vector layers in that file any more.

We have also rewritten a lot of the interaction with vector objects, to make working with vector layers easier and more productive, and we’d like your feedback on that as well.

And of course, this isn’t the only big change.

There is a complete new airbrush system, developed by Allen Marshall, that replaces the existing airbrush system. This will affect brush presets that use the airbrush option, but the new system is so much better that there was no reason to keep the old system in parallel.

Eugene Ingerman has added a healing brush tool. Just select the sticky plaster icon in the toolbox, and paint over the area you want to be patched out!

There is a new system for saving images that should be much safer than the old one, and that warns you when saving to a format that will lose you data.

There’s a much improved palette docker, by Wolthera van Hövell tot Westerflier, that allows you to organize a palette in groups of colors, and reorganize the palettes using drag and drop, and edit swatches by double-clicking.

There’s a new docker that makes it possible to load SVG symbols and drag and drop them as shapes onto the image. Handy for speech bubbles, and we’ve included David Revoy’s Pepper and Carrot speech bubble library to get you started!

And there’s much more ready for you to explore and experiment with!

We’re still working on the new text tool. We got the basics working only last week, but that isn’t in these development builds yet. It’s too rough for even that!

The Python plugin has been merged, and is ready for testing, but here we’ve run into another problem: we haven’t been able to figure out yet how to bundle Python and the Python modules for scripting Krita yet. It works fine when building Krita from source on supported Linux systems. We haven’t managed to build it on Windows or on OSX yet, at all. If you can help us with that, please contact us!

The Scripter — ad-hoc scripting in Krita, created by Eliakin Costa.



Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

For development builds, we only create 64 bits windows portable zip files, Linux appimages and OSX disk images.



Source code


For all downloads:


The Linux appimage and the source tarball are signed. You can retrieve the public key over https here: 0x58b9596c722ea3bd.asc. The signatures are here.

Support Krita

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

This is my report for the last month. This month was quite difficult, I took exams at the university, so I did not do as much as I wanted. For this month I did: Collecting system information At now a can to collect information about cpu, video card, qt version,...

Hello. Recently, within the framework of my project, the following was done: Collection and sending of basic information about the user’s system Accept and write it to the database on the server Frontend for visualization of this information(prototype) How do I store this information? It was decided that using sql...

June 14, 2017

Very happy to share, while writing this blog is that next month I will be attending Akademy 2017, the yearly KDE Community summit that is held since 2003 and which this year will take place in Almería, Spain from July 22th until July 27th 2017.

I am very grateful to KDE for providing me this wonderful opportunity to meet and connect with awesome people from the KDE community.Moreover, KDE has also provide me financial help by accepting my travel request so that I can travel to spain without any financial problem.

I am planning to schedule my travel from 21 july 2017 to 27 july 2017.Another good part of this event is that KDE has also provided me the opportunity to give a short talk(10 min) about my experience with open source world and how I am contributing to the community. So, I will give a short talk titled “Getting started with GCompris” which will highlight, how and when I started contributing to “GCompris” a awesome FOSS project under KDE.

So, at last I am once again very grateful to the KDE community for providing me this wonderful opportunity.
See you in Almeria !!

CMlyst is a Web Content Management System built using Cutelyst, it was initially inspired by WordPress and then Ghost. So it’s a mixture of both.

Two years ago I did it’s first release, and since them I’ve been slowly improving it, it’s been on production for that long providing www.cutelyst.org web site/blog. The 0.2.0 release was a silent one which marks the transition from QSettings storage to sqlite.

Storing content on QSettings is at first quite interesting since it’s easy to use but it showed not suitable very fast, first it kept leaving .lock files, then it’s not very fast to access so I had used a cache with all data, and a notifier updated that when something changed on the directory, but this also didn’t properly triggered QFileSystemWatcher so once a new page was out the cache wasn’t properly updated.

Once it was ported to sqlite, I decided to study how Ghost worked, this was mainly due many Qt/KDE developer switching to it. Ghost is quite simplistic, so it was very easy to try to provide something quite compatible with it, porting a Ghost theme to CMlyst requires very little changes due it’s syntax being close to Grantlee/Django.

Due porting to sqlite it also became clear that an export/import tool was needed, so you can now import/export it in JSON format, pretty close to Ghost, actually you can even import all you Ghost pages with it, but the opposite won’t work, and that’s because we store pages as HTML not Markdown, my feeling about markdown is that it is simple to use, convenient to geeks but it’s yet another thing to teach users which can simply use a WYSIWYG editor.

Security wise you need to be sure that both Markdown and HTML are safe, and CMlyst doesn’t do this, so if you put it on production be sure that only users that know what they are doing use it, you can even break the layout with a not closed tag.

But don’t worry, I’m working on a fix for this, html-qt is a WHATWG HTML5 specification parser, mostly complete, but the part to have a DOM, is not done yet, with it, I can make sure the HTML won’t break layout and remove unsafe tags.

Feature wise, CMlyst has 80% of Ghost features, if you like it please help add missing features to Admin page.

Some cool numbers

Comparing CMlyst to Ghost can be trick, but it’s interesting to see the numbers.

Memory usage:

  • CMlyst uses ~5MB
  • Ghost uses ~120MB

Requests per second (using the same page content)

  • CMlyst 3500/rps (production mode), 1108/rps (developer mode)
  • Ghost 100/rps (production mode)

While the RPS number is very different, on production you can use NGINX cache which would make the slow Ghost RPS not a problem, but that comes to a price of more storage and RAM usage, if you run on an AWS micro instance with 1GB of RAM this means you can have a lot less instances running at the same time, some simple math shows you could have 200 CMlyst instaces vs 8 of Ghost.

Try it!


Sadly it’s also liked soon I’ll be forking Grantlee, the lack of maintenance just hit me yesterday (when I was going to release this), Qt 5.7+ has changed QDateTime::toString() to include TZ data which broke Grantlee date filter which isn’t expecting that, so I had to do a weird workaround marking date as local to avoid the extra information.

The KDE Frameworks have been available in FreeBSD for a while now, but we haven’t seen much movement on the desktop environment or the applications front. KDE4 is still the latest you can get from ports. The plasma5/ branch in the KDE FreeBSD ports repository contains all the applications, and KDE Plasma 5 Desktop, and is very up-to-date with KDE releases — but it’s not in official ports, and that makes it a little more difficult than it needs to be to install the latest KDE  Software on FreeBSD.

The KDE-FreeBSD team is starting to migrate individual applications to recently-released KF5 versions. That sometimes means letting go of some features: Plasma 5 integration isn’t going to happen until we have Plasma 5 in the official ports tree. But KDevelop 5.1 is a valuable upgrade over 4.7, and the IDE suffers very little (except if you wanted the embedded konsole part).

Here’s a screenshot of my KDE4 desktop running on FreeBSD, with the first few KF5 applications alongside.

Those are Krita and Kexi and Calligra Words an KDevelop from KDE Applications 17.04.2, and a KDE4-based JuK.  I haven’t tested this much: they run, and I can type words into the windows and KDevelop can compile something. Krita is out of my league.

So for applications, we’re coming close to a situation where they can be updated to recent releases without breaking everything at once (except for a fistful of “core” applications — we might  keep a konsole-kde4 and a kate-kde4 if there’s both interest and effort put into maintaining them).

For users of the official FreeBSD ports, expect updates to trickle out for a little while yet, while we sort out things like UPDATING and finally decide on what-goes-where in the shiny new (um, I guess we still need a new branding package) KF5-based world.

June 13, 2017

Week 2 was just about minor changes

  • Change the delegate for the AlbumView
    • A better delegate FocusScope which is composed of Image and Kirigami’s BasicListItem for showing label.
  • Changes type of previouslySelectedAction from string to Kirigami.Action.
    • No use of findAction function now
  • Made sidebar actions look selected when the corresponding view is loaded
  • Removes handleVisible property for the GlobalDrawer
    • T6292
    • Handle property is something that should be dependent on the default style used by the environment
  • Implementation of ImageViewer has started

June 12, 2017

We have released version 2.8.0 of our Qt application introspection tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime.

A big focus in this release is improvements to the Qt Quick inspector, which gained layout helper grids and Qt Quick Controls 2 tracing, as well as initial support for the software renderer. We have also optimized the performance of the remote view, which previously managed to saturate a …

The post GammaRay 2.8.0 Release appeared first on KDAB.

For software that uses CMake as (meta) buildsystem, and then gets packaged by distro’s — at least on FreeBSD — there’s something weird going on: the meta-buildsystem knows exactly what files are generated and where they get installed, but then knowledge about those files gets re-created outside of the meta-buildsystem in the ports tree, and that re-created information is used to do the actual packaging. To me, it feels like a duplication of effort, since CPack can be used to (re)use the information straight from the meta-buildsystem.

Back in february I blogged about starting on a CPack generator for FreeBSD packages.

Since then, with some comments and hints from Baptiste Daroussin (FreeBSD pkg(8) maintainer) on the FreeBSD side, and a really slick and constructive review process on Kitware’s gitlab, mostly by Brad King, the FreeBSD generator is being upstreamed, and it may be in CMake 3.10, as near as I can tell. There is still some wrestling to be done because there are multiple sources of libpkg.

This isn’t directly intended to break into the FreeBSD ports system — if only because there’s various staging and QA steps in a ports build that CMake just doesn’t know about. But it does produce packages that can be directly installed. That’s a big help for stuff not-yet-in-ports but which might be distributed and tested already. That, in turn, is something I need for some of my other (non-KDE) projects which are inching towards release and could be subsequently packaged but need testing now.

Anyway, big thanks to the constructive reviewers, and y’all can probably look forward to new package generators in CMake 3.10.

One of the new things CMake is picking up — entirely independently — in 3.9 is a new parameter to the project() command. You can check out CMake 3.9-RC2 now. The project() command now has an optional parameter DESCRIPTION, where you can put the human-readable project description. The FreeBSD package generator will use that description if it is given (although the Debian project description takes precedence, and there’s a CPACK_FREEBSD_PACKAGE_DESCRIPTION if you need to set a FreeBSD-specific description which takes precedence over all).

This new parameter is an opportunity for other CPack generators, too: there’s a Deb and RPM generator, and it struck me while writing the FreeBSD package generator that there’s quite a bit of packaging information that is invariant under the actual package format: homepage of the upstream project, for instance; possibly the package description; the software license the upstream software is published under. The different Free Software distro package generators don’t share that information (much — the FreeBSD package generator falls back to Debian and RPM settings if the FreeBSD-specific settings are not given).

So I think there’s a longer-term project that could be undertaken: massaging software meta-data in CMake and sharing that between package generators. That doesn’t just make sense for the Free Software OS generators: Wix and NSIS could (re)use the same information, although I don’t know offhand if there’s license information fields in those packages (the Wix and NSIS stuff I’ve done is for propritary software that comes with a separate EULA, and doesn’t use CMake anyway). And while we’re at it, that makes project metadata more accessible: suppose you could end up with something like this:

  DESCRIPTION "Terminal emulator using KDE Frameworks 5, which integrates fully with the Plasma5 desktop."
  LICENSE spdx:gplv3+
  WWW https://konsole.kde.org/

Right now you can find those bits of metadata (usually) in the README and the LICENSE file, possibly in the appinfo file, but I think it would be (even more) useful to have that information available in the (meta) buildsystem. And I think that anything that nudges developers towards better metadata maintainence and use of standard-ish notations is a good thing.

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

Today, I will talk about my work on Krita during this second week of the coding period.


The Color Space plugin represents a functionality that exists inside Krita. You can change the color space to a document how is showed below.


The main difference between the plugin and the current implementation is that we can take a list of the currently opened documents. That shows how is easy replace old features with the Scripting API.


GUI Mockup

The first part of my work was figuring out how to implement a similar interface, but with the list of currently opened documents in the Krita. I drew a simple mockup to define some direction for my implementation.


C++ and SIP implementation

I did know that the Krita classes inside libkis don't have a colorModels and colorDepths methods to show these properties in the GUI. I implemented these two methods and your respective SIP signatures. I also wrote documentation to each method implemented in .h files.


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 set all color spaces to the selected documents.



Below, you can see a rendered image before and after the application of the Gray color space.

Before After

What will I do in the next week?

  • Plugin to Change canvas size for multiple documents
  • Plugin to Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list).

  • Upload to Task thread of simple scripts for all the previous plugins

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

June 10, 2017

So the week 1 comes to an end. The week was not normal as all weeks. It took off good but then had something really bad instore for me. Yes, something really bad. So no more of a suspense, the bad thing was my laptop which was working fine in the sunny morning was not turning on in the afternoon. You heard it right, I lost my laptop amidst the first week :( I took it for repair and it was expected to return in 3-4 days.

I had to find a workaround. I then thought of setting up GCompris in my college. I worked, made patches everyday and sent them to my mentors to commit them for me. Thankfully they were really supportive and helped me during that phase. As a result of which I accomplished my work for the first week:

  1. I implemented the basic layout for the activity which involves setting up the score item, the oware board etc.
    Basic Layout
  2. I made a generic component for the tutorial for an activity which looks like: Tutorial

A few lines of code are required to get the tutorial section now.

Tutorial {
    id: tutorialSection
    tutorialDetals: Activity.tutorialInstructions
    onSkipPressed: {

where the tutorialInstructions contains the instructions and images for each instruction for the respective activity.

My plan for the next week is to implement the two player mode for oware. Luckily my laptop has also returned now and I am back to work on it now. You can find the code at GSoC_oware More about the two players mode in the upcoming week :)

Week 1 of the GSoC coding period was a hell of a ride :D. Was really engaged in many things. Even had a camp to attend. But thankfully, my mentors was so supportive that it wasn’t an issue.

Hence, I started working on the Project and it’s proceeding really fast after reading and getting familiar with the codebase of Krita and KNSCore as well as KNewStuff.

During this first week, I have created a widget class named DlgContentDownloader, which will act as the interface between, the dialog and the user. This class will have the following functions.

  1. Download/Install the specific content.
  2. Remove/Uninstall the specific content.
  3. List View Mode
  4. Icon View Mode
  5. Search functionality
  6. Provision for rating.
  7. Selection method for the categories/bundle.
  8. Order by function.
  9. Shows number of downloads/download Count

Classes and functions for different functions have been written down and almost complete.

  1. entrydetailsdialog: Gets all the entries in the server which could be downloaded or manipulated.
  2. itemsgridviewdelegate: For the grid view of items.
  3. itemsviewbasedelegate: Acts as the base class for all the delegates.
  4. itemsviewdelegate: Gets the list of widgets or the items.
  5. widgetquestionlistener: It allows the framework to ask the question to the user in a widget based level.

These works are almost complete and need to tweak a little bit as well.

Plans for Week #2

Well, for Week 2, I have to completely finish the DlgContentDownloader and all its functions. Then will start working on the following:

  • Start creating the GUI/UI for sharing resource bundles.

After the UI for the ContentDownloader widget is done. We will move on to create the download dialog which would help us to download/Install or Remove/Uninstall all the entries.

Will create some class named ContentDownloadDialog, which will act as a centralized method to get the items required to be downloaded using the content downloader widget. After the dialog is done we could tweak the WdgDlgBundleManager and call this dialog to perform the required task. The implementation of the dialog in WdgDlgBundleManager to get the entries would look like this:

        ContentDownloadDialog dialog(d->knsrcFile, this);

        foreach (const KNS3::Entry& e, dialog. ()) {

            foreach(const QString &file, e.installedFiles()) {
                QFileInfo fi(file);
                d->model->resourceServerAdapter()->importResourceFile( fi.absolutePath()+'/'+fi.fileName() , false );

            foreach(const QString &file, e.uninstalledFiles()) {
                QFileInfo fi(file);

If possible, then by the end of the second week, I should be able to create a delegate item to view the resources inside the bundle and the details of the bundle, similar to this mockup we have designed.

Untitled drawing (3)

Will come up with the status of the work next week and will be committing the work done this week soon.

Cheers. ��

Well, it's time for some updates. =D As you know we are working on the development of a Printer Host inside KDE Community called Atelier. AtCore So far, so good. =D haha We are working on the final adjust and getting feedback of KDE-Core-Devel team to move our application from Playground to Extragear so we [...]

June 09, 2017

In my last weeks blog post, I mentioned about implementation of the basic structure of the levels. The progress are listed as follows:

  • The activity consists of 10 levels as of now
  • The dynamic components of the levels are added, namely: the submarine, the upper and lower gates, ship, whale, rocks and the crown along with the animations for the objects that require them
  • Tutorials for the initial three levels
  • Started out with basic movements of the submarine

Here is a screenshot of a level from the activity:


The thing that is not yet implemented:

  • The UI of the controls itself. As of now, the control bar of the submarine is fixed at the bottom of the screen. As a result of this, it hides gets hidden by the bar, which is disabled on start for avoiding the same reasons. I am planning to change the overall controls of the submarine compared to the gtk+ version, but as of now haven’t decided which way to go. I will start improving it once I get an idea on handling the controls which will solve the above problem along with making the controls much more intuitive

For this week, I will be working on the following:

  • Player movement using engines, rudders and ballast tanks [IN PROGRESS]
  • Collision detection: collision of the submarine with the ships, gates, whale, crown and the rocks [IN PROGRESS]
  • crown pickup mechanism: detect pickup of the crown and open the gate likewise
  • “level failed” conditions: in case of any collisions or when the time is up (gate closes in such cases)

In later blog posts, I will be discussing the implementation of the movement and collision using Box2D and the codebase of the activity in general.

Well, that’s it for now! If you wish to have a look at the codebase or follow it up, it is in the gsoc_rudra_submarine branch of gcompris. A mirror of the repository is also available on Github (link for the gsoc_rudra_submarine branch on Github).

We held off on Qt 5.8 because of problems with the Wayland support between it and KWin.  Qt 5.9 seems a little more promising but we don’t want to change something so fundamental to KDE’s software without checking for issues so it’s still in the hidden testing repo for now. Try it out on KDE neon Developer Unstable edition to see what breaks.

deb http://archive.neon.kde.org/testing xenial main

If you’re brave check it out for problems. (The packages even seen to work on the other editions of KDE neon but you are on your own there because it upgrades KWin and other parts to non-stable builds.)

Please do test out a Wayland session with it too (log out and select from bottom left of screen).  And review the Plasma Wayland bugs list.

Let us know how you get on using this blog, or neon mailing list or bugs.kde.org or forums.kde.org as appropriate.


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.