Future of `tui-rs`

[fdehau]

Hi !

Some of you may have noticed that my activity as the maintainer of tui has significantly decreased over the past year. There are multiple reasons to that: my job is taking most of my creative coding energy (for good reasons), I don't use Rust enough (even though I miss it) and I have not used tui for personal/work projects in a while so my motivation to dedicate time to it is pretty low. None of that is likely going to change in a near future. At the same time, the popularity of the crate keeps growing and I keep seeing it used in very cool projects. So it would be a shame if all of that goes to waste.

Therefore, I want to try over the coming months to foster a welcoming community around this project and make myself more available so that one or multiple maintainers could slowly take over the development of this crate. The main issue is that I do not have a lot of experience doing so. tui is my first and only popular project and I have not been really active in any other open source projects so far. My main question for those who would be interested in getting more involved but also for current users of the crate would thus be: what would encourage you to start contributing ? What I have in mind so far is:

• an official communication medium to discuss topics or getting help (Github Discussions, Zulip, Discord). The idea would be to have a place for less structured discussion and keep Github Issues for real issues and more formal communication.
• a dedicated Github organisation
• a better "Contributing" guide so that everybody would feel empowered to contribute.
• a "Code of Conduct"

I'm obviously all ears for more or better ideas.

I think it would also be fair to share my current view of the status of this crate:

I think tui got popular for the following reasons:

• A "nice look and feel" by default: I'm convinced tui draw attention because it has a nice demo shown in the README that you can replicate pretty easily.
• Nice for quick prototyping:
  • it is easy to add tui to your project to draw quickly on your terminal. Having a UI does not even have to be the end goal: I used it in several occasions to have a better understanding of the internal state of my program. Sometimes a nice graph is way better than hundreds of logs.
  • tui does not make any assumptions about how you want to drive your app: you don't have an app.run() method taking over your program execution and forcing you to drive everything from the UI.
• Nice for Rust beginners: because of the immediate mode paradigm we avoid a lot of lifetime and ownership issues common to retained mode UIs in Rust.

tui was good enough for my own use cases. But then people started using it in more ambitious projects and it started to show some shortcomings:

• The immediate mode paradigm is not clear to everyone. I keep getting a lot of requests to make it possible to store or return Widget even though Widget are simply configurable draw commands.
• It is hard to build complex UI abstractions on top of tui: scroll, mouse support and advanced layouts are for example challenging in the current state of the crate.
• Only suitable for full screen apps.

I thus think that tui most promising changes would be:

• A new architecture enabling the missing UI features. I don't think a common retained mode approach would be a good strategy though. At this point, a better investment of everyone's time would be to port the "look and feel" of tui to a crate like Cursive and officially deprecate tui. A more promising option would be something closer to what is described here.
• Support for inline views which would make tui widgets available in CLI tools.

You obviously don't have to agree with any of that 😅.

So if the perspective of helping to maintain a fairly popular rust crate sounds like an interesting challenge to you, please reach out on this issue.

[wookietreiber]

@fdehau I'd like to help. You have some low hanging fruits to get started?

[7sDream]

tui is such a great project that I used it a lot in many of my projects. Almost every time I need a UI, tui comes into my mind and works pretty well!

minimalist but attractive looking, immediate mode, full screen, great Canvas widget, etc. All of these features are why I love it. It will be a huge loss if it's no longer maintained or developed 😢

So I want to help too. Although I'm not very familiar with the layout engine or GUI implementation paradigm to help with those big architecture upgrades, I think some peripheral work is within my capabilities, like texting, styling, creating new widgets, etc.

For example, I've recently found that creating complex styled text requires a lot of code, and it's a bit of a pain if the text is a lot and needs to be changed frequently. So I created a markup language to generate styled text from plain text and added a generator for tui's Text just in those days.

Is it possible to have functionality like this (optionally) built into the tui library? I think I can help with works like this.

Speaking of the developer community, I think an official chatroom is very useful, both for users and developers. And a Contributing Guide will be great too. Other staff doesn't make much sense to me, personally.

Thanks again for your excellent work. 🥇

[wcampbell0x2a]

I use tui in both my public projects as well as some of my private projects. I'd be willing to help maintain this crate.

[dymk]

I think tui-rs is great for simple to simple-moderate applications. I have some thoughts on what an immediate-mode API could look like, while still having ergonomic stateful widgets for the obvious cases (such as list selection, or text inputs), but I think that would be most appropriate for a separate TUI library, as to adopt them into tui-rs would result in an incompatible API.

I agree with you than an Elm-like architecture (similar to Redox, for the web developers) for Rust applications makes sense. I ended up building something that looks basically like that to make state management more reasonable, and to separate the "view" logic from the "model/controller" logic. It meshes well with Rust's immutable-refs-by-default policy as well, so views don't need anything but a non-mut reference to render the app.

That being said, I'd be happy to help maintain tui-rs in its current form. I think the community gets a lot of value out of it because it's very straightforward. There's no magic state maintained on your behalf for e.g. list selection or text-inputs - that's all explicit and managed by the library consumer. Writing custom widgets is super easy, because the API is so simple. This of course is at odds with applications with complex state, but I think that's a reasonable tradeoff, and a separate project would have a home filling that other niche.

