Re[7]: Создать окна в консольном приложении. Как? - Qt

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

I>Нет тут, надо исходить и того, что такое как бы требование- надо чтобы было консольное приложене. На самом деле это библиотека и надо чтобы ее можно было использовать и в консольном приложении тоже. Все это под линукс, тут все горазло проще чем под виндой. То есть изначально нет разницы что это за приложение. Тут нет такого понятия как "подсистема" как в винде.

дважды прочитал — не опнял

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

I>Как это все сделать с точки зрения архитектуры?
Элементарно, разделяеш простое консольное приложение, имточник данных и гуй.
гуй пускаеш в отдельном потоке и выдаёш ему подписку на источник данных.
а консольное прложение пишет данные в этот самый источник.
С точки зрения архитектуры гуи и простое консольное не должны знать о существовании друг друга.

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

SaZ>Ну так а может стоит подробно описать, что такое "внешнее событие"? В кутэ это либо сигнал, либо QEvent. Что именно это в вашем случае — не ясно. Прерывание, сигнал ОС, какой-нибудь boost signals или сигналы из SObjectizer?

Ну я так обозначил некую абстракцию "внешее событие" внешнее оно по отношению к циклу QT. То есть условно говоря иногда вызывается некий код. Не важно по какой причине.

SaZ>Задача решается так: создаётся отдельный поток в котором делается инстанс QApplication. Пишется прокси, которые транслирует ваши события в Qt signals. Что тут может быть сложного если вы владеете основами Qt — непонятно. Очень не хватает конкретики в исходном вопросе.

Я нифига не владею основами QT ) Я все больше по системным вещам, ну сообственно поэтому и спрашиваю.

То есть создать окно без QApplication никак? А если надо несколько окон, то либо посылать сообщения в поток который создал QApplication, либо множить QApplication для каждого окна?

А если мне надо создавать скажем диалоги, то созданные там, в этом потоке где создан инстанс QApplication, они завесят обработку событий пока не завершаться. ) То есть получается кривоватая вешь эта QT... Какая-то в себе скажем так.

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

I>>То есть получается кривоватая вешь эта QT... Какая-то в себе скажем так.

S>Ты хоть пару примеров собери, прежде чем делать такие "авторитетные" заявления. Судя по тому, что ты тут пишешь, складывается ощущение, что ты вообще не понимаешь как работает любое Qt-based приложение.

Ты крут, мне мрям так сразу помогли твои советы... Спасибо друг. Пиши еще. )

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

BFE>>Приложению ничего не мешает иметь одно консольное окно и несколько графических. При этом вывод всё так же может читаться другой программой.
S>Это к теме не относится, но интересно как псевдографика будет читаться другой программой? И главное зачем?

Фигасе, ты оказывается понял почти ничего из того что он сказал. Но ты всех учишь... Ты крут. Все спасибо. Мне достаточно. Ты помог. )

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

I>Есть простое консольное приложение.

I>Требуется в зависимости от каких-то событий, создавать окна.
В чем проблема создавать окна по событиям?

#include <QApplication>
#include <QDebug>
#include <QTimer>
#include <QMessageBox>

class Application final : public QApplication
{
    Q_OBJECT
    Q_DISABLE_COPY(Application)

public:
    Application(int &argc, char *argv[]) : QApplication(argc, argv)
    {
        QTimer::singleShot(0, this, []{
            qDebug() << "do whatever you have to do, I will show you message box in 5 sec";
            //emulate some event
            QTimer::singleShot(5000, []{
                QMessageBox::information(nullptr, tr("Title"), tr("Message"));
            });
        });
    }
};

int main(int argc, char *argv[])
{
    Application a(argc, argv);
    return a.exec();
}

#include "main.moc"

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

I>Смотрите, вопрос по теме форума, вопрос не простой, вопрос на самом деле актуальный...
Извини, но у меня для тебя плохие новости.
Это настолько базавая и тривиальная вещь в Qt что непонятно, что тебе непонятно

По существу ответил.

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

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

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

I>>>Смотрите, вопрос по теме форума, вопрос не простой, вопрос на самом деле актуальный...
S>>Извини, но у меня для тебя плохие новости.
S>>Это настолько базавая и тривиальная вещь в Qt что непонятно, что тебе непонятно

S>>По существу ответил.

I>Уверен, что вешь трвиальная, но тем не менее... По эвентам это значит я не контролирую процесс выполнения приложения. То есть процесс обработки каких-то внешних по отношению к QT событиям идет лесом. А мне как раз и надо чтобы по какому-то внешнему событию создавались окна и также ассинхронно по отношению к QT они могли закрываться. Тут даже не главное закрывать окна, тут главное чтобы не было потери уравления в результате передачи управления в app.exec... Когда я сам диспечеризирую события QT то я могу также диспечеризировать внешние события.

