Design – sebas' blog

Sound-reactive Sideboard

March 4, 2026March 4, 2026 1 Comment

A project that I had planned for quite some time came to fruition last year, now I finally found time to document the result. My livingroom sideboard looked messy and kind of boring while not blending in anymore with the updated style of my living room. I wanted to turn it into a striking centerpiece of the room.
The plan was to install a sound-reactive lighting system. I wanted the light effects to be detailed and not disturbed by ambient sound in the living room, i.e. it sound not react to people’s voices, just the music playing.

My living room sideboard is an off-the-shelf product from IKEA that I bought many years ago. It didn’t have doors installed, but I was delighted that I could still buy matching doors with windows in them.
To realize the light effects, I’ve installed frosted plexi glass inside the windows.

Getting technical…

To control the LEDs, I’m using an ESP32-based LED controller with a line-in module and an ADC (analog-digital converter). After some experimenting, I’ve found this board to work well. I’ve connected 6 WS2812B LED strips to 3 pins and installed them with an aluminium profile into the doors. The frosted windows and profiles diffuse the light nicely so you can’t make out individual LEDs really.
On the software side, I’m using a sound-reactive port of the WLED project. WLED is Free and Open Source software, of course. Though its user interface can be a little unwieldy, it’s also very powerful and integrates nicely with homeassistant, so it can be controlled automatically.

The ESP32, being a rather powerful dual-core microcontroller, can process the incoming audio signal on one core (using fast-fourier transformation) and compute complex LED effects on the other core. Rendering up to 200 frames per second to 2 times 210 LEDs is no problem while power consumption of just the controller stays well under 1W. Pretty impressive! Depending on the LED effects (number of LEDs lit up at a given time and their colors), the whole thing hardly ever reaches 10W of power consumption.

Another functional goal of this project was to solve cooling issues of my amplifier once and for all. The amp would run really hot and shut off after playing at higher volume for some time. I installed a bunch of 12cm fans which suck air through the amplifier and blow it out on the backside. Both amp and and fans are connected to smartplugs. I turned to my homeassistant and set up an automation which turns the fans on whenever the amp’s power consumption reaches a certain level. This works really nicely, since the fans never spin at lower volumes (when you could hear them through the music) and keep everything cool and running stable at higher volume when it’s necessary — without human interaction.

Walnut finish

The outer shell of the sideboard is made of walnut wooden panels with an oil and varnish finish, thanks to my friend Joris. The oil gives it a darker look and accentuates the grain, matching the speaker system. The matte varnish finish (Skylt, highly recommended for its durability and natural look) allows me to sleep well even if people put their drinks on it.

I love it when a plan comes together!

I’m really happy with the result. While I had thought it out for a long time already, it’s always a lot more impressive when you see the final result in action.
The WLED firmware allows me to create interesting light effects. I can run the 3 doors as one, but also easily split them up into segments so each door panel renders its own effect. WLED has ca. 200 different LED effects, many of them react to sound. Each effect can be combined with one of 50 color palettes, some of the palettes are sound-reactive in their own right leading to a very dynamic display.
One cool feature is that the processed sound data can be broadcast across the network (over UDP) and received by other WLED controllers, so I can have multiple LED displays in the house, each rendering their own effect to the music, creating a more immersive experience.

More mobile settings: keyboard & wired network

October 23, 2025October 31, 2025

Recently, I’ve worked on making certain “less obvious” system settings more accessible for Plasma Mobile users. The modules I’ve worked on fall just outside the typical mobile phone use-case, but can be important to users of other types of devices. Specifically, users that plug in or connect a keyboard once in a while and need to change its layout or language, or devices that are connected using an ethernet cable, as often is the case with embedded industrial devices.

These two settings module offer a subset of their “desktop companions'” settings and cater to simpler use-cases while sporting a leaner and more focused user interface. Most of the business logic and the more complex UI components are also shared with the desktop versions.

Reviewers needed!

The merge requests for both are currently under review and I’d appreciate if people could help ironing out issues so we can go ahead and merge the code:

Update: Both modules have been merged and will ship as part of Plasma 6.6.

Back in Action on Plasma (Mobile)

August 28, 2025August 28, 2025 6 Comments

After I took a longer break from KDE development, I’ve been back in action for a few months now. It’s really nice to be back among friends, hacking on what I like most: Plasma. My focus has been on Plasma Mobile with some work naturally bleeding over into other areas.

Plasma on more Devices

I’d like to share some bits and pieces that I’ve worked on in the past months. Most of my efforts have revolved around making Plasma Mobile suitable for a wider range of devices and use-cases. The purpose of this work is that I want to make Plasma Mobile a more viable base for all kinds of products, not just mobile phones. We have a really mature software stack and great tools and applications which make it relatively easy for companies to create amazing products without having to hire large teams and many years to get the product ready for their market. This is I think a very interesting and worthwhile niche for Plasma to get into and I’m sure that Valve is not the only company that understands this.

