Roadmap
oyvindberg opened this issue · 5 comments
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
- #10
- #11
Complete porting remaining widgets and demos (see issue list)- #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.
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?
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 :)
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.
Would it be desirable to cross-compile the library to SJS/SN?
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