[Development] QML Runtime

[Mohamed Fawzi]

yup forgot reply all by accident,... sending this to the ML now

I like the idea of a single binary, but if we want to deprecate QML 1 later, two binaries might still be ok.
What I find important is working toward having a single binary in the end.

ciao
Fawzi
________________________________________
From: Alan Alpert [416365416c at gmail.com]
Sent: Wednesday, January 09, 2013 5:19 PM
To: Mohamed Fawzi
Subject: Re: [Development] QML Runtime

The qml binary is supposed to be the solution to the split. Let it be
the one binary, and qmlscene/qmlviewer can be deprecated.

--
Alan Alpert

PS: Did you forget to reply-all by accident? Better than the inverse I suppose.

On Wed, Jan 9, 2013 at 7:51 AM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
> Kay answered better that I could have: most of the debugging/monitoring is already plugin based, and it is just matter of loading or not.
>
> As Kay said the split qtquick1/qtquick2 already creates headaches: when we have a .qml file we have to look at the imports to
> (most likely, as the import QtQuick is almost for sure present) know if it is 1 or 2.
> Still it might fail, and then we have to guess the correct default from the context...
> This not just to run, but also to set up the correct imports, and so have the correct highlighting.
> I can understand the split, but I don't like it.
>
> If one manages to have all the differentiation in loadable plugins, then it is possible to at least not increase the number of binaries,
> and possibly even reduce it to one, and still only "pay" for what you use,
>
> Fawzi
> ________________________________________
> From: development-bounces+fawzi.mohamed=digia.com at qt-project.org [development-bounces+fawzi.mohamed=digia.com at qt-project.org] on behalf of Alan Alpert [416365416c at gmail.com]
> Sent: Wednesday, January 09, 2013 4:10 PM
> To: Koehne Kai
> Cc: Sorvig Morten; development at qt-project.org
> Subject: Re: [Development] QML Runtime
>
> On Wed, Jan 9, 2013 at 12:41 AM, Koehne Kai <Kai.Koehne at digia.com> wrote:
>>> -----Original Message-----
>>> From: Alan Alpert [mailto:416365416c at gmail.com]
>>> Sent: Tuesday, January 08, 2013 5:43 PM
>>> To: Koehne Kai
>>> Cc: Sorvig Morten; development at qt-project.org
>>> Subject: Re: [Development] QML Runtime
>>>
>>> [..]
>>> Technically you could achieve the same thing with one big binary instead of
>>> several smaller ones. I prefer the several smaller ones approach, because it's
>>> simpler and more efficient. You can technically use the runtime for
>>> development in the same way you use a webbrowser, but for serious QML
>>> development I think the answer will always be Qt Creator.
>>
>> Well, at the end of the day the different runtime alternatives also will show up in Qt Creator (we e.g. offer to run a certain .qml file explicitly either by qmlscene or qmlviewer , since there's AFAIK no bullet-proof way to find out the right runtime by just looking at the file). But granted, we can make sure that the defaults are sane, so people usually just press run.
>>
>> Still, we've already qmlviewer and qmlscene, now comes qml ... from the users perspective it would be good to have _one_ binary to rule 'em all :)
>
> Which one?
>
>>
>>> Note that if the qml binary works sufficiently for basic development as a
>>> more generic runtime, qmlscene and qmlviewer could theoretically move to
>>> Qt Creator (or go away, depending on what Qt Creator wants).
>>
>> We had that before - Qt Creator still ships a pimped version of qmlviewer called qmlobserver that adds the debugging API that didn't make it in 4.7.x (but was added to QtDeclarative in 4.8.0). Anyhow, this caused quite some headache: The binary has to be compiled with the target Qt version, which is done semi-automatically from within Qt Creator, but for a lot of cases fails, e.g. for embedded targets. Another example was the original qmlplugindump, which was first part of Qt Creator. This too caused headache, so we moved it to Qt ... Really, I don't want to go back , these tools are much more bound to Qt than to Qt Creator (and could also be used by other IDE's too).
>>
>>> As specialized development tools they should fit into the Qt Creator story
>>> properly. An example would be if we had a separate development tool for
>>> running QML it would be nice to integrate the performance profiler - like
>>> QtCreator has already done.
>>
>> The profiler and debugger works out of the box for any QML application, with whatever runtime. The server part is part of QtQml/QtDeclarative, and the qmltooling/qmldbg_tcp plugins. So no additional work needed for this.
>
> I know the implementation is in qtdeclarative, but the unified UI
> isn't. To use the profiler you need to run a separate tool to
> qmlviewer/scene and I don' think there a UI added for the debugging
> protocol at all in that repo. I doubt that users ever use this outside
> of an IDE (although you're right that other IDE's can use them -
> that's a big plus).
>
> --
> Alan Alpert
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development