Xboard 4.7.0 and earlier logos on OSX

[JoshPettus]

Sorry to do this to you guys now but I think I ran into a minor issue and it hold true with the master branch before 4.7 was released. I meant to bring it up before but forgot.

I couldn't get logos working for the engines as was advertised. I have this in my xboard.rc/xboard.conf file

-logoSize 100
-logoDir "/Applications/Xboard/Textures/Logos"
-autoLogo true

and the logofiles labed as
fairymax.xpm, crafty.xpm, fruit.xpm ect...
which i modified in gimp and are size 100x50 pixels

opening up xboard (xaw or gtk) and the space is created for the logo but nothing renders and is empty.

when launching xboard in debug mode it puts out in the console
white pixel = 0xffffff, black pixel = 0x0

I checked the xboard.debug file but didn't see anything on that subject, all looks pretty normal

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
shuffleOpenings = 0
resolved -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1 at pixel size 14
  to -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1
resolved -adobe-helvetica-bold-r-normal--34-240-100-100-p-182-iso8859-1 at pixel size 34
  to -adobe-helvetica-bold-r-normal--34-240-100-100-p-182-iso8859-1
resolved -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1 at pixel size 14
  to -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1
Version: xboard 4.7.0 + fairymax ()
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") fairymax
204 >first : xboard
protover 2
shuffleOpenings = 0
378 <first &#58; tellics say     Fairy-Max 4.8R
379 <first &#58; tellics say     by H.G. Muller
379 <first &#58; tellics say Gothic Chess is protected by U.S. patent #6,481,716 by Ed Trice.
379 <first &#58; tellics say Falcon Chess is protected by U.S. patent #5,690,334 by George W. Duke
379 <first &#58; feature myname="Fairy-Max 4.8R"
379 >first &#58; accepted myname
379 <first &#58; feature memory=1
379 >first &#58; accepted memory
379 <first &#58; feature setboard=0 xedit=1 ping=1 done=0
379 >first &#58; accepted setboard
379 >first &#58; accepted xedit
379 >first &#58; accepted ping
379 >first &#58; accepted done
379 <first &#58; feature variants="normal,shatranj,makruk,cambodian,courier,knightmate,capablanca,gothic,falcon,cylinder,berolina,super,seirawan,spartan,great,fairy"
379 >first &#58; accepted variants
379 <first &#58; feature option="Resign -check 0"
379 >first &#58; accepted option
379 <first &#58; feature option="Resign Threshold -spin 800 200 1200"
379 >first &#58; accepted option
379 <first &#58; feature option="Ini File -file /Applications/Xboard/Engines/Fairymax/data/fmax.ini"
379 >first &#58; accepted option
379 <first &#58; feature option="Multi-PV Margin -spin 0 0 1000"
379 >first &#58; accepted option
379 <first &#58; feature option="Variant fairy selects -combo Spartan /// FIDE-Clobberers /// Clobberers-FIDE /// FIDE-Nutters /// Nutters-FIDE /// Clobberers-Nutters /// Nutters-Clobberers"
379 >first &#58; accepted option
379 <first &#58; feature option="Cambodian Makruk rules -check 0"
379 >first &#58; accepted option
379 <first &#58; feature option="Dummy Slider Example -slider 20 0 100"
379 >first &#58; accepted option
379 <first &#58; feature option="Dummy String Example -string happy birthday!"
379 >first &#58; accepted option
379 <first &#58; feature option="Dummy Path Example -path ."
379 >first &#58; accepted option
379 <first &#58; feature option="Clear Hash -button"
379 >first &#58; accepted option
379 <first &#58; feature done=1
379 >first &#58; accepted done
380 >first &#58; memory 68
380 >first &#58; new
random
380 >first &#58; level 40 1 0
381 >first &#58; post
381 >first &#58; hard
381 >first &#58; ping 1
457 <first &#58; pong 1
GameEnds&#40;28, xboard exit, 2&#41;
3505 >first &#58; result * &#123;xboard exit&#125;
3507 >first &#58; force
3507 >first &#58; ping 2
3507 >first &#58; quit

Is there some library needed to render logos? Or should I name the texture file as something else? The "tidy name" is the "nickname" in the Engine dialog, correct?

Engines in the xboard.conf are
"fairymax" -fcp "fairymax" -fd "."
"crafty" -fcp "crafty" -fd "."
"fruit" -fcp "fruit" -fd "." -fUCI
ect...

[hgm]

Since the switch to Cairo logos have to be PNG files. Cairo does not support XPM.

[JoshPettus]

DOH! That's right! Thanks Harm.
(never liked xpm anyway. )

May want to update your new feature page when you get a chance.

[hgm]

Well, the upside of XPM was that you could edit it with a normal text editor, rather than needing specialized image editors.

[JoshPettus]

Oh neat, never knew. I just opened one in text edit. I guess it's understandable if you know what you are doing. I think i'll still be sticking with gimp.

