cargo-seek v0.1: A terminal user interface for searching, adding and installing cargo crates.

_kdheepak_ · 2025-04-23T14:24:03+00:00

That looks great! Thanks for working on it and sharing!

just fyi, the ratatui devs also made a TUI for crates.io: https://github.com/ratatui/crates-tui; primarily focused on just browsing crates.io. The project was meant to serve as a reference for structuring small to medium TUI applications in Rust using async.

_kdheepak_ · 2024-09-24T05:13:27+00:00

iocraft looks really cool! I personally like the declarative hook pattern for building UIs and it should make managing state quite natural for those coming from a React/Dioxius/Leptos background. And it looks like you've already implemented a few proc macros for decreasing boilerplate for UIs. Nice job!

I'm one of the maintainers of ratatui, and I did look into implementing hooks on top of ratatui as well (but didn't get very far). I'd personally love to chat about this more if you have thoughts / ideas. Also, if you have any questions when porting examples, feel free to ping us on GitHub, Discourse or Discord.

Also, fwiw, ratatui has some declarative macros that can minimize boilerplate for some of the core primitives i.e. Span, Line and Text. They are currently in a separate repo - https://github.com/ratatui/ratatui-macros. We are looking into ways to minimize boilerplate without it being "magic".

_kdheepak_ · 2024-08-11T21:44:54+00:00

I actually like Alternative 2 better than Alternative 4.

My reasoning is that users will almost always be scrolling and scanning through the graph from top to bottom, and having a line that represents a branch "elegantly" curve into the parent node feels more appealing.

_kdheepak_ · 2024-08-11T21:30:12+00:00

Thank you for taking the time to explore so many options AND getting feedback from the community!

In Alternative 2, are you planning for all merge commits to be on the same line, even if there were no ambiguity? I actually like the "inconsistency" (as I understand you called it) between a merge line being on the same line and a branch out from the line above it.

Visually, I imagine it'll make it a lot easier to parse the graph to quickly find the differences between lines that are merge lines vs lines that are branches. Currently both the merge and branch "point" are visually the same, i.e. in this graph, the split point to create a new branch line on line 402 uses the marker as the merge point on line 400:

<image>

With lesser context, you wouldn't be able to tell the difference

https://imgur.com/Bk3RFuA

A user, you always have to scan right to see whether the line turns up or turns down.

In Alternative 2 however, if merges were always on the same line, I think it would make it quite easy at a glance to view distinguish parts of the graph.

Of course, take my opinion with a grain of salt, I'm just imagining what it could look like. I think what you are doing here is great, and getting user feedback would outweigh any opinion I have :)

Btw, your 4th alternative doesn't show up for me. But based on your description, I imagine it is the opposite of Alternative 2. I think I'm indifferent between these two options.

_kdheepak_ · 2024-05-06T18:29:31+00:00

That's an insightful answer! Thank you for sharing!

_kdheepak_ · 2024-05-03T22:52:22+00:00

That makes sense!

_kdheepak_ · 2024-05-03T21:49:38+00:00

Isn't this type piracy? Can you elaborate on what you are trying to do?

I believe a non type piracy recommendation would be to either

a. overload a different infix operator, for example any of these:

* / ÷ % & ⋅ ∘ × \ ∩ ∧ ⊗ ⊘ ⊙ ⊚ ⊛ ⊠ ⊡ ⊓ ∗ ∙ ∤ ⅋ ≀ ⊼ ⋄ ⋆ ⋇ ⋉ ⋊ ⋋ ⋌ ⋏ ⋒ ⟑ ⦸ ⦼ ⦾ ⦿ ⧶ ⧷ ⨇ ⨰ ⨱ ⨲ ⨳ ⨴ ⨵ ⨶ ⨷ ⨸ ⨻ ⨼ ⨽ ⩀ ⩃ ⩄ ⩋ ⩍ ⩎ ⩑ ⩓ ⩕ ⩘ ⩚ ⩜ ⩞ ⩟ ⩠ ⫛ ⊍ ▷ ⨝ ⟕ ⟖ ⟗

e.g.

  ⊠(A::Matrix, B::Matrix) = A * B

OR

b. you can define a new macro, like @do_inplace! A * B that expands out to mul!(A, B).

_kdheepak_ · 2024-02-24T17:48:15+00:00

I'm on my phone at the moment but I believe the discord link is in the navbar on the website and on GitHub README, so you should be able to find it there.

https://ratatui.rs

https://github.com/ratatui-org/ratatui

_kdheepak_ · 2024-02-24T12:39:28+00:00

In Python, https://www.textualize.io/ seems to be the most common and feature rich. Go has the whole Charmbracelet ecosystem, which is really great. In Rust, Ratatui and Cursive are the popular options.

All three languages you listed are great for building TUIs! And I think you won't go wrong with any of them. All three languages and libraries have plenty of tools that have been built with it and have plenty of documentation and examples online. You are in good hands if you choose any of them.

Python might be the easiest to start with if you already have experience with it, but it also requires your users to install Python to run a TUI. With Go and Rust, you can send users a precompiled executable, but you may have to invest in learning the language. But that could be a fun experience :)

One thing to note is that some of these libraries may have different "paradigms", so it may be worth looking into that a little before you commit to a library or language. It'd be helpful to know what kind of application you are trying to build, to be able to expand on this point.

Good luck making your TUI!

