Бывают ли человечьи Immediate Mode GUI?

Дак вся суть IMGUI в том, что библиотеки в целом нахрен и не нужны — почти всё делаешь руками. У меня J2ME-калькулятор по этой парадигме сделан, там голый, по сути, GameCanvas, на котором рисую, и события нативные, и это всё в моей лапше обрабатывается. Там и анимации есть; в одной из переменных задаётся текущий режим графики, отдельные режимы на вьюхи и отдельные на анимации, пока рисуются анимации — всё блочится, естественно (путём того, что при обработке событий эти режимы игнорятся тупо).

Зато всё чётенько и предсказуемо работает, как и нативные гуйцы на телефоне; мне блин, на десктопе этого дико не хватает, нажимаешь кнопку — и хрен пойми, куда это нажатие уйдёт: стопицот виджетов на экране, фокус может быть на любом, и в любой момент может вылезти какая-то бяка и перехватить на себя фокус. Хоть в CLI этого бардака нету, и то хлеб.

Начинается там все со стандартного «MVC плёха»

с появлением идеологии реакта все эти замечательные MVC, а также их многочисленные архитектурные родственники типа MVVM, MVP и т.п. заслуживают только одно место, которого они достойны. на помойке.

Там есть вообще какая-то приличные по современным меркам реализации, пригодные на что-то большее чем накладывание субтитров на видео?

https://github.com/ocornut/imgui/issues/123

с появлением идеологии реакта все эти замечательные MVC, а также их многочисленные архитектурные родственники типа MVVM, MVP и т.п. заслуживают только одно место, которого они достойны. на помойке.

Ничего, что реакт - это только буква V из всего названного?

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

Глупый вопрос, а в чём ключевое отличие?

Вот у меня есть свой GUI тулкит для игры. Я его написал по принципу «чтобы было удобно его писать». Прочитал и не понимаю, к чему его в итоге отнести?

Ещё немного погуглил. Я не понимаю смысла ежекадровой перестройки UI. Вот в чём польза превращения кода UI в лапшу?

в чём польза превращения кода UI в лапшу?

как это в чем? в Immediate Mode GUI разумеется.

X ради X ни к чему хорошему не приводит.

да я шучу. прости, надо было добавить смайлик.

Ещё немного погуглил. Я не понимаю смысла ежекадровой перестройки UI.

Отрисовка всё равно ежекадровая. Если перестройка занимает не больше (или не намного больше) циклов, чем хранение состояния, то проще перестраивать.

Вот в чём польза превращения кода UI в лапшу

В CLI программах вы тоже все вызовы scanf/printf в отдельный модуль выносите, чтобы не «превращать код CLI в лапшу»?

Там как раз примеры уровня «наложить титры». А мне хотелось бы подобие Material Design.

Nuklear, остальные чёт не алё

Не понимаю. Что не хватает в https://cloud.githubusercontent.com/assets/8225057/8307152/3eb04a4c-197a-11e5... , например? Или в https://cloud.githubusercontent.com/assets/8225057/13198792/92808c5c-d812-11e... .

А мне хотелось бы подобие Material Design.

Можно пример? https://material.io/design/material-studies/shrine.html как-то не впечатляет.

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

Не понимаю. Что не хватает в

Хотелось бы понять, как при этом красиво реализовать:

- списки с прокруткой
- анимацию
- скины

CLI это не GUI. Хочешь сравнить консольку с графикой, давай проводить сравнения с TUI.

Если перестройка занимает не больше (или не намного больше) циклов, чем хранение состояния, то проще перестраивать.

Я не про ресурсы. Удобно представлять что у твоего виджета есть определенный lifetime, их можно засунуть друг в друга, есть родители, есть дети. Я не говорю уже про то, что это привычно, это просто логично — держать объекты со своими стейтами.

Вот всё это: https://github.com/ocornut/imgui

- списки с прокруткой : https://raw.githubusercontent.com/wiki/ocornut/imgui/web/v160/code_sample_03_...

- анимацию

он вообще весь про анимацию: https://user-images.githubusercontent.com/10915510/52533145-eef3fd80-2d72-11e...

- скины

https://raw.githubusercontent.com/wiki/ocornut/imgui/web/v160/code_sample_02.png

Более того, а как imgui как концепт накладывается на рендеринг регионами(или как вы хотите ещё его назвать называйте)? Это вообще важно для банальной энергоэффективности. Ибо идея в том, что нет смысла перерисовывать то, стейт чего не поменялся.

Я в свой уже упомнятый GUI тулкит планирую завезти такой режим отрисовки. Например чтобы его завести в embedded Linux, где доступен какой-нибудь экран.

CLI это не GUI. Хочешь сравнить консольку с графикой, давай проводить сравнения с TUI.

