Hacker News Reader

Comment by smallerfish | Hacker News Reader

Good job KDE team - nice to see steady progress.

I encourage anybody using KDE to occasionally file tickets at bugs.kde.org; Nate is a powerhouse and seems to review all inbound tickets, and anything critical will reliably get worked on within a reasonable period of time. They're also very open to ideas and feedback (that fit into their general UX guidelines.)

I would love to see more distros switch to an opinionated KDE (and also to KDE by default). It's so malleable, and yet most distros just dump the basic default setup on users.

View on HN

It's great to see, though my main gripe with KDE right now is Dolphin, the file manager. It tries to do everything but is just ever so slightly buggy in every way, it can't run as root, and asks to confirm saving twice every single time when editing a networked file. As much as it is less featured and ugly, Nautilus was less annoying to use.

Dolphin is legitimately my favorite KDE program. My experience is that it's a phenomenal productivity tool. Being able to quickly open or close a terminal. How customizable the ordering and appearance and columns are. Easy to manipulate tabs.

I think I can count on one hand having a root file manager would be beneficial. Are you logging into a desktop as root?

> Dolphin is legitimately my favorite KDE program.

Happiness is clicking on a folder with lots of files, hitting forward slash, typing a search term, and instantly finding your file.

I thought I didn't even have to hit / ? Perhaps that's in file picker mode.

It is in file picker.

> Are you logging into a desktop as root?

Nah, but I would occasionally like to move things around outside of /home without doing it manually in the terminal. I'm not sure why that's such a problem.

Dolphin can do that! You'll need to install kio-admin and you'll get an option to "open folder as root". After you authenticate, you'll be able to e.g. move files in /etc/

See https://invent.kde.org/system/kio-admin for details.

This will be included in dolphin natively in the near future.

Thank you for the tip, didn't know that!

I promise not to tell you "you're doing it wrong" but I would love to know what your use case is. What files are you moving so often, and why? Thank you.

I've historically had a lot of problems with Dolphin too. It has gotten a lot better though.

Try https://github.com/lxqt/pcmanfm-qt as an alternative.

It feels native in Plasma/Breeze and is more traditional. I like it.

I wonder, why are more people not using Krusader? I understand it is a nuclear bomb for killing mosquitos, but with a bit of tweaking it can be fast and easy to use; plus, when you really need the big guns, you have them right there.

I've been using KDE since the beginning, and have never heard of Krusader before reading your comment. Maybe I'm not the only one, and that's why?

Looking at it quickly, it doesn't seem to be my cup of tea, but until now I didn't even know it was there to consider.

I can't believe! I recently filed a ticket and the guy who reviewed was the KDE leader? If you are reading this, thank you Nate.

Well open source project leaders don't tend to be CEO likes that are far removed from the actual work. They are usually just regular contributors (well often the most active one) that have taken on the leadership role because someone has to.

"I encourage anybody using KDE"

Don't you effectively need to be running Neon, b/c you can only file tickets against the latest version? I have lots of small bugs with Ubuntu LTS (particularly with KDE Connect transfers) - but I assume nobody is interested in those. They're also basically impossible to replicate (ex: "Transfer failed for unknown reason" or "File arrived corrupted for unknown reason")

I don't know how much it affects priority, but they certainly accept bugs filed against older versions. Specifying versions is a big part of the form for a new bug, and they let you select versions going way back.

I have a feeling they wouldn't accept bugs filed against NixOS, however, considering the huge number of patches applied.

Which is a problem. NixOS remains by far the least aggravating OS I know, and... yeah. I wish there existed a desktop environment that played well with it.

Just submit a bug. If they dont accept it submit a bug to NixOS about KDE not accepting NixOS KDE users bugs.

I second my sibling comment -- just submit a bug. I think you are wrong that they would ignore it just because their context is somewhat different. Linux is full of differences like this.

But also: Isn't one of the main benefits of NixOS that you can fairly painlessly get and try different versions of things? Just see if you can reproduce the bug in the same version of upstream. If so, file the bug with kde, if not, file the bug with NixOS because it's presumably caused by one of the patches.

