Kristófer Reykjalín

How to make scrollbars from scratch

Sat, 05 Jul 2025 00:00:00 +0000

How to make scrollbars from scratch

Published on July 5, 2025.

I’ve been working on making a scroll view for libvaxis and calculating scrollbar dimensions in a performant way is hard. Or at least doing it in a general way when you don’t necessarily know the precise dimensions of the view makes it hard.

I couldn’t find any guides online for making your own scrollbar. Everything that came up was web related; CSS tricks for custom scrollbars, JavaScript implementations of scrollbars, etc. So I figured I might as well write this up and maybe someone will find this useful. And with some luck someone can tell me the actual best way to do this :)

Glossary

Let’s start by defining some terms:

Scrollbar: The whole thing you interact with.
Scroll thumb: The part of the UI that moves around to indicate the current position in a view. This fades out in most modern implementations of scrollbars.
Scroll track: The part of the UI underneath the thumb. Usually used to indicate where the scrollbar is, at least when it’s visible. Modern scrollbars don’t typically show this.

What do we need to know to make a scrollbar?

In theory, making a scrollbar is easy. You really just need to know 3 things and do some math from there:

The length of the content you’re scrolling through.
The length of the space you have to show content.
The distance you’ve scrolled so far.

If, for whatever reason, the space you have to show content is not the same size as the space you have for the scrollbar you need some more math, but not any more information.

Calculating sizes

Once you have these 3 things you just need to do calculations. Let’s call the content length l_c(for content length), the length of the space you have to show content l_v (for view length), and the distance you’ve scrolled so far d. What we need to calculate is then:

The length of the scrollbar thumb, l_t; and
the distance the thumb has moved down the scrollbar, d_t.

Both are proportional to the values we already know. The length of the scrollbar thumb in the scrollbar is proportional to the length of the view, and the distance the thumb has moved is proportional to the distance you’ve scrolled in the view.

l_t = l_v * ( l_v / l_c )
d_t = d * ( l_v / l_c )

So far so good, but the math is the easy part. The hard part is actually getting the lengths needed to do the math.

The big challenge: getting the values you need for the math

The biggest challenge is getting the correct height for the content. Generally speaking you need to draw the content to know the height it will occupy on the screen. Let’s assume for a moment that the content in the scrollview is massive. Let’s say something as big as a million elements. If you want your scrollview to be performant you don’t actually want to draw all of that every time. Instead, you only want to draw what’s going to be visible in the scroll view. That way you’re not wasting time drawing something that won’t be visible.

But this comes with a problem: now you don’t know the true height of the whole content, so you can’t get an accurate value for l_c (content height). And without an accurate l_c all of your other numbers will be wrong too, so your scrollbar will be slightly off at best, completely wrong at worst.

I couldn’t find a well explained solution to this problem online. I could’ve spent days digging through open-source projects, but the ones I looked at use a completely different paradigm when it comes to rendering than libvaxis does, and I didn’t feel like trying to learn a new codebase just to figure out if I could even use that approach. So I came up with a few solutions.

Solution 1: Measure the full height

This is the naïve approach, and it’s expensive. If you draw everything and measure the height you’ll have the most accurate l_c possible. You’ve gone through drawing things that aren’t visible, which is absolutely a waste of time, but you can draw the scrollbar properly now.

You can do things to mitigate the time you take for this. For example, you can store l_c between draws and only update it when the elements in the scroll view change. This will probably cause lag when a user is changing the elements though, because every time the children change you now need to redraw every single element.

Another way to approach this would be to do this calculation in a different thread so it happens in the background while other things are happening. This would remove the lag, but it adds a whole other layer of complexity that you may not want to manage.

I’d consider this an appropriate approach if you’re drawing content that doesn’t change or drawing relatively few items that are inexpensive to draw. "Relatively few" here depends on many factors, such as the elements you’re drawing, the platform you’re working on, and the hardware you’re working with, just like any other performance problem.

Solution 2: Estimate full height based on what’s been drawn

Counting the child elements should, in theory, be relatively inexpensive. That depends on the implementation, of course, but typically either you as the library, or whoever is using the scroll view, will know how many elements are in the scroll view.

Since we know how many elements there are in total, we can count the elements drawn in the currently visible part of the view, and use the average height of those elements to estimate how big the height of all the elements combined is.

If all the elements in the scroll view have roughly the same height and are evenly distributed, this should work pretty well. But the greater the variance in height is, the worse this will look. The scroll thumb will get jumpy, and may even start jumping back and forth as you scroll in a single direction. It’s not great.

I’d consider this an appropriate approach if you can be sure the elements have the same height — or something close enough to it. If that’s the case it doesn’t matter if the average height is a little off since it won’t be noticable.

Solution 3: Use proxy values to represent the heights

Instead of trying to work with the heights directly, it’s also possible to map the scroll thumb onto the scrollbar by using the indexes into the child element list to represent the heights and positions. So, instead of tracking the height of the current view, instead you track how many elements were drawn. And instead of tracking the distance you’ve scrolled down the view, you instead track how many elements you’ve scrolled past.

This effectively uses the indexes you’re working with as proxies you use to map onto actual distances in the scrollbar.

This does have the downside of possibly giving you an inaccurate size of the scrollbar thumb, and it can change while scrolling, if the number of elements on screen changes between draws, i.e. the height of the elements is inconsistent.

You could work around the jumpiness of the scroll thumb by doing something like keeping a running average of the number of elements on the screen to try to even out the estimated height. Generally speaking I think this is a strictly worse option than Solution 2, unless there’s something specific about your situation that makes this a good proxy.

In the case of libvaxis the number of elements happens to be a good proxy because we’re rendering things in a terminal, so the number of elements maps pretty well onto rows of text rendered there.

Solution 4: Cheat

Well, not literally.

The way I ended up doing this was to use Solution 3 and estimate the height of the content based on what’s being rendered, using the number of elements drawn and the total number of elements as proxies for the content height.

The cheating that we do is to ask whoever is using the library to provide an explicit height for all of the content. Since whoever is using the library will probably know the height of the content anyway, they might as well include it!

So you get the best of both worlds. If you don’t want to bother calculating the total height yourself — or can’t calculate it for some reason — the estimate is good enough for most cases, and pretty performant. However, if you do already know the total height we can skip the measurements and go straight to the math, which is very performant!

It’s not a perfect API, and far from seamless. But it works pretty well, and I’m quite happy with the solution as it is.

Interfaces are too vertical

Wed, 09 Oct 2024 00:00:00 +0000

Interfaces are too vertical

Published on October 9, 2024.

I find that many websites today — interfaces in general, really — are laid out vertically. Most of the time this is fine, but when it’s on pages focused on content, such as wikis, blogs, and even news websites, I’ve started wondering why?

It makes some sense of course, we generally read from top to bottom after all. But if the most important bit of the page is the content, why is a good quarter of the screen taken up by a logo, navigation, and potentially other elements that don’t add any value to the content?

I get this for mobile layouts or other screen sizes where you don’t have a lot of horizontal space. I still think taking up half the screen for a logo and navigation isn’t the best approach, but it’s understandable at least. On wider screens, basically anything other than a phone, you have more space to work with along the horizontal axis. And I think we should use that space! Bring those sidebars back!

This occurred to me as I was listening to an episode of the Arc Browser podcast. They’re working on the next major version of Arc and want to get to the core value statement of Arc. One of those, to me, is the sidebar layout. Having more space to read the pages I’m browsing improves the feel of the browser significantly. And stacking tabs vertically makes more sense to me than laying them out horizontally.

We consume content too-to-bottom, so why have the browser UI get in the way of that by putting it all above the web page you’re browsing? That’s getting in the way of you consuming the content on the page.

This doesn’t apply so much where the first thing someone might interact with is the navigation, but on something like a personal blog it seems to me that a sidebar makes sense. Where the navigation isn’t getting in the way of the content.

New site design

Having had all these thoughts I decided to make a new theme for the site! Again! The navigation is now on a sidebar if the page is wide enough. If not, the navigation appears underneath the content. There’s also a link at the top of the page to skip over the content straight to the navigation when needed.

This makes more sense to me personally. I never pay any attention to the header or navigation on pages I visit. I’m much more interested in the actual content.

I also made some strong stylistic choices with this theme. I’m only using named CSS colors, it only has a dark mode, and using magenta as the accent color is certainly a bit of a statement!

I hope you like it!

This site is now hand-crafted

