Some Of The Features That Could Come To KDE In 2020

[bug77]

If you regularly work with files on remote locations in non-KDE apps and don't have multiple screens with different pixel densities (or you use Wayland where the feature is already implemented), then FUSE mounts are definitely more important. If you have multiple screens with different pixel densities and don't use the Wayland session and never work with files on remote locations in non-KDE apps, then clearly the per-screen scale factor feature is more important to you. If this describes you and you'd like to see this feature reach completion sooner rather than later, please feel free to help out with patch testing and development work!

In the meantime, the big usability issue that you said was coming in 5.17 is still MIA (apps asking for you to submit a crash report, only to inform you one screen later that you can't actually submit one, because the app doesn't offer a URL for that).

And while you can argue this to no end, I have several colleagues with hi-dpi laptops and only FHD monitors... I, myself, am planning to get a 4k monitor for my desktop, while keeping my secondary FHD one.
I'm not saying that handling fuse mounts is not important, I just don't understand how some under the covers work can take precedence over, you know, actually display stuff the right way.

[skierpage]

I just don't understand how some under the covers work can take precedence over, you know, actually display stuff the right way.

I suggest you take your insightful feedback to the VP of software development at KDE, who sets projects’ priorities and pays the salaries of all its developers.

[bug77]

I suggest you take your insightful feedback to the VP of software development at KDE, who sets projects’ priorities and pays the salaries of all its developers.

I doubt he's being paid to please me
I was just saying, I find this prioritization of work puzzling. I mean, Apple made billions selling an interface that I'm sure had its shortcomings (e.g. iOS being unable to copy/paste until its second or third major release). Why? Because for all its shortcomings, it did one thing right: it displayed things properly, lag free and with few (if any) crashes. Hate Apple as much as you want, but the billions they made are proof enough they set their priorities straight.

The thing is, KDE is great (otherwise I wouldn't care at all). It feels like it needs an additional round of polish, that's why I find it weird when stuff that's not directly GUI related gets prioritized first. And I'm not saying "stop everything else until you completely fix the GUI", but we're looking at an improvement for fuse mounts (i.e. something that already works, only not optimal and only for non-KDE apps) vs having to give up one screen when DPI doesn't match. From Nate's blog, it seems they know the problem rather well, they're just not planning to work on it soon.

That said, I should exit this thread as I have nothing else useful to add and I don't want to sound like I'm trolling.

[stingray454]

This is work in progress:

https://bugs.kde.org/show_bug.cgi?id=387313

https://phabricator.kde.org/T10530

This is imo one of the most severe bugs in all of KDE right now, and I'm amazed how long it has been ignored. I used to pop in once every few weeks to check progress, but it has been years and it's still not resolved. Recently got marked as high priority (and rightly so), but so far nothing seems to have happened. How this has not been prioritised higher than all of the cosmetic changes / new features added since it was reported is beyond me.

[shmerl]

This is imo one of the most severe bugs in all of KDE right now, and I'm amazed how long it has been ignored. I used to pop in once every few weeks to check progress, but it has been years and it's still not resolved. Recently got marked as high priority (and rightly so), but so far nothing seems to have happened. How this has not been prioritised higher than all of the cosmetic changes / new features added since it was reported is beyond me.

I think KWin team was in transition, so a lot of things slowed down because of it.

[skierpage]

I find it weird when stuff that's not directly GUI related gets prioritized first.

Maybe you don't understand (the passive voice doesn't help) that there is no senior leadership team prioritizing what gets worked on in volunteer projects. It's just programmers scratching their itch. In his blog post Nate Graham discussed bugs that volunteers are working on, thus they have a good chance at getting into the next KDE release. Sometimes senior developers in a project will talk about features they hope/want/plan to have in the next major version (as we see in the planning for KDE libs version 6), but that only works because the programmers who might actually do the work participate in the discussion.

It's amazing that volunteer-driven open source works at all! I donate to the KDE e.V. as thanks.

[bug77]

Even if priority is not the responsibility of one person, I'd still expect the team to coordinate their work.
But yes, if it's gotten to "we'll take whatever contributions , in whatever order", than yes, I shouldn't be expecting anything.

[ssokolow]

But yes, if it's gotten to "we'll take whatever contributions , in whatever order", than yes, I shouldn't be expecting anything.

It was never anything but that. Different people have different skill-sets and interests. Contributors come and contributors go. It's not reasonable to expect to steer people who aren't getting paid too much. On occasion, a company will pay someone with the requisite skills to work on a specific issue that they need fixed. As skierpage said "It's amazing that volunteer-driven open source works at all!"

[insilications]

Switched from GNOME to KDE for awhile. I'm really impressed with the efficiency, modularity and performance. Out of the box, in comparison, GNOME feels way too bloated.