Я думаю, что Xamarin сольется с .NET 5;
Было бы здорово, если бы они приняли UWP XAML в качестве стандарта и работали с этого момента, Microsoft и UNO сделали бы его лучшим для настольных компьютеров, мобильных устройств, веб-браузера (Azure) и IoT.
Они могли назвать это
UWP vNext (на основе WinUI)/ Silverlight 6 (UNO)

Я думаю, что усилия Blazor были первым шагом к официальному внедрению .NET в WebBrowser с использованием его текущего рендеринга по умолчанию, т.е. HTML DOM
Но я верю, что вскоре они могут даже предложить другой движок рендеринга, легкое дополнение для WinUI, что-то вроде Silverlight, платформы UNO и Xamarin... например, Flutter/WPF.

Было бы здорово, если бы они приняли UWP XAML в качестве стандарта и работали с этого момента.

Все, что вы, ребята, хотите, уже происходит с Uno. MS было бы разумно выкупить этих парней, а затем нанять их, чтобы они руководили окончательной разработкой Uno.

Вероятно, это неправильное место для запроса такой функции. Как бы я ни хотел согласиться со всем в этом запросе, я считаю, что команда WinUI и многие старшие разработчики в сообществе Windows придерживаются очень узкого определения WinUI.

В идеальном мире WinUI был бы похож на Material Design. Будут способы иметь его на любой платформе со всеми типами библиотек, которые его реализуют. Однако WinUI — это не язык дизайна, как и Fluent Design. Microsoft, не находясь в модельном пространстве, значительно отстала от конкурентов в своем предложении пользовательского интерфейса.

WinUI — это библиотека пользовательского интерфейса для приложений Windows, и это совершенно очевидно. Язык дизайна неотделим от реализации, а реализация зависит от платформы, поскольку такие функции, как композиция, сильно зависят от платформы. Это плохо с точки зрения мобильного/кроссплатформенного разработчика, но на самом деле усилия здесь направлены на приложения для Windows.

Вот почему, вероятно, Uno Platform никогда не сможет быть действительно WinUI везде, если только они не портируют DX 11 на каждую платформу.

Я бы посоветовал вам изучить Comet (кроссплатформенная среда разработки на основе .Net). Он находится на ранней стадии, но концепция мало чем отличается от Flutter. Он также использует Skia (как вариант) для рисования пользовательского интерфейса с компонуемым / декларативным шаблоном пользовательского интерфейса, поэтому разработчики могут реализовывать библиотеки пользовательского интерфейса, такие как Material Design, и он будет выглядеть совершенно одинаково на каждой платформе.

Нет, это не должно быть кроссплатформенным. Не зря он называется пользовательским интерфейсом Windows. Давайте для начала создадим систему пользовательского интерфейса, которая работает на всех платформах и языках Windows, а? Это еще даже не достигнуто. Мы по-прежнему разделены между .net framework, .net core, uwp, а затем историей C++, в которой, по крайней мере, есть uwp, но разработчики игр не используют его, потому что у UWP/WinRT все еще есть некоторые проблемы — распространение, принудительная панель задач и всплывающие окна в заголовке. когда в полноэкранном режиме (yikes).

Думать о кроссплатформенности было бы колоссальной тратой ресурсов. Сначала сделайте это правильно на Windows, пожалуйста. И выпустить .net 5, исправить UWP и историю с окнами, а также поставить DirectX на C#. И исправить ГК. В узком сценарии еще так много всего нужно сделать, только в Windows.

И к ОП.

• UWP универсален. Сказать, что это не универсально, — ложное утверждение (слава богу, они никогда не собирались ориентироваться на Android). Первоначальное обещание было выполнено. Все устройства Windows работают под управлением UWP. Windows Mobile была отдельной ОС, от нее пришлось избавиться. Все новые платформы Windows будут Windows (10 или 10X). В конце концов, я полагаю, на основе CoreOS. И все они будут запускать приложения Windows. Просто потому, что у нас нет телефона с Windows на данный момент, это случайно. У нас есть все остальные типы устройств. И скоро у нас будут Нео и Дуо.

• Ограничения песочницы — это хорошие вещи. Общесистемный доступ в стиле Win32 должен быть вообще исключен. Если у вас есть конкретное требование, вы должны выдвинуть свое требование, чтобы мы могли обсудить, как это можно/должно быть выполнено внутри контейнера UWP и следует ли вам разрешить делать это так, как вы предлагаете. И выясните, нужна ли UWP эта функция. Потому что я могу придумать несколько продвинутых приложений, которые можно без проблем написать на UWP. Я могу имеет программу! Вам нужно обсудить детали.

• .net native заменяется, и история распространения изменится с .net 5. Я думаю, будет справедливо сказать, что Microsoft работает над этим. Наверняка знают о проблемах. Но вы должны указать здесь конкретные проблемы, чтобы выявить реальные основные проблемы.

• «Не связывайте WinUI с DirectX» — WTF? Он обязательно должен быть связан с DirectX, то есть родным графическим стеком Windows. Пожалуйста, даже не рассматривайте ничего другого. Я абсолютно не хочу сталкиваться с поверхностями рендеринга OpenGL под капотом. Это нарушило бы совместимость и вызвало бы все виды хаоса.

@Гэвин-Уильямс

Замечательно, давайте сделаем немного эволюционный апгрейд по сравнению с WPF.

UWP универсален

«Все устройства Windows работают под управлением UWP» ничего не значат без мобильных устройств. HoloLens — это ниша, Surface Hub — это ниша, Windows 10 IoT Core — это шутка.

Это обязательно должно быть связано с DirectX

У меня, как у разработчика, жесткая связь вызывает мурашки по коже. Есть ли какая-то основная причина, по которой графический стек нельзя поменять местами?

Это называется "модульность". Microsoft всегда боролась с этим.

Ограничения в песочнице — это хорошо

Да, они есть, пока они не сильно ограничивают диапазон приложений, которые можно создать. Вы пытались изменить размер раздела из UWP?