Sun, 10 Mar 2024 00:00:01 +0000

You’re now looking at a complete redesign of this site, but it’s actually more than that. This site is now entirely hand-crafted in HTML. Or well, it’s actually PHP, but that’s just for the reusable parts, like the header and footer, but the posts are all handwritten HTML. Wild right? Why would I do that? Why would anyone do that?

I’ve been using WordPress to host my blog for years now, but it’s always felt a bit restrictive to do things the WordPress way. This way I have complete control over what my blog looks like and what the individual pages do.

I’ve also decided to not just redesign the look of the site, but also the content. Or rather, I plan to write about a wider range of things that interest me.

If you’re interested in learning more about the current design you can read my post about this design iteration. This post is more about the reason behind this redesign than the redesign itself.

Control

Let’s start by talking about the increased control this approach offers. By writing the site content entirely by hand I have full control over every individual page on my site. I don’t need to create custom templates or post types to get different looking pages. I just write the markup and there it is!

This also gives me room to experiment with other things, e.g. make hyper custom one-off JS components for just a single post or page. One example of this is the YNAB I’m working on which would be a pain to host on a WordPress site.

I can experiment with new web technologies and write a page in Svelte or React. I could play around with WebAssembly or in-browser database engines.

Writing the site by hand opens up a world of possibilities when it comes to what I can do on the site.

Hosting

Another aspect of improved control is hosting. Since the site is all simple PHP I can host it pretty much anywhere. I’m not bound to hosts that can deal with WordPress or some other CMS.

Sure, the host will need to support PHP, but honestly which website host doesn’t? That’s barely even a limitation.

I’ve decided to try the hosting offered by NearlyFreeSpeech.NET. Their DIY, bare-bones offering really appeals to my inner minimalist. And with the basic tech stack necessary to run this version of the blog it should cost me less than US$5 per year. That’s a really nice price point that’s tough to beat.

The downside is that they don’t do much for you, you really do get what you pay for. However, that works really well for me since that’s what I prefer anyway, but might not be for everyone.

History

Or, to phrase the title of this section more completely; the history of my blog. I redesign my blog often. I’m a little sad the history of those changes doesn’t really exist. I’ve tried to archive my posts after I make them in the WayBack Machine, but that doesn’t capture the redesigns when I don’t make new blog posts in between the redesigns, since I only archive posts once when they’re published.

So, I’ve decided that going forward, after a post is published, it will exist in that state forever. I will not be retroactively going back to update the styles in a post. Even the header and footer will remain the same. A redesign will start a new stylesheet and set of reusable functions, so old posts will remain unchanged. This way you can go back in time, not just in terms of content, i.e. older posts, but also in terms of site design!

I’m very excited to see how this will turn out.

Rough edges

As i mentioned, the site is all hand-crafted HTML, and I’ll admit: it’s a bit of a pain. The writing experience is certainly different. But I don’t post frequently to begin with and don’t plan to go on some posting spree now. A post every month or two is the cadence I’m going for.

Maintaining the RSS feed is also a bit tedious — yes, the RSS feed is also handwritten — but it’s not so bad. Mostly just copy-pasting the HTML from the posts to the feed file and making some minor style adjustments here and there.

And that’s really it. The writing experience is different, but this setup comes with so much freedom and control that it offsets the minor annoyance of doing things by hand. That’s also a solvable problem! I’m writing this in Paper, a Markdown editor with a wonderful writing experience, generous pricing model, and exports to HTML.

Once I’m done writing the post I can even use WorkingCopy to push the post from my phone to the git repo and clean it up later before publishing from my computer.

So far I’m very happy with this setup. The migration itself was a huge chore, but now that it’s done I think the whole setup is quite nice.

I’m very excited to see how this turns out once I have some more posts up and eventually redesign the site again. That’s going to be the real test for the setup.

March 2024 style refresh

Sun, 10 Mar 2024 00:00:00 +0000

While redesigning my website I needed a way to get a proper look at what the various HTML elements look like as I was making the changes, so I’m writing this post to do just that. I also want to mention some of the choices made in the design of the website.

The website only has a dark mode. I find that it’s much easier on my eyes, and easier to read any time of day. Especially so at night when I want to look something up real quick.

I decided to use the Atkinson Hyperlegible font for the body text on the site this time around. I like the way it looks and it is, at least supposedly, designed to be easier to read than other fonts. I find it nice to read myself and quite like the font. The headings use Charter, and the code examples use JetBrains Mono.

I’m quite happy with this mix of fonts, I think they go really well together.

The colors in use are all based on the Open Color palette. I didn’t want to come up with all the colors myself, so I decided to pick colors from there. I think this turned out quite nice.

There are some color combinations I’m not quite happy with, e.g. the <code> elements, but they’re not terrible. I’m also not quite happy with the colors for links. I’ll probably tweak these a bit in the future.

The stylesheet sets variables to control the various colors and spacings on the site, mostly intended to make it easy for me to tweak the design later. I don’t think this will be the final iteration of this particular design, but it looks good enough right now.

Having read a recent post from Bradley Taunt on sticky table headings I’ve gone ahead and made the table headers for the one table on this site sticky.

And finally I decided to append a little icon to external links. I chose to go with the ISO symbol for “Escape”, which looks like this: ⎋. You’ll see this icon appended to any external links on the site.

A look at the various HTML elements

This is an `h1` tag

This is an `h2` tag

This is an `h3` tag

This is an `h4` tag

This is an `h5` tag

This is an `h6` tag

This is a paragraph.

This is a link.

This is an external link to Wikipedia.

This is an item in an unordered list.
- This is a nested item in a nested list.

This is an item in an ordered list.
1. This is a nested item in a nested list.

This is a quote.

This is a code tag.

This is a pre tag.

// This has C++ code.
int main() {
	return 0;
}

// This has JavaScript code.
const fn = () => {
	return 0;
}

Info

This is an info notice.

Warning!

This is a warning notice.

Paged.js for creating printable documents with HTML and CSS

Mon, 05 Apr 2021 00:00:00 +0000

I just came across paged.js, a JavaScript library specifically made to make it easy to use HTML and CSS to make websites that look nice when printed or saved as PDFs, and it looks really interesting. The demo that lead to my discovery of the library looks especially appealing.

I think this might finally lead to me wanting to maintain my CV as a HTML document. Even writing other types of documents using paged.js sounds appealing. At a glance this seems much better, in my opinion, than using a typesetting system like LaTeX or an office suite like LibreOffice.

I’m really looking forward to taking this for a spin!

git send-email not working on macOS?

Fri, 26 Mar 2021 00:00:00 +0000

I just spent 2 hours trying to send a patch to a mailing list via git send-email on my MacBook Pro, and kept getting this error:

$ git send-email --to="<mailing_list>" HEAD^
Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=smtp.migadu.com encryption=tls hello=localhost.localdomain port=465 at /usr/local/Cellar/git/2.30.2/libexec/git-core/git-send-email line 1566, <FIN> line 1.

If you include --smtp-debug=1 in your command, you might see something like this:

$ git send-email --to="<mailing_list>" HEAD^ --smtp-debug=1
Net::SMTP>>> Net::SMTP(3.11)
Net::SMTP>>>   Net::Cmd(3.11)
Net::SMTP>>>     Exporter(5.73)
Net::SMTP>>>   IO::Socket::IP(0.39)
Net::SMTP>>>     IO::Socket(1.39)
Net::SMTP>>>       IO::Handle(1.39)
Net::SMTP: Net::Cmd::getline(): unexpected EOF on command channel:  at /usr/local/Cellar/git/2.30.2/libexec/git-core/git-send-email line 1539.
Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=smtp.migadu.com encryption=tls hello=localhost.localdomain port=465 at /usr/local/Cellar/git/2.30.2/libexec/git-core/git-send-email line 1566, <FIN> line 1.

After spending 2 hours trying to find a fix for this online, the solution turns out to be simple: set smtpEncryption to ssl in your git config.

See, I recently moved my email provider from Mailbox.org to Migadu, and as per Migadu documentation I set smtpEncryption to tls. No amount of tweaking configs, git send-email parameters, or updating perl packages seemed to fix the issue.

Finally, when I notice that my previous config used ssl instead of tls I tried to change the value and that worked!

So, if whoever lands here is having the same issue, just try setting smtpEncryption to ssl instead of tls and see if that works. Even if your email provider says to use tls.

Example configuration:

