davep

Rogallo v3.1.0

Mon, 05 Oct 2026 10:13:48 +0100

Rogallo v3.1.0 is now available. This release is in response to a recent user request.

Right from the start of the development of Rogallo, I ensured that any MIME types that the application couldn't handle were correctly handed off to the operating system, to allow it to work out what to do. While it is possible for me to do some work to allow images inline -- something I might explore at some point in the future -- Rogallo doesn't currently support this and, accordingly, when faced with image/jpeg or image/png, etc, it delegates to the wider environment.

The problem, of course, is that the user might not have a tool in their environment that's capable of taking over the duties of downloading an image from a gemini URI and displaying it. So the next best thing is that Rogallo itself offers to download the file for you. With v3.1.0 this is now an option.

If you encounter a MIME type that hasn't already been marked for always opening in an external tool, there's a new Download button.

If selected, you'll be asked for a location to save the file.

To augment this, I've also added downloading support for links in the viewer. It might be, for example, that you've already marked image/jpeg and image/png as MIME types that should always be handed off to the operating system (perhaps you have a GUI-based client such as Lagrange or Major Tom installed and it's configured to pick up the URI and handle it). In that case, you'd never be shown the dialog that would allow for downloading. So now, on the occasion that you do want to download within Rogallo, you can navigate to the link and press d. The download dialog will then appear, and you can save the content of the link that way.

ℹ️ Note

If you want to change the binding for the link-based download, you can use the recently added UI element binding facility to bind gemtext_link.download_link to something else.

For now, at least, the download process is pretty simple. It follows the same approach as acquiring the content of a URI for display purposes, but instead writes it to the file you picked. There's no "download manager" or similar and no sticky "download directory". These are things I might consider adding in the future.

Rogallo v3.0.0

Fri, 02 Oct 2026 08:45:01 +0100

It's been a while since I last published an update to Rogallo. In part this is because I've had other distractions, but also in part because I've not had a huge need to add any new features of late. For the most part I feel Rogallo is "done"¹.

I haven't, however, been doing nothing with the code. On and off, over the last handful of weeks, I've been addressing something that I've wanted to tidy up since the early days of development: application configuration. The majority of my Textual-based applications use a simple JSON configuration file, and that's generally good enough. When I started Rogallo I used the same approach. Rogallo has since grown quite a lot and there's much that can be configured and so the "honking great pile-o-JSON" approach was starting to feel quite untidy.

So Rogallo v3.0.0 addresses this. The headline change is that the single JSON file has been replaced with a number of focused YAML files, and some items that were in the original configuration file have been moved out to either the data directory or the state directory, depending on their purpose.

Now for some details on the changes.

❗ Important

There are a lot of changes to how Rogallo is configured. As is mentioned at the end of this post, Rogallo will make a best effort to migrate your old configuration to the new format. However, as a precaution, you might want to think about making a backup copy of your configuration.json file before upgrading Rogallo.

Focused configuration files

As mentioned above, whereas before Rogallo kept all of its configuration in a single file, it now looks to a number of different YAML files that focus on a different aspect of configuration. These include:

aliases.yaml - Aliases for the Rogallo command line
bindings.yaml - Main command and UI element keyboard binding configuration
gopher.yaml - Gopher protocol configuration
icons.yaml - Configuration of icons used throughout the application
preformatted.yaml - Configuration for how preformatted text is handled
toolbar.yaml - Configuration for the Rogallo toolbar

General configuration

For the configuration items that remain, that aren't exactly focused on a particular Rogallo feature, the settings have moved to general.yaml.

Removal of some application commands

Rogallo's design is based around the idea of some "actions" being application-wide commands, and some actions being UI-control-specific. As I worked through the configuration changes I decided that it was time to "demote" some application-wide commands to either being UI-control-specific bindings or just simple configuration properties. With this in mind I've removed the following commands:

ChangeCommandLineLocation
StripeLinks
ToggleANSIEscapeSequenceHandling
ToggleCosyLinkNumbers
ToggleEmojiRemoval
ToggleLinkNumbers

All but ChangeCommandLineLocation are now keyboard shortcuts specific to the viewer widget itself (press F1 when the viewer has focus to get more details). ChangeCommandLineLocation is now a simple configuration property in general.yaml.

UI element action keyboard bindings

From the very start, Rogallo has supported some degree of control over keyboard bindings. As mentioned above, there's a split between "application-wide commands" and "UI-element-specific" actions. Until now it's always been possible to configure the bindings for the former, but never the latter.

In other words: you could always configure the binding for the HandOffToOperatingSystem application command (hands the URI of the currently-viewed document to your OS), but you couldn't change the in-viewer binding for the o key, which opens the URI of the focused link in the OS.

Rogallo v3.0.0 adds support for changing the bindings of the latter. So if you wanted to change o to b for opening a URI externally:

gemtext_link.open_link_externally: b

You can find the bindable IDs for each of the UI controls at the bottom of each page for each of the controls.

New Gophermap badges

Not directly a configuration setup change, but something I noticed while doing the work, was the fact that Rogallo (and the underlying Gophermap library) didn't handle PNG and RTF item types. They're now directly supported.

Conclusion

I believe all of the above changes make it easier to configure Rogallo, and more importantly easier to backup and share the configuration. Technically all of this is one huge breaking change -- everything that was in configuration.json now lives elsewhere. However, I've added some code to Rogallo that detects when you still have a pre-v3.0.0 configuration active, loads up the values, creates the new files, and then renames the old file to configuration.migrated.json. As mentioned near the start of this post, you might want to think about making a backup copy of configuration.json before upgrading.

One last big thing I do want to add is support for tabs. Still to come. ↩

Virtual Fighter Maneuvers

Thu, 01 Oct 2026 16:32:09 +0100

I realise I've been a bit quiet on the blog front for a few days, in part because I've also been a bit quiet on the coding front too. Looking at my GitHub contribution graph, the previous three days where I didn't commit anything are the longest run of no-commit days I've had in about 10 months. There are a couple of reasons for this: the first is that I've reached a bit of a natural pause point with my work on Rogallo (there's a biggish update brewing, but I've been taking my time with it), the second is -- as I expected -- getting my hands on the Steam Frame.

I haven't been playing with it exclusively -- when I have a good amount of free time I am back to streaming -- but I have been dipping in on occasion, and some of those occasions would be moments where I'd reach for the MacBook and bang out some code.

I'm still not set up for full-on PCVR, but I have "discovered" a game that runs really well on the Steam Frame, and it's one that's related to a favourite of mine in VR: Virtual Fighter Maneuvers.

Simply put: it's a very cut-down version of VTOL VR, designed to run well on standalone headsets. Graphically it's simplistic, and from a gameplay point of view it's very focused. There's no single-player campaign. There's no multiplayer campaign. There's no story at all. You strap on your headset, fire up the game, jump into a lobby and off you go: dogfight time!

I love it for that. I've always loved flight sims, and they're even more fun in VR. I like the slow pace and the sense of immersion. But if you're going to fly in VR it takes a bit of time to get set up and plan things. This is the total opposite. I love that I can dive in for 30 minutes, have a fun experience, and then be done. It's ideal for quick, casual sessions.

That's not to say I only want to play for those short bursts -- I have played longer sessions -- it's more to point out that it's a game that combines perfectly with the low-activation-energy accessibility of the Steam Frame. It's a game that makes the Frame feel as easy to pick up as the Steam Deck.

Of course, being a mainly multiplayer game, your chances of having a good time are mixed¹. I've been into a couple of lobbies that have been really fun, with a good mix of folk, who all seem to have joined to have a good time. I've also joined matches where it's just kids wanting to be edgelords on the Internet. Thankfully, so far, it's more the former than the latter. Sadly, though, there don't seem to be that many people playing it. In my (UK timezone) evenings there's normally, at most, four matches on the go that you might be able to join.

There also seems to be a 1v1 matchmaking service so you can get a ranking by battling folk at a similar level to you (I'm a newb to the game, of course); I've yet to actually get such a match going.

This one is a keeper and I can see myself diving into it often for a good while to come.

It does have bot matches too, so you can do some limited single-player gameplay. ↩

Initial Steam Frame impressions

Sat, 26 Sep 2026 11:36:53 +0100

Yesterday evening I finally had the chance to unbox my Steam Frame and have an initial play with it. Here are my impressions of it after playing for a couple of hours. Note that this isn't intended to be any kind of review, just some jotted notes about things I noticed and concluded. The order might appear a little random too.

Unboxing

The first thing I noticed was the obvious lack of any actual instructions. Either I missed the obvious, or there was no leaflet and nothing on the box to tell me how to get it up and running. I had already read online what to do so didn't have any issues, but this still strikes me as odd. I guess the Frame isn't intended for the full consumer market and so the kind of enthusiast who plays with SteamVR is likely curious enough to go find information or work things out, but it still feels like an odd omission.

The other thing that feels like a serious omission is the complete lack of any sort of welcome experience. I remember when I first got my Quest 2, the introduction app was a whole thing and did a great job of showing off the hardware. Heck, even the Steam Deck has Aperture Desk Job. It seems like a very odd choice that something new for the Frame wasn't created.

For example, The Lab is a decade old now; it seems strange to me that they didn't refresh it and promote it as a standalone initial experience for the Frame -- perhaps using it to show off some of the new capabilities or something.

Comfort

While I did buy the ergonomic kit, I didn't set any of that up right away. I was keen to try the device out so my initial test was without the top strap in place. While I've since fitted it, and find it a useful addition, I'm amazed at just how comfortable the headset is to wear. I've spent many hundreds of hours wearing the Quest 2 and the PSVR2, neither of which was horrible, but both of them felt uncomfortable after some use. Based on my initial impressions the Frame feels like something that could be worn for pretty long sessions without any problem.

To be clear: The Steam Frame is by far the most comfortable headset I've worn. This in turn makes it feel like the headset with the least activation energy required when it comes to being motivated to "jump into VR".

Controllers

The controllers are... okay, I guess. Compared to the headset they feel cheap, which they might well be. Based on my experience with the Quest 2, the controllers are the things that take the most punishment and so they're most likely to be the things that need replacing most often. Perhaps they're designed with the right balance of "last long enough" and "affordable to replace".

The main issue I have with the controllers is they seem to have crammed too much into them. They've put all four buttons on the right controller, and a D-pad on the left controller. Perhaps I'm missing something here but this feels like overkill. I found that this made the controllers feel far too busy. All of this also means that the two top buttons (the ones normally used to pull up menus of some description) feel just out of reach. During my time playing last night I found I was having to constantly readjust my grip to reach different buttons, which then meant I was often having to peek under the headset to actually see where my fingers were landing.

Honestly, in terms of ergonomics, I'd say the Frame's controllers are worse than those of the Quest 2, but slightly better than the ones that come with the PSVR2¹.

There's also the complication of the controller straps that come in the ergonomic kit. I love these sorts of straps (the kind that goes around the back of your hand) as they generally make controller use more comfortable. It's great to not have to keep gripping the controller all the time, and it also feels more natural if you need to throw something in VR. But it really feels like whoever designed the controller layout never spoke with whoever designed the straps. The combination ends up being pretty awkward.

I've never used the Index controllers, but everyone I've spoken to who has always seems to sing their praises. Based on that, the Frame's controllers feel like they can't have come from the same company.

Inside the headset

I've read a good few comments from people on Reddit that say that the display in the headset is pretty dark. That wasn't my experience at all. Out of the box I found the display bright enough, and that wasn't even turned up as high as it will go.

The other thing I found was that the display felt like the clearest one I've tried out yet. I wear glasses; I'm short-sighted and have an astigmatism that needs correcting. Given the design of the headset there's no way I was going to wear my specs while using it, so for the moment I'm playing unaided². Despite that I found the display very readable (to be fair, I'm not that short-sighted).

What is slightly disappointing is the lack of an actual "home" when you boot up the headset. This feels like a missed opportunity. Like, sure, the floating menus and the stark landscape are fine and do the job, but the actual home to exist in always felt like a fun thing. Even the Quest 2 has this -- surely it could be done on the Frame?

Audio

I really like the audio. My VR audio experience comes from the stock Quest 2 and also stock PSVR2. The Frame is obviously very similar to the Quest 2, in that the speakers are "near" your ears but don't cover them in any way. I like this. I like this a lot. I find this a really comfortable way to experience VR (and, while it's not an issue at the moment, the ideal setup for recording your voice for video-making or streaming purposes -- you're less likely to end up shouting). I've never liked the PSVR2 in-ear buds so I'm glad it's nothing like that.

While playing, I found that the sense of direction of sounds was pretty spot on, which is something that very obviously matters to immersion. That level of immersion, combined with an awareness of your own surroundings, feels like just the right balance.

Battery life

The battery life is not great, it has to be said. I think I got something like 40 minutes out of the device when I first booted it up. In all fairness, I can't remember what level it was on to start with, and I was also doing an OS upgrade, controller update, and the installation of a game or two.

The second part of my initial session started with something like 95% battery available. That second session ended up on about 20% battery left after playing Alyx for the better part of an hour, give or take (I didn't make a point of actually timing it).

I feel like, with a full charge, and depending on what I do, I might get around 90 minutes out of the device. This feels less than I'd get out of the Quest 2 back in the day.

All of this was, of course, playing a game locally on the headset itself. It will be interesting to see how it compares when in PC-based PCVR streaming mode using the supplied dongle.

Given my interest in using this mostly in standalone mode, I can see myself buying an external power unit and hooking it up while it's stuck in a pocket or something.

Ergonomic kit

The ergonomic kit feels like a thing that should have been included in the price, if I'm honest. The additional strap for the headset is, as I mentioned above, nice to have and improves the comfort from comfortable to very comfortable. The straps for the controllers feel a little cheap but do the job.

I've not tried out the nose guard thing yet. There's no doubt that a lot of light leaks around the nose, but at the same time that's actually quite handy for quickly glancing at the world around you if you need to be able to check on something (your phone, or where your fingers are on the controller because of the issues I mention above).

Now, this might just be me being a bit dense: I found the instructions that came with the kit kind of confusing when it came to the controller straps. I got there in the end, but I feel like the visuals printed on the box could have been so much better.

Thankfully my kit was complete. I've seen reports of people finding broken parts, missing parts, or things like two right-handed controller straps rather than a left and a right.

Gaming

For my initial session I only played games standalone. While I do have a PC for PCVR purposes, it's still packed away after my move last year. I will drag it out and give it a go at some point, but the standalone gaming abilities are what interest me most at the moment.

Gunman Contracts - Stand Alone

The first game I decided to try out was Gunman Contracts - Stand Alone. While the "Stand Alone" in the name is in reference to it no longer being a mod for Half-Life: Alyx, my understanding is that it is intended to be playable standalone on the Steam Frame.

It isn't. It so very isn't.

The FPS was horrible, and I noticed lots of graphical distortion as I tried to play. I never made it out of the home bunker as the whole thing was just a laggy mess.

This doesn't surprise me though. Based on other reviews it looks like it's not the best experience even when playing in full PCVR mode. I've also played it flat-screen on the Steam Deck and it's okay there, but obviously needs some work.

I will revisit this, as I noticed in the settings for it that everything seemed to be turned up to the max. Textures were on Ultra for example, which seems like a wild choice out of the box for a game running on a standalone VR headset. Given this I'm going to assume the game makes zero effort to detect the environment it's running in and to configure good defaults.

Gun Club VR

Next up I tried Gun Club VR. This is a game I've played before native to the Quest 2, and also in PCVR. Given it's an older game I had high hopes for it. I was right to. This was pin-sharp and buttery smooth. In terms of how it looked and felt in the headset it was night and day compared to Gunman Contracts.

Sure, I'm comparing apples and oranges there in terms of game age and what's being asked of the hardware, but I think it's a good comparison of the different ends of that spectrum.

While Gunman Contracts left me concerned that a lot of VR gaming would be off-limits on the Frame, Gun Club VR gave me hope that many of the classics will run well (perhaps after some tweaks by the authors).

Half-Life: Alyx

The third and final game I tried out was Half-Life: Alyx. I've played this in full PCVR mode before, and do feel it's pretty much the peak VR experience. The idea that this could work standalone was wild to me. I know Valve have worked hard on making it work, and are promoting it to the point of bundling it with the Frame³, but it still felt like it was going to be a bad time.

It wasn't a bad time. It was a good time.

While it's very obvious that the graphics have been dialled down, and while I did see a fair bit of pop-in of assets from time to time, generally it looked good and performed well. In my peripheral vision I could obviously see that the resolution was super-low, but no matter where I was directly looking, I saw a quality image (presumably eye-tracked foveated rendering at work, although I've not checked if it is used in Alyx). There was almost no stutter, no lag to speak of, and it felt as good as I remember when playing it in full PCVR mode.

Conclusion

Overall my first experience is pretty positive. Out of the box the Steam Frame is the most comfortable VR experience I've had yet. Given I'm writing this just one week after getting the purchase invitation email, I have high hopes for this device. It seems obvious that there's a load of software and firmware improvements to come, and I can imagine a good third-party market of add-on products to augment the use of the headset (mics, headphones, care and storage, power without full tether, etc.). I also imagine there will be a scramble to optimise a good number of VR games and experiences to get them working well standalone.

It is, without question, expensive for what it is. I very much doubt that this was Valve's intention or doing. The demand for various types of hardware is having a broad impact and I don't need to detail that. Taking this fact into account, this feels like a great little product that's only going to improve with time.

While I'm not sure I'll return to recording VR videos again, at least not with the frequency I used to, I will be returning to enjoying playing VR again thanks to this little device making it very accessible.

I'd place the PSVR2 higher than the Frame if it wasn't for the fact that I find the grips of the controllers far too bulky and very difficult to keep gripped for an extended period of time. ↩
I will be getting prescription inserts when they become available. ↩
Pity us poor souls who already own it I guess. ↩

Recently I found - 8

Fri, 25 Sep 2026 16:53:50 +0100

Introduction

An occasional collection of things I've recently found on the Internet and added to my bookmarks.

Weird little guys of FOSS

As the name says: a collection of "weird little guys" of the FOSS and adjacent worlds. Massively subjective, of course, but I don't think I've seen one (that I know of) that I disagree with yet.

Ball Splitter

The sort of thing that's fun to run up, muted, during boring meetings.

Deadpan Photography: Enjoying the Pretence

I love this style of photography, but I don't think I've ever seen an actual name for the style before. Now I have.

Stargate Worlds — Fan-Made Private Server

I don't need another game to invest all my time in at the moment. But if I did, I think it could be this. I love all things Stargate.

Geminispace topology

A map of Geminispace.

Kepler protocol specification

Yet another smolweb protocol, and yet another derived from or related to Gemini. I doubt I'll do anything with this one (Rogallo supports enough as it is for now), but it's worth keeping a link to it.

GitHub star history

A GitHub star history that doesn't need access tokens and the like.

Everybody's Lost Their Minds

A pretty great rant about all things AI.

Flet

I build enough applications using Textual; it might be interesting to play with a framework that works on all sorts of platforms (as opposed to just in the terminal).

Great on Frame

Games that are verified to work standalone on the Steam Frame.

Leaving DigitalOcean, one site at a time

I've not used DO for a while now, but I have been thinking about setting up a small host again so I can play with Gemini and Gopher. Having used DO in the past, they were at the top of my list.

Now I'm not so sure I need them there.

endoflife.date

End-of-life dates for... so many things!

Team Fortress 2: VR Mod

I used to have so much fun with TF2. The idea of TF2 in VR... hell yes please!

Siri is broken

Thu, 24 Sep 2026 08:12:05 +0100

I think, in part, I regret upgrading any of my Apple devices to the 27 line of operating systems. While my experience as a whole has been pretty favourable, the one thing I was looking forward to is not just disappointing, but is a huge step backwards.

I don't use Siri for many things, but I do use it a lot for a small number of core things. On any given day I'll lift my watch up and speak to it to set a timer or a reminder. Occasionally I'll ask other things, but they're the main uses. Thanks to the fairly recent addition of on-device voice handling, these requests have been near-instant.

With the new Siri that comes with iOS 27, etc., if I'm really lucky the reply will be super slow (getting on for 20 seconds or so to do the job), but more often than not it just doesn't work at all. Either it tells me that my main device isn't available right now¹ (which I take to mean my iPhone, which is wild given it's always in my pocket at the time), or it just busy spins for ages and then simply times out and does nothing.

If I try to use Siri on the iPhone itself, it either just busy waits for ages without getting anything done, or it finally tells me it isn't working.

I was one of the people who upgraded to the 16 Pro because of the promise of "Apple Intelligence". I was, unsurprisingly, kind of annoyed that they didn't deliver. But it was fine, the phone is a good one and it's still serving me well. Also, if I'm honest, I was comfortable with the idea that they chose to not really implement anything² rather than implement something bad.

Sadly though, based on my experience so far, they've implemented something bad. Since upgrading, on the Watch and iPhone, I've found that it's either horrifically slow or it just doesn't work. On top of that, I've lost all the benefit of the on-device voice handling of my watches.

Or words to that effect; I can't remember the exact wording. ↩
I mean, of course, they did do the image playground and writing tools, but they're hardly the leap forward in assistant intelligence that was originally being hinted at. ↩

Steam Frame is here

Wed, 23 Sep 2026 17:14:29 +0100

Actually a little sooner than I was expecting -- look what turned up today!

When I saw this morning, based on tracking, that it had made it to the national distribution centre down in England, I was expecting it to head up this way today and perhaps be out for delivery tomorrow. But, no, a little later in the morning I got an email to say it was up here and would head out this afternoon.

I probably won't be giving it a spin this evening, mainly because I had plans to stream some more Atomfall and I'm actually really into the story right now. The other reason is that I'm still waiting for the charger and ergonomic pack to show up. Not that I need them (it's not like I don't have a charger that'll work), but it would be nice to have those extra items to hand when I first have a play.

Realistically, I'm probably not going to get the chance to fire it up until Friday evening. That's fine, I'm in no rush. I've gone this long without playing much VR; a couple more evenings won't hurt.

Meanwhile, I've found out that Gunman Contracts - Stand Alone will actually work in standalone mode on the Frame. Yes, I know the name might suggest that, but the "Stand Alone" in the name is in reference to the fact that it's no longer an Alyx mod. This makes me quite happy. This is a game I've been looking forward to playing for a couple of years now and the prospect of being able to dive into it on the Steam Frame, without needing to faff with my PC, very much appeals.

I'll be sure to jot down some impressions once I've had a proper session.

GopherMap v1.1.0

Tue, 22 Sep 2026 08:12:12 +0100

I've just made a small update to GopherMap. While doing some work on Rogallo I noticed that, somehow, I wasn't showing a type "badge" for PNG files (p). I spent a moment or two trying to figure out what was wrong with the code in Rogallo, and then realised that I'd managed to miss out both PNG and RTF files in GopherMap itself.

So this release adds those types.

At this point I believe that GopherMap now knows about all the canonical and most useful non-canonical types.

At some point I should probably look at Gopher+, which I suspect will also mean some changes to Port70.

Steam Frame is shipped

Mon, 21 Sep 2026 10:09:21 +0100

I sat down at my desk at about 08:40 this morning and, five minutes later, got an email from Valve to say they were preparing my Steam Frame for shipping! On visiting the site, it said it was shipped.

Checking with the carrier, there's the usual message to say they're aware of the package but haven't picked it up yet. At this rate, it does look like I'll have my hands on it this week.

Time to have a proper look into what games and apps will run standalone on it. The updated Alyx I know about (which does have me wondering if the workshop items will work -- the original Gunman Contracts should be fun), but I've not really checked yet what other actual VR titles will run without the need for a PC.

Steam Frame is packaged

Sun, 20 Sep 2026 08:52:44 +0100

It looks like things are moving a wee bit quicker than I remember when I bought the Steam Controller, with the status of my Steam Frame purchase moving to "packaged" pretty quickly.

I'm curious as to when it will arrive. The small number of times that I've purchased Valve hardware, I've generally found the actual shipping (once it's shipped) to be reasonably swift.

