Можно ли говорить о поддержке типов данных, допускающих значение NULL, в элементах управления и значениях по умолчанию? В качестве примера есть DatePicker который возвращает DateTimeOffset, и CalendarDatePicker который возвращает DateTimeOffset ?.

• Почему один из них может иметь значение NULL, а другой - нет? Это потому, что DatePicker был разработан с использованием более ранних API во временном интервале Windows 8?
• Следует ли нам рассмотреть возможность добавления свойства конфигурации, чтобы разрешить / запретить использование null в элементах управления?
• Следует ли рассматривать свойство DefaultValue для новых элементов управления, таких как NumberBox, следует ли оставить NaN по умолчанию или следует переключиться на обнуляемое значение double с нулевым значением по умолчанию?
• Существуют ли ограничения XAML WinRT / OS на возврат и поддержку обнуляемых значений, которые не позволили бы сделать свойство NumberBox Value обнуляемым? Если да, то как был реализован CalendarDatePicker?
• Это напрямую связано с обсуждениями NumberBox в № 1721 и № 1708.

Кроме того, каков план устранения открытых проблем в NumberBox, не зависящих от WinUI 3.0? Было бы здорово начать использовать этот элемент управления в WinUI 2.4 вместо того, чтобы ждать дольше. На мой взгляд, он еще не полностью готов, и мне неудобно втягивать его в производственные приложения.

Еще одна интересная идея для обсуждения, о которой я задумался: какова будет политика Microsoft в отношении внесения изменений теперь, когда WinUI 3.0 станет открытым исходным кодом?

В прошлом Microsoft практически никогда не вносила критических изменений. Как правило, это хорошо, пока через несколько (или 10) лет не накопится весь беспорядок. Это также не стандарт для проектов с открытым исходным кодом. Например, в конечном итоге ListBox должен быть прекращен для ListView, а MessageDialog - для ContentDialog и т. Д. Я уверен, что в API есть много более приятных небольших улучшений.

Я знаю, что компании ненавидят перемены - не зря. Также ДОЛЖНА быть относительно простая (функционально эквивалентная) замена, позволяющая упростить перенос на новые API. Это необходимо будет оценивать в каждом конкретном случае и выносить суждение.

Мне интересно, можем ли мы установить основные выпуски (например, WinUI 4.0) как разрешающие критические изменения. Это позволит проекту продолжать расти, не пытаясь мириться со всеми прошлыми ошибками. По сути, Microsoft уже решила сделать это с .NET 5, основав его на .NET Core и отказавшись от того, что было полной .NET Framework.

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

Основываясь на прогрессе, достигнутом с момента последнего вызова, когда команда реально думает, что WinUI 3 будет готов к выпуску:

• Сборка 2020 (апрель-май)
• Ignite 2020 (октябрь-ноябрь)
• ~ 2021 г.

Кроме того, насколько зависит ваша работа от команды .NET, создающей новое решение AOT и .NET 5?

Наконец, есть ли давление со стороны Windows, чтобы она была готова к выпуску Windows10X и / или до этого разработчикам нужно было создавать специализированные приложения?

Будет ли / должен ли быть инструмент для простого преобразования проектов WinUI 2.X в WinUI 3.0 (поскольку выполнение этого вручную может потребовать много работы для больших проектов)?

