Frederik Handberg14d agoThere are many weird quirks when using #SwiftUI and #AppKit.
For example, say you have an overlay with an image above an `NSTextView`. You would expect the cursor to **NOT** change to the iBeam when you hover over the image because the text view is behind the overlay. However, it **WILL** actually change to the `NSCursor.iBeam` even though the overlay is above the `NSTextView`.
The `NSTextView` just takes higher priority. I don’t know why, and I’m not really sure what the correct approach is to fix this. I don’t actually think there is a correct approach, because to my knowledge, there is nothing in the official documentation about it.
I’ve had this problem ever since I began the development of my notes app, and I’ve never managed to completely solve it. But it’s also not something I’ve spent much time on either, though it is really frustrating. It’s something I see many take for granted when it comes to web development, as these things just work by default.
💬 0 replies
Replies (3)
Frederik Handberg14d agoI tried the obvious things like using `.onContinuousHover { NSCursur.arrow.set() }`, but it’s just fighting with AppKit. It flickers between the iBeam and arrow cursor constantly when dragging the mouse over the view.
It seems clear that the solution is to drop down to AppKit level instead of SwiftUI.
No idea if this will work, but I think using an `NSView` in the background of the SwiftUI overlay that explicitly registers an `.arrow` cursor should do the trick.
0000 sats
Frederik Handberg14d agoI probably need to call the super keyword on `resetCursorRects()` to inherit the default cursor functionality and then use `addCursorRect(bounds, cursor: .arrow)` to register the area where the cursor should be an arrow.
https://developer.apple.com/documentation/appkit/nsview/r…)
https://developer.apple.com/documentation/appkit/nsview/a…)
0000 sats