Hi HGM fixed some bugs in the v4.4.x branch and we will do a 4.4.4 release soon. Feel free to test the latest git version in that branch and let us know if there are any issues... probably release date: coming Friday cheers ARUN
I am reporting the following patch in this list, because I think that it is
something
Tim will appreciate. We have been discussing settings files several times,
and Tim correctly pointed out how much milage WinBoard gets from the way
the settingsfile was implemented. Well, through a subtle change, we now can get
even more. (And XBoard now uses it too...)
The way an -ini or -settingsFile argument used to be treated in WinBoard
(4.2.7, 4.4.x)
was (in pseudo-code) as follows:
fullname = PATH(settingsFileName);
FILE *f = fopen(fullname);
if(f) {
ParseSettingsFile(f);
settingsFileName = fullname;
}
This now has been changed in master (the future 4.5.0) to:
fullname = PATH(settingsFileName);
FILE *f = fopen(fullname);
if(f) {
settingsFileName = fullname;
ParseSettingsFile(f);
}
This subtle change makes that the name of the settings file now can be
redefined
from within the settings file, by including another -ini or -settingsfile
(Continue reading)
Nice! I would say this fixes a subtle bug in the old code. The change is definitely an improvement.
I am reporting the following patch in this list, because I think that it is something
Tim will appreciate. We have been discussing settings files several times,
and Tim correctly pointed out how much milage WinBoard gets from the way
the settingsfile was implemented. Well, through a subtle change, we now can get
even more. (And XBoard now uses it too...)
The way an -ini or -settingsFile argument used to be treated in WinBoard (4.2.7, 4.4.x)
was (in pseudo-code) as follows:
fullname = PATH(settingsFileName);
FILE *f = fopen(fullname);
if(f) {
ParseSettingsFile(f);
settingsFileName = fullname;
}
This now has been changed in master (the future 4.5.0) to:
fullname = PATH(settingsFileName);
FILE *f = fopen(fullname);
if(f) {
settingsFileName = fullname;
ParseSettingsFile(f);
}
This subtle change makes that the name of the settings file now can be redefined
from within the settings file, by including another -ini or -settingsfile option in it.
With the old code settings files could be used recursively, but -ini option inside
them would in effect be treated as indirection settings files ( <at> file), because
the effect they had on changing the settingsFileName (where settings would be
saved later) would be undone by the later assignment of fullname to it.
So only the outermost ini file, as specified by command-line options or default,
would be effective for saving.
In the new method the last-encountered -settingsFile option will prevail as the
file used for saving (if it existed). This allows redirection of the settings file
from the default settings file (winboard.ini in WB). The nice thing about this is
that having such a redirecting -ini option in it, will protect the default settings file
from overwriting, when saving the settings. They will now go to the redirected file.
As a result, the redirecting -ini option will remain in the winboard.ini, rather than
disappear because of overwriting, so the saved settings will be sought in the
place they were saved on a restart.
This now makes the possibilities for configuring WinBoard even more versatile.
I just prepared a binary install for Chinese Xiangqi customers. They would like
-variant xiangqi to be the default, of course. In the old way this could only be done
by options in the command line for starting up WinBoard (e.g. in a shortcut,
directly including the option, or put it in an indirection file, and use <at> to access
that). If you would put -variant xiangqi in the winboard.ini, it would disappear the
first time they sved, as the variant is a volatile option.
But in the new way, I supply a small winboard.ini with the install, which redirects
saving by including -ini settings.ini at the end, and contains -variant xiangqi.
So in effect this mechanism allows redefinition of the default values for volatile
options, by setting those before the redirection with the -ini option. But the
reverse is possible as well: you can effectively turn options that are saved
with the settings into volatile options. For that you have to include them
in the winboard.ini file AFTER the redirecting option. The processing of the
options in the files still takes place in the recursive manner, so even if another
setting was sved for that option, its occurrence after reading the settings back
from the save file in the winboard.ini will reset their value, making the saving
ineffective.
This mechanism can also be used to solve the security problem on multi-user
Windows systems. By specifying a redirection with a variable name, like
-ini %APPDATA%\winboard.ini (the equivalent to the XBoard -ini ~/.xboardrc),
in the winboard.ini master settings file will cause every user to have his own
settings file. The user can again apply this mechanism recursively, so that
from his own settingsfile in %APPDATA%
(= C:\Documents and Settings\{username}\Application Data\)
he can again redirect to another file for saving, and use his private winboard.ini
for redefining volatle or persistent options to any fixed setting he desires!
Hi I just uploaded new tar-balls for the developer releases for all 3 git branches... would be great if you could test the v4.4.4.20100806 one, since that should become the next official version. Let us know if you find any bugs, but please also let us know if everything worked fine. The plan is to do the release after a week of testing with the tar-ball. If I find some time tomorrow I'll create/update the openSUSE versions (rpm-packes, don't know how to create debian on the openSUSE build server although that should be possible too). cheers ARUN
There are some static translations of WinBoard around (i.e. requiring recompilation, and a separate executable for each language.) Mostly they are translations of WB 4.27 or 4.2.6. I looked around a bit, and found Spanish, Chinese and Russian translations. I did extract the translations from the Chinese and Spanish versions, by semi-automatically matching the translated winboard.rc with the one it was translated from. The Chinese version had all substitutions in the C source files clearly marked, after commenting out the English original, so I could easily extract that. The Spanish version made use of a language.h file with sections of English and Spanish strings in string variables, and I could easily correlate these by sorting on the variable name. I have not looked at the Russian translation yet, because I seem to vaguely remember there exists a more recent one. So this game me Chinese and Spanish translations in the form of a set of English strings and the corresponding translated string, of earlier WB versions. Basically, the translations are available as an editor script, or something that can be automatically converted into an editor script. Now some strings have been changed (by altering tabbing characters and accelerator keystrokes listed in the menu items, for instance), and there are many new strings as well. I extracted these from the sources of the master branch. For backend.c this was easy, as they were already marked with the gettext macro _(). The WB front-end files had no such markings yet, but the only file with really many strings is winboard.c, and it was reasonably easy to discriminate against strings intended for the debug file (which we do not translate) by first deleting all lines containing the word debugFP. Some front-end files, like wgamelist.c or wsettings.c, contained only 2 or 3 strings, which could easily be extracted by hand ith a text editor. This finally resulted in a collection of all (?) strings in the current version we would like to be translated. It was quite easy to then use the existing translations as edit script to conver the list of current strings into a translation script, which already specifies translations for those strings that still exist unmodified in the current version. Slightly altered strings, for which the translation was still valid could be copied into it by hand (which, admittedly, was a bit of a pain). The new strings of course require a new translator; for the Chinese version someone volunteered for this, so that is now complete. The Spanish translation for current WB is still only partial. It was also trival to use the list of translatable strings as an edit script to mark all strings in the WB front-end files (other than winboard.rc) with the GNU gettext macro _(). I applied the (complete) Chinese translation edit script to backend.c and all WB front-end files, (which was a pain), to generate a Chinese version. (Due to character-set differences this only seems to work if it is actually compiled on a Chinese PC, but it does work.) But of course we do not want to have separate executables for every language. So I consider this Chinese translation a one-time effort, although the result is quite nice. To avoid this cumbersome process in the future, I went through the one-time pain of making a list of all dialog items used in each dialog (as defined in the winboard.rc file). I had to define some 50 new item numbers, for the cases that were not unique before. But after that, there now is a list (as 2D array) that tells WB which dialog contains which items. I then made a small routine to loop through this list for a given dialog, read out the current (=English) text associated with that item, look up a translation, and set the item to that translated string. That makes the translation a fully dynamic (= run-time) event. As I don't kow how to use gettext, I provideded my own routine to be called wherever the _() macro is sitting, to translate the string. This was all very straightforward (using stupid, but simple algorthms like linear search...). So I have a WB version now that can read a translation script from a file (controlled by the /language=FILENAME option), and then makes all substitutions specified by the translation script in menus, dialogs,window titles and printed strings. So the problem is now reduced to providng the translation scripts. This still only works for lnguages that use the Roman character sets, as I do not mess with fonts yet during run time. (I would not really know how to do that...)
A more or less complete Spanish translation of WinBoard 4.5.pre0 is now available from http://hgm.nubati.net/winbo_int.zip . To start upin Spanish,use the command-line winboard /language=español The setting of the language option is remembered in the settings file, so next time you start up WinBoard even the startup dialog will appear in Spanish. Testers, please test!
The internationalized version of WinBoard that is now at http://hgm.nubati.net/winbo_int.zip now also has a (still imperfectly implemented) feature to switch language interactively. If language files (*.lng) are found in the WinBoard folder, their name (stripped of the .lng extension) will be appended to the Help menu, together with an item 'English'. (So after unpacking the download at the given link, you should see menu items English and Español.) Before continuing on this track, I would like to have some feedback, to determine if this is really what we want,or if it would be best to have people only select language through command-line options (which, after the first time, will be safely hidden in the ini file). Perhaps using the OS default language (if we can figure it out, and if it is available) when no such option is given. The problem is that this is a rather awkward patch, because I implemented the translations by reading out the items, translating them, and putting the translated strings back. This is fne for the transient dialogs, which always start their life as specified in the resource file, i.e. in English. But it is a bit of a disaster in permanent dialogs such as Engine Output, Game List and such, which are never closed, just hidden. There, once translated, the original texts are gone, and there is no way to get them back, or re-translate in a different way. Same with the menus, wich are also permanent features. So it would be necessary to give all the permanent dialogs special treatment, remembering their English texts, and retranslating it on every language switch. (For the menus I already did that.)
It seems when someone tries to install XBoard from source on a 64-bit system, the 'make' process results in lots of warnings (args.h, selfile.c, draw.c) of a type that indeed looks quite lethal: "cast from pointer to integer of different size". I guess the current XBoard code is not suitable for compiling as 64-bit application. But apparently we fail to tell the compiler that in our Makefile. The quick fix would be to include such a flag. (Does anyone know what it is?) In the longer run we sould have to clean up the code with respect to pointer <-> int conversions. I cannot test anything of this, as I have no 64-bit systems.
RSS Feed3 | |
|---|---|
1 | |
12 | |
5 | |
6 | |
4 | |
6 | |
8 | |
8 | |
4 | |
6 | |
4 | |
1 | |
40 | |
27 | |
55 | |
107 | |
41 | |
28 | |
34 | |
16 | |
8 | |
4 | |
91 | |
23 | |
48 | |
11 | |
22 | |
7 | |
14 | |
15 | |
17 | |
7 | |
12 | |
8 | |
7 | |
1 | |
6 | |
5 | |
20 | |
14 | |
14 | |
48 | |
72 | |
63 | |
49 | |
118 | |
37 | |
13 | |
13 | |
2 | |
1 | |
5 | |
5 | |
1 | |
1 | |
4 | |
2 | |
1 | |
9 | |
1 | |
27 | |
15 | |
4 | |
6 |
