Здравствуйте, Marty, Вы писали:
M>Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму. Но на самом деле это не всегда и нужно. Во-вторых, я задолбался с ними воевать. Еще в дизайнере контрол кидаеш на лайоут, он по порядку последним добавляется, и нумеруется соответственно, а на форме — первым.
Я одно время много на Делфи писал, а потом на Билдере. И меня раздражал этот визуальный стиль программирования, где надо заходить в кучу окошек и выставлять кучу пропертей. И очень на этом фоне зашли QWidget'ы, где всё описывается кодом, и всё в одном месте, и всё можно посмотреть глазами. Прямо таки бальзам на сердце.
M>>Честно говоря, GUI на Qt писать — то ещё удовольствие. Вот в Дельфях/С++ Билдере было самое классное, и с тех пор всё только хуже и хуже делают
I>А поподробнее можно? Qt Designer с Layout, palette, qt stylesheet, по моему мнению просто в другой вселенной(на голову выше), единственное что было лучше в Билдере и Дельфи это работа с БД из дизайнера, но честно говоря, делать подключение к БД в дизайнере это странно. А, ну и плюс было множество сторонних контролов, но тут вопрос в их качестве и актуальности, а сейчас можно и на https://marketplace.qt.io/ поискать недостающее.
Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму. Но на самом деле это не всегда и нужно. Во-вторых, я задолбался с ними воевать. Еще в дизайнере контрол кидаеш на лайоут, он по порядку последним добавляется, и нумеруется соответственно, а на форме — первым.
Что такое palette — хз.
qt stylesheet — в большинстве случаев он не нужен — хочется просто форму, максимально не отличающуюся от родных в данной ОС.
Связывание контролов с обработчиками событий — то так себе. Причем в вижуалке не всё работает, а то, что работает, тоже подглючивает. Qt Creator — ну, с формами там худо бедно можно работать, но остальное — особенно отладка...
Опять же, моки, уики — в дельфях/билдере такого просто нет. А тут сразу надо разбираться.
Сраная магия сигналов и слотов — отдельное приключение.
В общем, такое, чтобы за полчаса накидать рабочий прототип какого-то приложения или отдельного диалога — не вариант. Я быстрее ручками на WTL напишу, и всё растягиваться будет, как надо, в том числе.
Хотя, конечно, для кроссплатформенного гуя Qt в чем-то неплох. Хотя мне больше wxWidgets зашел
Здравствуйте, Nuzhny, Вы писали:
N> R>А в Delphi/Builder не прописывается кодом?
N> Не помню уже точно. Там было принято работать в дизайнере и все так делали.
Все что можно делать в дизайнере делается и в коде. Можно совмещать, при необходимости. Кроме того, есть даже редактируемое текстовое представление сохраняемых в дизайнтайме данных. Но вот писать простыни тупого кода — это на очень большого любителя.
Здравствуйте, Marty, Вы писали:
M>Честно говоря, GUI на Qt писать — то ещё удовольствие. Вот в Дельфях/С++ Билдере было самое классное, и с тех пор всё только хуже и хуже делают
BS>Вопрос, а как обстоят дела в 2021 году? Вопрос исключительно праздный и практической цели пока не имеет.
Microsoft рекомендует C++\winrt
А если нужно поддерживать чето древнее, то winapi и com все еще в ходу.
Здравствуйте, Marty, Вы писали:
BS>>>Вопрос, а как обстоят дела в 2021 году? Вопрос исключительно праздный и практической цели пока не имеет. N>>Из моего болота видно, как постепенно Qt вытесняет всё, даже C#. Но это для ресурсоёмких и кроссплатформенных приложений.
M>Честно говоря, GUI на Qt писать — то ещё удовольствие. Вот в Дельфях/С++ Билдере было самое классное, и с тех пор всё только хуже и хуже делают
А поподробнее можно? Qt Designer с Layout, palette, qt stylesheet, по моему мнению просто в другой вселенной(на голову выше), единственное что было лучше в Билдере и Дельфи это работа с БД из дизайнера, но честно говоря, делать подключение к БД в дизайнере это странно. А, ну и плюс было множество сторонних контролов, но тут вопрос в их качестве и актуальности, а сейчас можно и на https://marketplace.qt.io/ поискать недостающее.
Здравствуйте, Shtole, Вы писали:
M>>Дельфи/Билдер с тобой не согласны. Борланд допустил ошибку, позволив переманить главного архитектора в Майкрософт. В итоге и Борланд подзагнулся, и Майкрософт родил какое-то говно
S>«Вот какие басни Лафонтена приходится выслушивать!» (М.Булгаков).
S>Двадцать лет назад (боже, как летит время) я работал в команде, где единственный писал всё на WinAPI, а остальные на Delphi. Этот ужас я хорошо помню — десятка три стандартных компонентов, которые натягивают на юзер-кейсы как... вот именно, сову. На глобус. Намётанным глазом Delphi-происхождение этих шедевров распознавалось за три минуты. Нет, конечно были и приличные программы с приличным UI на этой самой Delphi, но они-то как раз писались не так — а с помощью кода и того же WinAPI (в конце концов, это был Тьюринг-полный язык).
Когда надо быстро накидать UI — лучше ничего нет. И пофик на намётанный глаз — эту прогу увидит два-три человека, а выпиливать месяцами клёвый UI — нет возможности.
Это как со стяжками — можно месяц устраивать сухую стяжку, а можно за вечер залить мокрую. Зачем тратить времени больше, чем нужно?
ЗЫ А в винде стандартных контролов гораздо меньше, чем три десятка. Если писать на винапи — то выпиливать что-то нестандартное гораздо дольше.
ЗЗЫ А дельфи приложухи детектились быстро потому, что все новички любили ОК\Cancel делать с зелёной галочкой и красным стоп-знаком. Если без них, то уже и не отличишь, если у разраба руки не из жопы
ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком?
Здравствуйте, Bjorn Skalpe, Вы писали:
BS>Всем привет. Где-то лет 10 назад я забросил программирование на С++ под Windows, в том числе и GUI, и программирую под Linux в области сервисного backend. BS>Когда я бросал, GUI под Windows писали на WinAPI, QT, ATL/WTL и фрейворки над ними, MFC и феймворки над ними, тогда стала появляться мода писать на C#, а функционал бизнес-логики и вычисления выносить через COM.
BS>Вопрос, а как обстоят дела в 2021 году? Вопрос исключительно праздный и практической цели пока не имеет.
Здравствуйте, Nuzhny, Вы писали:
N>Из моего болота видно, как постепенно Qt вытесняет всё, даже C#. Но это для ресурсоёмких и кроссплатформенных приложений.
у opencv есть классы позволяющие сделать простой GUI
Здравствуйте, Nuzhny, Вы писали:
BS>>Вопрос, а как обстоят дела в 2021 году? Вопрос исключительно праздный и практической цели пока не имеет.
N>Из моего болота видно, как постепенно Qt вытесняет всё, даже C#. Но это для ресурсоёмких и кроссплатформенных приложений.
Честно говоря, GUI на Qt писать — то ещё удовольствие. Вот в Дельфях/С++ Билдере было самое классное, и с тех пор всё только хуже и хуже делают
Здравствуйте, netch80, Вы писали:
N>То есть QML вы не заметили? N>Это как раз представитель того подхода, который средний между ними и который становится основным в современном GUI — максимум таки стараются сложить на язык описания, который одновременно N>2) машинночитаемый и машинноизменяемый для визуального редактора,
Вот это к сожаление, не про QML, ни одной формы на qml не видел которую можно в дизайнере увидеть, не то что даже править, там же чуть что выделяем компонент и всё, дизайнер не справляется с отображением.
Всем привет. Где-то лет 10 назад я забросил программирование на С++ под Windows, в том числе и GUI, и программирую под Linux в области сервисного backend.
Когда я бросал, GUI под Windows писали на WinAPI, QT, ATL/WTL и фрейворки над ними, MFC и феймворки над ними, тогда стала появляться мода писать на C#, а функционал бизнес-логики и вычисления выносить через COM.
Вопрос, а как обстоят дела в 2021 году? Вопрос исключительно праздный и практической цели пока не имеет.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>Microsoft рекомендует C++\winrt K>Да ладно? А чего они как переобулись? Вроде двигали всю жизнь C#.
Его и продолжают двигать.
Здравствуйте, Marty, Вы писали:
M>>>Честно говоря, GUI на Qt писать — то ещё удовольствие. Вот в Дельфях/С++ Билдере было самое классное, и с тех пор всё только хуже и хуже делают
I>>А поподробнее можно? Qt Designer с Layout, palette, qt stylesheet, по моему мнению просто в другой вселенной(на голову выше), единственное что было лучше в Билдере и Дельфи это работа с БД из дизайнера, но честно говоря, делать подключение к БД в дизайнере это странно. А, ну и плюс было множество сторонних контролов, но тут вопрос в их качестве и актуальности, а сейчас можно и на https://marketplace.qt.io/ поискать недостающее.
M>Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму. Но на самом деле это не всегда и нужно.
А когда не нужно делать растягивающуюся форму? M>Во-вторых, я задолбался с ними воевать. Еще в дизайнере контрол кидаеш на лайоут, он по порядку последним добавляется, и нумеруется соответственно, а на форме — первым.
Я правильно понял что претензия к автоименнованию контролов? Так то я на форме стараюсь не держать button_1, button_2 и так далее, а давать нормальные названия, а если уж и оставляю, то этот label_18 мне вообще не нужен для логики.
M>Что такое palette — хз.
Палитра, тоже для оформления стиля приложения
M>qt stylesheet — в большинстве случаев он не нужен — хочется просто форму, максимально не отличающуюся от родных в данной ОС.
Тебе можно сказать повезло.
M>Связывание контролов с обработчиками событий — то так себе. Причем в вижуалке не всё работает, а то, что работает, тоже подглючивает.
А пример можно? Но я предпочитаю всё это в С++ коде уже делать, в явном виде, без Auto-Connect в setupUi .
M>Qt Creator — ну, с формами там худо бедно можно работать, но остальное — особенно отладка...
Не MSVC это да, да и к самому редактору у меня есть претензии.
M>Опять же, моки, уики — в дельфях/билдере такого просто нет. А тут сразу надо разбираться.
Зачем в этом разбираться? Ошибку конечно можно сделать, если сам начинаешь писать формы, классы, а не через визард добавляешь новые файлы, но тут уже да, нужно хоть поверхностно знать устройство.
M>Сраная магия сигналов и слотов — отдельное приключение.
Где там магия то?
M>В общем, такое, чтобы за полчаса накидать рабочий прототип какого-то приложения или отдельного диалога — не вариант. Я быстрее ручками на WTL напишу, и всё растягиваться будет, как надо, в том числе.
Я на wtl наверное и за день ничего не накидаю, так как его не знаю. А вот быстро сделать форму в дизайнере проверить её по Ctrl+R что всё расстягивается, и правильно отображается можно, а потом уже логику на С++ написать дело не сложное.
M>Хотя, конечно, для кроссплатформенного гуя Qt в чем-то неплох. Хотя мне больше wxWidgets зашел
Не пробовал, не могу ничего сказать, на там вроде ничего кроме виджетов и нет.
Здравствуйте, Nuzhny, Вы писали:
N>Я одно время много на Делфи писал, а потом на Билдере. И меня раздражал этот визуальный стиль программирования, где надо заходить в кучу окошек и выставлять кучу пропертей. И очень на этом фоне зашли QWidget'ы, где всё описывается кодом, и всё в одном месте, и всё можно посмотреть глазами. Прямо таки бальзам на сердце.
То есть QML вы не заметили?
Это как раз представитель того подхода, который средний между ними и который становится основным в современном GUI — максимум таки стараются сложить на язык описания, который одновременно
1) машинночитаемый для генерации объектов и их связей,
2) машинночитаемый и машинноизменяемый для визуального редактора,
3) человекочитаемый для проверки, контроля и корректировки, где машина не справилась.
И к этому идут все, хоть и по-разному (WPF, Android...)
Здравствуйте, netch80, Вы писали:
N>То есть QML вы не заметили?
Заметил, но уже ушёл из этой области программирования. Я ещё делал GUI на чистом WinAPI, делал свои контролы на DirectDraw для вывода поверх видео, потом делал свои контролы на Direct3D с этой же целью (это для системы видеонаблюдения, где на одном экране десятки видеоканалов, нужны были быстрые контролы, видео выводилось на surface). Вот это всё меня и подкосило, тупо надоело.
Здравствуйте, Marty, Вы писали:
M>Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму.
А я в свое время в WinForms наоборот пришел к лэйаутам с авторазмерами.
M>Но на самом деле это не всегда и нужно.
Там, где не нужно, проблем обычно нет.
M>Во-вторых, я задолбался с ними воевать.
Та же фигня
Здравствуйте, Nuzhny, Вы писали:
N> Я одно время много на Делфи писал, а потом на Билдере. И меня раздражал этот визуальный стиль программирования, где надо заходить в кучу окошек и выставлять кучу пропертей. И очень на этом фоне зашли QWidget'ы, где всё описывается кодом, и всё в одном месте, и всё можно посмотреть глазами. Прямо таки бальзам на сердце.
Здравствуйте, Igore, Вы писали:
M>>Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму. Но на самом деле это не всегда и нужно. I>А когда не нужно делать растягивающуюся форму?
Диалогам многим нафик это не нужно
M>>Во-вторых, я задолбался с ними воевать. Еще в дизайнере контрол кидаеш на лайоут, он по порядку последним добавляется, и нумеруется соответственно, а на форме — первым. I>Я правильно понял что претензия к автоименнованию контролов? Так то я на форме стараюсь не держать button_1, button_2 и так далее, а давать нормальные названия, а если уж и оставляю, то этот label_18 мне вообще не нужен для логики.
Претензия к тому, что я кидаю на layout какой-то элемент, он в дереве элементов в тул окне вниз добавляется, а на форме — почему-то самым первым становится. И никак не поменять. Приходится руками лезть в XML уишный.
M>>qt stylesheet — в большинстве случаев он не нужен — хочется просто форму, максимально не отличающуюся от родных в данной ОС. I>Тебе можно сказать повезло.
Ват? Нафига вот нужно это пестрое аляповатое, в каждом приложении своё? Поубивал бы хреновых дизайнеров
M>>Связывание контролов с обработчиками событий — то так себе. Причем в вижуалке не всё работает, а то, что работает, тоже подглючивает. I>А пример можно? Но я предпочитаю всё это в С++ коде уже делать, в явном виде, без Auto-Connect в setupUi .
В креаторе пожно ПКМ и выбрать go to slot или как-то так — оно само создаёт слот. В интеграторе для вижуалки — этого пункта в меню нет.
В итоге-то оно в тот же код генерится, но зачем руками делать, если можно в UI-редакторе? Если уж использовать UI-редактор, так по полной
M>>Опять же, моки, уики — в дельфях/билдере такого просто нет. А тут сразу надо разбираться. I>Зачем в этом разбираться? Ошибку конечно можно сделать, если сам начинаешь писать формы, классы, а не через визард добавляешь новые файлы, но тут уже да, нужно хоть поверхностно знать устройство.
В креаторе всё работает искаропки, а в MSVC — нифига. Пришлось разбираться, что надо в инклюды проекта дописать, чтобы сгенерённое нашлось.
M>>Сраная магия сигналов и слотов — отдельное приключение. I>Где там магия то?
Да везде. В Билдере я видел типы обработчиков, и "коннект" делался простым присваиванием адреса функции. Тут же хз чего происходит, и, насколько я понял, легко можно обосраться с количеством и типами аргументов. В 11ых плюсах, и с лямбдами стало получше, но всё равно хрень
M>>В общем, такое, чтобы за полчаса накидать рабочий прототип какого-то приложения или отдельного диалога — не вариант. Я быстрее ручками на WTL напишу, и всё растягиваться будет, как надо, в том числе. I>Я на wtl наверное и за день ничего не накидаю, так как его не знаю. А вот быстро сделать форму в дизайнере проверить её по Ctrl+R что всё расстягивается, и правильно отображается можно, а потом уже логику на С++ написать дело не сложное.
А я два дня боролся с этими растягивалками, потом забил, и прибил всё гвоздями
M>>Хотя, конечно, для кроссплатформенного гуя Qt в чем-то неплох. Хотя мне больше wxWidgets зашел I>Не пробовал, не могу ничего сказать, на там вроде ничего кроме виджетов и нет.
Нет, он тоже типа всеобъемлющий, но наверное, победнее, чем кути. Но там я только гуй писал, да. А остальное — на обычных плюсиках. А Qt норовит тебе в каждую дырку без вазелина пролезть.
ЗЫ Еще сборка в Qt Creator'е параллельная через какой-то jom идёт. И эта сцука не умеет в русские пути
Здравствуйте, Nuzhny, Вы писали:
N>Заметил, но уже ушёл из этой области программирования. Я ещё делал GUI на чистом WinAPI, делал свои контролы на DirectDraw для вывода поверх видео, потом делал свои контролы на Direct3D с этой же целью (это для системы видеонаблюдения, где на одном экране десятки видеоканалов, нужны были быстрые контролы, видео выводилось на surface). Вот это всё меня и подкосило, тупо надоело.
А взял бы Sciter и получил бы HTML поверх (или пониз) DirectX. Ну, или HTMLayout, если время давнее было.
Здравствуйте, Bjorn Skalpe, Вы писали:
BS>Всем привет. Где-то лет 10 назад я забросил программирование на С++ под Windows, в том числе и GUI, и программирую под Linux в области сервисного backend. BS>Когда я бросал, GUI под Windows писали на WinAPI, QT, ATL/WTL и фрейворки над ними, MFC и феймворки над ними, тогда стала появляться мода писать на C#, а функционал бизнес-логики и вычисления выносить через COM.
BS>Вопрос, а как обстоят дела в 2021 году? Вопрос исключительно праздный и практической цели пока не имеет.
Здравствуйте, netch80, Вы писали:
N>То есть QML вы не заметили?
Заметил
N>Это как раз представитель того подхода, который средний между ними и который становится основным в современном GUI — максимум таки стараются сложить на язык описания, который одновременно N>1) машинночитаемый для генерации объектов и их связей, N>2) машинночитаемый и машинноизменяемый для визуального редактора, N>3) человекочитаемый для проверки, контроля и корректировки, где машина не справилась.
N>И к этому идут все, хоть и по-разному (WPF, Android...)
Идут, идут. Хоть и по разному, но всё равно через жопу как-то выходит в итоге
Наверное, должно вырасти какое-то новое поколение — поколение декларативных программистов
Здравствуйте, Nuzhny, Вы писали:
R>>А в Delphi/Builder не прописывается кодом?
N>Не помню уже точно. Там было принято работать в дизайнере и все так делали.
Из дизайнера всё сериализовалось в DFM. Обычный текст, вроде даже на том же паскале. Просто туда никто не лазал, потому что не за чем было
Здравствуйте, Marty, Вы писали:
M>>>Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму. Но на самом деле это не всегда и нужно. I>>А когда не нужно делать растягивающуюся форму? M>Диалогам многим нафик это не нужно
С чего бы? То есть при изменении диалога ты заново перекомпануешь всё на нём чтобы всё влезало? И под разные языке не забываешь проверить как всё выглядит?
M>Претензия к тому, что я кидаю на layout какой-то элемент, он в дереве элементов в тул окне вниз добавляется, а на форме — почему-то самым первым становится. И никак не поменять. Приходится руками лезть в XML уишный.
Я куда кидаю виджет туда он и встает, кидаю в начало layout-а он в начало встает, кидаю в конец, он в конец встает, кидаю в середину он в середину встает, видео чтоли запиши этого процесса.
M>Ват? Нафига вот нужно это пестрое аляповатое, в каждом приложении своё? Поубивал бы хреновых дизайнеров
Без коментариев
M>>>Связывание контролов с обработчиками событий — то так себе. Причем в вижуалке не всё работает, а то, что работает, тоже подглючивает. I>>А пример можно? Но я предпочитаю всё это в С++ коде уже делать, в явном виде, без Auto-Connect в setupUi . M>В креаторе пожно ПКМ и выбрать go to slot или как-то так — оно само создаёт слот. В интеграторе для вижуалки — этого пункта в меню нет. M>В итоге-то оно в тот же код генерится, но зачем руками делать, если можно в UI-редакторе? Если уж использовать UI-редактор, так по полной
Ну нет, есть еще стиль кодирования в компании и, on_element_clicked часто не подходит, проще 1 раз самому connect написать.
M>В креаторе всё работает искаропки, а в MSVC — нифига. Пришлось разбираться, что надо в инклюды проекта дописать, чтобы сгенерённое нашлось.
Qt Visual Studio Tools ставишь, работаешь через него и нет у тебя таких проблем.
M>>>Сраная магия сигналов и слотов — отдельное приключение. I>>Где там магия то? M>Да везде. В Билдере я видел типы обработчиков, и "коннект" делался простым присваиванием адреса функции. Тут же хз чего происходит, и, насколько я понял, легко можно обосраться с количеством и типами аргументов. В 11ых плюсах, и с лямбдами стало получше, но всё равно хрень
Не нужно пользоваться старым синтаксисом, если у тебя всё в одном потоке то вызов emit просто вызовет твой slot, если в другом, то информация с аргументами кладется в очередь и потом вызывается в нужно потоке, собственно всё. Тут магического может произойти только то что ты тип новый сделаешь и его надо зарегистрировать.
M>>>В общем, такое, чтобы за полчаса накидать рабочий прототип какого-то приложения или отдельного диалога — не вариант. Я быстрее ручками на WTL напишу, и всё растягиваться будет, как надо, в том числе. I>>Я на wtl наверное и за день ничего не накидаю, так как его не знаю. А вот быстро сделать форму в дизайнере проверить её по Ctrl+R что всё расстягивается, и правильно отображается можно, а потом уже логику на С++ написать дело не сложное. M>А я два дня боролся с этими растягивалками, потом забил, и прибил всё гвоздями
Жуть, там же всё визуально, единственный не очевидный момент установка layout верхнему элементу, нужно сначала добавить child элемент(widget) какой нибудь, потом кликнуть на родителя и после этого можно сделать layout ему.
M>>>Хотя, конечно, для кроссплатформенного гуя Qt в чем-то неплох. Хотя мне больше wxWidgets зашел I>>Не пробовал, не могу ничего сказать, на там вроде ничего кроме виджетов и нет. M>Нет, он тоже типа всеобъемлющий, но наверное, победнее, чем кути. Но там я только гуй писал, да. А остальное — на обычных плюсиках. А Qt норовит тебе в каждую дырку без вазелина пролезть.
Ну, с качеством модулей кроме ui тут такое, часто проще взять другую С/С++ библиотеку
Здравствуйте, Igore, Вы писали:
M>>>>Layout'ы вроде бы штука полезная, когда надо сделать растягивающуюся форму. Но на самом деле это не всегда и нужно. I>>>А когда не нужно делать растягивающуюся форму? M>>Диалогам многим нафик это не нужно I>С чего бы? То есть при изменении диалога ты заново перекомпануешь всё на нём чтобы всё влезало? И под разные языке не забываешь проверить как всё выглядит?
Часто не нужно ничего изменять. Или, если добавляется — то внизу — чего тут перекомпоновывать
На WTL, к слову, у меня своя растягивалка написана, по чьим-то мотивам. Что-то перемещается, что-то растягивается, что-то на своём месте остаётся. И всё. Этого вполне хватает без всяких иерархий layout'ов.
По поводу языков — я, когда писал приложухи на "мировой рынок", делал так, что от языка ничего не зависело. А сейчас мне даже английский не нужен, только русский.
M>>Претензия к тому, что я кидаю на layout какой-то элемент, он в дереве элементов в тул окне вниз добавляется, а на форме — почему-то самым первым становится. И никак не поменять. Приходится руками лезть в XML уишный. I>Я куда кидаю виджет туда он и встает, кидаю в начало layout-а он в начало встает, кидаю в конец, он в конец встает, кидаю в середину он в середину встает, видео чтоли запиши этого процесса.
Хм. Я наверное не догадался. Есть VLayout, кинутый на него виджет сразу на него растягивается, куда остальные кидать, я не понимаю. Пробовал кидать в дерево тул окне, так виджеты почему-то сверху добавляются. Надо будет проверить, кинуть таки на форму, может сработает. Хотя вроде пробовал, тоже какое-то г получилось, но не уверен, надо будет повторить эксперимент
M>>В итоге-то оно в тот же код генерится, но зачем руками делать, если можно в UI-редакторе? Если уж использовать UI-редактор, так по полной I>Ну нет, есть еще стиль кодирования в компании и, on_element_clicked часто не подходит, проще 1 раз самому connect написать.
Я пришел к выводу, что на местах стыка с другими системами оставлять тот стиль, который они предлагают. Заодно и лучше видно, что за код, к чему относится.
У нас в конторе обычно морды писли на шарпе. И есть одна тулза, которая код генерит, плюсовый для контроллера и шарповый для морды. И она умеет в том числе имена генерить в заданном стиле — camel, c++, pascal etc. ну и там был какой-то нюанс — точно не помню, н вроде связано с абревиатурами, она их не отличает от обычных слов. А у шарпистов стиль кодирования говорит, что абревиатуры надо писать заглавными буквами. И вот шарпист берёт генерённый код и ручками его правит (ну или рефакторит при помощи вижуалки). Только шарпист у нас остался один — т.е. нам всем пох на их соглашения, а кому было бы не пох, они уже уволились. А генерённый код во время разработки перегенерируется по нескольку раз на дню. И шарпист его постоянно правит.
Это всё, что я хотел сказать по поводу следования стилям кодирования.
M>>В креаторе всё работает искаропки, а в MSVC — нифига. Пришлось разбираться, что надо в инклюды проекта дописать, чтобы сгенерённое нашлось. I>Qt Visual Studio Tools ставишь, работаешь через него и нет у тебя таких проблем.
Я как бы с ними и работаю, и такие проблемы таки есть
Здравствуйте, Marty, Вы писали:
M>>>Претензия к тому, что я кидаю на layout какой-то элемент, он в дереве элементов в тул окне вниз добавляется, а на форме — почему-то самым первым становится. И никак не поменять. Приходится руками лезть в XML уишный. I>>Я куда кидаю виджет туда он и встает, кидаю в начало layout-а он в начало встает, кидаю в конец, он в конец встает, кидаю в середину он в середину встает, видео чтоли запиши этого процесса.
M>Хм. Я наверное не догадался. Есть VLayout, кинутый на него виджет сразу на него растягивается, куда остальные кидать, я не понимаю.
Туда куда нужно, в начало или конец VLayout, не через дерево, а прям на форме, там как раз margin/spacing есть чтобы не особо мучаясь можно было попасть виджетом в нужное место layout-а.
M>Пробовал кидать в дерево тул окне, так виджеты почему-то сверху добавляются. Надо будет проверить, кинуть таки на форму, может сработает. Хотя вроде пробовал, тоже какое-то г получилось, но не уверен, надо будет повторить эксперимент
Кидать через дерево объектов я не пробовал. А если на форму кидаешь то может только маленький margin/spacing мешать, увеличь его, раскидай на форме как нужно, а потом можно и нулевым сделать.
M>>>В креаторе всё работает искаропки, а в MSVC — нифига. Пришлось разбираться, что надо в инклюды проекта дописать, чтобы сгенерённое нашлось. I>>Qt Visual Studio Tools ставишь, работаешь через него и нет у тебя таких проблем. M>Я как бы с ними и работаю, и такие проблемы таки есть
Давно через него не работал, но там вроде были команды(визарды), добавить ui, или наследник qobject-a, и он всё что нужно в проект дописывает, чтобы uic и остальное подхватывалось, а сейчас вообще по идее можно на cmake перейти для студии и Qt. Там если что-то не находится можно удалить из проекта файл и заново его добавить, плагин всё подхватит сам, moc ручками не нужно в проект добавлять.
Здравствуйте, morgot, Вы писали:
M>А почему все так не любят С++ билдер ? Для гуи под винду самое оно. M>И можно винапи использовать и СОМ, если где-то не подходит VCL..
Здравствуйте, netch80, Вы писали:
N>машинноизменяемый для визуального редактора,
Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
Здравствуйте, Shtole, Вы писали:
S>Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
Я думаю это временно, подвержено закону цикличности.
Например — докрутят к редактору ИИ, он додумает как форма себя должна вести при изменении размеров, и вообще.
Достаточно будет дать ему набросок совы, детали он дорисует сам.
Здравствуйте, bnk, Вы писали:
S>>Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
bnk>Я думаю это временно, подвержено закону цикличности. bnk>Например — докрутят к редактору ИИ, он додумает как форма себя должна вести при изменении размеров, и вообще. bnk>Достаточно будет дать ему набросок совы, детали он дорисует сам.
И заодно пусть саму форму придумает. И обработчики. И бизнес-логику. И бизнес-идею. Чего уж мелочиться!
Наверно, на этом сайте не найти человека, который бы испытывал больший скепсис чем я в отношении И так называемого И.
Мечтать конечно не запретишь. В реальности же я недавно публиковал некий текстовой контент через некую CMS в сотрудничестве с редактором (человеком, который причёсывает контент вместе с автором перед публикацией). Получил пошаговую инструкцию, в которой первым же пунктом шло: «отключите WYSIWYG в CMS». Вот что думают профессиональные редакторы об этой идее. Наверное, не просто так человек это рассылает всем авторам, с которыми работает. CMS — самая бла-бла-бла в Европе (если вы понимаете, о чём я). А ведь речь там шла о публикации текстов — очень простое форматирование, очень большое комьюнити контентмейкеров, очень большое соотношение числа правок к числу просмотров (1:102..5), то есть об области, где WYSIWYG объективно наиболее полезен. Если сравнить с GUI, шансов у WYSIWYG нет вообще — форматирование намного сложнее (layout'ы, структура, поведения — вообще всё), программистов UI всяко меньше, чем авторов постов и статей, а за счёт того, что одну и ту же форму юзер открывает каждый день, число просмотров улетает в космос. Все и вылизывают вручную. Если же завтра, вопреки всем разумным соображениям, чудо всё-таки случится, боюсь вам не о том придётся думать, «на чём пишут GUI под Windows с применением C++».
Здравствуйте, Shtole, Вы писали:
N>>машинноизменяемый для визуального редактора,
S>Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
S>Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
Дельфи/Билдер с тобой не согласны. Борланд допустил ошибку, позволив переманить главного архитектора в Майкрософт. В итоге и Борланд подзагнулся, и Майкрософт родил какое-то говно
Здравствуйте, Shtole, Вы писали:
bnk>>Я думаю это временно, подвержено закону цикличности. bnk>>Например — докрутят к редактору ИИ, он додумает как форма себя должна вести при изменении размеров, и вообще. bnk>>Достаточно будет дать ему набросок совы, детали он дорисует сам.
S>И заодно пусть саму форму придумает. И обработчики. И бизнес-логику. И бизнес-идею. Чего уж мелочиться!
Хорошая идея
S>Мечтать конечно не запретишь. В реальности же я недавно публиковал некий текстовой контент через некую CMS в сотрудничестве с редактором (человеком, который причёсывает контент вместе с автором перед публикацией). Получил пошаговую инструкцию, в которой первым же пунктом шло: «отключите WYSIWYG в CMS». Вот что думают профессиональные редакторы об этой идее.
Визивуг хорош для нубов. Если это хороший визивуг. Я вот плюсовик с большим стажем, но интерфейс на кути даётся не очень. На Билдере было гораздо проще.
Если по поводу именно текстов — тут, как мне кажется, лучше отдельно — ввод, и отдельно — представление. В нижней части пишешь, например, на маркдауни, а сверху сразу видишь, во что оно превратится.
Здравствуйте, Marty, Вы писали:
N>>>машинноизменяемый для визуального редактора,
S>>Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
S>>Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
M>Дельфи/Билдер с тобой не согласны. Борланд допустил ошибку, позволив переманить главного архитектора в Майкрософт. В итоге и Борланд подзагнулся, и Майкрософт родил какое-то говно
«Вот какие басни Лафонтена приходится выслушивать!» (М.Булгаков).
Двадцать лет назад (боже, как летит время) я работал в команде, где единственный писал всё на WinAPI, а остальные на Delphi. Этот ужас я хорошо помню — десятка три стандартных компонентов, которые натягивают на юзер-кейсы как... вот именно, сову. На глобус. Намётанным глазом Delphi-происхождение этих шедевров распознавалось за три минуты. Нет, конечно были и приличные программы с приличным UI на этой самой Delphi, но они-то как раз писались не так — а с помощью кода и того же WinAPI (в конце концов, это был Тьюринг-полный язык).
Здравствуйте, Marty, Вы писали:
S>>Мечтать конечно не запретишь. В реальности же я недавно публиковал некий текстовой контент через некую CMS в сотрудничестве с редактором (человеком, который причёсывает контент вместе с автором перед публикацией). Получил пошаговую инструкцию, в которой первым же пунктом шло: «отключите WYSIWYG в CMS». Вот что думают профессиональные редакторы об этой идее.
M>Визивуг хорош для нубов. Если это хороший визивуг. Я вот плюсовик с большим стажем, но интерфейс на кути даётся не очень. На Билдере было гораздо проще.
Мы же не первый день живём на свете и отлично помним, что из инструментов для нубов никогда ничего хорошего не получается. Если вы профессионально (за деньги) делаете UI, придётся разбираться, чтобы не вылететь с рынка.
Другое дело — идея дать инструментарий не программистам (сисадминам, очень продвинутым пользователям, всяким смежникам типа data scientist и т.п.). Но это же не «нубы», это другая категория. Для них есть т.н. no-code платформы. Над одной такой я сам сейчас работаю — но даже у меня на данный момент классического WYSIWYG'а не предполагается (layout'ов нет от слова совсем), просто не нужно писать код благодаря штукам наподобие property inspector'а.
В промежутке между этими случаями ничего не выживает.
Каждый из нас в чём-то нуб, я, например — в изощрённых алгоритмах, но я же не рассчитываю, что какой-нибудь чудо-конструктор поможет мне сгенерировать подходящую сортировку (да даже обычный LINQ-запрос). Нет, приходится или делегировать другому, или брать яйца в кулак и разбираться («в геометрии нет царских дорог»).
M>Если по поводу именно текстов — тут, как мне кажется, лучше отдельно — ввод, и отдельно — представление. В нижней части пишешь, например, на маркдауни, а сверху сразу видишь, во что оно превратится.
Ну так это не WYSIWYG. Это просто markup language — вещь очень хорошая и правильная. Просто я не понимаю, зачем брать такие странные ML как маркдаун (он же не для этого сделан, а чтобы вы могли из конференций копипастить куски и было автоформатирование) или QML (на котором сами кутеры не пишут). Есть нормальный HTML, который понимает каждая собака, который покрывает на 146% все потребности UI (если брать хороший движок), по которому и комьюнити, и документация, и где весь прогресс идёт.
S>>>Мечтать конечно не запретишь. В реальности же я недавно публиковал некий текстовой контент через некую CMS в сотрудничестве с редактором (человеком, который причёсывает контент вместе с автором перед публикацией). Получил пошаговую инструкцию, в которой первым же пунктом шло: «отключите WYSIWYG в CMS». Вот что думают профессиональные редакторы об этой идее.
M>>Визивуг хорош для нубов. Если это хороший визивуг. Я вот плюсовик с большим стажем, но интерфейс на кути даётся не очень. На Билдере было гораздо проще.
S>Мы же не первый день живём на свете и отлично помним, что из инструментов для нубов никогда ничего хорошего не получается. Если вы профессионально (за деньги) делаете UI, придётся разбираться, чтобы не вылететь с рынка.
Ну, хз, профессионально или нет я делаю UI. Я роботов делаю, а для ПК делаю морду для управления.
Здравствуйте, Marty, Вы писали:
M>ЗЫ А в винде стандартных контролов гораздо меньше, чем три десятка. Если писать на винапи — то выпиливать что-то нестандартное гораздо дольше.
Как это ни парадоксально, НЕТ. Любой шаг в сторону сделать в WM_PAINT/ON_NOTIFY гораздо проще, чем долго и мучительно настраивать BCL-компонент через «стандартные» свойства, особенно, если в конце выясняется, что сделать именно так, как надо — нельзя. Ну, а дальше известно что. «Сегодня в колбасе потребности нет!» — то есть, гнём юзерские хотелки в прокрустово ложе типовой реализации.
И это, кстати, я наблюдал именно с кучкой пользователей (ну, не 2-3, а два-три десятка). Наша команда писала внутренний софт для смежного отдела. Который назубок выучил все Delphi-компоненты и отучился «хотеть невозможного», в итоге.
M>ЗЗЫ А дельфи приложухи детектились быстро потому, что все новички любили ОК\Cancel делать с зелёной галочкой и красным стоп-знаком. Если без них, то уже и не отличишь, если у разраба руки не из жопы
Ну да, конечно. Там был, например, такой мега-таблиц, очень узнаваемый. (Делфю же проектировали, в основном, для CRUD — со всеми метафорами типа курсоров БД, торчащими наружу). Вот им, помнится, затыкали такие дыры в UI, что вспомнить страшно.
M>ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком?
Я пошутил. Смысл в том, что если перевести windows.h на Паскаль, то и на Делфи можно написать ровно то же самое, что на любом другом языке.
Здравствуйте, Shtole, Вы писали:
M>>ЗЫ А в винде стандартных контролов гораздо меньше, чем три десятка. Если писать на винапи — то выпиливать что-то нестандартное гораздо дольше.
S>Как это ни парадоксально, НЕТ. Любой шаг в сторону сделать в WM_PAINT/ON_NOTIFY гораздо проще, чем долго и мучительно настраивать BCL-компонент через «стандартные» свойства, особенно, если в конце выясняется, что сделать именно так, как надо — нельзя. Ну, а дальше известно что. «Сегодня в колбасе потребности нет!» — то есть, гнём юзерские хотелки в прокрустово ложе типовой реализации.
Зачем что-то долго и мучительно настраивать, когда там был механизм owner draw искаропки? Ну и нарисовать своё — это малая часть того, что надо делать для нормального контрола. Я как-то писал свой нестандартный контрол на винапи, для отображения среднеквадратического отклонения. Всё через SendMessage. Удовольствие ниже среднего, больше так не делал.
Ну и прокрустово ложе типовой реализации — чем плохо-то? В винде все контролы тоже в этом прокрустовом ложе лежат. И на самом деле, это правильно — поведение во всех прогах стандартное. А любителей кастомизации вообще надо убивать маленькими, пока не стали программистами.
M>>ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком?
S>Я пошутил. Смысл в том, что если перевести windows.h на Паскаль, то и на Делфи можно написать ровно то же самое, что на любом другом языке.
Ну, вообще-то windows.h в дельфях и был переведён на псакаль. Как и куча других апи
Здравствуйте, Marty, Вы писали:
M>Зачем что-то долго и мучительно настраивать, когда там был механизм owner draw искаропки?
Как только программист начинал использовать owner draw, Delphi из волшебного чудо-инструмента «накидал контролов на форму и готово» мгновенно превращался в тыкву: всё то же самое, что если изначально использовать родной WinAPI, только между Windows и разработчиком оказывался ещё и Borland, в духе анекдотов про трёхспальную кровать «Ленин с нами». Конкретно, использование Delphi при этом обозначало дополнительный геморрой, связанный с тем, что ЯП разработки отличается от ЯП целевой платформы (забудьте про примеры в MSDN, сэмплы и библиотеки и т.п.) Но не надо думать, что использование плюсов давало иммунитет. У Builder'а, например, были свои тараканы типа __fastcall на каждый обработчик событий (я когда в первый раз увидел, как он генерирует обработчики, тихо прифигел).
Позвольте на этом замечательном примере и поставить точку в этой затянувшейся дискуссии. Те, кто изначально клюнул на сказки про WYSIWYG именно так и заканчивали — лицом к лицу с необходимостью заплатить изначальную цену в виде изучения WinAPI и набежавшие проценты в виде ненужной прослойки, дополнительного объёма кода, проблем с поддержкой и по всем кочкам.
M>Ну и прокрустово ложе типовой реализации — чем плохо-то? В винде все контролы тоже в этом прокрустовом ложе лежат. И на самом деле, это правильно — поведение во всех прогах стандартное. А любителей кастомизации вообще надо убивать маленькими, пока не стали программистами.
Вот вам маленький, но очень конкретный пример. Пользователь скажет вам, что не хочет, чтобы при изменении границ колонок в таблице мышиный курсор менялся на нестандартное нечто, нарисованное в Borland'е. У него, у пользователя, свой курсор для этого в винде настроен, с динозавриком. Что вы ему скажете? Я это всё проходил, «Not an issue/By design», фиксить не будем, гуляй юзер, жуй опилки. Потом, кажется, это починили (давно дело было, я могу путать детали). Ну, как починили — сделали системный курсор. Допустим, юзер хочет (а чего бы ему не хотеть конкретной кастомизации, если их, как вы пишете, 2-3 человека и ради них вся разработка?) наоборот — кастомный курсор. И вот тут уже вы НИ-ЧЕ-ГО не сможете сделать с готовым компонентом. Не в том дело, что под WinAPI тоже пришлось бы напрягаться и ловить... чёрт, название события забыл... WM_SETCURSOR, кажется?... а в том, что в инкапсулированном компоненте это сделать без исходников тупо нельзя.
M>>>ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком? S>>Я пошутил. Смысл в том, что если перевести windows.h на Паскаль, то и на Делфи можно написать ровно то же самое, что на любом другом языке. M>Ну, вообще-то windows.h в дельфях и был переведён на псакаль. Как и куча других апи
Вы, кажется, забыли, что мы говорим о визуальных редакторах.
Здравствуйте, Shtole, Вы писали:
N>>машинноизменяемый для визуального редактора,
S>Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
Не сказки. В большинстве практически значимых случаев таки работает.
Вот надо разделить окно программы по вертикали впополам, а нижнюю часть горизонтально в соотношении 30/70. И да, заказчика устраивает полученное, он всё равно ничего лучше не придумает.
И таких примеров, навскидку, 90%.
А для оставшихся вполне нормально идёт, если в этом языке можно писать "а вот тут у нас будет кастомный контрол системы MyPervertedReflexiveTreeListView, в редакторе рисуй на его месте синий прямоугольник, а вот набор кастомных параметров", а остальное отрабатывается где-то внутри.
S>Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
Так те самые 90% и есть "привет, мир!" в GUI варианте.
Здравствуйте, Shtole, Вы писали:
S>Вот вам маленький, но очень конкретный пример. Пользователь скажет вам, что не хочет, чтобы при изменении границ колонок в таблице мышиный курсор менялся на нестандартное нечто, нарисованное в Borland'е. У него, у пользователя, свой курсор для этого в винде настроен, с динозавриком. Что вы ему скажете? Я это всё проходил, «Not an issue/By design», фиксить не будем, гуляй юзер, жуй опилки. Потом, кажется, это починили (давно дело было, я могу путать детали). Ну, как починили — сделали системный курсор. Допустим, юзер хочет (а чего бы ему не хотеть конкретной кастомизации, если их, как вы пишете, 2-3 человека и ради них вся разработка?) наоборот — кастомный курсор. И вот тут уже вы НИ-ЧЕ-ГО не сможете сделать с готовым компонентом. Не в том дело, что под WinAPI тоже пришлось бы напрягаться и ловить... чёрт, название события забыл... WM_SETCURSOR, кажется?... а в том, что в инкапсулированном компоненте это сделать без исходников тупо нельзя.
Вот за это Borland и пострадал (в значительной мере) — что он менял из стандартного системного хозяйства по максимуму всё под себя (как те же зелёно-красные ✅ ok ❌ Cancel).
И что его объектная модель при этом, наоборот, мало допускала кастомизации, где нужна.
MFC тут был гибче.
Зато сейчас кроссплатформенный Qt, который переопределяет и рисует сам чуть менее чем всё, вполне себе живёт.
N>Я одно время много на Делфи писал, а потом на Билдере. И меня раздражал этот визуальный стиль программирования, где надо заходить в кучу окошек и выставлять кучу пропертей. И очень на этом фоне зашли QWidget'ы, где всё описывается кодом, и всё в одном месте, и всё можно посмотреть глазами. Прямо таки бальзам на сердце.
Ну, нет.
Во-первых, как сказали уже в делфях можно было всё кодом прописывать — было бы желание. А можно было рисовать. Можно было даже писать расширения свои со своей логикой и мастерами.
Во-вторых, когда я увидел QT (лет 7 назад), это было как назад в 90-е, тонны настроек пишешь ручками (или некоторые таскали из проекта в проект и правили сотни строк этих), какие-то левые глюки с выравниванием, положением и т.п.
Единственно, что понравилось — возможность расширения существующих элементов (хочешь таблицу в списке — пожалуйста, хочень список в таблице — тоже левой пяткой).
Здравствуйте, Marty, Вы писали:
M>ЗЫ Еще сборка в Qt Creator'е параллельная через какой-то jom идёт. И эта сцука не умеет в русские пути
Креатор умеет в qmake(jom при этом опционален), CMake и QBS.
Кирилицу в общем случае лучше вообще не использовать в путях, т.к. процесс сборки может включать вызов очень разных и древних тулзов.
Здравствуйте, Skorodum, Вы писали:
M>>ЗЫ Еще сборка в Qt Creator'е параллельная через какой-то jom идёт. И эта сцука не умеет в русские пути S>Креатор умеет в qmake(jom при этом опционален), CMake и QBS.
Спасибо, я в курсе
S>Кирилицу в общем случае лучше вообще не использовать в путях, т.к. процесс сборки может включать вызов очень разных и древних тулзов.
Да, но когда в конторе решался вопрос, какие будут логины — админы сказали — будут русские, и "у нас всё работает"
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, morgot, Вы писали:
M>>А почему все так не любят С++ билдер ? Для гуи под винду самое оно. M>>И можно винапи использовать и СОМ, если где-то не подходит VCL..
bnk>Turbo Vision навсегда?
Есть современные версии же, проект развивается. Em.. Rad Studio или как то так
ну без шуток, чем он плох?
Здравствуйте, netch80, Вы писали:
N>>>машинноизменяемый для визуального редактора, S>>Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
N>Не сказки. В большинстве практически значимых случаев таки работает. N>Вот надо разделить окно программы по вертикали впополам, а нижнюю часть горизонтально в соотношении 30/70. И да, заказчика устраивает полученное, он всё равно ничего лучше не придумает. N>И таких примеров, навскидку, 90%.
А дальше? Заказчику отдаётся два пустых полуэкрана в пропорции 30/70? Ваша мысль остановилась на самом интересном моменте.
Я ещё могу согласиться, что кому-то проще в Object Inspector'е набить «30», чем написать руками «30%» в ML/CSS, но с каждым следующим шагом и с каждым следующим компонентом описание разметки текстом будет выигрывать у WYSIWYG'а всё сильнее.
Про императивный layout, понятно, речи нет — это что-то из эпохи до исторического материализма.
