Show newer

Beta 2 is now available with a few input field fixes. If the app was ignoring what was entered, this may help.

The APK link on the gemlog post was updated.

Show thread

A side benefit of moving everything to the hideable bottom bar is that you can get a fullscreen view for reading.

Show thread

Android Alpha 7 ( v1.12 Preview)


v1.12 will have some new visuals: Roboto as default, paragraph justification, bottom URL/tab bars, new "Oceanic" color theme, and improvements for the other themes.

This makes more sense on mobile, but I like it a lot on desktop as well: having tabs and URL bar at the bottom kind of evokes the feeling of a terminal command line where you enter stuff at the bottom.

Another option for Lagrange v1.12.

Mm, a bit of justification makes paragraphs look much nicer. This will be an option in Lagrange v1.12.

Roboto is not that far off from the iOS/Mac San Francisco, slightly more angular and a bit taller, but it does make the app feel decidedly Android-ish. Compared to Source Sans, it's a much better match with the system UI, though.

Also, the font renderer lacks hinting and subpixel antialiasing, so on normal-density displays it won't be as "sharp" as the system-provided labels. This may be distracting with Segoe on Windows.

Show thread

Considering new default fonts for in v1.12.

The trajectory here is toward using whatever system UI font the OS provides, but that won't be implemented on every platform, nor will be ready for use very soon. In the meantime, switching to Segoe UI on Windows and Roboto everywhere else gets pretty close to the mark.

I've released v1.11:


(Had to make a quick .1 update due to a blunder.)

The highlights of v1.11 are support for multiple windows, fontpack search, and site-specific theme palettes.

Fearing for Gemini


Will some external force ruin ? Will people not see the value in remaining text-based and simple? Will technology drive itself off a cliff, once again?

Multiple Windows is now in the dev branch. Not quite glitch-free, yet, but starting to work pretty nicely.

Needs some optimizations, though.

A small patch for the weekend, perhaps the last one for v1.10:

This fixes empty path normalization and a small key event issue with the U key.

Bug fix: New replies to old threads were being hidden, it was just showing the thread root post.

I'm also marking updated posts so they should be showing up together with other new posts. Let's see if that works...

Show thread

Support for multiple windows is coming together for v1.11.

I expect there are a lot of little tweaks and debugging in event processing and drawing to get this running nicely on all platforms.

I can see this becoming my primary way of using Cosmos, although it would be great to have a way to sync tabs across devices... I'll need to look into a sync solution at some point.

A noteworthy limitation with this is currently that updated posts, like micrologs/journals, do not reappear when updated since their IDs don't change.

Show thread

Even More Dynamic Cosmos


I'm testing a new view mode in Cosmos that lets you see only the posts that have been added since your last visit, without saving any state on the server.

In case you're wondering what spurred me on to data URLs, it was the YLE teletext service. They use data URLs for the graphical version of the pages, i.e., what you would actually see on a TV. Here's an example of such an embedded image in Lagrange v1.11. This page is 6.2 KB in size.

I keep getting surprised by the wild stuff they actually have in there. Happy Valentine's Day, I guess! ☺️

I've updated the post with this as a downside ("Breaking constraints").

Show thread

A compromise would be to add a requirement in the specification that clients must disregard links that are longer than N bytes, where N is a reasonably low number like 4096 or even 1024 bytes.

This would allow some of the nice use cases of data URLs (like small metadata attachments), but would protect against inappropriate image attachments, for example.

Show thread

There's a valid case to be made that allowing data URLs steps over the intended constraints of Gemini.

Data URLs basically turn Gemtext into a container format that can have arbitrary other data types inside it. This also takes away the user's ability to completely choose which links' content is fetched, giving a bit more power to the server who is effectively able to "preload" content of some links, forcing them on the client whether it wants the data or not.

Show thread
Show older

skyjake's choices:

skyjake's personal Mastodon instance