Live data from Hacker News

TUI Studio – visual terminal UI design tool

tui.studio

261–270 of 304 posts

Re: TUI Studio – visual terminal UI design tool

#261

Earlier quoted context omitted.

> 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…

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 asc…

I don't remember "absolute" but I sure do remember "gotoxy" and it rhymes with boxy, yeah, you won't convince me otherwise.

Re: TUI Studio – visual terminal UI design tool

#262

Earlier quoted context omitted.

Like what? X forwarding has pretty much always been the thing most likely to work for me and I haven't been able to find any equivalent.

IIRC, it's not that secure though.. I'm really surprised people didn't do more things like send animated skulls to people's desktops.

Ps: oh yes and before '93 I've had so much fun practical joking around :)

Re: TUI Studio – visual terminal UI design tool

#263
post #197

I don’t want to be a curmudgeon, but why not just use CSS, HTML, React, etc. at this point? You could choose a style that looks like a TUI.

But will it render in a terminal over ssh? (I know, I know, port forwarding should work for a web app.)

It actually will given the excellent quality of text based browsers now.

Re: TUI Studio – visual terminal UI design tool

#264
post #239
post #198

Earlier quoted context omitted.

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.

An X server also normally renders things locally, as does a VT-compatible terminal. If you want no local rendering at all, there's VNC.

With a web app, you can slice and dice processing between local and remote by running JS locally. Most processing usually happens remotely though, and only the display and command logic is run in the browser.

Re: TUI Studio – visual terminal UI design tool

#265
post #239
post #198

Earlier quoted context omitted.

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.

Re: TUI Studio – visual terminal UI design tool

#266
post #197

Earlier quoted context omitted.

But will it render in a terminal over ssh? (I know, I know, port forwarding should work for a web app.)

It actually will given the excellent quality of text based browsers now.

Agreed.

Another thing that gives the TUI concept an edge is the lack of formatting options: no way to make a font too tiny or too huge, very little leeway in implementing common controls, any excessive whitespace looks jarring, etc. Icons are limited to the common emoji.

All this makes you concentrate on providing functionality first.

Re: TUI Studio – visual terminal UI design tool

#267
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…

> 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…

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

Re: TUI Studio – visual terminal UI design tool

#269

Earlier quoted context omitted.

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 asc…

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.

Re: TUI Studio – visual terminal UI design tool

#270

Earlier quoted context omitted.

I like TUIs keyboard-centric. Mouse can be a plus, but it should never be necessary.

That's fair... I feel that way about GUIs too in general though. Everything should be keyboard navigable and reasonable control flows. Tab and arrows, etc. Should be able to control focus and selection (enter). I admit I don't always pay the most attention to it, as the UI components I tend to use do a good enough job of this. But I'm usually pretty consistent with it.

Yes, even GUIs benefit from having good keyboard navigation.
Post reply on HN