Maui: Кроссплатформенный UX для .NET 5

Мне нравится эта идея. Однако на практике с этим, скорее всего, справится команда Xamarin.Forms.
Возможно, команда Core внесет некоторые низкоуровневые конструкции, чтобы сделать UX-фреймворк «лучше» (например, то, что делает CoreFxLab).

Изменить: может ли WebAssembly также стать поддерживаемой платформой?

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

Я почти уверен, что в обозримом будущем мы увидим перенос ядра .net на устройства Android и iOS с использованием приложения Native в качестве замены corehost . При этом потребуются возможности пользовательского интерфейса.

Например, для библиотек 2D xplat Drawing (включая ускоренное рисование) у нас есть Skia.

Я считаю, что во всех сценариях будет полезно перейти на XAML-Standard, чтобы достичь стандартного способа «описания» пользовательского интерфейса вместе с рекомендациями Fluent Design.

Тем не менее, я скептически отношусь к тому, что у .Net Team есть какие-либо планы потратить время на это больше, чем просто вернуть некоторые примитивы xplat System.Drawing.X ...

@4creators Возможно, это обсуждение вас заинтересует

@vibeeshan025 WebAssembly не является заменой JavaScript, поэтому большая часть вашего комментария на самом деле не имеет никакого смысла. Вам по-прежнему потребуется JavaScript для подключения WebAssembly к DOM. Так что нет, вы не можете просто скомпилировать что-то в wasm и ожидать, что он заменит все, что вы делали раньше, с помощью JavaScript. Это не так работает. Это не будет технология пользовательского интерфейса.

