Did you know you can Meta+Ctrl+Scroll to zoom on Wayland?

I didn’t! I just discovered it today while working on fixing a bug. And boy is it awesome! Just hold down the Meta (aka “Super” or “Windows) and Ctrl keys, then scroll. Boom! Note that this only works in a Plasma Wayland session.

We don’t expose this shortcut in the UI right now, so it’s quite hidden and explains why I and probably many others didn’t know about it. We’ll work on improving this.

Highlights from 2022

2022 is over, and it’s time to recap! Like in previous years, this isn’t in any way, shape, or form a list of everything that happened in KDE; it’s just an overview of the big things I noticed or was involved with. More is always available at https://planet.kde.org!

Roadmap items

Many but not all of the items I was hoping for from my 2022 roadmap are finished now.

While we didn’t get a new style for Breeze icons or inertial scrolling everywhere, we did get the merged “Formats and Languages” KCM and a major overhaul for multi-monitor support to make it all finally work properly. “The Wayland session can completely replace the X11 session” is a bit fuzzier, but I can tell you that it’s done so for me! I only ever use the X11 session for occasionally testing merge requests. This doesn’t mean it’s there for everyone, of course. But it got ever closer in 2022. And finally, the 15-minute bug initiative was a big success! We didn’t fix every one of the 142 bugs classified as “15-minute bugs” in 2022, but we did fix 95 of them! That’s a pretty good rate. We’ll keep up the focus on these quality-of-life issues in 2023, too.

Hardware Partnerships

Linux hardware vendor Tuxedo Computers started shipping Plasma by default on all of their machines, a huge win for everyone!

KFocus, makers of Kubuntu-based hardware, added some new machines to their line-up–all shipping KDE Plasma and apps by default, of course!

Slimbook released a new version of their KDE Slimbook laptop, the best yet!

Finally, the Steam Deck became a smash hit, selling over a million devices worldwide and introducing so many people to the world of KDE!

So overall it was a pretty good year for getting KDE software into more people’s hands through hardware. But there is still so much more to do. We need to get more big names here, like Dell, Lenovo, and HP!


For the first time in a few years, we had a real, in-person Akademy. Hallelujah! It was so wonderful to reconnect with KDE folks in person. You can see videos of the sessions and talks here. And here’s my talk.

In addition, I ran for a seat on the KDE e.V. board of directors and was elected!

Professionalizing KDE

KDE has done incredibly well over its 26-year history as primarily a volunteer organization. But there was always a dirty little secret: some of the most prominent contributors along the way have been sponsored to work on KDE in a quiet way. In the same way that Red Hat quietly funds the work of a lot of GNOME people, a lot of KDE people over the years have been sponsored by Nokia, KDAB, the city of Munich, Blue Systems, Valve, and other institutions in KDE’s orbit.

And this is great! It’s a very good sign when outside companies that derive value from KDE software pay to make it even better. But it also means they’ve been paying to make it better for their use cases, their pet projects, their areas of interest.

What’s always been missing was a cadre of paid professionals to work on KDE from a big picture perspective–people who are from the KDE community, and paid by the KDE community; people who can make a living as professionals working on KDE software from a community perspective.

Well, no longer! KDE e.V. has started hiring engineers for technical positions this year, beginning with a packaging engineer. We’re working through the process of hiring a software engineer at the moment, and we have an open position for an integration engineer too.

This is big stuff! Paid professionals in the employ of KDE e.V. can counterbalance and augment the work paid for by 3rd-parties, ensuring a healthy mix, so that KDE’s future and direction can remain in the hands of KDE. It can help to ensure a certain amount of continuity of technical knowledge, so that more people get to stay in KDE once their life circumstances change to reflect a different balance of free time and monetary needs. And of course, none of this in any way diminishes the volunteer efforts the remain the backbone of KDE! On the contrary, volunteers–who by nature come and go as life circumstances and interests dictate–can really benefit from a stable core of paid professionals to interact with.

This isn’t cheap, though. If you want to help the initiative succeed and expand, please make a donation–preferably a recurring one! 🙂 If you already have, tell your buddies, your family members, your boss, anyone you know who uses and enjoys KDE software!

New Goals

This year, KDE did a third round of goal-picking, cementing this process as a key part of KDE’s culture. The three goals chosen were “KDE For All” (accessibility), “Sustainable Software”, and “Automate And Systematize Internal Processes”–three very important goals! You can see more here.


