6 ms·

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 kAXWindowMov

by bsnnkv 10mo ago

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

tylerhall 10mo ago
Developer of the app here. You’re correct. Accessibility APIs + timer + transparent top-level NSWindow that ignores input and draws a border.
- Angostura 10mo ago
  Very nice idea, thank you for developing it. With an M1 iMac, though the window border lags the position of the window quite a lot if you drag it around, so probably not usable for me.
  - AshamedCaptain 10mo ago
    I really ponder what is the usecase here that requires dragging windows "quite a lot" and also makes a lagging window border "not usable".
    - Angostura 10mo ago
      You seldom resize, or drag windows?
  - OGEnthusiast 10mo ago
    Some lag is probably going to be unavoidable with a third-party app. The only way to have perfect synchronization of window dragging/resizing and the border is for macOS to implement this as a first-party feature.
- bsnnkv 10mo ago
  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
  - hyperhello 10mo ago
    As a developer I would interpret that as "try it in the new OS and you will immediately see what is wrong so there is no reason for me to write a tedious and unnecessary message to you".
- inatreecrown2 10mo ago
  I thought I take a look at the code, but I can only find readme and license?

by bsnnkv 10mo ago

tylerhall 10mo ago

Developer of the app here. You’re correct. Accessibility APIs + timer + transparent top-level NSWindow that ignores input and draws a border.

Angostura 10mo ago
Very nice idea, thank you for developing it. With an M1 iMac, though the window border lags the position of the window quite a lot if you drag it around, so probably not usable for me.
- AshamedCaptain 10mo ago
  I really ponder what is the usecase here that requires dragging windows "quite a lot" and also makes a lagging window border "not usable".
  - Angostura 10mo ago
    You seldom resize, or drag windows?
- OGEnthusiast 10mo ago
  Some lag is probably going to be unavoidable with a third-party app. The only way to have perfect synchronization of window dragging/resizing and the border is for macOS to implement this as a first-party feature.
bsnnkv 10mo ago
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
- hyperhello 10mo ago
  As a developer I would interpret that as "try it in the new OS and you will immediately see what is wrong so there is no reason for me to write a tedious and unnecessary message to you".
inatreecrown2 10mo ago
I thought I take a look at the code, but I can only find readme and license?