Эй, ребята, просто хочу поставить свой 5c здесь.
System.Drawing.X необходим для разработки .NET Core. (только что пришел сюда с https://github.com/dotnet/corefx/issues/20325)

Что касается пользовательского интерфейса — спросите веб-разработчиков (front-end). Они используют множество современных приемов, таких как горячая перезагрузка.
Лично мне нравится, как продвигаются дела вокруг React/ReactNative. Было бы здорово использовать C# для написания React, а затем использовать различные механизмы рендеринга для разных платформ.

FWIW, Mono принимает WebAssembly , поэтому, если он работает в Mono, он работает (или будет работать) в WebAssembly. По крайней мере, это нынешняя идея/понимание.

Кроме того, я должен повторить мнение о вероятности того, что .NET/MSFT выполнит эту задачу. Все их внимание/IQ было сосредоточено на ядре/внутренностях/структуре/просто-получи-работу, и я думаю, что так будет еще год или около того. Но кто знает, я могу быть (приятно) удивлен.

Я считаю, что некоторые внешние усилия будут набирать обороты и, возможно, будут куплены MSFT, аля Xamarin, но более ориентированными на пользовательский интерфейс (в отличие от ориентированных на фреймворк/инструменты, что является основной силой Xamarin IMO). Итак, что-то вроде Avalonia или Noesis , которые предлагают свои ценностные предложения через каналы с открытым исходным кодом и платные каналы соответственно. Между прочим, оба они встроены/поддерживают Mono.

Xaml Standard немного изменился с выпуском XAML Standard (Preview) для Xamarin.Forms и давно назревшим обновлением о ходе проекта . В PR dotnet/designs#111 ведется очень интересная дискуссия о целях проекта, которая, похоже, идет в направлении, выгодном для этого предложения.

Silverilght — отличное решение, код уже существует.

1. Код Silverlight с открытым исходным кодом
2. Сделайте так, чтобы он работал поверх среды выполнения ядра dotnet.
3. использовать лунный свет для дистрибутива Linux
4. создать альтернативу ядра dotnet для «Электрона», она уничтожит мир (меньше использования памяти + огромное улучшение производительности + совершенство xaml)
5. нативная компиляция (если однажды проект Corert увидит свет)

Нашел это актуальным - http://platform.uno

@gulshan Интересный, отличный проект, поддерживает ли он большую часть функций UWP, как им удалось реализовать такой богатый набор функций за очень короткое время, всего с 4 участниками.

@vibeeshan025 у них есть компания, финансирующая IIRC...

Еще одно будущее, которое стоит изучить — HTML/CSS + .net (вместо JS/TS). Здесь уже судят-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

После исследования кажется, что tcl/tk может быть вариантом графического интерфейса для всех платформ. Не уверен, что tcl / tk в Windows вызывает фактический материал gdiplus, но может быть вариант перенести WPF и Winforms в Linux, Mac, Windows, Android?, iOS?, И, может быть, веб-формы? Не уверен, поддерживает ли tcl/tk эти 3 последних. Если это так, это значительно упрощает поддержку графического интерфейса с единой кодовой базой.

Возможные библиотеки GUI для использования:

• TclBridge (похоже, он не бесплатный или с открытым исходным кодом)
• моно один (вероятно, лучший, может быть)
• Орел (не уверен, насколько он хорош)
• Может и другие.

У меня появилась идея использовать tcl/tk из модуля tkinner cpython.

Также не уверен, поддерживает ли .NET Core загрузку ресурсов из *.resources(скомпилированный resx) или даже из *.resx. Если получится, было бы здорово.

Microsoft.DesktopUI.App настоящее время доступна версия 3.0.0-alpha-26921-3 с ежедневными сборками Windows .NET Core SDK . Мне любопытно, что потребуется, чтобы запустить его в Linux под некоторыми уровнями перевода для GDC и DirectX.

Это должно быть нечто большее, чем кроссплатформенный UX, это должна быть кроссплатформенная среда разработки приложений.
Ограничивать его только UX — ошибка. Он должен как минимум иметь все функции SilverLight + RIA-Services.
Когда вы пишете огромные пользовательские системы для крупных компаний, которые будут жить десятилетиями, вам нужно держать все варианты открытыми, поскольку вы понятия не имеете, какие требования будут добавлены через год (или через 10 лет), поэтому закрытая и ограниченная среда как UWP никогда не будет рассматриваться, то же самое с чем-то, работающим внутри браузера. Должен быть полный, неограниченный и собственный доступ к каждой отдельной функции, API и сервису на разных платформах.
И когда вы разрабатываете систему, где вы пишете и сервер, и клиент, то вы не хотите использовать REST или что-то в этом роде (которое предназначено для использования, когда вы пишете сервер, а клиент пишет кто-то другой), вместо этого он должен быть в духе RIA, где вы определяете серверный API, а затем автоматически просто вызываете его из клиента, используя те же (===) классы и методы, что и на сервере. Все должно быть строго типизировано. Проверка данных начинается с жестких ограничений, полученных из полей на сервере SQL (или любого другого источника данных, который вы используете), и расширяется за счет аннотаций данных, которые автоматически распространяются на весь путь до клиента (с учетом локализации).

Это то, что нужно, меньшее не приемлемо:
Создайте повсеместную модель разработки клиентских приложений .NET

Прошло уже 20 лет с момента выпуска Visual Basic 6, и мы далеки от той производительности, которая была в 1998 году.Microsoft необходимо представить свое видение того, как должна быть создана более крупная пользовательская система в «мире Microsoft», и как они вернут производительность, которая была у нас 20 лет назад.

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

И забудьте о Xamarin, Microsoft даже не использует его сама , а скорее использует однопоточный фреймворк, требующий много памяти, такой как фреймворк ElectronJS (на основе Chromium, Node.js, JavaScript и CSS), чем использует Xamarin, которым они владеют и иметь полный контроль и создавать настоящий нативный код для каждой платформы.

@ Бартоломеус-649

Прошло уже 20 лет с момента выпуска Visual Basic 6, и мы далеки от той производительности, которая была в 1998 году.

И распространение использования компьютеров и Интернета, а также разнообразие платформ (ОС/мобильность/форм-факторы) далеко не так низко, как в 1998 году.

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

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

Я надеюсь, что мы получим лучший кроссплатформенный опыт, но я не думаю, что это будет легко или выдержит испытание временем. Даже если WebAssembly и электронные оболочки, PWA и им подобные станут популярным решением в ближайшие 5 лет, через 20 лет мы можем делать что-то совершенно другое (и тогда мы будем жаловаться на то, как легко все было в 2018 году 😂 ).

Microsoft оправдала наши ожидания и предоставила UX-фреймворки с открытым исходным кодом. Теперь мы можем запускать проекты сообщества, чтобы портировать их на другие платформы. К сожалению, MSFT прямо заявила, что не планирует работать ни с какими портами, поэтому, похоже, эта работа оставлена ​​сообществу.

@richlander @karelz @AdamYoblick @llongley @kmahone

Мой вопрос: можем ли мы, сообщество, работать над портами Linux и macOS в существующих репозиториях, то есть в отдельных ветках, или нам следует создавать отдельные репозитории для поддержки таких проектов? Это очень важное решение, поскольку использование существующих репозиториев позволит нам интегрировать порты с инфраструктурой MSFT CI, которую в противном случае пришлось бы настраивать с нуля сообществом.

Есть ли причина, по которой Xamarin.Forms/Avalonia/Platform.Uno не соответствует вашим потребностям? Кажется, что новая попытка внедрить кроссплатформенный XAML мало что дает сообществу в целом.

Не 4creators, а мои 2 цента/впечатления:

• Xamarin.Forms, по-видимому, в основном ориентирован на мобильные сценарии.
• То же самое для Platform.Uno
• Авалония еще не готова к прайм-тайму. Слишком глючный, чтобы я хотел ему доверять. (В прошлый раз, когда я проверял это, демонстрационное приложение даже не встроилось в текущую стабильную версию, не внушает доверия.)

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

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

Кстати, есть какие-то болевые точки в NoesisGUI?

сообщество может работать над портами Linux и macOS

@4creators Создавайте ответвления, которыми вы владеете и полностью контролируете.

CI-инфраструктура

Инфраструктура .NET Core CI движется к использованию обычного Azure DevOps вместо текущего пользовательского решения на основе Jenkins. Azure DevOps предлагает бесплатное предложение для проектов с открытым исходным кодом, которые вы можете использовать.

Говоря только о dotnet/winforms:

Winforms уже использует AzureDevOps, и любой PR в master автоматически запустит сборку PR CI.

Тем не менее, я почти уверен, что любая работа должна выполняться в вилке. Мы не планируем предоставлять доступ на запись к dotnet/winforms только для того, чтобы люди могли создавать свои собственные ветки. Со всеми публичными вкладами это немного загрязнит наш репозиторий. :)

