Eike Hein on KDE Blogs

Bouncy Ball 3D and Taking KDE to the Pyramids

Eike Hein — Thu, 24 Sep 2026 00:00:00 +0000

During this year's Akademy, while celebrating KDE's 30th birthday, I found some time to do some hacking on a beloved old toy widget: the Bouncy Ball I used to maintain for a while, and which Filip recently made available for Plasma 6 again.

The all-new Bouncy Ball 3D - find it on the KDE Store (and by extension your Plasma's Add Widgets dialog) now - adds high-quality 3D graphics, more expressive physics with satisfying ball squish, and better support for living in and launching from a Plasma panel.

I have of course coordinated this with Filip a bit, and we agreed it's better to make this a seperate widget/release for now to keep the classic ball available for its fans.

Note the new widget requires at least KDE Frameworks 6.26+, i.e. around the Plasma 6.7 timeframe.

Enjoy the bounce!

While you bounce about, consider watching my Akademy 2026 presentation on taking KDE to the Great Pyramid in Egypt for high-tech archeological research.

A few thoughts on Plasma/Wayland, KWinFT

Eike Hein — Mon, 19 Oct 2020 00:00:00 +0000

There's a lot of intense, opinionated debate on the current state of Plasma's Wayland session these days. This seems to be fueled by mainly two events, Fedora's announcement to flip to Wayland by default for version 34 of their KDE variant, and a a recent fork of KWin and a few other components of Plasma, KWinFT.

On the first, I think it's a great move. Concerns of a repeat of the "shipped before it's ready" situation of early KDE 4 releases aside (for now; more on this in a moment), it certainly feels like it makes sense for Fedora in particular - it's a bold, technology-focused early adopter move, something I think the Fedora user audience generally appreciates the distro for. Plus other Fedora variants default to Wayland already, so there's an appreciable desire to make the various offerings more consistent.

Distros should understand the user audiences they're trying to cater to, and if a distro believes there's a market for a particular flavor of desktop, it's certainly fine to challenge upstreams to provide the needed software. I think as far as Plasma on Wayland is concerned, the challenge is thoughtfully timed - it's coming after the KDE community voted to declare good Wayland support a community-wide goal, after all. I think there's every reason to believe this decision will lead to good things if the two (and overlapping) communities collaborate to make a good showing. Nice.

It's 2020, for crying out loud! Why is this taking so long?

A lot of us have some things in common. For example, if you're reading this, chances are you are the sort of person who is not indifferent to technological progress, even easily excited by it. Many of us also are also drawn to competition.

So people really care about how far down the road to Wayland adoption every of the competing projects is, and theories abound on what the comparison says about them. This is set against a backdrop of Wayland also still maturing as an upstream technology, driven forward by the same competing projects working together.

One particular claim that's been popping into the conversation lately is that Plasma not having the Wayland conversion safely in it's rear-view mirror yet is evidence of a project that's somehow fundamentally flawed, and unable to focus on what matters and make good long-term plans and roadmaps. If you didn't encounter this in one of the heated debates on social media yet it probably sounds a bit breathless to you, or maybe not really worth acknowledging - but it's actually my main reason to write this blog post, because it's an interesting excuse to talk about recent Plasma history!

Plasma 5.0 was the second large-scale rewrite of KDE's desktop environment offering in a row, meaning both 4.0 and 5.0 had debuted with a lot of new and young lines of code inside them. Both rewrites were motivated by lifting the desktop shell to a newer set of its base technologies - for example major versions of Qt, OpenGL-based UI rendering and so on. Younger code tends to have higher defect rates. At the time, the standard criticisms in online discussions about Plasma went something like this:

"It looks great, but it's really buggy" "I like a lot of the features, but it's missing those last 5% to fit my needs fully" "It's resource-heavy and doesn't perform smoothly enough on my machine"

And a less concrete one, but nearly as often repeated:

"It's really coming together now, but I'm already worried about the next major version being another rewrite and making it shaky"

The Plasma project paid attention, and made a number of very strategic decisions to set its focus on a set of goals:

Improve quality across the board by prioritizing bugs and bringing defect rates down
Go the distance with features, drive them to completion and make them easier and more consistent to use
Lower the resource needs and scale down to much lower-powered hardware, including ARM SBCs
If we do additional rewrites of fundamental code (and we ended up replacing major pieces in 5.x point releases, e.g. the entire taskbar, menu and notification systems - each of those quietly addressed dozens of bugs, but went mostly noticed for a few new features), there needs to be a noticeably positive impact on the above metrics

This remains the spirit of the Plasma project today, with many activities spanning multiple quarters of a year of work at the service of those goals. Recent examples include the Breeze visual refresh undertaken by the Visual Design Group, the revamp of session init with optional use of systemd, and the new cgroups-loving way of running apps.

For Plasma on Wayland, this meant: While we strongly believing in the tech, we would take our time to get it right, and not declare the offering ready before it isn't up to par. It also wasn't always the highest-priority development activity going on, with many other steps being simultaneously taken to reach our goals. Reasonable people can (and do) have diverging opinions on the relative prioritization of work, of course, but the path we walked was most definitely a consciously strategic one - one that has lead to the gradual disappearance of those earlier quotes from user feedback we receive, speaking to its execution. Work continues!

KwinFT

One source of these concerns is the KWinFT project, a recent fork of the compositor service in a Plasma system along with a few choice pieces of support code (e.g. the screen config subsystem).

KWinFT is a project by Roman Gilg, a contributor to KWin and KDE in general. Roman will not be shocked by reading this, as we had this discussion a couple of months before he announced the project, as well as recently, but I don't think the fork was necessary, or is a very good idea overall. I think his technical ideas for KWin are interesting, and think there were better options to deliver their value to users and have a bigger impact in the end, e.g. by making more aggressive use of feature/staging branches to prove out subsystem rewrites before merging them up. This is a suggestion I made at the time, too, and I haven't seen anything to change my mind since. We certainly keep talking.

This is a very personal opinion and speaks to my own style to open source involvement more than anything, which is shaped by the vibe of the KDE community and the KDE mentors and role models I received my education from. I believe in prioritizing user value, and in leadership by aligning diverse talents towards common goals, by being inviting, communicative and persuasive. I really don't believe these options were fully exhausted in this matter, and while I understand that starting a new project can make it easier to try out e.g. some different organizational ideas (and my impression of the fork is that it's really more about those than any actual tech disagreements) without having to do the work of getting others on board, I don't think this ultimately succeeds in bringing improvements to the max number of people who might benefit from them.

