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

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

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

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

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

Народ, есть идеи?

imh0:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Здравствуйте, 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>А вообще интересно: зачем вам такое извращение в двадцать первом веке? Где вы разыскали алфавитно-цифровой дисплей?

...

Здравствуйте, 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 что непонятно, что тебе непонятно
По существу ответил.

Автор: Skorodum
Дата: 11.11.21

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

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

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

Автор: Skorodum
Дата: 11.11.21

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

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

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

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

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

Автор: Skorodum
Дата: 11.11.21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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