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

Why TUIs are back

wiki.alcidesfonseca.com

Post reply on HN
Print view View original

361–370 of 443 posts

Re: Why TUIs are back

#361

Post by okanat »

Pay08 wrote: post #317
_jackdk_ wrote: post #89

The diagnosis for GNU/Linux is better than I expected but I think is still incomplete. Yes, you have two major toolkits (GTK+ and Qt) and many minor ones (most of which wrap one of the majors). Qt is proprietary but also available under a free software licence, but what if you don't want that that complexity? It feels like modern GTK+ is less of a cross-platform toolkit and more of a runtime layer for libaidwaita and…

Qt's license really isn't hard to figure out. If it's free software, you use the free software license. If it's propietary/commercial, you use the propietary license.

You can also use most of the core components (labels, buttons, grid views, image and media players) with LGPL in commercial apps. Only the more complex and more value-adding components like charts are GPL.

Re: Why TUIs are back

#362

Post by jacobwiseberg »

> I do not necessarily argue for cross-platform support, but having one such solution would help reduce the electron and TUI dependency.

I think this is the primary reason. I feel like whether or not there are good native libraries things were bound to converge into cross-platform preferencing since it's cheaper to produce and maintain.

Re: Why TUIs are back

#363

Post by badsectoracula »

spankalee wrote: post #121

I really don't get terminal UIs that try to rebuild GUI-like functionality. Don't we think that computer interfaces should get better? We're not limited to a grid of characters to pretend to draw lines and shapes with anymore. You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm. It's just a shame that we don't have a great cross-platform, streamed, UI system. The web is g…

> You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm.

Sixels are supported by many terminals[0] (several of the terminals mentioned that do not support them are based on GNOME VTE for which support is in the works and, based on the bug tracker comments, it seems to be almost done).

This includes xterm which is probably the most "standard terminal" on X11 you can get.

[0] https://www.arewesixelyet.com/

Re: Why TUIs are back

#364

Post by mg794613 »

When kubernetes got introduced, we didnt want to interact with only webpages/fronts.

So we created tooling we know on the CLI.

Every person here that thinks its AI that caused the resurgence of CLI tools is a vibe coder who just entered the scene this year.

Re: Why TUIs are back

#365

Post by colesantiago »

akerl_ wrote: post #288
colesantiago wrote: post #284

Earlier quoted context omitted.

Let's check the first one: Systemd-manager-TUI: A TUI application for managing systemd services Somebody said that they use this, so it is not a 'show off' project. You realise you made a silly sweeping generalisation right? People actually use them.

I don't know why you're so aggressively attacking the idea of people making projects to show off. The claim isn't that zero people use them, or that all TUI projects are made to show off. But most of the TUIs you see land on HN are things somebody made to play around with a technology / scratch a momentary itch. No shade on those people; making a project that brings the author joy is an awesome reason to make somethi…

> But most of the TUIs you see land on HN...

This is the main problem.

If you're using HN as a benchmark that most TUIs are show off projects, I don't know what to tell you other than you're in a bubble.

Re: Why TUIs are back

#366

Post by badsectoracula »

CopyOnWrite wrote: post #353

For the record: I have a terminal open at all times, my life is automated trough Bash scripts and I am a VIM / TMUX user. With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.) The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which…

> which is really integrated into a programming language or part of the standard library.

Not a programming language, but the programming language: C. The toolkit needs to be available as a C API because that lets it a) provide stable API and ABI and b) provide bindings for multiple other languages without having to jump through hoops, especially for other compiled languages (binding Qt to Python might be easy, but bindings to something like, e.g. Free Pascal requires an intermediate C++ library that exposes a C API that itself can be used from Free Pascal - and applications need to distribute it that library too).

Unfortunately the vast majority of GUI toolkits are not writtne in C but in C++ or some other language that makes using them from anything than the developers' favorite language a pain. And really the only mainstream that is written in C is GTK which has a complete disregard for proper backwards compatibility.

(you may think that a library only needs to expose a C API but it can be written in any language, however for something that doesn't have any widespread availability, you may want to link to it statically - however that can be an issue with anything outside C/C++ - as an example i recently tried to make a FLTK backend[0] for Lazarus since FLTK is a C++ library that the devs encourage to link it statically and it would allow creating GUI programs that are self-contained binaries... but statically linking a C++ library -for which i had to first make a C wrapper- in a non-C/C++ turns out to be a PITA under Linux if you are not g++ as that does passes a bunch of magic flags to the linker and impossible under Windows - or at least msys2, so i gave up).

[0] https://i.imgur.com/W6XbLkr.png

Re: Why TUIs are back

#367

Post by cassepipe »

lucasoshiro wrote: post #104
mr_mitm wrote: post #46

Earlier quoted context omitted.

Unfortunately, remapping escape to caps lock can lead to serious friction if you have to work with different laptops a lot, like I do. The muscle memory gets in the way a lot.

I always remap Caps Lock to Ctrl. I understand that Caps Lock needed to be next to Shift in typewriters, but in computers it seems like it is wasting a key in the home row for only be used sometimes for screaming (which can be done by holding shift...)

and if you really need the SCREAMING, vim got you covered. Just type your word normally , select it in visual mode and type gU

Re: Why TUIs are back

#369

Post by fg137 »

zozbot234 wrote: post #205
fg137 wrote: post #28

Only for software engineers who are already familiar with terminals. Most non tech people I know and in my company absolutely hate TUI. Even a fraction of software developers who spend most their time outside terminals (especially those that are on Windows and/or use specialized tools/IDEs) prefer to avoid TUIs as well.

Many "non-technical" folks who have interacted with virtual 3270 terminals for all sorts of mission critical tasks would disagree sharply with that assessment. And those are essentially TUIs.

Do they use it for generic computing stuff, like, reading and replying to emails, or specific tasks?

Re: Why TUIs are back

#370

Post by nickjj »

d3Xt3r wrote: post #328
nickjj wrote: post #11

I do like CLI tools and TUIs but in the article it mentions Gnome style apps don't fit the look. That sounds like a limitation of Omarchy. It's not too bad to theme GTK apps and have them all look a consistent way. For example I use Tokyonight Moon and Gruvbox and they both have GTK themes that look great for Firefox, Thunar, GIMP, LibreOffice and more. I don't use Omarchy but here's a few screenshots https://x.com/n…

Those apps you mentioned are not your typical modern GTK4/libadwaita apps, so naturally you can theme them. It's the GTK4 apps - and ones which use libadwaita specifically - that cause grief. - Firefox: Uses its own custom rendering engine but interfaces with GTK3. It respects standard GTK3 themes. - Thunar: Uses GTK3 - GIMP: Since v3.0, they now use GTK3 - LibreOffice: Uses its own visual framework (VCL) but has a G…

> so they're not good examples unfortunately

They're some of the most popular GTK apps available. They seems like a good example to me.

The themes I'm using are compatible with GTK4 apps too.

I use niri which suggests installing xdg-desktop-portal-gnome which comes with Nautilus which is a GTK4 app. It's perfectly themed just like the GTK3 apps.

Post reply on HN