textual-astare is another Textual-based Python project that I've developed in the last year and I don't believe I've mentioned on this blog. Simply put, it's a took for viewing the abstract syntax tree of Python code, in the terminal.

I've just made a small update to it this evening after someone asked for a sensible change I've been meaning to do for a while. When I first read the request I was going to look at it next week, when I have some time off work, but you know how it is when you sit at your desk and have a "quick look".

So anyway, yeah, v0.8.0 is out there and can be installed, with the main changes being:

• Updated textual-fspicker
• Updated textual
• Made it so you can open a directory to browser from the command line.
• Made opening the current working directory the default.
• Tweaked the way dark/light mode get toggled so that it's now command-palette-friendly.

I think the code does need a wee bit of tidying -- this was one of my earliest apps built with Textual and my approach to writing Textual apps has changed a fair bit this year, and Textual itself has grown and improved in that time -- but it's still working well for now.

In about a week's time I'll have had a GitHub account for 15 years! I can't even remember what motivated me to create one now, but back in October 2008 I grabbed the davep account...

...and then made my first repo.

My use of the site after that was very sporadic. It looks like I'd add or update something once or twice a year, but I wasn't a heavy user.

Then around the middle of 2015 I seem to have started using it a lot more.

This very much shows that during those years I was working on personal stuff that I was making available in case anyone found it useful, but also leaning heavily on GitHub as a (a, not the) place to keep backups of code I cared about (or even no longer cared about). Quite a lot of that green will likely be me having a few periods of revamping my Emacs configuration.

The really fun part though starts about a year ago:

It's pretty obvious when I started working at Textualize, and working on a FOSS project full time. This is, without a doubt, the most green my contribution graph has looked. It looks like there's a couple of days this year where I haven't visited my desk at all, and I think this is a good thing (I try really hard to have a life outside of coding when it comes to weekends), but I'm also delighted to see just how busy this year looks.

I really hope this carries on for a while to come.

Apparently, as of the time of writing, I've made 12,588 contributions that are on GitHub. What's really fun is the fact that my first contribution pre-dates my GitHub account by 9 years!

This one's pretty easy to explain: this is back from when I was involved with Harbour. Back then we were using SourceForge to manage the project (as was the fashion at the time), and at some point in the past whoever is maintaining the project has pulled the full history into GitHub.

My contribution history on GitHub is actually older than my adult son. I suspect it's older than at least one person I work with. :-/ ¹

I don't think I've mentioned it before on this blog, but some time back I decided it would be fun to use Textual to write a Mandelbrot explorer (simple Mandelbrot explorers have been another one of my favourite known problem to try an unknown thing problems). Doing it in the terminal seemed like a fun little hack. I started off with creating textual-canvas and then built textual-mandelbrot on top of that.

Not too long back I added a "command palette" to Textual (I'd prefer to call it a minibuffer, but I get that that's not fashionable these days), but so far I've not used it in any of my own projects; earlier today I thought it could be fun to add it to textual-mandelbrot.

Most of the commands I've added are trivial and really better covered by (and are covered by) keystrokes, but it was a good test and a way to show off how to create a command provider.

Having started this I can see some more useful things to add: for example it might be interesting to add a facility where you can bookmark a specific location, zoom level, iteration value, etc, and revisit later. The command palette would feel like a great way to pull back those bookmarks.

What I really liked though was how easy this was to do. The code to make the commands available is pretty trivial and, I believe, easy to follow. Although I do say so myself I think I managed to design a very accessible API for this.

