ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

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


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

Br,
Michael