This year, Bugzilla got a re-organization to make it easier for normal people to figure out where to submit a bug report:

KDE also got a better donation and fundraising platform, powered by Donorbox. This makes it much simpler for people to donate to KDE e.V.:

Finally–and this is quite new–there’s a new forum powered by Discourse in the works, currently being beta-tested and rolled out at https://discuss.kde.org. Exciting times!

Qt 6

This year KDE contributors spent an enormous amount of time porting KDE software to Qt 6, the latest version of the Qt toolkit. This is unsexy work, so I didn’t blog about it. But it’s critically important, so thanks to everyone involved! And the work is now more than half done, with most common software and nearly all of Plasma already done; you can see the progress here.


The Wayland session made enormous progress. Slimbook started shipping their new KDE Slimbook laptops with Wayland by default, following Fedora KDE 34 switching doing the same in late 2021. Our list of showstoppers continues to shrink, and new issues added to it are or notably less bad then the ones they replace. There are discussions about defaulting to Wayland in Plasma 6 next year, either for the inaugural release or one of the ones soon after it. The future really is here! And if you’re tempted to grumble, “well, Wayland still doesn’t work for me for $REASON,” please do it in a bug report so developers can fix it!


It was a big year for Plasma! Among many other changes, we got custom window tiling layouts; massive stability improvements for multi-monitor workflows; Wayland fractional scaling; non-blurry scaled XWayland apps; a UI overhaul for Discover; many KRunner UX improvements; mouse button re-binding; resizable Panel popups; finger-following touchpad gestures on Wayland; support for alternate calendars such as the Chinese lunar calendar and Islamic civil calendar; picking-and-choosing what you want to apply from Global Themes; accent color generated from wallpaper’s dominant color; and full-window tinting with the accent color.

Plus a lot more, of course! You can see everything in the Plasma release announcements, found at https://kde.org/announcements.


KDE has so many apps that I really can’t possibly do them justice here! Nevertheless, here’s an extremely small assortment:

Dolphin got a new Selection Mode, a new (optional) list view selection style, the ability to browse iOS devices using their native afc:// protocol, an eject button in the sidebar list items of ejectable/unmountable volumes.

Okular got a welcome screen, a new Breeze icon that better matches the original, a UI overhaul for its sidebar.

Gwenview gained feature to annotate images and edit their brightness, contrast, and gamma.

Kate and KWrite got welcome screens, KHamburgerMenu support, searchable settings windows, keyboard macro support, and even more massive UX and feature improvements of all kinds due to an influx of new contributors and a higher tempo of regular development work.

Konsole got Sixel support, adopted KHamburgerMenu, added a plugin to save and restore text snippets, and moved its tab bar to the top of the view by default.

Spectacle was ported to Kirigami and now lets you annotate in Rectangular Region mode.

Filelight was ported to Kirigami and gained a sidebar.

Ark got a welcome screen, KHamburgerMenu support, and overhauled toolbar contents.

Elisa gained support for displaying auto-scrolling lyrics from songs using embedded LRC lyrics, .pls playlists, a real Full Screen mode, and improved presentation in Artists view, touchscreen UX improvements and overhauled playlist styling

NeoChat got encrypted chat support and a boatload of features and UI improvements!

Many QtWidgets apps adopted KHamburgerMenu for a streamlined presentation

Well that’s all for now, folks. Happy new year and let’s do awesome things in 2023!

Status of the 15-Minute Bug Initiative

It’s been almost a year since I announced the 15-Minute Bug Initiative for Plasma. In a nutshell, this initiative proposed to identify and prioritize fixing bugs you can find “within the first 15-minutes of using the system” that make Plasma look bad and feel fundamentally unstable and broken.

This initiative has been a huge success so far! We started out with 100 bugs, and 11 months later we’re down to 47! But it’s even better than that; more bugs were added to the list over time as new issues were discovered (or created as a result of regressions), so the fact that we’re at 47 today means that a lot more than 53 bugs have been fixed. How many more? Well, the total list of 15-minute bugs fixed stands at 95 today!

This means that in total, there have been 142 15-minute bugs, and we’ve fixed 95 of them, for a fix rate of 67%. That’s not too shabby!

