[Development] Another method of registering QML types
Alan Alpert
416365416c at gmail.com
Fri Nov 9 16:47:05 CET 2012
On Thu, Nov 8, 2012 at 3:58 PM, BRM <bm_witness at yahoo.com> wrote:
> ----- Original Message -----
>
>> From: Alan Alpert <416365416c at gmail.com>
>> 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.
>
> As I said, i have not had the chance to play with QML. So if what I said is already supported great!
>
> Now, in my hypothetical case, I was planning on storing the dialog description probably as text within the server somehow. I never got to those details;
> but the server I have does not present a normal URL style interface - that is, it's not an http server but a specific application server with a proprietary XML protocol;
> so a client application would have to request the data and receive a big XML blob with the QML-based dialog and then somehow load it - thus it would be nice to be able to detect any imports not loaded so that it would be able to retrieve and load them.
>
> Any how...that is just a hypothetical, but one that may be very useful to consider if people are not doing that already. If I had the time, I'd probably invest more into QML and do just I described; but I'd still have to figure out the server-side storage and transport issues for my server. (A web server is not an option; though if sftp is support, that would be.) Any how...enough dreaming...
I think for that usecase you'd be adding a custom network access
manager that processes your special application protocol. But so long
as the URLs can be parsed like file paths (don't know how it would
handle ? parameters) I think that should work already.
--
Alan Alpert
More information about the Development
mailing list