(I'm not opposed to augmenting the API in a backwards-compatible way though, to support more complex widgets, such as https://github.com/fdehau/tui-rs/pull/639)

Cheers, --Dylan

[tbung]

I use this crate in my personal and professional work as well and will try to contribute as much as I can. As I am somewhat new to rust it'll probably be constrained to simpler stuff for the time being.

As far as architecture goes I think I agree with @dymk, I read the Xilem article even before seeing this issue and found it quite interesting, but there is an argument to be made for maintaining this crate's current simplicity. Please take my opinion with a grain of salt though.

[pierreyoda]

Hi, I really enjoy using tui-rs and would be extremely interested in doing my best to help maintaining it.

Cheers.

[mrjackwills]

Just wanted to add that I have found tui-rs to be a great package, and although at first I was daunted by it, the examples that you have provided are a superb experience for learning how to use it, although I probably do things inefficiently in my own work - see oxker.

I would like to help in any way that I can, although I haven't looked into the tui-rs source that much, and my current Rust knowledge isn't that great.

[TBS1996]

If you make an official zulip or discord then I'll definitively join it, I think an informal chat-community like that is a good starting point to generate discussion on where to go onwards from here

[sayanarijit]

As the author and maintainer of xplr, a somewhat popular tool using tui, I'm interested in getting involved with whatever you decide to be the best course of action. I believe a community around people using tui crate would be really cool. If we take inspiration from the @charmbracelet community, I have high hopes that we can too give back to the foss community countless valuable tools.

Finally I'd like to link to this insightful discussion around community building and sustainability in the opensource.

[sayanarijit]

Also inviting @orhun, the author of gpg-tui, kmon and other cool tools to the discussion.

[0x4ndy]

I'd be interested in helping out, and as per the very first comment, I'd be happy to warmup with some low hanging fruits!

[orhun]

As the author and maintainer of xplr, a somewhat popular tool using tui, I'm interested in getting involved with whatever you decide to be the best course of action. I believe a community around people using tui crate would be really cool. If we take inspiration from the @charmbracelet community, I have high hopes that we can too give back to the foss community countless valuable tools.

Finally I'd like to link to this insightful discussion around community building and sustainability in the opensource.

I totally agree with @sayanarijit, I think tui is a valuable project and it can be actively maintained with the help of a community.

[mindoodoo]

I am highly interested in contributing too.

Does anyone have any insight as to what has happened since this issue was first opened ?

[moali87]

I'm starting to learn rust, and have an ambitious project of creating a TUI for jira management. I'm constantly on discord for my other projects, if need be, I can create another server if we would like to meet there.

[Halkcyon]

@mindoodoo It's hard to say, @fdehau hasn't replied to the issue. I'd love to see what Textual is creating with their TUI framework recreated in Rust

[kivimango]

@fdehau Its been months since this issue raised, there are people willing to maintain and contribute to tui-rs. Have you decided the future maintainer yet ? Please don't let this project die. Thanks.

[rhysd]

As an author of tui-textarea, I can help some maintenance work for this crate. For now, I submitted a PR to follow the crossterm major version bump and fix CI failure: https://github.com/fdehau/tui-rs/pull/689

[mindoodoo]

At this point, has anyone attempted to reach out to him through any other channels ? We just need a new maintainer with the authority to merge PRs while waiting to maybe build a more permanent community.

If @fdehau doesn't reply, it's also always an option to make a new fork designated as the most up to date, but that's sort of the hard way in all this.

[fnordpig]

I wrote an email to him, but never received a response. I suspect a fork is required.

[orhun]

He seems active on GitHub which is a good sign. I suspect he might be too busy which means eventually a fork will be required.

[mindoodoo]

Alright, so how about a couple of us hop on a quick call or something like that and discuss the possibility of forking the project ? If @fdehau comes back after the fork, we can always transition back to the original repo and what not.

I'll tag a couple people who have expressed interest. @orhun @fnordpig @rhysd @kivimango @sayanarijit @7sDream

Let me know what you guys think, the original maintainer isn't showing any signs of coming back, would be stupid to wait for this great crate to dies before attempting a fork.

[orhun]

Works for me. It's a good idea.

[wookietreiber]

IMHO we should either use an existing or create a new GitHub organization for the fork. I think that'd be more appropriate for a community-managed, high bus factor project. I've started an org like that a while back to put some of my CLI projects in: https://github.com/rust-cli-enthusiasts -- just haven't like actively promoted it :smile:

I'd be happy to fork tui-rs to that org, and create a team to manage it.

[mindoodoo]

Yeah I think an organization will definitely be required in order to go the community driven route.

So I just created a discord server for us to continue chatting about the possibility of forking. I only copy pasted a little set of rules in a separate channel, didn't do much on it otherwise. Just a temporary solution for the time being.

Feel free to join, and I look forward to chatting with you guys there !

Oh, and if in the future the link has expired, just ping me on here and I'll get you a new link.

[7sDream]

As @fdehau post in this issue, moving this repo into a dedicated organization to encourage contributing is in his follow-up plan.

And, forking is actully a common thing in open source world, so I can't come up with any reason to stop us from doing that.

[fnordpig]

I'm a little too new to the rust community, how is the process of publishing a crate work? How does a crate's github repo get changed to a fork?

[kivimango]

@mindoodoo i hoped that this wont happen. but i think the decision has been made: tui-rs will be forked to keep alive the project and improve it in the future.There are already popular projects depend on it.

[rhysd]

If we fork this crate, I think the name should be chosen carefully. I remember that dirs crate went inactive, the dirs-next fork was created, then dirs was back to active again so dirs-next is actually older than dirs now.

[orhun]

I think we can take a page from dotenvy's book about naming:

The legend

Legend has it that the Lost Maintainer will return, merging changes from dotenvy into dotenv with such thrust that all Cargo.tomls will lose one keystroke. Only then shall the Rust dotenv crateverse be united in true harmony.

Until then, this repo dutifully carries on the dotenv torch. It is actively maintained.

[anthonygedeon]

Judging from the comments, have we reached a general consensus that forking is still a good idea?