This is a discussion thread about a new terminal application framework we've been thinking to implement. There are a few links below to tell more about where some ideas are coming from.

Links:

• https://github.com/gui-cs/Terminal.Gui
• https://github.com/rivo/tview
• https://github.com/gdamore/tcell
• https://github.com/derailed/k9s

Background:

• There is a component flow system which were created to provide terminal UI type of integrations for simple things like input, yes/no, single-select, multi-select, etc.
• While component flow is great by itself it has its own limitations like it was attached to a "flow" of commands similarly to a github cli where the concept were essentially copied.
• It's not easy to create a new component as burden to understand internals in spring-shell and in a jline itself is monumental.
• ComponentFlow then hooked build-in components together to create a "flow" and it were never possible to extend this "flow" for user components.
• In so many ways this existing component flow system were slightly "over engineered" and thus don't really fit its purpose.

Nice to have:

• Writing a "view" should work as is if you're on a full screen application more or in a command line mode (current flow system only works on a terminal mode, not fullscreen).

Issues:

• Terminal UI is completely different thing compared to a traditional GUI framework like JDK AWT or Swing.
• There are no defined key/mouse events from a terminal as everything are coming in as a stream of bytes(i.e. compination of characters and escape sequinces).
• Terminal infra is a wild-wild-west meaning there are old and new terminal emulators which all may "advertice" being xterm compliant.
• We're always going to be based on JLine for low level terminal features but it doesn't provide any "higher" level features, nor clear key mappings similarly what it provides for mouse events.
• JLine has its own ways to map into key event stream which is not so obvious for a user.
• It's a bit unknown where a current component flow system should go to as it has its own value for a non-fullscreen terminal app flow. What would be benefitial is to replace its internal ui representation with a new view components.

Where to go:

• We've been playing with an ideas to have a proper terminal UI system to have a better "view" system to represent building blocks of an UI, think these as a logos you use to build something bigger.
• Initial work would be done in 3.2.x and would contain a foundation of it.
• Idea is to have system where a small portion of a screen is a "view" and only that "view" is responsible what's in it. This "view" can be nothing or everything, but essentially something what will be show in a reserved restricted space in a boundary of a screen space.
• Abstract key/mouse events into more sensible format which is then easier to consume in a spring-shell.

Design ideas:

• We need an eventloop to control a state of a screen to get updated to a terminal.
  • Based on a https://projectreactor.io which drives spring reactive foundation.
  • Not just a busy eventloop but control system for a generic event and task system as well.
  • Scheduling an "animation" system
  • Timing of a screen update
  • Scheduling of a tasks
• View always controls its state
• View can be a layout view, aka controlling its child views.
• Central controller component
  • Handling translation of terminal stream into key/mouse events.
  • Handling root View and possible layered Views to support modal system.
• View components
  • Low level views like BoxView
  • Layout views like GridView and FlexView.
  • Text views
  • Input views
  • List views
  • Selector views

End words:

• Creating a new terminal ui framework is a big task.
• We're targeting getting foundation solid in a spring-shell 3.2.x, have a set of "views" or "legos" users can build on.
• This would be a good opportunity for those interest of this work to express their own views what might be important for a first released implementation.