Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
c.im is one of the many independent Mastodon servers you can use to participate in the fediverse.
C.IM is a general, mainly English-speaking Mastodon instance.

Administered by:

Server stats:

2.8K
active users

c.im: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.6

#textual

3 posts3 participants1 post today
Public
Dave Pearson

I've released v0.3.0 of AgiNG, my #NortonGuide reader for the #terminal. The main addition in this release is searching.

See blog.davep.org/2025/03/22/agin for more details.

blog.davep.org · AgiNG v0.3.0I've just released AgiNG v0.3.0. The main focus of this release was to get some searching added to the application. Similar to what I added to WEG back in the day, I wanted three types of searching: Current entry search. Current guide-wide search. All registered guides-wide search. The current entry search is done with a simple modal input, and for now the searching is always case-insensitive (I was going to add a switch for this but it sort of felt unnecessary and I liked how clean the input is). The search is started by pressing /, and if a hit is found n will take you through all subsequent matches. As always, if you're not sure of the keys, you'll find them in the help screen or via the command palette: Guide-wide and all-guide searching is done in the same dialog. To search guide-wide you enter what you want to find and untick "All Guides". With that, the search will stick to the current guide. As will be obvious, searching all guides that have been registered with AgiNG is as simple as ticking "All Guides". Then when you search it'll take a walk through every entry of every guide you've added to the guide directory in the application. Global searching is accessed with Ctrl+/ or via the command palette. With this added, I think that's most of the major functionality I wanted for AgiNG. I imagine there's a few more tweaks I'll think of (for example: I think adding regex search to the global search screen could be handy), but I don't think there's any more big features it needs. AgiNG can be installed with pip or (ideally) pipx from PyPi. It can also be installed with Homebrew by tapping davep/homebrew and then installing aging: $ brew tap davep/homebrew $ brew install aging The source is available on GitHub.
#MSDOS#Clipper#Python
Public
Darren Burns

What is this? An API client for ants??

With the right config you can get super compact!

Compact mode is working nicely with different themes, horizontal mode, and jump mode.

I also added a subtle background colour to indicate which tab has focus-within - something that I lost by hiding the tab underlines.

GIF
#python#OpenSource#programming
Public
Dave Pearson

I've released v0.1.0 of AgiNG; my new #NortonGuide reader for the #Terminal.

#Python #MSDOS #Textual #Clipper

blog.davep.org/2025/03/12/agin

