FlyoutShowOptions

[pr8x]

Would be nice to port UWPs FlyoutShowOptions that allows to control exact position where the flyout opens.

[amwx]

FWIW I didn't include FlyoutShowOptions with the Flyout PR because the Popup positioning API isn't robust enough to handle what's needed. And I think Wayland makes this harder since it has a more limited windowing API such that "open at <x, y>" may not be possible (at least that's what I've gathered, but I'm not all that familiar with Wayland). If so, maybe we could make them hints and just support them where possible?

• ExclusionRect is probably trivial to implement provided the flyout content is measured, but requires the position the underlying window is opened (overlay popups can do this now by looking at the Bounds position of the OverlayPopupHost)

• Position - (see above)

• ShowMode and Placement I don't really see the value of including here as they're already properties on FlyoutBase

[maxkatz6]

There was idea to do the opposite - and remove current flyout placement property (or deprecate it) and introduce flexible Popup properties instead - including offsets and anchor.

[robloo]

There was idea to do the opposite - and remove current flyout placement property (or deprecate it) and introduce flexible Popup properties instead

If the Popup positioning properties could still be set on the Flyout as attached properties I guess I would be OK with it. My instinct would be to include the same properties in both Flyout and Popup though for simplicity. Popup long term really should be more of a primitive and not used directly in apps too.

[amwx]

There was idea to do the opposite - and remove current flyout placement property (or deprecate it) and introduce flexible Popup properties instead - including offsets and anchor.

I'd be against that. Flyouts are really meant as a convenience wrapper around popups (over-simplification), with FlyoutPlacementMode allowing a quick way to get the popup to show at common places relative to its target. I certainly don't want to have to "experiment" with the different anchor and gravity settings and hope I get it right - rather just set BottomEdgeAlignedRight (or whatever) and be done. I don't know where the anchor/gravity stuff came from, but it doesn't exist in the microsoft ecosystem (at least I've never seen it) and I remember the trial and error I had building the flyout behavior.

Extending the current API may be appropriate, though. Offsets I could see being potentially useful and maybe the ConstraintAdjustment. But honestly, FlyoutPlacementMode really covers a lot of cases, how often do you need even more control over that other than showing a specific point on screen/the cursor (this probably should be addressed, if possible) - and if you do, you're probably building a custom control where you probably should use a popup with maximum control.

Also, WinUI extended their Popup to include DesiredPlacement and ActualPlacement properties, of type PopupPlacementMode, and those enum values are the same as FlyoutPlacementMode. So these new enum values should not be removed, if anything add them to Popup to bring parity between the two.

[maxkatz6]

Flyouts are really meant as a convenience wrapper around popups (over-simplification)

But unfortunately, with current Flyout it's not possible to set Offset property at minimum. That's the biggest point of inflexibility of this control. Other popup properties...not so sure.

but it doesn't exist in the microsoft ecosystem (at least I've never seen it)

That's Wayland-like API

how often do you need even more control over that other than showing a specific point on screen/the cursor (this probably should be addressed, if possible) - and if you do, you're probably building a custom control where you probably should use a popup with maximum control.

The simplest example - add flyout to the button with Placement=Bottom, but move it slightly by 4px down adding a padding. Sounds like a typical designing task, but harder to achieve with flyouts.

[maxkatz6]

These changes should be discussed together with another issue - #9583 , @kekekeks.
Possibly adding attached properties is the nicest option.

Also, I had an idea of extending Flyout to support native menus. So, developers could easily set NativeMenuFlyout instance on the Button.Flyout for example. This feature would also require moving some APIs between FlyoutBase and TemplatedFlyoutBase. But I stopped (at least for 11.0) as there are no much flexibility with platform specific APIs. #8581