Get Involved/Design/Frequently Discussed Topics

This page catalogs the results of various discussions that appear over and over again, as well as useful bits of wisdom and institutional knowledge relevant to development and design. Additional information can be found on the KDE Culture page.

Design pitfalls

Constant redesign proposals is a warning sign

When a piece of software's visual or functional design is not ideal, people will come out of the woodwork to propose changes and redesigns. Many of these proposals will be terrible or contradict one another if they were all implemented, and the software's developers will feel the need to shoot them down. However these proposals indicate that some kind of change is needed, even if any one individual redesign proposal is not the solution. In this case, engagement with the VDG is advised, and hopefully developers and designers can work together to implement some changes that make everyone happy. Once adequate changes to the design have been made, you will know because people will stop proposing redesigns, as if by magic.

Basic/advanced modes

See https://develop.kde.org/hig/powerful_when_needed/#user-driven-extensibility.

Tip of the day

A tip of the day feature that presents the user with a random piece of advice at startup sounds like a good way to let people discover lesser-known pieces of functionality.

However it doesn't work out in practice. Information that isn't relevant to what the user is trying to do *right now* is either outright ignored by the user or they will have forgotten once it would actually be useful. Being presented with random tips at startup is often perceived as more annoying that actually helpful.

First-run wizard

See https://develop.kde.org/hig/simple_by_default/#be-welcoming-not-demanding-or-baffling.

Context menus are not enough

Context menus offer fast access to functionality for mouse users, but they do not work well for:

People using the system with a screen reader
People using the system with a touchscreen
People using the system with a buttonless touchpad who have not become comfortable doing a two-finger right-click or pressing the hidden invisible right-click zone in the corner
People using the system with a weird mouse that only has one button or whose surface is a big touchpad (like Apple mice; see the previous group of people)
People using the system with a device that has a nice easy right-click button but who just don't use it because they never developed the habit of randomly right-clicking everything

For these reasons, no functionality should only be accessible from a context menu, and context menus should be considered accelerators for experts, like keyboard shortcuts.

"Broken promise" global options

When options imply or present themselves as having a global scope, but they don't really have a global scope (e.g. they only affect certain apps, or apps written with certain toolkits), this represents a broken promise to the user. The user will play with the option, notice that it doesn't affect this or that, and not understand why that's happening or who is to blame for it, because the technical details of the option's scope are rarely clear.

If it is deemed necessary to present such options to the user, try to locate them in places where the scope is automatically clear. For example, options specific to the active Application Style should go in a settings window specific to that style. If design requirements dictate that such options be located in a place where their scope is implied to be global (e.g. the top level of a System Settings page), their true scope should be clarified in the UI using inline help text or a contextual help button.

"Consistency" doesn't mean everything should look identical

"Consistency" is not a mandate to make everything look like everything else. The point is ensure that things which behave in an identical way look identical as well.

This is because users rely on visual cues to tell them what something is and how it behaves; for example once a user has learned that something that looks like a button behaves like a button, they will understand what buttons do everywhere as long as buttons have consistent styling. Hence:

Buttons should always be styled the same
tab bars should always be styled the same
List views and sidebars should always be styled the same
etc.

And as a corollary:

Things which are buttonlike but not exactly buttons don't need to be styled exactly like buttons
Things which are tab-like but not exactly tab bars do not need to be styled exactly like tab bars
Icons in different contexts don't have to use the identical sizing and styling
The contents of list views does not need to be completely identical
etc.

New off-by-default features

Most people never change most of the default settings for their software. Any feature which is off by default is likely to be missed by most users. Therefore, when proposing a new feature, don't make it configurable and leave it off by default. Have confidence in your designs and features! New features and design changes should be on by default, if they should even be configurable at all. If you are tempted to add a feature and make it off by default, consider your motivation: do you think it's too nerdy and esoteric a feature? In that case maybe it should be an optional downloadable plugin or even a separate app. Do you think the design changes might be too controversial? In that case consider working with VDG to improve the design so that you feel more confident about it, or implement your design in a downloadable theme instead of the default Breeze theme.

