[Kde-games-devel] Hacking again KScoreDialog

[Albert Astals Cid]

A Dilluns 29 Desembre 2008, Parker Coates va escriure:
> 2008/12/15 Albert Astals Cid:
> > Hi, the attached patch files bug 177515: High scores list should not
> > alphabetize tabs
> >
> > Do you agree to commit the patch plus all the needed
> > setConfigGroupWeights(KGameDifficulty::levelWeights()); ?
>
> Sorry for the late response. I've been away from home and without
> network access for the past two weeks.
>
> In general, I think support for non alphabetical sorting is good, and
> the implementation seems clean, but I do have some concerns about
> consistency in the API. setConfigGroupWeights(...) operates
> differently than differently than the similar functions
> addLocalizedConfigGroupName(...) and
> 	addLocalizedConfigGroupNames(...).
>
> Here's a list of problems I see:
>
>
> - There is no way to set the weight of a single group. A
> setConfigGroupWeight(...) function should probably be added.
>
> - The addLocalized... functions inserts new translations into the
> classes internal map, while setConfigGroupWeights only allows you to
> replace the existing internal map with a new one. Because there is no
> way to retrieve the internal map, the class' user must keep a local
> copy of the map if they want to make changes to the weights after
> originally setting them. I recommend switching to "add" functions
> instead of "set" functions.

I did it this way because i think this is a much more useful API while the 
other is an overkill, as a kscoredialog user you should never need to change 
the group weights once set. Basically you create a kscoredialog, set the 
weights and show it. I don't see why you would ever want to get the weights 
you set previously or add a new ones. The same for localized names, but i 
didn't think of it when it was added.

> - The addLocalized... functions map a groupkey to a translated string,
> while setConfigGroupWeights maps a weight to a groupKey. For
> consistencies sake, I would prefer to see the parameter changed to a
> QMap<QByteArray, int>.

And loose the automatic ordering provided by QMap? The consistency is there, 
you are adding weights for groups and they come in a structure that already 
has them ordered by weight, in the key->data sense, the order is what is 
unique not the group (ok, it's unique too but less important for this 
function)

> - The API documentation doesn't specify what affect the integer weight
> has on sorting. Do higher weights come first or last?

Last, that's something i find obvious but you are welcome to improve the 
documentation.

Albert

> I realise that at the moment the above issues don't make much of a
> difference as the only current use case is a single call to
> setConfigGroupWeights(KGameDifficulty::levelWeights()), but I hope
> you'll agree that if we bother adding this functionality, we might as
> well do it with enough flexibility to support new uses in the future.
>
> I'd be willing to (quickly) make the changes described above if you
> think they make sense. At what point is our API supposed to be frozen
> for 4.2?



>
> Parker
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel