How to access Qt resource data from non-Qt functions - c++

As I understand it, the way to packages non-code resources such as data files in a Qt app is using the resource system. However, what if I want to access a resource using a non-Qt function. For example, I may have a .txt or .csv file with some application data that I want to accessing using ifstream. It doesn't seem to work to use the ": ..." syntax in place of a filename for non-Qt functions and classes. Is there a separate workflow for packaging data used by non-Qt functions in an app?
I'm using OSX, but I would assume these issues are platform independent.

The sole purpose of the Qt resource system is to bundle data within the executable itself. If you wish not to integrate the data in the executable, then you simply must not use the resource system.
On mac, if you wish to add "data.txt" from project source to your application bundle, but not to the executable itself, add the following to your .pro file:
mac {
BUNDLE = $$OUT_PWD/$$TARGET$$quote(.app)/Contents
QMAKE_POST_LINK += ditto \"$$PWD/data.txt\" \"$$BUNDLE/Resources/\";
}
Given the above project file, use the QCoreApplication::applicationDirPath() for a path useful in getting to the file:
#include <QCoreApplication>
#include <QFile>
#include <QDebug>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
qDebug() << QCoreApplication::applicationDirPath();
QFile data(QCoreApplication::applicationDirPath() + "/../Resources/data.txt");
if (data.open(QIODevice::ReadOnly | QIODevice::Text))
qDebug() << data.readAll();
return 0;
}
In the above example, the Resources folder has nothing to do with the Qt resource system. It's simply a naming convention in OS X application bundles. We're not using the Qt resource system here.
If you wish to use the Qt resource system and access the resource data directly and not through a QFile, the QResource class provides access to resources that are bundled in the executable.
If the code under your control insists on using ifstream for data input, then it's artificially limited and should be fixed. It should use istream instead, as that class can be backed by anything, not necessarily a file. If it's code that you don't control, you could set up the ifstream on a QLocalSocket.
You can map the constant QResource::data() to an input stream via a stream buffer.
If the resource isCompressed(), then you need to first decompress it to a temporary area. You can also disable resource compression to avoid the decompression step. You can use a whole-executable compressor like upx instead - by the time your code runs, everything will be already decompressed and ready to use.

You can copy the resource file into a temporary folder. To do this, use a QTemporaryDir which creates a temporary folder and deletes it automatically when the program is finished. To access the path of that folder, use the QTemporaryDir::path() method. Here is an example of how you can use it:
#include <QTemporaryDir> //You need to include this header
QTemporaryDir temporaryDir;
//Copy the resource file into the temporary folder
QFile::copy(":/exampleprefix/examplefile.txt", temporaryDir.path() + "/examplefile.txt");
//Read the file
std::ifstream fileStream(QString(temporaryDir.path() + "/examplefile.txt").toLatin1().data());
//etc

What about opening the resource file with a QFile object, wrapping this with a QDataStream object, and wrapping this with a boost::iostreams::stream object, which derives from a specialization of std::basic_istream? Sounds complicated, but does not need too many lines of code, see this answer.

Related

How to get a settings storage path in a cross-platform way in Qt?

My program needs to read/write a text (just a few lines) file with its settings to disk. To specify a path in code may work well on one platform, like windows, but if runs it on Linux, the path is not cross platform.
I am looking for a similar solution to QSettings that saves settings to different paths or has its native ways to handle this. Programmers don't need to do with the details. But the text file is not suitable to be saved as a value in QSettings.
No user interaction should be needed to obtain such path. The text file should persist across application restarts. It can't be a temporary file.
Is there an existing solution in Qt and what is the API that should be used?
The location of application-specific settings storage differs across platforms. Qt 5 provides a sensible solution via QStandardPaths.
Generally, you'd store per-user settings in QStandardPaths::writableLocation(QStandardPaths::AppDataLocation). If you wish the settings not to persist in the user's roaming profile on Windows, you can use QStandardPaths::AppLocalDataLocation, it has the meaning of AppDataLocation on non-Windows platforms.
Before you can use the standard paths, you must set your application name via QCoreApplication::setApplicationName, and your organization's name using setOrganizationName or setOrganizationDomain. The path will depend on these, so make sure they are unique for you. If you ever change them, you'll lose access to old settings, so make sure you stick with name and domain that makes sense for you.
The path is not guaranteed to exist. If it doesn't, you must create it yourself, e.g. using QDir::mkpath.
int main(int argc, char ** argv) {
QApplication app{argc, argv};
app.setOrganizationDomain("stackoverflow.com");
app.setApplicationName("Q32525196.A32535544");
auto path = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation);
if (path.isEmpty()) qFatal("Cannot determine settings storage location");
QDir d{path};
if (d.mkpath(d.absolutePath()) && QDir::setCurrentPath(d.absolutePath())) {
qDebug() << "settings in" << QDir::currentPath();
QFile f{"settings.txt"};
if (f.open(QIODevice::WriteOnly | QIODevice::Truncate))
f.write("Hello, World");
}
}
If you want to save some user related data, you can get user home directory path using QDir::homePath().
There is QDir to handle paths to dirs, QFileInfo for platform independent file information and QDir's homePath()
My proposal is to use these classes and use QDir::home() or QDir::homePath() to find a directory where to write to, since the user has write permissions in his homedir and it exists on each platform.
You can store file in application directory. Take a look at QCoreApplication::applicationDirPath().
From Qt documentation:
Returns the directory that contains the application executable.

