[Dexarim]

Summary

• add a configurable, per-profile Action Ring with eight slots, folders, presets, custom shortcuts, commands, and application launchers
• integrate the ring with mouse-button assignments, foreground-application profiles, cursor-relative placement, and adjustment actions
• add a dedicated editor, themed icons, optional LayerShellQt Wayland support, profile migration, and cancellation on device/profile changes
• keep existing gesture assignments separate from Action Ring

Behavior

• assigning Radial menu to a supported mouse button opens the ring around the cursor
• actions run only after an explicit item selection; the trigger, center control, or blank ring area dismisses it
• layouts are stored per device profile, including application-specific profiles
• folders support one nested level and up to nine child actions
• volume and brightness adjustment actions remain open while scrolling or dragging

Validation

• Debug build completed successfully with GCC 16.2.1 and Qt 6.11.2
• Action Ring and application-catalog native tests: 17 passed
• QML suite: 99 passed
• existing DeviceRegistry XDG-isolation test: passed after keeping the new application-initializing tests later in link order
• full local ctest: 782/786 passed; the four remaining failures are environment-sensitive existing tests in SettingsModelTest and HyprlandDesktopFocus, outside the files changed by this PR

Notes

• real mouse hardware behavior has not been re-tested on this clean PR branch
• LayerShellQt is optional; non-layer-shell compositors use the existing Qt window fallback
• third-party plugin loading is not part of this change

[mmaher88]

Thanks for the substantial work. The ring itself looks polished and it's well tested. At 156 files and +3.6k lines it's too much to review and land as one PR, and master has moved under it. #174 made button routing per-device: the dispatcher takes PhysicalDevice*, has no ActiveDeviceResolver, and its state is keyed by serial. So the activeDevice() == device gating in AppRoot and the m_selection usage in the dispatcher would undo that design; they need to be reworked, not just rebased.

Could you split this up? Suggested order:

1. The launchApp splitCommand fix on its own, since it's a real bug fix.
2. The core binding and overlay, with cursor lookup and overlay placement behind IDesktopIntegration. KDeDesktop already has KWin script infrastructure; Hyprland and GNOME need their own cursor source, or the ring should be hidden there via a capability flag.
3. The editor and icons.
4. The app catalog, reusing LinuxDesktopBase's .desktop scanning.
5. Folders, adjustments and presets.

Also:

• Please add LayerShellQt (build) and gio (runtime) to the Arch, Fedora and Debian packaging, or official packages will silently fall back.
• Please store the ring in INI keys rather than a JSON blob, and don't reset the whole ring when one entry fails validation.
• Please get the full test suite green without depending on link order.
• Please say where the icons come from and under what licence (ideally one SVG per glyph, tinted, instead of light and dark copies).

Happy to review the first slices quickly.

[Dexarim]

Thank you very much for the detailed review and for pointing out these issues. I appreciate the suggested breakdown and will address the problems you identified.

Work on splitting the feature has already started in the proposed order. The launchApp / splitCommand fix has been separated into its own PR (#177), and I am currently reworking the core binding and overlay on top of the latest master. This includes adapting it to per-device routing from #174, moving cursor lookup and placement behind IDesktopIntegration, using capability gating for unsupported desktops, switching the configuration to INI keys, and updating packaging dependencies and tests.

The editor, icon set, application catalog, folders, adjustments, and presets will follow as separate slices.

Regarding the SVGs: the glyphs currently in the Action Ring branch were created specifically for this implementation and were not copied from an external icon pack. They are contributed under the same GPL-3.0-only license as the project. I agree that this should be stated explicitly. For the icon slice, I will also replace the separate light and dark copies with one tintable SVG per glyph and add a clear licensing note.

Thanks again — the feedback is very helpful, and I will keep the next PRs small and focused.