steamdeckhomebrew / decky-plugin-database

Decky Plugin Database. PR your plugins to this repository to have them added to the store!

Decky Plugin Database

This repository exists solely for developers to submit plugins

Use the built-in Plugin Store to download and install plugins.

Submit your plugin

For plugin developers submitting their plugin for the first time, please consult the wiki page on submitting your plugin. This README provides a good resource for the simple git related and a few other items, but the wiki has the rest of the information you'll need.

To submit a plugin to Decky's plugin store, open a pull request adding your plugin as a submodule (take a look at #189 for example). Don't forget to bump your version number in package.json. If you are not sure how to make a submodule, please reference the git docs on submodules.

Once you have your submodule added, in order to update it,
change directories to plugins/your-plugin and run git submodule update --init.
This should update your plugin to the latest version.

Please make sure your plugin is compliant with the pull-request template's steps. Plugins found to be out of compliance will not be accepted. If your plugin does not meet any of the criteria for utilizing a custom backend, then it only requires testing against Stable and Beta SteamOS Update Channels.

decky-plugin-database's Issues

Database - SDH-Toolbox when deployed to decky-plugin-store, cannot be installed from decky-loader

Making this issue here because this issue may be indicative of other plugins. We will need more plugins to test to determine where the issue occurs.

Custom MangoHUD Needs update for decky-frontend-lib version

Custom MangoHUD Needs update to a minimum decky-frontend-lib version of 1.7.5 or greater before we make a stable release of decky-loader otherwise the addon will have to be removed from the store. @simons-public If you could join the SDH discord to discuss with the team that would be greatly appreciated.

PowerTools moved to different repository and link needs updated

The link to the plugin Power Tools points to a non existent page:

https://github.com/SteamDeckHomebrew/decky-plugin-database/blob/main/plugins/PowerTools

It seems to have moved over to:

https://git.ngni.us/NG-SD-Plugins/PowerTools

according to the old official repository:

https://github.com/NGnius/PowerTools

EmuDecky is outdated

EmuDecky is stuck at EmuDecky @ ca548d2, 1.0.2-1, when https://github.com/EmuDeck/EmuDecky is at 1.0.5. Can you please update this? Not sure if I can do it myself, will check.

Plugin builds regularly fail when uploading to the store and these are not marked as failed runs

Caused by an "internal server error", likely an unavoidable CDN problem.

• Uploading plugins to store:

Run shopt -s dotglob
Processing plugin Junk-Store
  Notice: Processing plugin Junk-Store v1.0.1 (by Eben Bruyns)
  Notice: Uploading
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  
    0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  100  110k    0     0  100  110k      0  92999  0:00:01  0:00:01 --:--:-- 93072
  100  110k  100    21  100  110k      9  52697  0:00:02  0:00:02 --:--:-- 52734
  100  110k  100    21  100  110k      9  52695  0:00:02  0:00:02 --:--:-- 52734
  Notice: Internal Server Error

https://github.com/SteamDeckHomebrew/decky-plugin-database/actions/runs/9155996517/attempts/1

just need to add a check for this in the CI

Database - Default to building plugin backend from dockerfiles

Required before moving to full-release of Plugin Loader V2.

An example Dockerfile will be located in the template repo. See SteamDeckHomebrew/decky-plugin-template/issues/1

After the dockerfile from the plugin is ran by the CI and the binaries are placed into their a standardized directory, these binaries will be included during the zipping step which are then sent to the store in the CD steps.

video not being saved

no video file is made after recording

The contents of `/bin` are read-only for PowerTools

Plugins using git@ form URLs causing prompts when cloning

The following plugins use unnecessary authenticated GitHub URLs, which pop up an authentication prompt five times when I run git submodule update --init:

$ grep "git@" .gitmodules 
url = [email protected]:Loidbae/SDH-KLang.git
url = [email protected]:davocarli/deck-roulette.git
url = [email protected]:OMGDuke/SDH-GameThemeMusic.git
url = [email protected]:cboiangiu/decky-dictation.git
url = [email protected]:davocarli/sharedeck-y.git

This is because I (and probably the developers of these plugins) have a local SSH config configured for key-based auth with GitHub. There is, however, no reason why plugin submission URLs should use this URL form and this could probably be tidied up?

Build Plugin CI task failed on most recent merge

Most recent merge CI run appears to have failed, reason appears to be the "Download Decky CLI" step which failed to download the decky-cli required for the following step. Link below showing an empty curl response.

https://github.com/SteamDeckHomebrew/decky-plugin-database/actions/runs/8067374631/job/22037682907#step:8:20