Qt QDir::current()

I had some code like this:
void MainWindow::saveData()
{
QDir oldDir=QDir::current();//this should return the main executable directory.Since there is no other place in my hole code where i temper with QDir.
QDir sess("Sessions");
if(!oldDir.exists("Sessions"))//if "Sessions" Dir doesn't exist
oldDir.mkdir("Sessions");//create it.
QDir::setCurrent(sess.absolutePath());
//some virtual code inside current Dir, which i didn't implement yet.
QDir::setCurrent(oldDir.absolutePath());//restore old dir
}
When I run my app firstly the code works perfectly.but in the second run, the first call to QDir::current(); returns the "Sessions" Dir and not the main executable Dir as it should be restored in the first run.actually i did manage to overcome this by adding one line at the biginning of the code, the following :
QDir::setCurrent(QCoreApplication::applicationDirPath());
Still I want to know why the first code didn't work.already checked for the documentation of the functions and found nothing.
QDir::current();//this should return the main executable directory
No it should not! Not unless you change it to point there first.
I'm dead serious when I'll say this: Yours is a myth, fantasy, whatever you call it, I have no idea what gave you the idea. Point me to a spec that says so. Oh, you can't, because there's no such spec, no such requirement. It's someone's twilight hour mirage that seems to perpetuate itself endlessly. If you heard it from someone, you have every right to be angry at them this very moment, for they did you a big disservice.
Generally speaking, for applications that are not normally started from the command line, the initial working directory can be anything and it will be platform- and session/system configuration dependent. For a typical GUI application, assuming any particular initial working directory is a fool's errand and completely misguided.
Once you change it to where you want it to point to, you of course have full control over it, but the initial working directory must be assumed to be random and out of your control.
For example, on Windows I can start your application through an Explorer shortcut where I can specify whatever startup folder I desire, and you have zero control over it. On OS X, Finder sets the working directory to something or another, IIRC to the folder where the app bundle resides. Again, you as a developer have no control over it unless there's some setting in the bundle that you could add to that effect, but that is platform-specific and will be ignored if your application is not started through Finder or bundle API mechanisms (they probably are called something else). And so on. It's completely arbitrary and it's pointless to depend on its initial value.
If you want to refer to the application's installation directory or executable directory, do so explicitly. Do not assume anything about the initial working directory of a GUI application.
I tried with the below code and it works fine for several runs.
The version details of Qt and OS may help.
Qt creator 3.3.2 (open source). Qt lib 5.4.1.Os windows 8.1
#include <QCoreApplication>
#include "QDir"
#include "qDebug"
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QDir oldDir=QDir::current();
qDebug()<<QDir::current().absolutePath();
QDir sess("H:\\cuteapps\\session");
if(!oldDir.exists("H:\\cuteapps\\session"))//if "Sessions" Dir doesn't exist
oldDir.mkdir("H:\\cuteapps\\session");//create it.
QDir::setCurrent(sess.absolutePath());
qDebug()<<QDir::current().absolutePath();
return a.exec();
}
output 1:
"H:/cuteapps/build-untitled2-Desktop_Qt_5_4_1_MSVC2012_OpenGL_32bit-Debug"
"H:/cuteapps/session"
output 2:
"H:/cuteapps/build-untitled2-Desktop_Qt_5_4_1_MSVC2012_OpenGL_32bit-Debug"
"H:/cuteapps/session"
output 3:
"H:/cuteapps/build-untitled2-Desktop_Qt_5_4_1_MSVC2012_OpenGL_32bit-Debug"
"H:/cuteapps/session"

