🚀 go-pugleaf

In article <9002212306.AA03914@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes:
>
>> As a beginning of the Widget user, I am not sure how to use dialogWidgets.
>> What I need is to "gets" a string into a buffer when the string is typed
>> into the dialog window along with a carriage return (just like a regular
>> gets() does).  I understand that I may be able to use
>> XtDialogGetValueString, but I don't know how the Xserver can inform the
>> dialog Widget that the string has been typed in.  I tried to use the
>> client callback interface, but couldn't find the appropriate resourse in the
>> dialog resource database listed in the X11/R3 X Toolkit Athena Widgets
>> Manual (yes, I am still using X11/R3).
>
>You can certainly perform operations similar to gets() with widgets, the
>interface is a bit different, however, as well as the style of programming.
>To really do this in the X model you need to have an event driven interface. 
>This to say rather than doing this:
>
>	
>	.
>	.
>	.
>	printf("enter a value");
>	gets(string);
>	PerformOperation(string);
>    }
>
>You would do this:
>
>	.
>	.
>	.
>	PutUpDialogBox("enter a value");
>	return();
>   }
>
>   PutUpDialogBox(string)
>   {
>	/* Create box, and bind function DialogReturn() to
>	   the action of the user saying that the string has been entered. */
>   }
>
>   DialogReturn(dialog, ...)
>   {
>	string = XtDialogGetValueString(dialog);	
>	PreformOperation(string);
>   }
>
>Basically it is the assumption that your application is just performing a bunch
>of operations, based on the actions of the user within the user interface. 
>There is no longer a single line of obvious program flow control.

Well, this really depends upon your toolkit and what it offers.  The XView
toolkit has a function called, "notify_set_input_func()", which will tell
you when you should call gets in your program.  Since the input function
reads from any file descriptor, this could be stdin, or it could be the
output from a ttysw within the application.

Often dialog boxes can be cumbersome, and if your user base is used to
typing into a tty, it might be easier for them to continue to type into
a tty.  

Basically, one should let the needs of the end users define the user
interface parameters and thus which tools best fit those parameters.
If you let the constraints of your choosen tools define the user interface,
then you end up with applications which may not fit your end user's needs.

Also, if you have an existing application which looks like:

	printf("enter a value");
	gets(string);
	PerformOperation(string);

XView provides a function, "notify_do_dispatch", which allows an easier
port from this style to a window based style.  This is very handy if the
application is large and you want to minimize the time spent on it.  If
it is a new application, I would suggest using the event driven style
Chris mentions above.

The difference between using the notify_set_input_func and the 
notify_do_dispatch function is strickly a choice of programming style.
The value they provide is pretty much the same:  dispatch window events
while waiting for input on some file descriptor[s].  The difference is that
notify_set_input_func uses a callback to start some action while
notify_do_dispatch is inline.

There are programs in the on line O'Reilly examples which demonstrate how
to use both of the above mentioned functions.  See <XVIEW>/clients/examples/
notifier/[notify_input.c ntfy_do_dis.c].  <XVIEW> is on the X11R4 tape in
contrib/toolkits/XView.  Two patches on expo in contrib/XView.

Regards,

Heather