[Interest] Routing all QML file requests through a custom resource provider

[Dmitry Volosnykh]

You may want to install QtCreator for, at least, to use it as a tool to
quick dive into the examples. I realize that this is by no means what you
are after, but I think that worth it.

On Fri, Jun 17, 2016 at 2:06 PM Max Savenkov <max.savenkov at gmail.com> wrote:

> 1) I'm not using QtCreator, but Visual Studio
> 2) Even if I did, adding file to RESOURCES variable would not allow me to
> put it inside my own package. While it might be OK to have separate
> resource packages for the main game and Qt, I'd like to avoid it if
> possible.
>
> 2016-06-17 13:58 GMT+03:00 Dmitry Volosnykh <dmitry.volosnykh at gmail.com>:
>
>> Usually, you don't need to do anything to "register" you resources file.
>> Basically, you add .qrc filename to RESOURCES variable inside qmake's
>> project file. After that you are able to refer to its contents via "qrc"
>> protocol (in terms of URI) for either QFile or QUrl, etc.
>>
>> By the way, have you looked into examples provided with QtCreator. I am
>> pretty sure that there are a plenty of examples exploting this
>> functionality.
>>
>> On Fri, Jun 17, 2016 at 1:45 PM Max Savenkov <max.savenkov at gmail.com>
>> wrote:
>>
>>> Hi Dmitry,
>>>
>>> As a understand it, qrc is just an index file. I still need to provide
>>> binary data it refers to somehow. Basically, what I don't understand is
>>> this passage in documentation: "a binary resource can be created and at a
>>> later point in application code registered with the resource system.".
>>> Looking at header file, I can see two ways to register a rcc file. This
>>> first is by specifying filename to QResource::registerResource. That one
>>> won't work, since Qt will try to load this file from conventional
>>> filesystem, while it is really located in my resource provider (basically,
>>> in memory).
>>>
>>> There is a second overload of registerResource, which takes a pointer to
>>> rccData. Which LOOKS like that I need, but it suspiciously missing "size"
>>> argument, so I'm not really sure what this call does. Unless, of course, it
>>> just registers a pointer to memory as a resource and just assumes it's a
>>> correctly formatted output of rcc that at least contains some header with
>>> size? In which case I certainly can use it, and it will solve my problems,
>>> but then it seems unsafe to me.
>>>
>>>
>>> 2016-06-17 12:45 GMT+03:00 Dmitry Volosnykh <dmitry.volosnykh at gmail.com>
>>> :
>>>
>>>> Hi, Max!
>>>>
>>>> To be honest, I did not understand in all the details what you are
>>>> trying to achieve. Anyway that looks way complex indeed.
>>>>
>>>> Since you are inclined to pack all you resources into auxiliary file
>>>> like zip package, you are surely okay with static content. Having this
>>>> said, you should be fine using conventional .qrc files (this is what you
>>>> named Qt resource system). These files are easily accessed (i.e. viewed,
>>>> edited, etc.) from Qt Creator. Qt Designer tools understand them perfectly
>>>> fine, as well. Also, there should be no issues when importing QML
>>>> components from your .qml files once you feed QML engine with root .qml
>>>> file stored inside .qrc file.
>>>>
>>>> Regards,
>>>> Dmitry.
>>>>
>>>> On Fri, Jun 17, 2016 at 12:09 PM Max Savenkov <max.savenkov at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Once again, I'm trying to use Qt (in this case, QtQuick/QML) for game
>>>>> development. The game is going to store all its resources in a package
>>>>> (it might be zip, or a custom format) when deployed, but during
>>>>> development, resources are available in the usual filesystem. This
>>>>> difference is hidden by game's resource provider, which maps resource
>>>>> name to a file or an entry in package.
>>>>>
>>>>> This works for the game itself, but how can I make QML load images,
>>>>> imports and other resources from game's resource provider? (also, I'd
>>>>> like to view my QML files in Designer, which means I can't use custom
>>>>> image providers in QML code itself)
>>>>>
>>>>> I see two possibilities, but I'm not sure of either one.
>>>>>
>>>>> 1) Use dynamic resources produced by rcc. When loading a QML file from
>>>>> C++, also load relevant rcc data (from game's resources) and register
>>>>> it
>>>>> with Qt resource system to make it accessible. This sounds workable,
>>>>> but
>>>>> I'm not sure how exactly to make it happen. Suppose I got a binary
>>>>> buffer from game's resources. How do I register it in Qt?
>>>>>
>>>>> 2) Use a system of crutches.
>>>>> * Register Url Interceptor with my QMLEngine, such that:
>>>>>      - any URL that contains an image is changed into
>>>>> "image:/my_resource_provider/imagename.png"
>>>>>      - any URL that contains qml or qmldir is change into... What?
>>>>> There
>>>>> is no way to register a special loader for QML imports. But I guess I
>>>>> can change it into a network request, by substituting shcema to, for
>>>>> example, "my_provider"
>>>>> * Register image provider with name "my_resource_provider" that loads
>>>>> images from my resource system.
>>>>> * Register a custom network access manager factory/manager/network
>>>>> reply
>>>>> that load QML files from my system instead of network. This doesn't
>>>>> quite work, however, because QML at some point for whatever reason
>>>>> checks that URL used to load qml file is local...
>>>>>
>>>>> So, I'm stumped. This should be WAY easier... And it was, before
>>>>> AbstractFileEngine was made private. But I really don't want to use
>>>>> private APIs if I can avoid it.
>>>>> An argument against AbstractFileEngine was made, that virtual FS should
>>>>> be implemented "at OS level" - but I simply cannot see how a game can
>>>>> implement it at OS level, because it's a game 0_o.
>>>>> _______________________________________________
>>>>> Interest mailing list
>>>>> Interest at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160617/8c247e18/attachment.html>