Слон в комнате - WinRT (# 1856)

Слон в комнате - WinRT (# 1856)

Скоро появится модель приложения без песочницы, которая будет работать так же, как WPF (включая API Win32), но с доступом к современным API WinRT, а также пользовательским интерфейсом и элементами управления с открытым исходным кодом с новым XAML, работающим на Direct X 12.

Скоро появится модель приложения без песочницы, которая будет работать так же, как WPF (включая API Win32), но с доступом к современным API WinRT, а также пользовательским интерфейсом и элементами управления с открытым исходным кодом с новым XAML, работающим на Direct X 12.

Вот это да. Ух ты ух ты!!!!

Это невероятно! Есть ли у нас для этого расчетное время прибытия, будет ли это обсуждаться во время телеконференции?

Это безумно круто!

Скоро появится модель приложения без песочницы, которая будет работать так же, как WPF (включая API Win32), но с доступом к современным API WinRT, а также пользовательским интерфейсом и элементами управления с открытым исходным кодом с новым XAML, работающим на Direct X 12.

Вот это да. Ух ты ух ты!!!!

Это невероятно! Есть ли у нас для этого расчетное время прибытия, будет ли это обсуждаться во время телеконференции?

Это безумно круто!

Это было первое, что мы узнали о WinUI. Расчетное время прибытия в этом году, я подозреваю, что точная дата будет указана в // Build /, но не стесняйтесь спрашивать во время звонка.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo См. дорожную карту WinUI . Также см. Https://github.com/microsoft/microsoft-ui-xaml/issues/1045 для получения дополнительной информации (например, о шаблонах проектов VS).

@mdtauk @ Felix-Dev Я перечитаю эти документы. Я помню, как спрашивал об этом раньше - пока я могу легко использовать win2d из моего (не изолированного) приложения, я буду более чем счастлив!

@jesbis Извините за вопрос

Мы настраиваем информацию для завтрашнего звонка сегодня позже - я отправлю маршрут через несколько часов.

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

У меня просто возникла интересная мысль (по крайней мере, для меня).

Взглянув на сегодняшнюю прямую трансляцию ASP.NET Community Standup, я увидел, что по существу 4 разработчика MS выполняли поток livecoding, хотя это была скорее техническая демонстрация. Я также иногда настраиваюсь на @csharpfritz на Twitch, который полностью сеансах программирования в реальном времени.

Я подумал: после того, как WinUI 3 будет выпущен и кодовая база (или большая ее часть) станет полностью открытой, будут ли члены команды время от времени транслировать вживую часть своей работы над WinUI?

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

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

Вот ссылка на прямую трансляцию на YouTube на завтра!

https://youtu.be/MXTVqgB4rW0

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

Есть ли что-нибудь в руководстве о производительности / fps пользовательского интерфейса? Одна из самых больших проблем, с которыми я сталкиваюсь с современной Windows 10, заключается в том, что на такой машине, как Surface Book, вы получаете ужасную производительность на дисплеях с высоким разрешением, которая становится еще хуже, когда вы комбинируете прозрачность и дополнительные мониторы. Это может быть вне досягаемости возможного, но есть ли здесь какие-либо соображения о том, насколько плавно и хорошо он работает, особенно в этих условиях?

Пожалуйста, подумайте о повышении приоритета прозрачных окон без полей (например, https://github.com/microsoft/microsoft-ui-xaml/issues/1247). Это блокировщик внедрения WinUI для таких приложений, как наше .

Копия: @crutkas

Пожалуйста, подумайте о повышении приоритета прозрачных окон без полей (а-ля # 1247). Это блокировщик внедрения WinUI для таких приложений, как наше .

Копия: @crutkas

Для этого, вероятно, потребуется добавить элемент окна верхнего уровня в WinUI Xaml со свойствами, аналогичными WPF. # 1323

Было бы неплохо узнать больше о «будущем оконного управления» для WinUI - есть много связанных запросов, которые было бы неплохо хотя бы обсудить / адресовать.

Наверное, спрашивали раньше.

Для меня это всегда было вопросом повторного использования кода.
Это приводит к двум вопросам:

1. Будет ли у кого-нибудь в ближайшее время поддержка .NET Core 3 и C # 8.0?
2. Увидим ли мы дальнейшие шаги команды UWP / WinUI, чтобы упростить разработку приложений Uno Platform?

Еще один, когда мы увидим недостающие биты из WPF, поддерживаемые в UWP?

Наверное, спрашивали раньше.

Для меня это всегда было вопросом повторного использования кода.
Это приводит к двум вопросам:

1. Будет ли у кого-нибудь в ближайшее время поддержка .NET Core 3 и C # 8.0?
2. Увидим ли мы дальнейшие шаги команды UWP / WinUI, чтобы упростить разработку приложений Uno Platform?

Еще один, когда мы увидим недостающие биты из WPF, поддерживаемые в UWP?

Код .NET Core должен работать на обоих, поэтому приложению WPF потребуется только изменить UI Xaml и код UI.

Приложения UWP должны нормально работать с изменением пространства имен для WinUI 3.0 - для выхода из песочницы может потребоваться дополнительная работа, подробности пока неизвестны.

Отсутствующие биты WPF не были подтверждены, но я задал вопрос по этому поводу. # 719

@weitzhandler

Хотя он официально не поддерживается и не все функции C # 8 будут работать, вы уже можете использовать большую часть C # 8 с WinUI / UWP. Смотрите здесь .

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

Просто уточняю, что kmgallahan сказал об использовании C # 8. Я использовал многие из новых функций, но мне очень нужны были члены интерфейса по умолчанию, которые еще не реализованы.

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

@jesbis

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

Спасибо, постараемся ответить на все вопросы!

Есть ли что-нибудь в руководстве о производительности / fps пользовательского интерфейса?

@ryvanvel у нас есть некоторые рекомендации по производительности:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

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

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

Насколько я помню, эта ошибка была связана с Windows 10, надеюсь, ее исправят раньше: https://github.com/microsoft/microsoft-ui-xaml/issues/597

К сожалению, я не смогу вовремя настроиться, будет ли запись?

Изменить: запись звонка можно найти здесь: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis здесь :

Вот ссылка на прямую трансляцию на YouTube на завтра!
https://youtu.be/MXTVqgB4rW0

Переход по ссылке YT, похоже, начнется только в конце этого часа, на час позже обычного времени, это правда?

@weitzhandler Время начала указано вверху сообщения. Это тоже только 3-й звонок, так что «обычный» - это с натяжкой.

@weitzhandler Я почти уверен, что до сих пор все три звонка были запланированы на 9 утра по тихоокеанскому времени.

Спасибо вам двоим и извините за беспокойство. До скорого.

Мне было любопытно узнать, будет ли WebView2 базе Chromium также отображать событие типа WebResourceRequested из текущего WebView , чтобы разработчики могли фильтровать отдельные веб-запросы. Я очень полагаюсь на эту особенность в одном из своих приложений, и мне было интересно, будет ли она по-прежнему присутствовать в новом элементе управления и работать таким же образом.

Спасибо, ребята, за всю тяжелую работу! 😄🚀

Будет ли какой-нибудь инструмент для создания PDF-файлов? Win2D уже имеет множество замечательных инструментов, возможность создавать PDF из CanvasRenderTarget будет отличным дополнением.

не понял - как установить vsix? где скачать?

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

Я предполагаю, что все участники этой телеконференции - разработчики, и нам нужно знать и обсуждать детали. Менеджеры по работе с клиентами сосредоточены на очень простых темах и не могут вдаваться в подробности. Например, обсуждение документации / WebView / ProgressRing в начале телеконференции имеет приятную концепцию, но настолько простую, что, я думаю, для нас это бесполезно. Мы используем XAML годами / десятилетиями, и вы обращаетесь к экспертной аудитории (важно адаптировать презентации к аудитории).

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

1. Особенности - в этом случае то, что вы сказали, в основном верно
2. Ошибки / проблемы - в этом случае нет, вам не нужно, чтобы сообщество приводило вам примеры, чтобы помочь расставить приоритеты. При доставке любого продукта качество - ваш приоритет номер 1. Мы сообщаем вам об ошибках, а вы говорите: да, это хорошо. Докажите, что вам нужно это починить. Это ошибка. Может быть, вы никогда не отправляли приложения потребителям? Любые неправильные мелочи ВООБЩЕ влияют на ваш имидж и восприятие, которое является наиболее ценной частью компании. Индустрия приложений очень конкурентоспособна.

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

Во время разговора я дважды говорил об окнах, и было упомянуто, что:

• это фактически работает для WinUI 3 (несмотря на то, что проблема заморожена https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• проект отслеживания функций (обновленный вчера) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) отслеживает только материал WinUI 2 ???

Можем ли мы получить здесь некоторую ясность? Есть ли еще одно место, где можно увидеть отставание WinUI 3? Для целей планирования очень важно знать, что будет, а что нет. Спасибо!

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

Огромное спасибо всем, кто смог настроиться!

И еще раз извините за проблемы со звуком и командами - мы думаем, что выявили проблему с оборудованием, и надеемся, что в следующем месяце все будет рассортировано.

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

Мы просматриваем вопросы и постараемся найти все, что мы пропустили в этой теме.

Некоторые вопросы наверстывают упущенное:

Будет ли какой-нибудь инструмент для создания PDF-файлов?

@MuziburRahman

У нас не будет времени, чтобы добраться до этого для WinUI 3.0 RTM, но мы отслеживаем это в бэклоге с # 672 - не стесняйтесь добавлять комментарий к этой проблеме о том, как вы будете ее использовать!

как установить vsix? где скачать?

@hannespreishuber

Инструкции по использованию WinUI 2.x для производственных приложений находятся здесь: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

Инструкции по установке и опробованию vsix WinUI 3.0 Alpha находятся здесь:
https://aka.ms/winui/alpha

Может, это только я, но сегодняшний звонок меня разочаровал. Пожалуйста, включите больше технических специалистов. PM должен держать дискуссию сфокусированной [...] Мы используем XAML в течение многих лет / десятилетий, и вы говорите с экспертной аудиторией (важно адаптировать презентации к аудитории).

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

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

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

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

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

Во время разговора я дважды говорил об окнах, и было упомянуто, что:
это фактически работает для WinUI 3 (несмотря на то, что проблема была заморожена # 1247)
проект отслеживания функций (обновленный вчера) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) отслеживает только материал WinUI 2 ???
Можем ли мы получить здесь некоторую ясность? Есть ли еще одно место, где можно увидеть отставание WinUI 3? Для целей планирования очень важно знать, что будет, а что нет. Спасибо!

@riverar эта плата проекта в настоящее время предназначена для WinUI 2, поскольку в настоящее время это единственный код в репозитории.

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

Мы продолжим публиковать предложения функций для основных элементов, таких как спецификация Chromium WebView, в отдельном репозитории спецификаций:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

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

Тем не менее, я могу сказать, что большинство предложений по помеченным функциям не будут учтены в первоначальной версии 3.0 - наши основные направления:

• получение WinUI, отделенного от ОС и поставляемого отдельно
• открытый исходный код Xaml framework
• создание хорошего опыта разработки настольных приложений WinUI (использование Win32, упаковка, управление окнами и т. д.)
• включение Windows 10X
• включение приложений .NET Core / 5 + WinUI

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

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

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

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

Тем не менее, я могу сказать, что большинство предложений по помеченным функциям не будут учтены в первоначальной версии 3.0 - наши основные направления:

• получение WinUI, отделенного от ОС и поставляемого отдельно
• открытый исходный код Xaml framework

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

• создание хорошего опыта разработки настольных приложений WinUI (использование Win32, упаковка, управление окнами и т. д.)
• включение Windows 10X

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

• включение приложений .NET Core / 5 + WinUI

Текущая поддержка Native осуществляется в виде кода C ++ и API Win32, но означает ли это, что разработчикам на C # нужно ориентироваться на .NET? Будет ли модель приложения без песочницы допускать кодирование на C # без .NET?

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

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

Без CoreWindow (который будет UWP только в будущем) - Windowing - одна из тех вещей, которые должны быть на месте с первого дня. WPF имеет объект Window в XAML, который обрабатывает элементы управления, визуальное оформление, прозрачность и т. Д. Он обрабатывает изменение размера, минимизацию и т. Д. Старые фреймворки Win32 требуют ручной раскраски поверхностей, которые не подходят для пользовательских интерфейсов XAML - так как же восполнить этот пробел? ?

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

Можно ли публично перечислить эти внутренние рабочие элементы, даже если они отображаются как пустые записи с некоторым общим именем, например «Внутренняя проблема»?

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

Для начала у нас есть веха WinUI 3.0 для высокоуровневого отслеживания, и по мере того, как мы переносим код WinUI 3 Xaml в открытый исходный код, мы также откроем больше проблем «функционального уровня» на этом этапе.

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

Итак, мы начнем с проблем на уровне функций (например, уже начавшихся - например, WebView) и со временем полностью перенесем наши процессы на GitHub.

Текущая поддержка Native осуществляется в виде кода C ++ и API Win32, но означает ли это, что разработчикам на C # нужно ориентироваться на .NET? Будет ли модель приложения без песочницы допускать кодирование на C # без .NET

Вы спрашиваете о .NET Native или вообще без .NET? Технически я думаю, что спецификация C # как язык не зависит от .NET, но в настоящее время у нас нет планов по переносу на C ++ или что-то в этом роде.

Без CoreWindow (который будет UWP только в будущем) - Windowing - одна из тех вещей, которые должны быть на месте с первого дня. WPF имеет объект Window в XAML, который обрабатывает элементы управления, визуальное оформление, прозрачность и т. Д. Он обрабатывает изменение размера, минимизацию и т. Д. Старые фреймворки Win32 требуют ручной раскраски поверхностей, которые не подходят для пользовательских интерфейсов XAML - так как же восполнить этот пробел? ?

@ marb2000 работает над этим и сможет поделиться дополнительной информацией, если она станет доступной.

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

Чтобы быть ясным, WinUI 3 не будет переносить весь рабочий стол win32 на другие платформы, такие как HoloLens: универсальные приложения и API-интерфейсы по-прежнему будут использоваться при нацеливании на несколько устройств.

Размещено слишком рано. Полный комментарий:

@robloo - Я хочу начать с того, что во многом согласен с вашим мнением, и я ценю то, что вы

Устав и ресурсы

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

1. Развитие WinUI 2
2. Доставка WinUI 3
3. Открытый исходный код WinUI 3

Как вы знаете, мы твердо настроены на 2 и 3, потому что A) это взаимосвязанные цели и B) WinUI с открытым исходным кодом означает, что каждый может перестать быть заблокированным ограниченными ресурсами нашей команды, потому что WinUI, наконец, получит полномочия принимать запросы сообщества.

Если мы набраны слишком вперед цели 2 и 3 к точке , где WinUI 2 находится под выступающими членами сообщества, мы можем иметь этот разговор , и мы открыты для изменения приоритетов. Просто знайте, что устранение всех ошибок в нашем журнале отложит выпуск WinUI 3 на рынок примерно на 6 месяцев. Если вместо этого мы отдадим приоритет 2 и 3, что не только для WinUI с открытым исходным кодом, но и расширит его актуальность для нашей огромной базы разработчиков Win32, мы сможем очистить наш накопившийся список ошибок _и_ запросы функций с помощью сообщества открытого исходного кода и нашей команды. безраздельное внимание, поддерживающее нас. С этой целью наше текущее обоснование состоит в том, что план подхода не только продвинет эту платформу вперед быстрее, но и более комплексно. Когда я попросил вас помочь нам определить приоритеты ошибок, вопрос был не в том, «достаточно ли они важны для нашей команды, чтобы их исправить?» но вместо этого "это важно, чем раньше открывать исходный код WinUI?" При статус-кво у нас есть подмножество разработчиков, работающих над повышением приоритета 1, и вы можете оценить их влияние в нашей истории коммитов и активных проблемах, но они все равно сталкиваются с необходимостью расставить приоритеты в рамках этой цели. Это понятие «скажите нам, насколько это важно для вас» действительно помогает нам отфильтровать потребности (например, мой продукт заблокирован, и я не могу дождаться WinUI 3) по сравнению с тонкостями (например, я заметил эту техническую ошибку, но нет существующей разработки заблокирован на нем, поэтому он может ждать WinUI 3).

Еще я хочу четко сказать, что вся работа по регистрации ошибок WinUI 2, заполнению запросов функций и т. Д. _ Не _ будет потеряна для нас. Когда выйдет WinUI 3, у нас будет значительная часть нашей команды, которая сможет вернуться к рабочим элементам, которые продвигают платформу, помимо предоставления сообществу возможности отправлять код. Это означает, что прямо сейчас мы заполняем бэклог, который всеми силами нашей команды будет решен с помощью нашего существующего сообщества UWP, а вскоре и Win32.

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

NumberBox

Функции

Вернемся к NumberBox. Фактически вы правы, говоря, что V1 - это подмножество желаемых функций.
Запланированные функции V1 были отложены до V2 из-за зависимостей от таких вещей, как проверка ввода (которая, кстати, находится в предварительной версии в WinUI 3 alpha). Мы постарались быть полными в нашей спецификации, признав все, что, по нашему мнению, заслуживает того, чтобы быть V1 в спецификации (здесь), и планируем полностью выполнить это обязательство с выпуском WinUI 3 V2 элемента управления.

Принимая дух открытого исходного кода, мое желание (и, пожалуйста, скажите, если я ошибаюсь, сделав это), состоит в том, чтобы полностью предпочесть выпуск надежного и полезного кода как можно быстрее и создавать наборы функций постепенно. В приложении это означало, что мы предпочли выпустить наш _почти_ полный_ V1 в WinUI 2, а затем выпустить полнофункциональный выпуск с проверкой ввода, как мы можем с WinUI 3.

Ошибки

Как сказал @jesbis , ни одна база кода не свободна от ошибок, но качество для нас абсолютно @jesbis отметил, что вы можете увидеть соотношение исправлений качества и новых функций в журнале фиксации для WinUI 2, и как только он станет открытым исходным кодом, вы сможете увидеть то же самое для WinUI 3.

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

Следующие шаги

Для нас открытый исходный код - это обещание принять сообщество как членов команды, как если бы они сидели здесь, в нашем офисе в Редмонде. Мы слышим, слушаем. Давайте вместе поговорим об этих решениях, чтобы мы могли сосредоточиться на создании отличных вещей как одна большая команда. 🙂

Мы ❤️ WinUI

Принимая дух открытого исходного кода, мое желание (и, пожалуйста, скажите, если я ошибаюсь, сделав это), состоит в том, чтобы полностью предпочесть выпуск надежного и полезного кода как можно быстрее и создавать наборы функций постепенно. В приложении это означало, что мы предпочли выпустить нашу в основном полную версию V1 в WinUI 2, а затем выпустить полнофункциональную версию с проверкой ввода, как мы можем с WinUI 3.

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

@yaichenbaum Я мог бы лучше

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

Причина, по которой мы делаем промежуточную ветку предварительного просмотра с партнерами по проверке, заключается в том, чтобы отловить ошибки вроде # 1846 до того, как элементы управления будут переведены в стабильную версию. Извините, мы упали на этом, я буду работать с @teaP как можно скорее, чтобы посмотреть, как быстро мы сможем решить эту проблему! 🙂

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

Может ли кто-нибудь рассказать, как WinUI 3.0+ будет позиционировать возможности по сравнению с AppDomain для изоляции приложений и управления ресурсами?

Кроме того, последнее, что я знал о .Net Core, - полной поддержки AppDomain не было.

Может быть, я не в курсе, но вы говорите, что .Net 5 будет иметь полную поддержку AppDomain?

Спасибо за организацию сегодняшней телеконференции!

Может ли кто-нибудь рассказать, как WinUI 3.0+ будет позиционировать возможности по сравнению с AppDomain для изоляции приложений и управления ресурсами?

Извините, если во время разговора это было непонятно, но я говорил об AppContainer , а не о AppDomain.

Ах, хорошо, спасибо за разъяснения, Джесси.

Прежде всего, спасибо @SavoySchuler и @jesbis (и всей остальной команде WinUI) за организацию сегодняшнего звонка сообщества! Несмотря на некоторые технические трудности, этот звонок был очень информативным !!!

Как упоминал @jesbis, существует проблема с отслеживанием инструментов и функций, запрошенных для WinUI 3.0. Не лучше ли выделить запрос средства преобразования WinUI 2.x в 3.0 в отдельную задачу для упрощения отслеживания? Также уже есть какие-то планы? Есть ли планы сделать инструмент с открытым исходным кодом, чтобы другие разработчики могли помочь в его разработке?

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

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

Возможно, улучшения в этой области помогут людям внести свой вклад 😅

Как выполняется слой рендеринга WinUI 3.0? Использует ли он напрямую D3D11, D2D, уровень абстракции или что-то еще? Есть ли в нем уровень программного рендеринга или для этого используется D3D WARP?

@chingucoding

Я повторю то, что только что высказал здесь :

• Не использовать язык навсегда
• Понятия не имею, сколько оттока кода происходит в фоновом режиме для выпуска WinUI 3, который перезапишет изменения, сделанные сегодня.
• Нет доступа к исходному коду, который может понадобиться и / или существенно помочь в работе с проблемами.

Изменить: я приведу пример. # 1555 и # 1849 - это, по-видимому, серьезные проблемы с основным элементом управления (TextBox), которые препятствуют вводу и выделению текста во время многозадачности.

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

@SavoySchuler

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

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

NumberBox - это недавно разработанный элемент управления для WinUI 2.3, а не устаревший элемент управления, который все должны принять на данном этапе. Почему бы нам не сделать это правильно для начала? Это в значительной степени лакмусовая бумажка новой модели развития.

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

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

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

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

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

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

Я прошу вас исправить ошибки в V1 элемента управления, которые не зависят от WinUI 3.0. Некоторые из них довольно просты, а другие представляют собой вопиющие ошибки в дизайне (например, NaN приводит к сбою данных с двусторонней привязкой). После того, как вы обязуетесь выпустить функцию / элемент управления, вы должны быстро закрыть ошибки. Ошибки возникают ВСЕГДА, когда программное обеспечение выходит в первый выпуск, вам просто нужно спланировать ресурсы, чтобы быстро исправить ошибку V2 (как и все остальные разработчики приложений). Поскольку мы согласны с тем, что качество является главным приоритетом, пожалуйста, исправьте следующие проблемы с NumberBox, прежде чем переходить к другим вещам.

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

1721 - Большой проблемой UWP была неполная поддержка привязки данных в определенных элементах управления. Многие разработчики приложений много лет назад инвестировали в разработку MVVM, а затем, пытаясь перейти к элементам управления UWP, обнаружили, что привязка данных поддерживается только частично. Это огромная проблема, и это неприемлемо, учитывая, насколько MVVM фундаментален для лучших практик Microsoft. Старая команда разработчиков инструментов для Windows никогда не поддержала бы это - здесь Windows / нативное мышление.

1839 год - Здесь главное. Это всего лишь базовые ошибки в шаблоне управления, которые ДОЛЖНЫ быть исправлены. Никаких оправданий.

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

1852, № 1853, № 1854 - Опять же, они не слишком сложны и просто отсутствовали в первой реализации. Тем не менее, это требование закона для обеспечения доступности программного обеспечения, продаваемого в определенных регионах или разработанного для правительства. Как платформа, вы должны исправить это немедленно, чтобы разработчики приложений могли использовать элемент управления. Опять же, мне не следует спорить с вами об этом, это базовые вещи.

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

Поймите на высоком уровне. Однако исправление вышеуказанных проблем не приведет к задержке WinUI 3.0 на 6 месяцев. Они также не зависят от адресации WinUI 3.0 (за исключением потенциально # 1721). Вы создаете опасный прецедент, выпуская NumberBox, а затем не придерживаясь его, чтобы закрыть первый раунд ошибок. Вы должны были усвоить этот урок уже с самой UWP.

Возможно, улучшения в этой области помогут людям внести свой вклад

Хотел бы внести свой вклад. Не люблю работать с C ++ / WinRT и, конечно же, не чувствую себя достаточно квалифицированным, чтобы трогать кодовую базу, как я ее видел. Если бы элементы управления управлялись C #, у вас было бы намного больше возможностей. Я понимаю, почему архитектура такая, какая она есть, но одним из последствий является меньший вклад сообщества. Мы здесь не системные разработчики, мы разработчики приложений для конечных пользователей.

RE: способствуя:

Другой более общий вопрос (который также будет задан другим членам команды, не участвующим в WinUI), касается участия. Существуют ли в настоящее время какие-либо препятствия, мешающие людям вносить свой вклад? Может ли помочь лучшее руководство для участников по началу работы?
На мой взгляд, если вы начнете вносить свой вклад в проект, проект VS может быть немного подавляющим, и не так много документации о том, как разрабатывать, какой тестовый проект следует использовать для чего и т. Д.
Возможно, улучшения в этой области помогут людям внести свой вклад

Ничто не должно мешать людям вносить свой вклад в WinUI 2, кодовую базу, которая сейчас находится в репозитории. Если есть проблема с WinUI 2, над которой вы хотите работать, дайте нам знать, и мы можем передать ее вам!

У нас есть много предметов, помеченных как хорошая первая проблема, и нужна помощь, если кто-то хочет помочь с предметами, с которыми (относительно) легко начать 🙂

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

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

Приведу пример. # 1555 и # 1849 - это, по-видимому, серьезные проблемы с основным элементом управления (TextBox), которые препятствуют вводу и выделению текста во время многозадачности.
Они занимают одно из первых мест в моем списке важных вопросов, которые необходимо решить, но я не знаю, с чего начать. Я также не знаю, доступен ли код, который я хочу / должен пройти для отладки.

Они все еще должны быть отсортированы (классифицированы) нашими владельцами разработчиков (отсюда и ярлык «необходимость-сортировка» - в настоящее время я выясняю, почему они еще не были, извините), но я ожидаю, что, поскольку TextBox отсутствует WinUI 2 тем придется подождать WinUI3.

После сортировки к ним должна быть применена метка needs-winui-3, указывающая, что им придется дождаться WinUI 3, прежде чем мы сможем их решить.

Когда WinUI 3 станет открытым исходным кодом, любой сможет помочь решить и эти проблемы.

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

Мы знаем, что C ++ представляет собой более высокий барьер, чем C #, но планируется, что WinUI останется платформой C ++.

Еще один замечательный проект, в который можно внести свой вклад, - это набор инструментов Windows Community Toolkit, в который легче внести свой вклад, поскольку он C # и имеет некоторые смягченные требования.

Мы работаем с сопровождающими и часто используем Community Toolkit для создания новых элементов управления, которые в конечном итоге переносятся на платформу Xaml (что требует повторной реализации на C ++).

Требуется ли WinUI C ++ / CX? Если это так, кажется, что это проблема Win32 и других будущих целей?

Как выполняется слой рендеринга WinUI 3.0? Использует ли он напрямую D3D11, D2D, уровень абстракции или что-то еще? Есть ли в нем уровень программного рендеринга или для этого используется D3D WARP?

Отрисовка фреймворка WinUI Xaml в основном реализована в механизме композиции Windows 10 . API-интерфейсы уровня композиции также будут частью WinUI 3.

В конце концов, это обычно означает рендеринг с аппаратным ускорением с использованием Direct3D, Direct2D и DirectWrite, с программным рендерингом в некоторых случаях, когда это имеет смысл.

Вы также можете включать собственное содержимое DirectX, отрисованное на заказ, с помощью интерфейсов API взаимодействия.

Требуется ли WinUI C ++ / CX? Если это так, кажется, что это проблема Win32 и других будущих целей?

Нет - платформа WinUI написана на C ++, но вашим приложениям точно не должно быть!

С WinUI 2 сегодня вы можете создавать приложения UWP, используя .NET (C #, VB.NET) или C ++.

С WinUI 3 наша цель состоит в том, чтобы вы могли создавать приложения, использующие UWP и / или Win32 API, используя будущую .NET 5 или C ++.

@jesbis Я думаю, вы немного неправильно поняли мои вопросы.

1) Я знаю, что WinUI написан на C ++, однако для какого-либо кода WinUI требуются только расширения VC ++ / CX для Windows? Если для этого требуются расширения CX, я считаю, что это может вызвать проблемы с переносимостью в будущем, если WinUI захочет расшириться на другие платформы. Например, это может затруднить принятие кода командой UNO.

2) О системе рендеринга. Пара вещей здесь.

2.a) Является ли «Визуальный уровень» API абстракции достаточно далеко от API DirectX, чтобы он мог позже поддерживать, например, серверную часть Vulkan? (Я уверен, что на этот вопрос ответят, когда выйдет исходный код, но мне просто интересно)

2.b) Мой вопрос о программной растеризации был больше похож на: Будет ли WinUI 3.0 поддерживать полный программный рендеринг (а не только рендеринг текста или что-то еще)? Иногда у программного обеспечения для совместного использования экрана возникают проблемы с приложениями с ускорением на GPU (по крайней мере, с D3D9 / WPF), и принудительный программный рендеринг устраняет проблему в этих ситуациях). Или если приложение запущено на виртуальной машине без аппаратного графического процессора.

