devtoys-app/devtoys

1. Overall shape

- DevToys is a multi-project .NET desktop application with a plugin-oriented architecture.

- The center of the system is a shared tool model plus a Blazor-based UI, hosted by platform-specific desktop shells for Windows, macOS, and Linux.

- The repository also contains a command-line entry point, a shared public API for extensions, localization resources, build automation, and tests.

2. Core application layer

- DevToys.Core is the main non-UI application layer.

- It owns composition and discovery (MefComposer, MefProvider), tool catalog modeling, extension ordering, settings abstraction, logging, version checking, web client access, and smart-detection logic.

- It defines the internal “app contract” used by both the UI and the platform hosts.

3. Public extension API

- DevToys.Api is the boundary exposed to tool authors and extension packages.

- It defines interfaces and contracts for tools, GUI components, CLI tools, settings, clipboard, file storage, font access, theme listening, smart detection, and localization.

- This assembly is intentionally broader than the core app internals; it is the compatibility surface for third-party tools.

4. UI subsystem

- DevToys.Blazor implements the user interface in Blazor, but it is not a web app; it is rendered inside native desktop webview hosts.

- It contains the app shell (Main.razor), main pages, dialogs, navigation, and a large set of reusable UI components.

- The UI layer also includes “presenters” that adapt DevToys.Api.Tool.GUI abstractions into concrete Blazor controls.

5. Built-in tools and detectors

- Inside DevToys.Blazor, the built-in tools are grouped by category such as converters, encoders/decoders, formatters, generators, graphics, testers, and text utilities.

- Data type detectors live alongside these tools and feed the Smart Detection feature.

- This is where the app’s default capabilities are implemented, while the core layer handles discovery and selection.

6. Smart Detection flow

- Clipboard or user-supplied input enters the platform abstraction layer, then reaches the core smart-detection service.

- Detectors analyze the payload and classify it as text, JSON, XML, Base64, files, images, dates, and similar types.

- The result is used to select or recommend a tool page in the UI rather than forcing the user to browse manually.

7. Platform host boundary

- Each desktop platform project provides the native shell and the implementations of shared system services: clipboard, file storage, font provider, settings storage, theme listener, and window service.

- These projects are the bridge between OS-native APIs and the shared application code.

- They also host the Blazor UI through a platform-specific BlazorWebView implementation.

8. Windows, macOS, and Linux differences

- The Windows project includes native window chrome, overlay handling, taskbar/jump-list support, efficiency mode hooks, and Windows-specific composition helpers.

- The macOS project includes AppKit integration, window/menu handling, and WKWebView-based hosting.

- The Linux project provides GTK/WebKit-style hosting and platform-specific window and input integration.

- The shared app behavior is the same; only these host adapters differ.

9. Command-line subsystem

- platforms/desktop/DevToys.CLI is a separate executable that maps command-line options to command-line tool implementations.

- It uses the same underlying tool contracts, but drives them without the GUI.

- This gives the repository two entry modes: interactive desktop UI and scriptable CLI.

10. Business/presentation models

- DevToys.Business sits between the core app and the UI shell.

- It contains view models for the main window, tool group pages, and tool pages, plus a command-line launcher service.

- This layer is where app-navigation state is translated into UI-facing models.

11. Extension and package loading

- Extension support is built around MEF-style composition and metadata scanning.

- Tool groups, tools, data type detectors, and language services are discovered from assemblies and ordered into the navigation model.

- There is also an extension installation manager in the Blazor layer, which implies package validation and installation as part of the app’s extension boundary.

12. Localization architecture

- DevToys.Localization holds shared resource files for dialogs, window chrome, text boxes, toggle switches, and other shared UI strings.

- Many projects also carry their own localized resource sets for platform-specific UI.

- The generated resource helpers and culture generators show that localization is treated as a first-class cross-cutting concern.

13. Custom Blazor component system

- The UI has its own component library for layout, text, menus, lists, grids, popovers, dialogs, and feedback elements.

- Many components have small JS/TS companions for DOM behavior, focus trapping, scrolling, resizing, or editor interop.

- This component system is the main rendering boundary between the UI model and the browser engine embedded in the desktop shell.

14. Monaco editor integration

- The text-editor experience is built around a substantial Monaco editor wrapper and a large set of editor/language model types.

- This subsystem supports code-like editing, diffing, syntax-aware behavior, and language services within the Blazor UI.

- It is one of the biggest internal integrations because many tools depend on it.

15. Build, versioning, and test infrastructure

- Root-level Nuke build scripts, version-updater tasks, restore tasks, and generator projects handle repository automation.

- Tests cover core utilities, MEF composition, detectors, UI helpers, and extension installation behavior.

- This indicates the codebase is organized as a product platform with strong emphasis on composability, localization, and cross-platform desktop hosting.