[sendemail]
	smtpServer = smtp.migadu.com
	smtpUser = <smtp_username>
	smtpEncryption = ssl
	smtpServerPort = 465

Managing your site with WordOps

Sat, 20 Mar 2021 00:00:00 +0000

WordOps is a wonderful tool, specifically made to make hosting WordPress websites easier, although they also provide excellent support for setting up and managing static sites, reverse proxies, and the like. It’s a wonderful tool for managing websites, and I highly recommend you use it.

I want to to take you through the steps necessary to install and configure WordOps, and launching your first WordPress site!

Before you get started

Make sure you have the following available before you start:

A server.
A domain that points to the server; I'll be using thorlaksson.com as the example domain in this post.

I’ll be using an Ubuntu 20.04 server with an expandable volume attached where I will host sites, which will require some additional setup.

Tip!

WordOps also supports Debian and Raspbian, if you prefer either of those over Ubuntu.

Mounting the volume for expandable storage

Note!

You can skip this section entirely if you don’t need to mount a volume and jump straight to the WordOps installation.

I’m using Hetzner to host the server, so these instructions will be specific to servers hosted with them. The process should be similar for any other service, but there might be a few differences.

First, delete your /var/www/ directory. If you already have things there you want to keep, make sure you back them up.

cp -r /var/www ~/ # For backup purposes
sudo rm -rf /var/www

Open your fstab file with your favorite editor and mount your volume there.

sudo nano /etc/fstab # to open the file with nano
sudo vi /etc/fstab # to open the file with vi

Add the following line to your fstab, and make sure to change the volume ID.

/dev/disk/by-id/<volume_id> /var/www ext4 discard,nofail,defaults 0 0

Your fstab should now look something like this.

# /etc/fstab: static file system information.
UUID=2B0E-1DC7  /boot/efi       vfat    umask=0077      0       1
/dev/disk/by-id/scsi-0HC_Volume_10143990 /var/www ext4 discard,nofail,defaults 0 0

Now, reboot your server, and ssh back into it.

sudo reboot

Once your server is up again, make sure the /var/www/ directory has the correct ownership setup.

sudo chown -R www-data:www-data /var/www

And now we’re ready to setup WordOps!

Installing WordOps

To install WordOps use ssh to connect to your server and run the installation command.

wget -qO wo wops.cc && sudo bash wo

This will install WordOps and its dependencies on your system.

Tip!

Many people are uncomfortable with piping scripts to sudo for a good reason. If you prefer you can clone the repository from git and install it that way:

git clone https://github.com/WordOps/WordOps.git
cd WordOps/
sudo bash install

WordOps also provides a set of fully manual installation steps if you prefer to really do everything yourself.

WordOps requires super user privileges to manage everything for you, so it’s a good idea to add a command alias to automatically run the wo command with super user privileges.

echo -e "alias wo='sudo -E wo'" >> $HOME/.bashrc

Now that the wo tool has been installed, we use WordOps to install the technology stack used to run the websites. You can see precisely what will be installed here.

wo stack install

During this installation WordOps will create credentials for the administrative dashboard, but we’ll change those with the next command.

wo secure --auth

You’ll be prompted for a username and password. Generate a strong password with you password manager and save it there.

Remember to enable the firewall too!

wo stack install --ufw

Now, you should be able to look at the admin dashboard at https://<domain>:22222. In my case, that’s https://thorlaksson.com:22222.

The SSL certificate won’t be valid for the admin dashboard, but don’t worry about that; that will be fixed when we create our first site.

Creating your first WordPress site

Now it’s time to setup a WordPress site! 🎉

Run the site create command with a couple extra flags.

wo site create thorlaksson.com --wp --php74 --user=<wp_admin_username> --email=<admin_email> -le

--wp to setup a WordPress site.
--php74 to use PHP 7.4.
--user=<wp_admin_username> to choose the admin username we want.
--email=<admin_email> to set the email for the WordPress admin user.
-le to enable Let’s Encrypt and SSL.

Once that command has wrapped up you should have a WordPress site ready to go, with the username and password to login printed out during the installation.

Tip!

I created a simple WordPress site here with no caching set up. You can change that by replacing the --wp flag with any of the other WordPress flags to set up caching with WP Rocket, Redis, or any of the other caching solutions supported.

I recommend you change the admin password immediately when you first login to the WordPress site. Use your password manager to generate something stronger than the password generated by default.

Before we login though, let’s install some essential plugins, with WP CLI — a tool WordOps installed for us! Just make sure to run these commands with sudo or as www-data.

wo site cd thorlaksson.com
cd htdocs
# You should now be in /var/www/<domain>/htdocs

# Now let's install some plugins
wp plugin install akismet --allow-root --activate # To prevent comment spam
wp plugin install gutenberg --allow-root --activate # To use the latest version of Gutenberg
wp plugin install two-factor --allow-root --activate # So we can use 2fa for website accounts
wp plugin install wordpress-seo --allow-root --activate # For SEO

# Fix permissions
sudo chown www-data:www-data wp-content -R

You can use commands like this to automate the setup of new sites. If you manage multiple sites, or setup new sites on a regular basis, having a script to set everything up for you is an amazing boon.

Of course, you can remove or add plugins here as you like, or simply do this all through the WordPress dashboard.

Finally, let’s make sure everything on the server is up to date. You can run this same command whenever you want to install updates on your server.

wo maintenance

And that’s it! Your WordPress site is now ready at https://<domain>!

Conclusion

WordOps is an extremely versatile tool for website hosting, especially if you’re managing a WordPress site, or even multiple WordPress sites. I personally use this to great effect to set up testing sites at work.

WordOps is also useful for just managing your web server’s reverse proxies or static sites. I didn’t talk about this much here, but refer to the documentation for how to set those up.

Being able to spin up a site quickly without having to worry about managing a web server, keeping dependencies up to date, setting up a database, and securing everything saves so much time.

Finally, you can just focus on managing a website instead of managing a server.

"On the experience of being poor-ish, for people who aren't"

Tue, 02 Mar 2021 00:00:00 +0000

"On the experience of being poor-ish, for people who aren't" is a fantastic article about the experience of someone figuring out how to survive when you’re borderline broke. Broke in the literal sense. The "I had to choose between feeding my family or paying for electricity so I could work from home" kind.

But consider that this is a choice I have to make – do I spend 50% more on an apartment and stress my budget to death, or make my wife and kids in a place where I have 5 front doors within 15 feet of ours in the murder-iest part of town? Neither choice is great, but the lack of intermediate choices forces you to do one or the other.
"On the experience of being poor-ish, for people who aren't"

I think it’s really hard for many people to wrap their head around just how difficult it can be to be in that sort of situation. And it seems to be even harder to make your way out of it.

I find this an especially healthy read for myself. I wouldn’t classify myself as rich, but I’m fortunate enough to have never had any financial troubles in my life. It’s difficult for me to truly understand what it’s like to be so poor.

Learning more about the struggles of being so incredibly close to not being able to provide for yourself and your family is incredibly humbling. It makes me feel extremely thankful for how lucky I am. For how lucky I’ve been.

I also wonder how we can bring about lasting change? No one should be forced to make a choice between the ability to work or feeding your family; between food or water; between starving or dying of thirst.

How do you share photos with your family?

Wed, 20 Jan 2021 00:00:00 +0000

For the last several years I’ve been living far, far away from my family, and — as is to be expected — they want updates! Photos and such. Moments. I’ve never really been any good at sharing those, but I would at least posted something occasionally while I had Facebook and Instagram accounts. Now that I’ve deleted those accounts I’m not sure how to go about sharing moments from my life with them.

Another aspect to this is that I don’t receive any updates from them. If my wife didn’t have Instagram and Facebook I’d have no idea what was going on, except for news arriving through my parents.

I could, of course, do something like sending out a newsletter every month, adding photos to some shared cloud service, or set up a different blog that’s only intended for family. But that’s mostly one-way communication. There’s no sense of sharing things with your family. They might as well be random people on the internet.

I’m not a big fan of those solutions. I just want to share some photos and videos with a short caption. Maybe a quick status update every now and then. Does that really have to be this hard?

I guess I could create profiles on either Facebook or Instagram (ew 🤮). “Traditional” social media would certainly make this easier, but I don’t want to use social media to share personal moments in my life. I just want to share things with my friends and family.

There are things like Pixelfed that aim to replace services like Instagram with a more privacy friendly alternative. I even set up an instance to try it out, and that’s been going pretty well, even though the user experience is clunky right now.