Инструкции по установке и опробованию vsix WinUI 3.0 Alpha находятся здесь:
https://aka.ms/winui/alpha

сделал это с Edge New, появилась ссылка для скачивания doenst, повторила ее с хромом - скачать там

сделал это с Edge New, появилась ссылка для скачивания doenst, повторила ее с хромом - скачать там

@hannespreishuber ссылка для скачивания должна быть на последней странице опроса. Вы имеете в виду, что опрос не работал в Chromium Edge, но работал в Chrome?

ссылка для скачивания должна быть на последней странице опроса. Вы имеете в виду, что опрос не работал> в Chromium Edge, но работал в Chrome?

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

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

Хорошо, спасибо - мы протестировали опрос в обеих версиях Edge, и, похоже, он работал, поэтому, если у кого-то возникнут проблемы с загрузкой, сообщите нам об этом, а также сообщите о проблеме в Edge, если содержимое страницы отображается не так, как в Chrome (Настройки> Справка и Отзыв> Отправить отзыв) 🙂

Я знаю, что WinUI написан на C ++, однако для какого-либо кода WinUI требуются только расширения VC ++ / CX для Windows? Если для этого требуются расширения CX, я считаю, что это может вызвать проблемы с переносимостью.

@ zezba9000 мы реализовали элементы управления и функции WinUI 2 (новый код, который сейчас находится в репозитории), используя C ++ / WinRT, который является стандартным C ++ 17, но остальная часть WinUI 3 представляет собой гораздо большую и старую кодовую базу, которая в настоящее время все еще будет полагаться на на WRL и т. д. В настоящее время мы не фокусируемся на переносимости, но готовы обсудить ее в будущем.

