I have expected the February to become a month full of bug fixing because of the the KTouch’s release at the beginning of the month, but I haven’t received a single valid bug report to date.¹ Well, except a few which will be addressed by the the feature I have been busy working on instead.

Lesson Rendering Evolved

For KTouch 2.0 I have employed a rather simply approach to paint the current training line: for each character of the current line KTouch instantiates a dedicated QML Text item. This way it was easy to apply the styling for the individual states any character can have: placeholder text, typed text, contains a tying error and finally being part of the pre-edit text of some input methods. It also allowed my to implement the training screen very fast and works well for for Western languages with their simple Latin alphabet.

But this technique shows its deficiencies when used for more complex scripts like Arabic or Thai. Because of the use of individual Text items for each character it’s impossible to draw typographic ligatures. Both of the aforementioned languages rely heavily on them: Arabic joins most letters of a word together, Thai often stacks consecutive letters on top of each other. And for the former it doesn’t help either that KTouch currently can’t do right-to-left training.

With these issues it is clear KTouch needs new lesson rendering engine.

As of now the new engine is already nearly completed and fixes all the problems outlined above, only a few minor features compared to the old engine and some general code cleanup are still missing. When these are done I will push the changes to the KTouch’s central Git repository.

The new engine is now written in C++ as a new custom declarative type. Actually the old and the new approach doesn’t differ that much technically: both my custom type and the stock QML Text element leverage a QTextDocument to do the actual text rendering, the difference is only that my component gives me the control over it which I need. And that I now use only one single declarative item for the whole lesson text instead of one per character of the active line and one for each other line.

As one can see it is now possible to properly train on Arabic lessons, even though the alignment of the training text is still incorrect.²

One nice side effect of doing all the painting in C++ is that it gives me exact control over the font rendering. KTouch uses scaled font rendering to fit the lesson text into the viewport. In this case it’s important to disable hinting at least horizontally, because the rendering hints are calculated before scaling and this results in incorrect letter-spacing. I consider bad letter-spacing to be a major nuisance, so I was happy being finally able address this issue in the new C++ component.

The first line shows the old, fully hinted font rendering, the second the new font rendering where only vertical hinting is applied. As one can easily observe the letters in the second line are much more evenly spaced out.

This also includes the work done on KTouch in December. With the expected Christmas-related development hiatus I didn’t feel overly compelled to write a dedicated update.

And it is also the very last update before the upcoming KDE SC 4.10 release. The final tag freeze was already yesterday, so this report pretty much reflects the state KTouch will be released in.

Bugfixes

Since November another dozen of different mostly smallish issues have been fixed, among them the very last crash bug I am aware of. It took me forever to get to the bottom of the issue, even if the solution was always right in front of me. In the end it turned out KTouch’s resource editor was another victim of kdelibs Bug 303228, a bug report I have stumbled over very early on during my investigations. Too bad if one can’t match two backtraces.

Another significant fix is that KTouch is now able to render properly under a Plasma theme with light text on dark backgrounds (Bug 312082). No more impossible-to-read labels because of lack of contrast.

Data

Thanks to Ludo Beckers KTouch has gained support for the Belgian keyboard layout. As of now we don’t have matching course for this layout yet, so unfortunately it is difficult for the user to directly profit from it.

I think the overall data situation may improve, though, once the first release of KTouch 2.0 is out. I hope the new training experience combined with the completely overhauled authoring tools are enough of an impetus for new contributors to get some movement in that area.

It has been a quite month for KTouch, with the Feature Freeze in place for the greater part of the month. But this doesn’t mean nothing has been done at all.

Last Features

First, I did some work on the layouting code for the training screen.

Previously KTouch picked a font and laid out the sheet so the lesson text fit into it. This approach had a few problems:

• If the lesson contains very long lines the sheet didn’t fit into the view port.
• If the window is maximized on large screens the sheet used only a small amount of the available space.

The new version does it the other way around: the sheet will always fill the horizontally available space and we scale the text so it fits perfectly in there. Especially the latter was way more complicated to implement when I imagined. Calculating the required scaling factor is easy, but naïvely applying a value to the scale attribute to an QML text element results in severely degraded rendering quality. The default transformation origin is the center. With what, fonts will look very blurry. After setting it to top left corner rendering quality was okay, but still not that crisp like without scaling. Any hints to further improve the quality are welcome. I still think the gained flexibility is worth the price.

Secondly, one thing I have repeatedly observed is that users new to KTouch had problems grasping the training mechanisms of KTouch. Two characteristics in particular stood out in that way:

• Users have to correct their errors with Backspace.
• Finished lines have to be confirmed with Return.

The keyboard layout visualization always highlights the key the user has to press to go on, but in this cases this has been proven to be ineffective. Therefore I have implemented an additional hint system to help the user to overcome these hurdles: After three key presses after the users has entered one of the aforementioned conditions the key he has press to solve the problem will be displayed right under the current training line.

