It appears to me that what you're missing is that Qt is based on event-driven programming. Qt provides widgets / objects such as buttons, windows, controllers etc which you display to the user. A QPushButton object, for example, is able to receive various events, such as those from clicking a mouse button, or pressing a keyboard key and many more.
With events, Qt provides a slot / signal mechanism for receiving those events and reacting to them. So, as an example, in the case of a QPushButton, there's a signal called 'pressed'. When the user clicks on the button, its pressed signal is emitted. You, as the developer, can connect the pressed signal to a slot, which is a function that you define.
For example, in a class called MyClass that is derived from QObject: -
QPushButton button("Select"); // create a QPushButton object
connect(button, SIGNAL(pressed()), this, SLOT(buttonPressed()));
The connect statement connects the button's 'pressed' signal to the slot function called 'buttonPressed'. You would then define that function: -
void MyClass::buttonPressed()
{
// handle the button pressed event....
}
So you don't actually have any calls to wait for the button to be pressed as the framework and it's architecture is designed this way and you shouldn't need to be putting everything in a while(true) loop.