On 2014-04-24 00:36, Kim Foder wrote:
On Wed, 2014-04-23 at 22:53 +0200, tw_bolek wrote:
- manually edit Makefile and remove qml_install and qml_uninstall
- in .specs file remove /usr/share/myapp and %{_datadir}/%{name}/qml
lines
I usually do this by renaming the qml folder, create a new qml folder,
and create en empty qml file in the folder (otherwise the deploy fails).
This changes the path to files included in the resource, so they have to
be added again.
Both approaches are not optimal and work around a shortcoming of
libsailfishapp. The .spec file / .yaml file change will still be needed,
though.
Why do you want to use Qt Resources instead of deploying the files to
the filesystem?
Don't mean to be rude or something, but it is seriously SICK to have to do such
things to exclude a folder that is in a resource and thus it is no longer
needed. In Qt4.8 all I needed to do was to comment out one line
(DEPLOYMENTFOLDER) in .pro file, and on BB10 I just need to exclude asset in
bar-descriptor.xml.
It is rather irritating ;)
In general, there is no real advantage of putting the QML files into Qt
Resources. It doesn't "protect" your QML files in any way (see Lipstick
Pandora for an example, or just patch Qt if you are not used to objdump
and dealing with ELF files and the QRC format).
The default libsailfishapp approach therefore is to deploy your files
into the file system, and not into Qt Resources. However, we might want
to have an option that disables deploying for people who need their QML
files hidden in Qt Resources:
https://github.com/sailfish-sdk/libsailfishapp/pull/11
When this is merged, tagged and trickled into one of the next SDK
releases, opting out of QML folder deployment should be as simple as:
CONFIG += sailfishapp_no_deploy_qml
In general, I would recommend putting QML files in the filesystem; this
would allow (a'la webOS patches and more recently the homescreen
patches) to have UI tweaks from the community as a run-time option (of
course, your opinion could be that it's not a good idea that your users
can tweak the UI of your app; in that case, the Qt Resource option might
be a good way to make it a little harder for them - that is, until they
patch the QRC loader to handle that case as well for all Qt apps).
Looking farer into the future, DeltaRPM could have an easier time
creating update deltas for updating apps where just small parts of a few
QML files has changed (it's more difficult/less efficient if Qt
Resources are used, although something like Chromium's Courgette -
optimized for Qt/QRC use cases - could obviously help here).
Also note that you don't have to use libsailfishapp's config scheme, you
can also do everything manually. It's just a convenience library that
will give you mapplauncherd boosting and some path magic for free (and
makes some assumptions, such as that the qml/ folder is deployed
automatically, which makes things easier for all developers using the
default deployment method).
Obviously, pure QML (CONFIG += sailfishapp_qml) apps do not have that
option, because there by definition the files have to be deployed in the
filesystem (there's no main executable; sailfish-qml is used for launching).
HTH :)
Thomas
_______________________________________________
SailfishOS.org Devel mailing list
