Open saagarjha opened 8 months ago
Yeah, it's looking for a running instance of the Dock, so it will fail if Hammerspoon somehow manages to start before the Dock. But all it's actually doing with it at that point is trying to find the Dock app on disk, so I think it could probably be changed to:
local path = application.pathForBundleID("com.apple.dock") .. "/Contents/Resources"
(It does try to actually talk to the running Dock later on, to interact with Mission Control/Spaces - but the Dock is likely to be running by the time you're using any of those functions.)
If you want to try out that change, you can copy spaces.lua
from Hammerspoon into ~/.hammerspoon/hs/spaces.lua
and edit the line above into that copy. Or if you want to dynamically patch it, so that you still get any other updates to spaces.lua
in new Hammerspoon versions, you can create ~/.hammerspoon/hs/spaces.lua
with this code in it:
~/.hammerspoon/hs/spaces.lua
(patching version)I've never run into a timing issue this tight, but pathForBundleID
should work. At load time, it's looking for the specific verbiage that pages will be using in the Mission Control accessibility objects, so it's the location on disk that matters, not the running Dock itself.
As noted, the running Dock is important when you trigger it, but not at load time.
Would I run into issues if I just edited the app itself for testing?
@saagarjha nope, editing .lua
files inside Hammerspoon.app
is fine, they're ignored by Gatekeeper.
Not sure when I started seeing this, perhaps in the first beta of 14.4? But this line of code fails for me when Hammerspoon opens on startup: https://github.com/Hammerspoon/hammerspoon/blob/56b5835dc1bf7bb430dfea3f1662379cccec0c82/extensions/spaces/spaces.lua#L57
Here's the error:
If I reload the config it works as expected, so I assume whenever this runs is too early for this to return any results?