Кстати, есть какие-то болевые точки в NoesisGUI?

Каким-то образом NeosisGUI был избавлен от моих заметок о различных фреймворках пользовательского интерфейса, поэтому мне пришлось просмотреть его снова.

Я им не пользовался, хотя и собирался попробовать. У меня сложилось впечатление, что он предназначен для поддержки внутриигрового пользовательского интерфейса, поэтому он может не подходить для инструментов. (Хотя глядя на список элементов управления, это может быть плохим предположением.) Что касается внутриигрового пользовательского интерфейса, наши потребности не оправдывают будущих затрат. Он также не поддерживает Nintendo Switch по какой-то причине. (Хотя, судя по всему , работа продолжается .)

@4creators Я думаю, что эта проблема названа неправильно из-за смешения двух проблем.

Во-первых, разрешить платформам пользовательского интерфейса .Net использовать .Net Core вместо других сред выполнения .Net . Теперь WPF может работать на .Net Core, и они также могут заставить Xamarin.iOS/Android/Mac/GTK работать на .Net Core. Это дает преимущества в производительности и обслуживании по сравнению с использованием Mono или .Net Framework.

Однако это не создает новую кросс-платформенную структуру пользовательского интерфейса . И темы, на которые вы ссылаетесь, и большинство сообщений здесь посвящены созданию новой кросс-платформенной среды пользовательского интерфейса. Время выполнения здесь не главное. Однако эти потоки чрезвычайно запутаны, потому что они не решают реальных трудностей реализации кросс-платформенного пользовательского интерфейса, которые были решены реальными реализациями (Xamarin.Forms, в основном использующие собственные элементы управления, и Avalonia, использующие общий рендеринг).

