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

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

Your message dated Sun, 8 May 2011 23:18:56 +0200
with message-id <20110508211856.GH23498@mraw.org>
and subject line Re: Bug#626000: Acknowledgement (Non-sensical auto-sizing of  button controls (commandWidgetClass))
has caused the Debian Bug report #626000,
regarding Non-sensical auto-sizing of button controls (commandWidgetClass)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
626000: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626000
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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


--- End Message ---
--- Begin Message --- 
Hi,

h.g. muller <h.g.muller@hccnet.nl> (08/05/2011):
> Someone pointed out that the bug is in the code fragment I quoted:
> missng braces enclosing the j++ with the conditional.
> 
> Sorry for wrongly accusing libxaw of this. :-(

no problem, thanks for the report anyway, and for the follow-up.

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: