ubuntu-phone team mailing list archive

[Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>]

Am 14.08.2014 um 13:58 schrieb Christian Dywan:
> On 14.08.2014 13:18, Michael Zanetti wrote:
> > On Wednesday 13 August 2014 15:42:08 Christian Dywan wrote:
> > > On 13.08.2014 15:10, Sergio Schvezov wrote:
> > > > On miércoles 13 de agosto de 2014 10h'01:17 ART, Michael Zanetti wrote:
> > > > > On Wednesday 13 August 2014 12:13:34 Timo Jyrinki wrote:
> > > > > > 2014-08-13 9:03 GMT+03:00 Timo Jyrinki <timo.jyrinki@xxxxxxxxx>:
> > > > > > > We could survive a bit longer by distro patching qtchooser (another
> > > > > > > workaround), but I feel that eventually we'd like to have more control
> > > > > > > on the QML app startups
> > > > > > For the Ubuntu specific new wrapper, discussion can continue on
> > > > > > ubuntu-phone.
> > > > > Hmm... What is the reason for not doing it like all the rest of the
> > > > > Qt world does it? That is, having the SDK template generate a
> > > > > minimalistic main.cpp and a qtquickapplicationviewer.cpp which does
> > > > > the adaption for the platform. Now that the SDK seems to handle
> > > > > compilation just fine IMO that would be the best option. Also
> > > > > considering that in case we need to update something in there,
> > > > > qtcreator already features a mechanism to automatically update just
> > > > > that part.
> > > > Only benefit I see is to be architecture all.
> > Fair point... Although I'd argue that in practice any application that has
> > value on multiple targets ships the one or other compiled plugin. I can see
> > how it is desirable to keep stuff platform independent if possible though...
> >
> > > > > Additional benefits would be to only have a binary to run instead of
> > > > > exporting paths, choosing some QQuickView wrapper and fiddling around
> > > > > with qml file paths on the command line.
> > > > >
> > > > > Br,
> > > > > Michael
> > > These redundant launchers doing the exact same thing all over the place
> > > would waste power, space and development time… for what gain?
> > Well, as I said, IMO it makes things easier. You get a binary you can run
> > instead of exporting import paths and passing qml files around on the command
> > line which imo saves development time. For the wasting power compiling that
> > file, I guess you're right there, but not sure if the amount is big enough to
> > make that an argument.
> I acknowledge the argument of development workflow.
> > On wasting space, I'd bet such a main.cpp would have a
> > smaller memory footprint than qmlscene (didn't measure it so I might be wrong
> > here. But in any case again a negligible difference).
> The footprint could be reduced by a replacement for qmlscene. It's not
> an argument in favour of a custom main.cpp.
If we would talk about footprint, we could also mention that with a 
main.cpp you can
pack your qml files into a resource file. These resources get compressed 
and packaged
into the binary. Which means the strings will be loaded faster and most 
likely the whole
application is smaller (but not the binary itself).  When you have lots 
of qml sources maybe much faster.
The drawback of course is that all of the data is loaded into memory 
twice (one time for the
data section of the binary and second time once qml has to parse and 
keep the AST/binary
interpretation of the QML sources) and in case you target multiple 
architectures the click package is most likely bigger because every
arch needs its own binary.
> > > The reason that much of the Qt world have custom launchers is in part
> > > due to the large base of C++ developers unlike the lion share of Ubuntu
> > > app developers who can't even read C++.
> > The good thing about this is that if you can't even read that main.cpp, you
> > don't have to. Just ignore it like the python scripts and Makefile we're
> > shipping which you probably can't read either in that case. Also this
> > discussion doesn't really sum up if you ask me. I constantly hear we need to
> > keep things easy for our devs that can't do anything. Yet we're asking them to
> > learn QML for the app, write tests in python and are shipping the most complex
> > build system I can think of. But having a 5 line autogenerated main.cpp (which
> > doesn't have a single * or anything) suddenly is too much. Sorry, I don't buy
> > that any more.
> Sure, if you ask me you should be able to have no build system other
> than the click packaging itself and you shouldn't need Python at all.
> Unfortunately now isn't the time to change any of that.
Ok, but how would you create compile and package your native backends then?
How would the IDE know which files are included in the project?
Except you are talking about inventing a own buildsystem that comes with
the click tools.
While I agree that this would be the cleanest solution its way too much 
work, look
at QBS, how long is it in the making yet and still not at a point where 
you can use it?


Also, a bit off topic, keep in mind that the qml and html projects are 
nice and easy to use for a start
and for the basic farting app. But you cannot do anything in QML, 
sometimes because
of speed, sometimes because you need to interface to a non Qt library or 
access system
APIs.
The learning curve you get when you need to make the step from a 
qml/htmlproject to a
project with backend is huge. So the question is, is it maybe better to 
ship always
projects that can be easily extended without the need to change your 
project type?

The learning curve gets even steeper if you need to think about "How do 
I create a QML plugin?".
We as everyday Qt devs know this stuff. But for the average app 
developer using mostly QML extending
his app directly in the main binary, without the need for creating a 
plugin, is probably much easier.

So in favour of the main.cpp:
-> You always have the same project type, no need to convert if you need 
to extend with native code
-> You can directly extend the application, no need for plugin loading
-> Faster startup time, because the QML source could be packaged into 
the resource file

Drawback:
-> more memory consumption for loading the application binary
-> the basic app click package gets bigger because instead of packing 
the qml sources just once
     you need to pack a own binary per target architecture


> I have no issue with generated code, see above, I just would like to
> clarify the real benefits of it.
> > > Also unlike Ubuntu components
> > > several Qt frameworks require C++ code to do integration magic to inject
> > > non-standard features which we do soley via QML engine features.
> > Don't really understand what you're trying to say here... But what I've seen
> > is while trying to make things easier for people who can't write apps it often
> > happens that you make things more complex for people that can. I'm not sure if
> > that really has the desired effect in the long run.
> We don't have anything akin to a MeegoApplication class for example. All
> the setup we do happens in Ubuntu.Components or by using MainView. So we
> don't *have* to replace the launcher.