I could be in the position of being able to play with my new headset before next weekend. While I'm most interested in the standalone experience, I might have to dig out the VR gaming PC, update a bunch of things on it, and give it a general tidy. It's getting on a bit now, but it will be interesting to test out the wireless PCVR mode.

Steam Frame purchased

Sat, 19 Sep 2026 10:16:49 +0100

I didn't have to spend too long in the Steam Frame reservation queue. I'd just sat down on the sofa, after having dinner yesterday evening, opened the MacBook to hack on some code, and had this turn up:

I didn't hesitate. However, during the checkout journey, there was a glitch. I opened the email, clicked on the link to go and confirm the purchase, and on the Steam site I was greeted with a message to the effect that the quantity I was buying was too great! It wouldn't let me proceed to the payment. I clicked on the button to view my basket and this is what I saw:

This did make me slightly nervous for a moment. It was an obvious glitch, but was it double-counting the same unit, or had it somehow added two units to my basket? Given that I couldn't progress without doing something, I removed one and... it was all okay.

So as of right now I'm paid up, I have an active order, and now I wait for physical delivery. The estimated delivery time seems to be between 3 and 5 (working?) days.

Meanwhile, I now need to figure out what to do about prescription lens inserts. The inserts that Valve recommend on the Steam Frame page are currently "coming soon", which is mildly annoying. I have noticed in the Steam Frame subreddit a couple of people mentioning other companies who are already manufacturing and shipping inserts. I might take a look at them.