Я думаю, стоит упомянуть и напомнить, что Google разрабатывает Flutter, и они не называют его GoogleUI или AndroidUI. Он работает везде — даже в Интернете и на рабочем столе. Я утверждаю это, так как кажется, что есть склонность «просто заставить это работать на Windows», но если существует другое конкурентное предложение, которое дешевле, быстрее, проще в использовании И работает на Windows + все остальное ... что сделают разработчики ( и соответствующий рынок) выбрать? Я могу сказать вам как владелец малого бизнеса, что я знаю, куда я вкладываю свои инвестиции, учитывая два варианта.

Портирование DirectX на другие платформы кажется огромной работой, возможно, решение состоит в том, чтобы использовать OpenGL или Vulkan вместо DirectX.

@ Гэвин-Уильямс, я не знаю, знакомы ли вы с UWP, но когда вы создаете / распространяете, вы ориентируетесь на определенную версию (или диапазон версий) Windows. Эта идея абсолютно взаимосвязана и является одной из причин, по которой UWP не стала такой популярной, как WPF.
@nerocui вся цель языка пользовательского интерфейса состоит в том, чтобы отделить дизайн пользовательского интерфейса от необработанного рисунка на экране. Вот почему вы видите, что HTML может отображаться в ARM/x64/x64.

XAML обеспечивает выдающуюся абстракцию примитивов/композиции/анимации пользовательского интерфейса, запрос имеет абсолютный смысл из-за стоимости разработки и охвата платформы.

Я с уважением не согласен с @SuperJMN. Конечно, UWP еще не достиг паритета функций с WPF. Несмотря на его ограничения в качестве основы для создания инструментов на уровне ядра, практически для любой другой задачи разработки программного обеспечения с правильными возможностями, указанными в манифесте приложения, вы получаете гораздо лучший пользовательский опыт с разных точек зрения (безопасность, простота развертывания, установка/удаление опыт и др.). Песочница безопасности UWP — важная (необходимая) функция. Во многих отношениях UWP значительно опережает WPF.

Компилятор UWP .Net устраняет необходимость в запутывании кода и нестабильности, которая может возникнуть в WPF. Производительность может улучшаться с течением времени без изменения кода по мере улучшения компилятора. Сам UWP имеет гораздо лучший дизайн с точки зрения того, как он использует DirectX и другие ресурсы системного уровня. Он также имеет огромное преимущество перед WPF при интеграции с другими языками, в частности с C++. Интеграция высокопроизводительных компонентов C++ с C# в UWP является тривиальной задачей. Доступ к поверхностям DirectX также значительно улучшен.

Остальные дыры в UWP можно легко заткнуть. Я бы сказал, что более серьезной проблемой была неспособность Microsoft достичь уровня качества, связанного с WPF. WPF только что работал. Microsoft также не смогла осознать критическую важность требований LOB, таких как Data Grid, INotifyDataErrorInfo, элементы управления состояниями проверки и надежной базой данных из коробки. Большинство из них были рассмотрены, но это заняло слишком много времени. Непрямоугольные участки по-прежнему отсутствуют.

Другой критический сбой связан с некоторыми разработчиками WPF, которые решили держаться подальше от UWP. Принятие важно для создания импульса. Тем не менее, сага об усыновлении понятна, учитывая, сколько раз Microsoft колебалась со своими инициативами. Очевидно, что Microsoft снова лукавит. Возродить WPF, позволив ему подключаться к службам пользовательского интерфейса UWP, на первый взгляд кажется крутым, но это отвлекает от создания надежной платформы UWP.

Я полностью согласен с утверждением @SuperJMN о том, что разработчики потеряли надежду, что Microsoft поступит правильно. Правильные вещи различаются в зависимости от того, какое программное обеспечение вы создаете. Если речь идет о высокопроизводительных бизнес-приложениях, которые необходимо быстро создать и которые должны обладать широким набором возможностей, будучи безопасными и простыми в установке, UWP в основном подходит, за исключением качества. Этот разрыв в качестве убивает UWP больше, чем что-либо еще.

HTML+JS — кроссплатформенное решение дня. Нам не нужно изобретать его заново. Наличие высокопроизводительного механизма рендеринга XAML на IOS и Android имеет больше смысла, если цель состоит в том, чтобы сделать XAML более переносимым.

Я полностью согласен с тем, что WinUI в будущем должен стать кроссплатформенным. Вот еще несколько мыслей.

Ближайшие приоритеты

Я согласен с некоторыми комментариями о том, что непосредственным приоритетом должно быть обеспечение работы WinUI 3 в Windows с интеграцией .Net 5 и исправление ошибок. Однако, если еще не поздно, при принятии архитектурных решений следует учитывать цель кроссплатформенности в будущем.

Почему WinUI должен быть кроссплатформенным

Есть очевидные и наиболее важные причины: разработчики хотят ориентироваться на максимально возможную аудиторию без переписывания кода и т. д., а C# (или C++, я полагаю)/XAML — хорошая комбинация. Без кроссплатформенной истории они перейдут на другие технологии вроде Flutter.

Другая причина заключается в том, чтобы убедиться, что Microsoft продолжает поддерживать WinUI. Microsoft, скорее всего, продолжит поддерживать WinUI только в том случае, если его используют их собственные приложения. Они все больше внимания уделяют созданию кроссплатформенных приложений. Это правда, что некоторые кросс-платформенные фреймворки, такие как React Native и Xamarin, будут использовать WinUI, но что произойдет, если другие фреймворки, такие как Flutter или рендеринг на основе браузера, победят? Тогда WinUI станет избыточным и перейдет в режим обслуживания, как WPF.

Как должна быть реализована кроссплатформенность

