YAD: display graphical dialogs from shell scripts or command line | Hacker News Reader

YAD: display graphical dialogs from shell scripts or command line

yad-guide.ingk.se

50 pointsmodinfo15 comments

I hope anyone who uses something like this has the grace to fall back to https://linux.die.net/man/1/dialog for non-GUI users. Or https://github.com/Textualize/textual if they want to be faaaaancy.

On my Note phone, I just tried dialog. Spiffy!

I used Termux, and did this for a hello world:

     pkg install dialog
     dialog "hello there" 20 3

And BAM! There it is rendered in text, easy peasy.

Thanks for the reference. I agree with you.

man that's an ugly man page. The FreeBSD one is a lot easier to read.

https://man.freebsd.org/cgi/man.cgi?query=dialog

Well, after a bit of fiddling, Textual also worked on my Android running Termux.

Spiffy!

I like this one a bit less than I do the all text mode, though I will have to go through a bunch of widgets to see if that remains true.

Requiring Python seems a bit excessive, compared to the other one with works more lime the author intended, I believe.

Thanks for these. Interesting to look at.

Textual is new and fancy. Dialog has been on pretty much every linux system for a quarter century.

Yes. It shows. I like that quarter century stuff.

Or for those won't don't want to install dialog, just do your ui forms directly from the shell: https://github.com/polijan/sourcedialog

Nice to see some projects like this in kinda-active development after 20+ years.

Great program but I've always wanted a version that had a native look and feel, or at least a more modern UI.

> Great program but I've always wanted a version that had a native look and feel, or at least a more modern UI.

dtksh ? (CDE) /s

I know someone who uses FLTK for cross platform development. That one has a dated look too, and it's roots go back to that SGI Indigo Magic desktop I wrote about elsewhere in this discussion.

Sometimes it can be hard because people want to see the same GUI. And this is true even when it is input equal, I mean click to keystroke identical!

Most will say "modern" when they mean, "the one I drive daily."

And in many cases, those are one and the same. Modern simply is the daily driver, be it MacOS or Windows, or...

Doing that cross platform is hard!

With FLTK, a solo dev can write once, build for almost anything and it will work great. This is especially true for a C++ developer, which they are.

Over time, we have found building a modern GUI either takes a ton of time tweaking FLTK to look damn close, or it requires essentially different builds and dependencies, one set per platform supported, or...

Don't do it.

The thing is, we really value being able to bring the application to the user on their platform of choice. And today doing that is damn near free.

Basically, we just need to build FLTK on the target once, and the app will build with few to no problems. Easy peasy.

Users currently use Win 7 through 11 (yes, there are more of those out there than we may want to admit), Mac Intel and MX Apple Silicon, and a Linux user or two.

No Droid yet.

I wish it were different, but it isn't.

This tool seems high value because, like the other one mentioned here "dialog", which simply does the GUI in a terminal, command line tools are often the easiest, most portable build.

From there, one needs to adopt GUI foundation tools, which are specific to an OS, or like FLTK, look different.

Or, spend a ton more money, hire more devs and brute force cross platform tools.

I wish it were different. Is it?

Are we missing somethng?

> Are we missing somethng?

wxWidgets?[1] Native widgets on Windows and macOS, targets GTK on Linux-y systems.

Granted, no real Android story.

[1]: https://wxwidgets.org/

Nice!

Way back when I was daily driving an SGI IRIX box, I was struck by how SGI often made IRIX system programs dual mode, command line and or GUI.

On the command line, one could specify -v or --verbose or -GUI and generally get the desired outcome.

Some programs, usually the ones with some sort of -GUI option, or that would detect the user running on an X Window system, contained the GUI mode in the same executable. And it would just appear on whatever display was specified in the user environment.

Others, generally the ones offering --verbose style output, were designed so that GUI wrapper type programs could just call them and have a robust enough command line interface so as to support a GUI without the user experience suffering much, if at all. All that extra output was so a gui could display options, progress, and all the things we might expect. The program just streamed that stuff on STDOUT, GUI streaming actions on STDIN and both using STDERR as needed.

neato!

Anyhow, I loved that kind of design. Learning either the GUI or command line was cross productive, generally speaking.

And back in the 90's and 00's when all this was happening, IRIX was NICE. Seriously. I cannot count the number of people who would come by and end up talking shop, often prompted by various desktops they might see in action.

Sidebar = 1

I really do miss that compute environment. I rarely have experiences in computing as good as all that was back then. I know, an SGI was a ton of money! But damn! Worth it to many.

Often felt like computing a little ways into the future:

We would be playing 3D games in the 90's via X and or various boxes capable of running them locally, all while yelling and making faces at one another via web cam and mic, sharing videos and files with one another using standard desktop tools included with the Indigo Magic Desktop, and more...

The PC got there close to a decade later, but I digress...

Sidebar = 0

We have bigger, faster and recently, more functional systems today. Things are almost there!

(In both Unix and Windows land, surprisingly)

What you say? Almost there?

Back then, say I wanted to bring up a new box, then perform software management on it.

The system bring up would start with a nice GUI running under ARC loader.

That would get a person into single user mode where one would run "swmgr" and specify the system load and sometimes additional software to be loaded.

Powerful commands got this done quickly.

Keep default

Add [subsystem name or wildcard]

Resolve conflicts would bring up a list one could work through, or one could also just specify a default, the system would sort it and then...

Go.

And soon you had a running system!

Run "swmgr" again, and this time you got a GUI that looked a lot Ike package management tools do today, but with hidden power!

Say you asked something to be installed and part way though disk ends up near full.

The SGI system would allow one to pause the current operation, yielding time to solve the problem simply through file management, or adding space. Whatever.

But, it would also allow one to start another operation right in the middle of one in progress too!

Often, I would Uninstall bigger subsystems not used often, and then carry on with the initial operation, all while...

A user is at the machine working! And I could do that graphically, thanks to X and multi user graphical computing, or command line, old school UNIX style, or both!

They might notice the high disk activity, but it was rare to see their work impacted beyond that. I could always bump the admin tasks to low priority, or bump their task up depending on what mattered most.

Managing those kinds of things command line is crazy, but possible. And scriptable.

Using a GUI is still a bit crazy, but a lot more possible, but not so scriptable in the GUI.

Because of how so much was made to work either way, it just did not matter much. Anyone wanting to automate could.

And there was always Tcl/TK for crude GUI actions in shell scripts. That was hard enough to be unused by me unless the automation was really going to see a lot of use and varied scenarios to make the effort worth it.

These functions seem much simpler than I recall from back then. And it appears one can write programs that work with the best of them too.

An application could be a combination of shell code, compiled C or Python, or any other thing, even the likes of Fortran, and the GUI tools presented here provide the user with more than enough.

Neat!

I going to have to test drive this by making a wrapper for something I use a lot.

And I look at tools like gparted and realize creating more like that one may just have become easier?

Double neato!

When I was a co-op I worked at a company that had all sorts of SGI machines. They really were so much fun. As I remember it the SGI compliers would do just about anything so you would develop there and then take things to the Sun's and AIX to clean up the code. IRIX was so great. Og course all the 3D stuff was pretty fun, too with red/blue glasses etc.

We had both red blue and active shutter.

My TV is 3D. Bought it because of that and my SGI experiences.

Sadly, we botched 3D TV and few owners ever really got to use that tool to potential.

Reply on news.ycombinator.com