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