Xdialog FAQ v1.20, compiled by Thierry Godefroy <xdialog@free.fr>
Yes, in fact you can use Xdialog from any scripting language supporting external command calls.
I found three ways (but there are perhaps more; I'm not a Perl guru !):
a.- Using the "system" command (not the best way IMHO):
Just redirect the Xdialog output into a temp file, then use the "open" command to read the result, put it in a table and use it (here just printing it):
system('Xdialog --inputbox "Please enter something below:" 0 0 2>/tmp/my_temp_file'); if ($? == 0) { open(RESULT, "/tmp/my_temp_file"); @result=<RESULT>; close(RESULT); print @result; }
Finally, destroy the temp file (may be there is a better way to do this...):
system("rm -f /tmp/my_temp_file");
b.- Using backquotes (just like in "sh": IMHO the best way...):
$result=`Xdialog --stdout --inputbox "Please enter something below:" 0 0`; if ($? == 0) { print $result; }
c.- Using "open" and streams (useful if you want the result to be put in a table):
open(RESULT, 'Xdialog --stdout --inputbox "Please enter something below:" 0 0 |'); if ($? == 0) { @result=<RESULT>; print @result; } close(RESULT);
Note the use of --stdout in (b) and (c) so to send the result returned by Xdialog to the proper output stream...
GTK+ windows cannot be given an absolute coordinate on the screen, the only possible placement options are screen center (--screen-center Xdialog option), under the mouse pointer (--under-mouse Xdialog option) and automatic placement by the window manager (--auto-placement Xdialog option). Even worse, some window managers will simply ignore or override the GTK+ placement requirements and place the windows where they feel like.
But some window manager do allow to place a window with a given title or class name at a given position on the screen. Xdialog therefore provides a way to set its window manager class name through the --wmclass option. E.g.:
Xdialog --wmclass ppp_log_tailbox --title ppp.log --auto-placement \ --tailbox /var/log/ppp.log 0 0
Now this Xdialog tailbox is registered with the "ppp_log_tailbox" name. With twm and fvwm(2/95) you will have to edit the .Xdefaults file in your home directory, adding "ppp_log_tailbox*geometry" parameters so to set the Xdialog position and/or size. With sawfish, just move the Xdialog window to the place of your choice, pull down the window manager options menu (clicking on a given button in the Xdialog window title bar or on the title bar itself: this is user configurable and may also depend from your sawfish theme) and choose the "History"/"Remember position" item in the menu; the next time an Xdialog window with a "ppp_log_tailbox" wmclass will be open, it will pop up at the remembered position...
a.- Windows decorations:
Through --wmclass option provided your window manager makes use of the wmclass name of the windows so to decorate them differently. The method is the same as in §3 (just use the Xdialog --wmclass option and RTFM of your window manager; hints: "winoptions" editing for IceWM, window manager option menu use for sawfish, ".Xdefaults" editing for twm/fvwm, etc...).
b.- GTK+ themes:
As of v1.4.6, Xdialog accepts a new --rc-file option. Thanks to this feature Xdialog can be instructed to use a given GTK+ theme (which may therefore be different from the theme currently in use).
c.- User defined icons:
As of v1.4.6, Xdialog accepts the new --icon option that will make a user defined icon (in XPM format only) to appear on the left of the <text> (for the Xdialog box options using this parameter, the box options without a <text> parameter in their syntax are not taking the --icon option into account).
The name of the printer to be used by Xdialog is to be passed after the --print option in the Xdialog command line. Nothing prevents you to make this printer name a variable which will be set via an sh include file. Here is an example of how to do it:
#!/bin/sh # Sample script with per-user costumizable printer name. # First set the default printer. XDIALOG_PRINTER="lp" # Check if the user wants to use its own printer. if [ -f ~/.xdialog-printer] ; then . ~/.xdialog-printer fi Xdialog --print $XDIALOG_PRINTER .../...
Then for each user, the following .xdialog-printer file may be put in its home directory:
# /home/foo/.xdialog-printer include file for user "foo". # Let's use the "bar" printer... XDIALOG_PRINTER="bar"
Because this option only really works when the box autosizing feature of GTK+ is used. The work around is therefore to let GTK+ calculate the size of the box by passing a 0x0 (or 0 0) size to Xdialog. E.g.:
Xdialog --wrap --msgbox "Very, very long text indeed, let's hope it will be\ properly wrapped around by GTK+..." 0 0
In the exact same way as with any software using the GTK+ file selector: type a "." into the text entry field and then press the TAB key: the hidden files/directories will then be presented into the selector lists, allowing you to select one with the mouse.
Also, appending a ".*" to the default directory name into the Xdialog command line, makes all the hidden file/directory names (and only them) to appear into the fselect/dselect widgets when poped up. E.g.:
Xdialog --fselect "/home/foo/.*" 0 0
There is currently no known bug in Xdialog code (and I use Xdialog on four different Linux systems without problem so far). But here are some hints on why it may fails to run on some systems:
a.- Xdialog can theorically be used with GTK+ v1.2.0 and upper but it has only been extensively tested with GTK+ v1.2.8: if you are using an older GTK+ version, please upgrade (some segfaults have been reported when using GTK+ v1.2.6 that disappeared once upgraded to GTK+ v1.2.8).
b.- GCC is a fine compiler, but GCC v2.95 is broken ! It sometimes fails to notice that the stack has been tidied on return of self-tidying functions (mostly math functions)... As a result, compiling any program with the -fomit-frame-pointer flag may result in instable binaries (or even instable Linux kernel: I recompiled mine with -fno-omit-frame-pointer and some strange crashes I got in the past are now history !): If you compile Xdialog with this flag you WILL get into trouble... Please use the -fno-omit-frame-pointer flag when compiling Xdialog with gcc v2.95.x (as of Xdialog v1.5.0, the configure script takes care of adding automatically this compile option when a bugged gcc version is detected) !
The x86 binary RPMs on http://xdialog.free.fr are compiled (on a Mandrake v7.2 distro) with the proper settings and dynamically linked to glibc v2.1.3, XFree86 v4.0.1 and GTK+ v1.2.8.
If you meet the requirements above and still get segfaults with Xdialog, then this is probably a Xdialog bug that you should report to me; please be precise and give example(s) of how to reproduce the bug (I am generally pretty quick to diagnoze/fix bugs provided they were properly reported).