problem with paths (or QPainter)

[loa3]

Hi guys,

I've recently started next tutorial project about drawing.
The app should open texture from file and fill the window with them.
It also should do something more but I immediately obtain rather unusual trouble.

Here is simple code to load the texture needed:

File with the image seems to be at right place:

But I see 'invalid' value of star_background in debug window as well as no texture in the app window:

Tried to write different paths but it doesn't help. Please advise.

[artwaw]

@loa3 On Mac the current folder . designator points inside the app bundle when the program starts. So in your case it should be ../../img/ but that's also not the way you should have it.

Please create the resource file, attach images in it, then refer to them via resource path :/.

• https://doc.qt.io/qt-5/resources.html - an overview
• https://doc.qt.io/qt-5/designer-resources.html - how to handle it from within qt creator (you don't have to write that file, all can be clicked out)

And since you seem to be lost as to how things work under macOS, you can start reading here (the subject is extensive though, I foresee some troubles for you when it comes to deploying your program): https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW13

[loa3]

@artwaw said in problem with paths (or QPainter):

And since you seem to be lost as to how things work under macOS

I mix up file systems from several OS (starting from IBM360)... )))
Thank you!

[mpergand]

On Mac, to rely on the current directory is ... unreliable !

Try the following code:

QTextEdit edit;
    edit.append("Home Path: "+QDir::homePath());
    edit.append("Current Path: "+QDir::currentPath());
    edit.append("Root Path: "+QDir::rootPath());
    edit.append("App Dir Path: "+QCoreApplication::applicationDirPath());
    edit.show();

Start the app from QtCreator:
Current Path = App Dir Path

Now start the same app from the Finder by double clicking on it:
Current Path = Root Path

Not what we really expected, isn't it ?

[artwaw]

@mpergand when you start the program from Qt Creator and from the finder (which will fail unless you properly deploy) you are talking two different environments here, so to speak.
In order to obtain folder hierarchy one should use QStandardPaths which are designed for that purpose, QDir values are more contextual in terms of environment.

[loa3]

