I don't know, there are definitely some rough edges (particularly with the menu bar for some reason - big rewrite there?), but overall I'm quite happy with Golden Gate. "Buggy mess" is some serious hyperbole.
Of the issues they report:
- The centering bugs seem... not very important.
- The Mac User Guide looks fine to me. Shows "for macOS 27."
- Network app?
- Why are you looking at the Mission Control app icon at 20x zoom? And in any case, doesn't it seem reasonable to simplify the traffic light design to a flat circle for an icon that will be displayed very small 99.9% of the time?
- Firefox bugs are bugs in Firefox. (I also keep experiencing the stuck menu bug, but again, Firefox bug.)
- "You can find references to NeXTSTEP, the ancestor of macOS, in its UI!" No, that's not what that means.
- "I have a folder open in the Dock. If I click on another folder, shouldn't that then open?" Yes, and it does.
> Firefox bugs are bugs in Firefox. (I also keep experiencing the stuck menu bug, but again, Firefox bug.)
Glitches in context menus could theoretically be just Firefox bugs. Glitches in the global menu bar can't be just Firefox bugs. Those pixels don't belong to Firefox. It shouldn't be possible for an application to cause the OS to lose track of which menu the user has open in the global menu bar. Even if Firefox is buggy here (quite likely), there's clearly a deficiency in the OS itself, too.
The menus, and what happens when you open/close them, do belong to Firefox. Cocoa gives apps a fair amount of power here. In Firefox's case, the issue is likely because each window specifies its own independent set of menu bar menus - very un-macOS - and it handles that by destroying and recreating the global menu bar every time you switch windows. The stuck menu bug seems to happen when a window is opened or closed, so my guess would be that something about the destroy-and-recreate routine is broken on macOS 27.
If Firefox isn't responsible for rendering the menu bar, then Firefox doesn't own the menu bar. It sounds like what you're describing is a process where Firefox tells the OS what items it wants the OS to put in the menu bar. Whether or not the app provides a new set of top-level menu entries during a window switch, it still seems to be entirely the responsibility of the OS to actually manage the rendering and respond to user interaction, including the OS keeping track of which top-level menu should be rendered as selected, and the OS should be enforcing that there's only zero or one selected menu.
I think you may have a poor mental model of how GUI apps work, at least on macOS. Perhaps you’re confused because the menu bar looks to be a global OS element, when in reality it’s as much the responsibility of the app as an OS where the menu bar is visually drawn inside the app window.
Even if the OS “renders” the menu or “owns the pixels”, it’s still being driven by procedural code within the app in order to create those menus. This is not some declarative spec that apps just hand off and wipe their hands of. The app “owns” the menu bar, it just uses OS libraries to help with it.
If the app code misbehaves or doesn’t follow the API contract, it’s completely possible to have bugs with the menus. For example, if an app just deadlocks, the menu bar hangs with a spinning beach ball the same as any other GUI element drawn inside a window. Switching to another app will cause the menu bar to work (because that other app is now rendering the menu bar), but it will remain frozen if you switch back to the frozen app.
rafram · · focus · HN ↗
Of the issues they report:
- The centering bugs seem... not very important.
- The Mac User Guide looks fine to me. Shows "for macOS 27."
- Network app?
- Why are you looking at the Mission Control app icon at 20x zoom? And in any case, doesn't it seem reasonable to simplify the traffic light design to a flat circle for an icon that will be displayed very small 99.9% of the time?
- Firefox bugs are bugs in Firefox. (I also keep experiencing the stuck menu bug, but again, Firefox bug.)
- "You can find references to NeXTSTEP, the ancestor of macOS, in its UI!" No, that's not what that means.
- "I have a folder open in the Dock. If I click on another folder, shouldn't that then open?" Yes, and it does.
- The rest, sure.
wtallis · · focus · HN ↗
Glitches in context menus could theoretically be just Firefox bugs. Glitches in the global menu bar can't be just Firefox bugs. Those pixels don't belong to Firefox. It shouldn't be possible for an application to cause the OS to lose track of which menu the user has open in the global menu bar. Even if Firefox is buggy here (quite likely), there's clearly a deficiency in the OS itself, too.
rafram · · focus · HN ↗
wtallis · · focus · HN ↗
DamnableNook · · focus · HN ↗
Even if the OS “renders” the menu or “owns the pixels”, it’s still being driven by procedural code within the app in order to create those menus. This is not some declarative spec that apps just hand off and wipe their hands of. The app “owns” the menu bar, it just uses OS libraries to help with it.
If the app code misbehaves or doesn’t follow the API contract, it’s completely possible to have bugs with the menus. For example, if an app just deadlocks, the menu bar hangs with a spinning beach ball the same as any other GUI element drawn inside a window. Switching to another app will cause the menu bar to work (because that other app is now rendering the menu bar), but it will remain frozen if you switch back to the frozen app.