[Development] Another method of registering QML types

[Alan Alpert]

On Thu, Nov 8, 2012 at 12:49 PM, BRM <bm_witness at yahoo.com> wrote:
>> From: Alan Alpert <416365416c at gmail.com>
>
>> To: development <development at qt-project.org>
>> Cc:
>> Sent: Thursday, November 8, 2012 12:57 PM
>> Subject: [Development] Another method of registering QML types
>>
>> Currently, there is no way to register QML files as types from C++.
>> This is the exact same functionality that qmldir provides, but I think
>> there are situations where you'll want to do this progamatically
>> instead of with a qmldir file. There is a very specific example I have
>> in mind: Platform Components.
>>
>> I'm suggesting another qmlRegisterTypes function, one that takes a URL
>> instead of a C++ type:
>>
>> qmlRegisterType(const char* url, const char *uri, int versionMajor,
>> int versionMinor, const char *qmlName).
>>
>> https://codereview.qt-project.org/#change,39135 is a proof of concept
>> implementation.
>>
>> This would allow for a platform component import which looks like this:
>> if(platform=="desktoplinux")
>>     qmlRegisterType("/usr/share/desktop/components/Button.qml", uri,
>> 2, 0, "Button");
>> else if (platform=="meego")
>>     qmlRegisterType("/usr/share/meego/components/Button.qml", uri, 2,
>> 0, "Button");
>> ...
>>
>> Except that the strings would also be generated procedurally, instead
>> of having a dozen lines of code per component type.
>>
>> The function isn't strictly for that usecase, there are other cases
>> where you might want dynamically directed types. The other case that
>> comes to mind is if you have an application with built-in types and
>> you want to add a file from qrc as a type to outside files (or
>> vice-versa). It would be nice to hear other usecases if anyone has
>> them, to ensure this API can meet those requirements.
>>
>> Any comments on this suggested addition to the QtDeclarative public API?
>
> Sounds interesting. Here's another potential use case: server-side interface definitions.
>
> I have a system now where QML (actually its predecessor QtScript) was of interest to me (haven't gotten to using it yet) so that I could put interfaces for the system in a (trusted) server component.
> The generic (multi-system, multi-customer) user interface would have theoretically downloaded the interface descriptions (e.g. QML files) and then loaded them.
> I never did it at the time as I hadn't figured out the storage side, and got into doing some custom widgets for some of the functionality.
>
> >From this perspective it would be useful to be able to hand it a QByteArray containing a QML file, or http/ftp/custom URLs for remote QML file access.[1]
>
> One thought - it would probably be good to have a function that could return other URLs that would also need to be loaded for successful use, perhaps as an error condition, or qmlRegisterType() would need to be able to read the embedded URLs and recurse to do the same.
>
> As I haven't gotten into using QML yet, I don't know how well QML would meet that kind of use. It'd be a really cool one to support though.
>

I think this is already supported, in that the URL transparency of QML
means that if you have local assets with a remote file, it should
automatically load the assets remotely to go with it. I might need a
more specific example of what you mean if you're talking about
something not already supported, but I know the following is
supported:
If you have a http://remote/Image.qml with code like Image { source:
"graphic.png" } the png will be fetched transparently.

> [1] Yes, I realize that it would enable some on-the-fly stuff that might generate some security concerns. I would suggest that be documented so that users know they have to load appropriately trusted materials if we did that. They could just as easily write it to a temp file and load the temp file using the regular API too.

That is the current alternative. You can do the exact same thing by
writing out a temporary qmldir file to disk - it's just that I think
that approach is horrible and unnecessary. (This is actually more of a
security risk, because you could be overwriting the qmldir files for
other imports, like "." ).

--
Alan Alpert