I think those hints are hard to ignore and users accustomed to the behavior won’t get distracted by them since they won’t see them ever.

Bugfixes

With these two features done I’ve spend most of my time on fixing bugs. A good dozen of small and not-so-small issues have been resolved. But one pair of fixes is especially important to the user.

With German being my native tongue–a language which only seldomly requires accented characters–I have only realized very late that handling dead key events in QML alone is impossible right now. This is a problem for KTouch because the event handling for the trainer was implemented in QML only. Many languages KTouchs offers courses for are really depended on working dead keys so I have considered that bug of show stopper severity. Now that I’ve moved the implementation of the event handling to C++, dead keys are no longer a problem.

While I was active in that particular corner of the codebase I also made sure KTouch works fine with CJK input methods. At least in the past their was some interest in creating a Chinese course for KTouch, now the technical requirements for that are there.

Handbook

Last but not least KTouch got a new handbook. The version of KTouch to be released with KDE SC 4.10 is a complete rewrite having only few similarities to the previous version. So a rewrite was also due for the handbook. Huge kudos go to Yuri Chornoivan who has stepped up to support me in that area and has been the one doing at least 90% of the work. This was not a small task by any means and I think the results speak for themselves.

With that done we are one step closer to the quality I think is required for a successful initial release. Replacing a peace of established software is always a risky endeavor, so I really don’t want to release something half-baked. Having a complete and up-to-date handbook is important part of that to me.

Today I’ve finally merged my next branch into the master branch. Lately the differences between the two branches became increasingly huge:

1
2
3
4

$ git log origin/master..origin/next --oneline --no-merges | wc -l
402
$ git --no-pager diff origin/master..origin/next --shortstat -- src/
 252 files changed, 23468 insertions(+), 14282 deletions(-)

Merging all that into the master branch took a huge pressure from me. After spending all that time I spend on working on KTouch it’s really important to me get the fruits of my work out to the end-users. Getting my stuff in the the branch KDE SC 4.10 will be released from is first the important step towards that goal.

My next step is clearing out the Bugzilla entries against KTouch. The vast majority of the bug reports can be closed since they don’t apply anymore, and also a fair share of the reported wishes are met by the new version.

So after finishing a lesson that’s that the user is going to see now:

With the help of the screen the user can review his learning progress and identify his weaknesses. For that a bar diagram visualizing the errors he has made during the training can be summoned:

If he has passed the lesson he may choose to start training on the next lesson right away. Otherwise he can repeat the current lesson or return to the home screen.

The score screen was the last large outstanding feature I am targeting for the initial release. With that one done only a few small ones remain I can easily finish until the Feature Freeze on October 25. So it looks like the new version of KTouch will be actually released with KDE SC 4.10 on January 23, 2013.

After finishing the keyboard layout editor here in Randa I’ve started working on the last remaining big task of the upcoming new version of KTouch: the summary screen which will be shown after the user has completed a lesson. For that I want to display the user’s learning progress with pretty diagrams. As there are no ready-made components for Qt Quick for that purpose right now, I’ve sat down and started to implement my own:

My QML component to render such graphs is actually pretty generic. Here is the complete code for the screenshot above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

import QtQuick 1.1
import org.kde.plasma.core 0.1 as PlasmaCore
import org.kde.plasma.components 0.1 as PlasmaComponents
import org.kde.ktouch.graph 0.1 as Graph
import ktouch 1.0

Rectangle {
    width: 800
    height: 300
    anchors.centerIn: parent
    color: "white"

    Column {
        anchors {
            fill: parent
            topMargin: 2 * spacing + legend.height
            leftMargin: spacing
            rightMargin: spacing
            bottomMargin: spacing
        }

        spacing: 20

        Graph.LineGraph {
            width: parent.width
            height: parent.height - legend.height - parent.spacing
            model: learningProgressModel

            dimensions: [
                Graph.Dimension {
                    id: accuracyDimension
                    dataColumn: 5
                    color: "#ffb12d"
                    maximumValue: 1.0
                    label: i18n("Accuracy")
                    unit: "%"
                    unitFactor: 100
                },
                Graph.Dimension {
                    id: charactersPerMinuteDimension
                    dataColumn: 6
                    color: "#38aef4"
                    maximumValue: 400
                    label: i18n("Characters per Minute")
                }
            ]
        }

        Row {
            id: legend
            anchors.horizontalCenter: parent.horizontalCenter
            spacing: 20

            Graph.LegendItem {
                dimension: accuracyDimension
            }
            Graph.LegendItem {
                dimension: charactersPerMinuteDimension
            }
        }
    }
}

The model used as the data source for the graph—learningProgressModel—is just a normal QAbstractTableModel descendant.

