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
signature.asc
Description: This is a digitally signed message part.
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp