€ 20000 0.00
Please donate what you can to help make the Randa Meetings 2017 possible. Read more.

September 13, 2017

Public institutions spend millions of Euros every year for the development of new software that is specifically tailored to their needs.

Unfortunately, most of this software is closed source.

This means that your tax money is being used to pay for software that cannot be modified or even studied. Most public institutions pay to develop programs that they do not or cannot release to the public. When other institutions need to solve similar problems, they have to develop the same software again. And each time the public - including you - has to foot the bill.

Paying a company to provide closed software also leads to vendor lock-in. Vendor lock-in is when an institution contracts a certain provider and later discovers it is very hard to switch to another one.

Companies with a stranglehold on an institution can artificially restrict usage and features of their products. They can forbid you to install their programs on more than a handful of computers, disable saving your work in a certain format, or hike the prices of licenses for no reason.

The biggest problem, however, is the safety of your data.

Closed software makes solving flaws especially hard and expensive. Even if you know how to solve its vulnerabilities, you would not be legally allowed to do so. Many branches of our public administration often have to keep running insecure software because they cannot afford to pay for the newer version.

Furthermore, closed source providers often include in their software code that collects data they have no business in collecting. This data can end up in the power of foreign security agencies, sold to unscrupulous advertising companies, or worse.

How can we put our trust in public bodies if they don't have full control over the software they are using?
Shouldn't your money be used to develop software that benefits you and other citizens?

The Free Software Foundation Europe (FSFE) thinks it should - and we at KDE Community agree.

That is why we are supporting the FSFE campaign called Public Money? Public Code!.
The campaign proposes that all software financed with public money should be distributed as Free Software.

Public Money? Public Code! from Free Software Foundation Europe on Vimeo.

Although publishing/sharing publicly funded software under a free licence generates great benefits for governments and civil society, policy makers are still reluctant to move forward with decisive legislation. The purpose of this campaign is to convince them.


With Free Software, independent researchers can report earlier on errors, before even miscreants can use them. Experts from anywhere can provide solutions for applications because they can study the code. They can also audit the software to eliminate backdoors or other malicious code.

By using Free Software, citizens' data is kept safer and the chances of successful attacks from criminals goes down. Free Software can also be used as the foundation for better applications, building upon it to create more efficient and safer programs.

In short, Free Software can help us build a better society for everyone.

Join the Campaign!

More than 30 organizations and individuals have already endorsed the campaign, including Edward Snowden, President of Freedom of the Press Foundation.

You, too, can join the "Public Money? Public Code!" campaign. Sign the open letter that explains to politicians and policy makers why using public money to fund public code is a good idea. FSFE will send it to political representatives several times over the next months.

You can also share the link to the campaign website on social media and online forums. Send it to your friends and coworkers, and encourage them to sign the open letter.

Spread the word about the campaign by writing about it on your website, or by contacting the media in your country.

Show that you care about the future of digital infrastructure, because you will be paying for it one way or another.

This year the Randa KDE meeting it’s all about Accessibility: a big effort has been concentrated around two very intertwined things: keyboard navigation and screen reader support.
(The fundraising campaign is still going on)
As a first taste, in Plasma 5.11 KRunner will be completely accessible (unfortunately until now screen readers didn’t work at all with it), which is important as is a completely keyboard-focused UI to do things, therefore potentially more user friendly towards vision impaired people.
Orca will be able to read out loud what query has been entered and the currently focused entry, that is what will happen if the user presses the Enter key.
Here it is a screencast of KRunner running with Orca navigating trough the list of result entries.

September 12, 2017

KGraphViewer 2.4.0 has been released.

KGraphViewer is a visualiser for Graphviz’s DOT format of graphs.

This ports KGraphViewer to use KDE Frameworks 5 and Qt 5.

It can be used by massif-visualizer to add graphing features.

Download from:

88c2fd6514e49404cfd76cdac8ae910511979768477f77095d2f53dca0f231b4 kgraphviewer-2.4.0.tar.xz

Signed with my PGP key
2D1D 5B05 8835 7787 DE9E E225 EC94 D18F 7F05 997E
Jonathan Riddell <jr@jriddell.org>

Facebooktwittergoogle_pluslinkedinby feather

Marble, KDE's mapping app, will get
better turn-by-turn navigation features.

The last time we wrote about Randa Meetings 2017, preparations for the event were still in progress. The developer sprint is now in full swing. Everyone is settled in and ready to start improving, debugging and adding features to KDE's apps and frameworks. But what exactly will the developers work on during Randa 2017? Here are some more details.

As you're probably already aware, the theme of Randa Meetings 2017 is accessibility. This doesn't include only desktop software, but also extends to mobile apps. Sanjiban Bairagya is working on the Marble Maps Android app, KDE's answer to Google Earth. His accessibility-related tasks include making the turn-by-turn navigation experience more visually intuitive in real-time. He will also be switching Marble to the Qt 5.8 Speech module instead of using Java for text-to-speech support in navigation. Another thing Sanjiban wants to do is find a way to let users add notes to any place on the map.

Bhushan Shah will mostly focus on Plasma in all its shapes and sizes. During Randa 2017, he will work on making Plasma even better and snappier with Wayland, as well as on making PIM apps work better on Plasma Mobile.

Plenty of new things are in store for digiKam. Simon Frei will work on improving the user interface, as well as the way digiKam handles metadata. Gilles Caulier will be busy with digiKam documentation and tools for exporting images to web services.

Dan Vratil will be busy with KDE PIM and Akonadi. He plans to discuss accessibility in Kontact with other KDE PIM developers, and complete the process of porting all PIM code away from KDE4.

You Can Be Part of Randa 2017, Too

digiKam will have several developers working on it all at the
same time.

KDE software is developed every day by people from all around the world. For some of them, Randa Meetings are a unique, rare opportunity to finally meet other KDE developers in person. After many months, or sometimes even years, of communicating exclusively via email and IRC, the developers can sit down and work together on resolving the most pressing issues. Apart from writing code, they also discuss long-term goals and decide on the future of KDE projects.

Even if you're not a developer, you can also participate in Randa Meetings 2017 by donating to our fundraiser. Donations are used to cover accommodation and travel costs, and to make sure the developers are not hungry and thirsty during the sprint. This is your chance to support Free and open source software, and to directly contribute to the KDE Community.

Don't miss out!

[[ Written monday, but I did not get around to posting it then. Since I do not feel like applying a modal time-shift operator to the text, I will publish it on tuesday, even though that introduces some temporal disparities.]]