Question about using a flatpak build of another project within plugin

For reference I asked this question originally here. https://discord.com/channels/960281551428522045/960284327445418044/1187134163950768299

Basically what I'm curious about is how to properly include a flatpak of another project in a plugin.

In the deckbrew wiki it states "Black-box" meaning binaries generated from either FOSS or proprietary source code with no link back to source code and or documentation of any changes made are not allowed.

For more context the project I want to utilize in the plugin is https://github.com/Audio4Linux/JDSP4Linux.
Also I intend to build the flatpak myself. This is because the app is capable of being built HEADLESS and such a build is not distrubuted by the author. My plan would be to prebuild a flatpak with the build manifest (which I will include in the plugin repo) using a github action and also have it upload the build to the repo. The flatpak will be built directly from the source repo (no local version will be used/ nor changes made to source code), the url of which is in the build manifest. I will probably document all this in my plugin repo's readme as well. Is this sufficient to satisfy using and documenting built binaries in a plugin?

Add CI filter to only build relevant plugins in Pull Request

Seems like the CI builds every single plugin on every single PR, making it possible for a failing plugin to block everyone else from submitting anything (from my understanding). Only building the relevant plugins in any given PR should fix this.

[CI] Add python native extensions to the build

The CI does not currently support any custom files, which means native python extensions won't be bundled in plugins.

Avoid uploading Plugins with enabled "debug" flag

There are no measures in place to avoid a plugin being uploaded with the debug flag being enabled in plugin.json.

It should either be removed automatically before uploading or not be uploaded at all.

Decky Loader Doesn't Show up in Beta Build of Steam

Please Add a version where people can use along the steam beta

Create Plugin Addition, Update and Removal Templates and Automate addition of PRs to Tracker.

Utilize existing examples from Decky Loader repo and design templates for mentioned intents, and add CI to automatically add them to the tracker as they are filed to improve workflow for developers working on the plugin database.

https://github.com/actions/add-to-project

[BUG] PRs Changing CI Causes All Plugins to Be Re-Uploaded to Testing

When CI is run from and CI has been modified, the current and desired logic will rebuild all plugins. This is great in theory for merges to main to verify all plugins will build properly, but it can and actively does cause issues on submissions/updates of plugins (this is sometimes requested, sometimes required) involving reuploading tons of plugins to the testing store when this was not intended. The CI needs to be modified while work on the CLI interface is continued to account for this occurrence and to prevent the re-uploading of plugins when mass rebuilds are desired but not their uploading.

Detecting Global DFL

Since all plugins are supposed to be compiled as IIFEs, you can test if they are using the global DFL or not by analyzing the output binary.

A cheap but good enough way of doing so if the following:

tail -n1 dist/index.js | grep -Eq '\(([^)]+,\s*)?((globalThis|window)\.)?DFL(,[^)]+)?\)+;?$'

This verifies that the last line of the script self-executes itself by passing in DFL. An exit status of 0 means that global DFL is used, 1 means it isn't.

