[Feature] I want to use Kitty graphics for the graphs.

[ctrlcctrlv]

Checklist

• [X] I've looked through the documentation and existing open issues for this feature/feature request.

Describe the feature request

My eyesight is not that good. I don't want to use a small text size for my terminal, I want actual graphical…graphs.

This can be achieved with Kitty graphics. How hard would it be for me as a Rust developer to add this? Where would you start, maintainer?

[ClementTsang]

TL;DR: Out of scope and would be pretty low priority atm, but interesting and worth investigating. Probably doable, but I imagine lots of work.

---

Well this is certainly an interesting suggestion.

Going to be honest, I don't know how doable this is, and it's completely out of scope for what btm was designed for. It requires a ton of work since nothing in the codebase regarding drawing was designed with this use case in mind.

So I'll be upfront first, I will probably not do any work on this any time soon, if at all, though I'll be happy to look at PRs or discussion. I think it's an interesting idea worth taking a look at.

Now that being said, if you asked me what I might do if I was investigating this, off the top of my head (I apologize if I sound a bit rambly, I just woke up not too long ago):

• Look at something like https://docs.rs/viuer/latest/viuer/ (first link I saw) and see how that works. Can I leverage that for this?

• Test if this can be performant at all. I imagine it's a pretty different beast than your typical terminal printing, there are some use cases like event handling that I would like to see how performant this is with. Is this even appropriate for such a use case? I have no idea.

• How do things like configuration and setting work with this change? How do we go about configuring the kitty side vs the non-kitty stuff? I guess we can have "backends" of sort in the configuration options to control protocol-specific stuff.

• Rewrite every single widget to support this, if it looks reasonable to try. This would certainly take some time, if at all; I leverage tui-rs for this, which provides a high level abstraction over drawing in the terminal, but I imagine that wouldnt work if I tried dipping my toes in kitty protocol.

• On that note, how will the widgets look now?

• How about fonts? Do we need to support those?

So off the top of my head, it's probably doable... but again, it's completely out of scope atm and I already have a massive backlog of work. It would certainly be interesting to try though, I've never thought of this before.

[ctrlcctrlv]

I contribute to kitty. Most of this is not an issue. What I really want to know is how hard it is to turn off all the current drawing functions, but keep the spaces in the UI. Then I can really easily put Kitty graphics in those spaces, if that's the current mode, of course.

[ctrlcctrlv]

For example, Kitty graphics have a shared memory mechanism. We can just write our graphic to the shared memory and it'll update as soon as we overwrite the bitmap. I think we can lock to avoid tearing. Regarding fonts, no we don't need fonts. And, I don't think every widget needs rewritten. I mostly care about the line graph as it looks worst to me.

[ctrlcctrlv]

I personally would not use viuer for this...or I would, but PR support for our shared memory support to it. Not that it wont' work without shmem, of course. It will. But to be most performant locally, shmem is quite essential. Over ssh no one cares if we just keep dumping bitmaps, and they'll expect it not to work well unless their internet/GPU/CPU is strong. But over local, users won't be that sympathetic.

[ClementTsang]

What I really want to know is how hard it is to turn off all the current drawing functions, but keep the spaces in the UI.

Should be pretty easy to just call a different draw function if that's what you want to do.

[ctrlcctrlv]

I looked into this for btop++ as well but it's not so well-implemented lol. Its Graph class really expects to be character based, and to be shifting characters around, and I could tell it'd need a major refactor to not do that. I'm better at Rust anyway so will work on this. I think a version that is constrained, and does it only for the line graph for now, with a check for xterm-kitty and also an opt-out, is the best way. I'm sure I can make it performant, drawing a constantly updating linegraph is one of the oldest problems in computer graphics lol.

[ctrlcctrlv]

(Konsole supports kitty's protocol as well. I think wezterm does also. But I'd limit it to xterm-kitty at first so we can see if people even like the feature before I add support for our actual way of querying graphics support, as it's extremely convoluted and requires direct pty access. You to send two different ioctl's back-to-back and if you get ioctl A first, you have kitty graphics. If you get B, you don't.)