Any way to tell when forked/exec'd Qt application's main window is being displayed?

Question

I have a launcher application which will fork and exec a Qt application when the user clicks on the relevant icon.

For visual feedback, I want to display a wait cursor from the time when the user selects an icon, until the requested app's main window is on-screen.

void RocketLauncher::onItemSelect(QListWidgetItem* item)
{
    QApplication::setOverrideCursor(Qt::WaitCursor);

    const AppConfig& app = getAppConfig(item);

    forkAndExec(app.cwd(), app.cmd(), app.args(), app.env());

    // TODO: wait until app's main window is being displayed

    QApplication::restoreOverrideCursor();
}

The problem that I'm having is that in my launcher app, I get back the child process's pid from fork immediately, but it still takes some time for the child process to exec and for its main window to show up on-screen.

As such, my call to QApplication::restoreOverrideCursor() executes immediately, and there is no visual cue to the user that the application is still being launched.

Is there some way I can get signalled that the child is running?

Thomas McGuire · Answer 1 · 2016-03-18T22:10:06.277

I can see two ways to implement this:

With explicit inter-process communication. The child app can tell the launcher app once its main window has been created, for example via a DBus call, standard output, shared memory or any other of the many IPC mechanisms available. There is a startup notification library for X11 that uses explicit IPC by passing X messages, used by KDE and GNOME.
Depending on the OS and the used window manager in there, you might be able to ask the window manager for a list of opened windows and be notified when a new window is created. I don't think there is a Qt API for that, you'd need to use platform-specific code. For X11, you'd do something similar to the xwininfo program. Also, there is a LGPL-licensed KDE Frameworks API for this called KWindowSystem, which has a windowAdded signal. I haven't check on which platforms this is actually implemented, the docs suggest at least X11 and Mac OS.

Mohamed Hamzaoui · Answer 2 · 2016-03-19T09:19:29.073

I suggest you start a thread (with QtConcurrentRun and handled with QFutureWatcher) which is responsible for starting child process and waiting for the end displaying GUI. This mechanism can be done using a pipe in wich you send data from the place in child code where you believe that the GUI is displayed (catch showEvent() or the end of the MainWindow constrcutor...). The thread in parent process must sleep until receiving data on the pipe for waking up.

there is a lot of example of using pipe in linux. Also you can use Unix socket, shared memory or other IPC or maybe you can test with creatin a file in /tmp but is a bad idea.

Another simple idea is to proceed with QProcess and write from your new program some string on standard output to signal end of GUI display (to test...):

bool Class::startExternalProgram(QString _file)
{
    QtConcurrent::run(this, &Class::starting, _file);
    return true;
}

bool Class::starting(QString file)
{
    QProcess *p = new QProcess;
    params << file;
    p->start("your program", params);
    if (!p->waitForStarted(5000)) {
        p->close();
        delete p;
        crashFinish(1, QProcess::CrashExit);
        return false;
    }
    else {
        processes.push_back(p);
        /*to handle crash*/
        QObject::connect(p, SIGNAL(finished(int,QProcess::ExitStatus)),
                         this, SLOT(crashFinish(int, QProcess::ExitStatus)));
        p->waitForReadyRead(600000);/*10mn*/
        ... /*handle timeout here*/
        return true;
    }
}

void Class::crashFinish(int, QProcess::ExitStatus) {
    auto p = qobject_cast<QProcess*>(QObject::sender());
    ...
}

I don't think a thread is needed here, if you have a file descriptor from a pipe you can use ``QSocketNotifier`` in the main thread to get notified when someone writes to the pipe. — Thomas McGuire, Mar 19 '16 at 00:15
Sure it's a good solution except that is necessary to manage a timeout in which case you need to create a QTimer and to deal with timeout. It get's more complex when the program handle several start program request at a time... ? — Mohamed Hamzaoui, Mar 19 '16 at 08:36
About *"maybe you can test with creatin a file in /tmp but is a bad idea"*, it is not very elegant, but I wouldn't call it an outright bad idea. For one thing, it is very portable, easy to implement and understand, and easy to see and test everything works correctly (though file name should contain the pid of child, and parent should also check the time stamp of the file to make sure it is not stale, and QFileSystemWatcher should be used for checking for the file instead of plain QTimer polling). — hyde, Mar 19 '16 at 09:34

Any way to tell when forked/exec'd Qt application's main window is being displayed?

2 Answers2