Migration to flutter_acrylic/macos_window_utils and breaking change

[Adrian-Samoticha]

Hello,

I have recently stumbled upon issue #315 and decided to try and address it. Here's the result so far:

Screen.Recording.2022-11-27.at.15.09.08.mov

I did this by making certain backgrounds transparent (plus setting their background blend mode to clear) and using flutter_acrylic to add multiple NSVisualEffectViews to the window (full disclosure; I am the maintainer of the macOS port of flutter_acrylic).

Migrating to flutter_acrylic also has other benefits. For instance, a visual (and performance-related) bug that was present in the original version is now resolved:

This is what it looks like when a window using macos_ui is minimized with Stage Manager enabled:

Screen.Recording.2022-11-27.at.15.50.55.mov

As you can see, the shadow goes missing during the animation and the animation is quite laggy.

This is what it looks like after the migration to flutter_acrylic:

Screen.Recording.2022-11-27.at.15.51.12.mov

The shadow stays and the animation is silky smooth.

Yet another benefit is that the window's brightness can be changed independently of the system theme. That means the sidebar can remain transparent even when the window brightness differs from the system's brightness setting:

Screen.Recording.2022-11-27.at.15.58.19.mov

However, there are two catches. For one, support for adding Visual Effect Subviews in flutter_acrylic is relatively new and has (as far as I am aware) not yet been published to pub.dev, which makes it impossible to publish packages that depend on that functionality. If we were to depend on it, we would have to wait for it to be published first.

Additionally, it would be necessary to introduce breaking changes to macos_ui (which would be necessary to address #315 either way, even if it was done without depending on flutter_acrylic). This is the main reason why I am starting this discussion.
Is it okay to introduce breaking changes? Are there any issues that should be addressed before tackling those that require breaking changes? I would, of course, be happy to give them precedence, in case such issues exist.

Cheers, Adrian.

[Adrian-Samoticha]

I am currently in the process of migrating flutter_acrylic's macOS-related functionality into a new package called macos_window_utils. Therefore, if I were to do this, I would migrate to that, instead. Also, macos_window_utils is already on pub.dev, so no need to wait in that case.

[GroovinChip]

Hi, @Adrian-Samoticha! Thank you for starting this discussion and for your excellent work on this issue so far.

It is certainly okay to introduce breaking changes to macos_ui if they are of substantial benefit, which I'd say this brings.

A question, if you don't mind: I noticed that in the gifs you provided of your work that the Toolbar color seems off. Can your improvements be applied there?

[Adrian-Samoticha]

Regarding the backdrop filter issue, there's an open Flutter issue that addresses this (it proposes the support for custom image filters), however, it has P4 priority, so it's unclear when this will be addressed by the Flutter team. I guess I will need to resort to placing opaque containers underneath all widgets instead and hope the lack of wallpaper tinting underneath context menus isn't too noticeable, at least until that issue is resolved.

[boyan01]

so I guess the only way to achieve that would be to add macos_window_utils' functionality into desktop_multi_window.

Maybe there is an other way, we can use the callback to modify the NSWindow which created by dekstop_multi_window. for example: FlutterMultiWindowPlugin.setOnWindowCreatedCallback

And in fact now we can get a FlutterViewController by FlutterMultiWindowPlugin.setOnWindowCreatedCallback. So, is it possible to use this flutterViewController directly to achieve the desired effect? If not, it sounds OK to me for adding another window created callback in desktop_multi_window.

[Adrian-Samoticha]

Maybe there is an other way, we can use the callback to modify the NSWindow which created by dekstop_multi_window. for example: FlutterMultiWindowPlugin.setOnWindowCreatedCallback

Seems you're right! I was able to replace the FlutterViewController with a MacOSWindowUtilsViewController (while keeping its window) and after feeding it into the MainFlutterWindowManipulator I could do this:

Of course, macos_window_utils wasn't made with the assumption that there could be multiple windows. As a result, MainFlutterWindowManipulator is working with static class members and the platform channel assumes there is only one window. However, those issues should be fixable in macos_window_utils without a PR to desktop_multi_window.

That said, I am unsure as to how I should address the windows in macos_window_utils. Is there a way to get the ID of the newly created windows inside the Swift callback? Can I retrieve that ID from within Dart as well? I have found a getAllSubWindowIds method, but none that gets the ID of the window I am calling this method from.

[Adrian-Samoticha]

Alright, status update time. I have attempted to place a non-tinted background underneath all widgets below the context menus, but the fact that I used BlendMode.src for the wallpaper-tinted areas made this approach impossible. I have also attempted to draw the backgrounds using BlendMode.dstOver, however, I am probably hitting a RepaintBoundary somewhere, so that didn't work, either.

I ultimately resorted to just disabling wallpaper tinting whenever a MacosOverlayFilter is present in the widget tree, which looks like this:

Screen.Recording.2023-02-14.at.12.46.38.mov

The difference is quite noticeable, however, this appears to be in part due to the fact that the window's background color doesn't match macOS' windowBackgroundColor. This is what the window looks like with wallpaper tinting disabled:

The titlebar still isn't tinted and is therefore using macos_ui's background color, while the content area is using windowBackgroundColor. I have included macOS' System Settings window for reference and as you can see, even without wallpaper tinting it is much lighter than the titlebar.

The same difference can be observed in light mode as well. macos_ui's background is considerably lighter than the default window background in macOS.

This leads me to my question. Should I attempt to change the default background color in macos_ui so that it matches windowBackgroundColor? This would both make macos_ui more accurate and make the disabling of the wallpaper tinting less noticeable.

[GroovinChip]

@Adrian-Samoticha Sorry for the late reply. To answer your question, yeah, I think you should experiment with setting the default background color to match the windowBackgroundColor and see what happens.