Хотя Uno — отличный проект, на мой взгляд, имеет смысл сделать слой рендеринга (и ввода) кроссплатформенным и опираться на него, как это делают Flutter и AvaloniaUI, а не оборачивать нативные элементы управления. Есть несколько преимуществ кросс-платформенного подхода к созданию слоев рендеринга и ввода. Мне кажется, что поверхность API слоев рендеринга и ввода меньше, чем у элементов управления (но я полагаю, это зависит от того, создаете ли вы элементы управления поверх нескольких базовых и т. д.). Во-вторых, если вы полагаетесь на обертку собственных элементов управления, вы зависите от платформы. Если они изменят свой API, вам придется изменить свой или реализовать обходной путь. Если вы не сделаете это достаточно быстро после устаревания, ваш фреймворк сломается. Если вы хотите добавить новую функцию в элемент управления, возможно, вам придется реализовать ее для каждой платформы. У вас не может быть «видения» того, как вы хотите, чтобы ваш фреймворк развивался, потому что вы привязаны к фреймворкам платформы. Также требуется, чтобы разработчики все время тестировали на каждой платформе, так как внешний вид и поведение элементов управления различаются. Кроме того, было бы сложно/невозможно реализовать более мощные функции, такие как слой композиции. Создание кросс-платформенного слоя рендеринга решает все эти проблемы, и если вы хотите, чтобы на каждой платформе отображался другой вид, вы можете добавить другой стиль. (Я признаю, что некоторые действия на разных платформах будут разными, например прокрутка на Mac!).

Поскольку WinUI в настоящее время отделяет элементы управления, уровни рендеринга и ввода от платформы, кажется, что он находится в уникально выгодном положении для этого.

Одним из способов абстрагирования слоя рендеринга является использование Skia. Однако я бы не хотел, чтобы производительность страдала из-за форсирования этой абстракции. У меня есть альтернативное предложение для абстрагирования слоя рендеринга, которое является предложением С++ для 2D-графики - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . Очевидно, они проделали большую работу над поверхностью API, и она кажется довольно всеобъемлющей. Они утверждают, что «проблема» 2D-графики была по существу решена много лет назад, и я должен согласиться с ними в том, что их поверхность API кажется довольно полной. Есть много людей против этого предложения, но даже если оно не будет принято, я думаю, что поверхность API может быть использована. Если вы напишете серверную часть Direct2D для этой поверхности API, то, если предложение будет принято, это избавит команду MSVC от необходимости писать его. Возможно, команда WinUI могла бы использовать это как оправдание для разрешения работать над ним или добавления дополнительных членов команды. Кроме того, возможно, авторы статьи захотят помочь. Вы можете написать серверную часть для других платформ, используя Skia или что-то в этом роде, и, если предложение в конечном итоге будет принято, переключитесь на нативные реализации, когда они будут сделаны.

Наконец, заглядывая в будущее, я хотел упомянуть WASI — https://wasi.dev/ . На данный момент это похоже на системное программирование, но у него может быть потенциал для превращения в полноценную кросс-платформенную структуру приложений (в нее встроены кроссплатформенность и безопасность), а приведенное выше предложение C++, возможно, обеспечивает естественный кандидат для API слоя рендеринга. (Это, вероятно, очень далеко, хотя).

Глядя на доказательства, такие люди, как @SuperJMN , пользуются большим доверием, учитывая содержимое их репозиториев. Я вижу, что @SuperJMN , вероятно, отказался от UWP, когда он еще созревал (понятно). Microsoft было бы неплохо просмотреть репозитории людей, комментирующих здесь. Некоторые голоса не вызывают особого доверия из-за объема работ, которые они представляют миру.

@Noemata Раньше я был большим поклонником XAML + MVVM. Я работал с ним в Silverlight, WPF, WindowsPhone, Metro(WinRT). Я перегорел, когда дело дошло до UWP и Xamarin...

Трудно понять, что отличает эту итерацию от всех других случаев, когда я рассматривал новый стек XAML.

Microsoft выпустила несколько фантастических примеров приложений UWP. Они действительно хорошо демонстрируют, что возможно.

Вот неполный список:

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/ВанАрсдел
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

Есть еще много прекрасных примеров. Ни один из них не построен таким образом, чтобы его можно было легко переназначить или структурировать, чтобы образцы были связаны с другими работами.

Я не припомню столько же усилий с соответствующими образцами WPF. Это в основном хорошо.

Эта проблема? Потребовалось слишком много времени, чтобы добраться до того, что мы имеем сейчас с UWP и XAML. И теперь сообщение снова запутано. Если бы Microsoft просто предоставила достойные шаблоны проектов с Visual Studio, когда UWP была впервые выпущена, мы были бы менее негативны в отношении UWP. Для лучших шаблонов VS вы должны пойти сюда:

https://github.com/microsoft/windowsTemplateStudio

Не совсем готовый, несмотря на то, что это очень гибкий и полный набор строительных блоков для приложений UWP. Как вы все это находите? Нет подсказки. Отправляясь на охоту за сокровищами, чтобы выполнять свою работу, вы не укрепляете уверенность. Отказ команды Office от внедрения WinRT не помог. Они управляют многим из того, что входит в ОС, независимо от их теоретической досягаемости. Добавьте к этому проблемы с качеством, ошибки, сбои Windows Phone и непоследовательные инвестиции, а также обмен сообщениями, и вот мы здесь.

Microsoft выпустила несколько фантастических примеров приложений UWP. Они действительно хорошо демонстрируют, что возможно.

@Noemata Я согласен, это действительно крутые образцы. Но разработка сложного приложения с использованием UWP — это безумие. Это, конечно, возможно, но это намного сложнее. Да, я скучаю по тем временам, когда WPF «просто работает».

Одна из первых вещей, которую MS должна предоставить в качестве образца, — это простое приложение UWP, которое вы можете опубликовать за пределами магазина MS (и да, это не так просто, как вы думаете).

Еще одна вещь, которая меня не устраивает, заключается в том, что UWP задумывался с учетом «сначала мобильные устройства», отказываясь от правильного взаимодействия с рабочим столом.

Поправьте меня, если я ошибаюсь, но большинство разработчиков используют UWP для разработки настольных приложений, и пользовательский интерфейс не соответствует этому. Первое, что приходит на ум, это полоса прокрутки, которая с самого начала оптимизирована для сенсорной панели. Но для пользователей настольных компьютеров прокрутка очень плохая (примечание: я думаю, что команда WinUI работает над исправлением этого). Я довольно много гуглил, чтобы найти решение, которое снова сделает полосу прокрутки «нормальной» - просто безумие, что я не могу просто вызвать функцию API для этого.

То же самое, переключатели/поля со списком имеют минимальный размер, также оптимизированный для мобильных устройств. Простая установка ширины переключателя игнорируется, вам действительно нужно установить «MinWidth = 0», чтобы это учитывалось.