My problem, however, with Pixelfed is that it’s trying to be Instagram. Part of the mission statement there is discovery; other people can view all your public posts. It’s an open platform where anyone can follow anyone. You don’t even need an account to see posts.

I want something private, something personal; just for my friends and family. I don’t care about the thoughts of the world. Quite frankly I don’t even want to share these moments with the rest of the world. Why would I?

Another side to this is that I don’t care about likes or notifications or boosts or retweets or favorites or “hey, you might know this person!”. Comments and discussion can be fun, but I could do without all that other fluff.

I just want to share some photos and videos with the people closest to me, and maybe have a quick chat with them about those moments. But there’s just no good way to do that.

Maybe something will come along soon. I wouldn’t bet on it, but who knows?

How do you, dear reader, approach this? How do you let your family know what’s up with you?

How to fix blurry text in macOS applications

Thu, 17 Sep 2020 00:00:00 +0000

macOS is my operating system of choice, so when I’m working on projects that use a GUI I like to build macOS application bundles. This allows me to have some flexibility when it comes to running the app. However, every time I run these bundles for the first time the text in the app is blurry, and I keep forgetting why that happens.

This problem will inevitably come up again, so I’m documenting the solution here. I can’t say I’m very interested in spending hours searching for a solution. Again. Sigh.

Solution: support high resolution displays

Add the following to your Info.plist

<key>NSHighResolutionCapable</key>
<true/>

such that the file will look something like this

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSHighResolutionCapable</key>
	<true/>
</dict>
</plist>

There will be other items in the file, but that’s where you want the key-value pair to be; in the dict object.

If you’re using PyInstaller like I currently am, you can add this to the info_plist dict in the specification file:

app = BUNDLE(
	info_plist={
		"NSHighResolutionCapable": True
	}
)

Why is this necessary?

macOS uses the Information Property List (Info.plist) to identify various capabilities of the app in question, including whether your app supports high resolution displays via the NSHighResolutionCapable property . I imagine the text looks blurry because macOS renders the app at low resolutions when the property is not defined or is set to False.

So by setting the property to True you’re letting macOS know that “hey it’s ok to render this app at higher resolutions”. Once the app is rendered at a higher resolution the text will no longer be blurry! Success!

The End of History

Sat, 15 Aug 2020 00:00:00 +0000

In “The End of History” [non-YouTube link] Kyle Hill talks about how we live on the brink of extinction to prevent an all-out nuclear war. I found the video to be an interesting, and thoughtful, take on this weird situation we find ourselves in, and the whole mutually assured destruction doctrine.

It’s both amazing to think about the power we as a species wield, and terrifying to think about how easy it would be to cause our own extinction. And I don’t think there’s a word strong enough to describe the terror I feel when thinking about how close we’ve come several times. Governments around the world need to think really, really, hard about whether this is sustainable.

Is whatever conflict that happens to be “the biggest threat of your time™” really worth not just your and your opponent’s existence, but also the majority of life on earth?

Build your own text editor with Reason — Getting started

Mon, 27 Jul 2020 00:00:00 +0000

Warning!

As of September 29, 2020 I’ve decided to put this project on hold for a bit, until the Revery team addresses an issue with their ScrollView component. While it’s not a showstopper, the UI wouldn’t really work without it. I’ll be back on this as soon as the issue is addressed!

I’ve been thinking a lot about text editors lately, going so far as to playing with writing my own. In the process of exploring that idea I came across a tutorial written by Pailey Quilts on how to build a text editor in C. It’s a great write-up that thoroughly explains the code behind kilo, a simple terminal editor.

I’ve been writing code in Reason in different projects lately and I’m quickly falling in love with the language. I find the developer experience very pleasing, and I absolutely love the type system. I’ve also been keeping my eyes on Onivim 2, a new text editor that aims to have the usability of VSCode with the utility of Vim — an ambitious project to say the least!

It just so happens that Onivim 2 is built with Reason! More specifically, it’s built with Revery, a GUI framework that came to be because of Onivim 2. And all of this got me thinking; what would a kilo-like editor look like when made with Reason and Revery?

So, here we are. My take on Pailey’s tutorial, except instead of writing a simple terminal editor in C, you’re going to write a simple GUI editor in Reason!

Tip!

All the code and incremental changes will be published in ~reykjalin/kilo-gui.

Setup

Just like in Pailey’s post, the first thing you’ll want to do is to set up your environment. To build GUIs using Reason and Revery, you’ll need to install Esy. Esy is a package manager and build tool, similar to Node’s npm, but built for Reason and OCaml.

How to install Esy

The first thing you’ll need is Node. The LTS version will do just fine. Node should come with npm, and it’s really npm you need. You’ll use npm to install esy.

$ npm install --global esy

You may need to run this command as an administrator, in which case you’ll need to add the --unsafe-perm=true flag.

$ sudo npm install --global esy --unsafe-perm=true

I’d recommend you try running the test project they’ve set up to make sure esy is installed correctly. You can find instructions on how to do this in Esy’s getting started guide.

Creating a Revery project

The simplest way to get started with a new Revery project is to clone the Revery quick start project, and go from there.

$ git clone https://github.com/revery-ui/revery-quick-start.git

I’ve found that the dependencies tend to be out of date here, and there might be some key differences in the Revery API between the version installed in the quick start vs. the latest version of Revery, so the first thing you’re going to do is update all the project dependencies.

Updating the project dependencies

The current dependencies can be found in package.json in the dependencies and devDependencies objects. The dependencies should look something like this

/* package.json */
"dependencies": {
	"revery": "revery-ui/revery#8fd380c",
	"@opam/dune": "2.5.0",
	"@glennsl/timber": "^1.2.0",
	"esy-macdylibbundler": "*"
},
"devDependencies": {
	"ocaml": "~4.9.0",
	"@opam/ocaml-lsp-server": "ocaml/ocaml-lsp:ocaml-lsp-server.opam#04733ed"
}

Finding the newest versions for your dependencies can be a bit tricky, so here is how I found the newest versions:

Revery‘s latest commit hash is 1531d5f.
dune‘s latest version is 2.6.1.
OCaml‘s latest version is 4.10.0.
ocaml-lsp‘s latest commit hash is b017b14.
Timber is already using the latest version.
The * in esy-macdylibbundler means the latest version will be installed.

So after we update package.json the dependencies should look something like this.

/* package.json */
"dependencies": {
	"revery": "revery-ui/revery#1531d5f",
	"@opam/dune": "2.6.1",
	"@glennsl/timber": "^1.2.0",
	"esy-macdylibbundler": "*"
},
"devDependencies": {
	"ocaml": "~4.10.0",
	"@opam/ocaml-lsp-server": "ocaml/ocaml-lsp:ocaml-lsp-server.opam#b017b14"
}

Updating the project metadata

Updating the project metadata to fit your needs is usually a good idea. You should use this chance to do exactly that! You can find this project metadata in package.json.

/* package.json */
{
	"name": "kilo-gui",
	"version": "0.1.0",
	"description": "A simple GUI editor built with Revery",
	"license": "MIT",
	"scripts": {
		"format": "bash -c \"refmt --in-place **/*.re\"",
		"run": "esy x Kilo"
	},
	"esy": {
		"build": "dune build -p Kilo",
		"buildDev": "refmterr dune build -p Kilo",
		"buildsInSource": "_build"
	},
	"revery-packager": {
		"bundleName": "Kilo",
		"bundleId": "com.thorlaksson.kilo",
		"displayName": "Kilo",
		"mainExecutable": "Kilo",
		// ...
	}
}

The changes I’ve suggested here mean you need to rename src/App.re to src/Kilo.re, and change some of the dune files to accommodate these project changes. It’s a bit tedious to list all of those here, so I’d recommend you look at the commit where I make these changes instead.

Building the project

The first build after updating your dependencies needs to be completely clean, so before doing anything you should delete the esy.lock directory, which is used to lock the dependency versions in place. If you don’t delete this directory now, esy will not update the dependencies, despite the changes in package.json.

$ rm -rf esy.lock

Now you can build the project by running esy.

$ esy

Running esy will install your dependencies and build your project. This first build will take a while since esy will actually build all the dependencies for you. esy caches your built dependencies so subsequent builds will be close to instantaneous. You just need to suffer through this long build time the first time you build your project.

And now you can run the project!

$ esy run

Tip!

This command will both build and run the project for you! No need to run 2 commands, yay! 🎉

And you should be greeted with the default quick start app!

