[RFC] Add Window.CanMinimize/CanMaximize

[MrJul]

What does the pull request do?

This PR adds two new properties to Window to enable or disable the minimize (CanMinimize) and maximize (CanMaximize) buttons of a window.

They're implemented on all three desktop platforms: Windows, macOS and X11.

Notes

General

• Both properties are true by default.
• CanMaximize is automatically coerced to false when CanResize is false.
• Even if CanMaximize is false, the restore button stays enabled if the window is somehow already maximized (and is resizable).

Both Qt and Wine have been used as reference implementations for X11 and macOS.

Windows

On Windows, the two properties work exactly as one would expect. They map to the WS_MINIMIZEBOX and WS_MAXIMIZEBOX window styles.

Linux

On X11, the two properties are effectively hints (_MOTIF_WM_HINTS).
Maybe we should prefer names such as CanMinimizeHint and CanMaximizeHint?

In my tests, GNOME respects them, and while the buttons aren't visually disabled (at least on Ubuntu 24.04 with the default theme), they aren't clickable.

KDE (KWin) completely ignores them.

macOS

CanMinimize disables the minimize button, as expected.

CanMaximize disables both the zoom/maximize gesture (titlebar double click) and the green full screen button.
I went this route because I believe that's what most users would expect: that each property effectively corresponds to one traffic light button. Plus, clicking the green button with ⌥ pressed effectively zooms so the two behaviors aren't easily dissociated.

If that isn't acceptable, we could easily split that into CanMaximize and CanSwitchToFullScreen (naming TBD).

New API

namespace Avalonia.Controls
{
    public class Window
    {
        public static readonly StyledProperty<bool> CanMinimizeProperty;
        public static readonly StyledProperty<bool> CanMaximizeProperty;
        public bool CanMinimize { get; set; }
        public bool CanMaximize { get; set; }
    }
}

Fixed issues

• Fixes Add support to hide Minimize / Maximize window buttons #3422

[avaloniaui-bot]

You can test this PR using the following package version. 11.3.999-cibuild0054759-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[rabbitism]

Is the linked issue really resolved? CaptionButtons are still visible.

[MrJul]

Is the linked issue really resolved? CaptionButtons are still visible.

We're just supporting what the various platforms are exposing here.

On Windows, if Maximize and Minimize are both disabled, the system automatically hides both buttons.
On macOS, the traffic lights are kept, but disabled (see the "about this mac" system window).
On Linux, it totally depends on the window manager and its configuration.

To do more, it's always possible for users to use a custom chrome.

[maxkatz6]

I know it's annoying, but we need integration tests for win/mac :)

[MrJul]

I completely agree that we need more tests overall!
However, in this case, I don't really see a good way to test this with the current infrastructure.

Should we find the position of the maximize/minimize buttons and try to click them? (Can we even access the non-client area buttons via Appium?) Did you have another approach in mind?

[maxkatz6]

I wrote these extension methods before for window-decoration tests: https://github.com/AvaloniaUI/Avalonia/blob/master/tests/Avalonia.IntegrationTests.Appium/ElementExtensions.cs#L40

It might be enough to check enabled/visible state of these elements via appium apis.

[maxkatz6]

GetSystemChromeButtons for system titlebar. And GetClientChromeButtons for client titlebar (which also is properly recognized as an accessible titlebar, at least on windows).

[MrJul]

Thanks for the pointers! I really need to familiarize myself with the integration tests infrastructure.

[avaloniaui-bot]

You can test this PR using the following package version. 11.3.999-cibuild0054781-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[thevortexcloud]

I think hint in the name makes more sense and follows the existing pattern of things that may or may not work.

[robloo]

Couple thoughts:

1. Have you considered a higher level of abstraction like with WPF? WPF has the WindowStyle enum to control this. It might help here in some cases:
   • Do we really need to support maximize but not minimize? Usually a window is resisable or it is not.
   • A WindowStyle could have a value such as NotResizeable. On windows that would remove the minimize/maximize buttons completely but on macOS would just disable them. So this generic naming doesn't imply how the actual buttons are shown which allows the platforms to handle it natively.
2. For some reason I'm not a fan of "Hint" in this context. But I also agree it is more of a "Hint" on the platforms such as Linux that don't support all cases. I guess my justification is the main platforms support these properties just fine so its a shame to use less-than-ideal naming just because of limitations of a minor platform.