Ребят, в качестве хобби запилил проект — новые лэйауты для 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>Ребят, в качестве хобби запилил проект — новые лэйауты для 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-экосистема, не тратьте нервы на моё поделие"
Я не отгораживаюсь от критиков, но мне в хрен не упёрлись "амбассадоры %ОчереднаяХренотеньКоторойОниПользуются%". Если в МОЁМ решении ты видишь какую-то проблему — напиши, я с радостью рассмотрю — это ведь только черновик, многое может поменяться. А просто "я сижу в ВПФ и мне кайф" — ну такая себе помощь... от вил на воде больше толку.
Здравствуйте, 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
}
};
}
Здравствуйте, 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.
Тем более что на дотнете это принципиально решаемо