Don't freeze UI when initing games

[GoogleCodeExporter]

When pychess creates bitboards very first time, it takes time.
Adding a little dialog message with a process bar to inform the user, like
on fics connect, would be nice.

Original issue reported on code.google.com by gbtami on 22 Oct 2007 at 9:00

[GoogleCodeExporter]

Indeed. Currently the UI freezes when you start the first game.
I think Stauton should have a loading animation where the board is going to 
appear.
This would be used every time a new tab is created, and would also wait for 
engines
to init.

Original comment by lobais on 22 Oct 2007 at 11:12

• Changed title: Don't freeze UI when initing games
• Added labels: Milestone-Stauton, Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

A cool animation would be one of a chessboard being set up. It would be based on
BoardView and with the API of a progressbar.
Underneath it we could have progressbars for each engine.

Original comment by lobais on 22 Oct 2007 at 9:11

[GoogleCodeExporter]

I've made a preliminary widget derived from BoardView to animate the chessboard 
being
set up, as lobais suggested, and its working fine so far. However I cannot find 
the
function which gets called when a new game is about to start, I'll appreciate if
someone could point me in the right direction

Original comment by tat...@gmail.com on 31 Dec 2007 at 10:03

[GoogleCodeExporter]

Hey that sounds great!
To know when the game has finished setup, you can listen to 
inoest.handler.connect("game_started").
But knowing when we start setting up the game, is not really doable yet, as we
currently block until finish.

I have some code, I've tested, bringing the setting up to a background thread, 
using
GtkWorker, and it works quite good. Only problem is the subprocess.Popen in 
threads
thing..
I'll look a little further into it in 2008. Then after 0.8 final we can start 
merge
the changes.

Happy new year to you all!

Original comment by lobais on 31 Dec 2007 at 12:34

[GoogleCodeExporter]

While I understand the code I'll upload the widget a made plus a test file to 
see it
in action. The test file is "dummy.py", load it as you would with pychess:

  $ PYTHONPATH=lib/ python dummy.py 

And as you click on the "Boom!" button you'll see the board being set up, each 
click
on the button equal a .pulse(), you can also set how many pieces you wanna show 
per
pulse with .set_pulse_step(). I hope it is of any use :)

Happy new year ^^

Original comment by tat...@gmail.com on 31 Dec 2007 at 9:38

Attachments:

• boardprogress.tgz

[GoogleCodeExporter]

It works excellent.

However I think it would be nice if you could make it use animation. It is 
actually
not very hard with the current API.
When you do "self.model.boards[-1][Cord(i)] = self.full_board[Cord(i)]" you 
need to
first set the x and y attributes of self.full_board[Cord(i)] to somewhere 
outside the
board. Then instead of running redraw_canvas you should run start_animation.

I would also like you to make it use percent instead of pulse. Pulse is more of 
a
think to use, if you have an animation that can run forever.

Original comment by lobais on 1 Jan 2008 at 6:46

[GoogleCodeExporter]

I've attached the new version of the widgets, it uses animations and percent as 
you
suggested :).

If you wanna show the board in two pulse()'s you only have to set the pulse 
step to
0.5  and so on. I ran into a problem when trying to use a test file (the 
animation
thread got stuck or something like that).

So, I tested it by replacing the BoardView inside the BoardControl by an 
instance of
BoardProgress, and then I put some code into the button_release signal so each 
time I
clicked on the board it sends a pulse() to the BoardProgress.

Let me know what do you think.

Original comment by tat...@gmail.com on 2 Jan 2008 at 5:46

Attachments:

• BoardProgress.py

[GoogleCodeExporter]

The code looks super, taking into account that there is still no percent method 
;)

I've reworked the way PyChess starts games, so it now goes like this (from the 
view
of the BoardView):
1) ionest emits gmwidg_created.
   The BoardView shows no pieces, as model.status == WAITING_TO_START.

2) loading players and stuff has finished.
   GameModel emits game_started
   BoardView sets opacity of all pieces to 0 and run startAnimation for smooth view

While this make gamestarting much smoother, we still need progress monitoring, 
as
when you start 10 observing games at the same time, the board will show itself 
empty
for quite a long while, and users might think, that is has died.

So we now have most of the pieces. We just have to figure out how they fits.
I think that a good way would be to:
1) Add a game_starting signal to ionest.handler taking a percent value.
2) Make the ionest.forkfunc emit this signal (using its publish function).
3) Make BoardView listen to this signal and show the needed number of pieces.
This approach would deprecate the need of a BoardProgress module, which I'm not 
sure
how to fit in anyways. Of cource it would help to add further clutter in the 
already
very large BoardView module, but after Philidor this module would in anyway 
have to
be split up.

Original comment by lobais on 4 Jan 2008 at 11:24

• Added labels: Milestone-Release0.8
• Removed labels: Milestone-Stauton

[GoogleCodeExporter]

Original comment by lobais on 25 Apr 2008 at 3:50

• Changed state: Fixed