On the tech side, though, it's important to keep the focus of the conversation on Plasma on Wayland as a whole. KWin is an important component of that system, but owing to its multi-process architecture, it's only one of a fairly large and varied set of codebases that need to complete their porting efforts. Many use cases additionally require coordinated activity across several components (for example: the taskbar, System Settings, ...), and it's also still not too difficult to identify needed upstream improvements in Wayland to get over the finish line, some of which the Plasma team is currently driving forward.

And no, this isn't stacking features on shaky foundations - most of this work is technically orthogonal (easy to see for the ones that aren't in the same codebase or even project!), and in any case, the more pleasant Plasma's Wayland session becomes to consume, the higher the set of potential contributors exposed to the remaining tasks. Those attention dynamics of open source are fairly reliable :-). In any case, this is perhaps actually my main beef with the technical criticisms coming from the debates surrounding KWinFT - they are myopically focused on KWin and derive from this grander projections, ignoring the full picture of the system and a lot of other heavy-hitting technical activity all throughout it (including some of the projects linked throughout this post). The resulting signal-to-noise ratio is not very engaging overall. KWin != Plasma is an important constraint to add to them.

Linux desktop shell IPC: Wayland vs. D-Bus, and the lack of agreement on when to use them

Eike Hein — Sun, 11 Oct 2020 00:00:00 +0000

On the Linux desktop today, we have two dominant IPC technologies in use between applications and the desktop environment: Wayland and D-Bus. While created for different reasons, both are generically extensible and can be used to exchange data, synchronize state and send requests and signals between peers. A large number of desktop use cases are implemented using either technology, and some use cases are already distributed across both of them. The status quo is mostly the result of organic growth, with individual implementation choices down to tech friction or the lack thereof.

For some use cases the choice of which to use is not obvious. This is one of the factors still slowing down the standardization and hence adoption of Wayland-based sessions currently.

The overlap

While the semantics of Wayland and D-Bus are really pretty different, both enable the exchange of structured, typed data between peers along with RPC-shaped uses. While D-Bus supports many more connection topologies than just one process talking to another, for applications interacting with the desktop environment via protocols both parties agree on the difference is small and usually hidden by toolkit abstractions.

More importantly, both technologies were created to service the same key users - desktop environments and application toolkits - and widely adopted protocols layered over both transports deal in some of the same primitives coming from that ecosystem. For example, .desktop file names as stable application ids are referenced in both the Wayland xdg-shell protocol as well as well as <a href="https://www.freedesktop.org/wiki/>freedesktop.org's <a href-"https://specifications.freedesktop.org/notification-spec/latest/>notifications protocol.

The current usage split between the two protocols is a result of tech friction and little planning - some things are easier to talk about on a Wayland connection, others are easier to talk about on the D-Bus. It's down to the protocols we already have in hand now, adoption in various codebases and a spectrum of opinions.

Tech friction

Wayland (cool book link this time!) is the designated successor to the venerable X windowing system. Born from the same community, it's certainly informed by some of X's successes, but also many of the pain points experienced by implementers of X over the years. A lot of the advances in Wayland relate to the particular problems of windowing and presentation, but its heritage also did much to set the scene for revisiting what really belongs into the core windowing system and what doesn't. D-Bus and even its own direct predecessors did not exist for much of X's long and storied history. Conversely, in the Wayland world it has become a lot harder (in terms of scrutiny applied by the community) to get a desktop feature into a widely-adopted spec than it was in X, which for a long time was the only widely adopted transport medium in place.

D-Bus is a far more generic IPC/RPC technology supporting a wider variety of connection patterns between parties. Service activation through the bus, multicast signals open to any participant, pervasive introspection of interfaces - you won't find much of this in Wayland, and D-Bus is the latest in a chain of technologies driven by genuine needs for such capabilities.

There's a third element to the discussion, and it's the rise of the freedesktop.org standards ecosystem, broadly promoting interoperability between desktop environments and the portability of apps between them. Put on a timeline, freedesktop.org and D-Bus happened a decent number of years prior to the arrival of Wayland - D-Bus, therefore, has a headstart in being the medium of choice for freedesktop.org specs and fd.o standards being referenced in protocol and service designs.

In the end:

