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

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

Насколько я вижу сильно со стороны, сейчас в области разработки десктопного GUI на C++ есть два с половиной направления:

Первое направление -- это традиционный "тяжелый" GUI. Который нужен для продвинутых офисных пакетов (а-ля MS Office, LibreOffice, МойОфис и т.д.), мощных CAD-ов и пр. Когда нужны меню, тулбары, разные виды окон, MDI и вот это вот всё. Для этого направления, емнип, предназначены Qt, wxWidgets, FLTK, FOX Toolkit, U++ и пр. Из того, с чем приходилось (когда-то давно) иметь дело в лучшую сторону выделяется только Qt. Их механизм signal-slots, система layout-ов и spacer-ов, делала разработку GUI гораздо более простым и удобным занятием, чем wxWidgets, FOX Tooltip или приснопамятный MFC. ИМХО, учить сейчас людей чему-то отличному от Qt (особенно такому динозавру, как FLTK) -- это диверсия. Учить имеет смысл хорошему, а условный FLTK человек и сам найдет и освоит, если столкнется с ограничениями того же Qt.

Плюс к тому, в таких "тяжелых" классических GUI очень важны не только сами виджеты, но и разные "паттерны", вроде MVC или MVVM.

Ответвление от первого направления -- это легковесный классический GUI. Когда нам нужно всего пара-тройка несложных форм, без всего-того многообразия, которое есть в мире GUI. Типа есть программулина в виде "черного ящика" (демон/служба к примеру), нужно к ней GUI-конфигуратор сделать для дюжины параметров. Здесь имеет смысл смотреть в сторону Sciter или Nana (хотя Nana, возможно, уже и не развивается).

Второе направление -- это т.н. immediate mode GUI, самым известным представителем которого является Dear ImGUI.
Это направление для задач, где требуется максимально быстрое отображение, а качеством и удобством GUI можно пожертвовать. Либо там вообще специфические требования к GUI. Это различные инструменты для игростроя, видео- и аудио-редакторы, средства визуализации информации (рисование "стрелок осциллографа" (с) с максимальной скоростью) и вот это вот всё.

Причем подходы и цели у каждого из этих направлений разные. И вряд ли в рамках одного курса получится дать в достаточной степени и одно, и другое. ИМХО, тут следует определяться:

— либо классический GUI. Тогда либо Qt для "тяжелого" GUI (+акцент на паттерны, вроде MVC) или Sciter/Nana для "легкого";
— либо immediate mode GUI, тогда Dear ImGUI.

Как бы все остальное выглядит попыткой обхитрить самого себя.

Нихрена непонятно, в чем вопрос и о чем речь

Студентам давать Qt! Самое адекватное из всего что есть на плюсах. От остального кровь из глаз. У студентов всю охоту отбить можно и вообще посеять ненависть к десктопным ГУЯм.

PS ну разве что они не на PDP-11 и не ZX Spectrum каких-нить учатся

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

DP>>Студентам давать Qt! Самое адекватное из всего что есть на плюсах. От остального кровь из глаз.
LVV>1. Qt они и вполне сами осваивают.

А зачем им осваивать какое-то говно на занятиях, которое никогда не пригодится, а Qt, на котором они будут в пром разработке писать с 50% вероятностью, осваивать в свободное время?
Ну и тут как, кто-то будет осваивать, кто-то не будет, а если Qt будут все осваивать, то будет обмен информацией и помощь от сокурсников при проблемах.


LVV>2. Не люблю Qt.

Это плохо, когда свои предпочтения ставятся выше объективных обстоятельств, особенно в образовании


LVV>3. Ну их нахрен: https://www.rbc.ru/technology_and_media/06/03/2022/62221a5b9a79472b4f07b5e1
LVV>

LVV>Скандинавский разработчик софта Qt Group, на базе продуктов которого российские компании создают интерфейсы и приложения, ограничил доступ для российских пользователей.

Да и срать. Вы же на линупсе? Qt оттуда уже выпилили? Или ты такой же, как тупые европейсы, которые свою экономику гробят, только чтобы русским подгадить? Решил подгадить им аналогичным способом?

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

