While including this does have benefits, it should be up to the user to create this window rule.
Window rules may cause breakage in some scenarios so the user should be expected to maintain them. An application may do changes that break included KDE Plasma window rules. If an application update breaks the window rule, the user may not be aware of the window rule and blame KDE or some actor. This also increases the amount of work KDE developers have to do if this happens, since a change removing the problematic window rule will have to be made. Not all KDE Plasma users are aware of the existence of the window rule feature so fixing issues caused by nonoptimal included window rules becomes much harder.
Including window rules for specific third-party software sets a bad precedent, because it may cause some software developers to want their own included window rules.
Some window rules, including the KDE Plasma 6.8 Steam window rule, can change the presentation of applications, which may cause confusion. If an user switches the environment they run Steam in, they may expect Steam to be presented in the same way.
Application developers may not want KDE to include KDE Plasma window rules for their apps.
Users who use do not use Steam have an unneeded window rule they do not benefit from.
Software with included window rules may change their window class, breaking the window rule.
b) KDE Linux offers to install DOSBox Staging when you attempt to open DOS programs and have no application offering to open them.
Offering specific software to install increases KDE’s responsibility. DOSBox Staging is not under KDE’s control. If DOSBox Staging has some major controversy or issue, KDE offering to install the software would be in bad taste.
c) KDE Plasma should not favor Discover.
KDE Plasma offers to open Discover when trying to open files in a format that has no application set to open it. The user may prefer another application store instead of Discover. Alternatives to this could be a way to set the preferred app store or removing simply removing the offer to open Discover. The Discover results may also not be useful, because an application in the search result may actually not be capable of opening the type of file you were installing an application for.
KRunner includes a search provider for Discover. Discover itself should offer to install its KRunner search provider. GNOME for example lets installed applications create their own search providers for GNOME’s search. search. Future Discover packaging formats, Flatpak for example, and immutable distributions may cause problems with system-wide KRunner search providers so it should be installed user-wide.
KDE Plasma preferring Discover over other application stores in the file picker is a bigger problem than KRunner including a Discover search provider, because the KRunner Discover search provider is a first-party optional software offering. This could be another reason to remove the offer to search Discover for applications related to the format being opened.
No part of this post was assisted by or written by artificial intelligence. All of the problems listed in this post are quite minor, but making KDE more application-neutral has several benefits. For example:
Less chance of breakage and problems (not including window rules for specific applications)
More neutrality and less responsibility for KDE (not including window rules for specific applicarions and not recommending third-party software)
More chances for in-ecosystem competition (not preferring Discover)
you don’t say what distro you are using but this opinionated behavior you are describing sounds distro specific.
discover is the GUI front end to the package manager (apt in my case) but it works with the fedora package manager as well, and if opensuse ever makes up their mind i’m sure it will work with whatever they end up with eventually.
unknown file types should dump you into a choose an application dialog box, not discover.
Let’s start with the first thing: Steam having a window rule pre-shipped. This window rule is to add shadow to the app window because it previously didn’t have one.
Why do this? Ideally everything gets fixed upstream. Steam gets a little special treatment here. But, it is also a proprietary app. Getting KDE’s compositor to work with it has been nigh impossible, unless Steam developers specifically fix it.
So, in ideally, Steam fixes the issue at some point, and that window rule wouldn’t be necessary anymore
I believe the purpose of the window rule was to prevent a regression - if kwin MR 9863 had not added the window rule, it would have removed the shadow that Steam already had.
I learned something new then. So then, we’re simply trying to fix our compositor regression for an app that clearly needs special treatment in order for shadows to work…
Lets not chastise the devs for adding something to help the enduser. If you don’t like the rule ignore it. Most of us didn’t even realize the rule was or is therwe.
I agree with this, to a point, and it’s an interesting one. Competition is useful sometimes, but not always.
Originally Discover was a front-end for a package repository made by the distribution. Distribution packages were the main source of your apps. This repository has never really been an “app store” as in, market value driven app stores, Google Play Store, Apple Appstore etc. It’s a bunch of source-code compiled into packages by volunteer contributors. They chose the apps.
But ever since Flathub came around, this was no longer true. With Flathub support built-in, now it became an actual Appstore™ as in the modern sense, where companies can put their profit-driven, proprietary apps on it. Though still the minority, it’s putting a pressure on Flathub front-ends to present things fairly, and hopefully without bias.
The problem is that you are pointing to, might be that Discover is biased towards it’s own presentation of apps, and should allow users to have other front-ends that do effectively the same thing, just with a different presentation.
But now I wonder, what other appstore do you want to use instead of Discover?
It’s small and quite honestly I don’t even know why I’m still trying to go and dig for truth in what OP has said.
They’re giving so many “if” statements, scenarios that haven’t happened yet, and don’t cite any issues that other people have reported with them. They also assume things going to cause breakage, and no technical explanation as to why.
They are also advocating to ability to set integration with another app store but haven’t suggested any app store that they would like to use instead of Discover.
And most importantly, they are asking to remove very good usability features. They favor people having to manually configure things in order for them to work as they expect. This is very unhelpful for new users.
To add to the whole discover discussion: just recently I thought it would be really nice if there was a “lightweight” version of discover which just handled knewstuff (widgets, themes, krunner plugins, …).
I don’t have a need for discover because I handle the distribution’s repositories with the official tools, but if I uninstall it I’m not getting updates for plasma stuff. And on the same vein, if I want to update plasma stuff, discover makes this really complicated by wanting to also handle distribution updates.
All the while it displays a huge big warning on the top how managing those updates is not supported for my distribution, but also not giving the option to disable the sources without uninstalling packagekit-qt6.
I feel it would be nice to have a a lightweight update functionality for knewstuff right inside system settings, while discover can go live on as a dedicated software frontend for KDE Linux and whoever chooses to use it.
No, Steam never has shadow in Wayland. Not only in KDE, but also GNOME. Not only Steam, but also most Electron apps. Not only shadow, but also missing window border.
It’s affecting KDE users, because without border and shadow, these apps blend into windows behind them. The window rule for Steam is shipped both as an example, and a fix to the most popular one of a whole bunch of problematic apps.
Funnily enough when I used KRunner to search for a charmap application, for some language specific chars, roughly a year ago it recommended to install gucharmap the gnome application for me, not the KDE one. And I do not even have GNOME installed at all.
If I understand the complaint correctly that should not even be possible. Wonder how that happened, maybe because I typed “char…” and that does not start with K (like KCharSelect)
Something similar, I would guess, is happening with the DOSBox example, something to start a DOS executable a “simple” search engine finds a application with DOS in its name first(?) Edit: wait gucharmap starts not with char… either. The distos “Editor’s Choice” then, I guess. Edit-Edit: the “desktop-executable”-starter name is Charmap without the “gu” in front, though. Maybe that was the search criteria. It gets complicated.
It gets complicated.