Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TUI Studio – visual terminal UI design tool

tui.studio

Post reply on HN
Print view View original

231–240 of 304 posts

Re: TUI Studio – visual terminal UI design tool

#231

Post by shimman »

sandos wrote: post #115

I would be REALLY REALLY impressed if it manages to do this without bugs. Just using pythons textual can be very complex, belive it or not. Maaging not only to that but other frameworks too sounds insanely complex. I have a strong feeling this is vibecoded from the commit history?` Ah yes, it says clearly that on the github page. Still, if its works, I am then impressed by the LLM. Edit: It does, in fact, NOT work fo…

Yeah, the website has many bugs too. Literally can't click on 50% of the "clickable" stuff. Not impressed by vibe coded nonsense. The comments here are weird, people are discussing the "idea" rather than the broken implementation.

Probably a bad omen of things to come for the internet.

Re: TUI Studio – visual terminal UI design tool

#232

Post by nick_ »

sabas123 wrote: post #36

What is the point of having this if code generation is not functional yet? That is the entire point of this app.

TUIs are very in right now. Nostalgia/vintage-computin-aesthetics & guru-gatekeeping around command line savviness are front and centre in the HN-and-adjacent mindshare.

Re: TUI Studio – visual terminal UI design tool

#233

Post by ctmnt »

On one hand this is a neat idea. I've thought about how nice it would be to have a visual layout tool for text-based designs. The current offerings are slim. Of course, you could easily argue that if you need a visual tool for it, you've gone too far; even the most sophisticated TUIs are still extremely simple.

On the other hand, for this work as they describe, it needs to be a complete UI framework across a bunch of languages and built on top of a bunch of existing frameworks. That seems... ambitious. Building one UI framework for one language is plenty hard enough.

Re: TUI Studio – visual terminal UI design tool

#234

Post by throwawaymobule »

wolvoleo wrote: post #58
roywiggins wrote: post #42

Earlier quoted context omitted.

Even easier is just using an X server, if you have it set up properly you just need to run the remote app and the window pops up on your machine. (I think terminal-based GUIs are neat just for fluidity of use- you can pop one open during a terminal session and close it without switching to mouse or shifting your attention away from the terminal. They can also be a nice addon to a primarily CLI utility without introdu…

Yeah I love that about X. I remember in the 90s when I first figured that out. I was logged in from a university workstation into my home computer with SSH and I launched my mail client or something and I thought doh, stupid that will only popup locally. Then colour my suprise when it popped up on my screen right there. Slow as molasses but still. Wow. Magic. It's a shame Wayland dropped this. Yes I know there's wayp…

Waypipe looks interesting.

The main advantage of x forwarding for me was when I'd randomly need it and had nothing set up ahead of time. Hopefully it starts getting installed in distros by default eventually.

Re: TUI Studio – visual terminal UI design tool

#235

Post by h3lp »

eterps wrote: post #16

This is nonsensical, there is nothing textual about the UIs being shown here. It doesn't stop being a GUI if you have a 1:1 representation of the concept within character cells. The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the U…

Good insight, but if you discount the visual elements (tabs, buttons, etc), you're limiting TUI to CLI, and I think that's unwarranted. The value proposition of both TUI and GUI is two-fold: you see the available action options, and you see the effect of your actions. So, yes, TUI and GUI _are_ closely related: who cares whether we're displaying pixels or character blocks.

Unfortunately, they are often artificially differentiated by the style of the UX interaction: TUIs promote the keyboard actions, and GUIs prefer mouse without corresponding keyboard shortcuts. Unfortunately for GUIs, their designers are often so enamored with WIMP that they omit the keyboard shortcuts or make them awkward. I hate it when, even if the ACTION button is available by keyboard traversal at all, it requires some unknown number of widget traversals instead of being one tab away.

Since the keyboard is almost always used for the textual data, it makes sense to me to always enable it for command execution. Well designed GUIs and TUIs provide both WIMP and keyboard UX, which sadly is not the norm today, so here's my vote to make them larp for each other more.

Re: TUI Studio – visual terminal UI design tool

#236

Post by throwawaymobule »

cmrdporcupine wrote: post #145
eterps wrote: post #16

This is nonsensical, there is nothing textual about the UIs being shown here. It doesn't stop being a GUI if you have a 1:1 representation of the concept within character cells. The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the U…

Man, I've had so much frustrating just trying to copy & paste from inside a terminal running e.g. opencode or crush. I think TUIs are neat, I guess. But I think these things have abused the concept extensively. They don't actually interact well with the rest of a Unix environment.

Hold down a key (alt, I think) to prevent clicks.

Re: TUI Studio – visual terminal UI design tool

#238

Post by ralferoo »

dec0dedab0de wrote: post #199
ralferoo wrote: post #196

Earlier quoted context omitted.

I assume his point is that making stuff that assumes a mouse makes for a bad text-based UI. Absolutely fine if everything is controllable via the keyboard, e.g. if the tabs were labelled F1-Fn and they function keys switched them, or they had an underlined letter and Ctrl+letter switched focus to it, or whatever. But if this thing requires you to just tab a lot through lots of pointless and rarely used fields to get…

absolutely, but it's still a TUI. Just like if you made a GUI that didn't have any mouse support and needed all keyboard shortcuts, it wouldn't stop being a GUI.

TBH I've always hated the backronym TUI anyway, so if TUI includes things that require mouse input, then maybe we can go back to using "text-based UI" for things that only require a keyboard like we used to 30 years ago.

Re: TUI Studio – visual terminal UI design tool

#239

Post by dwedge »

nine_k wrote: post #198
tracker1 wrote: post #180

Earlier quoted context omitted.

It makes far more sense in the context of effectively a remote session or dumb terminal serial connection. Your "terminal" application is only emulating a text mode environment inside a gui, typically... you can ctrl+alt+F2 - F5 in a lot of Liknux's to switch to a terminal session if you want, but that's not what people tend to actually use. Beyond this, without remote X properly configured, again, most don't and pro…

A remote GUI application now runs in a special client called a web browser ; it's a recent development, barely 35 years old.

These sarcastic reddit style comments grate me. And it's also inaccurate, you're not runnning remote graphical applications from a remote headless webserver. You're rendering it locally.
Post reply on HN