Wayland is the natural transport between the application and the compositor, one of the key services of the desktop environment. Windowing being the goal, a lot of the protocols in place now make it easy for the two parties to converse at the level of windows. In xdg-shell, the application can also let the compositor know its application id as part of window metadata. This is one of several established ways for the compositor to know what application it's talking to. (A more recent aid is mapping from the client to a cgroup set up by the application launcher, e.g. Flatpak or Plasma, which can improve the security of this type of authentication. In both Wayland and D-Bus, you sometimes see this need - and much more - addressed by inserting a protocol proxy like xdg-dbus-proxy or Sommelier, respectively.)
D-Bus is the transport used for many other app-to-service interactions, e.g. notifications. On D-Bus it's often convenient to find the application id of a participant, but it's hard to relate the conversation to the windowing system. For example, efforts to relate a D-Bus notification event to a particular window to jump to are fairly recent and not yet widely implemented.

The decision vacuum

There's a particular snag in the timeline: With D-Bus arriving on the scene a lot later than X, a lot of interactions between apps and the desktop environment were spec'd into the X medium in the past. For example, various forms of window or broadly application state (e.g. requesting user attention) or requesting focus/activation from the window manager. No one thought to put onto D-Bus what was widely adopted and working already, although sometimes more comprehensive replacements gravitated towards using D-Bus instead and managed to get traction.

With X being replaced, a lot of the stuff in ICCCM and EWMH/NetWM is now up for grabs for either Wayland- or D-Bus-based specs.

Current trends: Plasma vs. Gnome vs. wlroots/Sway

Wayland is the natural choice for a compositor service to talk to apps. D-Bus is the most popular option for other desktop environment services to talk to apps. In some desktop environments, the compositor and other services may live in the same process (Gnome Shell in particular), others distribute services over few or many processes.

In Plasma, the compositor and the desktop shell are two seperate processes. The compositor implements the window management policy, and the desktop shell process draws your wallpaper, your panels and your menus. The notifications service lives in the Plasma desktop shell process as well. This architecture is a straight port-over from the X way of doing things, but it remains advantageous - for example, a crash in the shell won't bring your compositor (and then your apps) down with it. In fact, we're aiming for still more process isolation in future generations of Plasma.

The compositor and the shell being in different processes requires them to synchronize state. The shell also needs to pose requests to the compositor. In Plasma, this communication happens through a set of Plasma-specific Wayland protocols. This is a good example of a friction-driven implementation choice: As the shell and the compositor want to mainly converse about windows, using Wayland posed the least friction. On the other hand, in cases of the compositor talking to support processes such as the screen configuration service or the System Settings app, the choice of transport varies - Wayland protocols in some cases, D-Bus interfaces for others (notably virtual desktops configuration). Overall, we don't have a clear IPC usage policy at the moment.

For other desktop environments I cannot speak with any true authority, especially make no claims about implementation policy. Perhaps owing to the single-process shell architecture, I see our friends at Gnome using D-Bus-based protocols in a few places where we use Wayland-based ones, e.g. for screen configuration (edit: lack of friction between D-Bus and XDG desktop portals has been pointed out to me as another factor; makes sense).

The wlroots community (consisting of Sway and lots of other users) seems to broadly prefer Wayland over D-Bus to run protocols through. It's easy to surmise why - wlroots' raison d'être is to enable building shells on top of Wayland, and in particular shells built up of interoperating pieces made by distinct authors. Enabling this interoperability through the community's Wayland-based tooling must come naturally, and the wlroots community is no doubt leading this particular effort at the moment. Some of these protocols are great, and it's likely Plasma will implement more of them in the future.

Unresolved cases

An example where the lack of a clear choice has been slowing the desktop community down is focus/activation requests. Consider the following common usage pattern: The user clicks a link in a chat app. It opens in the default browser. For convenience, the user might want the browser window to be raised to the front now, the click being an instruction to the system to form a smooth workflow from one app to the other.

It might come as a surprise, but 12 years in, there's no good, widely-adopted solution to making this work in Wayland-based desktops.

It should not come as a surprise, however, that this an example handled in the past by an X-based protocol that's now out of the picture. The X way of doing things wasn't very robust - it put a lot of trust into the application posting a legitimate request to be activated, and it required the window manager to implement complicated heuristics to filter out illegitimate or just ill-timed requests. These heuristics are collectively known as "focus stealing prevention", e.g. sticking to the current window while the user is typing into it. For now, Wayland-based desktops by and large are skating by on even poorer semantics - giving focus to any new window while relying on heuristics, with partial solutions to the problem of already-existing windows not pervasively implemented across apps.

It's a good example of a case where the community really doesn't want to miss a chance to get it right this time. While trying to do so, a lot of more or less related desktop features have been looked at as well - for example, the X convention of apps placing attention hints on their windows to blink them in the taskbar, to be cancelled by the window manager when the window is raised and focused. Also the case of applications posting notification events through D-Bus carrying a link back to particular window, e.g. to jump from a chat message alert bubble to the specific conversation window.

Over the last couple of years, many different approaches have been proposed and tried, and we still don't have the One True Spec.

There seems to be fairly solid agreement on the need for a token exchange mechanism to clear the focus handover in the compositor - the chat app requests a token from the compositor, hands it to the browser handling the link (e.g. through an environment variable) and the browser may use it to request focus from the compositor. But there remains a lot of division over whether the activation request (along with other use cases) should be layered over the D-Bus-based notification spec, or whether all of this should remain solidly Wayland territory:

