Frederik Handberg

September 💚 I love this month. I guess mostly because it’s my birthday month…

I think I finally figured out a solution to this annoying problem! 😅 🎉 I created a new separate project with a simplified version of the code only for debugging. **The solution:** It turns out that it's possible to wrap the `ScrollView` in a `GeometryReader` which calculates the total window space. Then I am using the value from the `GeometryReader` to calculate the total height without the header. The header is the blue box that contains the document name and information like word counter. The calculation is simply `geometry.size.height - headerHeight` and now I have the minHeight value for the `NSTextView`. It's even a dynamic value that updates when the user resizes the window. From web development, I'm used to just being able to say `width: 100%` and then it works, but with native development, it's not as easy 😂 #dev #Swift #AppKit nostr:nevent1qvzqqqqqqypzp8yls8khjhc0tma9tzfjsfrg0kz0cln2fnaxmdwk6w6sljmlltkzqyv8wumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdsq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsz9rhwden5te0dehhxarj9ehhsarj9ejx2asqyr9g82lm56tahhghu5h44adlc0tamcr8rwe5k28yd32054dgflfmw54wpq8

Will look at it again today. Hopefully I can find a solution. It can’t be this difficult just to get a `NSTextView` to stretch full height inside a `ScrollView`… nostr:nevent1qqs225p8uqu30nzeyh9p4jlze7ntyy55cz5xmekt7qj5sr6dnh5ukugzyzwflq0d090s7hh62kyn9qjxslvyl3lx5n86dk6ad5a4pl9hl7hvyqcyqqqqqqgpz3mhxue69uhkummnw3ezummcw3ezuer9wccskhlr

This is driving me crazy! I can't figure out how to make the green box fill all the available height... The green box is a `NSTextView`. I can obviously give it a fixed height, but I want it to be dynamic so it fills all the available height even when resizing the window. I'm wrapping it all inside a `VStack` which is inside a `ScrollView`.

Something that bothers me about #Obsidian is that (to my knowledge) it’s not possible to open a #Markdown document outside the vault. You must import the document into your vault before being able to edit it. I find that annoying. It should definitely be possible to open a document outside the vault/workspace to view and edit it. It will be a feature I will add to my notes app. I think, when opening a document outside the workspace, it should open in a separate window that doesn’t include the sidebar but only shows the document by itself. Otherwise I need to figure out a way to make it clear for the user which files are part of the workspace and which are external. nostr:nevent1qqsdlvl92uh9ccd5j7a3hcxvrvdl88kxl5sv2j0jkdldly0g33aazlszyzwflq0d090s7hh62kyn9qjxslvyl3lx5n86dk6ad5a4pl9hl7hvyqcyqqqqqqgpz3mhxue69uhkummnw3ezummcw3ezuer9wcmvpzd0

**Workspaces in notes app** In my notes app, I need to decide how to represent **workspaces**. It’s the top-level context where a user’s notes, images, and mood boards are stored. #Obsidian uses _vaults_, but it's really just a normal folder. I think that’s the way to go for my notes app as well. It’s really important that it’s portable and open, and because it’s just a normal folder, you can copy it anywhere. The idea is when the user opens a directory, the app treats it as a workspace and loads all notes, images, and mood boards from inside it. When a user pastes or drags an image into a note, the app will copy that image into the workspace directory instead of keeping a reference to its original location on disk. This is important because the image path would break if moving the workspace folder to a different location while the image isn’t saved in the folder itself. By keeping images inside the workspace directory, all paths remain relative and the workspace folder can be moved around freely without worrying about breaking paths.

**Multiple windows in notes app** It's currently possible to open multiple windows in the notes app that I'm working on, but each window is a mirror (it shows exactly the same), and this is obviously not the behaviour I want. Each open window should be completely independent from each other, allowing the user to have completely different directories/workspaces open.

I got infinite scrolling working on my Nostr blog. Now whenever reaching near the bottom of the page, new posts will be fetched. Now it’s past midnight and I’m tired. GN #Nostr 😴

