Re: [Bug-XBoard] Infinite recursion
Den 11-04-2012 12:06, h.g. muller skrev: However if start xboard in my normal Danish locale the error error does not come up, and the engine setting menu item are enabled. If I click on Engine #1 settings, xboard will crash. ... But the point is that the behavoir depends on the locale in a way it shouldn't. I guess the problem is that XBoard (as described in the protocol specs) triggers on receiving a message containing No such file from the engine process, and that the engine probably sent a translated version of that message. That is a bit hard to fix. We could translate the system standard error messages it compares to in backend.c. But that is tricky; they really would have to be translated to the exact messages that the system in that locale would produce. We could of course let XBoard request the messages by error number in its own locale, and use those in the comparison. But also that will not always do what we need, because you could be running the engine on a machine with a different locale as wher XBoard is running. If Xboard is dependent on untranslated error messages from libc, it should run the engines in the C locale. It can be done by calling putenv(LANGUAGE=C) in the child proces before the exec() call. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Latest developments
Den 03-04-2012 22:51, h.g. muller skrev: BTW. I cannot compile the git master branch right now: [...] This is weird. Especially since the above error messages seem completely non-sensical. When I print backend.c from the current master branch in the savannah repository, There is no N_ macro anywhere near that line number. (It is in HandleMachineMove, though): Sorry! I had some local changes in the code, that I was not aware of. Problem is solved by using the right code. I am glad the clock bug seems to have gone away. I really could not find anything wrong remaining. During rewriting the file browser in my 'refactor' branch, I stumbled on a another problem, and I am not sure if v4.6.x is currently free from that. I got very erratic behavior as to which became the active window after pop-up or pop-down of dialogs. I remember I had problems with that before, but I thought they went away after I popped up file-browse and error-popup shells as children of the dialog that had focus, rather than as children from the main window. This, however, seemed no longer sufficient when I used GenericPopUp to generate the file-browse dialog: When I invokes it from the Browse button of a dialog (say Match Options), the first time it popped up on top (as it should). But after closing it, focus revert to the main board, rather than the Match Options dialog, although I created it as a child of the Match Options shell. And even worse, if I invoked it again from the Match Options dialog after that, it would consistenly pop up in the background (often completely invisible), while the Match Options dialog would retain focus and stay on top. This always happened after the main window had obtained focus once. No amount of XtSetKeyBoardFocus, XSetFocus, or even XRaiseWindow could alter that pattern. After some Googling, I found that it is a known problem that XRaiseWindow does not work on Gnome. Presumably the Xaw routines to create and popup windows suffer from that as well. It seems to have something to do that XRaiseWindows cannot be used to raise windows of another application, and that Xaw apparently does not tell the window manager to which application the windows belong, so that it assumes they are from different applications. I dug up some code that seems to achieve the raising by sending a _NET_ACTIVE_WINDOW message to the root window. To get my file-browser rewrite work aceptably, this was essential. I wonder if it would be needed to port this to 4.6.1. I have no problem with wrong windows having focus. Never happened for me. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] The clock stops if the board window is moved with stickyWindows on
Den 29-03-2012 23:41, h.g. muller skrev: While I am able to stop the clock occasionally by moving the board, it doesn't happen often. It is much easier to reproduce by iconifying/ deiconifying the board window. I have not been able to reproduce this (since I fixed the earlier bug of not clearing the pending timeout when it occurred). What exactly are the conditions under which you observe this? (which board size, which windows open, which mode). I tried in two-machines mode, with the Move list open, clicking on the taskbar to iconify. (Other windows have their own icon, and don't react. Only the Move List is enslaved to the main window.) I also cannot find anything suspect in the code. If I cannot reproduce it, the only hope to debug it is if Byrial trie it himself. A good method would be to put a printf at every place where there is an XtAppAddTimeOut or XtRemoveTimeOut call, printing the timer XID, and one in the callback routine to see if the event actually occurs (and for which timer XID). This is how I found the previous bug in this area. Just try until the clock stops, and then look if there was a clock timeout pending which simply never occurred (which would be an X11 bug), or if the timeout is erroneously removed by some other event. I cannot reproduce this any longer after I have upgraded to Ubuntu 12.04. It might have been caused by a faulty installation. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Latest developments
Den 30-03-2012 20:30, h.g. muller skrev: OK, I pushed everything to Savannah v4.6.x now, including a news page for 4.6.1. Unfortunately there is one new translatable string, so I guess we will have to go through the procedure of pot update and developer release, and allow the translators to hand in their po files. Yes, let's have a developer release with an updated pot file, and then 4.6.1. BTW. I cannot compile the git master branch right now: $ LANG=C make backend.o CC backend.o backend.c: In function 'HandleMachineMove': backend.c:7964:82: error: macro N_ passed 7 arguments, but takes just 1 backend.c:7963:40: error: 'N_' undeclared (first use in this function) backend.c:7963:40: note: each undeclared identifier is reported only once for each function it appears in backend.c:7964:83: error: expected ')' before ';' token backend.c:7970:2: error: expected ';' before '}' token ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] The clock stops if the board window is moved with stickyWindows on
Den 17-03-2012 14:31, Byrial Jensen skrev: Note that I got the coredump while connected to FICS, and I that now can only reproduce the clock-stop-while-moving-board on FICS. I cannot any longer get the clock to stop while playing an engine. Does ICS mode use any timers, which engine mode doesn't? I did some more testing with the current master branch code. I have been able to stop the clock now while playing an engine, so it is not an ICS mode only thing. While I am able to stop the clock occasionally by moving the board, it doesn't happen often. It is much easier to reproduce by iconifying/ deiconifying the board window. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated
Den 28-12-2011 10:05, h.g. muller skrev: It is simple for UTF-8, but some users use other encodings. Do you know them all? I would worry about that only when we actually did have translations that used other encodings. So far we only provide UTF8 po files. Excuse me, but for one it would be silly to code for the current po files only as new ones could appear at anytime. And secondly it doesn't matter at all how the po-files are encoded. The texts are recoded by the gettext() functions to the encoding currently used by the user. The user's encoding is determined by the current locale which again is selected based on environment variables. To see what encoding is currently used call the function nl_langinfo() with the argument LC_CTYPE. - Byrial ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated
Den 28-12-2011 10:59, Byrial Jensen skrev: Den 28-12-2011 10:05, h.g. muller skrev: It is simple for UTF-8, but some users use other encodings. Do you know them all? I would worry about that only when we actually did have translations that used other encodings. So far we only provide UTF8 po files. Excuse me, but for one it would be silly to code for the current po files only as new ones could appear at anytime. And secondly it doesn't matter at all how the po-files are encoded. The texts are recoded by the gettext() functions to the encoding currently used by the user. The user's encoding is determined by the current locale which again is selected based on environment variables. To see what encoding is currently used call the function nl_langinfo() with the argument LC_CTYPE. By the way if you wish to try xboard with other encodings than UTF-8 you could try this command to make and use a latin-1 locale for German: $ sudo localedef -i de_DE -f ISO-8859-1 de_DE.iso88591 $ LANG=de_DE.iso88591 xboard ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated
Den 28-12-2011 19:44, h.g. muller wrote: A possible solution might be to create the buttons first without width speficication, then messaure if they are too wide and make the widest buttons narrower. OK, this is feasible (and better). I pushed the patch again to hgm.nubati.net. Tested the new patch. It solves both of my 2 concerns about patch #1. Just take out the if(tinyLayout) block from CreateMenuBar(), make the corresponding change in the documentation for tinyLayout in xboard.texi and push it, and this bug report can be closed. - Byrial ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated
Sounds like an idea. However to increasingly shorten translated text you still need to use functions which first became a part in standard C in C99. I just took a look at xboard in German. You're right the wide menu. But in -size tiny there is also another problem: You cannot see the seconds on the clock for Schwarz (Black). Den 27-12-2011 16:06, h.g. muller wrote: I see 3 ways to fix that: 1) Extract the first character from the localized name using mbtowc(). (mbtowc stands for Multi Byte char TO Wide Char). It is easy to do, but the method may not be available for all as mbtowc() is a C99 function. 2) Extract the first character from the localized name using some library for handling multibyte chars. That could be a fallback solution if 1) fails, but means that the library have to be installed or distributed together with xboard. 3) Let the translators translate all the 1 letter abbreviations. Requires no extra configuration, and let the translators choose something else than the first letter if that is more appropriate for their language, so this is probably the best solution, I think. What do you think? Actually I remember making patch where the number of characters shown for each item was dependent on the board width in pixels, and could be different from just 1 or all. I still have to look into itwhythis is notin the master branch now (could beit is a WinBoard-only patch, could also be that it is in the aliennew branch). The current 'tiny-layout' scheme does not work satifactorily anymore: 1) Now we reorganized the menus, the main menu bar has more items, and is wider 2) Translation can make the meu bar arbitrary wide (e.g. try German on -size middling) 3) It does not take the number of board files into account; in xiangqi, gothic or courier the same -size would allow a ider menu bar 4) (I have never sen this, but I think it must be:) the font size is not taken into account, while the -messageFont is also used for the menu bar, AFAIK. So the current scheme is a total mess. I would prefer to replace it by something that takes everything into account. E.g. calculate the width of the menu bar in pixels, taking into account the font used to render it, and then clip the texts to an increasingly shorter number of characters until it is no longer larger than the board. This should be redone whenever the window width changes. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated
Den 28-12-2011 00:22, h.g. muller skrev: Yes, as said before in this thread you have to use the C99 function mbtowc() or some library dedicated to handle multibyte char strings. Well, I admit had not thought of that, but this is completely trivial to code even without using any libraries.The high bits of UTF8 immediately tell you the grouping pattern. (IIRC any byte that starts with10 binary is a continuation byte, all others are start bytes.) It is simple for UTF-8, but some users use other encodings. Do you know them all? ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34202] xboard has a 20-second startup delay running with Ubuntu 11.04
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: http://savannah.gnu.org/bugs/?34202 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34202] xboard has a 20-second startup delay running with Ubuntu 11.04
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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34202 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #34990] Use of Mono mode once permanently swictces to bitmap pieces
Den 22-12-2011 10:41, h.g. muller skrev: You are right about that. However when I tried I got a segfault! Oh yes, now I remember that occurred to me too. The patch that fixed the animation masks on swithing back to color mode fixes that too. Fine, but where is the patch? ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34202] xboard has a 20-second startup delay running with Ubuntu 11.04
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 xboard from start to exit. It was real time because presumably most of the time is spent by the X server. All times was about 3.2 seconds until this patch: commit 30583dd0f88cef9b1281f2ce5fa06651bf6d4bb6 Author: Tim Mann t...@tim-mann.org Date: Mon May 30 13:21:06 2011 -0700 Add a final wildcard default for fonts. This gives XCreateFontSet more freedom and lets it find fonts for some obscure charsets where fixed-bold or fixed-medium etc. may not have one. That increased the time to 3.8 seconds if configured with NLS enabled. It may possibly cause a much worse increase in start up time if you are short on RAM and the computer have to use swap memory. The time stayed at 3.8 s until this patch: commit 2bc700b32c6058a3e8f9c3a70d842c525cf0a6e3 Author: H.G. Muller h.g.mul...@hccnet.nl Date: Mon Nov 28 11:56:18 2011 +0100 Refrain from making unnecessary resize X request The window resizing code in InitDrawingSizes is suppressed when no change is needed. Similarly, changing piece bitmaps is suppressed when we stay in the same variant (and InitDrawingSizes is called e.g. because of chaging lineGap through the Board dialog). It reduced the start up time to 2.3 seconds with NLS enabled and and 1.7 s without NLS. So my advice at the moment is: Try the newest version from git or the latest test tar ball (ftp://alpha.gnu.org/gnu/xboard/xboard-4.6.0.20111203.tar.gz), configure it without NLS (the command is ./configure --disable-nls) and see if this solves the problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34202 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #34990] Use of Mono mode once permanently swictces to bitmap pieces
Den 21-12-2011 22:33, h.g. muller skrev: The only way to revert this is to quit xboard and manually edit .xboardrc to remove the automatically inserted -bitmapDirectory option. This is not true: the bitmapDirectory can be specified from the View-Board menu dialog as well. You are right about that. However when I tried I got a segfault! A string constant (DEF_BITMAP_DIR) is assigned to appData.bitmapDirectory when you change to monoMode if it was NULL. So when I try to change bitmap directory later DEF_BITMAP_DIR is attempted free()'ed, and xboard crashes. Add a strdup() at xboard.c:1946. Switching to modo-mode does force it to a default value when it was not yet set, because you mut ue bitmap pieces in mono-mode, and they are not built in. But it is not forbidden to use bitmap pieces in color mode, so there is no reason to force the bitmapDirectory to empty when switching off mono-mode. The user will have to indicate explicitly he wants that, by clearing the bitmapDirectory field in the dialog together with unticking mono-mode. You could argue that a value is forced in, should be automatically removed again when it is no more needed. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34991] Load engine doesn't work in localized xboard
Follow-up Comment #5, bug #34991 (project xboard): You cannot just remove gettext calls from the combo code. They are also used for combo boxes where translation is needed (search mode in Load options, the sound names in sounds options, load as first or second engine in Load engine) I see 3 ways to fix this: 1) Create arrays of the translated messages for these combo boxes in advance, 2) Have a flag in struct Option to indicate if gettext should be called (or reuse one of the variables otherwise not used for ComboBox options for this) 3) Have two Combobox values in enum Control: ComboBox and ComboBoxWithNoTranslation ___ Reply to this item at: http://savannah.gnu.org/bugs/?34991 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #35000] Temporary previous position (. key, former Ctrl) conflicts with start of Type a move
Follow-up Comment #4, bug #35000 (project xboard): I attach a diff file for a solution to the repeat key problem which works for me by testing if a release event is triggered by a repeating key. (file #24575) ___ Additional Item Attachment: File name: tempback.diff Size:2 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?35000 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #35000] Temporary previous position (. key, former Ctrl) conflicts with start of Type a move
Follow-up Comment #3, bug #35000 (project xboard): I have tested the git code. I doesn't work too well. Ctrl + . does go to the previus position when pressed, and back again when released. However if you don't release the . key immediately, the key will start to repeat, and the board will thus start to repeat going back and forward between the two positions. So you cannot hold the previous position for more than short moment (how long of course depending on your keyboard configuration). For this to work properly you have to use non-repeating keys. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35000 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34991] Load engine doesn't work in localized xboard
Follow-up Comment #2, bug #34991 (project xboard): Yes, all browse buttons (in the Load Engine window and else where) seem now to work and to have a size fitting for the text. The Combo box still contains the po file header as the the first item. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34991 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #35000] Temporary previous position (. key, former Ctrl) conflicts with start of Type a move
Follow-up Comment #1, bug #35000 (project xboard): There is a similar problem with the - key. It will both iconify xboard and pop up a Type a move window with a -. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35000 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34990] Use of Mono mode once permanently swictces to bitmap pieces
Follow-up Comment #1, bug #34990 (project xboard): Please read bitmap where I wrote bitmark. It was a typo. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34990 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] [bug #34972] Several issues regarding lokalization
On 03-12-2011 19:02, h.g.mul...@hccnet.nl wrote: BTW, WinBoard did also not have a Danish translation yet. So if you have a taste for it now, there is no need to stop, as the winboard/language.txt template file of the source distro is still ready and waiting to be converted to a winboard/language/dansk.lng. ;-) Anyway, thanks for the good work and the feedback! H.G. Well, if you are able to use or convert the po-file, you are welcome. If would be difficult for me to make a winboard file, as I don't use MSWindows, and thus cannot even test if I messed up the file by some accident. And if I should make a translation for Winboard, I wouldn't even know what charset to use. UTF-8 or ISO-8859-1 or some non-standard MS charset which I don't know? I think a much more sound approach would be to also make Winboard use gettext. The po file format is much easier to work with for a translator as we can use special po file editor programs that make sure that only the translation and translation comments can edited, while the original text and the file structure cannot be accidentially damaged. These programs normally also have translation memory used to propose translations based on similar texts in the same or other po files, good search and replace functions etc. - Byrial ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34972] Several issues regarding lokalization
Follow-up Comment #3, bug #34972 (project xboard): Thanks, that was fast. PGN files should not be changed. The PGN specification does not allow for that, and it would not be portable. But I think the move notation should be changed in the Move list window and other places where a move is shown to the user. And it should also be changed for typing in the Type a move window. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34972 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] [bug #34972] Several issues regarding lokalization
Follow-up Comment #4, bug #34972 (project xboard): Just tried the new git version. Remember to update po/POTFILES.in with all source files which strings marked for translation. ___ Reply to this item at: http://savannah.gnu.org/bugs/?34972 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
