Subscribe to Planet KDE feed
Planet KDE -
Updated: 27 min 32 sec ago

KDE neon Korean Developer Edition (... and future CJK Edition?)

3 hours 46 min ago
KDE Project:

While not being advertised on the KDE neon main page just yet (and it won't be for a while), we've recently begun doing regular builds of a special Korean Edition of neon's Developer Edition tracking the stable branch of KDE's code repositories. The Korean Edition pre-selects the Korean language and locale at boot, packs all the Korean translations we have and comes with a Korean input method pre-setup.

Hangeul metal type from the Joseon era
Joseon-era Hangeul metal type

Why a Korean Edition?

Among many other locations around the planet, the local community in Korea is planning to put on a KDE 20th Anniversary birthday party in Seoul on October 14th. The KDE neon Korean Developer Edition was directly created on request for this event, to be made available to attendees.

That said - this is actually something we've been wanting to do for a while, and it's not just about Korean.

None of the bits that make up the new image are new per-se; KDE has supported Korean for a long time, both with foundational localization engineering and regular maintenance activity. And as of the Plasma 5.6 release, our Input Method Panel is finally bundled with the core desktop code and gets automatically added to the panel on first logon in a locale that typically requires an input method.

Yet it's pretty hard to keep all of this working well, as it requires tight integration and testing across an entire stack, with some parts of the whole living upstream or downstream of For example: After we attempted to make the Plasma panel smarter by making it auto-add the Input Method Panel depending on locale, we couldn't actually be sure it was working as desired by our users, as it takes time for distros to get around to tuning their dependency profiles and for feedback from their users to loop back up to us. It's a very long cycle, with too many opportunities to lose focus or domain knowledge to turnover along the way.

This is where KDE neon comes in: As a fully-integrated product, we can now prove out and demo the intended distro experience there. We can make sure thing stay in working order, even before additional work hits our other distro partners.

Right now, we're kicking things off with Korean Edition, but based on time, interest and testers (please get in touch!), we'd like to build it out into a full CJK Edition, with translations and input support for our Chinese and Japanese users pre-installed as well (as another precursor to this, the decision to switch to Noto Sans CJK as Plasma's default typeface last year was very much made with the global audience in mind as well).

Ok, but where do I get it?

Here! Do keep in mind it's alpha. ☺

Kirigami 1.1

4 hours 21 min ago

Today the first feature update of Kirigami has been released.
We have a lot of bug fixes and some cool new features:

The Menu class features some changes and fixes which give greater control over the action triggered by submenus and leaf nodes in the menu tree. Submenus now know which entry is their parent, and allow the submenu’s view to be reset when the application needs it to.
The OverlaySheet now allows to embed ListView and GridView instances in it as well.
The Drawer width now is standardized so all applications look coherent from one another and the title now elides if it doesn’t fit. We also introduced the GlobalDrawer.bannerClicked signal to let applications react to banner interaction.
SwipeListItem has been polished to make sure its contents can fit to the space they have and we introduced the Separator component.
Desktop Kirigami applications support the “quit” shortcut (such as Ctrl+Q) now.

Plasma 5.8 will depend from Kirigami 1.1, so if you are planning to write a Kirigami-based application, it will work by default and nicely integrate in the Plasma 5.8 desktop.

Plasma 5.8 also has a new big user for Kirigami 1.1, that is Discover: the application to search and install for new software, has a brand new user interface, based upon Kirigami.


This is problably the last feature release based upon QtQuickControls 1, QtQuickControls 2 version is on the way at an experimental stage. The port will have way simpler code (and smaller memory footprint) but this is an entry for another day ๐Ÿ™‚

Adding API dox generation to the build by CMake macros

11 hours 40 min ago

Online documentations of APIs are a fine thing: by their urls they provide some shared universal location to refer to and often also are kept up-to-date to latest improvements. And they serve as index trap for search engine robots, so more people have the chance to find out about some product.

But the world is sometimes not an online heaven:

  • “my internet is gone!”
  • documentation webserver is down
  • documentation webserver is slooo….oo…ow
  • documentation webserver no longer has documentation for that older version

So having also access to offline documentation as alternative can make some developers using your library happy. If you are using Qt in your projects, you yourself might even prefer to study the offline Qt API documentation installed on your local systems, either via the Qt Assistant program or as integrated in IDEs like Qt Creator or KDevelop. Even better, the offline documentation comes together with the library itself (e.g. via packages on Linux or *BSD distributions), so the documentation is always matching the version of the library.

Being a good developer you have already added lots of nice API documentation in your code. Now how to turn this into a separate offline documentation manual for the consumers of your library, without too much effort?
If your project uses CMake for the build system and your target audience is using documentation viewers like Qt Assistant, Qt Creator or KDevelop, read on for a possible solution.

Deploying doxygen & qhelpgenerator

Very possibly you are already using doxygen to generate e.g. an HTML version of the API dox for your library project. And you might know doxygen can output to more formats than HTML. One of them is the format “Qt Compressed Help” (QCH). Which is a single-file format the above mentioned documentation viewers support well. QCH support by doxygen even exists since 2009.

So, with doxygen & qhelpgenerator installed and a respective doxygen config file prepared, the build script of your library just needs to additionally call doxygen as part of another target, and there is the API documentation manual as part of your project build, ready to be deployed and packaged with your library.

A CMake macro for convenience

To not have everyone duplicate the needed build setup code, like checking for the needed tools being installed, and to not have to learn all the details of the doxygen config file, some CMake macro doing the dull work recommends itself to be written and to be distributed for reuse.

Before doing that though, let’s consider another aspect when it comes to documenting libraries: including documentation for code constructs used from external libraries.

Linking between offline API dox manuals

Especially for C++ libraries, where subclassing across classes from different libraries is common, one wants to have direct links into the documentation of external libraries, so the reader has transparent access to any info.

The Qt help system has an abstract addressing system which works independently from the actual location of the QCH files e.g. in the filesystem. These addresses use the scheme qthelp: and a domain namespace for identifying a given manual (e.g. org.qt-project.qtcore). Additionally there is the concept of a virtual folder which is also set as root directory within a manual (e.g. qtcore). So the address of the document for the class QString would be qthelp://org.qt-project.qtcore/qtcore/qstring.html, and the documentation viewer would resolve it to the manuals registered by the matching metadata.

Doxygen supports the creation of such links into external QCH files. For a given manual of an external library, the references are created based on the domain name, the virtual folder name and a so-called tag file for that library. Such a tag file contains all kind of metadata about classes, methods and more that is needed to document imported structures and to create the references.

The QCH files for Qt libraries are coming with such tag files. But what about your own library? What if somebody else should be able to create documentation for their code with links into the documentation of your own library?
Doxygen helps here as well, during the creation of the API dox manual it optionally also creates a respective tag file.

Extending CMake Config files with API dox info

So for generating the references into some external library documentation, the location of its tag file, its name of the domain and its name of the virtual folder need to be known and explicitly added to the doxygen config file. Which is extra work, error-prone due to typos and might miss changes.

But it can be automated. All the information is known to the builder of that external library. And with the builder storing the information in standardized CMake variables with the external library’s CMake config files, it could also be automatically processed into the needed doxygen config entries in the build of your own library.

So a simple find_package(Bar) would bring in all the needed data, and passing Bar as name of the external library should be enough to let the to-be-written CMake macro derive the names of the variables with that data.

So with these theoretic considerations finally some real code as draft:

Patch uploaded for your review and comments

As possible extension of the Extra-CMake-Modules (ECM) the review request proposes 2 macros for making it simple and easy to add to the build of own libraries the generation of API dox manuals with links into external API dox manuals.

The call of the macro for generating the tag and qch files would e.g. be like this:


This would create and install the files ${KDE_INSTALL_FULL_DATADIR}/qch/Foo.qch and ${KDE_INSTALL_FULL_DATADIR}/qch/Foo.tags.

The call for generating the CMake Config file would be:

ecm_generate_package_apidox_file( ${CMAKE_CURRENT_BINARY_DIR}/FooConfigApiDox.cmake NAMES Foo )

This generates the file FooConfigApiDox.cmake, whose content is setting the respective variables with the API dox metadata:

set(Foo_APIDOX_TAGSFILE "/usr/share/docs/Foo.tags") set(Foo_APIDOX_QHP_NAMESPACE "org.kde.Foo") set(Foo_APIDOX_QHP_NAMESPACE_VERSIONED "org.kde.Foo.210") set(Foo_APIDOX_QHP_VIRTUALFOLDER "Foo")

This file would then be included in the FooConfig.cmake file

# ... include("${CMAKE_CURRENT_LIST_DIR}/FooApiDox.cmake") # ...

and installed together in the same directory.

Tightening and extending integration

In the current draft, for defining what source files doxygen should include for generating the API documentation, the macro ecm_generate_qch() takes simply a list of directories via the SOURCE_DIRS argument list, which then together with some wildcard patterns for typical C and C++ files is written to the doxygen config file.
Though being part of the build system, there might be more specific info available what files should be used, e.g. by using the PUBLIC_HEADER property of a library target. Anyone experienced with the usage of that or similar CMake features are invited to propose how to integrate this into the API of the proposed new macro.

Currently there is no standard installation directory for QCH files. So documentation viewers supporting QCH files need to be manually pointed to any new installed QCH file (exception are the QCH files for Qt, whose location can be queried by qmake -query QT_INSTALL_DOCS).
Instead it would be nice those viewers pick up such files automatically. How could that be achieved?

It would be also good if this or some similar API dox metadata system could be upstreamed into CMake itself, so there is a reliable standard for this, helping everyone with the creation of cross-project integrated API manuals. At least the metadata variable naming patterns would need to get wide recognition to get really useful. Anyone interested in pushing this upstream?

For proper documentation of public and non-public API perhaps the doxygen development could also pick up this old thread about missing proper support for marking classes & methods as internal. Or is there meanwhile a good solution for this?

On the product side, what manual formats beside QCH should be supported?
On the tool side, what other API documentation tools should be supported (perhaps something clang-based)?

Comments welcome here or on the phabricator page.

Emoji restyling

Mon, 2016/09/26 - 9:02pm

(really short post)
I started to restyling and try to finish the Emoji.


Hope you like it.

rect18481 rect15697

My Adventures and Misadventures in Qt Quick Land

Mon, 2016/09/26 - 11:58am

I venture into QMLand. I do not survive unscathed. I did not even get a shirt. I learned some lessons instead.

Kdenlive news and packaging

Mon, 2016/09/26 - 7:34am

rollingFollowing our last week’s monthly Café, we decided to concentrate on advanced trimming features and if possible an audio mixer for the next Kdenlive 16.12 release. It was also mentionned that several users requested the comeback of the rotoscoping effect, which was lost in the KF5 port, preventing some users to upgrade their Kdenlive version.

So good news, I worked on it and rotoscoping is now back in git master, will be in the 16.12 release.

On the stability side, we just fixed a packaging issue on our PPA that caused frequent crashes, so if you experienced issues with our PPA, please update to enjoy a stable Kdenlive.

Next Café will be on the 19th of October, at 9pm (Central European Time). See you there!

Jean-Baptiste Mardelle


Sat, 2016/09/24 - 10:00pm

I started a tiny project a couple of days ago: arch-audit.

arch-audit main (and unique) goal is to display the Arch Linux packages that are affected by known vulnerabilities on your system.

To do that, arch-audit parses the CVE page on the Arch wiki, which is maintained by the Arch CVE Monitoring Team.

arch-audit output is very verbose when it’s started without any argument, but two options --quiet (or -q or -qq) and --format (or -f) allows to change the output for your use case. There’s also a third option --upgradable to display only packages that have already been fixed in the Arch Linux repositories.

In my opinion a great use case is the following:

$ ssh openssl>=1.0.2.i-1 lib32-openssl>=1:1.0.2.i-1 Last login: Sat Sep 24 23:13:56 2016 $

In fact, I added a systemd timer that executes arch-audit -uq everyday and saves its output to a temporary file that is configured as banner for SSH. Then, everytime I log into my server, I get notified about packages that have vulnerabilities, but that already have been fixed. Time to do a system update!

So, now I’m waiting your feedbacks! Have fun!

BTW, Lynis already added arch-audit support!

Round two of Atcore Testing

Sat, 2016/09/24 - 12:45pm

It has been about two weeks since I last wrote about AtCore. In that time Tomaz has commited a few changes that allow us to use a plugin system so that AtCore can specialize in speaking your firmware!? Or something like that. Really what It means is that we should be able to keep most all of the common stuff within the AtCore object and use the plugins to give us firmware specific stuff when needed.

Did someone say Test?.

The test is pretty stright foward and that is to evaulate how well AtCore is doing at sending print commands to the printer to do this really we just need to be able to print an object that takes some amout of time.

Late nights printing tiny pyramids

I’ve been awake all night watching this thing print is working as expected. First I had to find a decent model to print and I came across this cool Fractal pyramid

038b2aff02be59222448f0799d856868_preview_featuredModel by ricktu



Mandatory hardware pictures ?

Two computers.. one to record and play host while the other keeps my sanity durring the nights print.It would be along print the slicer estimates the print to take around 5 hours. Ok time for the mandatory hardware pictures of stuff Check out the computer that will be hosting the printer and recording video for later.In this Set up we will have

img_20160924_061356chairs eyeview

Two cameras extruder cam and an overview cam. Sadly my 3rd camera didn’t want to play along it was

img_20160923_193812time for a new floor?

just unable to get a decent focus on the printer LCD so we will have to go without this time.


 Watch the Timelapse video ….7 hours later…..

After 7 hours of printing we have it completed. The Best part i have saved for last when printing



i have used glow in the dark filiament. To quickly charge up the glowing i have placed



the model between the lights of some very bright led lamps. Unfortunately the Camera didn’t do such a great job picking up the detail with the model glowing in the dark



So how did we do?

Well the print was a success! The RAM usage was a bit high for my liking but is most likey due to our text log. We will do further tests to check that. The Firmware Plugin for Repitier seams to be printing stabily for any lenght print I would call that a success!



digiKam 5.2.0 is published...

Sat, 2016/09/24 - 9:17am

Dear digiKam fans and users,

After a second release 5.1.0 published one month ago, the digiKam team is proud to announce the new release 5.2.0 of digiKam Software Collection. This version introduces a new bugs triage and some fixes following new feedback from end-users.

read more

New mobile IMG โ€“ 20160923-134224

Fri, 2016/09/23 - 1:46pm

Today’s weekly mobile IMG update brings,

  • Updated packages
  • New appstream release
  • Kirigami based new discover design

You can flash using instructions at

Plasma 5.7.5, Applications 16.08.1 and Frameworks 5.26.0 by KDE now available in Chakra

Thu, 2016/09/22 - 5:12pm

This announcement is also available in Italian and Taiwanese Mandarin.

The latest updates for KDE's Plasma, Applications and Frameworks series are now available to all Chakra users.

The Plasma 5.7.5 release is the final bugfix update for the 5.7.x series, as 5.8.0 will be released soon. It includes a month's worth of bugfixes and new translations, with notable changes found in the plasma workspace, sddm-kcm and networkmanager packages.

Applications 16.08.1 include more than 45 recorded bugfixes and improvements to kdepim, kate, kdenlive, konsole, marble, kajongg, kopete, umbrello, among others.

Frameworks 5.26.0 include bugfixes and improvements to breeze icons, plasma framework, kio, ktexteditor and sonnet.

Other notable package upgrades:


  • cups 2.1.4
  • git 2.10.0
  • mariadb 10.1.17 providing the security fix of MySQL 0-day "CVE-2016-6662"
  • php 5.6.25
  • poppler 0.47.0 - this breaks backward compatibility, if you have any local/CCR packages depending on it you will have to recompile them

  • pdf2svg 0.2.3

  • wine 1.9.19

  • amule 10958

    It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue in relation to this update, please ask or report it on the related forum section.

    Most of our mirrors take 12-24h to synchronize, after which it should be safe to upgrade. To be sure, please use the mirror status page to check that your mirror synchronized with our main server after this announcement.
  • KDE Timeline translated into Chinese

    Thu, 2016/09/22 - 4:13pm

    Hi everybody,

    After announcing that our timeline was translated into Spanish, now I wanted to announce that it is also available in Chinese. Thanks to Leslie Zhai now we have one version of the timeline in Chinese simplified.


    Screenshot of Chinese version.

    Besides that I did some adjustments as captions centralized, images turned into links, and improvement in the captions texts.

    If you also have any suggestions, translation, or adjustment, let me know.  Our repository can be cloned here. 🙂

    GSettings vs QSettings

    Thu, 2016/09/22 - 4:09pm

    A few weeks ago after discussing with Luke Yelavich about what to work on in speech-dispatcher next I decided to take a stab at making it use GSettings for its settings. (You can see the work in progress here if you like.) I've used GSettings before for work projects so thought it would be a good/easy thing to take on.

    There are many advantages of using GSettings over plain ini-style files.

    • Type checking (You can't enter a string for a numeric setting for example).
    • Notification of setting changes.
    • Command-line changing of settings.
    • Default values for settings defined in the schema(s).

    On that wip branch speech-dispatcher itself has been changed to use GSettings and also reacts to many setting changes dynamically. It doesn't react to changing the port type or port number or unix socket path dynamically, since we have no mechanism to tell client applications that it is changing. There are also GSettings schemas for the output modules, just need to make them read their settings from GSettings instead of the old ini-style .conf files. spd-conf also has been modified to write to GSettings rather than .conf files. That change alone reduced the spd-conf python script by quite a few lines of code and made it a lot easier to read.

    As I was doing this work I got thinking about the differences between GSettings and QSettings. Besides one being glib/c based and the other being Qt/C++ they are really pretty similar. There are a few differences though:
    • QSettings doesn't emit signals when a setting changes. (I found a few forum posts asking why this is with possible workarounds. Nothing built into QSettings though).
    • QSettings doesn't have a schema for the settings themselves. There's no way to introspect a setting file to see what settings are possible. It just depends what keys the application reads.
    • QSettings doesn't have a command-line tool to set the settings. Since QSettings is cross platform it uses the Registry by default on Windows, PList files by default on macOS, and ini-style files on linux
    • QSettings does have type checking, but no range checking or anything like that.

    I was a bit disappointed that QSettings that I've used for many many years is lacking these seemingly obvious and probably useful features. I wonder if we as a community implemented these features in QSettings if the Qt company would accept them.


    Thu, 2016/09/22 - 1:26pm

    toolboxWe’ve added a new Toolbox section that has posts dedicated to new and improved functionality in Kdenlive. Check back regularily for updates.

    Qt Conference Apps โ€“ out of the Developer Trenches โ€“ Part 1

    Thu, 2016/09/22 - 11:45am

    In a few weeks the Qt World Summit 2016 will open its doors in San Francisco and I have been given the chance to speak there about my experiences while developing the Qt World Summit 2016 Conference App. This article series here will give you some additional information to my presentation.

    For nearly 40 years I have been developing software, where the last 8 years I have focused on mobile App Development. I started mobile App Development with BlackBerry OS7 (Java) followed by BlackBerry 10 native Apps (Qt 4.8, Cascades UI Controls).

    In 2016 BlackBerry, for first time ever, started to build secure Android Phones and my customers asked for x-platform Apps. Personally, I liked the way BlackBerry 10 Apps were built using QML and Cascades. Fortunately Qt just started Qt 5.6 Tech Preview of new Qt Quick Controls 2. I did some first tests to see if Qt Quick Controls 2 will enable me to develop good looking and performant mobile Apps.

    First steps went well so I decided to spend some more time and to give Qt 5.7 and Qt Quick Controls 2 a try in real-life projects. Over the last 4 years I built many mobile business Apps for Enterprise and SMB and I also did some Apps for Developer Conferences.

    I asked Tero Kojo to develop the QtCon 2016 Conference App as a proof-of-concept to rely on new Qt Quick Controls 2. You can download the QtCon Conference App from Google Play (, Apple App Store (, Amazon App Store (, as APK ( or build it by yourself from Open Source Github Repo (

    The App was built without any extra native Code – pure Qt only. Feedback was great and I just started to do the Qt World Summit 2016 Conference App – Github Repo will be public soon. Hopefully this time the App will also be available for Windows 10 from Windows App Store. Special thanks to Maurice Kalinowski for his help, the QtCon Conference App is running on Windows 10, although I had some problems uploading this to Windows App Store.

    There is a blog series about all my experiences using Qt Quick Controls 2 to develop mobile Apps (, also a series in (German) Web & Mobile Developer Magazin and now some articles here at Qt Blog, too. You can expect some 3 – 4 articles here at Qt Blog about developing Qt Conference Apps.

    All development is done in my spare time and my goal is to motivate mobile App Developers to try out Qt Quick Controls 2 to develop x-platform Apps. I never did Qt development before, also never did native Apps for Android, iOS or Windows but now I am able to develop and upload Apps to Google Play or Apple App Store :) I am also using Google Material Style to provide a modern mobile App feeling. Thanks to J-P Nurmi, Mitch Curtis and others for great hints HowTo customize Qt Quick Controls 2.

    From my experiences over the last 6 months, developing mobile Apps with Qt 5.7 and Qt Quick Controls 2 is much more comfortable and easier than using Xamarin, React Native, Cordova, Angular or Ionic. The good news for all my friends from BlackBerry 10 community: there is a great amount of re-use of C++ Code from Cascades and also architecture style is similar using Signals/Slots and QObject* as data model.

    Speed is key to success

    The first impression of any mobile App with regards to User Experience comes from starting the App. The User should never have the feeling that an App is slow. Some of my recipes for a speedy start are below:

    • fast creation of C++ Classes
    • immediately show something on the screen
    • be dynamic: only instantiate UI Controls you really need

    How am I doing this? Only instantiate C++ Classes, avoid any initialization as open Databases, load Cache Files and more.

    DataServer::DataServer(QObject *parent) : QObject(parent) {     // Do NOTHING HERE }

    Use the fastest possible way to show some UI to the User. My root and main Navigation Control is a Drawer. The Drawer contains a list of “Destinations“, where a Destination is a specific area of the Application as

    • Home
    • Schedule
    • Speakers
    • Venue


    Each Destination can be one of the Qt Quick Controls 2 Navigation Controls ( or Container Controls(

    • Pane
    • Page
    • StackView
    • SwipeView / Tab Bar

    Inside the Drawer you can use a ListView to let the User select a Destination – take a look at Qt Quick Controls 2 Gallery Example. I‘m using a Repeater to create different types of Controls: Destinations, Divider, Header, …

    To show the selected Destination best way is to use a StackView as your root UI Control and swap the content – so there‘s always only one Item at this root StackView.


    To startup immediately don‘t create all the Drawer – Destinations ! This can easy be done with a little trick: define the Repeater without a data model.

            Repeater {             id: destinations             // Don‘t set the model here !             // model: navigationModel             Destination {                 id: destinationLoader             }         }

    So nothing will be created now. To show something to the User create a lightweight Control as initialItem. I‘m using a BusyIndicator.

            // STACK VIEW INITIAL ITEM (BUSY INDICATOR)         // immediately activated and pushed on stack as initialItem         Loader {             id: initialPlaceholder             source: "pages/InitialItemPage.qml"             active: true             visible: false             onLoaded: {                 // Show BUSY INDICATOR                 rootPane.initialItem = item                 item.init()                 // Now something is VISIBLE - do the other time-consuming stuff                 startupDelayedTimer.start()             }         }

    The next trick is to start a Timer with a small delay to allow QML to show and animate the BusyIndicator. Then from Timer timeout execute all the initialization stuff and call some Q_INVOKABLE methods from your C++ Classes to load data from Cache and more.

    As soon as this is done you can go on with creation of UI Controls. To trigger this set the Repeater Data Model and all the Destinations will be created and HomePage will become current Item on root StackView.

            Timer {             id: startupDelayedTimer             interval: 300             repeat: false             onTriggered: {                 initialPlaceholder.item.showInfo("Initialize Data ...")                 dataManager.init()                 settings = dataManager.settingsData()                 dataUtil.setSessionFavorites()                 // … and so on ...                 // inject model into Destinations Repeater                 destinations.model = navigationModel                 // show the Navigation Bars (Drawer and Favorites)                 initDone = true                 // now NavigationBars available                 // show first destination                 rootPane.activateDestination(firstActiveDestination)             }         }


    Here we go: first „real“ Page is visible.

    But wait: not all Destinations will really be created from the Repeater – this would take too much time and consume too much memory. All the Destinations are created dynamically using Loaders and I implemented some Activation Policies:

    • Immediate: The Control will be instantiated and remain. I‘m using this only for the first visible Page – the HomePage.
    • When-Selected: First time a User selects a Destination will create the Control and remain. This happens for all Destinations a User normaly will use while the App is running: Schedule, Speakers,…
    • While-Selected: Those Destinations are only created when needed and be destroyed if User changes the Destination. Candidates for this Policy: Help, Settings, About, …

    Take a look at the code how all of this is implemented, attend my Session at Qt World Summit 2016 in San Francisco ( or meet me at #QtWS16.

    Stay tuned – next article will cover the QObject* Data Model I‘m using, Caching and Data Binding.

    The post Qt Conference Apps – out of the Developer Trenches – Part 1 appeared first on Qt Blog.

    Kubuntu beta; please test!

    Thu, 2016/09/22 - 3:32am

    Kubuntu 16.10 beta has been published. It is possible that it will be re-spun, but we have our beta images ready for testing now.

    Please go to, login, click on the CD icon and download the image. I prefer zsync, which I download via the commandline:

    ~$ cd /media/valorie/ISOs (or whereever you store your images)
    ~$ zsync

    The other methods of downloading work as well, including wget or just downloading in your browser.

    I tested usb-creator-kde which has sometimes now worked, but it worked like a champ once the images were downloaded. Simply choose the proper ISO and device to write to, and create the live image.

    Once I figured out how to get my little Dell travel laptop to let me boot from USB (delete key as it is booting; quickly hit f12, legacy boot, then finally I could actually choose to boot from USB). Secure boot and UEFI make this more difficult these days.

    I found no problems in the live session, including logging into wireless, so I went ahead and started firefox, logged into, chose my test, and reported my results. We need more folks to install on various equipment, including VMs.

    When you run into bugs, try to report them via "apport", which means using ubuntu-bug packagename in the commandline. Once apport has logged into launchpad and downloaded the relevant error messages, you can give some details like a short description of the bug, and can get the number. Please report the bug numbers on the qa site in your test report.

    Thanks so much for helping us make Kubuntu friendly and high-quality.

    Plasma Wayland ISO Now Working on VirtualBox/virt-manager

    Wed, 2016/09/21 - 11:33am

    I read that Neon Dev Edition Unstable Branches is moving to Plasma Wayland by default instead of X.  So I thought it a good time to check out this week’s Plasma Wayland ISO. Joy of joys it has gained the ability to work in VirtualBox and virt-manager since last I tried.  It’s full of flickers and Spectacle doesn’t take screenshots but it’s otherwise perfectly functional.  Very exciting ๐Ÿ™‚


    Facebooktwittergoogle_pluslinkedinby feather

    Reminder: Submit your work for the 2016 Krita Artbook!

    Wed, 2016/09/21 - 8:47am

    We’re only one month away from the deadline for submissions for the 2016 Krita Artbook! We’ve already received a lot of great submissions, but you should still submit your work if you want to be part of the very first Krita Art book.

    This book will be sent out to the seventy Kickstarter backers who selected the artbook as their reward, and it will be available from the Krita shop.


    Here’s a short recap of the ruls:

    • A competent jury will judge all submissions and pick the best, since space if going to be limited
    • Use Krita 3.0.1′ new soft-proofing feature together with the Fogra39 CMYK profiles to check your colors. The color pages will be glossy, so use the coated variant.
    • The book will be printed professionally, either hard-cover or soft-cover (that depends on the final page count).
    • The dimensions are 200 x 280 mm.
    • There will be a glossy color page and a black & white page available for every artist.
    • The black & white page contains information about you, whatever you want to tell the world.
    • There will be room for a black & white illustration as well.

    Here’s a mock-up of what we intend:


    If you want to be in on it, send your submission to We need the following:

    • Your color art work at the full resolution: a minimum resolution of 150dpi but our experience is that 300dpi looks better.
    • Keep at least 3mm bleed on the outside of your picture (making the submission size 206×286 mm) and add cutting marks if you know how (if you don’t know how, we do, and will add them).
    • An optional black & white artwork. This needs to be even higher resolution (600dpi) since the black and white pages are printed at a higher resolution.
    • Information about you: a short bio, contact details — whatever you want to tell about yourself, about half a page so there’s room for the B&W artwork. There is no real-names rule: you can call yourself what you want.

    The artwork needs to conform to a few rules:

    • There is no set topic: just show off what you think you do best! But…
    • No gore or pornography. Nudity is fine, flashing swords are fine, people being strangled by their own guts, no.
    • No fan-art or characters copyrighted by others than you.
    • Made using Krita: you can use other tools, too, but Krita has to be used for most of the work.

    The deadline for submissions is November 1st!

    Send your submission to





    Kexi 3 Beta 1 + libs

    Tue, 2016/09/20 - 5:51pm
    KDE Project:

    Cool, Kexi 3.0.0 Beta 1 and related libraries have landed, ready for testing and packaging. Please find downloads and change logs at

    As usual report bug and wishes are welcome, details at

    This time the release got automated a bit more. Changelogs generated with some bash coding can be now easily pasted on the wiki, and mediawiki templates {{bug}}, {{commit}}, {{diff}} work also for your project, on any wiki page. What are your favourite changelog tools? Maybe Phabricator would offer something ultimate like

    Later we would move some content from wiki to semi-static generated pages on So this obsolete page would become more like or

    I know, I know. it's hard to try without examples and tutorials. Stay tuned. For now, API docs sit at at, a temporary location.

    Have fun!

    the case of the one byte packet

    Tue, 2016/09/20 - 9:27am

    Yesterday I pushed a change set for review that fixes an odd corner case for the Guam IMAP proxy/filter tool that was uncovered thanks to the Kolab Now Beta program which allows people to try out new exciting things before we inflict them upon the world at large. So first let me thank those who are using Kolab Now Beta and giving us great and valuable feedback before turning to the details of this neat little bug.

    So the report was that IMAP proxying was breaking with iOS devices. But, and here's the intriguing bit, only when connecting using implicit TLS; connecting to the IMAP server normally and upgrading with STARTTLS worked fine. What gives?

    In IMAP, commands sent to the server are expected to start with a string of characters which becomes the identifying tag for that transaction, usually taking the form of "TAG COMMAND ARGS". The tag can be whatever the client wants, though many clients just use a number that increases monotonically (1, 2, 3, 4, ...). The server will use that tag to prefix the success/failure response in the case of multi-line responses, or tag the response itself in the case of simpler one-line responses. This allows the client to match up the server response with the request and know when the server is indeed finished spewing bytes at it.

    We looked at the network traffic and in that specific case iOS devices fragment the IMAP client call into one packet with the tag and one packet with the command. No other client does this, and even iOS devices do not do this when using the STARTTLS upgrade mechanism. As a small performance hack, I had allowed the assumption that the "TAG COMMAND" part of client messages would never be fragmented on the network. This prevented the need for buffering and other bookkeeping in the application within a specific critical code path. It was an assumption that was indeed not guaranteed, but the world appeared to be friendly and cooperating. After all, what application would send "4" in one network packet, and then "XLIST" in completely separate one? Would it (the application, the socket implementation, ..) not compose this nicely into one little buffer and send it all at once? If so, what network topology would ever fragment a tiny packet of a few dozen bytes into one byte packets? Seemed safe enough, what could go wrong .. oh, those horrible words.

    So thanks to one client in one particular configuration being particularly silly, if technically still within its rights, I had to introduce a bit of buffering when and where necessary. So I took the opportunity to do a little performance enhancement that was on my TODO while I was mucking about in there: tag/command parsing which is necessary and useful for rules to determine whether they care about the current state of the connection, is now both centralized and cached. So instead of happening twice for each incoming fragment of a command (in the common case), it now happens at most once per client command, and that will hold no matter how many rules are added to a ruleset.

    So, one bug squashed, and one little performance enhancement, thanks to user feedback and the Kolab Now Beta program. As soon as the patch gets through code review, it should get pushed through packaging and deployed on Kolab Now Beta. Huzzah.