И цвет текстовой кнопки белый, затем черный в фокусе — что с этим делать? И у текстовой кнопки есть «x», который вы можете использовать, чтобы очистить его — это тачпад — почему он у меня там, когда нет тачпада?

В текстовом поле по умолчанию включено правописание — зачем мне это?

Есть и другие проблемы, но я их обошел. Но самая большая проблема в том, что вещи, которые должны занимать 10 минут, обычно занимают 2 часа и более. Я просто потерял способность оценивать - когда я что-то говорю, у меня уходит полдня, у меня уходит 2-3 дня.

Приветствую всех,
так как это общий вопрос для обсуждения, и я не знаю, где еще разместить свои пожелания/запросы функций UWP..... Я пользуюсь возможностью в этой теме:

• Улучшена поддержка интеграции приложений uwp в контекстное меню проводника Windows.
  
  
  
  • Пожалуйста, поддержите нас здесь https://aka.ms/AA6rmrk
  
  
• Отсутствует расширение разметки UWP IServiceProvider и сам элемент, для которого используется расширение разметки.
• Отсутствует триггер стиля UWP
• Проблема с неявными шаблонами данных UWP. См., например , здесь
• автоматическая печать невозможна без взаимодействия с пользователем (работает только для POS) см. здесь

Все вышеперечисленные функции или проблемы были решены в uservoice, от которого сейчас отказались. Кто-нибудь знает, что случилось с этими проблемами? Должны ли мы воссоздать их на Feedbackhub?

Люблю фразу «Забытые разработчики». Я знаю многих из них, талантливых, опытных, увлеченных технологиями. Это ветераны .Net-разработчиков. Я не сомневаюсь, что они, вообще говоря, могут делать приложения лучше, чем многие дети, которые преуспевают в разработке приложений для iOS и Android.
Если WinUI сможет предоставить им приятный и надежный способ использовать свой обширный опыт работы с C# + .Net + Xaml для создания приложений для Windows, Android, iOS и Интернета, многие прыгнут в фургон, и мир выиграет от их высокого уровня. качественные приложения.
Платформа WinUI + Uno может стать окончательным выбором.

В расширении разметки UWP отсутствует IServiceProvider и сам элемент, для которого используется расширение разметки.

Ты здесь прикрыт @mfe- !

Ты здесь прикрыт @mfe- !

@Mike-EE Вау, это круто! Я помню, как столкнулся с этим, когда хотел портировать CalcBinding на UWP. В итоге я сделал обходной путь, добавив поля только для чтения в модель представления.

"напиши один раз, беги везде".

Microsoft отошла от этого некоторое время назад.

Хорошая работа, все МЫ ЗНАМЕНИТЫ! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Забытые разработчики молчат или просто игнорируются

Люблю фразу «Забытые разработчики».

Давайте организуемся под этим именем! 💪

Я просто хочу кроссплатформенную структуру пользовательского интерфейса, разработанную и поддерживаемую Microsoft. Для экосистемы .NET просто нет ничего, кроме _Uno Platform_ и _Xamarin.Forms_ (если они все еще работают над ориентацией на рабочий стол).

И даже если я решу написать бизнес-приложение только для Windows с нуля, я не верю, что Microsoft полностью привержена UWP. Поправьте меня, если я ошибаюсь, но разве они не отказались от приложений Office UWP в пользу Office Online PWA? Если MS отказывается от собственной собственной платформы, то почему я должен доверять UWP? _кашель Сильверлайт_

К счастью, от WPF еще не отказались. Но это только усиливает мои сомнения.

Хорошая работа, все МЫ ЗНАМЕНИТЫ! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Холли 🤭

Супер! Давайте расширимся до других крупных журналов, веб-сайтов и т. д. 😛

Для тех, кто ищет кроссплатформенное решение для разработки приложений, вам не нужно ничего искать дальше Unity:

https://unity.com/

Как и все подобные решения, вы получаете фреймворк, включающий в себя мини-операционную систему. Java была операционной системой, искусно замаскированной под язык программирования.

Современный браузер теперь представляет собой мини-ОС. Я думаю, что у нас их достаточно. Предполагается, что WinUI/UWP является родным пользовательским интерфейсом для Windows 10 и более поздних версий. Возможно, имеет смысл иметь механизм XAML, который работает в большем количестве мест. Я не уверен, что это пойдет против встречного ветра таких вещей, как Unity. Я бы предпочел увидеть отполированную высококачественную UWP до того, как Microsoft уйдет и начнет заново изобретать Silverlight, чтобы мы могли размещать XAML на других платформах. Мы все знаем, как хорошо это сработало. Если вы еще не смотрели на Unity, вы многое упускаете. Тем не менее, будьте готовы к большому количеству кодирования и даже к отладке.

На следующей неделе я выпущу набор шаблонов VS для UWP, которые позволят создавать приложения за считанные секунды. Это использовалось для «внутренних» проектов. Это докажет, что UWP может быть готовой инфраструктурой RAD, если только в VS будут встроены нужные строительные блоки.

На следующей неделе я выпущу набор шаблонов VS для UWP, которые позволят создавать приложения за считанные секунды. Это использовалось для «внутренних» проектов. Это докажет, что UWP может быть готовой инфраструктурой RAD, если только в VS будут встроены нужные строительные блоки.

@Noemata Звучит круто! Мне очень любопытно!

Если вам всем нужна кроссплатформенная среда пользовательского интерфейса на основе .Net, которая может адаптироваться к любому языку дизайна. Не смотрите дальше, это Комета.

https://github.com/Клэнси/Комета

Если у вас есть свободное время, сделайте свой вклад, так как он все еще находится на ранней стадии.
Comet нацелен практически на все существующие платформы, и это дает вам выбор: нацеливаться на собственное управление на каждой платформе или использовать Skia для отрисовки всего, чтобы все они были согласованы (именно так, как это делает Flutter).

Он использует декларативный пользовательский интерфейс и шаблон MVU. Он разработан Джеймсом Клэнси, главным архитектором программ в Microsoft. Хотя он еще официально не поддерживается, но при достаточной поддержке сообщества это может быть.

