Development Glossary
Here we are listing all the development lingo and features of the RetroDECK Project.
"RetroDECK uses a lot of words from Cooking / Foods / Alchemy in combination with Technology Jargon / Technobabble."
Github Repositories
![]()
Main / Main Releases
Stable, feature‑frozen builds (pre‑releases). Full releases are on Flathub.
Cooker / Cooker Releases
Unstable, cutting‑edge branch for testers and developers.
Feature Branches
New features are developed here before merging into Cooker.
Component Branch
Holds shared component artifacts used throughout the project.
Selected Repositories
| Name | Description |
|---|---|
| RetroDECK/RetroDECK | RetroDECK Repo: Main repo of the RetroDECK Project |
| RetroDECK/Cooker | Cooker Repo: Cooker Build publication repo |
| RetroDECK/Wiki | Wiki Repo: RetroDECK mkdocs-material Wiki source code |
| RetroDECK/RetroDECK-website | Website Repo: Retrodeck.net source code |
| RetroDECK/ES-DE | ES-DE Repo: RetroDECK's light fork of ES-DE |
| RetroDECK/components | Components Repo: RetroDECK's central for Components |
| RetroDECK/RetroDECK-theme | Theme Repo: RetroDECK's ES-DE Theme |
| flathub/net.retrodeck.retrodeck | Flathub Repo: net.retrodeck.retrodeck |
| RetroDECK/repositories | Full Org Repo : All other repos in RetroDECK |
RetroDECK Development to Publication Process
![]()
How the publication process works:
- Feature Branches (GitHub) / Component Branch (GitHub) - Initial local testing of a specific feature branch or testing a specific new component.
- Cooker (GitHub) - Merged and publication of the cooker build. Testing starts with the help of Community Testers and the rest of the RetroDECK Team. When the cooker is stable (mostly bug free 🙏) and feature complete for the scope of the release it moves on to main.
- Main (GitHub) - The main release is a *pre-release. After everything looks good a RetroDECK Team member will trigger the flathub publication process.
- Flathub Testing - RetroDECK will first do a testbuild on flathub, the testbuild can be downloaded for the final test to verify that everything was built correctly on flathub. If all goes well it will redo the build on stable and publish.
- Flathub Stable - RetroDECK is out!
When is RetroDECK considered Released?
A version of RetroDECK is only considered released when it is published on Flathub.
Communication:
If a user asks:
Is a new version of RetroDECK out?
You can only answer YES when it has been verified that it is out on Flathub.
RetroDECK Framework
The RetroDECK Framework is the entire back-end system of RetroDECK.
It includes everything that powers the platform, such as:
- Build system
- Functions
- Code
- Scripts
- And more...
In short, it's the engine that makes RetroDECK run.
RetroDECK API
The RetroDECK API allows external applications to interact with the RetroDECK Framework, enabling them to operate like the RetroDECK Configurator.
Currently, the API is only accessible through:
- Named pipes.
- Internal calls within the
RetroDECK Framework.
RetroEngine
RetroENGINE lets you launch games directly from your desktop using RetroDECK - no need to open the full application.
- Supports file associations for common game file types.
- Allows launching games via the command line (CLI).
RetroDECK Configurator
The RetroDECK Configurator is a unique, multi-purpose utility built into RetroDECK.
- Manages many aspects of the RetroDECK application
- Gives users access to features and functions from the
RetroDECK Framework
It acts as the main interface between the user and the powerful tools behind the scenes.
RetroDECK Tool
A RetroDECK Tool is the name given to a function (or group of functions) that is exposed to the end-user through the RetroDECK Configurator.
Example:
BIOS Checker Tool- While it consists of many back-end functions, users simply know it as theBIOS Checker Toolin the Configurator.
RetroDECK Assembler
The RetroDECK Assembler is the total sum of the building engine part of the RetroDECK Framework.
- It builds RetroDECK into a flatpak.
- Packages them into official RetroDECK releases in various repositories.
- Publishes the final builds for distribution on Flathub Stable channels.
RetroDECK Alchemist
The RetroDECK Alchemist is the part of the RetroDECK Assembler that handles everything to do with component sourcing and building.
Library Gather & Library Hunter
The library managers or Library Gatherer & Library Hunter are the part of the RetroDECK Framework.
Their purpose is to reduce library dependency conflicts between components when libraries could be shared.
The Gatherer tries to gather all required extra libraries used by an component and output them into a structured json ingredient file called: component_libs.json
The Hunter then reads the component_libs.json and tries to "hunt" the location of the libraries and connect them.
RetroDECK Mascot: Reiki the Cyber Shark
Read more here:
RetroDECK Components
RetroDECK is made by assembling various components.
What are Components?
A component is a complete packaged executable of a:
- Client
- Emulator
- Engine
- Port
- System
- RetroDECK: Feature & Functions
They are built via a component_recipe.sh (the Recipe) that pulls and compiles the original source.
A component includes Component Ingredient Files that tell RetroDECK how to use it.
A component is stored in it's own isolated file structure under /app/retrodeck/components/<component‑name>/.
The sum of all components Recipe + Ingredient Files is just referred as Component Files.
Read more here about how we classify components:
RetroDECK?!
RetroDECK itself with it's various tools and features is also an component.
Component Recipe File (a.k.a. "Recipe")
Purpose
Directs RetroDECK’s build automation on how to transform a component’s original source-whether an AppImage, Flatpak, pre‑compiled binary, or source code-into a fully packaged RetroDECK component.
Note
component_recipe.sh is used only during the build process and is not shipped with the final component package.
Component Ingredient Files (a.k.a. “Ingredients”)
Purpose
Provide the RetroDECK framework with all the metadata, scripts, and library info a component needs to be displayed, configured, and launched correctly.
Key Contents
- Human‑readable info- Metadata such as name, description, menu text and more for UI menus.
- Preset actions - steps to run when a user changes a preset.
- Component‑specific Bash helpers - setup, firmware install, etc..
- Config‑file paths - other environment details.
- Launch instructions - how RetroDECK should start the component.
- Upgrade instructions - how RetroDECK should upgrade the component.
What are the Component Ingredient Files?
| Ingredient File | Role |
|---|---|
| component_launcher.sh | Sets up the environment and launches the component in its sandbox. |
| component_functions.sh | Declares config‑file paths and component‑specific helper functions (e.g., firmware install, configurator actions). Handles one‑time setup: reset configs, prepare directories, move/backup data, upgrading tasks between RetroDECK versions and apply post‑move tweaks. |
| component_manifest.json | Stores metadata and functional data for RetroDECK: name, description, supported systems, menu entries, preset options, actions, and optional core info. |
| --- |