There's more I'd like to add to that (the Textual command palette itself, I mean), of course; this was just the start. Support for commands that accept and prompt for arguments would be a neat and obvious enhancement (especially if done in a way that's reminiscent of how commands could be defined in CLIM -- I remember really liking how you could create self-documenting and self-completing commands in that).

All in good time...

As someone who started out in the Android ecosystem when it came to smart phones -- starting out with a HTC Magic and going through a few different phones before settling on Pixels (until I finally jumped ship to iOS in 2020) -- I have to admit that there's always been something nice about the design of iPhones. iOS, less so... My first exposure to iOS was back in 2015 when I got an iPod, and I wasn't terribly impressed. It looked okay, but it felt so far behind Android in terms of functionality.

Much has changed and improved since then. These days, 3 years into being totally consumed by the Apple ecosystem (one day I should write a post about how comprehensively I've moved over), I'm won over and I like how iOS works now.

Except this...

That thing where, when you're in one app, it will show the most useless link "back" to another app, and in doing so bump the time up and out of the way a little. Like, seriously, compare it to when the app link thing isn't there:

Once you see it, you can't unsee it.

After all this time you'd think they would have found a less janky way of doing this; perhaps even simply removed it (I can't remember the last time I needed or wanted the ability to go "back" an app like this, especially not with the bottom-of-screen swipe gesture being a thing). If nothing else you'd think that, by now, they'd have found a way of doing it that doesn't look so terrible.

The "eh, let's just shove it here" approach that seems to be on display here almost reminds me of the "time wiggle" that used to mildly annoy me back on my iMac.

Some time around late October or early November last year, around the time I started working at Textualize, I "discovered" Obsidian. While I didn't need another note-taking application (having gone through Evernote, trying to use Org, dabbling with a couple of other things and finally settling mainly on Apple Notes), I was quite taken by its style and ubiquity and the fact that it was, at heart, just a bunch of Markdown files.

So quite quickly I started using it; not to replace Apple Notes (which is still my general note-taking tool of choice), but to keep work notes and a daily coding journal, the latter coming in useful for the quick end-of-day meetings we normally have.

One of the things I was quite taken by was the graph. It was interesting and fun to see how each of my work days related to other work days, and what subjects kept getting pulled in, etc.

So come the start of this year I had an idea: what would it be like to keep a personal vault, but one where I track things I've done. Not a journal as such (I do keep one of those too, have done for many years now, but that's for other far more important reasons -- perhaps I'll write about that one day too), just a daily record of stuff I've achieved, stuff I've actually done, the routine things and the exceptional things?

What would that graph look like?

While it's not the end of this year yet, here's how that's shaping up:

Each of the yellow circles is a day, each of the blue ones is a tag of some sort. As you'd imagine, the size of the circles relates to how often that item is tagged. So I can see what proportion of my days so far this year have been tagged with being heavily involved with work:

Likewise, if I want to see how many days this year have involved a significant spot of gaming:

Ditto for days where I've done some coding on pet projects, or even some personal-time coding relating to work projects (it might be work, but it's also Free Software and I do like to support FOSS!)

I sort of have a curated set of tags I apply, but I've not made it a strict set; if some new situation crops up that calls for a new tag I'll use it. Mostly though I try and keep the tags pretty general so lots of days can relate to the same general subject.

Another thing I've done is tag each and every day with the day of the week, so while it's not really surprising to find that Sunday doesn't dominate over other days, I can see which days are Sundays and perhaps wander along the connections and see what I get up to:

I don't quite know what I hope to get out of this, I don't really know if there's anything useful to be had here at all, but it will be interesting to look back over it at the end of the year. It also means that I'll have a directory hierarchy full of Markdown files, all tagged and filled with information, which I'll be able to grep and slice and dice and count and perhaps pull into a database and cross-reference with stuff and things.

Or perhaps it's all just really me not having a good use for Obsidian but inventing one anyway. ;-)

Since quickly hacking together textual-query-sandbox a few days back, I've made a bunch of small changes here and there. While most have been cosmetic and playing with some ideas, some have also been internal improvements that should make the tool work better.

The most prominent change is one I pondered in the previous post, where I thought it might be interesting to have a small collection of playgrounds grounded together with a TabbedContent. So as of now the tool still has the original playground which had an emphasis on nested containers:

There's now a playground with an emphasis on selecting widgets within containers¹:

There's also now a playground that has an emphasis on pulling out widgets based on ID and classes:

The other change you will notice from the original post is the DOM tree shown in the bottom right corner. Note that that isn't there to show your query result (that's the bottom left panel), it's there to help picture how the DOM in the current playground hangs together, and will hopefully help in picturing the structure for when you write a query.

I sense there's still a lot of fun things I could add to this, and I'm still keen on the idea of having the playgrounds "soft coded" in some way, so people can make their own and load them up.

Another thing I want to try and work on is making the display as useful as possible. While I think it's actually pretty neat and clear, there's not a lot of space² available to show the playground and the results. Finding a good balance is an interesting problem.

For a number of reasons this is turning into a really enjoyable tinker project.

Sometimes I can have an idea for a Textual widget, library or application on my ideas list for weeks, months even, before I get around to it -- mostly just due to not having the clear time to make a run at getting it going -- and then other times an idea can pop into my head and it has to be created there and then. Has to be!

This happened yesterday evening.

While the tool I built is something I'd thought of before (back around November last year I think) it hadn't even made it to my "list of stuff I should make" that I keep in Apple Reminders; not sure why really. But then yesterday evening a question cropped up on the Textual Discord server that related to the subject and I was reminded of it.

