Possible way to completely hide the builtin menu bar

[Rhys-T]

There is one way to keep the builtin menu bar 'permanently' hidden without actually modifying the system. All it requires is accessibility permissions:

• Set the menu bar to auto-hide, in System Preferences > General.
• Use the CGEventTap* API to intercept mouse-moved events.
• If those events are within a few pixels of the top of the screen, adjust their location down, so that the bar doesn't know it needs to show itself. (You could also discard the events entirely, but moving them down seems a bit less likely to interfere with anything.)

Proof of concept for the event tap part, using Hammerspoon:

------- ~/.hammerspoon/init.lua: --------

require 'noMenubar'

----- ~/.hammerspoon/noMenubar.lua: -----

local minDistance <const> = 4 -- keep mouseMoved events at least this far from the top of a screen

-- store various things in locals for performance
local screen = require 'hs.screen'
local eventtap = require 'hs.eventtap'
local screenFind = screen.find
local geomNew = require 'hs.geometry'.new
local floor = math.floor

local lastFrame = nil -- cached rectangle of the last screen the mouse was seen on
local tap = eventtap.new({eventtap.event.types.mouseMoved}, function(event)
	local loc = geomNew(event:location())
	if not lastFrame or not loc:inside(lastFrame) then
		-- argument below needs to be a rectangle and not a point, hence the geomNew/0x0
		local screenContainingCursor = screenFind(geomNew(loc, '0x0'))
		lastFrame = screenContainingCursor:fullFrame()
	end
	local relativeY = floor(loc.y) - lastFrame.y1
	if relativeY < minDistance then
		event:location{x = loc.x, y = lastFrame.y1 + minDistance}
	end
end):start()

-- If the screen configuration changes, reset the cached rectangle
local screenWatcher = screen.watcher.new(function()
	lastFrame = nil
end):start()

-- Store references to the event tap and screen watcher in the module's return value,
-- to keep them from being garbage-collected.
return {tap, screenWatcher}

Would something like this be worth implementing into SketchyBar itself? That would remove the need for a separate app, and make sure that if SketchyBar wasn't running for some reason, the builtin bar would become available again. On the other hand, it could cause input lag if SketchyBar was busy doing something other than handling those events - at least until the system got tired of waiting and auto-disabled the event tap.

[es183923]

your POC is awfully complex

i believe the following code works. (it's from code that i used a while ago, haven't tested this recently)
it literally just hooks onto the mouse moved event, then if the location is less than 2, it blocks the event

hs.eventtap.new({ hs.eventtap.event.types.mouseMoved }, function(l)
    return (l:location().y < 2)
end):start()

[es183923]

take a look at this google groups convo: https://groups.google.com/g/hammerspoon/c/xQ7AjexL31o/m/QOkq62FPDwAJ
it suggests this as the basic example:

hs.eventtap.new({hs.eventtap.event.types.mouseMoved}, function(e)
     if e:location().y < 1 then
         return true
     else
         return false
     end
 end):start()

it suggests this for multi-monitor support (still need to wrap around in a hs.eventtap object tho):

function(e)
    local sf = hs.screen.mainScreen():fullFrame()
    local loc = e:location()
    if loc.y < (sf.y + 1) and loc.y > (sf.y - 1) then
        return true
    else
        return false
    end
end

[Rhys-T]

Yeah, that would work too. I was trying to avoid re-fetching the frame on every event to minimize the time spent processing each event, but that was probably a premature optimization.

The reason I was modifying the event's location instead of dropping it with return true was to minimize the chance that it would prevent the user from interacting with anything. It's unlikely to affect anything unless you're subscribing to mouse.entered, mouse.exited, etc. - I just have a tendency to over-engineer these things.

I did have to increase the distance threshold (the 2 in your first example, or the 1s in the second and third) all the way to 4 to reliably block the menu bar, though - at least on my (Catalina) machine. Anything less, and I can occasionally get the menu bar back if I move the mouse slowly at the very edge of the trigger area.

One other note: make sure to save the result of hs.eventtap.new(...) in a global variable or something¹ - otherwise it will get garbage-collected at some 'random' point and stop working.

Footnotes

1. In my example, that 'something' was the module's return value, which gets saved in the package.loaded table. That won't work for the main ~/.hammerspoon/init.lua file, since it doesn't get loaded through require. ↩

[FelixKratz]

Would something like this be worth implementing into SketchyBar itself? That would remove the need for a separate app, and make sure that if SketchyBar wasn't running for some reason, the builtin bar would become available again. On the other hand, it could cause input lag if SketchyBar was busy doing something other than handling those events - at least until the system got tired of waiting and auto-disabled the event tap.

I don't think I want to start using a global mouse event tap just to stop the default bar from showing, since this can have drastic performance implications as sketchybar would need to handle every mouse move event of the system. I have profiled this effect some time ago and it is a non-acceptable degradation of performance.

Creating a little helper program for this seems to be the best approach.

[Rhys-T]

Fair enough. I knew there was a risk of performance issues, but figured I'd mention the possibility in case it was a viable approach, and post the Hammerspoon version in case it was useful to anyone. Didn't know you had already profiled something like that.

[FelixKratz]

From yabai v6.0.12+ there is an option to completely disable the built-in menu bar:

yabai -m config menubar_opacity 0.0