А в чём разница? Почему в CLI считается нормальным перемешивать логику и ввод/вывод, а в GUI внезапно надо писать словно на Haskell полностью отделяя логику и интерфейс?

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

Вот в этом и разница. Ведь ты не представляешь, что у строки «Login:» при запуске есть определённый Lifetime. Что можно считать её родителем строки «Password:» и т.д. И вообще писать в стиле https://gist.github.com/madsaune/7749294

В этом и есть принципиальное различие ImGUI и OOP GUI. Для ImGUI виджеты не объекты. Это просто вывод данных или ввод данных. Всё.

В случае Dear ImGUI формируется текстура GL (или аналогичной библиотеки), а уже он перерисовывает.

Цитирую: A common misunderstanding is to mistake immediate mode gui for immediate mode rendering, which usually implies hammering your driver/GPU with a bunch of inefficient draw calls and state changes as the gui functions are called. This is NOT what Dear ImGui does. Dear ImGui outputs vertex buffers and a small list of draw calls batches. It never touches your GPU directly. The draw call batches are decently optimal and you can render them later, in your app or even remotely.

Вот у меня бэкграунд и 10 не пересекающихся прямоугольников. 9 ничего не делают, 1 запрашивает перерисовку для анимации.

Как это накладывается на imgui, если ты не знаешь предыдущее состояние и не уверен, что 9 прямоугольников и бэкграунд уже были отрисованы и есть в FBO или даже на экране уже?

Я вот глянул в реализацию и не нашёл ничего подобного. Ну VBO. И что? Цитата вообще не о том, о чём я спрашиваю.

Про CLI. Я не могу их сравнивать, потому что консоль исторически это последовательное устройство, будь то физический телетайп или виртуальный. И в большинстве программы пишутся, предполагая что нет возможности и необходимости возвращаться на предыдущее состояние. Вход в начале main(), выход там же, в конце. Где-то между ними получал ввод, что-то обрабатывал и куда-то сохранял. Никаких event-loop-ов, никаких exit() посередине исполнения.

В GUI/TUI так не бывает. Юзер имеет свободу производить действия в любом порядке, гоняя программу из одного состояния в другое и обратно, пока наконец юзер не нажмёт кнопку выйти.

При чём тут imgui? А ни при чём. Это я про фундаментальную разницу CLI и GUI, как я её понял для себя.

с появлением идеологии реакта все эти замечательные MVC, а также их многочисленные архитектурные родственники типа MVVM, MVP и т.п. заслуживают только одно место, которого они достойны. на помойке.

React? React + Redux это еще одно MVC, где React - View , Store - Model, Redux - Controller, Action - Interactors (из Taligent MVP).

Даладна!? Мускуль, питон и другие - имеют интерактивный кли.

зачем тащить за собой весь этот старый, ненужный хлам? не понимаю.

1 запрашивает перерисовку для анимации.

В случае imgui это утверждение не имеет смысла. Верно так: программа отрисовывает фон и 10 прямоугольников на нём, один из которых в каждом кадре разный. Если отрисовка идёт в видеодрайвер, то он сам определит, какие области обновились. Ну или можно вручную двойную буферизацию реализовать.

И в большинстве программы пишутся, предполагая что нет возможности и необходимости возвращаться на предыдущее состояние. Вход в начале main(), выход там же, в конце. Где-то между ними получал ввод, что-то обрабатывал и куда-то сохранял. Никаких event-loop-ов, никаких exit() посередине исполнения.

Все диалоговые программы имеют и главный цикл и exit() или return на команду выхода. Примеры: ed, mail, любой интерпретатор, ...

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

В CLI также. В том же консольном mail я могу делать любое действие над письмами пока не введу команду q.

Вся разница только в том, что в CLI все команды приходят через scanf, а в GUI через нажатия мышки/клавиатуры.

Надо спать больше. Я забыл про слово «интерактивный». :)

Но всё же в большинстве своём CLI программы интерактивностью не блещут.

Это слегка устаревшая тема. Сейчас CPU/GPU хватает с большим запасом, и значительного профита от частичной перерисовки ты не получишь.

зачем тащить за собой весь этот старый, ненужный хлам? не понимаю.

Действительно. Зачем писать loosely coupled code, если можно писать spaghetti code, понятный только тебе, и быть незаменимым сотрудником, которого хрен уволишь. Не понимаю.

если можно писать spaghetti code

это ты о чем?

Спасибо. Попробую еще раз посмотреть внимательнее.

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

https://github.com/littlevgl/lv_examples/issues/26#issuecomment-473279547 - вот тут есть скриншоты того, что хотелось бы навалять.

«Ребята, хватит заниматься ерундой. Персонального компьютера не может быть. Могут быть персональный автомобиль, персональная пенсия, персональная дача. Вы вообще знаете что такое ЭВМ? ЭВМ это 100 квадратных метров площади, 25 человек обслуживающего персонала и 30 литров спирта ежемесячно!»