The argument for D-Bus is that a mechanism to relate notification events to particular windows (by including a window handle in the metadata) is needed anyway, and once that's in place, it's easy to add in the focus token. Using special notification events to inform about window-specific ongoings is an extensible pattern potentially spanning all of activation and attention-seeking, along with things like taskbar job progress meters and others. The event spec also already has fields useful for accessibility - imagine a system where a blind user gets a "app X wants attention for Y" readout, without needing to craft a new protocol to tell the compositor specifics about Y. On the other hand, going this route clearly also requires some spec work for existing notification service implementations to be able to do the right thing when processing these special events.
The argument for Wayland is that the above requires a lot of translation forth and back (or rather, import and export of handles and tokens), and in the case of multi-process service architectures, expensive chaining of IPC. Plus it requires a Wayland-based desktop environment to use D-Bus for a core use case, while an X11-based desktop environment could do without a second transport for the same features. For some projects, this is an unattractive expansion of their current dependencies.

In conclusion

I suspect the above example of focus/activation requests will ultimately be addressed by a token exchange via Wayland, and the notification spec way of doing things will be implemented alongside it as well, rather than picking one way of doing things. And perhaps that's fine.

But it's worth stopping for a moment and being conscious of what's going on. We would all benefit from some commonly agreed-upon guidelines on where the scopes of Wayland and D-Bus end in our application platform, and where they overlap. Where does the windowing system start and end? Where should new protocols go? We also want to be smart in spec'ing out how the two mediums relate to each other, and making translations from one of the other safe and robust.

In addition to our regular comm tools of forges and merge requests, a natural venue for these kinds of discussions is the Linux App Summit, an event co-hosted by KDE and Gnome. LAS 2020 is just one month away. Perhaps it's a good chance for a sit-down about these things.

Using Architecture Decision Records (ADRs) in KDE?

Eike Hein — Fri, 11 Sep 2020 00:00:00 +0000

Over at Akademy 2020, I just witnessed a fantastic talk by KDE contributor mainstay Kévin Ottens on "Lost Knowledge in KDE". In the presentation, Kévin showed us a series of examples of sophisticated solutions to important problems KDE has innovated and implemented over the years - and subsequently lost knowledge of, applying them sparingly or inconsistently, or developing new solutions redundantly. He also talked about how this is a familiar problem to organizations, with a research field known as knowledge management itself looking to develop solutions and tools to combat this problem since the late 20st century.

He also highlighted how we don't use comm tools with higher knowledge retention factors - blogs, mailing lists, media with more permanent discussion records - as much anymore. So here's a suggestion in blog form! :-)

Within the wider open source as community as well as industry, the idea of writing Architecture Decision Records has recently become quite popular. ADRs are not really a new tool - surely forms of it have been around for a long time in various organizations - but giving the renaissance of the concept a name has a lead to ample discourse on its pros an cons, and plenty of resources available.

To give my take, an ADR is a concise write-up of a particular project/community decision. It should have enough detail to make the decision understandable, as well as cover its context and implications. They usually have an owner and co-authors, and are finalized via a light peer-review process. It's a bit like drafting and finalizing a PEP, another popular tool - except instead of motivating a change, it is describing a decision, to serve as a cache and make sure future discussions and changes have a frame of reference to work with. In this sense, it's a bit like KDE Manifesto, which has served us rather well.

ADR's aren't perfect - they can't and shouldn't replace other forms of documentation, such as API docs and protocol specs. They also have a problem with indexing - while being able to refer to/link to a particular ADR is extremely useful when someone is aware of the relevant ADR already, they're little information silos that are hard to dive into in flat-list format. But the big pro is that they have a low barrier of entry due to the lower effort and process overhead required compared to other forms of documentation, if implemented well. They make it more likely for documentation to be written.

KDE's design community has recently started making use of this idea, writing down some decisions that otherwise had a tendency to be re-discussed again and again: Design Lessons Learned.

I think we could co-opt the ADR idea and apply it to a lot of the examples Kévin showed, to record the needs and thinking that lead to building various solutions and frameworks we have: What problem were we trying to solve? Why was it better than we had before? How does the minimum bar look like now that we have the solution? Where should the solution be applied without fail? What alternatives were discussed and discarded before making the solution?

All we'd need to get started is a wiki space, a good ADR template, a minimal kdereview-like process, and a few good examples to seed the list ...

Introducing Kirogi: A ground control application for drones

Eike Hein — Sun, 08 Sep 2019 00:00:00 +0000

Today I'm in beautiful Milano, Italy, where the KDE community has gathered for its annual user and developer conference, Akademy. At Akademy I've had an opportunity to present my new KDE project to a larger audience: A ground control application for drones, Kirogi.

Kirogi's direct flight controls screen

Kirogi aims to enable the operation of drones of all sorts of makes and models in an approachable and polished manner, with both direct and map-based control modes and many more features planned for the future.

The origin story behind the Kirogi project is a classic open source tale. During this year's Lunar New Year holiday, I was paying a visit to family in Busan, South Korea (the name Kirogi is Korean and means wild goose). During the off-days I ended up buying my first drone. I attempted the first flight in my mother-in-law's living room. Unfortunately the official vendor application immediately started crashing after take off - much to my embarassment, I couldn't land the thing! Eventually it slowly drifted towards a very nice armchair (sorry mom!) and crashed on contact with an emergency engines-off.

Turns out the app I was using had been replaced by a newer, seperate app store upload intended for a newer drone - and the app I had wasn't fully compatible with a newer version of the phone's OS anymore. I realized open source can serve drone owners better there and started hacking on this new KDE application a few days later.

