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