It is almost 3pm. At three, the presentations from the Randa attendees will start, where each team or individual will present what they want to do for the week, and what they need from other attendees. So I’ll say “Calamares needs to support orca”. Short presentation, but then I’ve not had much time to prepare.

It’s almost 3pm, I’ve been up since 6:45 and have spent half an hour at my laptop. The rest of the day so far has been in the kitchen. Because keeping the meeting running, so that the attendees can do their thing to their full potential, takes a lot of logistics and effort. Let me give an example, based on profession software-engineers who are not professional cooks, doing the logistics.

Breakfast is from 7:30 to 9:00, which means that at 7:02 the kitchen opens. Coffee machine on. Dishwasher on. Tea kettle on. Send a minion to fetch the bread from the bakery. Dispense jam, nutella, peanut butter into bowls. Slice butter. Prepare muesli and yoghurt. Slice bread, together now that the minion has returned. One person runs the cheese / sausage slicer for 15 minutes while the other sets out cutlery, plates, cups, gets milk and orange juice ready. So at 7:30 when the first breakfasters show up, we’ve already put in one person-hour getting it ready. Hang around during breakfast, getting more bread, butter, refilling the coffee machine, slicing more salami. Once the last breakfasters are done (they show up at 8:50 for a quick bite), there’s three loads of dishes to do. The dishwasher is fast — less than two minutes — but everything needs to be put away, and the tables wiped down, and the slicer dismantled and cleaned, and the kitchen cleaned and swept.

So the “human cost” of breakfast is roughly 4, maybe five hours for non-professionals. Granted, there’s some time lost just in finding the way in the kitchen during the first day.

Lunch is a hot meal at 13:00 sharp, so preparations start at 11:00. Collecting today’s ingredients. Starting the stove and the oven. Starting 6l of water to boil for the rice, and another 6l of water for other parts of the meal. Cracking 15 eggs and whisking them. Cleaning, rinsing, and chopping 6kg of vegetables. Starting two pans of peanut sauce. Making a giant omelette. Waiting for 2kg of rice to cook. Shuffling six pans across five giant electric hobs. Setting out the chafing dishes, cutlery, plates, places again. Filling all the water pitchers. Checking the coffee machine. We — Grace, Scarlett, and I — had everything on the table at 13:05. And the cleanup cycle repeats, but with about six loads of dishes because of pots and pans. At 14:30, the kitchen is clean and tidy again.

The “human cost” of lunch is about six hours.

Dinner is scheduled at 19:00, which will have costs similar to lunch. Tallying up, it takes about 16 hours a day to keep everyone fed and happy (“it takes 30 people with their feet on the ground, to keep one man with his head in the air”). Today, we are doing it ourselves, because it is also a really fun way to work together and it’s a good team-building exercise. And while we’re sure to get more efficient, it’s just not efficient to actually do the cooking ourselves. I’m very happy to have worked together with Grace and Scarlett and Christian today, but I’ll be happy to hand over the chef’s hat to Hadrien tomorrow.

(O yeah, lunch was pretty expansive and tasty, so we’re stuffed. And in Randa.)

Vary-Eze on airfield in Bad Ragaz, Switzerland

Following the release of 5.6.0 published in June, the digiKam team is proud to announce the new release 5.7.0 of the digiKam Software Collection. In this version a lot of work has happened behind the scenes and in fixing bugs, which does not mean there is no enhancements: A new tool to create print layouts has been introduces, albums can now be exported by mail, support for Hugin 2017 was added and GPS traces are storable as KML.

Bugs Triage

We updated the bugs categories and went through all of them to reassign them to the correct category and find no longer valid or duplicate bugs. The immediate result of this is an enormous list of resolved issues in this release. However this is not the main benefit: The change makes it both easier for issue reporters to find an appropriate category as well as for developers to get an overview and find issues relevant to specific parts of the code.

New tool for advanced printing

This wizard allows you to print multiple images in various configurations. If the aspect ratio does not fit the printing format, you can choose which part of the image to crop (if at all). The result can be sent directly to a printer, to GIMP or to a file. The tool is available in all modes: Main view, light table, editor and showFoto through the tools menu. In the main view it is also accessible in the right sidebar in the tools tab.

Send by Mail

New tool for sending images by mail The long awaited tool to send pictures by email is here. You can set an upper limit to the email size, convert images on the fly and remove all metadata from the files. The supported email clients are visible on the screenshot above. As the Print Creator, this tool is accessible throughout the program.

Google Summer of Code 2017 Students

The time of the four students working on digiKam has ended officially. They have handed in their final report, but it will hopefully not be their final contribution. They have made real progress for digiKam and we hope they will continue helping making this software better. You can find a description and their final report on the official GSoC project page. We want to thank Yingjie Liu, Swati Lodha, Shaza Ismail Kaoud and Ahmed Fathy for their contributions!

Randa Meetings

The digiKam team was again invited to take part in the Randa Meetings. In this tiny town in the Swiss alps a lot of KDE developers work on improving their software. This years topic is accessibility, meaning make the software usable for as many users as possible, e.g. visual impaired people. Being able to meet team members face-to-face and profit from input of many experienced coders is extremely valuable. Please consider supporting the Randa Meetings to make sure that such events will continue in the future to make our software better. For the digiKam team represented at the event the main focus is on incorporating some of the GSoC projects as the media server dedicated to share collection contents on local network with compatible DLNA devices or applications, as tablets, phones, TV, etc. See below a shot of testing session sharing photo with a DLNA application runing on iPad.

digiKam media server contents displayed on iPad

Final Words

We already started to incorporate the astonishing work of our Google Summer of Code participants. It will take some time to get it to work as we want and put on the polish - things look promising for the next major release to version 6. The next minor release 5.8.0 will follow towards November.

As always, but especially noteworthy this time, you can look at the list of 505 resolved issues for detailed information.

digiKam 5.7.0 Software collection source code tarball, Linux 32/64 bits AppImage bundles, MacOS package, and Windows 32/64 bits installers can be downloaded from this repository.

Happy digiKaming while capturing lovely autumn colours!

The bugfix release of KStars 2.8.3 is available for all major platforms (Note: MacOS version is delayed to 2017-09-13). In this version, we finally managed to release translations for Windows & MacOS users, thanks to the efforts of Hannah and Kevin over at Craft, and the KDE translation team.

