Это мои первые мысли по вопросам, которые вы задали в содержании выпуска.

Я исхожу с точки зрения дизайна и пользователей, с небольшим опытом разработки, который в свое время очень интересовался разработкой Silverlight / Windows Phone 7, а сейчас чувствует себя немного обгоревшим.

Какие шаблоны вас заинтересуют больше всего?

Я думаю, прежде чем запрашивать список идей для шаблонов, необходимо провести какой-то аудит крупнейших и наиболее часто используемых приложений в каждой структуре, например, WPF, UWP, WinForms, MFC и т. Д.

Изучите «силуэт» этих приложений и выясните типичные сценарии UX.

Сверху у меня в голове:

• Главное меню (все фреймворки)
• MDI (несколько документов в одном окне) (в основном MFC)
• Вкладки и датагрид (WPF, WinForms, MFC)
• Лента (приложения Win32 Office, 3ds max, paint, wordpad, проводник и т. Д.)
• Утилиты в системном трее (MFC, WinForms)
• Браузеры
• Мастера (WPF, MFC)
• Сложные приложения MDI (программное обеспечение Adobe, Visual Studio)
• Медиаплееры
• LoB визуализации данных (WPF и Интернет)
• Социальные приложения (React Native, PWA - Skype, Facebook, Twitter)

Все или некоторые из них могут выиграть от системной интеграции WinRT / UWP с Уведомлениями / Центром действий.

Все эти шаблоны нового проекта должны избегать встроенных пространств имен Windows.Xaml, темы элемента управления WPF и визуальных стилей WinForms в пользу новых шаблонов и визуальных стилей, которые соответствуют дизайну элементов управления FabricWeb / Fluent.

Также должен быть простой способ для разработчиков с существующими приложениями WPF и WinForms добавить зависимость WinUI 3.0, которая дает им новые конструкции элементов управления с помощью простого оператора using или записи в манифесте.

XAML острова

По мере того, как острова Xaml становится все проще сделать возможным - замена старых элементов управления веб-просмотра, средств выбора цвета, диалогов на основе XAML может быть такой же простой, как Добавить новый ... и выбрать диалоговое окно или стандартный элемент управления, который может вызывать существующий код C # и C ++, и у них есть свой собственный код.

Современные приложения и шаблоны страниц, такие как приложения Xbox Next, NavigationView, Master / Details, Hubs, Modern Ribbon, NavigationViewTop и Pivot, могут быть доступны для всех платформ презентаций Windows - с помощью островов XAML и образцов контента.

Любой из этих сценариев, которые в настоящее время невозможны в UWP XAML, должен быть с элементами управления и шаблонами, чтобы упростить их.

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

Этот вопрос должен задаваться, когда кто-то открывает свой проект в последней версии Visual Studio с текущим Windows 10 SDK. Нажмите кнопку, и она либо заменит пространства имен и использование, либо помечает их, если это не элемент управления, с которым он знаком.

В новых проектах это должно быть значение по умолчанию, а пакет nuget устанавливается вместе с будущими версиями Windows SDK.

Какое решение вы бы предпочли для использования компонентов UWP с WinUI 3?

Как и в случае с ответом на автоматическое обновление, новые страницы и проекты должны включать его по умолчанию, а также сообщение с вопросом, хотят ли они автоматически перейти к WinUI | Добавьте комментарии ToDo, чтобы обновить пространство имен s | Не переходите на WinUI .

Для каких приложений вам больше всего хотелось бы использовать WinUI 3.0?

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

Я хочу, чтобы приложения устанавливались, не вмешиваясь в реестр и не оставляя мусора. (так Столетие)

Я хочу, чтобы все приложения можно было устанавливать из магазина или из установщика типа Centennial. Виртуализируйте папки System и Windows для каждого приложения.

Модернизируете приложение C ++ MFC с помощью Fluent UI?

Acrylic должен быть доступен для приложений WPF, WinForms и MFC и включен в новые шаблоны по умолчанию через зависимость или манифест WinUI 3.0. CommonControls и стили окон должны использовать акриловые и расширенные заголовки (которые можно переопределить, чтобы вернуться к текущим значениям по умолчанию)

Все приложения Microsoft Win32, отличные от UWP, должны быть перекомпилированы с WinUI 3.0, поэтому все они используют акриловые оконные рамки, главные меню, ThemeShadow, контекстные меню , текстовые поля, индикаторы выполнения и т. Д.

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

re: namespaces, я бы ожидал, что они просто изменятся в зависимости от цели, даже если для этого требуются условные пространства имен.

Вот мои ответы:

Создание нового приложения

Какие шаблоны вас заинтересуют больше всего?

• Мне бы хотелось увидеть сначала c ++ / winRT win32 + xaml и .net core + xaml, затем шаблоны UWP, упакованное приложение win32 не должно использоваться в качестве шаблона, поскольку текущие шаблоны пакетов приложений должны работать так же, как они уже работают с текущими Win32 / .Net приложения.
• Кроме того, мне бы хотелось видеть шаблоны элементов, такие как «Новое окно XAML» с стандартным кодом, чтобы отображать его в существующем приложении ядра win32 или .net (например: создание существующего приложения панели задач а-ля Docker Desktop, способного отображать новое окно Xaml верхнего уровня)

Добавление WinUI 3.0 в существующие приложения Win32

• отсутствие обратной совместимости - это точная причина, по которой я никогда не использовал острова xaml в реальном проекте (хотя использовал его для развлечения в личных целях). Отделение инфраструктуры пользовательского интерфейса от Windows API - одна из величайших вещей, заявленных в дорожной карте WinUI 3.0 (наряду с возможностью для использования неупакованными / не-uwp-приложениями)

Обновление существующего приложения UWP Xaml до WinUI 3.0

Это может показаться резким, но я чувствую, что приложение UWP xaml - это ниша (с момента падения Windows Phone больше нет тяги к UWP в качестве целевой платформы), и даже если инструменты / взаимодействие было бы неплохо иметь, я не Я не думаю, что это должно быть основным направлением WinUI 3.0.
Таким образом, инструменты обновления пространства имен (которые на самом деле могут быть выполнены с помощью глобального поиска и замены) и смешивание UWP xaml и WinUI xaml не кажутся мне критичными.

Кроме того, просто хочу упомянуть, что это очень долгожданный шаг, и иметь открытый исходный код всего UI-фреймворка на Github - это здорово! Большое спасибо за это!

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

1. WPF намного более зрелый, чем WinUI (проверка, существующие элементы управления и т. Д.), Поэтому для предприятий WPF лучше подходит
2. UWP отлично подходит для нескольких категорий устройств (мобильные, планшетные, настольные и т. Д.), Вот где потребители

Приятно видеть, что точка 1 может быть решена с помощью WinUI, поэтому я с энтузиазмом отношусь к прогрессу в WinUI. К сожалению, 2 больше не применяется (больше нет крутых устройств, только настольные компьютеры). Это заставляет задуматься о том, что на момент выхода этого материала (самое раннее через 1 год?), Что на этом этапе понадобится разработчикам.

Я думаю, что потребительские товары больше не являются частью уравнения, этот корабль придерживался «стратегии» сокращения штатов. Так что единственное, для чего это может быть полезно, - это корпоративные приложения.

В общем, меня бы больше интересовала хорошая стратегия миграции с WPF на WinUI, чтобы попытаться перенести нашу массивную кодовую базу WPF на Windows 10. Обратной стороной необходимости обновлять приложения, ориентированные на потребителя (в настоящее время UWP), является то, что они сильно зависят на разработчиков внешних компонентов (например, Win Toolkit и т. д.). Я думаю, что для их обновления больше нет жизнеспособного варианта, поскольку большинство разработчиков (о которых я знаю) потеряли интерес к разработке клиентов / клиентов Windows.

Ответы на вопросы

Создание нового приложения

Какие шаблоны вас заинтересуют больше всего?

Мне бы хотелось увидеть здесь .net core / xaml / C #, поскольку я считаю, что это наиболее часто используемая языковая комбинация. Но, возможно, здесь будет лучше использовать шаблон миграции (постарайтесь привлечь всех как можно быстрее, чем дольше это займет, тем болезненнее будет).

Добавление WinUI 3.0 в существующие приложения Win32

Я думаю, что это очень хорошо, и мы бы часто этим пользовались (но реально до этого не меньше года, поскольку корпоративные клиенты все еще используют Windows 7, даже когда поддержка MS закончится, компании будут использовать Windows 7). Затем мы можем медленно перенести WPF на WinUI 3.

Вы знали о Xaml Islands для модернизации настольных приложений?

Да, но слишком много клиентов используют (или были) Windows 7, поэтому это не вариант для корпоративных разработчиков. А для потребителей в любом случае можно просто использовать UWP.

Делает ли эта расширенная обратная совместимость в Windows 10 Xaml Islands более полезными для вас?

Это хорошее начало, потому что на момент выхода этого материала он будет работать во всех поддерживаемых версиях Windows 10 на предприятии.

Обновление существующего приложения UWP Xaml до WinUI 3.0

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

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

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

Если это просто пространства имен, поиск / замена также должны помочь.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Уже не важно, я готов взять на себя потерю тысяч часов разработки, пользователей все равно не осталось.

Вы создаете или используете библиотеки элементов управления UWP Xaml или компоненты WinRT, которые невозможно легко перекомпилировать и обновить вместе с кодом приложения?

Неа.

Какое решение вы бы предпочли для использования компонентов UWP с WinUI 3?

Острова UWP (своего рода размещенные компоненты)

Общий

Что вы думаете об общем плане 3.0, описанном выше и в дорожной карте? Позволит ли это вам использовать WinUI для ваших новых и существующих приложений Windows?

Вероятно, он нуждается в некоторой доработке, но я вижу, что использую этот материал через 1-2 года для развития предприятия. В зависимости от того, насколько сложно выполнить миграцию, мы выберем либо WinUI, либо Интернет (в зависимости от того, как «развивается» сама Windows).

Для каких приложений вам больше всего хотелось бы использовать WinUI 3.0? Создаете новое приложение Win32 и упаковываете его с помощью MSIX? Добавление новых представлений в приложение WPF? Модернизируете приложение C ++ MFC с помощью Fluent UI?

Вероятно, просто добавляю новые представления в приложение WPF и медленно начинаю миграцию.

Мне очень нравится эта дорожная карта. UWP необходимо освободить от оков, и это отличный способ сделать это.

Обновление существующего приложения UWP Xaml до WinUI 3.0

Это очень важно для моего работодателя. У нас в магазине есть сложное настольное приложение UWP. Теперь нам нужен Desktop Bridge, чтобы получить доступ к API Win32, которые не поддерживаются .NET Native.

мне бы хотелось

• прямой доступ ко всем API Win32;
• используя простую старую модель исполнения win32. Меня устраивает некоторая песочница, подобная Desktop Bridge (например, виртуализация реестра);
• разместить наше приложение в магазине (msix) как сейчас;
• по-прежнему использовать WNS (push-уведомления);
• безболезненное обновление UWP до некоторого нового типа настольных приложений Xaml. Я не против заниматься ручным трудом. Возможно, здесь я предпочитаю хорошую документацию инструментам.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Существующие стили по-прежнему должны работать. Я могу жить с небольшими визуальными изменениями. Но не с изменением поведения.

Вы создаете или используете библиотеки элементов управления UWP Xaml или компоненты WinRT, которые невозможно легко перекомпилировать и обновить вместе с кодом приложения?

Нет.

Какое решение вы бы предпочли для использования компонентов UWP с WinUI 3?

Если они не могут быть перекомпилированы (третья сторона): подход, подобный Xaml Islands. В противном случае их можно будет легко перенести на WinUI 3.

Общий

Для каких приложений вам больше всего хотелось бы использовать WinUI 3.0? Создаете новое приложение Win32 и упаковываете его с помощью MSIX? Добавление новых представлений в приложение WPF? Модернизируете приложение C ++ MFC с помощью Fluent UI?

• Настольные приложения win32, упакованные с MSIX.
• Кросс-платформенные приложения Uno;)

Пожалуйста , не вводите новые пространства имен для таких вещей, как _INotifyDataErrorInfo_ - его следует использовать в моделях представления, которые обычно являются кроссплатформенными и не должны зависеть от WinUI. Он должен быть определен, где расположены другие подобные вещи (например, _INotifyPropertyChanged_ или _INotifyCollectionChanged) _

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

Было бы лучше обозначить как XamlUI или подобное? Пространства имен Microsoft.UI. * В порядке, просто укажите репозиторий, например

Спасибо, что обратились к нам. С нетерпением ждем того, что будет в этом пространстве: smile:

Для меня все технические детали менее важны.
UWP, WPF или любой фреймворк только для Windows, каким бы замечательным он ни был, его будет недостаточно, пока он не работает на всех платформах (по крайней мере, Windows, Droid, iOS и Интернет) и совместим с любой размер экрана.

TBH разочаровал меня на последней сборке, обнаружив, что MS не планирует делать UWP или XAML кроссплатформенным. Уно не получил официального признания, кроме речи. Еще более обидным, я бы сказал, больно, было обнаружение, что MS СОВЕРШЕННО любит React Native и фреймворки, управляемые HTML / JS (WinJS), пренебрегая при этом ответственными разработчиками стека .NET.
Я бы хотел, чтобы MS официально создала кроссплатформенный стек пользовательского интерфейса, такой как Uno, и предоставила необходимые инструменты, шаблоны и интегрированную поддержку.

И, кстати, я работал с XF с момента его приобретения MS, и хотел бы, чтобы у него была альтернатива по следующим причинам: a. Нет веб-поддержки, б. Очень предвзято относится к мобильным устройствам, не любит десктопы c. Иерархия его библиотек кажется неаккуратной, определенно по сравнению с библиотекой управления WPF / UWP d. Не использует MS XAML.
Вот запрос функции, который я разместил в сообществе разработчиков Microsoft: .NET UI Standard .

Спасибо всем!

Нам нужен пользовательский интерфейс XAML, который также работает в Интернете (сборка). По крайней мере, подмножество UWP.
Почему бы не принять платформу UNO и не сделать веб-рендеринг с помощью SkiaSharp?
Может быть Silverlight 6 , веб-аналог WinUI.

Быстрые ответы на вопросы

Какие шаблоны вас заинтересуют больше всего?

Проекты в стиле SDK ядра .NET или какой-либо упрощенный формат проекта MSVC.
Файлы старых проектов слишком сложны для редактирования вручную, и существует множество проблем взаимодействия между старой и новой системой проектов. Мы должны полностью отказаться от старой системы проектов ради новых проектов.

Вы знали о Xaml Islands для модернизации настольных приложений?

Нет. Я переписываю свое приложение с полным изменением модели данных, поэтому прогрессивной миграции нет.

Делает ли эта расширенная обратная совместимость в Windows 10 Xaml Islands более полезными для вас?

В Windows 7 по-прежнему много пользователей, и острова Xaml не могут помочь.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Нет. Все мои компоненты написаны самостоятельно или из MUX и WCTK, поэтому я могу выполнить быструю миграцию вручную.

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

Не так много, потому что мой проект невелик (на данный момент ~ 20 страниц и ~ 10 пользовательских элементов управления).

Какое решение вы бы предпочли для использования компонентов UWP с WinUI 3?

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

Для каких приложений вам больше всего хотелось бы использовать WinUI 3.0? Создаете новое приложение Win32 и упаковываете его с помощью MSIX? Добавление новых представлений в приложение WPF? Модернизируете приложение C ++ MFC с помощью Fluent UI?

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

Мой личный взгляд на платформу пользовательского интерфейса

Набор инструментов Xaml

Язык xaml почему-то несерьезный, и я сталкиваюсь со многими проблемами, такими как «как мне это представить». WPF xaml и UWP xaml не полностью совместимы, поэтому мне нужно помнить об их различиях. Xaml не полностью совместим с функциями .NET, поэтому иногда мне нужно написать несколько уродливых трюков в моей модели и вспомогательном классе.

С x:Bind все становится еще хуже. Простые сценарии легко использовать, но очень сложно делать что-то большее, чем просто доступ к свойствам. Например, он не поддерживает перегрузку метода, поэтому я должен выполнить компиляцию, чтобы проверить, какая перегрузка выбрана для этого выражения привязки. Я даже не могу выполнить простой переключатель или преобразование «видно, когда какое-то свойство ложно», и требуется вспомогательный метод. В документации ничего не говорится об этих подробных сценариях, поэтому я думаю, что должна быть позиция для обсуждения xaml-language-design и сделать xaml серьезно разработанным языком, таким как C #.

Редактор xaml тоже сложно использовать. Для дизайнера разумно попробовать выполнить некоторый код, чтобы показать фактические эффекты, но текстовый редактор должен просто знать метаданные. Открытие файла xaml в представлении исходного кода происходит медленно, потому что он активирует конструктор и выдает некоторые исключения взаимодействия для полностью исправного xaml, например NullReferenceException и Cannot convert __ComObject to some type . Он затрагивает ProjectReference через встроенные библиотеки и приводит к сложной ошибке даже при простом редактировании области, не являющейся общедоступной api, в библиотеке зависимостей, обычно это реализация модели данных. Поэтому я думаю, что должен быть осведомленный о метаданных и исходном коде, полностью интегрированный xaml-компилятор Roslyn.

Лучшая оконная модель

Полноинформативное приложение с полным состоянием обычно использует многооконную модель вместо модели навигации. В настоящее время в UWP создание нового окна с использованием ApplicationView болезненно, поскольку возникают проблемы с потоками. Новый AppWindow использует поток пользовательского интерфейса, и я не уверен в его производительности.

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

Интерфейсы привязки данных

Мы очень устали создавать модели, реализующие INotifyPropertyChanged . Я написал специальную задачу MSBuild для преобразования XML в расширенные средства доступа к свойствам, но это не помогает, когда я хочу сделать что-то настраиваемое в установщике при изменении свойства.

И есть проблемы с потоками. Мои данные полностью поступают с фонового сетевого сервера, поэтому захват контекста для await мне не поможет. В WPF и Binding все как есть, потому что Binding решает саму многопоточность. При переходе на x:Bind я должен решить эту проблему внутри средства повышения событий, потому что x:Bind просто работают с вызывающим потоком. Ситуация становится еще хуже, когда у меня есть несколько представлений приложения, затрагивающих одни и те же данные, что означает, что нет доступного глобального диспетчера пользовательского интерфейса, и единственное решение - захват SynchronizationContext.Current при регистрации события. Для коллекций ItemsSource не является потокобезопасным, и требуется такой же обходной путь.

Определенно должен быть набор инструментов для решения проблем моделирования, многопоточности и расширения для изменяемых связываемых моделей. А общее встроенное решение для привязываемой коллекции должно обеспечивать механизм для «изменения указанного свойства любого дочернего элемента».

IObservableVector<T> - это поддельный универсальный тип, который может использовать только object , INotifyCollectionChanged является универсальным. Просто реализуйте его для встроенной коллекции, например ObservableCollection<T> недостаточно, особенно для сложных, ориентированных на ISupportIncrementalLoading / IItemsRangeInfo сценариев. Платформа должна предоставлять абстрактную реализацию по умолчанию с лучшими практиками, позволяя пользователю просто реализовать абстрактный метод заполнения данных.

@shaggygi @weitzhandler @TonyHenrique

Если должно быть кроссплатформенное будущее для UWP / XamlUI3.0, абстрагирование синтаксиса XAML от средства визуализации Windows и остальной части среды выполнения Windows было бы способом справиться с этим.

Если бы в проекте мог быть менталитет почти надстройки, это могло бы быть средство визуализации Android или iOS / AppKit и оболочка AppKit для Android / iOS для передачи API-интерфейсов ART в C # и VB, а также существующий язык C ++, C. служба поддержки.
Xamarin может здесь помочь.

Microsoft не обязательно должна работать над этими рендерерами альтернативных платформ.

Но пока сосредоточимся на Windows ... WinUI 3.0 может включать Fabric Web / React Native / WPF / WinForms / MFC. PWA также станут первоклассным гражданином для разработки приложений, поэтому существуют кросс-платформенные истории для приложений, которые не созданы для Windows / .NET / UWP напрямую.

Что нужно сейчас, так это рассказать разработчикам C # /. NET / UWP историю, чтобы они могли использовать свои приложения и инвестиции на более широком ландшафте платформ.

Мои 2 цента: я разработчик Xamarin.Forms и (как и многие другие) заинтересован в том, чтобы все диалекты XAML были объединены в один, который работает везде, включая мобильное пространство. Не знаю, как это будет происходить, но, по крайней мере, я так хочу.

Возможно, WinUI 3.0 и выше, но существует слишком много приложений WPF, чтобы ожидать, что все они переписывают и переводят весь этот XAML. Новые проекты WPF могут использовать более современный диалект WinRT XAML. Вы можете ввести эквивалент DocType в XAML, чтобы разные диалекты могли сосуществовать в одном проекте.

Конечно, легче сказать, чем сделать.

@mdtauk Я думаю, что как только платформа Xaml действительно станет открытой, у нас будет более четкое представление о том, на что она опирается в нижней части стека (мы уже знаем, что основными зависимостями платформы являются DirectX11, Direct2D и Windows Media Foundation, но кто знает, какая часть Windows SDK там используется) и как она разбита на уровни (так что мы можем иметь реальное представление о возможности любого переноса).
Также нам еще предстоит увидеть, по какой лицензии будет распространяться исходный код. Я не уверен, что это еще решено.

Android использует Vulkan и, я думаю, поддерживает OpenGL
iOS и macOS используют Metal

Что касается медиакодеков, то для замены можно использовать собственные API на основе C.