LVV>Мне студентов учить, надо чего-то выбрать более-менее не старое (Qt не предлагать — монстр еще тот)

Qt большая, но хорошо структурированная.
Поэтому легко найти нужное место.
Во всяком случае я лазил к ней в потроха и вносил исправления (и оно получалось).
А ещё она хорошо документирована.
И у неё самая лучшая документация из того, что я в своей жизни видел.

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

_>unreal engine 5 вот где можно разгуляться.

Пробовал кстати сделать на анреале аналог консольного HelloWorld. Ну чтоб выглядело как будто консольная прога. С вырезанием всего и вся. Мегов 90 вроде занял финальный билд

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

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

Тут много написали, добавлю что знаю.

Про Qt (адептом которого я являюсь, ибо не вижу аналогов) я бы советовал сразу смотреть в сторону QtQuick/QML, а не виджетов. Да, язык декларативный, со своими плюшками и недостатками. Но перед
этим нужен минимальный фундамент в самом кутэ — это их базовый класс QObject, система сигналов-слотов, понятие свойств (см. макрос Q_PROPERTY). Этого достаточно чтобы сделать связку между C++ и QML. Впрочем, можно делать QtQuick интерфейс на чистых плюсах, не зная синтаксиса QML, но это неудобно.
Почему не нужны виджеты — они стабильные, удобные, но с точки зрения обучения они провоцируют формошлёпство, ибо студенты будут бизнес логику пихать в обработчики кнопок и т.п.
Из плюсов QML — он компилируется практически во что угодно, в том числе webassembly. Можете глянуть пример тут (всё в браузере, можно на лету редактировать QML — https://try.qt.io/projects/outrun-ivi)

Сам не ковырял, но есть ещё достаточно популярный фреймворк — Flutter. Его чаще для мобилок используют. И главный недостаток — нет связки с C++.

В целом и общем, у большинства фреймворков есть следующие недостатки: отсутствие поддержки accessibility (а многие инструменты автотестирования завязаны на него), проблемы с HiDpi экранами или многомониторными системами, проблемы с хоткеями, проблемы с нормальной поддержкой drag-n-drop. Это всё далеко не сразу очевидно и даже в энтерпрайзе не сразу выстреливает, но бороться со всем этим крайне неприятно. Qt в этом плане достаточно хорошо продуман. Казалось бы, а зачем это всё студентам? Но... зачем страдать с чем-то среднего качества, когда можно взять хорошее.

Когда я учился у нас были следующие направления:
Некоторые (в том числе я) упарывались и делали интерфейсы на голом си + винапи, даже без mfc/wtl. Дичь та ещё, но в будущем мне это несколько раз пригодилось, особенно когда занимался встраиванием игровых движков в десктопные редакторы.
Кто-то самостоятельно учил делфи / с++ билдер, но в коде было сплошное формошлёпство, ибо в нашем техникуме в начале 2000-х про паттерны нам никто не рассказывал =)
А большинство делали интерфейсы на ФоксПро 6 — почему-то он взлетел для тех задач, которые нам давали на лабы и курсовые. Хотя в большинстве случаев это было как забивать гвозди микроскопом.

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

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

Это отрадно, конечно, но ничего не говорит о том, что Qt узнает, что следом должен быть отрисован другой QLabel. Да, Qt не будет перерисовывать текст прямо внутри вызова setText, но где гарантии, что после 20 вызовов setText для 20 разных QLabel отрисовка будет сделана в один общий заход?

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

Busy waiting на spin-lock-е тоже менее эффективна в каком-то смысле. Тем не менее за скорость готовы платить.

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

Что-то я вижу в примере вообще не то, о чем я говорил. Вы вызываете у QLabel метод setText и вы не знаете когда именно перерисовка случится. Если после вызова setText нужно еще и вручную repaint вызывать, да еще и для 20 таких объектов, то это такое себе.

S>TLDR: Qt можно использовать точно так же, как и Dear ImGUI

Мне кажется, вам нужно попробовать что-то запрограммировать на Dear ImGUI. Потому что лично у меня не возникло ощущения, что Qt можно использовать точно так же, как Dear ImGUI.

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


