For those interested in the matter, the discussion has now moved to codereview.
https://codereview.qt-project.org/#change,43539 adds the QQmlApplicationEngine https://codereview.qt-project.org/#change,43540 adds the qml tool using it The one thing missing from QQmlApplicationEngine is the resolution of different paths for different platforms. I'd be interested in ideas on how best to expose that, it might even be part of a more general device-independent code discussion. But I think that can wait for the next patch to QQmlApplicationEngine, it's still useful for the cases where you know your platform/path already. I'm aware that a lot of people are on holiday break, so these changes won't be merged for two weeks at the earliest. Gives most people who want to look the chance to do so. -- Alan Alpert On Thu, Dec 13, 2012 at 11:59 PM, Koehne Kai <[email protected]> wrote: >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On >> Behalf Of Sorvig Morten >> Sent: Thursday, December 13, 2012 4:55 PM >> To: [email protected] >> Subject: Re: [Development] QML Runtime >> >> >> On Dec 13, 2012, at 2:06 PM, Koehne Kai <[email protected]> wrote: >> > >> > It's there because there are different conventions on different OS >> > where the .qml files should be (relative to the binary). E.g. on Mac >> > its unter .app/Contents/Resources, on QNX it's app/native, on Android >> > it's "assets:/" ... >> >> This is a deployment issue we have to solve, so far using resources and qrc >> have proved most robust in my experience. > > It's indeed the most robust. Actually I changed all the qtdeclarative > examples just last week to use qrc:// to make them working in all scenarios > (shadow build, .app folders, installed vs non-installed, launched through > qmlscene). Anyhow , we didn't go for qrc:/// in the Qt Creator templates so > far because > > - on Symbian, embedding all the resources in the binary means that they're > two times in memory (that at least what Alessandro told me. Anyway, this > point is mood for Qt 5). > - It requires the developer to add every resource that he adds on the file > system also to the resource file (and he only finds out at runtime if he > forgot it). > - It prevents incremental deployment/ fast turnaround cycle on embedded > (you've to rebuild for every change). > - It will obviously not work with projects not having a binary as the entry > point. > > So all in all I still think that deploying files is the more hassle-free + > future proof approach for developers, and we should rather overcome the > issues in the Qt libraries + qmake to make them work without lots of template > code. > >> Could this be set controlled by >> QDesktopServices::DataLocation? (or a new enum value). > > I think DataLocation serves a different purpose (E.g. on Mac it's the > Application Support folder, which is to "be used for any data that supports > an application but is not required for it to run.", while we're talking about > read-only, essential data. Maybe > QDesktopServices::[Application]AssetsLocation or > QDesktopServices::[Application]ResourcesLocation? > >> > >> > E) Using the 'right' way to show the top level widget, which also happened >> to be OS specific: show() vs showFullScreen() vs showMaximized(). >> >> We now have the ShowIsFullScreen style hint that platform plugin can set. >> Then the correct app behaviour is simply to call "show()" > > Great :) > > Regards > > Kai > _______________________________________________ > 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