I think the point is that it won't run on NixOS without patches

From my experience, reproducibility is king. If you can give a formula to reproduce a bug, even if it is obscure, it makes it so much easier to track down.

That can be up to and including a downloadable VM image that shows the issue.

This concern is a bit overblown here. There are 23 KDE patches at the moment, across multiple packages. kwin itself has 5, plasma-desktop has 4. Each one has an extremely limited scope - mostly one line changes related to paths rather than visible functionality.

If you have a specific issue under nixos, it's going to be fairly easy to see if it's very unlikely to be caused by custom patches.

Out of interest, what are the issues you're facing? I'm having a great time with NixOS / Plasma 5

They have accepted bugs from NixOS before (there are nearly a 100 marked as "NixOS Linux" at bugs.kde.org), and I don't see any major reason they would stop. It's true there are many patches for the KDE libraries and Plasma, but realistically most of them are fairly "procedural" changes to adapt to non-FHS layouts, etc.

For reference I count about ~66 patch files among the KDE expression in nixpkgs as of today, including Plasma, all libraries, and related apps. Most of them are in the range of 20 lines long, and they are .patch files, i.e. the actual applied diff is smaller than that. The largest patch is barely 190 lines long and it's for Akonadi, mostly rewriting hardcoded FHS paths throughout the codebase.

I agree there are some quirks with most desktop environments on NixOS in my experience but realistically there's a huge amount of stuff in the ecosystem that plays anywhere from well-to-poorly in such environments, and the Linux desktop stack definitely was not designed at a time where this stuff was common. It is what it is, I guess.

I am using KDE on NixOS and IME there are no issues except the occasional screen freeze on X11 with Nvidia cards (and none with Wayland, you read that right!). Filed bugs and merged changes too.

FWIW your attitude is correct in general. When you have a bug with a distro package and you haven't root-caused it yourself to a bug in upstream source, the best thing is to report it on the distro tracker. The distro package maintainer can then do that root-causing, and if they determine it's an upstream bug they can forward it to upstream.

This is how it used to work (and still does with enterprise distros, because you might as well use the support contract you paid for). But users these days have gotten savvy enough to start engaging with upstream directly, especially since many upstreams have made it easier to be engaged with by using GitHub etc instead of mailing lists etc.

Sometimes engaging directly with upstream works, as it apparently does with KDE according to other comments in this thread. Sometimes upstream gets annoyed because they only care about their tree, eg systemd devs get annoyed when users report bugs that have long been fixed in master, but still exist in an old stable release that happens to be the latest on some LTS distro. It depends on the project, so when in doubt start with the distro tracker.

It works great on FreeBSD and I get the latest versions within days of release.

I will be _very_ surprised if there's a KDE6 in official ports within three months.

It's already there for several months. From the last status report:

> KDE Frameworks 6 (alpha) 5.247 was updated in the ports tree.

> KDE Plasma Desktop 6 (beta 2) 5.91.0 was updated in the ports tree.

https://www.freebsd.org/status/report-2023-10-2023-12/#_kde_...

I use Debian Testing which trails release by a couple of versions. I search the bug in the Bugzilla, and if it's not filed, I file the bug. Sometimes it's marked as a duplicate (but additional feedback is useful), sometimes new, but very rarely a duplicate of a closed bug.

So, you don't have to use Neon. KDE is a massive project.

I don't know how long it will take KDE 6 to arrive on Ubuntu LTS, but there have been several networking improvements to KDE Connect in this release (including supporting mDNS and bluetooth for more reliable operation), so possibly it may be better for your use case now?

>how long it will take KDE 6 to arrive on Ubuntu LTS

Probably Ubuntu 26. The release notes for 24.04 do not mention kde6. It is also likely the 25.04 or 25.10 release will incorporate kde6.

You can always add the NEON repos to get KDE 6 on Ubuntu LTS. I'm running with that right now on 22.04. Be sure to also add a repo to get newer Pipewire, as that really helps to avoid many papercuts.

