|
| 1 | +# DesktopManager App Design Plan |
| 2 | + |
| 3 | +This document captures the image-model design direction for the DesktopManager desktop app and tray experience. The mockups are intentionally treated as design references, not exact pixel contracts. |
| 4 | + |
| 5 | +## Design Goals |
| 6 | + |
| 7 | +- Make monitor topology the center of the product, not a secondary settings field. |
| 8 | +- Keep hotkey and rule editing fast enough for daily power-user use. |
| 9 | +- Make tray interaction useful without opening the full app. |
| 10 | +- Prefer clear operational surfaces over marketing-style presentation. |
| 11 | +- Keep diagnostics first-class so broken hooks, permissions, and monitor identity issues can be understood quickly. |
| 12 | + |
| 13 | +## Image Model References |
| 14 | + |
| 15 | +| Surface | Mockup | |
| 16 | +| --- | --- | |
| 17 | +| Main app control center |  | |
| 18 | +| Tray flyout |  | |
| 19 | +| Hotkeys page |  | |
| 20 | +| Layout rules page |  | |
| 21 | +| Diagnostics page |  | |
| 22 | +| Startup page |  | |
| 23 | +| Earlier control-center exploration |  | |
| 24 | + |
| 25 | +## Application Shell |
| 26 | + |
| 27 | +The app should use a compact left navigation rail and keep all product surfaces in one window: |
| 28 | + |
| 29 | +- `Monitors` |
| 30 | +- `Hotkeys` |
| 31 | +- `Layout Rules` |
| 32 | +- `Diagnostics` |
| 33 | +- `Startup` |
| 34 | + |
| 35 | +The top area should include runtime status, hotkey status, active profile, and quick actions: |
| 36 | + |
| 37 | +- `Apply Rules` |
| 38 | +- `Pause Hotkeys` / `Resume Hotkeys` |
| 39 | +- `Open Diagnostics` |
| 40 | +- profile selector |
| 41 | + |
| 42 | +The shell should avoid a landing page. Opening the app should land on the active management surface, with `Monitors` as the default. |
| 43 | + |
| 44 | +## Monitors Page |
| 45 | + |
| 46 | +The `Monitors` page is the primary workspace. |
| 47 | + |
| 48 | +It should contain: |
| 49 | + |
| 50 | +- a large topology canvas with physical monitor positions |
| 51 | +- stable topology labels such as `Top Left`, `Top Right`, `Bottom Left`, `Bottom Right` |
| 52 | +- resolution, DPI, primary, and connected status badges |
| 53 | +- selected-monitor details panel |
| 54 | +- quick `Move Active Window` controls |
| 55 | +- buttons for `Center`, `Maximize`, `Restore`, and move-to-monitor |
| 56 | +- visual indicators for disconnected or changed monitors |
| 57 | +- a small topology refresh and diagnostics link |
| 58 | + |
| 59 | +Expected behavior: |
| 60 | + |
| 61 | +- Selecting a monitor highlights it in the topology and details panel. |
| 62 | +- Topology labels should remain stable when device names change. |
| 63 | +- Disconnected monitors should not disappear silently; they should show as unavailable when still referenced by rules or hotkeys. |
| 64 | +- The active window movement commands should be testable directly from this page. |
| 65 | + |
| 66 | +## Hotkeys Page |
| 67 | + |
| 68 | +The `Hotkeys` page should be a real editor, not just a list of current bindings. |
| 69 | + |
| 70 | +It should contain: |
| 71 | + |
| 72 | +- searchable action list |
| 73 | +- enabled toggle per action |
| 74 | +- hotkey text and recorder control |
| 75 | +- action type selector |
| 76 | +- placement selector |
| 77 | +- target monitor selector using topology names |
| 78 | +- verification toggle |
| 79 | +- conflict warning surface |
| 80 | +- `Test`, `Save`, `Delete`, and `New Action` |
| 81 | +- recent hotkey activity |
| 82 | + |
| 83 | +Expected behavior: |
| 84 | + |
| 85 | +- Recording a hotkey should show captured modifiers and key before saving. |
| 86 | +- Conflicts should be detected before save. |
| 87 | +- Testing a hotkey action should execute the same path as the runtime hotkey handler. |
| 88 | +- Failed test results should link to `Diagnostics`. |
| 89 | + |
| 90 | +## Layout Rules Page |
| 91 | + |
| 92 | +The `Layout Rules` page should support DisplayFusion-style window placement rules. |
| 93 | + |
| 94 | +It should contain: |
| 95 | + |
| 96 | +- rule table with priority, enabled state, match summary, action summary, and last matched time |
| 97 | +- `New Rule`, `Apply Rules`, and `Preview Matches` |
| 98 | +- import/export profile actions |
| 99 | +- rule builder for process name, window title, window class, and current monitor |
| 100 | +- action builder for target monitor, placement, restore/maximize behavior, and delay |
| 101 | +- apply-on-startup toggle |
| 102 | +- safe delete and duplicate actions |
| 103 | + |
| 104 | +Expected behavior: |
| 105 | + |
| 106 | +- `Preview Matches` should show which currently open windows match each rule. |
| 107 | +- `Apply Rules` should report moved, skipped, and failed windows. |
| 108 | +- Rule priority should be explicit and reorderable. |
| 109 | +- Rules should use stable monitor identity/topology, not fragile display numbers alone. |
| 110 | + |
| 111 | +## Diagnostics Page |
| 112 | + |
| 113 | +The `Diagnostics` page should make broken hotkeys and monitor issues explainable. |
| 114 | + |
| 115 | +It should contain: |
| 116 | + |
| 117 | +- runtime status strips for app, tray, hotkey hook, startup, profile validation, and monitor topology |
| 118 | +- `Diagnose Hotkey` recorder panel |
| 119 | +- last pressed hotkey, captured/not captured, foreground process, focused window, matched action, and failure reason |
| 120 | +- monitor probe section |
| 121 | +- recent events table |
| 122 | +- `Run Self-Test` |
| 123 | +- `Export Diagnostics` |
| 124 | +- `Copy Support Bundle` |
| 125 | + |
| 126 | +Expected behavior: |
| 127 | + |
| 128 | +- The page should distinguish "not captured" from "captured but no action matched". |
| 129 | +- Foreground-window filtering and elevated-window limitations should be visible. |
| 130 | +- Profile validation errors should link directly to the affected hotkey or rule. |
| 131 | +- Exported diagnostics should include profile, topology, recent events, and runtime status. |
| 132 | + |
| 133 | +## Startup Page |
| 134 | + |
| 135 | +The `Startup` page should collect lifecycle, tray, and profile behavior. |
| 136 | + |
| 137 | +It should contain: |
| 138 | + |
| 139 | +- `Start with Windows` |
| 140 | +- `Start minimized to tray` |
| 141 | +- `Enable hotkeys on launch` |
| 142 | +- `Apply layout rules on launch` |
| 143 | +- `Show tray flyout on click` |
| 144 | +- `Require confirmation before moving many windows` |
| 145 | +- active profile selector |
| 146 | +- import/export/reset profile actions |
| 147 | +- startup registration status |
| 148 | +- tray behavior preview |
| 149 | + |
| 150 | +Expected behavior: |
| 151 | + |
| 152 | +- Startup registration should show the exact mechanism and status. |
| 153 | +- Profile import should validate before replacing the active profile. |
| 154 | +- Reset should offer scoped reset options: hotkeys only, rules only, or full profile. |
| 155 | +- Settings that affect runtime behavior should apply immediately where possible. |
| 156 | + |
| 157 | +## Tray Flyout |
| 158 | + |
| 159 | +The tray should support two layers: |
| 160 | + |
| 161 | +- left click: compact flyout for fast use |
| 162 | +- right click: classic context menu fallback |
| 163 | + |
| 164 | +The flyout should contain: |
| 165 | + |
| 166 | +- status header: app running, hotkeys active/paused, active profile |
| 167 | +- miniature monitor topology map |
| 168 | +- quick `Move Active Window` buttons for each monitor |
| 169 | +- `Center`, `Maximize`, and `Restore` |
| 170 | +- `Apply Rules` |
| 171 | +- `Pause Hotkeys` / `Resume Hotkeys` |
| 172 | +- `Open DesktopManager` |
| 173 | +- `Diagnostics` |
| 174 | +- recent activity list |
| 175 | + |
| 176 | +Expected behavior: |
| 177 | + |
| 178 | +- Tray flyout commands should execute quickly and close only when appropriate. |
| 179 | +- The flyout should show clear failure feedback when the active window cannot be moved. |
| 180 | +- Right-click menu should keep reliable basics: open, pause/resume hotkeys, apply rules, reload profile, exit. |
| 181 | + |
| 182 | +## Implementation Phases |
| 183 | + |
| 184 | +### Phase 1: Structure |
| 185 | + |
| 186 | +- Introduce shell navigation and page separation. |
| 187 | +- Move current controls into `Monitors`, `Hotkeys`, `Layout Rules`, `Diagnostics`, and `Startup` views. |
| 188 | +- Keep behavior equivalent while improving layout. |
| 189 | + |
| 190 | +### Phase 2: Monitor Canvas |
| 191 | + |
| 192 | +- Build a topology canvas from current monitor topology data. |
| 193 | +- Add selectable monitor elements and topology labels. |
| 194 | +- Wire `Move Active Window` commands to selected monitor actions. |
| 195 | + |
| 196 | +### Phase 3: Editors |
| 197 | + |
| 198 | +- Replace ad-hoc editing with dedicated hotkey and rule editor components. |
| 199 | +- Add conflict detection and profile validation feedback. |
| 200 | +- Add rule preview and apply result summaries. |
| 201 | + |
| 202 | +### Phase 4: Tray Flyout |
| 203 | + |
| 204 | +- Add a real tray flyout window. |
| 205 | +- Keep the right-click menu as fallback. |
| 206 | +- Add quick movement, rule execution, and diagnostics commands. |
| 207 | + |
| 208 | +### Phase 5: Diagnostics |
| 209 | + |
| 210 | +- Expand hotkey diagnostics into a structured live panel. |
| 211 | +- Add support bundle export. |
| 212 | +- Add monitor identity/topology warnings and profile validation links. |
| 213 | + |
| 214 | +## Open Design Decisions |
| 215 | + |
| 216 | +- Whether the app should default to a dark, light, or system-following theme. |
| 217 | +- Whether topology labels should be user-overridable. |
| 218 | +- Whether rule priority should use drag-and-drop, up/down buttons, or both. |
| 219 | +- Whether profile import/export should remain JSON-only or include a friendlier package format later. |
| 220 | +- Whether tray flyout should pin open during multi-window placement sessions. |
0 commit comments