Toolbar menus look non-mac-like in dark mode

[driftwoodstudio]

Description

When an app is in ThemeMode.dark and a menu is shown over light content, it causes color changes that make it look very out of place (non-mac-standard).

Use case: apps like Apple's Pages, which can work in dark mode with a white canvas without producing this odd menu behavior.

Here is an example from Pages:

.
.

Here's an example from a flutter app using macos_ui ToolBarPullDownButton in dark mode with light content:

.
.

The macos_ui version is glaringly out of place as a Mac app behavior.

[Adrian-Samoticha]

This is what it looks like in Pages for me:

Admittedly much darker than in macos_ui, but still, it does have a transparency effect going on.

Considering that your status bar is opaque, you probably have the “Reduce transparency” setting enabled in your system.

It’d technically be possible for macos_ui to check if the “Reduce transparency” option is active, but considering that we’re still in the process of making macos_ui comply with macOS’ default look (and have been for some time, due to lack of free time to work on the project), it’s not really a priority right now.

[driftwoodstudio]

Ok. I'd at least like to try to make it more like your version then. That alone would be a huge improvement in terms of appearance. The whole reason I'm investigating macos_ui is to try to get my Mac version to appear/work more like a Mac native application. Things like this defeat the purpose. Would rather see the stuff that's there work well, vs broadening feature set.

I may be forking to make changes directly here. Also considering just pulling entirely and sticking to Cupertino as a solution instead.

I get the impression that even if I were to submit pull requests for changes, resources are such that the project's volunteers aren't really in a position to review those and issue rapid releases to incorporate things, given other work currently underway.

[Adrian-Samoticha]

PRs are always welcome, of course. Most of them do, in fact, get reviewed. Looking at the currently open PRs, with only one exception, each PR was reviewed and is currently awaiting a response from the author of the PR. The only exception is #504, likely because it requires a Windows and/or Linux install of Flutter to test it, as well as the fact that we officially only support macOS. I’ve also been meaning to investigate #477 myself, given that @Otacon seems to have moved on from it.

We also have a Discord in case you need a better means of communication with us (which might be helpful to check for discrepancies between your changes and native components and such), but you might need to ask @GroovinChip for an invitation.

New updates also immediately get released on pub.dev, with the latest version being exactly one month old as of today.

[driftwoodstudio]

Great. Thank you. I'm finishing a push towards a 1.0 release of my outliner program (replacement for OmniOutliner). I'm keeping a document of my personal "issues", and only logging here the ones that seem either (a) maybe easy to change, or (b) seems-serious-to-me.

Once I get a release done, I plan to work on trying to integrate changes I've made as pull requests here.

[driftwoodstudio]

Worked on this a bit, have some progress but there are implications beyond ToolBarPullDownButton that I need to trace down, as it requires changes in sub-widgets of that, which may be used elsewhere.

Thus not prepared to submit a pull request, but want to document the path to a solution in case someone else gets time to allocate to this.

First, to clear up a point of confusion:

The default Mac behavior (with Accessibility setting "Reduce Transparency" = OFF) doesn't, I think, actually have any transparency in the menu panel for dropdown toolbar menu buttons. There is a very subtle color gradient, but no actual transparency as shown in this example from Pages:

Using that as a guide, here's what I've managed to produce, using a sorta-similar example from my own app using a modified fork of macos_ui:

It's not perfect, there is some unwanted transparency to content behind, but it's a good deal closer than the default behavior (see first comment for image example). It's also I think workable as "at least not jarring" for users who have their Mac Accessibility "reduce transparency" setting On.

