Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, s_aa, Вы писали:
_>>Ничего смешного, таких мелких задач пруд пруди и смысл огород городить с WPF? K>Вот мне интересно — о каком огороде идёт речь? Я его использую даже для примитивнейших proof-of-concept проектов с двумя кнопками "Do Thing #1" и "Do Thing #2". Никакого инфраструктурного кода там не требуется, MV инстанциируется прямо WPF в XAML.
Добавлю, что Самсунг для своего Tizen выбрал Xamarin.Forms которые на XAML и скоро выйдет XAML Standard.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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 (которые всё же были созданы совсем для других целей).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Напомнить судьбу Silverlight?
И что с ней случилось?
НС>Это не бложик евангелистов, это бложек команды, занимающейся WPF. Если туда никто не пишет — дело тухлое.
У моей команды вот почему-то нету бложика... Намёк понятен?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, 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-разработке.
Здравствуйте, koandrew, Вы писали:
НС>>А тоже кучу народа не нем новые проекты начинало. K>И чего? Эти проекты перестали работать?
И того что сервелат уже официально мертв со всеми вытекающими.
НС>>Нет. В твоей конторе, в отличие от МС, нет политики, прямо заставляющей вести такие бложики команды разработки. K>Всё равно не понятна связь. Нет блогов == проекты на нём внезапно поломаются?
Я вроде уже все на пальцах объяснил. Нет записей в блоге — в команде 1.5 человека — серьезные проблемы фикситься не будут, нового функционала можно не ждать.
