Yesterday KEXI 3.2 Beta shipped, effect of improvements from entire 2018. Full info in the wiki.

That's best KEXI to date! Pun intended because among other things one is especially worth mentioning, entirely new and final date/time grammar for user's SQL.

Twice a year (on that note, happy new one!), the KDE e.V. board of directors comes together for an in-person meeting, taking care of business. It's become a tradition that on one of the two meeting days, the board hosts a dinner event open to KDE users, contributors and other interested parties.

The board's first meeting of 2019 will be in Seoul, South Korea, and the dinner will be held on Saturday, January 19th in central Seoul.

If you're interested in attending (us five board members aside, we've already had the pleasure of confirming the attendance of many notable local community members - it won't be boring!) and talking all things KDE and FOSS over good food with us, please drop me a mail. Modulo available space, I'll get back to you with details on the time and location as soon as we've finalized both.

This week, we have received a number of inquiries into how Plasma extensions, particularly those found on the KDE Store, relate to the stability and safety of a Plasma system. With an engineering focus, this blog hopes to provide answers.

Crash Resilience By Process Isolation

Present-day process architecture: Compositor and shell UI are isolated from each other

In Plasma, the shell UI and the compositor are isolated into seperate processes (plasmashell and kwin, respectively). The two exchange information regulated by IPC mechanisms such as the windowing system (Wayland or X11) and DBus, using standard protocols where suitable and custom-created ones where needed.

In a Wayland session, it's kwin that plays host to your application clients and puts them on screen (on X11, both KWin and app are clients to the X Server, providing a further isolation - KWin can crash and restart without impacting apps). Shell UI extension live in the seperate plasmashell process.

In the event that a shell extension crashes the shell, this allows it to be restarted without impacting KWin and therefore without impacting your applications. They continue to run undeterred while the shell takes steps to right itself.

Beyond crash resilience, putting limits on untrusted code run in the compositor process also has a security dimension. Particularly on Wayland, where one of the design goals is not to allow untrusted code to introspect the windowing system globally.

Meanwhile, to make KWin ready to taking over for the X Server in a Wayland session, we significantly upgraded our engineering story - requiring and dramatically raising unit test coverage for KWin and related library code, for one.

Process Isolation: Next Steps

The architecture discussed above shields applications and the compositor from shell UI extensions, but it doesn't shield the shell. We want to fix that next.

Next: Isolate shell UI and extensions, too — individual or batch processes for extensions

The always-stunning David Edmundson has been spearheading several engineering efforts to make the shell itself have a multi-process architecture. Some of this has already quietly been shipping in the Plasma 5.12 LTS release: KRunner plugins, which provide search results in our menus/launchers, can now opt into running out-of-process. We've used this to isolate some of the crash chart-topping plugins, preventing them from taking down the shell when performing a search query.

Likewise, for shell UI extensions, he has been working on top off the library stack we initially built for the Wayland transition to allow them to be run out of process and then get composited into the shell UI. In addition to making the shell far more resilient to extension crashes, this would also create additional security domains for untrusted extension code - we can build on this to sandbox and drop privileges for them.

All of this is broadly similar to application architecture improvements pioneered by multi-process web browsers in past years, albeit built squarely to leverage the shared free desktop stack (particularly Wayland and DBus). Unlike what took place in Firefox' project Electrolysis, however, we don't see a need to break extension compatibility in our case. For Plasma's extension API scope, we've always taken a conservative demand-based approach instead of allowing extensions free access to all data and code by default. This is paying dividends now, allowing us new shell architecture options while preserving the known, stable API contract it has with its extensions.

David is set to show off the R&D proof of concept we have working now in his talk at this year's Akademy conference, which I can't wait to attend. Be sure to also keep your eyes peeled on his blog, where he will dive deeper into the details of this project after the conference excitement.

In Summary

Plasma today is architected to prevent shell UI extensions from being able to crash your session and interfere with your apps. We are working to expand on this and prevent extensions from interfering with the shell.

In Context

One of the broad goals of Plasma 5 has been raising quality. This is a user-driven process. Converting feedback we got during the first generation of Plasma into software, we worked hard to bring Plasma users tangible improvements to speed, resource usage and UI polish (this is by no means over, either). We also already implemented a LTS release process to improve our support story.

Dove-tailing with the KDE community's Goals, climbing higher on the ladder of safety and security is one of our immediate next ones. Increasing process isolation in Plasma and achieving state of the art crash resilience and sandboxing, a likely first on the desktop, is a concrete engineering expression of this aim.

Sounds interesting? If you want to be part of a team and a community that keeps pushing the desktop (and not just the desktop) forward in the days to come, join us in one of our channels.

Of course:

That was a surprising find. Libreoffice wouldn't start anymore (just some splash screen with a progressbar, then nothing happens).