Note that this does not apply to accessibility features which are generally always off by default. It also does not apply to adding the ability to turn off existing features which are currently always on. This should be done carefully and sparingly to prevent options overload, but is not necessary a bad idea.

Measuring between variable-size UI elements

People often like to annotate screenshots of KDE apps with lines drawn between UI elements to illustrate supposedly inconsistent margins between them. This can work for lines drawn between two fixed UI elements that have no dynamic sizing or positioning, such as a line drawn between a button and the window edge. But it does not work for lines drawn to or from text or icons, because text and icons commonly live inside a bounding box that is larger than the visual content. In the code, margins are drawn against UI elements' bounding boxes, not the variable-size content inside of them.

For example, a piece of English text with no instances of the letter g, j, q, p, or y still needs to allocate space in its bounding box for the descenders of those letters anyway. As a result, the text label will have a bounding box that does not perfectly hug the text, and will therefore have a larger perceived bottom padding compared to a text label with any of those letters in it.

The same is true of icons, which commonly incorporate internal margins. For example a 16x16px icon is almost never actually 16 pixels tall and wide; that is simply the size of the icon's bounding box. The icon within that bounding box can have its own margins, and in practice ends up actually being 16x12, 14x12, 12x12, or any other similarly varied size. Therefore such icons will always exhibit non-standard margins when lines are drawn between them and the edges of buttons, window edges, etc.

This problem with icons is theoretically solvable if all icons in existence were re-made to prohibit internal margins, so that icons' square bounding boxes were always required to be completely filled with pixels. However such a thing is not realistic as there are millions of icons in all the world's icon themes, and requiring every icon to be perfectly square would constrain icon designers' design choices.

As an alternative, we could abandon the use of borderless/Flat ToolButtons and always give all of our buttons borders, so that the borders would provide a thing to measure against. But this would be a very significant design change that as of 2024 has not been agreed to yet; see https://community.kde.org/Get_Involved/Design/Lessons_Learned#Buttonlike_buttons_or_flat_buttons?

And the problem is not even theoretically solvable for text, since redesigning the world's languages so that every character fits in a monospaced square box is not practical.

Copying other platforms

Doing it explicitly

Oftentimes, people will explicitly bring up the fact that a feature or visual style is already present in another OS as a justification for implementing the same thing in a piece of KDE software.

In KDE, we don't copy other platforms explicitly, or use the fact that a feature/workflow/visual style/etc. is already implemented elsewhere as evidence that we need to implement it as well. When we do implement something that is already present on another platform, it must be because we want to solve the same problem and have arrived at the same place by chance, not because we were explicitly trying to copy another platform. The reason for this is that other platforms don't always get everything right. We must look at them dispassionately, and take from them what works and what's applicable to us and our world, while confidently ignoring the rest.

Now, it's true that KDE finds itself eternally trapped in a world where Plasma and the "KDE style" are compared to Windows, and people expect to bring a certain measure of their familiarity with Windows along with them when they migrate. But this definitely does not mean that we simply need to copy them! Rather, the reverse is true: we need to have our own style and workflow as much as it's possible to stretch people's conceptions of what a computer can do beyond the Windows model. We do need to be mindful of not stretching it too far, since being able to benefit from familiarity is useful to new users. But as a general principle, we endeavor to be and look better than Windows, not the same.

Offering it as an option, via Global Themes

This has been proposed many times in the past, and was almost implemented; see https://phabricator.kde.org/D24223.

Ultimately the team decided against it because allowing users to set up layouts that mimic other platforms would establish the expectation that *everything* is similar to that platform. But 100% fidelity would be impossible, so the promise of mimicking the platform would never be kept.

In essence it would prime people's brains to enter "nitpicky conservative mode" and focus on the differences from what's expected, rather than "open-minded exploration mode" where it's possible to feel playful and curious and enjoy the distinctiveness of our system. People would feel angered and disgusted, rather than intrigued and curious.

