We just finished migrating one of our stacks to a new and powerful piece of hardware. It was a major activity and took about 9 hours with around 2-3 hours of downtime per CMS. The activity is now complete, however there are a few rough edges that we’ll be ironing out over the weekend.
Technically, the functions to reach those goals all bring their own interactions and workflows. For users it is necessary to perceive clearly what happens and how to achieve the desired result. Unfortunately, some uncontrolled growth in KDE applications has lead to non-standardized implementation and application-specific short-cuts.
A few weeks ago I contacted Thomas Pfeiffer with the idea to design a new user interface for Klipper in Plasma 5.1. Surprisingly he informed me that a discussion was already started in the KDE Forums. Which is awesome as that means there was already some ideas on how the user interface could look like. Last week the number of new bug reports for KWin get lower so I started to look into Klipper for 5.1.
Discussed at the Qt Contributor Summit and now turning into an Internet discussion is that the Qt High-DPI support is on hold.
The Qt High-DPI support process allows setting a scale factor (via platform plug-ins, a user environment variable, or potential per-screen configuration files), layering changes to accomodate scaling, QWindow and other platform changes, etc. The HiDPI support is of course centered around new monitors that have very high pixel densities (Retina MacBook Pro, many smaller 4K displays, etc) and improving the experience for end-users by avoiding unbearably small text. Qt developers have been working on HiDPI support for several months.
It’s an interesting day for the KDE community. At one hand they announced the death of two projects – Vivaldi tablet and Improv board, on the other hand Krita (a KDE software) has reached its goal of raising Euro 15,000 on Kickstrater. The project can now hire the developer, designer they need to further improve the sketching and painting software. The campaign is not over yet and there are eight more days left so the project will continue to get more money.
This is the second half of the 'where KDE is going' write-up. Last week, I discussed what is happening with KDE's technologies: Platform is turning modular in Frameworks, Plasma is moving to new technologies and the Applications change their release schedule. In this post, I will discuss the social and organizational aspects: our governance.
My project basically consists in mantaining the Gluon Player and all the distribution service in general from the server to player library that handles OCS requests to the actual QML client. This meant in porting the Qt4 player to Qt5, which led to a partial rewrite and rearchitecturing After the porting I started implementing "friends" features. This means that YOU, with a Gluon account, can ask an other Gluon user for friendship and he can accept. This is the basis of the social features we're introducing.
digiKam is the closest thing you can get in GNU/Linux based systems (also on proprietary operating systems) which costs nothing. It’s one of the many extremely polished and feature rich open source applications developed by the KDE community. The digiKam community has announced the release of version 4.1.0 which include many bug fixes for the 4.0.0 release.
There are two technology goals that Plasma hasn't yet achieved that I hope it will one day. Neither of these were primary goals at the outset of Plasma's design or development, but as the code base matured and I watched the strengths and weaknesses of various design decisions, they made it onto my radar.
Erasing the boundary between remote and local in user interfaces
Component-centric design providing stability and performance improvements