On Thu, Nov 8, 2012 at 12:49 PM, BRM <[email protected]> wrote: >> From: Alan Alpert <[email protected]> > >> To: development <[email protected]> >> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
