macOs Mojave noticably delay

For us to be able to understand the issue you’re having you need to follow this template. Please make sure there isn’t already an issue for the bug you’ve found, otherwise it’ll just take more resources, which means less time for us to actually fix bugs. Thanks for reporting!

Describe the bug

First time testing out ActivityWatch, installed it using brew cask install activitywatch. After installing it I’m noticing a bunch of delays when doing all kinds of stuff. Writing in chrome stutters. Switching windows sometimes have a small (a few hundred milliseconds? at least enough to be noticeable and annoying) delays before it gets active.

I can’t do anything but assume that ActivityWatch is the one imposing these delays / stutters as it started happening right as I installed and started the app.

To Reproduce

Happening on a new install after starting it and giving it accessibility access.

Environment

• ActivityWatch version: 0.9.2
• OS: macOs Mojave 10.14.6

[xylix]

There’s significant work on moving away from the AppleScript solution at https://github.com/ActivityWatch/aw-watcher-window/pull/40 . It does require some significant changes though, partially becase of the problems getting both app name and window title, and partially because of problems getting the native accessibility API access.

Your performance issues probably aren’t because of that though, it’s mostly because of the system events spam I think. More details here, https://github.com/ActivityWatch/activitywatch/issues/380 and I recommend we move future discussion there as well will be closing this issue for now, to keep most information about this bug in one place. There are some suggested workaround there in the latest comments, I recommend you look through them.

Your report did help me narrow it down that this is surely happening for brew installs. I also have not been able to reproduce on Catalina, but we have had multiple reports of this problem on Mojave. Work is being done on actually giving a sensible error on these cases /

[TheKnarf]

Decompiling printAppTitle.scpt by downloading it and running osadecompile printAppTitle.scpt reveals that the code is as following:

global frontApp, frontAppName, windowTitle

set windowTitle to ""
tell application "System Events"
	set frontApp to first application process whose frontmost is true
	set frontAppName to name of frontApp
	tell process frontAppName
		try
			tell (1st window whose value of attribute "AXMain" is true)
				set windowTitle to value of attribute "AXTitle"
			end tell
		end try
	end tell
end tell

do shell script "echo " & "\"\\\"" & frontAppName & "\\\",\\\"" & windowTitle & "\\\"\""

I do wonder if this is the thing that slows it down, or if the problem is elsewhere. It would also be nice if one could deliver the same functionality without having to refer to application "System Events" like that, as I got a bunch of popups when first installing the program where it wanted to control “System Events”.