[Kde-games-devel] KScoreManager design

Stefan Majewsky majewsky at gmx.net
Fri Oct 2 15:16:28 CEST 2009


I'm taking this to a separate thread, because what I'm going to say does not 
really relate to the current KScoreDialog implementation.

Am Freitag 02 Oktober 2009 12:12:49 schrieb Dmitry Suzdalev:
> Guys in the blog comments say that this can be useful for Level packs
>  support. As I'm currently adding a level packs support to KAtomic, I could
>  potentially use this too (though KAtomic doesn't use a KScoreDialog atm).
> 
> But in this case the API added by Felix needs to be generalized to some
>  more common concept.
> 
> And this would require a very different implementation.
> Because LevelPacks consist of separate levels. So highscores are for each
> level in pack. So layout of widgets in score dialog will differ and
>  unerlying implementation must differ.
> KGoldRunner and KAtomic are examples of games with such highscore
>  structure. Both of them don't use KScoreDialog because currently it
>  doesn't fit their model.

I've taken a look at the KScoreManager stuff for the first time. (I have 
followed the discussion about it at that time, but did not take part in it 
because I was relatively new to KDE programming.)

First of all, it seems like much code has been copied and adapted from 
KHighScore/KScoreDialog. There's nothing bad about that a priori, because this 
code has proven its stability in plenty releases. But moving to a new API 
gives the chance of cleaning up old stuff. In this particular case, much of 
the code (also on the presentation layer) is tossing around QMap and QList 
objects. I'd rather use a model/view approach here, which can reflect both the 
score tables and the groups at once.

Something like a KScoreModel might also open the door to an arbitrary grouping 
order (grouping by difficulty, by level, by level pack, etc.). See the 
attached mockup of a KScoreModel with level packs and levels. The green part 
of the model has a tree structure, while the blue part (which is found below 
every leaf of the tree) has a table structure. The blue part directly 
corresponds to what KScoreTable displays, while the green part might require 
different interfaces. Everything of this should be doable with the generic 
approach that the KScoreManager draft is taking on the UI side.

RFC.

Greetings
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kscoremodel-concept.svg
Type: image/svg+xml
Size: 11790 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20091002/927ef465/attachment.svg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20091002/927ef465/attachment.sig 


More information about the kde-games-devel mailing list