Since then I've received a lot of support and help from many people in the fantastic KDE community, including Krita-powered artist L. 'AsmoArael' C., who responded to a request I posted KDE's Artists Wanted forum and helped me realize Kirogi's mascot:

Kirogi's mascot, a farm goose and technology enthusiast

If you want to know more about the project's origins and dive further into the technical details, I invite you to check out the slides for the talk I gave today. It was recorded on video as well; I will add a link once it's been made available.

The project also has a website already. Along with much additional information on the project it features download links for nightly development builds.

Plasma sprint, 2019 edition; personal updates

Eike Hein — Tue, 16 Jul 2019 00:00:00 +0000

In June, I had a great time at a series of KDE events held in the offices of Slimbook, makers of fantastic Neon-powered laptops, at the outskirts of Valencia, Spain. Following on from a two-day KDE e.V. board of directors meeting, the main event was the 2019 edition of the Plasma development sprint. The location proved to be quite ideal for everything. Slimbook graciously provided us with two lovely adjacent meeting rooms for Plasma and the co-located KDE Usability & Productivity sprint, allowing the groups to mix and seperate as our topics demanded - a well-conceived spatial analog for the tight relationship and overlap between the two.

The Plasma team walked the gorgeous Jardí del Túria almost every day during their sprint week to stay healthy and happy devs.

As always during a Plasma sprint, we used this opportunity to lock down a number of important development decisions. Release schedules, coordinating the next push on Plasma/Wayland and a new stab at improving the desktop configuration experience stand out to me, but as the Dot post does a fine job providing the general rundown, I'll focus on decisions made for the Task Manager widgets I maintain.

On one of the sprint mornings, I lead a little group session to discuss some of the outstanding high-level problems with the two widgets (the regular Task Manager and the Icons-only Task Manager), driven by frequent user reports:

Poor experience performing window management on groups of windows
Unnecessary duplication in the UI displaying window group contents
Unintuitive behavior differences between the two widgets

To address these, we came up with a list of action items to iteratively improve the situation. Individually they're quite minor, but there are many of them, and they will add up to smooth out the user experience considerably. In particular, we'll combine the currently two UIs showing window group contents (the tooltip and the popup dialog) into just one, and we'll make a new code path to cycle through windows in a group in most recently used order on left click the new default. The sprint notes have more details.

Decision-making aside, a personal highlight for me was a live demo of Marco Martin's new desktop widget management implementation. Not only does it look like a joy to use, it also improves the software architecture of Plasma's home screen management in a way that will help Plasma Mobile and other use cases equally. Check out his blog post for more.

I got a new laptop. Slimbook founder Alejandro López made it a proper computer by attaching a particularly swanky metal KDE sticker during the preceding KDE e.V. board sprint.

In KDE e.V. news, briefly we stole one of the sprint rooms for a convenient gathering of most of our Financial Working Group, reviewing the implementation of the annual budget plan of the organization. We also had a chance to work with the Usability goal crew (have you heard about KDE goals yet?) on a plan for the use of their remaining budget -- it's going to be exciting.

As a closing note, it was fantastic to see many new faces at this year's sprint. It's hard to believe for how many attendees it was their first KDE sprint ever, as it couldn't have been more comfortable to have them on board. It's great to see our team grow.

See you next sprint. :)

In more personal news, after just over seven years at the company I'm leaving Blue Systems GmbH at the end of July. It's been a truly fantastic time working every day with some of the finest human beings and hackers. The team there will go on to do great things for KDE and personal computing as a whole, and I'm glad we will keep contributing together to Plasma and other projects we share interests and individual responsibilities in.

As a result, the next ~10 weeks will see me very busy moving continents from Seoul back to my original home town of Berlin, where I'll be starting on a new adventure in October. More on that later (it's quite exciting), but my work on the KDE e.V. board of directors or general presence in the KDE community won't be affected.

That said -- between the physical and career moves, board work and personal preparations for Akademy, I'll probably need to be somewhat less involved and harder to reach in the various project trenches during this quarter. Sorry for that, and do poke hard if you need me to pick up something I've missed.

And of course:

Join the first KDE e.V. board dinner of 2019

Eike Hein — Wed, 02 Jan 2019 00:00:00 +0000

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.

Engineering Plasma: Extensions and stability — Present and future

Eike Hein — Thu, 02 Aug 2018 00:00:00 +0000

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:

Off and On Again: The story of KDE Plasma's desktop icons; 5.12 improvements

Eike Hein — Wed, 24 Jan 2018 00:00:00 +0000

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!

Community goal: Modern and Global Text Input For Every User

Eike Hein — Tue, 24 Oct 2017 00:00:00 +0000

A few months ago, I had the opportunity to give a talk on Input Methods in Plasma 5 at Akademy 2017 in lovely Almería in Spain. If you were interest in my talk but were unable to attend, there's now video (complementary slides) available courtesy of the Akademy conference team. Yay!

A big part of my talk was a long laundry list of issues we need to tackle in Plasma, other KDE software and the wider free desktop ecosystem. It's now time to take the next step and get started.

I've submitted the project under Modern and Global Text Input For Every User as part of the KDE community's new community goals initiative, a new thing we're trying exactly for challenges like this - goals that need community-wide, cross-project collaboration over a longer time period to achieve.

If you're interested in this work, make sure to read the proposal and add yourself at the bottom!

Come dine with the KDE e.V. board in Berlin in October!

Eike Hein — Sat, 30 Sep 2017 00:00:00 +0000

