Qt Creator 4.0.2 Idiosyncracy?

[mdavidjohnson]

I'm running Qt 5.70 32-bit with x86 MinGW 32-bit on Windows 7 Pro 64-bit SP1.

In Qt Creator 4.0.2 the following mainwindow.cpp file (and other associated files - the usual) compiles successfully to ImageTest.exe in the debug folder of the build.


#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
}

MainWindow::~MainWindow()
{
delete ui;
}

void MainWindow::paintEvent(QPaintEvent *event)
{
QImage image;
image.load("tux.png");

QPainter imagePainter(this);
imagePainter.drawImage(QPoint(0, 0), image);
}


After copying tux.png to the build's debug folder, RUN (from within Qt Creator) just produces a blank screen.

But, if I actually go to the debug folder and click on ImageTest.exe the image is properly displayed.

Alternatively, if I replace "tux.png" in the above code's image.load line with the file's full path, Qt Creator's RUN shows the image correctly.

Furthermore, if I put the image file directly in the build folder (instead of in its debug sub-folder) it works correctly from Qt Creator but then, clicking ImageTest.exe in the debug folder produces a blank screen.

Where do I need to put the image file so that it will be properly accessed both when RUNning from Qt Creator and when directly clicking ImageTest.exe?

[Radek]

In rhe resources :D Let us decode what you have seen: (Having the image in the debug directory)
(1) When you run from the Creator, the current directory is the project directory - not the debug or release one. Therefore, the image is not found. Running the test.exe is okay, the image is in the same directory.
(2) When you place the image in the project directory, run from the Creator is okay but running test.exe fails. The image is not found again.

If you do not want the image in the resource file, copy the image both to the project directory and to the debug (and release) directories temprarily.

[d_stranz]

void MainWindow::paintEvent(QPaintEvent *event)
{
QImage image;
image.load("tux.png");

QPainter imagePainter(this);
imagePainter.drawImage(QPoint(0, 0), image);
}

And are you really sure you want to do this? Each time your MainWindow receives a paintEvent, it's going to waste time going out and reloading that same file, over and over and over again.

As well, you don't appear to be using a layout or setting a centralWidget on your MainWindow, the lack of which will lead you down the road to ruin when you want to turn this into a real app.

Better would be to make the QImage a member variable of the MainWindow class, and to load it either in the constructor (if the image never changes), or to load it in a slot connected to a QFileDialog's fileSelected() signal if the user can load a new one on demand, or in both places if you have a default startup image that can later be changed. And to add a plain old QWidget as the centralWidget for your MainWindow and do the painting to that instead. With a centralWidget, the MainWindow will center the image, add scrollbars when needed if the image is bigger than the MainWindow, and do other nice things.

[mdavidjohnson]

.... If you do not want the image in the resource file, copy the image both to the project directory and to the debug (and release) directories temprarily.

Thank you -

Yes, I thought of that too, but it seemed like such a horrible kludge that I would likely be mocked mercilessly if I suggested it here. :p

Added after 20 minutes:


And are you really sure you want to do this? Each time your MainWindow receives a paintEvent, it's going to waste time going out and reloading that same file, over and over and over again.

As well, you don't appear to be using a layout or setting a centralWidget on your MainWindow, the lack of which will lead you down the road to ruin when you want to turn this into a real app.

Better would be to make the QImage a member variable of the MainWindow class, and to load it either in the constructor (if the image never changes), or to load it in a slot connected to a QFileDialog's fileSelected() signal if the user can load a new one on demand, or in both places if you have a default startup image that can later be changed. And to add a plain old QWidget as the centralWidget for your MainWindow and do the painting to that instead. With a centralWidget, the MainWindow will center the image, add scrollbars when needed if the image is bigger than the MainWindow, and do other nice things.

All very good and reasonable points.

But... I AM a *Newbie* and this IS the Newbie forum. So I think I should be forgiven for not being aware of all these excellent enhancements just yet.

Right now, I'm just trying to figure out why, if Qt was intended (per Eirik Chambe-Eng) "to make life easier for developers"; why does it seem so obfuscated in some respects?

Furthermore, my code is really just a slightly truncated version of the code at Loc 1545 of 4286 in Lee Zhi Eng's Qt5 C++ GUI Programming Cookbook. If the eminent Eng finds such an example to be instructive in this context, I think (for me at least) it would be instructive to figure out why the example works or doesn't before proceeding to more esoteric considerations.

I do suspect, that in production scenarios, I would be more likely to encapsulate such images as resources and to access them via the :/ mechanism.

[wysota]

Right now, I'm just trying to figure out why, if Qt was intended (per Eirik Chambe-Eng) "to make life easier for developers"; why does it seem so obfuscated in some respects?
Would you give examples on what you mean?


Furthermore, my code is really just a slightly truncated version of the code at Loc 1545 of 4286 in Lee Zhi Eng's Qt5 C++ GUI Programming Cookbook. If the eminent Eng finds such an example to be instructive in this context, I think (for me at least) it would be instructive to figure out why the example works or doesn't before proceeding to more esoteric considerations.
Obviously we can't take responsibility over someone else's code (I have no idea who Lee Zhi Eng is) however my experience tells me examples rarely grow up to be good and functional applications.

Back to your problem:


After copying tux.png to the build's debug folder, RUN (from within Qt Creator) just produces a blank screen.

