As a total side tangent, but I really like the following flow: focus follows mouse but focus doesn't raise the window, clicking on the top bar, or Win+Click raises it (notice how neither of these 2 results in an interaction).
Unfortunately, of the popular DE's, this is only supported in Xfce (?), and it's not supported in Windows or macOS afaik.
It might be different if these things leaned a little bit into acme - or at least had some justification for what was similar and what was difficult [hah, Freudian autocorrect. Meant: different]. Like; do you want to be a powerful text-oriented tool, or just a mostly-dumb print out?
There are reasons for both - but ignorance shouldn't be one.
Actually, I’d really like to know the answer to this. I’m not a fan of clickable TUIs. Mouse events in my terminal are one of the banes of my existence.
But, if they are more popular with others, that would be helpful to know.
I don't care about clicking into the terminal. I don't understand why people do this more and more.
You just need to use your keyboard shortcuts correctly and navigate the tmux/kitty session as it's intended to.
See that's all a matter of workflow? You don't understand it because it's just not for you
A clickable TUI is contrarian to why I use most CLI tools. Neat that they could build this, though, because it suits their needs.
I'm fine with K9s and lazygit key-driven interfaces.
I guess one thing that's good about a clickable TUI is that maybe it's easier to approach for some, wihtout releasing yet another memory hog Electron App?
The code generated by Claude is fully under my control, and I make sure it works exactly as I intend. I could have hidden this by committing it myself, but I choose to acknowledge that I had Claude's help
It’s not your fault. The problem is now that my mother in law can vibe code a complete operating system, I cannot distinguish quality from shit any more. And the last few OSS projects that I tried that had the Claude icon where shit and breaking in many ways.
I think your prior assumption that all OSS projects had a degree of quality is where your problem is. But I get it.
We’ve had low quality code for as long as we’ve had programmable machines. I’ve seen a lot of manually written bad code well before LLMs took over. Nowadays, I primarily look at how long a repo has been around and how active it is. A repo that has consistent activity is probably going to be a higher quality one. Even better if I can follow PRs to see how the code base is evolving.
I will admit it’s become more difficult to tell low quality git repos from higher quality ones. Missing files or incomplete README files are a thing of the past. Claude is very good at filling in the gaps to make all repos at least appear respectable.
It's kinda like eternal September but for software engineering. There was a time that just being on the internet, having an email address, etc. was a signal that indicated a level of technical proficiency. Now everyone has that connectivity, it doesn't mean anything anymore.
The Claude-generated README doesn't inspire confidence in that. I believe you checked all the code, but a lot of people are going to see that README and not give the project a second chance.
But now other people's code is just a starting point for me forking an app to do exactly what I want it to - it's inspiration because code is cheap.
Of course for larger projects we will still need solid components underlying them, but what you're really talking about is just maturity - it's very easy to produce a lot of output now but you can't replace actual history or having more then exactly 1 maintainer.
I hope vibecoding doesn't mean the concept of contributing upstream gets lost. At least some of this (mouse clicking) would have been a great upstream contribution instead of rewrite.
I'm really surprised that "clickable tui" is grinding so many gears here. I've been using Linux for over 20 years. I love a good ol TUI. But nothing about clickability precludes a TUI from being useful. I love mouse support in tmux, for instance. I can shift-arrow my way around windows but I can also just click one (or tap one, if one a touch device). I do this all the time when controlling tmux from my iPhone. Why is this such a bad thing? It makes zero sense. Judge this tool on its merits of being a TUI for interacting with Kubernetes... not because it allows mouse input.
Some of us enjoy working entirely in the terminal. It’s OK not to enjoy that, but I assure you, I am far more productive in tmux + nvim than in, say, VSCode.
I wish we had a "cool" GUI toolkit. GUIs are way better at this stuff. Adding point and click is so close to being a GUI, the only possible reason this is a TUI is fashion.
How are GUIs "way better at this stuff"? I can't see it, but would like to understand how you feel that a GUI can improve on the management of automated processes at scale.
Just one example of the top of my head: filter by labels, sort by name, select a few pods using ctrl+click, view logs. GUIs were super quick at this sort of stuff in the 90s. I use kubectl myself, but when I see stuff like this it really seems like people just want GUIs again.
There's two different levels to this imho, a tui is usually still a non-bloated self-contained binary that can run on windowless server envirorments just fine.
TUIs can have GUI like affordances UX/UI wise regardless of if they use the terminal as the contract or a window server/gui lib
Idk if you are managing k8s stuff you are probably in a terminal already. Staying in a terminal is nice. Plus having persistent multiplexer sessions is a big deal in locked down corporate environments.
That is great until you have 12 similar windows open and your os window manager smooshes them into one indistinguishable stack. And if I want a window from app A to stick side by side with a corresponding window from app B you have few options. As opposed to tmux I can organize however I want and combine any arbitrary apps into a workspace. Plus RAM usage difference is night and day.
Most common things power users seem to want from TUIs on desktop:
- Easy efficient remote access. Pixel streaming and things like GTK Broadway are out. Needs a proper protocol/standard that would send styling-neutral primitives (and that is not X11 forwarding), and the entire toolkit architecture built around that. Something like SPICE/QXL but more semantics-aware? Not sure, might be too low level and chatty.
- Staying in the terminal. This is a matter of window management, though a toolkit can offer good defaults so this doesn't feel janky.
- Keyboard-first. Trivial. "GUI is for filthy mouse casuals" is a ludicrous idea.
- Low bloat. Web and things like GTK Broadway are out.
I haven't seen two similar opinions on actual architecture and stack, however being available in Rust will be a great start.
I really don't care to click anything in a terminal, and I don't understand why its being added more and more.
When Claude added it, I immediately hated it since you click into the terminal and accidentally click something.
100%
I don't mind something that requires a modifier key like Shift+click to follow a URL
But so many times now I'll click to get focus and now that's selected some option or opened some pane.
If I wanted that, I'd use the Claude Desktop app!
As a total side tangent, but I really like the following flow: focus follows mouse but focus doesn't raise the window, clicking on the top bar, or Win+Click raises it (notice how neither of these 2 results in an interaction).
Unfortunately, of the popular DE's, this is only supported in Xfce (?), and it's not supported in Windows or macOS afaik.
tmux has that these days and it’s great if you have a big monitor with a lot of panes, just move the mouse to focus.
It might be different if these things leaned a little bit into acme - or at least had some justification for what was similar and what was difficult [hah, Freudian autocorrect. Meant: different]. Like; do you want to be a powerful text-oriented tool, or just a mostly-dumb print out?
There are reasons for both - but ignorance shouldn't be one.
https://9p.io/wiki/plan9/Using_acme/index.html
Hopefully they add an option to atleast disable it
Or can we do it with a cli wrapper process?
Most of us love it
citation required
Actually, I’d really like to know the answer to this. I’m not a fan of clickable TUIs. Mouse events in my terminal are one of the banes of my existence.
But, if they are more popular with others, that would be helpful to know.
I'm pretty happy with highlight text and copy to clipboard. Yes, it is part of clicking.
A clickable TUI is contrarian to why I use most CLI tools. Neat that they could build this, though, because it suits their needs.
I'm fine with K9s and lazygit key-driven interfaces.
I guess one thing that's good about a clickable TUI is that maybe it's easier to approach for some, wihtout releasing yet another memory hog Electron App?
Don’t worry, you can use react for TUIs in the terminal.
Claude code uses react, iirc
It's because tmux makes session resumption easy. Although for K8S it makes no real sense, for Claude it does.
Of course with all the running around with AI programming, it would be nice if we could task sometime to making remote desktop not suck on Linux.
My Pavlov reaction when I see the Claude icon next to the committer is: not touching this. Is trust in OSS now completely gone?
The code generated by Claude is fully under my control, and I make sure it works exactly as I intend. I could have hidden this by committing it myself, but I choose to acknowledge that I had Claude's help
It’s not your fault. The problem is now that my mother in law can vibe code a complete operating system, I cannot distinguish quality from shit any more. And the last few OSS projects that I tried that had the Claude icon where shit and breaking in many ways.
I think your prior assumption that all OSS projects had a degree of quality is where your problem is. But I get it.
We’ve had low quality code for as long as we’ve had programmable machines. I’ve seen a lot of manually written bad code well before LLMs took over. Nowadays, I primarily look at how long a repo has been around and how active it is. A repo that has consistent activity is probably going to be a higher quality one. Even better if I can follow PRs to see how the code base is evolving.
I will admit it’s become more difficult to tell low quality git repos from higher quality ones. Missing files or incomplete README files are a thing of the past. Claude is very good at filling in the gaps to make all repos at least appear respectable.
It's kinda like eternal September but for software engineering. There was a time that just being on the internet, having an email address, etc. was a signal that indicated a level of technical proficiency. Now everyone has that connectivity, it doesn't mean anything anymore.
Same concept, but github repos now.
The Claude-generated README doesn't inspire confidence in that. I believe you checked all the code, but a lot of people are going to see that README and not give the project a second chance.
This is also why I allow it to add these things to the commit. I think it's worth disclosing despite me checking everything it did myself.
> I make sure it works exactly as I intend
I appreciate the effort. May I ask how do you tackle this?
As a former AI skeptic I get it and still get it.
But now other people's code is just a starting point for me forking an app to do exactly what I want it to - it's inspiration because code is cheap.
Of course for larger projects we will still need solid components underlying them, but what you're really talking about is just maturity - it's very easy to produce a lot of output now but you can't replace actual history or having more then exactly 1 maintainer.
https://github.com/kubernetes-sigs/headlamp is a good established option for a clickable k8s UI
I hope vibecoding doesn't mean the concept of contributing upstream gets lost. At least some of this (mouse clicking) would have been a great upstream contribution instead of rewrite.
It would have been better if that opened a browser tab, one binary, much more flexibility and more elegant
> Nothing is hidden behind memorised keys
Why is this a good thing? Have a help you your access via ? and document what the keys are. Don't dumb the interface down.
I'm really surprised that "clickable tui" is grinding so many gears here. I've been using Linux for over 20 years. I love a good ol TUI. But nothing about clickability precludes a TUI from being useful. I love mouse support in tmux, for instance. I can shift-arrow my way around windows but I can also just click one (or tap one, if one a touch device). I do this all the time when controlling tmux from my iPhone. Why is this such a bad thing? It makes zero sense. Judge this tool on its merits of being a TUI for interacting with Kubernetes... not because it allows mouse input.
What is the difference from k9s from this vibecoded clone?
Maybe try sofka :-)
https://github.com/nklmilojevic/sofka
That's the actual k9s successor imho!
TUIs are such a complete fad which i’m getting annoyed with.
It seems we cannot move on from them and I think we should.
It is a shame because surely there must be something better than terminals and TUIs.
Some of us enjoy working entirely in the terminal. It’s OK not to enjoy that, but I assure you, I am far more productive in tmux + nvim than in, say, VSCode.
I wish we had a "cool" GUI toolkit. GUIs are way better at this stuff. Adding point and click is so close to being a GUI, the only possible reason this is a TUI is fashion.
How are GUIs "way better at this stuff"? I can't see it, but would like to understand how you feel that a GUI can improve on the management of automated processes at scale.
Just one example of the top of my head: filter by labels, sort by name, select a few pods using ctrl+click, view logs. GUIs were super quick at this sort of stuff in the 90s. I use kubectl myself, but when I see stuff like this it really seems like people just want GUIs again.
There's two different levels to this imho, a tui is usually still a non-bloated self-contained binary that can run on windowless server envirorments just fine.
TUIs can have GUI like affordances UX/UI wise regardless of if they use the terminal as the contract or a window server/gui lib
Idk if you are managing k8s stuff you are probably in a terminal already. Staying in a terminal is nice. Plus having persistent multiplexer sessions is a big deal in locked down corporate environments.
I appreciate the tui.
Seems like a task for the window manager and a remote access protocol.
That is great until you have 12 similar windows open and your os window manager smooshes them into one indistinguishable stack. And if I want a window from app A to stick side by side with a corresponding window from app B you have few options. As opposed to tmux I can organize however I want and combine any arbitrary apps into a workspace. Plus RAM usage difference is night and day.
Seems like you selected the wrong window manager for your task then...
I've been using https://github.com/longbridge/gpui-component
Imgui is also good for this
I think X11 is the GUI version of terminal interface
we need more experiments with X11 interfaces
How would a "cool" GUI Toolkit look like for you?
Most common things power users seem to want from TUIs on desktop:
- Easy efficient remote access. Pixel streaming and things like GTK Broadway are out. Needs a proper protocol/standard that would send styling-neutral primitives (and that is not X11 forwarding), and the entire toolkit architecture built around that. Something like SPICE/QXL but more semantics-aware? Not sure, might be too low level and chatty.
- Staying in the terminal. This is a matter of window management, though a toolkit can offer good defaults so this doesn't feel janky.
- Keyboard-first. Trivial. "GUI is for filthy mouse casuals" is a ludicrous idea.
- Low bloat. Web and things like GTK Broadway are out.
I haven't seen two similar opinions on actual architecture and stack, however being available in Rust will be a great start.
That's what the web is for: https://ui.shadcn.com/
You missed the chance to use kittens (k10s) as your TUI's icon.
wouldn't that be k5(itten)s not k10s?