Recent Posts

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.

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.

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.

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.

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 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...

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".

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.

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 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...