S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
WPF (как технология) монструозен. Код пишется дольше, ресурсов ПК требует больше.
Но если нужно красиво или нестандартно — то только он.
У нас, в финансовой сфере, сам факт дотнета — это модно и круто, тк остальное совсем древнее.
Когда встал вопрос WPF или WinForms, то написали две версии приложения, а пользователи выбрали WinForms версию как более быструю. После того, как руководство сравнило фактические сроки реализации, вопрос отпал сам собой.
Здравствуйте, D.Lans, Вы писали:
DL>Не далее чем этой весной написал на WinForms утилитку из двух форм для соседнего отдела. Небеса не разверзлись, наказания не последовало, коллеги довольны.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Главная попа WinForms как раз и состоит в том, что оно крайне плохо поддается реюзу.
Главная попа в том, что говоря WinForms подразумевают лапша-стайл. Пиши на WPF драг-дропом контролов с тулбокса в окно, и получишь ровно то-же самое.
А получилось это потому что для WPF майкрософт пропагандировала и насаждала MVVM. В подавляющем большинстве туториалов для начинающих использовали правильные подходы. Плюс отдельные статьи по разработке в стиле MVVM имено на WPF. Я вот уверен, что будь такое же количество материалов WinForms + MVP, речь о недостатках WinForms в разрезе реюза звучала бы не слышным шопотом.
Так что я бы сказал, что это не WinForms плохо поддается реюзу, а на WinForms так пишут.
НС>WPF же долго запрягает, но потом на отлаженном фреймворке сотни окон пекутся как горячие пирожки.
Тут нет преимуществ WPF. Это преимущества MVVM. Пиши на WinForms + MVVM или, что лучше, WinForms + MVP и получишь ровно тоже самое.
НС>Для винформсов такое или вообще недоступно, либо доступно жестким потом и кровью с сомнительной надежности результатом.
Доступно-доступно. И результат надежней получится: строго типизированный, compile-time верифицируемый и без рантайм-рефлексии для биндингов — о таком WPF может только мечтать. А цена такого счастья не так уж и велика — MVP.
Единственное в чем WinForms откровенно сливает — система лейаутов. Вот в этом настоящий ад и израиль WinForms.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Стандартная тема WPF максимально имитирует родной стиль той ОС, на которой он запущен. Причем на разных ОС он разный. Никакой разницы в этом плане от винформсов нет.
Поплывший мутный шрифт и мыло на границе контролов — это действительно максимумум? Если мутность еще можно относительно просто заправить, то на все остальное нет времени — одно только убитое выравнивание в меню чего стоит.
WPF тема по-умолчанию очень сырая, и явно была сделана для галочки слепым разработчиком. Это длится не первый год. К сожалению, никаких улучшений нет. Вместо этого Сатья Надела предпочитает ездить по ушам, выплывая на инерции прошлых лет.
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
S>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится.
S>Или трупа лучше не ворошить?
Здравствуйте, Ночной Смотрящий, Вы писали:
_R_>>Копипаст в шаблонах, включая необходимость копипаста стандартных шаблонов для плевого изменения. НС>Ты там что то писал про спагетти-стайл?
Кажется ты удивишься, но я только про него и пишу.
_R_>>Я знаю про шаблоны WPF. Я не знаю как изменение внешнего вида контрола при сохранении его поведения способствует убиранию рутины. НС>Я там Data Templates упоминал. Не заметил?
Заметил. Заметил, что не мне. А еще я заметил, что ты не заметил мою фразу про то, что заплаток не будет, а будет по другому.
_R_>>Банальное прямое присваивание. НС>Т.е. ручками. Ну вот ты и сам все продемонстрировал.
Паттерно-дрочер?
_R_>>Я действительно не вижу как. НС>Верю.
Плюсуем снисходительность?
_R_>> И ответ "ещё как" ничего не проясняет, кроме твоей крутости или надменности. НС>Ну да, чужой код спагетти стайл ты обзываешь, а крутость и надменность у меня.
Если и было, то не намеренно. А на вопрос ты так и не ответил.
_R_>>Тем что мой. НС>Все, в общем, уже понятно.
Аналогично.
_R_>>А в WPF нормальная? НС>Да.
Это замечательно, но не показывает как WPF убирает рутину.
-----
А вот на главное то ты и не ответил:
НС>>при грамотном подходе, пишутся существенно проще. Иногда трудозатраты отличаются на порядок. _R_>Так расскажи про этот подход! Расскажи в чем ущербость WinForms, что им не доступен этот подход.
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
Я бы говно под названием "WPF" иначе как длинной палкой трогать бы не стал.
Здравствуйте, Gattaka, Вы писали:
G>WPF по скорости быстрее, т.к. использует видеокарту напрямую.
Эти сказки надо оставлять в том же рекламном мусоре, где ты их нашёл. Все тырнеты воют "wpf тормозит", зачем говорить откровенную ахинею??
G> По качеству кода выше не то что на две головы, а на порядок.
Качество кода? Так говоришь, будто сам понимаешь, что сказал. Достаточно знать, что WPF — overengineered кусок индусячей мысли, какое "качество" ты там нашёл?
Одни "гении" решили, что "всё есть объект" и придумали однородный, но тормозной Смоллток. Благополучно помер и труп насилуют в академических средах.
В M$ решили, что можно проперти обвешать своими хитрозадуманными dependency — чай, производительности дофига! Этот бред пронизал практически всю библиотеку, так что WPF — это не просто монстр, а тормознутый монстр — очевидный труп даже при вливании миллионов. Тот, кто хоронит WinForms, ещё пороха не нюхал и дальше стилизации кнопок в WPF не заглядывал. Это звучит дико, но здесь именно тот случай, когда отец переживёт дитя.
Здравствуйте, namespace, Вы писали:
N>Когда встал вопрос WPF или WinForms, то написали две версии приложения, а пользователи выбрали WinForms версию как более быструю. После того, как руководство сравнило фактические сроки реализации, вопрос отпал сам собой.
Глупо сравнивать сроки реализации на демопроекте, да еще на новой для команды технологии.
Главная попа WinForms как раз и состоит в том, что оно крайне плохо поддается реюзу. WPF же долго запрягает, но потом на отлаженном фреймворке сотни окон пекутся как горячие пирожки. Для винформсов такое или вообще недоступно, либо доступно жестким потом и кровью с сомнительной надежности результатом.
Здравствуйте, Shmj, Вы писали:
S>Не, тут вы перебарщиваете. Пока нет замены от MS -- говорить о кончине рано. О замене сейчас и речь не идет.
Не слушай этого товарища. Он уже лет 10 вещает о конце WPF
Здравствуйте, koandrew, Вы писали:
НС>>И того что сервелат уже официально мертв со всеми вытекающими. K>Ты на вопрос-то ответь.
Я ответил. Что непонятного то? Или ты думаешь что на нем кто то сейчас новые проекты начинает?
НС>>Я вроде уже все на пальцах объяснил. Нет записей в блоге — в команде 1.5 человека — K>Дык сколько-сколько человек в команде WPF? В реальной жизни? Только подумай головой, а не транслируй тут бред про бложики.
Бред тут ты транслируешь, потому что не знаком с тем что происходит внутри МС. Все, финита ля комедия, все хорошие разработчики оттуда свалили в более перспективные направения. Осталось только небольшое количество индусов на поддержке.
Ты, конечно, может мечтать о том, что там какая то суперкоманда сидит и уже много лет тихо пилит новый мегарелиз, но по правдоподобности это очень недалеко от сказок Толкиена будет.
НС>>серьезные проблемы фикситься не будут, нового функционала можно не ждать. K>Серьёзных проблем у него нету,
Серьезные проблемы у него есть, даже в этом топике несколько упомянули.
K> новый функционал не нужен
Здравствуйте, Gattaka, Вы писали: G>Здравствуйте, Shmj, Вы писали: S>>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP? S>>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится. S>>Или трупа лучше не ворошить? G>WPF по скорости быстрее, т.к. использует видеокарту напрямую.
Ну во-первых, WPF не использует видеокарту напрямую.
Оно использует то, рендерер, который частенько выбирается по каким-то странным критериям, а не видеокарту. При этом значительная часть всё-равно почему-то рендерится софтверно.
Во-вторых, кроме непосредственно рендера в процессе формирования картинки учавствует ещё WIC, который за каким-то хреном заюзали для масштабирования битмапов, хотя старые способы были вполне годными и превосходно оптимизированными. А он работает как ему заблагорассудится. Это ты просто с Windows Core не сталкивался. Кстати, похоже что именно для него — чисто маркетинговые цели.
В-третьих, кроме масштабирования битмапов и рендерера в процессе формирования изображения учавствуют Layout Engine, и WPF'ная маршрутизация событий, которая невероятно тормозная. Ясен пень, что здесь я о сложном и большом UI говорю.
В-четвёртых, WPF существенно замедляет старт софтины из-за компиляции BAML'а, что особенно заметно, если у тебя нет SSD. Там же он отжирает нереальное кол-во оперативы. G> По качеству кода выше не то что на две головы, а на порядок.
По качеству чьего кода кто выше?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
S>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится.
S>Или трупа лучше не ворошить?
Не далее чем этой весной написал на WinForms утилитку из двух форм для соседнего отдела. Небеса не разверзлись, наказания не последовало, коллеги довольны.
18.06.17 00:34: НС>Главная попа WinForms как раз и состоит в том, что оно крайне плохо поддается реюзу. WPF же долго запрягает, но потом на отлаженном фреймворке сотни окон пекутся как горячие пирожки. Для винформсов такое или вообще недоступно, либо доступно жестким потом и кровью с сомнительной надежности результатом.
18.06.17 23:27: _R_>>Продолжи, пожалуйста, фразу: "На WinForms печь формы как горячии пирожки мешает...". НС>Ничего не мешает.
НС>Берут люди и хреначат руками тучу форм. Мышой туда, мышой сюда.
Демагогия. Человеческий фактор в разговоре о технических возможностях фреймворков.
Здравствуйте, _Raz_, Вы писали:
_R_>Отчего же не поверю? Очень даже поверю. И конкретизирую — это заслуга MVVM. Что мешает в ВинФормсах использовать MVVM? Отсутствие конвертеров и форматтеров из коробки? _R_>Только вот все равно я не увидел как биндинг влияет на композицию UI.
Мне кажется, вы решили поиграть в игру "А что, неужто так сложно написать пол-WPF самостоятельно, с нуля и без ошибок?".
Здравствуйте, Mr.Delphist, Вы писали:
_R_>>А на WPF как биндинг помогает композиции UI? MD>Вы не поверите — соединение презентации с данными получается очень гибкое
И не только простое соединение, возможности там очень гибкие. Совместно с Control Template и Data Template можно весь UI строить по данным штатными средствами, без моря рукописного кода. Попытка подобный подход воспроизвести в винформсах — ну разве что ради поржать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И того что сервелат уже официально мертв со всеми вытекающими.
Ты на вопрос-то ответь.
НС>Я вроде уже все на пальцах объяснил. Нет записей в блоге — в команде 1.5 человека —
Дык сколько-сколько человек в команде WPF? В реальной жизни? Только подумай головой, а не транслируй тут бред про бложики. НС>серьезные проблемы фикситься не будут, нового функционала можно не ждать.
Серьёзных проблем у него нету, новый функционал не нужен. Всё есть и так. Потому любителям бложиков тут ловить нечего. Move on.
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
S>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится.
S>Или трупа лучше не ворошить?
Можно и на WinForms, если не нужна локализация и вы плевать с высокой колокольни хотели на 14" ноуты с FullHD на экране — вперёд, это ваш выбор. А вообще, WinForms — технология в целом годная, и проверенная временем.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, s_aa, Вы писали:
_>>Ничего смешного, таких мелких задач пруд пруди и смысл огород городить с WPF? K>Вот мне интересно — о каком огороде идёт речь? Я его использую даже для примитивнейших proof-of-concept проектов с двумя кнопками "Do Thing #1" и "Do Thing #2". Никакого инфраструктурного кода там не требуется, MV инстанциируется прямо WPF в XAML.
Добавлю, что Самсунг для своего Tizen выбрал Xamarin.Forms которые на XAML и скоро выйдет XAML Standard.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)?
Пиши без сомнений, если единственная цель именно утилиту написать, а не побаловаться с WFP или с чем еще. Никаких недостатков с утилитарной сторону у WinForms по сравнению с WFP нет.
S>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится.
Небольшой утилите для бухгалтерии (5-7 разных форм) ? Сомнения мера берут.
Здравствуйте, pagid, Вы писали:
S>>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? P>Пиши без сомнений, если единственная цель именно утилиту написать, а не побаловаться с WFP или с чем еще. Никаких недостатков с утилитарной сторону у WinForms по сравнению с WFP нет.
Я уже набаловался с WPF, мне на нем даже проще писать.
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
S>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится.
S>Или трупа лучше не ворошить?
Дам наводку . Про Slack слышали? Про Visual Studio, что оно и под линуксом тоже работает слышали?
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
Писал и на Windows Forms, и на WPF. Большой недостаток WPF — у него очень плохая стандартная тема, и приходится делать свою. Когда выходит новая версия ОС эта самодельная тема не всегда выглядит адекватно и снова приходится ее патчить. Потом смотришь как выглядит для пользователей на более старых ОС — и слеза падает от ужаса. Т.е. трудозатраты огромные. У WPF есть только два бонуса: хороший движок анимации и меньше проблем с разным DPI.
Поэтому сейчас пишем преимущественно на Windows Forms, но там где надо (анимация, предметная визуализация, сильно кастомная визуальная сцена), вставляем WPF элементы. В такой комбинации получается очень хорошо.
Т.е. со временем стало понятно что WPF это как JavaFX, и если выходить за эти границы — он не особо годится, слишком много неокупаемой бесмысленной возни с тем что должно на самом деле занимать 10 секунд рабочего времени и идти из коробки.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Включая. Проблема не в нем, а в архитектуре винформсов и железных оковах user32.dll.
О как! То есть по сути претензии не к WinForms, а к виндовой подсистеме контролов?
НС>[...] Шаблончики накидал базовые, а форма сама из них собралась.
На WinForms то что мешает сделать подобное?
НС>На винформсах же, даже если ты выпрыгнешь из штанов и полностью перепишешь штатный убогий биндинг,
А нафига? Штатный биндинг действительно убог, но ведь никто не заставляет его использовать.
НС> возможностей по композиции UI у тебя все равно не добавится.
А на WPF как биндинг помогает композиции UI?
НС>Все те же юзерконтролы
С ними что не так?
НС>и убогие и кривые лейауты.
Что есть, то есть.
НС>Попытки выпрыгнуть из штанов я тоже наблюдал неоднократно.
И, видимо, ни одной успешной?
_R_>>Получив личный негативный опыт НС>Можно узнать а какой ты получил опыт? Неличный?
Личный. И не только. Допустим в этой теме несколько сообщений с успехом использования ВинФормсов.
_R_>>2. Что-то мешает иметь на ВинФормсах "типичный уровень автоматизации WPF". НС>Куча всего, я выше кое что упомянул.
Выше ты показал, что у WPF и WinForms есть функциональные различия, но не показал как это влияет на рутинные операции.
НС> Что то можно решить заплатками, а что то — нет.
Это не заплатки. Это просто по другому. Никто на ВинФормсах не имитирует подсистему шаблонов.
НС>Нормальную поддержку HighDPI, к примеру, ты туда уже точно не добавишь.
Здравствуйте, Слава, Вы писали:
С>Мне кажется, вы решили поиграть в игру "А что, неужто так сложно написать пол-WPF самостоятельно, с нуля и без ошибок?".
Если б только это. user32 то тоже никуда не девается, и полет фантазии быстро обрывает. А если выдрать из Control этот самый user32, то это уже и не винформсы будут. А главное — нафига, если проще и дешевле взять WPF?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Напомнить судьбу Silverlight?
И что с ней случилось?
НС>Это не бложик евангелистов, это бложек команды, занимающейся WPF. Если туда никто не пишет — дело тухлое.
У моей команды вот почему-то нету бложика... Намёк понятен?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А тоже кучу народа не нем новые проекты начинало.
И чего? Эти проекты перестали работать?
НС>Нет. В твоей конторе, в отличие от МС, нет политики, прямо заставляющей вести такие бложики команды разработки.
Всё равно не понятна связь. Нет блогов == проекты на нём внезапно поломаются?
Здравствуйте, koandrew, Вы писали:
НС>>А тоже кучу народа не нем новые проекты начинало. K>И чего? Эти проекты перестали работать?
И того что сервелат уже официально мертв со всеми вытекающими.
НС>>Нет. В твоей конторе, в отличие от МС, нет политики, прямо заставляющей вести такие бложики команды разработки. K>Всё равно не понятна связь. Нет блогов == проекты на нём внезапно поломаются?
Я вроде уже все на пальцах объяснил. Нет записей в блоге — в команде 1.5 человека — серьезные проблемы фикситься не будут, нового функционала можно не ждать.
Здравствуйте, sr_dev, Вы писали:
_>Вроде электрон тоже натив, я про него. как то я спрашивал, мне ответили что sciter это не хромиум. html5/css3/js полноценно работает?
Sciter — это свой диалект HTML, с расширениями специально для разработки приложений и работает намного быстрее Хрома. Писать под него тоже приятнее.
Минус в том, что итоговый код будет работать только под Sciter. Сделать вариант чисто для web малой кровью не получится.
Здравствуйте, Serginio1, Вы писали:
S> Но с выходом .NetStandard 2, возможности UWP приблизятся к старшему .Net. Но будет выполняться в своем контейнере.
Несколько лет назад Симантек рассматривал использование UWP — отказались, слишком суровый тот контейнер оказался для их use cases.
Но к слову это понятно, антивирусу, как раз доступ к системе нужен чуть более чем полный. Т.е. по хорошему им бы пришлось клиент-сервер городить.
Им дешевле встало мне заплатить за Direct2D backend для Sciter.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, koandrew, Вы писали:
K>>Так вот — в "Тойоте" ВСЕ новые десктопные проекты пишутся на WPF (по крайней мере в северо-американской её части, хз, как там в остальных), плюс контракты в новые проекты на WPF тоже приходят мне регулярно. C>У меня друг пишет новые приложения на MFC. Тоже для автомобилистов, кстати.
А у меня не скажу (пока) какой клиент пишет бортовой UI на sciter.
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Serginio1, Вы писали:
S>> Но будет выполняться в своем контейнере.
A>И поэтому умрет не родившись.
Ошибаешься. Он как раз будет использоваться для кучи устройств.Win 10, XBOX, WinMO, Холонез, Учитывая XAML Standard по сути и в андроиде и а яблоке.
Уже сейчас можно писать единое приложение на XAML для всех платформ
и солнце б утром не вставало, когда бы не было меня
Одно время переходил на WPF, написал с десяток небольших приложений. Но потом стало лень, усилий гораздо больше, красоты во внутрикорпоративных прогах все равно никто не оценит — важен функционал.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, _Raz_, Вы писали:
НС>>Главная попа WinForms как раз и состоит в том, что оно крайне плохо поддается реюзу. _R_>Главная попа в том, что говоря WinForms подразумевают лапша-стайл.
Это следствие.
_R_> Я вот уверен, что будь такое же количество материалов WinForms + MVP, речь о недостатках WinForms в разрезе реюза звучала бы не слышным шопотом.
А я вот, накушавшись попыток хоть как то уменьшить количество рутины в винформсе, уверен в обратном. Типичный уровень автоматизации WPF для винформса недостижим никогда, хоть ты туда десять MVVM и других модных слов навешай.
Здравствуйте, c-smile, Вы писали:
CS>WPF так и не состоялась как UI layer системных и образующих приложений Windows. Т.е. велика вероятность что это будет abandon-ware очередной. CS>Или у тебя другие данные?
А какие вы имеете в виду под "системных и образующих приложений Windows"?
У меня под такое определение попадают:
UI настроек. Он в принципе весь или подавляющей частью — нативный. Т.е. там нет ни WPF, ни WinForms
UI стандартных приложений (типа Paint и WordPad) — аналогично, они почти все разработаны в незапамятные времена, и поголовно нативные. Зачем там .Net?
Административные утилиты и вспомогательные приложения. А вот тут уже всё неоднозначно. Я вот сейчас ради интереса открыл Windows\System32 и начал смотреть, какие из приложений, что там лежат, являются managed и сколько из них WinForms, а сколько WPF. Получилось вот так:
WinForms : 3 приложения и несколько dll (судя по названиям — это для mmc оснастки)
WPF: два достаточно крупных приложения — Server Manager и Active Directory Administrative Center + около 10-ка утилит поменьше.
Вот честно, я не вижу здесь никакого преимущества WinForms.
Здравствуйте, c-smile, Вы писали:
G>>Про Visual Studio, что оно и под линуксом тоже работает слышали? CS>Ты часом с Microsoft Visual Code не попутал ли?
Под Linux сейчас две разных Visual Studio доступно. VS Code это только одна из них
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, c-smile, Вы писали:
G>>>Про Visual Studio, что оно и под линуксом тоже работает слышали? CS>>Ты часом с Microsoft Visual Code не попутал ли?
TK>Под Linux сейчас две разных Visual Studio доступно. VS Code это только одна из них
Ну да, на электроне Code как раз. Но я думаю мысль понятна.
Здравствуйте, Михаил Романов, Вы писали:
МР>А какие вы имеете в виду под "системных и образующих приложений Windows"?
"Системные" это те что идут с дистрибутивом consumer versions of Windows. В Windows 10 Pro я таких приложений не наблюдаю. Возможно что я не так и не там смотрю.
"Образующие" это те что образуют Windows как [привлекательную для пользователей] платформу. Например Microsoft Office и пр.
МР>WPF: два достаточно крупных приложения — Server Manager и Active Directory Administrative Center + около 10-ка утилит поменьше.
Это что-то из опциональных downloadable приложений как я понимаю для серверов, правильно?
Даже если они и на WPF то я не вижу почему они должны быть именно на WPF:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это следствие.
Отлично! Значит допустимо перефразировать: "Для лапша-стайл такое или вообще недоступно, либо доступно жестким потом и кровью с сомнительной надежности результатом.".
НС>А я вот, накушавшись попыток хоть как то уменьшить количество рутины в винформсе, уверен в обратном.
Здравствуйте, _Raz_, Вы писали:
НС>>Это следствие. _R_>Отлично! Значит допустимо перефразировать: "Для лапша-стайл такое или вообще недоступно, либо доступно жестким потом и кровью с сомнительной надежности результатом.".
Для любого стайл.
НС>>А я вот, накушавшись попыток хоть как то уменьшить количество рутины в винформсе, уверен в обратном. _R_>"Ну показатель, чо." (c)
Для кого как.
НС>>Типичный уровень автоматизации WPF для винформса недостижим никогда, хоть ты туда десять MVVM и других модных слов навешай. _R_>Продолжи, пожалуйста, фразу: "На WinForms печь формы как горячии пирожки мешает...".
Ничего не мешает. Берут люди и хреначат руками тучу форм. Мышой туда, мышой сюда.
Здравствуйте, Aquilaware, Вы писали:
A>Писал и на Windows Forms, и на WPF. Большой недостаток WPF — у него очень плохая стандартная тема
Стандартная тема WPF максимально имитирует родной стиль той ОС, на которой он запущен. Причем на разных ОС он разный. Никакой разницы в этом плане от винформсов нет.
Здравствуйте, _Raz_, Вы писали:
НС>>Для любого стайл. _R_>Включая MVVM?
Включая. Проблема не в нем, а в архитектуре винформсов и железных оковах user32.dll.
НС>>Ничего не мешает. Берут люди и хреначат руками тучу форм. Мышой туда, мышой сюда. _R_>А на WPF у них мышу отбирают.
А на WPF многое можно вообще не писать. Иногда — почти все. Шаблончики накидал базовые, а форма сама из них собралась. На винформсах же, даже если ты выпрыгнешь из штанов и полностью перепишешь штатный убогий биндинг, возможностей по композиции UI у тебя все равно не добавится. Все те же юзерконтролы и убогие и кривые лейауты.
Попытки выпрыгнуть из штанов я тоже наблюдал неоднократно. Например в DevExpress. Печальное зрелище.
_R_>Получив личный негативный опыт
Можно узнать а какой ты получил опыт? Неличный?
_R_>1. Что хреначить руками тучу форм можно только на ВинФормсах.
Я такого не говорил.
_R_>2. Что-то мешает иметь на ВинФормсах "типичный уровень автоматизации WPF".
Куча всего, я выше кое что упомянул. Что то можно решить заплатками, а что то — нет. Нормальную поддержку HighDPI, к примеру, ты туда уже точно не добавишь.
Здравствуйте, _Raz_, Вы писали:
_R_>А на WPF как биндинг помогает композиции UI?
Вы не поверите — соединение презентации с данными получается очень гибкое, с минимумом рутинных телодвижений. Конвертер — пожалуйста, форматтер — пожалуйста, поведение контрола нестандартное исходя из входных данных — пожалуйста, вёрстка как в вебе — пожалуйста. И всё это можно реюзать практически как CSS в вебе.
Здравствуйте, Mr.Delphist, Вы писали:
_R_>>А на WPF как биндинг помогает композиции UI? MD>Вы не поверите — соединение презентации с данными получается очень гибкое, с минимумом рутинных телодвижений. Конвертер — пожалуйста, форматтер — пожалуйста, поведение контрола нестандартное исходя из входных данных — пожалуйста, вёрстка как в вебе — пожалуйста. И всё это можно реюзать практически как CSS в вебе.
Отчего же не поверю? Очень даже поверю. И конкретизирую — это заслуга MVVM. Что мешает в ВинФормсах использовать MVVM? Отсутствие конвертеров и форматтеров из коробки?
Только вот все равно я не увидел как биндинг влияет на композицию UI.
Здравствуйте, Слава, Вы писали:
С>Мне кажется, вы решили поиграть в игру "А что, неужто так сложно написать пол-WPF самостоятельно, с нуля и без ошибок?".
Нет игра называется "А давайте не забывать, что ВинФормс это не только спагетти-код". И мое сообщение
Здравствуйте, _Raz_, Вы писали:
НС>>Включая. Проблема не в нем, а в архитектуре винформсов и железных оковах user32.dll. _R_>О как! То есть по сути претензии не к WinForms, а к виндовой подсистеме контролов?
А одно от другого не отделимо, оно построено по единым принципам.
НС>>[...] Шаблончики накидал базовые, а форма сама из них собралась. _R_>На WinForms то что мешает сделать подобное?
Придется писать море нетривиального и плохо поддерживаемого кода. А на WPF зачастую вообще ничего писать не надо, штатные контролы, биндинг и движок лейаута сами справляются.
НС>>На винформсах же, даже если ты выпрыгнешь из штанов и полностью перепишешь штатный убогий биндинг, _R_>А нафига? Штатный биндинг действительно убог, но ведь никто не заставляет его использовать.
А что вместо него? Ручками твой вожделенный MVVM протаптывать в каждой форме?
НС>> возможностей по композиции UI у тебя все равно не добавится. _R_>А на WPF как биндинг помогает композиции UI?
Интересные вопросы ты задаешь. Еще как помогает.
НС>>Все те же юзерконтролы _R_>С ними что не так?
Слишком негибкие.
_R_>>>Получив личный негативный опыт НС>>Можно узнать а какой ты получил опыт? Неличный? _R_>Личный.
Так и чем твой лучше моего?
_R_> И не только. Допустим в этой теме несколько сообщений с успехом использования ВинФормсов.
Понятие успеха у каждого свое. Речь не про то, что на одном можно, а на другом нет. Речь про то, что типовые приложения с большим количеством форм на WPF, при грамотном подходе, пишутся существенно проще. Иногда трудозатраты отличаются на порядок.
Но learning curve у WPF, конечно, жесткая.
НС>> Что то можно решить заплатками, а что то — нет. _R_>Это не заплатки. Это просто по другому. Никто на ВинФормсах не имитирует подсистему шаблонов.
И что взамен? Ручное выписывание генераторов форм с ручным рассчетом размеров и координат? А если HighDPI?
НС>>Нормальную поддержку HighDPI, к примеру, ты туда уже точно не добавишь. _R_>Не я, а производитель. И, таки, добавляет.
А, ну если в винформсах, по твоему, нормальная поддержка масштабирования, то дальше разговаривать бессмысленно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Придется писать море нетривиального и плохо поддерживаемого кода. НС>А на WPF зачастую вообще ничего писать не надо, штатные контролы,
Копипаст в шаблонах, включая необходимость копипаста стандартных шаблонов для плевого изменения. Это хорошо поддерживаемый код? Или копипаст убирает рутину?
НС>биндинг
Глотающий ошибки. Ну не плохо. Код же тривиальный. Да и INotifyPropertyChanged убирает рутину.
НС>и движок лейаута
WPF win
НС>сами справляются.
Вот опять голословные утверждения о "море нетривиального и плохо поддерживаемого кода". Опять голое сравнение фунционала. Где фразы по шаблону "Такой-то функционал WPF легко и быстро позволяет напечь много форм тем что [...], что в сравнении с WinForms дает нам отсутствие рутины и/или качество кода".
Я знаю про шаблоны WPF. Я не знаю как изменение внешнего вида контрола при сохранении его поведения способствует убиранию рутины. При этом я знаю, что шаблон повторяется одним презентером и нужным количеством вьюх. Это для тебя не тривиальный и плохо поддерживаемый код? Тут ты увидел рутину?
_R_>>А нафига? Штатный биндинг действительно убог, но ведь никто не заставляет его использовать. НС>А что вместо него? Ручками твой вожделенный MVVM протаптывать в каждой форме?
Банальное прямое присваивание.
_R_>>А на WPF как биндинг помогает композиции UI? НС>Интересные вопросы ты задаешь. Еще как помогает.
Я действительно не вижу как. И ответ "ещё как" ничего не проясняет, кроме твоей крутости или надменности.
_R_>>С ними что не так? НС>Слишком негибкие.
Есть хэндл, есть оконная процедура. Куда уж гибче в "железных оковах user32.dll". Свойств зависимостей нет, ну звиняйте.
_R_>>Личный. НС>Так и чем твой лучше моего?
Тем что мой.
НС>Речь не про то, что на одном можно, а на другом нет. Речь про то, что типовые приложения с большим количеством форм на WPF,
Опять двадцать пять. Это все архитектурные вопросы. Если ты не продумал их, то и на WPF получишь ерунду.
НС>при грамотном подходе, пишутся существенно проще. Иногда трудозатраты отличаются на порядок.
Так расскажи про этот подход! Расскажи в чем ущербость WinForms, что им не доступен этот подход.
_R_>>Это не заплатки. Это просто по другому. Никто на ВинФормсах не имитирует подсистему шаблонов. НС>И что взамен? Ручное выписывание генераторов форм с ручным рассчетом размеров и координат?
Взамен — грамотный подход на WinForms.
НС>А если HighDPI?
Похоже вилять начинаешь.
_R_>>Не я, а производитель. И, таки, добавляет. НС>А, ну если в винформсах, по твоему, нормальная поддержка масштабирования, то дальше разговаривать бессмысленно.
А в WPF нормальная? Наверняка не та, которая мыло дает? Что, и картинки двойного размера автоматом применяет?
Здравствуйте, _Raz_, Вы писали:
_R_>Копипаст в шаблонах, включая необходимость копипаста стандартных шаблонов для плевого изменения.
Ты там что то писал про спагетти-стайл?
_R_>Я знаю про шаблоны WPF. Я не знаю как изменение внешнего вида контрола при сохранении его поведения способствует убиранию рутины.
Я там Data Templates упоминал. Не заметил?
_R_>>>А нафига? Штатный биндинг действительно убог, но ведь никто не заставляет его использовать. НС>>А что вместо него? Ручками твой вожделенный MVVM протаптывать в каждой форме? _R_>Банальное прямое присваивание.
Т.е. ручками. Ну вот ты и сам все продемонстрировал.
_R_>Я действительно не вижу как.
Верю.
_R_> И ответ "ещё как" ничего не проясняет, кроме твоей крутости или надменности.
Ну да, чужой код спагетти стайл ты обзываешь, а крутость и надменность у меня.
_R_>>>Личный. НС>>Так и чем твой лучше моего? _R_>Тем что мой.
Все, в общем, уже понятно.
_R_>>>Не я, а производитель. И, таки, добавляет. НС>>А, ну если в винформсах, по твоему, нормальная поддержка масштабирования, то дальше разговаривать бессмысленно. _R_>А в WPF нормальная?
Здравствуйте, koandrew, Вы писали:
S>>Не, тут вы перебарщиваете. Пока нет замены от MS -- говорить о кончине рано. О замене сейчас и речь не идет. K>Не слушай этого товарища. Он уже лет 10 вещает о конце WPF https://blogs.msdn.microsoft.com/wpf/ — последняя запись 29 октября 2015. Что это как не конец?
Причины, правда, вовсе не технические, а последствия ЧСВ придурка Синовского.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Shmj, Вы писали:
S>>Или лучше сразу на WFP?
MD>Сейчас это называется UWP — тот же WPF, но без тяжкого наследия Win32 API
Сейчас это называется кроссплатформенный XAML Standard
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, c-smile, Вы писали:
CS>Зачем менять то что не произошло?
CS>WPF так и не состоялась как UI layer системных и образующих приложений Windows. Т.е. велика вероятность что это будет abandon-ware очередной.
CS>Или у тебя другие данные?
Интересно только, что ж всё-таки тогда произошло? Т. е. на чём ж тогда написаны большинство приложний?
MFC/raw API? Вряд ли, скорее это похоже на поддержку уже написанного в системах вроде AutoCAD, чтоб не переписывать их от и до? Или есть что-то, где это основной UI и ничего нового не планируется?
JVM? Был период популярности из-за того, что WPF запоздал, но что на нём написана большая часть приложений — не похоже.
QT? Хороший инструмент сам по себе, но не сильно похоже, чтоб он самый распростанённый.
Python, Ruby, etc.. Возможно, хотя вроде и остальные инструментальные средства ещё окончательно не вымерли.
Допустим даже, что Windows вообще уже не очень нужен? Но что вместо? Web UI? Видел я как-то Web-версию PhotoShop? В самом деле на это уже все перешли? Может, мобильные устройства? Только мне пока что крупнее, чем Lightroom, мало что попадалось. Своя ниша у них немалая, но до замены desktop, видать, ещё не близко. IoT? Что-то ещё?
I>Допустим даже, что Windows вообще уже не очень нужен? Но что вместо? Web UI? Видел я как-то Web-версию PhotoShop? В самом деле на это уже все перешли? Может, мобильные устройства? Только мне пока что крупнее, чем Lightroom, мало что попадалось. Своя ниша у них немалая, но до замены desktop, видать, ещё не близко. IoT? Что-то ещё?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Aquilaware, Вы писали:
A>>Писал и на Windows Forms, и на WPF. Большой недостаток WPF — у него очень плохая стандартная тема
НС>Стандартная тема WPF максимально имитирует родной стиль той ОС, на которой он запущен. Причем на разных ОС он разный. Никакой разницы в этом плане от винформсов нет.
Насчет максимально это конечно сильно сказано. Тот же ListView на всех версиях Windows имеет стиль а ля Windows7 (подозреваю, что и он не совсем нативный, выглядит несколько убого). Грязно-серого цвета кнопки, непохожие на нативные, на всех версиях выше семерки (не говоря уже про такие мелочи, как отсутствие анимации подсветки при наведении курсора). В стиле по умолчанию отступы и выравнивание черти знает какое. Сделать нормальный TreeView они так и не удосужились.
Это навскидку. WPF из коробки довольно сырой. И это приходится компенсировать сторонними библиотеками или собственными усилиями.
Здравствуйте, Shmj, Вы писали:
S> Или лучше сразу на WFP?
Что там щас с ратеризацией шрифтов? Раньше было
в ideal mode смазано, если размер маленький — отстой
в display mode — пиксельные зубцы, если размер средний и большой — тоже отстой
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Здравствуйте, Shmj, Вы писали:
S>>>Или лучше сразу на WFP?
MD>>Сейчас это называется UWP — тот же WPF, но без тяжкого наследия Win32 API
S> Сейчас это называется кроссплатформенный XAML Standard
We are pleased to announce XAML Standard, which is a standards-based effort to unify XAML dialects across XAML based technologies such as UWP and Xamarin.Forms.
Т.е. это более абстрактная штука, что-то типа Стандарта на язык. А UWP — это уже стандартизованный XAML плюс набор доступных API (ибо дёрнуть какой-нибудь CreateFileEx в корневой папке диска C: в UWP-приложении уже не получится, тьфу-тьфу-тьфу).
S>> Сейчас это называется кроссплатформенный XAML Standard
MD>
MD>We are pleased to announce XAML Standard, which is a standards-based effort to unify XAML dialects across XAML based technologies such as UWP and Xamarin.Forms.
MD>Т.е. это более абстрактная штука, что-то типа Стандарта на язык. А UWP — это уже стандартизованный XAML плюс набор доступных API (ибо дёрнуть какой-нибудь CreateFileEx в корневой папке диска C: в UWP-приложении уже не получится, тьфу-тьфу-тьфу).
Но с выходом .NetStandard 2, возможности UWP приблизятся к старшему .Net. Но будет выполняться в своем контейнере.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Tolanay, Вы писали:
T>Это навскидку. WPF из коробки довольно сырой. И это приходится компенсировать сторонними библиотеками или собственными усилиями.
Что есть, то есть. Но по сравнению с проблемами винформса это цветочки.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>https://blogs.msdn.microsoft.com/wpf/ — последняя запись 29 октября 2015. Что это как не конец? НС>Причины, правда, вовсе не технические, а последствия ЧСВ придурка Синовского.
В отличие от тебя, я живу в реальном мире, а не в мире бложиков, и определяю "живость" технологии тем, делаются ли на них новые проекты, и есть ли соответствующие контракты.
Так вот — в "Тойоте" ВСЕ новые десктопные проекты пишутся на WPF (по крайней мере в северо-американской её части, хз, как там в остальных), плюс контракты в новые проекты на WPF тоже приходят мне регулярно. Для меня это является неопровержимым доказательством, что технология живёт и здравствует. А наличие или отсутствие бложиков "евангелистов" меня ни коим образом не трогает, ибо у меня нет ни времени, ни желания читать их выспосты.
Здравствуйте, s_aa, Вы писали:
_>Ничего смешного, таких мелких задач пруд пруди и смысл огород городить с WPF?
Вот мне интересно — о каком огороде идёт речь? Я его использую даже для примитивнейших proof-of-concept проектов с двумя кнопками "Do Thing #1" и "Do Thing #2". Никакого инфраструктурного кода там не требуется, MV инстанциируется прямо WPF в XAML.
Здравствуйте, koandrew, Вы писали:
K>А наличие или отсутствие бложиков "евангелистов" меня ни коим образом не трогает, ибо у меня нет ни времени, ни желания читать их выспосты.
Вот у меня тоже складывается стойкое ощущение, что все эти MS-евангелисты — просто "журналисты от программирования". Те, кто раньше топил за Windows Phone, теперь радостно топят за Azure, а про телефон ни гу-гу. Завтра выйдут очередные свистелки — будут писать про них, а про облака — больше ни слова.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Вот у меня тоже складывается стойкое ощущение, что все эти MS-евангелисты — просто "журналисты от программирования". Те, кто раньше топил за Windows Phone, теперь радостно топят за Azure, а про телефон ни гу-гу. Завтра выйдут очередные свистелки — будут писать про них, а про облака — больше ни слова.
Дык у них работа такая.
Однако я суровый практик и потому "живость" технологии определяю по её используемости в реальном мире. Собственно, в проектах с моим участием уже достаточно давно я являюсь лицом, принимающим решение об используемых библиотеках, либо вхожу в круг таковых. "Сверху" начальству обычно пофигу — они и букв-то таких не знают в большинстве своём, так что их все эти баззворды интересуют только в разрезе того, сколько всё это будет стоить.
K>Вот мне интересно — о каком огороде идёт речь? Я его использую даже для примитивнейших proof-of-concept проектов с двумя кнопками "Do Thing #1" и "Do Thing #2". Никакого инфраструктурного кода там не требуется, MV инстанциируется прямо WPF в XAML.
Ну наверное ты талантливый такой. Я, когда открываю старый проект на WPF с MVVM, то нужный функционал ищу долго, вспоминаю где тут к чему прибиндено. В WinForms тыкнул в нужную кнопку или меню и сразу вспомнил все. Для больших проектов со сложными формами считаю WPF лучше.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, s_aa, Вы писали:
_>Ну наверное ты талантливый такой. Я, когда открываю старый проект на WPF с MVVM, то нужный функционал ищу долго, вспоминаю где тут к чему прибиндено. В WinForms тыкнул в нужную кнопку или меню и сразу вспомнил все. Для больших проектов со сложными формами считаю WPF лучше.
Просто сказывается опыт. Я сразу знаю, куда смотреть и что искать — потому всё выходит быстро и просто. И да — мне читать XAML проще и быстрее, чем тыкаться по формочкам мышой. А вот продирание через тонны Button100500_Click всегда вгоняет меня в депрессию, и хочется что-нибудь сломать
Здравствуйте, koandrew, Вы писали:
K>В отличие от тебя, я живу в реальном мире, а не в мире бложиков, и определяю "живость" технологии тем, делаются ли на них новые проекты, и есть ли соответствующие контракты.
В реальном мире проект, который не поддерживается планомерно умирает.
K>Так вот — в "Тойоте" ВСЕ новые десктопные проекты пишутся на WPF
Напомнить судьбу Silverlight?
K>А наличие или отсутствие бложиков "евангелистов" меня ни коим образом не трогает, ибо у меня нет ни времени, ни желания читать их выспосты.
Это не бложик евангелистов, это бложек команды, занимающейся WPF. Если туда никто не пишет — дело тухлое.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Вот у меня тоже складывается стойкое ощущение, что все эти MS-евангелисты — просто "журналисты от программирования". Те, кто раньше топил за Windows Phone, теперь радостно топят за Azure, а про телефон ни гу-гу. Завтра выйдут очередные свистелки — будут писать про них, а про облака — больше ни слова.
Увы, но это не междусобойчик евангелистов, это политика корпорации. В 2015 еще что то бормоталось, что WPF мы не забросили. Но в 2017, увы, его явно ждет судьба сервелата.
Вот посмотри изменения в 4.7:
Support for a touch/stylus stack based on Windows WM_POINTER messages
You now have the option of using a touch/stylus stack based on WM_POINTER messages instead of the Windows Ink Services Platform (WISP).
New implementation for WPF printing APIs
WPF's printing APIs in the System.Printing.PrintQueue class call the Windows Print Document Package API instead of the deprecated XPS Print API.
Это все изменения за более чем год работы. Как думаешь, над WPF сейчас сколько программистов работают, один или два?
Здравствуйте, Serginio1, Вы писали:
НС>>Это все изменения за более чем год работы. Как думаешь, над WPF сейчас сколько программистов работают, один или два? S>Работают над UWP, Xamarin.Forms и над XAML Standard
Это все к WPF имеет крайне опосредованное отношение.
Здравствуйте, Ilya81, Вы писали:
I>Интересно только, что ж всё-таки тогда произошло? Т. е. на чём ж тогда написаны большинство приложний? I>MFC/raw API? Вряд ли, скорее это похоже на поддержку уже написанного в системах вроде AutoCAD, чтоб не переписывать их от и до? Или есть что-то, где это основной UI и ничего нового не планируется? I>JVM? Был период популярности из-за того, что WPF запоздал, но что на нём написана большая часть приложений — не похоже. I>QT? Хороший инструмент сам по себе, но не сильно похоже, чтоб он самый распростанённый. I>Python, Ruby, etc.. Возможно, хотя вроде и остальные инструментальные средства ещё окончательно не вымерли. I>Допустим даже, что Windows вообще уже не очень нужен? Но что вместо? Web UI? Видел я как-то Web-версию PhotoShop? В самом деле на это уже все перешли? Может, мобильные устройства? Только мне пока что крупнее, чем Lightroom, мало что попадалось. Своя ниша у них немалая, но до замены desktop, видать, ещё не близко. IoT? Что-то ещё?
Если говорить о крупных (как тут говорили, системобразующих) приложениях под десктоп (типа Офиса), то большинство из них пишется на своих оригинальных фреймворках, рисующих свои контролы поверх GDI/DirectX/OpenGL. Т.е. в принципе концепция Qt, но только в виде закрытого самопального решения. )))
А вот как раз небольшие проекты, которые не могу себе позволить разработку собственного велосипеда, используют популярные готовые решения, типа Qt, wxWidgets и т.п. Причём хотя подобные инструменты изначально написаны на и для C++, но сейчас уже используются практически из всех языков (включая упомянутые тобой Python, Ruby, Java, C# и многие другие).
Плюс в последние годы с развитием браузерных js фреймворков возродилась мода на веб-интерфейсы для десктопных приложений. Это подход действительно позволяет достигать кроссплатформенности меньшими усилиями, чем в случае фреймворков типа Qt. Однако на мой личный вкус это мелкое преимущество не стоит страданий от работы с js/html/css (которые всё же были созданы совсем для других целей).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Это все изменения за более чем год работы. Как думаешь, над WPF сейчас сколько программистов работают, один или два? S>>Работают над UWP, Xamarin.Forms и над XAML Standard
НС>Это все к WPF имеет крайне опосредованное отношение.
Вопрос скорее стоит так. Будет ли развиваться обычный .Net или только .Net Core к которому относится и UWP. Или после достижения .Net Core возможностей
.Net c выходом .Net Standard 2 будет развиваться и обычный .Net, но в рамках NetStandard
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Если б только это. user32 то тоже никуда не девается, и полет фантазии быстро обрывает. А если выдрать из Control этот самый user32, то это уже и не винформсы будут. А главное — нафига, если проще и дешевле взять WPF?
А почему не UWP?
Там сейчас вкусностей больше живёт и оно активней развивается.
А принципы проектирования приложения — ровно такие же.
Здравствуйте, Serginio1, Вы писали:
НС>>Это все к WPF имеет крайне опосредованное отношение. S> Вопрос скорее стоит так. Будет ли развиваться обычный .Net или только .Net Core к которому относится и UWP.
Опять ты кашу из головы вывалил в форум. Нет, UWP не относится к .NET Core, тебе тут об этом уже писали.
Здравствуйте, koandrew, Вы писали:
НС>>Напомнить судьбу Silverlight? K>И что с ней случилось?
Она утонула.
А тоже кучу народа не нем новые проекты начинало.
НС>>Это не бложик евангелистов, это бложек команды, занимающейся WPF. Если туда никто не пишет — дело тухлое. K>У моей команды вот почему-то нету бложика... Намёк понятен?
Нет. В твоей конторе, в отличие от МС, нет политики, прямо заставляющей вести такие бложики команды разработки.
Здравствуйте, vdimas, Вы писали:
НС>>Если б только это. user32 то тоже никуда не девается, и полет фантазии быстро обрывает. А если выдрать из Control этот самый user32, то это уже и не винформсы будут. А главное — нафига, если проще и дешевле взять WPF? V>А почему не UWP?
Потому что UWP накладывает столько ограничений, что вопрос его применения пока определяется совсем не возможностями UI фреймворка.
V>Там сейчас вкусностей больше живёт и оно активней развивается.
Политика партии такая, да. UWP, Лазурь, Core, остальное на обочине. Вот если бы WPF был в Core, картинка могла быть другой.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Это все к WPF имеет крайне опосредованное отношение. S>> Вопрос скорее стоит так. Будет ли развиваться обычный .Net или только .Net Core к которому относится и UWP.
НС>Опять ты кашу из головы вывалил в форум. Нет, UWP не относится к .NET Core, тебе тут об этом уже писали.
Ага. И где писали? .Net Core как и создавался для UWP и конкретно .Net Native
Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. Дело в том, что .NET Native статически связывает инфраструктуру с приложением, а затем удаляет все лишнее, что не нужно приложению. (Здесь я сильно упрощаю общую картину, но идею вы уловили. Подробнее на эту тему см. «Inside .NET Native» по ссылке bit.ly/1UR7ChW.)
Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности. Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.
Компиляция через .NET Native — сложный процесс, немного медленнее традиционной в .NET компиляции. Преимущества, упомянутые чуть ранее, даются ценой увеличения времени компиляции. Вы могли бы выбрать компиляцию в «родной» код всякий раз, когда запускается приложение, но тогда вы тратили бы дополнительное время, ожидая окончания сборки. Инструментарий Visual Studio предназначен для устранения этой проблемы и создания максимально комфортных для разработчиков условий. Скомпилировав и запустив программу в конфигурации Debug, вы выполняете код Intermediate Language (IL) в CoreCLR, упакованной вместе с приложением. Системные сборки .NET упаковываются наряду с кодом вашего приложения, и это приложение получает зависимость от пакета Microsoft.NET.CoreRuntime (CoreCLR). Если инфраструктура CoreCLR отсутствует на устройстве, где вы тестируете, Visual Studio автоматически обнаружит это и установит ее до развертывания вашего приложения.
Это означает, что получаете максимум удобств при разработке: быструю компиляцию и установку, богатые средства отладки и диагностики и весь инструментарий, к которому вы привыкли при .NET-разработке.
Здравствуйте, sr_dev, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
CS>>Если "да", попутал то тогда уже Sciter — всё гуманнее будет для машин в бухгалтерии.
_>памяти меньше жрёт, или что?
Native жеж ... Т.е. и это тоже.
В качестве примера вывод 32 видео потоков одновременно (60 FPS):
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, sr_dev, Вы писали:
_>>Здравствуйте, c-smile, Вы писали:
CS>>>Если "да", попутал то тогда уже Sciter — всё гуманнее будет для машин в бухгалтерии.
_>>памяти меньше жрёт, или что?
CS>Native жеж ... Т.е. и это тоже.
CS>В качестве примера вывод 32 видео потоков одновременно (60 FPS): CS>Image: publicpreview.php
Вроде электрон тоже натив, я про него. как то я спрашивал, мне ответили что sciter это не хромиум. html5/css3/js полноценно работает?
Здравствуйте, koandrew, Вы писали:
K>Так вот — в "Тойоте" ВСЕ новые десктопные проекты пишутся на WPF (по крайней мере в северо-американской её части, хз, как там в остальных), плюс контракты в новые проекты на WPF тоже приходят мне регулярно.
У меня друг пишет новые приложения на MFC. Тоже для автомобилистов, кстати.
Здравствуйте, sr_dev, Вы писали:
_>Вроде электрон тоже натив, я про него. как то я спрашивал, мне ответили что sciter это не хромиум. html5/css3/js полноценно работает?
Электрон судя по отзывам тоже далек от хромиума в плане полноценности. Ведь под html5 теперь понимается всё подряд. На его основе — это ж не значит быть полноценным.
Есть огромная разница между потреблять неизвестный контент в промышленных масштабах и заботливо сделанные приложения на основе веб технологий. Половина хрома последним просто не нужна, но платить прийдется всё равно: считай одна только неотключаемая многопроцессная архитектура уже выкидывает современные (тут скорее имеется ввиду движки браузеров) веб движки из игры. Будущий Servo к слову — такая же бодяга. Архитектура, чё. Но в браузерах оно оправдано, а в ембеде — абсолютно нет.
Некоторым приложениям вообще не нужен сетевой слой.
Другим — нафиг не нужен out-of-process gpu rendering, а то и вообще gpu rendering: обычная форма без тучи надоедливых анимаций будет рисоваться всё равно весьма хорошо даже на CPU.
Другое дело когда потребляется реальное веб приложение которое работает и в браузере и в специальном клиенте. Но это довольно узкая ниша.
В этом свете: Sciter просто не оставляет никому шансов. Просто посмотри демки, оцени размер...
PS: VSCode/Atom/Brackets — они больше от V8 выигрывают, утилизируя тонны библиотек, реализуя свистелки, нежели как от платформы для построения UI. Ребята в brackets помню настолько были суровы, что BOM в редакторе светился в первой позиции, а не латинские глифы — каким-то левым шрифтом. Редактор должен быть удобен... Но...
Здравствуйте, Mystic Artifact, Вы писали:
_>>Вроде электрон тоже натив, я про него. как то я спрашивал, мне ответили что sciter это не хромиум. html5/css3/js полноценно работает? MA> Электрон судя по отзывам тоже далек от хромиума в плане полноценности. Ведь под html5 теперь понимается всё подряд. На его основе — это ж не значит быть полноценным.
Electron — это и есть Хромиум. На нём вполне реально небольшими затратами писать приложение, которое работает в web и на декстопе.
Здравствуйте, Cyberax, Вы писали:
_>>>Вроде электрон тоже натив, я про него. как то я спрашивал, мне ответили что sciter это не хромиум. html5/css3/js полноценно работает? MA>> Электрон судя по отзывам тоже далек от хромиума в плане полноценности. Ведь под html5 теперь понимается всё подряд. На его основе — это ж не значит быть полноценным. C>Electron — это и есть Хромиум. На нём вполне реально небольшими затратами писать приложение, которое работает в web и на декстопе.
Это то понятно. Проблема в том насколько хорошо в электроне обвязан chromium's content layer, потому, что многие вещи "из коробки" работать не будут (но всё равно очень дофига — будет). В частности, тут где-то на форуме кто-то писал именно про электрон. Эти вещи могут быть и не нужны. Вещи на подобии application cache, но о чём была речь конкретно, я увы не помню.
Здравствуйте, Shmj, Вы писали:
S>Вот стали бы вы писать небольшую утилиту для бухгалтерии на WinForms (5-7 разных форм средней сложности)? Или лучше сразу на WFP?
S>Плюс WinForms -- оно работает на Linux. Мало ли, вдруг понадобится.
S>Или трупа лучше не ворошить?
WPF по скорости быстрее, т.к. использует видеокарту напрямую. По качеству кода выше не то что на две головы, а на порядок. Не понятно как вобще такой вопрос поставить можно было.
Здравствуйте, Gattaka, Вы писали:
G>WPF по скорости быстрее, т.к. использует видеокарту напрямую. По качеству кода выше не то что на две головы, а на порядок. Не понятно как вобще такой вопрос поставить можно было.
EverNote v.3.5 был сделан на WPF. Откатили на plain API в 4.0 по этим причинам
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, c-smile, Вы писали:
CS>>EverNote v.3.5 был сделан на WPF. Откатили на plain API в 4.0 по этим причинам
НС>Основные причины относятся к дотнету, а по поводу blurry text с 2010 года многое было поправлено.
Там все еще хуже было на самом деле. WPF да еще и CEF в качестве note renderer. Слоеный пирог какой-то жуткой высоты. И в графике и в коде.
Ну и к тому же occasionally used application которое натужно стартует и ест кучу ресурсов никому не упало.
А на вопрос ты так и не ответил.