Make room for your own work

The last thing for you to do is remove all the unnecessary code, and start with a clean slate. This is relatively simple; delete src/AnimatedText.re, src/SimpleButton.re, and src/Theme.re, and then modify src/Kilo.re. to remove the unnecessary Style, and reduce the main app component to an empty component.

/* src/Kilo.re */
let main = () => React.empty;

Finally, you need to remove the dependency on Theme.re by changing the win variable to

/* src/Kilo.re */
let win =
	App.createWindow(
	app,
	"Kilo",
	~createOptions=
		WindowCreateOptions.create(
		~backgroundColor=Colors.white,
		~width=512,
		~height=384,
		(),
		),
	);

Now when you run the program you should see an empty window—a great place to start a new project!

Going forward you’ll want to build and run the app to see the changes in action and make sure you didn’t accidentally break something. Like Pailey says:

It is easy to forget to recompile, and just run ./kilo, and wonder why your changes to kilo.c don’t seem to have any effect. You must recompile in order for changes in kilo.c to be reflected in kilo.

The same can be said here! Make sure to run the app after making changes!

The next post will be up soon!

I'm changing the default branch name in my git repositories, and you should too

Thu, 25 Jun 2020 00:00:00 +0000

There’s been a bit of an uproar in the software development community because it’s been brought to everyone’s attention that the default branch naming convention of master in git isn’t exactly appropriate.

This was first brought to my attention at work with a link to a post from Scott Hanselman about renaming your default git branch in response to the IETF pointing out that the master-slave terminology is both “inappropriate and arcane” as well as “technically and historically inaccurate”.

Many teams at work have decided to change the default branch names in their repositories, and I’m pretty sure that will end up being a company-wide change. Even GitHub is planning to change the default branch to main.

Having thought about this for a while I wholeheartedly agree with this decision, and I will be changing the default branch names in my own repositories to main.

But before we go any further let’s take a look at what the actual problem with the status quo is.

What’s the problem with `master`?

As far as I’ve been able to gather, the origin of the default branch name in git comes from a different version control system called BitKeeper. BitKeeper’s naming convention is based on the master-slave relationship.

This is problematic because of the racist subtext inherent in that metaphor, the historical context of which should never be forgotten.

The use of such terms [racist language] does not merely reflect a racist culture, but also serves to legitimize and perpetuate it.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/

I think it’s pretty safe to say that no one intends to legitimize and perpetuate racism, but just by using the language you become part of the problem, no matter whether that’s intentional or not.

I have no interest in being part of a community that accepts and encourages racist language—and racism by proxy—and neither should you.

So how do we address this?

The first thing we as a community need to do is recognize that there’s a problem here. Only then can we start to work our way through the issue, and come up with and implement solutions.

In this particular case the solution is easy. Just change the default branch name in your repositories. Stop using master-slave terminology. Try your best to stop using racist language in your day-to-day life, accidental or otherwise.

This will, of course, take a bit of getting used to, but I’m 100% sure that’s something everyone will get over quickly.

main, primary, default, production, leader, active are all reasonable alternatives. Having thought on this a bit I’d argue that main, primary, and default all describe the general purpose of the default branch much better than master ever can. Those terms don’t rely on metaphors; they describe the actual function.

The IETF has more suggestions that are appropriate in other contexts.

Counter-arguments

In my opinion, all of the arguments against this change ignore the fact that there exist better alternatives that describe the function of the default branch in a much better way than master can.

They also seem to ignore that this change is small, and will only need a slight adjustment on your part. For people that already find the master branch offensive this will be a huge change for the better.

Weighing those two against each other should make the choice obvious. The tiny bit of discomfort this will be for you is entirely worth the gain this will be for someone else.

But let’s discuss some of the actual counter-arguments I’ve seen floating around.

Many tools rely on `master` as the default branch

No, they probably don’t. I’ve seen people say this, and this worried me too. However, I’ve yet to see a tool that breaks when the default branch isn’t master.

Let’s all be honest here. If the tool breaks when you change the default branch, it frankly needs a lot more work, and you probably shouldn’t be using it for your super important project.

The `master` branch isn’t related to slavery, but a “master copy” from the recording industry

At this point the origin of the term no longer matters. Even if the master-slave metaphor wasn’t the original intent behind the phrasing, the fact of the matter is that the metaphor is now associated with the master branch naming convention.

Avoiding the use of `master` will only give more meaning to the racist undertones of the word

Here’s a newsflash for you: the word is already associated with racism. Using the word will not neutralize that association.

Try applying this reasoning to other racially charged words, especially ones that are already widely accepted to be racist. Is this really an argument you want to make?

Changing the branch name won’t change society

No, it probably won’t. But then again, that’s not the point of the change.

Language and terminology with offensive subtexts directly affects people’s perception of the content. As such, we shouldn’t be using language with offensive subtexts. It’s that simple.

Complex and subtle configurations of sexist, racist, or ethnocentric language use in technical documents can derail or interfere with readers’ ability and desire to comprehend and follow important information.
https://doi.org/10.1080/10572259809364639 (emphasis mine)

The point of this change is to make the software development community more welcoming to all, no matter what their background is.

If changing the default branch name will make even one person feel more welcomed and comfortable, then the change will have been worth it.

Final words

This small change could make someone’s day. It could make them ecstatic. This might be something that’s been causing them discomfort for a long time. Think about that someone. Isn’t a bit of temporary discomfort a tiny price to pay for that someone’s happiness?

Do the right thing.

Be the change you wish to see in the world.

We but mirror the world. All the tendencies present in the outer world are to be found in the world of our body. If we could change ourselves, the tendencies in the world would also change. As a man changes his own nature, so does the attitude of the world change towards him. This is the divine mystery supreme. A wonderful thing it is and the source of our happiness. We need not wait to see what others do.
Mahatma Gandhi

A new code editor?

Thu, 28 May 2020 00:00:00 +0000

I’ve written before about how I’m not happy with the code editors available today. I think they can be improved upon, so I’ve started experimenting with making my own. I don’t think this will ever be the shiny new code editor on the block, but I’m hoping it’ll at least be something I’d prefer over other editors.

I’m currently calling this project Qode, but I might change that further down the line—especially since I’ve already seen other similar projects with the same name.

I’m not sure how far I’ll take this, and might not even make this a huge thing, but I want to outline part of the vision for this editor. I think doing so will help me stay focused on what to work on next, and whether I’m spending too much time digging into something I don’t need to think about.

So, without further ado, let’s get into it.

Graphical interface please!

I dislike the limitations of terminal editors, and as such I want the editor to have a graphical interface (GUI). That said, I also want this interface to be minimalistic. Most of the time it shouldn’t be showing you anything beyond what a terminal editor would show you.

What I mean by this is that most of the time the only thing visible in the editor should be the text editing window itself. No toolbars, no sidebars, no fluff.

That doesn’t mean those won’t be available, mind you! Just that they shouldn’t be visible by default. Instead, you should be able to bring them to focus with a keyboard shortcut (e.g. double-tap tab, hold shift, etc.) or a single mouse-click/hover action.

I want the editor to get out of the way when you’re writing code, and I think modern editors fail when it comes to this, what with all their sidebars and toolbars.

Keyboard driven

I want the GUI to be fully accessible with just a keyboard. Or at the very least, you should be able to control every aspect of the editor with a keyboard.

I’m not really talking about navigating menus with a keyboard (although that should be possible either way), instead I’m thinking of a sort of command mode, similar to Vim, Emacs, and Kakoune. The commands should allow you to do anything you might otherwise do by navigating through a bunch of GUI menus.

Taking Vim as an example here, you enter command mode by typing : while in normal mode. You can then type write and hit the return key, and that’s how you save the file you’re currently working on; by typing :write<ret>.

Mouse driven

Yes! Also fully mouse driven!

I want to be able to fully navigate the editor with only my mouse. Sometimes I like doing that, e.g. when I’m just browsing through the codebase, or messing with some settings.

At other times I’d like to be able to use the keyboard, e.g. when I’m already working on some code and I want to quickly switch to a different file, jump to a definition, etc.

And sometimes I have one hand on the keyboard and the other on my mouse. That should limit me as little as possible.

The whole goal here is to make the editor equally accessible with multiple input methods.

Functionality driven by plugins

This is probably the most difficult part to design and implement. I want to allow plugins to control every aspect of the editor; rebind keys and actions, open/close dialogs, add configuration options, etc.

