refactor: moved daemon stuff to launchctl

[efa2d19]

ref

[efa2d19]

maybe using a bundle not the best idea tbh 'cause distributions have to provide it
Now its ready

[abilkhan024]

will checkout on the weekends

[abilkhan024]

I couldn't run the app on your branch in the background via:

swift build && .build/debug/VimiumNative start-daemon

Can you provide a minimal example on how it's supposed to be ran in daemon mode?

[efa2d19]

I couldn't run the app on your branch in the background via:

probably the permission is missing, check the logs at /tmp/vimium-native-out.log

[efa2d19]

you should add the binary to the accessibility permission allow list and it should start working after restart-daemon or start-daemon
It's kinda buggy tho if you want to add a binary from a build folder, I never got it working from there, copying it should work tho even in project root dir
If you see permissions message still reboot might help or reseting all accessibility permissions via sudo tccutil reset Accessibility (BEWARE that tccutil reset for some reason will freeze everything on the pc, at least on macos 26, so be prepared for force reboot)

[efa2d19]

probably the permission is missing, check the logs at /tmp/vimium-native-out.log

I'm planing to add a visible native banner for using the accessibility permissions later like in yabai or skhd (also the idea of using launchctl was inspired by these projects)

[abilkhan024]

In this case is moving daemon mode to launchctl justified? Cause I see it significantly complicates the setup with no apparent upside, apart from it being convention

[efa2d19]

it is cause it really persists as a daemon should and there is no more parsing processes by hand. Also it doesn't really complicate setup: you just start the daemon, make sure there is permission given to it which is needed only once after installation and restart the daemon if needed + permissions alert will make it obvious but it will come a bit later

[efa2d19]

all the problems mentioned above are true for developing and debugging the daemon not for using it

[abilkhan024]

Managed to run it. Turns out you need to give a11y api permissions, to the file now if you want to run it in daemon mode. So I think we should include it in the instructions when we exit if there are no such permissions. Also since we are using plists, I assume, the production build changes such that they're included in the final build? I don't see them in this PR

[efa2d19]

plist is included as generated byte array from resources
Adding instructions is a good idea tho, are you thinking about adding them to readme or on every daemon start/reload?

[abilkhan024]

1. Yeah, just additional info in stdout when !AXIsProcessTrusted(), that should grant a11y permissions to the runner and the executable itself
2. Checked the build works fine, so no issues there

One thing that I've noticed when you quit through menu item, when running in daemon mode, it restarts which I assume unintentionall side effect, may be we should handle the case when you terminate it from menu, you stop the daemon, such that it would stop restarting

[efa2d19]

One thing that I've noticed when you quit through menu item, when running in daemon mode, it restarts which I assume unintentionall side effect, may be we should handle the case when you terminate it from menu, you stop the daemon, such that it would stop restarting

yup, that's unintentional, will fix that as well

[efa2d19]

1. Yeah, just additional info in stdout when !AXIsProcessTrusted(), that should grant a11y permissions to the runner and the executable itself

AXIsProcessTrusted check will not suffice here 'cause it will check terminal emulator's permission instead of the binary itself. I was thinking about using AXIsProcessTrustedWithOptions in daemon only with kAXTrustedCheckOptionPrompt or maybe make it new default and skip check on daemon initialization so only the daemon itself will check permissions for the binary

upd: applicationDidFinishLaunching is skipped for daemon starting so forget about

it will check terminal emulator's permission instead of the binary itself

[abilkhan024]

I don't know it worked for me and message showed up in the log file when, I ran ./app start-daemon without the permissions

[efa2d19]

I guess there are also problems with multi user ux cause default permissions on String.write is 644

[efa2d19]

added in last 2 versions

• AXIsProcessTrustedWithOptions as default so there is a visible native window asking to enable permission
• mentioned binary path for running as a daemon on permission check failure
• disabled auto restart for the daemon on success exit
• • therefore permission failure exit code is 0 for now to avoid spamming with permission nag
• prepare path for logs to avoid launch failures on multiple users setup

[efa2d19]

@abilkhan024 another ping

[abilkhan024]

After reviewing it further, I've decided that it's not really what I want in my project because it complicates the setup and introduces unnecessary moving parts. The way macos manages a11y permissions makes it painful to develop in the proposed setup, so I will close this feature. Hope there are no hard feelings

[efa2d19]

make sense, gonna keep it as a patch for myself then, maybe i'll come up with something that will work better than a11