| ▲ | 2bitencryption 10 hours 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? |
|
| ▲ | galad87 4 hours ago | parent | next [-] |
| It broke some NSWindow styles: https://developer.apple.com/forums/thread/814798 |
|
| ▲ | GuB-42 9 hours ago | parent | prev | next [-] |
| 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 8 hours ago | parent [-] | | 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 8 hours ago | parent | next [-] | | 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.) | | |
| ▲ | reddalo 2 hours ago | parent [-] | | > the graphics are here to stay at least for a little while And that's the reason why I won't buy a new Mac. Tahoe and Liquid Glass are so horrible that they're going to lose customers because of those. They should realize what they did and just backtrack: it wouldn't be the first time they admit they made a mistake [1]. [1] https://www.theverge.com/2020/5/4/21246223/macbook-keyboard-... | | |
| ▲ | watt an hour ago | parent | next [-] | | Remember how long it took for them to give up on that stupid touchbar and "butterfly" keyboard. Don't hold your breath. | |
| ▲ | rezonant 2 hours ago | parent | prev [-] | | Still waiting on admission that the magic mouse was a mistake though |
|
| |
| ▲ | bandrami 3 hours ago | parent | prev | next [-] | | > it can't possibly be this hard Whenever I find myself saying this I remind myself it can in fact be this hard. | |
| ▲ | mvdtnz 8 hours ago | parent | prev [-] | | Pre-Tahoe windows didn't have these stupid round corners (which is the ACTUAL bug which should be fix). | | |
| ▲ | tom_ 8 hours ago | parent [-] | | I am using Sequoia and the windows are definitely rounded! Though the radius is pretty small (the curved region is about a quarter of the mouse cursor area), so the fact you can drag it from outside the window doesn't look ridiculous. |
|
|
|
|
| ▲ | radley 8 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent | prev | next [-] |
| Maybe they reverted it because they are already planning to get rid of the super rounded corners! |
|
| ▲ | msephton 8 hours ago | parent | prev | next [-] |
| 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 8 hours ago | parent | next [-] | | 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 8 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | 7 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | jlaternman 9 hours ago | parent | prev | next [-] |
| 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 26 minutes ago | parent [-] | | 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. |
|
|
| ▲ | anematode 9 hours ago | parent | prev | next [-] |
| 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 |
|
| ▲ | cardanome 9 hours ago | parent | prev | next [-] |
| The AI reverted the change and no one does proper code reviews anymore so it went into prod. |
| |
|
| ▲ | lobochrome 6 hours ago | parent | prev [-] |
| Or it was just a botched git op |
