A>И у неё самая лучшая документация из того, что я в своей жизни видел.
+100500 уж в плюсовом виде абсолютно точно это самое лучшее, что есть!

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

LVV>А там роботы и сенсорика...
Можно посмотреть на ]slint, от создателей QML.

P.S. Хороший GUI это сложно, а плохой лучше и не делать.

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

S>Это направление для задач, где требуется максимально быстрое отображение, а качеством и удобством GUI можно пожертвовать. Либо там вообще специфические требования к GUI. Это различные инструменты для игростроя, видео- и аудио-редакторы, средства визуализации информации (рисование "стрелок осциллографа" (с) с максимальной скоростью) и вот это вот всё.
FYI: Именно стрелочки и нестандартные контролы сейчас основной рынок для Qt — automotive да прочий embedded.

S>- либо классический GUI. Тогда либо Qt для "тяжелого" GUI (+акцент на паттерны, вроде MVC) или Sciter/Nana для "легкого";
S>- либо immediate mode GUI, тогда Dear ImGUI.
Такие формулировки создают впечателение о лучшей производительности ImGUI. Оно чем-то обоснованно?

SVZ>Тогда почему не sciter?
Я его чего-то плохо понимаю.
xtd, tgui, imgui — понятно.
А скайтер как-то не очень...

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

S>FYI: Именно стрелочки и нестандартные контролы сейчас основной рынок для Qt — automotive да прочий embedded.

Может быть. Я же не зря сказал, что взгляд сильно со стороны.

S>>- либо классический GUI. Тогда либо Qt для "тяжелого" GUI (+акцент на паттерны, вроде MVC) или Sciter/Nana для "легкого";
S>>- либо immediate mode GUI, тогда Dear ImGUI.
S>Такие формулировки создают впечателение о лучшей производительности ImGUI.

Это ложное впечатление. Речь шла о совсем другом подходе. В immediate mode GUI расчет идет на то, что все содержимое окна перерисовывается с заданным ритмом, например 30 или 60 кадров в секунду. Т.е. между рефрешами содержимого у вас есть, скажем, 16ms. Из которых вы 15ms тратите на вычисление того, что нужно отобразить, а оставшуюся 1ms на формирование собственно изображения + все наложенные на него Dear ImGUI контролы. И GUI-слой реализуется именно как цикл: в начале каждой итерации что-то считается/подготавливается, в конце итерации -- выплевывается на экран.

Что принципиально отличается от классического retained mode GUI, где вы содержимое какого-то контрола меняете один раз, когда для него приходят новые данные. И дальше это содержимое остается неизменным и перерисовывается автоматически лишь когда потребуется.

Соответственно, если вам нужно постоянно отображать меняющуюся информацию (вроде графического представления аудио-дорожек в аудио-редакторе), то в рамках immediate mode GUI вы работаете в рамках одной парадигмы, тогда как в retained mode GUI парадигма другая. Результат можно достичь и там, и там. Но есть ощущение, что для каких-то областей immediate mode GUI удобнее или более естественно. Хотя в общем этот подход гораздо менее распространенный.

А в каких-то embedded-ах и вряд ли применим из-за того, что там недопустимо тратить ресурсы на постоянную перерисовку.

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

SVZ>>Тогда почему не sciter?
LVV>Я его чего-то плохо понимаю.
LVV>xtd, tgui, imgui — понятно.
LVV>А скайтер как-то не очень...

Вёрстка на html со стероидами. События в GUI обрабатываются как в браузере.
Можно писать обработчики событий на скриптовом языке, лазить за данными в с++ код, вызывать GUI методы из с++ кода.
Считай полноценный веб-браузер в крошечной (по современным меркам) dll, заточенный на использование в качестве гуя.
Переносимость между основными платформами, правда мы использовали его только под виндой.
Ну и Андрей (AKA c-smile) более-менее доступен для общения. Если не здесь, так на своём сайте.

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

	Картинко

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

S>В immediate mode GUI расчет идет на то, что все содержимое окна перерисовывается с заданным ритмом, например 30 или 60 кадров в секунду. Т.е. между рефрешами содержимого у вас есть, скажем, 16ms. Из которых вы 15ms тратите на вычисление того, что нужно отобразить, а оставшуюся 1ms на формирование собственно изображения + все наложенные на него Dear ImGUI контролы. И GUI-слой реализуется именно как цикл: в начале каждой итерации что-то считается/подготавливается, в конце итерации -- выплевывается на экран.