Является ли «Визуальный уровень» API абстракции достаточно удаленным от API DirectX, чтобы впоследствии он мог поддерживать, например, серверную часть Vulkan? (Я уверен, что на этот вопрос ответят, когда выйдет исходный код, но мне просто интересно)

В настоящее время мы не фокусируемся на переносимости и визуального слоя. Между визуальным уровнем и API-интерфейсами DirectX есть некоторые слабые связи (не считая реализации), но в основном это абстрактно. Кроме того, чтобы прояснить ситуацию с открытым исходным кодом: наша первоначальная цель для кода с открытым исходным кодом и наших повседневных процессов разработки - это фреймворк Xaml, который в настоящее время не будет включать визуальный уровень с открытым исходным кодом.

Мой вопрос о программной растеризации был больше похож на следующий: будет ли WinUI 3.0 поддерживать полный программный рендеринг (а не только рендеринг текста или что-то еще)? Иногда у программного обеспечения для совместного использования экрана возникают проблемы с приложениями с ускорением на GPU (по крайней мере, с D3D9 / WPF), и принудительный программный рендеринг устраняет проблему в этих ситуациях). Или если приложение запущено на виртуальной машине без аппаратного графического процессора.

Да, рендеринг поверх экрана, в виртуальных машинах и т. Д. Должен работать. Для большей части контента не должно быть видимой разницы. Если вы просмотрите код WinUI 2 в репозитории, вы также можете увидеть использование API, который мы используем для запроса, поддерживаются ли определенные эффекты / "быстро" во время выполнения, и в некоторых случаях возвращаются к более простому рендерингу определенных эффектов, но приложениям этого не следует Не нужно делать ничего особенного для поддержки программного рендеринга при использовании элементов управления и функций платформы по умолчанию.

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

