
dialog-0.69
===========

Information about installation is in the file ./INSTALL
This file is mainly for development ideas.

The newest source code of dialog is on susix.jura.uni-sb.de in the
directory /pub/linux/source/libc/ncurses/dialog

Alternate sites are iride.unipv.it:/pub/linux/dialog and
foggy.systemy.it:/pub/dialog

More stable releases will be uploaded to sunsite.unc.edu into the
directory /pub/Linux/utils/shell/.

dialog-list@redhat.com is a mailinglist for the discussion about
further development of dialog. To join the mailinglist do:
"echo subscribe dialog-list First_Name Last_Name | mail listproc@redhat.com".

dialog is typically invoked from a shell script and puts nice
yes-no/checklist/radio-button - menues on your screen.
(Text is just passed on as arguments to dialog.)

This version of dialog should be compatible with all prior versions.

Please use ncurses-1.9.4 or newer with this dialog release. It's really worth
it. (prep.ai.mit.edu or ftp.netcom.com/pub/zm/zmbenhal/ncurses.)
If you have problems compiling dialog, you might have to change the
source code to use '<ncurses.h>' instead of the now used '<curses.h>'.

Thanks a lot,

Florian La Roche     florian@jurix.jura.uni-sb.de


TODO:

- allow editing in textboxes (optional)
- should ncurses be required or #ifdef code is worth keeping?
- redo help message
- react to SIGWINCH
- new rc file format (see notes below)
- finish writing docs
- a smart autoselection of the window size.
- A tk interface that selects nice X11-menues on a graphics screen and
  textboxes on a normal textscreen (see note below)
- check installation, and install the info docs as well.

fixes on new features:

- the mouse in input boxes.
- write correctly the hotkey (which isn't always the first) for list-like boxes
- remove (and autoconf) all the remaining "#ifdef ultrix" and such
- allow to specify some items on cmdline, and some via stdin/file


short notes about the rcfile (ARubini)
--------------------------------------

What is needed, imho, is something sketchy, like background, panel,
border, item, tag, key. This eases rc-file writing.  Then, all
hardwired things like '#define DIALOGRC' should have an environment
override. Parsing should be made as simple as possible, and the
"--create-rc" should be removed: just install a sample rc file, so
users can copy it -- the "FILE" section in the man page is there just
for this reason. Moreover, the installed file can be sourced as default
source of rc-info, so system-wide settings are allowed.

Ok, this is the list of attributes I'd use:
	background (only bg)
	shadow (only bg)
	panel (bg,fg)
	border (only fg, as the bg is the panel one)
	button (bg,fg,activebg,activefg)
	b_key (bg,fg,activebg,activefg)
	item (bg,fg,activebg,activefg)
	input (bg,fg)
	arrow (bg,fg)
	
The rc file can also embed tk-specific information.



short notes about the tk interface (ARubini)
--------------------------------------------

A tk interface would be nice, but the following problems must be taken
into account.

- A window can't simply disappear after accomplishing its task, becuase
   1- info boxes are meant to remain there
   2- usually a dialog script has more dialog invocations, and having
	windows spurring out and dying is quite annoying.

- An info box can't remain there forever. Some way of timing out is needed.

- The same script must run under text and graphics, without change wahtsoever.

- The window must retain the same size across dialog's, and the user must
	be able to change it by hand.

Thus, tkdialog must not be invoked directly by the user. It must be
"dialog" itself wich invokes the tk version. Invocation semantics can
well be different, to improve performance. Tkdialog must reside in
$(PREFIX)/lib/dialog, together with the rcfile.

The notion of "dialog-session" is needed. I think to implement it
by menas of a fifo in /tmp, named after the user and the tty, like
"/tmp/dlg.rubini.p0". The fifo is then used to communicate. Tk4 is able
to put file-events in its main loop, so the fifo should work smoothly.

Dialog itself can't remove the fifo, because the next dialog may be
part of the same script, and thus need the same (persistent) window.
The pid of the invoking shell can be used as a key, and tkdialog can
keep polling the shell every few seconds. When the invoking shell
is dead, tkdialog removes the fifo and exits.

Scripts invoked by scripts don't make any problem, because the first
invoking shell is still alive, and the first invocation of tkdialog
is made by the toplevel script. This is why I use the tty to name
the fifo and not a pid whatsoever.