LVV>И не говорите, что все от задач зависит.
LVV>Мне студентов учить, надо чего-то выбрать более-менее не старое (Qt не предлагать — монстр еще тот)

студентам однозначно raylib (книга+примеры) для экспериментов и лаб самое то.
если хочется без компиляции treejs (js) в браузере или love2d (lua), pyglet (python3)

для gui придётся qt расказывать ибо оно повсюду, если хочется менее монструозно смотреть альтернативы.
а по поводу монстров есть же unreal engine 5 вот где можно разгуляться.

Здравствуйте, 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) более-менее доступен для общения. Если не здесь, так на своём сайте.

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

	Картинко

DP>Нихрена непонятно, в чем вопрос и о чем речь
Мне пока тоже не очень понятно — на какой библиотеке остановиться...
Посмотрел на xtd — нравится.

DP>Студентам давать Qt! Самое адекватное из всего что есть на плюсах. От остального кровь из глаз.
1. Qt они и вполне сами осваивают.
2. Не люблю Qt.
3. Ну их нахрен: https://www.rbc.ru/technology_and_media/06/03/2022/62221a5b9a79472b4f07b5e1

Скандинавский разработчик софта Qt Group, на базе продуктов которого российские компании создают интерфейсы и приложения, ограничил доступ для российских пользователей.

DP>PS ну разве что они не на PDP-11 и не ZX Spectrum каких-нить учатся
Не надо смешивать лучшую архитектуру на все времена с говном.
Это не одно и то же...

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

А предмет-то как называется? Если UI там просто чтоб был интерфейс, может не стоит мудрить и взять Qt? А то куча времени уйдет на то, для чего курс не предназначен.

А отменяют там его для нас или нет — пофиг. Куча работодателей хотят Qt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что-то у меня голова кругом идет.
OpenGL + версии (хрен знает сколько, да еще ES)
SDL + версии 2 3
GWFL
SFML
А потом на этой базе еще гуй делается.
Вон чего у tgui написано:
SFML_GRAPHICS backend (Uses sfml-graphics for everything)
SFML_OPENGL3 backend (Uses sfml-window and FreeType, using OpenGL to draw)
SDL_GPU backend (Uses SDL and SDL_ttf, using SDL_GPUDevice to draw)
SDL_RENDERER backend (Uses SDL and SDL_ttf, using SDL_Renderer to draw)
SDL_TTF_OPENGL3 backend (Uses SDL and SDL_ttf, using OpenGL to draw)
SDL_TTF_GLES2 backend (Uses SDL and SDL_ttf, using OpenGL ES to draw)
SDL_OPENGL3 backend (Uses SDL and FreeType, using OpenGL to draw)
SDL_GLES2 backend (Uses SDL and FreeType, using OpenGL ES to draw)
GLFW_OPENGL3 backend (Uses GLFW and FreeType, using OpenGL to draw)
GLFW_GLES2 backend (Uses GLFW and FreeType, using OpenGL ES to draw)
RAYLIB backend (Uses raylib for everything)

ImGUI — оно же такое

Эти все подкладки — они для графики ?

xtd — там вообще wxWidget внизу...

U++ — это вообще вся своя среда, как и Qt

А fltk — она без подкладки.
Страуструп вон даже в книжке ее прописал.

Просто глаза разбегаются.

И не говорите, что все от задач зависит.
Мне студентов учить, надо чего-то выбрать более-менее не старое (Qt не предлагать — монстр еще тот)

xtd ?

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

Если даже препод не врубается во все эти флаги, может не стоит студентов напрягать?
И может стоит учить тому, с минимальным опытом чего хоть на работу можно устраиваться? Кому нафиг из работодателей нужен опыт в какой-то TGUI? А с хитрыми флагами потом сами разберутся если надо будет

Я бы посоветовал, перво-наперво, определиться с целями. От них и плясать. Да и тут помочь коллегам будет проще. А то "что учить" слишком размыто

Второе, я бы выбирал из этого списка https://github.com/fffaraz/awesome-cpp?tab=readme-ov-file#gui

Как вариант, дать какой-нить декларативный фреймворк.

Ну или вот тот же достаточно популярный Sciter есть.

