[Development] qmlbundle vs Qt Resource System

[Alan Alpert]

On Wed, Aug 14, 2013 at 2:48 AM, Oswald Buddenhagen
<oswald.buddenhagen at digia.com> wrote:
> 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:
>> [...]
>> > - 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).

Unless we extend the system (as you suggest below) this makes it
pointless because the only runtime meta-data really needed in the QML
file for a simple plugin is the line indicating where the plugin is to
be found.

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

You've failed to convince me that this *must* happen. The current
system works fine, this change would not fix the statically linked
plugin case, and the only advantage I see is that we'd be able to use
the JSON metadata - which is another change without any clear
advantage. Considering the thread started by decrying 'work for the
sake of it' I think we need some compelling reasons to make that
change.

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

Let me try explaining it again: imports are in an 'entirely abstract
namespace' but there's no mechanism for activating plugins in QML
outside of via directory URLs. Which covers all of those cases (save
statically linked plugins and some cases of free-standing .rcc) by
having the types resolved via a qmldir file in that directory.

--
Alan Alpert