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

Stop Making TUIs

sockpuppet.org

Post reply on HN
Print view View original

521–530 of 579 posts

Re: Stop Making TUIs

#521

Post by pjmlp »

misterderpie wrote: post #464
pjmlp wrote: post #459

Earlier quoted context omitted.

X Windows was invented on the 1980's and isn't the only way to graphically access remote systems. Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.

> Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data. Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal. Whilst I get that this is about TUIs, I do believe there is…

Use a REPL.

Since when is pipelining a low level feature?

How do you think OSes like Mac OS (the original one), exposed their low level features, whatever that may be?

Re: Stop Making TUIs

#522

Post by pjmlp »

MisterTea wrote: post #507
misterderpie wrote: post #464

Earlier quoted context omitted.

> Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data. Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal. Whilst I get that this is about TUIs, I do believe there is…

Look at Plan 9's devdraw. https://man.9front.org/3/draw devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Ri…

That one was going to be commercial, hence why.

However I would rather prefer its successor, with Limbo for userspace, although probably not Tk as the main UI toolkit.

The terminal thing emulating typewriter are a UNIX thing, as other graphical OSes, presented a plain REPL, or graphical shell, e.g. Amiga DOS did not emulate any tty.

Otherwise I agree with the spirit of the comment.

Re: Stop Making TUIs

#523

Post by pjmlp »

letmehelpyou wrote: post #516
pjmlp wrote: post #370

Some folks love to live in the golden age of CP/M, MS-DOS, and timesharing green and amber terminals, for whatever reason. I was alive back then already, and was a relief to finally be able to afford GUI powered computers.

[dead]

The golden age was with Amiga, Atari ST and similar systems.

Now everyone ships Electron crap, and then as alternative we are back into the 70's, because they cannot code anything else.

Re: Stop Making TUIs

#524

Post by fc417fc802 »

joshka wrote: post #291
fc417fc802 wrote: post #162

Earlier quoted context omitted.

> To get a good terminal UX, ... At that point you're just inventing a new DOM variant and aren't fundamentally different from any other opinionated GUI framework. The value of the terminal for me is the minimalism. I absolutely despise all these new "features" that get added via protocols. I _want_ the boring grid composed entirely of extremely primitive character cells where WYSIWYG in terms of any underlying abstr…

The problem is that cells don't compose well as an accessibility thing. You need a DOM equivalent in order to realistically do a bunch of things that are meaningful at an app level. TUI libraries are all basically doing that DOM thing already - just custom and treating the final shippable product as the cells, positions and imperative instructions for how to tell a terminal what to do. I' just saying that a more decl…

Upon reflection, I think the only thing I'm opposed to is visible "features". As long as the final output remains a dumb grid of cells with extremely limited capabilities I can see where it would be useful for accessibility (or other) purposes to have a bunch of metadata in a standardized format describing the model that underlies the final output. A number of times I've been frustrated by the lack of additional channels when processing streams of data.

Re: Stop Making TUIs

#525

Post by pjmlp »

d-us-vb wrote: post #508
zahlman wrote: post #416

Earlier quoted context omitted.

> I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. This is hard to square with the continuing obsession with Electron.

I suspect the u ubiquity of electron persists more because maintaining both web and desktop interfaces is somewhat simplified, and as a corollary, you don’t need a separate JS and C/C++/QML team. Qt has gotten pretty good, but JavaScript and typescript are easier to hire.

Pay for cheap labour, get a cheap product.

I thought Claude could do anything nowadays.

Re: Stop Making TUIs

#526

Post by pjmlp »

4k93n2 wrote: post #425
the__alchemist wrote: post #336

Earlier quoted context omitted.

> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. Basi…

they wont work on android though. thats the main reason i started using more TUIs myself. i needed to be able to run a bunch of python scripts on linux, windows and android/termux. or if any of the linux phones ever matures, or sailfish, then the same scripts will run thereas well, probably without any modifications needed

Termux is not the right way to execute Apps on Android, Pydroid does the job.

Also, Qt does support Android development.

Re: Stop Making TUIs

#527

Post by 4k93n2 »

pjmlp wrote: post #526
4k93n2 wrote: post #425

Earlier quoted context omitted.

they wont work on android though. thats the main reason i started using more TUIs myself. i needed to be able to run a bunch of python scripts on linux, windows and android/termux. or if any of the linux phones ever matures, or sailfish, then the same scripts will run thereas well, probably without any modifications needed

Termux is not the right way to execute Apps on Android, Pydroid does the job. Also, Qt does support Android development.

why is it not right? ive been using it for years and everything works just fine

Re: Stop Making TUIs

#528

Post by rtpg »

zahlman wrote: post #416
the__alchemist wrote: post #336

Earlier quoted context omitted.

> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. Basi…

> I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. This is hard to square with the continuing obsession with Electron.

I think Qt is a bit different here because of Qt Quick etc but I've tried using "native" GUI frameworks a lot and ultimately the web DOM model is pretty nice for iterating easily.

Querying into the DOM and working off of that means you're not futzing about holding onto a bunch of component references for the one thing you might need later on.

Web layout is also pretty easy to just get right, native GUI frameworks have a different kind of layout model that is not as amenable to "arbitrary" data (at least at first blush).

the reactive programming model also works quite well. While there are native GUI frameworks that lean into reactive programming, they tend to be doing a bunch of weird stuff that cause other issues.

And at the end of the day, when you package something like a Qt app it still often ends up being quite chunky.

In the end tho... the simplest thing is if you do web stack you get a web UI _and_ your "native" GUI in one go. Build things once, not twice. Hard to argue against that when that's presented.

Re: Stop Making TUIs

#529

Post by pjmlp »

4k93n2 wrote: post #527
pjmlp wrote: post #526

Earlier quoted context omitted.

Termux is not the right way to execute Apps on Android, Pydroid does the job. Also, Qt does support Android development.

why is it not right? ive been using it for years and everything works just fine

It is trying to fit GNU/Linux into Android/Linux, on a model that has only worked so far because internal politics have prevented the replacement of Linux kernel with Zirkon.

The official NDK documentation on what is supported for NDK written code on non rooted devices, and the hurdles that Termux faces to keep running on standard Android images via PlayStore distribution, show why it isn't right.

Re: Stop Making TUIs

#530

Post by vrypan »

> We build terminal interfaces because we have to, not because we should.

Who said we're building them because we have to? I like TUIs, and often prefer them over GUIs, depending on the case.

Post reply on HN