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

[Parker Coates]

2008/4/29 Matt Williams <matt at milliams.com>:
> On Tuesday 29 April 2008 03:59:16 Parker Coates wrote:
>  >   - ScoreInfo getScore( int index, const QByteArray& groupKey )
>  >   - QList< ScoreInfo > getScores( const QByteArray& groupKey )
>  >   - QStringList scoreGroupNames() //This will probably need to be more
>  > complex in light of the recent i18n changes.
>  >   - etc.
>
>  While these functions make sense since they are getters for the setters
>  already there, I can't really see a need for them. If someone could give me a
>  usecase for these functions I'd be glad to add them but I'm trying not to add
>  functions which aren't necessary.

You seem to have taken my original comment about multiple UI
interfaces in a different direction than I had originally intended. I
wasn't suggesting that /you/ create a QGraphicsItem score table. (But
good on you for planning to do so. Don't get me wrong!)

My thinking was that how ever many UIs you choose to implement, you
can't assume that that they'll suit everyone's needs forever. If you
were to implement the functions I mentioned above, it would allow a
future developer to write his own score interface while letting
KScoreManager worry about the nitty-gritty of reading and writing
scores.

But after having thought about this further, maybe it makes sense to
completely separate the "score manager" back-end from the "score
display" front-ends into separate classes. Please bear with me: OO
class design isn't a particular strength of mine, so if something
below seems downright nonsensical or impossible, don't hesitate to
shoot me down.

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 );
}

Others might disagree, but I think that pretty clean looking and I
think it's pretty intuitive to manage the scores with one class and
display them with another. The advantage there is that it also allows
the addition of new score display classes without having to make
changes to the internals of KScoreManager, who's only job is to manage
the scores and maybe inplement some signals and slots like the
following for the display classes to hook up to.

signals:
scoresChanged()
playerNameNeededFor( int index, QByteArray groupKey )

slots:
setPlayerNameFor( QString name, int index, QByteArray groupKey )

Anyway, that's just what I had in mind originally. It seems like
you're well under way with a different design, which is fine. I just
wanted to get as many of my thoughts out there as possible.

Parker