[Request] Allow disabling plugins without uninstalling them

[charlie-collard]

Please confirm

• [X] I have searched existing issues
• [X] This issue is not a duplicate of an existing one
• [X] This is not a request for a plugin

Feature Request Description

Sometimes I want to stop using a plugin temporarily, but don't want to go through the hassle of uninstalling and then reinstalling it later, ~potentially resetting settings~ (settings are persisted through re-installations, thanks @PartyWumpus). It would be nice to have a toggle switch next to each plugin that allows disabling the plugin while leaving it installed.

Further Description

No response

[charlie-collard]

For inspiration, this is how the toggle looks next to the plugins in the popular old school runescape client "Runelite":

[PartyWumpus]

plugin settings aren't deleted on uninstall and installation takes seconds so I personally don't think this is a worthwhile idea.

[charlie-collard]

The actual installation itself is very quick, yes. Navigating to the store, and scrolling for a while to actually find the plugin is quite a lot of annoying overhead if it's something you do a lot. To give an example, I'll often uninstall powertools to compare the effect on fps that my current settings have with the steam deck defaults. Being able to do that with a single toggle would be really useful!

[charlie-collard]

Also, if you haven't got any internet access then reinstalling isn't an option

[PartyWumpus]

There's a new store UI (with a search bar and sorting) coming out soon (#343), so it'll be faster to download. But yeah I suppose if you don't have internet it's not an option.

the example makes it clearer why you'd want that. I'm sure if you or someone else wants to make a PR to add this functionality the devs would be happy to take it but I think it's unlikely they'll dedicate time to it. (obviously I don't speak for them and you'll have to see what they think)

[spudpiggy]

you shouldn't have to uninstall a plugin to disable it, even if you can just redownload it afterwards. it just feels janky to not have the option, yk? bumping for visibility

[jcc10]

It would also be nice to have the option to "disable until next update" as in my situation, the deck UI got updated and now I am waiting on some plugins to update to the point where they don't completely break the UI.

I fully intend to use the plugins again later, I just don't want to have to keep hunting them down and checking if they got updated.

[jordigarcl]

plugin settings aren't deleted on uninstall and installation takes seconds so I personally don't think this is a worthwhile idea.

Is this right? So you can uninstall Decky Loader and/or uninstall individual plugins, and when you reinstall everything, all the plugin configurations are preserved?

Decky is broken (even on pre-release channel) on latest Steam Beta which enables the new Families. If we can just uninstall Decky and reinstall it again keeping all configs when it is fixed then it would be very useful.

[Managor]

I'm here for this feature. Sometimes plugins break due to changes and disabling a plugin would be nice to prevent error spam.

[MultiKoopa]

Would love this, since some of my most used plugins break on most updates

[DisasterIncarnate]

+1 for the option, seems more relevant an option with every steamos update where you need to quickly debug/test every decky plugin to see which one(s) are causing issue, constant install/uninstall is not a great solution, a toggle off/on would be far better.

[SiTWulf]

Any new about this?

[TrainDoctor]

Any new about this?

It is not a priority of our team at the moment. If users wish to contribute code to add the functionality they are free to do so.

[DisasterIncarnate]

if a misbehaving plugin is uninstalled as suggested then a user will not be aware of a plugin author updating their plugin to potentially fix an issue, if the plugin remains installed but disabled your plugin update system will show an update when available which is much more useful overall rather than deleting the problem plugin and not knowing its ever been fixed.

[MultiKoopa]

if a misbehaving plugin is uninstalled as suggested then a user will not be aware of a plugin author updating their plugin to potentially fix an issue, if the plugin remains installed but disabled your plugin update system will show an update when available which is much more useful overall rather than deleting the problem plugin and not knowing its ever been fixed.

This is a nice idea in theory, but when just having a plugin installed can cause hard crashes and break steamos, it's only nice in theory

[PartyWumpus]

This is a nice idea in theory, but when just having a plugin installed can cause hard crashes and break steamos, it's only nice in theory

