@Maluna34 maybe the qrc file mechanism is not the best approach for what you intend to use; however you only know your actual requirements.
From documentation about Qt resource system:

The Qt resource system is a platform-independent mechanism for storing binary files in the application's executable. This is useful if your application always needs a certain set of files (icons, translation files, etc.) and you don't want to run the risk of losing the files.

so a music file for a whole opera concert is not a suitable candidate for being stored in the qrc file as it ends up into your executable.

Given that said, you could get the file from the resource and save it somewhere to disk so the external tool can access it.

QFile::copy(":/sounds/ocean.mp3", "/tmp/ocean.mp3");

you can even use QTemporaryFile to avoid worrying about file naming and deletion.

@Chris-Kawa

It would actually just make things easier.

I would like to generalize this procedure to e.g.

QFile::copy(":/my/file", r.OriginalFileName);

Here Qresource::OriginalFileName() returns the original file name e.g. somefile.txt

Now, I am required to (for each file):

QString newLocation = QString(tempdir + tempdir.seperator() + QString("myNewFileName.txt")); QFile::copy(":/my/file", newLocation);

It just seems tedious and not very efficient.

But thanks for clearing it up though,

*grabs coffee

@CybeX said in copy file from resource to disk keeping folder structure (platform independant):

@Chris-Kawa @mpergand

Looks ok. What's wrong with it?

Well...nothing but it is an extremely tedious process...

Ok, let me change the question slightly here to help solve this using a different method.

Can (and how) am I able to get the original resource file name (e.g. below) from the QResource object.

Why don't you just give up to set alias and use the original file name in qrc?

@xLlama

You did not open your file for reading as indicated by the error messag "device not open".

http://doc.qt.io/qt-5/qiodevice.html#open

@trollkatt
You shouldn't compile a resource this big into the binary to begin with! Load it at runtime instead. For example look at this thread.

@mrjj said:

it means you compile a new version with rcc and copy it over?

Yes, it's generated from my CMakeLists.txt. No problem whatsoever with the generation.

If yes, have you try to flipflop

I did. It doesn't work. When going back to redTheme.rcc, the content is still the same as it was in first hand.

Note that I shared my problem on stackoverflow, and according to one of the replies, it's a bug.

Therefore, I reported it to the Qt bug tracker.

Solution can be found here: http://stackoverflow.com/questions/36335481/dynamically-change-qml-theme-at-runtime/36399339#36399339

Yes, it works if I build a normal shared library an a designer plugin containing the widgets used by other plugins.
The normal shared library is used to be linked to the other ones and the plugin is loaded into the designer to have the widgets available there.

Thank you Anant,

I will be deploying both to Linux and Windows and so require a solution for both, however they don't necessarily have to be the same solution.

Many thanks

Good, glad ya got it sorted out. Sorry I've been super busy lately and haven't lurked the forums here. :)

Yes, it is fixed since Qt 5.6.2, as the linked bug report suggests.