@simonferquel Это станет более ясным, когда код будет реорганизован и зарегистрирован. И может потребоваться, чтобы некоторые эксперты iOS и Android возглавили эти усилия.

Я думаю, что изменение пространства имен было разумным подходом, когда winui был сбором элементов управления. Однако теперь, когда он в основном заменяет платформу, я думаю, что это больше не оправдано. Это уже работает таким же образом для WPF / Winforms, где код может быть перемещен из .NET Framework в ядро ​​.net без изменения пространств имен в коде. Платформа должна автоматически загружать версии winui необходимых dll при включении. Таким образом можно сохранить совместимость исходного кода и двоичного кода (я успешно использовал библиотеки .NET Framework в основных приложениях .NET).

Просто хотел сказать спасибо всем за комментарии! Команда WinUI внимательно изучает все ответы и вопросы.
Мы также, вероятно, разделим некоторые конкретные вопросы, чтобы обсудить конкретные возникшие моменты (например, совместимость с существующими платформами и компонентами UWP), как только мы систематизируем свои мысли.

Я просто хочу поблагодарить MS за то, что она больше слушает и предоставляет разработчикам .net потрясающие инструменты, но я не могу не чувствовать разочарование в будущем UWP Xaml после конференции по сборке.
Читая этот блог и многие статьи в сети, вы чувствуете, что UWP становится исключительно «корпоративным», и даже это вызывает споры, поскольку многие предприятия становятся все более независимыми от ОС, позволяя работникам использовать, например, MacBook Pro.

Позвольте мне прояснить, что я сильно инвестирую в собственные формы UWP и Xamarin (Android, iOS), и я люблю эту платформу, но после того, как MS объявит о встроенной поддержке React, я собираюсь покинуть корабль.

Я знаю, что должен сделать свое приложение UWP более независимым от платформы на рабочем столе, поэтому я надеялся, что смогу создать «гибридное приложение» с моим текущим приложением uwp в качестве оболочки и включать все больше и больше интерфейсных веб-технологий, используя React в сочетании. . Что-то вроде предлагаемой функции «Наборы», которая, как я понимаю, теперь откладывается из-за более высоких приоритетов в Edge, было бы идеальным для моего текущего решения, поскольку оно полностью стирает границы между встроенными UWP и веб-технологиями за счет запуска собственных, а также веб-технологий в «Окна / боковые вкладки». Этот «гибридный» подход позволит мне постепенно внедрить веб-технологии в мою текущую платформу, но также даст «родным приложениям» вкладку в «браузере», так сказать. (с точки зрения потребителя) Это также дает мне выход, если «нативные приложения uwp» долго терпят неудачу на рабочем столе.

Причина вышеупомянутого мышления заключается в том, что UWP не предоставляет мне выхода, поскольку он может легко стать следующей жертвой Silverlight, если в ближайшее время не будет кроссплатформенной возможности. MS хеджирует свои ставки, чтобы убедиться, что они не проиграют в тенденции PWA, или их руки повернуты для этого в пользу встроенной поддержки React в Windows. Проблема в том, что я сделал ставку, надеясь, что к этому времени у UWP / c # /. Net появится «путь» в браузер или кросс-платформу, и я смогу повторно использовать большую часть своих инвестиций в эти платформы.

Я помню, когда каждый разработчик кричал, покупайте Xamarin, MS потребовалась вечность, чтобы сделать это. Я думаю, что большинство разработчиков, знакомых с веб-сборкой, знают, что недавно им удалось запустить «полную версию» Windows Server в веб-сборке, и они скажут, что купите платформу Uno и сделайте ее огромной, вложив значительные средства. Если полная ОС может работать на веб-сборке, MS должна предоставить каждому разработчику .net возможность перехода на кроссплатформенность, чтобы защитить свои существующие инвестиции.

Вы можете сказать, что Blazor существует, но, честно говоря, прежде чем я потрачу больше времени на новую платформу, я лучше изучу React, или вы можете сказать, что у нас, MS, есть ограниченные ресурсы для всего этого. Конечно, когда вы платите 7,5 миллиардов долларов за Github, все становится относительным.

Я думаю, что очень важно, чтобы MS понимала репутационный ущерб, нанесенный неудачным путем миграции на кроссплатформенность для существующих инвестиций в UWP / Win32. Кроссплатформенность должна быть синонимом .NET 5, но это не так. Я не уверен, что детские шаги по переходу на кросс-платформу в этом случае сработают для MS, и поверьте мне, я всегда был большим поклонником xaml / .net / c #

Какие шаблоны вас заинтересуют больше всего?

Вы также имеете в виду шаблоны проектов или шаблоны элементов?

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

Будет ли это просто поиск и замена (меньшее значение) или также включение обновления зависимостей до новой версии (более ценно, но не уверен, как вы могли бы сказать)

Re: обратная совместимость для новых функций

Будет ли обратная совместимость с Creators Update (15063) фиксированной точкой отсчета или в будущем планируется поддерживать текущую версию и X версий до этого?

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

Re: перенос пространств имен

Будет ли возможно мигрировать существующий UWP поэтапно (я думаю, страницы) или нужно будет обновить все приложение сразу? Если это все приложение за один раз, это замедлит его внедрение.

А как насчет миграции приложений WPF? - Используется ли в стратегии миграции острова XAML, которые могут использовать WinUI 2.x или 3.x? Могут ли оба быть использованы в одном приложении?

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

Замените все экземпляры UWP соответствующими именами, так как непонятно, о чем вы говорите.

@mrlacey :

Вы также имеете в виду шаблоны проектов или шаблоны элементов?

Шаблоны предметов или библиотек тоже интересны! Пока в ответах есть несколько замечательных моментов о предоставлении дополнительного шаблонного и начального кода, который мы могли бы добавить со временем, например, в Windows Template Studio .

Будет ли это просто поиск и замена (меньшее значение) или также включение обновления зависимостей до новой версии (более ценно, но не уверен, как вы могли бы сказать)

Хороший вопрос - какие обновления зависимостей сделают его более ценным? например, найти новые совместимые версии пакета NuGet?

Будет ли обратная совместимость с Creators Update (15063) фиксированной точкой отсчета или в будущем планируется поддерживать текущую версию и X версий до этого?

Мы предполагаем, что диапазон поддерживаемых версий будет меняться со временем в зависимости от использования. Вместо того, чтобы ограничиваться определенным количеством версий, мы, вероятно, продолжим анализировать данные об использовании и поддерживать наиболее активные версии Windows 10, представленные на рынке.

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

В настоящее время мы не предполагаем введения каких-либо дополнительных требований или «сертификации» для пользовательского контроля. Версионирование зависит от вас. Общая история управления версиями в May 2019 Update, WinUI 3.0 и будущих версиях WinUI определенно является темой, которую мы хотим в ближайшее время более подробно рассмотреть.

Будет ли возможно мигрировать существующий UWP поэтапно (я думаю, страницы) или нужно будет обновить все приложение сразу? Если это все приложение за один раз, это замедлит его внедрение.

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

Замените все экземпляры UWP соответствующими именами, так как непонятно, о чем вы говорите.

@riverar : есть ли какое-то конкретное использование или раздел, который

Мы используем термин « UWP Xaml » для обозначения платформы Xaml, которая поставляется как часть Windows 10 и UWP SDK, чтобы отличать ее от других платформ на основе Xaml (например, WPF).

Мы также ссылаемся на « модель приложения UWP » (упаковка и установка, управление данными и состоянием, жизненный цикл времени выполнения и т. Д.), В отличие от модели приложения Win32.

Даже на настольных компьютерах с Windows пользователи проводят много времени в Интернете.
Я думаю, что нам нужен способ разработки достойных веб-приложений с использованием (подмножества) UWP vNext XAML + .NET (C # / F # / VB.NET)

Я много лет разрабатывал в WPF + ClickOnce, затем начал изучать UWP. Мне нравится UWP, но он (или следующая версия) должен иметь возможность запускать автономный EXE, лучшие оконные API-интерфейсы (позволяют создавать даже пользовательские приложения в стиле окна Winamp, если мы ХОТИМ), больше API-интерфейсов печати, простое взаимодействие с C dll , OCX, по крайней мере, часть компонентов должна работать в Интернете.

Когда я увидел UNO, я подумал: Microsoft может купить эту компанию и присоединиться к этим разработчикам с командами UWP и Xamarin. Я был бы рад, если следующая версия UWP станет частью Azure, которая работает в Интернете, Windows, Mobile и IoT. ИМО, даже портал Azure может быть написан на UWP vNext.

Microsoft может это сделать. Вы сделали это с помощью Silverlight, вы сделали WPF, вы сделали UWP, вы сделали Xamarin. Пришло время для окончательной среды XAML с графическим интерфейсом пользователя. И, на мой взгляд, Web должен поддерживаться, по крайней мере, частью функциональности.

_INotifyDataErrorInfo_

Пожалуйста , не вводите новые пространства имен для таких вещей, как _INotifyDataErrorInfo_ - его следует использовать в моделях представления, которые обычно являются кроссплатформенными и не должны зависеть от WinUI. Он должен быть определен, где расположены другие подобные вещи (например, _INotifyPropertyChanged_ или _INotifyCollectionChanged) _

Об этой теме. Windows.UI.Xaml.Interop уже имеет интерфейс INotifyCollectionChanged, а Windows.UI.Xaml.Data имеет INotifyPropertyChanged. Эти два будут перемещены в пространства имен Microsoft. Возможно, сборки System.Runtime.WindowsRuntime могут выполнять какое-то отображение из WinUI в .Net

Единственное, что я хочу добавить, если он еще не был добавлен, это то, что я на 100% поддерживаю модель пакета MSIX / Appx, а Win10 проделал фантастическую работу по исправлению того дерьма, которое связано с установкой и удалением в течение срока службы Windows. Однако мне всегда было сложно создать приложение «UWP» из-за странного подмножества доступных вариантов API, которые были сделаны в песочнице AppContainer. Как разработчику C ++ это расстраивало, и каждый год видеть, как вы открываете песочницу дальше, чтобы разрешить полный набор Win32 API, было большим облегчением.

Так что, если WinUI 3.0 позволяет мне создать приложение с доступом к 100% стека Win32, то это будет золотая середина! Я пробовал использовать XamlIslands прямо сейчас, и это фантастический аварийный выход, но для меня он был нестабильным, и ему нужно немного поработать, прежде чем он действительно пересечет финишную черту.

Получив шаблоны проектов, которые позволят мне создать приложение Win32, не запихиваясь в процесс AppContainer, и позволят мне получить доступ ко всем улучшениям, которые вы сделали с пользовательским интерфейсом, WinUI 3 идеально мне подойдет.

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

Привет, Microsoft!

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

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

Я здесь не для того, чтобы обсуждать, лучше ли одно другое. Я здесь не для того, чтобы обсуждать взломы реестра, «настройки шрифтов» или то, как я могу настроить параметры ОС, чтобы шрифты выглядели лучше. Поверьте, я все это сделал; даже дошел до исследования, чтобы написать драйвер режима ядра для исправления функций DirectWrite в режиме ядра.

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

Помимо расстояния между руками, мне нужно носить корректирующие линзы. : eyeglasses: Уверен, мы все в курсе, экраны настольных компьютеров прямо на расстоянии вытянутой руки. Отсюда проблема.

• Шрифты, которые выглядят гладкими, кажутся мне размытыми.
• Шрифты с острыми краями (с привязкой к пикселям) кажутся мне более четкими.

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

Как товарищ-разработчик, который тратит много времени на написание кода и просмотр текста, это неприятно и чертовски больно. Это основная причина, по которой я все еще использую Windows 7, а не Windows 10 . Почти весь основной пользовательский интерфейс Metro в Windows 10 повсеместно использует сглаживание шрифтов.

Чтобы проиллюстрировать эту проблему сглаживания шрифтов, давайте посмотрим на оснастку services.msc MMC в Windows 7 :

Вы видите размытый текст, который выглядит не в фокусе? Здесь. Давайте увеличим немного ближе ...

Боже, милостиво, такое чувство, будто я косо смотрю на текст на автостереограмме .

Оказывается, в этом конкретном случае, копаясь в иерархии элементов управления этого окна, оснастка MMC размещает элемент управления Internet Explorer DHTML / ActiveX, который отображает нечеткий текст на панели «выберите элемент для просмотра его описания». Резкое (привязанное к пикселям), меню «Справка» и список служб отображаются с помощью обычных примитивов USER32 и GDI32.

Этот небольшой пример подчеркивает одну из самых больших проблем с отрисовкой шрифтов в Windows. Оказывается, IE8 будет учитывать глобальные настройки операционной системы, которые отключают ClearType и сглаживание шрифтов. Однако, если вы установите IE9 или выше, IE9 + с радостью проигнорирует любые и ВСЕ попытки отключить сглаживание шрифтов. IE9 + просто не заботится и заставляет всех пользователей просматривать текст на веб-сайтах (и в элементах управления ActiveX) со сглаженным шрифтом.

Проблема усугубляется для таких пользователей, как я, потому что с течением времени при рождении Windows 8 и Windows 10, Metro Apps, WPF и UWP использовался тот же подход, что и IE9 +. Все эти скрытые технологии пользовательского интерфейса игнорируют глобальные настройки операционной системы, которые должны соблюдаться на наших машинах. Если мы отключим ClearType и сглаживание шрифтов на уровне операционной системы, мы ожидаем, что API-интерфейсы ClearType и DirectWrite (и, следовательно, приложения Metro, WPF и UWP) не будут рисовать с каким-либо сглаживанием шрифтов.

Я знаю, что не только я столкнулся с этой проблемой.

Некоторое время назад Google Chrome сделал то же самое со своим выпуском v31 и попытался следовать подходу IE9 + и переключил весь рендеринг шрифтов на DirectWrite, игнорируя глобальные общесистемные настройки. Это изменение привело Интернет в ярость. См. Chromium Issue 319429 . Наконец, после долгого скрежета зубов Google изменил курс и исправил проблему в Chrome 37 для пользователей с близоруким нарушением зрения и теперь соблюдает общесистемные настройки операционной системы, которые отключают сглаживание шрифтов.

Благодаря власти и рыночным силам, Microsoft проиграла войну браузеров и теперь принимает движок рендеринга Chromium, но я затаив дыхание задерживаю, что команда Edge будет уважать отключенные настройки сглаживания шрифтов.

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

И как дружеское напоминание, это проблема доступности для пользовательского интерфейса Windows в целом, а не

На основе распространенности миопии во всем мире можно оценить, что более 22% нынешнего населения мира, то есть 1,5 миллиарда человек, страдают миопией. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Спасибо,
Брайан

: walking_man:: walking_woman: Пропавшие без вести - Прогулка по Лос-Анджелесу

Это означает, что полный фреймворк Xaml будет разработан на GitHub и будет поставляться вне очереди в виде пакетов NuGet .

NuGet великолепен, но поддержка vcpkg (и CMake ) также была бы оценена (для тех из нас, у кого есть большие существующие кроссплатформенные библиотеки).

Какие шаблоны вас заинтересуют больше всего?

В порядке предпочтения:
Win32 + Xaml для настольных ПК + WinUI
Win32 + острова Xaml + WinUI
UWP + WinUI

Вы знали о Xaml Islands для модернизации настольных приложений?Делает ли эта расширенная обратная совместимость в Windows 10 Xaml Islands более полезными для вас?

Да, Xaml Islands интересен, но поскольку мы нацелены на потребителей, а не на корпоративных клиентов, расширенная обратная совместимость не является препятствием для сделки - большинство клиентов разумно рады обновить свою ОС (и учитывая временные рамки для внедрения изменений на основе нового WinUI Xaml, если он будет заблокирован до 1903 года, вероятно, это будет означать, что он отсутствует уже год).

Корневое пространство имен для API Xaml, композиции и ввода в WinUI будет отличаться от корневого пространства имен Windows UWP SDK:

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

На меня это не влияет, так как у нас нет приложения UWP (в настоящее время используется WPF для прямых продаж и WPF + Desktop Bridge для магазина), но изменение пространств имен - единовременная вещь, и даже в самых больших базах кода, глобальный поиск и замена для Windows::UI::Xaml не так уж и сложен (мы все используем контроль версий, верно?).

Самый быстрый способ выпустить WinUI 3.0 - не поддерживать смешивание:

Меня это устраивает, их следует рассматривать как отдельные несовместимые библиотеки. Вы либо нацеливаетесь на UWP Xaml, либо на WinUI Xaml. Как упоминалось выше, одноразовое преобразование не должно быть таким сложным.

Однако одна из наших самых больших проблем - это проблемы совместимости и работы, которые могут возникнуть для существующих приложений UWP и библиотек компонентов, особенно если вы создаете или используете библиотеки элементов управления UWP Xaml.
Например, существующие версии Windows Community Toolkit нельзя будет использовать в приложениях WinUI 3.0, поэтому как Toolkit, так и любые приложения, использующие его, необходимо будет обновить перед использованием WinUI 3.0.

Microsoft нужно выбрать технологию и придерживаться ее. В течение многих лет нам обещали новейшие и лучшие среды пользовательского интерфейса рабочего стола (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml, а теперь и WinUI Xaml). Хотя выбор велик, он приводит к фрагментации функциональности и знаний разработчиков. Намного проще иметь один сеанс / одну веб-страницу / один ответ stackoverflow при реализации функции в Windows, по сравнению с 7 разными в зависимости от технологии. Если будущее за WinUI Xaml, то для использования его преимуществ необходимо обновить набор инструментов сообщества.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Я воздерживался от каких-либо действий с UWP Xaml, потому что функциональности просто нет (по сравнению с Win32 / WPF), и я предполагаю, что я не одинок в этом отношении. Таким образом, полная совместимость не является проблемой.

Вы создаете или используете библиотеки элементов управления UWP Xaml или компоненты WinRT, которые невозможно легко перекомпилировать и обновить вместе с кодом приложения?

Нет.

Какое решение вы бы предпочли для использования компонентов UWP Xaml с WinUI 3?

N / A

1. Что вы думаете об общем плане 3.0, описанном выше и в дорожной карте ? Позволит ли это вам использовать WinUI для ваших новых и существующих приложений Windows?

В дорожной карте нет упоминания о Xaml Desktop . Подпадает ли это под компетенцию WinUI?
Я уже говорил об этом раньше людям в // Build /, но причина отказа от принятия UWP Xaml ранее в том, что невозможно было создать приложение, использующее существующие библиотеки C ++. Например, когда пользователь выбирает файл с помощью FileOpenPicker , результат доставляется как IStorageFile , и нет способа передать его в существующую стороннюю библиотеку для открытия (например, libpng , libjpeg и т. Д.). Вот почему нам пришлось придерживаться WPF, поэтому, если Xaml Desktop или Win32 + Xaml Islands позволяет нам жить без этих ограничений, то да, это позволит нам использовать WinUI для нового приложения.

1. Для каких приложений вам больше всего хотелось бы использовать WinUI 3.0? Создаете новое приложение Win32 и упаковываете его с помощью

Создание нового приложения Win32 с WinUI (и упаковка с MSIX).

Если у вас есть какие-либо вопросы, дайте мне знать, я буду рад обсудить их дальше.

На самом деле надеюсь, что есть способ вызвать Compact Overlay из WPF / WinForms.
Нам просто нужна система разрешений администратора, такая как «Разрешение на рисование над другими приложениями» в Android.

Надеюсь, эта модель приложения + упаковка (UWP + AppX, Win32 + MSIX) позволяют это (Полная абстракция внутри песочницы)

Разве Windows не предполагает самые продвинутые и неограниченные возможности с лучшей безопасностью?
Нет, урезанная функция безопасности.

Спасибо за то, что открылись сообществу для комментариев относительно дорожной карты.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Кстати, прямо сейчас у нас есть довольно много приложений UWP, используемых для корпоративных клиентов, и я надеюсь, что путь миграции не будет таким сложным. Если есть критические изменения, было бы очень хорошо иметь инструмент миграции, похожий на .Net Framework to .Net Core который определяет, насколько совместим будет наш путь миграции, он должен сообщать обо всем, что может потребоваться изменить ( например, API-интерфейсы, которые могут быть устаревшими или вести себя по-другому), а также возможность автоматического изменения пространства имен, если это возможно. Таким образом, путь миграции с UWP на WInUI не будет таким изменчивым для корпоративных разработчиков.

Вы знали о Xaml Islands для модернизации настольных приложений?
Делает ли эта расширенная обратная совместимость в Windows 10 Xaml Islands более полезными для вас?

Да, но это не было большой проблемой, поскольку все наши недавно разработанные настольные приложения используют UWP для связи через серверную часть API, а большинство наших клиентов уже работают под управлением Windows10.

Что вы думаете об общем плане 3.0, описанном выше и в дорожной карте? Позволит ли это вам использовать WinUI для ваших новых и существующих приложений Windows?

Команда разработчиков настольных ПК уже воодушевлена ​​новостями о WinUI 3, но, как указано выше, опасается миграции на нее всех наших приложений UWP, если путь не будет таким гладким.

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

Также добавьте, что с WinUI 3 и далее должен также улучшиться диалект XAML, возможно, ввести пространство имен версий / Doctype, чтобы указать, какая версия XAML используется, чтобы сохранить обратную совместимость для старых приложений. Многое нужно сделать для того, чтобы сделать XAML менее подробным или вырезать какой-то шаблонный код, например, написать INotifyPropertyChanged с резервными частными сеттерами для одного вместо того, чтобы быть простым атрибутом свойства, скажем NotifyPropertyChangedAttribute и пусть шаг сборки внедрить реализацию, чтобы избежать накладных расходов во время выполнения, или DependencyProperties для настраиваемых элементов управления, чтобы упростить создание компонентов. Возможно, также возьмем некоторые улучшения от команды Razor для некоторых из хороших частей, которые у них есть.

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

@mdtauk Я не против безопасности файлов, но базовое ядро ​​должно препятствовать тому, чтобы вы писали там, где у вас нет прав, в отличие от использования совершенно нового набора API и отказа от API файла win32. Кроме того, я знаю, что это выходит за рамки темы, но StorageFile / StorageFolder api - ужасная замена, даже не учитывая безопасность файлов. Они медленные, и вы всегда проксируете через брокер исполняемых файлов. Кроме того, никогда не должно было быть ограничением, что приложениям в песочнице требуется специальное разрешение, одобренное MS, для записи в папку документов пользователя. Например, насколько ужасной была история с файлом для усилий AppContainer, было невозможно создать базу данных sqlite где-либо, кроме скрытой папки LocalData пользователя. Для настольной системы, в которой пользователи хотят создавать, сохранять и открывать файлы, а также сохранять их как yadda yadda, на разработчиков программного обеспечения ложится бремя, которое им необходимо переучивать своих пользователей, как управлять пользовательским контентом.

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

@MarkIngramUK Спасибо за комментарии, только одно уточнение. Концепция рабочего стола Xaml, представленная в Sneak Peek на // Build 2019, была переименована в WinUI Desktop. Этот новый проект Visual Studio будет использовать модель приложения Win32 с WinUI в качестве среды представления, и он может быть собственным или управляемым (с использованием .NET Core 3).

Спасибо @ marb2000 - это в пределах временного интервала WinUI 3.0?

@ marb2000 от WinUI Desktop, вы имеете в виду приложения Win32 с Xaml Islands? В каком сеансе сборки это было показано?

При переименовании WinUI 3.0 команда WinUI должна остерегаться одного: если вы переименуете какой-либо из типов, которые проецируются в .NET, прогнозы не будут работать (и мы не планируем добавлять больше, поскольку это не так. поддерживаемая расширяемая система). Вот список типов, которые мы проектируем: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Любые изменения типов, отличных от этих, потребуют от пользователей оборачивания своих объектов новыми объектами, реализующими новые интерфейсы, или копирования своих данных в новые типы. В частности, типы INotifyPropertyChanged и INotifyCollectionChanged представляют интерес в отношении островов XAML и обеспечения последующей поддержки.

INotifyDataErrorInfo

Пожалуйста, не вводите новые пространства имен для таких вещей, как INotifyDataErrorInfo - его следует использовать в моделях представления, которые обычно являются кроссплатформенными и не должны зависеть от WinUI. Его следует определить, где расположены другие подобные вещи (например, INotifyPropertyChanged или INotifyCollectionChanged).

Об этой теме. Windows.UI.Xaml.Interop уже имеет интерфейс INotifyCollectionChanged, а Windows.UI.Xaml.Data имеет INotifyPropertyChanged. Эти два будут перемещены в пространства имен Microsoft. Возможно, сборки System.Runtime.WindowsRuntime могут выполнять какое-то отображение из WinUI в .Net

Спасибо за ответ, но зачем он вам нужен в пространстве имен Microsoft, если в .NET Standard он уже есть в System.ComponentModel? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@ meir-pletinsky. NET - это только одна платформа, которую вы можете использовать для создания приложений с UWP XAML. Они хотят, чтобы для разработчиков была доступна проверка текстовых полей, независимо от того, какую платформу они используют.

@mdtauk , нет, WinUI Desktop (ранее Xaml Desktop) позволяет использовать Xaml с Win32 напрямую, без использования острова.

@ marb2000 Было бы здорово, если бы проект упаковки приложений позволял вам создавать AppX с окном Win32 и включать компоненты WinRT так же просто, как и проект UWP. Есть много вещей, которые не работают без ручного редактирования файлов vcxproj, таких как добавление ресурсов и компилятор cppwinrt, генерирующий заголовки из включенных компонентов WinRT.

Другой проект, который важен для этого нового пользовательского интерфейса, - это _PropertyChanged.Fody_ от Саймона Кроппа, который позволяет автоматическую реализацию INotifyPropertyChanged (я пробовал с C # / F #). См. Https://github.com/Fody/PropertyChanged

Это позволяет использовать такой простой код:

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

который мы можем использовать для привязки к пользовательскому интерфейсу.

Одна вещь, которую я хотел бы видеть в WinUI 3.0: в настоящее время компилятор XAML UWP ( genxbf.dll ) может быть вызван непосредственно MSBuild только при ссылке из файла csproj, vbproj или vcxproj. Это связано с тем, что нет инструмента командной строки, который можно было бы использовать для вызова этой функции. Это кажется мне очень странным решением, поскольку больше ничего из загружаемого пакета SDK для Windows 10 не требует Visual Studio. (Надстройка WDK также включает цели Visual Studio, но все эти цели вызывают инструменты командной строки, которые можно использовать независимо от VS.) Я был бы очень признателен за добавление, например, XbfCompiler.exe и XbfCodeGen.exe в каталог bin SDK. (Первый EXE компилирует файлы XAML в файлы XBF, а второй генерирует файлы кода программной части, необходимые для ссылки на типы XAML из кода.) Это было бы в основном полезно в проектах C ++, которые используют CMake или другой, не Visual Инструмент сборки Studio, но при необходимости также может использоваться для проектов C # и VB.NET. Спасибо!

@MarkIngramUK , вы случайно не знаете, где я могу узнать больше о WinUI Desktop. Эти сеансы Build 2019 нельзя смотреть онлайн. Похоже, это важная информация, на которую следует ссылаться в этом репо.

@mdtauk Это было упомянуто в так называемом Sneak Peek, который предназначен только для посетителей Build. Афаик записи нет. Меня там тоже не было, но есть слайд - может быть, лучший слайд :-) - доступен в Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk Дорожная карта WinUI 3 содержит самую свежую информацию и диаграммы, которые даже более актуальны, чем то, что было показано в

3,0 дорожной карты представляется вполне разумным для следующей стратегии: включить любое клиентское приложение для Windows , чтобы использовать XAML и «современные» управления WinUI.

Однако эта стратегия кажется недальновидной, если принять во внимание реальность сегодняшнего рынка: для разработки многих приложений основными целями являются Android и iOS, а Windows - это хорошо. Для .NET-разработчика Xamarin обеспечивает достойную поддержку Android и iOS, но их поддержка Windows невысока. Таким образом, для нативных мобильных / настольных приложений Win UI 3.0 не делает ничего, чтобы упростить кроссплатформенную разработку для .NET-разработчиков.

Что я действительно хотел бы видеть, так это продвинутый диалект XAML с поистине универсальными устремлениями. Я должен иметь возможность написать приложение .NET с помощью XAML и запустить это приложение в Windows, iOS и Android. Приложение должно быть действительно первоклассным на каждой платформе и иметь доступ к собственным элементам по мере необходимости. Как уже упоминалось, Xamarin - хорошее начало, но его диалект XAML сильно отличается, у него плохая поддержка Windows, и никакая работа, которую вы делаете, не помогает.

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

При необходимости отключите или откажитесь от поведения жизненного цикла устаревшего мобильного приложения, такого как приостановка + надгробие.

Реальность такова, что UWP - это среда рабочего стола, и, по крайней мере, для игр пользователь может часто минимизировать приложение, что обычно приводит к приостановке / захвату приложения. Это неприятный опыт, который сильно отличается от любого настольного приложения или игры win32. Запроса на расширенную отсрочку, которая, вероятно, все еще истечет, недостаточно, чтобы легко справиться с этим.

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

@natemonster

За: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

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

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

@TonyHenrique, когда вы упоминаете Fody , это потому, что вы хотите осознать это, или вы говорите, что он должен быть встроен в WinUI?

Шаблоны предметов или библиотек тоже интересны! Пока в ответах есть несколько замечательных моментов о предоставлении дополнительного шаблона и стартового кода, который мы могли бы добавить со временем, например, в Windows Template Studio.

@Jesbis Я являюсь основным участником Windows Template Studio и слежу за дорожной картой WinUI с точки зрения того, что мы делаем в будущем и как внедряем поддержку WPF. ;)