There’s more to do, of course. The remaining 47 bugs are some of the more challenging ones, and many are quite egregiously bad. I expect the fix rate to slow as the list is reduced mostly to issues beyond the capabilities or time budgets of volunteers. That’s one of the reasons why the KDE e.V. is looking to hire a Software Platform Engineer; in addition to other responsibilities, the person we select will be working on some of these bugs. Hiring someone technically skilled enough to consistently fix these complex bugs won’t be cheap, and if you’d like to help KDE sustainably afford that cost, please consider donating to our end-of-year fundraiser! It really does help. Thanks for being awesome!

Help KDE hire more people!

KDE’s 2022 year-end fundraiser is now live! Please go donate if you can. 🙂

It’s been several years since we did a fundraiser at the end of the year, and we’re going to be more on the ball about this going forward, given how much the KDE e.V. is expanding hiring. This year’s fundraiser sets the fairly modest goal of 20k €, which will help offset the cost of some of that hiring.

But of course… there’s no reason not to exceed the goal! The more money raised, the more contributors the KDE e.V. can hire directly, effecting the kind of professionalization needed to take KDE to the next level! We have big plans and we can’t do it without your help!

I know I’ve asked for a lot of donations recently, so if you’re feeling tapped out, this is a good time to go nudge your friends and family members who you’ve converted to KDE over the years! 😉 Help KDE challenge the big dogs and win!

A better fundraising platform

KDE is getting a much more user-friendly fundraising platform, and it’s a big deal!

Currently our small-donor donation page is https://kde.org/community/donations, which lets you make a single one-time donation. To make a recurring donation, you have to visit https://relate.kde.org, which is less user-friendly, and it’s always struck me as odd to have these split up in two locations.

Well, KDE is getting a much better donation system powered by Donorbox, which I hope will turbocharge our fundraising! It’s very user-friendly and allows you to easily make recurring donations, which is important. We already set this up for the Kdenlive fundraiser, and it was a smash hit, raising 100% of the funds in the first month of the 3-month campaign. That fundraiser has since moved into stretch goals!

We’ve now done it again, rolling out a Donorbox-powered donation UI on https://kde.org/bluefriday, our tongue-in-cheek anti-black-friday fundraiser, which will become a general end-of-year campaign. This work was done by members of KDE’s promo team and fundraising working group, principally Lays Rodrigues, Carl Schwan, and Paul Brown. And so far the response has been huge! The fundraiser opened yesterday, and at the time of publication, it’s already collected 530€ from 28 generous donors! And after the new year, the current plan is to continue to use the Donorbox-powered UI for all small donations.

This really goes to show how important user-friendliness is. When you make it easy for people to give you money… they give you more money! Thank you so much, everyone.

Why is all this money stuff so important? Well, it’s how the KDE e.V. pays for hiring (such as for the Platform Software Engineer position I blogged about two days ago), development sprints, conferences, infrastructure, and similar activities that help KDE thrive and grow. If we’re gonna hugely expand technical employment–which is a major goal of mine–then we’re gonna need a lot more recurring donations to do it.

So what are you waiting for? Head over to https://kde.org/bluefriday and make a donation today. If it’s a recurring donation, we’ll love you forever! 🥰

KDE roadmap for 2022

Another year, another roadmap! Last year’s was a smashing success, as we delivered on everything. So here’s what I think we can expect in 2022. As always, this is not an official planning document or a promise; it’s just me giving you a sneak peak of some things that are in progress or about to start, and that I think will be feasible to complete before the year’s end!

Merged “Formats and Languages” KCM

The Languages and Formats pages in System Settings have long been problematic because their scopes overlapped. Not for long! Han Young is working on merging them together into one new page that handles both, making it clear what applies when and making it harder or impossible to mess up your system by choosing incompatible settings. This is in progress and I expect it to be completed sometime in the first half of 2022.

Overhauled Breeze icons

KDE designer Ken Vermette is working on improving and modernizing Breeze icons! Colorful icons will be softened and rounded a bit, and visually updated to remove old ugly elements like the long shadows. Monochrome icons will eventually get attention too. All of them are expected to become more responsive to your system color scheme, and look better when doing so. Initial work for Places icons has already been submitted and is being reviewed. This work will soon start landing piece by piece, and you can read more about it on Ken’s blog.

Multi-monitor stuff finally works properly

We plan to focus quite a bit on resolving multimonitor issues this year, and some of that effort has already borne a bit of fruit so far. But there will be a much heavier focus in 2022!

Inertial touchpad scrolling in QtQuick software

A big improvement went in recently that will make this possible to do soon! It seems quite likely that we’ll finally have this sometime in 2022.

