[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#626000: Non-sensical auto-sizing of button controls (commandWidgetClass)



Package: libxaw7
Version: 2:1.0.4-1

OK, this is going to be cumbersome, as it concerns a deeply buried problem
in a low-level library routine. So there we go:

I am an upstream developer of XBoard, and I use an Ubuntu 8.04 system.
I take the sources of XBoard 4.5.2a from the git repository of
http://savannah.gnu.org/projects/xboard , and build an XBoard from it with
the commands (in the directory where I unpacked the tar ball):

./autogen.sh
./configure
make

I then run it with the Chess engine Glaurung (package: glaurung, version:
2.0.1-2), with the aid of the adapter Polyglot (package: polyglot, version
1.4.53b) through the command

./xboard -fcp glaurung -fUCI -size 49

>From the menu I select Engine -> Engine #1 Settings. A dialog pops up that
looks like this:

http://hgm.nubati.net/settings.png    (I also attached this image)

Look at the size of the button labeled "Clear Hash" near the upper right.
It is not high enough. That is what I am complaining about.

This dialog is generated from a list-driven dialog generator, and the code
specifying the button is the same code (in another iteration of the loop)
that generated, for instance, the button marked "Polyglot Save" far below
it. This code is:

	    j=0;
	    XtSetArg(args[j], XtNfromVert, option[i].min & 1 ? lastrow : last); 
j++;
	    XtSetArg(args[j], XtNlabel, _(option[i].name));  j++;
	    if(option[i].min & 1) { XtSetArg(args[j], XtNfromHoriz, last);  j++; }
	    else  { XtSetArg(args[j], XtNfromHoriz, NULL);  j++; lastrow =
forelast; }
	    if(option[i].max) XtSetArg(args[j], XtNwidth, option[i].max);  j++;
	    if(option[i].textValue) { // special for buttons of New Variant dialog
		XtSetArg(args[j], XtNsensitive, appData.noChessProgram ||
option[i].value < 0
					 || strstr(first.variants, VariantName(option[i].value))); j++;
		XtSetArg(args[j], XtNborderWidth, (gameInfo.variant ==
option[i].value)+1); j++;
	    }
	    option[i].handle = (void*)
		(dialog = last = XtCreateManagedWidget(option[i].name,
commandWidgetClass, form, args, j));

As you can see, no vertical size is specified, and I would expect the size
to be chosen based on the height of the font inside.

Why do I think Xaw is responsible for this? Well, the buttons generated by
this code behave extremely erratic. I have seen examples where they re
ridiculously wide (more than doubling the width of the dialog they are
in), and on opening a dialog with no elements other than an OK and cancel
button (for instance when the engine used was Crafty, "./xboard -fcp
crafty") I suffer inexpliquable crashes. Trying to locate the point of the
crash by putting printf calls in the code can make the crash go away,
although eventually I was able to pinpoint it to the call of XtPopup for
the dialog.
All this is very poorly reproducible; the example with Glaurung seems to
reproduce reliably, though, which is why I report that.

This whole affair has the smell of the use of an uninitialized local
variable in the code responsible for calculating the initial size of a
widget of this class. Very often it seems to "inherit" the width of a
widget just above or left of it. I can make the problem go away by
explicitly specifying an XtNwidth or XtNheight for the widget, (e.g. by
setting option[i].max non-zero for the width), but this is very cumbersome
to do if you don't know the text or font of the message it should contain
in advance.

Attachment: settings.png
Description: PNG image


Reply to: