Publish launcher status to Discord over its local IPC named pipe with
no external dependency: framed-JSON handshake and SET_ACTIVITY, a
background worker with reconnection and latest-state dedup, and silent
no-op behavior when Discord is not running.
- "Browsing the library" (game count, session elapsed) while idle;
"Playing <game>" with title id and elapsed time during emulation.
Activities always carry timestamps: Discord accepts but does not
render activities without them
- Presence flips back to browsing immediately on Stop instead of
waiting for process exit: a game wedged in a GPU driver call can
outlive termination for a while. Stop also terminates the job
object so the whole child tree dies even in that state
- Toggle in the Options panel (persisted); client id configurable in
gui-settings.json; SHARPEMU_LOG_DISCORD=1 traces queue/send/failure
* [gui] Add Avalonia desktop frontend
Adds SharpEmu.GUI, a dark-themed desktop frontend that drives the
SharpEmu CLI as a child process:
- Game library with folder scanning for eboot.bin, search, and
persisted settings (%APPDATA%/SharpEmu/gui-settings.json)
- Launch options mapped to CLI flags (log level, strict dynlib
resolution, import trace limit)
- Live console with severity color-coding, bounded buffer, and
crash-safe deferred auto-scroll
- EmulatorProcess launches the CLI via CreateProcessW with the same
CET/CFG mitigation opt-outs the CLI applies to its own relaunched
child (suppressed via SHARPEMU_DISABLE_MITIGATION_RELAUNCH so
output is not lost to a detached console), inheritable pipes for
stdout/stderr capture, a kill-on-close job object, and a fallback
to an unmitigated launch on Windows builds that reject the policy
bits
Also pins Tmds.DBus.Protocol 0.21.3 (transitive of Avalonia.Desktop)
to fix GHSA-xrw6-gwf8-vvr9.
* [gui] Integrate GUI into the SharpEmu executable
Per review feedback, the GUI is no longer a separate application.
SharpEmu.exe now opens the desktop frontend when started without
arguments and behaves exactly as the existing CLI when given any
argument:
- SharpEmu.GUI becomes a class library exposing GuiLauncher.Run(),
hosted by SharpEmu.CLI
- The console window is hidden in GUI mode only when the process is
its sole owner (double-click launch), never a terminal the user
launched from
- In GUI mode the frontend spawns this same executable (with
arguments) as the emulator child process, so the existing launch,
piping, and mitigation machinery is unchanged
* [gui] Address review feedback: no console, single-file, param.json, portable settings
- Switch SharpEmu.exe to the GUI subsystem so no console window appears
at startup. CLI mode attaches to the parent terminal console (or
allocates one when started with arguments but no terminal) and
rebinds missing std handles to CONOUT$; piped/redirected output is
used as-is, so scripted and GUI-spawned runs are unaffected.
- Publish as a true single file: native libraries are embedded and
self-extracted, with glfw kept as the only loose DLL next to the
executable.
- The game library reads sce_sys/param.json and shows the game title
with the title id beneath it, falling back to the folder name.
- GUI settings and the crash log now live next to the executable,
matching the emulator convention, instead of %APPDATA%.
* [build] Add win-x64 sections to package lock files
Generated by dotnet publish -r win-x64 with locked restore enabled.
* [build] Regenerate lock files from project configuration
dotnet restore --force-evaluate; removes the win-x64 runtime sections
that a local RID-specific publish had written into projects that do
not declare a runtime identifier, which broke locked-mode restore in
CI. Verified with dotnet restore -p:RestoreLockedMode=true.
---------
Berk