Ну так а может стоит подробно описать, что такое "внешнее событие"? В кутэ это либо сигнал, либо QEvent. Что именно это в вашем случае — не ясно. Прерывание, сигнал ОС, какой-нибудь boost signals или сигналы из SObjectizer, или какие-то самопальные коллбэки?
В любом случае всё сводится к следующему: создаётся отдельный поток в котором делается инстанс QApplication. Пишется прокси, которые транслирует ваши события в emit somesignal. Делаете класс — обработчик в том же потоке в котором ваш QApplication — и там всю работу с окнами. Что тут может быть сложного если вы владеете основами Qt — непонятно. Очень не хватает конкретики в исходном вопросе.

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

I>Смотрите, вопрос по теме форума, вопрос не простой, вопрос на самом деле актуальный...
Вопрос слишком обширный и не понятно, чего хочет imh0.
Если он хочет несколько консольных окон в одном приложении с одним(!) запущенным процессом — то это не возможно. Однако приложение может запускать самого себя с другими ключами и обеспечивать общение между своими запущенными процессами. Это возможно, но не понятно причём тут Qt.
Если imh0 хочет одно приложение и несколько диалоговых графических окон, то это в Qt делается не то, чтобы совсем просто, но просто.
Есть ещё вариант, обеспечивать окна внутри консоли (псевдографикой). Это возможно и даже имеет смысл, когда приложение запускается на системе, где нет графики, например, внутри соединения по SSH, во встроенных системах, где нет места под обеспечение клиенткой части X Windows.
Возможно imh0 хочет ещё чего-то, чего я не понимаю.

I>Чтобы продемонстрировать это, воспользуюсь темой со стека, из видимо наиболее понятной тут области винды...
I>https://stackoverflow.com/questions/16540743/windows-message-loop-instead-of-qapplicationexec-qapplicationprocesseven
I>В QT есть такие понятия как QApplication QMainWindow QWidget QWindow QDialog и пр. все они строятся на обработке событий.
Ерунда. В Qt есть ровно один цикл обработки сообщений, причём, если мне не изменяет память, он должен находится в основной нитке. Есть возможность встроить свой обработчик внутрь Qt-обработчика, но зачем?!
И как это вообще связано с вопросом imh0?

I>например мы создаем QMainWindow, затем показываем его и запускаем QApplication ... После чего мы получим управление только после того как приложение QApplication завершиться. )) То есть глядя на ответы в теме, так и хочется сказать, коллеги, что вы несете. )
Управление где? В основной нитке? Ну да. Из этого всего лишь следует, что надо запустить свои нитки до того, как будет запущен QApplication::exec().

В частности, если imh0 хочет работать именно с консолью, то нужна одна отдельная нитка на чтение команд из консоли, например. Но, пока что ещё не ясно, чего хочет imh0.

I>Например этот "перец"....
I>

I>Здравствуйте, Bill Baklushi, Вы писали:
BB>>imh0:
I>>>Народ, есть идеи?
BB>>Конечно есть. Берешь и делаешь. В чем сложность?

I>==
I>Помоему надо уже что-то такое делать, экстраординарное, чтобы форумы спасти ) А может и не надо их спасать, просто по-удалять или по-закрывать... )
Прежде чем что-то отвечать, надо понять, чего хочет imh0 и в чём его сложности.

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

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

I>>Ты крут, мне мрям так сразу помогли твои советы... Спасибо друг. Пиши еще. )
S>Зря ерничаешь

Я тебе по существу ответил.

Application a(argc, argv);
a.exec();

Честно? Твой ответ вообще не по теме. Мне надо после a.exec() работать, ты мне привел пример того что и так ясно... Но я уже сказал — извини, но таким тоном можешь разговаривать дома. А лучше и там не надо.

S>Тебе надо Qt хоть немного понять, и чтобы вопрос нормально сформулировать и чтобы ответы понимать.

Ага еще раз спасибо )

Здравствуйте, 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... Но думаю нет смысла, мало кому это покажеться интересным..

Есть простое консольное приложение.

Требуется в зависимости от каких-то событий, создавать окна.
Ну например мы слушаем на каком-то порту, и если соединение произошло то надо создать окно, куда что-то вывести, и закрыть окно только когда соединение закрывается. То есть окно открыть, и при этом продолжать слушать входящие соединения.

К окну прикрепить меню по правой кнопке, и по тому или иному выбору в этом меню запускать разные диалоги. И при этом сохранить способность перерисовывать окно. То есть пока диалог открыт в окне из которого диалог вызвали должно все корректно перерисовываться.

При этом если по сетевому соединению приходят какие-то события то в окне соответствующем этому соединению надо это отображать.

Как это все сделать с точки зрения архитектуры?

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

I>Как это все сделать с точки зрения архитектуры?

