I got images working in the #Markdown editor I'm building 🚀 In the old Markdown rendering engine I also had images working, but this new version is a completely new implementation - none of the code is like before. I decided to scratch my own implementation because even though my Markdown rendering engine was working as expected, I had some serious problems getting `NSTextView` and `TextKit2` to behave the way I wanted. For example, I was fighting a bug where it would apply the same styling to the last empty line as the text before it. Then I tried switching to `STTextView`, which did solve the bug, but had its own problem… It would crash the entire app as it caused an infinite loop bug because it was fighting #SwiftUI over the correct height of the textview. Therefore, the app kept recalculating the height which would eventually lead to a crash. Link to the Markdown rendering engine I am using:

GitHub

GitHub - nodes-app/swift-markdown-engine: A native AppKit Markdown editor for macOS, built on TextKit 2 and bridged to SwiftUI.

A native AppKit Markdown editor for macOS, built on TextKit 2 and bridged to SwiftUI. - nodes-app/swift-markdown-engine

This new engine solves the empty-line-bug I mentioned above.

This repository saved me a lot of time 😅 Have had an unbelievable amount of trouble with `TextKit2` and `NSTextView`. So many ridiculous bugs and I just could not get them solved... There is so little information out there about this AppKit stuff, and considering I'm still fairly new to programming, it makes it feel like I'm just guessing without really knowing what to look for. Now I have a version that actually works really well. I'm just missing some features to add, but so far so good. #dev #AppKit #Swift #macOS #Markdown View quoted note →

This bug seems unfixable 😂 I am now in the process of converting from `NSTextView` to `STTextView` instead. I have never used it before but I will give it a try. Maybe it will work…

GitHub

GitHub - krzyzanowskim/STTextView: Performant and reusable text view component (TextKit 2), with line numbers and more. UITextView / NSTextView replacement.

Performant and reusable text view component (TextKit 2), with line numbers and more. UITextView / NSTextView replacement. - krzyzanowskim/STTextView

View quoted note →

Rescue operation in Glud between Horsens and Juelsminde 🚁 #press

Teddy is a tired little guy 😂 View quoted note →

Teddy is using Panda as a bed 🛏️ 😂 #GuineaPig #rabbit

Line cutting feature implemented in the Markdown editor 🚀 Simply click `Cmd+X` after placing the caret in a line to cut it instantly. #dev #Swift #SwiftUI #AppKit #macOS

The excellent developer experience you get with #Electron gets traded for a _bad_ user experience. When I write _bad_ UX, I am referring to an Electron app _never_ really feeling native. You can certainly attempt to make an Electron app feel native, but simple things like the bouncing effect when you scroll beyond the top or bottom of a scrollable page or HTML element (like `<div>`) does not work in Electron. This is default behavior for native #SwiftUI apps when using `ScrollView`. It’s what macOS users expect from the apps they use. An Electron will always have that website feeling, which makes sense, because Electron apps are literally just websites. I can immediately tell if an app is native or is using Electron. It’s harder to tell if an app is using Tauri. Haven’t tried Tauri yet myself, but I’m always quite impressed by apps built with Tauri. I understand why devs choose to use Electron. I recently experimented with Electron for my notes app and I totally get the appeal. The speed of development is incredible for Electron. You can get features implemented so fast and web technologies have come super far. But still, I don’t think I’m willing to trade a bad UX for a good DX.

Fixing the grass trimmer. The primer bubble to pump fuel into the carburetor has cracked open.

Going back to old media. It just feels nostalgic to have physical media again :) Being reminded of my childhood with our countless DVDs and cassette tapes. I don’t actually have a Blu Ray player so that’s a bit of a problem… Starting with Suits because I like the first few seasons before the show turns to shit.

I feel like the worst part about building the same app in multiple different frameworks is getting the app to feel and work the same in all versions being near impossible, because each framework has its own quirks and bugs. For example, my native app for macOS built using #AppKit and #SwiftUI allows pinch-to-zoom in `WKWebView`, but `<webview>` in Electron has a bug where pinch-to-zoom just will not work:

GitHub

[Bug]: `<webview>`.setVisualZoomLevelLimits(1, 5) doesn't work · Issue #34440 · electron/electron

Preflight Checklist I have read the Contributing Guidelines for this project. I agree to follow the Code of Conduct that this project adheres to. I...

So now, I'm in a situation where the native macOS app has a feature that the cross-platform Electron app does not have... Luckily this is a small feature, but I expect feature parity to become a bigger problem because I only just started with the Electron app. Also, should I have chosen Tauri? Idk, I'm getting an urge to switch. The whole frontend can just be moved immediately to Tauri with React, but the backend would need some work. The worst part will be having to deal with different web engines because Tauri uses native engine from the OS. But then again, is that really such a big issue? Because when you build a webapp, you need to make sure to support all web engines, anyways.

Stories on #Nostr would be a nice feature. Hopefully it will be widely supported. View quoted note →

The new implementation uses the native HTML `<canvas>`. Then all canvas objects gets drawn on an 800x560px canvas allowing the app to take a snapshot. Now the app runs smoothly even when taking a snapshot of the canvas 😌 #dev #React #Electron View quoted note →

Using `html-to-image` was a mistake… I used it to generate the canvas objects so that the app could take a snapshot of the canvas, but the performance was horrible. After making a change in the canvas (e.g. moving an object), a denounce timer will run and afterwards, the canvas objects will be generated. Lastly, a snapshot will then be taken. This all happened using `html-to-image`. This caused a lag spike where the whole application froze for a few seconds.

Summer is amazing ☀️

I have a decision to make about how I will store the note documents in my app. The native Swift app stores the blocks in a flat JSON structure. This worked fine in the native macOS app, but now that I have also begun building the web app version in Electron, I have some issues because editors like TipTap and Lexical use their own structure, which is AST. That’s very different from my flat JSON structure. I’m probably just gonna switch over to the Lexical-way of doing it instead of my own. Bit annoying having to do that whole refactor now…