Well, then.
I used the weekend to make a proof-of-concept port of #Lagrange to the terminal, using ncursesw instead of SDL.
Yup, that's right. The custom GUI framework I've built for Lagrange is quite happy to run on a text-based canvas instead of a graphical one. 😁 Even all the UI animations are working.
There's a lot of polishing and tweaking still required, but it is already perfectly usable. I'm quite excited about this!
@jk Okay, that's pretty cool. Not a fan of curses UIs, but having it as a fallback is very useful.
@jk Lagrange over ssh !
@jk Wow, that's incredible. If you tell me it also has mouse support or can display images I'll be truly shocked. 🤩
ncurses does have mouse events, too, and my widgets are ready to handle them just fine, but I haven't tried it yet.
The app's UI isn't 100% keyboard-accessible at the moment, so this TUI build is a perfect environment for making it work fully via keyboard.
As for images, I could scale them down and render as Unicode/ASCII chars. Might be useful for previewing (cf. ploum's Offpunk). Currently they're just drawn as blanks...
Thanks!
Other terminal output libraries would work similarly well, I guess. Curses is quite venerable and therefore widely available, even though it doesn't have the latest bells and whistles. I'm open to making alternative versions later.
@jk O_O
@jk oh my... the TUI space is becoming quite crowd... 🤭
@Seirdy Libyui is definitely in the same vein, however I have no intention of making my GUI toolkit a general-purpose, standalone library. That would be an entirely different kind of project and one that I'm not interested in at the moment.
Nothing new to report on the accessibility front, i.e., no integrations with any existing assistive input or output technologies.
@icedquinn Lagrange has a simple custom GUI that renders directly to a graphics surface, e.g., via SDL's renderers. Here I switched the surface to a text buffer, and render that via curses.
The only major difference is that text is rendered as individual "pixels", each representing a character, instead of using a font. Otherwise the widget layout logic and event processing is the same, everything is just much smaller.
@icedquinn Yes, very traditional hierarchical widget tree == scene graph, where UI events get propagated until some widget eats them.
@mistermonster The TUI is not in the public repos yet. I just started working on it a few days ago.
It will be a separate build option. There will be a separate prebuilt binary, because the dependencies are different than the GUI version (no SDL, for one).
I'll probably add a little script in the source tarball to configure and build the TUI binary.
@jk Nice one ! I can't wait to see how that looks like on my e-ink display. THANKS!
@jk hmm, I wonder if that could be used to use NetSurf in the terminal…
@mmu_man Theoretically since there is a console framebuffer frontend for NetSurf, one could use a similar approach, i.e., replacing SDL with a terminal-based implementation.
However, in practice, it all depends on what assumptions the NetSurf code makes. Currently Lagrange relies on the SDL Render API to do its drawing, which made the porting much simpler as it deals with relatively high-level operations.
@jk I'm quite excited about that too.