может, для визуальной части сделать отдельную gui-шную программу ~~ненавистно висящую в трее~~? и пусть мониторит какой-нибудь файл в простейшем случае или обменивается с консольной по пайпу?

если консоль перестанет быть консолью и превратится в полноценный NT сервис, то разделение неизбежно ибо костыли в виде "interactive service"

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

I>>Как это все сделать с точки зрения архитектуры?

RW>может, для визуальной части сделать отдельную gui-шную программу ~~ненавистно висящую в трее~~? и пусть мониторит какой-нибудь файл в простейшем случае или обменивается с консольной по пайпу?

Нет тут, надо исходить и того, что такое как бы требование- надо чтобы было консольное приложене. На самом деле это библиотека и надо чтобы ее можно было использовать и в консольном приложении тоже. Все это под линукс, тут все горазло проще чем под виндой. То есть изначально нет разницы что это за приложение. Тут нет такого понятия как "подсистема" как в винде.

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

I>>Нет тут, надо исходить и того, что такое как бы требование- надо чтобы было консольное приложене. На самом деле это библиотека и надо чтобы ее можно было использовать и в консольном приложении тоже. Все это под линукс, тут все горазло проще чем под виндой. То есть изначально нет разницы что это за приложение. Тут нет такого понятия как "подсистема" как в винде.

RW>дважды прочитал — не опнял

а если по существу, то раз библиотека, то тем более — пусть пишет в какой-нибудь /var/log/mybestlibevents, консоль или gui, которые используют бибилотеку пусть получают какой-то интерфейс из библотеки что-то IMyBestLibEvents и реагируют на появление событие — консоль пишет в консоль, GUI вспучивает окошки, как-то так

) Ты предложил отдельное GUI приложение. Я говорю, что к сожалению, так нельзя. То есть "нельзя" это такое вот требование. )
Нельзя так как это библиотека и менять структуру приложения она не должна. Ну то есть запускать какое-то внешнее приложения нельзя. Ну например по тому, что это потребует например какой-то аутентификации при запуске. То есть другими словами изза такой ерунды на надо множить сущности.

Поэтому максимум потоки. Никаких отдельный процессов )

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

I>Поэтому максимум потоки. Никаких отдельный процессов )

Насколько я знаю процесс может либо не иметь консоли, либо иметь ровно одну консоль. Так что все окна вам придётся рисовать внутри одной и той же консоли.

А вообще интересно: зачем вам такое извращение в двадцать первом веке? Где вы разыскали алфавитно-цифровой дисплей?

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

I>Есть простое консольное приложение.
I>Требуется в зависимости от каких-то событий, создавать окна.

	Скрытый текст
	I>Ну например мы слушаем на каком-то порту, и если соединение произошло то надо создать окно, куда что-то вывести, и закрыть окно только когда соединение закрывается. То есть окно открыть, и при этом продолжать слушать входящие соединения. I>К окну прикрепить меню по правой кнопке, и по тому или иному выбору в этом меню запускать разные диалоги. И при этом сохранить способность перерисовывать окно. То есть пока диалог открыт в окне из которого диалог вызвали должно все корректно перерисовываться. I>При этом если по сетевому соединению приходят какие-то события то в окне соответствующем этому соединению надо это отображать.

I>Как это все сделать с точки зрения архитектуры?

раз мы в разделе Qt, значит можно создавать графические окна. Если можно создавать графические окна, то в чём, собственно проблема? В обеспечении ввода из консоли?

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

Не воспринимай как ответ имеено тебе... Просто воспользуюсь твоим ответом....

Коллеги, по моему с компетенциями тут на форуме просто пипец...

Смотрите, вопрос по теме форума, вопрос не простой, вопрос на самом деле актуальный...

Чтобы продемонстрировать это, воспользуюсь темой со стека, из видимо наиболее понятной тут области винды...

https://stackoverflow.com/questions/16540743/windows-message-loop-instead-of-qapplicationexec-qapplicationprocesseven

В QT есть такие понятия как QApplication QMainWindow QWidget QWindow QDialog и пр. все они строятся на обработке событий.

например мы создаем QMainWindow, затем показываем его и запускаем QApplication ... После чего мы получим управление только после того как приложение QApplication завершиться. )) То есть глядя на ответы в теме, так и хочется сказать, коллеги, что вы несете. )

Например этот "перец"....

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

BB>imh0:

I>>Народ, есть идеи?
BB>Конечно есть. Берешь и делаешь. В чем сложность?

==
Помоему надо уже что-то такое делать, экстраординарное, чтобы форумы спасти ) А может и не надо их спасать, просто по-удалять или по-закрывать... )

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

I>>Поэтому максимум потоки. Никаких отдельный процессов )

