[Kde-games-devel] A new highscore manager - KScoreManager

[Matt Williams]

On Tuesday 29 April 2008 21:37:17 Parker Coates wrote:
> 2008/4/29 Matt Williams <matt at milliams.com>:
> > On Tuesday 29 April 2008 17:50:49 Parker Coates wrote:
> >  > KScoreManager::self()->addField(KScoreDialog::Custom1, i18n(Moves
> >  > Taken)); KScoreManager::self()->setDisplayFields(KScoreDialog::Name |
> >  > KScoreDialog::Score | KScoreDialog::Custom1);
> >  >
> >  > KScoreManager::ScoreInfo scoreInfo;
> >  > scoreInfo[KScoreDialog::Name] = playerName;
> >  > scoreInfo[KScoreDialog::Score] = playerScore;
> >  > scoreInfo[KScoreDialog::Custom1] = numberOfMovesTaken;
> >  >
> >  > if ( KScoreManager::self()->addScore(scoreInfo) )
> >  > {
> >  >     KScoreDialog scoreDialog( KScoreManager::self() );
> >  >     scoreDialog.show();
> >  >
> >  >     // OR
> >  >
> >  >     KGraphicsScoreItem scoreItem( KScoreManager::self() );
> >  >     m_scene->addItem( scoreItem );
> >  > }
> >
> >  Any ideas about how name entry would work, when the score board should
> > be show, who should handle the name entry, etc.? For example, in the
> > snippet you posted above, the call to addScore() is made before any UI
> > frontend is created and so the frontend won't be able to handle adding
> > the name.
> >
> >  Any thoughts?
>
> Well, what if the following methods were added to KScoreManager?
>
> int newestScoreIndex()
> QByteArray newestScoreGroup()
> bool waitingForPlayerName()
>
> The first two could be used to determine the most recently added
> score. (Ignoring the problem at hand, these would still be handy for
> highlighting the newest score. They could return a null value if
> nothing has been added recently.) And the last method would let you
> know if the KScoreManager was expecting a player name. When the
> display is created/shown, it could check these, and do the right
> thing. Combined with the signals and slots I mentioned in my previous
> email, I think this would be sufficient to handle adding the name.
>
> But then again there might be other problems, I'm not seeing. You're
> the one doing the hard work of actually flushing these ideas out. I'm
> just the guy trying to make suggestions on his lunch break. :)

No, what you're saying is making sense. It solves all the problems I was 
having with this bit. However, the whole thing doesn't seem very elegant. I 
don't like (for example) having about 6 different function each of which 
return a different bit of information about the scores. Perhaps if I combined 
all of them into 1 function which returns some sort of struct or container 
class which contains all the information. Since, as far as I can tell, 
there's not going to be any time when a user of KScoreManager is going to 
want just _one_ of the pieces of information.

As for the bool waitingForPlayerName() and the signals/slots, I'll see if I 
can smooth off the rough corners I'm seeing.

Thanks a lot for your input, my brain had really hit a dead-end with this for 
a while.

Regards,
Matt Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20080429/b680a33b/attachment.pgp