какие обновления зависимостей сделают его более ценным? например, найти новые совместимые версии пакета NuGet?

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

@mrlacey Я упомянул Fody, потому что считаю это интересным решением, и нам нужен лучший способ избежать шаблонного кода _INotifyPropertyChanged_. Было бы хорошо иметь решение с поддержкой MS для этой концепции реактивного объекта, который автоматически вызывает событие при изменении какого-либо свойства.
Он работает с классами C # и даже с записями F # (но с некоторыми трудностями).
Так что в дорожной карте WinUI тоже должно быть это.

Примечание. Было бы хорошо, если бы мы также могли использовать записи F # для определения наших сущностей данных и привязки непосредственно к пользовательскому интерфейсу XAML. Было бы здорово, если бы мы могли без проблем использовать F # Records + Fody + DataBinding.

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

Это было бы более знакомо людям, пришедшим из C #.
Другой подход - это эльмишский путь. Я думаю, что оба они интересны, и их можно поддержать.

@tonyhenrique / @mrlacey Я думаю, что материал Fody (OAP) должен выходить за рамки. У команды WinUI уже достаточно на своей тарелке, и я думаю, что лучше иметь переплетение в отдельных проектах (намного более быстрые циклы выпуска в случае улучшений).

И я думаю, что на самом деле это деталь реализации моделей .NET (IL), а не WinUI (хотя он может прослушивать события изменения). Я предлагаю держать их отдельно. Например, я использую Catel, и у него есть свои ткачи Fody, чтобы убедиться, что все плетется правильно.

Что я действительно хотел бы видеть, так это продвинутый диалект XAML с поистине универсальными устремлениями. Я должен иметь возможность написать приложение .NET с помощью XAML и запустить это приложение в Windows, iOS и Android. Приложение должно быть действительно первоклассным на каждой платформе и иметь доступ к собственным элементам по мере необходимости.

Есть давнее предложение пойти в этом направлении: кроссплатформенный UX для .NET 5 - исходное название Cross platform UX for .NET Core 3.0 . Подавляющая поддержка этого сообщества очевидна, и мы можем надеяться, что MSFT поймет, что это лучшее направление для разработки любой инфраструктуры пользовательского интерфейса, работающей на .NET. Практически нет причин хранить отдельные кодовые базы для разных групп платформ и принудительно создавать отдельные наборы навыков разработчика на основе разных фреймворков UX, поддерживаемых .NET.

Создавая единый UX для всех платформ, мы устраняем все недостатки в разработке framewrk и снижаем барьеры для принятия разработчиками.

@mfeingol / @ 4creators , я бы согласился на

Приложение должно быть действительно первоклассным на каждой платформе.

в Windows для начала ...

Сейчас 2019 год, мне нужен быстрый, собственный интерфейс, и я не хочу серьезно рассматривать создание пользовательского интерфейса с CreateWindowExW , GDI и т. Д.

Теперь, когда с WinUI3.0 и выше код отделен от Windows 10, есть ли планы на будущее, чтобы WinUI работал на Linux и Mac?

@jesbis Touch взаимодействия будут сохранены в WinUI 3.0?

Спасибо за разъяснения, я предполагал, что 3.0 будет работать, если включить Xaml Islands в WinUI, а не использовать Community Toolkit.

Поскольку он становится XAML плюс Win32, это приобретает больше смысла, особенно с учетом того, что ОС Windows Core переписывает оболочку в XAML.

Насколько я понимаю сейчас, этот богатый доступ к Win32 API осуществляется на языках C и C ++ | с чем-либо в C #, полагающимся на .NET (будь то сейчас .NET Core).

Возможно, должен быть безопасный и простой способ доступа к этим API Win32, а также дополнительные точки входа для отображения пользовательского интерфейса приложений?

• Всплывающее окно XAML на панели задач для приложений WinUI 3

• простые пользовательские интерфейсы Picker для Hololens / Xbox / Surface Hub / IoT и т. д.

• обновленные настраиваемые общие диалоговые окна файлов XAML и средства выбора папок

• простой доступ C # .NET к API Win32

• компактная настройка для всех элементов XAML, которые соответствуют размеру элементов управления Win32 и WPF (это поможет фреймворкам удобно работать вместе)

• соответствие стилей управления / шрифтов / кистей акрила / акрила при использовании WinUI

• четкое определение того, какие устройства требуют жизненного цикла WinRT / Mobile

• Стили управления Xbox Next, встроенные для разработки и тестирования приложений Xbox в Windows

• Сохранение и одиночная упаковка и загрузка exe / MSI / APPX поддерживаются по умолчанию, БЕЗ УСТАНОВЩИКОВ, виртуализация файловой системы столетнего типа по умолчанию

• WinForms WinUI 3.0 - простой пользовательский интерфейс, доступ только к MFC, мыши и клавиатуре

• WPF WinUI 3.0 - плотный интерфейс, 3D-рендеринг, поддержка DPI, имитация касания и базовая поддержка рукописного ввода

• Xaml WinUI 3.0 - полное касание, MR, геймпад, рукописный ввод, голос, мышь, клавиатура. Плотный и простой интерфейс. Новая поддержка окон. MR 3D-рендеринг. Дополнительный управляемый жизненный цикл или жизненный цикл рабочего стола. Лучшее из всех миров по умолчанию для приложений оболочки и переработанных приложений для входящих сообщений, с версиями Win32 приложений для входящих сообщений, такими как блокнот, charmap, paint, проводник файлов - с открытым исходным кодом и доступными в магазине.

Сенсорные взаимодействия сохранятся в WinUI 3.0?

@ r7dev да, планируется сохранить тот же уровень сенсорной поддержки.

F # игнорируется в дорожной карте WinUI 3.0. Microsoft снова игнорирует один из своих продуктов.

Мысли о Win32 API

Я также подумал о том, почему Win32 тоже застрял. Я думаю, есть предположение, что это из-за устаревших проектов, но на самом деле это гораздо глубже. Win32 ABI очень легко подключить к выбранному вами языку, nodejs, python, rust, go, ruby, c #, c ++ и т. Д. И т. Д., Например, если мой основной проект находится в ржавчине, и я хочу сгенерировать окно Для управления выводом, как разработчику ржавчины, очень мощно получить доступ к набору API Win32 и создать интерфейс на том же языке.

В OS X для доступа к AppKit вам просто нужно было соединить objc_msgSend C API и получить доступ ко всей инфраструктуре obj-c. Все вышеперечисленные языки действительно хорошо справились с этим, и это позволило легко писать на выбранном вами языке и создавать что-то привлекательное.

Поэтому, если вы хотите, чтобы WinUI 3.x был верным путем для доступа к пользовательскому интерфейсу Win32 с малой задержкой, низким объемом памяти и высоким качеством, вам необходимо учитывать легкость, с которой специалисты по сопровождению других языков могут подключиться к инфраструктуре.

Согласованность пользовательского интерфейса

Если вы действительно планируете отделить пользовательский интерфейс от системы, каков план, чтобы пользовательский интерфейс оставался согласованным с каждым обновлением ОС? Когда Apple вносит изменения в тени и градиенты в AppKit или iOS, приложения, которые полагаются на системные фреймворки, наследуют все эти настройки и остаются согласованными. Это также затруднит вам добавление общесистемных функций, потому что приложения, которые привязаны к инфраструктурам пользовательского интерфейса 3 года назад, могут не работать должным образом с некоторыми новыми системными службами, поэтому со временем у них будет другой уровень совместимости.

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

Двоичный размер

Какова запланированная история внедрения всех этих UI.dll в наши проекты? Будет ли у этих вещей 40 Мбайт среды выполнения, которые необходимо поставлять вместе с нашими проектами? Что произойдет, если проект будет заброшен, начнут ли они выглядеть устаревшими из-за использования старых фреймворков пользовательского интерфейса?

Одним из преимуществ C ++ является то, что он имеет минимальные накладные расходы библиотеки в зависимости от кодовой базы. Конечно, если каждое отдельное приложение с этого момента требует WinUI 3.x, это будет 40 МБ x количество приложений.

Двоичный размер

WinUI уже является зависимостью, как и .NET. Это уже общесистемная библиотека. :)
У вас нет дублированных dll, и у вас их не будет.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@ eklipse2k8

«Я также подумал о том, почему win32 тоже застрял. Я думаю, есть предположение, что это из-за устаревших проектов, но на самом деле это гораздо глубже, чем это. Win32 ABI очень легко подключить к выбранному вами языку , nodejs, python, rust, go, ruby, c #, c ++ и т. д. и т. д. и т. д. Если мой основной проект находится, например, в ржавчине, и я хочу сгенерировать окно для управления выводом, как разработчик ржавчины, это очень мощно для получить доступ к набору API Win32 и создать интерфейс на том же языке ".

Это неоднозначная ситуация, поскольку реализация поддержки WinRT для нового языка - это огромная проблема, которую нужно преодолеть, как только вы это сделаете, вы получите автоматически сгенерированные типизированные привязки к любым новым API. Я недавно работал над проектом Rust, который соединяет Win32 и WinRT (используя API-интерфейсы Composition в окне Win32), и части Win32 определенно были более сложной задачей, хотя мне пришлось неуклюже работать с оставшимися отсутствие поддержки Rust для некоторых функций WinRT, таких как наследование классов. (Определенно помогает то, что использование Composition внутри Win32 теперь возможно, поскольку оно позволяет постепенно улучшать поддержку этой функции вместо того, чтобы заниматься всей моделью приложения сразу)

Вероятно, самая большая проблема заключается в том, что документация по низкоуровневым деталям WinRT ABI неорганизована, и в мире / сообществе очень мало понимания или осведомленности о них, но я надеюсь, что эта ситуация улучшится с проектом xlang.

Какие шаблоны вас больше всего интересуют?

В настоящее время я предпочитаю начинать с проекта «Пустое приложение» (универсальная версия Windows). Мне тоже нравятся шаблоны с предварительно настроенным фреймворком, но только тогда, когда я хочу что-то быстро опробовать. Также было бы неплохо использовать шаблон «Главное меню» и шаблон MDI для UWP (поскольку эти шаблоны существуют и для WinForms)

Вы знали о Xaml Islands для модернизации настольных приложений?
Делает ли эта расширенная обратная совместимость в Windows 10 Xaml Islands более полезными для вас?

Да, я знаю об острове Ксамл. Если смогу, я постараюсь придерживаться чистого WPF или чистого приложения UWP. Я не был в ситуации, когда мне потребовалась бы такая функция.

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

Да, конечно, если работает надежно! Я удивлен тем, что многие комментарии не оценивают такую ​​приятную особенность. Также эта функция может проверять, возможно ли обновление до WinUI 3.0, принимать код XAML, настраивать пространства имен и устанавливать необходимые Nugets WinUI.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Я бы ожидал изменить только пространства имен элемента управления для полноценной работы с WinUI 3.0. Я не хочу тратить много времени на обновление до WinUI 3.0

Вы создаете или используете библиотеки элементов управления UWP Xaml или компоненты WinRT, которые невозможно легко перекомпилировать и обновить вместе с кодом приложения?

Я использую сторонние библиотеки элементов управления UWP Xaml (например, Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement). Я думаю, что смогу самостоятельно обновить простые элементы управления из сторонних библиотек, таких как Dockpanel, до WinUI 3.0.

Какое решение вы бы предпочли для использования компонентов UWP Xaml с WinUI 3?

