Update of bug #34202 (project xboard):
Status: Need Info = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #9:
seems like this
Follow-up Comment #8, bug #34202 (project xboard):
Just checking in if I can close this bug... IIRC the problem was solved?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34202
___
It should be a persistent option. So if you switch it on from the menu
once, XBoard should start up with textures enabled forever after. If not,
your install is broken.
Op Vr, 23 december, 2011 7:32 pm schreef Richard Kircher:
Follow-up Comment #5, bug #34202 (project xboard):
Regarding board
The manual should be reasonably up to date.
Za, 24 december, 2011 12:21 am schreef Richard Kircher:
Follow-up Comment #7, bug #34202 (project xboard):
The command line option -useBoardTexture true worked fine but I think I
created myself another related problem by copying the compiled
Follow-up Comment #4, bug #34202 (project xboard):
Glad to hear about the reduced start up time.
For the textures try the new menu option:
View Board... Use Board Textures
___
Reply to this item at:
Follow-up Comment #6, bug #34202 (project xboard):
The command line option is -useBoardTexture true.
You can use it on the command line or put it into your .xboardrc file, either
manually or by saving all selected options in the Options menu.
Follow-up Comment #3, bug #34202 (project xboard):
Thank-you. Following your advice (your last paragraph), I now have the least
startup delay ever achieved from other changes suggested by h.g. muller, and
Arun Persaud. With NLS disabled, I now get a 1.8-second delay with the medium
xboard size,
Follow-up Comment #2, bug #34202 (project xboard):
Hi,
I did some test of the start up times in different versions to find what have
caused this regression.
I replaced the main loop (XtAppMainLoop) with a dummy function that returns
immediately using LD_PRELOAD, and timed the real time used by
One important difference between the previously reported bug
and what you report now would be that you now find this behavior
also in 4.2.x, while before it only manifested itself in 4.4.0.
I am not sure that taking a binary from one distribution, and
plugging that into another, is a valid
