> Show available game

I only know a fairly inefficient way to do this: poll the list of open seeks
every x seconds … anyway, off-topic for *this* bug.

(In reply to comment #1)
> > Show available game
> 
> I only know a fairly inefficient way to do this: poll the list of open seeks
> every x seconds … anyway, off-topic for *this* bug.

"There is a bug for this"  ;) left for post 0.4: 

Bug 12354 - List of games: Show available game offers only

In other words, it is ok not to refresh in 0.4.

Added the signals with 91e338c3f6390af89a1da11aa28967c369b76a63 and also fixed
the UX for gameStarted. But when aborting seeks, the whole seeks list gets
messed up? No idea what's going on here. Back to Quim to check QML UI.

How can I reproduce the steps? Whoever I select in non-testing mode gets
automatically selected, and in testing-mode it also seems to be accepted
automatically.

I have logging with another guest in my laptop but I can't see how to avoid
that the game starts automatically.

(In reply to comment #4)
> How can I reproduce the steps? Whoever I select in non-testing mode gets
> automatically selected, and in testing-mode it also seems to be accepted
> automatically.
> 
> I have logging with another guest in my laptop but I can't see how to avoid
> that the game starts automatically.

"seek 999 999 m"

And then "unseek" (or "decline") after the Miniature client joined.

I don't know either why the spinner keeps being visible and running. Are you
sure the signals are emitted? How can I test this from SeekGame?

However, the the behavior I'd like to apply is:

- OnSeekCancelled: remove the highlighted element from the model altogether
(and show a dialog to the user so he knows what happened).

- OnGameStarted: clear the model, so whenever the user goes back there it is
empty and the list starts from scratch.

But I'm failing at doing so. This is the code I'm playing with:

                    Connections {
                        target: miniature
                        onSeekCancelled: {
                            model.remove(indexGameOffer)
                        }
                    }

                    MouseArea {
                        anchors.fill:  parent
                        property int indexGameOffer: -1
                        onClicked: {
                            indexGameOffer = index
                        ...

The problem seems to be the syntax of model.remove(), or the fact that this
method won't find anything to play in the advertising model. Trying to debug I
get this in the console:

qrc:/SeekGame.qml:288: TypeError: Result of expression 'model.remove'
[undefined] is not a function.


Another thing that needs to be fixed is: once a seek is answered there is
somewhere a setting set to false, making that no new seeks will appear after
cancelling. You can see this in the logs:

FICS: "GuestXGDB (++++) seeking 3 0 unrated blitz f ("play 167" to respond)" 
false 995248292 "" "" -1359719168 
FICS: "fics% " 
false 2935248048 "" "" -1359719248 
FICS: "GuestXQVP (++++) seeking 5 5 unrated blitz ("play 134" to respond)" 
false 995248292 "" "" -1359719168 
FICS: "fics% " 
false 2935248048 "" "" -1359719248 
FICS: "GuestMHLJ (++++) seeking 10 0 unrated blitz ("play 157" to respond)" 
false 995248292 "" "" -1359719168 

(((these seek offers don't show up in Miniature)))

Making the model.remove(indexGameOffer) work and setting that property back to
'true' with OnSeekCancelled should fix this bug, I believe.

(In reply to comment #7)
> Making the model.remove(indexGameOffer) work and setting that property back to
> 'true' with OnSeekCancelled should fix this bug, I believe.

Implement model.removeAll (after logout) and model.remove(index), as part of
the login bug fixes. Your bug again ;-)

Created an attachment (id=3410) [details]
SeekGame.qml version with console.logs

I still couldn't get it to work and my guess is that there is something fishy
in seekCancelled.

I have attached a SeekGame.qml file with console.logs to report

- The index of the seek selected. This works well and you can see e.g. "Game
offer 2" in the console.

- When a game starts, as signaled by onGameStarted. This also works and you can
see "Yes, I work when starting a game!" in the console.

- When a seek is cancelled, as signaled by onSeekCancelled. I can't get any
report to the console, and I have tried placing this connection in several
places just in case this was the problem.

Hence my conclusion is that actually no signal activates onSeekCancelled even
if in the FICS server an opponent "decline" or "unseek" after responding to a
match offer. And this is why we get no spinners to stop, no element to be
removed, etc.

For what is worth, in the console you can see the FICS log when the opponent
"decline", but there is nothing to be seen when the opponent "unseek".

Something that has improved is that new seeks keep appearing no matter what
happens with the declined offer. This means that if the user gets tired of
waiting he can always go for another seek, and if the opponent accepts the new
game will start anyway. I checked and works this way.

I like the console.log output for easy debugging. Why not leave it in the
branch?

> For what is worth, in the console you can see the FICS log when the opponent
"decline", but there is nothing to be seen when the opponent "unseek".

Is it possible to leave this corner case as a post 0.4 bug? If yes then needs
new bug.

(In reply to comment #11)
> > For what is worth, in the console you can see the FICS log when the opponent
> "decline", but there is nothing to be seen when the opponent "unseek".
> 
> Is it possible to leave this corner case as a post 0.4 bug? If yes then needs
> new bug.

Agree. I will file it when we resolve this bug.

Have you figured whether it is me or seekCancelled who is buggy?

(In reply to comment #9)
> - When a seek is cancelled, as signaled by onSeekCancelled. I can't get any
> report to the console, and I have tried placing this connection in several
> places just in case this was the problem.
> 
> Hence my conclusion is that actually no signal activates onSeekCancelled even
> if in the FICS server an opponent "decline" or "unseek" after responding to a
> match offer. And this is why we get no spinners to stop, no element to be
> removed, etc.

And that conclusion was right. The backend was not interpreting a remote
"decline" as a trigger for seekCancelled. Now this is implemented in
https://gitorious.org/miniature/miniature/commit/3f330eae881e1e88da2843b924bd8c2411a285eb

> 
> For what is worth, in the console you can see the FICS log when the opponent
> "decline", but there is nothing to be seen when the opponent "unseek".

The "decline" case been solved. The "unseek" case is still pending since I
couldn't see any output in the console when the opponent unseeks (?). Anyway,
this is now Bug 12380

Resolving and verifying.