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

[Matt Williams]

On Thursday 01 May 2008 19:08:14 Parker Coates wrote:
> 2008/5/1 Matt Williams <matt at milliams.com>:
> >  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.
>
> Unfortunately, friendship isn't inherited.
> (http://www.parashift.com/c++-faq-lite/friends.html#faq-14.4) So while
> KAbstractScoreBoard will have friend access to KScoreManager, any
> classes derived from it won't. I had thought of using friendship to
> clean up the API a while ago, but couldn't find a way to make it work
> other than declaring every possible display class a friend. But of
> course this would mean new classes couldn't be added without modifying
> the KScoreManager header, which is nasty.
>
> Unless, of course, Albert knows a way around this.

See Albert's other email about this :)

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

Coolio.

> >  > - 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.
>
> Well, you could always make the user call m_board->setDisplayOptions(
> KScoreDialog::HighlightLastScore | KScoreDialog::DisplayMessage ) if
> they wanted to modify the dialog before calling m_board->show(). This
> really isn't a major issue, more style than anything. I guess my
> primary objection to adding the display options to the show() method
> is that it's inherited from QDialog and I feel modifying inherited
> methods without a really good reason is likely to clash with users
> expectations. Also if you override show() and add parameters you
> should probably do the same to exec() for consistency's sake.

Yeah, for example if you look at the QGraphicsWidget version, there isn't 
really a show(). It would be a case of creating the widget each time,  adding 
it to the scene and then deleting it when done. Or would people expect to be 
able to show() and hide it?

I'm tempted to go with a solution somewhere in between. Provide a ScoreDisplay 
option to the constructor and then provide a setDisplayOptions() type 
function in case people want to use one object and change its purpose.

As an aside: I realise now there's not really any need for both 
HighlightLastScore _and_ DisplayMessage since I can't think of a time when 
you'd only want just one of them. They could probably both be replaced with 
one flag telling the board that it's wanted to display the message and 
highlight the name. In the case of the board asking the player for their 
name, this could even be implicit. Then, you would only need to set this 
option if DoNotAskName is set.

> This just reminded me of another potential use case. What if I wanted
> to create a highscore dockwidget? The widget might only ever get
> show()n once, so it would be nice if it could refresh the scores
> automatically. Therefore, I still think KScoreManager should have a
> scoresChanged() signal, just as a convenient way to keep things in
> sync.

This is all starting to look very much like a MVC scenario (multiple possible 
views on the same data). Hmm...

> >  > - 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.
>
> I don't really see how this depends on the previous point. Could you
> explain?

Sorry, it was more a case of "I'll worry about this once the solution to the 
previous point has been found" since there could be conflict.

On the whole though, I think a different view class could be beneficial for 
this, yes.

> >  > - 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.
>
> I, personally, don't care for it. I think high scores should be
> recorded regardless of what the user wants, but if others think its
> important, they should probably argue their case. I guess the thread I
> was thinking of was back in August,
> http://lists.kde.org/?l=kde-games-devel&m=118708126008359&w=2

Or again from Burkhard,  
http://lists.kde.org/?l=kde-games-devel&m=120940404817412&w=2. Personally, 
I'm not particularly bothered either way. I don't think it would be a big 
problem to include the functionality so I will. If however, it turns out to 
be a big problem, I won't bother. 

I guess we'll wait and see :)

> >  > - 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).
>
> Presumably, the display classes will want to prepopulate the line edit
> with the appropriate default value, but how will they get it? Will the
> default name be preloaded into the score as soon as it's addScore()d,
> so that it can be extracted from scores()? Or should there be (yet)
> another method like QString newestScoredefaultName()?

The way it would work is the list of score data that KScoreManager sends to 
the UI would include the name for the player already filled in (from the list 
I gave before) and then, if 'ask name' is set, it will use that name to 
pre-fill the box.

I haven't decided yet at which point the scores will actually be saved to file 
though.

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