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


21 Responses to “KScore2: Yet another new framework”

  1. hron84 Says:

    I think the first is more beautiful for me… Tabs ftw 🙂

    • Stefan Majewsky Says:

      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.

  2. freinhard Says:

    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!

  3. sebastian1111 Says:

    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?

    • Stefan Majewsky Says:

      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.

  4. Rsh Says:

    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!

  5. Fri13 Says:

    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

    • Stefan Majewsky Says:

      This functionality is included, but game developers must specify which standard fields to add to the dialog.

  6. Supreme1012 Says:

    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!

    • Stefan Majewsky Says:

      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.

  7. nuno Says:

    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.

    • Stefan Majewsky Says:

      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.

  8. warnec Says:

    Hey! Good work!

    How about implementing Internet High Scores in the future, so that we can compare our scores with other KDE users? 😉

  9. tom Says:

    vertical Tabs are very bad usability imo
    horizontal Tabs are ok

  10. Matthijs Says:

    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?

  11. onety-three Says:

    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.

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

    • Stefan Majewsky Says:

      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.

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

    • Stefan Says:

      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?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s