TUI Studio – visual terminal UI design tool
tui.studio632 points by mipselaer 3 days ago
632 points by mipselaer 3 days ago
If you're going to put a video demo on your main webpage, can it have play/pause and a control bar? So I can actually skip to a part I want to look at. Here's the actual video: https://tui.studio/screenshots/video.mp4.
Also, how does this handle terminal resizing? Are there options to anchor elements to the left/right etc, or will narrowing the terminal window just make everything fall off the side, or worse, all the text wraps?
You can right click on it and choose "Show controls", at least in Firefox.
Oh, that's odd, it didn't show up on chrome when I first tried it, but it does now. I was wondering how they'd managed to hide the video context menu
It's probably just <video> element without "controls" attribute.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
> controls
> If this attribute is present, the browser will offer controls to allow the user to control video playback, including volume, seeking, and pause/resume playback.
Edit: I misunderstood, you are asking
> how they'd managed to hide the video context menu
Not sure, but it works in FF for me
Its entirely possible I did something to it accidentally that made the context menu not work properly. I had the dev tools open to pull the actual video address when I right clicked, so I might have messed something up. Or maybe the devs are secretly looking at the comments and fixed it between me and you trying :P
It won't let me reply to parent's child comment, but i wanted to say:
That is what HN is for!
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 UX expected for GUIs, it has become a GUI larping as a TUI.
> But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the UX expected for GUIs, it has become a GUI larping as a TUI.
Hard disagree. Borland TurboVision [0] was one of the greatest TUI toolkits of the DOS era, had all of these:
> Turbo Vision applications replicate the look and feel of these IDEs, including edit controls, list boxes, check boxes, radio buttons and menus, all of which have built-in mouse support.
Well, I can’t remember if it had tabs.
Oh man, Turbo Pascal was my first "real" programming language -- it was all various flavors of BASIC before, and mostly toy projects. The developer experience with Turbo Pascal (by which I guess I mostly mean Turbo Vision) was honestly pretty great
Vasellating. TurboVision was awesome, but it was pushing the boundary of TUI, which in my mind was great for moving hard copy to computer entered use case. To wit, hard copy on your right side, you transfer data to app without looking at screen, but just looking at hard copy, remembering when/where to hit return key, maybe tab for prior field, stuff like that.
But hey, if the screen is drawn 24 x 80 with extended ascii, it's TUI. And man, loved the "absolute" keyword in turbo pascal. Instant screen writes when writing to a 2 dimensional array.
I don't remember "absolute" but I sure do remember "gotoxy" and it rhymes with boxy, yeah, you won't convince me otherwise.
It was something like screen: array[1..80,1..25] of byte absolute $B800:0000; So, just use all the extended ascii to assign chars to cells to draw boxes for screens, buttons, tables, whatever. Instant update.
It's a TUI if it uses text to build those elements.
You can be effective and powerful in any kind of interface, Just like you can be ineffective and weak in any kind of interface. People like TUIs because they're cool, and work over SSH.
Yes. A TUI runs in a text session. A GUI runs in a graphics session. A terminal emulator emulates a text session in a graphics session - and allows you to run TUI/CLI tools. This is apparently controversial?
> TUI runs in a text session. A GUI runs in a graphics session
What do you mean by this? I have never heard these terms before. I can launch and interact with a GUI from a text application, or a text application from a GUI.
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 probably shouldn't.. you aren't running remote gui applications over an SSH session. Richer TUIs were pretty common in ye old days of DOS and other OSes before rich GUIs become the norm. DOSShell, Edit.com, etc. The IDEs of days past and Word Perfect even. These all interacted with Mice and were considered the norm. The features that allow this over a remote terminal today are pretty great IMO, the harder part is properly handling window sizes/resizes, etc.
With graphical extensions, there are even nice app explorers with image previews via TUI. It pushes the boundaries. For that matter, I often wonder what could have come with RIPscrip/RIPTerm if the leap to web didn't happen the way it did...
I think the single hardest part of TUI is dealing with wide characters and secondary fonts for color emojii that don't quite render in 2 spaces completely in a lot of termianls... it makes the line drawing harder too.
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.
He's functionally right though, a remotely served interface can be implemented as a TUI behind ssh, or it could be implemented as a website. Which is the better option depends on the context, but they're both serving the same function, and the terminal emulator you're using to view the TUI is most certainly rendering it on your computer.
This is true only up to "you can send and receive data".
A terminal is an OS construct mostly. It will, with permissions, allow you to do anything the OS can do, including shutdown, or serve more data. It's the default mode of operating the system.
The opposite is not true. The default mode of operating a web browser will not let you create a terminal access or do anything new with the machine.
Insofar as the previous is false - because it website has flaws that allow code execution, shell escapes, or remote package installations, it's worth pointing out that these are usually possible because your web server is running as a user on a system, effectively with system access via similar interfaces as the shell.
This is like saying you can operate a car from the truck - yeah maybe through some weird gymnastics, but the trunk is for transfer, and the drivers seat is for operating.