BFE>Насколько я знаю процесс может либо не иметь консоли, либо иметь ровно одну консоль. Так что все окна вам придётся рисовать внутри одной и той же консоли.

Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
Какие окна рисовать внутри консоли? На консоль пишут printf-ом скажем так... Обычно.

BFE>А вообще интересно: зачем вам такое извращение в двадцать первом веке? Где вы разыскали алфавитно-цифровой дисплей?

...

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

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

I>>Смотрите, вопрос по теме форума, вопрос не простой, вопрос на самом деле актуальный...
S>Извини, но у меня для тебя плохие новости.
S>Это настолько базавая и тривиальная вещь в Qt что непонятно, что тебе непонятно

S>По существу ответил.

Уверен, что вешь трвиальная, но тем не менее... По эвентам это значит я не контролирую процесс выполнения приложения. То есть процесс обработки каких-то внешних по отношению к QT событиям идет лесом. А мне как раз и надо чтобы по какому-то внешнему событию создавались окна и также ассинхронно по отношению к QT они могли закрываться. Тут даже не главное закрывать окна, тут главное чтобы не было потери уравления в результате передачи управления в app.exec... Когда я сам диспечеризирую события QT то я могу также диспечеризировать внешние события.

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

I>Уверен, что вешь трвиальная, но тем не менее... По эвентам это значит я не контролирую процесс выполнения приложения. То есть процесс обработки каких-то внешних по отношению к QT событиям идет лесом. А мне как раз и надо чтобы по какому-то внешнему событию создавались окна и также ассинхронно по отношению к QT они могли закрываться.
В чем проблема-то? Произошо событие — открыл окно

Я ж тебе полноценный пример даже сделал

Замени таймер на событие из сети, QMessageBox на своё окно и получишь, то, что тебе надо.

I>Тут даже не главное закрывать окна, тут главное чтобы не было потери уравления в результате передачи управления в app.exec... Когда я сам диспечеризирую события QT то я могу также диспечеризировать внешние события.
У тебя какая-то своя очень специфичная терминология и несуществующие трудности.
Твоя задача с отображением окна при сетевом соеденении совершенно стандартна.

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

BFE>Так что все окна вам придётся рисовать внутри одной и той же консоли.
Это какое-то очень странное утверждение.

BFE>А вообще интересно: зачем вам такое извращение в двадцать первом веке? Где вы разыскали алфавитно-цифровой дисплей?
Работы без окон — вполне стандартное тредование, например когда вывод читается другой программой.

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

SaZ>В любом случае всё сводится к следующему: создаётся отдельный поток в котором делается инстанс QApplication.
Обычно QApplication и все гуёвые события в основном потоке (собственно, QApplication::exec и стартуерт "main event loop"), а вот что-то типа работы с сетью — в отдельных потоках.

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

BFE>>Насколько я знаю процесс может либо не иметь консоли, либо иметь ровно одну консоль. Так что все окна вам придётся рисовать внутри одной и той же консоли.
I>Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
И для каждого придётся запустить отдельный процесс.

I>Какие окна рисовать внутри консоли? На консоль пишут printf-ом скажем так... Обычно.
Вы когда-нибудь far видели? Или midnight commander:

	Вот они, окна внутри консоли:

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

BFE>>>Насколько я знаю процесс может либо не иметь консоли, либо иметь ровно одну консоль. Так что все окна вам придётся рисовать внутри одной и той же консоли.

I>>Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
BFE>И для каждого придётся запустить отдельный процесс.

Да ладно...

I>>Какие окна рисовать внутри консоли? На консоль пишут printf-ом скажем так... Обычно.
BFE>Вы когда-нибудь far видели? Или midnight commander:

А эти? )) Ясно.

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

BFE>>Так что все окна вам придётся рисовать внутри одной и той же консоли.
S>Это какое-то очень странное утверждение.
Ничего странного. Окна не обязаны быть графическими. Их можно рисовать псевдографикой.

BFE>>А вообще интересно: зачем вам такое извращение в двадцать первом веке? Где вы разыскали алфавитно-цифровой дисплей?
S>Работы без окон — вполне стандартное тредование, например когда вывод читается другой программой.
Приложению ничего не мешает иметь одно консольное окно и несколько графических. При этом вывод всё так же может читаться другой программой.

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

BFE>>>>Насколько я знаю процесс может либо не иметь консоли, либо иметь ровно одну консоль. Так что все окна вам придётся рисовать внутри одной и той же консоли.
I>>>Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
BFE>>И для каждого придётся запустить отдельный процесс.
I>Да ладно...
А есть способ?

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

I>>>>Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
BFE>>>И для каждого придётся запустить отдельный процесс.

I>>Да ладно...
BFE>А есть способ?

Да конечно... ) Но это уже чистый офтопик. )

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