Accordingly, formalizing this by offering global themes out of the box that provide similarly imperfect mimicry of other platforms would make that problem worse, not better.

Chasing design trends

In all artistic matters, there is a dichotomy between minimalism and ornamentation. Throughout history, artistic styles have bounced between these extremes: when art is seen as too ornamental, it feels heavy, gaudy, excessive, or even ridiculous, and a pressure emerges to pare things down to basics. But going too far in the direction of minimalism makes art feel cold, sterile, unfriendly, or even amateurish.

In the software world, this manifests as user interface design trends, such as the "brutalist" trend of the 1990s, the "skeumorphic" trend of the 2000s, the "flat" trend of the 2010s, and the current "modern" trend. Each of these trends eventually flames out and gets replaced by a new one because its controversial visual style turns off some people, and it broadly fails to satisfy people who like ornamentation and also people who like minimalism.

To avoid the ping-pong between these extremes in our own software's visual design, we must aspire to a timelessness that combines both minimalism and ornamentation in a pleasing fusion. We must remove all that is not necessary, but make what remains feel rich and beautiful without being in-your-face about it. This balance is hard to get right, but you will know when it has been achieved because designers will stop coming out of the woodwork to try to redesign it (see #Constant_redesign_proposals_is_a_warning_sign).

Why not a Control Center?

Many other desktop environments have now implemented a "Control Center" UI in place of the "System Tray" style that Plasma uses. These Control Centers offer the user two-click access to simple controls such as changing the volume, and toggling bluetooth, night color, or dark mode. It is often suggested that KDE should copy them and implement such a thing for the Plasma System Tray.

As of 2024, so far no consensus has been reached on this topic, and there are a number of reasons not to and challenges that would need to be overcome if we decided to do it:

Many Plasmoids offer richer interaction opportunities than a Control Center that simply consists of toggles and sliders, and their functionality cannot be condensed into just a single button. For example: Clipboard, Battery & Brightness, Disks & Devices, Display Configuration, KDE Connect, Printers, Media Player, Notifications, and Vaults. That's most of them, in fact! So we could never fully migrate to a Control Center style anyway without losing a lot of functionality.
In terms of implementation, a Control Center would require adding an additional representation type for all Plasmoids (perhaps named ControlCenterRepresentation?) that would consist of simply a toggle button; this would have to be be opt-in so each Plasmoid could define its own appropriate Control Center button, which means a lot of porting work and 3rd-party Plasmoids would not be compatible for some time.
Our current System Tray offers 2-3 click access to most settings; for ported Plasmoids, all that would be saved by switching to a Control Center would be at most one click, and often zero.
Any UI changes that made access to the full Plasmoids require additional clicks beyond what we have right now would reduce the advantages of using them instead of simply opening System Settings, which is the entire point of this UI.

For these reasons, it does not seem like a Control Center is fully compatible with the richness of what the Plasma System Tray currently offers, and all of them would need to be addressed in the design phase before we could consider implementing it. One such promising proposal can be found at https://bugs.kde.org/show_bug.cgi?id=460125!

Scrolling

Names of different scrolling effects

Kinetic/inertial/momentum scrolling: After a touchpad or touchscreen scroll event finishes, the view continues to scroll and eventually comes to a smooth stop, rather than immediately ending. Never do this for mouse wheel scroll events.
Bounceback/Bouncy scrolling: When a scroll causes the view to reach the top or bottom, the view visibly "bounces" rather than the scroll event immediately ending. Only ever used in conjunction with kinetic scrolling; never do this for mouse wheel scroll events.
Pixel/Pixel-by-pixel/1:1 scrolling: When scrolling with a touchpad or touchscreen, the view moves pixel-by-pixel, as though it were glued to your finger(s). Not used or relevant for mouse wheel scroll events.
Smooth/animated scrolling: When scrolling using a mouse wheel, the arrow keys, PgUp/PgDn keys or spacebar/shift+spacebar keys, there is an animated transition between the old and new view positions, rather than the view jumping straight to the new position with no animation or transition.
Autoscrolling: When you can middle-click on a scrollable view and move the pointer up or down to have the view continuously scroll up or down, at a speed determined by how far the pointer gets from the middle-clicked point.

