[Development] QML Tooling Renames (was: Pending decisions on co-installation)

[Alan Alpert]

On Tue, Nov 20, 2012 at 4:04 PM, Chris Adams <chris.adams at qinetic.com.au> wrote:
> Hi,
>
>> > There are two points I'd like to add to the discussion. Firstly
>> > qmlbundle isn't
>> > really useful yet, I'd advocate moving it to the playground or somewhere
>> > outside the qtdeclarative module until it's done.
>>
>> I've been wondering about this too. There's zero documentation of it right
>> now, and I guess nobody still active here really knows whether the whole
>> bundle idea works, or not. Note though that the 'bundle' also appears in
>> public API, namely QQmlFile  , which features e.g.
>> bundleDirectoryExists(),bundleFileExists(), bundleFileName().
>
>
> The idea works, I don't know whether the implementation does (I don't know
> how far along it is, at all).

 I agree the idea works, but it looks like the implementation isn't
quite there yet. The tool creates bundles, but it doesn't look like
there's any way to launch them. Sounds like merely 'half-working'.

> For those following along at home who might not know what we're talking
> about, basically qmlbundle is a tool for developers, so that once they've
> finished writing their application, they can "bundle" everything into a
> single file.  All QML documents and JavaScript resources and images and
> whatever else get bundled together and a simple table of offsets for all
> files in the bundled directory structure is prepended.  File loads become
> mmaps/memcpys of regions from FileOffset in the loaded bundle.  Thus file
> i/o is greatly reduced, when loading the application - which can have huge
> impact on load times (especially if they've written a lot of QML documents
> which define custom QML types).  There is also the chance to preprocess all
> of in the input files (minimising/obfuscating to reduce parse time,
> rewriting some binding expressions into v4-able form if possible, and so
> on).
>
>>
>> Alternative: Keep it in the sources for now, but don't install it by
>> default.
>
>
> Sure.

The ruling for 'private' tools is vague to my knowledge, so I can see
this happening too. But I'd prefer it to be left off in a separate
branch or repository like unfinished features are expected to be. If
it's not inconvenient for the development of the feature, it would
help clarify that the feature is not ready for release.

--
Alan Alpert