Looks like the becoming-father-for-the-2nd-time hiatus is ending since I've been able to make some progress with Lagrange. This release has nothing radically new, but there are a few useful improvements and a handful of bug fixes.
In v1.14, the bookmark folder context menu has been updated to have more appropriate items, and the "Edit..." action now pops up a dialog for changing just the name of the folder. This has been a bit of an oversight: the folder context menu and edit dialog have been pretty much identical to the regular bookmarks' menu/dialog.
Folders are obviously very useful for organizing one's bookmarks into a more manageable hierarchy. They also enable quick group-based actions. In v1.14, I've added an action to open all bookmarks of a folder in tabs, either in the same or in a new window.
You might be thinking, what if I have a hundred bookmarks in a folder and they all get loaded at once? Or what if many of them point to the same capsule, and now you are effectively bombarding that poor capsule with dozens of simultaneous requests? To mitigate this side effect of batch actions, when opening multiple bookmarks, tabs get loaded sequentially instead of all at once. The loading order is the same as the order inside the folder, from top to bottom.
TECHNICAL ASIDE: There is similarity here to the feed subscription refresher that uses up to four concurrent requests. I should refactor the code a little to make both use a common mechanism for doing the requests in properly orchestrated fashion. However, as these things go, the needs of folder tabs loading and feed refreshing aren't quite the same, so the common mechanism would need some generalization and new parameters... Maybe I'll save this one for later.
From a usability perspective, one of the more confusing (or unusual) things about Gemini is TLS client certificates. The average user may be savvy enough to understand server certificates and the basics of TLS, but client certificates are rarely used on the web as a end-user-facing feature. Thus, Lagrange presents them as "identities", which is a common use case that is fairly intuitive. However, Gemini client certificates are also complicated by the scoping with URL prefixes. The user has to be quite technologically adept to pay close attention to the URL path in addition to knowing about the TLS cryptographic dance.
The standard method of using identities in Lagrange is pretty simple: you go on a page, click on an identity in the Identities sidebar, and select "Use on This Page". The current URL is then used as the activation prefix. However, it is up to the user to know which page is appropriate for taking an identity into use, and that depends on the capsule/service. To help a new user understand how this works, the app's UI could still provide additional guidance.
In v1.14, I'm trying something different. Let's consider a more approachable concept: bookmarks. What if we enable attaching an identity to a bookmark? (Which is somewhat analogous to including a user name in the authority component of a URL.) While each bookmark could be treated as a URL prefix, a user may bookmark a specific page inside a service (e.g., one's Astrobotany plant), so limiting the scope of the identity to the bookmarked URL doesn't make sense. I've chosen to activate the identity for the entire bookmarked "capsule root", i.e., domain plus possible tilde username in the path.
All right, but how does this differ from regular identity usage? When a bookmark with an identity is opened, that identity gets "pinned" to the opened tab. This means that the tab keeps using the identity for all subsequent requests, but can only switch to URLs under the same capsule root. If a link leads elsewhere, that link gets opened in a new tab with no identity pinned. This way, one can navigate freely inside the capsule while keeping the identity in use, while not accidentally sending it to any other capsule, for example if the user forgets they are using an identity and manually enters some other capsule's URL. To end use of the identity, it has to be unpinned manually or the tab has to be closed. Keeping the pinned identity tab-specific is also useful because then the same URL can be simultaneously opened with several different identities.
Here is a practical example of what is possible with pinned identities and folders. Say I have two accounts on Astrobotany. Watering, fertilizing, and shaking two plants per day means clicking through six links, and switching identities in between. Hard work, no? Instead, it is now possible to bookmark each of those actions and put the six bookmarks in a folder, pinning the appropriate identity for each bookmark. Then one's gardening activities can be automated simply by opening the folder in tabs.
This release adds a couple of useful command line features.
Firstly, one can change the user data directory with `--user`. For example, when running clagrange, you could use an entirely different user directory than with the GUI version of the app. Or you can choose where to keep the user data files, if the default location isn't optimal.
Secondly, Lagrange can now be run in a CURL/wget-like fetch-and-print mode. The `--dump` option causes the URLs/paths specified on the command line to be fetched and printed to stdout. Metadata of the requests (header line, content length, identity) are printed to stderr. The `--dump-identity` option specifies which identity is used for the request.
Dumping request contents has potential if one wants to use Lagrange together with scripting. The previous example of Astrobotany automation could be achieved with a six-line shell script, for example. Of course, compared to a small CLI-only utility, Lagrange is rather large and relatively to slow to launch, but on the plus side, all identities set up in the app are conveniently available.
In addition to minor UI tweaks and fixes:
π 2022-11-25
CC-BY-SA 4.0
The original Gemtext version of this page can be accessed with a Gemini client: gemini://skyjake.fi/gemlog/2022-11_lagrange-1.14.gmi