Frederik Handberg on nostr

Frederik Handberg

@Frederik Handberg 1783513728

Teddy and Panda are so adorable 😂

Laeserin · 22h

That's okay, Egypt 🇪🇬, you played really well, but we could tell the Argentinians just wore you down. 🫂 It happens.

Frederik Handberg @Frederik Handberg 1783512928

I normally don’t care about football, but that was a really fun match to watch

Frederik Handberg · 7h

It might not seem to make much sense why you would even want 20 or so separate textviews rather than just having one massive textview: nevent1qgsfe8upa4u47r67lf2cjv5zg6rasn78u6jvlfkmt4knk58ukll6assqy...

Frederik Handberg @Frederik Handberg 1783502492

The block-based note structure will be removed because I have implement support for Markdown files.

Markdown support was always the goal but building a Markdown parser is not an easy task and there just haven't been any good options imo.

However, recently I discovered a cool parser and renderer:
https://github.com/nodes-app/swift-markdown-engine.git

I have made quite a lot of changes because I needed more features but it was an excellent foundation to build on top of.

The Markdown editor uses one massive `NSTextView` and then I inject SwiftUI views for images, videos, and code blocks by using `NSTextAttachmentViewProvider`. I haven't figured out how I want to implement support for tables.

Frederik Handberg

@Frederik Handberg 1783501934

It might not seem to make much sense why you would even want 20 or so separate textviews rather than just having one massive textview:

You could just use a single `NSTextView` and then inject #SwiftUI views into that textview. This can be achieved with `NSTextAttachmentViewProvider`:
https://developer.apple.com/documentation/uikit/nstextattachmentviewprovider

I wouldn't say that it's easy to get working - at least I found it quite complicated.

In fact, I found it so complicated that I initially scratched using `NSTextAttachmentViewProvider`, and just used separate textviews for my block-based editor. This meant, each block was its own textview.

For example, if you have 50 blocks in your note document, that might be 40 textviews and 10 SwiftUI `Image` views.

This was a serious performance killer for my macOS app, but it also made it a horrible UX, as you cannot by default navigate the caret across different textviews.

I did actually find a solution to this problem:
https://github.com/frederikhandberg0709/Sequential-Text-Interaction.git

But it was complicated and took a ton of trial and error before it finally worked 😂

Frederik Handberg @Frederik Handberg · 7h

I've been doing native macOS dev for about a year now, and I have found it so much easier to get good performance from a webapp compared to native. I think part of it is just SwiftUI being quite bad performance-wise. If you want to have horrible performance in your app, show 20 Show more

1

Frederik Handberg

@Frederik Handberg 1783500952

I've been doing native macOS dev for about a year now, and I have found it so much easier to get good performance from a webapp compared to native. I think part of it is just SwiftUI being quite bad performance-wise.

If you want to have horrible performance in your app, show 20 different `NSTextView`'s in a `ScrollView` and try have a sidebar that can open/close so that it changes the width of textviews - because when it closes, there is more available space, so make the textviews stretch to fill all the available space.

This kills performance 😂