Option to allow the menu bar icon to indicate when the auto clicker is running

[AnonymousAlt0]

Description

I want to be able to double-check if the auto clicker is running at a glance. Right now I have to click the menu bar icon to check it is running.

Desired Behavior

Display a different icon (suggestions welcome) when the auto click is running. Perhaps a green play button.

This could be an option in preferences that would be defaulted to being disabled.

Additional Context

I could have a look at this over the weekend, I just want to check whether it would be accepted if I make the pull request.

[othyn]

Really like this idea - happy to accept PR's!

[othyn]

I've spent this evening trying to find out how to reset the status bar colour back to the system default for the current colour scheme and/or background wallpaper. This as on your PR, its just set to Color.white for the icon regardless of the system theme, which breaks on Light mode/Light wallpaper scenarios. In typical Apple docs fashion, this just doesn't appear to be a thing, so I have no idea how we can actually reset or follow the system.

If we just create and use a new instance of SymbolConfiguration(), it defaults to blue.

I've also had a look through the code, and there appears to be no way to simply retain or read the existing configuration colour. We could re-apply it, but then we need to persist and store it. This appears to be the simplest method for now, there is no documentation on this what-so-ever.

The only other way would be something manual like this: https://stackoverflow.com/a/66984289/4494375

static func resetImage() {
    if let statusBarButton = self.statusBarItem!.button {
        statusBarButton.image = NSImage(systemSymbolName: "cursorarrow.click.badge.clock", accessibilityDescription: "auto clicker")
    }
}

This is still not perfect. On Dark mode/Dark triggering wallpapers, Color.primary resolves to the correct dark colour. However, on Light mode/Light triggering wallpapers, Color.primary resolves to the incorrect light colour that is a dullish grey.

The issue is, on Dark/Light mode the wallpaper will trigger an override to the default colour, so doing an AppleInterfaceStyle check does nothing, as one display could be using light mode and the other using dark making a check useless.

I feel although I'm missing something, but between hours scouring documentation, search engines and ChatGPT, nothing is coming up.

---

I'm going to try and migrate from the old NSMenu setup to the new SwiftUI MenuBarExtra setup now its more established, as this looks to solve a lot of the issues.

Let's see how this goes!

[will09122000]

I didn’t even realise the default colour was anything other than white, I guess that’s something to do with my wallpaper. Thanks for looking into it, and sorry for sending you down this rabbit hole 😄

[othyn]

This is actually insane haha who would have thought that a simple colour change could drive such a massive chain of issues.

The key blockers on using MenuBarExtra as it stands is that for some reason when the scene becomes active for MenuBarExtra it hangs the WindowGroup scene, meaning the app stops functioning whilst the menu is open.

MenuBarExtra also appears to not respond to any state changes, such as updating Button states, Button text or Shortcuts.

I've also discovered and logged a state bug due to this in an upstream dependency, which I'll leave here for future reference:

https://github.com/sindresorhus/Defaults/issues/144

There is a proof of concept / prototype branch for this, but I think I'll just have to restore some earlier fixes for this, which annoyingly I didn't check in before I started the MenuBarExtra migration... 🤦

https://github.com/othyn/macos-auto-clicker/tree/menubarextra-working-prototype

[othyn]

Okay interesting, after doing some more playing around I've discovered a few things.

Firstly, the thing with the app state is a thing in the existing NSMenu implementation as well, I just never realised it. So that is now less of an issue.

Secondly, I've also fixed the state issue, its a known bug at Apple although who knows when it will be fixed, work around is to use an @EnvironmentObject instead of local View @State.

That just leaves the weird issue with the app's Show/Hide behavior.

[othyn]

Also turns out the show/hide bug exists within the NSMenu version of the app too.

If you hide the app, then close-open-close the menu, the app will close. No idea why.

If you show the app within one cycle of the menu closing and opening, it will behave as expected and keep the app hidden and running in the menu bar. But if you click on the menu bar once more without unhiding the app it will close. It also doesn't crash, it cleanly closes. Super weird.

[othyn]

Given all the above, I think I'll press forward with the MenuBarExtra re-write, as at least all the behaviours and bugs are consistent.

I'll fire off a new staging beta build with the app icon in now, then work on the MenuBarExtra stuff tomorrow (that's 20 tabs closed).

Fingers crossed the build works, due to #69.