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