Согласен на 100% - я даже не хочу вспоминать, сколько часов я трачу на работу над ошибками из UWP / WinRT.

Джесси,

Меня в первую очередь беспокоит разработка корпоративных приложений. В настоящее время я использую WinUI 3.0 Alpha, чтобы создать доказательство концепции, чтобы продемонстрировать, как Xaml, GPRC, несколько окон и настоящая многопоточность могут предложить бизнесу и бизнес-пользователям более продуктивную работу с приложениями.

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

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

Были 3 основные причины, по которым веб-приложения были приняты на предприятии так быстро: кроссплатформенная поддержка, безопасность и простота развертывания. Чтобы быть жизнеспособной альтернативой, настольным приложениям нужны ответы на эти вопросы.

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

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

В корпоративных приложениях есть и другие аспекты, которые не особо обсуждаются - долговечность и набор навыков. Опять же, здесь есть что сказать, но я подведу итоги. Компании вкладывают деньги в создание приложений и планируют использовать эти приложения в течение «длительного» времени. Это означает, что базовая технология должна поддерживаться десятилетиями. Я хотел бы, чтобы WinUI стал следующей долгоживущей технологией на замену Win32 / MFC и WinForms.

ИТ-отделы постоянно борются с поиском технических специалистов с нужным набором навыков. Веб-технологии сделали это еще более сложной задачей. Я хотел бы увидеть новый стек C #, Xaml и SQL (C # XS), который определяет акцент на создании настольных приложений.

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

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

