----- Original Message ----- > From: Alan Alpert <4163654...@gmail.com> > On Thu, Nov 8, 2012 at 12:49 PM, BRM <bm_witn...@yahoo.com> wrote: >>> From: Alan Alpert <4163654...@gmail.com> >> >>> To: development <development@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... >> [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 "." ). True - though I was thinking the application would just store it in say /tmp or /tmp/<user>.<application> and configure Qt to be able to use that dir as well for QML - e.g. something the application controlled, not Qt. $0.02 Ben _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development