Ребят, в качестве хобби запилил проект — новые лэйауты для WinForms. Кратко, это копия WPF-ных лэйаутов, но для WinForms, т.е. инженерно более правильная архитектура: на форме лежит "распределитель контролов", а сами контролы лежат поверх и автоматом раскидываются куда надо.
Пример:
Здесь 3.5 вида расположений: docking, table и горизонтальная/вертикальная полоса.
В самом WinForms уже есть table, но он тормознутый и его использование — зубная боль! (чего стоит один их ублюдочный дизайнер)
Докинг тоже более умный и оторван от личных свойств контрола. Благодаря порядку контролов в доке, они детерминированно занимают свободное пространство.
Ну а полосы — тоже не просто "полоска с хренью", а позволяет выравнивание (вверх/вниз/сентр/растянуть) и, внимание, "притяжение"! Т.е. контролы можно загнать в центр или правый край полоски независимо друг от друга (как listBox2 на картинке).
Вопрос: этот проект кому-нть интересен? Стоит его развивать? Я сам WinForms юзал очень давно, могу что-то и дилетантски сделать, вот как раз народ мог бы посмотреть, что к чему.
PS
Наверное, стоит пояснить, зачем выкопали стюардессу.
С моей колокольни дело выглядит так:
Есть WinForms — "очень продвинутый враппер" над Win32. Соотв. настолько быстрый и нативный, насколько можно себе позволить. Ну и откровенно, он ничем не плох для создания UI. Сколько "плоскоземельщики" (сторонники плоского интерфейса) ни выёживались, мутный, неразличимый интерфейс "тыкай в любой квадрат — вдруг это кнопка?" — не наш девиз. Я — олдскул, мой идеал — интерфейс Офиса 2003. Вот та тёплая, ламповая "синева", где кнопка — это кнопка, всё кругленькое и легко распознаваемое. Собственно, это и есть тот WinForms, который я хочу возродить.
WPF — это разумные зёрна пшеницы, кинутые в тупорылую почву "песок за полярным кругом". Шикарная идея декларативного интерфейса, доверенная стаду макак и укуренным гикам-космическим-архитекторам. Результат — гремучий, тормознутый павлиноуткаёж для создания километровых шаблонов кнопки. Сразу в топку.
Но... у нас осталось пара зёрен! А что если... да не! Не может быть... декларативный WinForms?! Что, прямо вот так просто <Button> и всё? "Да не, это фантастика!" (ц) Но на то мы и погромизды — боги компьютера, способные создавать "из ничего" шедевры! Так что программа максимум — это полная замена ушлёпскому WPF в виде новой, декларативной надстройки над WinForms, которая будет маленькой, простой, транслироваться в WinForms и наконец дать тот инструмент, который мы заслужили за годы мучений с XAML.
Здравствуйте, Kolesiki, Вы писали:
K>>>Никакого кода! Декларативно — значит отдельно от мух. AM>>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
K>Сам себе противоречишь — не смешивать и "тот же язык".
не вижу противоречий. То что вьюху лучше написать в отдельном классе логично, но если на том же языке — почему нет? K>Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#.
Да вроде развивается язык, можно многие вещи достаточно декларативно писать, не сравнить с 1й версией AM>>И не надо какой-то ещё один язык писать.
K>Надо. Для того и придумали идею DSL.
А если новый DSL — это всё тот же C#, то вообще красота.
AM>>Подобным путём пошли не только Eto, но и для мобилок swiftUI, flutter, compose: тоже на swift, dart, kotlin UI пишут.
K>"Ну и дураки!" (ц) Нет смысла равняться на баранов, если они бегут в пропасть. Ну и попутно, надо расширять свой лоб, чтоб не мыслить узко: ведь дело не только в том, чтобы "побырому накрапать гуйню" — так пишут студенты одноразовый код.
Вполне неплохой код получается на всех этих языках, легко пишется и потом читается, сопровождается K> А так, по-хорошему, есть и другие попутные преимущества именно отдельного ГУЙ-языка:
K>DSL позволяет меньше ошибаться в коде, меньше вообще его писать. <Button> — за этим может скрываться 20 строчек кода! Причём проверенного.
а если будет написано Button() всё будет так же, плюс компилятор сразу и типы проверит. K>DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван.
Сколько лет слышу эту байку, а в живую пока не видел — на этих DSL всё равно пишут программисты. Неожиданно надо уметь программировать, чтобы на них рисовать, дизайнеры обычно отвратные программисты. K>DSL позволяет легко улучшать низлежащий код — декларации остаются, а контрол хорошеет.
Любая библиотека может быть улучшена без изменения внешних соглашений K>DSL легко перезагружать, он динамичен. Низлежащие onClick'и остаются, а ГУЙ полностью меняется одним движением руки.
многие умеют hot-reload K>DSL в принципе проще — и структурно, и для изучения, и для улучшения (сопровождения).
на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает.
AM>>Меня только new здесь смущает, а так на мой взгляд читается не хуже вашего предложения. K>Я и говорю — "студенты пишут одноразовый код" — тогда да, почти не хуже. Но если прочитать приведённый список, то "сишарповая гуйня" — тот ещё отстой. Увы.
На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
Для WPF вот вполне приятная либа: https://github.com/VincentH-Net/CSharpForMarkup
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, AntoxaM, Вы писали:
AM>>Здравствуйте, Kolesiki, Вы писали:
K>>>>>Никакого кода! Декларативно — значит отдельно от мух. AM>>>>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
K>>>Сам себе противоречишь — не смешивать и "тот же язык". AM>>не вижу противоречий. То что вьюху лучше написать в отдельном классе логично, но если на том же языке — почему нет?
K>Каком "том же"?? UI — декларативный DSL. Который, повторюсь, позволяет "смешивать бизнес логику и рисование не надо".
Пока так и не понял в чём преимущество UI на своём языке. Плохой программист всё равно найдёт место где наговнокодить.
K>>>Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#. AM>>Да вроде развивается язык, можно многие вещи достаточно декларативно писать, не сравнить с 1й версией
K>Не надо путать ЯОН с декларативным UI — это вообще "разные миры". То, что в каком-то ЯОН стало чуть лучше что-то писать, вообще никак не делает его пригодным для UI. См. мой пример выше — там C# даже близко не стоял.
про c# мне тяжело судить, но вот когда смотрю и пишу на jetpack compose или swiftUI, то вполне себе выглядит как DSL, работает как DSL, крякает как DSL и при этом является кодом на kotlin и swift.
K>>>Надо. Для того и придумали идею DSL. AM>>А если новый DSL — это всё тот же C#, то вообще красота. K>C# не может быть "новым DSL", так как уже является стандартным C#.
библиотека может позволить коду на C# выглядеть как DSL.
K>>>DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван. AM>>Сколько лет слышу эту байку, а в живую пока не видел
K>Ограниченность личного опыта — не повод для общих суждений. В нищебродной России программисты даже принтер заправляют — но это же не повод?? K>Дизайнер — отдельная профессия, именно для них делался целый Blend. Другой вопрос, что освоить раздутое г***но типа WPF даже программистам сложно, поэтому инструмент тихо загнулся. K>А как раз ПРОСТОЙ язык позволит струячить UI не задевая прогера: он делает скелет, дизайнер "крутит ползунки".
Интересно было бы такое увидеть, но пока звучит как фантастика — очень непросто создать инструмент, удобный дизайнеру и позволяющий его потом использовать программистом.
Вспоминая Blend, который MS как раз под этим соусом пытался протолкнуть, как оно — где-то видно его, много дизайнеров его освоили?
В какого дизайнера ни плюнь — умеет фигму, иногда adobe или скетч. Статический html уже не все могут, а уж в какой-нибудь angular/react уже вряд ли осилят.
AM>> на этих DSL всё равно пишут программисты
K>Потому и пишут, что DSL — гогно! Слишком сложен. Плюс, индустрию надо РАЗВИВАТЬ, а не как MS — швырнула в толпу WPF и всё, делайте чё хотите, вот вам кусок нашего гения! K>По фотошопу курсы есть — по WPF тоже должны быть, индустрия должна быть уверена в стабильности платформы и её развитии. А WPF просто забросили НА ГОДЫ — ну и кто будет в это вкладываться??
DSLи сложные, потому что тема сложная.
AM>>на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает.
K>Ну да, см. пример про принтер. А потом придёт какой-нть "ЛИСПовод" или вообще "дизайнер-самоучка" — "А чоэта у вас тут C#, я не уметь!". ТЫ его будешь своему "цэшарпу" учить??
для UI из всего c# надо будет знать достаточно небольшое его подмножество, разницы с отдельным языком я не вижу.
Дизайнер будет уметь в фигму, а c# или ваш язык не будет знать и не захочет знать.
Ну а если, лисповод придёт программировать под .net на c#, и при этом будет жаловаться — а чё это у вас тут с#, я удивлюсь.
K>Теги HTML осваивает даже секретарша, благодаря чему на заре Тырнета мы поимели миллионы "хомепаг". C# — отдельный сложный язык, в нём без программистского бэкграунда делать нечего.
для UI из всего c# надо будет знать достаточно небольшое его подмножество, сложность будет не выше html.
K>Корень проблемы — "совок" в голове: когда программист за нищенскую зарплату тянет сотню профессий. Просто представь: в мире есть ОТДЕЛЬНЫЙ дизайнер, который "умеет в цвета". Всё. ЕМУ ты это объясни, что "C# — это круто!" Тебя даже слушать не будут, ибо не круто.
ну так тебе этот дизайнер нарисует в фигме картинки с нужными цветами и на этом всё — дальше ему сложно и не понятно.
AM>>На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
K>Сложно сказать, кто именно и по каким критериям считал это "невостребован". Вот Бейсик — очевидно, постоянно в догоняющих, сам язык многословный, неуклюжий, "детский" какой-то. По нему я уверенно могу сказать "живой труп, никак не сваливающийся на обочину истории" (в осн. благодаря чудилам из M$). А вот WinFroms... очевидно, что она имеет серьёзные преимущества, чтобы вот так её голословно хоронить. Я потому и занялся декларациями ДЛЯ WINFORMS, т.к. сама технология вполне мощная, просто клоунам в MS "скучно" её улучшать.
Возможно это поыт такой у меня, и на самом деле продолжают писать на нём, но все знакомые WinForms программисты уже давно WinForms в глаза не видели.
Здравствуйте, Kolesiki, Вы писали:
K>>>Ребят, в качестве хобби запилил проект — новые лэйауты для WinForms. vaa>>Кажется что-то похожее уже есть vaa>>https://github.com/picoe/Eto/wiki/Quick-Start
K>Да не "что-то", а десяток разной степени "гиканутости" библиотек! Это "ето" я уже видел, но не факт, что их лэйауты лучше.
vaa>>xaml definitions под различные движки, в том числе WinForms.
K>эээ?? Ткни мышью, не нашёл даже упоминания про XAML, не говоря про "под различные движки". Ну и потом, XAML/WPF — это такое себе наследие... чем от него дальше, тем лучше.
vaa>>не то?
K>Нет. Пока не вижу аналога. Там ВыньФормсы делаются тупо из кода.
ИМХО, таки не тупо из кода, а декларативно из кода.
vaa>>В коде кстати, тоже достаточно декларативно получается, имхо. K>Никакого кода! Декларативно — значит отдельно от мух.
Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
В итоге достаточно декларативно пишется, но если надо, то можно использовать любые средства языка как для написания, редактирования, просмотра. И не надо какой-то ещё один язык писать.
Подобным путём пошли не только Eto, но и для мобилок swiftUI, flutter, compose: тоже на swift, dart, kotlin UI пишут.
Меня только new здесь смущает, а так на мой взгляд читается не хуже вашего предложения.
public MyEtoPanel()
{
var button = new Button { Text = "Show Dialog" };
Content = new TableLayout
{
Spacing = new Size(5, 5),
Rows =
{
new TableRow(new Label { Text = "An Eto.Forms control" }),
new TableRow(new TextBox()),
new TableRow(new ComboBox { Items = { "Item 1", "Item 2", "Item 3" } }),
button,
null
}
};
}
Здравствуйте, Kolesiki, Вы писали:
K>Ребят, в качестве хобби запилил проект — новые лэйауты для WinForms.
Кажется что-то похожее уже есть https://github.com/picoe/Eto/wiki/Quick-Start
xaml definitions под различные движки, в том числе WinForms.
не то? https://github.com/picoe/Eto/wiki/Containers
В коде кстати, тоже достаточно декларативно получается, имхо.
Здравствуйте, vaa, Вы писали:
K>>Ребят, в качестве хобби запилил проект — новые лэйауты для WinForms.
vaa>Кажется что-то похожее уже есть vaa>https://github.com/picoe/Eto/wiki/Quick-Start
Да не "что-то", а десяток разной степени "гиканутости" библиотек! Это "ето" я уже видел, но не факт, что их лэйауты лучше.
vaa>xaml definitions под различные движки, в том числе WinForms.
эээ?? Ткни мышью, не нашёл даже упоминания про XAML, не говоря про "под различные движки". Ну и потом, XAML/WPF — это такое себе наследие... чем от него дальше, тем лучше.
vaa>не то?
Нет. Пока не вижу аналога. Там ВыньФормсы делаются тупо из кода.
vaa>В коде кстати, тоже достаточно декларативно получается, имхо.
Никакого кода! Декларативно — значит отдельно от мух.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Kolesiki, Вы писали:
K>>Здесь 3.5 вида расположений: docking, table и горизонтальная/вертикальная полоса.
MD>Это всё хорошо, но... как насчёт круглых кнопок? Треугольных? Залезающих друг на друга частично? Про анимации не спрашиваю...
Да ЛЮБОЙ каприз! (за ваши деньги ) Всё, что позволяет WinForms, то и мы позволим. Только делаться это будет не на 1000-строчном шаблоне, а отдельным контролом RoundButton. Чего тут сверхсложного?
MD>Например, типа этого:
Да, ОЧЕНЬ ТИПИЧНЫЙ интерфейс!!
MD>"Стадо макак" почему-то смогло предложить разработчикам способы построения подобных интерфейсов
Ну так а нахрен оно нужно — это решение? Вернее, ТАКОЙ ЦЕНОЙ. Шаблон ЛЮБОГО контрола в WPF — это бесконечная портянка лэйаутов, байндингов, событий, триггеров, хитрожопых стилей и попробуй только ошибись!! Охренеешь отлаживавши. А самое ржачное, что бегали-бегали со своей декларативностью, а так нихрена от неё и не получили — так и осталось решение windows-only.
Или вот тоже вопрос в пику: ты можешь сделать XAML, сканпелять, запустить, а потом загрузить с диска другой XAML (ровно с теми же элементами и именами) и заменить им текущий вид?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Это всё хорошо, но... как насчёт круглых кнопок? Треугольных? Залезающих друг на друга частично? Про анимации не спрашиваю... MD>Например, типа этого:
А как бы ничего, что это вопрос для iOS и там внизу портянка кода для реализации?? Хотел бы поржать, сколько километров кода будет на WPF. Хотя откровенно, вообще не хочу больше смотреть на XAML — осточертел.
Немного неуклюже получилось с топиком... показал лэйауты, а в постскриптуме — целая глобальная идея! Но лэйауты пригодятся и в этом проекте. Ладно, "Близе к дельу!" (ц) Шакал
Набросал черновик декларативного языка для UI, рабочее название — "Sketchy". Я много раз брался за эту задачу и каждый раз что-то там переусложнял, универсализировал... получал в итоге довольно неудобную мешанину. На этот раз я очень надеюсь, что получилось что-то практичное.
Хочу повесить в воздухе главную мысль: ПРОСТОТА. Язык должен быть лаконичным, безо всяких извращений, костылей и языков-в-языке. Например, если что-то проще написать в коде, это будет сделано в коде (как ужасный пример из WPF, поиск parent контрола и байндинг к его свойству).
Для ознакомления сделал вот такой пример кода (только то, что на данный момент работает):
Здесь видно, что есть стили (будет ещё наследование стилей, причём множественное). Аналогично, сразу несколько стилей могут быть применены к одному контролу.
Alias — тут всё ясно (для избежания коллизий с чужими контролами). Будут mixins(!). Вообще, хочу максимально приблизиться к крутости небезызвестного (и заброшенного автором) Ammy, но именно для WinForms.
Важная мысль-щит против тех, кто "набигает" сюда с домиками WPF: мы не делаем аналог или "убийцу" WPF. Более того: если вас устраивает WPF-экосистема, не тратьте нервы на моё поделие — оно априори будет проще и конечно же, даже рядом не будет стоять с тем, что могут наворотить в XAML отдельные извращенцы. Задача Sketchy — попробовать сделать декларативный WinForms, причём так, чтобы было приятно этим пользоваться. Большинство задач ГУЕклёпов просты как топор: формочки, гриды, скролы-бары-пассатижи. Даже собственные контролы далеко не все пишут! (я — писал )
После WPF мне очень нравится идея текстового описания UI, тем более, что результат сразу виден. "Визуальное" создание форм, особенно в неуклюжем VS — ну такое себе... так что будем идти декларативным путём. "За лопаты, товарищи!"
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, vaa, Вы писали:
K>>>Ребят, в качестве хобби запилил проект — новые лэйауты для WinForms.
vaa>>Кажется что-то похожее уже есть vaa>>https://github.com/picoe/Eto/wiki/Quick-Start
K>Да не "что-то", а десяток разной степени "гиканутости" библиотек! Это "ето" я уже видел, но не факт, что их лэйауты лучше.
vaa>>xaml definitions под различные движки, в том числе WinForms.
K>эээ?? Ткни мышью, не нашёл даже упоминания про XAML, не говоря про "под различные движки". dotnet new etoapp -m xaml # create a project xaml definitions K> Ну и потом, XAML/WPF — это такое себе наследие... чем от него дальше, тем лучше.
А в твоем проекте как описывается разметка, в дизайнере?
K>Нет. Пока не вижу аналога. Там ВыньФормсы делаются тупо из кода.
K>Никакого кода! Декларативно — значит отдельно от мух.
Здравствуйте, Kolesiki, Вы писали:
K>Да ЛЮБОЙ каприз! (за ваши деньги ) Всё, что позволяет WinForms, то и мы позволим.
А позволяет он не очень много. Mission complete!
K>Только делаться это будет не на 1000-строчном шаблоне, а отдельным контролом RoundButton. Чего тут сверхсложного?
И контрол будет в 1000 строк кода. Казалось бы, чего тут сверхсложного?
K>Да, ОЧЕНЬ ТИПИЧНЫЙ интерфейс!!
А вот тут уже смеяться не буду — впору плакать. Вы в самом деле не замечаете, что интерфейсы перестали быть квадратными? Пройдоха Джобс разбаловал людей, они хотят красивые интерфейсы, необычные интерфейсы, меняющиеся интерфейсы, скины, цветовые темы. Хотя чего я на Стива наезжаю — попробуйте Вашей библиотекой повторить классику. Да-да, тот самый проигрыватель MP3.
K>Ну так а нахрен оно нужно — это решение? Вернее, ТАКОЙ ЦЕНОЙ.
Насчёт "цены", отвечу цитатой:
— Вы утверждаете, что человек может поднять себя за волосы?
— Обязательно! Каждый здравомыслящий человек просто обязан время от времени это делать!
Помнится, когда я разрабатывал под FoxPro, мне встречались уже весьма пожилие люди, говорившие "нафига, вот в Clarion/ИнфоБухгалтер/etc это сделать проще". Ну и где этот Кларион? Там же, где восклицавшие.
Когда Фокс стал тесен, перешёл на Delphi, когда и он стал узковат, перешёл на C#/XAML. Станет неподходящим C# — возьму что-то более подходящее для решаемых задач. Не надо "жениться" на технологии. Нужен кругозор.
K>Шаблон ЛЮБОГО контрола в WPF — это бесконечная портянка лэйаутов, байндингов, событий, триггеров, хитрожопых стилей и попробуй только ошибись!! Охренеешь отлаживавши.
Шаблон ЛЮБОГО <X> в технологии <Y> — это бесконечная портянка <A>, <B>, <C> и попробуй только ошибись!! Охренеешь отлаживавши.
А затем, набивши шишек, разбираешься с технологией — и проблем дальше нет.
K>А самое ржачное, что бегали-бегали со своей декларативностью, а так нихрена от неё и не получили — так и осталось решение windows-only.
Ждём. Раньше и C#-код сам по себе был windows-only. А сейчас гляди-ка — NET Core работает на линуксах.
K>Или вот тоже вопрос в пику: ты можешь сделать XAML, сканпелять, запустить, а потом загрузить с диска другой XAML (ровно с теми же элементами и именами) и заменить им текущий вид?
Здравствуйте, Kolesiki, Вы писали:
K>А как бы ничего, что это вопрос для iOS и там внизу портянка кода для реализации??
Это интерфейс, он не зависит от языка программирования. Например, завтра приходит Product Owner и говорит "пацаны, теперь вот точно такое же — но для десктопа".
K>Хотел бы поржать, сколько километров кода будет на WPF.
Будет шаблон для элемента (кружочек с фоткой, именем и точечками сбоку), и будет шаблон для коллекции, которая при помощи матрицы трансформаций будет расставлять и поворачивать свои элементы вокруг центра. Более того, очень легко написать логику, которая будет равномерно расставлять элементы по кругу для любого N. Никаких километров кода там нет.
Здравствуйте, vaa, Вы писали:
vaa>А в твоем проекте как описывается разметка, в дизайнере?
В редакторе. "Дизайнер" (вернее, "отображатель результата") ещё впереди. Это как XAML+вьюер.
На данный момент я лишь проверяю саму идею — можно ли сделать декларативный язык, который проще XAML, но мощности которого хватит на любой GUI.
K>>Никакого кода! Декларативно — значит отдельно от мух.
vaa>ну не знаю, а если нужна простая ui-утилита, что ж, дизайнер подтягивать?
хм... а что в дизайнере "не так"?? Или он у тебя запускается 2 дня? Если так уверен, можешь вообще UI в блокноте набрать! (собственно, я к этому и стремлюсь — максимально упростить декларации)
vaa>java swing вот отлично сочитал в себе и то и другое(netbeans дизайнер), причем без partial классов.
Ну как "отлично сочетал"... вообще никак! Для мира Жабы это может и достижение, но в .NET после появления WPF, всё резко скакнуло на ступень выше. Мы это и так имели в виде HTML, но когда это применили ещё и к программным ГУЯм, стало совсем приятно.
Здравствуйте, Kolesiki, Вы писали: K>На данный момент я лишь проверяю саму идею — можно ли сделать декларативный язык, который проще XAML, но мощности которого хватит на любой GUI.
ясно, хорошая идея.
но язык должен быть прям ВАУ!
ну вроде еще json нотацию используют в Ammy и Eto.Forms
особенно нравятся лямбды конверторов в описании ГУЙЯ.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Kolesiki, Вы писали: K>>На данный момент я лишь проверяю саму идею — можно ли сделать декларативный язык, который проще XAML, но мощности которого хватит на любой GUI. vaa>ясно, хорошая идея. vaa>но язык должен быть прям ВАУ!
Ну вот ты же уже увидел его в редакторе — тебе он понятен?
"вау" — мне второкурсниц соблазнять не надо, мне нужно, чтобы язык был мощным и лаконичным. Типа как ЛИСП. Но для ГУЯ. И чтобы пишущие на нём не испытывали зубной боли.
vaa>ну вроде еще json нотацию используют в Ammy и Eto.Forms
Нет, увы — JSON для гуёв не подходит. Да и простоват слишком.
Язык ГУЯ должен быть DSL-порождением. Т.е. быть специально на это заточенным. И простым. Я как вспомню style="{StaticResource bzbz}", так вздрогну!!
Неужели за столько лет макаки из MS не умудохались это писать?? Очевидно же, что этим StaticResource будет пронизан ВЕСЬ КОД! Соотв. надо что-то думать по сахарку, чтоб народ не охренел вводить это в тысячный раз. Вот я над этим тоже думаю. К примеру, использование стиля не требует писать "стиль={покопатьсяВпомойкеРесурсовИНайтиИмя клёвыйСтиль}" — достаточно просто @клёвыйСтиль . Уже существенное упрощение! А вкупе с подсветкой, даёт отдыхать глазам от синтаксического шума.
vaa>особенно нравятся лямбды конверторов в описании ГУЙЯ.
Здравствуйте, Mr.Delphist, Вы писали:
K>>Только делаться это будет не на 1000-строчном шаблоне, а отдельным контролом RoundButton. Чего тут сверхсложного? MD>И контрол будет в 1000 строк кода. Казалось бы, чего тут сверхсложного?
Я и спрашиваю, что именно ты увидел сложного? Первый раз за C# сел что ли?? В том и дело, что КОД (как последовательность отрисовки) куда проще, чем объяснять на XML "найди мне предка с типом Button и залезь к нему в Bottom". Или того хуже — по 3 вложенных тега писать ради простых писюлек.
K>>Да, ОЧЕНЬ ТИПИЧНЫЙ интерфейс!!
MD>А вот тут уже смеяться не буду — впору плакать. Вы в самом деле не замечаете, что интерфейсы перестали быть квадратными?
Ну это кто что курит — тому то и мерещится. Если делать интерфейсы к angry birds — да, весело и забористо. А если для 99% десктоп-задач — там "квадраты" никуда не девались уже лет так 40. Да и по программе сразу видно — разрабы просрали время на "кругленькие карусельки" или занимались полировкой кода (привет кретинам, пилящим Vegas).
K>>Ну так а нахрен оно нужно — это решение? Вернее, ТАКОЙ ЦЕНОЙ.
MD>Насчёт "цены", отвечу цитатой: MD>
MD>— Вы утверждаете, что человек может поднять себя за волосы?
MD>— Обязательно! Каждый здравомыслящий человек просто обязан время от времени это делать!
Сам себе мудрость придумал, сам себя похвалил — так что ли? Без выпендрёжа уже не способен объяснить?
MD>Не надо "жениться" на технологии. Нужен кругозор.
Это тут причём? Ты вообще не въезжаешь, ЧТО ИМЕННО я пилю? Тут винформсы просто "подкапотная технология", вся маковка будет снаружи.
K>>Шаблон ЛЮБОГО контрола в WPF — это бесконечная портянка лэйаутов, байндингов, событий, триггеров, хитрожопых стилей и попробуй только ошибись!! Охренеешь отлаживавши.
MD>Шаблон ЛЮБОГО <X> в технологии <Y> — это бесконечная портянка <A>, <B>, <C> и попробуй только ошибись!! Охренеешь отлаживавши. MD>А затем, набивши шишек, разбираешься с технологией — и проблем дальше нет.
Было бы всё так просто, не было бы "плохих языков" — все были бы такими умниками как ты и писали НА ВСЁМ. Увы, "разбираться с технологией" мало — нужно, чтоб ещё сама технология не была высером больного извращенца (типа "синтаксиса на отступах" в пестоне).
K>>А самое ржачное, что бегали-бегали со своей декларативностью, а так нихрена от неё и не получили — так и осталось решение windows-only.
MD>Ждём. Раньше и C#-код сам по себе был windows-only. А сейчас гляди-ка — NET Core работает на линуксах.
Жди. Только вот перенос WPF даже не в планах(!!!). Что говорит как о квалификации его архитекторов, так и "воплощателей". И вообще M$ уже не интересен WPF — они побежали вперёд со своими Кошмаринами, MAUI и прочей белибердой. Как только на этих бородатых школотронов кончатся деньги (и терпение), их погонят ссаной метлой пилить "мультиплатформ" на морозе.
K>>Или вот тоже вопрос в пику: ты можешь сделать XAML, сканпелять, запустить, а потом загрузить с диска другой XAML (ровно с теми же элементами и именами) и заменить им текущий вид?
MD>Google://load xaml from file
Ты меня за идиота держишь или себя? Неужели ты думаешь, что я про это не читал? Это НЕ РЕШЕНИЕ, ибо XamlReader.Load загружает только дочерний контент (я не могу загрузить класс Window) и во-вторых, даже не подцепляет события! А вручную заниматься этой клоунадой нет интереса — я так и в WinForms могу написать!
Я вот понять не могу — я пишу вроде по-русски, разве что красным не выделяю для умников: "если вас устраивает WPF-экосистема, не тратьте нервы на моё поделие"
Я не отгораживаюсь от критиков, но мне в хрен не упёрлись "амбассадоры %ОчереднаяХренотеньКоторойОниПользуются%". Если в МОЁМ решении ты видишь какую-то проблему — напиши, я с радостью рассмотрю — это ведь только черновик, многое может поменяться. А просто "я сижу в ВПФ и мне кайф" — ну такая себе помощь... от вил на воде больше толку.
Здравствуйте, AntoxaM, Вы писали:
K>>Никакого кода! Декларативно — значит отдельно от мух.
AM>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
Сам себе противоречишь — не смешивать и "тот же язык". Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#.
AM>И не надо какой-то ещё один язык писать.
Надо. Для того и придумали идею DSL.
AM>Подобным путём пошли не только Eto, но и для мобилок swiftUI, flutter, compose: тоже на swift, dart, kotlin UI пишут.
"Ну и дураки!" (ц) Нет смысла равняться на баранов, если они бегут в пропасть. Ну и попутно, надо расширять свой лоб, чтоб не мыслить узко: ведь дело не только в том, чтобы "побырому накрапать гуйню" — так пишут студенты одноразовый код. А так, по-хорошему, есть и другие попутные преимущества именно отдельного ГУЙ-языка:
DSL позволяет меньше ошибаться в коде, меньше вообще его писать. <Button> — за этим может скрываться 20 строчек кода! Причём проверенного.
DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван.
DSL позволяет легко улучшать низлежащий код — декларации остаются, а контрол хорошеет.
DSL легко перезагружать, он динамичен. Низлежащие onClick'и остаются, а ГУЙ полностью меняется одним движением руки.
DSL в принципе проще — и структурно, и для изучения, и для улучшения (сопровождения).
AM>Меня только new здесь смущает, а так на мой взгляд читается не хуже вашего предложения.
Я и говорю — "студенты пишут одноразовый код" — тогда да, почти не хуже. Но если прочитать приведённый список, то "сишарповая гуйня" — тот ещё отстой. Увы.
Здравствуйте, vaa, Вы писали:
vaa>>>xaml definitions под различные движки, в том числе WinForms.
Да, спасибо, ТЕПЕРЬ увидел. Это ж надо так залепёхать сайт, что нихрена найти невозможно!
Но так или иначе, XAML — это явно ущербное решение. Притягивать за уши XML? Чего ради? Сначала должна проверяться применимость языка, а потом уже запиливать на нём "гуй-язык". То, что наворотили в XAML, явно вышло за рамки адекватности.
K>>Никакого кода! Декларативно — значит отдельно от мух. vaa>ну не знаю, а если нужна простая ui-утилита, что ж, дизайнер подтягивать?
Ну да, а что? Один хрен тебе нужно ПИСАТЬ ДЕКЛАРАЦИИ! Только с дизайнером ты видишь live view, а в нотепаде только C#.
И потом, уже давно эти грабли пройдены — не бывает "простых утилит"! Если тебе понадобилась сторонняя приблуда, значит и кому-то ещё. А ему нужна ещё одна кнопка. А в процессе развития проекта обновились запросы. И в итоге то, что было сделано "одноразово для себя", всё равно живёт дольше часа и всё равно требует улучшений, отладки и может даже передачи другой команде. Не думай об утилитах свысока это проекты не на один раз.
Видимо, точно так же думал головотяп Торвальдс со своим похабным git'ом — налепил команд "для себя, побырому", потом ещё команд, потом кривых флагов для тех же команд, а в результате получил алогичное говно. Которое даже стыдно сравнивать с Mercurial.
K>Ну да, а что? Один хрен тебе нужно ПИСАТЬ ДЕКЛАРАЦИИ! Только с дизайнером ты видишь live view, а в нотепаде только C#.
Ну когда ничего другого не было winforms и delphi с visual basic были конечно прорывом.
Следом подтянулись и html редакторы — которые сразу генерили html.
Но в итоге сейчас основная технология: hotreload. Экономит кучу времени и сил на поддержку глючного визуального редактора.
А по факту более продвинутое решение: не просто видим, но и можем "покликать".
Ну и разметка возможно когда-то умрет. Ведь это отдельный ЯП, а все движется к унификации процесса разработки. Вот пример удачного синтаксиса, я считаю.
Плюс такого подхода что не нужно учить синтаксические/семантические тонкости разных языков (Xaml, razor и т.д.).
Т.е. вот partial только с этой целью и вводили — поддержка визуального редактора.
Обратная сторона этого: страшные надписи генератора "если работает, ничего не трогай!"
Еще кстати, непреодолимый косяк визуального дизайнера — обязательно должен быть конструктор без параметров, что на корню рубит чистоту ООП.
А ведь проще реализовать live view/hot reload.
Тем более что на дотнете это принципиально решаемо
Здравствуйте, AntoxaM, Вы писали:
AM>Здравствуйте, Kolesiki, Вы писали:
K>>>>Никакого кода! Декларативно — значит отдельно от мух. AM>>>Это зря. Конечно смешивать бизнес логику и рисование не надо, но если язык позволяет — то имеет смысл использовать тот же язык.
K>>Сам себе противоречишь — не смешивать и "тот же язык". AM>не вижу противоречий. То что вьюху лучше написать в отдельном классе логично, но если на том же языке — почему нет?
Каком "том же"?? UI — декларативный DSL. Который, повторюсь, позволяет "смешивать бизнес логику и рисование не надо".
K>>Более того — в C# нет вообще ничего, что хоть как-то делало бы его удобным для UI. Даже в HTML больше "визуальности", чем в C#. AM>Да вроде развивается язык, можно многие вещи достаточно декларативно писать, не сравнить с 1й версией
Не надо путать ЯОН с декларативным UI — это вообще "разные миры". То, что в каком-то ЯОН стало чуть лучше что-то писать, вообще никак не делает его пригодным для UI. См. мой пример выше — там C# даже близко не стоял.
K>>Надо. Для того и придумали идею DSL. AM>А если новый DSL — это всё тот же C#, то вообще красота.
C# не может быть "новым DSL", так как уже является стандартным C#.
K>>DSL можно "отдать на сторону" для дизайна. Как известно, программисты — отвратные дизайнеры, поэтому ГУЙ должен делать отдельный UI/UX подаван. AM>Сколько лет слышу эту байку, а в живую пока не видел
Ограниченность личного опыта — не повод для общих суждений. В нищебродной России программисты даже принтер заправляют — но это же не повод??
Дизайнер — отдельная профессия, именно для них делался целый Blend. Другой вопрос, что освоить раздутое г***но типа WPF даже программистам сложно, поэтому инструмент тихо загнулся.
А как раз ПРОСТОЙ язык позволит струячить UI не задевая прогера: он делает скелет, дизайнер "крутит ползунки".
AM> на этих DSL всё равно пишут программисты
Потому и пишут, что DSL — гогно! Слишком сложен. Плюс, индустрию надо РАЗВИВАТЬ, а не как MS — швырнула в толпу WPF и всё, делайте чё хотите, вот вам кусок нашего гения!
По фотошопу курсы есть — по WPF тоже должны быть, индустрия должна быть уверена в стабильности платформы и её развитии. А WPF просто забросили НА ГОДЫ — ну и кто будет в это вкладываться??
K>>DSL легко перезагружать, он динамичен. Низлежащие onClick'и остаются, а ГУЙ полностью меняется одним движением руки. AM> многие умеют hot-reload
Мне нужны не "многие", а у хорошего GUI DSL. Он пока ещё никем не написан.
K>>DSL в принципе проще — и структурно, и для изучения, и для улучшения (сопровождения). AM>на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает.
Ну да, см. пример про принтер. А потом придёт какой-нть "ЛИСПовод" или вообще "дизайнер-самоучка" — "А чоэта у вас тут C#, я не уметь!". ТЫ его будешь своему "цэшарпу" учить??
Теги HTML осваивает даже секретарша, благодаря чему на заре Тырнета мы поимели миллионы "хомепаг". C# — отдельный сложный язык, в нём без программистского бэкграунда делать нечего.
Корень проблемы — "совок" в голове: когда программист за нищенскую зарплату тянет сотню профессий. Просто представь: в мире есть ОТДЕЛЬНЫЙ дизайнер, который "умеет в цвета". Всё. ЕМУ ты это объясни, что "C# — это круто!" Тебя даже слушать не будут, ибо не круто.
AM>На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
Сложно сказать, кто именно и по каким критериям считал это "невостребован". Вот Бейсик — очевидно, постоянно в догоняющих, сам язык многословный, неуклюжий, "детский" какой-то. По нему я уверенно могу сказать "живой труп, никак не сваливающийся на обочину истории" (в осн. благодаря чудилам из M$). А вот WinFroms... очевидно, что она имеет серьёзные преимущества, чтобы вот так её голословно хоронить. Я потому и занялся декларациями ДЛЯ WINFORMS, т.к. сама технология вполне мощная, просто клоунам в MS "скучно" её улучшать.
Здравствуйте, AntoxaM, Вы писали:
K>>>>Надо. Для того и придумали идею DSL. AM>>>А если новый DSL — это всё тот же C#, то вообще красота. K>>C# не может быть "новым DSL", так как уже является стандартным C#. AM>библиотека может позволить коду на C# выглядеть как DSL.
Полностью согласен. Не понимаю, зачем плодить языки программирования, если они не улучшают существующие, не повышают продуктивность и т.п.
Есть масса библиотек генераторов кода, в т.ч. для генерации JavaScript и т.п., например:
Из современных возможно (не разбирался пока подробно): https://anglesharp.github.io/
AM>>> на этих DSL всё равно пишут программисты AM>>>на мой взгляд код C# упрощает чтение кода, поскольку пограммист его уже знает. AM>для UI из всего c# надо будет знать достаточно небольшое его подмножество, разницы с отдельным языком я не вижу. AM>для UI из всего c# надо будет знать достаточно небольшое его подмножество, сложность будет не выше html.
Полностью согласен, кроме того можно ведь реально сделать ограничения по синтаксису, чтобы знатоки не наворотили слишком крутых конструкций, нечитаемых потом нубами-дизайнерами.
Т.е. добавить специальный предварительный синтакс Analyzer перед сборкой, который будет отпинывать сложные конструкции как нежелательные в данном проекте.
AM>>>На мой взгляд, просто не очень winforms восстребован, поэтму Eto не очень продвинута.
Интересно, насколько расширяема Eto? Например, насколько сложно описать для нее дополнительные конструкции для компонентов DevExpress WinForms?
K>>Сложно сказать, кто именно и по каким критериям считал это "невостребован". Вот Бейсик — очевидно, постоянно в догоняющих, сам язык многословный, неуклюжий, "детский" какой-то.
В этом его преимущество, программы на нем легко читаются и через 10 лет после написания.
>По нему я уверенно могу сказать "живой труп, никак не сваливающийся на обочину истории" (в осн. благодаря чудилам из M$).
Надеюсь, вы понимаете, что в рамках MS Office даже VBA (подмножество VB6) живее всех живых, хотя какие-то значительные инновации в нем появлялись более 20 лет назад?
> А вот WinFroms... очевидно, что она имеет серьёзные преимущества, чтобы вот так её голословно хоронить. Я потому и занялся декларациями ДЛЯ WINFORMS, т.к. сама технология вполне мощная, просто клоунам в MS "скучно" её улучшать.
Согласен, очень экономная технология по затратам времени на разработку несложных UI и потом ресурсов для запуска.
Windows раньше славилась очень экономичным потреблением ресурсов для GUI приложений. Более бедный UI на базе X11 отъедал в разы больше оперативки и поэтому в 90-ые использовался большей частью на дорогих рабочих станциях UNIX типа SGI, Sun, etc.. Windows 95 же работала на относительно доступных уже в то время персоналках X86 с 4-16 Mega (а НЕ гига, как сейчас) bytes оперативной памяти.
WinForms по сути своей — это ведь надстройка как раз над тем самым первозданным относительно лайтовым WinAPI, поэтому программы на WinForms не такие прожорливые к оперативке как WPF и другие более современные.
Мало того, WinForms можно запускать на Linux из под WINE, а значит и в OCI контейнерах, например в Docker или Kubernetes например с доступом по VNC (и с сайтиков noVNC), а значит можно обеспечить деплой, сравнимый с современными смузихлебными веб технологиями:
Здравствуйте, Kolesiki, Вы писали:
MD>>Ждём. Раньше и C#-код сам по себе был windows-only. А сейчас гляди-ка — NET Core работает на линуксах.
K>Жди. Только вот перенос WPF даже не в планах(!!!). Что говорит как о квалификации его архитекторов, так и "воплощателей". И вообще M$ уже не интересен WPF — они побежали вперёд со своими Кошмаринами, MAUI и прочей белибердой. Как только на этих бородатых школотронов кончатся деньги (и терпение), их погонят ссаной метлой пилить "мультиплатформ" на морозе.
А чем Avalonia хуже WPF кроме того, что для нее пока не делают массово компоненты гиганты отрасли компонентостроения типа DevExpress, Telerik, etc. ?
Т.е. контролы можно загнать в центр или правый край полоски независимо друг от друга (как listBox2 на картинке).
Тебя даже слушать не будут, ибо не круто.
Чего тут сверхсложного?
А самое ржачное, что бегали-бегали со своей декларативностью, а так нихрена от неё и не получили — так и осталось решение windows-only.
Это ж надо так залепёхать сайт, что нихрена найти невозможно!
