Category: Usability & Productivity

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!

“Why don’t you just fix [thing] already?”

The title of this post is a somewhat common gripe among users. Its obvious answer is that resources are limited and people were working on other things.

Duh! Not very helpful.

We need to dig deeper and find the implicit question, which is “Why wasn’t [thing that I care about] prioritized over other things?” This is a more accurate and useful question, so we can arrive at a more accurate and useful answer: because other things were deemed either more important or more feasible to fix by the people doing the work.

Why would other things be deemed more important? For bugs, it’s because they affect everyone and are trivially reproducible. The ones that get overlooked tend to be more exotic issues that are not easily reproducible, or only affect niche use cases or hardware. Put bluntly, it’s appropriate that such issues are de-prioritized; it should be obvious that issues which affect everyone and are trivially reproducible are more important to fix.

Let’s step back a moment: in my experience, this is exactly the same as in closed-source software companies. Every piece of closed-source software has multi-generational bugs, baffling mis-features, and things that make you wonder, “jeez, why didn’t they fix this years ago?” Anybody who uses Windows, macOS, Android, or iOS can rattle off half a dozen examples instantly. So it’s not like FOSS is especially bad here.

Still, it’s still not a very satisfying answer if you have an exotic use case or hardware that exposes you to an annoying issue.

However, it leads to one of the beautiful advantages of open-source: you can actually dig into the code and fix the issue yourself, then submit the fix! If you lack those kinds of technical skills, you can learn them, or maybe cajole a technically savvy friend into doing it. Or you can sponsor a developer to fix it, paying them directly. You can write a polite blog post about the issue to draw attention it. You have options.

These are all options you don’t have in the closed-source world, where your only option is to live with the issue until it happens to come to the attention of an executive, manager, or other decision maker who experiences it, or when user feedback indicates that it’s not as exotic as originally believed. However this is totally random; you have no control over the process. Also, once this happens, engineers are pulled off other tasks and asked to fix the issue. So while it does eventually get fixed, no new engineers are ever hired specifically to fix little issues, so as a result the pace of development for everything else slows down a tiny bit.

The open-source world has a real advantage here, in my opinion. There are many more ways for users to get involved in fixing the problems that affect them.

So what a great time it is to fix some of the little annoying issues you’ve been living with forever! If you’re strapped for ideas, you can find some lists of bugs here. We make it really easy to compile KDE code from source, so you can get hacking. Check out https://community.kde.org/Get_Involved/development

So what are you waiting for? GET TO DA CODE!

DO IT NOW!!!!!!

Why the animations in your Plasma 5.18 feel slow now, and when it will be fixed

KDE Frameworks 5.70 was just released and should be trickling out to users of rolling release distros at any time. Various Arch users who have already received the update have been complaining about slow animations in Plasma, and I wanted to write a blog post to explain what’s going on here. It is a bit technical so let me start with the TL;DR version: “releasing software is complicated and this will be fixed once Plasma 5.19 comes out next month.”

—

For the longer version, allow me to explain:

This is caused by an unfortunate timing problem stemming from the different Plasma and Frameworks release schedules.

Plasma and Kirigami-based apps use standard duration values for animations (e.g. units.shortDuration, units.longDuration, etc.) to keep animation timings relatively consistent. These duration values are set in the respective Frameworks: plasma-framework and kirigami.

I recently discovered that Plasma units were far shorter than Kirigami units. For example a Kirigami units.longDuration unit is 250ms, while a Plasma units.longDuration unit was 120ms–over two times faster. A Kirigami units.shortDuration unit was 150ms, while a Plasma units.shortDuration unit was 24ms–almost too fast to see. In practice the Plasma units.shortDuration value was useless and always had to be multiplied by something. Even most of the longDuration values were being multiplied by random numbers too. So we wound with animated transitions throughout Plasma having timings like units.shortDuration * 4 or units.longDuration * 3. It was a classic problem of badly-chosen library constants that force apps to work around them and munge them this way and that, totally defeating defeated the purpose of using standardized values in the library in the first place. There was not actually any standardization at all!

I needed to fix this as a part of my introduction of a new animation-using component, the ExpandableListItem (which I keep meaning to blog about): https://phabricator.kde.org/D28033

I fixed the Plasma units to be the same as the Kirigami units in https://cgit.kde.org/plasma-framework.git/commit/?id=0739113a4477e1eb25bf13b0040af5a502d3ef0a, and then fixed Plasma itself to no longer multiply the units in a series of other commits. However this presented an issue: Plasma and Frameworks have different release schedules! So people will not get both aspects of the change at the same time! This means that for a time, some people would have animations that were undesirably slower or faster. How should this be handled?