Please don't just say things without any basis, a disabled plugin would likely be able to act the same as not being installed at all. It of course depends on the implementation, but I doubt that would be true in any implementation.

[TrainDoctor]

@DisasterIncarnate @SiTWulf @squdpiggy

I absolutely agree with you all about the utility and purpose of the feature. Right now we're prioritizing future proofing Decky and Decky Frontend Library aka DFL. DFL specifically gives us the ability to future proof plugins from big changes in the Steam Deck BPM UI by vendoring all of the UI elements plugins user from Loader itself so when we update loader we can fix breakage in plugins that utilize our vendored DFL.

The team is also working to give users the tools to catch and in turn better report a broken plugin. In our latest pre-release we have a new feature that allows plugins to be uninstalled when they hit our error boundary (React term) and to collect logs etc and provide a few other options. If a contributor (from our core team or otherwise) has the time to implement disabling plugins both on the python backend and react/TS frontend + required new UI elements then we'd be able to block plugins that break the UI confidently. Unfortunately that has not been a focus for various reasons, mostly connected to Valve's regular updates which usually break our injection/DFL elements that we then inject into the Steam BPM UI (on Deck).

Towards @MultiKoopa's point, a plugin who's UI elements work but is broken at an underlying OS/library level due to updates/changes in dependencies etc, cannot be detected in the same way so we could only account for failure modes within the UI. I do not feel this is contrary to @PartyWumpus's statement as most plugins that break do so within the UI so the error boundary work will go a great distance to resolving plugins breaking UI and making Steam BPM on Deck, Decky and or other Decky plugins unusable.

Ultimately, we're a volunteer project that makes no revenue on our work and we can only get features and fixes out with the time our contributors have available to them, the support of our users and through external contributors as they so rarely come about. I will do my best to prioritize this feature but I cannot tell you that we will have it done in xyz timeframe or that it will be worked on at all as I cannot control that.

Apologies for the wall of text but I felt I needed to add some points of clarification and other important information.

[ttang4299]

if a misbehaving plugin is uninstalled as suggested then a user will not be aware of a plugin author updating their plugin to potentially fix an issue, if the plugin remains installed but disabled your plugin update system will show an update when available which is much more useful overall rather than deleting the problem plugin and not knowing its ever been fixed.

Towards @MultiKoopa's point, a plugin who's UI elements work but is broken at an underlying OS/library level due to updates/changes in dependencies etc, cannot be detected in the same way so we could only account for failure modes within the UI.

All due respect to the Decky contributors, if a misbehaving plugin can't be updated after being disabled because it can't be detected in the system, the only other option would be to uninstall. Either way, the plugin's reputation suffocates because it's not being given a chance to redeem itself. This could discourage a good amount of plugin developers from further contributing because they would have to find ways to inform users of their plugins of issues like these and of fixes that are on the way, but not everyone is in the Discord server.

The renewed interest in the feature given the recent bugs seems to have applied enough pressure for further consideration to be taken, so hostility towards rushing this feature to release without polish ASAP seems unnecessary. However (and again with respect to the volunteer contributors), Decky works as a platform because of 3rd party developers. Decky can be developer-hostile if there's no real system to rehabilitating misbehaving plugins. Uninstalling the plugin should hopefully not be the only option available in the future.

[TrainDoctor]

All due respect to the Decky contributors, if a misbehaving plugin can't be updated after being disabled because it can't be detected in the system, the only other option would be to uninstall. Either way, the plugin's reputation suffocates because it's not being given a chance to redeem itself. This could discourage a good amount of plugin developers from further contributing because they would have to find ways to inform users of their plugins of issues like these and of fixes that are on the way, but not everyone is in the Discord server.

The renewed interest in the feature given the recent bugs seems to have applied enough pressure for further consideration to be taken, so hostility towards rushing this feature to release without polish ASAP seems unnecessary. However (and again with respect to the volunteer contributors), Decky works as a platform because of 3rd party developers. Decky can be developer-hostile if there's no real system to rehabilitating misbehaving plugins. Uninstalling the plugin should hopefully not be the only option available in the future.