Exporting SVG into the local Resource directory

I am trying to reach the qt resource folder without success. It works if I export into an other folder like C:\\Temp\\18_25_21_18_09_2014.svg, but it doesn't work if I use an URL like :/Temp/18_25_21_18_09_2014.svg.
Here is the code:
QString fileName(":/Temp/Temp" + QDateTime(QDateTime::currentDateTime()).toString("hh_mm_ss_dd_MM_yyyy") + ".svg");
QSvgGenerator generator;
generator.setFileName(fileName);
generator.setSize(this->size());
generator.setViewBox(QRect(QPoint(0,0), this->size()));
generator.setTitle(tr("bubble_svg"));
generator.setDescription(tr("bubble_svg"));
_painter.begin(&generator);
_painter.setRenderHint(QPainter::Antialiasing);
_painter.setRenderHint(QPainter::HighQualityAntialiasing);
this->render(&_painter);
_painter.end();
Also I created a prefix called Temp and a folder called Temp.
It looks like that also QDirIterator can reach the folder, only the QSvgGenerator couldn't.
QDirIterator it(":/Temp/Temp", QDir::Files, QDirIterator::Subdirectories);
while (it.hasNext()) {
qDebug() << "FILE FOUND " << it.next();
}
The result of this part of code:
FILE FOUND ":/Temp/Temp/18_35_19_18_09_2014.svg"
I appreciate every idea. Thanks for dropping by and taking time with the questions!
Ok, I understood and post it as answer.
Unfortunately it is impossible. Qt Resource System forbid this. As documentation said:
The Qt resource system is a platform-independent mechanism for storing binary files in the application's executable. It means that resources are read only, thuis files compiled into the executable, you can't write it because this files storing in your exe file. Especially an executable can’t modify itself while it is running. You’ll have to re-compile the QRC file (using RCC) and then re-build the EXE file, if one of the resources has changed.
As you can see, you should provide another way to storing and using your files.
I hope it was useful for you.

How to use Qt/C++ to create/read/write files and store settings local with the program

I'm an unfortunate beginner at C++ and using the Qt GUI designer program seemed perfect for my needs, except I'm having problems trying to write out the code necessary for this. I could use the QSettings string to store local settings on the hard drive, but I personally hate it when programs do the %HOME_LOCAL%\APPS_SETTINGS bull that some do. I need to save a text file for both settings and a local\host database, within the program directory, to remember strings to read from later.
What is the line of code I need to make use of a local host text database or is there a better option? And how can I store that with the local program inside its directory?
You can use QSettings with any file, with constructor QSettings::QSettings ( const QString & fileName, Format format, QObject * parent = 0 ).
To get the program directory, you can use QCoreApplication::applicationDirPath().
So, answer to your question, statement to put after creation of QApplication instance:
QSettings *settings = new QSettings(
QCoreApplication::applicationDirPath() + "/settings.ini",
QSettings::IniFormat,
qApp);
But, as noted in the comments under question, if you're making your program for general distribution, you should use the OS default. Examine all the constructors of QSettings to see what it can do. User does not often have write permission in the application directory. Note that you can also store settings to Windows registry with QSettings::NativeFormat.

Phonon::MediaSource, cannot use resource as media source

with QT 4.6, I am trying to access a wav file in my QResource file to use as the media source of a media player and it does not work:
Phonon::MediaObject *music;
music=Phonon::createPlayer(Phonon::MusicCategory,Phonon::MediaSource(:/FPS_sounds/arming.wav));
music->play();
If I put the direct path it works. I have been successful at using resources in other parts of my program so there does not seem to be a problem there and the Qt doc says I can use QResource for this type of operation. Is this a bug or am I missing something?
This one gave me a good scratch as well.
But lo and behold, it can be implemented easily using a temporary file:
{
QTemporaryFile f;
f.open();
QResource res(":/badger");
f.write((char*)res.data(),res.size());
f.flush();
f.setAutoRemove(true);
f.close();
QString fn = f.fileName();
QSound::play(fn);
}