You assume correctly - QtQuick1 and Qt 4.8. But my qualms about pure
QML/JS has never been about performance.
it's more about portability between platforms, APIs available (I think
you just can't avoid at the moment digging into a little bit of C++),
and also somewhat about the separation between business logic and UI code.
But it all sounds good if C++ backend + QML UI is still easy and
supported.
I do agree pure QML/JS has many advantages. First of all it's easier
to start development for people unexperienced with C++. Second is what
you've already said, the independence of underlying CPU architecture.
You could have the same application running on x86 and ARM without
recompilation for example. At the same time, for me the ease of
cross-platform porting is more important than the relatively trivial
recompile needed for each target.
But I like what I've heard so far, and only wanted reassurance that
the C++ backend + QML UI is not forgotten when things go forward in
the currently preferred direction.
On Wed, Feb 13, 2013 at 6:30 PM, Zoltán Balogh
<zoltan.balogh@xxxxxxxxxxxxx <mailto:zoltan.balogh@xxxxxxxxxxxxx>> wrote:
I assume, that your experience comes from QtQuick1 and not from
QtQuick2.
QtQuick2 with the v8 JS engine is much better.
What you describe was the right rule with Qt 4.8 and QtQuick1. I
remember the struggling with QML when the N9's applications were
developed. By then, on that hardware using pure QML was wrong
idea. Time has passed.
I can promise that choosing C++/QML hybrid model as start will not
be impossible or complicated. It is your choice. All I say that
using C++ from the start will be slower, more expensive than
starting with pure QML.
The problems of cross compilation is just one of the issues. If
you stick to QML/JS then you can test your code on your Ubuntu
desktop and the same code will just work the same way on Ubuntu
phone. I think it is a significant benefit.
Zoltan
On 02/13/2013 05:46 PM, ajalkane wrote:
My experience is that pure QML/JS solution is suitable to only
quite simple applications. I have myself found the best practice
to be to do the UI part in QML/JS, and have the "business logic"
and models in C++. In fact, for portability between platforms I
think doing as little as possible in QML is preferrable. Ie. it
should contain only the UI code.
Your mileage may vary, and I'm certainly looking forward how this
approach works... but I do hope implementing a C++ backend is
still possible and not something that's overly complicated or
impossible. C++ plugins are perhaps more (coding) overhead in
many cases than should be necessary.
On Wed, Feb 13, 2013 at 5:27 PM, Zoltán Balogh
<zoltan.balogh@xxxxxxxxxxxxx
<mailto:zoltan.balogh@xxxxxxxxxxxxx>> wrote:
Hello Frank,
Please bother the SDK team :) the best what you and any
Ubuntu Phone application developer can do is to bother us
with questions and suggestions.
Actually the QML/JS does not rule out the finely crafted C++
plugins. Just the opposite!
We expect finely crafted C++ plugins designed in a generic
way so they could be reused by other applications and they
could be contributed to the SDK. What we do not suggest is to
use C++ where pure QML offers a viable solution.
The shift from a procedura to a declarative programming mind
is not necessarily trivial for a coder who have been doing
C++ apps for years. That is why I would suggest to all Ubuntu
Phone app developers to start with small and easy
applications and discover the strength of the declarative
programming.
Just translating a Qt/C++ code to QML/JS might not lead to
the best results.
cheers,
Zoltán
On 02/13/2013 03:30 PM, Frank Mertens wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi David,
thanks for the quick answer. I guess I'm trying to
rewrite my C++ models in JS then.
Let's see how much we can get out of QML/V8 when the
first phone image is released.
Thereafter we can then have a flame war on if we go
purely QML/JS or have lots
of finely crafted C++ plugins;) Until then don't bother
the SDK team to much! I really appreciate
the progress with the ubuntu-components -- gives me
sleepless nights, when I think what I could
do with these.
Greetings,
Frank
- -- gplus.to/frankencode <http://gplus.to/frankencode>
frankencode@freenode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined -
http://www.enigmail.net/
iQEcBAEBAgAGBQJRG5VZAAoJEMYU5+LCaHFcG8gIAKV7LddXISjrW647DyqadgdC
g3rd7A3ovUE4oZ/4xzcqQDxUcExgxVNZXwbqycWzMJK2RrvavmR0BXyHisxedDMK
cD/+ge9NdlYnuNc6wL6wvdBFJpF27/hOyKh4SWv/H4BEYNiHJ8PasS/fjRLE+2sM
CQtbTfmPVC4Yq17xjyb6ZJa6OJvsUElnadSCK32ouKJSuCLKCRdepybGl6YCcZnr
rrZNOVC86IaYQP1veisJPPdfxCT5baHET0JqWfoO6Bl52kMYif6Vbr0++eEYQnq0
bQCDH38R1PXXTXQp3D15pDZ1Lg6UYyed3Ejfha//vYSFrLMNFTPioUDkpqw/t5s=
=mJ1+
-----END PGP SIGNATURE-----
--
Mailing list: https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
<mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
<mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
More help : https://help.launchpad.net/ListHelp
