Find/write alternative to japplemenubar and remove it

[processing-bot]

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.

[processing-bot]

Created by: knupel

I don't if that's can help or poluate the topic, because my understanding of what is necessary to help. But just in case I work around an apple menu bar for my library rope. https://github.com/StanLepunK/Rope/blob/master/src/rope/gui/bar/R_Apple_Bar.java I've used javax.swing.JFrame, jMenu, JMenuBar et cetera. If it's a possible option maybe I can try to understand deeply what is necessary for Processing 4 :)

[processing-bot]

Created by: benfry

Thanks; it looks like that's solving a different type of menu-related issue, but I appreciate the interest.

[processing-bot]

Created by: knupel

Too bad, maybe next time I can add a stone to the Processing castle !

[processing-bot]

Created by: benfry

:)

[processing-bot]

Created by: benfry

Resolved for 4.0 beta 5.

[processing-bot]

Created by: benfry

Purged the old code for beta 7, now with a cleaned up version of the rewrite started in beta 5: 4ab1c8c

Documentation here: https://github.com/processing/processing4/tree/master/core/different

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.