KTouch

[Laszlo Papp]

> That's a viable option once they get readily available. As far as I can see
> they have even compatible API wrt Plasma Components. Right now I would still
> prefer to use Plasma Components, because that's the option which is already
> installed on every single computer of KTouch's user base, at least since KDE
> SC 4.8.

Just for your information since I am not sure you are aware of this:
kdeclarative is shipped in the same repository as kdelibs, but the
fact is that it is now being still marked as "experimental" for some
reasons. I personally know why, I believe. Distributions like Ubuntu
or Debian ships this submodule as a separate package from kdelibs. It
is just as experimental for an end user as a qt desktop components
snapshot package.

> I thought kde-runtime is the place for run time dependencies for all KDE
> applications.  I guess virtually every KDE application depends on some
> components from kde-runtime. The old KTouch used kio, for example.

Meanwhile certain applications depend on kde-runtime, it is not an
ultimate deal. There are quite a few applications using kdelibs only
(ie. no kde-runtime usage). It cannot be generalized for the whole KDE
project. What we need is a solution KDE-wise, not for certain group.

> I think that's an exaggeration. KTouch stays a standalone application and
> won't turn into Plasmoid.

I have not said Plasmoid. I have just said Plasma in general as a
project which you are apparently using.

> I don't use any of the high level Plasma components
> like containments, applets, data engines or services, just some low level
> components to render buttons and such.

Again, that is kde-runtime, and not "low-level" enough for minimalized
needs hence not an ultimate solution.

> Once the Qt Desktop Components gets ready for general consumption, I'm more
> than happy to switch to them, but right now, I think the best option is Plasma
> Components.

In fact, back to your saying about that Plasma Components is
"stylable": I have just made a quick research, and that is how this
seems to me: The plasma components supports theming, working only in
Plasma environment. It is not generic enough deal and depends on the
plasma theme machinery. This only has the option for changing the
svgs, fonts and color schemes from the widgets using the
Plasma::Theme::defaultTheme() resources.

It would be possible to develop further on, however it seems to be
unneccessary for Qt5 in many aspects. As for KDE4, I am personally a
little bit opponent to deleting the KDE UI solutions. To recap: the
plasma theming support is not generic enough for our needs.

I have just discussed this topic in question with Daker Fernandes
Pinheiro who had been working on the Plasma Components last year and
now making a research project to explore the opportunities for having
a stylable qt desktop components. He is the author of this article:
http://codecereal.blogspot.com.br/2012/04/qml-themingstyling.html

Even he said that, "Plasma is the only true way" pushing is too
radical. What we have agreed upon, we should have a qt desktop
components with styling support. We should not have yet another
component set like Plasma Components, but more or less a style plugin
on top of the qt desktop components, residing somewhere closer to the
core than kde-runtime, as it is now. It should probably be a core
plugin in a more core framework under the kde frameworks umbrella. I
do not personally see the point of yet another component set. In fact,
the point is to avoid X distinct components set, and just having
different styles. That is how we see this topic in question, at least
with Daker.

That said, even KDE UI remains to stay in frameworks for legacy
reasons since at this point, there are still no ready-made
technologies around reusable right away. However, work in progress.
:-)

Best Regards,
Laszlo Papp