How reyaansh72/mclauncher works
1. Overall shape
- MCLauncher is a single-process desktop application built in Python + PySide6.
- The architecture is intentionally compact: most runtime behavior lives in app.py, with two small local data files for persistence and Java mapping.
2. Primary subsystem: GUI launcher
- app.py owns the main window, controls, animations, and user interactions.
- The UI is the entry point for selecting a Minecraft version, username, and RAM settings, then starting install/launch actions.
3. Primary subsystem: version and metadata resolution
- The launcher reads the official Mojang version manifest directly to populate available Minecraft versions.
- This is the source of truth for what can be installed, rather than a curated local catalog.
4. Primary subsystem: installation pipeline
- The app handles the full client setup flow: downloading the version metadata, client jar, and required libraries.
- The install flow is responsible for preparing a runnable local Minecraft version under the launcher’s managed game directory.
5. Primary subsystem: Java selection
- Java runtime selection is driven by java_rules.txt.
- The file maps Minecraft version ranges to a Java version and download URL, letting the launcher choose the correct runtime for older, current, and experimental releases.
6. Primary subsystem: game execution
- After installation, app.py assembles the launch command and starts Minecraft via a subprocess.
- The launcher supports both offline/legacy launch behavior and version-specific runtime selection, which is important for compatibility across old and new releases.
7. State and persistence boundary
- config.json stores user-specific launcher state such as username, selected version, and RAM.
- This separates ephemeral UI/session logic from persisted user preferences, so the app can restore settings across launches.
8. Network and external dependencies
- The only major external service dependency is Mojang’s official manifest and download endpoints.
- The app also downloads Java distributions referenced by java_rules.txt, making runtime selection partly data-driven.
9. Platform boundary
- The project is explicitly Linux-only.
- That constraint affects packaging, runtime assumptions, and the binary release strategy; Windows and macOS are not part of the supported architecture.
10. Packaging and runtime model
- The repo is designed to run either from source or as a PyInstaller-built single binary.
- Because the app is mostly self-contained, the packaged artifact only needs the Python runtime, PySide6, requests, and the bundled java_rules.txt.
11. Data flow at a glance
- User input enters through the PySide6 UI in app.py.
- The app reads config.json and java_rules.txt, fetches Mojang version data over the network, downloads required game/runtime files, then launches Minecraft locally.
12. Architecture summary for diagramming
- Draw this as a desktop UI core with three local data inputs/outputs: persistent config, Java rule table, and managed Minecraft install directory.
- Surround that core with two external dependencies: Mojang services for version/download metadata and Java runtime downloads for execution compatibility.
Main entry points: app.py app.py · config.json config.json · java_rules.txt java_rules.txt
Components 11
Launcher core
Single-process PySide6 launcher logic centered in app.py.
- app.py · Main window, controls, install flow, and launch orchestration.
app.py - UI · Version, username, RAM selection, and user actions.
- Version data · Reads Mojang's official version manifest to populate installable releases.
- Installer · Downloads version metadata, client jar, and libraries into the managed game directory.
- Java selector · Chooses a Java version and download URL from version ranges.
- Launch cmd · Assembles the game command and starts Minecraft locally.
Local state
Persisted settings, rule data, and managed game files.
- config.json · Stores username, selected version, and RAM settings.
config.json - java_rules.txt · Maps Minecraft version ranges to Java versions and download URLs.
java_rules.txt - Game dir · Local Minecraft installation and downloaded libraries.
External services
Remote dependencies for Minecraft metadata and Java downloads.
- Mojang services · Official version manifest and game file download endpoints.
- Java distros · External Java distributions used for version-specific runtime compatibility.
Connections 15
- app.py → UI: renders · Creates the launcher interface and handles user input.
- UI → config.json: loads/saves · Restores and persists launcher preferences.
- UI → Version data: requests versions · Populates the version selector from the official manifest.
- Version data → Mojang services: fetches manifest · Reads available releases from Mojang.
- UI → Installer: starts install · Triggers the Minecraft setup flow for the selected version.
- Installer → Mojang services: downloads game · Fetches version metadata, client jar, and required libraries.
- Installer → Game dir: writes files · Places the installed version under the managed game directory.
- UI → Java selector: chooses runtime · Selects the Java runtime for the target Minecraft version.
- Java selector → java_rules.txt: reads rules · Uses local version-range mapping data.
- Java selector → Java distros: resolves download · Identifies the Java distribution to fetch when needed.
- Launch cmd → Game dir: uses install · Runs the installed client from the managed directory.
- Launch cmd → Java selector: gets Java · Uses the selected runtime for launch compatibility.
- Launch cmd → config.json: reads prefs · Uses persisted username, version, and RAM settings.
- app.py → Installer: orchestrates · Coordinates the install flow inside the main process.
- app.py → Launch cmd: orchestrates · Builds and starts the Minecraft subprocess.