Strange error with QListWidgetItem that uses QIcon - qt

I am building up a QListWidget, browsing through a directory so that every ".png" gets listed with a preview icon.
The core of my populating loop looks like this:
new QListWidgetItem( QIcon(act_fullname), act_filename);
Right after the whole list is ready, the app crashes.
The error is many times repeated and says this:
On Mac OS X, you might be loading two sets of Qt binaries into the
same process. Check that all plugins are compiled against the right Qt
binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
binaries are being loaded. QObject::moveToThread: Current thread
(0x103339cb0) is not the object's thread (0x10a848670). Cannot move to
target thread (0x103339cb0)
On Mac OS X, you might be loading two sets of Qt binaries into the
same process. Check that all plugins are compiled against the right Qt
binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
binaries are being loaded.
Do you have any ideas?
Thanks for your help!
EDIT:
If I skip the icons there is no problem. I have also tried going
QListWidgetItem *item = new QListWidgetItem(act_filename);
ui->listWidget->addItem(item);
item->setIcon(QIcon(act_fullname));
and got no difference.
EDIT 2:
I do not call QObject::moveToThread(QThread*) I don't even use threads (deliberately at least).
Also, the errors appear to come after the loop. I have cout-ed every iteration and the end of the loop and right after my "end loop cout msg" I see that
objc[56963]: Class QCocoaColorPanelDelegate is implemented in both
/Users/Barnabas/QtSDK/Desktop/Qt/4.8.1/gcc/lib/QtGui.framework/Versions/4/QtGui
and
/Users/Barnabas/Programming/Qt/demo_OpenCV-build-desktop-Desktop_Qt_4_8_1_for_GCC__Qt_SDK__Release/demo_OpenCV.app/Contents/MacOS/../Frameworks/QtGui.framework/Versions/4/QtGui.
One of the two will be used. Which one is undefined.
Here, too, I do not use QCocoaColorPanelDelegate. I don't even know what it is ... :(
But here is my more detailed code:
boost::filesystem::path p("/path/to/dir");
if(boost::filesystem::is_directory(p))
{
for(boost::filesystem::directory_iterator it(p); it!=boost::filesystem::directory_iterator(); ++it)
{
if(it->path().extension().string()==".png")
{
std::cout<< it->path() <<std::endl;
QString item_name( it->path.stem().c_str() );
QString screen_file( it->path.c_str() );
QListWidgetItem *item = new QListWidgetItem(item_name);
QIcon *icon = new QIcon(screen_file);
item->setIcon(*icon); // if I comment this one out, everything is fine.
ui->imageList->addItem(item);
}
}
}
I have also tested it with a single .png and the image was displayed properly in the list but crash followed with the very same messages.

I have finally found the solution: manually removed the Debug and the Release directories.
For those whose similar problem is not solved by this see: this link.

Related

QFileDialog keeps reopening

I wrote a Qt plugin for QGIS, and inside it I have a QPushButton browse_btn to browse for an output folder.
I use the QFileDialog.getExistingDirectory function and it all works fine. However if I close the plugin and open it again, then click the pushbutton to add a path, the opened window for choosing the path will re-open after I choose a path or close it. If I close the plugin a open it again the 'choose path' window will reopen 3 time and so on...
The similar problem is still open here and in comments here and probably solved here, but since there is no code provided I cannot apply it to solve my problem.
The exact code is following:
self.dlg.browse_btn.clicked.connect(self.set_output)
def set_output(self):
folder_path = str(QFileDialog.getExistingDirectory(self.dlg, u"Pick a folder"))
if not folder_path:
return None
I think this happens because each time I open-close the plugin the separate connection is created with self.dlg.browse_btn.clicked.connect(self.set_output), and it only disconnects after I relaunch QGIS
Try this - Add a boolean flag isConnected to your class (or dlg) and init this flag to false.
Then change your connection line to this
if (!self.isConnected):
self.dlg.browse_btn.clicked.connect(self.set_output)
self.isConnected = true

Why does my QPainter instance only draw when I use a specific .png?

I'm creating a simple "frogger" type game with Qt Creator.
I managed to get a player that works with 4 directional keys, and a car that moves on its own across the screen. I have separate Player, Car, and Frogger class.
The Frogger class paints the images in paintEvent:
painter.drawImage(player->getRect(), player->getImage());
painter.drawImage(car->getRect(), car->getImage());
But I'm encountering a problem with trying to load a different image for the car. If I use image.load("player.png"); for both the car and the player constructors, I can see the car moving across the screen as a player image, and the player which moves according to my keys.
However if I replace the image with anything else (all images are in the same folder; I also tried adding it to Qt Creator under "Other files") such as "car.png," it doesn't seem to show up. I tried it with other images, but those don't show up for player either. Any ideas on why this might happen? I commented out my autoMove() function and nothing changes, so I don't think it's related to how I implement my move. Any ideas on what I might be missing?
I guess you can reduce the possible error locations to the procedure when you load the image. Try to confirm this by checking the return value of QImage::load:
QString path = "player.png";
bool loadSuccess = image.load(path);
qDebug() << "Image" << path << "loaded? =>" << loadSuccess;
If this will print false, check if Qt can find exactly the same path when just passing to QFile:
if(!loadSuccess)
qDebug() << " File exists? =>" << QFile::exists(path);
If this will print true, the image format can't be read by Qt. Possibly you use a non-standard PNG encoding. Are the images all from the same source? (Edited by the same image editor for example)
However, if you still get the errors even when the first debug output above always prints true, the error is somewhere else. Then it could help to give us more code of how you use the images.