Если вам интересно, у меня есть другие идеи, но я остановлюсь на этом и резюмирую:

• Microsoft необходимо предоставить комплексное решение для разработки настольных приложений.
• WinUI / Fluent должен соответствовать требованиям бизнес-пользователя, таким как функция / форма, UX для рабочего стола, образцы кода / шаблоны проектов, демонстрирующие несколько окон, истинную многопоточность, проверку данных, страницы, похожие на формы.
• Microsoft необходимо четко дать понять, что они предлагают WinUI для создания высокопроизводительных и долговечных бизнес-приложений LOB. Кроме того, почему .Net 5 + WinUI НЕ будет еще одним адом для DLL.
• Дайте понять, что WinUI является заменой Win32 / MFC и WinForms.
• Продвигайте C # XS как набор навыков для ИТ-специалистов.
• (Бесплатно) Datagrid

Надеюсь, вы нашли это полезным.

@robloo Отдыхай спокойно - споры не нужны! 🙂 Я обязался исправить это упущение в своем раннем комментарии, и это все еще остается в силе. Думаю, я тоже раньше совершил ошибку, продолжив обобщать. Давайте поговорим о перечисленных вами ошибках. Два были поданы прямо перед нашими главными праздниками (я не могу говорить от имени @teaP , но большую часть декабря я был офлайн), и мы прошли через смену руководства на нашей инженерной стороне (поздравляю @ranjeshj!). Это не оправдание, и я прошу прощения за то, что эти две ошибки не были устранены быстрее во время этих изменений и отсутствий. Остальные, перечисленные здесь, были поданы в течение последних 10 дней или меньше.

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