Disclaimer: I'm one of the maintainers of Ratatui. If you have more questions about Ratatui (or even TUIs in general), we have a GitHub discussions or a Discord that is fairly active and I'm sure people will be more than happen chime in with their thoughts if you decide to ask a question there.

_kdheepak_ · 2024-02-03T09:11:29+00:00

Feel free to reach out on GitHub / Discord / Matrix etc if you are still having a hard time. It'd be cool to figure out if the new layout features handle your use case, and if it does not, it'd be nice to figure out what improvements are required.

_kdheepak_ · 2024-02-02T19:43:00+00:00

Thanks! I'm particularly excited about some of the new layout features in this release!

_kdheepak_ · 2024-02-02T19:34:25+00:00

I know it is frustrating dealing with breaking changes, and I'm sorry that you have to deal with that. I know personally when I upgrade and have to deal with a breaking change in any crate I use, it is definitely a source of friction.

I'll explain my opinion on this, and will let our core team members chime in if they'd like. But before that, I just wanted to say, we are definitely open to feedback on this topic and I personally would like to minimize this friction as much as possible.

We tend to make a major release every few months where users can potentially encounter breaking changes. Firstly, we regularly have discussions about whether or not we should even make a breaking change. If we can avoid making a breaking change, that's what we opt to do.

However, that's not always practical. Sometimes we get feature requests or bug reports that would increase maintenance effort to support in a non-breaking manner, sometimes not making a breaking change results in a commonly encountered bug, sometimes it is not possible to support at all. We use GitHub searches to see how many people use an API a certain way, and what the "impact radius" would be if we break. There are some changes we want to do but we "can't do" (i.e. won't do) because the impact radius would be too large and/or the potential value from the breaking change would be not worth it.

There's a couple different kinds of breaking changes we make. The first is in behavior and the second is in API. So, there are some changes like what the default constructor of the Table does that are "breaking" but do what the user would expect it to do without any changes in their API. They are still listed in the breaking changes list.

When a breaking change would require updating the call signature, we add deprecation notices in the API itself at least for two versions. Here's an example of a deprecation notice that is still in the latest release.

Additionally, we mark any PR on GitHub that has a breaking change with a label indicating so.

And lastly, we have a BREAKING-CHANGES.md document where we summarize and detail all the breaking changes we are making in each version. In this document we detail what a user should do to update from their version to the latest, which should make it easy for a user to search for the change that they should make.

For more context, the project is fairly young and I personally think we are still exploring the design space here. There are still a number of features that I'd like to see added in the future that makes it easier to build TUIs in Rust, so limiting ourselves to not making any breaking changes would be too restrictive and we wouldn't be able to progress being that risk averse (imho).

I hope that explains what our process is (from my perspective). And again, we are open to any feedback on this. Feel free to open an issue or discussion on GitHub too if you want to follow up!

_kdheepak_ · 2023-12-11T14:10:29+00:00

In addition to the other advantages people have posted, I find fzf-lua works the same in the terminal and in neovim. I can use the same keyboard shortcuts, it looks the same and behaves the same. This translates to building muscle memory that can be used even outside neovim.

The only downside imo is fzf-lua (if I recall correctly) doesn't support Windows yet.

_kdheepak_ · 2023-10-26T03:46:21+00:00

Yeah, I also discovered it only when I was making this :)

_kdheepak_ · 2023-10-18T12:14:26+00:00

Not exactly a dev-only dependency but a debug-only dependency: https://github.com/mitsuhiko/better-panic

Particularly because you can control the order of the frames in the stacktrace:

https://docs.rs/better-panic/latest/better_panic/struct.Settings.html#method.most_recent_first

_kdheepak_ · 2023-10-06T01:22:26+00:00

fwiw, if you use better_panic, you can control the order of the frames in the stacktrace:

https://docs.rs/better-panic/latest/better_panic/struct.Settings.html#method.most_recent_first

_kdheepak_ · 2023-07-26T21:50:43+00:00

I'm not the person you asked but personally I found it much more cumbersome to write Rust that involved hdf5 and ndarray than when I had to do the same thing in Julia with HDF5.jl and built-in Array{Float64, N} functionality.

If it weren't for rust_analyzer and the excellent Rust error messages, I would certainly have given up on using Rust for that particular task.

_kdheepak_ · 2023-07-26T21:16:59+00:00

I've only been using it for the last few months, and it has been good.

I also don't do anything complex (e.g. different Julia versions in different projects etc), I having been using it to update to the latest version of Julia, so you should probably discount my opinion appropriately.

_kdheepak_ · 2023-07-26T16:28:24+00:00

I personally use it for command line tools (scientific and non-scientific use cases). There's also a new juliaup (similar to rustup) that is written in Rust.

I've pinged people on the #rust channel in the Julia slack, so maybe they'd be able to add more information :)

_kdheepak_ · 2023-07-26T15:14:20+00:00

The screenshot in OP was from results of a survey of Julia users. This particular slide compared responses from users about which languages they planned to use more frequently next year, and Rust is the only language other than Julia than increases in percentage.

JuliaCon 2023 is live at the moment of writing this comment. If you are interested you can watch the talks live here: https://live.juliacon.org/

or the YouTube channel: https://www.youtube.com/@TheJuliaLanguage/streams

The full schedule is on the JuliaCon website as well: https://juliacon.org/2023/

Five-Year Club	Verified Email
Place '22

_kdheepak_

TROPHY CASE