H>Если даже препод не врубается во все эти флаги, может не стоит студентов напрягать?
С чего-то надо начинать.
На Qt я когда-то писал.
FLTK сам Страуструп для студентов использовал.
Но сейчас необходимо посмотреть вокруг.
Поэтому и спрашиваю знатоков.

H>А предмет-то как называется? Если UI там просто чтоб был интерфейс, может не стоит мудрить и взять Qt? А то куча времени уйдет на то, для чего курс не предназначен.
Да начальство еще и само не понимает.
Влезли в программу по ИИ.
А там роботы и сенсорика...
Эт, конечно, не гуй, но там, видимо, много всего придется с нуля поднимать.
Гуй — это я и для себя и пролоббировать перед начальством какой-нить такой курс (все одно оне не понимают)...

Предлагаешь игрушки писать ?

Эт они и сами освоят.
Хотя мысль интересная.

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

LVV>Предлагаешь игрушки писать ?
LVV>
Не обязательно.
LVV>Эт они и сами освоят.
LVV>Хотя мысль интересная.

Для визуализации урматов 1, 2, да и вообще бытрая обратная связь.

LVV>>Предлагаешь игрушки писать ?
LVV>>
_>Не обязательно.
_>Для визуализации урматов 1, 2, да и вообще бытрая обратная связь.
По стандарту направления Программная инженерия нет физики вообще...
Но согласен, графические библиотеки вполне подойдут.
Хотя Страуструп в своей книжке для студентов графики функций строил вполне с помощью FLTK.

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

LVV>>>Предлагаешь игрушки писать ?
LVV>>>
_>>Не обязательно.
_>>Для визуализации урматов 1, 2, да и вообще бытрая обратная связь.
LVV>По стандарту направления Программная инженерия нет физики вообще...
LVV>Но согласен, графические библиотеки вполне подойдут.
LVV>Хотя Страуструп в своей книжке для студентов графики функций строил вполне с помощью FLTK.
Графики функций лучше на питоне строить, а вот итереактивную визуализацию лучше в raylib
покрутить матрицы, поумножать кватернионы, анимацию повертеть, более того оно умеет в gltf можно из блендера модели с анимацией засовывать, а если еще подключить какой нибудь esp32+gy87 будет весело

TGUI на базе SFML.
А в SFML есть network — сокеты и все такое...
Ну, и графика там же, и аудио/видео

xtd — там есть консольная часть, можно и в консоли курсором управлять и даже окна делать.
wxWidget для окон из коробки
xUnit сразу там же
И они косят под Go
xtdc run

LVV>U++ — это вообще вся своя среда, как и Qt
Это надо все же попробовать, когда руки дойдут

LVV>А fltk — она без подкладки.
LVV>Страуструп вон даже в книжке ее прописал.
Ну, и это тоже...

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

LVV>Влезли в программу по ИИ.
LVV>А там роботы и сенсорика...
LVV>Эт, конечно, не гуй, но там, видимо, много всего придется с нуля поднимать.
LVV>Гуй — это я и для себя и пролоббировать перед начальством какой-нить такой курс (все одно оне не понимают)...

Тогда почему не sciter?

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 — понятно.
А скайтер как-то не очень...

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

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

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

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

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

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

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

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

OpenGL — это абстракция про то, как рисовать с помощью видеокарты (GPU). Qt может использовать OpenGL для отрисовки, а может и не использовать (например, он может использовать примитивы Win32 или Xlib). А еще Qt может менеджить OpenQL-ное окошко, в котором будет своя собственная, ему неведомая жизнь, а он только место на экране выделит и рамочку к нему пририсует.

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

Pzz>В Qt ты нарисовал в окошко, и если ничего не происходит, оно так и висит в видеопамяти, отрисованным. До следующего изменения никто ничего с ним не делает.
Речь про цикл, он есть в обоих фреймворках.

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

Автор: Skorodum
Дата: 16.09 11:33

даже пример сделал.

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

Pzz>OpenGL — это абстракция про то, как рисовать с помощью видеокарты (GPU). Qt может использовать OpenGL для отрисовки, а может и не использовать (например, он может использовать примитивы Win32 или Xlib). А еще Qt может менеджить OpenQL-ное окошко, в котором будет своя собственная, ему неведомая жизнь, а он только место на экране выделит и рамочку к нему пририсует.
Какое это имеет отношение к вопросу про эффективность Qt vs ImGUI и введеному вами термину "OpenGL-ный event loop"?

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