KStars in Arabic
A major bug that was fixed is inaccurate asteroid and comets positions. After exhaustive troubleshotting with the aid of JPL Horizon ephemeris, the problem was traced to imprecise Earth ecliptic longitude angle. The Earth coordinates are important if we want to calculate positions of solar system bodies from a geocentric point of view. Valentin traced the problem to problematic VSOP87 files and promptly generated new data files that solves the discrepancy in Earth ecliptic longitude.

However, while that greatly improved the accuracy, it was still a bit off. While checking KStars Florence (1981 ET3) asteroid position against that of Stellarium, I noted KStars epoch of date position exactly match the J2000 position reported in Stellarium! This was not a coincidence, it turns out we didn't account for precession in KStars. After that is taken care of, the comet and asteroid positions are now accurate on the order of arc-seconds! This is a 100-fold improvement in accuracy from previous versions.

Several fixes and improvement to Ekos with fixes in PHD2 support along with the ability to disable streaming from remote cameras right from the guide module. Another issue that was resolved is the focus module always running autofocus even when the HFR is below the threshold. This was tricky to trace down as it was due to a switch of HFR algorithms when the HFR check is first requested. For those using domes, the align module now properly waits until a slaved dome reaches its target before proceeding with image capture. More over, the Mosaic Tool was simplified and now dragging the mosaic grid produces precise jobs for all orientations.

Numerous stability improvements from GSoC 2017 projects made it into the release. GSoC 2017 student Csaba Kertesz concluded the project and KStars is now much more bullet-proof than before.

This release is named after my lovely loyal German Shepard Tommy! Isn't he a good boy?


September 11, 2017

The Kubuntu Council is happy to announce the results of the election, and welcome the following members: Rik Mills, Aaron Honeycutt (returning) and Rick Timmis.

We thank Simon for running and making this a race, Clay and Ovidiu-Florin for their service on the Council, and Kubuntu Member Clive Johnston for stepping up and running this election.

See the official announcement from Clive on the mailing list: https://lists.ubuntu.com/archives/kubuntu-devel/2017-September/011374.html

Day 1 was mostly covered by the trip from Germany up to Randa which went really smooth. The last leg of the trip I was on a KDE train with 8 other fellow developers going from Visp up the valley to Randa. Once arrived at the house, I met old friends that I haven’t seen …

“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

  • Fixed scrolling behaviour with a mouse wheel (it used to be very slow).
  • Prepared the 0.4 release.
  • Fixed RE: prefixing for replies.
  • Fixed issue where searching for removed entities would result in a query going through all uids instead of only the ones of a specific type. As this touched storage a “sinksh upgrade” will be required to clean up.
  • Added some missing icons that where symlink targets.
  • Inverted colors on folderview scrollbar to match that area of the UI.
  • Fixed layouting issues with long attachment lists in the composer.

Kube Commits, Sink Commits

Previous updates

September 10, 2017

Today I traveled from Zurich to Randa, which is about three hours by train. The day’s views started with a city, and trams and buses and high buildings. And then they got better:

Pictures of mountainsidesThe trip from Visp up to Randa is impressive every year. The moment you can see the ice of the glacier above Randa is wonderful. And now I’m sitting across from Thomas and Bhushan who are debugging something complicated. There was a wonderful dinner cooked by Mario’s parents, and a re-union feel with attendees from last year. I’m happy to see KDEnlive Joseph and Grace again, and the PIM dudes (although they seem to have slunk off to one of the meeting rooms for Serious Talks already).

Tomorrow starts at 7:02, when I have kitchen duty to roll out breakfast for 20-or-so Free Software hackers who are hungry from the fresh mountain air, and then after that it’s time to self-organize and sit down to work.

Hello folks,

This had been one of the best summers in my entire life, and one of the most productive one too. All the hard work and love for the work which I did start last year, mostly by this time only I guess, paid off. One of the greatest blessing in my life which happened is getting into a University which has a diverse FOSS culture. The people there, they are total bliss �� The amount of help they have provided and the amount of effort they have put into me, making me what I’m and that is tremendous. I’m unable to find a better way to appreciate them for the amount of help they have put into me. To be honest I still feel like all these are just a dream. I still can’t digest the fact that, I was possible to get this done.

So all start during this same time, last year. A beautiful Caption, Experience Freedom got into my head. Yes, it is the Tagline of my favorite community KDE. Following that, I did almost everything an Open-Source Enthusiast does. Joined their IRC, went to Bug trackers to solve some issues, Talked with developers who have diverse knowledge on the things which they do, rather than someone like me �� People in KDE are so helpful and friendly that, at any time I was having a doubt or was stuck at anywhere, let it be some silliest mistake at my end itself (most of the time though :P)

I still remember the time, I struggled to get my build running and fix a bug which I assigned to myself :P. It took me almost 2 months in KDE to fix my first bug, In fact, that was in KIO framework :). (I was searching for the code section in the code base of system settings the whole time, where I should have looked into KIO, Rookie issues — you know �� ). I still remember my first patch was just removing a clear button from the system settings, because it had an inline clear already, and it was just roughly 8 line of code change.

They are there to help me and support me. With the flow of this going through, I got to know about a program called KDE-SoK similar to Google Summer of Code, But a bit different, without any stipend and hassle free of deadlines, whatever maybe, the thought of my work going for the betterment of the community I love, It pulled me to be a part of it. yay! I was a part of it. I worked for a project in KDE called KStars. Within this, I exposed myself to new opportunities after that. I got to know about KDE conf India, conf.kde.in, I got invited to give a talk there on the topic Object Tracking Using OpenCV and Qt. That was the place where I got to know a few of KDE devs face. (Argh, again, the blog post about it really late too, still in my Draft! Seriously! what was I so busy with :P)

Then came the Google Summer of Code, one of the most hyped programs in our college. Not only in our college, from the people I know in different parts of India, It is almost the same situation in almost every college, where there exists some FOSS culture. Project List for KDE was published. I thought, Since I have done KDE SoK project with KStars I will move with that itself, but it had lot of astronomical content and the project seemed to be a fair bit complex and for me, because I was in my freshman year and only had a fair bit knowledge on the programming skill set that the whole KDE community required. I always felt that I might have got in with KStars itself, but for me what mattered was successfully completing the project with in the deadline. Then I saw a project in Krita, and looking through the codebase itself, I don’t know why, but I was able to understand what was happening under the hood. And fortunately, I found a pretty good project as well in Krita, Integrate share.krita.org [Phabricator | idea]. This was profound enough for me.

