You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recolour SVG icons for light/dark and disabled states, including submenu items.
Add classic and Mica resources, focused tests, and separate Windows visual baselines; document deferred solid-backdrop validation.
Validation
WinUI theme builds successfully.
15 focused MenuFlyout/Mica unit tests pass.
Classic and Mica MenuFlyout visual regression cases pass separately.
Reviewer notes
WinUIMica is marked complete; WinUIClassic is marked needs validation against the native solid-backdrop/acrylic fallback. The SampleApp startup selection remains local and is not included in this PR. Posted by Copilot SDK in VS Code (agent), on behalf of Anna Malchow-Perryman (@apman).
Style MenuFlyout surfaces, items, submenus, SVG icons, and entrance motion for WinUI classic and Mica. Add focused behavior tests and separate Windows baselines; document pending classic validation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…adding
The main flyout surface hard-coded Padding="0,2" while the submenu
surface bound to the MenuFlyoutPresenterThemePadding dynamic resource.
Overriding that resource therefore only affected submenus, causing the
two surfaces to diverge. Bind both to the same resource.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The outer presenter surface does not bind MaxWidth or MinHeight (unlike the submenu surface below at lines 126-127), so the inherited FlyoutThemeMaxWidth/MenuFlyoutThemeMinHeight constraints are ignored for top-level flyouts. Long menus can grow past the intended width, and short presenters do not receive the minimum height; bind these properties on LayoutRoot as well.
…surface
The outer flyout surface (LayoutRoot) did not bind MaxWidth/MinHeight, unlike
the submenu surface, so the inherited FlyoutThemeMaxWidth/MenuFlyoutThemeMinHeight
constraints were not applied to top-level flyouts (confirmed via a headless test:
the border''s MaxWidth read back as Infinity). Bind both on LayoutRoot and add
regression assertions to the existing shadow/padding/chevron test.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addressed the "previously missed" finding from the latest review (Bind MaxWidth and MinHeight on the outer flyout presenter, src/Devolutions.AvaloniaTheme.WinUI/Controls/MenuFlyout.axaml:29).
Fixed in 3acd95e: the outer MenuFlyoutPresenter's LayoutRoot border now also binds MaxWidth="{DynamicResource FlyoutThemeMaxWidth}" and MinHeight="{DynamicResource MenuFlyoutThemeMinHeight}", matching the submenu surface. I verified with a headless test that the border's MaxWidth previously read back as Infinity (the base theme's inherited setter for that property is not applied once the derived ControlTheme overrides the Template), and now correctly resolves to 456/32. Added regression assertions for both properties (on the outer surface and the submenu surface) to the existing Flyout_and_submenu_have_shadow_padding_and_small_chevron test; all 316 tests in the project pass.
…w through
Padding/MaxWidth/MinHeight were bound directly to theme resources on the
LayoutRoot border, bypassing the presenter''s own properties: a consumer
overriding MenuFlyoutPresenter.Padding/MaxWidth/MinHeight (per-instance or via
a style) was silently ignored by the rendered surface. Add ControlTheme
Setters with the resource-backed defaults and bind the template to those
properties via TemplateBinding instead, matching the established pattern in
the Linux theme''s MenuFlyoutPresenter. Added a regression test asserting
instance-level overrides reach the rendered border.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This adds an implicit {x:Type Separator} theme to the WinUI theme, so every Separator in the consuming scope—including ordinary panels and SeparatorDemo—will receive MenuFlyout's 1px height and 12,4 margin. The repository explicitly guards against this pattern because menu separator styling must be scoped to menu descendants (tests/Devolutions.AvaloniaControls.Tests/MenuPackContractTests.cs:597-650). Use a selector style scoped to MenuFlyoutPresenter/nested MenuItem descendants instead.
The implicit `{x:Type Separator}` ControlTheme in MenuFlyout.axaml restyled
every Separator in the consuming app (e.g. SampleApp''s standalone
SeparatorDemo, which the page catalog marks as not yet supported by WinUI),
not just the ones inside menus, mirroring a regression the Linux/macOS/
DevExpress themes already guard against (MenuPackContractTests.cs).
Move the separator styling into a new scoped Controls/MenuFlyoutSeparator.
styles.axaml using a descendant selector (ContextMenu/MenuFlyoutPresenter/
Menu/MenuItem Separator), matching the sibling themes'' convention, and merge
it via StyleInclude in ThemeRoot.axaml. Added a regression test asserting a
standalone Separator keeps its Fluent-default Background while one inside a
MenuFlyoutPresenter gets the WinUI value.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addressed the "previously missed" finding from the latest review (Scope menu separator styling to MenuFlyout descendants, src/Devolutions.AvaloniaTheme.WinUI/Controls/MenuFlyout.axaml:153).
Fixed in f208be7: removed the implicit {x:Type Separator} ControlTheme (which restyled every Separator in the consuming app, not just menu ones) and moved the styling into a new Controls/MenuFlyoutSeparator.styles.axaml using a descendant selector (ContextMenu Separator, MenuFlyoutPresenter Separator, Menu Separator, MenuItem Separator), merged via StyleInclude in ThemeRoot.axaml. This matches the convention already established by the Linux/macOS/DevExpress themes' own Separator.styles.axaml and the regression guard in MenuPackContractTests.cs. Added a test (Separator_styling_is_scoped_to_menu_descendants) asserting a standalone Separator keeps Fluent's default Background while one inside a MenuFlyoutPresenter gets the WinUI value. Full test suite (318 tests) passes. Posted by Copilot SDK in VS Code (agent), on behalf of Anna Malchow-Perryman (@apman).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation
Reviewer notes
Posted by Copilot SDK in VS Code (agent), on behalf of Anna Malchow-Perryman (@apman).