Today I landed a change in KWin master branch to enable real time scheduling policy for KWin/Wayland. The idea behind this change is to keep the graphical system responsive at all times, no matter what other processes are doing.

So far KWin was in the same scheduling group as most other processes. While Linux’s scheduler is completely fair and should provide a fair amount of time to KWin, it could render the system hard to use. All processes are equal, but some processes are more equal than others. KWin – as the windowing system – is to a certain degree more equal. All input and all rendering events need to go through KWin.

We can now imagine situations where a system can become unusable due to KWin not getting sufficient time slots. E.g. if the user moves the mouse we expect a timely cursor motion. But if KWin is not scheduled the system is quickly starting to lagging. Basically what we expect is that when the mouse moves with the next page flip the cursor must be at the updated position. A page flip happens normally every 16 msec (60 Hz), so if we miss one or two we are in the area where a user visually notices this. For a gamer with a high precision mouse this could be quite problematic already.

Another situation is a few processes running amok and one wants to switch to a virtual terminal to kill the processes. The key combination (e.g. Ctrl+Alt+F1) needs to go through KWin. Again the user wants to have a responsive system in order to be able to switch the session.

While thinking about these general problems I came to the conclusion that we should try making KWin a real time process. This would ensure that KWin gets the CPU whenever it wants to have the CPU. This is actually quite important: KWin is only taking CPU if there is a reason for it, e.g. an input event or a window requesting a repaint, etc. So by adding a real time scheduling policy to KWin we can ensure that all input events and all rendering events are handled in a timely manner. My hope is that this in general results in slightly smoother experience and especially in a smoother experience if the system is under heavy load.

Of course I considered the disadvantages. If KWin is a real time process, it always wins. It’s on the scheduler’s fast lane. This could of course be a problem for other processes actually demanding a higher scheduling policy or which are real time itself. E.g. a game or a video player might already be real time. But here we also see that there is no point in having the game be real time for fast input if the windowing system itself is not real time. So this is actually not a disadvantage, but rather another reason to make KWin a real time process.

There could be other real time processes which are more important. Of course those should win against KWin. To support this KWin requests only the minimum priority, so any other real time process in the system is considered more important than KWin.

The only real “problem” I see would be KWin running amok, because then KWin would get too much CPU time. But in this case the system would be broken anyway. If e.g. KWin would be stuck in an endless loop one would not be able to switch to another VT as KWin is stuck in the endless loop. This is obviously only a theoretical example.

So how is it done? KWin gained a new optional dependency on libcap and on installation sets the capability CAP_SYS_NICE on the kwin_wayland binary. @Distributions: please update your build deps. On startup kwin_wayland adjusts the scheduler policy to request SCHED_FIFO and drops the capability again before doing anything else.

As this change is in master it won’t be part of the Plasma 5.11 release which also means we have now the maximum time span till it ends up in a release. I would be happy about users testing it and especially report any negative influences of the change.

What are you looking at?

As a means to give our work direction and a clearer purpose, KDE is currently in the process of soul-searching. Here’s my proposal of what we should concentrate and focus on in the coming years. I’d welcome any feedback from the community to make this proposal better, and rally up more support from the community, and others interested.

So here’s the Big, hairy, audacious goal that — in my opinion — KDE should focus on, and should adapt its strategy for:

“In 5 years, KDE software enables and promotes privacy”

Privacy is the new challenge for Free Software. KDE is in a unique position to offer users a complete software environment that helps them to protect their privacy. KDE, being community-driven and user-focused, has the opportunity to put privacy on top of the agenda, arguably, being in this position, KDE has the obligation to do this, in the interest of the users.

The effect is expected to be two-fold:

• Offer users the tools to protect privacy and to lead a private and safe digital life without compromising their identity, exposing their habits and communications
• Setting a high standard and example for others to follow, define the state of the art of privacy protection in the age of big data and force others to follow suit, thereby increasing pressure on the whole industry and eco-system to protect users’ privacy better

Leaking user data, allowing users to be tracked, collecting their most private information in databases across the world means that users lose control of their identity and what parts they want others to know, and what they want to keep for themselves. Worse, collecting data in so many places, often commercially, but also by governments means that the user has little way of knowing what is known about him or her, let alone being able to determine who should be able to control what. Data being persistently collected means that not only today's security measures and policies are relevant, but also the future's. This poses multiple great risks.

KDE adds a 5th Freedom to the 5 principal software Freedoms:

“The freedom to decide which data is sent to which service”.

Personal Risks for Users

Orwell’s 1984 is not an instruction manual

Risks that individual users run are, among others:

• The more data that is collected, the bigger the risk of Identity Theft becomes
• More collected data means that decisions will be made for the user based on skewed or incomplete information (imagine insurance policies)
• Collected data may end up in the hands of oppressive regimes, posing risks to the user when travelling, or even at home
• Blackmail
• User's most private secrets may end up in the wrong hands

Socio-economic Effects

Socio-economic effects that effect how society, national and international communities work, are:

• Free speech is compromised
• Journalists need tools to communicate secretly, lacking that, freedom and independence of press cannot be guaranteed
• Trade-secrets cannot be kept, free markets cannot function without tools protecting privacy
• Sovereignty of nations cannot be guaranteed
• Cyber-attacks may lead to shift in power