After some debugging (comparing my normal zsh session where it wouldn't start, with a clean `sudo -u dfaure bash` session where it worked), I found the culprit. I had QT_NO_GLIB=1 in my environment for some reason, and that's what breaks libreoffice...

Posting this in case it helps someone one day ;)

Like every year, the PIM developers met in Toulouse for a bit of bugfixing ;)

Except for Dan Vratil, we forgot to blog about it, here's a belated blog post with what we did there.

Upgrading from Leap 42.3 to Leap 15.0... How hard can it be? Well, there was a bit of fighting necessary. One fight due to an encrypted root partition, another one due to NVIDIA and libGL.

I used the zypper upgrade method, from a text virtual terminal (after stopping X), which always seems safer to me than booting on a USB disk and hoping the partition setup is correct.

Hi,

there is a new book on CMake (there are not many):
Professional CMake - A practical guide.

I haven't read it yet, so I cannot say more about it, but I guess it should be useful.

Here's "Babe" beta, but before let me talk to you about what's going on with "Babe" right now.

**********
if you're a student like me and want to start learning new things and work on a exciting open source project the following are some ways you could get involve.

If you feel like contributing and getting involve there are a lot of things you could start with:

Today is the release day for KEXI 3.1.0 Beta & its frameworks: https://community.kde.org/Kexi/Releases#3.1.0_Beta_1

Since version 3 it becomes KEXI not Kexi to suggest becoming a standalone app. It's standalone status includes being first-class app also outside of KDE Plasma. To make this real things such as useful yet simple file widget are developed or single click mode is really single click mode "even" on XFCE. Actually implementing optimal experience for Windows is quite similar to supporting XFCE.

Desktop icons in Plasma 5.12 LTS Beta (Click to enlarge)

Recent news in the Linux desktop community recall an interesting time in Plasma's history: Release 4.1 in 2008, Plasma's second release ever, that time we (in)famously abandoned desktop icons (sneak preview: they came back).

Of course we never really abandoned them. Instead, in 4.1 we initially debuted the Folder View technology, which powers most of the ways to browse file locations on a Plasma desktop. Folder View gives you folder widgets on the desktop, folder popups on your panels - and yes, desktop icons, which always remained a supported option. An option we, crucially, did decide to tick default-off at the time. Instead we chose to place a folder widget on the default desktop, in part to reinforce the then-new widget-oriented ways of doing things in Plasma, things older KDE desktops just couldn't do.

The Awkward Years

A telling sign in hindsight, many distributions reneged on our decision and turned icons on for their users anyway. And yet we had decided to throw the switch upstream; what next?

A period of research and experimentation followed. With all that newly freed-up screen real estate and a new modular architecture, we looked into alternatives for what a device homescreen could be. The PC during this time was in a mood to diversify as well, with new form factors popping up in stores. Some of our experiments took off - the Search and Launch interface we debuted alongside the Plasma Netbook spin in 4.5 directly inspired the popular Application Dashboard fullscreen overlay we introduced in Plasma 5.4. Others, like the Newspaper view, failed to find much of an audience.

The Application Dashboard overlay has its origins in the icons-off adventure (Click to enlarge)

Ultimately, though this period was productive in many ways, we didn't hit upon a clearly-better new homescreen. Elsewhere meanwhile, on a parallel track, the icon homescreen UI metaphor unexpectedly bounced back and grew stronger. Touchscreen handsets introduced a whole new generation of computer users to - essentially - desktop icons. In the following years we saw user numbers and familiarity with homescreen icons increase, not decrease.

The Lights are Back on and the Doors are Open

During the Plasma 5.10 dev cycle, we did a lot of polish work on the desktop icons experience. We then decided that it was time to stop hiding desktop icons support behind a config option: All things considered, the previous default was just not serving the majority of our users well. It had to change.

We still don't place any icons on the desktop by default. (Many distributions do - but they always did for all that time.) Those who enjoy the calm and tranquility of an empty desktop or don't want icons to get in the way of widgets were not impacted by this move. But drop a file or add an app to the desktop, and you now get an icon again, with full support for all of the powerful features KDE's desktops have always offered when dealing in files and links. For the many users who rely on desktop icons, this is a welcome reprieve from having to fiddle around post-install.

Icons of the Future

In the upcoming Plasma 5.12 LTS release, desktop icons are getting even better. We've done a truckload of work on improving the experience with multiple monitors, across which icons can be moved freely again, along with gracefully handling monitor hot plug/unplug. Performance and latency improvements, the key theme to 5.12 in general, have continued where 5.10+ left off, with the desktop reflecting file operations now faster than before.

We've worked though many of the most-reported feature requests and pain points for desktop icons throughout 2017, but we're not done yet. Folder View development continues in 2018 with more outstanding user requests on the horizon, so feel free to get in touch.

Check out the beta now and let us know what else you want out of desktop icons after 5.12!