[Development] Another method of registering QML types

[BRM]

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

$0.02

Ben

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