@SavoySchuler Спасибо!

@SavoySchuler , похоже, вы застряли в сложной ситуации выбора между:

а) Исправьте ошибки в WinUI 2.x и отложите выпуск WinUI 3.0.
или
б) Оставьте WinUI 2.x сообществу и выделите внутренние ресурсы для WinUI 3.0 для достижения самой ранней даты выпуска.

Я предполагаю, что многие существующие пользователи WinUI 2.x захотят, чтобы вы сначала исправили ошибки, поскольку они в настоящее время затронуты, но, возможно, это можно смягчить, предложив реалистичное ожидание того, когда WinUI 3.0 _ может_ быть доступен, при наличии достаточных ресурсов ( и предполагая, что WinUI 3.0 предложит дополнительные исправления по сравнению с 2.x).

Лично я не хотел бы видеть задержки с выпуском WinUI 3.0 и считаю разумным, чтобы сообщество участвовало в решении любых проблем, которые являются критическими в WinUI 2.x (в конце концов, это открытый исходный код). Некоторые люди ожидают, что, поскольку это проект Microsoft, они должны сделать всю работу. К сожалению, это нереально, как и другие проекты с открытым исходным кодом.

@jesbis , интересно услышать о Visual Layer применительно к WinUI 3.0. Вы хотите сказать, что для начальных выпусков WinUI 3.0 будет зависеть от классов Windows.UI.Composition ? Есть ли возможность добавить в ОС дополнительные функции для поддержки визуального уровня перед извлечением в WinUI 3.0?

Для справки, то, что мне интересно:

• Модель Win32 "AppContainer". Мы полностью совместимы с песочницей в других операционных системах, но нам нужен доступ к «современным» API.
• Визуальный слой ( Windows|Microsoft.UI.Composition )
• DXGI Своп цепочки в визуальном слое / SwapChainPanel
• API управления окнами (AppWindow и т. Д.)

@infoequipt благодарим за подробные заметки! Определенно полезно. @ marb2000 для наглядности

Интересно услышать о Visual Layer применительно к WinUI 3.0. Вы хотите сказать, что для начальных выпусков WinUI 3.0 будет зависеть от классов Windows.UI.Composition?

@MarkIngramUK нет, извините за путаницу - я раньше

Microsoft.UI.Composition будет частью WinUI 3, и Microsoft.UI.Xaml будет зависеть от него. Это уже относится к WinUI 3 Alpha.

Мы работаем над созданием Xaml с открытым исходным кодом, что означает, что код фреймворка Xaml будет жить в этом репозитории, а наша команда инженеров будет делать всю нашу повседневную работу над Xaml на GitHub в будущем. Однако пакет Microsoft.UI.Composition, от которого зависит Xaml, по-прежнему будет разрабатываться внутри компании и обновляться только в двоичной форме.

Спасибо за разъяснение, @jesbis очень ценится. Какие методы распространения вы будете использовать для этого? Мы кроссплатформенное приложение, поэтому используем CMake и зависим от Windows.UI.Composition, поэтому нам бы очень понравился способ простого добавления новых dll, lib, заголовков и т. Д.

Есть ли какие-либо последствия для производительности при извлечении визуального слоя из ОС? Т.е. если вы полагаетесь только на визуальный слой, будет ли обновление до новой библиотеки недостатком?

Планируется ли в конечном итоге открыть Microsoft.UI.Composition с открытым исходным кодом?

@MarkIngramUK Я в целом согласен с тем, что вы говорите, и с тем, что @SavoySchuler говорит с точки зрения «общей картины». Однако, как вы отметили, нам, пользователям WinUI 2.0, труднее принимать ошибки, поскольку прямо сейчас у нас есть производственные приложения. Нам нужно найти компромисс между исправлением некоторых ошибок, которые не задерживают WinUI 3.0, а также сохранением WinUI 3.0 на ходу. Еще одно разочарование вызвало то, что NumberBox - это совершенно новый элемент управления, которым сразу же пренебрегли - с комментарием, что Microsoft не будет возвращаться к нему более года. Тем не менее, я определенно согласен с тем, что WinUI 3.0 является приоритетом, и не хотел бы, чтобы он откладывался в какой-либо значительной степени.

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

