headers
Arun Persaud | 2 Nov 2011 04:50
Favicon
Gravatar

developer release

Hi

I created a tar-ball for a developer release for 4.6.0 (same as master
at this point). Feel free to test it and send in those bug-reports :)

The GTK-version is also getting closer to being free of Xt calls. The
open build server provides packages for people to try these out. I think
I'll wait with a developer release until we got all the Xt statements
removed, unless people would like to see a developer release sooner...

cheers
	ARUN
Permalink | Reply | 0 comments |
headers
Translation Project Robot | 2 Nov 2011 17:24

New template for 'xboard' made available

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to <coordinator <at> translationproject.org>.)

A new POT file for textual domain 'xboard' has been made available
to the language teams for translation.  It is archived as:

    http://translationproject.org/POT-files/xboard-4.6.0.20111101.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

    ftp://alpha.gnu.org/gnu/xboard/xboard-4.6.0.20111101.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coordinator <at> translationproject.org>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Translation Project Robot | 3 Nov 2011 14:02

New Ukrainian PO file for 'xboard' (version 4.6.0.20111101)

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'xboard' has been submitted
by the Ukrainian team of translators.  The file is available at:

    http://translationproject.org/latest/xboard/uk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/xboard/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/xboard.html

If any question arises, please contact the translation coordinator.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arun Persaud | 5 Nov 2011 21:11
Favicon
Gravatar

bug reports

Hi

Just noticed that you can configure the bug-report web page on Savannah,
so I added some categories and item groups. Let me know if you can think
of other items that we should add or remove from there.

https://savannah.gnu.org/bugs/?func=additem&group=xboard

cheers
	ARUN
Permalink | Reply | 0 comments |
headers
h.g. muller | 7 Nov 2011 10:13
Picon

overruling engine features

I just added 3 new options on which I have somewhat mixed fealings;
their only purpose is basically to wreck proper (documented) operation
of XBoard. They can be needed, however to prrovide work-arounds for
non-compliant engines. In particular, that silly stuff with SIGINT causes
problems running Windows binaries of engines under wine: normally
SIGINT would kill the engine process, of course, and the protocol specs
recomend either to let the engine suppress sending of it by announcing
"feature sigint=0" at startup, or ignore SIGINT. Problem is that under
wine, engines that ignore sigint die anyway when they receive it. This
should be considered a wine bug, but it is very damaging to the usefulness
of XBoard, as most engines are only availableasWindows binaries.

So I needed an option for the user to turn off sigint even when the engine
does not do it, and I figured it was more versatile to then allow
the user to specify or overrule any engine feature. But of course
that offers the user a powerful tool to completely wreck the protocol.

This is especially dangerous since the option changing the feature
defaults is now implemented as persistent; perhaps we should configure
XBoard such that the /etc/xboard.conf resets the option to an empty
string _after_ having read the user settings file, so that people can
only enable the persistence by first removing that line from the master
settings file.
Permalink | Reply | 1 comment |
headers
h.g. muller | 8 Nov 2011 20:44
Picon

Re: gtk-branch

The gtk branch is really progressing at an enormous rate!
Most things seem to work now, good job! I toyed a bit with it,
to see what worked, and what notor only partially. I will report
my findings below, in the hope this will be helpful.

The crash on switching variant after moving is now indeed cured.

The button for Spartan Chess in the new-variant dialog has mysteriously
grown a lot larger than the buttons for the other variants.

The animation of explosions in Atomic chess are not centered on the
capture square, and the piece that captured seems to jump back to
the from square before the explosion. The latter could be a general fault
of animate moving, which still does work erratically.

The piece menu does pop up in Edit Position (with -pieceMenu true),
but none of the items in it does anything. Sweep-selection of pieces
(with -pieceMenu false) does not work at all; the first middle click
produces a white Pawn, the right click a black Elephant (?!), which
then stay unchanged when you move the mouse. It seems that the
mose-move event is not yet connected to the corresponding handler
in the back-end.

Promotion menu works perfectly; in Suicide a King button appears,
in Gothic even Archbishop and Chancellor buttons. All buttons work here.
Chosing promotion the piece from holdings, as in Superchess, also works.
Sweep promotions ('Almost always promote to Queen') donot work at all,
however. The Pawn does change into a Queen when you pickit up,
but even when you drag it directly to the promotion square the move is
refused. Dragging it backwards does not alter the Queen in aything else.
(Continue reading)

Permalink | Reply | 16 comments |
headers
John Cheetham | 9 Nov 2011 09:38
Picon
Favicon

Re: gtk-branch


> 
>T he gtk branch is really progressing at an enormous rate!
> Most things seem to work now, good job! I toyed a bit with it,
> to see what worked, and what notor only partially. I will report
> my findings below, in the hope this will be helpful.
>