Convergence Improvements

Convergence, or rather being able to support and switch between formfactors and usage patterns has always been a pet-peeve of mine and still is.
One area was improving using the available screen real estate use landscape displays (Plasma Mobile has quite naturally been rather “portrait-focused”, though a few smaller patches go a long way.)

Configurable number of columns in the Quicksettings drawer

I also improve usability with different pixel densities in the mobile shell by making the size of the top panel configurable. Also, when plugging in a second monitor, Plasma Mobile now switches from “all apps are maximized” to normal window management. (I’m currently working on KWin supporting more fine-grained window management. Currently, we just maximize all windows which has problems especially with modal dialogs.)

One changeset I worked on earlier this year makes it possible to ship multiple user interfaces for settings modules (“kcms”). An example is the “remote desktop” kcm which now shows a mobile-focused UI in Plasma Mobile. What happens here is that we load a main_phone.qml file in Plasma Mobile (where “phone” is picked from a list of form factors set in the environment of the session, so basically the “main” QML file gets picked based on the device. This mechanism allows us to share components quite easily, reducing the delta between different device UIs.

This actually builds on top of work that I’ve done ten years ago which added support for form factors to our plugin metadata system.
I’ve also made the “Display & Monitor” kcm usable on mobile, this is a pretty important thing to have working when you want to be able to plug in an external monitor into your device. I have a mobile version of the keyboard KCM in the pipeline, too, but this will need a bit more work before it’s ready for prime-time.

More Features

There’s a new page in the mobile Wi-fi settings module, showing connection details and tranfer speeds. The code for this was amazingly simple since I could lift most of the functionality from the desktop panel widget. A shared code-base across devices really speeds up development.

Connection details for the mobile wifi settings

Adding useful features here and there, such as having the list of available bluetooth devices now filtered by default and only showing devices which actually make sense to pair (with an option to “Show all devices” in good Plasma manner). This feature isn’t mobile-specific, so desktop and laptop users will benefit.

Welcome to Okular Mobile

Not all my work goes into infrastructural and “shell” bits. The mobile okular version has now kind of caught up with the desktop version since it got a nice welcome screen when opened. This allows the user to easily open a document either from the “Documents” directory on disk (this is actually configurable) or one of the recent files viewed.

Going to Akademy ’25

After having missed our yearly world conference for a number of years, this year I will be at Akademy again. I’m really looking forward to seeing everybody in person again!

See you in Berlin!

Bringing light to life

November 19, 2020February 23, 2022

Some of you may be wondering what I have been up to lately since I took a break from my work in the KDE community. Well, it was time for a change, a change towards family, friends and a more local life. The result is a more balanced, a more grown up me. These changes in my life lead to me having a small family and a group of new friends, both of which I spend a lot of time with. They brought more light into my life, one could say.

That is not all I want to talk about, however. I the past 1.5 years I worked on a new project of mine that combines my love for software with the physical world. I created a product and brought it to the market last month. Now, we’re ready for the international launch of Organic Lighting. The product is a design smart lamp for the living room. It combines unique and dynamic visual effects with natural, sustainable materials.
Meet our Aurora lamp:

It’s a connected device that can be eighter controlled using its physical knob on the front, or via its web ui (or REST interface). Effects can be changed, tweaked and its firmware can be updated (nobody should want an IoT device that can’t get security of feature updates). The concept here, technically is to do “light in software”. The lamp is run by a microcontroller embedded in its foot. Its roughly 600 leds produce ca. 4000 Lumen and render effects at more than 200 frames per seconds.
The lamp is built with easy repairs in mind, and it’s designed for a long-lasting experience, it respects your privacy, and it creates a unique atmosphere in your living space.

With our products, we’re offering an alternative to planned deprecation, throw-away materials and hidden costs of cheap electronics that make you the product by consuming your data for breakfast.

In the future, we will build on these concepts and technology and offer more devices and components that match our principles and that enhance one-another. Stay tuned!

Connecting new screens

February 28, 2018February 28, 2018 10 Comments

Plasma's new screen layout selection dialog — Plasma’s new screen layout selection dialog

This week, Dan Vratil and me have merged a new feature in KScreen, Plasma’s screen configuration tool. Up until now, when plugging in a new display (a monitor, beamer or TV, for example), Plasma would automatically extend the desktop area to include this screen. In many cases, this is expected behavior, but it’s not necessarily clear to the user what just happened. Perhaps the user would rather want the new screen on the other side of the current, clone the existing screen, switch over to it or perhaps not use it at all at this point.
The new behavior is to now pop up a selection on-screen display (OSD) on the primary screen or laptop panel allowing the user to pick the new configuration and thereby make it clear what’s happening. When the same display hardware is plugged in again at a later point, this configuration is remembered and applied again (no OSD is shown in that case).
Another change-set which we’re about to merge is to pop up the same selection dialog when the user presses the display button which can be found on many laptops. This has been nagging me for quite a while since the display button switched screen configuration but provided very little in the way of visual feedback to the user what’s happening, so it wasn’t very user-friendly. This new feature will be part of Plasma 5.13 to be released in June 2018.

Plasma Convergence, technically

October 5, 2017 3 Comments

In one of my latest blogs, I’ve explained what convergence is, how Plasma benefits from it, and why we consider it a goal for Plasma. This time around, I’ll explain the how, how it works across the stack and how we implemented it. Naturally, this article dives a lot deeper, technically, than my previous one.

Convergence plays a role at different levels of the whole software stack. In this, more technical article, I’ll look at different layers of the software stack, from boot/kernel and middleware to UI controls and overall layout and input methods. After reading this article, you’ll understand how Plasma allows to use the same software on a range of devices, which parts are different, and where code sharing makes sense, and thus happens.
Keep in mind that Convergence, at least for Plasma, doesn’t mean that we ship a lowest-common denominator UI so it “kind of” runs on all things computer, but that it provides a toolbox to build customized UIs that allow taking advantage of specific characteristics of a given target device.

Lower Levels and Packaging

Plasma -- same code, different devices — Plasma — same code, different devices

One aspect of convergence that is of course the deployment side. This doesn’t just include the kernel and bootloader, which needs to be compiled differently for ARM devices and for x86 devices. The rest of the stack is by now largely the same. We are now using the same set of packages and CI for both, mobile and desktop builds, in fact most packages are the same, and the difference between a device set up for mobile use cases and desktop is the selection of packages, and what gets started by default. Everything is integrated to a very large degree, lots of work is shared which means timely updates across the device spectrum we serve.

Controls

When it comes to user interface controls, such as buttons, text fields, etc., convergence is mostly a solved problem. Touch input is possible, Qt nowadays even ships a virtual keyboard (which Plasma uses for example for password input in the lock-screen), and buttons react to touch events as well. QtQuick-based user interfaces often work quite well with both, keyboard/mouse and touch input, in fact touch is one of the design goals of QtQuick.

Not everything is perfect yet, however, especially text selection and keyboard control of QtQuick-based UIs often still requires custom-code, meaning it needs more development and maintainance time to get right. QWidget-based UIs are still a bit ahead of the game here, though often the benefits of also being able to deploy an app on touch devices (such as many Android devices out there!) make QtQuick an attractive technology to use. We see more and more QtQuick-based applications, as this technology matures also for desktop use-cases.

Widgets

Plasma is made of widgets. Even in a standard Plasma desktop, everything is a widget: The menu in the bottom left is a widget, the task manager is, the system tray is a widget, and there are widgets inside the system tray for notifications, battery, sound, network, etc.. Plasma is widgets.
These widgets can be used on any device of course, but it doesn’t always make sense. Some of these widgets are very specific for desktops. The task-manager (that thing you use to switch windows, which is usually located in center of the bottom panel) doesn’t really make sense on a mobile device. For a mobile device, which needs larger areas to touch, something more aking to a full-screen window switcher is useful (and in fact what we use for Plasma Mobile). Other widgets, such as the network connections widget or battery and brightness widgets are perfectly suitable also for mobile devices. Plasma’s architecture allows us to re-use the components that need no or just little changes and use them across devices. That means we can concentrate on the missing bits for each device, and that in turn means we can deliver a feature-rich and consistent UI across devices much easier, while making sure the specific characteristics of a given form-factor are used to their fullest extent.
Again, by sharing the components that make sense to share, we can deliver higher quality features for a given devices with less effort, and thus quicker.

Shell and Look & Feel

Plasma can dynamically load different so-called shell packages. The shell package defines the overall layout of the workspace environment. On the desktop, it says that there’s a fullscreen wallpaper background, with a folderview, a panel at the bottom and the widgets which are loaded into that panel: application launcher, task-manager, system tray and clock for example.
The shell package is different for each device, as this defines the overall workflow, which is highly dependent on the type of device.

To take differences between devices even further, Plasma has the concept of “Look and Feel” packages, which allow further specilialization how a device, well, looks and feels. There’s the widget style and the wallpaper of course. The Look and feel package also defines interaction patterns, such as if a settings interface should use “instant apply” when a setting is changed, or if it should present an “Apply and Okay” button for the user to save settings. Mobile devices typically use instant apply, while desktop interfaces (at least Plasma’s) use the “Apply and Okay” concept throughout. For Plasma UIs, this can be changed dynamically. Plasma’s Look and Feel features is not just useful in the convergence aspect, it allows also for example to switch between a traditional default Plasma setup and a workspace that closely resembles Unity. These “Look and Feel” packages are available through the KDE store, so they’re easy to install and share. There’s even a cool tool that allows you to create your own Look and Feel packages, very much like themes.

Apps

Subsurface Mobile, Linux, Android and iOS from the same code-base

Finally, at application level, we see more and more convergent applications. Kirigami, a high-level toolkit that supplied components for consistent, touch- and keyboard/mouse-friendly application nagivation and layout makes it very easy to create applications with responsive UIs that adapt well to screen size and density and that show flexibility in their input methods. This doesn’t just work between Laptops and phones, but also allows to create one app that works equally well on desktops, laptops, phones and tablets.
Kirigami complements Plasma’s convergence feature on application side, and we recommend it for most newly developed apps. With Qt and QtQuick being a viable target for Android devices, it increases the possible target audience by a very large degree. As an example, Subsurface Mobile, an application for scuba divers, uses Kirigami and works on Linux desktops, Android and iOS, all from the same code-base.

Make it happen…

If you like the idea of convergence, why not join KDE and help us work on Plasma? Perhaps you’d love to see Plasma on a mobile phone? In that case, consider backing the crowdfunding campaign for the librem5 so we can build a convergent phone!

Plasma Mobile and Convergence

September 26, 2017September 26, 2017 14 Comments

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!

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).

