[SailfishDevel] Path to main qml in resource file - not found whatever I try

[Thomas Perl]

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