Refactored master

[h.g.muller]

I was finally satisfied with my reorganization / rewrite of the XBoard
front-end code,
and rebased the contents of my 'refactor' branch onto Savannah master.
I think it would be a good idea to do a deveoper release of this new code,
because changes were very drastic, and testing would be welcome.

When I wanted to prepare the release, I ran into some problems, though:
the "make distcheck" aborts with an error. Apparently it does not like that
the GhostView filebrowser code was removed from the project, athough
I did delete the mentioning of those fimes from the Makefile.am, and had
no problems compiling XBoard itself. I did have problems regenerating
the pot/po files, though, and at some point internationalization ceased
working completely for me (the line spacing in menus and dialogs also
switching back to a smaller value).

So it seems the autoconf process is somehow broken, and I have no
idea how to fix it. Perhaps Arun can have a look at it? It must be something
very simple, related to addition or removal of source files.

[h.g.muller]

Oh, I figured it out (partly). There apparently is a po/POTFILES.in that
had to be updated, and it still contained references to the filebrowser/*
source files. I fixed that now, and "make distcheck" works. I also did
a "make update-po" in the po directory, and pushed the po/pot files to
Savannah master.

I can unpack the tar ball and build XBoard from it. After

./configure
make
sudo make install

it runs fine, except that it does not seem to be internationalized. It has
the low buttons and line spacing, and "LANG=de_DE.utf8 xboard" does
not produce any translations. I have been in such a state before, and
it is probably just due to something I am doing wrong. I don't know what
brought me out of it last time (it was not a conscious action).

[Byrial Jensen]

Den 10-04-2012 14:52, h.g. muller skrev:

> Oh, I figured it out (partly). There apparently is a po/POTFILES.in that
> had to be updated, and it still contained references to the filebrowser/*
> source files. I fixed that now, and "make distcheck" works. I also did
> a "make update-po" in the po directory, and pushed the po/pot files to
> Savannah master.
>
> I can unpack the tar ball and build XBoard from it. After
>
> ./configure
> make
> sudo make install
>
> it runs fine, except that it does not seem to be internationalized. It
> has
> the low buttons and line spacing, and "LANG=de_DE.utf8 xboard" does
> not produce any translations. I have been in such a state before, and
> it is probably just due to something I am doing wrong. I don't know what
> brought me out of it last time (it was not a conscious action).

You don't see any translations because the program runs in the C locale.
You need to call setlocale(LC_ALL, "") to change to the locale defined
by environment variables.

[Byrial Jensen]

Den 10-04-2012 16:44, Byrial Jensen skrev:

> Den 10-04-2012 14:52, h.g. muller skrev:
>> Oh, I figured it out (partly). There apparently is a po/POTFILES.in that
>> had to be updated, and it still contained references to the
>> filebrowser/*
>> source files. I fixed that now, and "make distcheck" works. I also did
>> a "make update-po" in the po directory, and pushed the po/pot files to
>> Savannah master.
>>
>> I can unpack the tar ball and build XBoard from it. After
>>
>> ./configure
>> make
>> sudo make install
>>
>> it runs fine, except that it does not seem to be internationalized.
>> It has
>> the low buttons and line spacing, and "LANG=de_DE.utf8 xboard" does
>> not produce any translations. I have been in such a state before, and
>> it is probably just due to something I am doing wrong. I don't know what
>> brought me out of it last time (it was not a conscious action).
>
> You don't see any translations because the program runs in the C
> locale. You need to call setlocale(LC_ALL, "") to change to the locale
> defined by environment variables.

I looked at it some more. It seems that the XT call
XtSetLanguageProc(NULL, NULL, NULL) also will set the locale, and that's
why Xboard used to work with NLS without calling setlocale().

However the locale must be set before the call to bindtextdomain(). In
the refactored master it comes later. That is reason it doesn't work there.

[h.g.muller]

> I looked at it some more. It seems that the XT call
> XtSetLanguageProc(NULL, NULL, NULL) also will set the locale, and that's
> why Xboard used to work with NLS without calling setlocale().
>
> However the locale must be set before the call to bindtextdomain(). In
> the refactored master it comes later. That is reason it doesn't work
> there.

OK, thanks, I would never have figured that out myself. This seems to
work. Strange thing is that by mistake I first put the XtSetLanguageProc
immediately behind the bindtextdomain, and that did work too. But not if
it was too far back. (I had moved it back to make it easier to remove all
X11 code completely, for a 'NoBoard' command-line interface to play
engines against each other, that could run on machines that do not support
X.)

Now that internationalization works, I could see that some label widgets
in the Engine Output window got a disastrous height, because they
specified an empty string (which apparently translates to a huge
multi-line thing). This was because they were only there to accomodate an
icon. (Perhaps this is a wrong way of doing it, because I believe that a
single label widget can accommodate both a text and an icon, and that the
text than automatically goes behind the icon, so in principle the
first&second and third&fourth label widget above the text memos in the
Engine-Output window could be combined. But that was not how the old code
did it, and might entail the risk of the text jumping back and forth if
the icon is missing.

Anyway, I fixed that too now, by giving the icon widgets a text of a
single space. (I guess I could have put an explicit test for emptiness
suppressing the translation in the code as well, but this was simpler.)

[Byrial Jensen]

Den 10-04-2012 20:43, h.g.muller@... skrev:
> Now that internationalization works, I could see that some label
> widgets in the Engine Output window got a disastrous height, because
> they specified an empty string (which apparently translates to a huge
> multi-line thing).

An empty string is "translated" to the header from the po file with
typically 12 text lines of info about the file.

>  Anyway, I fixed that too now, by giving the icon widgets a text of a
> single space. (I guess I could have put an explicit test for emptiness
> suppressing the translation in the code as well, but this was simpler.)

I would avoid calling gettext() with anything not intended to to translated.

[h.g.muller]

>I would avoid calling gettext() with anything not intended to to translated.

Yes, well, this is a bit difficult when the text is coming from a static
table that can contain some elements that need translation, and others that
don't. Passing a NULL pointer for the text is unfortunately already used as
a signal to omit the widget completely (this was needed for the tags popup
in case of cmail, I think: that had an optional extra message field). I
could of course test explicitly for an empty string, and suppress
translation if it occurs. Or, more generally, introduce a NO_GETTEXT flag
with Label Options as well. (Btw, I guess that for ComboBox options that
flag is nowhere used anymore, now the engine-select has been changed to
ListBoxes, the content of which is never translated.) But all those
solutions seemed a lot longer than adding the 4 bytes needed to turn empty
strings into spaces, just adding unnecessary complexity for no clear
benifit. Surely gettext must always be resistent to a missing translation.

[Byrial Jensen]

Den 11-04-2012 12:24, h.g. muller skrev:

 > Surely gettext must always be resistent to a missing translation.

Of course. The problem is if the text if unexpected translated.

[h.g.muller]

At 11:33 11-4-2012 +0200, Byrial Jensen wrote:
>Of course. The problem is if the text if unexpected translated.

OK, I see. But for now I am prepared to take my chances on it that a text
of a single space will not be translated to a multi-line message.
(In WinBoard I actually translate a string of 6 spaces to a copyright
notice for the translation, in the About box :-D )