With respect to touch input, most parts of KDE can be handled very easily. However, one, imho, very important aspect, simply lacks all touch UI support: the lock screen (and also the login screen), right now, do not support touch UIs at all.
There is a somewhat recent bug report that requests the addition of virtual keyboard support to the lock screen but so far it seems that no solution is available yet. Personally, I was very surprised that such an, imho, important feature like a “proper” touch UI lock screen, is not available in KDE. Even the touch-optimized plasma-mobile/Plasma Active doesn’t offer a proper touch UI lock screen. With “proper” I mean a lock screen that really offers security features.
I played a little around and could at least get a KDE lock screen that shows an on-screen keyboard. My approach was to use Maliit in combination with the stock KDE lock screen. I am using Fedora as Linux distribution and installed Maliit as follows:
yum install maliit-plugins maliit-framework-qt4
The next step is to start the lock screen with Maliit as input method. This can be done manually as follows:
Once the lock screen is shown, clicking in the input field opens the Maliit on-screen keyboard. Note that this only works when run for the first time, when the maliit-server is started when the input field is clicked. Subsequent attempts on using this command line do not show the Maliit keyboard on the lock screen. Reason is that the lock screen is implemented such that it covers all other windows, including the virtual keyboard. The fact that the keyboard is shown on the first run may be a bug in the lock screen but I am not sure about this.
The fact that the on-screen keyboard is shown on the first invocation already gives a hint for a temporary solution. Killing all maliit-server processes before using above command line fixes the observed issue.
Right now, I use this hack as workaround. I created a shell script for killing maliit-server and starting /usr/libexec/kde4/kscreenlocker_greet. Then, I added a quick launch widget to my desktop for running the script. So, the result for me is that I can finally lock the KDE desktop and unlock it via an virtual on-screen keyboard.
This is quite a hack. I am event not sure how long this will work, assumed that the “workaround” presented here may be, in fact, (partly) a bug. However, I think, this hack already shows one possible solution. The only thing that needs to be done is to allow to display Maliit keyboards on the lock screen; allow to show the Maliit virtual keyboard window above of the lock screen.
Furthermore, I experimented with replacing the kscreenlocker_greet binary with a shell script. I moved kscreenlocker_greet to kscreenlocker_greet_bin and created a shell script named kscreenlocker_greet which calls the renamed binary with QT_IM_MALIIT being set. This way, all the built-in lock actions make use of this new approach. Unfortunately, when being called this way, the Maliit keyboard is shown underneath the lock screen; i.e., after unlocking via the normal keyboard, the Maliit on-screen keyboard is visible. As far as I understand, this is the intended way of how kscreenlocker should work and is a security feature; no other application are allowed to be shown on top of the lock screen. However, if it would be great if there was a way to define an exception to that such that the Maliit keyboard can be displayed in the lock screen. Then this whole issue could simply be solved by using the Maliit input method for the lock screen executable.
Maybe, a similar solution could be used to enable an on-screen keyboard for KDM. However, I didn’t look that much into this right now.