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.
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.
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.
I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)
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.
There are plenty of examples where menu display and help texts can be toggled.
For example, aptitude has `Aptitude::UI::Menubar-Autohide` and midnight commander has options in the layout menu to disable menu/buttons/etc. That way beginners get to learn through discovery, and may later choose to switch to calling the menu/action with a keypress. Both of those respond to "standard" F1 for help too.
Would I prefer emacs M-x and C-h style interaction in mc? Yeah, probably. I'm used to it everywhere else(such as zsh). However, as a long term user I can execute basically all the functions even though I've long since disabled the buttons, menus and hints.
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.
As an aside, I really like your web page - simple and clean with images and demos, no bloat.
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.
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.
[1]: https://functionalprogrammingstrategies.com/
This looks really nice in the screen-shots.
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.
I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)
[1] https://github.com/joouha/euporie/tree/dev/packages/apptk
[2] https://github.com/joouha/euporie
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.
There are plenty of examples where menu display and help texts can be toggled.
For example, aptitude has `Aptitude::UI::Menubar-Autohide` and midnight commander has options in the layout menu to disable menu/buttons/etc. That way beginners get to learn through discovery, and may later choose to switch to calling the menu/action with a keypress. Both of those respond to "standard" F1 for help too.
Would I prefer emacs M-x and C-h style interaction in mc? Yeah, probably. I'm used to it everywhere else(such as zsh). However, as a long term user I can execute basically all the functions even though I've long since disabled the buttons, menus and hints.
> Startup time really is an issue with Python, because import is super slow.
Python has lazy imports coming soon in 3.15!
Source: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...
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.
As an aside, I really like your web page - simple and clean with images and demos, no bloat.