KScore2: Yet another new framework
August 9, 2010
Library programming seems to be fun lately. After KGameRenderer, I’m currently preparing a successor to the aged KHighscore and KExtHighscore frameworks. If you followed the kdegames development closely (i.e. read the development mailinglists) over the last couple years, you will know that we have wanted to replace especially the widely used KHighscore for a long time.
So this weekend, I finally sat down and designed KScore2, which shall eliminate the problems of KHighscore. The most prominent issues are:
- Scores can only be grouped in a flat hierarchy of categories. The most common grouping is by difficulty. Grouping by levels is also possible, but you cannot group by levels and by difficulties at the same time (i.e. a group hierarchy). KScore2 allows this because categories are read from an arbitrary tree-shaped QStandardItemModel.
- The scores can only be stored in the application’s configuration file. Especially, no interaction with online highscore systems is possible. KScore2 allows the application developer to write his own storage engine to support such systems (or legacy score file formats, as they are found e.g. in KGoldRunner).
After about two days fulltime work, I’m basically done with bringing KScore2’s feature list on par with KHighscore, though some polish is still missing. So my hope is to get this into KDE SC 4.6 as well.
And because everyone loves screenshots, find below a comparison between the old KScoreDialog (top) and the new KScore2::Dialog (bottom).