I think I finally have a working solution in my notes app 🚀 Don't want to declare victory too early. Will need to do some more testing, but my solution seems really promising. I am now able to hover the ellipsis button in a collapsed heading and the `NSCursor` will correctly change to the `.pointingHand`. Before it would immediately change back to the default, which is the `.iBeam` for text views. This is because the ellipsis button is positioned on top of an `NSTextView`, and text views in AppKit are very aggressive in controlling the `NSCursor` type. Even if you set `.onHover` to change cursor in SwiftUI, it will just get overridden by the text view... My solution involved controlling the cursor on AppKit-level, as I needed more control than what SwiftUI offers. Part of my solution involved overriding the function `cursorUpdate()` so that can control exactly when the cursor should update. I have a guard that returns early to avoid changing cursor if the hit view is the ellipsis button. I also override the function `mouseMoved()` to constantly set `NSCursor.pointingHand()` whenever the mouse is moved over the button. On a rare occasion, the cursor will flicker, but from my testing, this happens very rarely. #dev #AppKit #SwiftUI #macOS View quoted note →

Having some trouble with changing the `NSCursor` on hover. I have an `NSButton` layered on top of an `NSTextView`, and I want the button to use the `.pointingHand` cursor type when hovering it. But the text view will constantly override the `.pointingHand` back to the default for text views, which is the `.iBeam`. It’s not the first time I’ve been fighting this behavior. I’ve been trying to find a workaround before, but never spent much time on it, as I considered it a low-priority bug fix. But today I finally had the time to figure out a way to fix it. #AppKit #macOS

GitHub

GitHub - frederikhandberg0709/NSCursor-hover-tracking: Change NSCursor when hovering NSButton above NSTextView

Change NSCursor when hovering NSButton above NSTextView - frederikhandberg0709/NSCursor-hover-tracking

Semi-truck crashed on E45 Horsens #press

I’m hooked on the Canon C50… Looks like a great hybrid camera like the Sony FX3. I think the C50 and FX3 would be great together (even though their color profile is quite different, but that doesn’t matter for the work I do). One camera with a 35-150mm lens and the other with a 200-600mm. Now, the shitty thing is that I have two lenses for Sony; the Tamron 35-150mm and Sony 200-600mm. Both are incredible lenses. But with Canon, I’d need an RF lens, and I don’t like any of them... The Canon 200-800mm is not bad, but it does not have internal zoom like the Sony does. The reason for me wanting a second camera is so that I don’t have to change lenses all the time. It sucks missing a good shot because you’re messing around with the lenses. Not to mention, the risk of me dropping a lens is quite high when everything around me is so chaotic (like at the big structure fire I was at yesterday).

Major fire at a summer house in 7130 Juelsminde #press

I just finished implementing code blocks in my notes app 🚀 #dev #macOS #Swift #AppKit

I finished drafting my t-shirt pattern in CLO3D and got it printed. Now I need to trace it onto real pattern paper. #sewing

For the past month or two, I've been working on some pretty complex logic to support caret navigation and text selections across multiple sequential `NSTextView`s in #AppKit. I need this functionality for my block-based notes app, where each block lives inside its own text view. The problem is that by default #macOS doesn't natively support caret navigation or text selection across multiple text views. This would be a big problem for the user experience in my app, so I had to build a solution! My solution lets the user move the caret smoothly between text views just by using the arrow keys. On top of that, the implementation also supports making text selections across text views. The user can even copy text from a selection that spans multiple text views. In the video, the red borders show the boundaries of each text view. Notice how I'm able to move between them seamlessly, as if it were one continuous editor. #dev

From a learning perspective, I definitely think I’m making the right choice by building natively for each platform, because it lets me experience many different ways of doing things. Every language and framework has its own patterns and philosophies. Because of that, I’m getting a lot of practical experience that in the future, will help me make better implementation decisions. At some point, I’ll need to learn Electron and React Native. It should be easy, considering it’s React, which I’ve already used a lot. Tauri would be cool too, mostly because it’s much less bloated than Electron. But it sure isn't Rust that’s drawing me in… #dev View quoted note →

It’s difficult not to want to just scrap #AppKit and go all-in on #Electron or #Tauri. If my app was a macOS-exclusive, going the native route would be no problem - but this is not the case… I do want my notes app to be available on all the major platforms (iOS, Android, macOS, Windows, Linux, and the web). Building a native app for each platform is a massive undertaking - even for a large team of developers, let alone a single person. In fact, I would argue it’s naive to believe one person can realistically achieve this (even with LLMs). Sure, it's *possible*, but keep in mind, that you’ll be spending an enormous amount of time pushing every feature to every platform, while your competition using Electron and React Native move much faster. This becomes a big problem from a business perspective. Customers expect you to keep up with the competition, but that is nearly impossible when you're maintaining five separate codebases instead of just two (Electron and React Native where much of the code can be shared). If this project was purely for the sake of business, I probably made the wrong choice by going native 😅 But hey, I'm new to programming, so I think it's good that I'm making all these choices and learning from them. This project is about learning the craft of programming. Of course, I'd love for this project to eventually make a living income - that'd be a dream come true. I started my Software Engineering degree ≈2,5 years ago. I had coded before that, but just some pretty basic Remix and Next.js. I would barely even call that real programming considering how little logic was involved (mostly just mutating state values) to what I'm doing now with AppKit where I'm working with low-level APIs that are poorly documented. #dev