Went into Krita IRC channel talked with the people around. Started to fix some bugs in the codebase. And when we were talking, they mentioned that at least 3 bug fix should be there for a GSoC participant in Krita. And that was mind boggling because I had to get that done in 1 week of time, where I had to start working on my proposal too. But I never gave up and did those 3 bug fixes in the span of 1 week and completed the proposal in time and submitted it off! Even though those bug fixes weren’t that huge ones, just roughly maybe 50 lines of code. But I did it �� And Luckily guess what, I got selected.

Meanwhile, after getting selected, during the community bonding period, I was continuously blogging in most of the reports and about my project idea on how I was thinking to move on and make this project into a reality. Here comes my life saver to the rescue leinir, according to plan we might have to recreate KNSCore again if we were going to create the content downloader with libaattica. But seeing my blog posts, I got in touch with leinir and from then, they were a real help to me.  Still, I was a bit confused and needed some space to get a clear idea on what I should do in order to get the project done in the perfect way. There comes one of the best camps I attended here for a week, a camp called Gitaamritam, one of most irritating but the best rule for this camp was that we weren’t allowed to use any kind of devices until the camp gets over. Even though, this was tough for me because, especially during the time of GSoC, but that was the time when the whole perspective on how I viewed my project changed and I got an evident idea on how to proceed. (I had lot of ample time to think and think and only think about the project for a whole of 1 week �� )

Before I get into much more technical aspects, I would like to thank my mentors, Timothée GIET, Scott Petrovic and Boudewijn Rempt for the tremendous help for shaping the whole procedure into an awesome one. Thanks a lot!!!


Screenshot_20170906-180002I just love my mentors :), They are super cool. Just like the art we create and the code we write ��


After that, everything started off with a blast! All the functionalities as planned from the wireframe mock up and all was done with easy with hell lot of help from the community.

Created a widget class named DlgContentDownloader, which will act as the interface between, the dialog and the user. After all the work, the content downloader ended up having all of these functionalities:

  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.

Since I was handling bits and parts of libraries as well, I learned a technique in Qt, d-pointer(d-pointer implementation is a part of design pattern is also called opaque pointers in other architectures).

Also, going into a deeper level of the project, we have used certain KDE primary level framework/APIs in order to complete the GUI and get things working as planned. SOme of them are:

  • Kconfig

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

  • KWidgetsAddons

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

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

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

After all of this, I was working on the UI for the content downloader. as planned as the mock-up and here is the implemented dialog with the mockup we planned according to the wireframe.


After this was the second part of the project, Improving the design aspect of bundle manager and fix the issues and add certain UI features into the resource manager, such as search functionality for finding the bundles of your choice.

Here is the before and after of the bundle manager:


Hence that was it, the most exciting summer of my life, so not elongating this blog post anymore, just dropping down my pen here with some snaps, where my favs ❤ appreciating my effort during the whole struggle, they know the whole struggle story ��

All the Blog posts till now related to GSoC’17:

Work Product: https://cgit.kde.org/krita.git/?h=Aniketh%2FT6108-Integrate-with-share.krita.org

Status Reporthttps://community.kde.org/GSoC/2017/StatusReports/AnikethGirish


It's been a week since I announced Rust Qt Binding Generator.

Rust Qt Binding Generator (Logo by Alessandro Longo)

Rust Qt Binding Generator (Logo by Alessandro Longo)

Since last week

A brief recap. The new project Rust Qt Binding Generator can create bindings between Rust code and Qt code. You can use Rust code to power your Qt application. Or in other words, you can use Qt as a cross-platform user interface for your Rust application.

You describe the interface between Rust and Qt in a simple JSON file. Then you compile the Rust code into a static library that you call from Qt. The user interface is still written in QML or C++. QML in particular is a wonderful language for writing user interfaces. And with these bindings, your Rust code will feel as a natural part of that user interface.

Today, I'll walk through a very simple application. We'll pretend that Qt code has no way to figure out the time, so we'll implement code in Rust to ask the time.

But first an update on the happenings since the announcement of the bindings.

Live at KDE

The project is hosted at KDE. This is important to me. KDE is a community where software is created that gives the user control. It is a smoothly running organization that churns out releases of libraries and applications regularly.

Since this week the project is set up on the KDE infrastructure thanks to our admin team. That means bugzilla for bug reports, Phabricator for code browsing and patch review and Jenkins for continuous integration including code coverage.

The first translation commits and bot housekeeping commits have appeared already.

If you want to contribute, please create an account at the KDE community.

Time for QML

If you are new to QML, I can recommend the QML book. It walks you through many wonderful examples. In addition, Qt Creator comes with many more.

It is a tradition in KDE to use clocks as examples. I will follow this tradition and create a widget that shows the time.

We'll start without any Rust at all. The initial version is only QML. It uses a simple SVG image as the background.

You can download this version and run it locally with qmlscene. qmlscene can run plain QML files. If you have QML plugins installed, these can be used too. You can make plugins that are implemented in Rust, but we'll not go into that now.

The syntax of QML is declarative. The rotation of the Rust logo is given by the statement angle: time.second * 6. This is a binding. The value of angle updates automatically whenever time.second changes. The rotation of the logo changes every second because of this declarative binding.

Another example is anchors.fill: parent on the Image item. This means that the image takes up the same rectangular space as the parent item. If that item is resized, the image will scale along with it.

In this file, we added a temporary QtObject with properties hour, minute and second. The values in this object are updated every second by the Timer item. The JavaScript code between {} runs every second and updates the values in the QtObject. This object has id: time and the logo and hands are bound to this object.

The QtObject is a functional placeholder for the Rust code that we are going to write later.

import QtQuick 2.5
import QtQuick.Window 2.2

