* improve the error screen visuals
* comment out placeholder buttons
* run formatter
* Refactor DeckyErrorBoundary styles and text
- Removed gray text class usage
- Removed styles reminiscent of Steam BPM
- Fixed typos
* Further refactor of DeckyErrorBoundary.tsx
- Change background/text of buttons to be closer to Steam Deck UI
- Make panel background not reliant on transparency and have a neutral gray
- Bold "likely occurred" text
- Make swipe prompt appear in the center of a horizontal bar, drawing more attention to it
- Make "An error occurred" text smaller, as it isn't helpful for troubleshooting
- Add text clarifying solutions are in recommended order and how to get more help
- Add "Retry the action or restart" to the left of Retry, Restart Steam, and Restart Decky buttons
- Move disabling Decky to beneath the Decky update checking
* Revert header boldness change
* add disable plugin buttons to error screen
* Set background to black
---------
Co-authored-by: EMERALD <info@eme.wtf>
* implement base frontend changes necessary for plugin disabling
* implement frontend diisable functions/ modal
* plugin disable boilerplate / untested
* Feat disable plugins (#810)
* implement base frontend changes necessary for plugin disabling
* implement frontend diisable functions/ modal
---------
Co-authored-by: Jesse Bofill <jesse_bofill@yahoo.com>
* fix mistakes
* add frontend
* working plugin disable, not tested extensively
* fix uninstalled hidden plugins remaining in list
* hide plugin irrelevant plugin setting menu option when disabled
* fix hidden plugin issues
* reset disabled plugin on uninstall
* fix plugin load on reenable
* move disable settings uninstall cleanup
* add engilsh tranlsations for enable/ disable elements
* fix bug where wrong loadType can get passed to importPlugin
* show correct number of hidden plugins if plugin is both hidden and disabled
* fix: get fresh list of plugin updates when changed in settings plugin list
* fix: fix invalid semver plugin version from preventing latest updates
* retain x position when changing focus in list items that have multiple horizontal focusables
* correction to pluging version checking validation
* make sure disabled plugins get checked for updates
* show number of disabled plugins at bottom of plugin view
* add notice to update modals that disabled plugins will be enabled upon installation
* run formatter
* Update backend/decky_loader/locales/en-US.json
Co-authored-by: EMERALD <hudson.samuels@gmail.com>
* chore: correct filename typo
* chore: change disabled icon
* chore: revert accidental defsettings changes
* format
* add timeout to frontend importPlugin
if a request hangs this prevent it from blocking other plugin loads.
backend diaptch_plugin which calls this for individual plugin load (as opposed to batch) is set to 15s.
other callers of importPlugin are not using timeout, same as before.
* fix plugin update checking loop
---------
Co-authored-by: marios <marios8543@gmail.com>
Co-authored-by: EMERALD <hudson.samuels@gmail.com>
* fix(Updater): Remove `FocusRing` component and use `Focusable` instead
* feat(Markdown): Add Link `class` to a tag for a mentain a Steam UI colors palette
* fix: useDeckyState proper type and safety
* refactor: plugin list
Avoids unneeded re-renders. See https://react.dev/learn/you-might-not-need-an-effect#caching-expensive-calculations
* feat: sync with local plugin status in store
Adds some QoL changes to the plugin store browser:
- Add ✓ icon to currently installed plugin version in version selector
- Change install button label depending on the install type that the
button would trigger
- Adds icon to install button for clarity
The goal is to make it clear to the user what the current state of the
installed plugin is, and what would be the impact of installing the
selected version.
Resolves#360
* lint: prettier
* fix: add missing translations
* refactor: safer translation strings on install
Prefer using `t(...)` instead of `TranslationHelper` since it ensures
that the translation keys are not missing in the locale files when
running the `extractext` task.
By adding comments with `t(...)` calls, `i18next-parser` will generate
the strings as if they were present as literals in the code (see
https://github.com/i18next/i18next-parser#caveats).
This does _not_ suppress the warnings (since `i18next-parser` does not
have access to TS types, so it cannot infer template literals) but it at
least makes it less likely that a translation will be missed by mistake,
have typos, etc.