As has become tradition in recent years, the KDE e.V. board will have an open dinner alongside its in-person meeting in Berlin, Germany on October 14th, at 7 PM.

We know there will be a lot of cool people in town next month, thanks to a KDE Edu development sprint, Qt World Summit, the GNOME Foundation hackfest and probably other events, and you're all invited to drop by and have a chat with us and amongst yourselves - and enjoy good food.

We're still picking out a location currently, so if you're interested in attending, please drop me a mail to pre-register and I will (space permitting) confirm and send details soon.

Konversation 2.x in 2018: New user interface, Matrix support, mobile version

Eike Hein — Tue, 05 Sep 2017 00:00:00 +0000

It's time to talk about exciting new things in store for the Konversation project!

Konversation is KDE's chat application for communities. No matter whether someone is a newcomer seeking community, a seasoned participant in one, or a community administrator: our mission is to bring groups of people together, allow them to delight in each other's company, and support their pursuit of shared interests and goals.

One of the communities we monitor for changes to your needs is our own: KDE. Few things make a Konversation hacker happier than journeying to an event like Akademy in Almería, Spain and seeing our app run on many screens all around.

The KDE community has recently made progress defining what it wants out of a chat solution in the near future. To us, those initial results align very strongly with Konversation's mission and display a lot of overlap with the things it does well. However, they also highlight trends where the current generation of Konversation falls short, e.g. support for persistence across network jumps, mobile device support and better media/file handling.

This evolution in KDE's needs matches what we're seeing in other communities we cater to. Recently we've started a new development effort to try and answer those needs.

Enter Konversation 2.x

Obligatory tantilizing sneak preview (click to enlarge)

Konversation 2.x will be deserving of the version bump, revamping the user interface and bringing the application to new platforms. Here's a rundown of our goals:

A more modern, cleaner user interface, built using Qt Quick and KDE's Kirigami technology

Adopting a responsive window layout, supporting more varied desktop use cases and putting us on a path towards becoming a desktop/mobile convergent application
Scaling to more groups with an improved tab switcher featuring better-integrated notifications and mentions
Redesigned and thoroughly cleaned-up settings, including often-requested per-tab settings
Richer theming, including a night mode and a small selection of popular chat text layouts for different needs

Improved media/file handling, including image sharing, a per-tab media gallery, and link previews
A reduced resource footprint, using less memory and battery power
Support for the Matrix protocol
Supporting a KDE-wide Global and Modern Text Input initiative, in particular for emoji input
Versions for Peruse, Calligra Gemini, Gwenview, and others. When we tried it out Kirigami quickly proved useful to us as well. We've been enjoying a great working relationship with the Kirigami team, with code flowing both ways. Check it out!

Design process

To craft the new user interface, we're collaborating with KDE's Visual Design Group. Within the KDE community, the VDG itself is a driver of new requirements for chat applications (as their collaboration workflows differ substantially from coding contributors). We've been combining our experience listening to many years of user feedback with their design chops, and this has lead to an array of design mockups we've been working from so far. This is just the beginning, with many, many details left to hammer out together - we're really grateful for the help! :)

Matrix

Currently we're focused on bringing more of the new UI online, proving it on top of our robust IRC backend. However, Matrix support will come next. While we have no plans to drop support for IRC, we feel the Matrix protocol has emerged as a credible alternative that retains many of IRC's best qualities while better supporting modern needs (and bridging to IRC). We're excited about what it will let us do and want to become your Matrix client of choice next year!

Work done so far

The screenshot shown above is sort of a functional R&D mockup of where we're headed with the new interface. It runs, it chats - more on how to try it out in a moment - but it's quite incomplete, wonky, and in a state of flux. Here's a few more demonstrations and explorations of what it can do:

Responsive window layout: Front-and-center vs. small-and-in-a-corner (click for smoother HD/YouTube)