S>Это отрадно, конечно, но ничего не говорит о том, что Qt узнает, что следом должен быть отрисован другой QLabel. Да, Qt не будет перерисовывать текст прямо внутри вызова setText, но где гарантии, что после 20 вызовов slot does not cause an immediate repaintдля 20 разных QLabel отрисовка будет сделана в один общий заход?
Документация прямо об этом говорит.

The QWidget::update() slot does not cause an immediate repaint; instead it schedules a paint event for processing when Qt returns to the main event loop.

Все последовательные обновления виджетов будут перерисованы один раз при возвращении в цикл событий.

label1->setText("Hello world 1");
...
label20->setText("Hello world 20");

Это одна перерисовка.

S>Что-то я вижу в примере вообще не то, о чем я говорил.
Он делает ровно то, что вы говорили: синхронно обновляет виджет 60 раз в секунду. Рисуйте стрелки.

S>Вы вызываете у QLabel метод setText и вы не знаете когда именно перерисовка случится.
1. Те, кто читают документацию знают — при возврате в цикл событий.
2. Можно вывзать обработчик событий явно
3. Можно и ручками синхронно рисовать как показано выше (зачем — вопрос к вам).

S>Если после вызова setText нужно еще и вручную repaint вызывать, да еще и для 20 таких объектов, то это такое себе.
И действительно, зачем вам такое?

S>Мне кажется, вам нужно попробовать что-то запрограммировать на Dear ImGUI. Потому что лично у меня не возникло ощущения, что Qt можно использовать точно так же, как Dear ImGUI.
У вас какое-то очень странное представление о Qt. Я, честно говоря, очень удивлен.

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

K13>Будет вызван метод "пометить виджет как грязный", и в конец очереди событий запрос на перерисовку.
K13>Те области, которые попадают в видимую часть экрана/окна, пойдут запросом через paintEvent к конкретным QLabel в пределах одного обновления
Причем это так как минимум со времен Qt 4, т.е. 20+ лет. Откуда у людей альтернативные версии Наверное, это травмы от работы с MFC, ImGUI.

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

S>Все последовательные обновления виджетов будут перерисованы один раз при возвращении в цикл событий.

Кто вам сказал? Вашу GUI-нить могут прервать между 10-м и 11-ым вызовом, а за время пока она спит, в цикл событий может нападать еще чего-нибудь.

S>>Что-то я вижу в примере вообще не то, о чем я говорил.
S>Он делает ровно то, что вы говорили: синхронно обновляет виджет 60 раз в секунду. Рисуйте стрелки.

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

S>1. Те, кто читают документацию знают — при возврате в цикл событий.

И когда же этот возврат произойдет?

S>>Если после вызова setText нужно еще и вручную repaint вызывать, да еще и для 20 таких объектов, то это такое себе.
S>И действительно, зачем вам такое?

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

S>>Мне кажется, вам нужно попробовать что-то запрограммировать на Dear ImGUI. Потому что лично у меня не возникло ощущения, что Qt можно использовать точно так же, как Dear ImGUI.
S>У вас какое-то очень странное представление о Qt. Я, честно говоря, очень удивлен.

У меня был в далеком прошлом опыт работы с Qt (Qt3/Qt4). Остались впечатления как об очень удобном, но тормознутом инструменте. Т.е. заниматься формошлепством в Qt одно удовольствие. Делать что-то шустрое (в моем случае нужно было отображать телеметрию по мере ее съема, в том числе кусочки получаеммых из контролируемых приложений логов) -- да ну нафиг, там чуть ли не половину времени съедали преобразования между QString и внешним миром.

А в недалеком прошлом небольшой опыт работы с ImGUI.

И да, я понимаю, как в Qt сделать отображение информации с заданным темпом.
Но это будет ну вот сильно не так, как в ImGUI. Поэтому я и говорю, что нет у меня ощущения, что Qt можно использовать точно так же, как ImGUI.