Qt is event driven and yet there is no "start" signal?

reactive

Hi, I'm only a few weeks into Qt, but I've been programming for a long time.

A "wtf" (I say that jokingly) I've stumbled on is that QCoreApplication has
an "aboutToQuit" signal, but no matching "appStarting" signal.
It really would be conceptually nice to have and might make the code nicer to look at and follow.
Creating and showing widgets before exec() just seems "impure".

Event driven programming is kind of like knocking a domino down and setting a rube
goldberg machine into action. Most of the tutorials/examples feature trivial gui apps
where some user action (like selecting a menu option) can put the app into motion -
but what if a programmatic event needs to do this?

With my (almost nonexistent) Qt knowledge all I can think to do would be something like:

@
int main(...){
QCoreApplication app(...);
// some QThread.start() where run(){ sleep for a few seconds, emit some signal }
return app.exec();
}
@

I know Qt started as a widget library, but in non-GUI apps where a signal isn't the result of
a user interaction, a "start" signal would be great.

[EDTI: code formatting, Volker]

giesbert

You could use a Queued slot call to an object to achieve that:

@
QMetaObject::invokeMethod(pObj, SLOT(mySlot()), Qt::QueuedConnection, ...);
@

Or post yourselve an event with QCoreApplication::postEvent(...)

reactive

My understanding is that exec() starts the event loop, right? So from your response I'm guessing it's ok to queue up events before it is started? That's good to know!

I still say a "start" signal would make the API nicer. Josh Bloch gave a good Google Tech Talk once about designing good APIs and he speaks a bit about "symmetrical" APIs. Currently it's a little lopsided in this one respect. ;)

giesbert

exec starts the event loop, that's correct. And quieued events are queued by the event loop so it should work. But I have never tried to queue an event before the event loop is running :-)

Try it out :-)

baysmith

QTimer::singleShot() with a timeout of 0 will send a signal when the event loop starts. You could use this on your own application class with an appStarting() signal.

@
#include <QtCore>
#include <QtGui>

class Application : public QApplication
{
Q_OBJECT
public:
Application(int &argc, char **argv)
: QApplication(argc, argv)
{
QTimer::singleShot(0, this, SIGNAL(appStarting()));
}

signals:
void appStarting();
};

int main(int argc, char *argv[])
{
Application app(argc, argv);

QPushButton *button = new QPushButton("Test");
QObject::connect(&app, SIGNAL(appStarting()), button, SLOT(show()));
QObject::connect(button, SIGNAL(clicked()), &app, SLOT(quit()));

return app.exec();

}

#include "main.moc"
@

goetz

[quote author="Gerolf" date="1296330631"]exec starts the event loop, that's correct. And quieued events are queued by the event loop so it should work. But I have never tried to queue an event before the event loop is running :-)

Try it out :-)[/quote]

Calling show() on the widget queues the first events before QApplication's exec starts (IMHO - I did not check the sources!) - so you're doing this all the time with the samples :-)

vidar

I just wanted to push this thread, as I got the same "problem". I solved it by checking the receipt of a signal by polling via a timer.
It would be great, if the exec() function could emit a "event loop started" signal. Maybe a Qt developer will read this. :-)

goetz

The single shot timer mentioned by Bradley is a good solution for this.

If you want to attract the devs' attentions, please report your request in the "public bugtracker":https://bugreports.qt.nokia.com. This forum is not monitored regularly by the trolls.

vidar

The single shot timer solution did not work in my scenario (or I did something wrong ;). Thanks, I think I will post a feature request.

giesbert

Another option woulkd be to implement the stuff and file a merge request on www.gitorious.org for Qt sources.