sebastiangottfried at web.de
Fri May 4 09:14:34 UTC 2012
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.
More information about the kde-edu