Auto-hiding/overlay/invisible scrollbars

Scrollbars serve three related purposes:

Allow the user to change the current view position
Indicate the current view position relative to the whole view
Indicate how large the current view is relative to the whole view

Depending on the user's current set of input devices, apps, and device form factor, scrollbars might rarely or ever be used directly, obviating the need for #1. And users who grew up with the smartphone device form factor and are accustomed to auto-hiding scrollbars may question the need for #2 and #3. Nonetheless, all are important even if any one of their functions may not be used at any given point in time. Scrollbars cannot ever be completely hidden or else at-a-glance information about the view's size and position relative to the whole is lost, which may be quite disruptive, depending on the view in question.

Scrollbars must also be accessible for the benefit of stylus users, who otherwise may have no other way to scroll. And mouse users interact with scrollbars somewhat frequently for very long scrollable views, as mouse wheel scrolling is generally rather slow. Even touchpad users may do the same for very large views in apps where scroll acceleration has not been implemented. And if the scrollbars auto-hide or become invisible when not hovered, the precise location of where to click to access the bar or the track is not obvious, which slows down interaction.

In addition, in the past when Kirigami-based apps did use auto-hiding scrollbars, many issues were encountered where scrollbars covered content areas which looked bad and also resulted in functional impairments, e.g. clickable buttons at the right side of list views lost half of their clickable area. Many workarounds were sought whereby app content would try to dodge scrollbars, but this was buggy and unreliable, and when it worked, it caused content to move around based on scrollbar visibility, which triggered complaints about that. All in all it was deemed to be more trouble than it was worth.

Visually separating scrollbars from content areas

When a scrollview's content area uses a highlight effect that spans the full width of the scrollview, some sort of visual separator to delineate the bounds of the scrollbar track is needed, to provide an anchoring point for anything that touches the edge of the scrollbar track. Examples include full-width highlight effects and table view headers. Without some visual separation, those UI elements seem to be "floating in space" on their right side, but connected to the edge of the view on their left side, which looks weird.

On the other hand, if all of those elements use a style where the entire thing is "floating in space" and not visually attached to anything on any side of it (in the case of list view highlight effects), or drawn above the scrollview (in the case of table headers), then it becomes okay to omit a visual scrollbar separator, since it no longer serves an anchoring function.

Why things are the way they are

CSD Headerbars

It is often asked why KDE apps do not use client-side-decorated headerbars the way GNOME apps do. While they do indeed look very good in GNOME apps, there are many reasons why we don't use them in KDE apps:

