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

[Matt Williams]

On Thursday 01 May 2008 02:51:51 Parker Coates wrote:
> 2008/4/30 Matt Williams <matt at milliams.com>:
> >  Just an update...
> >
> >  I've committed the current version to SVN playground, it can be found at
> >  http://websvn.kde.org/trunk/playground/games/kscoremanager/. Hopefully
> > by tomorrow the doxygen generator will have run and so documentation will
> > be available at
> > 
> > http://api.kde.org/playground-api/games-apidocs/kscoremanager/html/index.
> >html. There's still no .cpp code, just headers.
>
> It looks really good! Here are some comments:
>
> - It's missing an "int numberOfScores() const" method. I don't really
> love that name, but I haven't been able to come up with anything much
> better. Maybe "scoreBoardLength"?

Yes, scoreBoardLength() sounds good. In that case I'll change 
setNumberOfScores() to setScoreBoardLength().

> - As you mentioned the Comment logic and
> KScoreManager::ScoreDisplayFlags should probably move to the UI class
> as they affect only presentation.

After some discussion with Albert, I've separated the UI from the management 
even further. The functions for accessing the information about the scores 
has now been made private. I've then created an abstract class called 
KAbstractScoreBoard which is a friend of KScoreManager so that it can access 
its private functions. This way, whatever funky display widget you can think 
of will just have to subclass KAbstractScoreBoard.

This way, all the display based functions and enums can be moved to 
KAbstractScoreBoard.

Do you think that the setMessage() function and the OutcomeFlag enum should be 
moved as well since they're UI specific?

> - Instead of
>
>  KScoreBoardDialog board();
>  board.show(KScoreDialog::HighlightLastScore |
> KScoreDialog::DisplayMessage);
>
> I'd prefer
>
>  KScoreBoardDialog board(KScoreDialog::HighlightLastScore |
> KScoreDialog::DisplayMessage);
>  board.show();
>
> as these seem like properties of the dialog that are unlikely to
> change during it's lifetime.

The reason I did it this way is that I've noticed people have a tendency of 
storing dialogs such as this as member variables of their mainwindow class 
(in fact that was a cause of bugs in a number of games using KScoreDialog). 
To allow people to do this (or at least to avoid bugs _if_ they do) I decided 
to build the dialog on the show() command rather than construction. People 
can then use the same object for displaying the board (passing nothing to the 
show() function) and displaying the end-of-game congratulation message/enter 
name box (by passig the relevant flags to show()).

Now, honestly I don't like this way of doing it but I don't know of a way to 
prevent people from using the Dialog as a member variable.

Suggestions on this are very much welcome.

> - Dmitry's "leader board" style dialog should probably be it's own UI
> class (KLevelScoreDialog?), instead of an option passed to
> KScoreBoardDialog. It would certainly keep the implementation a lot
> cleaner.

Its certainly a possibility. Though this depends on the resolution the the 
previous point.

> - Does calling "submitName( QString() )" submit a score with an empty
> name? Use the presupplied player name if one exists? Use
> "i18n("Anonymous")"? Or does it reject the current score? If not, will
> there be a way to cancel the last submitted score? I'm not sure that
> that's necessary, but someone did ask for it earlier.

submitName( QString() ) would submit the score with an empty name field. 
There's not currently a way to cancel a score, though you're right, it's 
probably a required feature.

> - What does KScoreManager do if "submitName" is never called? If a new
> score is added while "isWaitingForName()" is true, what do we do about
> the last score? I guess these are situations that should never occur
> in a properly coded application, but they should probably be handled
> properly regardless.

In this case the first score would be saved with whatever the default name is 
(in order: the Name field of ScoreInfo, the LastPlayer field from the file, 
info from KUser).

> Anyway, it seems like things are shaping up nicely. I can't wait to
> see some implementation to go with this API.

Yes, I'm suer I'll get round to writing it sometime :)

Matt
-------------- 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/20080501/45844579/attachment.pgp