There is now a new sidebar offering all the courses KTouch has for a total of 34 different keyboard layouts. In previous versions, KTouch presented only the courses matching the current keyboard layout. Now it is much more obvious how to train on different keyboard layouts than the current one.

Other improvements in this release include:

• Tab focus works now as expected throughout the application and allows training without reaching for the mouse ever.
• Access to training statistics for individual lessons from the home screen has been added.
• KTouch supports now rendering on HiDPI screens.

KTouch 19.08.0 is available on Flathub, on the Snap Store, and is coming to your Linux distribution.

Last week I was attending the LinuxTag 2014 in Berlin. The plan was to give three workshops--each day one--introducing potential contributors into the wonders of KDE development and otherwise enjoy the event. But Jos had other plans for me: he convinced me to man the KDE booth in our shared OpenSUSE/Owncloud/KDE area, so that's what I did, at least for most of the time. This rewarded me with lots of feedback from our user base and I was able to help quite some users with their favorite KDE issue. Also I met a few of my fellow KDE contributors and had a chat with them. All in all it was a fun experience.

The workshops themselves were pretty successful. I had not that much guests, but the few who showed up had all a genuine interest in the topic. In case your interested: The slides for the workshop are here, the sources of mentioned demo application--yet another clone of the ubiquitous 2048 game--may be obtained from a scratch repository of mine.

The plugin now provides three new QML types: ChartModel and Record. The first type implements QAbstractTableModel, so it can directly hooked up with a chart as its source model. The other allows to easily describe the model's data in QML making it trivial to draft a simple QML chart demonstration:

import QtQuick 1.1
import org.kde.charts 0.1

Rectangle {
    color: "white"
    width: 800
    height: 400

    ChartModel {
        id: chartModel
        columns: 2

        Record {
            values: [0.1, 0.2]
        }
        Record {
            values: [0.25, 0.3]
        }
        Record {
            values: [0.5, 0.5]
        }
        Record {
            values: [1.0, 0.75]
        }
    }

    Column {
        anchors.fill: parent
        anchors.margins: 20
        spacing: 20

        LineChart {
            model: chartModel
            width: parent.width
            height: parent.height - legend.height - parent.spacing
            pitch: 180
            dimensions: [
                Dimension {
                    id: funDimension
                    color: "#ffd500"
                    dataColumn: 0
                    minimumValue: 0.0
                    maximumValue: 1.0
                    label: "Fun"
                    precision: 0
                    unit: " %"
                    unitFactor: 100.0
                },
                Dimension {
                    id: profitDimension
                    color: "#ff0000"
                    dataColumn: 1
                    minimumValue: 0.0
                    maximumValue: 1.0
                    label: "Profit"
                    precision: 0
                    unit: " %"
                    unitFactor: 100.0
                }
            ]
        }

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

            LegendItem {
                dimension: funDimension
            }
            LegendItem {
                dimension: profitDimension
            }
        }
    }
}

The file can be directly run with qmlviewer, in fact I have used it to generate the screenshot in the original announcement for this project.^[1] There are no C++ components required anymore to leverage the charts plugin.^[2]

The way the demo employs ChartModel obviously doesn't reflect how most applications want to use the charts plugin. Static data isn't encountered what often after all. For this case ChartModel offers a set of methods to dynamically manage its data. I am currently developing a second, more complex demo illustrating their use.

Update Mar 12th, 2014: The seperate Value type is gone by now. I have updated both text and the code sample reflecting changes.

kqtquickcharts is a Qt Quick 1 plugin for beautiful and interactive charts. It offers QML elements for line and bar charts to present numeric data from a model implementing the interface of QAbstractTableModel.

The plugin will see its first release as a part of KDE Edu with KDE SC 4.13 on April 16, 2014. Future efforts will be aimed at making the plugin viable for pure QML applications and to port it to Qt Quick 2.

This project is the result of an effort to make the charts originally developed for KTouch available to a greater audience. The first new application to make use of the components will be artikulate, an upcoming KDE Edu application to improve one's pronunciation skills.

It has been quite a while since my last post. My time available for KDE development has dried up since then considerably, limiting the scope of my work to basic maintenance and user support. Time for actual programming, let alone writing about it, was rather scarce.

Luckily this state has largely come to an end. And on top of that I was invited to attend this year's KDE Edu sprint in A Coruña. The sprint was, as usual, highly productive and motivating. Many thanks go to the KDE e.V. and GPUL for sponsoring the event, to KDE España for covering my traveling expenses and especially to José Millán Soto for organizing the event.

During the sprint, many discussions were held and plans were made, and there was, of course, a decent amount of time to for some serious hacking. For the most part I worked on KTouch, and the time was well spend. I was able complete my main goal for the next version of KTouch, 2.2 to be released with KDE SC 4.12.

So let's see what 4.12 will bring for KTouch.

Custom Lesson Support

The probably most missed feature from old version 1.x days returns to KTouch, only in much improved and extended fashion: an easy way to train on arbitrary text.

Technically spoken, this was possible since 2.0, because users could create their own courses and train on them. But the process is still cumbersome and too complex for the task at hand.^[1] In the old days one could just open a text file and get going. A feature like that is clearly missing.

This solved for the next version by introducing a new special course, the Custom Lessons course, always available right next to the normal built-in courses.

This new special course mostly acts like any other, training and statistics gathering works as usual. Clicking on New Custom Lesson brings up a stripped-down version of the normal lesson editor.

This has the nice side effect that the usual quality checks are also performed for custom lessons. The characters of the lesson text are matched against the current keyboard layout, so the user has a realistic chance to spot special or foreign characters he can't type before hitting them during training.^[2]

During my work on the custom lesson editor I took also some time to improve the actual lesson text editing experience. Now the editor has a toolbar allowing to load text files and to reformat lesson texts with long lines so they use the recommended line length.

The custom lessons are stored per user profile and keyboard layout, so one can train on different lessons depending on the specific situation.

One nice side effect of the re-introduction of this feature that KTouch is now finally at least basically usable under every keyboard layout, even for those it offers no courses for.

New Courses

Thanks to the to a some generous contributions KTouch will ship a few new courses:

• A new Farsi course including the corresponding keyboard layout data. Contributed by Seyed Ali Akbar Najafian.
• For the Spanish keyboad layout a new couse in Basque. Contributed by Alexander Gabilondo.
• And a course for the rather exotic Workman layout. Contributed by Peter Feigl.

Many thanks go to the respective authors!

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.^[1] 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 simple 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.^[2]

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:

$ 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:

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

{% img /images/screenshots/ktouch/welcome20120914.png%}

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.