KTouch

[Sebastian Gottfried]

Hi Anne-Marie,

thanks for the positive feedback :)

> KDE will soon release 4.9 and thus we have time to consider things for
> "after 4.9" as the KDE community does not know right now if there will
> be a 4.10 or if we move to the new kdelibs frameworks (as far as I know).
> 
> I personally think we should  move to your code after 4.9 (and work on
> it in between):
> - the code is modern, especially the separation logic/UI
> - you will maintain it
> - we have time to sort out problems
I agree that a release with KDE 4.9 is to soon. Feature freeze is around the 
corner and my code is simply not ready, yet.

So how should we proceed? Continue working on github for the time being? Or 
import the code into a new branch of the official repository?

> Problem to solve:
> - as Laszlo mentioned, relying on Plasma components is maybe not the
> best choice. The KDE community has no global solutions for QML
> components outside Plasma. I tried to raise this problem a few times
> inside the KDE project but went nowhere. I'll poll other KDE sub
> projects to see what they use and what is the best approach in the long
> time and in term of portability. Calligra does not use QML for desktop
> so far, not sure what KDE Games will do. In KDE Edu we use self-made
> components in KHangMan and Kanagram. The question so far as I see it is:
> will each app make it's own QML components or will we have a set of
> ready-made QML components already available (like the Plasma ones but
> not relying on Plasma). Could KDE Edu start such a set?

In my opinion, usage of the Plasma Components is preferable in comparison to 
creating an own widget set for QML.

All components live either in kde-libs or in kde-runtime, so their are no 
additional dependencies for KDE applications wanting to use them.

On top of that, they exist and they are maintained. Maintaining a complete 
widget set isn't a trivial task and our development resources are rather 
limited, so I would definitely try to reuse the existing code base.

Right now QML Plasma Components widgets feel a little bit underpowered in 
direct comparison to their QtWidgets counterparts, especially wrt to pure 
keyboard control and focus management, but I think these deficiencies are 
better rectified than starting over with a new implementation.

The only real argument I can think of against the usage of QML Plasma 
Components is that they have different look than the traditional QtWidgets.  
But as the Plasma Components are theme-able even this should be solvable.  

I think in the context of KTouch, which relies heavily on custom graphics, 
this is hardly a problem, or at least a rather small problem among lots of 
more important tasks, like the severe feature regressions, so I'm going to 
focus on these first.

Best regards,

Sebastian Gottfried