S>Что принципиально отличается от классического retained mode GUI, где вы содержимое какого-то контрола меняете один раз, когда для него приходят новые данные. И дальше это содержимое остается неизменным и перерисовывается автоматически лишь когда потребуется.
А если эти данные приходят раз в 16ms? Я с Dear ImGUI не работал, но из этого описания, у меня создается ощущение, что вся разница лишь в том, насколько явен цикл. В Qt он больше спрятан из-за сигналов-слотов, но в конце дня все тоже самое. Разве не так?

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

S>А если эти данные приходят раз в 16ms? Я с Dear ImGUI не работал, но из этого описания, у меня создается ощущение, что вся разница лишь в том, насколько явен цикл. В Qt он больше спрятан из-за сигналов-слотов, но в конце дня все тоже самое. Разве не так?

Не-а, совсем не так. Например, в Qt у вас может быть виджет с рабочей областью и какими-то контролами вокруг нее.
В рабочей области вы можете рисовать некую кривую -- тот же осциллограф.
В Qt вы однажды определяете контролы, потом занимаетесь только отрисовкой рабочей области. И если вам нужно рисовать ее 30 раз в секунду, то вы заводите таймер, вешаете на него слот и внутри слота уже занимаетесь рисованием.

В Dear ImGUI вы будете отрисовывать и рабочую область, и контролы вокруг нее на каждой итерации цикла.

Как именно приходят данные -- это отдельный вопрос. Могу только сослаться только на то, что сам делал: окно с отображением нескольких видео-потоков. Видео-фреймы снимаются в другом треде, как-то обрабатываются, готовые для отображения фреймы складываются в специальные места. Основной GUI тред когда приходит время фигачит фреймы из этих мест на экран (через буферизацию, если я правильно помню принцип работы Dear ImGUI). Если к этому времени пришел новый фрейм -- его и отобразим, если нет и все еще лежит старый, то отобразим старый.

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

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

S>Не-а, совсем не так.
В обоих случаях есть цикл. Qt-шные таймеры и слоты крутятся внутри Qt-шного Event Loop.
Понятно, что Qt-шные не перересовывает без необходимости, речь не про это.

Что, по вашему мнению, в Dear ImGUI более "immediate mode" и почему Dear ImGUI более подходит для рисования "с максимальной скоростью" (цитата).

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

S>Понятно, что Qt-шные не перересовывает без необходимости, речь не про это.

В этом не уверен. Если у вас 20 контролов типа QLabel и вы по очереди в каждом из них меняете текст, то я не уверен, что Qt отрисует все это за один раз. Вроде бы он будет отдельно перерисовывать каждый из них. Т.е. вызвали setText и контрол пошел меняться не зная ничего о том, что следом будет меняться и другой контрол.

S>Что, по вашему мнению, в Dear ImGUI более "immediate mode"

То, что я уже написал: в retained mode вы создали 10 кнопок и 15 однострочных редакторов и все. Дальше вы можете менять в них содержимое, а можете и не менять.

В immediate mode вы будете создавать эти 10 кнопок и 15 однострочных редакторов каждый раз, при каждом отображении. И каждый раз вы будете в них устанавливать то, что вы хотите отобразить.

Почему этот режим называется именно "immediate" и какой смысл "immediate" несет по сравнению с "retained" -- это уже вопросы к авторам терминологии.

S>и почему Dear ImGUI более подходит для рисования "с максимальной скоростью" (цитата).

Потому что вы управляете моментом когда нужные вам вещи перерисовываются. Тогда как в Qt вы вызываете какой-то метод у виджета, типа смены текста или заморозки/разморозки, а когда и как это случится вам уже неподвласно.

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

S>В этом не уверен. Если у вас 20 контролов типа QLabel и вы по очереди в каждом из них меняете текст, то я не уверен, что Qt отрисует все это за один раз. Вроде бы он будет отдельно перерисовывать каждый из них. Т.е. вызвали setText и контрол пошел меняться не зная ничего о том, что следом будет меняться и другой контрол.

Будет вызван метод "пометить виджет как грязный", и в конец очереди событий запрос на перерисовку.
Те области, которые попадают в видимую часть экрана/окна, пойдут запросом через paintEvent к конкретным QLabel в пределах одного обновления

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

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

LVV>>А там роботы и сенсорика...
S>Можно посмотреть на slint, от создателей QML.

Ого, интересно. Не знал про такой проект, выглядит многообещающе. Только непонятно по их сайту, что у них с поддержкой мобильных платформ, а так же редакторов кроме vs code.
Но потыкав браузерную демку (последний хром на маке) — выглядит крайне сыро. Те же текстбоксы — размер пляшет когда начинаю что-то писать, шрифты рендерятся отвратительно.

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

