[Kde-games-devel] Review Request: KScoreDialog with level selection

[Dmitry Suzdalev]

On Friday 02 October 2009 13:26:21 Stefan Majewsky wrote:
> Am Freitag 02 Oktober 2009 09:22:34 schrieb Dmitry Suzdalev:
> > Actually I'm not sure if this really should be added to KScoreDialog.
> >
> > It seems to me that if every game which has a slightly different layout
> > of its highscore system would patch libkdegames, we would end up with a
> > mess in API and in implementation.
> >
> > What do others think?
> 
> From what Felix said (he's sitting next to me currently), people have
>  already commented on his blog article that they would also like to use
>  this functionality. Also for me, separating highscores by level name opens
>  the possibility to use KScoreDialog in Palapeli.

I've read Felix's blog and also thought a bit more about this.

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.

We discussed this once on this list and all decided that our highscore system 
would need some reimplementation. Back then we gathered all suggestions on a 
wiki page. *searches*. here: 
http://techbase.kde.org/Projects/Games/Ideas#Reworked_highscore_system

But this never got implemented because no one had found a time for this :)

Looking at Felix's patch it looks more like some "hack to make this work with 
current KScoreDialog implementation". It doesn't look like a clean solution or 
clean extension from my POV :)

That's why I suggested inheriting dialog inside kspiral's sources and 
introduce this "hacky" part there - to keep KScoreDialog's implementation 
(relatively) simple...

Another option is what you've suggested: to implement an additional 
KScoreDialogWithLevels perhaps by factoring out some common code in some 
baseclass/mixin.

I also must admit that this is my opinion and KScoreDialog has a maintainer, 
and also we have some other devs here, so I think i'm not the one to judje, 
just expressing my thoughts.

I don't want to stop the Felix's initiative, I just want to find a right place 
for it :)

Cheers,
Dmitry.