Isn't it true that Apple just prefers apps not use the menu bar in the first place? I'm not sure where I had read that, but it might explain why Apple doesn't improve the menu bar. Personally I'm of the opinion that they should improve it because the current situation is untenable.
Not exactly, though many apps violate Apple's Human Interface Guidelines for macOS menu bar extras[1]:
Let people — not your app — decide whether to put your menu bar extra in the menu bar. Typically, people add a menu bar extra to the menu bar by changing a setting in an app’s settings window. To ensure discoverability, however, consider giving people the option of doing so during setup.
Avoid relying on the presence of menu bar extras. The system hides and shows menu bar extras regularly, and you can’t be sure which other menu bar extras people have chosen to display or predict the location of your menu bar extra.
Consider exposing app-specific functionality in other ways, too. For example, you can provide a Dock menu that appears when people Control-click your app’s Dock icon. People can hide or choose not to use your menu bar extra, but a Dock menu is aways available when your app is running.
Yes, it was a huge mistake to allow any random app developer to claim such a prominent and limited piece of screen real estate. But it’s been an option for so long now that everyone will scream bloody murder if they try take it away.
Apple’s opinion seems to be: running out of space happens to only a few people running tons of menu-bar-loving apps, so if you are dorky enough to run into this problem, you should be dorky enough to solve it yourself.
I run into it when using Rider. I have text size increased on my Macbook and Rider has 8000 menu items, so my menu icons (all of which are default macOS, no third-party stuff) will be hidden to make room for Rider's stuff. I have to switch over to another workspace or window (i.e. away from Rider) if I want to access one of them. It's annoying but I'm not sure who I blame here; Rider I guess, for having a zillion menu items.
Why not blame Apple for having a busted-ass menu bar design? The behavior of "if the menu is busy, icons just disappear" and advice like "apps shouldn't rely on menu bar icons" are just bad ideas. They don't work well with how people use computers or how developers write apps. It's a bad design.
I prefer to blame Rider because it's the only app where I encounter this problem, and it seems more like a "don't make your list of menu entries so long it spans the notch and pokes into the menu icons" error than anything else to me. Simple as.
Unfortunately for me, notch overflow happens to me in Chrome, Edge, Firefox, VSCode, Outlook, Excel (and Word and probably all of the other Microsoft Office apps), LibreOffice, IINA (mpv frontend), CotEditor, IDEA, and QtCreator, just among those installed on my work machine.
> Simple as.
Neither Apple nor app developers control either what font sizes a user needs or how many apps they're running which produce menu bar icons. In that context, "not so long that it [...] pokes into the menu icons" isn't even well-defined. It's literally meaningless unless you parameterize it according to factors like those, which is not "simple as" anything.
It's a computer screen, not a page in some particular print magazine.
> it seems more like a "don't make your list of menu entries so long it spans the notch and pokes into the menu icons"
Only counting menu bar items that either (a) come with the operating system or (b) are imposed on me by applications that my employer forces me to run for compliance or other purposes, there are eleven mandatory icons in my menu bar at all times. So it doesn't matter whether the app in focus has few menu items or many; I run into this issue regardless.
> I prefer to blame Rider
There are a few ways to make sense of the situation, but none of them look great for Apple tbh.
If the menu bar is well designed but it doesn't work well with increased display scaling, accessibility is a second-class (or worse) concern in Apple's design.
If the menu bar is well designed but it doesn't work well when there are dozen menu bar icons, then it isn't suitable for environments where users don't control the number of menu bar icons they have to deal with— this, of course, is many professional environments.
So either: macOS isn't genuinely intended to be accessible, macOS isn't a general-purpose operating system for professionals, the menu bar has a bad design, or some combination of all three.
Of the three, "the menu bar's design is bad" seems the simplest and least absurd.
Presumably for the same reason things related to e.g. American politics gets flagged: everyone knows where they stand on the topic, and there's no good discussion to be had about it here – just flame wars.
Those are terminal emulators, not actual terminals. You can't fork or exec on iOS/iPadOS, so they're not actually running e.g. a python process, they're just running python interpreter.
As I understand it, ish implements x86 instructions and Linux syscalls as functions and translates running programs into arrays of calls to these functions, so all the machine code that will ever run is included in the app bundle, which at least satisfies the rules iOS enforces at runtime.
As for the rules as written, I suppose you could make reasonable arguments either way.
God damn, how much time am I wasting by writing full paragraphs to the Skinner box when I could just write half-formed sentences with no punctuation or grammar?
This was kind of an interesting comment from that thread. "Just invoke GDPR" is a refrain that's oft-repeated on Reddit (and, dare I say, HN), but it didn't seem to do much in this person's case:
> I did an SAR with Google last year and it took over a month for a single account. It also ended up containing very little because of the way they decide what is and isn’t ‘personal data’, e.g. for the one I used for work, they outright refused to release most of it apart from specific emails and docs where I was mentioned by name because the email address was a standard contact@mywebsite.com (which to be fair is correct grounds for refusal). They were very helpful in padding out the SAR release by re-sending the emails of me requesting the SAR, and also redacted the data protection employee name whom I was conversing with though lol.
> For SARs themselves there’s also grounds to refuse if they think it might interfere with potential future legal investigations, which given the ban reason I suppose isn’t an impossibility but unlikely.
People don't have a choice between Facebook and not-Facebook-but-still-has-all-of-your-friends-and-family. Abstinence isn't a choice here any more than shutting off your cell phone service is a choice; true in the literal sense, but only if you don't mind being unreachable to everyone who still has a phone.
But am I misremembering this?
reply