The subject being: Textual DOM queries. I like to think that DOM queries in Textual are pretty easy to do, and well-explained in the docs, but it's fair to admit that they need a bit of practice first, just like any powerful tool. So I was reminded that I'd wanted to write a sandbox application, that would have a practice DOM inside it, an input field to type in a query, and a way of displaying the results.

So textual-query-sandbox was born!

In this very first version (which was really quickly put together -- it was something like 15 minutes to write the main code and then probably 45 minutes tweaking styles, adding all the admin stuff to allow deployment to PyPi and writing the README) there's an Input, a display of a group of nested containers with different IDs and classes, and then a Pretty widget at the bottom to show the query result.

If you think this looks like it might be useful to you, it can be installed using either pip or (ideally) pipx:

$ pipx install textual-query-sandbox

and then you can run it with:

$ tqs

At which point load up the Textual query docs, type queries into the input field, hit enter and see what gets highlighted and which widgets end up in the result set at the bottom of the screen.

Like I say: this was a quick hack yesterday evening, I think there's a lot more can go into this. For one thing I think a more interesting practice DOM would be a good idea, with a good mix of widgets; another thing could be having a collection of different DOM playgrounds that can be switched between (a TabbedContent of different playgrounds could be fun here); this could even be taken further such that the user can create their own playground DOM to practice against.

Eventually it would be neat if this could be turned into a library that can be included in a Textual application, as a development-time debug tool, so that on-the-fly test queries can be made.

For now though, it's started, it's under way, and I think the current version probably covers 90% of the use cases for something like this; making for a really quick and easy tool to double-check how to query something.

And I'm done! While it did only turn out to be one a week, I pulled it off, I managed to make it to at least one Fringe show per week!

Yesterday was a full, busy, and hugely enjoyable day. While it could have just been a dash into town to see the show and back home again, in conjunction with Mariëlle (who first introduced me to the Mythos show) we arranged to go watch Oppenheimer first (amazing, easily the fastest any combined 3 hours have passed for me -- I'm not even going to try and write up anything about this, other than I was utterly enthralled by the movie from start to end), grab some dinner, then go and see Mythos: Ragnarok.

With a wee bit of shopping thrown in along the way.

As I've mentioned before, I first saw Ragnarok last year. Then they were in a fairly small venue, with a pretty full crowd. At the end they talked about how the first night they'd played the audience had been a single person; over the nights of the run it had slowly grown, and by the end of the run (we went on the last night) it was getting properly busy.

This year they were in a much bigger place, with a lot more seating, and the house was full. This did make it feel a little less intimate than last year, and also last year we were sat all around the stage, which worked well for the performance; this time around it was a more traditional stage at the front, seating all on one side thing. I was really pleased for them that they were in a much bigger place, but I did miss the layout from last year.

As for the show itself... just as fantastic. There seemed to have been some tweaks and changes to how the story was done over what I remember from last year, but mainly it was the same. The energy in the performance was incredible, and the comedy was spot on, with a lot of nods and winks to the audience. This is the part that I think I enjoy most: they know what they have, they know what they're doing, they know what they have on offer. It's a high-energy play performed by stunt people.

It's amazing.

As I write this there's one last show, I believe, tonight; so the chances of anyone reading this and getting to see it are very remote. But if they're back next year, and you're reading this near then and wondering about Fringe shows, do it! Really, do it. You won't regret it.

I'll be going again. No question.

Almost seven years ago I took up maintaining an ad-hoc photoblog again. I say again because I'd had one once before. I'd kicked that off back in the late 200xs, with my little HTC Magic, and hosted it on Posterous. Eventually Posterous was shut down, mostly because the company (or at least the team behind it)) had been bought up by Twitter. When kicking off the blog this time I decided on a few things:

• I'd host it on Blogger.com; it had been around for long enough, and of course Google could be trusted to keep something that big up and running for good.
• I'd keep multiple backup copies of the images and file them in useful ways (I keep copies in Google Photos, on Google Drive, on iCloud and locally).
• As much as possible I'd automate the process of doing some, if not all of this.

At this point, while it was kind of old as an idea, this felt very much like one of those things that was perfect to do in a Web 2.0 way; the good old reliable mashable web!

So the plan became this:

• Every post would be a tweet, posted to Twitter with a #photoblog tag.
• I'd use ifttt to keep an eye on my tweets and when it saw one with that tag it would extract the image, make a post to Blogger, drop a copy into Google Drive, and do a couple of other things too.
• Every week or so I'd do some manual checks to make sure everything is looking okay.

