Hacker News new | ask | show | jobs
by chipotle_coyote 1641 days ago
> As far as I know, the best long-term answer here is for apps that present visuals full screen to "capture" the external display for exclusive use using an API...

If I'm understanding you correctly, that means there's already a supported workaround for this if apps just use that API? I don't want to downplay the annoyance of this for apps that aren't using that API, but this suggests there's already an official answer.

I'm mildly surprised the orange dot shows up in full-screen apps; I was going to suggest that might be the easiest "fix" for Apple to make that doesn't require either adding a new security setting or taking away the indicator entirely -- have it only show up in the menu bar, and not when the menu bar isn't present.

3 comments

I'd like to ask a follow-up also as I don't do any Mac dev, but has this API been around for a bit then? Like Monterey has been out for a bit and it's a little surprising that this article and the subsequent discussion is only popping up now, especially if there is an API answer to it already.

I ask earnestly if the change is really such a substantial one?

I have mixed feelings after reading the comments as I think that there are fairly valid arguments in both directions (e.g., that the solutions are plentiful, but also that workarounds aren't really a solution), but the arguments feel a bit empty if there's a "right" way to be handling the visuals that just isn't being used.

As a user I like the change in general as I have caught naughty applications that try to use mic input when I really don't want it, and my misclick/absentmindedness is not uncommon, so seeing such things helps a lot as I don't really think it's reasonable to constantly be checking the various app permissions to make sure they're what I want. This is a good reminder for me.

But I totally get not wanting the dot, as it's even been a prank on a site I go to to have a tiny red pixel just to annoy people (and it's a prank I've used). So I get the frustration with an unexpected visual. But, if there's a way to do the same activity by having the app utilize the correct API, it seems like an issue that is solved in the next update from these visual production apps, no?

CoreGraphics and the associated screen capture APIs have been around for a very long time. However they aren't particularly easy to use and do require your app to be trusted (reasonably so). You can't have just any old Mac app start capturing the screen and doing things with the pixels.
Users of audio/visual software typically wait a bit after major OS updates.
Grabbing into a different programs UI to move some dot off-screen by 99999 pixels does not exactly rise to the level of an API.
The hack that the OP created is not, AFAIK, using the API that they described. I'm pretty sure we're talking about two different things. :)
> If I'm understanding you correctly, that means there's already a supported workaround for this if apps just use that API?

I don't think this API helps people that use display out, like a projector or screen.

Why would you think that? The CGDisplayCapture function that the GP linked includes a "display ID" keyword to specify a specific external display, like a projector or a screen. Why wouldn't it work?