Здравствуйте, c-smile, Вы писали:
_>>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
CS>Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
CS>Что из этого верно?
Вроде как вполне ясно написано "во многих местах". GUI очевидно к этим местам не относится. Ну разве что я обработчики иногда реализую через лямбды, но это вряд ли можно считать настоящим функциональным стилем. )))
CS>>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
_>>
_>>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
CS>Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
Ну как бы в том же Qt у тебя каждый объект так же может быть проинтерпретирован как экземпляр класса QWidget. И что с того то? Как бы полиморфизм — это и есть базовая особенность ООП. Непонятно что ты этим хотел сказать.
CS>+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Похоже что ты всё же не заглядывал в исходники современных браузеров, но при этом пишешь тут какие-то свои фантазии на эту тему. Загляни хотя бы в папку core/html вебкита и полюбуйся на представленные там файлы. Ты там увидишь и отдельно файлы HTMLSelectElement и отдельно HTMLTextAreaElement и т.д. — собственно все html контролы (да и не только контролы, а просто все тэги). И каждый из них имеет классическое наследование от HTMLElement (или кого-то из его наследников) с кучей методов, помеченных как override. Я даже не могу себе представить более классическую ООП схему. )))
CS>>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>>И это всё отлично ложится как раз на ООП модель.
CS>Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
CS>или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
CS>Если внутреннего устройства то это никого не парит.
CS>Важно как API этого GUI engine устроен и его гранулярность.
API абсолютно одинаковый — набор видимых (контролов) или невидимых (менеджеров разметки и т.п.) объектов, которые можно складывать иерархически (получая некое итоговое дерево). А с учётом наличия компиляторов/интерпретаторов ui/xrc файлов (которые XML внутри), я вообще не вижу никакой разницы между html движками и Qt/wxWidget. Ну кроме того, что HTML движки не представляют возможности статической компиляции в C++.
_>>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
CS>Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
CS>Это вот
CS>CS><body>hello world</body>
CS>
CS>24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
CS>При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
Какая ещё сериализация, ты вообще о чём? Мы тут обсуждаем GUI! Или у тебя приложение стартует, подгружает с сервера свой GUI и только потом его рендерит?
В приложение у тебя будет просто скомпилированная строка типа my_layout.addWidget(new QLabel("hello world")), которая априори эффективнее любого сочетания парсер+рендер.
_>>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).
CS>Я не знаю что такое "локальные настройки" в современном мире.
Ты похоже осознал тенденцию 2000-ых, когда все переходили в веб, но как-то пропустил тенденцию 2010-ых, когда все переходили снова на приложения (только уже мобильные, а не десктопные). Сейчас у каждого приличного сайта по своему приложению в двух главных магазинах. И эти приложения на каждой из платформ выглядят нативно, что сразу заметно — стиль iOS существенно отличается от Android. Это уже не говоря о том, что они меняются от версии к версии.
CS>Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
CS>А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Вот именно, что всё разное. И если при этом инструмент позволяет разработчику забыть про всю эту разность (при этом корректно отображая на каждой платформе все нужные особенности), то это правильный инструмент для кроссплатформенной разработки.
