Rust is simply not meant for GUI-based data design but I still want Qt in Rust. That's it. Not QML or Slint. No markup at all. None of the immediate mode things. No other languages. Definitely not GTK. I'm worried it will never happen for Rust and it will be such a missed opportunity.
No, the people making TUIs in Rust are making TUIs because they love TUIs, and because Ratatui is pretty delightful. The state of GUI frameworks in Rust is irrelevant for this purpose, because even if there existed your ideal of Qt in Rust (putting aside the debatable notion that Qt is some sort of pinnacle of design), the people making TUIs wouldn't care, because that's not what they want to make.
Apart from what you said about the GUI situation in Rust (which I disagree with) I think TUI's have their niche.
I think writing a useful GUI has considerable overhead no matter which technology you use. In addition they cause other difficulties, like testability, i18n, l10n and accessability.
This is why people often resort to command line tools, rightfully so.
There are cases, however, where a CLI won't cut it and I believe TUI's are a nice and lean solution that sits right between CLI and full-blown GUI and isn't going anywhere.
I have to agree with this, but for a lot of different things other than GUI as well. My friends all want me to use Rust, but I moved back to C++ after trying to do a lot of different projects in it after finding every crate I needed to be a WIP or abandoned state. There are the massive crates that are super popular of course, but it seems that once you get off the popular beaten path the available crates becomes far worse than any other language I have ever used.
Of course comparing Rust to something like Python or C++ is unfair to Rust, since Rust has had less time to develop those packages, but I think its more about the community at this point. I just don't see any enthusiasm for working on crates/frameworks. Most of the time when I find a crate I need, its sitting at version 0.3.0, last updated 1-3 years ago, with the documentation simply stating "Reimplementation of X in Rust, go read X's C++ documentation on how to use."
IMO, traditional GUI frameworks in Rust (like Qt) are difficult for the same reason that game engines in Rust are difficult: cyclical references. A window might contain a group box which contains a text field and a button. All of these are (direct or indirect) children of the window, but all children also hold a reference to their parent. Qt's signal-slot mechanism would also be difficult to implement in Rust.
You basically preempted nearly every single option, including an incumbent one. I don't believe it's fair to judge Rust based on its compatibility with Qt alone - something written in C++. Nothing against C++, but it's harder to get C++ and Rust to work together. You haven't addressed Iced yet, though going by your requirements, you're unlikely to be satisfied by it as well. Iced is not there yet, but it is the native GUI toolkit of the Cosmic desktop.
It's amusing reading things like this. Meanwhile, we have at least 4 high-quality, practical GUI frameworks to choose from. You want QT in rust? I get that, but that is different from your claim about the state of GUIs in rust.
"I like the A tool in category B. System C doesn't have tool A; system C is dreadful in category B".
I think you could have made the acute part of this argument about GUIs in rust 3 years ago, but not today!
I need to try Slint and GPGUI. I love EGUI, but need to do a proper comparison; could be missing out. This seems to be a concern of a different nature from the one you describe!
I think it's pretty normal to have a language dedicated to the UI structure. It should be declarative for easy machine manipulation with a WYSIWYG editor and could be translated to code before compilation.
My reference in this are Delphi .dfm files, which you rarely have to edit manually because they're handled by the IDE form builder. It is still a fantastic IDE to build native UI apps and I don't see a reason why Rust couldn't be used the same way.
I kept forgetting Narrator is a Windows program, and the post read like the author was referring to the "Narrator voice in their head" while testing the UIs.
It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.
The linked post is worthless. It’s a bunch of whining about how various rust stuff doesn’t work correctly on Windows “The most popular OS for developers.” Nobody cares.
I just completely disagree. We have Slint, Dioxus, Tauri, Egui (best imo).
If Dioxus blitz renderer takes off them it will vastly better than 99% of options for other languages
I'm really waiting for the TUI web browser. That would let me live completely in the terminal.
Is anyone working on this?
With the speed terminals are and support for graphics through things like sixel and shaders I'd love to have a browser even if I couldn't do videos. Even if it was like viewing most pages in reader mode.
I'm not sure some big companies would be happy about that though since it likely would mean you could do things like ad blocking more easily. But maybe you could get them on board if you pitched it as a browser for LLMs. Something something it's a native interface for them. ;)
I know there's some browsers but things like W3M, Lynx, or *links* are... rough... definitely not of the quality we're seeing elsewhere in the current TUI revolution.
But.. why? Like I do get the occasional need where it's easier to just see an html page in the terminal, but why would you render to a low-resolution 2D buffer with random character-hacks with a huge amount of overhead, over having a real buffer and just writing pixels to it, with actual hardware acceleration?
Why would you want to live in a terminal? That's extremely limiting. What you really want is Emacs. Emacs has both a TUI web browser (EWW) and info browser already. You can even run vim in Emacs if you want, either the "real" (and inferior) thing via vterm, or use evil mode or another modal mode for Emacs like god mode.
Markdown is really cool in the sense that you can still look at the raw text and read it easily. But one thing that always made me load up .md files in the browser was that it's just much easier to read when the headers are bigger.
So I wrote a markdown viewer that renders the headers as images. You need to configure your font once for it to work, can't really detect the terminal font. It obviously also renders inline images, which was another reason to use the browser.
And then, Kitty developed the novelty https://sw.kovidgoyal.net/kitty/text-sizing-protocol (I think it's now also implemented in Ghostty), which means we can skip the text-to-image processing and directly leverage that protocol.
We just don’t have good desktop GUI platforms anymore. Qt and GTK are massive beasts, Windows changes theirs every 4 years (and no one wants to be tied to a single platform anyway), we don’t want to deal with Electron, and writing your own GUI from scratch is hard.
Terminals just got good lately and it’s way easier to make something higher quality in them than as a GUI. It’s just too hard to make a good small desktop app.
It’s the same reason why it’s easier to make something look great with LEGO than if you want to mold clay. I’d also wager that devs today on average know more about good UX than devs did back in the 80s when clunky terminal apps used to be made.
TUI libraries have sufficiently abstracted away the low-level quirks of terminal rendering that the terminal has become something like a canvas[0] available in the IDE with no extensions. This is quite a nice DevX if you want to display the state of an app that does something to data, without writing the necessary plumbing to pipe that data to a browser and render it.
> I've seen lots of TUIs lately, why is that? What is the renewed interest?
A few reasons:
- for the most part TUI apps are cross-platform: macOS, Linux, BSD, Windows
- they cut down on context switching. If you're already in the terminal, you shouldn't have to switch to a GUI app to check on something.
- Today's terminal emulators—Ghostty, WezTerm, Kitty, iTerm, Alacrity, etc.—are fast and capable with GPU acceleration, 24-bit color support running on high resolution displays. It makes for a compelling platform to code for.
- Anecdotally lots of developers are spending less time in IDEs and more time in the terminal using Claude Code, Gemini CLI, Codex, etc.
I think that a lot of people here at HN have had bad web interfaces and GUIs inflicted on them for a long time, that a TUI is a welcome change and a big improvement. TUIs are limited, which make it hard to create great interfaces; but those limits also make it hard to create really bad interfaces. Also the TUI is genuinely good at simple-to-moderate complexity software. For an example, try out Midnight Commander.
For me, often, it’s an escape for a GUI world taken over by out-of-control “design” tenets. I value good Ux design concerns, but often working with designers lately feels bureaucratic, at times cargo culting, and overly spacious.
It’s like a graphical form of “I didn’t have time to give you a short answer, so I gave you a long one instead”. TUIs force a paucity that often makes for a nice information/pixels ratio.
Unrelated to the article, a lot of my millennials could see web and then mobile coming, focused on web & mobile, and as a result just weren't really participating in C and C++ development. We used terminal applications leftover from peak GNU.
When Rust came along and presented a career opportunity, terminal apps was a great way to get into it and filled a gap in a lot of people's skill sets. Even when building GUI apps in Rust, your first entry point is a CLI usually.
We took our UX thinking from web & mobile and remixed it with Rust and new ideas came out. Turns out "If it aint broke don't fix it" for two decades can build up a lot of evolutionary pressure.
The main reason for me is simple keyboard navigation. I don't want to click through links and menus, I don't want to use the mouse at all. I think that's also why tiling window managers are popular again.
My theory, web apps are extremely bloated and slow, teams behind it always “optimize” and switch things up, and desktop apps are usually just wrapped web apps. TUI developers don’t mind settling and not always messing up the product and they keep the TUI “lean and mean”. Some users appreciate fast, simple UIs and they don’t want to be constantly A/B tested on only for the core experience to break all the time.
Idk, I see it them all the time on the rust subreddit. Like, cool, but my friend, I have like ten brain cells and all of them are in overdrive. I’m not going to remember I have your TUI app installed AND remember the commands to make it work. If I have to use a CLI I just save the command I need in a text file so I don’t have to look them up. Just give me ang button any where. I’m not picky.
i think this might be caused by codex.
it's open source, many people use it and it uses ratatui. People check how it is implemented and discover ratatui.
I believe this might be current most popular application using this library.
That's a big question. I think TUIs are great for glue processes, and it doesn't hurt when they look pretty. They're also excellent first projects with composable interfaces. Shell code is such a pain. It's quick and dirty, but there are a lot of footguns. The main challenge is reducing the friction of making a TUI to the point where it's easy to execute an idea, and a lot of frameworks do this really well. Add the proliferation of LLMs on top, and maybe that could explain it?
I don't care much about forms and windows in the command line (I've had enough of turbo vision back in the 90s), but I don't think I am alone in wanting to see some progress bars and stats for long running processes. So 2% of these libraries is actually pretty useful.
The terminal remains an extremely compelling computing environment in spite of its limitations and fifty years of technical debt. As anachronistic as arcane escape codes and box drawing characters seem in $CURRENT_YEAR, the fact remains that nothing has arisen to fill its niche.
They're easier to program and seamlessly integrate into the terminal. That's basically it, other than that they're worse than normal GUIs. Also, GUI frameworks aren't that mature in Rust in particular.
Yeah I think it’s the software equivalent of “go back to the land” type movements. Resurgence of Linux tiling window managers, NeoVim, TUIs. Everything in web and Electron land feels busy, attention grabbing, and bloated. Heck, even VSCode’s defaults are a kind of cluttered.
I for one love the tranquility of a dark mode terminal and find it quite pleasant with a nice nerd font, a pretty color scheme, a single high resolution monitor and an ergonomic keyboard. I feel much more connected to the code or data I’m interacting with in that space. Trying to live there as much as I can lately. JiraTui has been great for preventing context switching at work.
I tried Ratatui for a small app. I just needed a textbox, and I copied an example from the tutorial. When typing (quickly), the CPU usage was crazy. I was expecting something like 0% CPU (it's just typing text, a similar app in Go uses nothing) but it was using like 8% CPU.
I would guess I was doing something wrong, but it was really running an example from the official website. So I gave up on Ratatui.
I don't know what I just got into, but I love it. Reminds me of Hattrick (the decades old soccer management sim) but with more elbow grease and panache. If you're even remotely interested, just ssh in and you're off to the races.
BTW, the video at the top of the repo readme won't open on any device I own.
Looks really cool! Love the artwork. Right now the video in the readme doesn’t render on github, though. I had to manually download the mp4 from your demo folder to view it.
Ratatui is neat but the way it's architected, you need to take on third party dependencies for each individual widget. And we're talking basic things like spinners, checkboxes, text areas, etc. -- there aren't too many widgets built into ratatui itself. I didn't like the idea of taking all that on so instead I went with something more handrolled.
That's pretty much how I would expect a UI framework to work. As long as each widget class only depends on the UI base classes the dependencies should be small and grow proportionally to the number of widgets types used by the app. This should also being much less version churn than a big central library including everything.
Rust has a culture of using lots of dependencies in general. I'm not super happy about this. I'd prefer a few larger dependencies, but most of the time I don't have the time/energy/talent to rebuild (or even vendor) these dependency trees
the title of this post is odd? it’s a showcase of TUI applications built with this Rust crate — which I am hearing about for the first time, and am interested in. I was expecting a blog post on why Rust is experiencing a TUI revolution or something
Would be more and more useful to have terminal CLI utilities like running a given prompt or agent over a folder. I'd use that for auditing legal compliance for some projects.
How is the Windows support in Ratatui? I recently developed something with a different library (also crossterm based) only to discover it did not work very well for my windows users and ended up having to build a GUI with Iced.
There’s a very real chance I just missed some initialization code that Ratatui might do out of the box that the other library was not.
Edit: Issues experienced by windows users were no colors, terminal flashing on every keypress, all keypresses registered as double.
Edit2: This miniature rant inspired me to go back to the commit and submit a patch to eliminate the event reporting on KeyUp and enable terminal colors.
I’ve been experimenting with a coding agent project [0], and ratatui-rs became my framework of choice for building its first TUI. [1] The framework now ships with native list view support and improved terminal capabilities, including smoother mouse interaction and text selection.
Some of the most interesting projects here have the worst installation stories.It's sort of tilting at windmills to not acknowledge that people are going to mostly install through package managers for their platform by advertising it as such. I'm not suggesting there's anything wrong with building from source. On the contrary, I think it's fantastic as many targets are supported here as there are! I think it's a shame more people aren't discovering them is all.
Rust, following Go's footsteps, has made it very easy to distribute-and-compile from source. They've taken all the pain out of the compiling-from-source pipeline, through "go build" or "cargo build"
Meanwhile, distributions sometimes maintain their plodding rate at package updates (usually handled by distribution volunteers, not the original program's developers), which was developed in an era when building from source was a tedious process where the distribution volunteers provided value.
In effect, build-from-source has taken over "just use the distribution package".
CA Clipper database stuff was my jam! I only wish I had gotten into Turbo Vision. I used to watch my users fly through db apps filling out forms, hititng TAB between fields. There was just something so natural about it. The first app we ported to a web-based solution was really painful to watch.
Wow, I did not know that some of my most loved apps in terminal are written in Rust: yazi, atuin, bottom, isn't fzf also written in Rust? And today I learned about some more I want to explore: csvlens, bandwhich, dua, material, oha.
I find these apps so increadibly useful, I almost want to learn Rust :D
I began learning Rust in my spare time - as a C++ dev it seemed like the right thing to do. I ended up using Ratatui for a hangman implementation. I really liked using it, I ended up with an itch to make an oldschool roguelike with it. Perhaps some day I'll carry on and do it.
This is basically how dioxus 0.7.0 works. You can download components, and they will automatically add the source to your source and then you can just freely use them
I want a small wrapper around slumber so it can take the same command line arguments and options as curl. I now there are several attempts at making a graphical UI for curl, but slumber has a very nice and simple cli.
What is the best / most popular / user friendly terminal http client I can replace postman with. Has a history I can search, save favorites, secure etc.
I like smaller more focused tools on the terminal. You can make these all work together pretty reasonably with a little glue. Hurl, mitmproxy, httpie with http-prompt. I tend to prefer mitmproxy sessions and massaging that with Python/curl as needed for repeating and tweaking. User friendly is relative, but these tools work well. Python for tweaking http streams in mitmproxy is powerful and rather friendly for what you get in return. Mitmproxy lets you easily save flows with a bit of Puthon glue to output httpie commands giving history, and you can save mitmproxy sessions.
I recently asked grok-code-fast-1 to read the SST OpenTUI readme and docs (gave it the github link), and to write an implementation plan for an OpenTUI usage mode for my Rust CLI stdin/stdout app. It fetched the readme. Fetched a couple more doc pages. Response begins "Sure, here's the plan: I'll write a TUI using the Rust package Ratatui..."
RustSupremacist|3 months ago
Rust is simply not meant for GUI-based data design but I still want Qt in Rust. That's it. Not QML or Slint. No markup at all. None of the immediate mode things. No other languages. Definitely not GTK. I'm worried it will never happen for Rust and it will be such a missed opportunity.
kibwen|3 months ago
weinzierl|3 months ago
I think writing a useful GUI has considerable overhead no matter which technology you use. In addition they cause other difficulties, like testability, i18n, l10n and accessability.
This is why people often resort to command line tools, rightfully so. There are cases, however, where a CLI won't cut it and I believe TUI's are a nice and lean solution that sits right between CLI and full-blown GUI and isn't going anywhere.
PoorRustDev|3 months ago
I have to agree with this, but for a lot of different things other than GUI as well. My friends all want me to use Rust, but I moved back to C++ after trying to do a lot of different projects in it after finding every crate I needed to be a WIP or abandoned state. There are the massive crates that are super popular of course, but it seems that once you get off the popular beaten path the available crates becomes far worse than any other language I have ever used.
Of course comparing Rust to something like Python or C++ is unfair to Rust, since Rust has had less time to develop those packages, but I think its more about the community at this point. I just don't see any enthusiasm for working on crates/frameworks. Most of the time when I find a crate I need, its sitting at version 0.3.0, last updated 1-3 years ago, with the documentation simply stating "Reimplementation of X in Rust, go read X's C++ documentation on how to use."
dlivingston|3 months ago
goku12|3 months ago
elmt35|3 months ago
sunbum|3 months ago
the__alchemist|3 months ago
"I like the A tool in category B. System C doesn't have tool A; system C is dreadful in category B".
I think you could have made the acute part of this argument about GUIs in rust 3 years ago, but not today!
I need to try Slint and GPGUI. I love EGUI, but need to do a proper comparison; could be missing out. This seems to be a concern of a different nature from the one you describe!
junon|3 months ago
It's no less or more equipped than C or C++, so not really sure what to make of this comment given the username lol.
speed_spread|3 months ago
My reference in this are Delphi .dfm files, which you rarely have to edit manually because they're handled by the IDE form builder. It is still a fantastic IDE to build native UI apps and I don't see a reason why Rust couldn't be used the same way.
k_bx|3 months ago
linhns|3 months ago
dancemethis|3 months ago
It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
lenkite|3 months ago
krzyk|3 months ago
Because it is quite easy to do.
There are also TUIs in other languages, just Rust is more cool.
ogoffart|3 months ago
This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperativ...
claudiug|3 months ago
Tepix|3 months ago
Haha!
athoneycutt|3 months ago
WD-42|3 months ago
Diti|3 months ago
[1]: https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fa...
vablings|3 months ago
godelski|3 months ago
Is anyone working on this?
With the speed terminals are and support for graphics through things like sixel and shaders I'd love to have a browser even if I couldn't do videos. Even if it was like viewing most pages in reader mode.
I'm not sure some big companies would be happy about that though since it likely would mean you could do things like ad blocking more easily. But maybe you could get them on board if you pitched it as a browser for LLMs. Something something it's a native interface for them. ;)
I know there's some browsers but things like W3M, Lynx, or *links* are... rough... definitely not of the quality we're seeing elsewhere in the current TUI revolution.
gf000|3 months ago
awesomeusername|3 months ago
It's glorious
[0] https://www.brow.sh/
littlestymaar|3 months ago
You can already do this, since the 90s: Lynx[1] and w3m[2] have both existed for more than three decades at this point.
[1]: https://en.wikipedia.org/wiki/Lynx_(web_browser)
[2]: https://en.wikipedia.org/wiki/W3m
be_erik|3 months ago
miguel_martin|3 months ago
mike31fr|3 months ago
globular-toast|3 months ago
fruitworks|3 months ago
https://sr.ht/~ireas/cursive-markup-rs/
the whole cursive library strikes me as very html-like in layout
unknown|3 months ago
[deleted]
the_gipsy|3 months ago
https://github.com/benjajaja/mdfried/
Markdown is really cool in the sense that you can still look at the raw text and read it easily. But one thing that always made me load up .md files in the browser was that it's just much easier to read when the headers are bigger.
So I wrote a markdown viewer that renders the headers as images. You need to configure your font once for it to work, can't really detect the terminal font. It obviously also renders inline images, which was another reason to use the browser.
And then, Kitty developed the novelty https://sw.kovidgoyal.net/kitty/text-sizing-protocol (I think it's now also implemented in Ghostty), which means we can skip the text-to-image processing and directly leverage that protocol.
unmotivated-hmn|3 months ago
omarvanez|3 months ago
The only places I know of is Awesome TUIs [0] and terminaltrove [1]
I can also see that Ratatui has an awesome list too [2].
[0] https://github.com/rothgar/awesome-tuis
[1] https://terminaltrove.com/
[2] https://github.com/ratatui-org/awesome-ratatui
laserbeam|3 months ago
We just don’t have good desktop GUI platforms anymore. Qt and GTK are massive beasts, Windows changes theirs every 4 years (and no one wants to be tied to a single platform anyway), we don’t want to deal with Electron, and writing your own GUI from scratch is hard.
Terminals just got good lately and it’s way easier to make something higher quality in them than as a GUI. It’s just too hard to make a good small desktop app.
It’s the same reason why it’s easier to make something look great with LEGO than if you want to mold clay. I’d also wager that devs today on average know more about good UX than devs did back in the 80s when clunky terminal apps used to be made.
genidoi|3 months ago
[0] https://github.com/NimbleMarkets/ntcharts/blob/main/examples...
alwillis|3 months ago
A few reasons:
- for the most part TUI apps are cross-platform: macOS, Linux, BSD, Windows
- they cut down on context switching. If you're already in the terminal, you shouldn't have to switch to a GUI app to check on something.
- Today's terminal emulators—Ghostty, WezTerm, Kitty, iTerm, Alacrity, etc.—are fast and capable with GPU acceleration, 24-bit color support running on high resolution displays. It makes for a compelling platform to code for.
- Anecdotally lots of developers are spending less time in IDEs and more time in the terminal using Claude Code, Gemini CLI, Codex, etc.
webnrrd2k|3 months ago
travisgriggs|3 months ago
For me, often, it’s an escape for a GUI world taken over by out-of-control “design” tenets. I value good Ux design concerns, but often working with designers lately feels bureaucratic, at times cargo culting, and overly spacious.
It’s like a graphical form of “I didn’t have time to give you a short answer, so I gave you a long one instead”. TUIs force a paucity that often makes for a nice information/pixels ratio.
lynndotpy|3 months ago
positron26|3 months ago
When Rust came along and presented a career opportunity, terminal apps was a great way to get into it and filled a gap in a lot of people's skill sets. Even when building GUI apps in Rust, your first entry point is a CLI usually.
We took our UX thinking from web & mobile and remixed it with Rust and new ideas came out. Turns out "If it aint broke don't fix it" for two decades can build up a lot of evolutionary pressure.
mendelmaleh|3 months ago
serial_dev|3 months ago
J_Shelby_J|3 months ago
Szpadel|3 months ago
I believe this might be current most popular application using this library.
I'm surprised it isn't included in this showcase
CSSer|3 months ago
tptacek|3 months ago
nurettin|3 months ago
the_gipsy|3 months ago
This means almost all TUI programs can be entirely keyboard driven.
Almost all GUI programs fail at this, in other words, it's extremely likely that at some point, something that requires a mouse action will interrupt.
DC-3|3 months ago
morkalork|3 months ago
orbital-decay|3 months ago
pixelready|3 months ago
I for one love the tranquility of a dark mode terminal and find it quite pleasant with a nice nerd font, a pretty color scheme, a single high resolution monitor and an ergonomic keyboard. I feel much more connected to the code or data I’m interacting with in that space. Trying to live there as much as I can lately. JiraTui has been great for preventing context switching at work.
Thom2503|3 months ago
ssh teletekst.nl
[1] https://tweakers.net/geek/237754/nos-maakt-teletekst-beschik...
palata|3 months ago
I would guess I was doing something wrong, but it was really running an example from the official website. So I gave up on Ratatui.
nhatcher|3 months ago
nhatcher|3 months ago
https://github.com/ironcalc/TironCalc
Into the main repo :
https://github.com/ironcalc/ironcalc
Now, I'm not 100% convinced ratatui is the way to go after seeing what the folks of Microsoft did with edit.
Anyhow, I think TironCalc is a great open source project to work with Rust and Ratatui.
discoinverno|3 months ago
https://github.com/ricott1/rebels-in-the-sky
gausswho|3 months ago
BTW, the video at the top of the repo readme won't open on any device I own.
benrutter|3 months ago
Absolutely fantastic description right there.
seabass|3 months ago
ModernMech|3 months ago
speed_spread|3 months ago
bbkane|3 months ago
dkdcio|3 months ago
wrs|3 months ago
Charm would probably say the same for Go.
tomhow|3 months ago
Submitters, please remember this from the guidelines:
... please use the original title, unless it is misleading or linkbait; don't editorialize.
airstrike|3 months ago
dkdcio|3 months ago
eric-burel|3 months ago
whycombinetor|3 months ago
nhatcher|3 months ago
Bluetui – A TUI for managing Bluetooth on Linux
https://news.ycombinator.com/item?id=45817114 https://github.com/pythops/bluetui
diab0lic|3 months ago
There’s a very real chance I just missed some initialization code that Ratatui might do out of the box that the other library was not.
Edit: Issues experienced by windows users were no colors, terminal flashing on every keypress, all keypresses registered as double.
Edit2: This miniature rant inspired me to go back to the commit and submit a patch to eliminate the event reporting on KeyUp and enable terminal colors.
zdragnar|3 months ago
vinhnx|3 months ago
[0] https://github.com/vinhnx/vtcode
[1] https://github.com/ratatui/awesome-ratatui
CSSer|3 months ago
AceJohnny2|3 months ago
Meanwhile, distributions sometimes maintain their plodding rate at package updates (usually handled by distribution volunteers, not the original program's developers), which was developed in an era when building from source was a tedious process where the distribution volunteers provided value.
In effect, build-from-source has taken over "just use the distribution package".
Jaxan|3 months ago
mbm|3 months ago
https://terma.mattmay.dev/
pjmlp|3 months ago
Need to dust off my Turbo Vision and Clipper projects.
nobleach|3 months ago
submeta|3 months ago
I find these apps so increadibly useful, I almost want to learn Rust :D
timeon|3 months ago
Derpdiherp|3 months ago
jossephus01|3 months ago
vablings|3 months ago
https://dioxuslabs.com/components/
thomasfl|3 months ago
alfiedotwtf|3 months ago
Any recommendations for something that’s ergonomic to use and looks nice?
siavosh|3 months ago
tonypapousek|3 months ago
bitexploder|3 months ago
seabrookmx|3 months ago
I starred Posting[1] but haven't yet got around to trying it.
[1]: https://news.ycombinator.com/item?id=40926211
Edit: here's another one: https://github.com/LucasPickering/slumber
tcoff91|3 months ago
esseph|3 months ago
esafak|3 months ago
nullbyte808|3 months ago
swiftcoder|3 months ago
unknown|3 months ago
[deleted]
whycombinetor|3 months ago
renewiltord|3 months ago
MangoToupe|3 months ago
[deleted]
rireads|3 months ago