The editor should have default functionality relevant to the core usage of a code editor, but every aspect of that default functionality should be extendable with plugins. The system should even allow you to completely re-implement how some things work.

The example that’s at the forefront of my mind all the time is rebinding keys. Or rather, changing the input handling. It should be easy for plugins to create modal editing modes, like what Vim and Kakoune do. That means you’re not just rebinding keys, the plugin should be able to change the whole input handling for the editor.

Another example of a plugin would be a frontend for debuggers. Allowing the user to set breakpoints, step through code, etc.

Aside from the ambitious scope of this plugin system I also want plugin support to be programming language agnostic. If you want to write a plugin in Java, go for it. Haskell? No problem. C? You got it boss!

This, of course, essentially means that plugins must be standalone executables or scripts. There’s no other way to make this happen unless you rebuild the editor. As a result, the plugins need to communicate with the editor somehow, and I think I’ll use the json-rpc protocol to achieve this.

Initial goals

What I’ve outlined here is already pretty ambitious, and would take a long time to implement properly. Because of that I want to limit the scope to a sort of minimally usable editor for myself:

Syntax highlighting.
Support for TextMate/VSCode color themes.
Auto-completion via the language server protocol (LSP).
Project overview bar.
Support for basic plugins
- The benchmark here is to support plugins that change the input handling.

I haven’t yet decided what will be part of the core editor and what will be implemented through plugins. Especially the syntax highlighting and LSP support. I guess that’s something I’ll need to find out along the way!

What’s happening with this now?

Despite the fact that Electron apps work fine most of the time, I dislike the idea of Electron when it’s not required (hint: it almost never is). As such I chose to find a suitable GUI framework that’s closer to being native, and that doesn’t leave me with many options.

I chose to go with C++ and Qt. The Qt framework is mature, looks nice on all platforms, comes with a lot of good stuff, and I’ve worked with Qt before.

At the time of writing I have a working proof of concept available built with QScintilla as the editor widget. Input handling is managed with a plugin, and so is syntax highlighting and TextMate theme support.

Right now I’m looking into whether I should continue to use QScintilla, or whether I should use Scintilla or KTextEditor. My main gripe with QScintilla is that it’s based on a relatively outdated version of Scintilla. QScintilla is based on Scintilla v3.10.1, which was released in October 2018. That version of Scintilla is the LTS version, but it’s still several LTS versions behind, the latest one being 3.11.2.

I’m leaning towards using KTextEditor since that gives me a bunch of nice things out of the box, but that will really only work if there’s an easy way to include that in the project.

Once I’ve explored what it’s like to use some of the different editor widgets, and made up my mind as to which one I’ll use, I’ll work on LSP support and re-evaluate how far I want to take this after that.

Here’s to hoping this project isn’t way too ambitious.

How I protect my privacy online

Mon, 20 Apr 2020 00:00:00 +0000

This post is in no way meant to be a guide or tutorial on how to protect your privacy on the internet, and neither is it a guide to staying completely anonymous online. However, this could be a good starting point for others interested in online privacy, so I wanted to share my general approach to online privacy.

I don’t have a strict need to hide what I’m doing online, but generally I want companies to know as little about me as possible. It’s not the end of the world if they do have some information about me, so long as they can’t predict my wants and needs before I even realize they’re something I want or need.

This means that—as much as possible—I don’t want to be served ads, and I don’t want companies to track what I’m doing online. Google and Facebook run some of the biggest ad networks on the internet, and have a horrible history of literally selling your data to anyone that’s willing to pay for it. As a result they are the top 2 companies I want to avoid.

No more Google

I try my best to not use any of Google’s services. This means no Google search, no GMail, no Google Drive, no Google Docs, etc. There are plenty of alternatives out there, and I’d like to highlight a few here.

So how do I find stuff online?

I’ve been using DuckDuckGo for a while now with great success. There are still some cases where Google’s results are miles ahead of DDG, but I can use DDG for the vast majority of my online search needs.

February 2024 update

I’m currently using Kagi and really like it, but DDG is a much stronger general recommendation.

April 2025 update

I was subscribed to Kagi for a long time and would recommend it easily. However, I’ve had to reduce the subscriptions I’m paying for in my life, and Kagi was one of the first to go. DuckDuckGo is good enough for the most part, although I find myself resorting to Google more and more. I also try to use Marginalia Search, an independent search engine for the small web, and like it for what it is. It does not, however, replace a general purpose search engine like DDG or Google.

But what about e-mail?

GMail serves you ads directly to your inbox in their mobile app. That’s such a huge violation of what an e-mail provider should do that I have no words to express my disgust. It’s abhorrent.

I’ve stopped using my GMail account in favor of a more private e-mail provider: Mailbox.org. I then use aerc to read my e-mails on my computer, and the Apple Mail client on my phone.

What Mailbox.org has over many other e-mail providers is that they support encryption out of the box in their web UI, and that’s why I initially chose them as my provider.

I’ve since realized encryption in the web UI isn’t something I really need. This setup is good for day to day use, but I find the Mailbox.org web UI to be very frustrating to use when I occasionally need to use it. As a result I’ve been looking for a simpler setup. Currently I’m eyeing both Fastmail and Migadu, both of which seem to have this figured out.

I also have a ProtonMail account that I don’t really use, but I’ve considered using them as well. Their service is solid but what’s holding me back is how difficult it is to not use their web UI. Due to how they encrypt their e-mails you need to run a software bridge on your computer so your e-mail client can talk to ProtonMail.

February 2024 update

I eventually decided to use Migadu for myself and Fastmail for my wife. I can wholeheartedly recommend both, although Fastmail is expensive and Migadu is aimed at a more technical customer than the general public. A better general recommendation might be something like Zoho, which I’ve heard decent things about, or Purelymail, which I’ve only heard good things about.

If I were setting up an email account for myself today I’d probably use Purelymail, but currently I like the control Migadu offers over how addresses on my domain work. I don’t know if Purelymail offers similar levels of control and simply don’t have a reason to check.

I don’t think I’ve ever used my ProtonMail account since writing this post, but maintain it anyway as an additional email account in case I need it, e.g. for recovery purposes.

April 2025 update

I recently had to reduce the cost of subscriptions we were paying for so I’ve moved all our emails to Purelymail. It’s US$10 per year, which is significantly lower than even Migadu. Purelymail has fewer features than Migadu offers, but I find that it’s more than enough for my purposes.

And how do you even access the internet?

Google Chrome is an amazing web browser and especially so in terms of its developer tooling. However, the tracking it forces on you ruins all of that. It constantly rings up Google’s servers, automatically logs you into your Google account, and tracks your browsing history. Google will then use that data to serve you targeted ads everywhere they can. As much as Chrome impresses me on the technical side, the tracking inherent in the browser ruins it completely.

Mozilla Firefox has been my browser of choice for ages—even before I started thinking more about online privacy. It’s the browser I recommend to most people, and I don’t think that will change anytime soon. However, recently I’ve come to realize that Chrome works far better for my browsing experience, especially while working.

As a result I’ve been using the Brave browser. It comes with really good privacy settings out of the box, and is based on Chromium. That’s the same browser Google Chrome is based on, so they work mostly the same. Brave comes with integrated ad-blocking and has HTTPS Everywhere enabled by default, so there’s no need to install extensions to get that functionality.

On top of using browser features to reduce tracking, I also use AdGuard as my DNS provider. AdGuard’s DNS blocks ads before they ever get to my browser, so my browser can focus on cleaning up what slips past AdGuard.

I also highly recommend Ungoogled Chromium. It’s a custom built Chromium that blocks the tracking introduced by Google in both Chromium and Google Chrome.

When I use Firefox and Ungoogled Chromium I use several extensions to block trackers: uBlock Origin, Decentraleyes, and HTTPS Everywhere.

February 2024 update

I think I will forever be jumping between browsers. I currently use Arc for the user experience it offers. I have a general preference for browsers that don’t use Chromium because we desperately need more browser engine diversity on the Internet, but unfortunately I haven’t found a browser that works as well as Arc for my purposes.

I did briefly use Orion, which is based on WebKit (the engine Safari uses), and it’s the browser that has come closest to Arc for me, but unfortunately just didn’t work as well as Arc does. The UX of Arc is just that good.

Firefox is still the best general recommendation for a “classic” web browsing experience.

April 2025 update

