ubuntu-phone team mailing list archive

[Christian Dywan <christian.dywan@xxxxxxxxxxxxx>]

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

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.

Attachment: signature.asc
Description: OpenPGP digital signature