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).
The Geek Shall Inherit The Earth 
August 9, 2010 at 09:15
I think the first is more beautiful for me… Tabs ftw 🙂
August 9, 2010 at 09:17
Yes, but tabs can only reflect a flat hierarchy (which is one of the two weak points of KHighscore which I mentioned). Also, vertical tabs have problems with accessibility IMO.
August 9, 2010 at 09:17
the list itsself does look a lot better!
but please, PLEASE don’t make me twist my head just to read tabs, thats usability at it’s worst!
August 9, 2010 at 09:29
Also ich finde diese Verbesserung rein vom optischen auch nicht so viel besser. Zumal man mehrere Ebenen (wie im Kommentar angesprochen) ja noch über mehrere Dialoge anbieten kann. So geht nach Level A einfach der Highscore für A auf, am Reiter kann man noch andere Schwierigkeitsgrade ansehen. Ich finde das ausreichend und übersichtlicher. Zumal ich leider nicht sehe, wie die neue Liste links mehrere Dimensionen zulassen soll?
August 9, 2010 at 11:53
I won’t translate the comments from German, so here’s just a synopsis: The commenter thinks that the first dialog could implement multiple levels via cascaded tabs/dialogs.
To your question about how the list allows multiple dimensions: It’s actually a tree view, which I configured such that it looks like a list view when the category hierarchy is flat.
August 9, 2010 at 10:38
I think the first one looks much better as well! I don’t know if it is because of vertical tabs (which can be debatable, I admit) but I think it is because of this TableWidget – on first image the data is precisely fit into the layout, while the second one looke like a rough unpolished UI. Probably the contrast with white background also spoils the visual effect. It is very subjective .. but kudos to you for improving the functional side of things which is more important!
August 9, 2010 at 10:42
Is there change to get dates to the records?
If I am only player (as usually on my account), I care more that when did I make a record than who did it (as it is always me).
name | points | level | date
August 9, 2010 at 11:53
This functionality is included, but game developers must specify which standard fields to add to the dialog.
August 9, 2010 at 11:45
it looks good! I just dont completely know what is what exactly since I cant read that language. and sideways tabs are definitely a usability problem, so good call there. Fri13’s idea about adding a timestamp seems like it would be helpful as well. great job with all the hard work you’re putting into the KDE games!
August 9, 2010 at 11:54
The important stuff is in English. The last column just states the selected game mode, and the list at the left holds the difficulty levels.
August 9, 2010 at 12:09
reasons how come i think people will like first one better.
1. #1 Is simpler visually.
2. The sheet mode is rather incomplete and many visual differences in all the fields.
3. There is low visual alignment in the second case.
4. You scaled the second screenshoot.
August 9, 2010 at 20:53
1. Agreed.
2. What do you mean by visual differences? All fields are formatted equal.
3. Actually, I feel that visual alignment is better in the second case.
4. That’s not me. 🙂 That’s WordPress scaling too big images.
August 9, 2010 at 14:00
Hey! Good work!
How about implementing Internet High Scores in the future, so that we can compare our scores with other KDE users? 😉
August 9, 2010 at 18:14
vertical Tabs are very bad usability imo
horizontal Tabs are ok
August 10, 2010 at 10:24
I like the first screenshot better, but I understand the issues with vertical tabs. Can’t you make horizontal tabs when the tree is flat, and do the other things with multi-level trees?
August 10, 2010 at 11:41
I’d just like to add that left-aligning the score field probably isn’t a good idea both from a visual as well as an a11y standpoint.
Apart from that, the image looks much better when it isn’t scaled 😉
You might want to consider to resize the last column to fill the rest of the table widget so that it looks cleaner. Something similar for the bottom edge would be good, too.
August 10, 2010 at 11:42
Of course I meant usability, not a11y. Sorry. But I’m not an expert anyway.
September 15, 2010 at 14:02
Hi Stefan,
Where can I find source code of KScore2?
Does it depend heavily on KDE and libkdegames, or it could be converted to use only Qt classes?
September 16, 2010 at 07:19
It’s in the kscore2 branch of my Git copy of kdegames at git://git.bethselamin.de/kdegames-work.git. Porting to Qt should be easy, you need to replace KDialog with QDialog, KColorScheme with QPalette, and i18n() by tr(). The only thing that heavily depends on KDE classes is the default storage engine which uses KConfig, but it should be straightforward to write your own (e.g. QSettings-based) engine.
September 16, 2010 at 07:29
Out of curiosity: why didn’t *you* use Qt classes? For example, starting with Qt 4.6 QDialog in KDE launches KDialog (not sure about KColorScheme, but pure Qt apps look natively in KDE). Usage of Qt classes could reduce interdependency of KDE modules and make them usable in portable applications
September 16, 2010 at 08:00
I want the better integration and coherence. The actual advantage of KDialog over QDialog, for example, is the simplified and consistent button management. For the same reason, I use KStandardGuiItem.
Looking at the code, KColorScheme can actually not be replaced by QPalette, because I need the positive/neutral/negative colors which only KColorScheme can give me.
Then there are all the other invaluable facilities in kdecore which have no Qt equivalents, e.g. KStandardDirs or KConfig.
BTW is there an equivalent for KUser in Qt?