The Wayland session can completely replace the X11 session

This is a bit of a moonshot but I think it’s possible. The list of issues on our “Wayland Showstoppers” wiki page is quite low, and when new ones are added, they’re notably lower in severity than the ones that have already been fixed. And now that NVIDIA has added GBM support to their driver and KWin already supports it, I think life should really start to get better for NVIDIA users, who represent a large chunk of dissatisfied Plasma users and those still unable to use the Wayland session at all. Let’s call this a stretch goal, but I think it’s not impossible!

“15 minute bug” initiative

This year I’d like to start something I call the “15 minute bug” initiative–an effort to fix as many of the bugs as possible that are trivially encountered within a quarter hour of basic usage. These are the kinds of issues that form permanent negative opinions in people’s minds, and reinforce the perception that KDE software is buggy and unreliable.

So far I’m limiting it to Plasma and Plasma-aligned software (e.g. KWin, System Settings, Discover) to avoid getting overwhelmed by scope creep. But if it’s wildly popular and successful, I’d love to extend it to apps and frameworks as well! Check out the current list here. I’ll be writing about this in more detail soon!

So that’s the list! What do you think? Is there anything else you think we should focus on in 2022?

Be flexible to win big

My goal of KDE Plasma World Domination is not a secret at this point. But what does it truly take to get there?

Let’s look at the existing market leaders in the OS space: Microsoft’s Windows and Google’s Android. Neither was the first to market, but they were the first to successfully serve the mass market. Neither is picky about what kind of software you run on them or write for them, so they are used on a wide range of devices by lots of different people. Both work with others in adjacent industries, rather than taking a “my way or the highway” approach. They are flexible.

Before KDE, I came from the Apple world, which takes a different approach. Apple identifies distinct use cases and focuses their efforts like a laser on making them as polished as possible. This works very well, but it requires ignoring, abandoning, or explicitly blocking other use cases, and sometimes inventing new things that conflict with what others are doing, in the hope that their new thing takes over. It requires saying “no” a lot and being opinionated.

Apple’s opinionated approach worked well for me with my own personal use cases in my pre-KDE days, as it did for many millions of other people. But evidently it doesn’t work for everyone, as Apple’s products routinely fail to crack 15% market share. And when they do, they often fall back down to that level after competitors emerge. But that’s okay, because Apple isn’t going for the mass market anyway; they’re happy in their profitable and opinionated boutique niche.

But that’s not KDE, and it never has been; we’ve always dreamed of a broad scope and being useful for everyone. This is what’s behind Plasma desktop’s extreme flexibility; Plasma Mobile for phones; Plasma Bigscreen for TVs; and Plasma Nano for embedded devices. It’s why the Steam Deck handheld gaming console, PinePhone smartphone, and JingPad A1 tablet are built on top of KDE technology.

To be the market leader, you must be flexible enough to accommodate everyone’s weird and random use cases. This includes grandmas, gamers, businesspeople, students, teachers, phones, tablets, shared family PCs, kiosks, and everything in between. It means you have to give up a certain amount of that laser-focus on making a particular use case bulletproof, in favor of flexibly accommodating everyone and working with partners to support their needs so that they can build their products on top of your platform. Windows and Android do this, and so does KDE.

This, fundamentally, is why I believe KDE can and will take over the world. We share the market leaders’ winning strategy and culture of flexibility, and we can supplant them by leveraging our advantages of being free and eternal, our resistance to turning evil because of our diverse stakeholders and decentralized leadership model, and our philosophy of keeping the user in control rather than exploiting them for ad or upgrade revenue.

So I think ultimately we will become the Windows or Android of the Free Open-Source Software world, with projects like GNOME and ElementaryOS competing to be the Apple of FOSS. I think there will absolutely be room for projects like theirs; in fact I think it’s highly likely that they’ll offer a better user experience than we do for people who fit within the usage paradigms they focus on–just like Apple does.

None of this means that we actually have to make our stuff look or behave like Windows or Android, of course. But it means we need to retain their philosophy of not shutting anyone out. We need to stay willing to make changes for vendors who want to ship our software and developers who want to write apps for our platform. We need to keep listening to our users and trying our best to make our software work for them. We need to remain flexible.

And I think we’re doing this. Which is why we’re going to win.

It may take a few decades, but I believe it’s going to happen. If you agree, help get there faster! This crazy thing only works because of people like you and me and all of us. There is no “they” in KDE. So c’mon, get involved and let’s take over the world together.

