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 [[email protected]] 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 <[email protected]> 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: [email protected] > [[email protected]] on behalf of > Alan Alpert [[email protected]] > Sent: Wednesday, January 09, 2013 4:10 PM > To: Koehne Kai > Cc: Sorvig Morten; [email protected] > Subject: Re: [Development] QML Runtime > > On Wed, Jan 9, 2013 at 12:41 AM, Koehne Kai <[email protected]> wrote: >>> -----Original Message----- >>> From: Alan Alpert [mailto:[email protected]] >>> Sent: Tuesday, January 08, 2013 5:43 PM >>> To: Koehne Kai >>> Cc: Sorvig Morten; [email protected] >>> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
