@blu256

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...

@jk @blu256 maybe a port to notcurses would be possible too ? It would enable rendering of images in compatible terminals (through sixels for instance).
Nevertheless this is a great achievement !

@fdlamotte @blu256

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.

@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.

@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.