[Kde-games-devel] Review Request: Add KScore2 framework to libkdegames (implementation incomplete)

Stefan Majewsky majewsky at gmx.net
Sun Aug 8 00:42:56 CEST 2010



> On 2010-08-07 11:11:19, Parker Coates wrote:
> > /trunk/KDE/kdegames/libkdegames/kscore2/dataset.h, lines 28-33
> > <http://reviewboard.kde.org/r/4919/diff/1/?file=32808#file32808line28>
> >
> >     I'm not sure if DataSet is the best name for this class. The word "set" implies plurality, which makes me think that it would represent a group multiple scores.
> >     
> >     In the previous (failed :D) KScore rewrite, the equivalent class was called an Entry, which I think is a bit more descriptive. I also notice that you use the term entry in the Engine API. Other potential names are Submission, Record, or Attempt.

I like "record" the best, mostly because (like you said) "entry" is already used by the Engine, and "entryIndex" as a name is too clunky IMO.


> On 2010-08-07 11:11:19, Parker Coates wrote:
> > /trunk/KDE/kdegames/libkdegames/kscore2/flags.h, lines 35-41
> > <http://reviewboard.kde.org/r/4919/diff/1/?file=32814#file32814line35>
> >
> >     What about support for remembering the last used player name? Currently, KScoreDialog only falls back to KUser if no last-used-name has been saved. That is certainly behaviour that I think we'd like to preserve.

Ah, so that is the reason for that "0_LastPlayer" key...


> On 2010-08-07 11:11:19, Parker Coates wrote:
> > /trunk/KDE/kdegames/libkdegames/kscore2/model.h, line 132
> > <http://reviewboard.kde.org/r/4919/diff/1/?file=32816#file32816line132>
> >
> >     s/senseful/sensible/

Good point. That shows I'm not a native speaker. The German adjective "sinnvoll" (which literally translates to "senseful") has the same meaning as "makes sense", so I thought it would be sensible (sic!) at this point.


> On 2010-08-07 11:11:19, Parker Coates wrote:
> > /trunk/KDE/kdegames/libkdegames/kscore2/model.h, lines 138-159
> > <http://reviewboard.kde.org/r/4919/diff/1/?file=32816#file32816line138>
> >
> >     Just so I'm understanding, you're providing a singleton interface for convenience, but allowing a public constructor in case some future game has special needs and wants to have multiple Model instances?

Right.


> On 2010-08-07 11:11:19, Parker Coates wrote:
> > /trunk/KDE/kdegames/libkdegames/kscore2/model.h, lines 196-222
> > <http://reviewboard.kde.org/r/4919/diff/1/?file=32816#file32816line196>
> >
> >     None of these setters have getters. I can see why providing them for the sorting setters would be a pain, but I think adding a behavior() getter is probably wise for completeness, if only because it should be easy to do.

Okay, if you really wish. :-)


- Stefan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4919/#review6846
-----------------------------------------------------------


On 2010-08-07 22:42:24, Stefan Majewsky wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4919/
> -----------------------------------------------------------
> 
> (Updated 2010-08-07 22:42:24)
> 
> 
> Review request for KDE Games.
> 
> 
> Summary
> -------
> 
> KScore2 is a new framework which ought to replace the commonly used KHighscore/KScoreDialog and perhaps also KExtHighscore. The most central class (and the point where you should start reading the APIDOX) is KScore2::Model.
> 
> KScore2 makes use of the Model/View concept to create a simple, extensible, yet future-proof API. Contrary to KScoreManager (the other new highscore library which is in playground/games ATM), KScore2 is designed such that no assumptions about the internal data structures are included in the public interfaces. Its API makes simple tasks easy and complex tasks achievable.
> 
> Many KDE games have, over the years, grown their own highscore systems. KScore2 allows to accomodate these special needs: The score model can be made to retrieve its data from arbitrary locations by writing a custom KScore2::Engine subclass. Similarly, a KScore2::CategoryModel can be implemented to support custom highscore grouping (e.g. by difficulty, by level, or by levelpack and level).
> 
> What I'm presenting here is my current working state. Several things are missing:
> * two functions in the KScore2::Model class, and the complete KScore2::Dialog class (which will only be available internally; its whole public interface is KScore2::Model::showDialog)
> * unit tests
> * integration into the rest of libkdegames (at the very least, this means a KGameDifficulty::CategoryModel which provides grouping of scores by difficulty as we have it already in most KDE games)
> * API for gathering game statistics (like KPat and KReversi do; I want input on this one!)
> * testing in the form of ported games (KDiamond will likely be my guinea pig again)
> 
> The code is also available from my Git-SVN repository at git://git.bethselamin.de/kdegames-work.git (branch "kscore2").
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdegames/libkdegames/CMakeLists.txt 1160372 
>   /trunk/KDE/kdegames/libkdegames/kscore2/categorymodel.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/categorymodel.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/dataset.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/dataset.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/datasetdefinition.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/datasetdefinition.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/engine.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/engine.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/flags.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/flags.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/model.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/model.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kscore2/model_p.h PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/4919/diff
> 
> 
> Testing
> -------
> 
> At least it compiles. ;-)
> 
> 
> Screenshots
> -----------
> 
> Relation of the different data sources in KScore2
>   http://reviewboard.kde.org/r/4919/s/473/
> 
> 
> Thanks,
> 
> Stefan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20100807/070f06e7/attachment-0001.htm 


More information about the kde-games-devel mailing list