Эх.. а с блокирующими сокетами было бы всё несколько проще..

Гость_me_*,
петля событий потоку необходима, если в этом потоке требуется асинхронно выполнять слоты.

Так у меня и получается что на асинхронный сигнал QFtp надо вызывать слот в этом же потоке.. (например как я уже говорил для анализа и работы листинга директории)

void MyThread::run()
{
QFtp ftp = new QFtp;
ftp->connectToHost("ftp.trolltech.com");
ftp->login();
ftp->list();
......
ftp->close();
exec();
}

Таким образом все слоты будут обрабатываться не до и не после exec, а во время.

т.е. сделать тот самый выход из exec() - quit()/exit(0)

по всей видимости, тут ещё имеют место проблемы с пониманием асинхронное работы сокетов кутэ.

тем более, что ftp будет создан в родительском потоке

void MyThread::run()
{
QFtp ftp;
ftp.connectToHost("ftp.trolltech.com");
exec();
}

Классы QHttp и QFtp предоставляют поддержку протоколов HTTP и FTP на клиентской стороне. Так как эти два протокола используются для решении похожих задач, классы QHttp и QFtp имеют много общих особенностей:

* Неблокирующее поведение. QHttp и QFtp асинхронны. Вы можете отправить ряд команд (также называемые "запросы" для HTTP). Команды выполнятся позже, когда управление вернется к циклу событий Qt.
* ID команд. Каждая команда имеет свой уникальный номер ID, который используется для слежения за выполнением команд. Например, QFtp передает сигналы commandStarted() и commandFinished() с ID команды для каждой выполняемой команды. У QHttp тоже имеются подобные сигналы requestStarted() и requestFinished().
* Индикаторы процесса передачи данных. QHttp и QFtp посылают сигналы при передаче данных (QFtp::dataTransferProgress(), QHttp::dataReadProgress() и QHttp::dataSendProgress()). Вы можете соединить данные сигналы, например, с QProgressBar::setProgress() или QProgressDialog::setProgress().
* Поддержка QIODevice. Оба класса поддерживают загрузку в и скачивание из QIODevice, дополнительно к API, основанному на QByteArray.

Есть два основных способа использования QHttp и QFtp. Самый обычный способ состоит в том, чтобы отслеживать ID команд и следить за выполнением каждой команды, соединившись с соответствующим сигналом. Другой способ состоит в том, чтобы запланировать все команды сразу и соединиться только с сигналом done(), который посылается, когда все команды были выполнены. Первый способ требует большего количества работы, но дает больший контроль над выполнением конкретных задач и позволяет вводить дополнительные команды, основанные на результате предыдущих. Что позволяет обеспечить пользователю детализированную обратную связь.

а дальше уже ловить успешное подключение и действовать дальше ?

не забыв конечнео же сделать connectы всё какие нужно...