Qt Resources question when loading plugins
-
I've got a Qt application that dynamically enumerates and load plugins (they are Qt plugins so their resources automatically get mounted) and I'm able to avoid resource collisions between differing plugins (for example if multiple plugins have an 'icon.png' resource in same path in their own QRC directories) by having each plugin use its GUID (they have GUIDs for other reasons) in its QRC pathing.)
So if two plugin would normally have a resource like this:
qrc:/myresource/icon.png
I currently avoid the collision it by having the plugin convention:
qrc:/<GUID>/myresource/icon.png
So plugin one might have:
qrc:/A8C71F6A-C9AA-42E7-A109-FCC430D6128A/myresource/icon.png
And the other plugin might have:
qrc:/DFEBBA93-CA16-48EF-A08A-9B4E27179CF4/myresource/icon.png(for example.)
Again, this works for me, but I don't know much about the resource system in Qt - is there simpler, more intrinsic property, or method I could use where plugin writers would simply be unable to screw it up by failing to follow the 'GUID convention'? I like making this easier for them :).
Something I may have missed, such as "Oh, when a plugin loads, it mounts in a special fashion that you can then..." blah, blah, blah :).
Looking for pointers, thanks!
-
I've got a Qt application that dynamically enumerates and load plugins (they are Qt plugins so their resources automatically get mounted) and I'm able to avoid resource collisions between differing plugins (for example if multiple plugins have an 'icon.png' resource in same path in their own QRC directories) by having each plugin use its GUID (they have GUIDs for other reasons) in its QRC pathing.)
So if two plugin would normally have a resource like this:
qrc:/myresource/icon.png
I currently avoid the collision it by having the plugin convention:
qrc:/<GUID>/myresource/icon.png
So plugin one might have:
qrc:/A8C71F6A-C9AA-42E7-A109-FCC430D6128A/myresource/icon.png
And the other plugin might have:
qrc:/DFEBBA93-CA16-48EF-A08A-9B4E27179CF4/myresource/icon.png(for example.)
Again, this works for me, but I don't know much about the resource system in Qt - is there simpler, more intrinsic property, or method I could use where plugin writers would simply be unable to screw it up by failing to follow the 'GUID convention'? I like making this easier for them :).
Something I may have missed, such as "Oh, when a plugin loads, it mounts in a special fashion that you can then..." blah, blah, blah :).
Looking for pointers, thanks!
@VRHans said in Qt Resources question when loading plugins:
Again, this works for me, but I don't know much about the resource system in Qt - is there simpler, more intrinsic property, or method I could use where plugin writers would simply be unable to screw it up by failing to follow the 'GUID convention'? I like making this easier for them :).
no not really. There is no 'dynamic prefix' feature in qrc yet.
It would be also not that straight forward, since the paths are already hardcoded used by the developer, refering to a file in the qrc... -
@VRHans said in Qt Resources question when loading plugins:
Again, this works for me, but I don't know much about the resource system in Qt - is there simpler, more intrinsic property, or method I could use where plugin writers would simply be unable to screw it up by failing to follow the 'GUID convention'? I like making this easier for them :).
no not really. There is no 'dynamic prefix' feature in qrc yet.
It would be also not that straight forward, since the paths are already hardcoded used by the developer, refering to a file in the qrc...I figured as much, it's just that Qt has so many ways to solve problems that I often over-engineer a solution instead of knowing something simpler - one of the reason to love Qt :).
It might be interested to offer the dynamic loader a mount point for resources when the plugin is instanced; e.g. "Qt, when you load this plugin mount its resource under a sub-tree"
Possibly resource requests from code in a given code segment (from the dylib/so/dll) could be remapped in real-time to ensure that plugins can load their own resources without knowing anything about this - or the resource system could provide an abstraction layer between the API and the resource system and the remapping happens there.
Anywho, works as is right now - cheers!
-
I figured as much, it's just that Qt has so many ways to solve problems that I often over-engineer a solution instead of knowing something simpler - one of the reason to love Qt :).
It might be interested to offer the dynamic loader a mount point for resources when the plugin is instanced; e.g. "Qt, when you load this plugin mount its resource under a sub-tree"
Possibly resource requests from code in a given code segment (from the dylib/so/dll) could be remapped in real-time to ensure that plugins can load their own resources without knowing anything about this - or the resource system could provide an abstraction layer between the API and the resource system and the remapping happens there.
Anywho, works as is right now - cheers!
@VRHans
seems i was wrong afterall: QResource::registerResource()
But you have to provide the resource binary (.rcc file). Created with the following command:rcc -binary myresource.qrc -o myresource.rcc