Guys, this app is just for drawing methods (classes) learning purposes and will not be used as 'real' application. Moreover, programs (in future) will be written for PLCs (i.e. embedded linux).
So it is enough just to grab dozen of .jpeg pictures somehow. But I can not ((

Path with ../../img/ as Artur advised earlier is also gives 'invalid' object...

[JonB]

@loa3 said in problem with paths (or QPainter):

../../img/

It seems to me everyone is telling you not to use a relative path. Either if it's read-only you can use a Qt resource like @artwaw says, or you can store data in one the directories @mpergand lists.

[mpergand]

For testing purpose only, you can do:

Put your img dir at the same level as lesson9 dir

in your code do:

    QDir dir(QCoreApplication::applicationDirPath());
    dir.cdUp();
    dir.cdUp();
    dir.cdUp();
    dir.cdUp();
// or dir.cd("../../../../");
    dir.cd("img");
        
    qDebug()<<dir.path()<< dir.exists();

[artwaw]

@loa3 there should be at least one more .., my bad.

Initial . points to the YourProgram.app\Contents\MacOS\

[loa3]

@mpergand said in problem with paths (or QPainter):

For testing purpose only, you can do:

Put your img dir at the same level as lesson9 dir

in your code do:

    QDir dir(QCoreApplication::applicationDirPath());
    dir.cdUp();
    dir.cdUp();
    dir.cdUp();
    dir.cdUp();
// or dir.cd("../../../../");
    dir.cd("img");
        
    qDebug()<<dir.path()<< dir.exists();

I've done very close:
```
QDir dir(QCoreApplication::applicationDirPath());

dir.cdUp();
qDebug()<<dir.path();
dir.cdUp();
qDebug()<<dir.path();
dir.cdUp();
qDebug()<<dir.path();
dir.cdUp();
qDebug()<<dir.path();

dir.cd("img");

qDebug() << dir.path() << dir.exists();

qDebug() << star_background.load("star_background.jpg");

It gives such debug log:

"/Users/apple/Google Drive/Electro/plc-edu/CPP/L9/build-lesson9-Desktop_Qt_5_15_2_clang_64bit-Debug/lesson9.app/Contents"
"/Users/apple/Google Drive/Electro/plc-edu/CPP/L9/build-lesson9-Desktop_Qt_5_15_2_clang_64bit-Debug/lesson9.app"
"/Users/apple/Google Drive/Electro/plc-edu/CPP/L9/build-lesson9-Desktop_Qt_5_15_2_clang_64bit-Debug"
"/Users/apple/Google Drive/Electro/plc-edu/CPP/L9"
"/Users/apple/Google Drive/Electro/plc-edu/CPP/L9/img" true
false

So the problem seems to me in QImage::load()?

[mpergand]

QString path=dir.filePath("star_background.jpg");
star_background.load(path);

[artwaw]

@loa3 said in problem with paths (or QPainter):

So the problem seems to me in QImage::load()?

No quite, the problem is that you do not address your paths in the system independent way. Hence the load() fails.

[loa3]

Oh, yeah!
It works! And I slightly understand what was the trouble.
But it's not easy to realize how .app file may be both executable and also 'directory' for it's data.
Anyway now I can continue my play with images.

Many thanks!

[SGaist]

Hi,

@loa3 said in problem with paths (or QPainter):

.app file may be both executable and also 'directory' for it's data.

They are not both. In fact they are specially treated folders. Look for app bundle in macOS developer documentation.

[mpergand]

For those who targetting MacOS (IOS ?) only,
it's possible to use the app bundle as a resources container.

To copy the contents of a folder in the Resources folder in the app bundle, add the folllowing in the .pro file:

# the img folder is in the project folder (same level as the project file)
IMAGES.files = $$files(img/*.jpg)
IMAGES.path = contents/resources/img
QMAKE_BUNDLE_DATA += IMAGES

Note that the img folder is created automatically if it doesn't exist , cool feature !

I try to do the same things the Qt way with RESOURCES
RESOURCES +=$$files(img/*.jpg)
the folder appears in the left panel hierarchy tree, but it doesn't work because no qrc is created.

Any magic command for that ?

[loa3]

@SGaist said in problem with paths (or QPainter):

They are not both. In fact they are specially treated folders. Look for app bundle in macOS developer documentation.

I understand. It was like a joke (take into account my poor English).

[loa3]

@mpergand said in problem with paths (or QPainter):

For those who targetting MacOS (IOS ?) only,
it's possible to use the app bundle as a resources container.

It is very helpful information. I proposed that something like this.

But in fact now my apps should be 'universal'. Since the 'teacher' use Win to check my exercises (as well as Qt with MinGW).

[artwaw]

@mpergand said in problem with paths (or QPainter):

it doesn't work because no qrc is created.

Again: Qt way to handle it is to create resource file and put the images in the resource file. This way when the bundle is created all the resources are properly put.
Modifying app bundle by putting surplus data in it is not advisable. You might run into the problems later, when signing and verifying deployment bundle.
Besides, there is not need to reinvent the wheel.

[mpergand]

@artwaw said in problem with paths (or QPainter):

Modifying app bundle by putting surplus data in it is not advisable. Y

macx {
QMAKE_INFO_PLIST = Mac/Info.plist
ICON = Mac/AppIcon.icns
}

Where do you think these two files go ?

A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code. The bundle contains resources that may be accessed at runtime, such as images, audio files, user interface files, and property lists.
If you don’t use Xcode to build your software product, use the information below to place your bundled content in the right location.
If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems.

All that seems obvious, but what's wrong with Qt Apps ?
If there are issues, it is a Qt problem, not mine.

[artwaw]

@mpergand There is nothing wrong with Qt Apps.
My point is that there no need to fiddle with resources (and rare case when you need to adjust info.plist) since Qt offers you ready solutions to handle it.

@mpergand said in problem with paths (or QPainter):

If there are issues, it is a Qt problem, not mine.

O'rly