Window {
    width: 512
    height: 512
    visible: true

    // A mock-up of the time object that we will
    // implement in Rust
    QtObject {
        id: time
        property int hour
        property int minute
        property int second
    // This timer will also become Rust code
    Timer {
        interval: 1000; running: true; repeat: true
        onTriggered: {
            var date = new Date()
            time.hour = date.getHours()
            time.minute = date.getMinutes()
            time.second = date.getSeconds()

    // the clock face
    Image {
        anchors.fill: parent
        source: "rust-logo-blk.svg"
        fillMode: Image.PreserveAspectFit
        transform: Rotation {
            origin.x: width / 2
            origin.y: height / 2
            angle: time.second * 6 // convert seconds to degrees
    // the minute hand
    Rectangle {
        id: minute
        x: (parent.width - width) / 2
        y: 0
        width: parent.width / 100
        height: parent.height / 1.8
        radius: width
        color: "#3daefd"
        transform: Rotation {
            origin.x: hour.width / 2
            origin.y: height / 2
            // convert minutes to degrees
            angle: time.minute * 6
    // the hour hand
    Rectangle {
        id: hour
        x: (parent.width - width) / 2
        y: parent.height / 6
        width: parent.width / 50
        height: parent.height / 2.8
        radius: width
        color: "#3daefd"
        transform: Rotation {
            origin.x: hour.width / 2
            origin.y: height / 3
            // convert hours to degrees
            angle: time.hour * 30 + time.minute / 2
Time for Rust and QML Time for Rust and QML

Set up a QML project with Rust

Before we can replace the QtObject, we have to set up a project. Rust Qt Binding Generator comes with a template project for QML in the folder templates/qt_quick.

You can get set up like so. You will need to have Qt, Rust and CMake installed.

First build rust_qt_binding_generator.

git clone git://anongit.kde.org/rust-qt-binding-generator
mkdir build
cd rust-qt-binding-generator/build
cmake ..
make rust_qt_binding_generator
export PATH=$PATH:$PWD/src

Now build and run the template project.

mkdir ../templates/qt_quick/build
cd ../templates/qt_quick/build
cmake ..

You will be greeted with a 'Hello World' application.

Starting from a template

So what just happened? The template project is based on CMake. CMake is the build system that most KDE projects use. A template in CMake is an example of how to add Rust code to KDE programs. It is possible to ues another build system.

CMake performs four steps. It

  1. generates Rust and C++ from bindings.json by calling rust_qt_binding_generator,

  2. compiles the Rust code in rust/ into a static library by calling cargo,

  3. compiles the C++ code,

  4. links the C++ objects, the QML files, and the Rust library into an executable.

If you prefer to use only cargo, you'll have to tell it to perform steps 1, 3 and 4 in a build.js file.

Adding some Rust

Now let's turn this clock into the Antikythera mechanism by adding some Rust.

We want the Rust code to have a Time object that indicates the hour, the minute and the second. We write this interface into bindings.json.

    "cppFile": "src/Bindings.cpp",
    "rust": {
        "dir": "rust",
        "interfaceModule": "interface",
        "implementationModule": "implementation"
    "objects": {
        "Time": {
            "type": "Object",
            "properties": {
                "hour": {
                    "type": "quint32"
                "minute": {
                    "type": "quint32"
                "second": {
                    "type": "quint32"

Now if we run make again, three files will be updated: src/Bindings.h, src/Bindings.cpp, and rust/src/interface.rs. And then we'll get a compile error from cargo.

That is because we have to adapt rust/src/implementation.rs to the new interface.rs. interface.rs specifies a trait that must be implemented in implementation.rs.

This is the generated trait:

pub trait TimeTrait {
    fn new(emit: TimeEmitter) -> Self;
    fn emit(&self) -> &TimeEmitter;
    fn hour(&self) -> u32;
    fn minute(&self) -> u32;
    fn second(&self) -> u32;

Note that the trait has getters, but no setters. With "write": true, you can add setters on properties.

For now, we implement a fixed time in our new implementation.rs.

use interface::*;

pub struct Time {
    emit: TimeEmitter

impl TimeTrait for Time {
    fn new(emit: TimeEmitter) -> Self {
        Time {
    fn emit(&self) -> &TimeEmitter {
    fn hour(&self) -> u32 {
    fn minute(&self) -> u32 {
    fn second(&self) -> u32 {

Now whenever the QML application wants to know the time, it can ask the Rust code. Well, almost. We have to change three more files and one of them is a C++ file. It is a very simple change and it is needed to tell the QML code about the Rust QObject. In src/main.cpp, change this line:

    qmlRegisterType<Simple>("RustCode", 1, 0, "Simple");

to this

    qmlRegisterType<Time>("RustCode", 1, 0, "Time");

And we have to add the logo to the qml.qrc. This file lists files that should be compiled into the executable.

    <qresource prefix="/">

Now write this in main.qml. The third line imports our Rust object into the application. Our mockup QtObject and the Timer have been replaced with Time { id: time }.

This Time still has the properties hour, minute, and second. Whenever these change, the user interface is updated.

import QtQuick 2.5
import QtQuick.Window 2.2
import RustCode 1.0

Window {
    width: 512
    height: 512
    visible: true

    // here is our Rust time
    Time {
        id: time

    // the clock face
    Image {
        anchors.fill: parent
        source: "rust-logo-blk.svg"
        fillMode: Image.PreserveAspectFit
        transform: Rotation {
            origin.x: width / 2
            origin.y: height / 2
            angle: time.second * 6 // convert seconds to degrees
    // the minute hand
    Rectangle {
        id: minute
        x: (parent.width - width) / 2
        y: 0
        width: parent.width / 100
        height: parent.height / 1.8
        radius: width
        color: "#3daefd"
        transform: Rotation {
            origin.x: hour.width / 2
            origin.y: height / 2
            // convert minutes to degrees
            angle: time.minute * 6
    // the hour hand
    Rectangle {
        id: hour
        x: (parent.width - width) / 2
        y: parent.height / 6
        width: parent.width / 50
        height: parent.height / 2.8
        radius: width
        color: "#3daefd"
        transform: Rotation {
            origin.x: hour.width / 2
            origin.y: height / 3
            // convert hours to degrees
            angle: time.hour * 30 + time.minute / 2

Start the time

The time is now A happy clock

Are you still here? That was quite a few instructions to follow for a simple example. The good news is that this setup does not get harder when you add more interfaces.

Anyway, now the part you've been waiting for. We will let Rust update the time and send it to the user interface. The crate chrono is used to get the time. Add it to lib.rs and Cargo.toml.

This code goes in implementation.rs. A thread wakes up every second and sends a signal to the user interface whenever a property changes.

use interface::*;
use chrono::{Local, Timelike};
use std::thread;
use std::time::Duration;

pub struct Time {
    emit: TimeEmitter,

fn emit_time(emit: TimeEmitter) {
    thread::spawn(move || {
        loop {
            if Local::now().second() == 0 {
                if Local::now().minute() == 0 {

impl TimeTrait for Time {
    fn new(emit: TimeEmitter) -> Self {
        Time {
    fn emit(&self) -> &TimeEmitter {
    fn hour(&self) -> u32 {
    fn minute(&self) -> u32 {
    fn second(&self) -> u32 {

Closing remarks

This was a pretty long tutorial with quite a few different parts. That was the point of the tutorial: to learn the parts that make up a binding between Qt and Rust.

Next time, we will go into Model/View programming. We'll create a list in Rust that can be used in many Qt widgets. If you cannot wait until then, please have a look at the code in demo/.

September 09, 2017

Yesterday we went shopping to nourish some Free Software enthusiasts next week. According to the shopping list we’ve ready:

  • Several kinds and kg of vegetables
  • Some boxes full of fruits
  • A lot of Swiss cheese (like more than 10 kg)
  • Some meat and sausages
  • Milk, orange juice, coffee, tea and some beer and wine
  • Lasagne pasta and rice (some kg too) and 7 kg of Spaghetti
  • Two buckets of yoghurt and a bucket of jam
  • Almost 100 eggs
  • And last but not least several kg of Swiss chocolate…

As you see some of it in the picture below this stuff is ready in the meetings house in Randa. But the participants need to pay (15 CHF per day for 3 meals and chocolate, beer and wine are extra) this for themselves as they would need to at home too.

Some food (and chocolate) for the Randa Meetings participants

Some food (and chocolate) for the Randa Meetings participants

But there are other expenses as well: travel costs and accommodation. Some of the participants just can’t afford these things and thus we need to support them. And that we can support these people to come to Randa to work on your favorite KDE software we need your financial support too. So please go to our fundraiser page page and give. Thank you!

Oh and btw besides me the first participant already arrived… and the others will arrive tomorrow during the day when we start to make KDE more accessible for a whole week and just as a start.

Randa Meetings Konqi with Matterhorn and Edelweiss

Flattr this!

It’s time for me to get ready for the trip to Randa, CH to meet some fellow KDE developers at the annual Randa Meetings. The train tickets have been bought a while back, the swiss power adapter together with an extra extension cord providing multiple Schuko outlets is packed and clothes for almost all weather …

September 08, 2017

I will give a presentation at the next Ceph Meetup in Berlin on the 18th of September. It will be about a exciting project we work on, at Deutsche Telekom, since a while. The goal of this open source project called librmb is to store emails directly in Ceph RADOS instead of using e.g. a NAS system. 

For an short abstract checkout out the Meetup description. The Meetup is already full, but there is a waiting list you can subscribe to. The slides from the talk will be available afterwards if you are not able to join. Otherwise see you in Berlin.

After some delay, I am finally pushing forward towards a final release of KBibTeX for KDE 4. The first step is the tagging and releasing of tar balls for version 0.7's Beta 1.

Read more... )

comment count unavailable comments

The “Live Preview” plugin for the editors/IDEs Kate & KDevelop (see introduction) makes use of KParts plugins to support different file formats. Thus it can also pick up the range of existing KParts implementations out there right from the start.

A perfect user experience with the “Live Preview” plugin means:

  • automatic updates of the preview while one edits the sources, without a reset of the preview settings (scroll position, zoom state, etc.)
  • not going through the file system to push changes in the sources to the preview

For that usually some more work needs to be done to the existing KParts plugins.

Editing in the Qt UI file worlds

One of those plugins, where I also have personal interest in and thus giving priority, is the KParts plugin from the KUIViewer, a tool to display and check Qt user interface (*.ui) files. Because in the recent time I have edited Qt UI files quite often and started to do this manually directly in the XML-based sources instead of in Qt Designer, as it became quicker to do for me the more I had learned the syntax. But for checking the current state I still had to save the file and load it separately in Designer or KUIViewer.

So the KUIViewer KParts plugin and the “Live Preview” plugin for KDevelop have started to improve my developer life ��

“Containers” for the rescue, once more

Besides some pain points though: if you used KUIViewer yourself before, you might remember that its code was operating straight forward. For one it instantiated any UI file as-is, e.g. showed a QMainWindow-based UI also as normal separate window in the workspace, so not embedded in the window of KUIViewer itself. Which comes at least as surprise, if not as something unhandy. Especially for the use with the “Live Preview” plugin, where the automatic update of the preview and thus the reloading of the UI file in the KUIViewer code means windows coming and going all the time.
Then normal widgets were shown as main widget of the KUIViewer window, which for very big or very small widgets result in according changes to the window and broken display in the “Live Preview” plugin.

Too much pain, and then I was looking at the sources anyway. So while extending the KUIViewer KParts plugin to implement the streaming API and restoring/keeping the view state on reloading from the same URL, I also reached out for the class QMdiArea for the rescue and changed KUIViewer to show the object defined by a UI file as a subwindow instead. And that way allowing widgets to have any sizes, but also taming QMainWindow-based UI to not escape the KUIViewer scene:

This change will be coming to everyone as part of KDE Applications 17.12.

And thanks to the respective code being in the KUIViewer KParts plugin, without any further changes we get the same tamed behaviour in the “Live Preview” plugin:

Improve your favourite KParts plugin for the “Live Preview”

If you edit some other sources often and want to be supported by the “Live Preview” plugin, get and build the plugin quickly yourself, the current state works good enough.
Then see if there is a matching KParts plugin you then can improve as needed.

The “Live Preview” plugin is currently planned to be released as official part of KDE Applications 17.12 and later as well, possibly as part of the Kate repo. So a few months left to shape up your favourite KParts plugin. Go for it now to be done in time ��

September 07, 2017

I just received my certificate of completion and very proud of contributing to digiKam in KDE this summer, and grateful to Google, the people of KDE and my mentors for making this possible.

Now I can also celebrate that I graduated and earned my Bachelor degree from Faculty of Engineering, Ain Shams University in July having delayed this celebration for a while.


Getting started with contributing to KDE PIM can be hard – we have nearly 60 repositories with complicated dependencies – just getting that right can discourage many people from even trying. And then there’s, of course, the risk factor of running development build alongside your production Kontact, endangering your precious emails.

To address all these issues I have created a Docker image. It’s based on the KDE Neon Developer edition and it has all the dependencies pre-installed and pre-configured and comes with a set of handy shell scripts to make your life easier. It also has the environment set up properly so that you can run the development build of Kontact inside of the container – completely isolated from your production installation.

Interested now? Follow the instructions how to build the Docker image and how to run the container on our KDE PIM Docker wiki page.

The section regarding GPU drivers is still incomplete, if you have any knowledge regarding running OpenGL-enabled applications inside a Docker container with Nouveau or AMD/ATI drivers, let us know, please!

You can probably use our Docker image to develop other KDE applications in there as well, or you can take a look at Jos’ blog about Developing KDE with Docker and create your own Docker image to work on your favorite KDE application.

Happy hacking!

Although the team is at full throttle getting ready for the 17.12 big refactoring release, we make available the first point release of the 17.08 series bringing various bugfixes and usability improvements. Stay tuned for testing the refactoring branch packages to be announced soon.


  • Remember last selected title template. Commit. See bug #384340
  • Fix proxy error (height not multiple of 2). Commit. Fixes bug #384345
  • Fix extract frame from bin exporting lower than source image. Commit.
  • Fix visibility check of tracks in multitrack-view. Commit.
  • Allow disabling autosave until we improve it. Commit. Fixes bug #384197
  • Windows: find Kdenlive lumas. Commit. Fixes bug #375337
  • Windows: terminate KDE session on window close. Commit. Fixes bug #380854
  • Windows: always use bundled MLT. Commit. Fixes bug #380036
  • Remove project profiles sharing (knsrc). Commit. Fixes bug #383238
  • Gardening: fix GCC warnings (8). Commit.

With Randa approaching, I’ll be meeting some KDE people, some for the first time. So it’s time for another GPG keysigning! The usual approach to a GPG keysigning is to have Harald organise it, that ensures a maximum amount of abiding-by-rules. But .. he’s not going to be there, this year. So this post is a random bit of throw-information-out-there about how typical KDE event keysignings work, and an annoucement of my own protocol in handling keysinging.

My PGP key can be found here in pubkey.asc, and has key fingerprint = 00AC D15E 25A7 9FEE 028B 0EE5 7FEA 3DA6 169C 77D6.

Anyway, a typical KDE keysigning goes like this:

  • An Austrian^Wattendee is selected to coordinate the process in advance. You need to trust the coordinator and their printer.
  • A wiki page is started, which lists participants by name and GPG key fingerprint.
  • On the day of the event, the coordinator prints out one copy of the wiki page with the key table for each attendee. This is the point at which you need to trust the coordinator, to print out N identical copies.
  • At the event, each attendee in turn is asked to state that the key fingerprint on the sheet is, indeed, their key fingerprint.
  • All those who say “aye”, are participants. A shared secret for the session is established by writing a word on the whiteboard; this can optionally be used as part of the verification process later.
  • Each pair of participants cross-checks government-issued photo-ID plus whatever else they want to do. Sometimes we try to establish two concentric circles, for efficiency in cross-checking, but in my experience that leads to random milling about.
  • After all the cross-checking, we’re done the party part, and people can do the actual signing in whatever way they wish.

My personal protocol adds the following:

  • During the keysigning, I have double-slips of paper with my key fingerprint printed on them, and five randomly selected words from /usr/share/dict/words (on a FreeBSD machine, there are 235924 words in that file). Each double-slip has the words printed twice, and can be cut in half with the same words on both halves. For each participant, I have a different double-slip with uniquely selected words.
  • I’ll cut the slip in half, write your name on both halves, and give you one of the copies. Now we have a shared secret — those five randomly-selected words. Both you and I need to guard those slips of paper carefully!
  • Once home, I’ll send you an encrypted, signed, message asking for our shared secret.
  • You respond with an encrypted, signed, message containing those five words.
  • I send you an encrypted, signed, message with my signature on your key.

I used to ask a question (like “what stupid joke did I tell you on the first day of Akademy?”) which was some kind of shared secret between us, but memories are fallible and something that makes a big impression on me might be useless fluff to you. So that’s why I’m switching to using these slips of paper. I figure “choledocholithotripsy unobeying odontogeny staymaking fantigue” is as good a shared secret as any.

Massif Visualizer is a visualiser for output generated by Valgrind’s massif tool.  It shows you graphs which measure how much heap memory your program uses.

Download link: https://download.kde.org/stable/massif-visualizer/0.7.0/src/

f8a4cc23c80a259a9edac989e957c48ed308cf9da9caeef19eec3ffb52361f6d  massif-visualizer-0.7.0.tar.xz

PGP signature is mine:
Jonathan Riddell with 0xEC94D18F7F05997E.

It has an optional dependency on KGraphViewer which is due for a release shortly.


Facebooktwittergoogle_pluslinkedinby feather

September 06, 2017

I should be communicating more often about development related to the Elisa music player. Recently Safa Alfulaij added support for right-to-left interface. This is a very good excuse to talk about what happened since my previous post.

Accessibility Improvements

As I said, thanks to Safa Alfulaij Elisa has mostly good support for RTL interface. From my testing as a French native speaker I did notice a problem with icons of ToolButton components that have no way to indicate that they should be mirrored. Apart from that, it should be usable.

Screenshot_20170906_220229Reversed Album View

This contribution is really important to have Elisa be more accessible to more people. This topic is also the main subject of the next KDE sprint in Randa (Randa Meeting). Please have a look to the contribute page to help fund KDE developer sprints (Make KDE more accessible).

Music Import

After having gotten quite a few feedback about the lack of user interactions during music import, I have started to work to improve this area.

I added two things:

  • A passive area showing the count of imported music track files (before duplicates are ignored) ;
  • An offer to modify configuration when Baloo indexing is disabled or the music is not found in the default music path. This also adds a KCM dedicated to configure the paths where your music collection is located.
Screenshot_20170906_225104Improvements in user notifications

Platform Support Improvements

I have been improving support for flatpak as a way to allow a faster way to test it and to get feedback for new developments. I also think that this in no way going to replace packaging by Linux distributions. At least for me, there is a lot of comfort to be able to “apt-get install” almost everything I need.

I also have been working on improved Windows support. This is mainly driven by my need to have a good music player usable at my work place. By the way, people working on KDE for Windows are both really helpful and they do a very good job.

Future work

I need to finish my work to have robust support for notifications allowing the user to have a better and more natural interaction with the player especially during music import.

I also need to integrate in the main branch a very nice work by Martin T. H. Sandsmark that adds support for visualizations during play of music. I just needed to learn how to write KCM (especially with an qml UI). I also want to allow the feature to be easily discoverable without bothering people not using it.


Kdenlive 17.12 alpha for testing will soon be released

Kdenlive’s large cleanup and code refactoring will reach a major milestone with the release of Kdenlive 17.12 in december. The development team has been working hard all year to prepare for this release, and we will merge the code to the master branch in october. As part of the development process, we want to make regular alpha/beta releases to allow interested users to test the development version.

Randa meeting
Next week, the Randa meetings will take place in Switzerland, and part of my job there will be to prepare the first AppImage version to test the new Kdenlive. I will also exchange with other KDE developers to see what we can do to have Kdenlive’s development version available as daily built Snap and Flatpak packages. Other topics for this week include a UI review. If you are interested, please consider a donation to the Randa meetings that help us make Kdenlive better every year.

What’s next
When the alpha testing packages will be available, we will concentrate on making Kdenlive more stable than ever. But a few features have already been added thanks to the updated architecture, like resizable tracks, sub-groups, and more… we will add more professional features in the mid-long term. We are always interested in feedback, and recently started a poll regarding parts of the timeline behavior.

Join Us
We always need help to make Kdenlive better, so if you want to participate, don’t hesitate to contact us on the mailing list or stay tuned for our next café.

Using Breeze

Using Oxygen

qqc2-desktop-style is a style for Qt Quick Controls 2 to make it follow your desktop’s theme.

It will be released with a future release of KDE Frameworks 5 but in the mean time it’s due to be an optional dependency to Plasma 5.11 which has a beta next week.

Download the beta now: sha256 checksum is

PGP signature is mine:
Jonathan Riddell with 0xEC94D18F7F05997E.







Facebooktwittergoogle_pluslinkedinby feather

At the beginning of the summer I went to Akademy in Almeria. So what did it bring, in terms of development? I can point to the FreeBSD-on-KDE-Slimbook posts as one technical result of Akademy, although I suppose I could have just had the machine shipped to me, too. (There need to be more posts about the laptop, as FreeBSD support for it improves; I must admit I’ve been a little lax in hacking on that).

There was a documentation BoF, expressing the wish to work on the community.kde.org pages to make them more up-to-date. Documentation, especially something showcasing the latest-and-greatest, is a constant source of maintainence-effort-required. I’ll have to admit I haven’t done anything there — writing Calamares documentation, for instance, has higher priority for me personally and can chew up inordinate amounts of time as well.

Photo of Mira with KTuberling

Using KTuberling in KDE3

Non-technically, there were two really surprising, but personally gratifying results:

  • My daughter, age 14, is going to Akademy 2018. Partly for Akademy, partly because of the Lippizaner horses; I guess she’s a nerd-horse girl.
  • Her response to her school’s mandatory-Windows-10-laptop policy: “dammit, why can’t they just use Linux? I know how to use that.”

She’s come a long way since KDE3.

I would like to provide some information on working with System Settings. This is a big endeavor and not an easy one. System Settings is a good expression of the power of Plasma KDE and also the many influences that have shaped it over the years.

Trying to untangle the work that has gone into System Settings requires time and patience. I have always been interested in working in revamping this UI. We worked with the team in the VDG on this some time ago, and although there were many great and interesting changes, the scope of the work was too great. Therefore, we decided only to move forward with those things that were achievable at the time.

We reorganized our settings.

In recent iterations of the software, we have also decided to change a few more visuals with the application and have added a second column for specific KCMs.

However, I feel we want to go further in the future and achieve even more. It is because of that vision that I have decided to keep working with System Settings to help the modules arrive at a good place in the near future. I have taken consideration of a few ideas and initiatives that our team has, some reported bugs and overall perception. I suggested that I become a lead designer for this project.

But I can’t do it alone. If you have ideas and thoughts (albeit without drastically changing the direction that I am taking) please share them.

This is somewhat rough, but here is something that I can show for now, please note this is a graphic mockup, not a working UI:


Please note that these ideas here are still in progress. They are developing and changing a lot. Further things that I would like to design are:

  •  Work on labels and develop a tone and angle for descriptions. Right now labels don’t have a consistent sound and tend to lead to confusion, at least in English.
  • Work on removing tabs in favor of a one-page interface where settings can be together without the need for more than 3 clicks before getting to the desired content.
  • Design new interactions for certain KCMs and follow a predictable structure for information presentation.

I hope this helps understand where System Settings can be.

Our KDE team is working hard these days in many areas. Adding System Settings to the mix might take time. For now, they are focused on getting people at our next sprint at Randa. They will be working on accessibility. I am hoping that we can bring System Settings to those discussions as well.

UPDATE: I should make a statement as it seems that others have been misled. This mockup is only a graphical concept, not a developed application. I am not a developer, I am a visual designer. This mockup is intended to have the KDE team review and come to a consensus to develop System Settings to something like I have proposed. The mockup is missing a few things, title bar, search fields, labels, and buttons. I hope it is evident that those changes will be included.

September 05, 2017

KTechLab is capable of simulating not only circuits, but circuits containing PIC microcontrollers with a program running on it.

Later this week, I’m leaving for Zurich, and from there I’ll take the train up to Randa (up, in the sense that I live at sea level, and Randa is the length of one million micro-SD cards laid end-to-end higher).

In Randa, I’ll be working as a KDE developer, and as a Calamares developer, and learning about accessibility tooling. There’s about 60 hacking hours in that week. I’ll also be working as the cook, for one day. There’s about 12 cooking hours in a day, since feeding 30 people takes a lot of vegetable-chopping, bread-slicing, and dish-washing.

That is something special about Randa, I think: the feeling of much closer “living together”, and the way the attendees work together to create an optimal hacking environment. And cooking (along with the hacking) is my way of supporting the Randa meeting.

You can support the Randa meeting, too. That doesn’t support me; it supports other attendees who need to make long trips, it defrays the costs associated with infrastructure, it brings networking to town for a week. Support the Randa meetings for this year’s theme, or for the idea of a focussed retreat for hacking.

There’s a dot story about plans for the meeting. There will be summaries as well, and blog-roundups. But blog-roundups are tricky, because of the kind of things we (attendees) tend to write about. When blogging about the Randa meeting, I’ll probably blog more about food and hikes than about the hacking. The non-hacking bits make for better stories, even if the point of being there is the hacking. The results of the long coding sessions — privilege-separating Calamares, double-checking accessibility of KDE on FreeBSD — will show up later, in a future Calamares release or KDE-FreeBSD update. That’s the long-term payoff.


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.