Здравствуйте, VladD2, Вы писали:
VD>Проблема в том, что под языком должна лежать какая-то реализация. ... И тут без использования чего-то вроде WPF-не обойтись.
Я понял мысль. Но библиотека как раз вторична, а вот потенциал, закладываемый в язык — нужен.
А по поводу WPF... мне кажется, это ещё одна страшная ошибка. Как идея — WPF превосходен (идея декларативного UI), но реализация была безбожно испорчена космическими микроархитекторами микрокомпании с микротанцорами, мать их за ногу! Поэтому я безо всяких сомнений сделал бы этот "Гуеязыг" поверх... WinForms! А почему бы и нет?
Декларации, стили, контролы — всё транслируются в обычный Win32 мир, который на порядок быстрее WPF, как бы нас ни убеждали в обратном продажные шлёндры микрософта.
Другими словами, мы можем сделать тот же WPF, но правильный, быстрый и на известных каждому школьнику ВинФормсах, где "создать новый контрол" — вопрос пяти строк, а не километровой простыни свойств, стилей и прочей шняги.
Здравствуйте, ionoy, Вы писали:
I>Один мой знакомый делает нечто похожее для C#
Проблема в том, что "шарпоГУЙ" своей идеей напрочь отрезает от процесса главных гуеделов — ДИЗАЙНЕРОВ! Если для WPF запилили хотя бы Blend, то что ты предоставишь для C#??
Теги способен выучить последний имбецил. Причём достаточно просто тега, остальное допилим ползунками в Property Editor. В цэшарпе ты уже ничего не допилишь.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, ionoy, Вы писали:
I>>Один мой знакомый делает нечто похожее для C#
K>Проблема в том, что "шарпоГУЙ" своей идеей напрочь отрезает от процесса главных гуеделов — ДИЗАЙНЕРОВ! Если для WPF запилили хотя бы Blend, то что ты предоставишь для C#?? K>Теги способен выучить последний имбецил. Причём достаточно просто тега, остальное допилим ползунками в Property Editor. В цэшарпе ты уже ничего не допилишь.
У нас в провинции гуй делается руками разрабов по макетам. Может это неправильно. Но так уж получилось.
Чем принципиально отличается древовидная структура списка в синтаксисе C# от xml?
Ничем кроме вида скобок. Плюс все возможности C# можно. Уже практически все это используют.
Например, .
еще Giraffe, Suave, WebSharper (если нужно увидеть как это C#).
Разметка в коде вероятно более гибка и менее подвержена болезням шаблонизаторов.
Конечно, дизайнер это хорошо, но он также становится зависимостью от которой трудно избавиться, т.к. генерится очень много доп кода. Или взять swing Jtable(java), там данные и метаданные(названия колонок) берутся из программной модели.
Ну а в лиспах типа кложи/скрипта уже давно и html и css пишут в коде на одном языке.
Это удобно и мощно. Как сложно например в разоре (асп нет) генерить по циклах да еще если условия нужны.
На чистом C# гораздо было бы проще.
Что-то много написал.
Здравствуйте, Kolesiki, Вы писали:
K>Я понял мысль. Но библиотека как раз вторична, а вот потенциал, закладываемый в язык — нужен.
Я то с тобой согласен. Проблема лившь в том, что людям не нужны абстрактные языки. Им нужно решать конекретные задачи. По сему ничего вторичного тут нет. Если выбрать мертвую либу в базу, то даже самый лучший ДСЛ не спасет такой проект.
K>А по поводу WPF... мне кажется, это ещё одна страшная ошибка. Как идея — WPF превосходен (идея декларативного UI), но реализация была безбожно испорчена космическими микроархитекторами микрокомпании с микротанцорами, мать их за ногу!
Опять же согласен. Более того МС сама как-то забила на WPF. WPF же сделан по верх Direct X и стало быть не особо переносим. Ну, а UWP, который предлагают в МС не кросплатформен даже в пределах винды. Нам вот надо поддерживать Win 7, а там UWP. Есть, правда, Xamarin но и у него куча пролбем.
K>Поэтому я безо всяких сомнений сделал бы этот "Гуеязыг" поверх... WinForms! А почему бы и нет?
Вот только людям не нужен WinForms. Он не переносим. Не достаточно расширябелен. А главное люди не считают его чем-то что имеет смысл выбирать.
K>Декларации, стили, контролы — всё транслируются в обычный Win32 мир, который на порядок быстрее WPF, как бы нас ни убеждали в обратном продажные шлёндры микрософта.
Да не фига он не быстрее. На сегодня и WPF довольно быстр, за счет 3D-акселлерации. И есть другие варианты. И вообще, скорость как-то перестала быть критерием для выбора библиотек. Ее достаточно даже в HTML-е.
K>Другими словами, мы можем сделать тот же WPF, но правильный, быстрый и на известных каждому школьнику ВинФормсах, где "создать новый контрол" — вопрос пяти строк, а не километровой простыни свойств, стилей и прочей шняги.
Ну, вот есть варианты. Возможно его лучше сделать на Blazor-е, например. При этом сразу убъется несколько зайцев. Ну, и это не должен быть XAML. Программирование в XML-е это звиздец какой идиотизм.
Сочетание переносимости, приемлемой скорости, хорошего строготипизированного ДСЛ-я, хорошей интеграции с ЯП вроде Nemerle/C#/F#, динамического превью как в AMMY и Live XAML, богатая библиотека дотнета, прозрачная интеграция с серверным кодом написанным на тех же языках, пакетная система nuget-а и может получиться отличное решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Ну, вот есть варианты. Возможно его лучше сделать на Blazor-е, например. При этом сразу убъется несколько зайцев. Ну, и это не должен быть XAML. Программирование в XML-е это звиздец какой идиотизм.
Здравствуйте, VladD2, Вы писали:
K>>Поэтому я безо всяких сомнений сделал бы этот "Гуеязыг" поверх... WinForms! А почему бы и нет?
VD>Вот только людям не нужен WinForms. Он не переносим.
ээ... вопрос колом: а ЗАЧЕМ его переносить?? Куда, в какой дивный мир ты хочешь выйти из Окон? Кругом венда. Линуксоиды застряли в своём гиковом мире. Макакось — вообще секта контуженых ябловеров. Ну... куда? Я не праздный вопрос вопрошаю, я за свои 25 лет в индустрии так и не видел ничего путного в идее "кросс-чего-нибудь". Ни ГУЙня никогда не была нормальной, ни целые платформы — все страдали синдромом павлиноуткоежа.
VD> Не достаточно расширябелен.
В каком смысле?? Наследуй контрол, да расширяй!
VD>А главное люди не считают его чем-то что имеет смысл выбирать.
Скажем так: это не совсем те люди, мнение которых я могу ценить. Кто писал реальные проги на WPF и WinForms *поклонился*, тот знает, насколько череззаборногузадерищенски работает WPF и насколько всё проще в мире WinForms. Чего б его не выбирать-то?? Или кто-то увидел, как кастомайзить кнопочку в WPF и всё, поплыла Катя? Даже кривая обучения у WPF — это какая-то жоццкая кубическая парабола, где на старте всё мягко, а потом уносимся в непостижимые разумом облака! На WinForms можно писать годами и никогда не перекрыть OnPaint. А надо — всегда можно прочитать ОДИН туториал и тут же(!) запилить свой контрол. Это к слову "расширябелен".
K>>Декларации, стили, контролы — всё транслируются в обычный Win32 мир, который на порядок быстрее WPF, как бы нас ни убеждали в обратном продажные шлёндры микрософта.
VD>Да не фига он не быстрее. На сегодня и WPF довольно быстр, за счет 3D-акселлерации.
Влад, это всё сказки, не верь им. Я даже ГЛАЗАМИ вижу, как WPF-ная гуета тормозит во многих приложениях. Причём было бы на чём: в одном месте тупо засосал 1000 записей из базы — и всё, СЕКУНДАМИ жду грид, пока покажет результат. Чо там ускоряет, говоришь, DirectX? А криворуких разрабов WPF там никто не ускоряет?
Вот хорошая статья, почему WPF говно тормозит — там чувак реально заморочился до самого нижнего уровня и показал, как неэффективно работает отрисовка. А мне лично даже без чувака достаточно моего человеческого ощущения, что приложения реагируют куда медленнее, чем должны. Про идиотию на базовом(!) уровне в виде Dep.Properties вообще молчу. Ты как инженер скажи: если на машину повесить полутонные колёса, она быстрее поедет?
VD> И вообще, скорость как-то перестала быть критерием для выбора библиотек.
Ну да. Если бы ВСЕ библиотеки отрисовывали сложный экран за <= 1 мкс. Пока что этого не наблюдаю. А ты не представляешь, насколько раздражают задержки именно в ГУЯх! Ты можешь делать самый крутой UI, но если я больше полсекунды жду реакции — к чёрту такой "тырфейс", лучше запилите простую консоль.
VD>Ну, вот есть варианты. Возможно его лучше сделать на Blazor
Ну так это же в итоге HTML! Накой мне этот протухший монстр с кучей ограничений и костылей? Только потому, что его могут посмотреть задроты со смартфона? Так мобильный ИТ — это вообще другой мир с другими правилами.
VD> Ну, и это не должен быть XAML. Программирование в XML-е это звиздец какой идиотизм.
Согласен, не самый удобный язык. Но пока нет лучшего, ДАЖЕ ЕГО я готов терпеть — пока что он наиболее близкий к декларативным гуям. Но чтобы транслировать всё в WinForms.
Проблема в том, что для юных подаванов любая технология старше 5 лет кажется каким-то атавизмом — ещё б, они привыкли JS-фрэймворки каждую неделю менять! Как им объяснить, что чем дольше лет — тем больше стабильность самой либы и тем больше САМО ВРЕМЯ доказывает, что либа ещё не исчерпала себя?
Я согласен, что "неуклюжих" моментов в WinForms хватает, но никто не мешает их улучшить! Вплоть до переписывания комбобокса. Факт тот, что результат будет быстрый и главное — СОПРОВОЖДАЕМЫЙ. Никому не нужен "театр одного актёра", людям нужен код, который можно взять и уже через час расширять его во всю ширь.
Я вот только с декларативностью немного не в ладах — на .NET GUI напишу почему.
K>Я согласен, что "неуклюжих" моментов в WinForms хватает, но никто не мешает их улучшить! Вплоть до переписывания комбобокса.
Если тебе надо переписывать такой базовый компонент, как комбобокс, чтобы убрать «неуклюжий момент», то все, можно закапывать
K>Факт тот, что результат будет быстрый и главное — СОПРОВОЖДАЕМЫЙ.
Ты просто очень плохо представляешь, сколько усилий надо потратить на создание — да — того же комбобокса, чтобы он был и быстрым и сопровождаемым и с правильным поведением.
K>>Я согласен, что "неуклюжих" моментов в WinForms хватает, но никто не мешает их улучшить! Вплоть до переписывания комбобокса.
M>Если тебе надо переписывать такой базовый компонент, как комбобокс, чтобы убрать «неуклюжий момент», то все, можно закапывать
Закапывать ЧТО?
Моя идея проста: можно иметь декларативно описанный ГУЙ, который мэпится на уже существующий WinForms. И если типичная кастомизация контрола (из WinForms) не поддерживается, значит переписать контрол с правильной внутренней структурой. Что в этом такого? Да, поначалу сложно, ну так и задача — фундаментальная! До сих пор на рынке даже близко не было тех ГУЁв, которые были бы адекватным, простым решением.
K>>Факт тот, что результат будет быстрый и главное — СОПРОВОЖДАЕМЫЙ.
M>Ты просто очень плохо представляешь, сколько усилий надо потратить на создание — да — того же комбобокса, чтобы он был и быстрым и сопровождаемым и с правильным поведением.
Я-то писал, я представляю. Да, МНОГО. Но это если сразу обозреть ВСЮ функциональность. Которая, очевидно, не всем и не сразу нужна. И делается в режиме дописывания. Главное — заложить гибкую основу.
M>Алсо. GUI-фреймворки умерли, как класс.
K>>>Я согласен, что "неуклюжих" моментов в WinForms хватает, но никто не мешает их улучшить! Вплоть до переписывания комбобокса. M>>Если тебе надо переписывать такой базовый компонент, как комбобокс, чтобы убрать «неуклюжий момент», то все, можно закапывать
K>Закапывать ЧТО?
Закапывать проект, в котором нет нормального комбобокса
K>Моя идея проста: можно иметь декларативно описанный ГУЙ, который мэпится на уже существующий WinForms. И если типичная кастомизация контрола (из WinForms) не поддерживается, значит переписать контрол с правильной внутренней структурой. Что в этом такого? Да, поначалу сложно, ну так и задача — фундаментальная! До сих пор на рынке даже близко не было тех ГУЁв, которые были бы адекватным, простым решением.
Потому что GUI никогда не является простым решением. В частности именно потому, что правильные компоненты писать очень сложно
M>>Ты просто очень плохо представляешь, сколько усилий надо потратить на создание — да — того же комбобокса, чтобы он был и быстрым и сопровождаемым и с правильным поведением.
K>Я-то писал, я представляю. Да, МНОГО. Но это если сразу обозреть ВСЮ функциональность. Которая, очевидно, не всем и не сразу нужна. И делается в режиме дописывания. Главное — заложить гибкую основу.
Угу. «Делается в режиме дописывания». Не делается. Этому надо реально посвятить разработку, а не «в режиме дописывания».
M>>Алсо. GUI-фреймворки умерли, как класс.
K>Можно развернуть мысль?
Их не осталось. Кроме полутора, что разрабатываются уже тридцать лет (например, Qt) или поставляются с самой ОСЬю (например, в МакОСи). Все остальное по разным причинам вымерло: с одной стороны разработка невероятно сложная, дорогая и долгая. С другой — все деньги в мобильных приложениях.
Здравствуйте, Mamut, Вы писали:
M>Закапывать проект, в котором нет нормального комбобокса
Ну так ни у кого его нет! А гуйню тогда делать на чём??
K>>Я-то писал, я представляю. Да, МНОГО. Но это если сразу обозреть ВСЮ функциональность. Которая, очевидно, не всем и не сразу нужна. И делается в режиме дописывания. Главное — заложить гибкую основу.
M>Угу. «Делается в режиме дописывания». Не делается. Этому надо реально посвятить разработку, а не «в режиме дописывания».
Ты не так понимаешь мысль. ГУЙ — в нём есть принципы построения. Вот как у WPF: "невизуальный контрол" + стили. Если заложить правильные и гибкие принципы, удобные примитивы, то вся остальная либа делается "в режиме дописывания", т.е. база у нас есть, а отсутствующие контролы легко дописываются по мере надобности.
M>Их не осталось. Кроме полутора, что разрабатываются уже тридцать лет (например, Qt) или поставляются с самой ОСЬю (например, в МакОСи). Все остальное по разным причинам вымерло: с одной стороны разработка невероятно сложная, дорогая и долгая. С другой — все деньги в мобильных приложениях.
WPF — жив. Даже WinForms живее всех живых! Кто умер-то?? Не слишком громкие высказывания, мистер Эпатаж?
Разработка — не особо сложная, все трудности — они на этапе проектирования и написания базовой модели.
К слову, вот этот симпатичный ГУЙ https://github.com/buggins/dlangui поначалу делался вообще одним челом, причём когда проект был представлен, он уже содержал больше десятка контролов. Задача — вполне подъёмная, особенно когда есть единомышленники. А вот это тухлое Qt и ко — даром не нужно.