But, if I actually go to the debug folder and click on ImageTest.exe the image is properly displayed.

Alternatively, if I replace "tux.png" in the above code's image.load line with the file's full path, Qt Creator's RUN shows the image correctly.

Furthermore, if I put the image file directly in the build folder (instead of in its debug sub-folder) it works correctly from Qt Creator but then, clicking ImageTest.exe in the debug folder produces a blank screen.

Where do I need to put the image file so that it will be properly accessed both when RUNning from Qt Creator and when directly clicking ImageTest.exe?

You are using a relative path to the image you try to load. It is relative to the current working directory which might be different to what you think when your application is executed using different means. Qt Creator sets it different compared to the Windows graphical environment and different compared to when someone explicitly sets the working directory in the shell or via a shortcut icon. On different platforms the rules might be different as well. Either change the current working directory in your application (QDir::setCurrent()) to something you can derive the relative path to the image from (e.g. QCoreApplication::applicationDirPath()) or embed the image as a resource directly in your executable.

[d_stranz]

But... I AM a *Newbie* and this IS the Newbie forum. So I think I should be forgiven for not being aware of all these excellent enhancements just yet.

So please also do not look upon these suggestions as being criticisms of or ridiculing your code. The intention was to make you aware of what the consequences of what you wrote are, and to suggest how you might modify it to make it a bit better. What if your tux image was 30 Mb and you had no idea why your program was so slow to update the screen? Likely you would have eventually figured it out, but how many lumps would you have from pounding your head on the desk?


Right now, I'm just trying to figure out why, if Qt was intended (per Eirik Chambe-Eng) "to make life easier for developers"; why does it seem so obfuscated in some respects?

Qt does make life easier for developers. The problem for new learners is that it is a huge set of libraries that covers almost every feature you would like to handle in a platform-independent way. Even the GUI part alone is massive, with at least a hundred or more classes in each of the QtCore, QtGUI, and QtWidgets libraries alone. It takes a long, long time just to learn what functionality is available, and even longer to discover which class(es) you need to implement that functionality. Even after 10+ years of Qt coding, Qt Assistant is always running while I write new code.

By the way, I looked at the preview of Eng's new book on Amazon a month or so ago and wasn't much impressed. It takes a scattershot at a bunch of unrelated topics and doesn't seem to treat any of them in much detail. The code examples may be technically correct, but they don't seem to reflect good development style. I would not use it as a book to learn Qt as a newbie.

Even though it is based on Qt4, the book by Blanchette and Summerfield, "C++ GUI Programming with Qt 4" was my go-to book for learning Qt and I still recommend it. The core of QWidget-based GUI hasn't changed all that much between Qt4 and Qt5, and with the exception of the reorganization of the locations of include files and libraries between Qt4 and Qt5, the code for the examples should be usable with only minor changes.

And don't overlook the Qt Examples and Tutorials (http://doc.qt.io/qt-5/qtexamplesandtutorials.html) you got when you installed Qt.

I see that Wysota has a new book out; from the table of contents, it looks like it is about as comprehensive as Blanchette and Summerfield's book. Unfortunately, the preview on Amazon doesn't get much past the overview and installing chapters, so I can't comment on the code examples. No doubt Wysota can ;)

[wysota]

I see that Wysota has a new book out; from the table of contents, it looks like it is about as comprehensive as Blanchette and Summerfield's book. Unfortunately, the preview on Amazon doesn't get much past the overview and installing chapters, so I can't comment on the code examples. No doubt Wysota can ;)

Some examples are better other are... even better ;) Seriously speaking some examples are meant to stay being examples. However examples should not teach you bad patterns or present bad approach (and unfortunately many examples I've seen do that, even some in Qt docs).

BTW. the book is mine as well as Lykurg (http://www.qtcentre.org/members/452-Lykurg)'s.

[d_stranz]

BTW. the book is mine as well as Lykurg's.

Yes, sorry - I should have given him credit too.

So is the book worth getting, even for someone with experience? I doesn't sound like it is really about game development, even though that is the title. It seems more general than that.

But what I would really like is a comprehensive book on Qt Quick and QML - one with something more substantial than toy examples. Any recommendations there?

[wysota]

So is the book worth getting, even for someone with experience?
I cannot answer that question. I'm really happy with some of the aspects, especially on Qt Quick and scripting. And the bonus chapter which is available for download if you have the book. It contains most that didn't fit into the printed/e-book version (which is about 100 pages of content, as far as I remember).


I doesn't sound like it is really about game development, even though that is the title. It seems more general than that.
It is more general. All or almost all examples have applications for game develop though. Chapters on Qt Quick are more biased towards games but they have a lot of general information as well.

But what I would really like is a comprehensive book on Qt Quick and QML - one with something more substantial than toy examples. Any recommendations there?[/QUOTE]

My book contains about 120 pages (+ some in the bonus chapter) on QtQuick and QML. A purely QtQuick oriented book is qmlbook.org but the examples there are really simple.

@mdavidjohnson: Sorry for offtopic.

[d_stranz]

@mdavidjohnson: Sorry for offtopic.

A little, maybe. But @mdavidjohnson did say he was a newbie and having a hard time with Qt concepts using the book he had at hand. Pointing him towards possibly better resources is still within the scope of the original post. I wish I had discovered some of the books I used in my learning days earlier in the process.

Your book with Lykurg is on order :)