[ggo-discussion] Re: gGo error/request

  • From: Peter Strempel <zotan@xxxxxx>
  • To: ggo-discussion@xxxxxxxxxxxxx
  • Date: Mon, 7 Apr 2003 09:24:40 +0200

On Sat, Apr 05, 2003 at 07:54:24PM +0300, Jarkko Lindblad wrote:

> I doubt that this is the same bug. When observing, the new moves have always
> appeared unless I've been using the move slider on the bottom of the window.
> If I've used it, sometimes the moves don't appear until I move the sider
> again. This is at least how I think it's been the couple of times I've
> witnessed this bug.

Yes, this is the same observation I have, however, if you moved the slider,
move it back to last move and all following moves are not displayed, then
minimize/maximize or resize the window, the formerly missing moves appear
again. I have no explanaition for this. I let gGo print the matrix, where
the board position for each move is stored, to the debug log, and saw that
all moves which are not displayed are in the matrix, so gGo gets the moves
from IGS and handles them. Also the update-the-board and display-the-move
functions are called. I fail to trigger and reproduce the bug, I had to wait
and run a debug-enabled version for some days to finally get it.

So far about observing only.


> > * The stones *are* painted on the board (!), but not displayed. You can
> 
> *No, they are not*. Refreshing the window in any way does NOT help. Only
> using the IGS refresh-command (I use the command line interface) works
> AFAIK. Resizing boards, moving other windows over it or whatever does not do
> anything. Also even after I use the refresh command, I must send my first
> move manually via the console as gGo does not recognize the blacks first
> move as the previous move and doesn't allow me to use the mouse to make a
> move.

I got this missing-first-black-move-in-own-games when I play white only once
at all (Windows), and I could fix it by minimizing/maximizing the window.
But that's been 3 months now maybe or more.

I have two versions of painting stones on the board: Repaint only the changed
parts or repaint the complete board. Latter can get really slow with 200
stones on the board. For normal moves, the first partial repaint is used,
but as sort of workaround I force a full repaint for move #1. Since the
release with this enabled, the problem seems to have been largely reduced,
from what people told me. Unfortunately, not completely vanished, so I
suppose it might be two independant things and I only fixed one.


> Small bug:
> I had two chat windows open in the chat area (?). After the game was
> finnished, my opponent thanked me, but his chat window did not pop over the
> other chat window.

That is partly intentional. If you have for example two chat subwindows
within the chatter desktop, with player A and B, the chat with A is focussed
and in front of the chat with B, then B sends you a chat, you keep the focus
of the window with A and the incoming chat from B will be displayed in the
background without moving the B-window to front and giving it focus. This
makes sense, as when you are chatting with some person and recive another
chat, it should not interrupt your ongoing chat session, and by no means
change the focus of the input field.

Consider the following:
Chat with perkele. Trying to type: "Some people think tweet sucks"
Right after typing "people" incoming chat from tweet: "Hi". Now focus
changes, tweet chat window is moved to front, and I continue typing "think
tweet sucks" <return>
That results in a problem. :*)

So the chat thing follows the basic policy: If you have one active chat, and
another chat (new or not) arrives, never change the input focus. If the
incoming chat is already in an existing window, dont move it to front. If
not, add a new window (that will be moved to front, happens when you create
new windows in that desktop pane, but the input focus won't change).

My first version of the chatter pane brought new chats always to front and
gave them the focus, that was very annoying.


> Bigger bug:
> I edited a game I just finnished, and in the edited version of a finnished
> (opponent resigned while in scoring) game the first black move was missing.
> This is kind of funny (I enjoy dark comedy) considering all the problems
> with the first move in gGo :)

Difficult to comment now. I just played with two accounts against myself,
gGo was white, black resigned in scoring, I opened the edit board in gGo, all
moves there.


 Peter

Other related posts: