Roadmap

[oyvindberg]

Roadmap

Current state

What is here now is a quick and dirty port of tui-rs to scala. It also contains a pure Java/JNI wrapper for crossterm.

It's a significant improvement of the state of the art on the JVM (as far as I know) to easily create rich, pretty, cross-platform TUI interfaces easily. It also works with GraalVM native images, which really will enable us to make great and pretty TUI tools in Scala.

Immediate next steps

• refactor JNI layer to throw java exceptions, not panic #10
• setup CI / publish #11
• Complete porting remaining widgets and demos (see issue list)
• make all of tui immutable #9
• scalaify the API (snake case => camel case, and whatever else comes up)

Adressing limitations of the design

tui has a simple interface and core, but doesn't model important things like event handling. It's fine for smaller apps because you can just write custom code for it (see all the demos), but it would be better to solve it properly.

The tui repo itself points to cursive instead for an improved design, so it's an obvious place to look for inspiration.

So why not just port cursive instead?

When I decided to try to port tui it was because it seemed manageable to port quicly:

• The core is quite small
• It was decently covered by tests
• It has a manageable internal dependency graph to enable porting piece by piece
• It was familiar to me

Cursive didn't seem manageable to me by those standards, so it just wouldn't have happened.

I'm fully convinced we'll be able to refactor tui-scala to for instance handle events gracefully.

[ckipp01]

Related to the the last point:

scalaify the API (snake case => camel case, and whatever else comes up)

Do you want me to dive into the renaming right away, or do you want to finish #26 first so it doesn't conflict?

[oyvindberg]

Yes i would certainly welcome help with the renaming!

Before you start though, maybe you can help me land the immutable branch? Not sure I need much coding help per se, but some feedback on the composable styling and atomic buffer cell writes.

I can do a writeup about where it's at and some tradeoffs tomorrow and you can try to weigh in?

Because after we land that, we can do all other smaller improvements, and start hacking on making the widgets into something which feels more like react components. At least that's where I think i want it to go :)

[ckipp01]

I can do a writeup about where it's at and some tradeoffs tomorrow and you can try to weigh in?

Absolutely. Just ping me when you're ready for me to dig through it.

[kubukoz]

Would it be desirable to cross-compile the library to SJS/SN?

[oyvindberg]

Maybe! I mean i likely haven't made it easy for you or particularly cared about it. My only focus was to support graalvm native image, mainly for bleep.

If you want to work on it you'll need to reimplement the crossterm facade on top of something else. Maybe that's easy - maybe it's impossible - i have no idea.

I would absolutely accept a PR though, if somebody wants it enough to port (and help maintain) it

[dejvid]

Hello, I am interested in the plan for handling events. Or is this already done in some branches? I would really like to avoid that while(true) loop and use the Tui framework to start the app, render the app, and end the app. Have you seen how Charm is doing it with the Elm architecture design pattern here? I find it an excellent idea.

[oyvindberg]

my work for now has stalled with #50 - that's an accurate representation of the newest. no work done on events so far