Reduced space for UI controls which encourages developers to make everything into an icons-only button (and those have bad usability) or else add secondary toolbars below the headerbar, which negates any space savings
No built-in area to show the app name, window title, and/or open document name. If you make room for them, you're reducing space for interactive controls, which exacerbates issue #1
Because everything has to fit in one small space, excellent design skills are required to make a satisfactory UX, which means you can't let the user customize the headerbar or else they can worsen your UX and ruin the app
Worse or no integration with features provided by the window manager (e.g. actions to keep the window on top, move it to another virtual desktop, close it when it's frozen, etc.)
Nowhere to put an in-window menubar
Reduced space to drag the window
A less native look and feel on other platforms

Some KDE developers would like CSD headerbars for dialogs and small apps as many of the above points don't apply for dialogs and small apps.

For more information on this topic, see https://pointieststick.com/2018/12/18/on-headerbars and https://pointieststick.com/2019/03/06/more-on-headerbars-rebuttals.

Rounded window corners

In general, everyone wants rounded window corners. Implementing them properly has been a challenge, though.

In the past, windows decorated by KWin had all four of their corners rounded because the rounding was provided by KWin's Breeze window decoration style. The top corners on the titlebar got some rounding, and the bottom corners were provided by extra window borders drawn by KWin. This came with a downside: it was impossible to make the window's views and content touch the true edges of the window. Because of this, the extra bottom and side borders were eventually disabled by default in the Breeze window decoration style, resulting in un-rounded bottom corners.

If we want to keep the ability for window contents to touch the edges of their windows, we will need to come up with a different way to round the bottom corners. There are several options, ranging from having KWin chop off some pixels and round them itself, to making individual windows or window toolkits opt in and do their own rounding.

As of 2024, all options come with drawbacks, so no consensus has been reached yet.

Pixel-alignment for SVG icons

It is often asked, "you use vector SVG icons; why doesn't this let you scale the icons up or down to arbitrary sizes and keep them always looking good no matter the scale?"

The answer is because despite the use of a vector icon format, we still draw our SVG icons to be pixel-aligned when displayed at their native size (16x16 px, 22x22 px, etc). An icon's 1px lines will be perfectly aligned to the screen's physical pixels when displayed at either its native size (i.e. 100%) or at a multiple of its native size (200%, 300%). The result is nice crisp icons with no blurriness. However if you scale such an icon to 150% size, then the 1px strokes become 1.5px strokes, but the physical pixels on your screen are still the same size that they were before. The result is blurriness as the system attempts to figure out how to display a 1.5px line on a pixel grid that is not fine enough.

This effect is less pronounced for large colorful icons that are scaled up by greater amounts, but the effect can still be noticeable. And the effect produces particularly undesirable results for small monochrome line-art icons with 1px strokes which are scaled up or down by a non-integer amount. For a more technically in-depth explanation, see https://phabricator.kde.org/T13722#255733.

The next question is usually, "Wait, so why is this not a problem for vector-based fonts? They look good at any size, on a screen of any DPI!"

The answer is because fonts and font rendering engines have support for sub-pixel anti-aliasing and hinting, which lets them perform clever tricks to take advantage of the physical arrangement of the pixel grid to effectively draw "half-pixel" lines, and to smooth out jagginess in a more optimized way than what the window manager is capable of doing. This gives the screen effectively triple the resolution (but only in the vertical direction!).

In principle it would be possible to build an icon rendering engine that implemented these features, and then our icons could be adjusted internally to make use of them. It would be an absolutely enormous undertaking and break compatibility with all existing FreeDesktop icon themes. Resources for such a task and consensus that it would be a good idea do not exist as of 2024.

System Tray popup sizing

It is often asked: "Why can't system tray popups fit their contents with no extra wasted space"? The "wasted space" effect is particularly noticeable in the Bluetooth Plasmoid when only a single device is paired, or the Audio Plasmoid when using simple audio hardware.

However there is a good reason why this is not done: if it did, then each Plasmoid would have a different size, because it has different content. As a result, every time you opened a Plasmoid, the buttons on its header and its internal UI elements or list items would be in different locations compared to other Plasmoid, or even compared to the last time it was opened, if content had been added or removed since the last time. This would destroy the user's muscle memory and make interaction slower. Furthermore, for Plasmoid that have dynamic content that changes in real-time (such as the Disks & Devices, Networks, Notifications, and KDE Connect Plasmoid), the popup would dynamically resize itself while the user was attempting to interact with it! This would be extremely frustrating and cause the user to mis-click frequently.

Media Player icon

People frequently observe that the icons of the Media Player widget show the current status of playback (stopped, playing, paused, etc) rather than the action that will be executed if clicked (stop, play, or pause), as is done in audio and video player UIs. This is because the Media Player icon is not in fact a clickable button that will execute an action when clicked, but rather a status indicator--it shows the current status of playback. As such, showing the current playback status rather than the potential future playback status is intentional.

Theming/color issues when running KDE or Qt apps in non-Plasma desktop environments

It's often observed that KDE apps look ugly when run in GNOME, Cinnamon, or other desktop environments that weren't written using the Qt toolkit. The reason for this boils down to fundamentally different approaches to styling that conflict with one another.

Qt is an inherently cross-platform toolkit that's designed for writing software that adopts the conventions and styling of whatever platform it's run on. As such, Qt apps get their widget style, color scheme, and certain behaviors (such as single/double click) from the Qt Platform Theme (QPT), which tells them which of these things to use, and when. In other words, Qt apps expect the presence of a platform-specific abstraction layer telling them how to look and behave.

KDE answers this call by providing its own QPT, called plasma-integration. It tells Qt apps run in Plasma to use the user's chosen widget style, the KDE color scheme, and so on.

Qt also provides built-in QPTs for macOS and Windows. But for other smaller platforms such as Plasma, GNOME, Cinnamon, and XFCE, it does not. These environments are expected to provide their own QPT, and Plasma does. Unfortunately, the others generally don't. Qt apps run on those platforms then fall back to the built-in generic QPT for *Nix-based platforms, which specifies the Fusion style and an internal hardcoded color scheme. These look ugly and dated, don't respect the light/dark theme setting, and don't provide icon recoloring.

Why don't the developers of those environments provide QPTs? Several reasons:

Lack of resources or interest: it's extra work that only benefits competing apps.
Lack of knowledge or expertise using Qt and its platform integration tooling.
Philosophical disagreement with the concept of platform theming ("Just look like a KDE app; don't try to look like a GNOME app").

This last point is especially crucial: as a cross-platform toolkit, Qt is built around the concept of platform theming, while some developers outside of KDE believe platform theming to be fundamentally wrong. The simplest option is to make plasma-integration a mandatory dependency of all KDE apps, which would at least make them look like nice KDE apps when run on other platforms. However this would forestall a better solution in the form of other environments getting more platform-specific QPTs.

As of 2024, it's not clear how this issue can be resolved.

Battery status icon and charge percentage

By default Plasma's battery status icon does not show the charge percentage on it, and the user can optionally add a badge overlay with the percentage that covers up part of the icon.

At small icon sizes, the badge covers up most of the icon which looks ugly. So people complain and propose solutions. The problem is that there is no good option:

If we moved the icon up a bit to make room below it for text, this would work with the Breeze icon theme, but could not be guaranteed to work with any other icon theme that has battery icons with different dimensions.
To avoid that issue, if we located the text below to the side of the icon, then we'd have to make room by using a non-square container. This would break a requirement of the System Tray that icon containers be square, which facilitates grid layouts. So we'd have to limit the System Tray to only linear icon arrangements, which would be a regression for people happily using grid arrangements.
To avoid that issue, if we integrated the percentage into the battery icon itself, we would need 1200 new icons (100 for each percentage, multiplied by the four possible charge states, multiplied by the three sizes per icon) and break compatibility with existing 3rd-party icon themes. Also this would not work for languages that don't use western-style Arabic numerals.
This leaves us with the status quo, which is to locate the localizable percentage text in an overlay that covers up part of the icon--quite a lot of it at small icon sizes.

As of 2024, it's not clear how we could proceed here.

Open Topics

Buttonlike buttons or flat buttons?

In KDE software, we commonly use two types of buttons:

PushButtons which have a visibly buttonlike appearance with a background, frame, and shadow.
ToolButtons which have no background, frame, or shadow, but do show a frame when hoverered with the cursor. Often called "flat" buttons.

It's often suggested that we should standardize on only one type to avoid having two visual styles for the same thing. In addition, there is some usability research on the subject to suggest that visibly buttonlike buttons offer better usability. However, in a very button-dense layout, displaying many buttonlike buttons can make the UI feel heavy, intimidating, or even overwhelming.

As of 2024, so far no consensus has been reached on this topic. We don't want to achieve a usability win by making buttons look buttonlike at the cost of incurring the aesthetic penalty or making our button-heavy layouts feel scary, which would then reduce usability. One option is to redo these layouts to have fewer buttons, and another is to use conjoined buttons to visually group related actions and reduce the "frames next to frames effect. See the discussion in https://invent.kde.org/teams/vdg/issues/-/issues/12.