«640k ought to be enough for anybody»

«32-bit address space is quite enough for PC»

«Сейчас CPU/GPU хватает с большим запасом на UI» <- вы находитесь здесь

Тем не менее его продолжают реализовывать. Если есть рядом Android устройство, там можно включить режим, где подсвечиваются обновленные прямоугольники. Там их два — один про окна(кстати тоже полезно, можно посмотреть как работает композитор), второй про частичную перерисовку.

monk, я быть может ошибаюсь, но драйвер GPU и сам GPU хоть и могут так делать, но не обязаны.

Да. С интерпретаторами я немного погорячился. TUI их вроде не назовёшь.

Там скорее видосик внутри канваса. А мне надо типа выезжающих боковых менюшек, всякая красивая кинетика на прокрутке и т.п.

Ясно. Такое потенциально сделать можно (технически оно не отличается от реализации обычной прокрутки). Но практически никто заморачиваться не будет, так как на анимацию нужно кучу кода, а ImGUI библиотеки позиционируются как легковесные. Если легковесность не требуется, можно Qt статически прилинковать, там и анимация и всё остальное.

https://github.com/littlevgl/lv_examples/issues/26#issuecomment-473279547 - вот тут есть скриншоты того, что хотелось бы навалять.

Либо не та ссылка, либо не понял. По ссылке картинки слайдера, галочки, ввода числа кнопками и радиокнопок. Всё это в ImGUI есть и выглядит не хуже.

но драйвер GPU и сам GPU хоть и могут так делать, но не обязаны

Я же написал: можно вручную двойную буферизацию делать. Просто для ImGUI это уровень ниже: OpenGL, SDL, ...

И... тем не менее ты всё равно не можешь сэкономить на gl вызовах.

Всё это хорошо конечно, но поиграться, прототипировать какой-то гуй — вообще самое то. Взял, накидал всё в одной функции и готово. Но для чего-то серьёзного я не могу представить ни во что превратится код, ни на сколько отрисовка будет действительно оптимальной.

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

GUI в принципе не может быть «чем-то серьёзным». Также как не может быть чем-то серьёзным файловый ввод/вывод.

Насчёт «действительно оптимальной отрисовки» вспоминается, что у React'а пересчёт изменений происходит дольше, чем собственно графический вывод. И старые ОС, где планировщик процессов всегда выбирал оптимальный план выполнения. И процесс выбора при большом количестве процессов происходил дольше, чем само выполнение. Поэтому сейчас в линуксе O(1) планировщик, а оптимизация отрисовки возложена на видеокарту.

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

Я хреновый программист, но, мне кажется, этот разврат от того, что люди никогда ui кроме яваскрипта не делали.

прибитыми к чему? к модели? ну да. а разве это не самый разумный и естественный метод?

Объектная модель - да. Что значит «прибитыми». Контрол там — что угодно с методом render. И при отрисовке строится DOM и разность с предыдущим состоянием. Для большого количества простых объектов тормозит.

Для большого количества простых объектов тормозит.

с появлением файбера уже нет

Возможно. Я его давно тыкал. В данном случае реакт просто «например» для случая когда желание оптимального алгоритма приводит к общему замедлению системы.

GUI в принципе не может быть «чем-то серьёзным».

Вот это ты зря. Делать несерьёзно тут нельзя ни в коем случае, ведь именно это увидит твой покупатель.

Да вот пытаюсь вообразить модель данных заказ-наряда на Склад со встроенным контролом комплектации со всеми CSS.

Нет.

пригодные на что-то большее чем накладывание субтитров на видео?

При чём тут субтитры?

Я не против, хочешь - делай. Просто отметил что не стоит в это упираться как в уберфичу, от которой все зависит и без которой ничего не взлетит.

Сейчас CPU/GPU хватает с большим запасом

Попробуйте заполнить текстом холст 4к на CPU используя вашу любимую либу - получите 2.5 FPS.

А что не так? В 1С почти так и есть. Встроенный контрол комплектации называется «ФормаДокумента».

GUI в принципе не может быть «чем-то серьёзным».

Шта?

Нивапрос. Собсна, я и хотел понять, что где куда упирается.

Например, в вебне есть подходы, когда код вкрячивается в темплейты отображения. Но это делается не совсем от балды. И мне был не совсем понятен переход в imgui от базовых принципов к имплементации:

[ full frame render, no state ] => [ код рисовалки ]

Либо не та ссылка, либо не понял. По ссылке картинки слайдера, галочки, ввода числа кнопками и радиокнопок. Всё это в ImGUI есть и выглядит не хуже.

Представь что у тебя дисплей 200*200, и это скриншоты. Есть список настроек, когда в какую-то тыкаешь, сбоку выезжает один из вариантов. Как на мобилке.

Херить анимацию крайне не желательно.