Unable to select files on Fedora 30

[eduperez]

I have been using this nice piece of software on several Fedora releases. After upgrading to Fedora 30, I downloaded and built it (using the "build-hdrmerge") script, but now I cannot select any files, the application just locks without displaying any dialog at all.

If I start the application from the command line, and provide a list of files, everything seems to work, up until when I try to save the results, and again no dialog is being displayed.

[Beep6581]

@eduperez I heard of the filechooser's default window size being very small on some systems - are you sure it's locked up and not just off-screen, in a corner, on a different monitor, or really tiny?

[eduperez]

@Beep6581 Well, the behaviour of the app is consistent with what I would expect if the dialog where someplace I cannot see it. However, I really cannot find it, not with [ALT]+[TAB], or switching to another desktop, etc. If it's there, I really do not know how to bring it up.

[ff2000]

Do you get something printed on the console when the application locks up? Can you still click buttons? I assume not. One way to close dialogs is via "ESC" key. Do you get a responsive main window then? If yes try opening the same file dialog again. Does it show up now? Fedora by default uses GNOME. Can you test hdrmerge on a different Desktop Environment? Or a simple Window Manager like fluxbox?

[eduperez]

I launched the application from the console, and even using "-vv" I could not see any message at all. I cannot click any button, and I cannot close any dialog (using the ESC key or the WM's close icon), everything becomes unresponsible, even Gnome's "Force quit?" dialog is unresponsible.

I'll make more tests using other DEs / WMs.

[eduperez]

I tried with GNOME + Xorg, GNOME + Wayland, and FluxBox: exact same results.

[ff2000]

OK. I want to see if it native vs. not native file dialog. Here is a small test program:

#include <QApplication>
#include <QMainWindow>
#include <QFileDialog>
#include <QDebug>
#include <QtGlobal>
#include <QAction>
#include <QToolBar>

int main(int argc, char** argv) {
    QApplication app(argc, argv);

    QMainWindow mw;    
    QToolBar *tb =  mw.addToolBar("Open/Save");

    QAction* native = tb->addAction("Open File - Native");
    QObject::connect(native, &QAction::triggered, [&mw] () {
        QString file = QFileDialog::getOpenFileName(&mw, "Open File - Native");
        qDebug() << file;
    });

    QAction* noNative = tb->addAction("Open File - Not Native");
    QObject::connect(noNative, &QAction::triggered, [&mw] () {
        QFileDialog fd(&mw);
        if(fd.exec() == QDialog::Accepted) {
            QString file = fd.selectedFiles().front();
            qDebug() << file;
        }
    });

    mw.show();

    return app.exec();
}

project file:

TEMPLATE = app
TARGET = 195
INCLUDEPATH += .
DEFINES += QT_DEPRECATED_WARNINGS
QMAKE_CXXFLAGS += -std=c++11
QT += widgets
SOURCES += main.cpp

Save the cpp file as "main.cpp", the project file as e.g. "195.pro". The run qmake 195.pro, and then make. [[ qmake might be called qmake5 or qmake-qt5 or something like that, probably need to try a little bit ]] Run the test program, should be just "195". There are two actions available. Do they both work? Or don't they work?a

[ff2000]

And a general question: Are you using the qt packages offered by Fedora or are you using an own build? I assume it worked before the upgrade, correct? Did you try a clean build, e.g. delete the whole build folder that was created by the build script?

[Beep6581]

@ff2000 just a quick confirmation that your test-program compiles and both dialogs show correctly in Sabayon/KDE-5.17.1/Qt-5.12.5

[Beep6581]

And when I plugged in an external monitor via HDMI with the desktop extending onto that one, the window and both file-open dialogs appeared on my primary monitor.

[ff2000]

@Beep6581 And with two monitors did the dialog have focus, e.g. could be navigated via arrow keys and closed with ESC?

[Beep6581]

@ff2000 I didn't explicitly test that but I don't see why not - they appeared normal as always, on the primary monitor, using a decent default window size.

[ff2000]

@Beep6581 I was asking for focus because the OP can't get focus for the mainwindow with ESC, so if the dialog really was there it has no input focus.

@eduperez One more thing: When hdrmerge hangs does it consume a lot of CPU?

[eduperez]

OK. I want to see if it native vs. not native file dialog. [...]

I built an ran the program, both native and non-native options work perfectly.

[eduperez]

And a general question: Are you using the qt packages offered by Fedora or are you using an own build?

Everything is as-provided by Fedora.

I assume it worked before the upgrade, correct?

Yes, it has been working across several upgrades, I just have to recompile after each upgrade.

Did you try a clean build, e.g. delete the whole build folder that was created by the build script?

I just deleted everything, then followed the instructions at Compilation in Linux for Linux: same results.

[eduperez]

One more thing: When hdrmerge hangs does it consume a lot of CPU?

Quite the opposite... this what happens when I open the dialog and let it there for a few seconds:

[eperez@delfin ~]$ time hdrmerge
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Killed

real    0m34.044s
user    0m0.273s
sys 0m0.046s

[ff2000]

@eduperez thx for testing. That warning should be gone with Fedora 31: https://fedoraproject.org/wiki/Releases/31/ChangeSet#Qt_Wayland_By_Default_On_Gnome It should also be there with my test program. You can specify QPA Platform manually. Run QT_QPA_PLATFORM=wayland ./hdrmerge - is it working now?

Another issue could be the way hdrmerge constructs the QApplication instance. In the testprogram change this QApplication app(argc, argv); to QApplication app(argc, argv, true); Run make and execute the program. Does the testprogram now also stop responding?

[ff2000]

Seems I still remember mostly Qt4. With Qt4 only the static QFileDialog functions returned a native dialog, Qt5 also does it with QFileDialog instances. One has to set a flag to use non native file dialogs. Could you add this line in the sample?

        QObject::connect(noNative, &QAction::triggered, [&mw] () {
        QFileDialog fd(&mw);
        fd.setOptions(QFileDialog::DontUseNativeDialog); // <--- add this line
        if(fd.exec() == QDialog::Accepted) {
            QString file = fd.selectedFiles().front();
            qDebug() << file;
        }
    });

If that still works (via Not Native Open file) you could remove all the extra lines in hdrmerge. https://github.com/jcelaya/hdrmerge/blob/master/src/LoadOptionsDialog.cpp#L139 change it so it looks like this:

            QFileDialog loadDialog(this, tr("Select raw photos"), lastDirSetting.isNull() ? QDir::currentPath() : QDir(lastDirSetting.toString()).absolutePath(), filter);
    loadDialog.setOptions(QFileDialog::DontUseNativeDialog);
    // loadDialog.setAcceptMode(QFileDialog::AcceptOpen);
    // loadDialog.setFileMode(QFileDialog::ExistingFiles);
    // QList<QUrl> urls = getStdUrls();
    // loadDialog.setSidebarUrls(urls);
    if (loadDialog.exec()) {

Recompile and try to open RAW files through the GUI.

To check if the dialog just has zero size you can add this modification (again, same place in hdrmerge LoadOptionsDialog.cpp):

            QFileDialog loadDialog(this, tr("Select raw photos"), lastDirSetting.isNull() ? QDir::currentPath() : QDir(lastDirSetting.toString()).absolutePath(), filter);
    loadDialog.setOptions(QFileDialog::DontUseNativeDialog);
    loadDialog.resize(800, 800); // <.--- add this line

[eduperez]

@eduperez thx for testing.

Thanks you for your support!

You can specify QPA Platform manually. Run QT_QPA_PLATFORM=wayland ./hdrmerge - is it working now?

No, this only affects to the WM decorations, but the behaviour is the same, both for hdrmerge and the test program.

Another issue could be the way hdrmerge constructs the QApplication instance. In the testprogram change this QApplication app(argc, argv); to QApplication app(argc, argv, true); Run make and execute the program. Does the testprogram now also stop responding?

No, even with that change, both "native" and "not native" buttons work as expected.

[eduperez]

Could you add this line in the sample? [...]

Test app still works after the change.

If that still works (via Not Native Open file) you could remove all the extra lines in hdrmerge. https://github.com/jcelaya/hdrmerge/blob/master/src/LoadOptionsDialog.cpp#L139 [...]

This seems to fix the issue, I see the "Open" dialog, can select the files, and proceed.

[eduperez]

I did another test, and noticed that only these lines need to be commented out:

    //QList<QUrl> urls = getStdUrls();
    //loadDialog.setSidebarUrls(urls);

Both calls to "setAcceptMode" and "setFileMode" are enabled now, and everything still works.

[ff2000]

Awesome! This might "just" be an issue with your file system(configuration) or mounts. I am quite sure that it will hang again if you uncomment (remove the //) the next line QList<QUrl> urls = getStdUrls();, am I right? Then go to https://github.com/jcelaya/hdrmerge/blob/master/src/FileSystem.cpp#L32 Disable the last block

    // QList<QStorageInfo> volumes = QStorageInfo::mountedVolumes();
    // for (auto & volume : volumes) {
    //    if (volume.isValid() && volume.isReady() && !volume.isReadOnly()) {
    //        urls.append(QUrl::fromLocalFile(volume.rootPath()));
    //   }
    // }

recompile, test. If it already works you have the issue, if not take the next out

    // stdLocations = QStandardPaths::standardLocations(QStandardPaths::StandardLocation::PicturesLocation);
    // for (auto & i : stdLocations) {
    //    urls.append(QUrl::fromLocalFile(i));
    // }

And so on.

If you want you can try if you can make the Not Native open file in my test program hang. Qt caches the sidebar urls for its not native file dialogs. It's in ~/.config/QtProject.conf. Rename that file to e.g. QtProject.conf.backup and run my test program. Does it hang now, too?

And do you know how to use gdb? That could help to find the function call that makes the whole program hang. But to be helpful it needs debug packages for all involved libraries, especially Qt, and you need to build hdrmerge with debug symbols. If you want we can find the root for your issue.

[eduperez]

This might "just" be an issue with your file system(configuration) or mounts.

Let me think... file selector, sidebar, URLs... I have a couple of Google Drive mounts (from GNOME's "online accounts"), plus another couple of SAMBA mounts (from a local SMB server), that appear on the sidebar on my file browser (GNOME's "Files" app).

I removed those mounts (both SAMBA and Google Drive), enabled again the call to "setSidebarUrls", and it is working now. And another piece of software (Rapid Photo Downloader) that took ages to start when those mounts where enabled, is now working properly, too.

I am now adding the mounts back (both SAMABA and Google Drive), and it is still working as expected. Perhaps one of those mounts was "stale" (an expired credentials, or an obsolete server, who knows), and that was locking some applications.

Anyway, I think this issue can be closed now; many thanks for your help.