KTouch

[Anne-Marie Mahfouf]

On 05/04/2012 11:14 AM, Sebastian Gottfried wrote:
> 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?
Moving the code to KDE git playground/edu.
https://projects.kde.org/projects/playground/edu
You need for that to create an identity on
https://identity.kde.org/register.php
then follow
http://community.kde.org/Sysadmin/GitKdeOrgManual#Requesting_project_migrations_from_KDE_SVN_or_Gitorious.org

One of the first thing to do then is to port the French keyboard to the 
new format so I can really try your app! ;-)

>> 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.
Yes. QML on the desktop is not KTouch problem, it's something that would 
be best to agree on generally in KDE.

Welcome to KDE Edu!

Best regards,

Anne-Marie