Pretty much this. Wild that you can traverse most of China in affordable high speed trains, yet the Amtrak from Seattle to Portland barely crawls along and has to regularly stop for long periods of time because the tracks get too hot in the Summer.
And this is why all new projects by independent developers should seriously consider using a post-open source license before defaulting to corporate-friendly/corporate-first OSI licenses
> any time someone says something is post-$thing it means what they are doing is in dialogue with and in response to $thing. “we were doing that before $thing” no, you can’t be in dialogue with something that hasn’t happened yet.
> this is like saying “what do you mean post-modernist architecture, architecture predates modernism”.
Corporations who use and benefit from software should be made to pay for their use of that software, but they don't want to, which is why they'll happily spend money promoting the use of corporate-friendly and maximally exploitable open source licensing among the passionate individuals who maintain the lions share of their dependency tree.
I'm a fan of this. My own projects on GitHub have an action[1] which autocloses and autolocks any opened issues until they have been reviewed and accepted by me, and I only consider feature requests from sponsors.
The real miss here is that there isn't a way on GitHub to only allow maintainers to create issues, instead we are left with these subpar workarounds.
The experiment is end-user mediated wealth redistribution from large corporations by leveraging reimbursement mechanisms, and so far I'm content with the results
Not consistently, but there have been a few months this year where I have hit $500 selling individual commercial use licenses for my tiling window manager[1]
Fwiw I think this is the right approach. The trade-off between stability across OS updates vs tracking performance is a no-brainer for me - the absolute last thing that I would want is a deluge of bug reports with no other information than "it stopped working" when Apple pushes out an update
Took a look at this and it feels like it is implemented using public macOS frameworks so it shouldn't break between macOS updates
My guess is that kAXWindowMovedNotification, kAXWindowResizedNotification, kAXMainWindowChangedNotification etc. are being listened to on the currently focused window using the Accessibility framework, and there is a callback which gets the latest position of the tracked window whenever it is fired, and uses that position as a reference to update the border position
The border window itself is most likely an NSWindow, which is why the tracking of the border with the target window feels quite sluggish
It's very sad that none of these Linux DEs expose APIs for customization in anything other than JavaScript - I would love to be able to build on Gnome or KDE with something equivalent to windows-rs or objc2