The Evolution of Plasma Mobile

September 22, 2017November 28, 2017 7 Comments

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.

Interview on hostingadvice.com

August 4, 2017August 4, 2017

How KDE's Open Source community has built reliable, monopoly-free computing for 20+ years — How KDE’s Open Source community has built reliable, monopoly-free computing for 20+ years

A few days ago, Hostingadvice.com’s lovely Alexandra Leslie interviewed me about my work in KDE. This interview has just been published on their site. The resulting article gives an excellent overview over what and why KDE is and does, along with some insights and personal stories from my own history in the Free software world.

At the time, Sebastian was only a student and was shocked that his work could have such a huge impact on so many people. That’s when he became dedicated to helping further KDE’s mission to foster a community of experts committed to experimentation and the development of software applications that optimize the way we work, communicate, and interact in the digital space.

“With enough determination, you can really make a difference in the world,” Sebastian said. “The more I realized this, the more I knew KDE was the right place to do it.”

Plasma’s Vision

July 25, 2017July 27, 2017 33 Comments

Plasma -- Durable, Usable, Elegant. — Plasma — Durable, Usable, Elegant.

Over the past weeks, we (KDE’s Plasma team) have distilled the reasons why we do what we do, and what we want to achieve into a vision statement. In this article, I’d like to present Plasma’s vision and explain a bit what is behind it. Let’s start with the statement itself, though:

