Description
Created by: benfry
In the macOS build we have a dependency on japplemenubar which hasn't been updated in a decade. I'm concerned that it will stop working at any time, because it uses SetSystemUIMode, which is a Carbon API and we're supposed to be using setPresentationOptions() (a Cocoa API) instead. In fact, I'm not even sure why it still works.
There's the code in question: https://github.com/kritzikratzi/jAppleMenuBar/blob/master/src/native/jAppleMenuBar.m
The update to this code was done in Mozilla: https://bugzilla.mozilla.org/attachment.cgi?id=8616917&action=diff in which this code:
if (sMenuBarHiddenCount > 0) {
::SetSystemUIMode(kUIModeAllHidden, 0);
} else if (sDockHiddenCount > 0) {
::SetSystemUIMode(kUIModeContentHidden, 0);
} else {
::SetSystemUIMode(kUIModeNormal, 0);
}was changed to
NSApplicationPresentationOptions options;
if (sMenuBarHiddenCount > 0) {
options = NSApplicationPresentationHideDock | NSApplicationPresentationHideMenuBar;
} else if (sDockHiddenCount > 0) {
options = NSApplicationPresentationHideDock;
} else {
options = NSApplicationPresentationDefault;
}
[NSApp setPresentationOptions:options];In our case, we don't need any of this logic, we need:
NSApplicationPresentationOptions options =
NSApplicationPresentationHideDock | NSApplicationPresentationHideMenuBar;
[NSApp setPresentationOptions:options];and a second call to clear those out.
There's also this version done in Swift that toggles, though we'd be changing autoHideMenuBar to just hideMenubar and autoHideDock to hideDock.
let application = NSApplication.shared
let autoHidden = application.presentationOptions.contains(.autoHideMenuBar)
if autoHidden {
application.presentationOptions = []
} else {
application.presentationOptions = [.autoHideDock, .autoHideMenuBar]
}Reference for presentationOptions and hideMenuBar.
Anyhow, we need something as simple as the japplemenubar solution (a teeny tiny JNI library) or something that's like two lines of JNA that handles this for us. In particular, we'd want to avoid adding an entire dependency like Rococoa or similar.
A JNA solution would mean adding JNA to core, but we may need to do that soon in order to get native screen resolutions for handling hidpi screens.
Or if not, it'd be great to stay away from JNA, maybe we do the JNI one liner. Or maybe the hidpi calls can mostly be handled with similar one-liner JNA code, which we could use to build out a tiny native sidecar for core.