KTouch

[Laszlo Papp]

Hmm, this is a bit longer discussion, so I am trying to spot the gist
of my opinion with as less line as possible for readibility.

> https://bugreports.qt-project.org//browse/QTCOMPONENTS-200

Oh, the "famous" bugreport. ;) Yes, that is at least a good point if
the Plasma Components API strictly follows this.

>> Which is precisely the goal behind the current research project for
>> the Qt Desktop Components. The recent update is available in here:
>> http://codecereal.blogspot.com/2012/05/qml-themingstyling-update.html
>
> yes, i'm aware of this. it is a very young research project.

Yes. I personally find this nice and promising.

> Plasma Components has already had releases and will continue to. chasing Qt's
> decision of the day when it comes to QGraphicsView, QML and SceneGraph has
> unfortuantely wasted much development time. so we're focused on producing
> things that ship and which will continue to ship for multiple releases into
> the future.

Yes, I am not saying it has not been a solution so far, but this might
need a re-factoring if the Qt Desktop Components or qml theming
research project goes somewhere. I do hope they do. I am already using
Qt Desktop Components in smaller applications.

> wrong. we already do this.

I am unsure then what the purpose of the Qt Desktop Components project
and the qml theming in general, if you already do this. I am
apparently missing some information. If this is really the case, there
should be a decent amount of overlap between those and the Plasma
Components project.

> well, here's the reality:
>
> * the idea of theme components was initially rejected by QML developers (i
> ended up pushing rather hard for this concept; spent a few days in meetings
> with them in Oslo at one point doing design work..)

Wow, nice of you at least!

> so i'm skeptical about betting on the future here and am much happier with
> components in our hands following the common API. instead of waiting for years
> for Qt to sort this out, we have decided to make something that works now.

I respect this. This is a good we have something here, but I am
personally leaning towards the future as well. I am trying to help
them as much as I can.

> it depends. for some applications this makes sense (e.g. okular, kontact or
> calligra). for others, it really doesn't (many games, edu apps, the make play
> live add-ons app ..)

I even did that for kanagram and khangman. I have even done that for
games in the sense of the Gluon player.

> that might be because nobody has written the Harmattan implementation for
> Plasma Components.

How can we do that ?

> perhaps because it's seen as a dead platform, kdelibs
> delivery on that platform is a bit unclear

I do not understand why. The packages are available from the Community
OBS just like all other Harmattan community packages. We have also
written up this documentation at the last sprint:
http://community.kde.org/KDE_Mobile/Harmattan

> and KDE devs who have targetted it
> have charged forward without collaborating with others who are working on QML
> in KDE.

Aaron, I went to the #active IRC channel few times, and asked
questions about the collaboration. Also, how to build kde-runtime
properly, with what profiles, which branches, and so forth. Just one
use case of those: remember for the UI dependency question in
kdeclarative. ;) Also, I have personally communicated as much as
possible with others, and I needed. I have also bothered Marco many
times. Perhaps not always visibly, but in query. :)

What exactly did you miss ? Perhaps, we can learn the lesson out of
that for the future. I have tried to do my best around the KDE
Harmattan efforts. I am sorry, if you are disappointed for some
reasons. Let us improve such things for the future. =)

> don't worry, i don't take it as an offence. but it's still wrong :) we are
> doing things fairly differently than the systems you list.

What is the difference in essence ? I mean QtComponents was also
targetted for fixing up the differences and make a unified interface
between projects. It somewhat failed in the end, but this is something
you also mentioned about the Plasma Components.

> it has nothing to do with API. the QML implementation of the component is
> selected at runtime depending on which device target the application is
> running on. Button, for instance, has a slightly different implementation on
> Touch vs Desktop .. and it's 100% transparent to the application. this is not
> an API compatibility but an internal design approach.

OK, I agree with that even if QtDesktopComponents, there is a lack for
mobile support, but this is ideally what you can also do between a Mac
or Windows machine with the QtDesktopComponents. The changes are
perhaps not so intrusive though than between a mobile and desktop
system.

> and what are the real options with a known future right now? we have platform-
> specific efforts and research projects in early development..

My option is QtDesktopComponents for now, as in: usage from "customer"
point of view, and also involved with helping them as much as possible
to get something out of those researches and work.

> hopefully it will also work very well with SceneGraph and not hurt performance
> by cheating the declarative model into a procedural one for painting behind
> the scenes...

As far as I understood the last update, the SceneGraphy study is part
of the research and what can be cooked out of the ingredients.

>> I do not mind others working with Plasma Components, but I would first
>
> i guess i misunderstood when you wrote this then:
>
> "I would not personally like to use Plasma Components on my desktop for
> several reasons. Would the current UI still be available or do you have a
> plasma-free replacement for that ?"

Perhaps, it is a misunderstanding (due to my non-native English human
being), yes. :-)

I would probably choose a different frontend than Plasma Components if
I have that selection. Like the KDE UI which is not shipped by the
aforementioned distribution(s) as experimental. This is merely KDE4
speaking. As for Qt5 (and perhaps even Qt5), I would use
QtDesktopComponents based for now and involve myself that way to
provide feedback, and patches if needed. The latter would not be
possible (separate branching with its continous overhead and so forth
yes, but that is inconvenient), if the Plasma Components is the /only/
accepted way for desktop.

Best Regards,
Laszlo Papp