В Comet пользовательский интерфейс — это просто библиотека, поэтому вы (или, возможно, Microsoft может) можете разработать библиотеку WinUI, точно так же, как у Comet есть библиотека Material Design.

Если вам всем нужна кроссплатформенная среда пользовательского интерфейса на основе .Net, которая может адаптироваться к любому языку дизайна. Не смотрите дальше, это Комета.

@nerocui это звучит круто, но, по крайней мере, если посмотреть на это, нет конструктора XAML. Создание сложных пользовательских интерфейсов, вероятно, безумие на нынешнем этапе. Но выглядит многообещающе.

Если вам всем нужна кроссплатформенная среда пользовательского интерфейса на основе .Net, которая может адаптироваться к любому языку дизайна. Не смотрите дальше, это Комета.

@nerocui это звучит круто, но, по крайней мере, если посмотреть на это, нет конструктора XAML. Создание сложных пользовательских интерфейсов, вероятно, безумие на нынешнем этапе. Но выглядит многообещающе.

И речь идет не о перетаскивании, а о предварительном просмотре UI в дизайнере в реальном времени при внесении изменений в код.

На следующей неделе я выпущу набор шаблонов VS для UWP, которые позволят создавать приложения за считанные секунды. Это использовалось для «внутренних» проектов. Это докажет, что UWP может быть готовой инфраструктурой RAD, если только в VS будут встроены нужные строительные блоки.

Это использует NoesisGUI? Если это так, то существует МНОЖЕСТВО отсутствующих функций, которые были бы необходимы для бизнес-приложений. Теперь WinUI, ориентированный на Unity, был бы потрясающим.

Я создал репозиторий для документирования текущего состояния XAML, и надеюсь, что люди помогут и внесут свой вклад с идеями и фактическими фрагментами кода, в которых перечислены способы выполнения задач в различных вариантах XAML.

https://github.com/gatewayprogrammingschool/XAML-стандартизация

Простая проблема, выйдите за рамки сегодняшней песочницы и примите то, что требуется для кроссплатформенности. Уже делаю это для всех остальных аспектов Windows/OS, почему бы и не для пользовательского интерфейса.

Возьмите кросс-платформу песочницы.

От: [email protected]
Отправлено: суббота, 29 февраля 2020 г., 20:00:13
Кому: microsoft/microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Комментарий [email protected]
Тема: Re: [microsoft/microsoft-ui-xaml] Обсуждение: WinUI должен быть кроссплатформенным (#2024)

Простая проблема, выйдите за рамки сегодняшней песочницы и примите то, что требуется для кроссплатформенности. Уже делаю это для всех остальных аспектов Windows/OS, почему бы и не для пользовательского интерфейса.

—
Вы получаете это, потому что вы прокомментировали.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 или отписки https://github.com/ уведомления/отказ от подписки-авторизация/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

Интеграция высокопроизводительных компонентов C++ с C# в UWP является тривиальной задачей. Доступ к поверхностям DirectX также значительно улучшен.

@Noemata За исключением того, что меня волнует то, что мне не нужно писать C++ для начала, WinDev продолжает проваливать все попытки, которые могли бы сделать языки .NET равными друг другу в отношении API C++, Managed Direct X, XNA, правильной AOT-компиляции .NET код, функции COM, ....

Создание кроссплатформенности WinUI 3.0 будет аргументом в пользу переноса существующих приложений .NET/Forms на WinUI.

Для начала будет достаточно поддержки macOS, и не проблема, если у него не такая производительность, как на Windows, или не все функции вроде анимации.

Windows является эталонной платформой; конечно, он должен быть связан с DirectX для лучшей производительности.

На мой взгляд, нет смысла пытаться переписывать большие приложения C # в HTML + JS только для поддержки macOS. А также для новых настольных приложений C# является лучшим выбором.

Для настольных приложений C# и XAML намного надежнее, чем HTML+JS.

Кроссплатформенность WinUI 3.0 обеспечивает будущее .NET, C# и XAML.

Всем привет

Я работаю контрактным разработчиком WPF в Лондоне. С 2006 года я создаю сложные высокопроизводительные пользовательские интерфейсы с помощью WPF для ряда финансовых учреждений. Вот мое мнение по этому поводу:

1) Я внимательно слежу за рынком труда в Великобритании. 100% вакансий WPF, объявленных с 2006 года (из них 1000), предназначены для создания высокопроизводительных настольных приложений для финансового трейдинга для финансового сектора. До сих пор не было объявлений о вакансиях разработчика UWP для какой-либо отрасли.

2) Эти настольные торговые приложения не могут использовать UWP или будущий WinUI — он просто недостаточно хорош по сравнению с WPF по множеству сложных причин. Кроме того, Fluent design — это не то, что интересует этих пользователей — он просто должен выглядеть как сетка Excel — без анимации, без стилей — только данные и потрясающая производительность.

3) Эти клиенты совершенно не заинтересованы в кроссплатформенных решениях. Никто не использует Mac, а мобильные устройства их не интересуют.

4) Эти команды разработчиков WPF вложили большие средства (время и деньги) в сторонние библиотеки элементов управления WPF или разработали для них сложные, производительные наборы пользовательских элементов управления с помощью таких людей, как я. Они не собираются отходить от WPF, если не будет очень значительной выгоды (которой не будет в обозримом будущем)

5) Для этих финансовых учреждений любое приложение, которое не нужно писать специально для рабочего стола / WPF, пишется с использованием веб-технологий и Javascript. Их не интересует ничего более экзотического, чем это - ни трепыхание, ни блейзер и т.д.

Такова ситуация в Великобритании. Сотни разработчиков WPF не хотят в ближайшее время переходить на что-то новое. Нет разработчиков UWP (за исключением, возможно, нескольких человек, разрабатывающих приложения для магазина, что сомнительно, учитывая состояние магазина)

Кроме того, я не понимаю всей этой истерии по поводу кроссплатформенности. Кросс-платформа, которая охватывает как мобильные, так и настольные компьютеры, — дурацкая затея. Никогда не будет интересно. Microsoft попробовала это с приложениями UWP, которые работали на настольных компьютерах и телефонах — это была катастрофа — ограничить приложения простейшим пользовательским интерфейсом, который не мог сделать ничего сложного или интересного. Настольные и мобильные устройства созданы для разных задач и вариантов использования и требуют разных приложений — мы все это знаем.

