| previous next contents | bottom |
Xdialog FAQ v1.60, 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...
There are two ways but the result is not guaranteed as some window managers will simply ignore or override the GTK+ placement requirements and place the windows where they feel like.
a.- As of v2.0.0, Xdialog takes into account the origin coordinates given into a "-geometry"-like parameter; e.g. passing 240x120+150+80 as a size parameter to Xdialog will place its window (which size will be 240x120 pixels) at Xorg=150 and Yorg=80. In this example, you may as well let Xdialog auto-size by passing 0x0+150+80 instead. E.g;:
Xdialog --title ppp.log --tailbox /var/log/ppp.log 0x0+150+80
b.- 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 must use the GTK+ auto-wrapping mode and alas this only really works when the box auto-sizing 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.
With some scripts written for dialog, some pre-formatted text may appear mis-aligned in Xdialog menus. This is because GTK+ uses proportional fonts while the console tools such as dialog may only use fixed width fonts.
While the --fixed-font intructs Xdialog to use a fixed width font (more exactly a monospacing one) into the text windows of the tailbox, textbox and editbox widgets, the labels and backtitle of Xdialog still use the font defined in the GTK+ theme in force when Xdialog is started. There are two ways around this, by using either the (c)dialog high compatibility mode, or the --rc-file option together with a gtkrc file where the font parameter is set for a monospacing font name. E.g.:
style 'fixed_font' {
font = "-*-*-medium-r-normal-*-*-*-*-*-m-70-iso8859-1"
}
widget '*' style 'fixed_font'
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 ".*" 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
You may need to build dynamically a menu for some scripts. Although Xdialog does not accept to take its parameters from a file (in which you could put the menu entries), nothing prevents you to build dynamically a sub-script containing a Xdialog command, and then call it from you main script. Take a look to the xlock-wrapper script which uses such a trick.
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 fail 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 to v1.2.10: 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) !
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).
Because your GTK+ setup is badly configured... Most probably, you are lacking some fonts for your locale and/or your GTK theme is buggy... You should find out and fix it. This is not a Xdialog bug, please do not report it as such ! For convenience and as a quick hack (to let you the time to fix your system later and yet let you use Xdialog), I adopted in v2.2.0 a slightly modified version of Debian's hack for v2.0.6: by setting the XDIALOG_NO_GMSGS environment variable to "TRUE", (or "1"), you may disable all messages sent by GTK/GDK/GLIB. Note, yet, that GNOME may still send such messages (including on stdout), and I did not find any way to divert them so far...
Well... The idea behind Xdialog was to need for as little dependencies as possible (it only needs for glib and gtk+ v1.2.10, beside the X11 server)... I therefore always rejected the idea to port it to GTK2, the latter needing for an insane number of libraries and being as well quite sluggish (beside, who needs for anti-aliased fonts in dialogs and menus ?... Not me...). The only interest for such a port would be the UTF8 support (but here again, it is of little to no interest for most people, unless they live in a country such as China, Japan or Russia...). For all the above reasons, I never even tried to port Xdialog to GTK2, and I'm afraid I can't help you (I never had any interest in GTK2 itself either, and I keep using GTK+ v1.2.10 as it suits all my needs).
This said, someone did send me a patch to turn Xdialog into a GTK2 app. Of course, I reworked it so that the default is still to compile Xdialog against GTK1 (but you may try and compile it for GTK2, see the Change log). The GTK2 port is still incomplete and buggy (problem with output of accented characters on systems using ISO charsets), so if you feel like taking over the burden to complete the port, I'll gladly include your patches into the next release...
Because, in their most recent distros (v10.2/LE2005 and probably others), Mandrake used two patches which are breaking some GTK+ functionality. One of the patch is allowing to update all already open GTK windows whenever a theme change occurs (who cares ?... Do you change the theme every 5 minutes ?... Can't you stand having temporarily unmatched window themes just after a change ?), but overrides any custom gtkrc setting as a result. The other broken patch is supposed to "fix" locales problem (I didn't even notice there was any !), but breaks fonts matching as a result. To fix this problem, you may download from Xdialog's website the custom GTK+ packages I rebuilt.
| previous next contents | top |