Any rolling release distro is probably fine? openSUSE Tumbleweed generally gets new packages within a week or two of release.

> anything critical will reliably get worked on within a reasonable period of time.

And "resolved" like [0] which is a 9 year old regression is marked "resolved upstream" becase KDE devs refuse to implement a workable solution FOR KDE like there used to be in 3.x and 4.x and instead require a perfect solution that will never happen as can be seen by the bug report's age. Not worth my time to report bugs if they will be treated like this.

[0] https://bugs.kde.org/show_bug.cgi?id=340982

I'm sure you can find a similar example for any significant FOSS project, including GNOME, but that doesn't mean it is a general stance adopted by developers when a new bug report comes in.

KDE should probably invest in better defaults if these need tweaking.

People don't usually dig in the settings menu unless something is bothering them. If there are great opt-in features they're going to stay off.

just what they did with V6.

Most people I know that use KDE use it because it's so customisable. It's not the same crowd as Gnome. I don't think this is an impediment at all.

I'm using KDE for 20 years already because it has great miscellaneous apps (though it's less important in 2024), slick integration between components and nice all-encompassing settings app. I do tweak a few things when I boot up a fresh install, but generally, I don't feel the need to do a deep customization, and am not aware of any missed opportunities.

> I'm using KDE ... because it has great miscellaneous apps...

KWrite and Dolphin are insane!

Agreed - the main reason I switched to KDE from Gnome was so I could have a vertical taskbar.

Heh, in the meantime modern Gnome doesn't have a Taskbar at all, because it "is not ok to distract users with a list of other things they could be doing when they have already selected one task to look at"...

Is that a quote? I couldn't find the source if so. Hard to tell if it's a joke based on other GNOME statements.

I don't know either if it's a joke.

The way I always thought of it is that the taskbar generally just can at best have a limited set of applications listed and takes up precious vertical monitor space, so its mostly limited to the overview/activities since that is the "I want to change apps" mode of the desktop and is just 1 click away (either super or top-left on the desktop).

Then again I am one of the (probably) few people that would probably even do away with the top bar currently still in GNOME and not have anything other than the app visible by default.

I use to be annoyed at the behavior as well when I started using GNOME, but at some point I actually started preferring it and now barely use the taskbar on Windows.

I remembered it as a version of what some Gnome designer claimed, but I tried searching for some statement on the topic and I couldn't find any explicitly mentioning it.

it suits my workflow since all windows are full screen on all the monitors. I either use alt+tab or super key to get the exploded view.

it won't suit all workflows of course

That not only depends on preference, but also on hardware. When only using laptop display, most of my windows are full screen. However, when using a 32 inch 4K display, I prefer my windows smaller, often having multiple windows side by side, sometimes tiled.

There are merits to the GNOME design philosophy. My Sway workflow and customizations are actually inspired quite a bit by GNOME. I don't use any taskbar or system tray. I don't even have a clock; I open a terminal and check the date command if I want to know the time. I make heavy use of workspaces rather than "minimizing" (Sway calls this the scratchpad or something like that, which I only use if I want to "background" graphical applications). I have absolutely no flashy styling or animations; I simply use nord where I can.

It's not for everyone. It would be next to impossible for someone to sit at my computer and be productive, because I have accumulated my configuration over years, with no real thought into making things that I configured discoverable (I know it's there because I put it there). But it works really well for me. I find the ability setup a workspace how I want for one task, and then switching workspaces to context switch to be very nice.

I do something very similar in KDE with a whole bunch of virtual desktops. Though I do use a taskbar because I like the overview of it but I don't actually use it to switch tasks :)

I always thought Gnome was not very useful for this because workspaces are created on the fly whereas I want to have them spatially oriented in a fixed grid that persists on every boot with the right application tiles in them. And I have hotkeys mapped to each one directly on the numpad (without key combos, I hate those). So my numpad is not a numpad at all but a workspace switcher :P

The problem with the gnome design philosophy is that it only works for you if you agree with them on everything. If you're pretty opinionated yourself (as I am and it sounds like you are too), opinionated software only works well if you have the exact same opinions as its creators. With something as complex as a DE this will run into many mismatches quickly. This is why configurable software is so great if you're not willing to compromise on how you want things.

