[Kde-games-devel] KPat/Freecell broken?

[Parker Coates]

On Mon, Dec 14, 2009 at 15:07, Andreas Pakulat <apaku at gmx.de> wrote:
> On 14.12.09 12:50:24, Parker Coates wrote:
>> Fortunately there's an even cleaner solution. CardDeck now has a
>> cardAnimationsDone() signal, so as soon as I get a chance, I'll modify
>> this logic to make use of that instead of manually connecting to the
>> animationStopped() signal of individual cards.
>
> That might actually solve the spider problem. I've tried some debugging
> and for some (unfortunately unknown reason) the bookkeeping of
> carddeck.cpp m_cardsWaitedFor gets out of sync with reality. Thats why
> mousePressEvent then ignores all subsequent mouse events, the
> m_cardsWaitedFor is not 0 once the run is moved to the bottom-left
> stack.
>
> I also saw that this only happens when you manually complete a run, if
> you complete a run by fetching another round of 10 cards from the
> right-hand stack and one of the cards completes a run this doesn't
> interrupt the flow!
>
> The following is my current debug output, the "card started/stopped
> animation" is printed from CardDeck::cardStartedAnimation and
> CardDeck::cardStoppedAnimation. The numbers are the "current" and the
> "new" value of the counter variable m_cardsWaitedFor:
>
> SpiderPile::moveCards
> card started animation 0 1
> <snip>
> card stopped animation 3 2
>
> I'll see if I can dig deeper...

I'm not sure there's a need. If the problem is in CardDeck's animation
tracking, then just revert the last commit to it. See
http://websvn.kde.org/?view=revision&revision=1057660 .

Originally I wrote this logic using a QSet for better debugability.
Once (I thought) this code was working properly and I wasn't seeing
any asserts any more, I decided to replace the QSet with a simple
increment/decrement system. Obviously, I was wrong about it working
properly. This change was fairly recent, so it wouldn't surprise me if
this is the cause of all these headaches.

>> Do you have commit access? If so, please commit. If not, could someone
>> else please do so?
>
> I'll commit tomorrow unless Julian is faster.

Thanks. Even after reverting the commit mentioned above, I still think
it makes sense to commit Julian's change.

Parker