Google Summer of Code, Porting Keyboard KCM to Qt Quick!


I am Gun Park, and I’m excited to finally join the wonderful KDE community through this amazing opportunity called Google Summer of Code 2018. Thanks for all the people that have supported and led me to this journey!

My project is porting the Keyboard configuration module in System Settings to the modern Qt Quick framework, with Wayland in mind. Right now, it’s only capable of configuring Xkb. But Xkb alone is useless without an IME when trying to input languages like Chinese, Japanese, and Korean. So far, if you spoke one of those languages, you had to go to the command line, and manually install fcitx and the corresponding module for your language in order to use your language at all. So I’m planning to add a seamless interface for configuring the IME, to do all that automatically.

Currently the Keyboard module codebase is ancient, depends on a lot of legacy stuff, and a bit messy after standing the Test of Time. It needs a new backend, and a fancy new UI with modern Qt Quick too.

So far I have been experimenting with QML, and have replicated the existing interface in QML. But it seems like they have to be changed a lot. Let’s look at them over.

This is the first screen you see when you go into System Settings -> Inputs -> Keyboard (actually, my replica of it in QML):

Hardware Panel

Also the second panel:

Layouts Panel

The third panel, “Advanced”, is a bunch of miscellaneous settings from the xkb configuration file, and not all of them might be necessary, and they could certainly be placed in better places. So this needs to be completely redesigned with collaboration with the KDE Visual Design Group.

I have also been learning how QAbstractItemModels work, and my mentor told me about how we can use these models and proxy models to make the program much more flexible and easy to work with. I could definitely see why, and I thought this was very cool. So I have been experimenting with the layouts and the keyboard model’s models.

The current backend relies on legacy libraries like xlib and xkblib. We need to transition to a libinput-based solution. (This seems like the biggest work we will need to do, but I still don’t know a lot about it.)

That is what I have figured out so far, thanks to the immense help from my mentor Eike Hein, as the coding period starts.

Like what you read? Give Gun Park a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.