Какие методы распространения вы будете использовать для этого? Мы кроссплатформенное приложение, поэтому используем CMake и зависим от Windows.UI.Composition, поэтому нам бы очень понравился способ простого добавления новых dll, lib, заголовков и т. Д.

@MarkIngramUK подойдет ли вам использование пакетов NuGet? То есть, что мы делаем с WinUI 2.x и WinUI 3 Alpha. Мы все еще прорабатываем некоторые детали распространения с командой Visual Studio. Прямо сейчас WinUI 3 Alpha содержит двоичные файлы Xaml и Composition в одном пакете, но мы разделим их для поддержки Xaml с открытым исходным кодом и возможности сборки Xaml отдельно.

Есть ли какие-либо последствия для производительности при извлечении визуального слоя из ОС? Т.е. если вы полагаетесь только на визуальный слой, будет ли обновление до новой библиотеки недостатком?

Следите за обновлениями 🙂 Тестирование производительности и работа находятся в нашей дорожной карте на конец этого года, поэтому пока рано говорить о каких-либо цифрах.

Планируется ли в конечном итоге открыть Microsoft.UI.Composition с открытым исходным кодом?

Это в нашей очереди на рассмотрение, но у нас нет плана на этот счет.

@MarkIngramUK, если бы я мог спросить: какую выгоду вы надеетесь получить от открытого исходного кода?

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

Нам, пользователям WinUI 2.0, труднее принимать ошибки, поскольку прямо сейчас у нас есть производственные приложения. Нам нужно найти компромисс между исправлением некоторых ошибок, которые не задерживают WinUI 3.0, а также сохранением WinUI 3.0 на ходу. Еще одно разочарование вызвало то, что NumberBox - это совершенно новый элемент управления, которым сразу же пренебрегли - с комментарием, что Microsoft не будет возвращаться к нему более года. Тем не менее, я определенно согласен с тем, что WinUI 3.0 является приоритетом, и не хотел бы, чтобы он откладывался в какой-либо значительной степени.
Я, вероятно, должен сказать, что ценю всю работу, которую Microsoft делает здесь, и их усилия, направленные на то, чтобы быть более прозрачными и коммуникативными.

@robloo спасибо! Мы действительно стараемся быть прозрачными, и хорошо знать, что это ценно 🙂

Просто чтобы повторить то, что упомянул Савой, у нас есть разработчики, работающие над WinUI 2.x (как, надеюсь, можно увидеть из журнала PR), поэтому мы определенно по-прежнему инвестируем в WinUI 2 и 3 параллельно - это просто большая часть наших ресурсы находятся на WinUI 3. Я согласен с тем, что NumberBox, в частности, требует некоторого внимания, и наш руководитель разработчиков элементов управления Xaml сейчас занимается этим.

@robloo Ты лучший! 😄 Еще раз извините за путаницу - единственное, что связано с этой задержкой в ​​~ 1 год, это дополнительные режимы проверки ввода NumberBox, потому что они заблокированы в нашей работе по проверке ввода, запланированной на 3.0. В противном случае @teaP , @ranjeshj и я будем в списке ошибок NumberBox, начиная со следующей недели. 🙂

Я думаю, что @jesbis позаботился обо всем остальном!

@jesbis ,

@MarkIngramUK подойдет ли вам использование пакетов NuGet? То есть, что мы делаем с WinUI 2.x и WinUI 3 Alpha. Мы все еще прорабатываем некоторые детали распространения с командой Visual Studio. Прямо сейчас WinUI 3 Alpha содержит двоичные файлы Xaml и Composition в одном пакете, но мы разделим их для поддержки Xaml с открытым исходным кодом и возможности сборки Xaml отдельно.

Честно говоря, я не так хорошо знаком с NuGet, но, глядя на этот ответ SO, кажется, что он будет работать только в том случае, если вы используете CMake для создания файлов проекта VS, а это не то, как мы обычно работаем (обычно просто откройте папку , который использует Ninja в качестве генератора). Жаль, что вы не можете отправить исходный код, так как вы также можете использовать vcpkg . Для справки, мы собираем все библиотеки из исходного кода (что позволяет избежать любых потенциальных проблем с ABI, особенно с учетом того, что мы строим с помощью Clang / LLVM и в Windows).

Планируется ли в конечном итоге открыть Microsoft.UI.Composition с открытым исходным кодом?

Это в нашей очереди на рассмотрение, но у нас нет плана на этот счет.

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

@MarkIngramUK, если бы я мог спросить: какую выгоду вы надеетесь получить от открытого исходного кода?

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

Первоначальные мысли способствуют / расширяются (как я упоминал ранее, у нас есть зависимость от Windows.UI.Composition, но не от Xaml Framework / UWP), хотя мы думаем вслух, портируя Visual Layer на Vulkan или Metal для кросс- платформа может быть захватывающей, но я уделил этому буквально 30 секунд размышлений. Кроме того, открытый исходный код избавит от мучительного беспокойства по поводу принятия другой инфраструктуры, от которой в конечном итоге Microsoft откажется через несколько лет (наши текущие приложения построены на WPF, наши предыдущие приложения были построены на MFC, у нас были веб-компоненты, использующие Silverlight, поэтому , вы можете увидеть, откуда я иду ...).

NumberBox

Всем привет! @teaP , @ranjeshj и я сегодня проработали все наши открытые элементы NumberBox.

• Мы уже закрыли несколько.
• @teaP отправил объединенный PR еще для нескольких ( здесь фильтрация по ярлыкам ).
• У нас есть план действий в отношении остальных (за исключением № 1721), и мы ответим исправлениями как можно скорее. # 1721 требует дополнительной работы, чтобы определить наилучший путь вперед. Мы продолжим работу, чтобы решить эту проблему.

Спасибо всем за сотрудничество с нами. Мы ❤️ WinUI!

Есть ли «календарь» для звонков сообщества WinUI? Пример: в виде общедоступного календаря, который мы можем добавить / интегрировать в наш live / google / * календарь для автоматического обновления сведений о звонках.

События YouTube запланированы заранее, поэтому вы можете добавить напоминание Google здесь, в разделе «предстоящие прямые трансляции»:

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

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