I>То есть получается кривоватая вешь эта QT... Какая-то в себе скажем так.
Ты хоть пару примеров собери, прежде чем делать такие "авторитетные" заявления. Судя по тому, что ты тут пишешь, складывается ощущение, что ты вообще не понимаешь как работает любое Qt-based приложение.

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

BFE>Ничего странного. Окна не обязаны быть графическими. Их можно рисовать псевдографикой.
Можно, но речь явно не об этом.

BFE>Приложению ничего не мешает иметь одно консольное окно и несколько графических. При этом вывод всё так же может читаться другой программой.
Это к теме не относится, но интересно как псевдографика будет читаться другой программой? И главное зачем?

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

BFE>Если imh0 хочет одно приложение и несколько диалоговых графических окон, то это в Qt делается не то, чтобы совсем просто, но просто.
И что же в этом непростого?

BFE>Ерунда. В Qt есть ровно один цикл обработки сообщений, причём, если мне не изменяет память, он должен находится в основной нитке.
Не вводите людей в заблуждение. В каждом потоке свой цикл обработки сообщений. Более того, и их можно создавать локально.

I>>например мы создаем QMainWindow, затем показываем его и запускаем QApplication ... После чего мы получим управление только после того как приложение QApplication завершиться. )) То есть глядя на ответы в теме, так и хочется сказать, коллеги, что вы несете. )
BFE>Управление где? В основной нитке? Ну да. Из этого всего лишь следует, что надо запустить свои нитки до того, как будет запущен QApplication::exec().
Один написал ерунду, другой ответил ерундой...

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

I>например мы создаем QMainWindow, затем показываем его и запускаем QApplication ... После чего мы получим управление только после того как приложение QApplication завершиться. ))
Это какой-то бред. Сделать так можно, но зачем?

I>То есть глядя на ответы в теме, так и хочется сказать, коллеги, что вы несете. )
Вот именно.

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

I>Ты крут, мне мрям так сразу помогли твои советы... Спасибо друг. Пиши еще. )
Зря ерничаешь

Я тебе по существу ответил.
Тебе надо Qt хоть немного понять, и чтобы вопрос нормально сформулировать и чтобы ответы понимать.

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

BFE>>Если imh0 хочет одно приложение и несколько диалоговых графических окон, то это в Qt делается не то, чтобы совсем просто, но просто.
S>И что же в этом непростого?
Ввод из консоли.

BFE>>Ерунда. В Qt есть ровно один цикл обработки сообщений, причём, если мне не изменяет память, он должен находится в основной нитке.
S>Не вводите людей в заблуждение. В каждом потоке свой цикл обработки сообщений. Более того, и их можно создавать локально.
Хорошо, уточняю: речь про события отрисовки окон. Все окна должны создаваться и отрисовываться в одной нитке, если я правильно помню.

I>>>например мы создаем QMainWindow, затем показываем его и запускаем QApplication ... После чего мы получим управление только после того как приложение QApplication завершиться. )) То есть глядя на ответы в теме, так и хочется сказать, коллеги, что вы несете. )
BFE>>Управление где? В основной нитке? Ну да. Из этого всего лишь следует, что надо запустить свои нитки до того, как будет запущен QApplication::exec().
S>Один написал ерунду, другой ответил ерундой...

Покажите мне код, где два окна Qt создаются и рисуются независимо/параллельно в двух отдельных нитках.

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

I>>>>>Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
BFE>>>>И для каждого придётся запустить отдельный процесс.
I>>>Да ладно...
BFE>>А есть способ?
I>Да конечно... ) Но это уже чистый офтопик. )

Елки-палки! Опять это секретное знание ускользнёт от меня. Ну намекните хотя бы, в какое из множества консольных окон будет направлен вывод printf?

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

I>Мне надо после a.exec() работать
После у тебя нет цикла обработки сообщиний, сигналы и слоты работать не будут, соответственно окна работать не будут.
Хочешь окна — работай при живом цикле обработки сообщений.

I>Ага еще раз спасибо )
И тебе не кашлять

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

BFE>>>Если imh0 хочет одно приложение и несколько диалоговых графических окон, то это в Qt делается не то, чтобы совсем просто, но просто.
S>>И что же в этом непростого?
BFE>Ввод из консоли.
Выделил начальное утверждение. Что в нем непростого?
Ну ок, изменим условние — добавим ввод из консоли. Что усложнилось-то?

BFE>Хорошо, уточняю: речь про события отрисовки окон. Все окна должны создаваться и отрисовываться в одной нитке, если я правильно помню.
Вот это верно.

BFE>Покажите мне код, где два окна Qt создаются и рисуются независимо/параллельно в двух отдельных нитках.
Зачем? В чем проблема получать события в рабочих потоках и рисовать окна в основном потоке

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

I>Фигасе, ты оказывается понял почти ничего из того что он сказал.
Ты все понял? Ну так ответь можно ли рисовать окошки с помощью ncurses и писать в коносль с помощью printf?
Мне вот такое никогда не требовалось, я не знаю и прямо спрашиваю