Что касается меня, я хочу, чтобы моя Microsoft напрямую инвестировала в WPF, не жертвуя обратной совместимостью. Я хочу увидеть разработку поддержки управления WPF в неуправляемом C++, чтобы мы могли работать ближе к металлу. Я хочу видеть лучшую технологию связывания, лучшее шаблонирование данных, лучшую функциональность шаблонов управления, включая частичное наследование. Я хочу видеть лучшие инструменты отладки и анализаторы визуального дерева. Я хочу, чтобы отладка XAML была более подробной. Я хочу лучшую поддержку многопоточности в пользовательском интерфейсе. Я хочу много-много вещей, как и мои коллеги-подрядчики WPF из Великобритании.
Текущая дорожная карта Microsoft не дает мне ничего из того, что я хочу, и всего того, что меня не волнует.

Если Microsoft не поддержит это видение (чего они явно не поддерживают прямо сейчас), то планом Б будет то, что сообщество превратит WPF в платформу, которой он должен быть, с помощью вкладов с открытым исходным кодом — при условии, что Microsoft примет более легкий подход, когда дело доходит до разрешения новых код и идеи, чтобы стать частью платформы WPF.

@deanchalk Я думаю, что большую часть этого, возможно, лучше было бы разместить в репозитории WPF, чтобы показать им, что есть интерес к WPF, размещение его здесь в основном говорит о том, что вам не интересно, что делается в репозитории WinUI / обсуждается в этом выпуске. Хотя это действительный ввод, он, вероятно, не приведет к чему-то конструктивному, кроме пустой дискуссии.

@weltkante @deanchalk В репозитории есть проблема с запросом «поддержки устаревшего управления» в WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/1833.
По крайней мере, пункт 4) подходит к этой проблеме и, вероятно, должен быть повторно размещен там, чтобы обосновать инвестиции Microsoft.

@deanchalk , я все еще большой поклонник WPF. Это замечательный инструмент, который, к счастью, начинает получать некоторую любовь от Microsoft. Способ, которым Microsoft решила отказаться от WPF, был самым неудачным. UWP, будучи новой блестящей игрушкой, не должен был препятствовать дальнейшим инвестициям в WPF.

UWP был во многих отношениях правильным путем вперед. К сожалению, первые итерации игнорировали некоторые из наиболее важных требований для людей, которые использовали WPF и могли подумать о миграции. Не последним из них является довольно поразительное состояние фрагментации XAML в стенах одной организации. WPF != Silverlight != UWP != Xamarin. Ух ты!

Я меньше сочувствую разработчикам WPF, которые решили закрепиться в WPF в 2020 году. Дело значительно продвинулось вперед. XAML Islands с возможностью использования WinRT API дают вам довольно простой способ начать миграцию на UWP. И UWP больше не будет недоставать, если вы решили сделать оптовую конверсию.

Более серьезной проблемой остается отсутствие ясности со стороны Microsoft относительно того, что на самом деле будет дальше. Все те, кто надеялся на XAML Nirvana, разочаровались в фиаско Silverlight, которое снова повторяется с UWP.

WinUI — это настолько явно переименованная UWP, что больно смотреть на это. И столь же очевидно, что Microsoft надеется, что мы все забудем, что такое UWP.

Тем не менее, левая рука Microsoft не всегда в гармонии с тем, что делает правая рука. WindowsX сделала Win32 и все, что с ним связано (WPF/Winforms/и т. д.), ненадежной перспективой для приложений, которые «могут» работать в песочнице с более низкой производительностью. UWP есть и в настоящее время остается родным пользовательским интерфейсом для Windows 10, WindowsX и более поздних версий. WinRT API — это большое улучшение по сравнению с Win32. Так что, я думаю, вам придется выбирать, хотите ли вы переехать в 2020-е или застрять в 2010-х.

WinUI — это настолько явно переименованная UWP, что больно смотреть на это. И столь же очевидно, что Microsoft надеется, что мы все забудем, что такое UWP.

@Noemata WinUI — это новый продукт, основанный на API-интерфейсах UWP (XAML, Composition, Input,...). Название имеет смысл, поскольку вы сможете использовать его для создания пользовательского интерфейса для приложений Windows независимо от базовой модели приложения.

Я запутался. Вы сами упоминаете 10X в последнем абзаце. Сама модель приложения UWP получает толчок в Windows 10X. Теперь, удастся ли 10X, покажет только время. Но MS ясно выразилась в своих сообщениях: UWP — это собственная платформа 10X (наряду с веб), как вы указали.

@Noemata до 2020 года догонит функции, доступные в 2010 году, многие из нас вынуждены оставаться в 2010 году.

Многие из нас просто устали от переписывания поезда, который начался с отказа от Silverlight, XNA и наблюдения за тем, как MS вручную машет переписыванием, требующим перезаписи для .NET Core, WinUI, отказываясь от функций в процессе, не завоевывает сердца многих из наших. клиенты с полностью работающими приложениями, которые не понимают, почему они должны платить за переписывание, чтобы вернуть меньше функций.

Прямо сейчас, благодаря умению иметь планшеты Android и Windows 10 X, мы ожидаем Xamarin и PWA, а не WinUI.

@pjmlp , возможно. Мне интересно, какой функции вам не хватает? Я перенес несколько довольно больших приложений WPF на UWP. Самой большой головной болью была песочница безопасности и обучение работе с ней, а не борьбе с ней. Ранее отсутствовали такие элементы, как Data Grid, подключение к БД, достойный API для высокоскоростной связи и так далее. Сейчас мало чего не хватает. Многое я не мог сделать так же легко в WPF. Честно говоря, в настоящее время я ничего не могу сделать в WPF, используя доступ к WinRT API, за исключением того, что у меня будет более низкая производительность, потому что UWP компилирует машинный код более оптимальным образом и использует лучший стек рендеринга DirectX. Кроме того, вы должны запутать свой код WPF (сделать его более уязвимым), если вы намерены защитить свой IP или предотвратить злоумышленников.

