Comments 84
Опять либа чуть менее чем полностью состоящая из макросни. Автору статьи респект, что не стал скрывать проблемы!
Почему это проблема?
Yвеличение времени компиляции и IDE с макросами не очень хорошо работают. Хотя в данном случае мне кажется, что от этого никуда не деться.
Ну, тут действительно стоит выбор или писать больше кода, но без макросов, либо писать меньше кода, но дольше компилировать. За поддержку со стороны IDE ничего не могу сказать, ибо для раста пользуюсь по большому счёту только подсветкой и подстановкой из скоупа файлов. Для остального у меня есть манулы мануалы.
Я правильно понимаю, что весь интерфейс прописывается ручками в виде
export component Calculator {
property <[[string]]> buttons: [
["1", "2", "3", "+"],
["4", "5", "6", "-"],
["7", "8", "9", "*"],
["C", "0", "=", "/"]
];
VerticalBox {
for row in root.buttons: HorizontalBox {
for button in row: Button {
text: button;
}
}
}
}?
Извините, на дворе какой год? Интерактивное рисование форм появилось еще в 90-х годах прошлого столетия. В простейшем виде - MSVC 1.52 под Win 3.11 все это уже было. Дальше - Delphi и C++ Builder - там вообще все было мощно.
А вот такое вот я в последний раз помню для какой-то библиотеки, реализующей текстовый интерфейс с менюшками и прочим под DOS... Это где-то конец 80-х годов прошлого века.
И уж если мы говорим про винду, то там для всего этого есть специальные .rc файлы, где хранится описание всего интерфейса и на работу с которыми заточен WinAPI.
Ну, или, коль хочется мультиплатформенности, то есть же wxWidgets тот же. Где есть wxCrafter, wxFormBuilder где рисуешь форму, а оно само генерит весь этот код.
Писать руками мало-мальски сложные интерфейсы таким вот образом - 80% времени на это уйдет. Еще и, подишто, на бумажке придется все это рисовать, если у вас на форме пара десятков контролов (менюшки, списки, выпадающие списки, движки, счетчики, текстовые формы с валидацией ввода, футбары с иконками, статусбыры в какими-то контролами и т.п.)
Как-то несерьезно все это...
Быстрый гуглинг дал пару ссылок:
https://crates.io/crates/wx-rs
https://rust.libhunt.com/wxrust-alternatives
Не смотрели в эту строну?
Расскажите это всему frontend сообществу, где есть куча фреймворков которые описывают интерфейсы через html/xml, css и js.
wxWidgets - ужасен, мне довелось с ним поработать из под python. Он тормознутый, не может даже 2 десятка мелких картинок отобразить, так еще и кривой до кучи. Да банально - он морально устарел. Сколько было хаков в проекте для того что бы сделать тривиальные вещи. Так к тому же все было описано кодом. Билдер форм пытались использовать для интерфейсов определенных пользователем, но он просто глючил и вылетал.
WinApi - только под винду, сейчас правят браузеры и смартфоны.
Насколько я слышал даже разработчики на Qt предпочитают QML.
Несерьезно это застрять в каком-то своем мире и не видеть развития вокруг. Мир давно уже ушел вперед, а вы все так же смотрите на свою зеленую траву. Попробуйте научиться чему-то новому, оно придумано не от хорошей жизни.
Я в свое время написал немало интерфейсов в самых разных средах.
И сейчас иногда приходится делать (правда, это вообще что-то с чем-то - AS/400, текстовые экранные и принтерные формы, описываемые на DDS - data defenition specifications, но там тоже есть редактор визуальный).
И в целом представлю себе неплохо затраты времени на ручное написание кода формы и возможность ее визуального проектирования когда ты сразу видишь как она будет выглядеть "в натуре". Что там будет генериться на выходе - код, QML, DDS - абсолютно не важно. Важно что вы сразу видите результат. И можете двигать, добавлять, удалять контролы, редактировать их свойства здесь же. По времени и усилиям несопоставимо. В визуальном редакторе все это в разы быстрее делается. Потом только логику прописываешь в готовый уже код.
Достаточно прост о сделать что-то более-менее объемное - хотя бы десяток форм с 5-15 контролов на каждой чтобы понять что рисовать их в специальном редакторе, где сразу видишь как оно будет выглядеть, намного эффективнее. Особенно, когда надо добавить новый контрол туда, где уже есть еще 15 и их надо подвигать туда-сюда...
Ваш калькулятор в делфи или билдере делается за 15-20 минут левой ногой. И руками там потребуется написать десяток-другой строк кода, не больше.
сейчас правят браузеры и смартфоны
То, что в статье описано - оно под браузер или под смартфон? Или таки под десктоп?
В винде все сделано достаточно разумно, кстати. Есть rc файл с описанием формы и есть движок, который эту форму отрисовывает по данным из rc. А в коде вы только получаете сообщения о том, что там делает пользователь и обрабатываете их.
Сделайте для RUST что-то подобное - будет удобно и красиво. Описание форм может быть любым - QML, DDS - что угодно. Важно что для описания интерфейсам вам не придется набивать десятки станиц кода и при этом держать в голове всю разметку.
Несерьезно это застрять в каком-то своем мире и не видеть развития вокруг. Мир давно уже ушел вперед
"Вперед" - это куда? К тому, как это делалось под DOS в 80-х годах? Я все это еще застал. И даже тогда уже были попытки к описанию интерфейсов не в коде, а специальными скриптами. А код уже или генрирился по ним, или использовал их как данные для отрисовки.
А для любителей задолбаться могу предложить писать документы не в ворде, а в ноутпаде в формате postscript.
Просто как пример (далеко не самое сложное что приходилось делать, просто это близко лежало)
Сколько времени уйдет на описание кодом таких вот форм?
А чего-то вот такого:
Со всеми двигающимися сплиттерами, выравниванием и т.п.
Вот просто чтобы все это на экран вывести. Даже без логики заполнения данными, обработки действия пользователя (отметка элемента в таблице, перетаскивания мышкой карты, изменения размеров элементов сплиттерами и т.п.)
Вот вторую половину второй формы гораздо проще описать кодом чем натыкивать вручную. А потом ещё и использование этих данных в коде заодно упростится.
Да и с первую я бы попытался кодом сделать.
И да, в нижнем окне вы лукавите, потому что там видны стандартные компоненте, который явно вручную не рисовались (собственно, если точный дизайн не важен, именно их я бы и на вторую форму засунул). Да и двигающиеся сплиттеры с выравниванием - это именно то, что в коде делать проще.
Вот третья форма - да, явная демонстрация достоинств визуального создания интерфейсов.
При "натыкивании вручную" можно точно также копипастить, как в коде - нормальный редактор позволяет дублировать однотипные элементы, использовать выравнивание относительно самой формы, других элементов.
Т.е. выделил группу элементов - "это привязываем к верхнему краю", для другой группы - "это в левому краю" и т.п.
Все свойства контролов тоже там же описываются, включая сообщения, которые нужно посылать в форму при тех или иных действиях. В Дельфи/Билдере просто "добавить форму", потом рисуешь ее и на выходе имеешь код-болванку где уже все обработчики сообщений обозначены, остается только свою логику прописать.
Просто количество нажатий на клавиши сокращается в разы. И размер кода (за счет того, что все это рендерится на кодом, а самой виндой) сильно меньше (а значит и работать с ним проще).
Тут сам принцип работы - есть описание интерфейса, есть рендер (на уровне системы или конечного устройства). В коде вы только обрабатываете события от рендера.
Все это проявляется особенно когда у вас достаточно плотная форма, а вам говорят "нужно еще два поля для ввода добавить". И начинается - "это поле чуть сократим, это сдвинем вниз и влево, это вверх и вправо, вот местечко разгребли и сюда воткнем новое поле...". Делать это мышкой на экране намного проще и удобнее, чем в тексте, пытаясь представить а как оно все в итоге будет выглядеть - не наедут ли поля друг на друга..."
А если у вас еще все это разбито на группы разделенные сплиттерами и в группах выравнивание относительно друг друга, то имеется режим предпросмотра, то сразу можете смотреть не разъезжается ли что-то (или не наезжает друг на друга) если сплиттеры начинаете двигать. И для этого не надо ничего компилировать и запускать.
А если все это еще потом хранится в виде QML или DDS, то можно руками сделать тонкую доводку в тексте. Но 80-90% рутинной работы вы быстро сделаете визуально.
При "натыкивании вручную" можно точно также копипастить, как в коде
В визуальном редакторе копипастить сложнее, как бы это странно не звучало. После каждого копипаста надо переключаться в окно свойств элемента и там менять значения, выискивая их в огромном списке.
В коде же настройки, имеющие значения по умолчанию, как правило места не занимают. Кроме того, в коде зачастую и копипастить не нужно, ибо есть циклы и подпрограммы.
В Дельфи/Билдере просто "добавить форму", потом рисуешь ее и на выходе имеешь код-болванку где уже все обработчики сообщений обозначены, остается только свою логику прописать.
Не все, а те которые вы сами попросили добавить. Та же Delphi даже автоматически убирала пустые обработчики. Потому что всевозможных обработчиков попросту слишком много.
Все это проявляется особенно когда у вас достаточно плотная форма, а вам говорят "нужно еще два поля для ввода добавить". И начинается - "это поле чуть сократим, это сдвинем вниз и влево, это вверх и вправо, вот местечко разгребли и сюда воткнем новое поле..."
На плотной форме - да, а вот на обычной это работает в другую сторону. Там, где в декларативной разметке можно просто добавить строчку и остальные сдвинутся вниз - в классическом визуальном редакторе надо все элементы сдвигать вниз вручную. И пытаться не добавить случайно им обработчик в процессе сдвигания.
PS а помните ли вы слишком большие формы, которые приходилось редактировать с прокруткой?
Вы просто пропустили лет 15 эволюции гуев и абсолютно не знакомы ни с современными фреймворками (на которых реально проще накидать текстом со всеми современными ide), ни с современными требованиями к этим самым гуям. Говорю как человек много и с удовольствием красящий кнопки в очень разных стеках с 2002 года. Стало лучше, стало веселей. Текст даже не пишется, а собирается как конструктор. Интерфейс же теперь - не статичные формы с обработчиками, а динамичная структура, которую проще и нагляднее описывать в немногословных декларативных фреймворках. Уж поверьте на слово тому кто встретил столкновение винформз и первых промышленных планшетов на винде, что вызвало необходимости изобретать dip чтобы пользователь попадал в кнопку своим мозолистым толстым пальцем. И одновременно свело на нет всю полезность визуального редактора.
Мир интерфейсов куда интереснее и многообразнее задачи накидать кучу элементов на статичную форму. И фреймворки эволюционируют в код-фест не потому что чьей-то левой пятке так захотелось, а потому что эффективность подхода была проверена.
И вы тоже заблуждаетесь по части визуальных редакторов. Скорее всего по тому что используете в основном фреймворки без них.
Интерфейс же теперь - не статичные формы с обработчиками, а динамичная структура
Само собой, что не статичная и визуальный редактор не является ограничителем или причиной статического интерфейса.
Любой интерфейс не состоит из случайных контролов, он состоит из смысловых блоков: блок элементов списка, блок с меню, блок с набором полей, блок с рендером. Форма состоит из этих блоков, которые можно описать отдельно.
Я могу в дизайнере отдельно построить интерфейс конкретного блока и использовать его в разных формах. В WinForms это либо не используется, либо вообще не доступно (я уже не помню). Речь идет о фреймах и схожего на них функционала.
Пришло ТЗ на программу с ссылкой на фигму. Фигма тоже раскидывает всё на блоки. Вижу конкретный вид элемента списка, создаю стиль такого элемента (визуально). Теперь в любой список я могу добавить элемент с таким стилем. Стиль кнопки - сделано, стиль элемента меню - сделано, стиль самого меню - сделано. Для всего этого мне не нужно написать ни строчки кода.
Мир интерфейсов куда интереснее и многообразнее, чем вам кажется.
Hidden text
Приведенный вами пример на любом современном фреймворке пишется буквально в несколько строк кода. А еще позволяет без напильника подставлять любое количество вариаций одного и того же элемента в зависимости от условий - хошь по параметрам отображения, хошь состояния. И разносить их по разным экранам если они вдруг маленькие телефонные. И при переходе между экранами красиво превращать один элемент в другой. Стилизация с той же фигмы переносится практически в лоб (и это мы веб не берем где она вообще генерится какая нужна при правильном дизайнере и переносится 1 в 1).
Ну то есть, блин, дельфи как иллюстрация моих слов про разнообразие? Серьезно? Я там уже писал что уход от визуалщины не левой пяткой разработчиков мотивирован. Как у дельфей с версткой в макетных единицах, например?
Я ещё раз убеждаюсь, в том что вы мало что знаете о современно Делфи.
Стиль из скринов сверху может быть применен к любому элементу управления и изменен в любое время. А поведение элементов зависит от внешнего контейнера (хошь разноси, хошь не разноси).
Уход от визуальщины мотивирован отсутствием нормальных инструментов, а существование Фигмы тому прекрасное подтверждение.
У Делфи с единицами размеров и позиционирования всё прекрасно. Прекрасно всё скейлится автоматически и рисуется замечательно на разных экранах. Об этом я даже не забочусь при создании GUI.
Прежде чем минусить, изучите вопрос. Ознакомьтесь с тем, что и как работает и какие доступны возможности.
Hidden text
Это не я. Вообще не имею привычки минусы ставить.
Макетные единицы я не просто так взял. Это священный грааль всех дизайнеров за который они бьются с разрабами, так же известный как пиксель перфект. И от которого разрабы всеми силами отбиваются. На текущий момент я не видел их внятной имплементации ни в одном фв вообще кроме флаттер/композ/свифтюи - то есть декларативных. Вот пример: https://pub.dev/packages/flutter_screenutil
Я не говорю что ваш современный дельфи плох и да я действительно его не знаю. Мой спич о том что при переходе в код с визуала мы в эффективности не теряем, а приобретаем, потому как получаем естественным образом доступ к тому что в любых визуальных разделено на этапы - и верстку и биндинг и стейт-менеджмент и прочее любое. И это я говорю на основе собственного опыта перехода с нативных вьюшек дроида на композ например (хотя есчестно нативные вьюшки тоже проще было руками в xml верстать и весь редактор там был нужен только как превью, несмотря на то что в нем и была вся полнота возможностей для верстки).
Когда мы смотрим на код мы ясно и однозначно видим что происходит, а WYSWYG, грубо говоря, это не совсем правда. При достаточно вычурных требованиях у нас нет соответствия того что мы видим тому что получаем. Если вы не сталкивались с этим достаточно часто, то это всего лишь недостаток опыта. Оно как раз чаще всего именно так.
Единственное отличие визуального создания и декларативного - это то, что я вижу сразу как оно будет и должно выглядеть. В остальном никаких ограничений нет. Визуальный редактор лишь позволяет и помогает строить код интерфейса. Результат его работы в любом случае - код. В случае Делфи не конечный код, а свой формат, но это по сути ничего не меняет. Я также могу переключиться на код и добавить части интерфейса через него. А могу использовать визуальный редактор и то же самое сделать, но сразу с возможностью увидеть.
Весь спор сейчас состоит в том, что я знаю возможности визуального редактора в Делфи, а вы, к сожалению, нет. И я пока не встречал того, чего бы я не мог сделать через него. На моём счету много проектов и часть из них шла с проектом в Фигме. Реализовал я абсолютно всё, что требовалось, включая анимации, эффекты, переходы и т.д. Визуальный редактор в Делфи далеко ушел от WinForms, особенно в кроссплатформенном фреймворке, о котором я говорю.
Весь спор сейчас состоит в том что вы почему-то считаете что я спорю про дельфи. Я дал вам одну-единственную штуку которой в вашем дельфи нет и быть не может, в остальном я его никак не третирую, а говорю про разный подход и почему концепция декларативок не менее, а чаще более хороша, а фв не предлагающие редактора могут быть лучше во многих моментах. А вы мне дельфи то, дельфи се. Вы вообще с ним зачем-то решили подколоть меня насчет моей фразы о разнообразии мира юай. Хотя писал я и про веб (с его там всякими реактами и вью жс) и про свинг (на котором до сих пор почти все продукты JB) и про джава эфикс (с его полумертвым, но неплохим торнадо) и про нативную дроид-верстку (с живым редактором в котором тоже при желании все можно), и про кутэ (господи никогда больше) и про винформс (в разрезе его давнего столкновения с новой реальностью) и про композ/флаттер/свифтюи как однояйцевых близнецов ставших мейнстримом не за красивые редакторы. Ну как-то так. И тут вы "а я вот могу все это на дельфи, смотрите ". Я могу все это же на всем вышеперечисленном. Причем шустрее и приятнее всего на последних трех. Вот про это "шустрее и приятнее" речь и шла.
Так о том и речь, "я могу, смотрите" - демонстрация того, что вы не знаете на что способы визуальные редакторы. И о какой "штуке", которой нет в Делфи, идет речь?
Вы ограничены в визуальных редакторах своим опытом.
Интересная концепция "если вы можете что-то на дельфи, то значит я этого не знаю про визуальные редакторы". Это в какой логике? Я вам абсолютно точно не писал того что вы не можете собрать насчастный экранчик на дважды два линейных лейаута с двумя списочными элементами и горстью контролов попроще.
И да, мы все ограничены своим опытом. Но бога ради прекратите ограничивать себя своими фантазиями в дискуссии с живыми людьми. Нужно ж как-то услышать что ли.
Перевирание слов - это "интересная концепция". Я сказал, что визуальный редактор визуальному редактору - рознь. И сказал, что не согласен с вашей точкой зрения, потому что работаю с таким визуальным редактором, который меня ничем не ограничивает. Вы с ним не работали, но уверены, что он не справляется с тем, с чем вы справляетесь декларативным подходом. Всё так? Или я что-то упустил? Пример который я показал - лишь небольшой пример и небольшого проекта, который я могу показать. А за "двумя лейаутами" скрывается масса функционала и адаптивности, которую вы не видите.
Подходов в визуальном редакторе может быть много и не стоит голословно заявлять, что ни один такой редактор не позволяет то, что позволяет декларативный подход.
То, что ты пишешь декларативно я в точности повторяю визуально. Речь не о конечном результате, а о процессе разработки. Ты пишешь начало блока слоя, я просто его туда помещаю, ты пишешь код настроек свойств, я их указываю визуально (и да, мне не нужно лезть в документацию, чтобы их узнать).
Редактор Делфи далеко ушел от "открыл форму, кинул кнопку и поле". Да это просто и быстро, но это не гибко и приводит к статичным интерфейсам, как ты сам и говорил. В Делфи же подход шаблонов-стилей, фреймов-заготовок. Да, ты можешь так же открыть форму и кинуть кнопку, только помимо этого ты можешь придать любой вид любому контролу в любой момент времени. Любой контрол может быть помещен в любой контрол, что позволяет делать шаблон. Шаблон-стиль - это набор других контролов, которые тоже могут иметь свой стиль. Шаблон-стиль является представлением контрола (каким бы он ни был). Разные слои предоставляют разное поведение дочерних контролов. Компоненты анимации, которые могут быть добавлены в шаблон обеспечивают интерактивность.
Ты пытаешься мне доказать, что декларативный подход лучше, не аргументируя это абсолютно ничем, чего не позволяет редактор в котором я работаю. Проблема в том, что ты убежден, что что-то точно можно сделать только через декларативны подход, я же, не понимаю о чем именно ты говоришь, потому что я не сталкиваюсь в редакторе с этим. И не надо говорить, что "ты не сталкиваешься, потому что что-то не делал". Я делал много и разные интерфейсы, повторяю, опыта работы в этом редакторе у меня много. И пока ты не начнешь предметно говорить, этот диалог ни к чему не приведет.
Если знаешь, что сделать через декларативный подход можно, а через визуальный редактор - нет, говори. А я скажу как это делается в том редакторе или соглашусь, что этого сделать нельзя.
Я сказал, что визуальный редактор визуальному редактору - рознь. И сказал, что не согласен с вашей точкой зрения, потому что работаю с таким визуальным редактором, который меня ничем не ограничивает. Вы с ним не работали, но уверены, что он не справляется с тем, с чем вы справляетесь декларативным подходом. Всё так?
Я дальше не читал, извините. Вообще не так. И последние реплики три я пытаюсь об этом вам сообщить. Вы ведете дискуссию не со мной, так что дальше и сами справитесь.
Бро, а можно можешь какую-нить наностатью по этому поводу запилить: как теперь носят?
Типа мы шли-шли-шли и пришли! Реальные пацаны носят так: ..... и мыслью по древу!
То есть вся претезия к фремворку - отсутствие WYSWYG редактирования. Это как минимум странно. Ну и во вторых все вот эти ваши тык тык формы что в делфи, что в студии работали только под винду. Если появился Линукс - извольте обмазываться QT/Gtk, которые занимаются ахтунгом похлеще чем у автора. А уж если приложение внезапно захотели в веб или мобилки, то здраствуйте я ваша тётя - тут даже наличие Qt Creator + QML не спасёт вас от допиливания напильником. Это не говоря уже про адок, который спрятан за теми библиотеками компонентов, который во многих случая проще взять и переписать. Только компонент в библиотеке не появится, чтобы его wyswygать.
Без логики заполнения и работы такие формы нелюбимые вами фронтендеры сделают кодом менее чем за час. И работать это будет не только в Windows.
Многие из нас делали такие интерфейсы... на курсовых в университете.
С тех пор появилась целое направление, называемое UX/UI-дизайн. И если вам хочется возразить, что это бесполезные люди и их работа никому не нужна, то просто в очередной раз продемонстрируете свой весьма ограниченный взгляд на мир.
"Вперед" - это куда?
Мусорная куча растет все выше, и старые слои скрываются под новыми завалами.
Это же формошлепство!
похоже наигралась индустрия с интерактивным дизайном. Даже Андроид переходит на декларативный подход с их Compose.
На самом деле ничего хорошего в этом нет. И не "наигрались", а нет нормального мультиплатформенного рендера интерфейсов по их описанию (в том же QML), который работа бы везде. Вот и откатились на уровень DOS 80-х годов где все это ровно также делалось.
В результате приходится держать отдельных "фронтенд разработчиков", которые заняты тем, что любой десктопный разработчик под той же виндой делает вообще мимоходом, тратя в разы меньше времени.
Кстати, когда еще был жив Blackberry, там интерфейсы именно так и делались - на QML с визуальным редактором. Но там в основе разработки был Qt.
Все-таки не совсем так. Тот же адаптивный интерфейс накидыванием контролов на форму так просто не сделаешь. Более-менее сложный дизайн, выходящий за рамки стандартной библиотеки элементов управления - тоже боль. Отсутствие встроенных шаблонов и стандартных архитектурных шаблонов вроде MVC приводило к заметному падению качества кода сложных программ, которые не исчерпываются одним окном. Это я уже не про DOS даже а про классический Windows и тот же Windows Forms.
Хотел бы я посмотреть, как десктопный разработчик мимоходом сделает интерфейс какой нибудь сложной CRM, да еще так, чтобы оно открывалось на любой устройстве - от телефонов, до ПК и телевизоров.
Особенно когда форма только с винды и запускалась.
Да без проблем, если честно. Особенно, если все формы не одинаково-шаблонные, которые web-фреймворки как бы автоматически строят
если все формы не одинаково-шаблонные, которые web-фреймворки как бы автоматически строят
Человек рассуждает о формах в контексте интерфейсов. Ммм. Это такая эпичная иллюстрация эффекта Даннинга-Крюгера, что я даже затрудняюсь придумать наводящий вопрос.
Ну вы походите по Интернету, чтоли, поизучайте разные сайты. GitHub, Gmail, VK, где у вас есть учётка, Хабр, опять же. Поизменяйте форму окна, посмотрите как они себя ведут. Откройте на телефоне. Подумайте, как вы это будете воспроизводить в своих любимых Делфях (да, я почитал другие комменты).
Да видел, я, боже мой. Вы везде это таскаете.
Вы почему-то считаете, что если смогли воспроизвести базовую двухколоночную вёрстку, то теперь всё возможно.
Ну так это самый тривиальный layout, который ваши Делфи переняли из-за распространения в Интернете среди этих наших веб-фреймворков. А если нужно что-то интереснее?
Тогда в чем смысл вашего комментария? Вот пример с адаптивным интерфейсом. Делается это точно так же как делают адаптивные сайты. Только визуально.
Делфи перенял у веба) Смешно. Во-первых, здесь нет "двухколоночной верстки". Не надо предположений. То, что вы знаете натягивать на всё остальное - плохая идея. Принцип тут совершенно другой и не имеет значения, какой будет сложности интерфейс. Во-вторых, если визуальный редактор имеет все те же элементы, чем манипулируешь в декларативном подходе, то в чём сложность создавать такие же интерфейсы, но только визуально?
В этом примере сверху не накидано всё сразу на форму, интерфейс строится блоками, которые реализованы отдельно и могут работать независимо. Меню - один блок, область чата - другой, страницы настроек - другие блоки. Внимательнее бы смотрели "мои другие комментарии", то увидели бы, что каждый элемент этого приложения отображается отдельно в разных дизайнерах. А управлять блоками ими можно как угодно, помещай в слои разных назначений и с разными параметрами, удаляй, скрывай, создавай.
Создание GUI тут очень похоже на реализацию UI веб-сайтов. Есть макет, есть стили. Здесь точно так же. Помимо того, что он делится на блоки, каждый контрол может иметь свой собственный стиль (class в терминологии html/css). Создавать его можно тоже визуально. И каким бы сложным не был интерфейс, в любой момент можно изменить представление любого элемента и соответственно его поведение.
Делфи перенял у веба) Смешно.
Создание GUI тут очень похоже на реализацию UI веб-сайтов.
У вас хобби такое - спорить с самим собой? Или это для меня шарада - найти взаимоисключающие параграфы?
То, что вы знаете натягивать на всё остальное - плохая идея.
Хотел вам написать буквально это. Вы варитесь в своей экосистеме - это хорошо и замечательно, что вы глубоко изучили свой инструментарий. Но вы, подобно комментатору выше, почему-то считаете, что все удобства и достижения существуют только в вашей области и напрочь игнорируете развитие индустрии в целом.
Делфи перенял у веба) Смешно.
Создание GUI тут очень похоже на реализацию UI веб-сайтов.
А представление контрола это придуманная вебом вещь? Я провел вам аналогию, чтоб было понятно. Ближе аналогия - скины и это близко не про веб. Принципы, использование в Делфи (речь о новом фреймворке, а не о старом со времен нулевых) не такие, как в вебе. Я лишь сказал, что создание GUI похоже на веб (и привел близкие аналогии), а не реализация. Вы хоть читайте текст.
считаете, что все удобства и достижения существуют только в вашей области и напрочь игнорируете развитие индустрии в целом
Ну да, ведь я не занимался разработкой GUI в декларативном варианте, я просто так спорю, без предметно.
На самом деле ничего хорошего в этом нет.
Какой вы загадочный человек - не перестаю удивляться. То у вас ООП не нужно, потому что появляется много лишних абстракций в коде, то слепо доверяете всякому WYSWYG пилить за вас вёрстку. Вы там как-то разберитесь уже.
Ну вот есть для xml андроидного wyswig редактор. Но один черт написать разметку руками проще и быстрее чем ковыряться в визуальном редакторе с привязками, что во что вложено, свойствами и прочим. А уж не создавать а поддерживать - еще более просто руками.
А compose тот же еще удобнее писать. Там визуального редактора конечно нет, но превью генерит.
Все эти привязки и прочее напоминает мне 1с/делфи, причем даже не современный 1с, с управляемыми формами, а старый, с формами обычными. Как же от него плевался.
Вы слишком многого требуете от авторов библиотеки. Создать библиотеку и создать IDE - немного разные по сложности задачи.
И уж если мы говорим про винду, то там для всего этого есть специальные .rc файлы, где хранится описание всего интерфейса и на работу с которыми заточен WinAPI.
Эти .rc файлы даже не всеми виндовыми приложениями используются: у Delphi VCL свой механизм, у WinForms свой, у WPF свой - и это только то с чем я работал лично. И ладно бы это был хотя бы удобный инструмент, так ведь нет - это был ужасный инструмент, единственным достоинством которого является его "изкоробочность".
Писать руками мало-мальски сложные интерфейсы таким вот образом - 80% времени на это уйдет. Еще и, подишто, на бумажке придется все это рисовать, если у вас на форме пара десятков контролов (менюшки, списки, выпадающие списки, движки, счетчики, текстовые формы с валидацией ввода, футбары с иконками, статусбыры в какими-то контролами и т.п.)
Иногда лучше и правда рисовать на бумажке.
У визуальных редакторов, при всей простоте в создании интерфейса, я каждый раз наблюдал дикие сложности в редактировании, особенно на чужих проектах. Вот нужно заменить 14й шрифт на 12й? Сиди как дурак, тыкай абсолютно все элементы интерфейса, и проверяй размер шрифта. И тыкай аккуратно, чтобы случайно не тыкнуть два раза...
Разумеется, я так на самом деле ни разу не делал - я просто открывал текстовый файл с описанием интерфейса и менял всё там. Поэтому текстовой разметке - быть!
Ну так ведь подходы к дизайнеру могут быть разными. Например, тот же пример с шрифтами. В Delphi, если тебе нужно у всех контролов поменять шрифт, то достаточно поменять шрифт родителя (например, формы). Шрифт, как и многие свойства контролов В Delphi поддерживают наследование. (тут речь о VCL)
Или можно взять новый подход, который сейчас имеется в Delphi для кроссплатформенного фреймворка (FMX). Там есть понятие стилей и оно сопоставимо со стилями CSS. Т.е. для представления любого контрола мы можем задать стиль и достаточно поменять настройки стиля, чтобы изменить все контролы с этим стилем.
На основании этого, я даже делал полноценный стиль Material Design с возможностью указать акцент и смену темная/светлая тема.
При всём при этом у нас остается визуальный дизайнер и кстати, дизайн стиля мы тоже создаем визуально, а не кодом как css. Т.е. всё что мы настраиваем и создаем в виде стилей сразу применяется и отображается в дизайнере.
Шрифт, как и многие свойства контролов В Delphi поддерживают наследование. (тут речь о VCL)
В своём коде я так и делал. Но при редактировании чужой программы всё равно нужно проверить все элементы управления, потому что, тот кто их создавал, мог поставить им размер шрифта вручную.
И со стилями тоже самое. Свои стили я пытаюсь организовать в некоторую систему, а вот чужие регулярно оказывались той ещё хренью.
Все верно. Тонкости в тексте проще довести. Но быстро собрать форму из нескольких десятков элементов проще визуально. А потом уже допилить руками в тексте. Чтобы не сидеть и не представлять в голове "вот у меня кнопка, левый верхний угол X, Y пунктов, ширина N, M пунктов, дальше интервал K пунктов - сколько там должно быть X1, Y1 для второй кнопки? А при ширине N1, M1 оно за границу формы не вылезет?"
А вот теперь уже я должен спросить - извините, какой сейчас год?
Современные UI фреймворки не требуют абсолютного позиционирования элементов. Вы просто добавляете в контейнер сначала одну кнопку, а потом вторую.
Пусть и без абсолютного позиционирования, но видеть наглядно "как получилось" гораздо удобнее, чем перезагружать композер или всю программу.
Не будь такой необходимости, вряд ли бы появились на свет такие инструменты как Figma
Про удобство не спорю. Но вот с дихотомией "либо визуальный редактор, либо рассчитывать все координаты" я не согласен категорически.
И вообще, наиболее удобный вариант редактора я видел для WPF - на одной панели разметка, на второй панели результат.
А я не вижу смысла в отдельной панели с кодом, когда есть дизайнер, в котором ты можешь расположить всё как надо. Речь конечно не об абсолютном позиционировании (я уже не помню, когда подобным занимался), а о добавлении слоев, вставке контролов, указании привязок и настройке других свойств, наличие которых не нужно гуглить или смотреть справку по контролу (виджету).
Hidden text
Чтобы видеть всё то, чего визуальный редактор не показывает.
Вот на вашем втором скриншоте (или это первый? как их вообще считать если один из них под спойлером) текст "Make HTTP Request in javascript" - это статический текст или результат биндинга? У левой панели ширина автоматическая, фиксированная или в процентах? Размер шрифта унаследован, объявлен в стиле, или установлен?
Ну так ведь достаточно нажать на то, что вас интересует и увидеть свойства.
Ну, собственно, в этом и проблема - нужно нажать чтобы увидеть.
Вот нужно заменить 14й шрифт на 12й? Сиди как дурак, тыкай абсолютно все элементы интерфейса, и проверяй размер шрифта. И тыкай аккуратно, чтобы случайно не тыкнуть два раза...
Ну откуда вы это берёте? Конечно же просто изменяете стиль, в одном месте
Да, было. Но ушло в далекое прошлое и превратилось в забытую технологию предков. Не исключено, что лет через пять возродится и породит гигантскую волну хайпа как уникальное и не имеющее аналогов нововведение. Примерно как статическая типизация с TypeScript, автоматическая перестройка интерфейса по изменениям в модели в SPA-фреймворках или компиляция в один исполняемый файл с Rust и Go. На всякий случай - я не хочу сказать что во всех вышеперечисленных технологиях нет ничего нового и/или отличающегося от упомянутого мной вообще.
А где итоговый скриншот? На днях тоже ковырял. Был очень раздосадован, когда провозился несколько часов над демопроектом, выполняя все строго по инструкции. Оказалось, что по автомату подцепилась версия slint 1.4, когда текущая 1.5. После обновления, все завелось без правок кода.
В целом проект очень интересный, в том числе, с его возможностью сборки под веб. К стати, собрался ли этот проект под веб?
Как я понимаю slint был создан для проектирования маленьких интерфейсов. В HMI панелях к примеру. А что насчёт iced?
Их там слишком много всяких. В итоге те формы появятся не в .slint файлах, а прямо в коде, так что врядли разница будет большой.
О, спасибо за ресурс, я и не знал что их такое количество.
С релизом 1.0 ржавчины повсеместно стали появляться сайты вида arewe{X}yet.(com|org|rs) где X - название какой-нибудь технологии - areweguiyet, arewegameyet, ..web.., ..async.., ..wasm.. и прочие. Видел пару сайтов не про ржавчину, которые по тому же принципу какие-то дайджесты своих фреймворков/библиотек делали.
ну, и если интересуетесь новостями, то есть ещё еженедельник this week in rust
Да нет, указывал фичю, иначе компилятор ругается :)
Круто
Я так и не понял, как заставить его растягиваться, так как автоматом канвасу выставляются те же размеры, что указаны в width и height
Скорее всего это ещё не реализовано. Даже в их текстовом проекте https://releases.slint.dev/1.5.1/demos/memory/
явно ничего никуда не растягивается
А как на андроид SQLite завести используя rust ? Тудушку под SQLite сделал, при запуске под Андроид не создаётся бд,
Пишем калькулятор на Rust с GUI