Thanks for taking an interest in Proton Pulse.
This project is built for Steam Deck players who rely on Proton, ProtonDB, and Linux gaming tools every day. The goal is simple: make ProtonDB data useful on-device, help people compare reports against their own hardware, and make it easier to apply, test, and share launch configurations without leaving the Deck.
- Read the main README for the project overview.
- Check existing issues before starting a larger change.
- If you are changing user-facing behavior, screenshots and translation checks are usually worth revisiting too.
From the plugin repo:
pnpm install
UV_CACHE_DIR=/tmp/uv-cache uv sync --group devUseful commands:
make build
make test
make test-ts
make test-py
make check-translationsIf you are working with a real Steam Deck:
DECK_IP=$(cat ~/.deckip) make deploy-reload- Keep changes focused.
- Prefer fixing the root cause instead of layering on workarounds.
- Preserve the Steam Deck controller-first experience.
- Keep translations in sync for user-facing strings.
- Add or update tests when behavior changes.
- TypeScript and Python are both used here.
- Keep UI text in i18n instead of hardcoding English strings in components.
- Favor small, readable helpers over deeply nested conditionals.
- If a change affects settings, configs, screenshots, or local storage, think about migration and backup/restore behavior too.
Before opening a PR, try to run the relevant checks for your change:
make build
make testIf your work touches translations:
make check-translationsIf your work touches the Steam Deck UI or screenshot flows:
DECK_IP=$(cat ~/.deckip) make deploy-reload
make take-screenshotThis project keeps a screenshot gallery for documentation and translation review.
Useful examples:
LANG=cn DECK_IP=$(cat ~/.deckip) make capture-project-screenshots
LANG=all DECK_IP=$(cat ~/.deckip) make capture-project-screenshotsWhen adding or changing user-facing text:
- update translations
- review affected screenshots if possible
- call out any remaining untranslated text that comes from external content, such as ProtonDB report prose
PRs are easiest to review when they include:
- a short explanation of the problem
- a clear summary of what changed
- testing notes
- screenshots for UI changes when relevant
Small PRs move faster than large ones. If a change is big, splitting it into a couple of focused PRs is usually better.
This repository enforces DCO sign-off on pull requests. Every commit in the PR needs a Signed-off-by trailer from the commit author.
The easiest way to add it is when you create the commit:
git commit -s -m "your message"If you already created a local commit without the sign-off, you can add it with:
git commit --amend -s --no-editThen push the updated commit:
git push --force-with-leaseBug reports are most helpful when they include:
- what you expected
- what actually happened
- whether it happened on-device, in Desktop Mode, or in screenshots/docs
- logs, screenshots, or a short video when available
You do not need a perfect patch to contribute. If you are unsure about a direction, opening an issue first is completely fine.
The project covers a few moving parts:
- the Decky plugin
- localization
- screenshot automation
- the
proton-pulse-webpipeline and CDN-backed data flow
So if something feels connected to one of those systems, it probably is.