Getting an annoying bug in my Markdown editor where line spacing is acting weird but only for newlines right below headings... Then once I insert a character, the line spacing gets reset to the default/correct value. #dev #AppKit

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…

I love apps with an infinite canvas! #inspiration Here’s another one:

Trying to build your own Markdown parser is a horrible experience 😂 I tried once and quickly learned that there are just way too many edge cases to solve…