Future of `tui-rs`
fdehau opened this issue · comments
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
tuidraw 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
tuito 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. tuidoes not make any assumptions about how you want to drive your app: you don't have anapp.run()method taking over your program execution and forcing you to drive everything from the UI.
- it is easy to add
- 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
Widgeteven thoughWidgetare 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
tuito a crate like Cursive and officially deprecatetui. A more promising option would be something closer to what is described here. - Support for inline views which would make
tuiwidgets 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.
@fdehau I'd like to help. You have some low hanging fruits to get started?
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. 🥇
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.
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 #639)
Cheers,
--Dylan
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.
Hi, I really enjoy using tui-rs and would be extremely interested in doing my best to help maintaining it.
Cheers.
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.
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
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'd be interested in helping out, and as per the very first comment, I'd be happy to warmup with some low hanging fruits!
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.
I am highly interested in contributing too.
Does anyone have any insight as to what has happened since this issue was first opened ?
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.
@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
@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.
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: #689
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.
I wrote an email to him, but never received a response. I suspect a fork is required.
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.
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.
Works for me. It's a good idea.
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 😄
I'd be happy to fork tui-rs to that org, and create a team to manage it.
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.
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.
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?
@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.
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.
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
dotenvyintodotenvwith such thrust that allCargo.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.
Judging from the comments, have we reached a general consensus that forking is still a good idea?
Yes
I think we can take a page from dotenvy's book about naming
As an alternative we could use ce suffix. That way we could even get an easily pronounceable name like tuice.
I propose to name the fork tuile. It respects the French origins of the maintainer, it looks delicious and it means "tile", which is not so far-fetched for a UI library. :)
I propose to name the fork
tuile. It respects the French origins of the maintainer, it looks delicious and it means "tile", which is not so far-fetched for a UI library. :)
That was one of my suggestions too! Good one.
We're running a poll for naming: https://strawpoll.com/polls/BDyNEj7PwZR
My proposal would be to fork to a different repository but keep the name. Then update the revision to at least 1.0.0. The difficult part then becomes to convince Crates.io to point the crate to the new repository.
Such a process is not in place for Crates.io, but as the years transpire getting a process in place to handle abandoned crates would help a lot of projects.
We're running a poll for naming: https://strawpoll.com/polls/BDyNEj7PwZR
I do not see tuile as an option to vote for?
There was a lot of new name suggestions so we will create another poll soon. This much of attention was not expected 🐻
Please submit your naming suggestions here: https://forms.gle/LfKfevEZNXC2j687A.
Hey everybody 👋 Sorry for the very delayed response. My personal life and work took most of my free time and I had to mute all non-work related Github notifications for my own sanity. Thanks to those who reached out by mail, I'm now aware of the ongoing initiative.
As you have probably guessed already, I'm not in a capacity to support the plan I highlighted in my first message. But the good news is that it looks like a lot of you are willing to take over. Thanks for that.
First, I'm totally ok with the idea of a project fork if it is already too late (I'm not caught up on all the discussions).
But it seems that an official transfer of ownership would be better for the new maintainers. Thus, what do you think of the following plan:
- I create a new organisation
tui-rs. - I transfer
tui-rsto this new organization. - Those who volunteered to maintain this crate are invited as
Members. I need to figure out exactly what this entails but it looks like it should give you enough freedom to let the community self-organise (PR reviews, merge, closing issues, etc...). The only thing that will have to go through me at first are releases to crates.io (in order to avoid an hostile takeover). - Out of the new maintainers, some are chosen to get access to crates.io and becomes admin of the Github org. You get full autonomy over the development and release process.
- I'm removing myself from the Github org and crates.io. The project lives on its own.
Great to hear you are doing ok! Good luck to all you do :)
@fdehau I'm really glad to see you reply !
The timing is perfect as we have not yet created the fork nor the organization ! The plan you outlined for the transfer of ownership sounds good. However, if things are too busy for you, we can take the organization creation off your hands (of course making you an owner).
The process you outlined for the crates publishing sound good, as long as we are able to reach you, seems like a good way to proceed.
I personally am very excited this crate can live on under the same identity and look forward to seeing it flourish !
Feel free to join the discord server we setup if you want to participate in the discussion whenever you have time !
@fdehau By the way, I'm the one that emailed you in french. Me and two other individuals are currently moderating the discord server. Feel free to reply to my email or get in touch on discord in order to further coordinate the organization creation and ownership transfer.
@fdehau Glad to hear you're okay. Wanted to shoot you an email but did not want to bother you. Thank you so much for what you're willing to do for the community at this point. I'm personally still very interested in actively helping out, and did join the discord server cited above as soon as I was made aware of it.
@fdehau So good to see you back! As outlined in the previous replies, we would like to keep this awesome lib alive by doing whatever it means. Creating the organization and moving forward from there would be absolutely great!
Hello @fdehau, hope you're doing fine! 🐻
We decided it would be best for us to create a "temporary fork" for the time being until you are available to create the organization and invite the members. This way, we won't keep people hanging and start getting more familiar with the codebase. After the organization is created, we will be transferring all the changes there.
We're planning to start the process of working our way through the backlog of PRs and issues on Sunday. We will most likely create the temporary fork then.
Thank you for your awesome work for this library and we're looking forward to hear from you soon!
A quick update: we forked the project under tui-rs-revival/tui-rs-revival and start working on the PRs until the organization is created!
Update: We have decided to go with a new name, and are running polls again for the new name and version number.
- Name: ratatui-org/ratatui#72
- Version: ratatui-org/ratatui#70
@fdehau With ratatui now being the established successor, I think it would be a good idea to explicitely mention that and reference the new project in the README.
We have a request to add tui to the @rustsec database as unmaintained: rustsec/advisory-db#1610
We plan on listing ratatui as a maintained alternative, but if there are any others we should mention, please leave a comment on the linked issue.
@fdehau we'd like to get your approval on the advisory if possible as well
It sounds like we're all waiting for @fdehau to get back and updated us. He is still super active on GitHub, "153 contributions in private repositories Jun 1 – Jun 19". The desire seems to be,
- Update the Readme, make mention of ratatui being the successor.
- I would further "archive" the repo, since there is no utility in keeping it open. It just raising the educational burden.
To be fair @EvanCarroll his "super active" activity on GitHub appears to be his day job so you're making a false equivalency but I think we all still get your point.
That said, I too have a day job and I cannot blame him for not looking at GitHub outside of that when his day is complete and you shouldn't either.
It's not a false equivalence. You didn't uncover that the contributions were private: I provide the very same thing your screenshot said as a quote in the original message. The point is that the OP is safe, well, and programming elsewhere. As compared to dead, or incapacitated (or having left the industry). Anyway, thanks for obscuring a summary of this thread with a responsive that provides 0 value.
There is always one that has to keep this crap thread running.