I>Но ты всех учишь... Ты крут. Все спасибо. Мне достаточно. Ты помог. )
Всегда обращайся

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

BFE>>>>Если imh0 хочет одно приложение и несколько диалоговых графических окон, то это в Qt делается не то, чтобы совсем просто, но просто.
S>>>И что же в этом непростого?
BFE>>Ввод из консоли.
S>Выделил начальное утверждение. Что в нем непростого?
S>Ну ок, изменим условние — добавим ввод из консоли.
Что значит, "изменим условние"? Название темы однозначно говорит о консольном приложении.

S>Что усложнилось-то?
Например, выход из приложения. Как корректно выйти из консольного приложения (с графическими окнами) ожидающего ввод пользователя при shutdown?

BFE>>Покажите мне код, где два окна Qt создаются и рисуются независимо/параллельно в двух отдельных нитках.
S>Зачем? В чем проблема получать события в рабочих потоках и рисовать окна в основном потоке

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

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

BFE>Что значит, "изменим условние"? Название темы однозначно говорит о консольном приложении.
+1

BFE>Например, выход из приложения. Как корректно выйти из консольного приложения (с графическими окнами) ожидающего ввод пользователя при shutdown?
Установить обработчик на ctrl+c и спросить пользователья точно ли он хочет выйти

BFE>Проблемы могут быть связаны со скоростью: вывод в одно окно тормозит вывод во всех других окнах.
Сколько-нибудь вменяемый для человека вывод ничего тормозить не будет. Миллион записей из БД разом можно вывести, но зачем?

BFE>Так же и обратные сообщения от ввода в окнах: данные к отдельным ниткам проходят через общий цикл, если не делать специальных ухищрений.
И? Взаимодействие пользователя с окнами не может сгенерировать хоть сколько-нибудь значительное количество сигналов.

BFE>Так же могут возникнуть проблемы при завершении отдельных потоков.
Если криво писать — то да, наверное, могут.

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

RW>>может, для визуальной части сделать отдельную gui-шную программу ~~ненавистно висящую в трее~~? и пусть мониторит какой-нибудь файл в простейшем случае или обменивается с консольной по пайпу?

I>Нет тут, надо исходить и того, что такое как бы требование- надо чтобы было консольное приложене. На самом деле это библиотека и надо чтобы ее можно было использовать и в консольном приложении тоже. Все это под линукс, тут все горазло проще чем под виндой. То есть изначально нет разницы что это за приложение. Тут нет такого понятия как "подсистема" как в винде.

А что мешает установить X11 сессию, в нужный момент (а вдруг иксов не окажется, может лучше заранее?) и собственно отрисовать окно (второе, третье) когда нужно, а не на старте программы? В юниксе нет понятия "графическая программа" или "консольная" (как верно замечено, нет понятия подсистемы, как в виндах). Любая программа может сделать что угодно и когда попало.

Но практически, повторюсь, сессию начать наверное стоит на старте, и даже окна может быть создать сразу (чтоб потом не тупить). Просто делать эти окна видимыми по факту необходимости.

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

_>гуй пускаеш в отдельном потоке и выдаёш ему подписку на источник данных.

Главное чтоб гуй случайно не стал многопоточным. Винда так может местами и может,
а X11 заклинит. Нет, что-то отослать (запрос на X11 сервер) ещё так можно, но ответы от сервера,
цикл обработки событий, неизбежно слушать нужно в одном потоке. На самом деле можно не в одном,
но синхронизироваться нужно и непонятно зачем тогда такое нужно. Читать иксовый сокет должен
строго один поток (ждать событий), да и писать одновременно не стоит (в сокете будет мешанина).

_>а консольное прложение пишет данные в этот самый источник.

Я бы просто в отдельном потоке запустил иксовую сессию, цикл обработки событий. И в нём
делал бы все гуёвые дела, событийным методом. И туда же накидывал события от негуёвых
частей системы.

_>С точки зрения архитектуры гуи и простое консольное не должны знать о существовании друг друга.

Да ладно. В виндах все всё знают и всё работает.

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

S>>Это настолько базавая и тривиальная вещь в Qt что непонятно, что тебе непонятно

S>>По существу ответил.

I>Уверен, что вешь трвиальная, но тем не менее... По эвентам это значит я не контролирую процесс выполнения приложения. То есть процесс обработки каких-то внешних по отношению к QT событиям идет лесом.

А всё остальное пускаешь в отдельных потоках. И они накидываюют эвенты в гуёвый евент-луп если
им что-то от него нужно. А он в свою очередь их может пинать через их евент-лупы, если у них
есть, напрямую вызывать их функци и т.п.

I> А мне как раз и надо чтобы по какому-то внешнему событию создавались окна и также ассинхронно по отношению к QT они могли закрываться.