Plasma is a cross-device work environment by the KDE Community where trust is put on the user’s capacity to best define her own workflow and preferences.

Plasma is simple by default, a clean work area for real-world usage which intends to stay out of your way.
Plasma is powerful when needed, enabling the user to create the workflow that makes her more effective to complete her tasks.

Plasma never dictates the user’s needs, it only strives to solve them. Plasma never defines what the user is allowed to do, it only ensures that she can.

Our motivation is to enable actual work to happen, across devices, across different platforms, using any application needed.

We build to be durable, we create to be usable, we design to be elegant.

I’ve marked a few bits which are especially important in a bold font, let’s get into a bit more detail:

Cross-device — Plasma is a work environment for different classes of devices, it adapts to the form-factor and offers a user interface which is suitable for the device’s characteristics (input methods such as touchscreen, mouse, keyboard) and constraints (screen size, memory and CPU capabilties, etc.).

Define the workflow — Plasma is a flexible tool that can be set up as the user wishes and needs to make her more effective, to get the job done. Plasma is not a purpose in itself, it rather enables and gets out of the way. This isn’t to say that we’ll introduce every single option one can think of, but we strive to serve many users’ use cases.

Simple by default means that Plasma is self-explanatory to new users, and that it offers a clean and sober interface in its default state. We don’t want to overwhelm the user, but present a serene and friendly environment.

Powerful when needed on the other hand means that under the hood, Plasma offers tremendous power that allow to get almost any job done efficiently and without flailing.

We build to be durable, we create to be usable, we design to be elegant. — The end result is a stable workspace that the user can trust, that is friendly and easy to use, and that is beautiful and elegant in how it works.