Why pre-installation is so important

Linus Sebastian of Linus Tech Tips recently did a long-form chat about the Steam Deck and Linux in general. A major complaint was that Linux is too hard to install, and this gets to the heart of why I believe pre-installing our software on devices like the Steam Deck is so important.

The truth is that Linus is right; a Linux-based OS is too hard to install. Only huge nerds can manage it or even have the courage to try in the first place, and it’s easy to be overwhelmed in the process. But let’s face it: this would be the case for Windows or macOS as well. Imagine if every computer was bought as an empty shell and the user needed to choose an operating system, research compatibility, flash a USB drive with the selected OS or buy a DVD or something, and then install it. You think grandma is gonna do that? I don’t think so. How about a busy professional? Forget it.

The only way this works is if the OS comes pre-installed on the physical hardware that people can buy. Then the overwhelming selection process and the technical fiddliness are gone, and people can just start using what they bought. …Like they can when they get a Steam Deck, which comes with Plasma. Or one of the other devices with Plasma pre-installed.

Pre-installation is the only way to grow Plasma out of the clubhouse of the uber-nerds like us. Which means we need to focus on the kinds of issues that are barriers to vendors wanting to ship their hardware with Plasma, or to regular people using the system normally.

This is what matters!

How I learned to stop worrying and love the hamburger menu

Yesterday we introduced KHamburgerMenu to the world, and I wanted to talk a bit more about it, because I think it’s a very exciting UI control in ways that may not be immediately obvious.

But first some background: a few years ago I wrote a big long post criticizing GNOME-style headerbars, and one of my complaints was that adopting them requires the replacement of traditional menu bars with hamburger menus. You know, this little thing:

Because the button’s icon looks like a hamburger, gedit? I’ll show myself out now

Specifically, here are the problems I see with GNOME’s hamburger menus:

  • They are mandatory with the headerbar design because there is no place to put a traditional in-window menu bar.
  • To condense the entire app’s non-visible functionality into a small hamburger menu, you have to remove a lot of features, making it unsuitable for large and complex apps because there’s simply no way to fit in all the functionality.
  • GNOME hamburger menus don’t show keyboard shortcuts, so they fail to teach users how to become more proficient right at the point of use for each feature.
  • GNOME headerbar items can’t have custom drag behaviors in order to preserve window draggability, so they don’t let you click-and-hold to open, slide the cursor over an item, and release to select that item.
  • GNOME hamburger menus are implemented as a widget inside the app’s window, so they can get cut off if the window is too small–reinforcing the need to avoid putting too much stuff in them (EDIT: apparently this is fixed in GTK4 on Wayland):
lol (note: laughter is only applicable to X11)

Our grass isn’t that much greener

However, I think at the time I was being too kind to traditional menu bars to help me make my argument. Over time I have sometimes found myself frustrated with how hard it is to actually find anything quickly in traditional menu bars. Every time I use a GNOME headerbar app, I have to admit that as an infrequent user, I appreciate the approachability and speed of their simple and consistent hamburger menus. The apps feel friendly and easy to use, not overwhelming as some KDE apps can be (though I think we’re getting better about this). And I think our flagship apps’ use of huge menu bar structures is a part of that feeling of overwhelmingness. If we’re being honest with ourselves, we need to admit that traditional menu bars can suffer from a variety of well-known problems that we can’t just ignore:

  • Menu bars are designed to show everything, so they are inherently duplicative; a button visible in the toolbar or status bar still needs an item in the menu bar. This causes the menu structure to become enormous with medium to large apps. Because menu bars are not context-aware, they’re always full of disabled menu items that you have to ignore, or wonder why they’re disabled. Thus it becomes harder to find any given menu item since you need to mentally filter out all the irrelevant ones.
  • Menu bars require strict categorization for every action which can become nebulous or nonsensical. Why are the “New Tab” and “Quit” menu items typically in the File menu? Why is “Search” in the Edit menu? Why is “Donate” in the Help menu? Because there weren’t any better places to put them without adding even more top-level menus, which would make everything harder to find. And depending on the toolkit or OS, an app’s “Preferences/Configure” item can be found in the Edit menu, the Tools menu, the Settings menu, or even somewhere else entirely!
  • Finding anything in a menu bar is slow. There are generally between 4 and 12 top-level menus, and because items are imperfectly categorized, in practice you end up having to just scrub through all of them to find what you’re looking for. With big apps, menus are very long, so this takes forever. macOS goes so far as to offer a menu item search feature just because it’s usually faster to search than to actually use the menu structure!
  • Because a traditional in-window menu bar consumes a row in the window’s header area, it wastes all the space to the right of the menu, and can cause the header area to become quite thick when it also has a titlebar, a toolbar, a tab bar, a URL bar, and so on. This can add up, especially for laptops with 16:9 aspect ratio screens.