The need for prescription lenses is one annoyance of VR for me. Sure, it's easily fixed, but it's a bit of a shame when, upon opening the box, I have to go with a blurry experience for a wee while. Of course, I could wear my glasses in the headset, but based on my experience when I got my Quest 2 back in late 2020, that's not comfortable and there's the danger of scratching the glasses, headset lenses, or both.

It's not worth the risk.

In the Steam Frame queue

Fri, 18 Sep 2026 08:54:45 +0100

It's getting on for six years now since I got my first VR headset, and it's the best part of five years since I sorted myself with a PCVR setup. Between then and now I've played a lot of VR games and spent a lot of time in VR.

This last year, though, aside from a quick dabble with the PS5 version of Zero Caliber, I've not really been in VR. Mostly this is down to me moving late on last year, and evenings and weekends now being busier with other things. It's sort of always felt like a hassle to have to set up the PCVR rig (when you live alone it's fine to have your PCVR rig lying around the living room all the time; when you share with other people and your cat... not so much).

So when I saw the Steam Frame announced and realised that it would likely give me standalone access to some PCVR-level games (yes, I know, not really PCVR, but I would hope that there will be a push to get many games running standalone), I was tempted. Very tempted. Not only does it offer a good-quality standalone headset, it's also still designed as a full PCVR headset. Feels win/win.

Fast forward to yesterday evening...

I don't know that I'll return to recording PCVR quite yet -- I guess that'll depend on what the Frame offers in terms of being able to record -- but I aim to dive back into any parts of my catalogue that will work with the device. I think a full revisit to the world of Half-Life is necessary if nothing else.

GitHub PR reviews broken

Sun, 13 Sep 2026 15:19:16 +0100

Late on last week I was doing a PR review at work and noticed that, for some odd reason, the author of the PR seemed to have absolutely nuked all of the indentation in the code. While not a problem given the nature of the files I was reviewing, I wasn't happy with their apparent disregard for style and good practice, and was about to leave a remark and a request for changes. But something seemed off. So I did a refresh of the page and... everything fell into place.

Weird.

Since then I've seen the issue on multiple machines. To be fair, each time it's been in Safari, and each time I've been busy with something else so haven't had the chance to really dive into it. But given it's suddenly cropped up, at the same time, on multiple machines, with nothing else changing, it feels like something on the GitHub side of things.

Perhaps I'm letting a bit of bias creep in here, but I feel like this sort of thing is happening more and more on GitHub. It's not that long back since social previews suddenly broke, for example. It's hard to shake the idea that changes are being made without regard to comprehensive testing, and likely without regard to how things connect.

Now, at this point, it would be easy to reach for the "well they're obviously using agents to do most of the work" argument -- and I'm sure plenty of people would -- but that doesn't quite fit with my experience. Having experimented with such tools for a good chunk of this year now, both for personal and, more recently, professional projects, I've generally found that such tooling easily helps with catching such issues.

Plenty of times now, when using something like Antigravity or Claude Code to work on some code, I've found that with reasonable care (you know: the sort of care you'd put into your work anyway) you can quickly and easily uncover connections and knock-on effects you might not have immediately noticed. Moreover, if LLMs are useful for anything when it comes to coding, it's for writing tests¹. With that in mind you should be able to reasonably expect the number of silly bugs to go down.