This worked. Mostly. It ran fine for a few years, with very few problems. I'd take a photo, manipulate the heck out of it for the emotional effect I was going for (that was the point of the blog; it was all about the messing with the image), tweet it, and Web 2.0 magic would happen.

Then the odd issue started to crop up. At one point Twitter made changes to how images were stored, or something, and the ifttt recipe broke for a wee while; then they changed the way that public posts could be seen (long before the Musk-era bullshit) and that broke things again, and so on. I forget the details but at every point I was able to nurse it back to life and things carried on.

Recently, of course, it all fell apart when Musk took over Twitter and massively ruined it, turning it into the steaming pile it is now¹. I've honestly lost track of which change broke what, and of course I also gave up even trying to use Twitter (the drip, drip, drip of right-wing hate politics got to a point where I could not find a way to make it work any more). So that's when I decided to cut Twitter out altogether.

This had actually started a little earlier than that, when the whole API fiasco kicked off. When that came in ifttt had to remove Twitter things from its free tier; I was on the free tier. I was on the free tier only because I didn't need anything the paid service offered. If Twitter had been "normal" and this change had been made I'd have happily paid -- I don't mind paying for things I find useful.

But, nope, given all the context, I bailed.

So by that point I decided the easiest thing to do was to simply hand-add posts to Blogger, and also along the way post to a pixelfed account instead, reposting those posts from my Fosstodon account. Not ideal, needing more manual input, but also I was thinking that once I find a good flow I could probably automate the whole thing again.

Anyway, that's the point I'd reached. Twitter was 100% out of the workflow, there was a bit more manual intervention, but the primary location for the photos was still getting updated.

Then yesterday I noticed this:

I don't actually quite know exactly what's going on here, and at this point I really don't care. My working hypothesis is this: when ifttt added the images to the Blogger posts, it was doing so in a way that it was using the image hosted by Twitter. Because of this, either due to some change in the Twitter API, or perhaps because I've locked down my Twitter account, the images can't be served any more. That's my best guess anyway.

I don't really care to dig deeper than that.

But, yeah, this is another example of the long-growing rot of the dream of Web 2.0. I'm not surprised; I'm not angry; I'm just disappointed.

Thankfully I have all the images saved (see backup options above), so I can go back and edit the posts and drop fresh copies of the images into them. There's 100s of posts affected so this is going to take quite a while; I mean, sure, I could probably do it in a day if I sat and did nothing else, but I have other things to do.

Another option would of course be to create a fresh blog using my own tools; that would be simple enough. I have the images, they're all set with the right date and time, recreating things would be fairly trivial (post titles a slight problem but I could work around that); a tool like mkdocs or Pelican plus some Python code to recreate the posts from the images would be a fun couple of hours mucking about. But... I have a lot of posts on Blogger and all the URLs are stable and still there many years later.

Perhaps I could automate the "fixing" of the broken posts? I wonder what the Blogger API is like to work with?

PS: If you've read this and feel that what's really needed is a "helpful" comment that self-hosting is the solution; please sit on that and read the above again (and, you know, look over the rest of this blog and the entirety of my time and content on the Internet in general and the Web in particular, going back to the mid-90s).

As mentioned just over a week back, last night I went to see a Fringe show that was a production of The Little Shop of Horrors. Before going I had no idea what to expect (in terms of how it would be done, not what the content would be): I wasn't clear if it would be a really small affair, or something on a bigger stage with reasonably high production values (what can I say? It was LSoH, it was a Fringe show, it was booked knowing nothing else).

When we got there and got into the venue it was... small, oh so very small! No real set to speak of. The cast who were about to kick off the performance didn't really seem to have much of a costume going on. So, without judgement, I settled down to expect the next 90 minutes or so to be... a Fringe experience.

First impressions were oh so wrong! While there was (for obvious reasons) a lack of any real set, the effort that went into the performance really worked and I absolutely enjoyed every single moment. Also, because it was a production of the musical (which I haven't seen), rather than an adaption of the movie (which I have), I got to experience a fresh ending (spoilers!).

The seats were uncomfortable. The room was down in the basement, with no ventilation, and so was uncomfortably hot. Physically it wasn't a great space to be. And yet I really wasn't wishing for it to be over. I think that says a lot about the show itself.

I think special mention has to be given to the Audrey II models, of which there were three different sizes. Someone put some real effort into them.

So, yeah, a fun night, topped and tailed with pre-show dinner and post-show drinks with friends. I couldn't have asked for more.

Unless I last-moment book anything else over the next week, there's one more show to go in my push to go and see at least one show per week of the Fringe.

PS: Sadly no photos. I wasn't sat in a great spot to take photos.