Асинхронно по отношению к графической системе не получится. Цикл на самом деле не в Qt, а в X11.
Т.е. на самом деле в X11 его нет, там только несколько функций которые нужно вызывать в цикле, а
цикл действительно внешний и в Qt, но работать вне цикла не получится вообще тем не менее.

I> Тут даже не главное закрывать окна, тут главное чтобы не было потери уравления в результате передачи управления в app.exec... Когда я сам диспечеризирую события QT то я могу также диспечеризировать внешние события.

В отдельных потоках. По крайней мере в ещё одном отдельном потоке, по меньше мере ещё одном.
Потому, что GUI будет блокироваться на 1) ожидании своих событий, 2) отрисовке.

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

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

I>>Смотрите, вопрос по теме форума, вопрос не простой, вопрос на самом деле актуальный...
BFE>Вопрос слишком обширный и не понятно, чего хочет imh0.
BFE>Если он хочет несколько консольных окон в одном приложении с одним(!) запущенным процессом — то это не возможно.

С хера ли невозможно? Запускай 10 штук xterm'ов и каким-то образом передавай от них файл-дескрипторы, от slave-конца псевдотерминала себе в аппликацию. Через, например, некий мелкий процесс который тебе их, файл-дескрипторы, через сокет обратно вышлет, например. Только я посмотрел, это тебе даже не нужно, т.к. xterm имеет опцию -S, т.е. может рабоать с уже созданным тобой и существующим псевдотерминалом. В общем говно вопрос. У тебя в итоге десяток псевдотерминалов и пиши/читай в любой. Сам, без printf только.

BFE>Есть ещё вариант, обеспечивать окна внутри консоли (псевдографикой).

Для этого есть ncurses.

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

BFE>>Например, выход из приложения. Как корректно выйти из консольного приложения (с графическими окнами) ожидающего ввод пользователя при shutdown?
S>Установить обработчик на ctrl+c и спросить пользователья точно ли он хочет выйти

А если пользователь выходит по Ctrl-\ ? А если по Ctrl-Z и Ctrl-D, Ctrl-D ?
А если пользователь мышкой закрывает xterm в котором программа?
А если зашёл через ssh и тут интернет оборвался?
А если сисадмина обидели, он уволился и в кронтаб вставил kill -11 $RANDOM ?

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

I>...
I>

I>Application a(argc, argv);
I>a.exec();
I>

I>Честно? Твой ответ вообще не по теме. Мне надо после a.exec() работать, ты мне привел пример того что и так ясно... Но я уже сказал — извини, но таким тоном можешь разговаривать дома. А лучше и там не надо.

Что именно нужно делать "после"? С точки зрения Qt ничего "после" быть не может. Если надо "после" — то в отдельном потоке. А лучше — вот этот весь код с QApplication в отдельный поток. Но я об этом уже писал выше.

S>>Тебе надо Qt хоть немного понять, и чтобы вопрос нормально сформулировать и чтобы ответы понимать.
I>Ага еще раз спасибо )

Если хотите абстрактно от Qt — то вы должны понимать и уметь реализовывать в многопоточной среде такие паттерны как chain of responsibility и producer consumer. Иначе все объяснения бесполезны.
Ваша проблема — вы не можете понять где вам проинициализировать обработчик. Об этом я тоже выше писал — надо понимать что у вас за события. Без этого не получится предметного разговора.

P.S. ко всем участникам темы — давайте не переходить на личности и оскорбления, а то достану банхаммер.

Очень псевдокод:

class Handler : public QObject
{
  Q_OBJECT
public:
  // ...
  void on_my_event()
  {
    QTimer::singleShot(0, this, &Handler::show_gui);
  }

  void show_gui()
  {
    // Создаём окно. Это уже будет вызвано в Qt потоке
  }
}

int qt_thread(conditional_variable& cv, Handler *h)
{
  QApplication app;
  h = new Handler;
  h->setParent(&app);
  cv.wake_all();
  return app.exec();
}

void main_thread()
{
  conditional_variable& cv;
  Handler *h = nullptr;

  std::thread t{&qt_thread, cv, h};
  cv.wait();

  // Прилетает сигнал - дёргаем наш прокси
  h->on_my_event();
}

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

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

SaZ>>В любом случае всё сводится к следующему: создаётся отдельный поток в котором делается инстанс QApplication.
S>Обычно QApplication и все гуёвые события в основном потоке (собственно, QApplication::exec и стартуерт "main event loop"), а вот что-то типа работы с сетью — в отдельных потоках.

Там где-то проскакивало условие, что нужно из динамической библиотеки это делать. Всё сводится к тому, что считать "основным потоком". Если в Qt за последние 5 лет ничего не поменялось, то основной поток это тот, в котором инициализируются глобальные qtшные переменные и создаётся QCoreApplication. Делать это в разных потоках так себе идея, но у меня работало.

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