So if the grass isn’t greener on the other side, but it isn’t greener on our side either… where can we find some green grass? It can’t be a barren wasteland everywhere!

UI design has to be better than this, at least somewhere! (with apologies to the U.S. state of Nevada, which is not all this ugly)

A place for everything, and everything in its place

For big apps with lots of features, menu bars are probably here to stay. They aren’t perfect, but humanity hasn’t yet figured out something appreciably better: hamburger menus can’t fit everything without becoming insane; ribbons take up much more space and suffer from the same categorization problems; sidebars take up even more space; trying to put all the controls inline with 100% context sensitivity becomes overwhelming. The jury’s still out on this one.

And this is fine: since KDE apps don’t use headerbars, there is a place for a powerful app’s menu bar to live without infringing on any other UI element’s turf. We fully support traditional menu bars and we always will!

However for smaller apps with less functionality, a menu bar can be overkill. As I mentioned earlier, I think a well-designed hamburger menu is quite pleasant to use, even if its implementation in GNOME is quite limiting and suffers from technical restrictions. If only there were a way to have the advantages of such a clean and friendly setup for small-to-medium apps, without any of its disadvantages…

KHamburgerMenu to the rescue

And this is where KHamburgerMenu comes in. While designing it, we were conscious of the problems with GNOME hamburger menus and specifically set out to avoid them, while also trying to match it to KDE’s existing technical and cultural conventions:

  • The hamburger menu provided by KHamburgerMenu is optional; if you just don’t like hamburger menus, you can use a full traditional menu bar if you like. And apps that are so powerful and complex that they demand the use of a full menu bar do not have to adopt KHamburgerMenu at all if they don’t want!
  • A KHamburgerMenu toolbar button is just another ordinary toolbar button, so you can move it to another place, give it some text, change its icon, or remove it entirely if you are a fussy advanced user who wants no menubar and no hamburger menu. It’s your choice! The system adapts to you, not the reverse.
  • KHamburgerMenu menus provide emergency access to the full menu structure in case the curated set of actions isn’t enough, which eliminates the need to remove features to conform to the new UI style for apps that do adopt it!
  • KHamburgerMenu menus show keyboard shortcuts, so they teach the user how to become more proficient in using the software!
  • KHamburgerMenu menus let you click-drag-release to quickly trigger an item!
  • KHamburgerMenu menus are traditional menus, so they aren’t limited to the dimensions of the window even on X11, further reducing the pressure to make them as small as possible!
  • KHamburgerMenu can modify the contents of its menu according to what’s visible on the toolbar. For example in Dolphin, the menu can avoid showing the “Sort By” item because this would be redundant with the one on the toolbar, but if you remove that button from the toolbar… it can become visible in the hamburger menu!
Again, this layout is not final! 🙂

I think KHamburgerMenu will truly bridge the gap for KDE’s moderately powerful QWidgets-based apps like Dolphin, Okular, Gwenview, Konsole, KWrite, and KCalc–providing the space savings and pleasing single entry point of GNOME-style hamburger menus, without its drawbacks of being inflexible, mandatory, limited in size, hiding keyboard shortcuts, and requiring that adopting apps remove functionality. If we get it right, our flagship apps will feel much more approachable while not losing any of their powerful features or customizability. Doing this in a flexible and optional way is more work, of course–and if we’re honest with ourselves, it will probably lead to more corner-case bugs. But that’s the KDE way. 🙂 We have to be true to who we are, even when we march boldly into the future!

High DPI update

I’d like to share a brief update regarding the state of high DPI support. Since getting a laptop with a 4K screen, I’ve found all sorts of subtle papercuts and have been doing my best to fix them or at least file bug reports. Here’s what’s been fixed recently:

Fixed recently

…And the work continues! Here are the bugs next on my list to investigate and try to fix:

Next up

A lot of the above issues are sort of stretch goals for me as each one requires a great deal of learning before I can even begin to try to put together a halfway-intelligent fix. So feel free to help out if you find this work useful and have relevant skills!