Wield

Problem

Wield grew out of an earlier project (DeskCrafter) for creating and managing Linux desktop-entry files. Partway through, the intended use case changed to something different: a global-hotkey command palette and tray fronting quick utility actions — screen capture tools and file/data converters — built on XDG Desktop Portals so it works across desktop environments without per-DE code. Most of the old codebase was redundant under the new design, and the old name no longer matched what the project had become, so it restarted clean under a new name rather than carrying that mismatch forward.

Audience

Linux desktop users who want quick utility actions — screen capture, file/data conversion — available from one global-hotkey command palette, without tooling that only works on a specific desktop environment.

My role

Sole builder, as a personal project — rebuilt from scratch after the DeskCrafter scope changed.

Key decisions

• Built on XDG Desktop Portals rather than per-desktop-environment integrations, so the same tool works across GNOME, KDE, and others without separate code paths for each.
• Split into a Rust workspace — wield-core (descriptor model, executor, tool registry), wield-portal (portal access and capability probing), wield-tools (built-in tool descriptors), wield-cli (a command-line surface) — with a Tauri + React desktop shell on top, instead of one monolithic app.
• Restarted as a new project rather than continuing to evolve DeskCrafter, once the scope had changed enough that most of the old codebase was redundant and the old name no longer matched what the project had become.

Result

Still in active development and not yet at an MVP — an ongoing process, stated plainly rather than dressed up as further along than it is.

Constraints & honest scope

Early-stage and pre-MVP: the design is still being worked out, and scope or direction may keep changing before an MVP lands. No packaged release yet.