Hacker News Reader

Comment by rafram | Hacker News Reader

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.

- The rest, sure.

View on HN

The centering bugs are important. They show attention to detail. Humans are wired to see such sloppiness as indicative of deeper problems. If they can’t get the easy stuff right, it saps your trust that they got the harder stuff right.

Apple built their entire brand around this ethos, and being willing and able to execute it better than any other brand. Letting it slip undermines the Apple brand, which is the entire company.

They built this brand for hardware, but, personally, I’ve never had this opinion of their software. I mean, being Unix based is better than Windows, but they’ve always been cooking weird UI refreshes or buggy software.

It’s crazy because they have (or had) something like $100bn in cash. Spending 0.5% of that per year on software (development, bug-fixing, performance, and QA) would help tremendously. They’d be insurmountable.

I know “they don’t have to”, but they don’t have to do a lot of things that they do on the hardware side. They choose to.

> Spending 0.5% of that per year on software (development, bug-fixing, performance, and QA) would help tremendously. They’d be insurmountable.

Doesn't really help:

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Also, "bug fixing" tends to add new bugs - any kind of change can cause regressions. It's quite difficult.

This is a little simplistic. Investing more in the quality component of the org - valuable.

TM3 is basically "if this is your approach to shipping sooner / more quickly, then you're going to have a bad time." It's not a solution for a delayed project. It's not "you shouldn't invest more in the infrastructure of a large project" (or at least not blindly).

It is valuable if you do it right, but it's difficult.

I've been promoting a specific aspect of performance quality recently, but it's mostly lead to other teams creating tests to monitor it that don't really make sense (along the lines of "if you use the computer it'll make the CPU % go up"), asking me to look at it, and then when I say it's probably fine I get a response along the lines of "it must be important because we already told all the executives about it."

>Doesn't really help:

That's just a classic software development book. What makes its lessons scientific fact?

Also, it's about a singular project that's late.

Not necessarily applicable to dozens of projects with understuffed teams. Adding people to such teams to help, and assigning new people to look and fix bugs nobody cares about now because they're overworked on some "flagship" new features, is a different case.

If they can’t get stuff you think is easy right, it saps your trust that they got the things you think are harder right.

Centering is not easy. Apparently. It requires human eye to verify. I can prove my decryption algorithm works. I can’t prove centering works.

> 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.

Firefox UI bugs are crazy. For example, on Tahoe 26.5, you can select disabled control menu items: https://imgur.com/a/7VUHzLK

Anywhere else on macOS, you can't do that. Even better, you can activate them with Enter.

Interesting, that one actually seems to be fixed on Golden Gate.

iirc these aren’t native menus. Firefox builds their own. I found this out when scratching my head why I couldn’t find “Look Up” in the right click menu in Firefox.

> particularly with the menu bar for some reason - big rewrite there?

This bothers me. Why would you rewrite the menu bar, something that works?!

I keep seeing new kinds of menu items in macOS. The menu for Focus mode is completely different in rendering than the menu for Wifi, say. Surely (I think to myself) all these should be inbuilt system menus -- that is, reusable shared code -- that are consistent? Or is macOS just getting rewritten, ad hoc yet wholesale, half the UI custom not system?

> "I have a folder open in the Dock. If I click on another folder, shouldn't that then open?" Yes, and it does.

Look at their gif carefully. Enable Dock magnification, click one folder, then click on any part of another folder's icon for which the click/cursor would no longer be on that folder's hitbox after the magnification effect moves to center that folder.

> Why are you looking at the Mission Control app icon at 20x zoom?

Apple used to. Scott Forstall famously used a photographer's loupe to inspect the UIs Apple was putting out.

What does the NS prefix mean?

NeXTSTEP. Grandparent is wrong.

Search this document for "Historical Note" for the canonical explanation:

https://developer.apple.com/library/archive/documentation/Co...

That it's a symbol in a Cocoa framework :)

NS hasn't had anything to do with NeXTSTEP since, well, NeXTSTEP. The author's wording makes it sound like this is some crazy remnant of forgotten 30-year-old code poking through, but it's really not. It's Swift (most likely) string concatenation being passed a view instance instead of a string by mistake.

That’s kind of a weird take. It’s perfectly reasonable that Apple has not attempted to yank all the “NS” references out, but they are absolutely a holdover from NeXTSTEP. That NeXTSTEP no longer exists does not change that.

The convention is a holdover. It does not mean that the code is the same. There’s plenty of NS classes that did not exist before OS X.

I didn’t say the code is the same. I said it’s incorrect to say that “ns” has nothing to do with NeXTSTEP.

Even funnier, there's new ones added for Liquid Glass that still reference NS: NSGlassEffectView

What would you say the letters NS stand for? Perhaps "Not Standforanything"?

Oh, hyperbole and a half. It's a useable OS.

- Centring _is_ important! How dare you!

- Same for me now. Wasn't when I used it a few days ago.

- ¯\_(ツ)_/¯

- Very pedantic, I know. But look at some of the other icons close up, lots contain tiny details very few ever see (try the Mail app, the icon of a text file, or the loupe on the old Preview icon). That obsessive attention to detail feels like it's now in the past.

- Yeah could well be Firefox's fault. But it surfaced in Golden Gate, so I included it.

- You can trace anything NS* back to NeXTSTEP

- Not for me!

- :)

Reply on news.ycombinator.com