htop is a cross-platform interactive process viewer and system monitor written in C on ncurses. It enumerates and displays processes by reading OS kernel interfaces — primarily /proc on Linux, sysctl/kvm/kstat on the BSDs and Solaris, libproc/mach on macOS, and PCP (Performance Co-Pilot) metrics for the pcp-htop variant — and renders a scrollable process table alongside a header of pluggable meters (CPU, memory, swap, disk I/O, network I/O, ZFS ARC, GPU utilization, pressure stall, battery, sensors, and more). Beyond display, it supports process management actions: kill, renice, set CPU affinity, scheduling and I/O priority, spawning strace/lsof child processes, plus tree view, sorting, filtering, incremental search, and persistent configuration in htoprc. Architecturally this is a monolithic C application with emulated object orientation: an Object base class with vtable-style Class function tables, generic containers (Hashtable with Robin Hood open addressing, Vector with ownership semantics), a RichString wide-character rendering layer, reusable Panel/Meter widget classes, and a ScreenManager event loop. Each supported OS lives in a backend directory (linux/, darwin/, freebsd/, openbsd/, netbsd/, dragonflybsd/, solaris/, pcp/, unsupported/) that implements the Platform/Machine/ProcessTable/Process contract. Entry points are htop.c and pcp-htop.c, which route through CommandLine_run() into ScreenManager_run(). The build uses GNU autotools with optional features (hwloc, libsensors, libnl, libcap, libunwind, PCP), and CI runs the binary headlessly under sanitizers plus a Lua/rote terminal-emulation test suite. Maintenance is genuinely active: recent commits, a CodeQL workflow, address/UB sanitizer jobs, valgrind suppressions, and a ChangeLog showing security fixes (CVE-2024-37676) and steady feature work through 3.6.0-dev. The honest caveats are platform fragility: Solaris and OpenBSD have TODO stubs for disk/network I/O, NetBSD uses deprecated proplib compatibility aliases, /proc and DRM fdinfo parsers are sensitive to kernel format changes, and there is visible copy-paste divergence across BSD backend field arrays. The core Linux path is current and well-maintained; the tail platforms lag, which keeps overall technical drift at medium rather than low.
The mviewer repository is a Rust-based application for viewing and exporting Marmoset .mview scene files. It features a dual-mode interface: launching a GUI (using tao/wry embedded webview) for interactive preview when no arguments are provided, or running in CLI mode for batch conversion when arguments are given. The GUI loads a local HTTP server to serve an embedded, forked Marmoset JavaScript viewer that renders scenes with visual parity to Marmoset Toolbag. The core Rust logic handles loading the proprietary .mview archive format, extracting scene data (meshes, materials, animations, cameras, lights, textures), and exporting to glTF/GLB/OBJ formats. The application demonstrates strong modularity with clear separation between archive parsing, data processing, export pipelines, and GUI integration. While the embedded JavaScript viewer introduces some maintenance considerations due to its forked nature, the Rust components exhibit high reusability and craftsmanship, particularly in handling complex binary formats and data transformations.
Reall3dViewer is a high-performance 3D Gaussian Splatting (3DGS) web viewer built on Three.js. It streams and renders large-scale point cloud scenes (up to 150M points) at interactive frame rates across desktop and mobile devices. The viewer supports multiple input formats including PLY, SPLAT, SPX (proprietary high-compression format), SPZ, SOG, and GLB with the KHR_gaussian_splatting extension. Its architecture is event-driven and modular, with a central event system (Events.ts), dedicated loaders for each format, web workers for parallel data fetching and sorting, and a texture management pipeline that handles LOD tile streaming, frustum culling, and adaptive quality levels. Beyond basic viewing, the repository provides a full suite of interactive features: measurement and annotation tools (distance, area, point labels, 3D tags, circle plans), a map viewer (Reall3dMapViewer) with GIS basemap integration, a first-person/third-person player mode with physics (rapier3d), weather effects (rain, snow), audio-driven text overlays, and a fly-through camera path system. The code is published as an npm package (@reall3d/reall3dviewer) and includes comprehensive demo pages with scene configuration JSON files. While primarily an application library, the project also exhibits data/research characteristics through its custom SPX format specifications, advanced compression techniques (WebP, gzip, xz, zstd), and spherical harmonics support up to degree 3. The source code demonstrates high engineering craftsmanship in areas like GLSL shader modularization, WebAssembly integration for format parsing, and efficient web worker communication patterns. However, there are some maintenance risks including a large monolithic event constant file (200+ auto-incremented integers), hardcoded demo URLs, and a build script that embeds worker code as base64, which complicates debugging. No automated tests are present.
GameExtractor is a desktop application designed to extract, view, and convert resources from various game archive formats. It features a plugin-based architecture that allows users to add support for new game formats without modifying the core application. The software provides a graphical interface for browsing archive contents, previewing extracted resources (images, audio, models), and performing operations like extraction, conversion, and file replacement. The application follows a modular design with clear separation between the core framework, plugin system, user interface, and utility functions. At its core, it uses a plugin architecture where format-specific handlers (archive, viewer, exporter) implement standardized interfaces. The main entry point is the GameExecutor class, launched via platform-specific scripts. Data flows from archive selection through plugin-based parsing to resource representation, then to UI display or export operations. External dependencies include numerous Java libraries for compression (zip4j, junrar, xz, lzf, lz4, zstd), image processing, audio playback, and UI components. The application supports both legacy formats and modern game engines through its extensible plugin system, with specific implementations for formats from games like Doom, Quake, Unreal Engine, Unity, and many others.
GTKWave is a mature desktop application for viewing waveform dump files generated by digital circuit simulators (VCD, FST, GHW, etc.). It provides a graphical interface with hierarchical signal browsing, time-synchronized waveform rendering, marker placement, pattern search, and transaction filtering. The tool also ships with multiple command-line utilities for format conversion (e.g., vcd2fst, fst2vcd) and signal mining. Its codebase is structured as a core GObject-based library (libgtkwave) that abstracts dump-file loading and querying, a set of helper libraries (libghw, libvzt, liblxt, libwcp, libjrb) for specific formats, and a GTK GUI layer (src/) that handles user interaction, rendering, and state. The project continues to receive active maintenance, with recent work including GSettings integration, WCP remote control protocol, and migration to Meson build system. However, the code retains significant global state (struct Global), platform-specific #ifdefs, and some duplicated VCD parsing logic across converters, which somewhat limits modularity and testability.