I find it interesting that people still build and like TUIs that have menus and buttons. Trying to stuff a 1980s windowing paradigm into a terminal just seems odd to me. I never really liked the Borland interface. The article says that menus provide discoverability without having to read a manual, which is true, but at a cost of a whole line of precious text in the term and multiple keystrokes with modifiers to open the menu. Seems like a help key with a pop-up overlay could give you just as much discoverability. Anyway these Borland-style TUIs just keep hanging around. IMO, better to embrace something more like Emacs with built-in help.
Coincidentally I'm working on my own TUI framework for my book [1], so it's always interesting to see how other people approach it. I wouldn't, for example, use windows and drop-downs in the terminal; I think there are better approaches. Some of the most interesting text-focused UI experiments are taking place in Emacs and Vim, so that's where I'm taking inspiration from.<p>My framework is demonstrating the capability-passing approach to effects, which is the underlying architecture in most modern JS frameworks, Jetpack Compose, and "immediate mode" toolkits (though the authors are not necessarily aware of capability-passing as a concept). If you've read recent posts on "algebraic effects" or "effect handlers" it's in the same space. It makes for a quite pleasant user experience. I'm enjoying the work uniting theory and practice; one of the benefits of writing the book is I can justify these excursions.<p>[1]: <a href="https://functionalprogrammingstrategies.com/" rel="nofollow">https://functionalprogrammingstrategies.com/</a>
This looks really nice in the screen-shots.<p>I'm working on what is effectively a fork of prompt_toolkit [1], which supports many modern terminal features I needed for euporie [2], such as terminal graphics, extra text styles, color palette detection, terminal clipboard, synchronized outputs, CSI-u, mouse pixel positioning, etc.<p>I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)<p>[1] <a href="https://github.com/joouha/euporie/tree/dev/packages/apptk" rel="nofollow">https://github.com/joouha/euporie/tree/dev/packages/apptk</a><p>[2] <a href="https://github.com/joouha/euporie" rel="nofollow">https://github.com/joouha/euporie</a>
> Startup time really is an issue with Python, because import is super slow.<p>Python has lazy imports coming soon in 3.15!<p>Source: <a href="https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-lazy-imports" rel="nofollow">https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...</a>
This looks beautiful and I'm sorry the current state of affairs has made you not want to publish the code, I would love to play around with it. Regarding your decision to build - I feel you, I've had the same happen to me for everything from charting libs to various web components.<p>As an aside, I really like your web page - simple and clean with images and demos, no bloat.
[dead]