What kind of signals can be emitted in GUI applications before event loop starts

abhic

@Christian-Ehrlicher Okay. Actually I thought that for such classes, signals themselves were emitted only as a result of event processing and hence needed event loop before they can actually be emitted by such Qt classes. It seems you are saying that is wrong assumption.

Is this atleast a valid assumption that signals will not be generated before the "show" call for top level widget or Qt provides no such gurantee and we should not make such assumption?

Pl45m4

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

Is this assumption wrong?

Yes, it's wrong, however I guess I know why you thought so:

Most signals are emitted as reaction on a certain EVENT. So e.g. QPushButton's ::clicked() signal...
... and as you can tell from the name, Qt Events are not propagated without a running Qt Event Loop.
But this has nothing to do with Qt Signals or how theywork.

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    MainWindow w;

    qDebug() << "Nothing to see here";
    w.show();

    qDebug() << "Now starting Event Loop";
    return app.exec();
}

When changing the WindowTitle directly in MainWindow c'tor:
(as per implementation windowTitleChanged is not related to any QEvent)

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
{
    connect(this, &MainWindow::windowTitleChanged, this, [=](const QString &title){
        qDebug() << title;
    });
    setWindowTitle("Foo42");
}

The output is:

"Foo42"
Nothing to see here
Now starting Event Loop

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

Is this atleast a valid assumption that signals will not be generated before the "show" call for top level widget or Qt provides no such gurantee and we should not make such assumption?

Also wrong.
As you can see, show() results in a QShowEvent... and you can use signals with lambdas for example in the c'tor already... way before the widget is shown...
Actually you don't need to show it at all. You can construct a widget and send signals to the QObject instance without the widget ever becoming visible.

Edit:
Added debug output before show() call.

Edit_2:

All you need is a valid QApplication instance (or QCoreApplication for QObjects with no GUI involved --> No QWidget derived classes)
See QTimer (a QObject) and its signals, for example :)
Works just fine without drawing anything on screen

abhic

@Pl45m4 Thank you for explaining with example like this.

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

There are some classes like QItemSelectionModel class which are not derived form QWidget. From my experiments it seems currentChanged is called once for QItemSelectionModel (while using QTreeView) when the view is setup initially before any user click/selection happens.

For above example of QItemSelectionModel currentChanged signal. It seems that this signal is emitted initially also before user clicks anywhere.
I will review my code for what would be a reliable point to add connect such that I dont miss the signal but also all other members have been initialized which might be accessed by corresponding slot

Pl45m4

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

I will review my code for what would be a reliable point to add connect such that I dont miss the signal

If you subclass it and write your own model, connect signals in the constructor.
If you just use QItemSelectionModel connect as soon as possible (when sender and receiver are available and "ready" for whatever you're trying to do next)

You could also check the Qt source code to see where and when the signals are fired.

Christian Ehrlicher

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

For above example of QItemSelectionModel currentChanged signal. It seems that this signal is emitted initially also before user clicks anywhere.

Because it's currentChanged() and not clicked() or whatever. The current index changes as soon as there is data in the view. I don't see what's the problem here tbh.

abhic

@Christian-Ehrlicher I understand that it is being triggered before any click as part of just initial display. I was just trying to understand what is the point at which this signal is emitted . My initial understanding was that it will be emitted after show() call but after discussion today I am not going to make any such assumption.

Pl45m4

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

My initial understanding was that it will be emitted after show() call but after discussion today I am not going to make any such assumption.

What show() call in the context of QItemSelectionModel are you talking about? :D

I was just trying to understand what is the point at which this signal is emitted

As I've said before, go check it!

Here:

https://codebrowser.dev/qt6/qtbase/src/corelib/itemmodels/qitemselectionmodel.cpp.html

There you can see each occurrence of emit currentChanged()

abhic

@Pl45m4

@Pl45m4 said in What kind of signals can be emitted in GUI applications before event loop starts:

What show() call in the context of QItemSelectionModel are you talking about? :

Sorry for missing context.
I am using QStandardItemModel for a tree like model and displaying it using QTreeView. There are some other items also in my window. QItemSelectionItemModel that i was referring to was one that I got from QTreeView. And the show call was referring to show call on the window that contained everything

@Pl45m4 said in What kind of signals can be emitted in GUI applications before event loop starts:

As I've said before, go check it!

Yes, I will check the code. But I don't want to rely on something on the basis of current Qt implementation unless it is also mentioned/guaranteed explicitly in the doc because I don't want something to break if Qt version changes by relying on the current implementation

Thank you everyone for your help on this.

SimonSchroeder

@abhic said in What kind of signals can be emitted in GUI applications before event loop starts:

I will review my code for what would be a reliable point to add connect such that I dont miss the signal but also all other members have been initialized which might be accessed by corresponding slot

I guess you are overthinking a little bit. Just use signal/slot connections where you need them without thinking about when app.exec() is called. I don't think I ever had a problem with slot not being called because the signal was emitted before the main event loop. (But you are right that you have to make sure that members are already initialized.)

JonB

@abhic
As @SimonSchroeder says, not sure why it should be an issue. But if it really bothers you, don't forget you could delay calling the connect()s/attaching your views to models etc. till the event loop has started by doing them in a function on a QTimer::singleShot(0) which you set off just before the app.exec().