Current versions of Gnome allow setting a fixed number of workspaces in Settings, Multitasking.

To configure hotkeys, you have to set some dconf entries manually, with dconf-editor or gsettings from a terminal:

> gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-1 "[\"<Super>F1\"]"

I absolutely agree that it's nice for this to exist as an option for users who are used to it. I'm a somewhat heavy emacs user, so I'm not at all opposed to esoteric workflows.

But I think it's clearly proven to be a bad design as a default. Discoverability is very important, especially to people who work a lot with a mouse. And using multiple apps at the same time is a very common work flow, one that an always-on-screen task switcher makes much simpler than an alternate view you have to bring up, especially if that alternate view also obscures all of your windows.

I will also say I find workspaces a hard to use UI, as I always lose context when I have to switch workspace, but maybe this is just how my mind works. And the idea of one-task-per-workspace has never worked well for me, as there are several apps that I use in every task, such as chat or email while I'm coding and while doing a presentation and while writing some design. It also seems to require a lot of setup and discipline.

Finally, as a nitpick, moving apps to a different workspace instead of minimizing to taskbar/systray seems like much more work to me.

Personally I'm a huge fan of Win7's grouped taskbar with window previews, along with its window snap support (extended in Win 10).

I'd say workspaces aren't for everyone, and you're right: they require setup and discipline or else the context switching is too disruptive. I think they're good if you can organize them effectively with separate tasks on the different workspaces, such that you don't need to switch between them frequently: this way, you can minimize distractions from other tasks that you're not working on currently, and might not work on for hours or days even.

