feat: allow opening hidden plugins

[alvaro-cuesta]

Please tick as appropriate:

• I have tested this code on a steam deck or on a PC
• My changes generate no new errors/warnings
• This is a bugfix/hotfix
• This is a new feature

Description

This fixes issue: #734 (see issue for alternatives considered)

This solves the use case where plugins are hidden from the quick access list because access to their panels is not used very often. For example, plugin "ProtonDB Badges" is fire-configure-once-and-forget, so it makes sense to hide it so it doesn't waste space and attention during quick access.

But this doesn't mean the user will never want to access hidden plugin panels to e.g. briefly change configuration. Currently the only way to access the plugin content panel is to unhide the plugin, access it in the quick access list, and then hide it again.

This allows opening plugins from the "Plugins" panel in Decky's settings, even if the plugin is hidden in the quick access list. Clicking the open button opens the plugin in the quick access sidebar, regardless of its hidden status.

Additionally:

• Since the "open" action is expected to be more common than the current "Reinstall" button (which seems to be there because it turns into "Update" when an update is available for the plugin):

  • Add "Open" action as the primary icon button
  • Move "Reinstall" option inside context menu so plugin can always be reinstalled (regardless of available updates)
  • Keep "Update" button in main interactables, but only show it when an update is available

  (See my comment below for some thoughts around this.)

• Add notification badge if plugin has updates

  Makes it more consistent with the rest of the app, which already has badges on available updates. It also makes it more obvious now that the "Update" button is only shown conditionally, calling attention to the updatable entries.

This is how the changes look in the "Plugins" settings tab:

[alvaro-cuesta]

Posted this PR because I'm running it on my fork and I figured having an actual runnable build would make sense to better discuss the ergonomics (see #734 for alternatives considered).

In particular, I'm not entirely sure if the "Open" action should be relegated to the context menu anyways, instead of having its own icon button.

I want to work on #350 soon-ish (which might deserve a toggle per row for conciseness, see screenshot in first comment) so it might make sense to not even add the "Open" as a main action in this PR to leave some space for the toggle.

This discussion is not really specific to this PR, but I'd rather leave a smooth path forward without too many UI changes across PRs.

• I expect 99% of the time users will just use the quick access menu, and for the very few cases that they really want to open a hidden plugin they can still reach through the context menu which is one click away.
• Seems like the toggle might be a useful action to have ready at hand, especially after updates that might break multiple plugins at once...
• ...but "open" seems useful as a main action too, so I can't make up my mind on which of the actions should stay (or both?). Currently "hide" and "freeze" are inside the context menu and it feels fine... plus a toggle might be a bit unspecific.

I still think it makes sense to keep the "Reinstall" button tucked inside the context menu though (for the same space-saving reasons).

Some actual screenshots on how it could look like IF the plugins are disabled via toggle:

• This would be the "Plugins" tab with "Open" button AND disable toggle, which admittedly looks a bit busy and makes overflows more likely:

  

• And this would be only the disable toggle, no "Open" button:

  

• If the open action is tucked inside the context menu it could look like this (note that this uses my branch of feat: add MenuSeparator component decky-frontend-lib#115 which exposes MenuSeparator):

  

Thoughts?

[TrainDoctor]

@alvaro-cuesta, hey sorry for the long time between when we last discussed this on discord and now.
@EMERALD0874 is our most versed UI/UX person on the team. I'll ask them to give this a review. Personally I love the toggle and open button in combination but I want Emerald's opinion if that's too much visually. I'm aware that a large portion of our users don't even know to open the settings menu until a plugin starts misbehaving so adding more interface might not be helpful.
Is it possible to make the open button only appear on plugins that have been hidden? If so I think that would be ideal imo.

[alvaro-cuesta]

@TrainDoctor no worries, holidays are always a tough time, thanks for coming back to this.

Is it possible to make the open button only appear on plugins that have been hidden?

The UX person at my job has this motto of better being consistent with what you show. E.g. in this case it might not be immediately obvious why some plugins have the buttons while others don't, which might puzzle some users.

But of course there are always exceptions and although I like dabbling in UX I'm not an expert either, let's see what @EMERALD0874 thinks!

[alvaro-cuesta]

Now that SteamDeckHomebrew/decky-frontend-lib#115 is merged I added the menu separator to the plugin's menu (tested in both SteamOS Stable and Beta), splitting it in two sections:

• Install actions (reload, reinstall, uninstall)
• Status actions (hide, freeze)

Change is VERY small but IMO it makes the context menu a bit less overwhelming and more structured, since this PR adds an additional menu item with the "Reinstall" action, making the plugin list a bit more crowded.

I've been running this locally in my fork and I feel it makes a difference.

• Normal mode:

  

• Developer mode:

  

Even though the "normal" mode only has one status item I still think it's a good idea to guide the user through both sets of actions, plus SteamOS itself has multiple instances of guiding like this, e.g. see how "Switch to Desktop" is standing alone here to highlight it's its own kinda thing: