KTouch

[Aaron J. Seigo]

On Tuesday, May 15, 2012 16:20:12 Laszlo Papp wrote:
> > 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. 

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

> Qt Components contain more APIs for Symbian, MeeGo and so forth.

which is indeed unfortunate.

> > a) think about your users
> 
> I do, including also the group not using Plasma for some reasons.

there is very little connection between the Plasma Desktop or Plasma Active 
shells and the components. the fact that it is shared by both Desktop and 
Active despite those being separate projects with different device targets and 
use cases says a lot.
 
> > 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

yes, i'm aware of this. it is a very young research project. 

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.

if/when QML Theming works, is released and gets real world use and then 
maintenance support we'll definitely be interested in utilizing it.

> >> 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.

wrong. we already do this.

> On the other hand, Qt Desktop Components seems so.

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..)

* Qt Desktop Components currently relies on QtWidgets, uses the legacy theming 
system and is therefore a short term solution

* now we have the QML Theming research project and that might bring something 
new again

* we still don't have something for mobile

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.
 
> > 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. 

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 ..)

and for when you do need/want a separate UI .. that is already supported in 
Plasma Components as i noted in my last email. you can have a *completely 
different UI* from the same package; even sharing some of the UI and having 
some of it different. so the whole "different UI for desktop" thing is not 
relevant.

> 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.

that might be because nobody has written the Harmattan implementation for 
Plasma Components. perhaps because it's seen as a dead platform, kdelibs 
delivery on that platform is a bit unclear and KDE devs who have targetted it 
have charged forward without collaborating with others who are working on QML 
in KDE.

> 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.

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.

> > 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.

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.

> 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.

fair enough :) 

> > 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. 

yes, i agree.

> 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.

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

for better or worse, that was exactly the QML vision. we'll see how the style 
project goes; would be nice if it works out, as it is what i recommended 1+ 
years ago in Olso.

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...

> 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.

that'd be great..

> 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 ?"

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20120515/6ade76fe/attachment.sig>