Unfortunately there is no easy way to do conditionals depending on a frameworks version in QML code as we can in C++ code, so that easy option was not available. Probably something to look into implementing.

So we had a few options. One was to avoid solving the problem until Plasma 6, several years in the future, at which point we could do everything at once. This was not deemed satisfactory, as the issue was blocking the ExpandableListItem patch which was needed for a task targeted for Plasma 5.19. Another option was to leave the existing units alone for Plasma 5, and add new units with different names now, and have Plasma 5.19 use those new differently-named units. This would have avoided the issues you’re all experiencing, but would have resulted in terribly confusing code. In the end we decided to spare ourselves the potential for new bugs stemming from that.

The final option was to wait to make the Frameworks change in a Frameworks release that lines up as closely as possible with the Plasma 5.19 release. Plasma 5.19 depends on Frameworks 5.70, but always releases about a month later, at which point Frameworks 5.71 will be out. This option therefore presented two sub-options: put the units change in Frameworks 5.70 or 5.71?

If we did it in 5.70, there would be a one-month period in which people using rolling release distros suffer from slow animations, because they have Frameworks 5.70 but not Plasma 5.19 yet.

If we did it in 5.71, the period of time in which people suffered from this issue would still exist, but it would potentially be shorter. However depending on distro release schedules, if a distro released Plasma 5.19 *before* Frameworks 5.71, then animations would become too fast to see! Furthermore, any discrete release distro in the future that shipped Plasma 5.19 with the 5.70 Frameworks version it depends on rather than a newer one would then have all of its users suffer from the bug forever (or at least until its packagers backported the plasma-framework commit).

So shipping the units change in Frameworks 5.71 did not seem to be a realistic option. In the end I shipped the units change in Frameworks 5.70 knowing that rolling release distro users (myself included) would suffer from slow animations for one month. Sorry. 😦 It will all be fixed in Plasma 5.19.

Software is complicated!

This week in KDE

See, I told you I’d continue to blog about the cool things that have happened in KDE-land. 🙂

On that subject… Kate is now available for free on the Microsoft Store! So far the ratings are quite good. 🙂 KDE has always aspired to make our apps available to as many users as possible, and getting them on today’s distribution platforms continues that.

For those of you who switched from Windows or macOS, think back to how helpful it was that a bunch of your favorite apps (Firefox, Chrome, VLC, LibreOffice, Inkscape, Blender, Krita, etc) were already available on Linux and you already knew how to use them. Getting more of our apps on other platforms is a key part of easing the transition for future generations of switchers. 🙂

Beyond that, it’s been a somewhat light week because everybody was off at Akademy planning the future. A lot of really great things got discussed and decided, the results of which should start to trickle into subsequent weeks’ blog posts. 🙂 So stay tuned!

New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

This is a new section I’m adding to these weekly blog posts, highlighting a new way to get involved every week!

Do you have any web design experience? KDE community members are currently working on redoing the ancient and inconsistent assortment of websites hosted on kde.org, and help is needed! If this sounds like your cup of tea, join the kde-www mailing list and check out the tasks on the Phabricator Workboard.

You can also check out https://community.kde.org/Get_Involved, and find out other ways to help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

KDE Usability & Productivity: Week 87

This is the last week in KDE’s Usability & Productivity initiative (next week the blog posts will continue, but under a new name). The voting results are in for KDE’s new goals and the community-selected winners are full Wayland support, consistency throughout the KDE ecosystem and software, and a renewed focus on KDE apps. Read all about it here!

But meanwhile, there’s a ton of stuff to announce right now, so let’s jump right in.

Serendipitously enough, something big landed this week that’s relevant to the first new goal: fractional scaling on Wayland!!!

Check out the complicated dependency tree of patches that were required to make this happen:

Veteran KWin developers Roman Gilg and David Edmundson have been working on this for ages, and all of their hard work–which will land in Plasma 5.17–is much appreciated. But wait, there’s more!

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

KDE Usability & Productivity: Week 86

Here’s week 86 in KDE’s Usability & Productivity initiative! There are lots and lots of cool changes, which is especially impressive as the KDE community prepares for Akademy, which kicks off next weekend. Sadly I cannot attend this year–there was an unavoidable scheduling conflict with my best friend’s wedding–but I will be there in spirit! In the meantime, check out the progress:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

KDE Usability & Productivity: Week 85

I’m not dead yet! KDE’s new goal proposals have been announced, and the voting has started. But in the meantime, the Usability & Productivity initiative continues, and we’re onto week 85! We’ve got some nice stuff, so have a look:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.