• Создайте шаблон проекта «Пустое приложение с WinUI 3.0» в Visual Studio для UWP. Зависимость WinUI 3.0 будет установлена ​​как nuget (как в WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . Я бы абсолютно предпочел такое решение, если у меня есть все основные элементы управления. Я ожидал, что все классы из Windows.UI будут иметь эквивалентный класс в пространстве имен Microsoft.UI.

Основная тема WinUI 3.0 была посвящена элементам управления и совместимости с Windows 10, которые можно использовать из UWP и WPF или WinForms через XAML Island, если я прав. Есть ли шансы, что разметка UWP XAML получит какие-то дополнительные функции?

• Отсутствуют триггеры стиля
• Отсутствует стиль `BasedOn = {StaticResource {x: Type TextBlock}}
• Определенные шаблоны данных с типами данных не применяются автоматически, как в WPF (только через ключ)
• Почему каждый второй элемент Windows.UI.Xaml.Controls (TextBlock, Border, ...) объявляется запечатанным ?! Пожалуйста, не делайте этого в WinUI 3.0 с UWP.
• Расширения разметки для контроля четности WPF
• Об этом уже упоминалось, но я собираюсь упомянуть об этом еще раз. Печально, что UWP не использует System.ComponentModel.IDataErrorInfo. Таким образом, я не могу поделиться своим проектом модели с решением UWP.
• ReportControl (для корпоративных приложений)

Я очень жду WinUI 3.0 и его обратную совместимость!

F # игнорируется в дорожной карте WinUI 3.0

Есть ли шансы, что разметка UWP XAML получит какие-то дополнительные функции?

@ Happypig375 , @ mfe-:

Дорожная карта охватывает только начальную версию 3.0, а в начальной версии мы в основном сосредоточены на равенстве и обратной совместимости для существующих функций с небольшим количеством новых функций.

Если вы считаете, что другие новые функции, такие как улучшенная поддержка F # или новые возможности разметки, важны, пожалуйста, откройте новый запрос функции, чтобы мы могли отслеживать их по отдельности!

Почему каждый второй элемент управления Windows.UI.Xaml.Controls (TextBlock, Border, ...) объявлен как запечатанный ?! Пожалуйста, не делайте этого в WinUI 3.0 с UWP.

Элементы управления распечаткой на самом деле - одна из немногих новых функций, которые мы надеемся включить в 3.0 😊

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

F # используется для некоторой внутренней логики - C # для привязки данных и кода пользовательского интерфейса - C ++ для элементов управления и, возможно, некоторых низкоуровневых обработчиков Win32 или даже для запуска диалогового окна WinForms.

Все языки кода равны, взаимозаменяемы, WinUI 3.0 обрабатывает весь пользовательский интерфейс.

Это ксланг 😉

Это ксланг 😉

@MarkIngramUK Хм, я думал, что это мост между языками, который абстрагирует каждый язык, а не позволяет файлы кода с нескольких языков в одном проекте.

Я как бы изо всех сил пытался понять цель xlang - замалчивать обновления, которые происходили в репо (но все еще есть в моем списке наблюдения)

Работает ли xlang до или после компиляции? Это его собственный абстрактный язык, который можно проецировать, или он просто находится между существующими файлами кода?

Да, вы не можете смешивать языки в одном проекте. Это мост, но все же он полезен для этих целей.

@MarkIngramUK Я думаю, что если его код, который можно скомпилировать, то включен.

Было бы хорошо иметь возможность использовать C # для доступа к собственным функциям Win32 без PInvokes и других уловок .NET.

@jesbis Меня, честно говоря, больше интересуют кроссплатформенные аспекты этого проекта ...

Я думаю, что при запуске вам, ребята, следует переименовать его в нечто более _генерическое_, а не строго в "Windows".

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

Если целью в .Net 5 должен быть «One .Net Everywhere», чего, по сути, всегда ожидали все начиная с .Net 1.0, основы для фреймворка «Anything but Win UI» должны начинаться с кроссплатформенности.

Хорошим примером того, как это исправить, является Google Flutter. Flutter находится в самом начале своего развития, но получил ОЧЕНЬ популярность из-за того, что их ядро ​​(также известное как Flutter Engine) на 100% кроссплатформенное и работает везде (включая IoT, Win, OSX, а теперь и Интернет!).

Вот только мой 2с. Я хотел бы вернуться к работе над Xaml, но если он останется в той же строке, что и в UWP, я боюсь, что он не получит нужной тяги и будет еще одной попыткой переписать WPF, которая в конечном итоге потребует еще одной попытки в будущее и так далее.

Пожалуйста, не сердите меня и не воспринимайте мой комментарий как плохую критику. Я просто хочу, чтобы усилия по созданию пользовательского интерфейса в мире .Net получили что-то вроде Flutter, .Net Core 3.0 / .Net 5 и даже Blazor.

Для записи, я начал проект по переписыванию / переносу движка Flutter полностью на C # и .Net Core из-за отсутствия опций в .Net World ...

Кстати, CoreUI - хорошее имя ...

Престижность Джейку Хелферту за это предложение 😄

💃

Кстати, CoreUI - хорошее имя ...

Престижность Джейку Хелферту за это предложение 😄

💃

CoreUI можно спутать с .NET Core

WinUI в значительной степени ориентирован на Windows, но структура XAML в нем может иметь средства визуализации для Metal (iOS и macOS) или Vulkan (Android), а FabricWeb может быть способом PWA / ChromeOS для обработки других платформ.

Если команда когда-нибудь решит перенести платформу представления, Xland или Xamarin смогут обрабатывать среду выполнения для кроссплатформенных приложений.

Что касается миграции с пользовательского интерфейса UWP для входящих сообщений на WinUI 3.0, я процитирую недавнее сообщение в блоге от @dotMorten (https://www.sharpgis.net/post/2019/05/14/The-future-UWP):

Забавное нижнее примечание: с UWP происходит не то, что его убивают: Microsoft делает поворот, доставляя лучшие части туда, где они нам нужны. Это действительно происходило раньше, но, к сожалению, не использовалось как возможность для поворота. Помните Silverlight? Угадайте, откуда взялась кроссплатформенная среда CLR .NET Core. И большая часть кода Silverlight также оказалась в UWP. Если бы они только развернулись и сказали: «Да, мы согласны с тем, что Silverlight не имеет смысла в потребительском запасе, но он процветает в корпоративном пространстве, так что давайте продолжим его, и мы доработаем его до .NET Core и Windows Store». К сожалению, все прошло не так гладко, и многие люди до сих пор страдают от посттравматического стрессового расстройства и опасаются того, что делает Microsoft, которая убивает любые технологии.

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

@weitzhandler WinUI 3.0 - это объединение различных платформ Win32, .NET Core и UWP с одной платформой XAML и взаимодействие с WPF, WinForms и MFC ++.

XAML в Windows отображается до Direct X.

Если вы хотите использовать тот же XAML в сочетании с .NET Core и заставить его работать на других платформах. Вам нужно будет написать новые средства визуализации для этих платформ. iOS и macOS используют Metal как эквивалент Direct X. Android использует Vulkan. Не знаю, как Linux обрабатывает рендеринг, я бы предположил, что это просто Open GL.

Microsoft не захочет делать это самостоятельно, потому что для них это не имеет смысла. Но исходный код WinUI 3.0 будет открытым, поэтому другие могут попробовать сделать его кроссплатформенным.

@mdtauk

Спасибо, что разъяснили это. Наверное, будущее за флаттером.

Это просто мое понимание, я могу ошибаться.

Предполагается, что в будущем Flutter получит поддержку Windows. Поддержка React Native также поступает в Windows. Плюс есть PWA, если вы инвестируете в мир веб-HTML и Javascript.

Для меня вся история WinUI может иметь больше смысла, если они также учтут, позволяя хотя бы базовому подмножеству запускать кросс-платформенный (macOS, iOS, Android), включая Интернет, а также предлагают лучшую поддержку F # и шаблоны проектов (включая Двусторонняя привязка XAML к записям F #, а также более функциональный способ Elmish)

XAML должен быть независимым от среды, точно так же, как HTML , не занимая более 100 МБ даже для самых простых инструментальных приложений, как это делают приложения HTML. Это означает, что структура XAML написана на чистом C / C ++ или C # и может быть размещена в WASM, Win32, UWP, iOS, Android, macOS, Linux и т. Д. С минимальными усилиями при переносе. Вам нужен агностический сервер рендеринга, который используют игровые движки для начала.

Нет, если этот XAML, ориентированный на UWP, решает какие-либо проблемы, с которыми моя компания или я лично сталкивались в течение многих лет с XAML ... и это переносимость. TBH MS полностью ошибается с пользовательским интерфейсом, и он не будет быстро реализован (это тратит много драгоценного времени для многих людей). Этот хакерский прием UWP XAML просто не нравится людям, которым я его показываю ... что печально, потому что это просто означает нескончаемый отпор принятию XAML, и на данный момент у меня больше нет аргументов.

На мой взгляд, единственный способ сохранить XAML:

• Создайте новую независимую / переносимую базу фреймворка для .NET Core и C / C ++.
• Создайте независимый уровень абстракции рендеринга, который любой может расширить с помощью запросов на вытягивание.
• Точно так же, как HTML, сохраните XAML, сфокусированный на концепциях приложений с одним окном (так же, как это делается в играх), НО разрешите расширенные функции рабочего стола для нескольких окон и т. Д. (Это позволяет приложению работать практически в любом контексте, как пользовательский интерфейс игр)

Проще говоря, есть два условия, которые необходимо объединить в одно, прежде чем адаптация XAML будет исключена.

1 MS необходимо поддержать проект XAML, иначе люди опасаются, что он развалится.

2 Он должен быть кроссплатформенным, иначе все застрянут в безумно раздутой среде выполнения HTML.

В любом случае, это мои два цента, и если WinUI 3.0 спроектирован правильно, возможно, перенос будет возможен. На данный момент я не понимаю, что чувствовать.

Здесь есть несколько комментариев о кроссплатформенности, и я не уверен, что WinUI должен быть кроссплатформенным для успеха. В любом случае он не будет хорошо работать на Mac или Linux, поскольку он достаточно отличается, чтобы не чувствовать себя родным ни на одной из этих платформ. Этот проект принадлежит команде, которая обладает обширными знаниями о том, как работают внутренние компоненты Windows, и для них было бы отвлечением оторваться и выяснить, как сделать так, чтобы что-то работало действительно хорошо на Mac или Linux в той же степени.

Кроме того ... Свободно работать на Mac было бы неуклюже, просто посмотрите на iTunes, Apple пришлось перенести всю свою систему пользовательского интерфейса на Windows, и это определенно кажется неуместным. Рендеринг шрифтов отличается, кривые анимации, тени и выбор цвета просто кажутся неуместными в Win10. Я имею в виду, что это нормально и удобно, но я предпочитаю spotify, который не пытается имитировать какой-либо пользовательский интерфейс рабочего стола, а просто использует веб-браузер под капотом. На Mac, если вы увидете прожектор с квадратными компонентами на рабочем столе с закругленными углами и без эффекта раскрытия, это будет так сильно противоречить.

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

Здесь есть несколько комментариев о кроссплатформенности, и я не уверен, что WinUI должен быть кроссплатформенным для успеха. В любом случае он не будет хорошо работать на Mac или Linux, поскольку он достаточно отличается, чтобы не чувствовать себя родным ни на одной из этих платформ. Этот проект принадлежит команде, которая обладает обширными знаниями о том, как работают внутренние компоненты Windows, и для них было бы отвлечением оторваться и выяснить, как сделать так, чтобы что-то работало действительно хорошо на Mac или Linux в той же степени.
Кроме того ... Свободно работать на Mac было бы неуклюже, просто посмотрите на iTunes, Apple пришлось перенести всю свою систему пользовательского интерфейса на Windows, и это определенно кажется неуместным. Рендеринг шрифтов отличается, кривые анимации, тени и выбор цвета просто кажутся неуместными в Win10. Я имею в виду, что это нормально и удобно, но я предпочитаю spotify, который не пытается имитировать какой-либо пользовательский интерфейс рабочего стола, а просто использует веб-браузер под капотом. На Mac, если вы увидете прожектор с квадратными компонентами на рабочем столе с закругленными углами и без эффекта раскрытия, это будет так сильно противоречить.
Нет, я думаю, что этот проект должен быть направлен на то, чтобы предложить лучший в своем классе способ создания нативного программного обеспечения Windows для разработчиков, которые хотят / нуждаются в создании программного обеспечения для Windows. Оставьте кроссплатформенный вопрос командам Electron / Typescript.

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

Это то, что уже было решено командой дизайнеров Microsoft. На веб-сайте Fluent прямо говорится: «Разрабатывайте и создавайте собственные приложения, изначально созданные для iOS, но все же уникальные для Fluent». В документации по Fluent показано, что следует использовать собственные стили элементов управления.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

Чего следует избегать, так это необходимости разрабатывать и поддерживать полностью отдельные пользовательские интерфейсы для каждой платформы. Это не означает, что он должен выглядеть идентично на поверхности, но должен иметь общий макет, и дизайнеры пользовательского интерфейса должны иметь возможность многократно использовать его в максимально возможной степени. Фактический стиль не должен (и не должен) соответствовать стилю системы Windows 10.

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

@KyleNanakdewa Что ж, если они открывают исходный код, пусть некоторые поклонники Xaml уйдут и создадут базовые части платформы. Я думаю, что он, вероятно, достаточно сложен с архитектурной точки зрения и использует преимущества Win32 в достаточной степени, так что я подозреваю, что перенос будет серьезным мероприятием.

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

Этот аргумент мог бы быть убедительным, если бы Microsoft еще не владела существующим кросс-платформенным набором инструментов XAML, который просто предлагает совершенно другой диалект XAML, чем WinUI.

Плюс есть PWA, если вы инвестируете в мир веб-HTML и Javascript.

Да ... "тот мир", который быстро заменяет все, что мы знаем о разработке на базе ОС / Store / Hosted. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Представьте, что «этот мир» существует на _все_ современных устройствах с рендерером HTML5:

• Apple с 1,4 миллиарда
• Дроид с 2,5 миллиардами
• Windows 10 с 800 миллионами

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

Сравните это с Flutter, который с _один_ кодовой базой достигает _все_ из вышеупомянутых торговых площадок, наряду с Интернетом , который, как уже упоминалось, состоит из всех трех, что позволяет максимизировать охват рынка и потенциальные доходы для разработчиков приложений при одновременном сокращении необходимых затрат на создание приложения для этого.

Хотя я большой поклонник усилий здесь по открытому исходному коду , также ориентирован на PWA ).

Управление диаграммами имеет важное значение в любом современном настольном компьютере, управляемом данными, который вскоре станет официальной NET CORE 3 (сентябрь 2019 г.), а в конечном итоге. NET 5 (ноябрь 2020 г.)

Я рассматриваю предоставленный элемент управления с открытым исходным кодом Networkview как эффективный вариант использования Xaml для переноса WPF в элемент управления пользовательского интерфейса Win. Этот перенесенный Win UI послужит хорошей гильдией для других, чтобы портировать другие немного более сложные элементы управления WPF в Win UI.

Мы видим вариант использования 2 в 1, когда наше приложение должно поддерживать режим планшета в будущей ОС Windows Core. Мы подозреваем, что Winform в .NET Core 3 не поможет ... еще одно веское оправдание того, почему элемент управления Win UI - это НЕ просто упражнение PoC, НО должно быть частью основных элементов управления win ui в том же классе FIRST, что и элемент управления Grid, движущийся вперед ..

Если вы считаете, что другие новые функции, такие как улучшенная поддержка F # или новые возможности разметки, важны, пожалуйста, откройте новый запрос функции, чтобы мы могли отслеживать их по отдельности!

Кажется, @migueldeicaza берет дело в свои руки: https://github.com/microsoft/microsoft-ui-xaml/pull/736

Я хочу повторить мысли @ eklipse2k8 о кроссплатформенности. При создании кроссплатформенной библиотеки пользовательского интерфейса вам всегда придется идти на компромиссы. WinUI не должен идти на компромисс - он должен быть современной заменой пользовательского интерфейса Win32 (я больше не хочу называть CreateWindowExW !), И он должен быть демонстрацией того, что вы можете делать в Windows. WinUI на macOS или Android всегда предоставлял возможности, которые никогда не могли сравниться с нативным интерфейсом. Мы пишем кроссплатформенные приложения, и мы пишем собственный пользовательский интерфейс для каждой платформы. Таким образом, клиенты получают наилучшие впечатления от выбора платформы. Если людям нужно кроссплатформенное решение, это нормально, им следует обратиться к другой библиотеке для этой цели - возможно, той, которая обертывает WinUI на платформе Windows.

Что касается PWA, то они не представляют собой полное использование системы пользовательского интерфейса Windows, поэтому рекомендация сосредоточить внимание на «приложениях единого окна» сразу же исключает любую профессиональную часть программного обеспечения (кроме игр). Уже есть решения для PWA и кроссплатформенности - другое нам не нужно.

Обязательный XKCD:
https://xkcd.com/927/

@MarkIngramUK Я думаю, что речь идет о

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

WinUI 3.0 должен оставаться проектом, ориентированным на Windows, чтобы унифицировать различные API и ABI с современной платформой пользовательского интерфейса на основе XAML. Но это не означает, что Xamarin или отдельные лица не могут брать код отрисовки и создавать версии для других платформ.

Все, что действительно потребуется (на высоком уровне мышления), - это обеспечить наличие кода, который отображает XAML на экране в Windows, чтобы другие средства визуализации могли вмешаться в кросс-платформенные сценарии.

WinRT / UWP / XAML потребует некоторого рефакторинга, чтобы вывести их из ОС Windows 10, поэтому следует помнить о том, как выполняется этот рефакторинг, чтобы обеспечить возможность расширения в будущем. Независимо от того, станет ли кроссплатформенность реальностью.

@MarkIngramUK Я согласен с @mdtauk

Не должно быть причин, по которым мы не можем использовать xaml для описания компонентов пользовательского интерфейса в других библиотеках, включая React. Если вы посмотрите на такой проект, как http://www.cshtml5.com , они используют xaml, который конвертируется в html.
Я также не думаю, что кто-то намекает на тот факт, что конечная цель состоит в том, чтобы пользовательский интерфейс выглядел так же на других платформах, но лично я хочу, чтобы на стороне пользовательского интерфейса было что-то, что я мог бы использовать для увеличения своих существующих инвестиций, например, в UWP.

Дело просто в этом. Если я сделаю предложение корпоративному заказчику и представлю классное приложение UWP, которое будет фантастическим во всех отношениях. Если у этого корпоративного клиента есть 1 пользователь, который использует, например, MacBook Pro, тогда у меня сразу же возникает проблема, поскольку корпоративный клиент скорее возьмет что-то, что работает везде (наименьший знаменатель => веб-сайт), чем мое «родное приложение», даже если они будут работать. в Windows 10.

Так что доступность является ключевым моментом. Тот факт, что MS по-прежнему ожидает от нас инвестиций в «нативные приложения» в 2019 году без какой-либо дорожной карты по кроссплатформенности, является безумием.

Любой новый проект с точки зрения предприятия, вероятно, будет следовать вышеуказанной логике доступности, и поэтому все новые проекты будут ориентированы на Интернет, и все потому, что нет дорожной карты, которая включает кроссплатформенные возможности на XAML / UWP.

Итак, мы перенесемся на 2-3 года вперед, никаких новых инвестиций от компаний в UWP / win32, и вы сидите с другим «Silverlight», о котором никому нет дела.

MS даже может сказать мне, что завтра XAML устарел, а «новая» библиотека пользовательского интерфейса - это, например, React. Пока C # можно приклеить к этой новой библиотеке, я буду сокращать свои потери, сбрасывать XAML и использовать эту новую кроссплатформенную библиотеку пользовательского интерфейса. По крайней мере, мои инвестиции долговечны и доступны в долгосрочной перспективе.

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

Что касается PWA, они не представляют собой полноценное использование системы пользовательского интерфейса Windows.

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

Тем не менее, я полагаю, что часть путаницы здесь с моей стороны заключается в том, что пространство имен отражает Microsoft.* , хотя на самом деле это звучит так, как будто оно все еще должно быть Windows.* (или даже Microsoft.Windows.* ) .

Уже есть решения для PWA и кроссплатформенности - другое нам не нужно.

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

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

Иногда производительность и детали UX могут иметь большое значение. Skype максимально расширил охват рынка, используя платформу Electron за счет снижения производительности, что привело к коммерческой катастрофе.

По поводу кроссплатформенных (xplat) решений.
Решения Xplat представляют собой абстракцию над несколькими собственными базовыми системами. Насколько я понимаю, WinUI будет родной системой для Windows.

Если бы WinUI также был xplat, как бы он мог включать в себя уникальные особенности Windows? Разве это не помешало бы ему делать новые и инновационные вещи? Или это будет означать, что Microsoft должна переносить что-то новое или отличаться от Windows и на другие платформы? А как насчет вещей, которые нельзя перенести, потому что другая базовая ОС не может их поддерживать - не следует ли их добавлять в Windows?

Если вы создаете что-то с использованием собственных технологий Windows, разумно предположить, что Microsoft будет поддерживать это в течение определенного периода времени и обеспечит путь к более новым системам на базе Windows в будущем. (Признавая SilverLight исключением.) Я не думаю, что разумно предполагать, что если вы создаете что-то с использованием собственных технологий Windows, а затем хотите запустить это в конкурирующей операционной системе, то Microsoft / Windows должны сделать это легко. Если бы вы создали приложение для iPad с помощью Swift и хотели бы перенести его на рабочий стол Windows, ожидали ли вы, что Apple изменит разработку для iOS, чтобы упростить эту задачу?

Если вам нравится или вы предпочитаете использовать собственные технологии Windows, это прекрасно. Чего вы не можете сделать, так это отложить принятое вами бизнес-решение при выборе этих технологий на кого-то другого. Любой выбор технологий имеет последствия, и никто не знает, что может потребоваться через несколько лет в будущем или чего могут попросить ваши клиенты. Запрос на программное обеспечение, разработанное специально для Windows, чтобы его можно было запускать где-либо еще, может создать впечатление, что цель состоит в том, чтобы избежать принятия технологического решения, которое может иметь возможные негативные последствия в любой момент в будущем. Исходя из природы технологий и скорости изменений, я не думаю, что это реально.

Тем не менее, если вы хотите создать решение xplat (а есть много людей, которые делают и есть причины для этого), потому что вы либо хотите настроить таргетинг на несколько операционных систем сейчас, либо, возможно, захотите сделать это в будущем, тогда это разумный и понятный сценарий.
Для этого у Microsoft есть Xamarin. Или, если вы предпочитаете что-то с XAML, больше похожее на UWP, есть Uno. (Есть и другие варианты.)
Если, как и я, вы хотите, чтобы у Xamarin была лучшая встроенная поддержка для создания приложений Windows, я не думаю, что WinUI попытается сделать несколько вещей, это ответ.

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

По поводу кроссплатформенных (xplat) решений.
Решения Xplat представляют собой абстракцию над несколькими собственными базовыми системами. Насколько я понимаю, WinUI будет родной системой для Windows.

Извините, но я так не думаю ...

Посмотрите на Flutter ... У него есть основной движок, который может рендерить что угодно на любой поддерживаемой платформе.

Вдобавок ко всему, у него есть компоненты, которые полностью реализованы в Dart с использованием уровня, управляемого движком, и который представляет (рисование / рендеринг) с точностью до пикселя платформу и язык дизайна, которые вы хотите использовать, например, Material.io и Apple Cupertino.

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

Я не думаю, что разумно предполагать, что если вы создаете что-то с родными технологиями Windows, а затем хотите запустить это в конкурирующей операционной системе, то Microsoft / Windows должны сделать это легко.

Правильно ... Я думаю, что здесь другие говорят о том, что в наши дни это кажется немного отсталым / глухим, особенно в контексте запуска нового приложения. Зачем кому-то создавать собственное приложение для Windows, если оно достигает лишь небольшого процента рынка? Это плохое использование капитала.

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

Именно об этом я и говорю ...

Например, появятся устройства для встраивания flutter для рабочего стола как на Win10 (WPF и UWP), так и на OSX.

Они на 100% управляются средой выполнения flutter, но они используют только (например) WPF / UWP для получения управления окнами и указателя Graphics . Все остальное - движок ...

Мы сами портировали движок флаттера на встроенное устройство ARM, и я должен сказать, что это был потрясающий опыт. Почему? Потому что он создан для того, чтобы быть портативным и работать где угодно, позволяя «встроенному устройству» иметь дело с деталями реализации конкретной платформы на примитивах, таких как графический процессор, программный рендеринг, управление вводом и т. Д.

Вот почему я говорю, что WinUI с помощью UWP: The empire strikes back не будет работать долгое время.

MSFT должен иметь что-то кроссплатформенное, открытое и портативное. Так же, как они поступили с .Net Core, с Blazor и т. Д. Reinvent UWP / XAML никуда не денется.

Я считаю, что XAML имеет хороший потенциал при правильном использовании в том смысле, что он используется для «описания» (или объявления, как некоторые говорят) пользовательского интерфейса. «Движок» строит из него дерево рендеринга, а затем отправляет команды рендеринга на базовую платформу.

Как MSFT недавно сделал с Chromium в качестве ядра для Edge, я считаю, что WinUI (или как бы там его ни называли) может использовать Skia, поскольку у него есть бэкенды для GL, DX, Vulkan, Software Rendering, FB и т. Д. Просто начав с что у вас есть ОГРОМНЫЙ потенциал для добавления других платформ позже ...

@galvesribeiro ,

Посмотрите на Flutter ... У него есть основной движок, который может рендерить что угодно на любой поддерживаемой платформе.

Вдобавок ко всему, у него есть компоненты, которые полностью реализованы в Dart с использованием уровня, управляемого движком, и который представляет (рисование / рендеринг) с точностью до пикселя платформу и язык дизайна, которые вы хотите использовать, например, Material.io и Apple Cupertino.

Отлично, поэтому, как только Apple выпустит обновление для macOS и обновится пользовательский интерфейс (возможно, изменится радиус угла кнопки или изменится фоновый градиент и т. Д.), Ваше приложение Flutter не обновится и продолжит выглядеть как предыдущая ОС - в отличие от родной контроль, который будет получать льготы бесплатно.

@MarkIngramUK - это работа команды по поддержке обновлений.

Подобно тому, как команда Xamarin предоставляет обновления с дня 0 + 1, эта команда может делать то же самое. Команда Google тоже этим занимается ...

Используя «родной» элемент управления, вы снова возвращаетесь в мир Xamarin, где только вы это делаете, оболочки (также известные как Renders) ...

Мы не обсуждаем привязки C # к собственным элементам управления (как это делает Xamarin) ... Мы говорим о полной структуре пользовательского интерфейса, как вы это делаете с Flutter ...

К сведению, никто не использует тему «по умолчанию» ни для одной платформы. Все они создают свой уникальный UX на основе языков дизайна каждой платформы.

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

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

Также Flutter позволяет использовать «тему» ​​на всех платформах. Таким образом, вы можете запустить Купертино на своем ПК с Win10. БОЛЬШОЙ пример - материальный дизайн. Это язык дизайна, а не набор элементов управления. Его можно использовать где угодно ... Просто так случается, что на некоторых платформах (например, Android) есть собственные элементы управления, реализующие его ...

@MarkIngramUK

Я просто разъясняю, почему WinUI не должен быть просто заменой Win32, вот и все.

Если это так, то я почти уверен, что в обозримом будущем он упадет, как и UWP ...

Я согласен с тем, что сам

WinUI 3.0 включает извлечение всего этого кода и рендеринг XAML из ОС Windows, превращение его в платформу, независимую от цикла обновления ОС, и создание его с открытым исходным кодом.

Как его поднимать и переупаковывать, пока неизвестно. Только те, кто работает в Microsoft, знают, как они это сделают. Чтобы обеспечить поддержку кроссплатформенной поддержки XAML в будущем, я только надеюсь, что будут задумываться о том, как этого можно достичь в будущем, поскольку они выводят его из Windows.

.NET Core уже доступен на других платформах. Итак, код C # уже можно передавать. Теперь это просто XAML, пользовательский интерфейс и элементы управления, которым нужен путь к iOS / macOS / Android / Linux (и тому, что может появиться в будущем).

Возможно, это выходит за рамки WinUI 3.0, но определенно связано с этим проектом и усилиями.

@jesbis @terrajobst @jevansaks

Каковы планы Microsoft по внедрению инфраструктуры пользовательского интерфейса в .NET Core, которая будет отображаться на настольных компьютерах, мобильных устройствах (Droid, iOS) и в Интернете?
Неуверенность в этом существует уже очень давно.

@weitzhandler , у них уже есть дорожная карта со следующим абзацем:

Родная цель Windows для веб-платформ и кроссплатформенных платформ.
WinUI 3 лучше оптимизирован для библиотек и фреймворков для построения на.
Например, мы планируем основать новую высокопроизводительную реализацию C ++ React Native Windows на WinUI 3.

Обратите внимание на выделенную часть «надстроить». Как я уже говорил выше, нет причин, по которым это не может быть прежде всего Windows, когда на ее основе создаются другие библиотеки.

Хорошо, тогда...

/me keep working on FluSharp

что разумно, но я не думаю, что это должен быть этот проект.

Там, @MarkIngramUK ,

со следующим абзацем

Немногое говорит. Это не раскрывает четкого намерения MS сделать разработку на C # и .NET xplat. Возможно, он говорит, что HTML JS и CSS shi {- лучшее оборудование для вас, чем C #, если вы хотите быть портативным.

На данный момент Xamarin и Xamarin Forms - это история Microsoft для разработки C # и .NET Core вне Windows.

React Native для Windows подходит для кода Javascript и собственного пользовательского интерфейса (который будет использовать WinUI 3.0 XAML)

На данный момент Microsoft не объявляет о планах переноса XAML WinUI 3.0 на другие платформы.

WinUI - проект пытается объединить среды разработки Win32, WPF, MFC, UWP, .NET Core в рамках единой современной среды представления XAML.

Я думаю, что после этого следует заняться поиском способов рендеринга XAML, написанного для WinUI 3.0 - на таких платформах, как macOS, iOS, Android и т. Д. - но пока это не входит в повестку дня.

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

Есть ли планы сделать F #, рыжеволосого пасынка .NET гражданином высшего класса? А потом люди задаются вопросом, почему подавляющее большинство разработчиков .NET не трогают F # десятифутовой палкой.

На данный момент Xamarin и Xamarin Forms - это история Microsoft для разработки C # и .NET Core вне Windows.

Да, Xamarin.Forms портируется на macOS, GTK, UWP и WPF, плюс к тому, что материальный дизайн повсюду в работе, что делает его де-факто .NET UI Framework, но он настолько медленный и глючный, что мне интересно, что думает Microsoft о своих разработчиках. Взгляните на список проблем! Как только начнется серьезная разработка, ошибки будут появляться слева и справа. Я надеюсь, что с WinUI мы, наконец, сможем улучшить опыт разработки.

Re: F #

Если вы считаете, что другие новые функции, такие как улучшенная поддержка F # или новые возможности разметки, важны, пожалуйста, откройте новый запрос функции, чтобы мы могли отслеживать их по отдельности!

Да, всегда отдельно отслеживаются и снова игнорируются F #. Достаточно взглянуть на UWP и .NET Native - оба не имели в виду F #, и сообществу в целом пришлось во всем разбираться. 🙄 Спустя 4 года F # по-прежнему не поддерживается в .NET Native.

Для предложений / вопросов F # я создал специальный выпуск:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

Не стесняйтесь направлять туда обсуждения F #.

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

RE: кроссплатформенный интерфейс:

Спасибо всем за поднятые вопросы и за страсть к .NET и Xaml.
Я просто хочу еще раз сказать, что мы внимательно прислушиваемся ко всем отзывам и будем делиться своими мыслями и обновлениями по мере нашего прогресса.

Просто чтобы подтвердить текущую дорожную карту и некоторые поднятые вопросы:

WinUI - это собственная платформа пользовательского интерфейса для Windows (включая собственные приложения, а не только .NET), и для начальной версии 3.0 мы в первую очередь сосредоточены на том, чтобы сделать ее независимой от ОС и работать над ее подготовкой для разработки с открытым исходным кодом в более быстром выпуске. цикл. Мы хотим убедиться, что объем работ достаточно реален, чтобы мы могли выпустить предварительный просмотр в этом году.

Одна из других наших текущих краткосрочных целей - позволить WinUI служить нативной целью для других платформ для использования в Windows: например, мы также работаем над обеспечением react-native-windows - высокопроизводительной реализации C ++ React Native. для Windows - использует WinUI , и что элементы управления WinUI могут использоваться для создания собственных представлений пользовательского интерфейса в приложениях React Native.

Я буду совершенно честен. У меня есть собственное настольное приложение для Windows, которое я написал в 2006 году на WinForms, и я все еще продаю его в Интернете.

Я не планирую переносить это приложение на WPF, UWP или использовать какую-либо эксклюзивную технологию пользовательского интерфейса Windows. Меня не волнует, насколько убедительны демонстрации Windows. Если я когда-нибудь снова решу поработать над этим приложением, следующая основная версия будет некой кроссплатформенной реализацией, которая сможет работать в MacOS, Linux и Windows.

В настоящее время это, вероятно, будет выглядеть как Blazor + .NET Core + Electron.

Я думаю, что @ Mike-EEE делает несколько замечательных замечаний. UX / платформа, которая позволяет мне использовать свои навыки C # для охвата наибольшего числа аудитории, - это более вероятная технология, которую я выберу.

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

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

В экономике товар - это экономический товар или услуга, которые имеют полную или существенную взаимозаменяемость: то есть рынок рассматривает экземпляры товара как эквивалентные или почти эквивалентные, независимо от того, кто их произвел. https://en.wikipedia.org/wiki/Commodity

Microsoft должна решить, хочет ли она быть частью истории разработки инструментов? Или Microsoft инвестирует миллионы долларов в новый стек UX только для Windows, который в конечном итоге пополнит кладбище стеков UX, которыми пользуется все меньше и меньше людей?

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

Это тяжелое положение, чтобы быть уверенным. Но времена изменились. Сегодняшний мир сильно отличается от того, каким был в 1995 году. На мой взгляд, есть несколько вариантов:

Вы можете нанять больше людей, чтобы расширить свои знания за пределы Windows.

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

Точно так же, как WSL для запуска Linux в Windows.

• Используйте знания команды, чтобы GTK работал в 200 раз быстрее.
• Используйте знания команды, чтобы приложения QT работали в 200 раз быстрее.
• Используйте знания команды, чтобы приложения Electron отображались быстрее, чем любая другая ОС.

Можно проделать большую работу, чтобы улучшить кроссплатформенную совместимость Windows UX. Но инвестировать в совершенно новый стек UX и надеяться, что мы все перейдем (без какой-либо кроссплатформенной истории), - довольно большая ставка. Я должен избавиться от этой привычки, создавая новые UX-фреймворки только для Windows.

Всего два цента. :сумка денег:

: horse_racing:: cowboy_hat_face: Lil Nas X - Old Town Road (Официальный фильм) при участии Билли Рэя Сайруса

@bchavez

Я должен избавиться от этой привычки, создавая новые UX-фреймворки только для Windows.

-- Не только это. Даже привычка ломать собственную внутреннюю переносимость XAML Windows. WPF, Siliverlight, UWP - все на своей собственной вилке ... Подобные вещи отталкивают все больше и больше людей от инструментов разработки для Windows в целом, которые я лично хотел бы продолжать использовать в будущем. Чем больше отталкивают инструменты разработчика Windows, тем меньше актуален C #, и для меня это то, что меня волнует, когда я перехожу к нему.

RE: кроссплатформенный интерфейс:

... WinUI - это собственная платформа пользовательского интерфейса для Windows (_ включая собственные приложения _, а не только .NET), и для начальной версии 3.0 мы в первую очередь сосредоточены на том, чтобы сделать ее независимой от ОС и работать над ее подготовкой к использованию с открытым исходным кодом. разработка в более быстром цикле выпуска. Мы хотим убедиться, что объем работ достаточно реален, чтобы мы могли выпустить предварительный просмотр в этом году.

Добавьте +1 для идеи обновления внешнего вида элементов управления WinForms, MFC, WPF, работающих с WinUI 3.0, чтобы лучше соответствовать стилям элементов управления Fluent / FabricWeb.

Конечно, разные размеры элементов управления (что-либо, кроме WinRT XAML, вероятно, должно соответствовать своим метрикам компактной версии элементов управления UWP), но один согласованный и согласованный отшлифованный вид.

Добавьте зависимость WinUI 3.0 в WinForms, и элементы управления изменятся.

Приложения WinUI 3.0 WPF обнаруживают и используют темы элементов управления Fluent.Light.xaml или Fluent.Dark.xaml.

@weitzhandler Я понимаю ваше мнение. Я надеюсь, что мне никогда не придется прикасаться к javaScript и тому подобному, чтобы создать этот кроссплатформенный графический интерфейс. Мне не нравится даже думать о запуске проекта с использованием электронов, углов, дротиков, флаттеров.
Я надеюсь, что скоро мы сможем получить решение с .NET 5, которое принесет мечту об универсальном XAML. Microsoft XAML поддерживает WIN, Интернет, мобильные устройства, настольные компьютеры и Интернет вещей.
Silverlight почти справился с этой задачей во многих случаях использования .

Я должен избавиться от этой привычки, создавая новые UX-фреймворки только для Windows.

WinUI 3.0 никогда не будет выпущен, если нам придется дождаться (неизбежно скомпрометированной на всех платформах) кроссплатформенной поддержки. WinUI должен быть фреймворком пользовательского интерфейса самого низкого уровня в Windows, и если вам нужна кроссплатформенность, создавайте его поверх (или используйте React Native, Xamarin и т. Д.).

Я должен избавиться от этой привычки, создавая новые UX-фреймворки только для Windows.

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

Наша первоначальная цель:

• устранение препятствий для использования существующих современных нативных технологий (пользовательский интерфейс Windows 10 Xaml и композитор) путем отделения их от ОС и предоставления им возможности работать с существующими моделями приложений (win32 и UWP), языками, другими фреймворками (через острова) и версиями Windows.

• обновить наш инженерный процесс, чтобы он был с открытым исходным кодом

WinUI 3.0 никогда не будет выпущен, если нам придется дождаться (неизбежно скомпрометированной на всех платформах) кроссплатформенной поддержки.

Чувак ... Если вы действительно в это верите, вы имеете в виду, что успешные фреймворки, такие как Flutter, не работают ...

Мне тоже не нравится Dart, но они ДЕЙСТВИТЕЛЬНО выпустили классный продукт, который развивается и ДЕЙСТВИТЕЛЬНО быстро набирает обороты.

Я разочарован тем, что WinUI станет только вещью Windows ...

.Net нужна инфраструктура пользовательского интерфейса, которая соответствует всем возможностям кроссплатформенной платформы .Net Core, как мы только что получили для Web с Blazor (клиентская и серверная).

Я думаю, что пока нам все еще нужно полагаться на усилия сообщества.

Я понимаю, что ваша команда пытается сделать @jesbis ... Просто многие из нас устали видеть UI в .Net / C ++ / UWP / MFC / Windows как нечто _silo_, которое работает только в Windows, в то время как весь мир (за исключением Apple и OSX) идут противоположным путем, предлагая разработчикам все более качественные кроссплатформенные решения. Как вы упомянули React и Rect-Native (к сведению, мне тоже не нравится, просто упомяну, что они развиваются).

Так что сейчас у нас есть просто инициативы сообщества, такие как Avalonia или даже Uno и другие фреймворки (например, FluSharp, над которым я работаю, как уже упоминалось), которые развиваются ОЧЕНЬ МЕДЛЕННО по очевидным причинам ...

Мое предложение состоит в том, чтобы вместо того, чтобы просто вывести XAML и композитор из кодовой базы Windows и сделать его доступным только для Windows, получить его и сделать правильные абстракции, чтобы он мог работать на нескольких платформах. Как и в случае с .Net Core, который изначально был предназначен только для Windows, но благодаря усилиям сообщества он работал довольно быстро на Linux, OSX и даже на устройствах ARM ...

(неизбежно скомпрометированный на всех платформах) кроссплатформенная поддержка

Я действительно не думаю, что это будет проблемой, учитывая, что кроссплатформенный дизайн является и всегда был ключевым аспектом пользовательского интерфейса XAML UWP и Fluent Design. Определенно есть некоторые элементы управления, визуальный дизайн которых отличается в разных версиях Windows - это выполняется без проблем, вы получаете собственный пользовательский интерфейс, соответствующий ОС устройства.

Например, Acrylic и Reveal встроены в элементы управления, акцентируют цвета на Pivots и NavigationViews - эти вещи не отображаются в Creator's Update, но есть в FCU и новее. Никаких изменений не требуется.

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

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

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

Понятно, что MS в целом ориентирована на кроссплатформенность - мы видим это с помощью Fluent Design (который теперь имеет примеры для iOS, Android и Интернета), большого количества приложений, созданных MS на других платформах, поэтому общий пользовательский интерфейс действительно просто большое недостающее звено. Вот почему было бы так обидно не увидеть этого - я думаю, многим людям нравится идея универсальной платформы приложений, созданной MS, но нет смысла поддерживать ее, если у нас нет полное решение для него.

Дело в том, что ... Как и в случае с material.io и Купертино, мы могли бы (и я не удивлен, если Google этого еще не делает!) Иметь "тему" на флаттере для свободного языка дизайна ...

И это моя точка зрения, когда я сказал, что действительно кроссплатформенный UI-фреймворк не будет заботиться об этом и будет просто работать, как Flutter ... Я не вижу, где у нас есть компромиссы по этому поводу ...

@weitzhandler Мне тоже не нравится HTML для нативных приложений. В противном случае я бы использовал Electron с React 😄

Я здесь просто не страстен, а просто веду себя рационально.

Я действительно с нетерпением жду WinUI 3.0 и сразу же использую его для нового проекта рабочего стола Windows на C ++ / WinRT. И я надеюсь, что в следующей основной версии после 3.0 будет представлена ​​переносимая среда выполнения для размещения приложений WinUI (например, среда выполнения Flutter). Для значительного числа бизнес-приложений и приложений, подобных Photoshop, графический интерфейс пользователя может быть одинаковым на каждой платформе, но ключевым моментом является производительность и повторное использование исходного кода. И я также считаю, что проект xlang - отличная идея и обещает хорошие новости в будущем.

Я предлагаю пользователям найти время, чтобы послушать Скотта Хантера после BUILD 2019 о том, как можно объединить Win UI, Xamarin Form, UNO, Web Assembly.

.NET Core 3 и выше со Скоттом Хантером @ .NET Rock

И Xamarin Forms (XAML), и UNO (XAML) были созданы с учетом кроссплатформенности. В случае UNO (помимо iOS, Android, XAML для Интернета через веб-сборку).

UWP создавался без видения выхода за пределы экосистемы Microsoft, например Web, Android, iOS. Все впечатляющие усилия по разработке Fluent практически не требуются из-за медленного внедрения UWP.

Как отметил @ Mike-EE, у droid и iOS 2 и 1,5 миллиарда, а у Win10 - 0,9 миллиарда. Большинство разработчиков по-прежнему не хотят переходить с WinForm и WPF на UWP.

ПОЧЕМУ? Элементы управления UWP от коммерческих и Microsoft НЕ ПОЛНЫЕ !!!!! по сравнению с WinForm и WPF. Microsoft не прилагает никаких усилий, чтобы помочь этому переходу. XAML - слепое пятно как то , что не хватает , что разработчики нуждаются в переход к UWP из Winform и WPF.

В связи с отсутствием элементов управления UWP теперь прилагаются значительные усилия по внедрению пользовательского интерфейса Win в React Native for Web. ?????? Нам нужны эти отсутствующие элементы управления Win UI для UWP, чтобы мы могли лоббировать переход от WinForm и WPF к UWP .

Одним из таких элементов управления является

==> Я понимаю необходимость разъединения пользовательского интерфейса UWP. Имеет смысл только распространять брендинг Fluent Design на другие платформы, например iOS, Android, Интернет.
==> Пожалуйста, сосредоточьтесь на улучшении управления 3D-моделями и элементами управления диаграммами (как 2D, так и 3D).

Имеет смысл оставаться и ждать NET5 только тогда, когда ВСЕ BCL из (моно объединено с родным Windows, для веб-сборки и т. Д.), Потому что Я ВИЖУ БУДУЩЕЕ творческого 3D UI HOLOLENS.

Для этого нам нужен элемент управления 2d / 3D Diagram Control для UWP и элемент управления 3D-моделью, который должен не просто отображать модель, но позволять разработчику получать доступ к скелетной / вершинной анимации.

@jesbis Я призываю вас привлечь больше людей к этим USP (уникальным

@weitzhandler

Этот вопрос был создан для обсуждения дорожной карты WinUI 3.0 .

@jesbis сделал уточняющее заявление :

WinUI - это собственная платформа пользовательского интерфейса для Windows (включая собственные приложения, а не только .NET), и для начальной версии 3.0 мы в первую очередь сосредоточены на том, чтобы сделать ее независимой от ОС и работать над ее подготовкой для разработки с открытым исходным кодом в более быстром выпуске. цикл. Мы хотим убедиться, что объем работ достаточно реален, чтобы мы могли выпустить предварительный просмотр в этом году.

Ваши первые два комментария были по теме.

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

Это должно остаться продуктивным профессиональным разговором с Microsoft.

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

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

Кроссплатформенность и Интернет

.NET Core великолепен. Наконец-то мы можем настроить таргетинг на каждую платформу и точку взаимодействия с помощью отличных инструментов и отличного языка.
Единственное, чего не хватает, так это стека пользовательского интерфейса, за исключением Blazor (хотя HTML / CSS - отстой). Для максимальной сопоставимости было бы замечательно иметь структуру, которая позволяет разработчикам настольных компьютеров мигрировать в Интернет и за его пределы с теми же навыками, инструментами и языком (Xaml и C #). Тбх, Silverlight там здорово поработал - просто заработало). Я не уверен, что WinUI должен быть такой структурой, но, пожалуйста, поднимите этот вопрос внутри компании. По сути, Flutter для разработчиков .NET, и ориентация на Интернет будет самым большим преимуществом.

Не уверен, что Xamarin может быть этой платформой, но если да, убедитесь, что Xaml максимально выровнен между WinUI и Xamarin.

WinUI

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

HoloLens и не только

С приближением Lite и новых супер захватывающих форм-факторов, таких как HoloLens, можно утверждать, что UWP не готов к этому с точки зрения пользовательского интерфейса. Да, мы можем запускать их на HoloLens, что неплохо, но я хотел бы увидеть способ действительно оптимизировать приложения для 3D без использования полной Unity.

WinUI намного опережает Xamarin. Но команда Microsoft просто выпустила Xamarin 4.0 ...
Лично мне больше нравится Xamarin, так как это наименьшее название для кросс-платформы, и в будущем количество нативных приложений для SaaS будет расти.

Помимо Xamarin, есть альтернатива.
1) Почему бы не принять платформу UNO и не сделать веб-рендеринг с помощью SkiaSharp?
2) @ zezba9000 Вам для

Может быть, Microsoft больше продвигает WinUI, потому что внутри нет трассировки открытого исходного кода, в отличие от других кроссплатформенных решений: Xamarin, UNO, могут иметь библиотеки UNIX ...

В любом случае, да пребудет с вами сила.
PS: Спонсор Github от Microsoft, поэтому, пожалуйста, спонсируйте какого-нибудь известного разработчика Mac / Linux для кроссплатформенной вилки WPF / Winforms.

@jkoritzinsky , При переименовании WinUI 3.0 команда WinUI должна остерегаться одного: если вы переименуете любой из типов, которые проецируются в .NET, прогнозы не будут работать (и мы не планируем больше добавлять поскольку это не поддерживаемая расширяемая система). Вот список типов, которые мы проектируем: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Любые изменения типов, отличных от этих, потребуют от пользователей оборачивания своих объектов новыми объектами, реализующими новые интерфейсы, или копирования своих данных в новые типы. В частности, типы INotifyPropertyChanged и INotifyCollectionChanged представляют интерес в отношении островов XAML и обеспечения последующей поддержки.

Я согласен и рад, что вы подняли этот вопрос, хотя я хотел бы добавить, что я считаю эти прогнозы досадным злом. Мы не проецируем все API, которые, вероятно, должны быть (думая об API System.IO), поэтому мы должны либо исправить это, либо думать иначе. Одна вещь, которая приходит в голову, - не добавлять типы, похожие, но разные, на типы .NET в другом пространстве имен. Вместо этого мы должны позволить нашим разработчикам на C ++ также использовать System.ComponentModel.INotifyDataErrorInfo. Это вроде того, что мы сделали с C ++ / CLI, но это не потребовало бы загрузки CLR для чистого приложения C ++. Я не знаю, будет ли это более запутанным, но похоже, что мы утекаем фундаментальные и лежащие в основе различия в технологиях .NET и WinRT на уровне API, что делает вещи бессвязными.

@ meir-pletinsky. NET - это только одна платформа, которую вы можете использовать для создания приложений с UWP XAML. Они хотят, чтобы для разработчиков была доступна проверка текстовых полей, независимо от того, какую платформу они используют.

Это правильно, ведь у нас есть разработчики на C ++, о которых мы заботимся. Хотя, как я уже упоминал выше, я бы хотел, чтобы мы не вызывали путаницы в сообществе .NET только для того, чтобы это произошло.

@mdtauk , нет, WinUI Desktop (ранее Xaml Desktop) позволяет использовать Xaml с Win32 напрямую, без использования острова.

Я думаю, что @ meir-pletinsky имел в виду .NET / C ++, если я чего-то не упускаю?

@MarkIngramUK Я считаю, что мы говорим здесь о двух разных проектах. WinUI должен быть заменой Win32. Люди просят кроссплатформенное решение, что разумно, но я не думаю, что это должен быть этот проект.

Да, полностью согласен! Для меня WinUI - это определение самого современного, производительного и лучшего пользовательского интерфейса для Windows. Xamarin должен стать кроссплатформенной историей Microsoft и должен развиваться, чтобы быть на вершине WinUI.

@mdtauk

Добавьте +1 для идеи обновления внешнего вида элементов управления WinForms, MFC, WPF, работающих с WinUI 3.0, чтобы лучше соответствовать стилям элементов управления Fluent / FabricWeb.

Конечно, разные размеры элементов управления (что-либо, кроме WinRT XAML, вероятно, должно соответствовать своим метрикам компактной версии элементов управления UWP), но один согласованный и согласованный отшлифованный вид.

Добавьте зависимость WinUI 3.0 в WinForms, и элементы управления изменятся.

Приложения WinUI 3.0 WPF обнаруживают и используют темы элементов управления Fluent.Light.xaml или Fluent.Dark.xaml.

Я действительно не хочу, чтобы MS вкладывала время и ресурсы в эти фреймворки, чтобы они выглядели как нативные приложения Windows 10. Поэтому будет WinUI 3.0. Вам нужен внешний вид Windows 10 в приложениях WPF / WinForms? Используйте WinUI 3.0.
MS лучше вкладывать свои ресурсы в закрытие существующих (и блокирование) пробелов между UWP / WinUI и их аналогами Win32, чем повторно посещать свои старые фреймворки. Особенно с учетом того, что WinUI должен стать фреймворком представления для Windows ...

Я хотел бы попросить разъяснений по поводу WinUI и намерений Microsoft в отношении UI / UX:

1. Заменяет ли WinUI ВСЕ из следующего (гипотетически?): Win32, ATL, MFC, WinForms, Silverlight (я знаю), WPF, UWP и / или острова XAML? Я понимаю, что эти технологии будут продолжать существовать и будут продолжать поддерживаться в течение неопределенного времени ; Я просто хочу четко понять, что это то, что Microsoft говорит как «путь вперед», и что (например) мы должны рассматривать WinForms и WPF так же, как мы рассматриваем Win32 или MFC.

2. Унаследован ли WinUI от UWP? (Или насколько они похожи?) Насколько похож (или отличается) WinUI по сравнению с UWP, XAML Islands или WPF?

Как профессиональный разработчик C # и C ++, я начал работать с WinForms, а затем перешел на WPF, а затем вернулся к WinForms просто потому, что мог разрабатывать UI / UX для бизнес-целей в WinForms примерно в два раза быстрее, чем в WPF. WPF дал гораздо больше гибкости, производительности и выглядел намного лучше, но искажение XAML, которое происходило, как только кто-то касался интерфейса через конструктор вместо ручного редактирования XAML, было ужасно. В некоторых случаях я думаю, что WinForms (с использованием конструктора) был на порядки быстрее, чем создание формы XAML или аналогичного элемента управления вручную.

Лично мне бы хотелось, чтобы пользовательский интерфейс был доступен и идентичен для всех продуктов Microsoft. Фреймворк, который может использоваться Win32 или .NET аналогичным образом, будет означать согласованные, современные приложения для ВСЕХ разработчиков Microsoft, а также означать, что общие вопросы и проблемы могут быть решены на сессиях, нацеленных на одну технологию - например, при задании вопроса об элементе управления ответ будет идентичным (если не почти идентичным) для разработчика Win32 ИЛИ разработчика .NET. Это сделало бы изучение «WinUI» полезным для любого стека для любого данного разработчика, а также сделало бы доступ к информации в Интернете (StackOverflow и т. Д.) Намного более ценным, независимо от того, где вы разрабатываете. Хотя я не использую Xamarin, если бы Xamarin можно было заставить следовать по этим стопам (как расширение WinUI?), То приведенное выше утверждение можно было бы применить не только к разработчикам Windows, но и к тем, кто ориентирован на Android, iOS и т. Д.

Для каких приложений я был бы рад использовать WinUI?

Если я правильно понимаю WinUI, и это «путь вперед», заменяющий Win32, MFC, Forms, WPF и т. Д., И такая же структура доступна для нативной разработки или разработки .NET, то я с нетерпением буду заменять композицию во ВСЕХ приложениях, которые я поддерживаю. Современные согласованные пользовательские интерфейсы, которые работают (и ведут себя) одинаково независимо от платформы или стека? Разве это не то, чего мы все хотим? Я не думаю, что кто-то захочет вспомнить, как одновременно использовать CreateWindowEx () и запускать цикл сообщений для отправки событий в Win32, при этом обрабатывая события совершенно отдельно в WinForms или WPF. Пришло время чего-то «современного». Я очень надеюсь, что это то, что есть WinUI (3.0).

Совместимость с ОС и поддержка нижнего уровня

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

Можно ли сделать WinUI статически связываемым или встраиваемым (например, .NET Core / 5)? Нам придется ориентироваться на Windows 8.1, Windows 8, Windows 7 - даже Windows PE. Как мы можем использовать WinUI с этими требованиями?

@shidell :

Унаследован ли WinUI от UWP? (Или насколько они похожи?) Насколько похож (или отличается) WinUI по сравнению с UWP, XAML Islands или WPF?

WinUI 3.0 в некотором смысле станет следующей версией компонентов платформы пользовательского интерфейса Windows 10 / UWP, включая платформу Xaml, композицию и ввод. Это происходит из этой кодовой базы.

Он должен быть очень похож на API-интерфейсы платформы Windows 10 / UWP Xaml, за исключением того, что упоминается в дорожной карте : а именно другое корневое пространство имен, лучшая поддержка смешивания и сопоставления с другими технологиями (например, с использованием модели приложения win32 вместо UWP) и некоторые новые аддитивные функции.

Заменяет ли WinUI ВСЕ из следующего (гипотетически?): Win32, ATL, MFC, WinForms, Silverlight (я знаю), WPF, UWP и / или острова XAML? Я понимаю, что эти технологии будут продолжать существовать и будут продолжать поддерживаться в течение неопределенного времени; Я просто хочу четко понять, что это то, что Microsoft говорит как «путь вперед», и что (например) мы должны рассматривать WinForms и WPF так же, как мы рассматриваем Win32 или MFC.

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

Острова Xaml станут частью WinUI и позволят вам использовать WinUI для создания новых представлений в существующих приложениях (например, WPF, WinForms).

Какие дискуссии ведутся о том, чтобы сделать WinUI доступным для более старых платформ после 1703 года, которая, как я считаю, является самой старой целевой платформой в настоящее время?
Можно ли сделать WinUI статически связываемым или встраиваемым (например, .NET Core / 5)? Нам придется ориентироваться на Windows 8.1, Windows 8, Windows 7 - даже Windows PE. Как мы можем использовать WinUI с этими требованиями?

Спасибо, что поделились своим мнением по этому поводу. В версии 3.0 мы сосредоточены на платформах, указанных в дорожной карте (1703+, с некоторой поддержкой в ​​8.1). Мы определенно понимаем, что у разработчиков есть клиенты и для других версий, и это то, что мы планируем оценивать в будущем.

Замечательно - похоже, что WinUI - это «путь вперед», и, учитывая такое понимание, сказать, что я взволнован, было бы преуменьшением.

В частности, я считаю фантастическим то, что острова XAML позволят разработчикам расширять WinUI на более старые технологии, такие как WPF и WinForms. Это отличный мост «вперед» при работе / расширении старых (бывших) проектов.

Замечательно - похоже, что WinUI - это «путь вперед», и, учитывая такое понимание, сказать, что я взволнован, было бы преуменьшением.

В частности, я считаю фантастическим то, что острова XAML позволят разработчикам расширять WinUI на более старые технологии, такие как WPF и WinForms. Это отличный мост «вперед» при работе / расширении старых (бывших) проектов.

Я хотел бы подумать, был ли создан проект WinForms, MFC или WPF с включенным WinUI 3.0 - они могли бы просто отображать страницы / контент / окна XAML без необходимости использовать остров XAML в окне Form / WPF / HWND Window.

Возможность просто использовать чистый XAML или использовать Island для размещения XAML в предоставляемых фреймворком поверхностях - действительно сделало бы WinUI 3.0 «Единым пользовательским интерфейсом, чтобы управлять ими всеми».

действительно сделает WinUI 3.0 «Единым пользовательским интерфейсом, чтобы управлять ими всеми»

... в Windows. 😉

WinUI 3.0 в некотором смысле станет следующей версией компонентов платформы пользовательского интерфейса Windows 10 / UWP, включая платформу Xaml, композицию и ввод. Это происходит из этой кодовой базы.

В связи с этим, @jesbis , мне интересно, можете ли вы рассказать о том, как будет происходить интеграция между WPF и UWP. В частности, с такими концепциями, как расширения разметки, которые мы просили в UWP уже много лет, но без особого успеха.

Конечно, была предпринята попытка , но реализация WPF оказалась неудачной, несмотря на то, что на разработку ушло более двух лет.

Кроме того, многие службы, которые были доступны в разметке WPF, остаются доступными и реализованными в UWP. Прилагаются ли усилия, чтобы гарантировать, что новая разметка WinUI 3.0 на основе UWP будет полностью соответствовать WPF? Приносим извинения, если это где-то объясняется, но мне еще предстоит проанализировать сообщение, чтобы увидеть его (и приветствую любые ресурсы, чтобы исправить / дополнить мое понимание).

действительно сделает WinUI 3.0 «Единым пользовательским интерфейсом, чтобы управлять ими всеми»

... в Windows. 😉

По крайней мере, для окна выпуска WinUI 3.0. Я надеюсь, что это может стать началом процесса переноса XAML-рендеринга на другие платформы ...

Мне интересно, можете ли вы рассказать о том, как будет происходить интеграция между WPF и UWP. В частности, с такими концепциями, как расширения разметки, которые мы просили в UWP уже много лет, но без особого успеха. [...] Прилагаются ли усилия, чтобы гарантировать, что новая разметка WinUI 3.0 на основе UWP будет полностью соответствовать WPF?

@ Mike-EEE полная совместимость с WPF не является целью для версии 3.0. Однако мы отслеживаем ряд рабочих элементов, чтобы со временем устранить пробелы (например, улучшения расширения разметки # 741 - пожалуйста, посмотрите и оставьте комментарий, соответствует ли это вашим потребностям!) И продолжаем расширять WinUI за пределы WPF (например, # 686 поддержка 3D-моделей).

Если в WPF есть другие специфические функции, которые вы хотите / должны использовать в WinUI, то, пожалуйста, не стесняйтесь открывать для них новые проблемы с предложениями функций или комментировать недавний выпуск № 719 « Функции WPF, которые должны быть в WinRT XAML ». У нас нет бесконечных ресурсов, но мы определенно пытаемся учитывать вклад сообщества при планировании. Как только все станет открытым исходным кодом, у любого желающего будет возможность внести свой вклад в создание новых функций.

Это обнадеживает, @jesbis спасибо, что поделились этим. Я обновил соответствующие голоса в UserVoice, чтобы указать подписчикам на эту проблему.

Я предполагаю, что меня больше всего беспокоит то, что полная верность WPF не является целью, хотя использование WinUI в WPF _ является целью, тогда вы столкнетесь с трениями при принятии WPF, поскольку он имеет превосходную (и оригинальную) модель Xaml.

То есть, похоже, нет очевидного ценностного предложения для включения WinUI3.0 в WPF, во многом так же, как у островов Xaml нет очевидного ценностного предложения. В конце концов, может показаться, что вы пытаетесь ввести регрессивную / неполноценную / недоразвитую модель Xaml в устоявшуюся и превосходную модель Xaml, что просто не имеет никакого смысла.

Для случаев использования WinForms, MFC и т. Д. Да, этот подход имеет смысл для WinUI3.0. Однако с WPF он имеет превосходную модель представления и парадигму разработчика / дизайнера, которой просто не соответствовала никакая другая инициатива MSFT или внешних поставщиков.

@ Mike-EEE, основанный на выступлении Скотта Хантера , мне кажется, что может быть ошибкой, что цель «ONE BCL, чтобы управлять ими всеми» имеет более высокий приоритет, чем «One UI, чтобы управлять ими всеми».

Путем замены MONO, лежащего в основе Xamarin Forms XAML и UNO XAML в веб-сборке через веб-сборку, на общий BCL с AoC, приложения, основанные на XAML Xamarin Forms, Uno XAML в Интернете, ВСЕ ПОЛУЧАЮТ за счет быстродействия.

Такая скорость КРИТИЧНА для всех, кто заботится о будущем своей карьеры, вкладывая средства в C # для кросс-платформы, учитывая острую конкуренцию со стороны других технологий, например, флаттера, реакции и т. Д.

Надеюсь, что на этом пути к .NET5 = общему BCL для управления ими всеми , стандартизация XAML позаботится, частично или полностью, в процессе, НО не является основной целью .NET5.

Еще одним приоритетом, помимо потребности в стандартизации XAML, является распространение брендов Microsoft посредством плавного дизайна на все платформы (мобильные, настольные и веб-версии). [С технической точки зрения, разделение через Win UI 3.0, о котором нас снова и снова просят сфокусировать на цели дорожной карты WinUI 3.0]

В конце концов, насколько UWP, созданный пользовательским интерфейсом Win, на самом деле играет роль в ОДНОМ BCL, ЧТОБЫ УПРАВИТЬ ИМИ ВСЕМИ к НОЯБРЮ2020, когда будет выпущен .NET5, ТАКЖЕ НЕ является высокоприоритетной целью, на мой взгляд.

С маркетинговой точки зрения, к сожалению, не реализовано в технологиях, которые нас глубоко волнуют, заключается в том, что брендинг Microsoft посредством плавного дизайна является повсеместным, а приложение, продвигающее этот дизайн, работает БЫСТРО ВЕЗДЕ.

Вот как я вижу долгосрочную стратегию Microsoft по «захвату доли рынка» из-за отсутствия мобильного присутствия.

Это очевидно, за исключением того, что Я ВИДУ БОЛЬШЕ ПОТЕНЦИАЛА, заложенного в Hololens 2 и более поздних версиях. Для этого НАМ НУЖНО УБЕДИТЬСЯ, что приложения UWP с WinUI 3.0 поставляются с элементами управления трехмерными диаграммами и расширенным средством просмотра трехмерных моделей.

Извините, ребята, я продолжаю настаивать на этом, так как хочу использовать ограниченное время, которое у меня есть, на ЛУЧШЕЙ ИЗ ЛУЧШИХ ТЕХНОЛОГИЙ. :-)

Что касается переходного периода WinUI 3.0

Я бы посоветовал Microsoft работать напрямую с сопровождающими Windows Community Toolkit (некоторые из которых работают на MS), чтобы:

1. Проверьте, нет ли каких-либо непредвиденных препятствий при перенацеливании инструментария на WinUI 3.0 (включая пример приложения).
2. Протестируйте автоматическое переименование пространства имен с помощью Visual Studio или «другого инструмента», чтобы увидеть, насколько гладко оно проходит.
3. Публично сообщите о том, как прошел процесс (сообщение в блоге / проблема GitHub / все, что вам нравится).
4. Предоставьте фрагмент текста о WinUI 3.0 и переходе, который сопровождающие проекта могут добавить в свои GitHub / Nuget / другие Readme-файлы, или хотя бы URL-адрес с краткой информацией об этом. Это поможет быстро освоить WinUI 3.0 всех пользователей этих проектов и объяснить, что им нужно сделать для завершения перехода.
5. Обозначьте предлагаемый процесс перехода и график, который могут принять сопровождающие проекта / библиотеки.

Что касается последнего пункта, это должно охватывать такие предложения, как:

• Создайте новый номер основного выпуска, указывающий, что он будет использоваться с приложениями WinUI 3.0 (такими как WCT v6.0).
• При желании (?) Создайте ветку, содержащую устаревший код, который будет поддерживать проекты, которые еще не обновились до WinUI 3.0.
• Укажите период времени (например, 3/6/12 месяцев), в течение которого будет предоставляться поддержка унаследованных проектов (например, слияние исправлений ошибок и т.п. из основной ветки). Это потенциально может иметь определенные даты, чтобы «синхронизировать» период поддержки между проектами / библиотеками сообщества.

Наконец, я считаю важным определить, что можно сделать, если вам потребуется поддержка Windows 10 версии 1507 и 1607 LTSB. Это единственные 2 поддерживаемые версии W10, которые будут доступны и с которыми WinUI 3.0 не будет совместим на момент выпуска.

Первоначально я собирался предложить протестировать процесс с помощью калькулятора Windows 10, поскольку это приложение с открытым исходным кодом производственного качества. Однако потом я понял, что это приложение должно работать на 1507 и 1607 LTSB еще 6-7 лет. Очевидно, будут некоторые разногласия по поводу поддержки этих типов приложений, особенно когда речь идет о небольших проектах сообщества. Если они действительно нуждаются в этой поддержке, им следует предоставить четкую долгосрочную стратегию того, как это сделать.

По поводу WinUI 4.0 / 3.x / vNext

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

Поскольку большинство из этих элементов выходит за рамки версии v3.0, я считаю, что раньше, чем позже, следует создать новую проблему, чтобы начать сбор отзывов сообщества о WinUI 4.0 / 3.x / vNext. Во всяком случае, это поможет определить как типы работы, которые рассматривает команда WinUI, так и то, что выходит за рамки WinUI и / или ответственности других команд MS.

Пример последнего пункта - я бы очень хотел увидеть такие вещи:

• Поддержка .NET Core 3.0 для проектов UWP (ответственность команды .NET, насколько я понимаю)
• Полная поддержка приложений Windows (UWP и Win32) из ​​Центра приложений Visual Studio (очевидно, что команда WinUI не отвечает за это)
• Более конкретные рекомендации по Fluent Design, аналогичные тем, что вы можете найти в документации по Material Design (опять же, ответственность отдельной команды)
• Использование WinUI 3.0 и дизайна Fluent во встроенных приложениях W10 (отдельные команды и некоторые из этих приложений должны поддерживать версии LTSB)

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

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

Было бы здорово, если бы F # имел такую ​​же поддержку, как C #, например, имел бы те же шаблоны проектов, что и C #.

Я хотел бы, чтобы WinUI (UWP vNext) имел правильный объект Window, такой как у WPF, с методами Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency и Show () / ShowDialog ().

(_Я не уверен, как это окно будет работать (или разрешено) на устройствах с маленьким экраном, таких как мобильные телефоны и Интернет вещей_)

@TonyHenrique в 1903 году появился новый оконный API для UWP, но он далек от завершения.

Снова смотрит на рендеринг XAML в рамках WinUI 3.0.

Вещи, которые я считаю шагом вниз по сравнению с рендерингом WPF:

• Текст не использует ClearType, вместо этого предпочитает сглаживание оттенков серого;
• Отсутствие точности пикселей для таких вещей, как обводка границ;

Я могу понять, когда Windows Phone 7 и Windows Phone 8 должны были использовать общую систему рендеринга - тип технологии экрана и скорость рендеринга подталкивали к повышению производительности. Но с переходом WinUI сначала на рабочий стол и с более крупными дисплеями - возможно, пришло время восстановить эти качества в движке XAML Render.

И если такие вещи, как Hololens и Xbox, требуют особого внимания, почему бы не предложить режим производительности, который можно включить на уровне платформы на тех устройствах, которым требуется рендеринг, как сейчас?

А как насчет шаблона f #?

Если это не работает из коробки в стандартных шаблонах проектов Windows Forms и WPF, ориентированных на .NET Framework 4.5 или новее, мы не сможем принять библиотеку WinUI.

Требование только последней версии Windows 10 и / или приложения UWP является препятствием для принятия дизайна Fluent.

Я бы посоветовал Microsoft работать напрямую с сопровождающими Windows Community Toolkit (некоторые из которых работают на MS).

@kmgallahan
Отличное предложение! Это определенно входит в план. Наша команда часто тесно сотрудничает со специалистами по сопровождению Windows Community Toolkit, и это одна из тех вещей, которые мы хотели бы использовать в качестве тестового проекта.

Снова смотрит на рендеринг XAML в рамках WinUI 3.0.

@mdtauk
Любые изменения рендеринга, скорее всего, выходят за рамки 3.0, но, пожалуйста, откройте для него проблему, чтобы мы могли пересмотреть эту идею в следующих выпусках. Большое внимание определенно уделялось универсальной производительности, что, как вы заметили, привело к некоторым изменениям рендеринга в Windows 8+. Переключатель режима производительности - интересная идея.

А как насчет шаблона f #?

@edgarsanchez , @khoshroomahdi
Похоже, мы проявляем большой интерес к F #! Мы хотели бы услышать больше о том, почему вам нужен F #: пожалуйста, не стесняйтесь комментировать в проблеме F #, почему вам он нужен и для чего вы его используете: # 740

Если это не работает из коробки в стандартных шаблонах проектов Windows Forms и WPF, ориентированных на .NET Framework 4.5 или новее, мы не сможем принять библиотеку WinUI.

@jozefizso
Вы заглянули на острова Ксамл? Эта функция позволяет вам использовать WinRT Xaml в приложениях WPF и Windows Forms, чтобы вы могли начать улучшать их с помощью современных представлений / страниц Xaml:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

Мы планируем включить в WinUI 3.0 острова и обеспечить обратную совместимость с Creators Update и более новыми версиями, по крайней мере, с последними 5 версиями Windows.

Могут ли Xaml Islands, работающие над Creators Update и новее с WinUI 3.0, удовлетворить ваши потребности?

Любые изменения рендеринга, скорее всего, выходят за рамки 3.0, но, пожалуйста, откройте для него проблему, чтобы мы могли пересмотреть эту идею в следующих выпусках. Большое внимание определенно уделялось универсальной производительности, что, как вы заметили, привело к некоторым изменениям рендеринга в Windows 8+. Переключатель режима производительности - интересная идея.

Сделано №768

Для островов XAML требуется Windows 10 версии 1903, а для библиотеки Windows Community Toolkit требуется, чтобы проект был UWP. Это не годится.

Для островов XAML требуется Windows 10 версии 1903, а для библиотеки Windows Community Toolkit требуется, чтобы проект был UWP. Это не годится.

WinUI 3.0 не перейдет на Windows 7/8 / 8.1, но эти ОС очень скоро перестанут работать. И вы все еще можете использовать для них WPF и WinForms. Это когда ваши пользователи перешли на Windows 10.

В этом случае проект будет UWP для Windows 10, поэтому нет смысла поддерживать WPF / WinForms. Это просто движение по кругу и фрагментация инструментов разработчика.

@jozefizso Точнее сказать, что UWP меняется, чтобы он стал больше похож на WPF и WinForms, а пользовательский интерфейс XAML приближается к платформам WPF и WinForms.

Приложения UWP с современным пользовательским интерфейсом XAML выходят за рамки ограничительной песочницы и могут подключаться к платформам WPF и WinForms.

Я так понимаю.

Для островов XAML требуется Windows 10 версии 1903.

В этом случае проект будет UWP для Windows 10.

С WinUI 3.0 мы планируем сделать острова доступными на 1703 и новее (намного раньше).

Мы также работаем над тем, чтобы WinUI можно было использовать с моделью приложения Win32 вместо UWP (неофициально называемого «рабочий стол WinUI»), поэтому это не обязательно должно быть приложение UWP.

Мы также работаем над тем, чтобы WinUI можно было использовать с моделью приложения Win32 вместо UWP (неофициально называемого «рабочий стол WinUI»), поэтому это не обязательно должно быть приложение UWP.

Это то, что меня больше всего волнует. Собственное приложение с полным доступным API Windows, будь то Win32 или среда выполнения Windows, способное иметь производительный пользовательский интерфейс через Xaml.

Мы также работаем над тем, чтобы WinUI можно было использовать с моделью приложения Win32 вместо UWP (неофициально называемого «рабочий стол WinUI»), поэтому это не обязательно должно быть приложение UWP.

Это то, что меня больше всего волнует. Собственное приложение с полным доступным API Windows, будь то Win32 или среда выполнения Windows, способное иметь производительный пользовательский интерфейс через Xaml.

Возьмите приложение WinForms, оставьте код позади, но замените форму окном XAML и получите доступ ко всем кистям и элементам управления XAML.

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

1. Пространство имен следует переименовать. «Xaml» не подходит, потому что Xaml относится к языку разметки, который неправильно используется в качестве языка маркетинга (который часто меняется) для собственных компонентов UWP. «Xaml» следует заменить на «WinUI». Вы можете увидеть, сколько путаницы вызвано даже в этом потоке, где очень часто неясно, относится ли «Xaml» к языку .xaml или к компонентам пользовательского интерфейса.
2. Поскольку это сближает WPF и UWP, это хорошо. У каждого из них есть функции, которых нет в другом, и имеет смысл иметь «пользовательский интерфейс Windows», сочетающий их. Возможно некоторое дублирование функций, но это также может быть путь перехода WPF -> UWP.
3. Отделение от версий для Windows имеет смысл, но также можно предположить, что Win10 будет относительно обновленным, учитывая, что Win7 будет значительно старше EOL, когда эта работа будет завершена.

Xaml - это имя инфраструктуры пользовательского интерфейса. Следовательно, Windows.UI.Xaml ...

Xaml - это имя UI-фреймворка.

Xaml - это технология в WPF, которая позволяла разработчикам эффективно описывать и создавать не только сцены представления в своих приложениях, но и сами приложения. То есть вы можете описывать элементы пользовательского интерфейса _ а также POCOs_. Если бы это был .NET, его можно было бы подробно описать с помощью Xaml и загрузить в контекст приложения.

Чтобы мы не забыли (а это похоже на то, что мы забыли), что Xaml означает eXtended Application Markup Language, что означает, что это язык разметки, который позволяет вам элегантно и эффективно описывать компоненты _application_ .NET. Хотя он в основном использовался для описания элементов пользовательского интерфейса, на практике он не был понижен или ограничен как таковой.

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

Xaml - это не пользовательский интерфейс. Это две совершенно разные концепции, но, к сожалению, уже много лет они объединяются в UWP. Мне, например, нравится видеть термин «Xaml», освобожденный от этих усилий, но я не очень уверен, что такие меры будут рассмотрены, не говоря уже о предпринятых.

@charlesroddie Я согласен, что это название действительно произвольно. Просто касательно, если вы когда-нибудь проверяете следы стека вещей, происходящих из пространства имен WUXaml, на самом деле они находятся внутри пространства имен DirectUI. Я бы хотел узнать историю Win8, если бы кто-нибудь здесь был в те дни, потому что я полагаю, что это была другая история. DirectComp для наложения слоев, DirectManipulation для плавной прокрутки и резиновой ленты, а затем Direct2D / DirectWrite в качестве движка векторной графики с DirectUI наверху, чтобы собрать все воедино. Затем по какой-то причине некоторые из них были обратно перенесены на Win7, только биты Xaml были доступны через систему WinRT, в то время как все другие API остались в виде загадочных интерфейсов com со странными фабриками и шаблонами, которые вам нужно было увидеть, образцы объясняют, как вызывать.

Собственно, теперь, когда я думаю об этом, было бы действительно хорошо, если бы, подобно тому, как WUComposition представил DirectComp и DirectManipulation через WinRT (или это переписывание), Direct2D / DirectWrite также имел здесь формальный дом. Все они работают вместе, чтобы обеспечить различные уровни аварийных люков и точек привязки, если вы это ищете. Win2D на самом деле наполовину готов и тоже не является хорошим API.

Я считаю, что Windows.UI.Composition - это переписывание DirectComposition. API похожи, но не одинаковы.

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

Это может быть немного не по теме, но предположим, что у вас уже есть большое приложение Win32, написанное на C ++, вы хотите модернизировать систему пользовательского интерфейса, поэтому вы можете использовать WinUI или Comp с минимальной зависимостью, например, использовать только Comp без ин- box control set или даже без XAML .

Хотя это уже возможно, для этого не нужно ждать выхода WinUI 3.0.

Спасибо всем за отзывы об именах. Как уже отмечалось, сегодня у нас есть различие между «платформой Xaml» и «языком Xaml» (со своими собственными различными спецификациями / диалектами), что может сбивать с толку. Я не думаю, что предстоит серьезный ребрендинг, но мы определенно обсуждаем именование и пространства имен.

Используйте Windows.UI.Composition в приложении C ++ Win32 без XAML для модернизации существующих приложений (например, Photoshop). У них уже есть архитектура пользовательского интерфейса.

Это может быть немного не по теме, но предположим, что у вас уже есть большое приложение Win32, написанное на C ++, вы хотите модернизировать систему пользовательского интерфейса, поэтому вы можете использовать WinUI или Comp с минимальной зависимостью, например, использовать только Comp без ин- box control set или даже без XAML.

Спасибо за обратную связь по этому поводу - я надеюсь, что это станет возможным в конечном итоге с WinUI 3, аналогично «бескаркасному» приложению с использованием Windows.UI.Composition, которое вы можете сделать уже сегодня. Мы будем иметь это в виду, когда будем определять, как структурировать пакеты WinUI NuGet и зависимости.

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

@ reli-msft, не могли бы вы открыть отдельный выпуск, чтобы отслеживать это?

@jesbis 👉 # 67

Сегодня Apple анонсировала SwiftUI ...

Как насчет того, чтобы предоставить Xaml Direct шаблоны Visual Studio, чтобы разработчики могли создавать приложения с использованием кода вместо XAML и кода.

Я не думаю, что предстоит серьезный ребрендинг, но мы определенно обсуждаем именование и пространства имен.

Спасибо, @jesbis, я благодарен вам за участие в этой теме. Обычно кажется, что кто-то сделает такой пост / объявление, а затем оставит его умирать (или для других, чтобы они редко управляли), поэтому отрадно видеть, что вы, как автор темы, не только вовлечены, но и внимательно к ним относитесь. что говорят другие. Особенно, когда эти другие - _me_. 😆

И вы правы: есть 1) платформа пользовательского интерфейса и 2) механизм языка / разметки / описания. В своих критических замечаниях я скажу, что никогда не уделяю должного внимания (первой) платформе пользовательского интерфейса, поскольку я знаю, что команда Windows проделала большую работу по этому поводу. Лично меня это никогда не беспокоило. Это вторая область, которая вызывает у меня (и других) гнев и ужас, и мы видим это в проблемах UserVoice, которые возникли с годами.

Все это говорит о том, что я бы по крайней мере попросил (прошу, даже 😅) продолжить рассмотрение усилий по брендингу, чтобы лучше классифицировать эти две сферы. Я думаю, что «Xaml Direct» - это вершина путаницы здесь, поскольку его название подразумевает «язык разметки» - это прямо в названии! - но в его фактическом использовании нет ничего подобного. Я бы предложил ужасно сбивающее с толку и вводящее в заблуждение, и граничащее с злоупотреблением брендом.

Кстати о Xaml Direct, @mdtauk :

Как насчет того, чтобы предоставить Xaml Direct шаблоны Visual Studio, чтобы разработчики могли создавать приложения с использованием кода вместо XAML и кода.

Как в чем-то вроде CSharpForMarkup ?

Я бы предложил гораздо лучшее и подходящее имя, чем Xaml Direct. Конечно, _любое_ имя будет. 😉

Кстати о Xaml Direct, @mdtauk :

Как насчет того, чтобы предоставить Xaml Direct шаблоны Visual Studio, чтобы разработчики могли создавать приложения с использованием кода вместо XAML и кода.

Как в чем-то вроде CSharpForMarkup ?

Я бы предложил гораздо лучшее и подходящее имя, чем Xaml Direct. Конечно, _любое_ имя будет. 😉

@ Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

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

@mdtauk ДА! SwiftUI похож на Xaml, но выполнен в коде. Мне очень нравится идея того, что все в коде так, как это делает React. Это своего рода старая школа - разбивать ваши файлы дизайна, а затем связываться с каким-то кодом программной части, и я считаю, что это затрудняет поддержку.

Один друг только что упомянул, что им нужен механизм компоновки SwiftUI для работы с дисплеем iPad Pro с частотой 120 Гц. Вот на чем они сосредоточились. Довольно увлекательно.

Я сделал новый выпуск №804, в котором обсуждение изменений, вдохновленных SwiftUI, могло идти @ eklipse2k8

НЕ ЗАБЫВАЙТЕ добавлять шаблоны для Visual Basic.

Пусть WPF построит _он_ нижние уровни WinUI 3!

@ reli-msft, какие преимущества вы хотели бы получить от обновления WPF?

Если есть определенные функции WPF, на которые вы полагаетесь и которые вы хотели бы видеть в WinUI, мы хотели бы услышать больше в ветке «Функции WPF, которые должны быть в WinRT [WinUI]»: https://github.com/microsoft / microsoft-ui-xaml / issues / 719

Закрытие в пользу нового закрепленного выпуска № 888

Очень жду этого. Решит многие вопросы, связанные специально с версией.

@weitzhandler [16 мая 2019 г.

Для меня все технические детали менее важны.
UWP, WPF или любой фреймворк только для Windows, каким бы замечательным он ни был, его будет недостаточно, пока он не работает на всех платформах (по крайней мере, Windows, Droid, iOS и Интернет) и совместим с любой размер экрана.

Что касается WinUI и XAML в целом, мне бы хотелось увидеть улучшения в следующих аспектах, некоторые из которых меня раздражают и замедляют мою работу.

• НАМНОГО больше встроенных преобразователей. Должно быть множество преобразователей, некоторые из которых даже следует использовать в качестве расширения разметки, чтобы уменьшить многословие. Это также должно включать в себя отрицание простого арифметического действия, преобразователя объекта в логическое значение (ложное по семантическому значению, т.е. пустая строка, пустая коллекция, скрытая видимость и т. Д. Для каждого контекста).
• То же, что и выше, но с поведением. Между привязкой и событиями / действиями должен быть простой порт. Было бы намного проще, если бы это было встроено, и разработчик не сомневался, какой непроверенный NuGet использовать.
• Все, чего не хватает в WPF, например, некоторые типы привязки, расширения разметки, общие представления и другие.

Спасибо!

НАМНОГО больше встроенных конвертеров

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

Весь бизнес переработчиков следует бесцеремонно бросить.

объект в логический преобразователь

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

Да и существующие нетипизированные системы, такие как привязки, тоже должны быть сброшены.

Весь бизнес переработчиков следует бесцеремонно бросить.

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

логические значения являются логическими. Другие объекты не являются логическими.

Вы правы, но когда дело доходит до пользовательского интерфейса, это не имеет особого значения.
Вы хотите показать / скрыть материал на основе обычного состояния объекта. Не все должно иметь специальное свойство видимости.

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

Хм? Я действительно думаю, что у этого есть преимущество. Слабая связь между V и VM может быть хорошей.

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

Слабая связь между V и VM может быть хорошей.

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

Скомпилированные привязки очень помогают в этом.

@weitzhandler Я имею в виду, каковы ваши альтернативы?
... Не все должно иметь специальное свойство видимости.
Хм? Я действительно думаю, что у [bindings] есть преимущество. Слабая связь между V и VM может быть хорошей.

В хорошей реактивной среде вы можете определить наблюдаемые переменные (в коде), такие как name:Mutable<string> а затем сопоставить их с let visibility = name.map(fun s -> s <> "") а затем связать их для просмотра свойств с помощью visibility.bind someView.set_IsVisible или name.bind(fun s -> someView.IsVisible <- s <> "") .

Я использую https://github.com/ReedCopsey/Gjallarhorn, но существуют различные реактивные фреймворки.

Обратите внимание, что: 1. все набрано, в отличие от привязок. 2. Вещи (функции, свойства, представления) называются объектами, а не путем передачи им строковых имен, 3. функции - это просто функции, гораздо менее громоздкие, чем преобразователи, 4. шаблон привязки, где простым свойствам объекта нужно давать дополнительные "связываемые свойства" и т. д. могут быть удалены.

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

Говоря о реактивных фреймворках, пожалуйста, ознакомьтесь с Chain Reactive и скажите, следует ли мне открыть его исходный код.

Привет, может ли команда ms решить все ошибки / функции на uservoice ?
Если бы это было так, это был бы отличный шаг, больше, чем WinUI 3.0.

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

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

@charlesroddie Да, похоже, голос пользователя заброшен. Я отправлю свой голос в Feedback Hub. Возможно, ms проигнорирует их, но я сделаю свою работу.

В этом месяце UserVoice будет полностью удален.

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

Для обратной связи, не связанной с продуктом конкретного репозитория, используйте Центр отзывов. Существует категория «Платформа разработчика» с различными подкатегориями специально для отзывов об API и инструментах разработчика.

Я знаю, что в настоящее время о UserVoice много историй и предыдущих отзывов (которые мы все еще будем отслеживать), но и GitHub, и Feedback Hub предоставляют более прямой путь к нашим командам разработчиков и отслеживанию рабочих элементов, чем UserVoice когда-либо мог, так что, надеюсь, это должно произойти положительное изменение. Мы обновляем различные ссылки для поддержки и обратной связи.

Мы действительно видим все, что приходит с любого канала, и очень ценим отзывы и сообщения об ошибках!

@jesbis Хорошо, понял.

Для WinForms, при использовании нового шаблона проекта WinUI, будет ли по-прежнему работать окно «Свойства» и будет ли возможность устанавливать свойства элементов управления WinUI? Я могу кодировать HTML весь день без проблем (обычно Asp.net MVC), но когда для элементов управления доступно так много настроек, мне нравилось использовать окно свойств последние 20 лет.

@ Dean-NC Я думаю, вы спрашиваете о конструкторе XAML, а не о WinFoms / Windows Forms, верно? Если да, то панель свойств по-прежнему будет работать для элементов управления WinUI при выборе элемента в конструкторе XAML.

@ marb2000 Наверное, я наивно думал, что WinUI 3 принесет новые элементы управления в WinForms в том смысле, что он будет в основном бесшовным, и что у меня может быть форма с устаревшими элементами управления и элементами управления WinUI, и что окно свойств будет работать как для устаревших элементов управления, так и для элементов управления WinUI.

Я прочитал всю публикацию выше, и я с большим воодушевлением следил за ней (как разработчик WinForms), но, думаю, я неправильно понял высокоуровневый рабочий процесс того, как это будет работать (опять же, с точки зрения WinForms ).

Я уже давно говорил, что WinForms все еще может быть отличной вещью на долгие годы, но его самая большая слабость заключается в том, что его основные элементы управления выглядят устаревшими (текстовое поле не допускает заполнения, поэтому оно выглядит тощим, маленькие кнопки переключателя и флажка , так далее.). Даже самые основы элементов управления Win 10 (текстовое поле, радио, флажок) будут иметь большое значение для того, чтобы вдохнуть новую жизнь в WinForms.
Есть ли статья или не могли бы вы дать краткое описание того, каким будет рабочий процесс для нового проекта WinForms, который хочет использовать как устаревшие элементы управления, так и новые?
Спасибо.

@ marb2000 Наверное, я наивно думал, что WinUI 3 принесет новые элементы управления в WinForms в том смысле, что он будет в основном бесшовным, и что у меня может быть форма с устаревшими элементами управления и элементами управления WinUI, и что окно свойств будет работать как для устаревших элементов управления, так и для элементов управления WinUI.

Я прочитал всю публикацию выше, и я с большим воодушевлением следил за ней (как разработчик WinForms), но, думаю, я неправильно понял высокоуровневый рабочий процесс того, как это будет работать (опять же, с точки зрения WinForms ).

Я уже давно говорил, что WinForms все еще может быть отличной вещью на долгие годы, но его самая большая слабость заключается в том, что его основные элементы управления выглядят устаревшими (текстовое поле не допускает заполнения, поэтому оно выглядит тощим, маленькие кнопки переключателя и флажка , так далее.). Даже самые основы элементов управления Win 10 (текстовое поле, радио, флажок) будут иметь большое значение для того, чтобы вдохнуть новую жизнь в WinForms.
Есть ли статья или не могли бы вы дать краткое описание того, каким будет рабочий процесс для нового проекта WinForms, который хочет использовать как устаревшие элементы управления, так и новые?
Спасибо.

Более вероятно, что вы сможете взять свой проект приложения, добавить окна и страницы WinUI и использовать современный пользовательский интерфейс XAML для полной или постепенной замены пользовательского интерфейса.

И есть острова XAML для вставки XAML в существующие пользовательские интерфейсы Winforms и WPF.

Вы, команда Blazor, должны работать с Uno, чтобы включить некоторые из ее моделей хостинга в Uno (в частности, на стороне сервера) и / или получить пользовательский интерфейс Uno (и, следовательно, WinUI 3), рендеринг / визуальный слой, используемый Blazor .... и / или, может быть, острова Ксамл для Blazor?

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

Моя команда разработала только одно приложение UWP. Мы больше не будем развиваться.

Непреодолимое препятствие - отсутствие встроенного средства составления отчетов в виде таблиц. Мы перепробовали всех сторонних разработчиков отчетов на рынке, которые говорят, что поддерживают UWP. К сожалению, ни один из них не работает с UWP. Их предложение UWP обычно представляет собой быстрый взлом своего варианта WPF / WinForms и не будет работать должным образом.

Мы используем Stimulsoft Reports в нашем продукте UWP. В нем очень много ошибок, и они сказали нам, что не будут исправлять ошибки, поскольку их использование UWP настолько низкое.

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

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

Надеюсь, визуальных людей это не обидит :-)

Полностью согласен. Как мы можем разрабатывать современные бизнес-приложения без системы отчетности, которую можно легко интегрировать с приложением? это огромный каньон, который остановит переезд застройщиков.

Бизнес-пользователи должны иметь возможность взаимодействовать с табличными данными, а затем распечатывать их или экспортировать в другие форматы. Они также должны иметь возможность создавать счета-фактуры, цитаты, выписки и другие инструментальные документы.

Насколько я понимаю, бизнес / предприятие по-прежнему остается крупнейшим потребителем Windows. Почему что-то столь важное для экосистемы Windows не разрабатывается для UWP?

Спасибо за отзывы @VagueGit и @Elmarcotoro ! Корпоративный контроль - это пробел для нас прямо сейчас. Но у вас подходящий момент, мы собираем отзывы для разработки элемента управления DataGrid. Пожалуйста, прочтите и оставьте отзыв здесь: # 1500.

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

Для системы отчетности я считаю, что Telerik UI - лучший выбор в настоящее время. Китайская пословица гласит: «Некоторые люди специализируются на одних профессиях, а другие - на других». Telerik, DevExpress или кто-то еще хорошо умеет составлять отчеты.

В отсутствии различных элементов управления мы должны винить не эту команду, а всю стратегию MS. С самого начала Сатья отказывается от мобильных, они больше предпочитают ios и android, потому что босс им нравится. Вся экосистема UWP становится слабой и слабой.

На данный момент в твиттере есть аргумент под названием «UWP мертв», я думаю, MS должна прояснить это и объявить о своем пути к использованию uwp.

На данный момент в твиттере есть аргумент под названием «UWP мертв», я думаю, MS должна прояснить это и объявить о своем пути к использованию uwp.

Вы только что разместили это в ветке дорожной карты ...

@jevansaks Спасибо за информацию об элементе управления

@ hupo376787
«Я считаю, что Telerik UI - лучший выбор для системы отчетности в настоящее время».

Из того, что я вижу, Dev Express - единственные, кто в настоящее время предоставляет полный набор для создания и просмотра отчетов для UWP, и их цены кажутся более высокими. У всех остальных, включая Telerik, есть пробелы в инструментах, что означает, что отчеты для UWP не могут быть созданы. Я хочу (надеюсь), что меня поправят по этому поводу.

Для системы отчетности я считаю, что Telerik UI - лучший выбор в настоящее время. Китайская пословица гласит: «Некоторые люди специализируются на одних профессиях, а другие - на других». Telerik, DevExpress или кто-то еще хорошо умеет составлять отчеты.

@ hupo376787, пожалуйста, будьте особенно внимательны, чтобы проверить свои факты, прежде чем предполагать, что публикация неверна. В Telerik Reporting есть дизайнер отчетов для WPF и WinForms, но не для UWP.

DevExpress также имеет дизайнер отчетов для WinForms и WPF, но не для UWP.

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

@ hupo376787, пожалуйста, будьте особенно внимательны, чтобы проверить свои факты, прежде чем предполагать, что публикация неверна. В Telerik Reporting есть дизайнер отчетов для WPF и WinForms, но не для UWP.

DevExpress также имеет дизайнер отчетов для WinForms и WPF, но не для UWP.

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

Хорошо, я думаю, что у нас другое понимание отчетности. Я имею в виду https://www.telerik.com/universal-windows-platform-ui и https://www.devexpress.com/products/net/controls/win10apps/.

Я ошибся, Dev Express не предоставляет отчеты для UWP. Похоже, что ни один сторонний разработчик инструментов этого не делает! Я связался с Dev Express через их чат, чтобы узнать, есть ли у них дорожная карта по предоставлению отчетов для UWP.
Они сказали,
«XtraReports Suite использует функциональность, предоставляемую сборкой System.Drawing, и то, что мешает нам реализовать тот же набор инструментов для универсальных оконных приложений, заключается в том, что эта сборка там недоступна (https://stackoverflow.com/questions / 31545389 / windows-universal-app-with-system-drawing-and-possible-alternate). Итак, мы еще не определились с нашими планами на будущее в этой области ».

@jevansaks , похоже, что между командой Microsoft UI и этими сторонними поставщиками инструментов отсутствует связь. Мы были бы счастливы использовать сторонние инструменты, но похоже, что платформа UWP затрудняет для этих компаний интеграцию инструментов, которые у них есть для других платформ, в UWP.

Они попросили меня связаться с их [email protected] и сообщить о наших требованиях к отчетности. Для команды Win UI 3.0 может быть полезно связаться с ними и узнать, могут ли они помочь им в реализации. Я не понимаю, как вы получите бизнес-разработчиков на универсальной платформе без надлежащих инструментов отчетности.

https://www.devexpress.com/subscriptions/reporting/

Отчетность: просто с точки зрения WinForms я использовал и Telerik, и DevExpress (даже их последние версии), и хотя Telerik был хорош, я думаю, что DevExpress не только лучше в целом дизайнер и опыт, но и имеет гораздо более тонкие функции, которые позволил мне делать более сложные макеты, чем Telerik. Я считаю, что технология рендеринга DevExpress более продвинутая.

команде Win UI 3.0 может быть полезно связаться с ними и посмотреть, могут ли они помочь им в реализации.

Спасибо за звонок. Мы тоже с ними свяжемся.

Спасибо за звонок. Мы тоже с ними свяжемся.

Может стоит поговорить со всеми и посмотреть, что это за блоки? Telerik, Grapecity, DevExpress и др.

Спасибо за звонок. Мы тоже с ними свяжемся.

Может стоит поговорить со всеми и посмотреть, что это за блоки? Telerik, Grapecity, DevExpress и др.

Конечно, это наш план.

Мы немного отличаемся от большинства разработчиков, создающих для Windows. Мы разрабатываем в основном киоск-приложения (приложения, предназначенные для запуска пользователями, не являющимися владельцем компьютера, и, как правило, в полноэкранном режиме без какого-либо доступа к более широкой системе). Приложения обычно создаются в соответствии с конкретными требованиями клиента, без намерения распространять их через магазин или аналогичный продукт.

Поскольку приложения работают в полноэкранном режиме, встроенные элементы управления имеют очень ограниченную ценность, поддерживающую внешний вид других приложений Windows; вместо этого они, как правило, имеют высокий бренд для каждого покупателя. Нам по-прежнему нужно много общего _поведения_ и элементов управления из стандартных приложений Windows, но мы обычно много настраиваем шаблоны элементов управления каждого из них или, по крайней мере, переопределяем их основные стили. В течение очень долгого времени мы создавали множество приложений в виде бэкэндов WinForms со встроенными интерфейсами Flash для пользовательского интерфейса.

Вообще говоря, почти каждое приложение, которое мы пишем, интегрирует какой-либо веб-сервер с некоторым оборудованием (например, принтером, сканером штрих-кода, считывателем магнитных полос, сканером RFID, камерой, оборудованием для оплаты картой, наличными платежами в торговом стиле. компоненты и т. д.), и подавляющее большинство этих компонентов исторически поставлялись с Win32 SDK, а не с UWP.

По этим двум причинам большинство наших исторических приложений являются приложениями WinForms, а большинство наших современных приложений - приложениями WPF. Мы создали несколько приложений UWP (в основном для того, чтобы извлечь выгоду из действительно хороших возможностей режима ограниченного доступа / режима киоска Windows), но над ними обычно сложно работать по сравнению с WPF, и мы, как правило, не можем получить совместимые аппаратные SDK в любом случае. .

Тем не менее, нас очень заинтриговали острова XAML, которые позволяют нам писать Win32-совместимые приложения с современным пользовательским интерфейсом (хотя преимущество UWP над WPF для нас не всегда очевидно, особенно если мы не используем стандартные элементы управления или специфичные для Microsoft. такие эффекты, как Fluent и т. д.).

Чтобы ответить на ваши конкретные вопросы:

Какие шаблоны вас заинтересуют больше всего?

C # с .NET Core, Win32 с наложенным WinUI 3.0 было бы неплохо.

Вы знали о Xaml Islands для модернизации настольных приложений?

Да, и я был относительно доволен ими, когда играл с ними, хотя мы вряд ли будем использовать _single_ элемент управления, как принятие решения для всего пользовательского интерфейса.

Основная причина, по которой я знал об этом, заключалась в том, что мы получили поддержку Lottie для приложений Win32.

Делает ли эта расширенная обратная совместимость в Windows 10 Xaml Islands более полезными для вас?

Не совсем; мы почти всегда контролируем целевые ПК и можем гарантировать, что всегда получаем последнюю совместимую версию.

Помогло бы, если бы Visual Studio или другой инструмент автоматически обновляли пространства имен для вас?

да.

Насколько важна для вас полная совместимость между существующими компонентами UWP Xaml и приложениями WinUI 3.0?

Очень минимально. Основная проблема совместимости, которая у нас возникнет, - это изменение ключей StaticResource для стилизации основных элементов.

Вы создаете или используете библиотеки элементов управления UWP Xaml или компоненты WinRT, которые невозможно легко перекомпилировать и обновить вместе с кодом приложения?

Да, в прошлом мы использовали библиотеку элементов управления Syncfusion UWP .

Какое решение вы бы предпочли для использования компонентов UWP Xaml с WinUI 3?

Предпочтительным решением было бы иметь больше стандартных элементов управления, доступных в самом WinUI, а не полагаться на внешние источники (например, средства просмотра документов), но я ожидаю, что эти библиотеки внешних компонентов, как правило, будут более прогрессивными в обновлении своих библиотек, чем мы были бы при переключении на Во всяком случае, WinUI 3 по большей части.

Что вы думаете об общем плане 3.0, описанном выше и в дорожной карте? Позволит ли это вам использовать WinUI для ваших новых и существующих приложений Windows?

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

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

Для каких приложений вам больше всего хотелось бы использовать WinUI 3.0? Создаете новое приложение Win32 и упаковываете его с помощью MSIX? Добавление новых представлений в приложение WPF? Модернизируете приложение C ++ MFC с помощью Fluent UI?

В основном о получении доступа к более активно поддерживаемым библиотекам элементов управления в моих старых приложениях с более красивой и очевидной документацией (или даже с доступом к базовому коду для стандартного элемента управления), что значительно упрощает определение того, когда я могу адаптировать стандартный элемент управления. и когда мне нужно свернуть собственный пользовательский элемент управления. Например, в недавнем приложении, построенном на WPF, у меня было несколько средств выбора даты; заставить этот элемент управления работать нормально при касании, а также настроить размер, шрифт, всплывающий значок и т. д. было чрезвычайно раздражающим. Я был бы склонен использовать WinUI для такого рода приложений по _default_ в будущем, учитывая дорожную карту выше, потому что:

1. Я могу быть разумно уверен, что есть собственный элемент управления выбора даты, который, по крайней мере, умеренно удобен для сенсорного ввода.
2. Я могу легко изучить собственные / готовые шаблоны этого элемента управления и т. чтобы выяснить самый чистый способ стилизовать тип - размер шрифта, вес, семейство - заголовка элемента управления TextBox независимо от его входного текста; использует ли стандартный HeaderTemplate волшебные статические ресурсы, которые я могу переопределить, или мне нужно переопределить сам шаблон? Если я переопределю шаблон, как будет выглядеть разметка шаблона по умолчанию; поддерживает ли он что-то, что я не рассматривал?).

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

Текстовое окно:
Если пользователю необходимо отредактировать TextBox, он сначала должен щелкнуть в TextBox, чтобы отобразить кнопку очистки, а затем нажать кнопку очистки, чтобы очистить TextBox. Это очень неэффективно при работе с большими объемами данных. Было бы хорошо, если бы когда пользователь щелкал мышью или вкладывался в TextBox, текст мог быть выделен готовым к написанию.

Gridview / ListView:
Gridview и ListView, похоже, не позволяют пользователю эффективно использовать Tab через коллекцию.
ListView позволяет Tab перемещаться к элементам управления в той же строке, но не выполняет Tab к следующей строке элементов управления. Вместо этого ListView теряет фокус, а Tab переходит к следующему элементу управления в визуальном дереве.

Это две проблемы, которые наши пользователи считают очень раздражающими.

@Elmarcotoro

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

Эта проблема существовала в первую очередь для получения отзывов о 2 «общих вопросах» в верхней части сообщения.

Поддержите модель хостинга Blazor, встроенную в WinUI. Это позволит использовать элемент управления Blazor непосредственно в сети клиент / сервер или использовать непосредственно в WinUI. В дорожной карте Blazor есть эта концепция будущего без использования элемента управления WebView. Таким образом, пользовательский интерфейс элемента управления работает в собственном коде, а часть кода .Net Standard также работает в собственном коде.

Поддержка модели хостинга Blazor, встроенной в WinUI.

Обсуждается на стороне Blazor, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

Конечно, это наш план.

@jevansaks Было бы здорово

Мне бы хотелось лучшей согласованности меню в трее / меню значков с WinUI 3.0. Каждое приложение имеет разный интервал, а приложения Win32 не следуют последовательно рендерингу / интервалам / темам шрифтов. Пожалуйста, исправьте это уже!

WinUi на рабочем столе для меня совершенно бесполезен из-за отсутствия какой-либо возможности управления окнами: показывать / скрывать окна, положение окон, размер окон, закреплять / откреплять ...

@alexandrevk это пока превью. Вы видели дизайн оконного API? https://github.com/microsoft/ProjectReunion/issues/157

Спасибо @dotMorten за

@alexandrevk - мы собираем API для Reunion, которые позволят вам выполнять этот тип оконных операций как из Win32, так и из UWP с содержимым WinUI, а также при использовании других фреймворков / содержимого цепочки обмена в вашем окне. Некоторые из этих оконных функций могут быть затем абстрагированы в оконный класс WinUI для более легкого доступа, но это будет дальше. Технические характеристики оконной области находятся в трубе, следите за обновлениями.

Говоря строго как обычный пользователь (т.е. не корпоративный / компания) и только на C ++, даже если я всего лишь одинокий голос, кричащий в пустоту, я чувствую необходимость сказать, что до тех пор, пока любая из этих новых систем пользовательского интерфейса связаны с UWP и той ужасной системой упаковки, в которую они встроены, поэтому, боюсь, что бы вы ни делали, это всегда будет в неведении. (Исходя из опыта WinRT, я еще не пробовал WinUI, но мне он кажется почти таким же).
Наверняка нужно знать, что на самом деле приложениями UWP практически никто не пользуется? (на самом деле ненавидимый большинством afaik), поэтому, если он будет называться «родным», то почему он не действительно «родной», то есть: несколько #includes, свяжите .lib или два и создайте свое приложение на СТАНДАРТНОМ c ++.
Приходиться прибегать к таким вещам, как Qt, когда кроссплатформенность не вызывает беспокойства, просто чтобы избежать оборачивания win32 в тысячный раз, честно говоря, уже стареет.
Во всяком случае, только мои 2 цента от человека, который использует этот язык каждый день, но, вероятно, здесь некуда комментировать.

@ nl-n, вы должны быть счастливы узнать, что одним из главных преимуществ WinUI является то, что его не нужно запускать как приложение UWP. Фактически, это стало возможным со времен предварительного просмотра 2.
_Currently_ это требует упаковки как msix, но msix на самом деле является довольно приличным способом распространения (и обновления) ваших приложений.

@dotMorten Это одна из больших проблем: требуется загрузка / установка из магазина. Я не знаю ни одного человека, который бы не отключал / отключал магазин до (или сразу после) установки окон, так как же мы должны их распространять ?.
Я знаю, что это несколько риторически, но это соответствует сути. Я просто смогу заархивировать каталог сборки и распространить его (или установщик, если это необходимо).
Тогда есть проблема совместимости, очень многие люди до сих пор отказываются даже устанавливать W10, так что это тоже ...
Однако приятно слышать, что идет направление 3.0, хотя я ненавижу xaml, но это было бы долгожданным дополнением.
Может быть, мы могли бы получить это без необходимости устанавливать всю рабочую нагрузку UWP на 50 ГБ в VS? 🙏 (преувеличивая, я знаю, но все же)

Процитирую @MarkIngramUK в начале этой

Сейчас 2019 год, мне нужен быстрый, собственный интерфейс, и я не хочу серьезно рассматривать создание пользовательского интерфейса с CreateWindowExW , GDI и т. Д.

что (как ни странно) я буквально должен делать прямо сейчас, и да, это так же болезненно, как кажется :)

@ nl-n кто что сказал про магазин? MSIX на самом деле не отличается от установки MSI. Это просто установщик приложений. Дважды щелкните по нему, чтобы установить. Магазин не нужен. Гарантирует 100% чистую деинсталляцию (в отличие от MSI, которая создает гигантский беспорядок)

Я не знаю ни одного человека, который бы не отключил / не отключил магазин

Однако это не обычное явление.

как мы должны их распространять

В первую очередь нужно проинформировать пользователей, чтобы они не отключили магазин)

Я просто смогу заархивировать каталог сборки и распространить его

MSIX можно установить без магазина. В последних версиях Windows пользователю не нужно ничего включать для этого. Конечно, если пакет ранее был подписан доверенным сертификатом. Но да, если пользователь удалил хранилище с ПК, он также мог удалить с него MSIX / APPX AppInstaller. В этом случае им, вероятно, не нужна вся вариативность приложений.

очень многие люди до сих пор отказываются даже устанавливать W10,

Это их выбор. Достаточно.

вся рабочая нагрузка 50 ГБ UWP в VS тоже

Единый SDK составляет около 3 ГБ. Скачивать каждую, начиная с 10240, не требуется.

@ nl-n кто что сказал про магазин? MSIX на самом деле не отличается от установки MSI. Это просто установщик приложений. Дважды щелкните по нему, чтобы установить. Магазин не нужен. Гарантирует 100% чистую деинсталляцию (в отличие от MSI, которая создает гигантский беспорядок)

Это было из описания, которое Visual Studio дает вам: «для загрузки / установки через магазин microsoft», единственная другая информация, которую я нашел на msix, - это msdn, в котором в основном говорится: пакеты msix - это изолированные / виртуализированные приложения appx , что в значительной степени убийственно для всего, что работает напрямую с winapi. И они требуют подписи, чтобы их можно было установить? ...

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

Однако это не обычное явление.

Чаще, чем вы думаете, и не без оснований 😄

В любом случае, я не собирался сорвать рельсы, поэтому я вернусь к написанию моих материалов CreateWindowExW