Телефоны/планшеты — отличные устройства для точечных приложений. Я бы не хотел писать музыку для симфонии на телефоне или проектировать небоскреб, и я бы предпочел нацелить часть точечных решений моего настольного приложения на мобильные устройства, чем пытаться заставить мобильные устройства работать на моем рабочем столе.

@ Felix-Dev Я понимаю, что такое WinUI. Я задаюсь вопросом, почему потребовался еще один форк только потому, что разработчики WPF, Winforms и MFC/Win32 не купились на него. Лучшей стратегией было бы сделать миграцию либо более привлекательной, либо менее болезненной, либо и то, и другое.

Microsoft сделала многое правильно с UWP. Существует множество примеров приложений, охватывающих все виды вариантов использования. Они прибыли поздно, как и недостающие функции. Неужели уже слишком поздно?

@Noemata WinUI, вероятно, произошел бы в любом случае (с WinUI Desktop или без него), поскольку отделение стека пользовательского интерфейса UWP от ОС является абсолютно необходимым шагом. Было бы лучше, если бы WinUI уже существовал, когда Windows 10 была впервые выпущена, но есть причины, по которым это не так.

Что касается того, не слишком ли поздно… у нас было много таких обсуждений на канале разногласий сообщества UWP, а также бесчисленное количество страстных обменов здесь. Некоторые из нас думают, что корабль уже отплыл, в то время как другие все еще думают, что есть шанс, что платформа UWP/WinUI может расти и развиваться, чтобы стать основной платформой для разработчиков. Много людей с множеством идей о том, как может выглядеть лучший подход для MS (т.е. перейти на xplatform или нет?). Дело в том, что команда в настоящее время усердно работает над WinUI 3, и его выпуск будет сигнализировать о начале решения реальной задачи: продвигать WinUI вперед — с помощью сообщества — чтобы он стал предпочтительным фреймворком для разработчиков, ориентирующихся на Windows. .

@Noemata , в первую очередь совместимость с существующими библиотеками сторонних компонентов, таких как Telerik, Component One, ...

Тогда не нужно ничего переписывать для начала, как уже упоминалось, мы сыты по горло переписыванием.

Что касается DirectX, то не только классы 3D-моделирования из WPF не поддерживаются, от нас ожидают написания C++, потому что Microsoft не утруждает себя созданием Runtime-проекций для DirectX, а какой-то приятный диалект C++/CX был заменен многословным менее способный, но лучше совместимый, C++/WinRT.

Кроме того, мы не только должны выбросить отлично работающий код WPF, мы должны сделать то же самое с кодом WCF, EF6.

Я по-прежнему считаю, что UWP намного лучше API, чем Win32, каким должен был быть Longhorn, но то, как это происходит, просто сожгло слишком много мостов, так как Microsoft сожгла бюджет перезаписи многих организаций.

@pjmlp , это все хорошие моменты с довольно скромными контраргументами, поэтому я даже не буду пытаться. Отсутствие поддержки WPF 3D API лично для меня стало большим ударом. Изучать новый подход было неинтересно и гораздо менее способно, учитывая параметры привязки WPF для 3D. Существуют альтернативы C# для 3D в UWP, но они менее полезны после того, как вы ощутили преимущества привязки к 3D-модели.

C++/CX — еще одна болевая точка, решение которой заняло слишком много времени с помощью C++/WinRT, которая может стать стабильной на следующей неделе (она все еще меняется).

WCF мертв (извините, новые варианты намного лучше). EF6 должен был иметь лучшую историю миграции. Вы абсолютно правы в фиаско с переписыванием бюджета @pjmlp , очевидно, это то, что Microsoft использовала для получения и больше не заботится о том, чтобы учитывать сумасшедший / непоследовательный отток технологий.