Second, the main remaining issue has less to do with the panel itself and more to do with the content. The text items that macos_ui produces are white (#FFFFFF) where the Mac produces "white" text in the menu panel as something more like light grey (#F0F0F0). You can see this in the Pages image, for instance, by comparing the "125%" text of the button label to the text items in the menu. The button label is white, the text in the menu is is grey-white.

That produces an effect in macos_ui of making the menu panel appear darker, as the text "pops" more when it's pure white.

That's not easily fixable, though, as the ToolBarPullDownButton doesn't have any parameters for a dev to specify menu text color. That will require surgery on the macos_ui components themselves (as I did with the panel).

What I did:

(documenting to help anyone who wants to work on this, or for myself in case I forget what I did)

_MacosPulldownMenuState.build( )

Change 1:

Change this:

    return 
    FadeTransition(
      opacity: _fadeOpacity,
      child: 
      Semantics(
        scopesRoute: true,
        namesRoute: true,
        explicitChildNodes: true,
        child: IntrinsicWidth(
          child: MacosOverlayFilter(
            color: MacosPulldownButtonTheme.of(context)
                .pulldownColor
                ?.withValues(alpha: 0.25),
            borderRadius: _kBorderRadius,
            child: Padding(
              padding: const EdgeInsets.all(8.0),
              child: Column(
                mainAxisSize: MainAxisSize.min,
                crossAxisAlignment: CrossAxisAlignment.stretch,
                children: children,
              ),

To this:

    // Temporary override of MacosPulldownButtonTheme.pulldownColor
    final c = Color.fromARGB(255, 80, 80, 80);  //   <--  CHANGE

    return 
    FadeTransition(
      opacity: _fadeOpacity,
      child: 
      Semantics(
        scopesRoute: true,
        namesRoute: true,
        explicitChildNodes: true,
        child: IntrinsicWidth(
          child: MacosOverlayFilter(
            color: c.withValues(alpha: 0.95),    //   <--  CHANGE, color + alpha
            borderRadius: _kBorderRadius,
            child: Padding(
              padding: const EdgeInsets.all(8.0),
              child: Column(
                mainAxisSize: MainAxisSize.min,
                crossAxisAlignment: CrossAxisAlignment.stretch,
                children: children,
              ),

Change 2:

MacosOverlayFilter.build( )

Change this:

    return WallpaperTintingOverride(
      child: Container(
        decoration: BoxDecoration(  /*omitted*/  ),
        child: ClipRRect(
          borderRadius: borderRadius,
          child: BackdropFilter(
            filter: ImageFilter.blur(
              sigmaX: 20.0,
              sigmaY: 20.0,
            ),
            child: child,
          ),

To this:

    return WallpaperTintingOverride(
      child: Container(
        decoration: BoxDecoration(  /*omitted*/  ),
        child: ClipRRect(
          borderRadius: borderRadius,
          // ... Delete BackdropFilter here...      <-- CHANGE
          child: child,
        ),

--

Obviously the above changes have implications, as things like MacosOverlayFilter are used in more than this specific item, so can't just be modified like this willy-nilly. Will need to make a replacement/alternate, or parameterization, so that ToolBarPullDownButton can have this change without it pushing into other components as well.

Obviously that the default MacosPulldownButtonTheme.pulldownColor has a color so unsuited to use in this context is a whole-other issue. The default reduction of that darker color to an alpha of 0.25 is... workable? ... but obviously brings in so much transparency that it's effectively unusable. But changing the color, as I did, means it affects everything that uses MacosPulldownButtonTheme so... implications need to be considered.

[Adrian-Samoticha]

First, to clear up a point of confusion:

The default Mac behavior (with Accessibility setting "Reduce Transparency" = OFF) doesn't, I think, actually have any transparency in the menu panel for dropdown toolbar menu buttons. There is a very subtle color gradient, but no actual transparency as shown in this example from Pages:

The subtle gradient is very much caused by the transparency effect. Here’s a screenshot from Keynote that shows this quite well:

I think what’s necessary is for the dropdown menu to have color and alpha values that closely match those of the native UI, as well as (perhaps) a blur effect with a larger radius?

Plus, macOS uses shadows that aren’t actually visible underneath the shadow-casting UI elements. In Flutter, you can achieve the same effect using BlurStyle.outer, but you won’t be able to offset the shadow if you do that (because doing so also offsets the “cutout,” which doesn’t happen on macOS). In my experience, the lack of an offset may be less noticeable than the shadow being visible underneath the widget (thus making it appear darker than it actually is).

[driftwoodstudio]

Ok, I you're ight about the transparency.

But given the actual current appearance of what macos_ui does vs the examples you're posting here, I'm a little surprised that this is even an issue. I frankly wouldn't (and won't) ship an app with my name on it that has the current macos_ui appearance for this.

If the goal is "it's not acceptable unless it does it exactly the same way in every detail that Mac OS actually uses, technically" then I have no idea how what's there now managed to ship.

As a developer who needs something that just looks acceptable in my app, I'm much less concerned about the technical details of how the shadows are implemented than about whether or not it even meets a minimum standard. In my opinion, the existing implementation does not meet the minimally-acceptable standard:

Given the discussion here, I'm discouraged and don't plan to keep working on this. "This is better" is clearly not going to be sufficient to work on a replacement and get it accepted, so I'll put this on hold and just worry about modifying my own fork.

Best of luck with the project. I'm getting a great deal of benefit from it.