For the chat and email stuff, as long as you have screen space (or if you don't mind them going to the background sometimes), you can set those windows to be on every workspace. KDE has a thumbtack icon that you can click in the window bar to make that window show on every desktop.

> Finally, as a nitpick, moving apps to a different workspace instead of minimizing to taskbar/systray seems like much more work to me.

I specifically want to reply to this, because it is not at all how I use workspaces. I almost never find myself moving an application from one workspace to another. Instead, I switch to a new workspace before opening the application (causing the application to open on the new workspace), unless I know I want to use the new application at the same time as an application on an existing workspace. Switching workspaces essentially replaces alt+tab in my workflow.

I don’t want to “but, actually” this, but actually…

Gnome does what it does because Gnome is not intended to be the final form of a DE that the user uses. Gnome is intended to be a DE that distros can make their own by adding their own opinionated choices, extensions and modifications on top.

So while you complain about the lack of a vertical taskbar, in actual practice, outside of maybe Fedora users (which is essentially a distro largely designed to be used as a test bed), nearly every other Gnome user does have some form of taskbar because their distro included it, or they did a 1-click install from the Extensions app.

I don't agree. Reading Gnome designers' blogs makes it pretty clear that they strongly believe in these decisions as the best UX. Looking around Gnome reddit there's also plenty of people who like this minimalism and think it's actually superior [2].

That's not to say that the designers are not supportive of the existence of extensions. They clearly do, that's why they make a nice Extensions app in the first place. But they never say "yeah, we made it as barebones as possible to make it easy for extensions". They explain why it's better for users not to have a minimize button on windows [1], or why they've removed the systray to avoid confusion and so on [0].

[0] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gno...

[1] https://afaikblog.wordpress.com/2011/03/01/where-did-the-but...

[2] https://www.reddit.com/r/linuxquestions/comments/11bhxa7/com...

Most useful software that badly needs usability improvements has a group of people that just got used to it, and they will complain bitterly about any attempt to correct UI mistakes. If it’s customizable, they can configure it back after making improvements so it’s useful to everybody else, too. I hate the way gnome is set up, and welcome any updates to KDE with open arms.

> If it’s customizable, they can configure it back after making improvements so it’s useful to everybody else, too.

That is still creating needless work for existing users. Change the default for new users if you must but the update for existing users should be transparent unless they explicitly op into changes.

That sounds like survivorship bias though? Everyone else already left it and jumped ship to GNOME (including pretty much all of the distros).

Are the current users the full target market or just leftovers?

Isn't GNOME the one that doesn't have a "desktop"?

Yes? What's this question supposed to imply? No one should use Gnome?

Not really, Most distros allow you install what you want. For example you don't need Kubuntu to install KDE. Just install kde-desktop.

I don't think I like KDE more because of its customizability but that's certainly welcome (as long as the default are good, which they also are)

Most distros will change the defaults anyway., and, as others have said, a lot of KDE users use it for its customisability.

> KDE should probably invest in better defaults if these need tweaking.

We've done that a lot the last couple of years! We've changed many defaults to values that reflect better what the users actually use, based on reviewing what distros do, studies, and opt-in telemetry. A lot of this already happened in the back half of the 5.x era, but 6.0 includes additional changes in this regard.

And you're not wrong, it does help a lot.

Great, but konsole tabs on the bottom by default? Why?

I have them on the bottom for 20 years. The first thing I'll change on fresh system. Glad I won't need to do that anymore.

I wonder if "new tab" button is always visible now too.

To each his own I suppose, as long as it's adjustable :)

Is it a browser tabs vs. taskbar tabs ideology?

People like tabs right next to the area they look at most of the time.

In browsers, that's always at the top. In terminals, depending on if you're a heavy user (and as result, the prompt is at the bottom) or a light user (and the prompt is at the top), you'll likely prefer tabs to be in the same area, too.

I've actually got different settings for taskbar position and terminal tab position between my work ubuntu, personal ubuntu, and personal windows systems.

For me it's a Windows/Mac thing - if you're a Mac user, you're used to having a menu bar at the top, and you're always up around the top, so top tabs feel right.

When I was on Windows, the Start Menu/taskbar was on the bottom, and bottom tabs felt right (as they became available).

Let's all agree that side tabs are of the devil.

my discord addled gen z brain keeps tabs and taskbar to the left, there's always gonna be someone

I don't care much either way, why would this matter so much?

Also, if this is the only thing that's annoying, KDE won I guess.

Tabs are on top by for me on 6.0. Seems to be the default, unless my distro (Arch) changed the default.

I can't say which position is the "right" one, but I also noticed different distros have different defaults on where the tabs are positioned.

It's cool that KDE lets you do that, but it's a bit annoying actually as it messes with the consistency of KDE. Sure, users can always change their preference to what suits them best, but it would be nice if out of the box all KDEs behaved and looked the same and leave the personalization to the user after installation.

https://github.com/KDE/konsole/blob/61264c1917770102a85123d3...

It appears the default is Top in Konsole's source.

This is an excellent illustration of why "better defaults" is a gateway to endless bikeshedding. One person's "better defaults" are another person's "why?"

The only "better" defaults are those that match what people already know, not necessarily because they're objectively better but because most people will already know how to use them. You literally can't get a learning curve better than "you already know it".

Konsole has had tabs at the bottom for about 25 years now (I don't recall KDE 1.x, but they were definitely there in 2.x). Who do you prioritize in a design? Everyone who already uses KDE, and expects them at the bottom, or a subset of users who might switch to KDE and expect them at the top?

More importantly, is the position of tabs -- especially one that you can change! -- like, a real, actual problem?

I wonder if it would be worthwhile to have a “here are some of the options we’ve got, pick one, there’s no default!” splash screen on first run.

KDE had exactly that back in its 3.x era, actually. It had a first run wizard that allowed you to choose things like whether you open things with a single or a double click, and options were largely organised based on platforms with similar conventions (as in, it had options like "single click selects, double click opens (Windows style)"). It was remarkably friction-free actually, people could just pick the mode that they were already familiar with and that was that. It had all the good parts of "the right default" (i.e. the "right" default was always the one you liked best) and required exactly one click to configure.

Zorin OS takes this approach (and pretty far). At first boot you get to select Windows, Mac, Unity or Zorin style and it shifts a bunch of things around based on that.

It would be nice for KDE to have three presets: Windows, Mac, and Classic (= KDE).

>Who do you prioritize in a design? Everyone who already uses KDE, and expects them at the bottom, or a subset of users who might switch to KDE and expect them at the top?

If you want to grow your user base: The latter.

Now you’re assuming that the group that would switch is bigger than the group that appreciates the tabs at the bottom. I doubt that the tabs at the bottom are the main reason people wouldn’t switch to KDE.

Not only this, but who exactly uses Konsole? It's certainly not grandma, who you set up with a KDE laptop. She's not going to know what to do with the command line, and even if she did need to use it for some weird reason one day under your direction, she sure as hell isn't going to open multiple tabs in Konsole.

The people using Konsole are already the highly technical people, and therefore probably not newbie users.

Nooooo!

That is the most frustrating thing about some projects:

They take existing users for granted and make a lot of changes to accommodate the new users they envision coming in torrents.

These users of course never arrive and in the meantime they have alienated the old user base.

With KDE you can put the tabs where you want them.

Or, if you want everything to be like in Gnome or Windows or Mac you can just use these.

In KDE's case the "you can just customize it" works both ways though. They could change the defaults and instead and let old users customize it back to the old way it was, rather than every new user customizing it. It comes across as a pretty weak argument.

The reality is that most users are simply bitterly opposed to change, especially in "subjective" parts of the system like UI design, and it has nothing to do with whether or not the change is actually an improvement that helps people, or can be undone with in 1 minute through a KWin tweak, or whatever. The very example you're theorizing about (accomodating new users who don't yet exist through UI improvements) actually has happened before with positive and negative examples e.g. Blender's complete UI overhaul in 2.8 which was widely praised, versus Gimp which continues to receive flack for its UI choices, versus Gnome which people just endlessly argue over both ways. It is not as simple as "New UI bad, old UI good" no matter how common of a mindset (and how over-represented) that is here.

Developers of the project have to balance these concerns as they see fit, and that is their right. Being an older user of the project (or any user, actually) does not mean every decision and plan in the project is going to revolve around you exclusively, at the end of the day.

They shouldn't require wasting time to get the old behavior, though, that's indeed alienating, it should instead be saved to user config and preserved on updates

> and let old users customize it back to the old way it was

That's a weird way to write "and automatically import settings from previous versions to keep the behavior the same without user effort".

They "of course never arrive" because of course you never implemented the proper match in behavior

But the old users can have it too, that's what configurability is for, just save the state to user config and don't change any such behavior on upgrades, only for fresh installs

Look to Mozilla and Ubuntu to see and organization and a company that "bet the farm" on new users by systematically breaking everything we loved them for.

The problem with these (and many other UX initiatives) is there isn't a fallback for us who used them from the start.

If there was it wouldn't have been a problem.

The lack of fallback is a problem, but that's a different one. And there are even more examples of orgs that didn't bet on new users and simply died off (though that didn't stop them from breaking things)

And then you have vim. Same as always. Yet still the same as it was.

Same goes for KDE (if you forget 4), Windows (more or less if you skip Windows 8) since 95, bash, LibreOffice.

> If you want to grow your user base: The latter.

Prioritizing the needs of potential new users may bring you actual new users, but not prioritizing those of existing users may send some of them away. How do you know which group is bigger?

Sure, the group of potential users is massive but not all of them will switch. Meanwhile you're making software worse for people who actually use it and, at least for FOSS software, are usually your biggest advocates, part of the developer base, and one of the most important means through which new users are brought in.

That is a result of forcing an either-or and making a problem, not a result of pursuing the trends of potential new users.

That is just idle semantics.

I think it took you longer to ask that question than it does to move the tabs to where you want them. Personally I have them on the bottom and like it.

I'm guessing because tabs on top push the terminal down, moving all the text and maybe being distracting while reading since we are mostly reading from the top of the terminal buffer.

I only very rarely use konsole tabs at all (I prefer multiple windows), but when I do, I appreciate that they're at the bottom of the screen. That tends to be where my attention is when I'm using konsole.

Reply on news.ycombinator.com