@ Феликс-Дев, ты тоже делаешь абсолютно правильные выводы. Разделение пользовательского интерфейса должно было быть с самого начала. Люди, запрашивающие пользовательский интерфейс xplatform на основе XAML, должны перефразировать свой запрос и запросить механизм рендеринга XAML на выбранной ими платформе с мини-ОС для репликации поверхности API (другая платформа Java/Silveright/Uno/Unity/что угодно… в конечном итоге заканчивая HTML, который близко к металлическим приложениям не может быть рассмотрен). На данный момент я не знаком с последними внутренними инициативами MS. Глядя наружу, WinUI представляет собой развевающийся флаг, указывающий на то, что корабль снова выправляется (сколько еще раз?). Защита Microsoft стала невозможной после смерти Silverlight. Я больше не возьму в руки этот меч. Я полагаю, что на самом деле я оплакиваю смерть UWP :-( ... болезненно. https://www.youtube.com/watch?v=uBiewQrpBBA

Чарли == Майкрософт

Кроссплатформенность? Microsoft должна просто купить UNO и покончить с сиськами.

Кроссплатформенность? Microsoft должна просто купить UNO и покончить с сиськами.

Я надеюсь, что какое бы решение ни представилось, оно не будет зависеть от веб-браузера или какого-либо веб-представления. Отображать пользовательский интерфейс в любом родном окне платформы или поверхности пользовательского интерфейса, но выглядеть так же, как в Windows.

Кроссплатформенность? Microsoft должна просто купить UNO и покончить с сиськами.

Я надеюсь, что какое бы решение ни представилось, оно не будет зависеть от веб-браузера или какого-либо веб-представления. Отображать пользовательский интерфейс в любом родном окне платформы или поверхности пользовательского интерфейса, но выглядеть так же, как в Windows.

Вот как это делает UNO, за исключением Windows 7. Windows 7 является единственным исключением, поскольку она использует веб-браузер.

Для тех разработчиков WPF, которым требуется кроссплатформенное настольное решение, Wine может оказаться подходящим вариантом. Я добился большого успеха при портировании больших приложений WPF (в основном .NET Core WPF) для работы в Linux с помощью Wine. У меня есть запись, которая может помочь вам начать:
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

Я также начал портировать некоторые приложения WinForms на Linux. До сих пор я не сталкивался с какими-либо проблемами.

Wine также должен позволять вам работать на Mac, Chrome OS и Android. Я пробовал только линукс.

Для меня это показывает, что использование DirectX в качестве уровня абстракции работает и является жизнеспособной моделью для подражания. Я подозреваю, что он будет хорошо работать даже в Интернете с WebGL, как только .NET WASM станет более зрелым.

Если Microsoft поможет с Wine (по крайней мере, убедитесь, что они не сломают его), это очень поможет. Они могли бы помочь создать действительно нативное решение с WineLib, и, учитывая их опыт, я не думаю, что это потребует слишком много усилий.

AvaloniaUI уже ЯВЛЯЕТСЯ кроссплатформенным. Почему бы не обратиться к участникам проекта за помощью и отзывами для улучшения WinUI?

Ну, не так сильно, как Uno Platform. Платформа Uno также работает в Интернете (WASM). В Авалонии такой возможности нет.

Avalonia также использует собственный диалект XAML, чего Uno пытается избежать.

От: [email protected]
Отправлено: пятница, 27 марта 2020 г., 4:09:30
Кому: microsoft/microsoft-ui-xaml [email protected]
Копия: The Sharp Ninja [email protected] ; Комментарий [email protected]
Тема: Re: [microsoft/microsoft-ui-xaml] Обсуждение: WinUI должен быть кроссплатформенным (#2024)

AvaloniaUI уже ЯВЛЯЕТСЯ кроссплатформенным. Почему бы не обратиться к участникам проекта за помощью и отзывами для улучшения WinUI?

Ну, не так сильно, как Uno Platform. Платформа Uno также работает в Интернете (WASM). В Авалонии такой возможности нет.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 или отмените подписку https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA .

Большая часть технологии WinUI исходит от Sliverlight, и Sliverlight фактически достиг кросс-платформенности. Таким образом, кроссплатформенность WinUI зависит от стратегии, а не технологии.

Честно говоря... это на самом деле так жалко, что Microsoft сейчас пытается играть в догонялки... они заботятся только о "большой" доле рынка, они не смотрят на то, что хотят их клиенты/поклонники продукта.

Microsoft является причиной того, что разработка DESKTOP APP перешла к устаревшей WEB-разработке, даже когда веб-это так ужасно.

Я уверен, что все XAML-разработчики согласны с тем, что HTML/CSS — это мусор.

Но все же... HTML, CSS, DOM... с такими фреймворками, как React, Angular, Vue, которые пытаются сделать что-то более приятное. Люди по-прежнему сосредоточены на этой устаревшей сети, а не на новой платформе Microsoft с закрытым исходным кодом, предназначенной только для Windows, которая умирает каждые 2-4 года в пользу новой.

Платформа Win-приложения на основе XAML должна была иметь открытый исходный код ГОДЫ назад. Он должен иметь запись после развертывания на ВЕБ-САЙТЕ, Windows, Mac, Linux, Android (любая платформа, которую хочет клиент). Магазин Windows должен был быть кроссплатформенным с средством визуализации приложений XAML/UWP. (аналогично тому, как Google Chrome является кроссплатформенным с визуализатором HTML/CSS).

Во времена золотого века Microsoft кроссплатформенное приложение на основе XAML могло уничтожить Интернет, тогда нам не пришлось бы иметь дело с этими CSS, HTML, DOM и бесчисленными фреймворками.

Но нет, одержимость Microsoft проприетарным программным обеспечением заставила их проиграть Интернету.

Тем временем Flutter от Google становится тем, что я всегда хотел для XAML.

Я ожидаю, что WinUI 3 станет целевой платформой в MAUI. Платформа Uno уже объявила о поддержке WinUI 3 Preview.
Итак, @jeromelaban / Microsoft, что нам действительно нужно, так это унификация Uno/MAUI? MAUI менее полезен, чем Flutter или Uno без веб-цели (браузера).

Пожалуйста, оставляйте свои комментарии и в репозитории MAUI .

WPF (Silverlight) везде!

Портирование DirectX на другие платформы кажется огромной работой, возможно, решение состоит в том, чтобы использовать OpenGL или Vulkan вместо DirectX.

У Google есть ANGLE, который позволяет запускать OpenGL ES изначально на любой платформе, переводя вызовы и шейдеры в собственный API (рабочий стол gl [возможно, предоставляется программным рендерером swiftshader], vulkan, directx, metal). Это также основная часть Chrome и Flutter, работающая вместе со Skia.

Microsoft может сделать небольшое (возможно, просто в качестве отправной точки) подмножество DirectX для приложений с графическим интерфейсом и перевести его в собственные API, как это делает ANGLE.

Что касается проблемы «поддержки разных дистрибутивов Linux», пользователи Linux часто достаточно опытны, чтобы самостоятельно исправить несовместимость, и даже в этом случае существует Flatpak, который унифицирует упаковку для настольных компьютеров так же, как Docker делает это для серверов.

Упоминание в чате Lonje https://www.lonje.com/message/1968439855/

Я действительно думаю, что WinUI также должен поддерживать собственные темы на Mac и Linux, сохраняя при этом поддержку пользовательских тем.
Я не уверен насчет пользователей Mac, но сообществу Linux нравится контролировать внешний вид своего рабочего стола.
У них уже есть Gtk, который, я думаю, было бы неплохо включить в фреймворк WinUi.

Я действительно думаю, что WinUI также должен поддерживать собственные темы на Mac и Linux, сохраняя при этом поддержку пользовательских тем.
Я не уверен насчет пользователей Mac, но сообществу Linux нравится контролировать внешний вид своего рабочего стола.
У них уже есть Gtk, который, я думаю, было бы неплохо включить в фреймворк WinUi.

Это определенно сложно сделать, поскольку WinUI — это язык стилей, а лежащие в его основе платформы XAML требуют, чтобы вы сами создавали темы, в то время как темы по умолчанию также предоставляются.

В прошлом я предлагал структурировать проект таким образом, чтобы сообщество могло разработать средство визуализации Metal для macOS и iOS и, возможно, средство визуализации Skia для Android.

Одни и те же стили и шаблоны по умолчанию можно использовать на всех платформах, или можно создавать шаблоны и ресурсы по умолчанию в стиле Android и macOS.