Yes this is very useful. Hopefully we will get round to to looking at these.
 
> The crash on switching variant after moving is now indeed cured.
> 

The X code and X11 headers are gone now. We shouldn't get any more of the badpixmap type errors.

> The button for Spartan Chess in the new-variant dialog has mysteriously
> grown a lot larger than the buttons for the other variants.
> 

It doesn't seem to like the fact there are an odd number of buttons. Should be easy to fix.

> The animation of explosions in Atomic chess are not centered on the
> capture square, and the piece that captured seems to jump back to
> the from square before the explosion. The latter could be a general fault
> of animate moving, which still does work erratically.
> 

Yes the move animations don't work. Fixing it should fix some things like the piece jumping back to from square.

> The piece menu does pop up in Edit Position (with -pieceMenu true),
(Continue reading)

Permalink | Reply | 15 comments |
headers
h.g. muller | 9 Nov 2011 21:31
Picon

Re: gtk-branch

At 08:38 9-11-2011 +0000, John Cheetham wrote:
>The other problem is that every board square looks identical so we should 
>be able to improve it by introducing some random variations into the 
>positioning when they are loaded onto each square.

The old code did have this, except that it was not random; from where 
tocutthe squares from the bitmap has to be carefully calculated, to make 
sure the exact bitmap provided by the user  is reproduced when thebitmap 
was as wide and high as the board (i.e. N x squareSize). Otherwise a 
Xiangqi board would not properly reproduce.

You were right about the piece menu; one needs to use a new left click 
toselect an item. Thisis rather inconvenient, though. Although I consider 
the piece meu a deprecated feature, and always use sweep selection 
(-pieceMenu false), people that wat to stick to the piece menu would 
probably be outraged they cannot select with the right up-click anymore. 
This destroys whatever convenience the piece menu had, in particular  the 
clever trick of letting a simple static right-click drop a Pawn. Can't we 
arrange it such that upclicks also select menu items?

Note I have tied upa few of the loose ends I signaled the other day, and 
pushed them to hgm.nubati.net (gtk-xt branch). If they dont duplicate 
something John already did, they can be pushed to Savanah. They include:

*) fixing of circle size and position (Atomic-capture animation, 
-showTargetSquares option and seekgraph dots).
*) unstacking on animate dragging (crazyhouse drops and seirawan gatings).
*) connecting various mouse handlers. Detour under-promotion, sweep 
selection in Edit Position, PV walking, and seek-graph hovering now all work.
*) the visibility of the seek graph has been restored by making the
(Continue reading)

Permalink | Reply | 0 comments |
headers
h.g. muller | 10 Nov 2011 12:03
Picon

Re: gtk-branch

It tried to improve the coloring of the atomic-captures animation,
(changing the color of the blast wave from white -> yellow -> orange
  -> red -> grey during the explosion) because cairo offers an easy
way to adjust  the colors. But it seems there is something seriously
wrong also with this animation. When I set -animationSpeed 500,
so that I can see what happens exactly, it turns out that from the
15 sequences the animation is supposed to draw, only 5 or so show up.
And they show up seconds later that  they were actually drawn.
(I put a printf  in the code to see when they were drawn.)

So apparently something is seriously slowing down the drawing,
while there also seems to be a problem flushing the draw operations
to the display, which is probably also why -animateMoving is not
working properly. Because there seemed to be no explicit calls in
the code to flush what is drawn, I googled a bit on 'cairo' to see how this
is supposed to work, and it seems that drawing something generates
an expose event. But the expose-event handler draws an entirely new
board. This will probably overwriting the animated piece. (Animate dragging
will not suffer from this, because DrawDragPiece is called from the board
drawing routine.) And because the board is drawn without clipping, this
will be very slow.

I guess it will be essential to speed up the drawing process by letting
the expose-event handler set a clipping region on the exposed area,
or it would try to draw an entire board for every tiny dot you try to draw
in it. Accordingtomy google source this could be achieved by two cairo
calls (cairo_rectangle(cr, coords); clip(cr);), but the problem is that
the cairo context cr does not exist yet in the handler, but is created
and destroyed for every element of the board that is drawn. I wonder
if this is proper use of cairo; it would seem more logical to create it
(Continue reading)

Permalink | Reply | 13 comments |
headers
Michel Van den Bergh | 10 Nov 2011 12:08
Picon
Favicon

Re: gtk-branch

On 11/10/2011 12:03 PM, h.g. muller wrote:
> It would be better to draw in a buffer, and then copy
> the buffer to the display.

This is normally how drawing should be done. Otherwise you have
flicker.
Permalink | Reply | 12 comments |

Gmane