Re: XBoard 4.7.3: Full board textures + maximize window

Hello,


On 17.09.2014 21:38, H.G. Muller wrote:
>>> The problem seems to be that you want
>>> one and the same texture bitmap to work over a very wide range of board
>>> sizes.
>> well, yes, of course.
> XBoard was just never designed to do that. Before we switched to Cairo
> plotting, every single board size needed a separate set of images for
> the pieces.

but we're no longer in the past :)


>> Say hello to non-integer factor image scaling, please.
> I tried that, and it looked very ugly on the textures, and in particular
> on the Xiangqi board.

I'm pretty sure it depends on the kind of texture.  And with SVG,
scaling should look sharp at any resolution anyway.


>   The problem is that the way you want it to work would wreck the
> behavior I would like to have for the version we distribute.

How so?

I don't think that's the case if you separate single-field and
full-board modes properly.  I still hope for that to come.


> The Xiangqi
> board that goes with the distro (preferably the ones we already have)
> should at least display at any standard board size, which means upto 129
> x 129, and in the old code that was not the case, as your initial
> screenshot showed.

The situation is better now than two days ago (and I would welcome a new
release with those patches soon) but I consider the fact it doesn't work
for other full board images rather sad.  I don't really see why XBoard
graphics quality should /not/ be as high as that of

  http://blog.hartwork.org/__images/setup_imitate_playok.svg

viewed in Firefox at any given zoom factor.  Maybe that's a goal for
XBoard in 2015.


> The similarity of the tiles can be further disguised by randomizing
> their orientation (although I am not sure XBoard does that. WinBoard
> doesn, though).

I can confirm that feature is missing in Xboard, yes.
It's a cool feature.  I would go further and allow/deny mirroring with
certain kinds of textures but that would need new switches for a human
to control... which I suppose you're not too much of a fan of.


>   You convinced me that there would be some merit in an option that
> forces contiguous cutting, achieved by scaling the texture to exactly
> the required size, for Escherian boards.

Cool.


>>   * It's still as broken for other_1800x2000.png .
>>
>>
>> To get it compiling, I needed to apply the gettext 0.18 patch from
>> https://savannah.gnu.org/bugs/index.php?39970 . It would be cool to have
>> that applied upstream: even Debian stable has gettext 0.18 by now.
>> Which distro and version of gettext are you running?
> I am running Ubuntu 10.04, which has gettext 0.17 and does not support
> higher versions.

If that's Ubuntu Desktop version, support for it ran out in May 2013.
What does a Ubuntu from 2010 have, that you don't find in 2014 with
other releases or distros of Linux?


> I don't really know much about Linux, and Arun Persaud does the gettext
> and autotools stuff, but this gettext problem seems very tough. The
> Debian patch would prevent me to compile it. It seems inconceivable that
> it would not be possible to have a version that would work on any
> gettext version from version 0.01 and up, as we only use the most basic
> features (the _(), N_() macros, and I think one other). This is
> confirmed by the fact that we never have to change anything in the
> actual C source. It is purely an autoconf problem, which drags a number
> of m4 macros from somewhere, which then aren't the version that some
> automatically generated Makefile then thinks it must insist on.

Frankly I believe you need to get off Ubuntu 10.04: (a) for your own
security (you have long run out of security updates, haven't you?) and
(b) for developing XBoard against stable or development dependencies,
not against old-stable (in Debian terminology).

Best,



Sebastian