[Development] qmlbundle vs Qt Resource System

[André Pönitz]

On Mon, Aug 12, 2013 at 08:02:55PM +1000, Chris Adams wrote:
> [...]
>  However, what I do know for sure is that nobody ever tried to come up
>  with a set of requirements and discuss the topic with the rcc
>  maintainer.
> 
> 
> I don't know too much about the specifics of the qmlbundle implementation
> at all, but I do know at least some of the requirements which drove its
> development.  As to whether or not qrc would have worked for these
> use-cases is a different question (and one which I also know next to
> nothing about, so I'm not trying to answer the "why wasn't qrc used"
> question at all here).  But some of the things are:
> 
> 1) Since a QML module can consist of just qmldir + .qml documents + .js
> resources, we can't require a plugin or executable into which the bundle
> gets embedded, to exist at distribution time
>
> 2) Going forward, including the compiled QML typedata into the bundle as
> a two-stage build step was a goal.  This would greatly speed up
> application startup time for obvious reasons (no need to parse the
> bundled .qml files, no need to compile the parsed tree, just mmap the
> compiled typedata and do the fixups for the virtual address offsets,
> etc).

Bundling architecture-independent data with an architecture-dependent
binaries is the bread-and-butter job of the Qt Resource System. It's
not restricted to that, but it's what the resource system is meant for. 


As far as I can see, there are two use cases here:

1. Having a couple of .qml, .png and whatever non-executable, but
potentially target (resolution...) dependent resources loaded and
"run" in some kind of viewer application.

-> Smells like the resource system might be suited (rcc -binary,
   recognize/load result into viewer application)

2. Bundling a couple of .qml, .png, and whatever architecture-
independent data together with some real compiled code.

-> Smells like the resource system might be suited (a shared object/dll
   with compiled-in or dynamically loaded resources as usual)


I don't see any obvious reason to dismiss the existing ressource
system in either case, nor to run a new-from-scratch approach instead.

I am not (yet) aware of another case.

So what do I miss?


>  The whole resource code (core + the rcc commandline tool) is barely
>  3000 lines of code. Might be not the nicest, nor the most obvious
>  code ever, but field-proven, and "just works". Someone might even be
>  able to look at it and find out.
> 
>  <sarcasm> But why bother when re-inventing wheels is so much more
>  fun.  And of course, the few thousand more lines of qrc tooling
>  integration is nothing to be concerned of, either. It will magically
>  adjust itself, at no cost. As usual. </sarcasm>
> 
>  The refusal to even only consider re-use of existing assets is a huge
>  sink of resources.
> 
> 
> It's not about fun, in many cases, it's about pragmatism.

For fifteen years, Qt application startup time has never been a serious
issue, thanks to native code and proper compilation. Even declarative
UI elements have been compiled by default, and All Was Well.

If now, with machines a dozen times beefier than before, startup times
suddenly become an issue, a flag should be raised.

A _pragmatic_ approach to the problem would certainly not be to add
more workarounds and re-invent more wheels, but to go back and find
out at what time what new feature caused what part of the damage.

For starters, the whole idea of shifting computational effort from build
time to run time by replacing properly compiled native code with run-time
interpreted code _and expect acceptable performance especially on
resource-constraint embedded and mobile target systems_ looks bizarre
enough to justify a reality check.

Andre'