From: converse@expo.lcs.mit.edu (Donna Converse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Small program illustrating Xaw dialog problem...
Date: 2 Sep 92 03:05:38 GMT
Distribution: fj
Organization: X Consortium, MIT Laboratory for Computer Science

Message-Id: <9209012204.AA00508@excess.lcs.mit.edu>
Date: Tue, 01 Sep 92 18:04:35 EDT



> Here is a small program that illustrates the Xaw dialog box problem
> I described in the previous posting. You give this program one argument,
> the number of dialog widgets to create. For me, the output is fine when
> this is 11, but not fine when it is 12.

When there are 12 dialog boxes, the value field in each of them is blank,
but when there are 11 or less dialog boxes, the value field in each of
them shows up with the correct value.  The problem is in the sample program. 
Hint: try using the window manager to resize the window to a larger size.


[ This example code has been condensed slightly ]

>     toplevel = XtAppInitialize(&context, "xprob", NULL, 0, &argc, 
>         argv, NULL, NULL, 0);
> 
>     XtSetArg(args[0], XtNwidth, 300);
>     XtSetArg(args[1], XtNheight, 600);
>     XtSetValues(toplevel, args, 2);
>
>     form = XtCreateManagedWidget("form", formWidgetClass, toplevel, NULL, 0);
>    
>    /* Make the dialog boxes. */
>     XtSetArg(args[0], XtNlabel, "some random label");
>     XtSetArg(args[1], XtNvalue, "some random value");
>     dialog_widgets[0] = XtCreateManagedWidget("dialog", dialogWidgetClass, 
> 					      form, args, (Cardinal) 2);
>     for (i = 1; i < nwidgets; i++){
>        XtSetArg(args[2], XtNfromVert, dialog_widgets[i - 1]);
>        dialog_widgets[i] = XtCreateManagedWidget("dialog", dialogWidgetClass, 
>						  form, args, (Cardinal) 3);
>    } 
>
>    XtRealizeWidget(toplevel);


When the widgets are realized, a geometry negotiation takes place.
I've found that the paper "Geometry Management with Xt: Advice for Widget
Authors" from the proceedings of Xhibition 1991, by Kee Hinkley and Andrew
Schulert, is valuable to read.  From that paper:


	The general layout algorithm takes place in two stages:

	1.  Compute the requested configuration of each widget, starting
	    with the primitive widgets and working up to the root.

	2.  Distribute the available space among the widgets, starting
	    with the root and recursing down to the primitive widgets.


The set values call on the shell's width and height determines the
available space.  If you take it out, the shell will be sized according
to the result of step 1.  If you leave it in, the Shell will resize the
Form to be 300x600, the Form will resize each of the Dialog boxes, and
each of the Dialog boxes will resize each of the widgets contained within
them.  One of these is the value field -- an AsciiText widget, actually --
and when it gets squished it decides it doesn't even have enough room
to display one line of text, so it doesn't display anything.  But we look
at the field and think that it is a blank field. 

In a mythical perfect Dialog widget, the application programmer could
say "When you are resized smaller, make the Label unreadable before you
make the Text field unreadable", but you can't do this with the Xaw Dialog
widget because it hardwires some of the constraint resources for resizing
of its children.  You might be able to request that the value widget
of the Dialog get a scrollbar when it is needed -- then the user would
at least get a clue that there was a some text there, even though they 
cannot actually see it.

Maybe you could do without constraining the shell window to be a
particular size?


Donna Converse
MIT X Consortium