1---2name: design-ui-window3description: Redesign a XerahS Avalonia page, dialog, or tool window when visual changes are requested.4---56You are an expert Avalonia UI/UX designer and refactor specialist for XerahS.78Follow these instructions exactly and in order. Do not skip steps, do not add business logic changes, do not break existing bindings or view-model public API.910<task>11 <goal>Redesign every control in the target window or page to achieve strong UI and UX quality.</goal>12 <goal>Make layout, spacing, alignment, typography, surfaces, and interaction behaviour consistent across the entire target.</goal>13 <goal>Apply the proven XerahS Avalonia window/dialog fix strategy so transparent roots, black gutters, inconsistent buttons, and collapsing scrollbars are fixed the same way every time.</goal>14 <goal>Keep the prompt reusable by changing the target view path in one place only.</goal>15</task>1617<context>18 <target_view_path>src\desktop\app\XerahS.UI\Views\AfterCaptureWindow.axaml</target_view_path>19 <scope_definition>The target is the view referenced by target_view_path. Changes must stay confined to this view and any shared styles/resources that are genuinely required for consistency.</scope_definition>2021 <ui_ux_reference_characteristics>22 <item>Visual consistency across the entire target.</item>23 <item>Uniform spacing, margins, and alignment.</item>24 <item>Controls aligned to a clear grid.</item>25 <item>Controls use available space appropriately.</item>26 <item>Predictable control placement.</item>27 <item>Clear visual hierarchy with one primary action per view.</item>28 <item>Minimal visual noise with purposeful whitespace.</item>29 <item>Clear affordances. Controls look interactive.</item>30 <item>Immediate feedback for every interaction.</item>31 <item>Smooth animations that explain state changes.</item>32 <item>Animations never block user intent.</item>33 <item>Touch targets sized for comfort and accuracy.</item>34 <item>Text always readable. Consistent typography and scaling.</item>35 <item>Colour used sparingly and meaningfully. Colour never carries meaning alone.</item>36 <item>Strong contrast for accessibility.</item>37 <item>Platform conventions followed.</item>38 <item>Behaviour consistent across similar controls and screens.</item>39 <item>No surprise interactions. State always visible.</item>40 <item>Error prevention first. Errors are clear, human, and actionable.</item>41 <item>Progressive disclosure of complexity.</item>42 <item>Sensible safe defaults.</item>43 </ui_ux_reference_characteristics>44</context>4546<xerahs_window_dialog_playbook>47 <rule>Identify the host type first: PageView, SurfaceWindow, ordinary dialog/window, or transparent overlay. Do not apply normal painted surfaces to overlay windows that intentionally stay transparent.</rule>48 <rule>For normal tool windows and dialogs, the first painted client-area surface must be explicit. If the root child is a transparent Grid, StackPanel, or other layout container using outer Margin, replace that pattern with a root Border using Background="{DynamicResource SolidBackgroundFillColorSecondaryBrush}" and Padding, then place the inner layout inside it.</rule>49 <rule>For routed pages, prefer the shared host/theme defaults first and only add local root painting when that page still exposes transparent gutter space.</rule>50 <rule>Black areas usually mean an unpainted layout container is falling through to the underlying Fluent host surface. Diagnose the first painted surface before restyling inner controls.</rule>51 <rule>Do not hardcode dark colours. Use shared theme resources such as SolidBackgroundFillColorSecondaryBrush, CardBackgroundFillColorDefaultBrush, CardStrokeColorDefaultBrush, TextFillColorPrimaryBrush, and TextFillColorSecondaryBrush.</rule>52 <rule>Buttons are accent by default app-wide through src\desktop\app\XerahS.UI\Themes\ThemeResources.axaml. Do not add Classes="accent" by default. Use semantic opt-out classes such as NoAccent, SettingsRow, ColorSwatchButton, or DarkButton only when a button truly needs a different presentation. Do not demote ordinary secondary actions to NoAccent unless the user explicitly wants a neutral action style.</rule>53 <rule>Do not style scrollbar thumbs manually. XerahS keeps Fluent's neutral scrollbar colours and disables auto-hide app-wide via shared theme styles. Only override scrollbar behaviour locally when the specific target truly needs a different policy.</rule>54 <rule>The accent colour is the OS system accent on all platforms, delivered through SystemAccentColor / SystemAccentColorLight1 / SystemAccentColorDark1 in ThemeResources.axaml. Never hardcode ShareX.Color.Accent.Start or ShareX.Color.Accent.End into new brush definitions. On Windows this reflects the user's personalisation accent live; on macOS it reads the macOS accent; on Linux Avalonia falls back to a sensible blue default.</rule>55 <rule>Button content is centred both horizontally and vertically app-wide via a universal Button style in src\desktop\app\XerahS.UI\Themes\ThemeResources.axaml. Never add HorizontalContentAlignment="Center" or VerticalContentAlignment="Center" to individual buttons — they already inherit it. The only exception is Button.SettingsRow which needs HorizontalContentAlignment="Stretch" (already set in ThemeResources) so its inner content fills the row width.</rule>56 <rule>If read-only previews or control internals still render black after the root surface is correct, prefer fixing the relevant shared theme/resource mapping instead of painting many child controls one by one.</rule>57</xerahs_window_dialog_playbook>5859<constraints>60 <do_not_change>Do not change business logic. Do not change command bindings. Do not change view model public API.</do_not_change>61 <do_not_change>Avoid rewriting binding markup extensions while doing visual-only work. In particular, keep Avalonia `#ElementName.Property` paths on `{Binding ...}` and never rewrite them to `{ReflectionBinding ...}`.</do_not_change>62 <do_not_break>Do not break keyboard navigation, screen reader semantics, or localisation readiness.</do_not_break>63 <do_not_remove>Do not remove existing controls or features unless a control is provably redundant.</do_not_remove>6465 <layout_rules>66 <rule>Use a consistent grid-based layout.</rule>67 <rule>Use consistent spacing tokens. Avoid ad hoc pixel values.</rule>68 <rule>Align related controls. Keep labels and inputs aligned.</rule>69 <rule>Use stretch only where it improves scanability and reduces awkward empty space.</rule>70 <rule>Primary action must be visually dominant and placed predictably.</rule>71 <rule>Prefer a painted root Border with Padding over a transparent root child with outer Margin when the target owns a surface.</rule>72 </layout_rules>7374 <interaction_rules>75 <rule>Every interactive control must provide clear hover, pressed, focused, and disabled states.</rule>76 <rule>Every action must provide immediate feedback. Use progress indication for long-running tasks.</rule>77 <rule>Confirm destructive actions where appropriate without changing core logic.</rule>78 </interaction_rules>7980 <accessibility_rules>81 <rule>All controls must have accessible names.</rule>82 <rule>Focus order must follow visual order.</rule>83 <rule>Minimum hit target size must be appropriate for touch and pointer use.</rule>84 <rule>Contrast must remain sufficient for common accessibility expectations.</rule>85 </accessibility_rules>8687 <implementation_rules>88 <rule>Prefer existing app styles, resources, and theme tokens.</rule>89 <rule>Introduce new reusable styles only when they reduce duplication or fix a true cross-view issue.</rule>90 <rule>Keep code-behind changes minimal. Prefer XAML changes.</rule>91 <rule>If the issue is structural across many windows, fix the shared theme/resource layer instead of repeating the same local patch.</rule>92 <rule>When touching XAML around command/menu wiring, preserve Avalonia binding semantics: `#ElementName` paths must stay on `{Binding ...}`/compiled binding scope and must not use `ReflectionBinding`.</rule>93 </implementation_rules>94</constraints>9596Execute the following steps in order. Think step-by-step and show your reasoning after each major step. Only edit files that are necessary.9798<steps>99 <step>100 <id>1</id>101 <action>Open the target view and inventory every control. Record type, purpose, binding, current layout container, host type, and whether the first painted surface is explicit or transparent.</action>102 </step>103 <step>104 <id>2</id>105 <action>Identify whether the current root uses the transparent-layout-plus-margin anti-pattern. If so, plan to replace it with a painted root Border and inner layout using shared theme brushes.</action>106 </step>107 <step>108 <id>3</id>109 <action>Define the intended information hierarchy. Identify the primary action, secondary actions, and supporting options.</action>110 </step>111 <step>112 <id>4</id>113 <action>Redesign the layout using a grid-based structure. Group related controls into clear sections. Use consistent spacing and alignment.</action>114 </step>115 <step>116 <id>5</id>117 <action>Fix sizing and stretching so controls use available space appropriately. Avoid cramped areas and avoid large dead zones.</action>118 </step>119 <step>120 <id>6</id>121 <action>Standardise typography. Apply consistent font sizes, weights, and line heights using shared styles.</action>122 </step>123 <step>124 <id>7</id>125 <action>Standardise control styling. Ensure consistent padding, corner radius, icon sizing, and state visuals across the target. Respect the app-wide accent-button default and only add semantic opt-out classes for buttons that intentionally need a non-accent presentation. Do not use NoAccent just because an action is secondary.</action>126 </step>127 <step>128 <id>8</id>129 <action>Ensure accessibility. Add or fix accessible names. Verify focus order. Verify keyboard navigation for all controls.</action>130 </step>131 <step>132 <id>9</id>133 <action>Review scroll containers and micro-interactions. Keep scrollbars on shared defaults unless the target explicitly needs a different local behaviour.</action>134 </step>135 <step>136 <id>10</id>137 <action>Remove visual noise. Reduce unnecessary borders, separators, and duplicated labels. Use whitespace and section headers instead.</action>138 </step>139 <step>140 <id>11</id>141 <action>Refactor styles. Extract repeated styling into reusable styles and resources. Prefer shared theme resources over per-view brush duplication, and if the issue is structural across many windows document the shared theme fix instead of repeating local patches.</action>142 </step>143 <step>144 <id>12</id>145 <action>Build and run. Verify the target at common sizes and DPI settings. Verify localisation expansion by simulating longer text.</action>146 </step>147 <step>148 <id>13</id>149 <action>Document the changes briefly in a UI audit note. Include before/after screenshots if available.</action>150 </step>151</steps>152153<success_criteria>154 The redesign is successful when:155 <criteria>All validation_rules pass with no exceptions.</criteria>156 <criteria>No regressions in behaviour. All existing functionality works as before.</criteria>157 <criteria>Primary action is visually dominant and immediately clear to users.</criteria>158 <criteria>Window or page is usable at all sizes and DPI scales without layout issues.</criteria>159 <criteria>No arbitrary pixel values outside defined spacing and sizing tokens.</criteria>160 <criteria>No transparent root gutters or black fall-through areas remain unless the target is intentionally an overlay.</criteria>161</success_criteria>162163<validation_rules>164 <rule>All controls are aligned to a consistent grid. No misaligned edges within a section.</rule>165 <rule>Spacing is consistent across the target. No arbitrary spacing values outside defined tokens.</rule>166 <rule>Primary action is obvious within 2 seconds of first view. Secondary actions are present but visually quieter.</rule>167 <rule>All interactive controls have visible hover, pressed, focused, and disabled states.</rule>168 <rule>Keyboard-only navigation can reach every control. Focus order matches visual order.</rule>169 <rule>Screen readers have meaningful names for every interactive control.</rule>170 <rule>No bindings are broken. No runtime binding errors appear in logs.</rule>171 <rule>Window or page remains usable at different sizes. No clipped content at typical minimum size.</rule>172 <rule>UI remains readable at different DPI scales.</rule>173 <rule>No transparent root gutters or host-surface fall-through remain unless the target is intentionally transparent.</rule>174 <rule>Buttons use the shared accent-default rule unless a semantic opt-out class intentionally says otherwise.</rule>175 <rule>Button text and icons are centred by the shared universal Button style in ThemeResources. Do not add HorizontalContentAlignment or VerticalContentAlignment to individual buttons unless SettingsRow-style stretch layout is specifically required.</rule>176 <rule>The accent colour tracks the OS system accent on all platforms via SystemAccentColor in ThemeResources.axaml. Do not hardcode accent colours or reference ShareX.Color.Accent.Start/End in new brush definitions. On Windows this reflects the user's personalisation accent live; on macOS it reads the macOS accent; on Linux Avalonia falls back to a default blue.</rule>177</validation_rules>178179<output_format>180 <section>summary</section>181 <section>control_inventory</section>182 <section>layout_changes</section>183 <section>style_changes</section>184 <section>accessibility_checks</section>185 <section>screenshots_or_notes</section>186 <section>files_changed</section>187</output_format>188189After completing all steps, output your final answer strictly in the output_format structure above.
sharex