Like I predicted, Arc didn’t stick. I’m now using Zen, a Firefox-based browser that has learned a lot from how Arc’s UI works and applied it to Firefox. I find that Chrome is generally better supported, so some services I still have to open in Chrome, but for the most part Zen (and Firefox) just work!

These days I’d easily recommend Zen over every other browser out there.

No more Facebook

This one has been one of the hardest things to move away from, not because I use Facebook a lot, but because where I’m from the community runs on Facebook. If you’re not on Facebook you don’t get invites to events, and people have a hard time reaching you (maybe they’ve never heard about mobile phones?). As a result you generally just miss out on what’s happening around you.

As much as that frustrates me, I don’t really mind missing out on most things in my community; I hear about events through my friends and family anyway. What does frustrate me however, is that I can’t get away from Facebook Messenger. If I where to delete my Facebook account, most of my family and friends wouldn’t be able to reach me.

I don’t live in my home country anymore, and haven’t for the past 3+ years at the time of writing. That means family and friends can’t call or text me by phone, leaving online communication as the only viable option. Since everyone is already on Facebook everyone uses Facebook Messenger to communicate. I really don’t want to force people to install an app just to talk to me, although I made an exception to that rule for my parents and close friends 🙂.

The vast majority of online conversations I have are with my girlfriend, parents, and a couple of close friends. Thankfully they’ve all been willing to switch to either Telegram or Signal. While I’d love to use Signal for all my communications, Telegram’s user experience is far better in every way. Telegram’s default encryption model is good enough for me for most communications; if I need proper end to end encryption I can use secret chats or Signal.

No more social media

Well, almost.

I’ve removed Facebook, Instagram, and Twitter from my phone, and rarely visit any of them. I might check each service once or twice every 2 months. Instead I’ve made a Mastodon account on the Fosstodon instance, and I can honestly say it’s been great! Most of the discussions happening there are relevant to my interests, and if I want to follow specific people from other instances that’s super easy to do.

I do miss following some personalities on Twitter, but not so much that I go back to check on their updates. Honestly, I think I’m much more productive since I’m not looking at those updates 😅.

April 2025 update

I’ve moved my Mastodon account to Treehouse Systems. One more benefit of Mastodon’s decentralization is that you can easily move your account to a new host network if you want!

No more Dropbox

While Dropbox‘s policies aren’t exactly bad, they’re not that great either. My biggest issue is that data is not encrypted before it’s sent to Dropbox. That means that even though Dropbox encrypts the data on their side they still have the potential to read and process all of it.

I’ve already talked about why I don’t like Google products so I don’t think I need to reiterate why I don’t want to use Google Drive.

As a result I’ve been using Tresorit for a while with great success, although their mobile app experience is lacking. Right now I’m looking at buying a subscription to Sync.com or paying for a VPS with a good amount of storage and self-hosting Nextcloud instead.

February 2024 update

I currently use iCloud. I find that I trust Apple enough to hold my data for me. I’m also deeply embedded in Apple’s ecosystem where my computer of choice is a Mac and my phone of choice is an iPhone. iCloud simply works best for those devices and the integration is seamless.

For a general recommendation today I’d probably just recommend buying access to a Nextcloud instance or hosting one yourself.

In conclusion

My general approach here is to try to use services that encrypt my communication with them, and ideally store my data in such a way that they can’t access it, e.g. services like Tresorit and Signal. I also try to limit my exposure to services that are known bad actors when it comes to tracking and advertising.

I could take this idea much further; block scripts from executing in my web browser, exclusively browse the web through the Tor browser, never sign up to services that require any sort of personal information, and so on and so forth, but to that’s too extreme for me. If I did, there would be multiple services I simply wouldn’t be able to use.

That said I don’t think it’s unreasonable for services to ask for some identifiable information to prevent spam, although it’s certainly not the best solution. So long as the service provider doesn’t gather too much information—and so long as they don’t abuse that information—I don’t mind giving up some information about me in exchange for their services.

Calling Fable from TypeScript

Wed, 05 Feb 2020 00:00:00 +0000

Fable is a framework used to compile F# code to JavaScript. I’ve been using it in a TypeScript project — actually going so far as using F# for most of the code.

Fable has a really nice interface that allows easy interoperability with JavaScript, although it can take some time to fully grasp how to use the interface.

Unfortunately this interface isn’t really well documented. They do have some introductory instructions there, but nothing really comprehensive.

While using Fable in my project I had a really hard time figuring out how to call the compiled F# code from my TypeScript project, even going so far as converting the project to JavaScript while I was figuring this out because I really wanted to use F# instead of TypeScript.

So, without further ado, let me explain how you go about importing your compiled F# code into your TypeScript project!

My interpretation of the documentation

After reading the documentation I thought I should import the Fable code into index.ts with an import command like import { helloWorld } from 'fsharp/helloWorld.fs' and a corresponding declaration file, but that doesn’t really work; you can’t import F# code directly into TypeScript, or any non-TypeScript code for that matter.

To import non-TypeScript code into your TypeScript project, you need a declaration file, but before getting to that I want to talk about project folder structure. This is because the declaration file itself isn’t enough, it has to be in the right location.

Project folder structure

Lets assume your project folder looks something like this:

project/
|- src/
   |- index.ts
   |- fsharp/
      |- helloWorld.fs
      |- helloWorld.fsproj

And let’s assume you’ve set up your compilers such that the compiled output looks like this:

project/
|- out/
   |- index.js
   |- fsharp/
      |- helloWorld.js

To be able to import your F# code into your TypeScript project, you need to think about the output folder structure, and subsequently where you should put your declaration files.

You always need to think about the end result; the compiled code will always be pure JavaScript, and thus you need to think as if you’re working in JavaScript.

Assume for a moment that you’re the one writing the code in the compiled output out/index.js. If you wanted to use the code from out/fsharp/helloWorld.js you’d import it with import { helloWorld } from 'fsharp/helloWorld.js'. Because of this, we need the import in src/index.ts to be that exact import.

The easiest way to achieve this is to have the source directory mirror the structure of the output directory. Take a look at the example I outlined above again, here, in its entirety:

project/
|- out/
   |- index.js
   |- fsharp/
      |- helloWorld.js
|- src/
   |- index.ts
   |- fsharp/
      |- helloWorld.fs
      |- helloWorld.fsproj

You’ll see that the src/ and out/ directories look the same, aside from the F# specific helloWorld.fsproj.

Where to put your declaration files

With the mirrored folder structure in mind, we put the declaration file somewhere that will make the import from src/index.ts work for the compiled version of the JavaScript. In this case that would be in src/fsharp.

We also need to make sure that the name of the declaration file fits the import. Remember that the compiled F# code will live in out/fsharp/helloWorld.js. For this reason we’ll call the declaration file helloWorld.js.d.ts and save it in src/fsharp:

project/
|- out/
   |- index.js
   |- fsharp/
      |- helloWorld.js
|- src/
   |- index.ts
   |- fsharp/
      |- helloWorld.js.d.ts
      |- helloWorld.fs
      |- helloWorld.fsproj

You can think of the declaration file name as <import_path>.js.d.ts.

What should you put in your declaration file

This is another part where the documentation fails us. Lets assume your src/fsharp/helloWorld.fs file looks like this:

// helloWorld.fs

module Hello
let helloWorld (name: string): string =
	sprintf "Hello, %s!" name

Based on the documentation, the declaration file for this helloWorld.fs should look something like this:

/** helloWorld.js.d.ts */

declare module "helloWorld.js" {
	function helloWorld( name: string ): string;
}

However, I found that this didn’t work for me at all. Nothing. Nada. The TypeScript compiler simply told me that helloWorld.js is not a module.

Instead, you’ll want your declaration file to look like this:

/** helloWorld.js.d.ts */

export function helloWorld( name: string );

Simple, and to the point. Just export your function signature, and be done with it.

If your code is a little more substantial, you have to change the declaration file accordingly:

// helloWorld.fs

type HelloMessage =
	{ name: string
		message: string }

let helloWorld (msg: HelloMessage): string =
	sprintf
		"Hello %s! Your message is: %s"
		msg.name
		msg.message

/** helloWorld.js.d.ts */

export class HelloMessage {
	name: string;
	message: string;
}

export function helloWorld( msg: HelloMessage ): string;

In conclusion

Mirror the compiled JavaScript folder hierarchy in your source folder.
Put your declaration files in the same folder as your F# source files.
Name your declaration files <f#_source_name>.js.d.ts.
Import in TypeScript with import { yourFunction } from 'path/to/fsharp/source.js'.