Qt QFileSystemWatcher on Windows

I have the following issue: I create a QFileSystemWatcher and it runs and works nicely on Linux, but no way on Windows 7. Can you spot anything in the code that might make it not to work?
Thx.
Here is the code to initialize it:
mConfigChangeWatcher = new QFileSystemWatcher();
mConfigChangeWatcher->addPath(config_file_name);
QObject::connect(mConfigChangeWatcher,
SIGNAL(fileChanged(QString)),
this,
SLOT(configFileChanged(QString)));
and this is supposed to be the slot getting the work done:
void MyClass::configFileChanged(const QString &file)
{
qDebug() << "Changed: " << file ;
}
When you check if the file is added to the watcher using QFileSystemWatcher::files() method after the first modification in the file do you get the correct list?
I was with the issue that some applications, when modifing a file, delete the old file from the system and write it again.
Note that QFileSystemWatcher stops monitoring files once they have been renamed or removed from disk, and directories once they have been removed from disk.
I was using QFileSystemWatcher to watch an image file edited by Photoshop. Somehow the file gets removed from the list of files being watched.
I had the same problem and solved it very fast.
Within the slot that manages the fileChanged signal I noted the path disappears from files(). I simply make a check and re-add it if necessary
if (! watcher_.files().contains(path))
{
watcher_.addPath(path);
}
I hope this helps
Fabio

QFileDialog::getExistingDirectory does not close after choosing a folder

In Qt,
QFileDialog *dlg = new QFileDialog();
QDir dir = dlg->getExistingDirectory(this, tr("Choose folder"), qgetenv("HOME"));
opens a folder choose dialog. Once I select a folder (press choose button) the folder is not closing automatically. So I tried:
if(dlg->close() == true) delete(dlg);
When I debug the dlg->close() returns true and the code delete(dlg) is hit. Still the Folder chooser dialog box is not closing.
I am using Ubuntu 11.10 64 bit OS. Using Qt libraries from the repository.
My ultimate aim is just to show a folder chooser dialog and once the folder is chosen the dialog should close. After that processing should continue. How to do this?
Thanks in advance.
Even if QFileDialog::getExistingDirectory is static and doesn't need a QFileDialog object to work, it should close the dialog window when a directory is finally chosen.
By default that function tries to open a native file dialog window, which seems to cause some problems on some platforms.
You should try forcing a non-native dialog by adding the option DontUseNativeDialog:
QString dir = QFileDialog::getExistingDirectory(
this,
tr("Choose folder"),
QDesktopServices::storageLocation(QDesktopServices::HomeLocation),
QFileDialog::ShowDirsOnly | QFileDialog::DontUseNativeDialog);
And remove the two other lines (with new QFileDialog and if(dlg->close()) ...).
getExistingDirectory(...) is a static function.
To add to cmannett85's answer:
You should not make an instance of QDialog. If you do, it's up to you to hide it. Modify your code to read
const QString home = QDesktopServices::storageLocation(QDesktopServices::HomeLocation);
const QDir dir = QFileDialog:getExistingDirectory(this, tr("Choose folder"), home);
This code should be relatively portable. qgetenv("HOME") is Unix-specific. You should not introduce gratuituous platform-specific code in Qt-based projects -- it sort of defeats the purpose of using Qt in the first place.

New in 4.7.4: QDir::homePath() gives out empty string

QString path = QDir::homePath(); // <-- "path" is always ""
Is this a new bug in 4.7.4? use to work well in 4.7.3
I’m on OSX Lion (4.7.3 worked on Lion well).
The “Clear System Environment” probably cleared the HOME environment variable too.
Basically, QDir::homePath() returns QFile::decodeName(QByteArray(::getenv("HOME"))) almost unchecked. And that's an empty string, if there is no HOME variable.
Hmmm It seems the problem is resolved if I don’t use the “Clear System Environment”. I unchecked it, then re-built and it worked fine. could it be the “SHELL” definitions? I can’t think of anything other than that that’s remotely related to this. I guess something caused Qt to have QT_NO_FSFILEENGINE defined and thus to return an empty string:
// from Qt source file: QDir.cpp
QString QDirPrivate()
{
#ifdef QT_NO_FSFILEENGINE
return QString();
#else
return cleanPath(QFSFileEngine::homePath());
#endif
}

Resources