Friction-free switching to and from settings mode (click for smoother HD/YouTube

Overlay context sidebar: Tab settings and media gallery will go here (click to enlarge)

See a gallery with an additional screenshot of the settings mode.

Trying it out

The work is being carried out on the wip/qtquick branch of konversation.git. It needs Qt 5.9 and the master branch of kirigami.git to build and run, respectively. We also have a Flatpak nightly package soon on the way, pending sorting out some dependency issues.

Be sure to check out this wiki page with build and testing instructions. You'll learn how to retrieve either the sources or the Flatpak, as well as a number of command line arguments that are key when test-driving.

Sneak preview of great neat-ness: It's possible to toggle between the old and new Konversation UIs at any time using the F10 key. This makes dogfooding at this early stage much more palatable!

Joining the fun

We're just starting out to use this workboard on KDE's Phabricator instance to track and coordinate tasks. Subscribe and participate! Phabricator is also the platform of choice to submit code contributions.

As noted above, Konversation relies on Kirigami and the VDG. Both projects welcome new contributors. Helping them out helps Konversation!

To chat with us, you can stop by the #konversation and #kde-vdg channels on freenode (using IRC or the Matrix bridge). Hop on and introduce yourself!

Side note: The Kirigami team plans to show up in force at the KDE Randa meeting this fall to hack on things the Konversation team is very much interested in, including expanding support for keyboard navigation in Kirigami UI. Check out the Randa fundraising campaign which e.g. enables KDE to bring more devs along, it's really appreciated!

Join us at Akademy 2017 in Almería!

Eike Hein — Fri, 19 May 2017 00:00:00 +0000

This July KDE's user and developer community is once again going to come together at <a href=''https://akademy.kde.org/2017">Akademy, our largest annual gathering.

I'm going there this year as well, and you'll even be able to catch me on stage giving a talk on Input Methods in Plasma 5. Here's the talk abstract to hopefully whet your appetite:

An overview over the How and Why of Input Methods support (including examples of international writing systems, emoji and word completion) in Plasma on both X11 and Wayland, its current status and challenges, and the work ahead of us.
Text input is the foundational means of human-computer interaction: We configure or systems, program them, and express ourselves through them by writing. Input Methods help us along by converting hardware events into text - complex conversion being a requirement for many international writing systems, new writing systems such as emoji, and at the heart of assistive text technologies such as word completion and spell-checking.

This talk will illustrate the application areas for Input Methods by example, presenting short introductions to several international writing systems as well as emoji input. It will explain why solid Input Methods support is vital to KDE's goal of inclusivity and how Input Methods can make the act of writing easier for all of us.

It will consolidate input from the Input Methods development and user community to provide a detailed overview over the current Input Methods technical architecture and user experience in Plasma, as well as free systems in general. It will dive into existing pain points and present both ongoing work and plans to address them.

This will actually be the first time I'm giving a presentation at Akademy! It's a topic close to my heart, and I hope I can do a decent job conveying a snaphot of all the great and important work people are doing in this area to your eyes and ears.

See you there!

Complex text input in Plasma

Eike Hein — Thu, 06 Apr 2017 00:00:00 +0000

Surprisingly not enough

A brief note: If you're a developer or user of input methods in the free desktop space, or just interested in learning about "How does typing Chinese work anyway?", you might be interested in a discussion we're now having on the plasma-devel mailing list. In my opening mail I've tried to provide a general overview about what input methods are used for, how they work, who they benefit, and what we must do to improve support for them in KDE Plasma.

Bringing high-quality text input to as many language users as possible, as well as surfacing functionality such as Emoji input and word completion in a better way, is something we increasingly care about. With the situation around complex text input on Wayland and specifically KWin still in a state of flux and needing-to-crystallize, we're looking to form closer ties with developers and users in this space. Feel free to chime in on the list or hang out with us in #plasma on freenode.

Fear not, OMG! Ubuntu! You will bounce again!

Eike Hein — Fri, 10 Mar 2017 00:00:00 +0000

Serving the quadruped audience

Intrepid journalist Joey Sneddon over at OMG! Ubuntu! recently pointed out to us that Plasma 5 is currently not doing so well when it comes to serving an important user demographic - bored cats!

Indeed, Plasma 5.0 cost them (and us) the Bouncy Ball widget. And the reasoning mentioned in the article ([...] when trying to develop a professional experience toys and gimicks aren’t a good thing to be shipping by default [...]) is actually pretty solid I think. Hmm.

Have we lost our bounce forever? No!

But! These days we have the sexy KDE Store going on, which is a great place to put toys and gimmicks (along with neat menus).

So it's back! Behold the demo:

Bouncy Ball v2.0 on Plasma 5

You can grab it now for your Plasma 5 via Add Widgets... in your desktop menu and then Get new widgets in the Widget Explorer, or check out the Bouncy Ball store page.

Now for some additional fine print, though: I wrote this at ludicrous speed over a Friday night, and it's not well-tested. It behaves a little quirky sometimes (the goal was to match the original closely, but I didn't have a running KDE 4 to refer to). And despite the v2.0 moniker, it's still missing some of the features of the old Ball, including auto-bounce and that satisfying Boing! sound on collisions. I went with v2.0 in honor of the heritage - I'll polish it and add back the missing features a little later!

Update Bouncy Ball v2.1 is now on the store with sound support, auto-bounce, much better mouse response, a configurable simulation tick and a few bugfixes!

Plasma 5.10: Folder View as default desktop mode

Eike Hein — Wed, 01 Mar 2017 00:00:00 +0000

New defaults: Plasma 5.10 with desktop icons

A brief history lesson

To set the stage, we need to briefly recap some of the problems with the KDE 3.x desktop that (among others) Plasma initially set out to solve.

In the KDE 3.x desktop, three separate applications performed the duties of today's Plasma shell. kicker was in charge of putting panels on screen edges, kdesktop put wallpapers and desktop icons on screens, and SuperKaramba allowed for (quite shakily) putting widget windows in an extra layer between the desktop and application windows. kdesktop was essentially non-extensible (i.e. you couldn't make it put anything other than icons on the desktop by installing an add-on of some kind), while kicker and SuperKaramba could be extended by new plugins at runtime, but using incompatible plugin formats that couldn't share any code and had to do their work using entirely different sets of APIs.

With Plasma 4.0, things got a lot better. Plasma widgets need to be written only once, using one set of APIs, and can then be added to both the desktop and to panels - tuning their UI to their respective surroundings. Moreover, things like the desktop and panels themselves are plugins as well, and can be similarly swapped out (allowing us to make very different UIs for different devices within the same framework). And multiple plugin can share the same data sources in the back, also cutting down on overhead.

Enter Folder View

Folder View is one of the bundled plugins, and it illustrates many of the above concepts. It does what kdesktop used to do - visualize folder contents. But not only can you use it to put icons on the desktop, you can also put additional Folder View widgets on top of that desktop, or put Folder View in your panel, all of them showing different folders. In the panel, it will usually take the form of a button that brings up a popup (which can use either list or icon view modes), but it will expand into the panel itself if the panel is roomy enough, allowing even for a file system sidebar.

No more icons on the desktop?

