ubuntu-phone team mailing list archive

[Kevin Krammer <anda.skoa@xxxxxxxxx>]

On Monday, 2013-05-20, Stuart Langridge wrote:
> On Sat 18 May 2013 18:41:34 BST, Kevin Krammer wrote:
> > On Friday, 2013-05-17, Stuart Langridge wrote:
> >> It is somewhere in between impossible and very nearly impossible to
> >> write a book reader in pure QML for Ubuntu Touch right now, sadly.
> > 
> > Well, QtQuick (assuming you wanted to refer to that UI framework when you
> > wrote QML) is a UI framework, not a data processing or application
> > framework. Those pieces are supplied by C++ code just like QtQuick
> > itself being implemented in C++.
> 
> Speaking purely for myself here, I don't agree with this. I know that a
> lot of experienced long-time Qt programmers think that apps should be
> written in C++ with Qt Quick solely as a presentation layer, but I
> personally believe that the more it can be possible to write apps using
> QML and JavaScript alone, with no compilation step or C++ requires, the
> more it becomes possible to engage developers in building for the
> platform.

I see your point but I was specifically addressing QtQuick which is solely a 
presentation layer, not QML generically.
However, QtQuick as one of the available type sets for QML shows that certain 
things are best implemented in C++, exposed to the QML scene as ready-to-use 
building blocks.

The more type sets you have available as part of the platform, the less often 
application developers will have to create their own. In this case my 
impression was that there are currently not components for rendering certain 
type of documents, neither into a QtQuick element nor into a buffer.

One important thing to keep in mind is that the JavaScript parts of QML is not 
the same thing as JavaScript for Qt scripting, i.e. focused on the needs of 
QML. While it is currently using V8, a very capable and extensive engine, 
there are considerations to create a custom egine, codenamed V4, that is 
reduced to work for the QML use case but does not incur the problems V8 and 
other "full" engines have, e.g. not allowed on restricted platforms like iOS.

> I certainly acknowledge that that's not entirely possible
> right now, that there will always be a space for C++ plugins, and that
> the platform should probably not grow to encompass all things! However,
> I'd like to see Qt Quick, and the Ubuntu SDK, extend more capability
> than it currently does to JavaScript programmers. The web is working
> out the same way: using HTML and JavaScript as a presentation layer
> only certainly works, but more and more capability is extended to
> programmers in those environments without having to fall back on a more
> "capable" environment server-side.

True, but in the case of HTML/JavaScript the browsers provide a closed system 
that is not really expandable by anyone than the browser vendor so they need 
to provide the option of adding functionality otherwise. Henvce their strive 
to provide better and better JS engines, even if that means not being able to 
provide the browser for certain locked down platforms.

Qt, as a framework that others build upon cannot as easily afford to pass on 
those platforms but since it provides other means of extending the provided 
features set it can compromise in scripting capability and there have been 
hints that they are at least investigating into that direction.

> like that with Qt Quick; what's preventing that is not a large
> technical chasm between the two, but a few trivial items such as QML's
> XMLHttpRequest not supporting some of the XMLHttpRequest v2 API that
> deals with binary data. As Kevin says here, one way to do this is to
> put most of the logic of an ebook app in C++ and compile for each
> platform, and that's indeed what I suggested in my original mail... but
> I'd love to see the final few tweaks happen to allow an app such as an
> ebook reader to be writeable without compiling anything, in the same
> way that a good proportion of the already existing Ubuntu Touch apps
> are also pure Qt Quick.

Sure, the very core concept of QML is to be agnostic of where the types 
developer can use come from. Whether the types are registered by the 
application startup code, by the application package or the platform doesn't 
matter.

So if registered by the application startup code is undesired, i.e. the 
application should be started by a generic "runner", then this still leaves 
the last two options.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

Attachment: signature.asc
Description: This is a digitally signed message part.