The recent breakage with specific plugins that should have been delisted ages ago due to deprecation, known issues (etc) and the fact that users should have been notified that they were no longer being updated is 100% on me. To your point, the ability to let users know what's going on with Loader itself and or certain plugins is important and must be improved. Addressing your point about plugins being the backbone of why Decky works, of course! We'd be nowhere without them and I want to do better by plugin developers as best I can. I don't have a concrete plan right now but I'm going to coordinate with the rest of the contributors/devs and hammer out a plan for putting better protections against plugins bringing the entire structure down with them.

[DisasterIncarnate]

great feedback from the devs here, ultimately the devs and deckyloader as mentioned will always be on catchup due the aforementioned rapid updates SteamOS can get, so looking at this from us end-users point of view, we know plugins will fall behind, perhaps not even slowly, some have the potential to break on just 1 update this all depends on the complexity of the plugin and not all will break ofc.

In my own case, again as an end-user, the feedback i have given is exactly from the point of view that i know and expect things to break, this is not a bad thing as ofc i expect what are unavoidable issues but myself and others would prefer to give feedback on what is essentially a cyclic set of actions we take when something does break and as i mentioned, when i can eventually identify a plugin causing issues, simply uninstalling the plugin does indeed work but is not useful in the long run due to the points i made earlier about not knowing when an update lands that fixes the issue.

The whole disable plugin feature request thing is simply due to continual cause and effect, as the devs will always be on catchup our feedback is basically a request to roll in a new feature which handles this in a way that keeps us as end-users potentially informed of issues when they happen, and better yet, allow us to be informed when these issues have a fix.

The very welcome information TrainDoctor has given us sounds great, the part regarding automagically catching plugins creating errors and being uninstalled would be ideal, perhaps again automatically disabling them rather than uninstalling would be better as again the plugin could be seen/flagged to the end-user as disabled due to such errors and the user would be informed of this fact, their issue would be temporarily fixed/bypassed and they would remain informed of a plugin issue and can simply wait for an update, as currently the normal outcome is for a LOT of posts to appear in various places of people not knowing whats happening and asking for magic cures which simply wont happen until a plugin gets an update, many less informed users often not even knowing its a plugin issue and they end up thinking their device is at fault.

This is why i supported the idea of disabling plugins as the plugin would remain, and with what TrainDoctor mentioned of their upcoming features the plugin would still be listed in an end-users plugin list but could be flagged/marked as "disabled due to errors, await a plugin update", and perhaps giving a useful link to contact the plugin author, even if its just a link to their github issues page.

Information is king and as mentioned due to always unavoidably being on catchup we end in this cyclic set of actions where we install a plugin, wait and see if it works, if it does, all is well, if it does not we uninstall it, we are then currently blind as to when the plugin is if ever fixed so people end up installing it again occasionally and going through the same "try and uninstall" loop all the while lacking information as to when the issue is fixed. Keeping the plugin but having it disabled would at least fix this issue and if your upcoming feature could auto-disable said plugins then this would be the best possible result we can expect which gives us a functioning system and keeps us informed.

[SiTWulf]

Some plugins like DeckMTP do not generate any errors, they do not show any errors, but they simply do not work. In this case, we would have a non-functional plugin activated, consuming resources and ram memory to do nothing, the solution would be to uninstall it, but then when you find out that there is an update that makes it work, deactivating it due to errors does not solve the problem, because this plugin does not generate any errors, it simply does not do what is indicated. Another plugin with the same behavior is HLTB, not generate any error but simply not work.

For example, in SDH-CssLoader you can disable/enable any theme and works on the fly, if one theme not work, you can disable and wait for a update, you get a update warning about the disable theme.

[MultiKoopa]

I feel like I was misunderstood earlier. But I'm glad there's renewed interest in this.