On a another note. It seems the GTK version adds a ridiculous amount of space for just 100 pixels horizontally, but then doesn't allow enough room for the board vertically no matter how you re-size it.

[hgm]

Actually the XPM images are even valid C programs! They can be incorporated without any modification in a C program (which is what XBoard did for the built-ins), and when they are compiled, they result in arrays of characters.

The large horizontal space you see could be the consequence of specifying a large board size. (Did you by any chance enter -size 100 in stead of -logoSize 100? Once you did that, it will remember it.) One of the yet unsolved problems of the GTK version is that it won't allow sizing to below the initial width of the clocks/menu bar. You can only enlarge the size compared to that. And such re-sizing will not be remembered, it still saves the initial size back into the settings file, no matter how much you resized. Resizing should still be considered as an experimental feature. (But as previous XBoard versions did not have it at all, we figured it should not delay the release.) So try to run again with -size -49 or -size 33, to see if the problem disappears.

As to the board being clipped at the bottom: Yes, this is a known problem in the GTK version. (It is just that there is currently no known fix...) I have that too:



Vertical sizing is sick in GTK anyway. To not limit how much the user can shrink the board, I initially pop it up with a 1x1 board, and then I request the size of the outer window, to see which 'margins' are needed for the clocks etc, and window frame. These margins are then later subtracted from the new size of the outer window, (if the user resized), to know how large the board can be. And they are added to the desired start board size to resize the outer window under program control at startup. (You can see this happening.)

Problem is that the initial 1x1 popup did leave a 25-pixel wide empty space below the board, rather than producing a tight fit. So I had to assume that 25 pixels of the reported margin were in fact unnecessary, and subtracted those. But for some reason that does not work with logos on; apparently then the initial popup left less unnecessary space below the board. Then Arun patched the code to use another type of window (a top-level window, with menu buttons on it to minimize), and then suddenly the initial popup produced a window that was 13 pixels too small, rather than 25 pixels too wide. So now I add 13 pixels to the vertical margin. Which again seems to fail by the same amount when logos are on.

Of course I could correct with another fudge factor when logos are on, but I have no idea if this could also depend on the size of the logo, for instance. Furthermore, it seems that other people don't see this sick behavior, and in a previous version already complained against me subtracting the 25 pixels (which would make the lowest 25 pixels of the board invisible for them).

All this is very sick, and almost certainly a GTK bug. I saw some very weird behavior in the secondary board window (observing two games at once on FICS), when I was resizing it. The board there is always drawn with the same square size as in the main window, so resizing there has no effect on the size of the board. But it has effect on its positioning! And an extremely weird effect: it seems to sort of center the board in the window, but then when I narrow it, it pushes it to the left edge of the window, (while there is still space on the right), and then turns a corner and starts moving down! This seems related; I might get the extra space because the initial 1x1 popup might try to shift the board to the left edge, and then turns a corner too, to cause extra height.

[JoshPettus]

Yup boardSize 49 seemed to fix the issue while still accounting for logos.
Shame about thoes missing 13 pixels. Hopefully someone with gtk experience knows of a workaround. Is this still an issue in gtk3?

Fortunately GTK is still labeled beta and xaw handles it alright. In Xaw it doesn't figure out a way to shrink the clocks and logos when you re-size it lower then 49 and starts cropping off the clocks, but that's alright.

Though there is an idea, can't cairo resize the logo's as well when resized lower then a say the 200 pixels need for both clocks? Though i guess it wont matter in GTK anyway which can't re-size lower then the starting horizontal which looks alright when boardsize is 49.

Actually what you describe with the second observation board is a little similar to how I noticed it handles in xaw yesterday. The board size of the second board is limited by the size of the first board no matter what the actual window size is. As you said in gtk, this was all wonky with part of the board not even rendering with out significant fiddling with the windows. I did like that xboard automatically popped up and observed the second board when observing bughouse. Will be a really nice feature.

[hgm]

Indeed, proper resizing would involve a lot more than just drawing the board with another square size. In Xaw it would have to change the size of all fonts (clock, coords, message), for example. This would solve the problem of clipping the clocks, and the height of the clock widgets would adpat automatically, as the font size determines it. That would also make it much harder to calculate the new square size, though: you would have to measure the clock height again based on the new font to know how much was left for the board.

The GTK version does not have any support for fonts at all, so it would not even be clear what to do. I figured this should be solved first, before even thinking of how to auto-size that area.

[pkappler]

Speaking of Xboard 4.7.0 and OSX, is there a pre-built binary I can download? I tried building from source, but OSX 10.8 doesn't include automake, autoconf, aclocal, etc.

[zullil]

Speaking of Xboard 4.7.0 and OSX, is there a pre-built binary I can download? I tried building from source, but OSX 10.8 doesn't include automake, autoconf, aclocal, etc.

Get what you need at MacPorts and then build from source.