It should account for different ways of writing IIFEs (not just rollup's).

Build process should use a whitelist instead of a blacklist

https://github.com/SteamDeckHomebrew/decky-plugin-database/blob/main/builder/entrypoint.sh currently has a blacklist of things to exclude but this will let files/folders slip in that shouldn't be..

We should instead whitelist files/folders. At a minimum, my understanding is there needs to be a dist folder with index.js and then a plugin.json file. Others may have a python file (not sure if that has to be main.py or not). Honestly it kind of sounds a bit too complicated. Might be just easier to have this process pull in a tagged release from the devs that has everything already built. My repo has a build pipeline that pushes out a zip file of exactly what is needed to install my plugin and it creates a release for it (see https://github.com/hulkrelax/deckfaqs/releases/tag/v1.0.0). Might be something to consider.

SteamGridDB Issues

Over the past couple of days I have tested the SteamGridDB plugin extensively on stable and beta. For the most part this it's worked absolutely fine, with one of the earliest bugs I found resulting in a "hiding" option to change artwork when this is accessed through library view. I believe the bug has occurred in the latest version of the plugin, so in my experience it isn't fully patched out yet.

That's not the main issue. One that I'm now facing is that the plugin can't always keep up with the user if assets are being changed at a fairly fast rate. (Let's say spending thirty seconds or so on each game, changing various asset types before moving onto the next.) The asset loading will occasionally bug out if you're working at this sort of speed or faster. Subsequently, when you try to change the artwork on a game it may load the assets from the previous game you edited, or maybe a few before that. It is confusing to see assets from a different game appear. However, the issue isn't major as it can easily be resolved by exiting out of the artwork changer and trying again.

SteamOS 3.3.3, build 20221213.1, kernel 5.13.0-valve21.3-1-neptune
Decky 2.4.6-pre5
SteamGridDB latest (1.0.0?)

This bug report was requested by the plugin author. Is anybody else able to reproduce this issue or found any others?

Plugins are not sorted by latest version on the Testing Store

Currently, the Decky Loader's store front end does not recommend the latest version of plugins for all plugins.

At the moment, the following plugin is affected, with a screenshot:

• Emuchievements by Witherking25 (1.0.1.-7bcf1db currently recommended, while several 2.0.0. versions are available.)
  
  

In the past, several other plugins have been affected as well (notably Controller Tools), but these plugins have been passed to the regular store. The default store is not affected by this bug, as it sorts properly by the semantic version number.

A personal recommendation would be to sort a version by date, rather than alphabetical order. This would also out rule any sorting errors caused by duplicate semantic version numbers but with different commit IDs.

PR Submitted Plugins are built and sent to test server

Not working Docked mode

Crashes if docked to a TV when trying to record using decky recorder.
It's either crashed or not working not recording.

To fix this on my end, I'll have to restart and record when handheld.
It wont work while docked.

Also additional, Steam + Y button disconnects bluetooth controller which is also the new replay mode.

Thank you for your work

A plugin without a `pnpm-lock.yaml` file fails to build but passes CI anyways

This results in a plugin on the store which can be installed, but will not show up anywhere (not even in Decky's plugin list).

It can be seen here, specifically in the step Build plugin frontends.

Edit by TrainDoc:

• Update submission process guide.

Check for missing or incorrect URLs in plugin.json

CI currently does not check if there is a missing or incorrect URL for the image tag in plugin.json, which leads to seemingly successful deployments where the plugin does not actually get uploaded to the testing store.

[CI] Allow a setup.sh step that generates files required for build

This is specifically for custom build toolchains support; In the Kotlin/Multiplatform implementation I'm working on, the package.json and related metadata files are generated by the toolchain, rather than being provided directly. Having a separate entrypoint to run e.g. ./gradlew generateMetadataFiles would be very helpful here.

Builder - Error Checking

This bash script should check if a plugin build errors out, and skip rsync'ing it over and any further steps. It should show this error clearly in the build log (maybe red ANSI colored text?), but continue building other plugins instead of just failing the entire run.

It would also be nice to have a summary of which plugins failed and succeeded to build in this run after all plugins finish building,

Convert CI to using new CLI tool fully

A parallel task with SteamDeckHomebrew/decky-plugin-template#21.
Given CLI tool fully ready for production, CI should be moved over to utilizing the CI tool. This will be followed with an update to the wiki's documentation on building and testing plugins to utilize the CLI tool and the plugin templates' current supported build methods (vscode tasks).

Repo - Write a proper Readme

The repo's currently lacking some documentation in form of a Readme.

Allow paths in plugin.json publish.image field

Currently the image field only accepts links to an image, but they are all getting uploaded to the store CDN anyway.
It would make sense to also accept a file path to an image contained within the plugin's git repo since the link is only used by the CI anyway.

For a bit more context (discord link to SD Homebrew guild): https://discord.com/channels/960281551428522045/960284311444131840/995760749764935790

Root tags not being applied with recent uploads to plugin store

Reported by @NGnius, PowerTools and Fantastic don't have their relevant root tags and the CI needs to be investigated to see where the lack of this tag is occurring, but this seems more than likely to be on the server side.

Plugins in Need of Bump to DFL >= 3.19.1

I havr gotten responses from everyone but @0xD34D, @Loidbae. Currently, plugins that have not been updated to DFL >= 3.19.1.

Once the current SteamOS beta release comes to stable, the relevant plugins that have not been updated will no longer work on any branch properly. At that point broken plugins will be hidden from the store until they are patched.

Thanks.

Decky Recorder does not show up

Hey there I just noticed after resting my Steam Deck and doing a fresh install of Decky Loader that Decky Recorder does not show up in the plugin search any more.

Update channel: Stable
Marked place: Stable

But also I was not able to find Decky Recorder on Testing Update or testing marketplace.
Got the plugin delisted?

Account for new plugin template utilizing py_modules folder

Relevant steps to CI to account for new inclusion of py_modules folder during build, zip etc.

Trim testing versions when plugin is merged to production.

Add a ci run for the plugin database that will remove the testing versions of a plugin once it's been merged into the database, (update or new submission treated the same).