Лучше поработать над улучшением возможностей рабочего стола Xamarin.Forms, добавив соответствующие элементы управления рабочим столом (несложно), или внести свой вклад в обеспечение стабильности Avalonia, если хотите. Для любой новой платформы (даже если она основана на существующей одноплатформенной) потребуются годы работы, чтобы достичь альфа-качества, и единственное оправдание для переделки Xamarin.Forms и Avalonia вместо того, чтобы вносить в них вклад, заключается в том, что они оба делают это. неправильно.

Я согласен с последней частью. Однако команда Xamarin прямо заявила, что замена Mono на .NET Core невозможна, поскольку они оптимизированы для разных рабочих нагрузок, и потребуется выполнить значительную нетривиальную работу по интеграции.

Я думаю, что этот вопрос неправильно назван из-за смешения двух вопросов.

@charlesroddie ИМО, не совсем так. Дело не в том, чтобы на платформе .NET Core была доступна какая-то инфраструктура UX, а в том, чтобы UX, являющийся частью экосистемы DotNet, создавался и поддерживался совместно с другими частями. Планы MSFT на будущее для экосистемы .NET включают .NET Core на основе .NET Framework, устаревший компонент Windows, который не рекомендуется для разработки новых приложений. В настоящее время нет планов переноса Xamarin.Forms на .NET Core по некоторым причинам, указанным выше @Happypig375 , а другой причиной является отсутствие решения о том, как продолжить поддержку xplat на мобильных устройствах. Однако я предполагаю, что благодаря усилиям по разработке, вложенным в .NET Core, будущая платформа xplat, используемая MSFT, будет основана на .NET Core.

Mono недостаточно оптимизирован для многих рабочих нагрузок даже в Linux, и больше нет новых важных функций, разработанных поверх этой среды выполнения. В настоящее время BCL совместно используется Mono и .NET Core. Это указывает на высокую вероятность устаревания Mono в будущем.

Основываясь на этом предположении, я думаю, что стоит иметь единую UX-платформу на основе .NET Core как часть своей экосистемы. Таким образом, название проблемы точно такое, каким оно должно быть, поскольку я не прошу какой-либо UX-фреймворк, который является xplat и основан на стандарте CLI, а UX-фреймворк, который является частью экосистемы .NET Core, разработанной и поддерживаемой командой DotNet.

.Net Standard гарантирует, что разные среды выполнения пользовательского интерфейса могут быть частью одной и той же экосистемы без проблем. Хотя у .Net Core есть преимущества по сравнению с другими средами выполнения, которые со временем могут обесцениться, нет необходимости связывать среду выполнения с поиском правильного подхода к кроссплатформенному пользовательскому интерфейсу. Это просто слишком усложняет вопрос.

Было бы слишком далеко говорить, что платформа UX «основана» на конкретной среде выполнения. @ Happypig375 В настоящее время Xamarin не планирует переходить на .Net Core (вместо этого планируется сделать Mono более похожим на .Net Core за счет совместного использования кода). Но это должно быть не сложнее, чем перенести WPF на .Net Core.

(Кстати, это неправда, что в Mono нет новых функций, поскольку он обновляется для поддержки .Net Standard 2.1, а текущая работа над веб-сборкой выполняется в Mono, а не в .Net Core. Но это в стороне, поскольку эту работу можно портировать. в .Net Core.)

Дорожная карта WinUI 3.0 — нам нужен ваш вклад!

Кажется, что это предложение по разработке может открыть новые возможности xplat, когда все необходимые компоненты будут доступны с открытым исходным кодом.

Им следует подумать о том, чтобы назвать его MicrosoftUI 1.0 , если это так, @4creators. 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

Я считаю, что эта проблема решается этим репо.