SaZ>Ого, интересно. Не знал про такой проект, выглядит многообещающе. Только непонятно по их сайту, что у них с поддержкой мобильных платформ, а так же редакторов кроме vs code.
Мне кажется, что для них основная целевая аудитория — это embedded.

SaZ>Но потыкав браузерную демку (последний хром на маке) — выглядит крайне сыро. Те же текстбоксы — размер пляшет когда начинаю что-то писать, шрифты рендерятся отвратительно.
У меня на винде в хроме не пляшет, но низкое качество шрифтов заметно.

Disclaimer: я slint не использовал, но знаю, что основные разработчики это те, кто стоял у истоков QML в Qt. Они хотят сделать "better QML".

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

LVV>Что-то у меня голова кругом идет.

Мне кажется, реальный выбор очень простой: или Qt или GTK.

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

LVV>Хотя Страуструп в своей книжке для студентов графики функций строил вполне с помощью FLTK.

Да чёрт с ним, со Страуструпом. Во-первых, его книжки невозможно читать, потому, что он ссылается на то, что будет описано несколькими главами позже. У него собственные мысли не структурированы.

Во-вторых, он убил ни в чем не повинного страуса, и этим всё сказано.

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

S>В этом не уверен. Если у вас 20 контролов типа QLabel и вы по очереди в каждом из них меняете текст, то я не уверен, что Qt отрисует все это за один раз. Вроде бы он будет отдельно перерисовывать каждый из них. Т.е. вызвали setText и контрол пошел меняться не зная ничего о том, что следом будет меняться и другой контрол.
Конечно же, это не так.
QWidget::update

This function does not cause an immediate repaint; instead it schedules a paint event for processing when Qt returns to the main event loop. This permits Qt to optimize for more speed and less flicker than a call to repaint() does.

S>В immediate mode вы будете создавать эти 10 кнопок и 15 однострочных редакторов каждый раз, при каждом отображении. И каждый раз вы будете в них устанавливать то, что вы хотите отобразить.
Ок, это делает Diar ImGUI менее эффектитвной.

S>Потому что вы управляете моментом когда нужные вам вещи перерисовываются. Тогда как в Qt вы вызываете какой-то метод у виджета, типа смены текста или заморозки/разморозки, а когда и как это случится вам уже неподвласно.
Конечно же, это не так.
QWidget::repaint()

Repaints the widget directly by calling paintEvent() immediately, unless updates are disabled or the widget is hidden.

class ImmediateWidget : public QWidget {
public:
    ImmediateWidget() {
        QTimer *timer = new QTimer(this);
        // Immediate repaint! Blocking!
        connect(timer, &QTimer::timeout, this, qOverload<>(&ImmediateWidget::repaint));
        timer->start(1000 / 60); // 60 FPS
    }

protected:
    void paintEvent(QPaintEvent *) override {
    ...
    }

TLDR: Qt можно использовать точно так же, как и Dear ImGUI при необходимости, только это анти-паттерн в общем случае.

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

S>А если эти данные приходят раз в 16ms? Я с Dear ImGUI не работал, но из этого описания, у меня создается ощущение, что вся разница лишь в том, насколько явен цикл. В Qt он больше спрятан из-за сигналов-слотов, но в конце дня все тоже самое. Разве не так?

В Qt ты нарисовал в окошко, и если ничего не происходит, оно так и висит в видеопамяти, отрисованным. До следующего изменения никто ничего с ним не делает.

В immediate mode GUI окошко натурально перерисовывается на каждом кадре.

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

S>Что, по вашему мнению, в Dear ImGUI более "immediate mode" и почему Dear ImGUI более подходит для рисования "с максимальной скоростью" (цитата).

Насколько я понимаю, оно там не вокруг програмного event loop крутится, а вокруг OpenGL-ного. Который достаточно жёстко привязан к аппаратной кадровой развёртке.

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

Pzz>Да чёрт с ним, со Страуструпом. Во-первых, его книжки невозможно читать, потому, что он ссылается на то, что будет описано несколькими главами позже. У него собственные мысли не структурированы.
Вот кстати да, несколько раз брался и каждый раз бросал.

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

Pzz>Насколько я понимаю, оно там не вокруг програмного event loop крутится, а вокруг OpenGL-ного.
OpenGL же нет никакого event loop. OpenGL точно также используется и Qt, просто абстракция потольще, но это не значит, что менее эффективная.