Assigning to me.

mikhas, is there a signal or something I can use to know which side is playing?
I'm looking at miniature.cc but I can't find anything

Now the timers behavior depend on really fragile calculations of which color is
playing, which was fine for UI demos but is not enough in real games. For
instance, currently it is assumed that each time the confirmed button is
pressed, the side changes - which is not true for wrong moves.

What the frontend needs is to know for sure which side is playing: local or
remote. Thanks!

Taking. Will add active side signals but also forward the timer information.

Hi, I'm trying to understand how to operate with all the new code that has
landed. Let me explain in human language what OnlineBoard must do, please help
me to fill the gaps with the variables from the backend I must use. Thanks!

1. Game starts, user jumps from SeekGame to OnlineBoard. DONE

2. The header must show the data of the active game. Are the variables to use
activeGame.time - activeGame.increment a- activeGame.rating ?

4. The counters must show a variable too. For the beginning of the game could
also be activeGame.time although during the game the backend provides the
values of each timer in the FICS server. Which are these variables for local
and remote?

5. In order to start the correct timer, the frontend needs to know who is
white: local or remote. What is the variable bringing this value?

6. Whenever there is a turn change the corresponding timer will stop and update
to the value provided by the server, and the other times will start. What is
the signal marking the change of turn?

So mikhas, here you have the template to fill:  ;)

- Time of the active game:
- Increment of the active game:
- Rating of the active game:
- What color is local (or who is white):
- Server time for local:
- Server time for remote:

Thanks!

Fixed in commit 8f56e7100c57bf4cbe37128f56643563b4084ba0. 

I moved the timer handling into the backend, as there seem to be problems when
chaining up QML properties (property bindings are apparently not transitive).

Great! I played my first game with real time: nice!

There is a little detail: the time must start to run only after white and black
have moved once. Since we're syncing with the FICS server this is not grave,
but aesthetically needed. Do you want me to handle this in the frontend or do
you prefer to fine tune the backend?

(In reply to comment #6)
> Great! I played my first game with real time: nice!
> 
> There is a little detail: the time must start to run only after white and black
> have moved once. Since we're syncing with the FICS server this is not grave,
> but aesthetically needed. Do you want me to handle this in the frontend or do
> you prefer to fine tune the backend?

This is a FICS detail, meaning the engine must handle it, not the frontend.
Postponed for after 0.4 though.

(In reply to comment #7)
> (In reply to comment #6)
> > Great! I played my first game with real time: nice!
> > 
> > There is a little detail: the time must start to run only after white and black
> > have moved once. Since we're syncing with the FICS server this is not grave,
> > but aesthetically needed. Do you want me to handle this in the frontend or do
> > you prefer to fine tune the backend?
> 
> This is a FICS detail, meaning the engine must handle it, not the frontend.
> Postponed for after 0.4 though.

Well, if you add a bold comment that this needs to be handled by the FICS
engine blah blah then of course you can add the workaround in the QML UI, for
now.

Actually it's not that bad, and people that haven't played with FICS before
won't even notice. The rest might notice but at the end will have the exact
same time to play. Verifying this bug. I will open a new one for the specific
detail if it's something really evident or annoying over time.

A new enhance bug against the engine then, so that we don't forget about it?