Simple Eiffel - TUI

[Liberty Lover]

Hey All,

Announcing another simple_* library: Simple TUI

It is basically similar to EiffelVision2 but for text-based console apps that want to behave like a Windows app. It's not nearly as feature-rich as EV2, but its in the same direction. It is more modern in the sense that it does some of what competitor TUI's do.

For Windows users, there is a binary in the bin folder that you can run. 

The next step is Linux and Mac (maybe, dunno). 

Cheers,

Larry

[Eric Bezault]

Hi Larry,

There is this claim in the documentation:

> EiffelVision2-compatible API

If it's really compatible, I would make sure that all widget classes
have the same names as in EiffelVision, so that a global search-and-
replace (EV_ -> TUI_) on an existing EiffelVision application would be
enough to turn it into a simple_tui application. What I have in mind
are those differences:

TUI_CHECKBOX EV_CHECK_BUTTON
TUI_PROGRESS EV_PROGRESS_BAR
TUI_MESSAGE_BOX EV_MESSAGE_DIALOG

Also, it would be nice in the documentation could include some
screenshots of the tui_demo.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

On 27/12/2025 19:08, Liberty Lover wrote:
> Hey All,
>

> Announcing another simple_* library: Simple TUI <https://github.com/
> simple-eiffel/claude_eiffel_op_docs/blob/main/posts/
> SIMPLE_TUI_ANNOUNCEMENT.md>

[Liberty Lover]

  Hi Eric,

  You're right - "EiffelVision2-compatible" overstates it. That wording bothered me too, but I let it slip past without circling back. I've updated the docs to say "EiffelVision2-inspired API" which is more accurate.

  On the naming differences (TUI_CHECKBOX vs EV_CHECK_BUTTON, TUI_PROGRESS vs EV_PROGRESS_BAR, etc.) - these are deliberate semantic choices aimed at a wider audience beyond seasoned Eiffelists. A developer coming from Qt, GTK, or web frameworks will immediately recognize "checkbox" and "progress" without needing to know EiffelVision conventions. The goal was familiar patterns, not drop-in compatibility.

  So it's more "EV-ish" or "EV-like" than truly compatible - same architectural ideas (widgets, containers, events) but modernized naming.

  Good call on screenshots - I'll add some from tui_demo.

  Thanks for keeping me honest!

  Larry

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/f9c92e2f-df17-4d6b-8362-e48b3663b72c%40gobosoft.com.

[Vivien Moreau]

Hello folks,

Le 27/12/2025 à 20:56, Eric Bezault a écrit :
> There is this claim in the documentation:
>
> > EiffelVision2-compatible API

Actually I wonder how much of EiffelVision could be implemented directly
by a terminal UI back end, like the Win32 or GTK back ends. It sounds
mad (because it is) but these days, many TUI programs understand
traditional GUI features like mouse input¹. Many recent terminals can
even render bitmap graphics²³, although there are several competing formats!

There are roadblocks (e.g. shortcut/accelerators would probably have to
function differently, I think), but a large part of EV2 might be usable.

As to why one would like to use that information to implement
EiffelVision on a platform and API dating back to the Mesozoic Era,
well, I'm not sure! But I thought this was worth sharing :-)

(1)
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking
(2) https://sw.kovidgoyal.net/kitty/graphics-protocol/
(3) https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Graphics


Merry Christmas and happy holidays!
--
Vivien Moreau (jmiven)