This is the second part of my blog post series describing the results of my work on KTouch. If you haven’t read the first part, you can find it here. This time I will write more about the new course and keyboard layout editor.

KTouch can be only as good as the underlying data. Without courses the trainer is basically useless to the user, without the keyboard layouts the visualization of the keyboard during training isn’t available. Therefore it’s important ships with as much data as possible.

Currently there is support for 39 keyboard layouts and there are 39 courses for 30 keyboard layouts. Unfortunately the quality of the course material varies a lot. There are a few courses of truly outstanding quality, but the most courses have been auto-generated out of dictionaries. Their quality ranges from passable to unusable. Of course none of those have full phrases or sentences in the training data, or provide even complete short texts to train on. A course containing such elements is much more effective and fun to learn.

Therefore I really would like to see more human-created high-quality courses in KTouch. As I can’t do anything about it personally (The German courses are already excellent, the only language I feel sufficiently proficient in to write training texts in.) the only thing I can do is to provide the tools to make creating them as easy as possible.

That’s a screenshot of the new course editor with one of the problematic courses loaded showing one of the built-in quality-assurance checks: if a lesson contains characters not available in that lesson, because they are not among the configured new characters of this lesson or any previous one, they are highlighted in red. There is also a check for too long lines.

On the left side their is a list over all data files KTouch knows about, built-in and user-created alike. If the user selects a built-in resource the editor will degrade to a simple viewer, though. If the user selects a keyboard layout the program will adapt appropriately.

The keyboard layout editor is still a bit unfinished, though: currently there is no way to edit the characters on a key yet.

This post will tell you more about the new features touch typing trainer component of the upcoming version of KTouch, but before I come to that, I will write a little bit about the approach I took to design the new user interface.

Design Principles

Actually this boils down to two simple points:

Act like a game

Learning touch typing is boring enough, the application one uses to achieve this goal should make the experience as much funny as possible while not getting in the way. A good way to do so is to borrow some of principles from video games which render them as engaging and addicting as they are.

Keep it simple

Learning touch typing should be possible for every literate person. After all, KTouch is an educational application targeted at especially at pupils. So knowledge about technical details like the existence of keyboard layouts can’t be assumed. The user interface hast to be designed accordingly.

The New Features

The new user interface is split into several screens, each responsible for a certain feature set. This keeps the complexity low, because it reduces the amount of controls visible at any given time and guides the user on their way through the application.

1. The Welcome Screen

This is very first thing a new user of KTouch will see and it is the only setup necessary to start training. It should be pretty much self-explanatory.

2. The Home Screen

From here the user picks a lesson to train on out of the courses matching their current system keyboard layout. It also provides access to profile managment, the keyboard layout and course editor and the configuration dialogs.

3. The Trainer

That’s the part of the application a typical user will spend the most time on. Therefore extra effort went into this screen to make its operation as smooth as possible. Every dynamic part of the user interface is animated in a nice and unobtrusive way. Small features, like stopping the time when the window looses its focus, help to improve the overall training experience. Users wanting an absolute minimum of distraction while training may choose to hide the keyboard and now also the real-time statistics readings in the application settings.

There is more

Careful readers will have noticed, that I mentioned an editor component — this one deserves a post on its own.

After completing a lesson, the user won’t return immediately to the home screen. Instead a special summary and statistics screen is shown. Right now it is still largely unfinished, so no screenshot right now.

The good news is that the KDE e.V. gave me the opportunity to attend to the upcoming Randa 2012 sprint. Looking at my todo list, this summary screen will be among my top priority tasks I want to work on in Randa.

Organizing a sprint of this scale costs a lot of money. So if you able to donate some money, please do so. For me as a volunteer developer such an event is an exceptional opportunity, your donation makes it possible. Thank you!

I’ve been developing for KDE for quite a while now, so I figured I should start blogging about what I’m up to. This being my first post I think it’s best I introduce myself and write about what I have been able to achieve so far.

My name is Sebastian Gottfried, I’m currently studying Computer Science and in November 2011 I’ve started hacking on KTouch. My main incentive was to learn and master new technologies, this time my main interest was Qt Quick. Why did I choose this project in particular? First I gained much personal profit from this application as I’ve successfully learned touch typing with it. Secondly the application was basically unmaintained and in a state deserving a facelift. Being a game-like application of some sort Qt Quick seemed to be the obvious choice to tackle such a task. Lastly I thought rewriting KTouch’s user interface was a big enough task to actually learn something and small enough to remain achievable.

Well, ten months later my code is still not in a releasable state. Maybe I underestimated a bit the amount of work necessary, but there is continuous progress and the current plan is to release this new version with KDE SC 4.10. For the time being, here’s a screenshot documenting the current state of my version.

As one can see the difference to the currently released version of KTouch is quite dramatic. I will write about the new features and my plans in more detail in future posts. If anyone wants to try it out: the code lives in KTouch’s Git repository in the branch next.