← Back to context

Comment by 2bitencryption

6 days ago

The interesting part, for anyone who actually reads the article - the change was fixed in an RC and then reverted in the final release.

Which implies there was some regression, some issue, some incorrect behavior or negative impact. One has to wonder… what could it have been? What could the issue with having a more accurate clickbox for the corner of the window possibly be?

29 comments

2bitencryption

Reply
GuB-42  6 days ago

It can be some technical detail.

For example: imagine you have 2 windows, the lower right corner of one window almost touching the upper right corner of the other, so that the bounding rectangles overlap but the graphics don't.

With the inaccurate "false square" corners, you just had to check the bounding rectangles, to know which window to resize, now you have to check the actual graphics (or more likely, a mask).

I am not saying it is the problem, but that's the kind of thing that can happen. Or it may be a simple bug, like a crash, memory corruption, an unhandled exception, the usual stuff, but they couldn't fix it in time and it is better to revert instead of leaving the buggy code or pushing an untested fix.

  • blindriver  5 days ago

    Just revert the code back to pre-26! This is ridiculous, it can't possibly be this hard and if it is, it just points to the degradation in the quality of Apple software! This is maddening!

    • igregoryca  5 days ago

      This is already the pre-26 bounding box, isn't it? It's the new graphics that don't line up. (Not a great excuse, but the graphics are here to stay at least for a little while.)

      6 replies →

    • bandrami  5 days ago

      > it can't possibly be this hard

      Whenever I find myself saying this I remind myself it can in fact be this hard.

msephton  5 days ago

I think it shows how difficult it is to ship a seemingly easy thing inside the Apple machine.

I'm more interested in how or why this bug was approved up be worked on so quickly after it was surfaced, rather than other longstanding and arguably more impactful bugs.

  • StilesCrisis  5 days ago

    It's because the bug got publicity. Apple marketing prioritizes what does and doesn't get built. Someone saw bad publicity on the front page of HN and requested a fix.

  • nozzlegear  5 days ago

    The answer is probably a ho-hum combination of different teams work on different issues, and this one having annoyed one of the devs who could work on it.

radley  5 days ago

Most likely (and natural): they tested it publically and the response wasn't positive, so they held it back until they could do it better.

pdhborges  5 days ago

Maybe they reverted it because they are already planning to get rid of the super rounded corners!

anematode  6 days ago

Maybe it was just an oversight in the merge process? e.g. the diff was applied only to the RC and not to the release branch? idk

jlaternman  5 days ago

macOS does have weirdness with windows that span multiple screens. I bet some of that kicked in to an unacceptable level. It can create incoherent moving/snapping, for example. Has been kind of crazy-making for a while, for my set-up where screens are not joined but adjacent in a triangular configuration.

  • iainmerrick  5 days ago

    Yeah, that's something that was unambiguously better back in the "Classic MacOS" days (probably starting with the Mac II). Windows could overlap multiple screens and they were always drawn correctly.

    At some point in OS X in the switch to hardware acceleration, they started rendering windows on one screen only.

    I get that you hardly ever really want a window spanning two screens, but when you accidentally misplace a window it would be handy to be able to see it on each overlapping screen so you can track it down. Right now you can put a few pixels of the title bar on the wrong screen, and the rest of the window just vanishes.

    These regressions are weird given that modern hardware is vastly more powerful than a Mac II.