KTouch

[Laszlo Papp]

> Qt Components and the Plasma variety are API compatible. that's not
> accidental.

I am unsure what you mean. The Qt Components project does not have one
API. Qt Components contain more APIs for Symbian, MeeGo and so forth.
They are already not compatible with each other. Perhaps you mean the
Plasma Components API is compatible with one of them at least.

> if the goal is to have something that is easily packaged on specific target
> devices (N9, e.g.) then that is indeed a packaging and delivery issue and one
> that needs attention. to just say "forget using KDE libraries" is the answer
> also means "forget using everything useful in KDE libraries, rewriting it
> ourselves and lose integration opportunities".

I believe, this is an exaggeration. =)

I have not talked about anything else than just Plasma Components. It
is healthy in my opinion, if a developer does not prefer everything
from KDE. Perhaps, it is a dumb example, but if there is a pure Qt
project in KDE and there is a similar, but more matured and better
designed (this is not example for the exact Plasma Components case)
somewhere else, I would go for that. That would fit my need better.

Likewise, I went for Harmattan Components instead of Plasma Components
on Harmattan since that integrates better with the platform. I am
unsure if I did anything wrong about that decision.

> to be overly blunt about it, the N9 and friends family of devices are dead
> ends; KDE's libraries are not. factor that into your decisions.

I was not discussing N9 in this thread. I was referring to Plasma
Components and the Desktop relation.

> a) think about your users

I do, including also the group not using Plasma for some reasons.

> b) the themability allows the same code to be run on different devices (that's
> the real intent of that functionalit)

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

> c) the themability extends beyond "changing the colours and the pixmaps" and
> extends to device-appropriate functionality. have you seen, for instance, how
> scrollbars behave on the Desktop and Touch implementations?

Yes.

> d) themability is by far and away not the only reason to use the components.
> there are additional useful components included, integration with KDE library
> functionality (usually transparently behind the scenes) and an active and open
> development process that allows the components to grow alongside needs.

Yes, I agree. Plasma Components can exist as an extension
(upper-layer) and we can have our KDE styling solution for a common
component set, but then again: not everybody needs the "Plasma
extensions". As for me putting few some common elements up available
in Qt Desktop Components, does the trick.

>> even if this has the feature for that, it does not mean there is such
>> a replacement for the desktop player style in any case.
>
> there is exactly such a replacement.

Please note that I wrote "desktop", and not "plasma desktop". I do not
see how Plasma Components replace the common cross-desktop needs. It
seems to me it is tied to the Plasma Vision. It is not meant for being
a common component with various style set that other can build upon.
On the other hand, Qt Desktop Components seems so.

> first up .. if you use a Plasma Package to contain your QML, you can create
> device-specific QML files and they are loaded as appropriate, transparently to
> your application. so you can have a device UI and a desktop UI.

I do not think, this is such a simple question. I would personally
re-design the whole UI for desktop and mobile anyway. Yes, it is a
good thing if you can solve the "qml preprocessor"-like question, but
then again: I have tried out the Plasma Components on Harmattan, and I
think the Harmattan components really looked better.

I am sure it would be a no go for certain other platforms and  devices
as well. This is not against the Plasma Components project, so do not
take this as offense. :) It is like this with the Harmattan,
Fremantle, Symbian, Android and so on components as well.

> secondly, Plasma QML Components have Touch and Desktop implementations and
> which version is used is done based on the device the application is running
> on. the API is idetical for each, but the interaction and other aspects adjust
> as neecessary.

This is really not only a Plasma Components only approach, and was
reported way before the Plasma Components existed. Standardizing the
API, that is. I believe that was one reason behind putting the Qt
Desktop Components into the same repository as the Harmattan
components in the beginning. I just do not really see this use case
practical when you do not use the Plasma Active platform (based on
Mer, MeeGo, Arch, or something else), but some other platform.

> if you have real world issues with Plasma QML Components, please bring them to
> the plasma-devel mailing list. we are very interested in making them a
> comprehensive and solid solution to the needs people working with QML have.
> that's even more so the case as we are increasingly relying on them ourselves.

I do not think Plasma Components will replace everything, and that is
healthy that way. I would not force this set for every platform even
if there is a better fitting component set with the guidelines, styles
and so forth.

My real world issue is this: in an ideal world, we should not have
Button implementations in each component set (unless the Button is for
some reason designed for different purposes than the other Button, but
this is not the use case for each single and fundamental UI element).
We could just have different styling and so forth.

Hence, I rather spend my time with helping the Qt Desktop Components
for now (which was designed for this on desktop at least), and once
that is getting mature, I can help the Plasma Components project to
build a layer on top of that or so, or even a kde edu specific
component set and so forth, if needed.

I do not mind others working with Plasma Components, but I would first
like to get a base component set for desktop that might be stylable
and customizable later. Hence, my interest towards the Qt Desktop
Components. Surely, if I need to use the KDE "upper-layer" on top of
that later, I would just use that. :)

As for now, I do not have yet such reasons since the applications I
work on are simple enough; they can probably go for Qt Desktop
Components for now on my side. The findings and then discussions and
fixes of those with the contributor behind afterwards were pleasure so
far.

Best Regards,
Laszlo Papp