Unless, of course, there's no human in the loop anywhere, or the human in the loop lacks adequate training and experience, or, I guess, they simply lack the ability to give a shit.

I wonder when this particular issue will get fixed? I should probably go and see if it's reported in the GitHub forums anywhere. I know for sure that there's little point in actually reporting it as a bug; my experiences with that in the past haven't been great, and the GitHub subreddit has seen enough stories of people getting nowhere.

Arguably they're a little too good at it to the point of coming round the other side and doing badly again, if you don't keep an eye on things. ↩

Rogallo v2.4.0

Wed, 09 Sep 2026 08:37:57 +0100

I've released Rogallo v2.4.0, which contains two new features.

The first is the addition of a feature related to the Gemini Protocol, and it's something I've been meaning to add for a wee while: a trusted host browser/manager. It's a simple enough idea: you might want to have a look at all the host/port pairs that exist in your trusted hosts list and, perhaps, revoke the trust for one or more.

From the dialog you can either visit the host/port combination (perhaps you got curious about what you've trusted in the past and want to see what was there), or you can forget the trust. This also somewhat follows on from work done in Rogallo v2.1.0, except rather than having to make the decision when you visit a capsule, you can review all the capsules you currently trust.

If this seems useful, it's called up with the new BrowseTrustedHosts command, bound to Ctrl+Shift+t by default.

The second new feature is something that's been on my TODO list for quite a while, and has mainly been sat there because I wanted the viewer widget in the application to settle down a bit before I tackled this. I'm talking here about in-viewer search. It's a simple enough requirement, but one that's not that straightforward when you're dealing with views of different kinds of text files, views of the source of such documents, and also having to handle things like embedded ANSI escape sequences.

The work is now done, so if the viewer itself is focused, you can press Ctrl+f, enter some text to search for, and then press Ctrl+n to keep moving through all the hits. Once you hit the last match, you'll be told there are no more matches, but then the search will start again from the top.

You can also cancel an ongoing search with Ctrl+Shift+f.

I'm glad to finally get this added to Rogallo as it's a feature I've been finding myself needing on a good few occasions.

Rogallo v2.3.0

Sun, 06 Sep 2026 10:41:12 +0100

Rogallo v2.3.0 is now available. The main addition to this release is support for the Titan Protocol.

First up, there's a small fix. The other day I discovered Scriptonite. While looking at the examples I noticed none of them worked with Rogallo. This struck me as odd because the whole point of Scriptonite is that it all happens on the server-side; nothing on the client-side should affect how well it works.

It turns out that Wasat had a bug when it came to slicing and dicing Gemini URIs, where parts of a URI that followed a ; were being lost. Somewhat amusingly, I didn't even need to do any work on a fix because it had already been taken care of in the branch that existed to support Titan.

The point here being: as of v2.3.0, Rogallo now works fine with the Scriptonite examples.

As I mentioned, the main change in this release is support for the Titan protocol. It's been on the TODO list for a wee while, partly because I was struggling to follow the idea of it, and also partly because I'd not played with it and just didn't see the purpose. The other day I sat down and properly dived in and it finally all clicked.

With v2.3.0, if you now visit a titan:// URI, you will be presented with a rich input dialog. It is a tabbed view, with one tab being for text input/upload:

and the other being a file attachment and upload:

As per the Titan specification, there is support for setting the MIME type for the attached data. If using the text view, this will always be set to text/plain. If using a file attach/upload, you have full control over it, but it will default to the best guess based on the file selected.

There is also support for entering an upload token.

As well as supporting the core Titan specification, I've also added support for the proposed ;edit extension. This means that it is safe to enable Titan-based editing on bbs.geminispace.org, making it easier to modify text you've already written.

One final change in this release of Rogallo also relates to user input. I've given the Gemini-based input dialog an overhaul. Originally this was, by design, as simple and as bare-bones as possible. It was simply a free-text input box that would grow as you added lines, and the prompt from the server was shown as a title in the border of that box. While testing out editing on BBS, I realised that this doesn't always work so well; most of the time the prompt would get truncated.

Not a great user experience. The redesigned input box works more or less the same, but now ensures that the prompt is fully visible.

Between this change and the new Titan edit/upload dialog, I feel Rogallo is now in a good position to act as a near-zero-compromise daily driver when it comes to wandering around the small web.

I guess adding tabs will get it closer to zero. Perhaps in-terminal image viewing. Okay, perhaps a sprinkle of http(s) support too? Also...

Wasat v1.9.0

Sat, 05 Sep 2026 08:20:48 +0100

The work to add Titan support to Rogallo is going well, and I've been able to test it out fine on bbs, doing additions of "long text" and performing file uploads. In doing so, though, I was reminded that there is a proposed "edit" extension to Titan, which is supported there (and I believe on a couple of other capsules too). That got me thinking...

Wasat v1.9.0 is now available, which adds support for this extension. Of most use is the is_edit property which has been added to TitanURI, giving a well-defined approach to testing whether a Titan URI is for editing a resource. The Client class has also grown an edit method to handle the request for the raw content which will then be used as the basis for a subsequent edit by the user, before being uploaded.

All of this, of course, pushes back the work I'm doing on Rogallo, just a little. As I said above, the Titan support is pretty much there and working, but now I want to try and really dial it in and get it working "just so". While the edit support is probably pretty niche, it seems worth adding and, I hope, might delight someone one day when they try it out and it "just works".

Wasat v1.8.0

Thu, 03 Sep 2026 19:24:30 +0100

Another quick little update to Wasat, bumping the version to v1.8.0. This version is in support of some work I'm about to do on Rogallo: Titan support.

This release adds TitanURI and makes a number of changes to handle such URIs alongside GeminiURI. A lucky side-effect is that a problem was uncovered and corrected with how Gemini URIs are sliced and diced in the library. This first showed up for me when I was having a look at the Scriptonite examples. None of them were working for no obvious reason. Eventually it became clear that parts of the URIs were being lost as they travelled through Wasat's code.

So v1.8.0 clears up that problem (fixing the bug in Rogallo by simply upgrading the library).

As of now, I can move on to actually adding Titan support.

next-gh-pr.el v1.1.0

Thu, 03 Sep 2026 15:17:17 +0100

A quick little update to next-gh-pr.el. Since writing the first version I've found it to be really useful, but I've also bumped into one small issue. Sometimes I'll create a draft PR before I remember to start the changelog entry, and so then I want to insert the current PR link rather than the next one.

Now, sure, I can just go and copy the URL and create the link in the changelog, but where's the fun in that when I can solve the problem in Emacs Lisp? So, with this in mind, I've just updated the package so that, with a prefix argument to the command, it will include a link for the latest PR rather than for the next one.

This does, of course, make the name a little less correct, but I'm not going to rename the package or the command for this one minor difference in intent.

Rogallo v2.2.0

Thu, 03 Sep 2026 08:14:57 +0100

Rogallo v2.2.0 is available. This release contains a handful of small new features and also a very minor cosmetic change.

First to the small cosmetic change: the overall design behind the UI of Rogallo is that it's split into a couple of key panels -- the side-panel and the main viewer. The styling of a panel when focus is within it, and when it is outwith it, is different; the idea being that your eye should be drawn to the active panel. This is an approach I take with all my Textual applications.

Part of this styling is to have a thin border to the left of the active panel, which also helps signify that the panel is the one you should be paying attention to. In applications where there's always two or more panels on the screen all the time, this makes sense -- you want the line between the panels anyway to help break up the content. In Rogallo, however, it's going to be normal to only ever have the one panel in view (the viewer).

The other day I realised that, when it's just the viewer available, I should remove that left-hand border. So that's how Rogallo works now. If the viewer is the only panel visible: no border. If the side-panel is also visible: borders. I think it makes the display look a little cleaner; for what it's worth it also saves one column of the display for something more useful.

I've also added a couple of useful features to the active link in the viewer. Now, when a link is selected, you can press c to copy the URI of that link to the clipboard. You can also press o to open the URI by passing it to the operating system. Both these changes should make it easier to take a link out of a document and go and do something else with it.

The last couple of changes are around visiting finger:// URIs. The first is a quick and simple change: any finger content now makes use of Rogallo's document cache, so if you find yourself navigating back and forth between finger responses, there should be fewer requests made in a short period of time.

I added caching partly in anticipation of another change to finger responses: making them interactive where possible. Having created finger2gemtext, I've updated Rogallo so that, where possible, the response is turned into Gemtext and anything that can be turned into a link is now interactive. This means that some finger services should be easier to navigate, no longer requiring that you copy/edit/paste text to get a fresh finger:// URI to follow.

This can be seen if you visit somewhere like finger://plan.cat or finger://redterminal.org/. Whereas before you would just be shown some plain text:

Now you get a version that lets you follow the implied links in the response:

This is, of course, going to be reasonably brittle. If any of the services change their output format such that the "links" can't be detected any more, the output won't be turned into Gemtext. Likewise, it's not impossible that false positives might turn up. I'm going to run with this for a while and see how it works out. I also have a vague plan for how the detection and smarter rendering of finger responses could be made configurable by the user.

Anyway, that's it for this release of Rogallo. Now I can return to the main change I was making a start on this week: Titan support. I've not so much been putting it off as I have been allowing myself to get distracted by the above changes -- mostly because I don't quite get Titan support yet and I don't have a good location to play around with it. Time to solve that problem...

finger2gemtext - A library for converting finger responses to Gemtext

Wed, 02 Sep 2026 19:21:50 +0100

I've just released the first version of another library in the collection of libraries that support the development of Rogallo: specifically, another one that helps convert text in other formats into Gemtext so Rogallo's display can be a little richer. In effect, this is a sibling to md2gemtext and html2gemtext.

This time it's a library to convert finger responses into Gemtext, where it makes sense. For the most part, finger responses are free-form plain text, but there are times when there's information in the response that would be of most use if you could interact with it. For example, if you get a user list from plan.cat¹, that's a lot of data that could be turned into finger:// URIs that can be subsequently followed.

With this in mind, finger2gemtext can take a body of text, look at it to see if it might be possible to convert it to useful Gemtext, and will convert it if that's the case. Given that there's no standard to be had here, and given that any given response could be of any form the author desires, I'm making the conversion pretty conservative.

What I have done, though, is make it so that the conversion process can be extended. The finger_to_gemtext function can be given a collection of additional filtering classes; if the built-in classes can't find anything to convert, the additional classes get a go. There is a base class to inherit from.

I've not fully planned it out yet, but the vague idea I have here is that Rogallo could, at some point, have "finger plugins" which will handle various special cases and site-specific formats.

For now, though, this gives me the basics that let me turn this:

into something where I can follow finger:// links without the need to copy/paste/edit:

Now I need to find a few more online finger resources that respond with things worth making linkable...

finger @plan.cat ↩