blog.davep.org · AgiNGIt seems I really do still have this need to create new terminal-based projects at the moment. There's been Braindrop, then Peplum, then after that came Hike. While I'm still tweaking and adding to them, and also using them to refine a wee library I'm building up that forms the core of my latest apps, I felt I still had this one app that I needed to finally build. Since the 1990s I've had this mild obsession with building tools for maintaining access to Norton Guide files. I've written readers for GNU/Linux (which also works on macOS too), OS/2, Windows, GNU Emacs, and also or the web (in multiple incarnations). Those builds have covered a few languages, including C, C++, Pascal, JavaScript and Emacs Lisp. I'd never written a Python library or application for it though. So when I first saw Textual mentioned in passing on Twitter a few years back, way back in the 0.1 days, I thought that could be the thing that would push me over the edge. In anticipation of that, back in 2021, I initially developed ngdb.py. This is a library that provides the core Norton Guide reading code for Python applications and could form the basis for other tools. As a test for this I then wrote ng2web (which works, but I think still needs a bit of tidying up -- something I'm aiming to do in the next few weeks). Meanwhile, the journey with Textual itself kicked off, happened, and came to an end; and yet somehow I'd never got round to building the thing I'd initially looked at Textual for: a terminal-based Norton Guide reader that looked nice and modern (by terminal standards). When I initially joined Textualize the owner had actually said they wanted me to build this as test of the framework, to essentially start out by employing me to create some Free Software that would help dogfood the library, but that seemed to get forgotten. Fast forward to the start of this month and I finally felt it was time to tackle this. The result is AgiNG1. As of v0.1.0 it has most of the features you'd expect from a usable Norton Guide reader, including: An ability to add guide files to an in-application directory. The ability open and navigate a guide. Full see-also support, etc. Full translation of characters as were under MS-DOS into the terminal. The ability to copy entry text or source to the clipboard. The ability to copy save entry text or source to a file. Access to a guide's credits. I still need to write some proper documentation for the application, but meanwhile all commands and key shortcuts can be discovered either via the help screen: or by pulling up the command palette: Hopefully the workings of the application will be fairly obvious to anyone who is familiar with Norton Guide files; if anything isn't making sense I'm more than happy to answer questions or take suggestions for improvements. One wee feature I want to call out, that I felt was important to add, was a "classic view" facility. The thing with Norton Guide files is they were mostly created in the very late 1980s and early-to-mid 1990s. People would often get creative with the colouring within them, but in many cases the colouring assumed the default Norton Guide application. Its colours were white text on a blue background. So sometimes other colouring was done assuming that background. You can see an example of this here, with an entry in a guide being viewed using the default textual-dark theme: Notice the colouring in the syntax section. This is more obvious if the application is switched to one of the light themes: With a nod to this issue in mind, I added the "classic view" for entries (which is a sticky setting -- turn it on and it stays on until you turn it off): A little hard on the eyes, I think, but also filled with nostalgia! Talking of themes, all the usual application themes are available, here's a wee selection: AgiNG is licensed GPL-3.0 and available via GitHub and also via PyPi. If you have an environment that has pipx installed you should be able to get up and going with: $ pipx install aging It can also be installed with Homebrew by tapping davep/homebrew and then installing aging: $ brew tap davep/homebrew $ brew install aging Expect to see more updates in the near future; as with other recent projects this is very much something I'm going to be dabbling with and improving as time goes on. If you're wondering about the name, it's nothing more than a word that happens to have NG in it, and also a mild pun about this being an ageing hypertext help system; with the spelling acknowledging Peter Norton's nationality. ↩
Public *
Timothée Mazzucotelli :python:

I'm FINALLY playing with #Textual. Copilot, the official Textual Syntax Highlighter VSCode extension and the *amazing* docs at textualize.io are extremely helpful to kickstart code 🔥

I'm building an app that reads a #GitHub issue form YAML file to render a TUI 🙂 It will also read hidden data in the YAML file to automate filling some of the fields.

The goal is to make it easy for both users and maintainers to report bugs and reproduce them, respectively.

Fun sunday night! #python

Some YAML data for a GitHub issue form.
A screenshot of the TUI built from the GitHub issue form YAML data, thanks to Textual.
Public
Dave Pearson

I finally documented textual-fspicker, and ran into a small problem along the way, the solution of which was a TIL about how #GitHub Pages works: blog.davep.org/2025/02/28/docu

With thanks to @pawamoy for checking my sanity as I tried to work out what the heck was happening.

blog.davep.org · Documenting textual-fspicker (plus a TIL)I've just made a wee update to textual-fspicker, my dialog library for Textual which adds FileOpen, FileSave and SelectDirectory dialogs. There's no substantial change to the workings of the library itself, but I have added something it's been lacking for a long time: documentation! Well... that's not quite true, it's always had documentation. I'm an avid writer of Python docstrings and I make a point of always writing them for every class, function, method or global value as I write the code. As such the low-level "API" documentation has always been sat there ready to be published somehow, eventually. Meanwhile the description for how to use the library was mostly a pointer to some example code inside the README. Not ideal, and something I really wanted to improve at some point. Given I'm still on a bit of a coding spree in my spare time, I finally decided to get round to using the amazing mkdocstrings, in conjunction with mkdocs, to get some better documentation up an running. The approach I decided to take with the documentation was to have a page that gave some general information on how to use the library and then also generate low-level documentation for the all the useful content of the library from the docstrings. While latter isn't really useful to anyone wanting to use the library in their own applications, it could be useful to anyone wanting to understand how it hangs together at a lower-level, perhaps because they want to contribute to or extend the library in some way. While writing some of the general guide took a bit of work, of course, the work to get the documentation up and running and generating was simple enough. The effort comes down to 3 rules in the Makefile for the project: ############################################################################## # Documentation. .PHONY: docs docs: # Generate the system documentation $(mkdocs) build .PHONY: rtfm rtfm: # Locally read the library documentation $(mkdocs) serve .PHONY: publishdocs publishdocs: docs # Set up the docs for publishing $(run) ghp-import --push site The rtfm target is useful for locally-serving the documentation so I can live preview as I write things and update the code. The publishdocs target is used to create and push a gh-pages branch for the repository, resulting in the documentation being hosted by GitHub. A wee problem This is, however, where I ran into a wee problem. I noticed that the locally-hosted version of the documentation looked great, but the version hosted on GitHub Pages was... not so great. I was seeing a load of text alignment issues, and also whole bits of text just not appearing at all. Here's an example of what I was seeing locally: and here's what I was seeing being served up from GitHub Pages: As you can see, in the "bad" version the func label is missing from the header, and the Parameters and Returns tables look quite messy. I spent a little bit of time digging and, looking in Safari's console, I then noticed that I was getting a 404 on a file called _mkdocstrings.css in the assets folder. Problem found! Only... was it though? If I looked in the gh-pages local branch the file was there (and with fine permissions). If I looked in the remote branch, it was there too. Thinking it could be some odd browser problem I even tried to grab the file back from the command line and it came back 404 as well. At this point it was getting kind of late so I decided I must have screwed up somehow but I should leave it for the evening and head to bed. Before doing so though I decided to drop a question into the mkdocstrings discussions to see if anyone could see where I'd messed up. As it turns out, it looked like I hadn't messed up and the reply from the always super-helpful Timothée was, in effect, "yeah, that should work fine". At least I wasn't the only one confused. Fast forward to this morning and, with breakfast and coffee inside me, I decided to try and methodically get to the bottom of it. I wrote up the current state of understanding and looked at what might be the common cause. The thing that stood out to me was that this was a file that started with an underscore, so I did a quick search for "github pages underscore" and right away landed on this result. Bingo! That had to be it! A little bit of testing later and sure enough, the documentation hosted on GitHub Pages looked exactly like the locally-hosted version. So, TIL: by default sites hosted by GitHub Pages will pretend that any asset that starts with an underscore doesn't exist, unless you have a .nojekyll in the root of the repository, on the gh-pages branch (or whatever branch you decide to serve from). To make this all work I added .nojekyll to docs/source and added this to mkdocs.yml: exclude_docs: | !.nojekyll All done! And now I've worked out a simple workflow for using mkdocs/mkdocstrings for my own Python projects, in conjunction with GitHub Pages, I guess I'll start to sprinkle it over other projects too.
#python#terminal#textual
ExploreLive feeds
About