Faugus Launcher is a Linux-native game launcher designed to run Windows games via compatibility layers (UMU-Launcher/Proton/Wine). It provides a modern GTK4/libadwaita GUI with multiple views (list, grid, covers, carrousel) for managing and launching games from sources like Steam, Epic, and others. The application handles game configuration, Proton version management, prefix handling, shortcut creation (desktop/appmenu/Steam), system tray integration, backup/restore of settings, and performance tool integration (MangoHud, GameMode, Lossless Scaling). Architecturally, it follows a modular Python structure with clear separation of concerns: launcher.py (main GUI), runner.py (game execution), config_manager.py (settings), proton_manager.py (Proton handling), backup.py (backup/restore), shortcut.py (shortcut creation), tray_sni.py (system tray), and various utility modules. Key entry points include the main launcher (launched via flatpak/AppImage/binary), the runner for game execution, and the tray daemon for background operation. Data flows involve storing game metadata in JSON files (games.json), configuring launch environments, and interacting with external services like SteamGridDB for art and GitHub for Proton/UMU updates. The application demonstrates strong engineering practices: atomic JSON writes to prevent corruption, proper GTK resource cleanup, background task handling, cross-platform path management for Flatpak/AppImage/native installs, and a configuration migration system. While it relies on external tools (mangohud, gamemoderun, icoextract) and online APIs (SteamGridDB, GitHub), it gracefully handles missing dependencies. The codebase is actively maintained with recent commits, CI/CD workflows for multiple packaging formats, and ongoing translation efforts.
Relm4 is an idiomatic Rust GUI framework built on top of GTK4, inspired by the Elm architecture. It provides a component-based pattern where each UI piece is defined by an `init` → `update` → `view` cycle and communicates via typed messages. The framework includes a declarative macro system (`view!`, `#[component]`, `menu!`) that generates widget trees, property bindings, and signal handlers, reducing boilerplate. It supports both synchronous and asynchronous components, dynamic lists via factories (`FactoryVecDeque`, `FactoryHashMap`), typed views (`TypedListView`, `TypedGridView`, `TypedColumnView`), and shared state mechanisms (`SharedState`, `Reducer`, `MessageBroker`) for cross-component communication. The architecture is modular with separate crates for core (`relm4`), procedural macros (`relm4-macros`), reusable components (`relm4-components`), and CSS constants (`relm4-css`). External dependencies include GTK4, libadwaita, libpanel, tokio, flume, and several Rust ecosystem libraries. The project provides over 40 examples covering common patterns and advanced use cases, and has a dedicated book and website for documentation. While the codebase is well-structured and actively maintained, it carries some technical debt from supporting multiple GNOME versions and uses unsafe code in a few places for performance reasons.
Bottles is a desktop application for running Windows software on Linux by managing Wine/Proton 'bottles' — isolated Windows prefix environments. In production it creates, imports, configures, and deletes bottles, installs and manages Wine runners (Wine, Proton, Soda) and graphics components (DXVK, VKD3D, NVAPI, D7VK), applies step-based dependency manifests (DLLs, runtimes, registry keys, fonts), and launches Windows executables with per-bottle environment composition (sync modes, HDR, Wayland, gamescope, FSR, mangohud, sandboxing via bwrap/flatpak-spawn). It also integrates with the UMU launcher for running Proton games outside Steam, discovers Steam/Epic/Origin libraries, and tracks playtime in a local SQLite database with crash recovery and aggregation. The dominant character is unambiguously a desktop application, though it embeds a small data layer (playtime SQLite, EagleIntel community-intelligence SQLite, YAML catalog caches) that serves the app rather than constituting a research pipeline. The architecture is a classic backend/frontend split: a singleton Manager orchestrates sub-managers (component, dependency, installer, library, versioning, sandbox, playtime, backup, Eagle), while a GTK4/Adwaita frontend (views, windows, widgets, Blueprint .blp templates) and a companion CLI (bottles-cli) consume it. Loose coupling is achieved through a SignalManager/EventManager pub-sub bus, RunAsync threading helpers, and a standard Result return type. Catalogs for components, dependencies, and installers are fetched as YAML from remote repositories with local caching, offline fallback, and checksum validation; user settings live in GSettings; bottle configs are YAML dataclasses; versioning snapshots are delegated to an external FVS2 tool. A distinctive Eagle subsystem performs static analysis of Windows executables (pefile parsing, YARA rules, installer/ASAR extraction) and consults a bundled community-sourced SQLite database (ProtonDB/winetricks-derived) to recommend compatibility environment variables, DLL overrides, and launch flags. A Microsoft identity bridge implements the Soda OAuth 2.0/PKCE protocol over Unix sockets, with libsecret/cpak secret storage, enabling Microsoft account sign-in inside Wine. Engineering quality is strong: a large pytest suite covers backend managers, Wine wrappers, UMU, playtime integration, and frontend dialogs; the project uses ruff/mypy/pyright via pre-commit; CI builds Flatpak and cpak multi-arch (amd64/arm64) images and runs tests; localization spans 60+ languages. The repository is actively maintained with very recent commits, structured issue templates, and a dependabot-enabled pipeline with zero alerts. Principal drift risks are moderate: a deprecated Gtk.FileChooserNative call (vs Gtk.FileDialog), dual download implementations (pycurl for repos vs requests for Downloader), a vendored ValvePython vdf/vdict copy, hardcoded repository URLs pinned to commit hashes, and version-specific Wine/Proton workarounds that will age. The frontend is tightly coupled to Flatpak runtime resources, limiting its portability, but several backend components are cleanly isolated and genuinely reusable.
Czkawka is a multi-tool file cleanup utility written in Rust that finds and removes duplicate files, similar images/videos/music, empty directories, broken files, temporary files, and more. It is structured as a Rust workspace with a shared core library (`czkawka_core`) that implements all scanning algorithms and a common architecture (traits, caching, progress reporting). Three frontends exist: a CLI (`czkawka_cli`), a legacy GTK4 desktop GUI (`czkawka_gui`, in maintenance mode), and a modern Slint-based desktop GUI (`krokiet`) which is the primary focus. An additional Slint-based Android app (`cedinia`) also reuses the core. The codebase demonstrates strong software engineering practices: modular design, extensive use of traits, parallel directory traversal with a builder pattern, generic caching, and comprehensive localization via Fluent. Despite some duplication between frontends and the deprecated GTK GUI, the core library is well-crafted and reusable.
Trayscale is an unofficial GTK4/Libadwaita desktop GUI for the Tailscale VPN daemon, targeting Linux (no official Linux GUI exists). It provides a system tray status icon, a full Libadwaita window for managing peers, exit nodes, Mullvad exit nodes, Taildrop file transfers, profiles, and connection state. The architecture is a single Go binary using gotk4 bindings to GTK4 and Libadwaita. It communicates with the local tailscaled via Tailscale's local API and IPN bus watcher for real-time status updates. The codebase demonstrates solid Go engineering: clean separation of concerns (tsutil client layer, UI layer, tray, datatypes), use of modern Go features (generics, iterators, slices, maps), and comprehensive tests for the core polling and search logic. While not a reusable library, several internal packages (peersearch, autosave, listmodels) are well-isolated and could be extracted.
Lan Mouse is a cross-platform software KVM switch that enables sharing a single mouse and keyboard across multiple computers on a local network, inspired by Apple's Universal Control. It is implemented as a Rust daemon with a GTK4/Libadwaita GUI frontend and a CLI interface, supporting Linux (Wayland, X11), macOS, and Windows. Communication between peers uses DTLS/TLS encryption with self-signed certificate fingerprint authentication over UDP/TCP. Input capture and emulation are abstracted via traits with platform-specific backends (libei, layer-shell, X11, CoreGraphics, Windows input APIs), and client discovery relies on mDNS/DNS. The architecture features a central service orchestrator managing capture, emulation, state, and IPC with the frontend over Unix sockets (or TCP on Windows). The codebase demonstrates solid Rust practices, async patterns with Tokio, and clean trait design for platform abstraction. While functionally complete, there are known caveats around compositor support, scancode mappings, and some memory leaks, reflecting ongoing development effort.
Tangram is a GNOME desktop application written in JavaScript (GJS) that functions as a specialized browser for managing web applications as persistent, sandboxed tabs. It uses GTK4, Libadwaita, and WebKitGTK to render each tab independently, with per-tab settings (name, URL, user agent, notification priority) stored via GSettings. The application provides a tab overview (Adw.TabOverview), navigation controls, and integrates with the GNOME notification system. It is packaged as a Flatpak and supports translations via Weblate. The codebase is well-structured, modular, and follows modern GNOME development practices, with unit tests for URL utilities and web app metadata extraction.
SongRec is a Linux desktop application (with CLI counterpart) that recognizes songs by sending audio fingerprints to Shazam's proprietary API. It is written in Rust and uses GTK4/libadwaita for the GUI. The architecture is a multi-threaded monolith with dedicated threads for microphone capture, audio processing (fingerprinting), HTTP communication with Shazam, and the GUI event loop. External dependencies include Shazam's servers (reverse-engineered endpoint), FFmpeg for audio file decoding, and platform audio backends (CPAL, PulseAudio, ALSA). The application provides persistent song history with CSV export, favorites, MPRIS integration, system tray icon, and configurable request intervals to handle rate limiting. The codebase shows good engineering practices with trait abstractions for audio backends, a typed channel message system, and versioned preferences. A separate Python reference implementation exists in the `python-version/` directory but is not the primary codebase.
Clapper is a modern media player application designed for the GNOME desktop, built with GTK 4 and powered by GStreamer. It features a queue-based playback system supporting sequential, repeat, carousel, and shuffle modes, along with standard media controls like play/pause, seeking, volume adjustment, and fullscreen toggling. The application emphasizes usability with an adaptive interface, subtitle/audio track selection, playback speed control, and media information display showing technical details such as codecs and bitrates. The architecture consists of three main layers: a core library (`clapper`) handling playback logic, queue management, and extensibility via plugins; a GTK library (`clapper-gtk`) providing reusable widgets like video display, buffering indicators, and custom layouts; and the main application (`clapper-app`) assembling the user interface and integrating with the core. Extensibility is achieved through a libpeas-based plugin system for metadata extraction, playlist parsing, and reactive components, while optional features like MPRIS and a built-in web server for remote control are marked as deprecated in favor of the external enhancer ecosystem. Clapper demonstrates strong engineering practices with proper GObject encapsulation, thread-safe design using a custom `ClapperThreadedObject` base class, and adherence to GTK 4 patterns such as template-based widgets and action-driven UI. The project maintains active development with recent commits, comprehensive internationalization support, and integration with modern GNOME technologies like libadwaita, though it relies on evolving dependencies (GStreamer, GTK) and contains some deprecated components requiring ongoing maintenance.
Foliate is a desktop e-book reader for GNOME/Linux, built with GTK4, Libadwaita, and GJS (GNOME JavaScript). It supports EPUB, Mobipocket, Kindle, FB2, CBZ, and PDF formats, using WebKitGTK to render book content via a custom JavaScript rendering engine (foliate-js). The application provides a full-featured reading experience with paginated and scrolled modes, customizable fonts and themes, annotations (highlights, notes, bookmarks), text-to-speech via Speech Dispatcher, OPDS catalog browsing, and dictionary/Wikipedia lookups. Architecture: The main entry point is src/main.js, which initializes the GJS application and loads the GResource-bundled source files. The core UI is defined in src/app.js (window creation, file handling) and src/book-viewer.js (reading view with sidebar, search, navbar, TTS). The library view (src/library.js) manages book collections and OPDS integration. Reading state (annotations, bookmarks, progress) is persisted per-book as JSON files in the user's data directory. The rendering pipeline lives in the WebView: src/reader/reader.js handles content display, CSS injection, and footnotes, while the foliate-js submodule parses e-book formats into a pageable model. External dependencies: GNOME platform (GTK 4.12, Libadwaita 1.8, WebKitGTK 6.0, GJS 1.82), Speech Dispatcher for TTS, Tracker (optional) for file indexing, and third-party APIs (Wiktionary, Wikipedia, Google Translate) for lookup tools. The build system uses Meson, with Flatpak and Snap packaging provided. Internationalization across 30+ languages is maintained via gettext PO files. Data flows: User opens a file → book is parsed by foliate-js into a structured document model → rendered in WebView → user interactions (scroll, search, annotate, bookmark) are communicated back to GJS via the WebView's async RPC pattern (exec/iter/provide) → state is persisted as JSON files. OPDS catalogs are fetched via HTTP and rendered in a separate WebView frontend (src/opds/main.html).
Live Photo Converter is a cross-platform application for processing Android Live Photos (MVIMG files). It provides a modern GTK4/LibAdwaita graphical interface, a set of command-line tools, and a shared library (`liblivephototools`) for creating, extracting, and repairing these files. The core operation involves appending an MP4 video to a JPEG image and managing the associated XMP metadata (Google's GCamera and Container namespaces). It also supports generating long exposure photos from video frames and copying metadata between images. The architecture is a well-structured monolith written in Vala and built with Meson. The core logic resides in a shared library, with CLI and GUI frontends linking against it. Video processing is handled by a clean strategy pattern, defaulting to an in-process GStreamer pipeline with an FFmpeg subprocess fallback. The build system is highly sophisticated, supporting Linux (Flatpak, Arch), Windows (MSYS2), macOS (Homebrew), and Android (experimental, via pixiewood). The codebase demonstrates strong software craftsmanship. It features clean abstractions (abstract base classes `LivePhoto`/`LiveMaker`), meticulous thread safety (GOnce, AtomicInt, AsyncQueue, Mutex), and well-encapsulated utility components. The `PipelineWatch` class for GStreamer error handling and the `Reporter` class for CLI output are particularly well-crafted and reusable. The primary weakness is the absence of a formal unit test suite, which prevents a higher quality score.
Collision is a desktop application for generating and verifying cryptographic hashes of files. Built with Crystal, GTK 4, and libadwaita, it provides a clean GUI interface to calculate MD5, SHA-1, SHA-256, SHA-512, Blake3, CRC32, and Adler32 hashes. The application features concurrent hash calculation using Crystal's fiber system, a Nautilus extension for file manager integration, and proper handling of Flatpak sandboxed environments. It follows a modular architecture with separate concerns for UI, core functionality, and application logic.
Packet is a GTK4/libadwaita desktop application for Linux that implements the Google Quick Share protocol, enabling wireless file transfer between Linux and Android devices. The application discovers nearby devices via Bluetooth and mDNS over Wi-Fi, and supports sending files, text, links, and Wi-Fi passwords. It integrates deeply with the GNOME desktop: a Nautilus plugin adds a "Send with Packet" context menu, a D-Bus API allows external control, and it can run in the background with a system tray icon. The codebase is written in Rust, using the `rqs_lib` library for the Quick Share protocol logic. The architecture follows a standard GtkApplication pattern with custom GLib object types for transfer state, asynchronous file operations using tokio, and a modular widget system for transfer cards. The code is well-structured overall, though the main window file is large and some FIXMEs indicate areas for improvement. The project has active maintenance, comprehensive localization (30+ languages), and a CI pipeline.
Gear Lever is a GNOME desktop application for managing AppImage files on Linux. Its core function is integrating AppImages into the desktop environment by extracting them, generating .desktop entries with metadata and icons, and keeping them updated. It supports one-click install from downloaded AppImages, drag-and-drop integration, in-place version updates from multiple sources (GitHub releases, GitLab, Codeberg, Forgejo, FTP, and static URLs), side-by-side version retention, per-app environment variables and exec arguments, and bulk update operations. The application is distributed primarily as a Flatpak on Flathub and also ships a headless CLI (src/Cli.py) matching most GUI operations such as integrate, update, remove, list, and fetch-updates. Architecturally, this is an event-driven GTK4/Adwaita desktop application written in Python. The main window (GearleverWindow) uses Adw.Leaflet navigation with a drag-and-drop overlay, and views communicate through custom GObject signals. The core lifecycle logic lives in AppImageProvider, which handles download, extraction, desktop-entry generation, and launch. Extraction uses a fallback chain (dwarfs → 7zz → unsquashfs → appimage-extract) to handle the fragmented AppImage format landscape. Update sources are abstracted behind an UpdateManager ABC with separate backend classes per hosting platform. Configuration is split between a global JSON settings store and per-app INI files, with a migration path from an older JSON schema. Background work is managed through custom async/idle/debounce decorators that marshal tasks onto worker threads and safely return results to the GTK main loop. The system relies on external runtime binaries (7zz, dwarfsck, dwarfsextract, unsquashfs, readelf, strings, file, get_appimage_offset) in addition to Python packages (dbus-python, pyxdg, ftputil, requests, desktop-entry-lib). Notably, the repo embeds a demo.AppImage binary used as a test fixture, illustrating the extraction pipeline against a real-world AppImage. Test coverage is thin — only CLI integration tests that download actual AppImages — and the codebase shows some legacy baggage (ftputil, direct D-Bus usage, fragile external-tool version assumptions). Nonetheless, the code is modular, actively maintained with nightly builds, well-internationalized (16 languages), and demonstrates real craftsmanship in its abstraction layers.
GNvim is a GTK4-based Neovim GUI written in Rust. It communicates with Neovim via the MessagePack-RPC protocol, providing a native desktop experience with features like floating windows, popup menus, tabline, cmdline, and smooth animations for cursor and scrolling. The architecture is a single Rust binary split into a workspace: the main `ui` crate contains the GTK4 frontend with custom widgets (e.g., Grid, GridBuffer, Cursor, Fixedz, Popupmenu, Shell), and the `nvim-rs` library crate provides a reusable, async RPC client for Neovim with auto-generated API bindings. The system's entry point is `ui/src/main.rs`, which registers resources and launches the GTK application. Data flows bidirectionally: Neovim sends UI events (redraw, options, notifications) as RPC messages, which are deserialized into Rust types and applied to the GTK widget tree; user input (keyboard, mouse) is captured by GTK event controllers and sent back to Neovim as RPC calls. The codebase is well-structured, modular, and follows modern Rust async patterns, with extensive use of GTK4's property system and custom layout managers for complex UI composition.
Honkers Launcher is a Linux desktop application that serves as an unofficial launcher for the game Honkai Impact 3rd. Built with Rust, GTK4, and relm4, it manages Wine prefixes, installs DXVK, applies game patches (including the Chinese edition patch), disables telemetry, and handles game updates. The architecture is a standard GTK GUI with a first-run wizard and a state machine for launcher operations. It relies on the `anime-launcher-sdk` crate for API calls and component management, and external tools like Wine, DXVK, bubblewrap, and gamescope. The codebase is in maintenance mode, with no new features planned, and some code quality issues such as unsafe globals, excessive unwrap calls, and commented-out code.