I made a UI design of the search functionality I want to implement in my notes app. I think it looks pretty nice. I need to figure out how I can add some filters. For instance, if the user only wants to search in a specific folder. I have actually already implemented a search function in the sidebar of the app. It might be a bit redundant to have two search functions, but I think they still can complement each other. I'll keep it for now and figure out later if it still makes sense to keep it... #dev #Swift #Markdown nostr:nevent1qvzqqqqqqypzp8yls8khjhc0tma9tzfjsfrg0kz0cln2fnaxmdwk6w6sljmlltkzqy28wumn8ghj7mn0wd68ytn00p68ytnyv4mqz9nhwden5te0wfjkccte9ehx7um5wghxyctwvsq3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcqyzjfqstyyfvjwv8ekl253mmletvcusw6nmdtwl90tart2a0xq779q9874p9

Ngl making a lightweight replacement for MS #Word would be awesome. It feels so clunky and slow to use… #OPD format is probably the way to go for this, but I believe it’s pretty complicated, so not something I’ll be working on any time soon. First, I need to get my notes app fully working with features like #Markdown support, the visual canvas for brainstorming, and a search function similar to #Raycast. I have already implemented a basic search function in the sidebar which works nicely. Nothing special about it. But I do want something similar to Raycast, Arc Browser, and Spotlight on Mac. A search function that opens through a shortcut, perhaps CMD + SHIFT + F. It shows a search input in the center of the window with a beautiful blurry background. Then search results will show in a grid of three columns with previews for each search result. So for example, searching for a document, would show a preview of the text, image, or whatever content is inside the document (basically the first 5-10 lines). #dev nostr:nevent1qqszm35ugd843cmk8a0jkyldzqyfwas3jf6advam0j3exc58s3pnugqzyzwflq0d090s7hh62kyn9qjxslvyl3lx5n86dk6ad5a4pl9hl7hvyqcyqqqqqqgpz3mhxue69uhkummnw3ezummcw3ezuer9wcc5454z

Markdown is great for simple notes, journaling, and such, but if you need _advanced_ formatting then Markdown quickly starts to become too basic and limiting. Even something as simple as text alignment, you just can’t do in Markdown, unless you break the simplicity of Markdown and start introducing CSS. This is why I think, besides supporting Markdown in my notes app, having another format would be a good idea. Something more advanced. It needs to be non-proprietary, so it must be an open standard like #Markdown - perhaps #Asciidoc or #Pandoc Markdown. There are mainly two downsides to having support for multiple different formats in the app. Firstly, it takes longer to develop, and secondly, it makes it more confusing to non-technical people. The first downside is not so much of a problem imo. I’ll start with Markdown (which I’m already working on and have most of the essential formatting working), and then later, I can start implementing support for another format. I see the second downside as more of a problem. If users need to choose between two formats such as Markdown or Asciidoc, they are going to be like _“wtf is this?!”_ I probably need a little helper explaining the two formats…

Today I’ll get headings working in my #Markdown editor. I should also build some kind of dropdown menu with options to search the document, show word counter, and so on. Besides that, it would be nice to get shortcuts working to add/remove bold and italic styling by clicking `CMD + B` for bold and `CMD + I` for italic. I suppose text formatting should also be added as buttons in the menu bar. I have decided to continue with building my own parser instead of using a package like `swift-markdown`. I might switch to a package eventually, but it’s a good learning experience. #dev

Pro tip: if you have guinea pigs, don’t leave any cables near them… I learned that the hard way 😂

It might be a good idea to simply start by making a #WYSIWYG editor that writes and reads #Markdown files, but without the show/hide functionality of the Markdown syntax in 'live-preview' mode. Instead, I have now made an editor that only shows the rendered Markdown using `swift-markdown` package. I will also have a 'source mode' (this mode should show the raw Markdown without any formatting). Building an #Obsidian-style live-preview editor is so damn difficult. My current hack is to render the Markdown syntax at a font size of 0.01, which makes it look invisible. That works visually, but it breaks keyboard navigation, because the cursor still has to step through those hidden characters. For example, if I have **bold**, the two invisible asterisks (**) on each side are still in the text buffer, so arrow-key movement feels awkward as the caret gets stuck on them. This project is frustrating but I can't give up! I want this to work out 😂 #dev nostr:nevent1qvzqqqqqqypzp8yls8khjhc0tma9tzfjsfrg0kz0cln2fnaxmdwk6w6sljmlltkzqy28wumn8ghj7mn0wd68ytn00p68ytnyv4mqzxrhwden5te0wfjkccte9eekummjwsh8xmmrd9skcqg5waehxw309aex2mrp0yhxgctdw4eju6t0qqs0k5p3z5h24kp2dtg0u62svszq3jkancl44zdv7yfk8u6qp494r5q0wnzsp

