avoid crashing QApplication when closing the X11 connection? (typically screen a GUI app after destroying its QMainWindow)

mbruel

Hi,

I've a CmdOrGuiApp that can either run pure Command Line (QCoreApplication) or with a GUI (QApplication + QMainWindow).

Some users would like to be able to use the GUI to prepare all the work graphically on a remote server and then switch Command Line so they can detach and let the process run in background typically using screen so they can close their connection to the server and reattach later whenever.

I was thinking it would not work, but I gave it a try:
I've added an handler on SIGUSR1 to just hide / show the QMainWindow.

void CmdOrGuiApp::hideOrShowGUI()
{
    if (_hmi)
    {
        if (_hmi->isVisible())
            _hmi->hide();
        else
            _hmi->show();
    }
}

of course when I log out from the remote server after having hidden the QMainWindow, the session remains opens as some GUI elements were created and still exist. If I kill the session, it will kill the program on the server with this error: The X11 connection broke (error 1). Did the X11 server die?

So I suppose there is no way to make survive a GUI to the loss of its X11 session. Would there be a way?

I've tried to delete the QMainWindow (instead of hiding it) before closing my connection to the server and I'm still getting the same crash about the X11 connection although I don't use it anymore.

Is there a way to release properly a GUI to continue Command Line when using a QApplication?

mbruel

Well it seems the only way to not crash when closing the X11 Connection is to NOT use a QApplication but only a QCoreApplication. Is that correct?

in my handler I can destroy the QMainwindow, stop the event loop of the QApplication, delete the QApplication, then create a new QCoreApplication, start its event loop and then I can then detach properly and close the X11 connection.

What do you think about this approach?
Will my existing QObjects switch automatically to the event loop of the new QCoreApplication ?
Will they crash?
what happen with the qApp pointer, will it be updated?

Kent-Dorfman

this is not a correct design paradigm. Your client (gui or command line) should be just that: a client...separate the processing backend into a server that run independently of the front end.

mbruel

@Kent-Dorfman it's kind of boring for the user to have to launch a server and then a front end as the server doesn't need to survive the front end. I could launch it as a backgound process but what's the point to loose a Process...
99.9% of my use cases don't need to detach the GUI.
The architecture of the soft is already kind of MVC. One main active object will handle all the logic and will have either only a QCoreApplication (if it runs command line) or both a QApplication and a QMainWindow if it runs with a GUI.
So it could make sense to be able to switch from one mode to another without going through a client/server architecture.
I'm just wondering what would happen if we change the QCoreApplication within an app. The documentation says that there should only be one QCoreApplication per application but what happen if we stop it's event loop delete it and create a new one?

mbruel

It would be great if QApplication or QGuiApplication could provide 2 methods:

releaseGUI : to basically close the x11 session and become a QCoreApplication
initGUI: to do what's done in the constructor which initialize everything needed to have Widgets

This would be a great benefit to avoid as you suggested to develop unnecessary client/server architecture for small apps and just allow to switch mode completely from GUI to CMD.