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

[Andreas Pakulat]

On 12.12.09 12:29:03, Parker Coates wrote:
> On Fri, Dec 11, 2009 at 20:34, Andreas Pakulat wrote:
> > On 11.12.09 16:50:45, Parker Coates wrote:
> >> On Fri, Dec 11, 2009 at 16:14, Andreas Pakulat wrote:
> >> > Hi,
> >> >
> >> > I'm wondering if anybody else has problems with KPat not accepting
> >> > mouse-clicks/drags anymore after a couple of initial moves when playing
> >> > Freecell? The first oddness is that a double-click to move a card to the
> >> > free-stack doesn't result in an undoable action. And then after a couple
> >> > of movements of cards around I can suddenly not click anything anymore,
> >> > no card reacts. Seems this happens as soon as more than one card is
> >> > moved at once.
> >>
> >> Yes, others have seen it. It's been reported as bug 218019. [1]
> >
> > Thanks and sorry for being lazy :) Thats basically all I needed...
> >
> >> > The same happens in Spider when the first complete line from ace to king
> >> > vanishes.
> >>
> >> Crap. I was hoping it was Freecell specific. The reporter claimed that
> >> he didn't have any issues in Spider, but maybe he didn't play for long
> >> enough to clear a run.
> >
> > Just to be sure we're on the same page: A "run" means adding up cards
> > from King down to ace so it gets nicely moved to the bottom-left
> > stack-place, right? Oh, btw, this was single-suite spider
> 
> Yeah, that what I meant by "run".
> 
> >> > Saving and reloading the games helps "fixing" the problem with Spider,
> >> > i.e. it doesn't block access to the cards until I start a new game. In
> >> > Freecell loading a game that previously blocked also makes it playable,
> >> > but only until the next move that involves more than one card.
> >>
> >> Thanks for the details. Please add them to the report, if you don't
> >> mind. If you start then stop the demo, does that have any affect?
> >
> > For Freecell it didn't hit the problem as the demo mode always moved
> > only a single card.
> 
> Makes sense.
> 
> > For Spider it was a bit tricky to get it to complete a run as it always
> > "hangs" when one can still move cards around, but not in a meaningful
> > fashion (i.e. one empty 9 and one thats build down to 6, so you can move
> > 8 and following around). But once I had it complete a run it didn't
> > stop. When I then completed the next run manually it again stopped
> > accepting any input.
> >
> > Oh, wait now I understand what you mean with "start and stop demo"...
> > No, once the mouse stops working the demo button also stops working.
> >
> > Added that and the other text to the report. I took the liberty to mark
> > the bug as NEW and kde-4.4.0-blocker as IMHO this breaks the app quite
> > heavily. Feel free to change the latter back (in the Keywords)
> 
> Those both seem fair.
> 
> >> This bug is definitely my fault, and I'm feeling pretty bad about it.
> >> Just before the freeze I cleaned up the mouse handling and it seemed
> >> to be working well, but I didn't really consider the custom weirdness
> >> that Freecell adds. The major problem here is that I'm out of town for
> >> work, away from my dev machine and I will probably won't be back until
> >> January 5th.
> >>
> >> I read through the code at lxr.kde.org, but I couldn't really see any
> >> obvious problems. I probably need to run it to figure out what's going
> >> on, but if I had to guess, I'd say the fix won't be that complicated.
> >> If someone else wants to take a stab at fixing this, I'd be more than
> >> happy to try to support them, but I realise that this is asking a lot.
> >> If anyone has a git-svn checkout and is willing to run a git-bisect to
> >> figure out which commit broke this, that would certainly help narrow
> >> down the issue, too.
> >
> > As I love to play Spider and Freecell I'll definetly have a look
> > sometime (probably not this weekend though). No git-svn here, but the
> > bug (at least in freecell) is easy enough to trigger. So if you can give
> > me a hint where to start looking that would be nice :)
> 
> Okay, I think I figured out what is wrong, at least in Freecell. If
> someone try out the following changes to freecell.cpp, test them and
> commit, it would be most appreciated. There's a much cleaner way to do
> this, but these minimum changes should get the things working again.
> 
> Line 257:
> - m->disconnect( this );
> + disconnect(m, SIGNAL(animationStopped(Card*)), this,
> SLOT(waitForMoving(Card*)));
> 
> Line 264:
> - c->disconnect(this);
> + disconnect(c, SIGNAL(animationStopped(Card*)), this,
> SLOT(waitForMoving(Card*)));
> 
> Let this be a lesson, kids. Always make your disconnects as specific
> as possible to avoid breaking connections made elsewhere.

Unfortunately that doesn't help. Freecell still stops doing card-moves
once one stack of cards has been moved.

A grep for similar disconnects yielded one more result in dealer.cpp,
but also adjusting that one didn't help unfortunately (line 741)

BTW: There's a disconnect() call in dealer.cpp, unless you need to
disconnect exactly at that point its not overly useful as ~QObject will
disconnect everything from the deleted object too.

Andreas

-- 
Your boss is a few sandwiches short of a picnic.