Здравствуйте, SaZ, Вы писали:

SaZ>Ваша проблема — вы не можете понять где вам проинициализировать обработчик. Об этом я тоже выше писал — надо понимать что у вас за события. Без этого не получится предметного разговора.

Все сделал. Вроде архитектурно не плохо... Приводить код и подробно описывать неверное не имеет смысл, но кратко суть такая...

1) В main создаю поток через std::thread создаю поток П1.

2) В потоке П1 создаю обьект класс MYLIB отнаследованного от QApplication. В этом классе обьявленны сигналы и слоты CreateWindow, DestryWindow, и некоторыми функциями для вывода данных в окна.

3) В потоке П1 с помощью QObject::connect с транспортом через Qt::BlockingQueuedConnection, соединяю эти сигналы со слотами.

4) В потоке П1 через статический глобальный std::promise<MYLIB*> MyLib с помощью set_value устанавливаю значение для созданного в П1 обьекта.... Можно было ды обойтись и без глобальной переменной но мне это пока не критично.

5) В потоке П1 запускаю QT exec()... То есть QT поехала... )

5) В main через std::future <MYLIB*> на MyLib жду когда библиотека будет от-инициализирована в потоке П1.

6) В любой точке любого потока пользовательского кода, вызывается например функция (MYLIB*)->CreateWindow которая отрабатывает в SLOT соединенный с CreateWindow. И так как транспорт Qt::BlockingQueuedConnection то пока слот не отработает то пользовательский код висит и ждет.

То есть удалось сделать красиво — избежать диспечеризации событий, но при этом корректно вызывать создание окон из одного единственного потока. И блокировки X11 дисплея удалось избежать, и QT висит на своем exec() и все кросплатформенно.


Думал код тут выложить — там строк 200 вместе с двойной буферизацией черех QPIXMAP... Но думаю нет смысла, мало кому это покажеться интересным..

Здравствуйте, SaZ, Вы писали:

SaZ>Ваша проблема — вы не можете понять где вам проинициализировать обработчик. Об этом я тоже выше писал — надо понимать что у вас за события. Без этого не получится предметного разговора.

Ага. Спасибо....

Но пока с Skorodum-умами пререкались, я все и сделал. Вроде архитектурно не плохо... Приводить код и подробно описывать неверное не имеет смысл, но кратко суть такая...

1) В main создаю поток через std::thread создаю поток П1.

2) В потоке П1 создаю обьект класс MYLIB отнаследованного от QApplication. В этом классе обьявленны сигналы и слоты CreateWindow, DestryWindow, и некоторыми функциями для вывода данных в окна.

3) В потоке П1 с помощью QObject::connect с транспортом через Qt::BlockingQueuedConnection, соединяю эти сигналы со слотами.

4) В потоке П1 через статический глобальный std::promise<MYLIB*> MyLib с помощью set_value устанавливаю значение для созданного в П1 обьекта.... Можно было ды обойтись и без глобальной переменной но мне это пока не критично.

5) В потоке П1 запускаю QT exec()... То есть QT поехала... )

5) В main через std::future <MYLIB*> на MyLib жду когда библиотека будет от-инициализирована в потоке П1.

6) В любой точке любого потока пользовательского кода, вызывается например функция (MYLIB*)->CreateWindow которая отрабатывает в SLOT соединенный с CreateWindow. И так как транспорт Qt::BlockingQueuedConnection то пока слот не отработает то пользовательский код висит и ждет.

То есть удалось сделать красиво — избежать диспечеризации событий, но при этом корректно вызывать создание окон из одного единственного потока. И блокировки X11 дисплея удалось избежать, и QT висит на своем exec() и все кросплатформенно.


Думал код тут выложить — там строк 200 вместе с двойной буферизацией черех QPIXMAP... Но думаю нет смысла, мало кому это покажеться интересным..