Submitted by “Whilst an increasing number of recent converts are avoiding it (and I don’t blame them really), the shell is still a key tool for the majority of GNU/Linux users. Shell scripts are knocked-up, shared and deployed in all sorts of circumstances – some simply time-saving, others life-saving. But even if the shell script has been written by somebody else, running it can be a cumbersome and frightening exercise for users of lesser experience or confidence. How do we bring the flexibility of the shell script to the GUI-only user? Recently faced with just such a quandary, http://www.freesoftwaremagazine.com/columns/saving_my_sanity_zenity_shell_script_interaction_gui”>I discovered Zenity: a tool which just might have saved my sanity.”
It’s a tool to show simple dialog boxes from the terminal. These tools have been around forever. Big deal.
The author uses it to pop up a message when his network-connection script runs. Seems he just realised that there’s a world of desktop users out there too. Taking care to make your programs (shell scripts or otherwise) user-friendly, interactive and informative isn’t newsworthy. Indeed, it should be compulsory.
Yeah. What is needed is something like the Windows AutoHotKey that can intelligently script Qt and GTK applications.
Yes, what you say is true. But the problem is that to allow the user to work as he/she is used to may require quite a bit of work if you do it in any other way than zenity or kdialog.
Like, for instance, having him pick a date.
You can write a whole script and just use zenity to put up the user interactions with minimal work, and its all going to be very intuitive and normal for them.
Example at
http://www.linuxjournal.com/content/make-your-scripts-user-friendly…
What it means is, you can use shell scripts where otherwise you might be driven to a full blown gui language.
I’m not sure you can convert the power of the shell to a GUI. A major selling point of the shell is piping commands together and I just cannot see how this’ll be possible on the GUI.
Haven’t actually done it, but it looks like the zenity commands to get the user input are just one line in the script. You can still pipe anything to anything in the rest of the script, and also can pipe that input.
“Whilst an increasing number of recent converts are avoiding it”
I often see glib statements about new Unix users avoiding the shell. What I have not seen is any basis for these statements.
From the article:
In my experience, users accustomed to a dialog with Yes/No buttons can find themselves stumped by a black window with a bunch of white text, the last line of which says something like Interface not found: proceed (Y/N)?.
I find myself stumped reading this.
For KDE users there is kdialog. It has everything zenity has minus calender but plus many other things: –geticon, –getopenurl, –menu, –combobox, –password, –checklist, –radiolist etc.
In combination with kfmclient (or kioclient for KDE4) this is really handy. I use it from python, too. e.g.: http://kde-apps.org/content/show.php/Get+YouTube+Video+(improved)?content=41456
zenity (or kdialog or xdialog etc.) are all well and good, but your shell script should check for $DISPLAY and only run zenity if it’s set. If it isn’t set, each GUI dialog prompt/display will need the equivalent text-only prompts/output.
I’m about to do something similar myself with a text-only program I’ve written (in C – nothing wrong with system()’ing zenity from a binary – it’s not just for shell scripts) – I’ll be calling zenity for input and output, but only if $DISPLAY is set and /usr/bin/zenity is available (otherwise the old text input/output code will be used as a fallback).
there are also “dialog” program for text terminals, and “gdialog” which use zenity but has same parameters as dialog.
so u can do something like on top of your script
[ “$DISPLAY” ] && DIALOG=”gdialog” || DIALOG=”dialog”