What it will take?

TL;DR:

• Security
• Privacy-respecting defaults
• Offering the right tools in the first place

Security

We can only guarantee privacy if we also value security.
Possible approaches:

• Functioning code-review
• Quick turn-around times for software updates, especially security fixes
• Prefer to use encrypted communication where possible, prefer HTTPS over HTTP where possible, avoid unencrypted connections
• Storing sensitive information only in an encrypted way
• Moving away from inherently insecure technologies, i.e. default to Wayland instead of X11
• Avoiding single points of failure and centralized control

Privacy-Respecting Defaults

KDE software supporting this goal should:

• Only collect and send data when necessary and clear and sensible from within the context. No hidden telemetry sending user stats, not HTTP connections downloading content, no search queries to online services without the users explicit consent (or where it's entirely clear from the context, e.g. web browsers, software updater, etc.).
• Use anonymity where it is possible, for example by using Tor connections for things like weather updates that don't require user identification
• No collection of privacy-relevant data without clear purpose.
• Conservative defaults: a user should not have to make changes to the software configuration to avoid leaking data. Secure and private by default. (Software may be configured to be more leaky if that benefits the user, but the risk to that should be clear, either from context or explicitely stated.)
• Use clear and consistent UI and design language around network-related options

Offering the Right Tools

KDE needs to make an effort to provide a comprehensive set of tools for most users' needs, for example:

• An email client allowing encrypted communication
• Chat and instant messenging with state-of-the art protocol security
• A webbrowser (self-provided) that has private default settings
• File storage and groupware solutions
• Other tools that allow offline operation and independence from popular cloud services
• Support for online services that can be operated as private instance, not depending on a 3rd party provider
• State-of-the-art support and integration for services like Tor, Matrix, Zeronet, etc.

Others

• KDE e.V. allows anonymous donations via bitcoin (or other crypto currencies)
• Adaption of blockchain where useful

How we know we succeeded

Static and runtime analysis tools:

• https://github.com/iovisor/bcc/blob/master/tools/tcpconnect.py
• […]

KDE software can be audited for compliance with common, security related standards, such as:

• NIST Cybersecurity Framework (NIST CSF)
• ISO 15408
• RFC2196
• Cyber Essentials (UK Government Standard)
• … etc.

"Soft" criteria include:

• Press and 3rd party refer to KDE as carrying the gold-standard for such software
• Journalists prefer KDE software for their work
• The NSA hates KDE
• The CCC loves KDE ♥

The full proposal has a little more details and pointers (and may still be updated, it’s not final yet), but I’d like to keep it at this for my weblog, and also add a note here: Coincidentally, shortly after starting the work on this proposal, KDE’s Plasma team was contacted by Purism who are building a privacy-focused phone. I was immediately excited since I think privacy is more or less an extension of the core values of Free software and the librem5 could provide a really valuable target for KDE’s privacy efforts, I see a fantastic degree of synergy there.

There are quite a few applications in KDE that are severely outdated and deserve a new life.

A few weeks ago I started playing around with KTimer, and I managed to make it out of this:

to this:

I managed to keep the core of the code, and everythign works. The current work is in the branch kirigamize_it and will go to review as soon as I remember to do it.

Last year, the AppStream specification gained proper support for adding metadata for fonts, after Richard Hughes did some work on it years ago. We weren’t happy with how fonts were handled at that time, so we searched for better solutions, which is why this took a bit longer to be done. Last year, I was implementing the final support for fonts in both appstream-generator (the metadata extractor used by Debian and a few others) as well as the AppStream specification. This blogpost was sitting on my todo list as a draft for a long time now, and I only just now managed to finish it, so sorry for announcing this so late. Fonts are already available via AppStream for a year, and this post just sums up the status quo and some neat tricks if you want to write metainfo files for fonts. If you are following AppStream (or the Debian fonts list), you know everything already .

Both Richard and I first tried to extract all the metadata to display fonts in a proper way to the users from the font files directly. This turned out to be very difficult, since font metadata is often wrong or incomplete, and certain desirable bits of metadata (like a longer description) are missing entirely. After messing around with different ways to solve this for days (afterall, by extracting the data from font files directly we would have hundreds of fonts directly available in software centers), I also came to the same conclusion as Richard: The best and easiest solution here is to mandate the availability of metainfo files per font.

Which brings me to the second issue: What is a font? For any person knowing about fonts, they will understand one font as one font face, e.g. “Lato Regular Italic” or “Lato Bold”. A user however will see the font family as a font, e.g. just “Lato” instead of all the font faces separated out. Since AppStream data is used primarily by software centers, we want something that is easy for users to understand. Hence, an AppStream “font” components really describes a font family or collection of fonts, instead of individual font faces. We do also want AppStream data to be useful for system components looking for a specific font, which is why font components will advertise the individual font face names they contain via a

<provides/>

 -tag. Naming fonts and making them identifiable is a whole other issue, I used a document from Adobe on font naming issues as a rough guideline while working on this.

How to write a good metainfo file for a font is best shown with an example. Lato is a well-looking font family that we want displayed in a software center. So, we write a metainfo file for it an place it in

/usr/share/metainfo/com.latofonts.Lato.metainfo.xml

  for the AppStream metadata generator to pick up:

<?xml version="1.0" encoding="UTF-8"?>
<component type="font">
  <id>com.latofonts.Lato</id>
  <metadata_license>FSFAP</metadata_license>
  <project_license>OFL-1.1</project_license>

  <name>Lato</name>
  <summary>A sanserif type­face fam­ily</summary>
  <description>
    <p>
      Lato is a sanserif type­face fam­ily designed in the Sum­mer 2010 by Warsaw-based designer
      Łukasz Dziedzic (“Lato” means “Sum­mer” in Pol­ish). In Decem­ber 2010 the Lato fam­ily
      was pub­lished under the open-source Open Font License by his foundry tyPoland, with
      sup­port from Google.
    </p>
  </description>

  <url type="homepage">http://www.latofonts.com/</url>

  <provides>
    <font>Lato Regular</font>
    <font>Lato Black Italic</font>
    <font>Lato Black</font>
    <font>Lato Bold Italic</font>
    <font>Lato Bold</font>
    <font>Lato Hairline Italic</font>
    ...
  </provides>
</component>

When the file is processed, we know that we need to look for fonts in the package it is contained in. So, the appstream-generator will load all the fonts in the package and render example texts for them as an image, so we can show users a preview of the font. It will also use heuristics to render an “icon” for the respective font component using its regular typeface. Of course that is not ideal – what if there are multiple font faces in a package? What if the heuristics fail to detect the right font face to display?

This behavior can be influenced by adding

<font/>

  tags to a

<provides/>

  tag in the metainfo file. The font-provides tags should contain the fullnames of the font faces you want to associate with this font component. If the font file does not define a fullname, the family and style are used instead. That way, someone writing the metainfo file can control which fonts belong to the described component. The metadata generator will also pick the first mentioned font name in the

<provides/>

  list as the one to render the example icon for. It will also sort the example text images in the same order as the fonts are listed in the provides-tag.

The example lines of text are written in a language matching the font using Pango.

But what about symbolic fonts? Or fonts where any heuristic fails? At the moment, we see ugly tofu characters or boxes instead of an actual, useful representation of the font. This brings me to an inofficial extension to font metainfo files, that, as far as I know, only appstream-generator supports at the moment. I am not happy enough with this solution to add it to the real specification, but it serves as a good method to fix up the edge cases where we can not render good example images for fonts. AppStream-Generator supports the FontIconText and FontSampleText custom AppStream properties to allow metainfo file authors to override the default texts and autodetected values. FontIconText will override the characters used to render the icon, while FontSampleText can be a line of text used to render the example images. This is especially useful for symbolic fonts, where the heuristics usually fail and we do not know which glyphs would be representative for a font.

For example, a font with mathematical symbols might want to add the following to its metainfo file:

<custom>
  <value key="FontIconText">∑√</value>
  <value key="FontSampleText">∑ ∮ √ ‖...‖ ⊕ �� ℕ ⋉</value>
</custom>

Any unicode glyphs are allowed, but asgen will but some length restrictions on the texts.

So, In summary:

• Fonts are hard
• I need to blog faster
• Please add metainfo files to your fonts and submit them upstream if you can!
• Fonts must have a metainfo file in order to show up in GNOME Software, KDE Discover, AppCenter, etc.
• The “new” font specification is backwards compatible to Richard’s pioneer work in 2014
• The appstream-generator supports a few non-standard values to influence how font images are rendered that you might be interested in (maybe we can do something like that for appstream-builder as well)
• The appstream-generator does not (yet?) support the <extends/> logic Richard outlined in his blog post, mainly because it wasn’t necessary in Debian/Ubuntu/Arch yet (which is asgen’s primary audience), and upstream projects would rarely want to write multiple metainfo files.
• The metaInfo files are not supposed to replace the existing fontconfig files, and we can not generate them from existing metadata, sadly
• If you want a more detailed look at writing font metainfo files, take a look at the AppStream specification.
• Please write more font metadata

 

I have focused on keyboard navigation and correct handling of focus. Some preliminary work is already integrated with more to come. I hope to soon be able to use Elisa only with the keyboard and am starting to enjoy the progress so far. This is quite different from the last two years where only mouse and touch screen were usable to interact with Elisa.

If you think this is an important or useful feature in Elisa, please consider donating to the Randa Meeting fundraising campaign (https://www.kde.org/fundraisers/randameetings2017/). Without it, probably nothing would have happen in Elisa in the keyboard usage area.

The next step will be to give a look to Orca screen reader. I really feel inspired by the work that has been done during last Randa meeting.

Another important thing (at least for me) would be a pleasant usage with the touch screen you usually found on laptops.

Tomaz Canabrava did analyze a runtime error due to using a Qml property not existing in the required version but existing in the version used at runtime (or not). Due to that, Elisa now requires Qt5.9. Thanks a lot.

Burkhard Lück started to fix a few issues with the Elisa documentation.

KGraphViewer 2.4.2 has been released.

KGraphViewer is a visualiser for Graphviz’s DOT format of graphs.
https://www.kde.org/applications/graphics/kgraphviewer

Changelog compared to 2.4.0:

• add missing find dependency macro https://build.neon.kde.org/job/xenial_unstable_kde-extras_kgraphviewer_lintcmake/lastCompletedBuild/testReport/libkgraphviewer-dev/KGraphViewerPart/find_package/
• Fix broken reloading and broken layout changing due to lost filename https://phabricator.kde.org/D7932
• kgraphviewer_part.rc: set fallback text for toplevel menu entries
• desktop-mime-but-no-exec-code
• Codefix, comparisons were meant to be assignments

KGraphViewer 2.4.1 was made with an incorrect internal version number and should be ignored

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

Download from:
https://download.kde.org/stable/kgraphviewer/2.4.2/

sha256:
49438b4e6cca69d2e658de50059f045ede42cfe78ee97cece35959e29ffb85c9 kgraphviewer-2.4.2.tar.xz

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

by

Today is a special day for Nextcloud and me because Nextcloud gets a cool and important new capability. This is end to end encryption for file sync and share. Nextcloud supports server side encryption for a long time and all file transfer over the internet is encrypted with

TLS/SSL of course. But there is still the need for full end to end encryption to make sure that the data is secure in all scenarios. One

example is that the current server side encryption doesn’t protect the data against an evil server admin or if the server is hacked. The new end to end solution does that.

This feature is more important then ever in the light of Trump and other governments including western ones like the UK who want to have access to the private data of users.

Please read this blog post about the upcoming dangers in the next few months. European datacenter is no solution, recent developments show

Most requested feature

End to end encryption is our most ever requested feature. Users and customers have been asking for this for many many years so I am super happy that we finally do this now. So you might ask “what took you so long?” There are many reasons.

The first is that it is hard. This needs to be done without compromising the user experience. Then we wanted to support as many core Nextcloud features as possible, for example sharing. And we wanted to do this in a way that doesn’t compromise performance. Obviously security is the highest priority and that is hard in itself. But another must have requirement is to make the feature truly enterprise ready. So real key management is necessary and it has to be designed with the assumption that users make mistakes. We don’t need another solution that is aimed at technical users, losing their data when they forget their password for example… Our solution doesn’t even let users pick their own password, taking away the risk of passwords that are easy to hack due to reuse or shortness! We also wanted to implement this feature fully transparent and native in all clients and fully open source instead of integrating a third party tool. It was hard to find a solution that balanced all these requirements. But I’m happy to say that Björn, who already designed and developed the server side architecture and Lukas our security lead, found a good architecture, with a lot of feedback from a number of other team members of course. This has been a real collaborative effort, building on our years of experience and a good understanding of the needs of our users and customers.

How does it work?

The feature consists of several components. There is the actual encryption and decryption code which is implemented in the Nextcloud iOS and Android apps and in the Mac, Windows and Linux clients. And then there is a server component which is implemented as a Nextcloud app to do the key management. This is useful to make it easy for the users to distribute private and public keys to all clients and share with each other. Obviously the private keys are encrypted with very strong auto generated passwords which are only known by the users and clients and are never accessible by the server. The key server also supports an optional recovery key which can be activated to make it possible to recover lost passwords/keys. This feature can be activated or deactivated to balance user convenience and security. The clients will warn users when the feature is or gets enabled.

End to end encryption can be activated by the users on a folder by folder basis. Once a user decided to encrypt a folder everything inside the folder will be encryption including the content of the files and folder and the metadata like filenames. From now on the folder is no longer accessible from the Nextcloud web-interface and WebDAV. But it is still fully readable and writable from iOS, Android and Mac, Windows, Linux. Sharing still works via public keys of other users. The full design is explained here and the architecture is further documented here

Enterprise ready

It was a key requirement to implement this feature in a way that it is not only useful for home users who want to protect their data on home-servers or at service providers. It had to be done in a way that it is useful for companies and other large organisation. We had conversations with some of our bigger customers over the last few month to make sure that this integrated nicely into the enterprise infrastructure and is compliant with existing policies. One example is that we will try to integrate this into Desktops like KDE, Gnome, Mac and Windows and will support Hardware Security Modules.

Where are we today?

This feature will be fully production ready and included in Nextcloud 13 which will be out later this year. But we didn’t want to wait until then and announce and release something as soon as possible so we can get feedback from encryption experts and the wider infosec community. So today we have our architecture document ready here. The server component is fully implemented and can be found in our github. There is a preview version of the Android app available which is fully working. The Desktop client and the iOS app are in the middle of the development. You can expect preview builds in the next few days. You can see the development and give feedback in the repositories in github.

More information can be found here:

• Nextcloud introduces native integrated end to end encryption
• End to End encryption RFC

The software can be found here:

• Server
• Android
• iOS
• Desktop

So please give feedback about the architecture and the code if you want to get involved. This is a big step forward to protect the data of users and companies against hackers and organisations who want to abuse it in various ways!

 

 

I’ve switched to using Plasma 5 as my daily (work) desktop. “So what?” you say, since Plasma 5 has been available since July 15th, 2014. Yep, more than three years on the desktop — see Sebas’s blog for some history. So I’ve finally switched my FreeBSD desktop machine, as a sign that Plasma 5 really is coming closer to the official FreeBSD ports tree.

KDE Applications are starting to trickle in to the official ports tree. The first (I think) was FileLight, which gave a good illustration of the gotcha’s involved with the update:

• Anything that touches baloo requires a radical update to Plasma 5 as a whole. Baloo 4 and baloo 5 are not happy side-by side, and we don’t intend to put serious effort into installing them in separate places.
• Translations are tricky, because they have moved from (KDE 4 times) a separate i18n package, to the application package. This means that the new KF5-based application package conflicts with the old KDE4 application, but also with the entire translation package (for, say, Russian) for KDE4.

For people who want the whole thing now, and who understand that KDE4 co-existence with Plasma 5 and modern KDE Applications can be problematic, the official ports tree can be avoided, and Area51 is the repository or ports tree to use.

On my desktop, on 10.3-STABLE and with nVidia drivers, Plasma 5 is more stable than on 12-CURRENT with tricksy Intel IGP drivers on the laptop. That’s a good thing, for the desktop I spend all week in writing code.

KMail and Akonadi have decided that my local maildirs are not accessible, so I’m using mutt for the time being to look at those. All my IMAP (knock on wood) is fine, so there’s still an intriguing bug there. In Randa I showed the effect and the messages to Dan and Volker, who were likewise intrigued. In the
end, though, it needs to be debugged and fixed here, locally, and then upstreamed.

At some point, the KDE-FreeBSD team had in mind to have Plasma 5 in the official ports tree in 2017Q2. It’s looking like 2017Q4, now (with just 5 days to go in Q3), basically because the upgrade path is annoying (from a ports perspective). Not for any functional reason, which is why it’s worth repeating that Plasma 5 from Area51 is a fine, fully functional, and fully up-to-date KDE desktop.

[[ Edit 2017-09-27 14:18 because Phoronix manages to get everything wrong, all the time: Tobias has been using Plasma 5 as his FreeBSD desktop of choice for years, dogfooding the ports much better than I ever have. And while I might be the noisiest blogger of our lot, that’s .. not necessarily a position of leadership. ]]

We are happy to bring you GCompris 0.81.

This is a bugfix release to correct some issues in previous version. All GNU/Linux distributions shipping 0.80 should update to 0.81.

Also, we introduce a new “light” version that doesn’t require OpenGL to run. This means that it should work on any computer. We provide some special windows packages using this option, and also the standalone installer for Linux 32bit is using this option. In this light version, the transparency gradient on the menu is gone, and we had to adapt a dozen of activities that will look a little different in this mode, but should still be usable.

We also added a new Download page on the website, with instructions for each operating system.

Last but not least, we now have translation for Indonesian, thanks to some very nice contributors who organised a sprint in Indonesia to work on it.

The most important changes in this version are:

 

• Categorization, fix the “Shape” category
• Categorization, fix the menu layout
• Categorization, display score in expert mode
• Guesscount, fix invalid result
• Add Indonesian locale
• Fix the missing copyright and licence info
• Fix a font issue on windows version
• Add a new minimal version with software rendering (requires Qt 5.8)

 

 

Activities modified to run with software rendering:

 

• crane
• categorization
• lang
• hanoi
• tangram
• land_safe
• click_on_letter
• left/right
• hexagon
• magic_hat
• color_mix
• color_mix_light

 

 

You can find this new version here:

 

• Android:

 

The new version is available in the Android store

 

• Windows:

 

Windows 32bit or Windows 64bit version

 

• Windows (light version – No OpenGL):

 

Windows 32bit – No OpenGL or Windows 64bit – No OpenGL version

 

• Linux:

 

If your distribution doesn’t provide an updated package, use one of those standalone installers. They must be launched from command line, after adding executable permission on the file. Check the Download page for more info.
Linux 32bit or Linux 64bit version

 

• Source code

 

• md5sums :

 

For all downloads: md5sums

 

• GPG verification :

The source tarball, the windows and the linux installers are signed. You can retrieve the public key over https here: 0x63d7264c05687d7e.asc.

 

Thank you all,
Timothée & Johnny

Convergence, or the ability the serve different form factors from the same code base, is an often discussed concept. Convergence is at the heart of Plasma‘s design philosophy, but what does this actually mean to how apps are developed? What’s in it for the user? Let’s have a look!

Plasma — same code, different devices

First, let’s have a look at different angles of “Convergence”. It can actually mean different things, and there is overlap between these. Depending on who you ask, convergence could mean any of the following:

• Being able to plug a monitor, keyboard and mouse into smartphone and use it as a full-fledged desktop replacement
• Develop an application that works on a phone as well as on a desktop
• Create different device user interfaces from the same code base

Convergence, in the broadest sense, has been one of the design goals of Plasma when we started creating it. When we work on Plasma, we ultimately expect components to run on a wide variety of target devices, we refer to that concept as the device spectrum.

Alex, one of Plasma’s designers has created a visual concept for a convergent user interface, that gives an impression how a fully convergent Plasma could look like to the user:

Input Methods and Screen Characteristics

Technically, there are a few aspects of convergence, the most important being: input methods, for example mouse, keyboard, touchscreens or combinations of those, and screen size (both physical dimensions, portrait vs. landscape layout and pixel density).

Touchscreen support is one aspect when it comes to run KDE software on a mobile device or within Plasma Mobile. Touchscreens are not specific to phones any more however, so making an app, or a Plasma component ready for touchscreen usage also benefits people who run Plasma on their convertible laptops, for example. Another big factor is that the app needs to work well on the screen of a smartphone, this means support for high dpi screens as well as a layout that presents the necessary controls in a way that is functional, attractive and user-friendly. With the Kirigami toolkit, which builds on top of QtQuick, we develop apps that work well on both target devices. From a more general point of view, KDE has always developed apps in a cross- platform way, so portability to other platforms is very much at the heart of our codebase.

The Kirigami toolkit, which offers a set of high-level application flow-controls for QtQuick applications achieves exactly that: it allows to built responsive apps that adapt to screen characteristics and input method.

(As an aside, there’s the case for Kirigami also supporting Android. Developing an app specifically for usage in Plasma may be easier, but it is also limiting its reach. Imagine an app running fine on your laptop, but also on your smartphone, be it Android or drive by Plasma Mobile (in the future). That would totally rock, and it would mean a target audience in the billions, not millions. Conversely, providing the technology to create such apps decreases the relative investment compared to the target audience, making technologies such as QtQuick and Kirigami an excellent choice for developers that want to maximize their target audience.)

Plasma Mobile vs. Plasma Desktop

Plasma Mobile is being developed in tandem with the popular Plasma desktop, in fact it shares more then 90% of the code with it. This means that work done on either of the two, mobile and desktop often benefits the other, and that there’s a large degree of compatibility between the two. The result is a system that feels the same across different devices, but makes use of the special capabilities of a given device, and supports different ways of using the software. On the development side, this means huge gains in terms of productivity and quality: A wider set of usage scenarios and having the code running on more machines means that it gets more real-world testing and bugs get shaken out quicker.

Who cares, anyway?

Whether or not convergence is something that users want, I think so. It takes a learning curve for users, and I think advancements in technology to bring this to the market, you need rather powerful hardware, the right connectors, and the right hardware components, so it’s not an easy end-goal. The path to convergence already bears huge benefits, as it means more efficient development, more consistency across different form factors and higher quality code.

Whether or not users care is only relevant to a certain point. Arguably, the biggest benefit of convergence lies in the efficiency of the development process, especially when multiple devices are involved. It doesn’t actually matter all that much if users are going to plug their mouse and keyboard into a phone and use it as a desktop device. Already today, users expect touchscreen to just work, even on laptops, users already expect the convertible being usable when the keyboard is flipped away or unplugged, users already expect to plug a 4K into their 1024×768 resolution laptop and the UI neither becoming unreadable or comically large.

In short: There really is no way around a large degree of convergence in Plasma (and similar products).

“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

• Added support for secret distribution to resources in sink. This will be the base for avoiding passwords in configuration files.
• Added a simple in-memory keyring in Kube. Doesn’t persist the password yet as we have no secure storage.
• Simplified the configuration dialog to only require name + email address
• Moved the password entry into a separate view so we can request the password on startup if not available.
• Fixed keyboard focus in configuration and password view.
• Fixed indefinitely growing webviews. This was a problem with mails that would always grow one pixel larger than what was available which lead to a resize cycle.

Kube Commits, Sink Commits

Previous updates

KTextEditorPreviewPlugin 0.1.0 has been released.

The KTextEditorPreviewPlugin software provides the KTextEditor Document Preview Plugin, a plugin for the editor Kate, the IDE KDevelop, or other software using the KTextEditor framework.

The plugin enables a live preview of the currently edited text document in the final format. For the display it uses the KParts plugin which is currently selected as the preferred one for the MIME type of the document. If there is no matching KParts plugin, no preview is possible.

Download from:
https://download.kde.org/stable/ktexteditorpreviewplugin/0.1.0/src

sha256:
21e17a97fe2b942991ce564371ce822564397488847f8d21d7d5b24d4c120796 ktexteditorpreviewplugin-0.1.0.tar.xz

Signed with my new PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau <kossebau@kde.org>
ktexteditorpreviewplugin-0.1.0.tar.xz.sig

Notes

Long term the plan is to merge this plugin into the Kate repository, or some new separate KTextEditor-Plugins repo, ideally already for KDE Applications 17.12.

For now though this plugin is in its own repository to allow an initial independent quick release cycle phase, following the release-often-and-early mantra. With the help of your feedback (file your issue) that should make the features of the plugin the ones you like to have rather soon.

Developers: Improve your favourite KParts plugin

While a usual KParts plugin works out of the box, for a perfect experience with the Automatic Updating option some further improvements might be needed:

• Keeping the current view state if reloading from the same URL (e.g. scrolling offset, zoom)
• Implementing the KParts::ReadOnlyPart streaming API, to by-pass and thus preserve the filesystem/storage hardware:
  • virtual bool doOpenStream(const QString &mimeType)
  • virtual bool doWriteStream(const QByteArray &data)
  • virtual bool doCloseStream()

A few KParts plugins have already seen such adaptions, like the SVGPart and the KUIViewerPart (see also blog post), adaptions to be released with KDE Applications 17.12.
Another KParts plugin has been written with that in mind from the start, the KMarkdownWebViewPart (see also blog post), which already has been released.

You might want to take some guidance by the respective commit “Support loading by stream and restoring state on reload” to the SVGPart repository.

I’ve been part of the KDE Community for over 15 years .. maybe 20. I started with Red Hat Linux, and then ran Yellow Dog Linux with KDE on my work desktop; probably KDE 1.1.2. But mostly I was one of the FreeBSD and Solaris people. I packaged KDE for Solaris on big Sun iron like the E10k, and then for FreeBSD around 2005 (I know this because of at least one wonderfully descriptive commit message Add boogers on July 26th, 2005 in Area51), and then for OpenSolaris for a while, and moved back to FreeBSD when OpenSolaris went away.

So in a sense I have been part-time part of the FreeBSD Community for nearly 15 years as well. FreeBSD has reached Tier-1 status within KDE now, with the KDE FreeBSD CI, which much stronger upstreaming happening, and with Tobias and Raphael following new releases pretty closely. I’ve been pushing and prodding at our ports tree a lot, and chasing CMake releases (and reporting bugs), and trying to get some KDE KF5-based applications into the official ports tree. So I’m happy to now receive a FreeBSD ports commit bit, with Tobias and Raphael acting as mentors. I won’t pretend this will immediately lead to Qt 5.9 and KDE Applications 17.latest in the official FreeBSD ports tree, but it increases the (direct) effort we can expend on it.

For my FreeBSD hat, I can be reached at adridg@, like my KDE hat is groot@ .

Over the last weeks I concentrated my work on KWin on what I call the XFree KWin project. The idea is to be able to start KWin/Wayland without XWayland support. While most of the changes required for it are already in Plasma 5.11, not everything got ready in time, but now everything is under review on phabricator, so it’s a good point in time to talk about this project.

Why an XFree KWin?

You might wonder why we spend time on getting KWin to run without X11 support. After all we need to provide support for XWayland anyway to be able to support legacy applications which are not yet on Wayland. So what’s the advantage if in a normal session one needs XWayland anyway?

One aspect is that it shows that our porting efforts to Wayland are finished. Over the last years I tried to start KWin without XWayland support for a few times just to find areas which are not yet ported. By being able to run KWin without X11 support we know that everything is ported or at least does not hard depend on X11 any more.

Another aspect is obviously Plasma Mobile which does not really require XWayland and also XWayland not making much sense on e.g. the libhybris enabled systems as Xwayland doesn’t have OpenGL there. By not requiring XWayland we can reduce our runtime and memory costs.

Speaking of runtime costs: not requiring X11 means that we don’t have to wait for XWayland during KWin startup. Instead XWayland can be started in parallel. This means KWin and the complete Plasma session starts a little bit faster.

And most important this is an important prerequisite to be able to handle a crashing XWayland. So far when XWayland crashed KWin terminated gracefully as KWin depends on X11. The hope is that when XWayland crashes we can just restart it and keep the session running.

How it was done

The general idea behind getting KWin X11 free is “code that isn’t loaded, cannot interfere”. KWin uses platform plugins (not Qt QPA plugins) for the various platforms KWin can run on. There is also a platform plugin for KWin/X11, so code which is only required in the KWin/X11 case can be moved into the platform plugin. As KWin/Wayland does not load this plugin we are certain that the code will not be loaded and thus cannot interfere.

But how to find code which is only required on KWin/X11? After all KWin’s code base is about 150 kSloc (according to cloc) and that makes it rather difficult. A good help here was our CI system which performs code coverage. KWin’s tests mostly are mostly based on KWin/Wayland so an area which does not have any test coverage is a good candidate for being X11 specific. By looking at these areas it was possible to find patterns which also helped to find more usages. A good help is KWin’s internal X11 API such as displayWidth, displayHeight, rootWindow and connection. The usage of these functions is partially so few that one could just evaluate each usage. As a result of this work the functions displayWidth and displayHeight are not used at all any more.

Plugin based compositors

Another idea was to get our compositors into plugins. Especially the XRender based compositor is not of much use in a Wayland world and thus should not be loaded into the binary. Unfortunately various parts of KWin called directly into the concrete compositor implementations, so to solve this we had to extend the internal API. In Plasma 5.11 the XRender and QPainter compositor are now loaded as plugins, so on Wayland the not-compatible XRender compositor is no longer loaded into memory and on X11 the not-compatible QPainter compositor is no longer loaded into memory. But also on Wayland the QPainter compositor is only loaded into memory if it is going to be used.

The OpenGL compositor is still always loaded in Plasma 5.11, but the change to have it as a plugin is already prepared and will be merged into master soonish. This will bring great advantages to the stability of the system: currently we are not able to define which platform supports which compositor as the initialization code just didn’t support being more flexible. But now with the plugin based approach I’m very confident that we can make this work in a better way.

Outlook

Being able to start and run KWin/Wayland without X11 support is of course only the start. More changes will be required. For example to delay loading XWayland until an application tries to connect to it (c.f. Weston). This would not make much sense in the start of Plasma yet as we still have applications in our startup which require X11 (e.g. ksmserver).

Another area is to try to get KWin compile without X11 support and to move everything required for Xwayland into a plugin. This will be a larger project as it will require to move much code around and to add further abstractions in some areas of KWin. Hint: this could be a nice Google Summer of Code project. As a fast step for especially Plasma Mobile and the Purism Librem phone an ifdef around every X11 code area could be a solution.

But my personal main goal is to be able to handle a crashing XWayland. This will also be an interesting task as the X11 code in KWin also depends on other libraries (e.g. KWindowSystem) which do not expect to outlive the X server. So that will be a challenging task to find all areas where KWin holds X11 data structures and to clean them up properly without crashing due to some cleanup code calling into xcb.

Plasma Mobile

Back around 2006, when the Plasma project was started by Aaron Seigo and a group of brave hackers (among which, yours truly) we wanted to create a user interface that is future-proof. We didn’t want to create something that would only run on desktop devices (or laptops), but a code-base that grows with us into whatever the future would bring. Mobile devices were already getting more powerful, but would usually run entirely different software than desktop devices. We wondered why. The Linux kernel served as a wonderful example. Linux runs on a wide range of devices, from super computers to embedded systems, you would set it up for the target system and it would run largely without code changes. Linux architecture is in fact convergent. Could we do something similar at the user interface level?

Plasma Netbook

In 2007, Asus introduced the Eee PC, a small, inexpensive laptop. Netbooks proved to be all the rage at that point, so around 2009, we created Plasma Netbook, proving for the first time that we could actually serve different device user interfaces from the same code-base. There was a decent amount of code-sharing, but Plasma Netbook also helped us identifying areas in which we wanted to do better.

Plasma Mobile (I)

Come 2010, we got our hands on an N900 by Nokia, running Maemo, a mobile version of Linux. Within a week, during a sprint, we worked on a proof-of-concept mobile interface of Plasma:

Well, Nokia-as-we-knew-it is dead now, and Plasma never materialized on Nokia devices.

Plasma Active

Plasma Active was built as a successor to the early prototypes, and our first attempt at creating something for end-users. Conceived in 2011, the idea was not just to produce a simple Plasma user interface for a tablet device, but also deliver on a range of novel ideas for interaction with the device, closely related to the semantic desktop. Interlinked documents, contacts, sharing built right into the core, not just a “dumb” platform to run apps on, but a holistic system that allows users to manage their digital life on the fly. While Plasma Active had great promise and a lot of innovative potential, it never materialized for end-users in part due to lack of interest from both, the KDE community itself, but also from people on the outside. This doesn’t mean that the work put into it was lost, but thanks to a convergent code-base, many improvements made primarily with Plasma Active in mind have improved Plasma for all its users and continue to do so today. In many ways, Active proved valuable as a playground, as a clean slate where we want to take the technology, and how we can improve our developemnt process. It’s not a surprise that Plasma 5 today is developed in a process very similar to how we approached Plasma Active back then.

Plasma Mobile (II)

Learning from the Plasma Active project, in 2015 we regrouped and started to build a rather simple smartphone user interface, along with a reference software stack that would allow us not only to develop Plasma Mobile further, but to allow us to run on a growing number of devices. Plasma Mobile (II)’s goal wasn’t to get the most innovative of interfaces out, but to create a bread-and-butter platform, a base to develop applications on. From a technology point of view, Plasma is actually very small. It shares approximately 95% of the code with its desktop companion, widgets, and increasingly applications are interchangeable between the two.

Plasma Mobile (in any shape or form) has never been this close to actually making it into the hands and pockets of end users. A collaboration project with Purism, a company bringing privacy and software freedom to end-users, we may create the first Plasma phone for end users and have it on the market as soon as januari 2019. If you want to support this project, the crowdfunding campaign has just passed the 40% mark, and you can be part of it — either by joining the development crew, or by pre-ordering a device and thereby funding the development.

So, back in Randa I was splitting my energies and attentions in many pieces. Some attention went to making pancakes and running the kitchen in the morning — which is stuff I take credit for, but it is really Grace, and Scarlett, and Thomas who did the heavy lifting, and Christian and Mario who make sure the whole thing can happen. And the attendees of the Randa meeting who pitch in for the dishes after lunch and dinner. The Randa meetings are more like a campground than a 5-star hotel, and we work together to make the experience enjoyable. So thanks to everyone who pitched in.

Part of a good sprint is keeping the attendees healthy and attentive — otherwise those 16-hour hacking days really get to you, in spite of the fresh Swiss air.

Frederik encouraged us to touch the floor and the ceiling with his acro-yoga sessions; it is good to get out of the hacking room and get into shape. These sessions also teach us all trust and cooperation. And between sessions, he fixed a Qt bug that probably affects Calamares accessibility.

Calamares had some more bugs squashed, its accessibility improved — although I need to test that again and again on different setups now that I’m home, since it needs time to re-build Qt and all. Even with this fix, the goal to reduce Calamares’ root-needs remains.

You can read more of what the attendees in Randa achieved on planet KDE (e.g. kdenlive, snappy, kmymoney, marble, kube, Plasma mobile, kdepim, and kwin). I’d like to give a special shout out to Manuel, who taught me one gesture in Italian Sign Langauage — which is different from American or Dutch Sign Language, reminding me that there’s localization everywhere.

For me, being back home means sitting back at my big FreeBSD box, hacking on Calamares and ARPA and CMake and stuff again, with a renewed sense of purpose and team thanks to having worked together in Randa. If you like what KDE achieves in Randa, consider still supporting the fundraiser so that we can return to the mountains next year.