Targeting a hidden menubar with Wooshy

[jannis-baum]

I have my macOS menubar set to be hidden by default, meaning it only shows when I move the mouse cursor to the top of the screen. For the longest time, needing to click something on the right side of the menubar was a major reason I had to use an actual mouse since there is no way to make the menubar appear without a mouse¹.

Now I found a solution with Hammerspoon and Karabiner Elements deep down the rabbit hole. The basic idea is to

1. move the mouse up to where the menubar will show before activating Wooshy so that it's there when Wooshy grabs UI elements
2. it it's still visible, move the cursor back down afterwards to make the menubar disappear

Showing the menubar with HS

I set up a URL event at hammerspoon://mouseToMenubar that will move the mouse up, revealing the menubar. You can add the following to your ~/.hammerspoon/init.lua:

hs.urlevent.bind('mouseToMenubar', function()
    pos = hs.mouse.absolutePosition()
    event = hs.eventtap.event.newEvent()
    event:setType(hs.eventtap.event.types.mouseMoved)
    event:location({ x=pos.x, y=0 })
    event:post()
end)

Showing the menubar before starting Wooshy

I use a simultaneous press of i and u to open Wooshy with menubar access, and have my Wooshy hotkey in its preferences set to command+f8, so this is what I'll use in the example. Furthermore, I'll use goku, which provides more concise .edn syntax over Karabiner's .json. Add the following to your ~/.config/karabiner.edn:

{
  :templates {
    :uri "open -g \"%s\""}

  :main [
    {:des "Wooshy with menubar access" :rules [
      [
        ;; trigger with u+i and any modifiers → set this to whatever you want to use
        {:sim [:u :i] :modi :any}
        ;; map to HS URI
        [:uri "hammerspoon://mouseToMenubar"]
        ;; trigger unconditionally
        nil
        ;; if no other keys are pressed, open Wooshy 200ms later (this delay works well for me)
        ;; `:invoked` mappping needs to match your Wooshy preferences
        {:delayed {:invoked :!Cf8} :params {:delay 200}}
      ]}
  ]
}

With this set up, we can already use Wooshy on the right-side items of our normally hidden menubar🥳

Hiding the menubar after Wooshy-ing

Sometimes we don't click anywhere and just exit Wooshy after opening it; in this case it's useful to move the mouse back down to make the menubar disappear again. Add the following to your ~/.hammerspoon/init.lua:

wooshyDisappearWatcher = hs.distributednotifications.new(function(name, object, userInfo)
    pos = hs.mouse.absolutePosition()
    if pos.y < 24 then
        event = hs.eventtap.event.newEvent()
        event:setType(hs.eventtap.event.types.mouseMoved)
        event:location({ x=pos.x, y=pos.y + 100 })
        event:post()
    end
end, 'WooshyInputDidDisappear')
wooshyDisappearWatcher:start()

Footnotes

1. other than cmd+shift+/, which will bring up the search for the left side of the menubar, but doing this will make the entire menubar disappear as soon as Wooshy takes focus so we still can't access anything on the right side :( ↩

[godbout]

AWW.

but also, would be nice to have this natively from Wooshy right? will see what i can do. there was a similar issue about the Dock, but it happened to be undoable properly (the Dock is an app that you have to kill after you've made the change, and it broke some other stuff). could be nice to see if this is doable properly for the menu bar!

do you mind opening an issue for this? thanks :))

[godbout]

the similar issue about the Dock talked above: #37

[jannis-baum]

That would of course be even cooler!🙈 Opened #130

[jannis-baum]

Especially if there was some way you could make the menubar show/hide fast... for the Dock there are

defaults write com.apple.dock autohide-delay -float 0
defaults write com.apple.dock autohide-time-modifier -float 0

but I'm pretty sure there is no such option for the menubar. If I skimmed #37 correctly though you didn't go with manipulating the defaults there so maybe you can find a way for the menubar😇

[godbout]

i didn't mention it in the issue but the way to fuck with the Dock was actually to manipulate the defaults yeah. plus killing the Dock after. but you couldn't get a proper UX because you don't control the transition times, etc. even if it's faster. as usual i remember i investigated and reached a conclusion that it was not good to implement, but now i'm not sure exactly about the details anymore. maybe will revisit 😅️ (if that makes sense. the menubar makes a lot more than the Dock as far as i'm concerned, as for the Dock you could mostly use Alfred to call apps.)