I moved away from building my own #Markdown parser. Now I am trying to use the package called `swift-markdown`. It's certainly more convenient because it takes care of all the edge-cases. Now I just need to think about how I am going to hide and show the Markdown syntax when selecting some text with styling applied. I tried cheating a bit by making the syntax a size of 1, so that the characters are so small they become invisible. This worked, but if having double or triple asterisks (** or ***), then it will obviously create more spacing when hidden, because they are still there, just a very small size. I can definitely understand why there are so few editors that support live-preview the way #Obsidian does it... #dev

Working on complex problems is fun (like the #Markdown parser I’m building), but I feel like it’s so difficult to fall asleep because I can’t stop thinking about how I can solve whatever problem I’m working on 😂

I have the nested styling working with both **bold** and _italic_ styling applied. But the parsing logic seems to have trouble finding correct opening and closing asterisks. If I have something like "this ***text is* bold and** italic.", then the third asterisk in the beginning will always be visible - it doesn't hide like it's supposed to... I assume this is because, it has trouble scanning for opening and closing asterisks, otherwise, I don't know what it could be. But idk... maybe it's a simpler problem than I think. Will have to look into it tomorrow. Also, doing something like "this _text is italic **but some of the_ text is also** bold" doesn't work yet. There are quite a few edge cases to test and solve, and it's getting increasingly more complex. I am building my own parsing logic, which really isn't ideal considering how complex this stuff is getting. Had this been a JavaScript project, I would have just used a package for the parsing, but I haven't found a really nice one for #Swift... #dev #Markdown nostr:nevent1qvzqqqqqqypzp8yls8khjhc0tma9tzfjsfrg0kz0cln2fnaxmdwk6w6sljmlltkzqy28wumn8ghj7mn0wd68ytn00p68ytnyv4mqzxrhwden5te0wfjkccte9eekummjwsh8xmmrd9skcqg5waehxw309aex2mrp0yhxgctdw4eju6t0qqspu2th96csyzauh0nepzvm2k3r5h5pk6t6gjm6uxpyqjrtvmlxnucfenxda

Arc Browser has been a bit annoying lately for me. My tabs have been going dark. Like, literally just a dark page and refreshing didn't help... So now I'm back to using Brave Browser again.

Having some trouble with nested styles in my native #Markdown editor app that I'm working on for #macOS. In the example below _(see image)_, the parent element is bold styling and the nested child is italic. The child element is correctly italic as it should be, but for some reason, the bold styling does not apply to the child element as well. #dev #Swift

The reason why I am building an alternative to #Obsidian is simple: I want a native notes app for #macOS that supports #Markdown with live-preview. The **native** part is what’s important. I want something natively built for the macOS platform. I know there are native Markdown editors for macOS, but none of them support REAL live-preview. At least not that I could find. And believe me, I’ve been looking… They all have this side-by-side feature with the raw Markdown syntax on the left and the rendered Markdown on the right. I also have many more ideas, like building a moodboard with an infinite canvas for notes, links, images, and videos. **Basically, the perfect app for brainstorming new ideas!** nostr:nevent1qvzqqqqqqypzp8yls8khjhc0tma9tzfjsfrg0kz0cln2fnaxmdwk6w6sljmlltkzqy28wumn8ghj7mn0wd68ytn00p68ytnyv4mqzxrhwden5te0wfjkccte9eekummjwsh8xmmrd9skcqgkwaehxw309aex2mrp0yhxummnw3ezucnpdejqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcqyzmql5c78xx8jzz5yljjtave4668yyslan4txewqm74zm2794repkx9n8kh