SaZ>Там где-то проскакивало условие, что нужно из динамической библиотеки это делать.
Какая разница какая линкова? Это ничего не меняет

Потоки сторонней библиотеки оборачиваются в QThreaed, события прокидываются в основной поток через стандартные сигналы/слоты.

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

I>>>Как это все сделать с точки зрения архитектуры?

RW>>может, для визуальной части сделать отдельную gui-шную программу ~~ненавистно висящую в трее~~? и пусть мониторит какой-нибудь файл в простейшем случае или обменивается с консольной по пайпу?

I>Нет тут, надо исходить и того, что такое как бы требование- надо чтобы было консольное приложене. На самом деле это библиотека и надо чтобы ее можно было использовать и в консольном приложении тоже. Все это под линукс, тут все горазло проще чем под виндой. То есть изначально нет разницы что это за приложение. Тут нет такого понятия как "подсистема" как в винде.

Раз библиотека — просто реализуешь нужные функции, и всё. А откуда они будут вызываться — проблема пользователя библиотеки

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

BFE>>>>Насколько я знаю процесс может либо не иметь консоли, либо иметь ровно одну консоль. Так что все окна вам придётся рисовать внутри одной и той же консоли.

I>>>Ну во первых консолей можно открыть сколько хочешь, и в винде и в линуксе....
BFE>>И для каждого придётся запустить отдельный процесс.

I>Да ладно...

Не ладно
В линупсах, скорее всего, как-то так же

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

BFE>Елки-палки! Опять это секретное знание ускользнёт от меня. Ну намекните хотя бы, в какое из множества консольных окон будет направлен вывод printf?

Ну, если бы такое было бы возможно, то наверное printf выводил бы в ту консоль, к которой приаттачен STDOUT

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

BFE>>Если он хочет несколько консольных окон в одном приложении с одним(!) запущенным процессом — то это не возможно.

fk0> С хера ли невозможно? Запускай 10 штук xterm'ов и каким-то образом передавай от них файл-дескрипторы, от slave-конца псевдотерминала себе в аппликацию. Через, например, некий мелкий процесс который тебе их, файл-дескрипторы, через сокет обратно вышлет, например. ...

Т.е. сторонний процесс всё равно обязателен.

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

BFE>Т.е. сторонний процесс всё равно обязателен.

)) Нет, не обязателен!! ) Кончай уже офтопить. Где тут винда и консоли в форуме QT?
Как делать рассказывать не буду, и не проси. )

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

BFE>>Проблемы могут быть связаны со скоростью: вывод в одно окно тормозит вывод во всех других окнах.
S>Сколько-нибудь вменяемый для человека вывод ничего тормозить не будет. Миллион записей из БД разом можно вывести, но зачем?

Или будет. От задачи зависит.

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

BFE>>Т.е. сторонний процесс всё равно обязателен.

I>)) Нет, не обязателен!! )
Вы сами себе противоречите.

I>Кончай уже офтопить. Где тут винда и консоли в форуме QT?
Я что-то писал про винду? Винда или линукса, так или иначе придётся создавать отдельный процесс для ввода-вывода.
Что же касается офтопа, то вполне может быть, что вся тема к Qt отношения не имеет, так как для того, чтобы создать приложение, которое запускает несколько общающихся друг с другом процессов с консольными окнами можно сделать как с использованием Qt, так и без Qt.

I>Как делать рассказывать не буду, и не проси. )
Жаль.

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

S>>Установить обработчик на ctrl+c и спросить пользователья точно ли он хочет выйти

fk0> А если пользователь выходит по Ctrl-\ ? А если по Ctrl-Z и Ctrl-D, Ctrl-D ?
Так же установить обработчик, если это желаемое поведение

fk0>А если пользователь мышкой закрывает xterm в котором программа?
fk0>А если зашёл через ssh и тут интернет оборвался?
fk0>А если сисадмина обидели, он уволился и в кронтаб вставил kill -11 $RANDOM ?
Ничего не делать. Стандартное поведение в таких случаях — умереть. Чтобы поведение было нестандартным должны быть очень веские причины.

	От:	imh0
	Дата:	10.11.21 11:13
	Оценка:

	От:	Bill Baklushi
	Дата:	10.11.21 11:17
	Оценка:	+3

	От:	RonWilson
	Дата:	10.11.21 11:41
	Оценка:	+3

	От:	kov_serg
	Дата:	10.11.21 12:05
	Оценка:	+3

	От:	imh0
	Дата:	11.11.21 11:17
	Оценка:	-2

От:	fk0	https://fk0.name
Дата:	12.11.21 23:44
Оценка:

	От:	удусекшл
	Дата:	15.11.21 08:43
	Оценка: