[Development] qmlbundle vs Qt Resource System

[Oswald Buddenhagen]

On Tue, Aug 13, 2013 at 12:14:26PM -0700, Alan Alpert wrote:
> On Tue, Aug 13, 2013 at 11:42 AM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
> > if you do AOT compilation into a platform-specific format, the correct
> > solution is to compile it into a proper binary (which would typically
> > also contain the compiled qrc data).
> 
> That's what we're talking about - except that the binary may not
> contain a native main in the case of a QML only entry point.
> 
my point was that this is a non-usecase. when you go native, you can
(and should) use the native "container format" for code, too - a plugin.

> > when you then have a platform which supports multiple variants in one
> > bundle (e.g., android and osx), you'd do that bundling at the os level.
> > in either case there is no point in having multi-platform support in the
> > qrc system.
> 
> So we'd have a cross-platform API (possibly just the build system),
> which developers use but internally is just the platform-specific
> method of bundling architecture variants?
> 
not sure what you mean.
as far as the bundled application goes, it would be multiple separate
binaries; that they would be bundled at the os level would be opaque to
them (fwiw, it would be actually possible to make a separate .rcc file
which is bundled together with the executables to avoid that the assets
are duplicated, but that's an internal optimization).
but the asset system as a whole should indeed be abstract enough to
enable all kinds of deployment types and weird optimizations behind the
scenes without changing a single line of code (except in the build
system to flip the switch).

> > - anything platform specific (plugin code or just precompiled qml). in
> >   this case you comple a proper plugin (and any plain qml and other data
> >   is included via qrc into the binary). you cannot reasonably compile
> >   the qmldir into the plugin, because opening it just to check what is
> >   in that plugin would be prohibitively expensive. ergo the qmldir needs
> >   to be transformed into the new-style json-based plugin meta data.
> 
> I'm not following you here. In both cases there's a second file
> outside the plugin, it's contains the same data, why does it have to
> be JSON?
> 
you missed the point. the json file is the *source*. it gets compiled
into the plugin to make the meta data quickly accessible without
properly loading the plugin (as that is slow and has side effects).

> This plugin is not loaded like the other Qt plugins, it's loaded via a
> different path triggered when the QML engine reaches an import
> statement. The import statement points to a specific directory, we
> need a specific file in that directory to be or point to the plugin
> and the plugin meta data files don't fulfill that usecase (yet, I
> suppose they could be extended?).
> 
yes, it *must* be extended. you must make the system find the plugins
themselves, not the qmldir files.

> >   currently the qmldir also contains the plugin name to load. this must
> >   be changed, because it's a) counter to the atomic bundle (one file)
> >   idea
> 
> The important thing about the atomic bundle idea is that the number of
> files is O(1), not 1 specifically. But if we had everything in one
> bundle, we would make that the module target instead of qmldir in the
> compiled case.
> 
right. to support the braindead build/packaging systems which are unable
to treat a directory as a single object.
but let's aim for "1" - it sure looks achievable without much trouble.

> >  and b) it's meaningless in case of statically linked plugins. see
> >   the discussion in the relevant reviews.
> 
> That's a separate issue, qmldir is already meaningless for statically
> linked plugins but having a different target in URL based module
> imports isn't going to help (we need non-url based module imports).
> 
url-based imports sound plain wrong to start with. there should be base
urls as one option of defining roots, but the actual namespace of
imports must be entirely abstract. then it doesn't matter whether they
come from free-flying qml files, qml files in qrc files (linked into the
binary or free-standing .rcc), qml files in platform-specific assets,
plugins, statically linked plugins, or network resources.