[Kde-games-devel] KScoreManager design

[Parker Coates]

On Fri, Oct 2, 2009 at 09:16, Stefan Majewsky wrote:
> 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.

That was one of the main reasons I lost motivation to work on it. It
quickly became obvious that this was one of those things that should
be implemented as a model/view. Or rather, I noticed that I was
hacking together my own awkward model/view system. Unfortunately I
didn't know Qt's ModelView framework (and still don't), so work
ceased. This definitely seems like the right way to go to me.

There's no need to be polite, so don't hesitate to shit on my design.
Class design isn't something I have a lot of experience in, so I
generally end up starting with a naive hack, get it somewhat working,
see the limitations, tear it apart, and repeat.

> 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.

You model doesn't include difficulty. Do you think it should be the
topmost level or the bottommost. I'm thinking probably the latter.

It looks like you're all set. I remember reading that you had a
surplus of free time and a shortage of interesting projects, so I'm
sure you'll have no trouble getting this ready before the feature
freeze. ;)

Parker