Back in Plasma 4.0, we made the decision not to use Folder View as the default desktop layout (default being the operative term - users could change this in config, returning to a more traditional icon desktop). Instead, we left the desktop surface empty by default, and had Plasma add a Folder View widget on top of it.

We had reasons for that. We wanted to let users know about Plasma's new abilities: highlight its more modular nature, encourage experimenting with new setups and personalized mix-and-match. We didn't want the desktop to be constrained by the skeuomorphic desktop metaphor that at the time looked like it might well be on the way out (as indicated e.g. by a pervasive shift from spatial to browser-style file management across systems). It was exciting to ponder what things might fill the void left by shedding those icons.

Yes - icons on the desktop

More recent history has shown, however: Icons are here to stay. In mobile, there's been an explosion of new platforms that have really doubled-down on the icons-on-the-homescreen thing, making it more popular than ever. Many of those platforms also mix in widgets as we do, meaning nine years after 4.0, both our long-time and our still to-be-recruited users get all of this with ease now. We no longer need to try so hard when it comes to doing the onboarding for Plasma's key concepts.

The evolved landscape leads us to believe that Folder View is now the better default, and this is what Plasma 5.10 will be shipping (some distributions, of course, have beaten us to this, or have always done so). It will still be possible to have an empty desktop (it's that "Layout" option in the desktop settings), but it's a role-reversal in what's opt-in and what's opt-out. Likewise, extending Plasma with new desktop layouts is of course also still possible.

Better icons on the desktop

Given Plasma 5's incarnation of Folder View is about to be put front and center, we're putting a lot of effort into making it really shine throughout the 5.10 development cycle. Performance has been improved greatly. We've been thoroughly auditing for interaction issues, sorting through feedback and talking to people about how they use Folder View. This has lead to numerous small improvements, often subtle, that improve the feel of using Folder View - e.g. tuning the sizes of various hitboxes and hitpoints to make rectangle selections and dragging icons around that extra bit less cumbersome. Sizes and spacing have been tweaked as well in response user feedback, resulting in a tighter icon grid than before. And there's even some cool new functionality as well.

How you can help

We're committed to making the default experience of Plasma 5.10 - desktop icons included - rock more than ever. If you want to help, several distributions offer live images or packages of current development snapshots. Use them to take a long good look at Folder View, and then let us know about your experience!

Plasma 5.10: Spring-loading in Folder View; performance work

Eike Hein — Tue, 31 Jan 2017 00:00:00 +0000

I was sorely remiss not to blog more during the Plasma 5.9 dev cycle. While 5.9 packs a fair amount of nice new features (e.g. here's the widget gallery in Application Dashboard at some point during development), there was not a peep of them on this blog. Let me do better and start early this time! (With 5.9 out today ...)

Folder View: Spring-loading

Spring-loading functionality in Plasma 5.10's Folder View (click for on the KDE Store and install it via Add Widgets... -> Get new widgets in your Plasma.

Please note that Simple Menu requires Plasma v5.9 (to be released tomorrow). Actual v5.9, not the v5.9 Beta - it relies on fixes made after the Beta release.

Ethics in engineering

Eike Hein — Wed, 16 Nov 2016 00:00:00 +0000

Powerful: The Code I'm Still Ashamed Of

Things like this are a big reason why I work in open source.

KDE neon Korean Developer Edition (... and future CJK Edition?)

Eike Hein — Tue, 27 Sep 2016 00:00:00 +0000

While not being advertised on the KDE neon main page just yet (and it won't be for a while), we've recently begun doing regular builds of a special Korean Edition of neon's Developer Edition tracking the stable branch of KDE's code repositories. The Korean Edition pre-selects the Korean language and locale at boot, packs all the Korean translations we have and comes with a Korean input method pre-setup.

Joseon-era Hangeul metal type

Why a Korean Edition?

Among many other locations around the planet, the local community in Korea is planning to put on a KDE 20th Anniversary birthday party in Seoul on October 14th. The KDE neon Korean Developer Edition was directly created on request for this event, to be made available to attendees.

That said - this is actually something we've been wanting to do for a while, and it's not just about Korean.

None of the bits that make up the new image are new per-se; KDE has supported Korean for a long time, both with foundational localization engineering and regular maintenance activity. And as of the Plasma 5.6 release, our Input Method Panel is finally bundled with the core desktop code and gets automatically added to the panel on first logon in a locale that typically requires an input method.

Yet it's pretty hard to keep all of this working well, as it requires tight integration and testing across an entire stack, with some parts of the whole living upstream or downstream of KDE.org. For example: After we attempted to make the Plasma panel smarter by making it auto-add the Input Method Panel depending on locale, we couldn't actually be sure it was working as desired by our users, as it takes time for distros to get around to tuning their dependency profiles and for feedback from their users to loop back up to us. It's a very long cycle, with too many opportunities to lose focus or domain knowledge to turnover along the way.

This is where KDE neon comes in: As a fully-integrated product, we can now prove out and demo the intended distro experience there. We can make sure thing stay in working order, even before additional work hits our other distro partners.

Right now, we're kicking things off with Korean Edition, but based on time, interest and testers (please get in touch!), we'd like to build it out into a full CJK Edition, with translations and input support for our Chinese and Japanese users pre-installed as well (as another precursor to this, the decision to switch to Noto Sans CJK as Plasma's default typeface last year was very much made with the global audience in mind as well).

Ok, but where do I get it?

Here! Do keep in mind it's alpha. ☺