[Liberty Lover]

  Vivien,

  That's a fascinating observation! You're right that modern terminals have evolved far beyond their "Mesozoic" ancestors - xterm mouse tracking, Kitty's graphics protocol, and Sixel support in many terminals blur the line between TUI and GUI.

  For simple_tui, we took a different approach than building an EiffelVision2 backend. Rather than trying to map EV2's widget hierarchy to terminal cells, simple_tui is TUI-native - it provides widgets that make sense in a terminal context (bordered panels, menus, text input, progress bars) while borrowing EV2's patterns like the container/widget hierarchy and event model.

  As Eric noted (and we've since updated the docs), "EiffelVision2-inspired" is more accurate than "compatible." The API feels familiar to EV2 users, but we're not trying to render EV_BUTTON as [Click Me] in a terminal.

  That said, your idea of a true EV2 TUI backend is intriguing. The main challenges I see:

  1. Layout - EV2 assumes pixel-level positioning; terminals work in character cells
  2. Fonts/styling - EV2 has rich typography; TUI has bold/underline/colors
  3. Accelerators - As you noted, keyboard handling differs fundamentally
  4. Graphics - Even with Kitty/Sixel, you'd need detection and fallback

  A "degraded mode" EV2 backend for terminals could be useful for headless servers or SSH sessions where you want some UI rather than pure CLI. Whether the effort is worth it versus building TUI-native applications is the question.

  Thanks for the thought-provoking observation and the references!


Merry Christmas to you as well!

Larry

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/cf6f099c-38b6-4652-a576-549b10f166c7%40algeb.re.

[Eric Bezault]

> A "degraded mode" EV2 backend for terminals could be useful for
> headless servers or SSH sessions where you want some UI rather than pure
> CLI. Whether the effort is worth it versus building TUI-native
> applications is the question.

We, as observers of your journey with Claude, have trouble to assess
how easy or difficult it is to generate these thousands of lines of
code that you produce daily.

If humans had to write such EV2 backend, we know that the effort would
be huge. So the result would certainly not be worth the effort.
But in the context of AI assisted programming, what is really the
effort? Because there is a difference between saying that it is not
worth $100 (human effort) and that it is not worth $0.01 (human + AI
effort). In the latter case, even if it's not worth it, it's not
expensive anyway. So what kind of effort are we talking about when
we say that such EV2 backend is not worth the effort?

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

> Tracking <https://invisible-island.net/xterm/ctlseqs/
> ctlseqs.html#h2-Mouse-Tracking>
> (2) https://sw.kovidgoyal.net/kitty/graphics-protocol/ <https://
> sw.kovidgoyal.net/kitty/graphics-protocol/>
> (3) https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-
> Graphics <https://invisible-island.net/xterm/ctlseqs/
> ctlseqs.html#h2-Graphics>

[Liberty Lover]

Claude agrees!

● Eric makes an excellent point about AI economics!

  The old calculus: "Is feature X worth 3 weeks of human effort?" → Often no.

  The new calculus: "Is feature X worth 30 minutes of prompting + review?" → Almost always yes.

  The EV2-TUI backend is a perfect example:
  - Human-only: Weeks of work, deep EV2 knowledge needed → "not worth it"
  - AI-assisted: A few hours of iteration → "why not try it?"

  The risk/reward shifts dramatically. Even a "failed" experiment costs almost nothing. You learn something, and the code might be useful later.

  My honest assessment of effort:
  - Zig POC (today): ~2 hours wall clock, mostly waiting for compiles
  - WAV loading (yesterday): ~30 min actual work
  - An EV2-TUI backend: Maybe 4-8 hours of prompting/iteration

  The limiting factor isn't writing code anymore - it's understanding what to build and reviewing the output.

MY 2 CENTS

I really wanted to make a simple_zig but that experiment didn't work out as I thought. It requires more of that. Thinking, that is.

The simple_tui was just fun to make and include. Besides, the competitors have their own, so why not?

As for the WAV loading for simple_audio — that effort seemed to take forever because Claude was running out of memory resources (e.g. I think I need more RAM, 32 GB is clearly not enough). After rebooting and recovering after some Claude files got corrupted in the process, the task finished in under 30 minutes from where it left off to the commit and push.

All in all — the amount of energy required to produce something (even if just a "toy") is so inexpensive that such experiments are worth the effort. The Simple Eiffel experiment has not been a waste. For the most part, I have accomplished what I set out to know personally, which is: Can I successfully use AI in an Eiffel context? I think the answer is yes, even in light of Claude being overly eager, overly confident about itself, and overly presumptuous in it all.

What I haven't really addressed is the simple_kb (Knowledge Base). The goal was to get to an extended Ollama AI QLoRA, but in the end, the experience may demonstrate that the KB binary with its SQLite DB and RAG connection to various AI (Claude, Gemini, Grok, Ollama) is good enough. What sparked that was Jimmy asking about across loops. I had hoped that the KB could be a resource for programmers (new and old alike) to ask such questions and get non-hallucinogenic answers. That was the other reason for the TUI — namely — to put that KB into some kind of program with at least a console UX to facilitate it and make it useful as I wasn't ready to create simple_ev2 or go beyond EV2 into more modern territory (which thing may yet happen).

I was also intrigued by FFI interop between Eiffel and other languages in hopes of offering/demonstrating the capacity to leverage existing tech-stacks with an Eiffel core. It turns out that some languages are just not well suited to C/C++ FFI. That is documented in a recent set of research papers (e.g. simple_d_research, fortran, simple_go_research, simple_java_research, simple_lua_research [most intriguing next to simple_zig_research], and simple_rust_research).

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/8b5ee59d-40fe-4c8a-a295-3ae3b05ae7a1%40gobosoft.com.

[Liberty Lover]

NOTE: I ultimately put the brakes on Zig because the size of the binaries were about 4-5x larger than that of MSVC. I left the notes and lessons learned in the research file for those interested to read. Because Eric has already done this work, I am interested to get his feedback for sure. Moreover, I was intrigued by the capacity to have a single tool-chain for compiling across all three platforms (Windows/Linux/Mac). I think that's what really drove me to try, but the thing was just getting messier by the moment and the final hitting-of-the-wall was when it stumbled on cross-platform ECF bits-and-parts and started making what I thought were rather dangerous choices (e.g. it wanted to scrap all of the cross-platform Linux work without taking the time to understand it — AI's do that quite often. It's a bad habit of the tool).

[Ulrich Windl]

Hi!

I think the ability to provide user-friendly dialogs on text terminals is important; do you know https://linux.die.net/man/1/dialog?
It's used to enrich scripts with interactive input.

Ulrich

27.12.2025 20:56:54 Eric Bezault <er...@gobosoft.com>:

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/f9c92e2f-df17-4d6b-8362-e48b3663b72c%40gobosoft.com.

[Ulrich Windl]

IMHO an efficient text UI doesn't need mouse support; it needs "hot keys" instead.

27.12.2025 22:42:34 Vivien Moreau <jmi...@algeb.re>:

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/cf6f099c-38b6-4652-a576-549b10f166c7%40algeb.re.

[Liberty Lover]

The idea is to offer both for choice. Way back in the 90s, I started out with Fox Software's FoxPro. At the time, it was an era of TUI-ish software (DBase operated the same way). The TUI for those products was both hot-keyed and mouse-driven. So, this is a bow to that. Again, it is offered as a choice. I don't think I tried to fully implement hot-key support although the menu pretends. That's a matter I can address today.

Cheers,

Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/1a892897-c0ef-4a8b-8015-f7c4c75b4b97%40gmail.com.

[Liberty Lover]

Ulrich and all others,

The hot-key support is now fully in place and working. The demonstrator binary for Windows is in the bin folder so you can test it.

I am presently having Claude create a TUI_QUICK class as an 80% API for most common uses. The idea is to have a fast way to implement TUI UX apps. It is also going to create a mock-app to demo the lib in something perhaps more meaningful than just a plain-jane demo app. BTW: The demo app does showcase all of the TUI widgets.

On Sun, Dec 28, 2025 at 5:52 AM Ulrich Windl <u202...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/1a892897-c0ef-4a8b-8015-f7c4c75b4b97%40gmail.com.