Why don't we have good code editors?

Fri, 27 Sep 2019 00:00:00 +0000

I’ve spent a long time trying different code editors, trying to find the perfect one for me. And yes, I’m well aware that finding the perfect editor can certainly sound impossible, but should it be in today’s software ecosystem? I don’t think so.

To be clear, this rant—let’s be honest, this post definitely is a rant—does not propose any solutions for the issues I have with today’s code editors. Instead it seeks to point out what it might take to create a good code editor.

I’d also like to point out we have a lot of great text editors! Just not text editors that are also great code editors.

My frustrations with today’s code editors

The most limiting factor for my choice of code editors is that I need modal editing. After learning how to use Emacs, and then Vim, I can’t imagine going back to the typical non-modal text editing. These editors make it much more comfortable to edit text (and code), and ruined every other way of editing for me.

Now when I try a new editor or IDE the first thing I do is find a Vim emulation extension. Usually, the extension can’t fully support that style of editing because the editor wasn’t built with that type of editing in mind. That lack of support for modal editing eventually makes me frustrated enough to go back to Vim.

I will then use Vim for a couple of days, trying to set up a good environment for what I need. That inevitably fails and I go back to using an editor like VSCode, that has a “good enough” Vim emulation plugin.

I’ve even gone so far as to try wrappers for Vim like Oni and neovim-gtk, but there are always some issues. Inevitably there will be something that makes it so unappealing that I go back to something else like VSCode.

And I hate that. I don’t like using VSCode—I don’t hate it either—but I’m stuck with it because it’s the best editor available. I don’t like the Vim emulation extension, because it’s often slow, and it doesn’t perfectly replicate the utility of Vim. The best Vim emulation extension I’ve come across is – oddly enough – in QtCreator. If only I could use QtCreator for everything…

What I think good code editors should have

Modal editing first

Modal editing should be the first priority; “normal” editing should come after.
Me, myself, and I

Modal editing makes repetitive tasks while editing code so easy to perform. Now, you might be thinking “why would I want to repeat editing tasks while writing code?”. Well, you won’t want it for writing code, you’ll want it for editing. Deleting multiple lines, writing on multiple lines simultaneously, multiple selections, etc., etc.

Besides, “normal” editing is just a mode in modal editing. If you don’t want the modal editing enabled, just disable it. The editor already supports a normal editing mode—that’s how you write most of the time after all—and that should make this configuration trivial.

Editors that do this well are editors like Vim and Kakoune, and—in my opinion—Emacs, but to a lesser extent.

A modern, graphical UI

Terminal editors are out of date. By this I don’t mean that they’re obsolete; I mean their user experience is lagging far behind modern standards. Using editors like Vim and Emacs is not a good experience for the user. The user interface sucks.

I know there are some crazies out there that do everything in a terminal—I mean have you heard of the operating system called Emacs? It’s great, but despite being decades old, still lacks a decent text editor. In all seriousness though, a terminal does not a pleasant user experience make.

You’ll see many Vim/Emacs users argue that you’re faster by getting used to working only with the keyboard to control the UI. Sure, you might gain a few milliseconds in specific cases, but that’s not how anyone works today. Using the mouse is comfortable, intuitive, and easy. Using a terminal editor that doesn’t properly support doing everything with a mouse just doesn’t hold up in today’s environment of graphical software.

Of course, when a terminal is all you have, these editors are amazing. But that doesn’t change the fact that the UI is horrible, and far from being modern.

Just look at editors like Atom, VSCode, and Sublime Text. All of these editors come with excellent UIs that make editing multiple files—working on a project, not just a file—an easier experience. The way these editors achieve this is through graphical representation of the project hierarchy—the file sidebar—and many other quality of life improvements—like being able to use your mouse!

Support user made extensions

Most text editors have this today, but making extension development easy, and making it easy for users to find and install extensions, is a tricky problem to solve. VSCode and Atom have clearly figured out a way that works for those editors. It’s easy to search for, and install, any extension you might want.

Relative to those editors, Vim and Emacs make this very difficult. You need to either install a package manager, and then the extension, or install every extension manually. The process is a pain, even when you get it right.

When it comes to extensions the following tasks must be easy:

Searching for extensions
Installing extensions

An easy way to search for extensions is important because easy discoverability is the key to getting users to use extensions. Easy installation—as in no more than 1 click after finding the extension—is equally important so users will not only search for extensions, but actually use them.

It is, of course, important to design the text editor with all this in mind, and some way to allow extensions to interact with the editor.

Smart auto-complete

This is simple. I want IntelliSense everywhere. Built in. Is that so much to ask?

Peek at implementation/definition

Being able to peek at a function’s implementation makes it so much easier to work with code! You don’t have to remove yourself from the current context to find another file, locate the function, see what it does, navigate back to where you where, and get back to work. IntelliJ really has this one figured out.

Fast and responsive

I don’t mind Electron apps, when they work properly and feel responsive. I happily use programs like Simplenote, Tutanota, and Signal all the time, because they don’t feel sluggish and unresponsive.

Programs like Spotify, Atom, and VSCode however, do feel sluggish and unresponsive at times. It takes a while to load large files. Scrolling halts. Loading the syntax highlighting takes a while. It just feels slow. Not to mention they also use a lot of memory and system resources, even more so than your average Electron app. If they have access to all of that memory and computing power, surely they should be able to run without lagging right?

All of these should come out of the box

I’m sure I could spend days setting up the perfect Vim environment, but my question is: Why should I have to do that? Having all of these come out of the box shouldn’t be that hard in 2019. Some editors have perfect implementations of at least one of the features I want, so an editor that has all of these is clearly not an impossible feat. Why has no one made one yet?

There is hope

I’m actually very excited to see where new editors like Xi and Oni2 will end up. Specifically I’m actively following the discussions surrounding new frontends for Xi, as well as their open issue on modal editing.

I’ve even thought about just doing this myself, but so far I haven’t found the motivation and time to actively work on a big undertaking like creating a text editor I like.

I can only hope someone will see the light and save us all sometime soon.

Kristófer Reykjalín

How to make scrollbars from scratch

How to make scrollbars from scratch

Glossary

What do we need to know to make a scrollbar?

Calculating sizes

The big challenge: getting the values you need for the math

Solution 1: Measure the full height

Solution 2: Estimate full height based on what’s been drawn

Solution 3: Use proxy values to represent the heights

Solution 4: Cheat

Interfaces are too vertical

Interfaces are too vertical

New site design

This site is now hand-crafted

Control

Hosting

History

More varied content

Rough edges

March 2024 style refresh

A look at the various HTML elements

This is an h1 tag

This is an h2 tag

This is an h3 tag

This is an h4 tag

This is an h5 tag

This is an h6 tag

Paged.js for creating printable documents with HTML and CSS

git send-email not working on macOS?

Managing your site with WordOps

Before you get started

Mounting the volume for expandable storage

Installing WordOps

Creating your first WordPress site

Conclusion

"On the experience of being poor-ish, for people who aren't"

How do you share photos with your family?

How to fix blurry text in macOS applications

Solution: support high resolution displays

Why is this necessary?

The End of History

Build your own text editor with Reason — Getting started

Setup

How to install Esy

Creating a Revery project

Updating the project dependencies

Updating the project metadata

Building the project

Make room for your own work

I'm changing the default branch name in my git repositories, and you should too

What’s the problem with master?

So how do we address this?

Counter-arguments

Many tools rely on master as the default branch

The master branch isn’t related to slavery, but a “master copy” from the recording industry

Avoiding the use of master will only give more meaning to the racist undertones of the word

Changing the branch name won’t change society

Final words

A new code editor?

Graphical interface please!

Keyboard driven

Mouse driven

Functionality driven by plugins

Initial goals

What’s happening with this now?

How I protect my privacy online

No more Google

So how do I find stuff online?

But what about e-mail?

And how do you even access the internet?

No more Facebook

No more social media

No more Dropbox

In conclusion

Calling Fable from TypeScript

My interpretation of the documentation

Project folder structure

Where to put your declaration files

What should you put in your declaration file

This is an `h1` tag

This is an `h2` tag

This is an `h3` tag

This is an `h4` tag

This is an `h5` tag

This is an `h6` tag

What’s the problem with `master`?

Many tools rely on `master` as the default branch

The `master` branch isn’t related to slavery, but a “master copy” from the recording industry

Avoiding the use of `master` will only give more meaning to the racist undertones of the word