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.

Another successful Randa meeting! I spent most of my days working on snappy packaging for KDE core applications, and I have most of them done!

Snappy Builds on KDE Neon

We need testers! Please see Using snappy to get started.

In the evenings I worked on getting all my appimage work moved into the KDE infrastructure so that the community can take over.

I learned a great deal about accessibility and have been formulating ways to improve KDE neon in this area.

Randa meetings are crucial to the KDE community for developer interaction, brainstorming, and bringing great new things to KDE.
I encourage all of you to please consider a donation at https://www.kde.org/fundraisers/randameetings2017/

This week has been focused on finishing the development of persistent notifications at the top of the music views. They are intended to provide information about what happen with actions the user can take to improve things.

The following items have been pushed:

• Clean up of dependencies. Now all frameworks come with a description. Some have been downgraded to optional or recommended. Some have been upgraded to recommended ;
• A new version of persistent notifications.

The new persistent notifications

The player can be in four states:

• No notifications are active

  No notifications

   

• One notification is activeOne notification

   

• More than one notifications are active. Only one is shown such that vertical space is preserved

  Multiple notifications with the first visible

• The notifications area is expanded and several notifications are visible

  Show multiple notifications

   

If the user choose to act, the buttons are temporarily disabled to provide instant feedback and the notification disappear when the root cause is fixed (like in the example, if music tracks are discovered or Baloo configuration is modified or Baloo music indexer is disabled in Elisa.).

I have tried to provide smooth transitions between each of those states. Some may still be missing. Please do not hesitate to provide feedback on this feature.

I plan to add more notifications of this kind when the software wants to provide feedback to the user and asks him to choose what he prefers.

Next week, I should continue to improve integration with Baloo. I would also like to improve (in fact allow) the keyboard interaction.