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

[Matt Williams]

On Tuesday 29 April 2008 17:50:49 Parker Coates wrote:
> 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.

During the last 24 hours, the API has passed through a point much like this 
several times (mostly in my head but at least once in code). To quote one of 
my other emails:

"The other alternative is to have KScoreManager return the raw data which can 
then be passed to a "KScoreBoard : public KDialog" class or 
a "KGraphicsScoreBoard : public QGrapicsWidget" which will create the stuff 
and you can then display the dialog/widget how you wish?"

to which Dmitry replied, "+1 for the [other way] as it would produce a more 
obvious and readable code"

So your idea is a slightly better version of what I said there but we decided 
that having 1 class was better. I do like the idea of splitting off the UI 
from the implementation like you say but the only reason I'm hesitating is 
that for any of these 'display classes' to be able to make good use of the 
KScoreManager data, we're going to have to expose a lot of the data, 
including various settings.

I tell you what, since I'm in a good mood I'll hack about the API to get it 
able to do what you suggest to see how it feels :) I'm going to get some food 
first though :D

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/1498b731/attachment.pgp