컨트롤 및 기본값에서 nullable 데이터 형식에 대한 지원에 대해 이야기할 수 있습니까? 예를 들어 DateTimeOffset을 반환하는 DatePicker 와 DateTimeOffset?을 반환하는 CalendarDatePicker 가 있습니다.

• 이 중 하나는 nullable이고 다른 하나는 nullable이 아닌 이유는 무엇입니까? DatePicker가 Windows 8 시간대에 이전 API를 사용하여 개발되었기 때문입니까?
• 컨트롤에서 null을 허용/비허용하기 위해 구성 속성을 추가하는 것을 고려해야 합니까?
• NumberBox와 같은 새 컨트롤에 대해 DefaultValue 속성을 고려해야 합니까, NaN을 기본값으로 유지해야 합니까, 아니면 기본 null을 사용하여 nullable double로 전환해야 합니까?
• NumberBox의 Value 속성을 nullable로 만드는 것을 방지하는 nullable 값 반환 및 지원에 WinRT/OS XAML 제한 사항이 있습니까? 그렇다면 CalendarDatePicker는 어떻게 구현되었습니까?
• 이것은 #1721 및 #1708의 NumberBox 토론과 직접적인 관련이 있습니다.

또한, WinUI 3.0에 의존하지 않는 NumberBox의 미해결 문제를 해결하기 위한 로드맵은 무엇입니까? 더 오래 기다릴 필요 없이 WinUI 2.4 주변에서 이 컨트롤을 사용하기 시작하는 것이 좋습니다. 내 의견으로는 아직 완전히 구워지지 않았으며 이것을 프로덕션 앱으로 가져 오는 것이 불편합니다.

토론할 또 다른 흥미로운 아이디어는 다음과 같습니다. WinUI 3.0이 오픈 소스로 전환되는 지금 Microsoft의 주요 변경 사항은 무엇입니까?

과거에 Microsoft는 사실상 획기적인 변경을 한 적이 없습니다. 이것은 일반적으로 모든 혼란이 몇 년(또는 10년) 후에 쌓일 때까지는 좋은 일입니다. 또한 오픈 소스 프로젝트의 표준이 아닙니다. 예를 들어, 결국 ListBox는 ListView에 대해 단계적으로 중단되고 MessageDialog는 ContentDialog에 대해 단계적으로 중단되어야 합니다. API에도 더 나은 작은 정리가 많이 있다고 확신합니다.

나는 기업이 변화를 싫어한다는 것을 알고 있습니다. 정당한 이유가 있습니다. 또한 새 API로의 이식을 간단하게 만들기 위해 사용 가능한 비교적 쉬운(기능적으로 동등한) 드롭인 교체가 있어야 합니다(MUST). 이는 사례별로 평가하고 판단을 내려야 합니다.

주요 릴리스(예: WinUI 4.0)를 주요 변경 사항으로 설정할 수 있는지 궁금합니다. 이를 통해 과거의 모든 실수를 안고 살지 않고도 프로젝트가 계속 성장할 수 있습니다. 본질적으로 Microsoft는 .NET Core를 기반으로 하고 전체 .NET Framework를 삭제하여 .NET 5로 이를 수행하기로 이미 결정했습니다.

논의가 끝나면 문서화하는 것이 좋습니다.

마지막 호출 이후의 진행 상황에 따라 팀은 언제 WinUI 3가 출시될 준비가 될 것이라고 현실적으로 생각합니까?

• 빌드 2020(4월-5월)
• Ignite 2020(10월-11월)
• ~2021년

또한 새로운 AOT 솔루션과 .NET 5를 통합하는 .NET 팀에 대한 귀하의 작업은 얼마나 의존적입니까?

마지막으로, Windows 10X 릴리스를 위해 준비해야 하는 Windows 측의 압력이 있습니까?

WinUI 2.X 프로젝트를 WinUI 3.0으로 쉽게 변환할 수 있는 도구가 있어야 합니까?

방 안의 코끼리 - WinRT (#1856)

방 안의 코끼리 - WinRT (#1856)

샌드박스가 적용되지 않은 앱 모델이 출시될 예정입니다. 이 모델은 WPF(Win32 API 포함)와 동일한 방식으로 실행되지만 최신 WinRT API에 액세스할 수 있으며 Direct X 12에서 실행되는 새로운 XAML이 포함된 오픈 소스 UI 및 컨트롤이 제공됩니다.

샌드박스가 적용되지 않은 앱 모델이 출시될 예정입니다. 이 모델은 WPF(Win32 API 포함)와 동일한 방식으로 실행되지만 최신 WinRT API에 액세스할 수 있으며 Direct X 12에서 실행되는 새로운 XAML이 포함된 오픈 소스 UI 및 컨트롤이 제공됩니다.

우와. 와우 와우!!!!

그것은 놀라운 것 이상입니다! 이에 대한 ETA가 있습니까? 통화에서 논의할 예정입니까?

엄청나게 굉장하다!

샌드박스가 적용되지 않은 앱 모델이 출시될 예정입니다. 이 모델은 WPF(Win32 API 포함)와 동일한 방식으로 실행되지만 최신 WinRT API에 액세스할 수 있으며 Direct X 12에서 실행되는 새로운 XAML이 포함된 오픈 소스 UI 및 컨트롤이 제공됩니다.

우와. 와우 와우!!!!

그것은 놀라운 것 이상입니다! 이에 대한 ETA가 있습니까? 통화에서 논의할 예정입니까?

엄청나게 굉장하다!

그것은 우리가 WinUI에 대해 배운 첫 번째 것이었습니다. ETA는 올해를 위한 것이므로 //Build/에서 정확한 날짜가 제공될 것으로 생각합니다. 그러나 통화 중에 자유롭게 질문하십시오.

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

@jtorjo WinUI 로드맵을 참조하십시오. 또한 자세한 정보(예: VS 프로젝트 템플릿)는 https://github.com/microsoft/microsoft-ui-xaml/issues/1045 를 참조

@mdtauk @Felix-Dev 그 문서를 다시 읽을 것입니다. 전에 이것을 물어봤던 기억이 납니다. (샌드박스가 아닌) 앱에서 win2d를 쉽게 사용할 수 있다면 더할 나위 없이 행복할 것입니다!

@jesbis 멍청한 질문에 대해 죄송합니다 - 통화에 어떻게 참여합니까?

오늘 오후에 내일 통화를 위한 정보를 설정하고 있습니다. 몇 시간 후에 안내를 게시하겠습니다.

지연은 새로운 방송 시스템을 사용하는 것이 처음이기 때문입니다. 이후에는 더 원활하게 진행되고 더 일찍 준비될 것입니다. 🙂

나는 (어쨌든 나에게) 흥미로운 생각을 했다.

오늘의 ASP.NET Community Standup 라이브 스트림을 살펴보면 기술 데모에 가깝긴 하지만 본질적으로 4명의 MS 개발자가 라이브 코딩 스트림을 수행하는 것을 보았습니다. 나는 또한 라이브 코딩 세션에서 전체를 수행 하는 Twitch의 듣 습니다.

그래서 내 생각은 - WinUI 3가 출시되고 코드베이스(또는 대부분)가 모두 오픈 소스가 된 후 팀 구성원이 가끔 WinUI에서 작업 중 일부를 라이브 스트리밍할 수 있을까?

WinUI 노출을 늘리고 사람들이 코드베이스를 쉽게 탐색할 수 있도록 돕고 때때로 질문을 던질 수 있는 좋은 기회가 될 것입니다. ~나는 매우 비생산적일 수 있으므로 항상 전체 채팅 참여를 권장하지 않지만 가끔은 Q&A가 될 수 있습니다.

특히 근무 시간에는 MS 정책이 어떤 유형인지 전혀 모릅니다. 당신의 생각을 듣는 것이 흥미로울 것입니다.

내일의 유튜브 라이브 이벤트 링크입니다!

https://youtu.be/MXTVqgB4rW0

지금까지 모든 의견과 질문에 감사드립니다! 우리는 모든 것에 접근하려고 노력할 것이고, 시간이 없을 경우 후속 조치를 추적할 것입니다.

가이드에 UI의 성능/fps에 대한 내용이 있습니까? 최신 Windows 10에 대한 가장 큰 불만 중 하나는 Surface Book과 같은 시스템에서 높은 DPI 디스플레이에서 끔찍한 성능을 얻을 수 있다는 것입니다. 투명도와 추가 모니터를 결합하면 더욱 악화됩니다. 가능한 범위 밖일 수도 있지만 특히 이러한 조건에서 얼마나 유연하고 잘 작동하는지에 대한 고려 사항이 있습니까?

테두리 없는/투명한 창의 우선 순위를 높이는 것을 고려하십시오(https://github.com/microsoft/microsoft-ui-xaml/issues/1247). 이것은 우리 와 같은 앱을 위한 WinUI 채택 차단기입니다.

참조: @crutkas

경계선이 없는/투명한 창의 우선 순위를 높이는 것을 고려하십시오(a la #1247). 이것은 우리 와 같은 앱을 위한 WinUI 채택 차단기입니다.

참조: @crutkas

이를 위해서는 WPF와 유사한 속성을 사용하여 WinUI Xaml에 추가된 최상위 창 요소가 필요할 수 있습니다. #1323

WinUI에 대한 '윈도우의 미래'에 대해 더 많이 배우는 것이 좋을 것입니다. 적어도 논의/처리할 수 있는 관련 요청이 많이 있습니다.

아마 전에 물어본 적이 있을 것입니다.

나에게 항상 코드 재사용성의 문제였습니다.
이것은 두 가지 질문으로 이어집니다.

1. .NET Core 3 및 C# 8.0 지원이 곧 제공되나요?
2. UWP/WinUI 팀에서 Uno Platform 앱을 더 쉽게 개발할 수 있도록 추가 단계를 살펴볼까요?

또 하나, UWP에서 지원되는 WPF의 누락된 비트는 언제 볼 수 있습니까?

아마 전에 물어본 적이 있을 것입니다.

나에게 항상 코드 재사용성의 문제였습니다.
이것은 두 가지 질문으로 이어집니다.

1. .NET Core 3 및 C# 8.0 지원이 곧 제공되나요?
2. UWP/WinUI 팀에서 Uno Platform 앱을 더 쉽게 개발할 수 있도록 추가 단계를 살펴볼까요?

또 하나, UWP에서 지원되는 WPF의 누락된 비트는 언제 볼 수 있습니까?

.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 컨트롤 갤러리에서 이 문제 를 열었습니다. 원한다면 통화 중에 논의할 수 있습니다.

감사합니다. 모든 질문에 대해 알아보겠습니다!

가이드에 UI의 성능/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 여기 :

내일의 유튜브 라이브 이벤트 링크입니다!
https://youtu.be/MXTVqgB4rW0

YT 링크를 따라가면 정규 시간보다 한 시간 늦은 이 시간이 끝날 때만 시작되는 것 같은데 사실인가요?

@weitzhandler 시작 시간은 게시물 상단에 있습니다. 이것은 또한 세 번째 호출이므로 "regular"는 확장입니다.

@weitzhandler 지금까지 세 번의 전화 모두 태평양 표준시로 오전 9시에 시작될 예정이었습니다.

두 분 감사하고 번거롭게 해서 죄송합니다. 곧 봐요.

Chromium 기반 WebView2 가 현재 WebView 에서 WebResourceRequested 와 같은 이벤트를 노출하여 개발자가 개별 웹 요청을 걸러낼 수 있는지 여부가 궁금했습니다. 나는 내 앱 중 하나에서 그 특정 기능에 많이 의존하며 그것이 새로운 컨트롤과 함께 여전히 주변에 있고 동일한 방식으로 작동하는지 궁금합니다.

모두들 고생해주셔서 감사합니다! 😄🚀

PDF를 생성하는 도구가 있습니까? Win2D에는 이미 많은 놀라운 도구가 있으며 CanvasRenderTarget 에서 PDF를 생성하는 기능이 추가될 것입니다.

그것을 얻지 못했습니다 - vsix를 설치하는 방법? 어디에서 다운로드?

저만 그런건지도 모르지만 오늘 통화에 실망했습니다. 더 많은 기술 인력을 포함하십시오. PM은 토론의 초점을 유지하고 일정에 맞게 움직여야 하지만 응답을 전문가에게 위임해야 합니다(마지막에 더 많이 수행됨).

이 통화에 참여하는 모든 사람이 개발자이고 자세한 내용을 알고 논의해야 합니다. PM은 매우 기본적인 주제에 초점을 맞추고 있으며 세부 사항에 들어갈 수 없습니다. 예를 들어, 문서/WebView/ProgressRing에 대한 호출 시작 부분의 토론은 개념적으로는 훌륭하지만 너무 기본적이어서 우리에게 유용하지 않다고 생각합니다. 우리는 수십 년 동안 XAML을 사용해 왔으며 전문 청중과 이야기하고 있습니다(청중에게 프레젠테이션을 적용하는 것이 중요함).

@SavoySchuler 당신은 본질적으로 우리 회사와 앱을 포함하여 우리가 컨트롤을 사용하는 방법을 알려주라고 말했습니다. 이것은 필요한 재료와 좋은 것을 구분하는 데 필요합니다. 이는 기능에 대한 리소스의 우선 순위를 지정하는 데 도움이 됩니다. 다음 두 가지에 대해 다르게 생각할 필요가 있습니다.

1. 기능 -- 이 경우 귀하가 말한 내용이 대체로 정확합니다.
2. 버그/이슈 -- 이 경우 커뮤니티에서 우선 순위를 지정하는 데 도움이 되는 예제를 제공할 필요가 없습니다. 제품을 배송할 때 품질이 최우선입니다. 우리는 당신에게 버그를 말하고 당신은, 음, 네, 그것은 좋은 것입니다. 수리가 필요하다는 것을 증명하십시오. 버그입니다. 소비자에게 앱을 제공한 적이 없습니까? 조금이라도 잘못된 것은 회사의 가장 가치 있는 부분인 이미지와 인식에 영향을 미칩니다. 앱 산업은 경쟁이 매우 치열합니다.

커뮤니티에서 버그를 보고하면 버그를 수정하도록 예약해야 합니다. 수정할 계획이 없는 불완전한 컨트롤 배송을 중단하십시오. 이것은 매우 친숙하게 들리기 시작했습니다. 몇 년 전 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을 수십 년 동안 사용해 왔으며 전문가 청중과 이야기하고 있습니다(청중에게 프레젠테이션을 적용하는 것이 중요함).

@roblo 이에 대한 피드백에 감사드립니다. 우리는 더 많은 개발자를 포함하고 향후 통화에 대한 특정 주제에 대해 더 자세히 설명할 수 있습니다. 만약 그것이 모두에게 관심이 있다면 - 우리는 오랜 시간이 지났기 때문에 첫 번째 통화에서 그것을 시도하고 싶지 않았고 일반적인 캐치-를 하고 싶었습니다. 위로.

우리는 또한 많은 청중이 아직 WinUI에 익숙하지 않기 때문에 때때로 너무 기술적이고 너무 깊이 있다는 피드백을 과거에 받았습니다. 그래서 우리는 그 피드백의 균형을 맞추려고 노력하고 있습니다.

또한 참고할 수 있다면: 개발자 플랫폼 팀의 많은 PM은 뛰어난 기술을 보유하고 있으며 주요 플랫폼 및 실제 앱을 위한 프로덕션 코드를 작성한 경험이 있습니다. 그들 중 일부는 이전에 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용입니다.

WinUI 3를 기다려야 제대로 처리할 수 있는 문제에 대해 needs-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 개발을 통해 내부적으로 유지될 가능성이 높습니다. 엉킴을 풀기 위한 개인 OS 종속성, 다른 OS 구성 요소 개발 팀과 긴밀하게 인터페이스해야 하는 등)

태그가 지정된 기능 제안의 대부분은 초기 3.0 릴리스에서 해결되지 않을 것이라고 말할 수 있습니다. 우리의 주요 초점 영역은 다음과 같습니다.

• OS에서 WinUI를 분리하여 별도로 배송
• Xaml 프레임워크 오픈 소싱
• 좋은 WinUI 데스크톱 앱 개발 경험 만들기(win32 사용, 패키징, 윈도우 설정 등)
• Windows 10X 활성화
• .NET Core/5 + WinUI 앱 활성화

그리고 동시에 수많은 추가 새 기능 개발을 시도하여 이를 지연시키거나 불안정하게 만들고 싶지 않습니다.

데스크탑/윈도우 지원과 같은 큰 영역에서 구체적인 진전이 이루어지면 제안 및 업데이트를 리포지토리에 게시할 것입니다.

WinUI 3 Xaml을 오픈 소스로 만들 수 있게 되면 추적을 GitHub로 이동할 수 있지만 일상적인 작업 항목 추적의 대부분은 현실적으로 여러 가지 이유로 3.0 개발을 통해 내부적으로 유지될 가능성이 높습니다. 엉킴을 풀기 위한 개인 OS 종속성, 다른 OS 구성 요소 개발 팀과 긴밀하게 인터페이스해야 하는 등)

내부 문제 와 같은 일반적인 이름을 가진 빈 항목으로 표시되더라도 이러한 내부 작업 항목을 공개적으로 나열할 수 있습니까? To Do에서 In Progress, Complete로 이동하는 것을 보면 전체 프로젝트에 대한 어느 정도의 진행 상황을 나타냅니다.

태그가 지정된 기능 제안의 대부분은 초기 3.0 릴리스에서 해결되지 않을 것이라고 말할 수 있습니다. 우리의 주요 초점 영역은 다음과 같습니다.

• OS에서 WinUI를 분리하여 별도로 배송
• Xaml 프레임워크 오픈 소싱

물론 이것이야말로 노력의 핵심이지만, 현재 구현되어 있는 다양한 문제점이나 문제점을 OS 코드에서 해방시켜 해결하는 것이 가능할 수도 있다.

• 좋은 WinUI 데스크톱 앱 개발 경험 만들기(win32 사용, 패키징, 윈도우 설정 등)
• Windows 10X 활성화

이는 올바른 작업을 수행하는 데 필수적이며 피드백을 수용할 수 있는 열린 마음으로 사용자와 개발자의 손에 이 두 가지를 모두 제공해야 합니다. 또한 앱 런타임 및 앱 모달은 이 WinUI 팀의 소유가 아니므로 이를 담당하는 사람에게 피드백을 필터링할 수 있도록 설정해야 하기 때문에 어려울 것입니다.

• .NET Core/5 + WinUI 앱 활성화

현재 기본 지원은 C++ 코드 및 Win32 API의 형태로 제공됩니다. 하지만 이것이 모든 C# 개발자가 .NET을 대상으로 해야 한다는 것을 의미합니까? 샌드박스가 적용되지 않은 앱 모델은 .NET 없이 C# 코딩을 허용합니까?

그리고 동시에 수많은 추가 새 기능 개발을 시도하여 이를 지연시키거나 불안정하게 만들고 싶지 않습니다.

데스크탑/윈도우 지원과 같은 큰 영역에서 구체적인 진전이 이루어지면 제안 및 업데이트를 리포지토리에 게시할 것입니다.

CoreWindow 없이(앞으로만 UWP가 될 예정) - Windowing은 첫날부터 제자리에 있어야 하는 것 중 하나입니다. WPF에는 컨트롤, 시각적 스타일 지정, 투명도 등을 처리하는 XAML의 Window 개체가 있습니다. 크기 조정, 최소화 등을 처리합니다. 이전 Win32 프레임워크는 XAML UI에 해당되지 않는 표면의 수동 페인팅이 필요하므로 이 간격을 어떻게 메울까요? ?

이것은 우리가 이중 스크린 장치에 도달하기 전이며 비 UWP 앱 모델 및 창 설정이 이에 적응하는 방법입니다.

이러한 내부 작업 항목이 내부 문제와 같은 일반적인 이름을 가진 빈 항목으로 표시되더라도 공개적으로 나열할 수 있습니까?

우리의 목표는 분명히 우리의 프로세스(문제 추적 포함)를 코드 외에 오픈 소스로 옮기는 것입니다.

우선 상위 수준 추적을 위한

그러나 여기에는 WinUI 3.0의 모든 일상적인 개발 작업이 즉시 포함되지 않습니다. 참고로 우리는 현재 2020년에 수천 일 분량의 관련 개발 작업을 추적하고 있으며 아직 모든 작업을 이동할 준비가 되지 않았습니다. 오늘 GitHub에 대한 매우 세분화된 추적. 우리는 WinUI 2에서 했던 것처럼 시간이 지남에 따라 그것에 도달할 것입니다.

따라서 기능 수준 문제(예: WebView)부터 시작하여 시간이 지남에 따라 프로세스를 GitHub로 완전히 마이그레이션할 것입니다.

현재 기본 지원은 C++ 코드 및 Win32 API의 형태로 제공됩니다. 하지만 이것이 모든 C# 개발자가 .NET을 대상으로 해야 한다는 것을 의미합니까? 샌드박스가 적용되지 않은 앱 모델은 .NET 없이 C# 코딩을 허용합니까?

.NET 네이티브에 대해 묻고 있습니까, 아니면 .NET이 전혀 없습니까? 기술적으로 언어로서의 C# 사양은 .NET에 의존하지 않는다고 생각하지만 현재 C++ 또는 이와 유사한 것으로 변환할 계획이 없습니다.

CoreWindow 없이(앞으로만 UWP가 될 예정) - Windowing은 첫날부터 제자리에 있어야 하는 것 중 하나입니다. WPF에는 컨트롤, 시각적 스타일 지정, 투명도 등을 처리하는 XAML의 Window 개체가 있습니다. 크기 조정, 최소화 등을 처리합니다. 이전 Win32 프레임워크는 XAML UI에 해당되지 않는 표면의 수동 페인팅이 필요하므로 이 간격을 어떻게 메울까요? ?

@marb2000 은 이에 대해 작업 중이며 가능한 한 더 많은 정보를 공유할 수 있습니다.

이것은 우리가 이중 스크린 장치에 도달하기 전이며 비 UWP 앱 모델 및 창 설정이 이에 적응하는 방법입니다.

분명히 말해서, WinUI 3는 모든 win32 데스크톱을 HoloLens와 같은 다른 플랫폼으로 가져오지 않을 것입니다. 여러 장치를 대상으로 할 때 범용 앱과 API는 여전히 갈 길입니다.

너무 일찍 게시되었습니다. 전체 의견:

@roblo - 나는 당신의 많은 감정에 동의하는 것으로 시작하고 싶습니다. 나는 우리의 모든 기술적인 문제로 인해 매우 혼란스러웠고 그 질문을 내가 원하는 만큼 처리하지 못했습니다. 여기에서 다시 시도할 수 있도록 허용해 주세요.

헌장 및 자원

이와 같은 주제를 다루는 것이 결코 인기가 없을 것이라는 것을 압니다. 그러나 저는 투명성을 믿으며 우리가 직면한 문제에 대해 커뮤니티로서 여러분과 솔직하고 싶습니다. 그래야 문제를 해결하는 방법을 결정하는 데 도움이 되는 토론에 참여할 수 있습니다. . 이 특정 과제는 시간과 자원 자산의 분할에 중점을 둡니다. 우리 팀은 세 가지 주요 이니셔티브로 나뉩니다.

1. WinUI 2의 발전
2. WinUI 3 제공
3. 오픈 소싱 WinUI 3

아시다시피, 우리는 A) 이것이 결합된 목표이고 B) WinUI를 오픈 소싱함으로써 모든 사람 이 우리 팀의 한정된 리소스에 의해 차단되는 것을 멈출 수 있음을 의미하기 때문에 2와 3을 향해 확고히 전화를 걸었습니다.

목표 2와 3에서 WinUI 2가 커뮤니티 구성원에게 제대로 서비스를 제공하지 못하는 지점까지 너무 앞서간다면 우리는 대화를 할 수 있고 우선순위를 변경할 수 있습니다. 백로그의 모든 버그를 해결하면 WinUI 3의 출시가 6개월 정도 지연된다는 점을 알아두세요. 대신 WinUI 소스를 공개할 뿐만 아니라 방대한 Win32 개발자 기반과 관련성을 확장하는 2와 3을 우선순위로 지정하면 오픈 소스 커뮤니티와 우리 팀의 힘으로 버그 _및_ 기능 요청의 백로그를 정리할 수 있습니다. 우리를 지원하는 전폭적인 관심. 이를 위해 우리의 현재 근거는 접근 계획이 이 플랫폼을 더 빠르게 발전시킬 뿐만 아니라 더 포괄적으로 발전시킬 것이라는 것입니다. 버그의 우선 순위를 정하는 데 도움을 달라고 요청했을 때 질문은 "우리 팀이 해결하기에 충분히 중요합니까?"가 아니었습니다. 그러나 대신 "이것이 WinUI를 더 빨리 오픈 소싱하는 것보다 중요합니까?" 현재 상태에서 우선 순위 1을 향상시키기 위해 작업하는 개발자의 하위 집합이 있으며 커밋 기록 및 활성 문제에 영향을 줄 수 있지만 동일한 목표 내에서 우선 순위를 지정해야 할 필요성에 직면해 있습니다. "이것이 얼마나 중요한지 알려주세요"라는 개념은 요구 사항(예: 내 제품이 차단되었으며 WinUI 3을 기다릴 수 없음) 대 좋은 것(예: 이 기술 오류를 발견했지만 기존 개발이 없음)을 필터링하는 데 도움이 됩니다. WinUI 3)을 기다릴 수 있도록 차단됩니다.

내가 분명히 말하고 싶은 또 다른 것은 WinUI 2 버그를 제출하고 기능 요청을 작성하는 등의 모든 작업이 우리에게 _ 잃지 _ 없다는 것입니다. WinUI 3가 출시되면 커뮤니티가 코드를 제출할 수 있는 권한을 부여하는 것 외에도 플랫폼을 발전시키는 작업 항목으로 돌아갈 수 있는 팀의 상당 부분이 확보됩니다. 즉, 현재 우리 팀의 전체 전력이 기존 UWP 커뮤니티와 곧 Win32의 도움으로 처리할 백로그를 준비하고 있습니다.

한 가지 추가로 알아야 할 사항은 OS에서 WinUI 3으로 코드를 마이그레이션하는 동안 우리가 할 수 있는 곳에서 코드를 간단하고 정리하기 위한 조치를 취하고 있다는 것입니다. 즉, 특정 기능 추가 및 버그 수정이 WinUI 3에서 해결될 경우 시간과 노력이 현저히 줄어듭니다.

넘버박스

특징

NumberBox로 돌아가자. V1이 원하는 기능의 하위 집합이라고 말하는 것이 사실 맞습니다.
계획된 V1 기능은 입력 유효성 검사(WinUI 3 알파에서 미리 보기에 있음)와 같은 항목에 대한 종속성으로 인해 V2까지 지연되었습니다. 우리는 사양(여기)에서 V1이 될 자격이 있다고 생각하는 모든 것을 인정함으로써 사양을 완전하게 만들려고 노력했으며 컨트롤의 WinUI 3 V2 릴리스로 그 약속을 완전히 이행할 계획입니다.

오픈 소스의 정신을 받아들임으로써 내 바람(그리고 이 작업을 통해 내가 잘못했는지 알려주세요)은 가능한 한 빨리 안정적이고 유용한 코드를 릴리스하고 기능 세트를 점진적으로 구축하는 것을 전적으로 선호하는 것입니다. 응용 프로그램에서 이것은 WinUI 2에서 _대부분_ 완전한 V1을 릴리스하고 WinUI 3에서 할 수 있는 것처럼 입력 유효성 검사가 포함된 완전한 기능을 갖춘 릴리스로 후속 조치를 취하는 것을 선호한다는 것을 의미했습니다.

버그

@jesbis가 말했듯이 버그가 없는 코드 베이스는 없지만 품질은 우리에게 절대적으로 최우선입니다. 우리는 버그를 제거하기 위해 최선을 다하고 있으며 이 WinUI 2를 수행하기 위해 작업하는 팀의 하위 집합이 있습니다. WinUI 3의 출시로 우리 팀의 모든 노력이 재결합될 때까지 이것은 우리의 마음이 원하는 것보다 느리게 움직일 것입니다. 그러나 우리는 여전히 그것을 멀리 일하고 있습니다. @jesbis 는 WinUI 2의 커밋 로그에서 품질 수정과 새로운 기능의 비율을 볼 수 있으며 일단 오픈 소스가 되면 WinUI 3에서도 동일한 것을 볼 수 있다고 말했습니다.

저는 NumberBox로 이러한 버그를 해결하는 데 도움을 주기 위해 최선을 다하고 있으며, 제가 자산이 될 수 있는 미해결 문제, 버그 및 질문에 응답하기 위해 나머지 시간을 할애하고 있습니다. 다음주에도 하루를 비워두겠습니다. Twitter에서 저에게 질문을 보내거나 여기 리포지토리에서 이에 대해 저와 교류할 수 있도록 격려해 주십시오.

다음 단계

우리에게 오픈 소스는 마치 여기 Redmond 사무실에 앉아 있는 것처럼 커뮤니티를 팀원으로 포용한다는 약속입니다. 우리는 듣고 있습니다. 이러한 결정에 대해 함께 이야기하여 하나의 큰 팀으로 멋진 기능을 구축하는 데 집중할 수 있습니다. 🙂

우리 ❤️ WinUI

오픈 소스의 정신을 받아들임으로써 내 바람(그리고 이 작업을 통해 내가 잘못했는지 알려주세요)은 가능한 한 빨리 안정적이고 유용한 코드를 릴리스하고 기능 세트를 점진적으로 구축하는 것을 전적으로 선호하는 것입니다. 응용 프로그램에서 이는 WinUI 2에서 대부분의 완전한 V1을 릴리스하고 WinUI 3에서 할 수 있는 것처럼 입력 유효성 검사가 포함된 완전한 기능을 갖춘 릴리스로 후속 조치를 취하는 것을 선호한다는 것을 의미했습니다.

이것은 나일 수 있지만 가능한 한 빨리 코드를 제공하는 것이 중요하지만 무언가를 제공하기 전에 해결해야 하는 특정 유형의 문제가 있다고 생각합니다. 예를 들어 #1846은 V1을 제공하기 전에 해결해야 하는 문제입니다. 다른 몇 사람도 될 수 있습니다.

@yaichenbaum 거기에서 내 말을 더 잘 선택할 수 있었습니다. 🙂

AD가 _반드시 갖추어야 하는_ 기능이고 EH가 _가져 있으면 좋은_ 기능인 경우, 제 우선순위는 AD를 밖으로 내보내고 가능한 한 EH를 점진적으로 추가하는 것입니다.

검증 파트너와 함께 프리뷰 브랜치를 준비하는 이유는 컨트롤이 안정적인 릴리스로 푸시되기 전에 #1846과 같은 버그를 잡기 위함입니다. 죄송합니다. 이 문제에서 공을 놓쳤습니다. @teaP 와 최대한 빨리 협력하여 이 문제를 해결할 수 있는지 확인하겠습니다! 🙂

통화 중 한 시점에서 WinUI 앱이 AppDomain을 통해 샌드박싱을 허용할 것이라고 언급했습니다.

응용 프로그램 격리 및 리소스 제어를 위해 WinUI 3.0+가 Capabilities와 AppDomain을 어떻게 포지셔닝할 것인지 누군가 말할 수 있습니까?

또한 .Net Core에 대해 내가 마지막으로 알았던 AppDomain에 대한 완전한 지원이 이루어지지 않았습니다.

연락이 닿지 않을 수도 있지만 .Net 5에서 AppDomain을 완벽하게 지원한다는 말씀이신가요?

오늘 이 통화를 조직해 주셔서 감사합니다!

응용 프로그램 격리 및 리소스 제어를 위해 WinUI 3.0+가 Capabilities와 AppDomain을 어떻게 포지셔닝할 것인지 누군가 말할 수 있습니까?

통화에서 명확하지 않은 경우 죄송하지만 AppDomain이 아닌 AppContainer 에 대해 이야기하고 있었습니다.

아, 알겠습니다. 설명해주셔서 감사합니다. 제시.

우선 오늘 커뮤니티 콜을 주최해 주신 @SavoySchuler 와 @jesbis (및 나머지 WinUI 팀)에게 감사드립니다! 기술적 인 어려움이 있었지만이 전화는 매우 통찰력이있었습니다 !!!

@jesbis가 언급했듯이 WinUI 3.0에 대해 요청된 도구 및 기능을 추적하는 데 문제가 있습니다. 보다 쉬운 추적을 위해 WinUI 2.x에서 3.0으로 변환 도구의 요청을 별도의 문제로 분할하는 것이 더 낫습니까? 또한 이미 계획이 있습니까? 다른 개발자가 개발을 도울 수 있도록 도구를 오픈 소스로 만들 계획이 있습니까?

다른 비 WinUI 팀 구성원에게도 해당되는 또 다른 일반적인 질문은 기여에 관한 것입니다. 현재 사람들이 기여하는 것을 방해하는 장애물이 있습니까? 기여자를 위한 더 나은 시작 가이드가 도움이 될까요?

내 생각에는 프로젝트에 기여하기 시작하면 VS 프로젝트가 다소 압도적일 수 있으며 개발 방법, 어떤 테스트 프로젝트를 무엇에 사용해야 하는지 등에 대한 문서가 많지 않습니다.

아마도 그 영역의 개선으로 사람들이 더 쉽게 기여할 수 있을 것입니다 😅

WinUI 3.0 렌더링 레이어는 어떻게 수행됩니까? D3D11, D2D, 추상화 계층 또는 무엇을 직접 사용합니까? 소프트웨어 렌더링 레이어가 있거나 이를 위해 D3D WARP를 사용합니까?

@chingucoding

여기에서 방금 말한 요점을 반복

• 영원히 lang을 사용하지 않고
• 오늘 변경 사항을 덮어쓸 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와 같은 새로운 컨트롤을 출시하고 지금부터 1년까지 버그 수정에 리소스를 투입할 수 없다고 말하는 것은 좋지 않습니다.

WinUI 3.0에 의존하지 않는 컨트롤의 V1 버그를 해결해 달라는 요청입니다. 일부는 상당히 기본적이고 다른 일부는 설계에서 눈에 띄는 실수입니다(예: NaN이 양방향 바인딩 데이터 충돌). 기능/컨트롤을 릴리스하기로 결정하면 버그를 닫기 위해 신속하게 작업해야 합니다. 소프트웨어가 처음으로 광범위하게 출시될 때 항상 버그가 있습니다. (나머지 앱 개발자와 마찬가지로) 빠른 버그 수정 V2를 수행하기 위해 리소스를 계획하기만 하면 됩니다. 품질이 최우선이라는 데 동의하므로 다른 작업을 진행하기 전에 NumberBox에서 다음 문제를 해결하십시오.

1708 - 컨트롤의 모든 형식 사용과 사양에 이미 있는 기본 기능 중 하나에 자리 표시자 텍스트가 절대적으로 필요합니다. 이것이 NaN에 대해 실제로 수정되었으면 닫아야 합니다. Null 지원은 아래에서 다른 주제입니다.

1721 - UWP의 큰 문제는 특정 컨트롤에서 데이터 바인딩에 대한 불완전한 지원이었습니다. 많은 응용 프로그램 개발자는 몇 년 전에 MVVM 디자인에 투자한 다음 UWP 컨트롤로 전환하려고 시도했지만 데이터 바인딩이 부분적으로만 지원된다는 것을 발견했습니다. 이것은 엄청난 골칫거리이며 MVVM이 Microsoft의 모범 사례에 얼마나 기본적인지 고려할 때 용납할 수 없습니다. 이전 Windows 개발자 도구 팀은 결코 이를 지지하지 않을 것입니다. 이것이 Windows/기본 사고입니다.

1839 - 여기에 기본적인 것들이 있습니다. 이는 컨트롤 템플릿의 기본 버그일 뿐이며 반드시 수정해야 합니다. 변명하지.

1846 - 이전에 다른 많은 컨트롤에서 이 문제가 발생했습니다. 지금까지 이를 테스트하는 릴리스 체크리스트가 없는 이유는 무엇입니까? 다시 말하지만, 고쳐야 할 기본적인 것들. 이 컨트롤을 사용하는 모든 앱의 사용성에 영향을 줍니다.

1852, #1853, #1854 - 다시 말하지만, 이들은 지나치게 복잡하지 않으며 첫 번째 구현에서 놓쳤습니다. 그러나 특정 지역에서 판매되거나 정부를 위해 개발된 소프트웨어의 접근성을 지원하는 것은 법적 요구 사항입니다. 플랫폼으로서 애플리케이션 개발자가 컨트롤을 사용할 수 있도록 즉시 수정해야 합니다. 다시 말하지만, 나는 당신과 이런 종류의 논쟁을 할 필요가 없습니다. 그것은 기본적인 것입니다.

한 가지 추가로 알아야 할 사항은 OS에서 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)의 주요 문제인 것 같습니다.
그것들은 해결해야 할 중요한 문제 목록의 상위에 있지만 어디서부터 시작해야 할지 모르겠습니다. 디버그를 위해 단계별로 수행하고 싶은/필요한 코드를 사용할 수 있는지 여부도 알 수 없습니다.

그것들은 여전히 ​​dev 소유자에 의해 분류(분류)되어야 합니다(따라서 "needs-triage" 레이블 - 현재 아직 분류되지 않은 이유를 추적 중입니다. 죄송합니다). 그러나 TextBox가 WinUI 2는 WinUI3를 기다려야 합니다.

일단 분류되면 우리가 해결하기 전에 WinUI 3을 기다려야 함을 나타내는 needs-winui-3 레이블이 적용되어야 합니다.

WinUI 3가 오픈 소스가 되면 누구나 이러한 문제를 해결하는 데 도움을 줄 수 있습니다.

C++/WinRT로 작업하는 것을 좋아하지 않으며 분명히 내가 본 것처럼 코드베이스를 만질 자격이 없다고 생각합니다. 컨트롤이 관리되는 C#이라면 훨씬 더 많은 기여를 했을 것입니다.

우리는 C++가 C#보다 더 높은 장벽이라는 것을 알고 있지만 WinUI는 C++ 플랫폼으로 남을 계획입니다.

기여할 수 있는 또 다른 훌륭한 프로젝트는 C#이기 때문에 기여하기 쉽고 요구 사항이 완화된 Windows Community Toolkit 입니다.

우리는 유지 관리자와 협력하고 종종 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를 사용하는 하드웨어 가속 렌더링을 의미하며 일부 경우에는 소프트웨어 렌더링이 합리적입니다.

interop API를 사용하여 사용자 지정 렌더링된 DirectX 콘텐츠를 포함할 수도 있습니다.

WinUI에 C++/CX가 필요합니까? 그렇다면 이것이 Win32 및 기타 미래 목표에 대한 문제인 것 같습니까?

아니요 - WinUI 플랫폼은 C++로 작성되었지만 앱은 반드시 그럴 필요는 없습니다!

현재 WinUI 2를 사용하면 .NET(C#, VB.NET) 또는 C++를 사용하여 UWP 앱을 만들 수 있습니다.

WinUI 3의 목표는 곧 출시될 .NET 5 또는 C++를 사용하여 UWP 및/또는 win32 API를 사용하는 앱을 만들 수 있게 하는 것입니다.

@jesbis 제 질문 의도를 조금 오해하신 것

1) WinUI가 C++로 작성되었다는 것을 알고 있지만 WinUI 코드에는 Windows 전용 VC++/CX 확장이 필요합니까? CX 확장이 필요한 경우 WinUI가 다른 플랫폼으로 확장하려는 경우 이식성 문제가 발생할 수 있다고 봅니다. 이것은 예를 들어 UNO 팀이 코드를 채택하는 것을 어렵게 만들 수 있습니다.

2) 렌더링 시스템에 대해. 여기에 몇 가지 사항이 있습니다.

2.a) "비주얼 레이어"가 나중에 Vulkan 백엔드를 지원할 수 있도록 DirectX API에서 충분히 멀리 제거된 추상화 API입니까? (출처가 공개되면 이 질문에 대한 답을 얻을 수 있을 거라 확신하지만 궁금합니다.)

2.b) 소프트웨어 래스터화에 대한 내 질문은 다음과 같습니다. WinUI 3.0이 전체 소프트웨어 렌더링(단순한 텍스트 렌더링 또는 기타 기능이 아닌)을 지원합니까? 때로는 화면 공유 소프트웨어에 GPU 가속 앱(최소한 D3D9/WPF 사용)에 문제가 있고 소프트웨어 렌더링을 강제 실행하면 이러한 상황에서 문제가 해결됩니다. 또는 앱이 하드웨어 GPU가 없는 VM에서 실행되는 경우.

vsix를 설치하고 사용해 보기 위한 WinUI 3.0 Alpha 지침은 다음과 같습니다.
https://aka.ms/winui/alpha

Edge New로 그렇게 했습니까? 다운로드 링크가 표시되지 않고 크롬으로 반복했습니다. 거기에서 다운로드하십시오.

Edge New로 그렇게 했습니까? 다운로드 링크가 표시되지 않고 크롬으로 반복했습니다. 거기에서 다운로드하십시오.

@hannespreishuber 다운로드 링크는 설문조사의 마지막 페이지에 있어야 합니다. 설문조사가 Chromium Edge에서는 작동하지 않았지만 Chrome에서는 작동했다는 뜻인가요?

다운로드 링크는 설문조사의 마지막 페이지에 있어야 합니다. 설문조사가 Chromium Edge에서 > 작동하지 않았지만 Chrome에서는 작동했다는 뜻인가요?

둘 다에 대한 설문 조사를 했지만 마지막 페이지는 달랐습니다. 아마도 제 잘못일 것입니다.

둘 다에 대한 설문 조사를 했지만 마지막 페이지는 달랐습니다. 아마도 제 잘못일 것입니다.

좋습니다. 감사합니다. 두 버전의 Edge에서 설문조사를 테스트했으며 작동하는 것 같았습니다. 따라서 다운로드에 문제가 있는 사람이 있으면 알려주시고 페이지 콘텐츠가 Chrome과 다르게 렌더링되는 경우 Edge에서도 문제를 보고해 주세요(설정 > 도움말 및 피드백 > 피드백 보내기) 🙂

WinUI가 C++로 작성되었다는 것을 알고 있지만 WinUI 코드에는 Windows 전용 VC++/CX 확장이 필요합니까? CX 확장이 필요한 경우 이식성 문제가 발생할 수 있습니다.

@zezba9000 우리는 표준 C++17인 C++/WinRT를 사용하여 WinUI 2 컨트롤 및 기능(현재 저장소에 있는 새 코드)을 구현했지만 나머지 WinUI 3은 현재 여전히 의존할 훨씬 더 크고 오래된 코드베이스입니다. WRL 등에서. 우리는 현재 이식성에 초점을 맞추지 않고 있지만 미래에 이에 대해 논의할 준비가 되어 있습니다.

예를 들어 나중에 Vulkan 백엔드를 지원할 수 있도록 "비주얼 레이어" 추상화 API가 DirectX API에서 충분히 멀리 제거되었습니까? (출처가 공개되면 이 질문에 대한 답을 얻을 수 있을 거라 확신하지만 궁금합니다.)

우리는 현재 시각 계층에 대한 이식성에 초점을 맞추지 않고 있습니다. Visual 계층과 DirectX API(구현 제외) 사이에 약간의 느슨한 결합이 있지만 대부분 추상화되어 있습니다. 또한 오픈 소스에 대해 명확히 하기 위해: 오픈 소싱 코드 및 일상적인 개발 프로세스에 대한 초기 목표는 Xaml 프레임워크이며, 현재로서는 공개 소싱 시각적 계층을 포함하지 않습니다.

소프트웨어 래스터화에 대한 내 질문은 다음과 같은 것이었습니다. WinUI 3.0은 전체 소프트웨어 렌더링(단순한 텍스트 렌더링 또는 기타 기능이 아닌)을 지원합니까? 때로는 화면 공유 소프트웨어에 GPU 가속 앱(최소한 D3D9/WPF 사용)에 문제가 있고 소프트웨어 렌더링을 강제 실행하면 이러한 상황에서 문제가 해결됩니다. 또는 앱이 하드웨어 GPU가 없는 VM에서 실행되는 경우.

예, 화면 공유를 통한 렌더링, VM 등에서 모두 작동해야 합니다. 대부분의 콘텐츠에는 눈에 띄는 차이가 없어야 합니다. 리포지토리에서 WinUI 2 코드를 살펴보면 특정 효과가 런타임에 지원/"빠른"지 여부를 쿼리하고 경우에 따라 특정 효과의 더 간단한 렌더링으로 대체하는 데 사용하는 API 사용을 볼 수도 있지만 앱은 다음과 같아야 합니다. 기본 플랫폼 컨트롤 및 기능을 사용할 때 소프트웨어 렌더링을 지원하기 위해 특별한 작업을 수행할 필요가 없습니다.

여기에 전적으로 동의합니다. 하지만 당신은 기능과 버그의 차이를 이해해야합니다. Microsoft의 리소스/인력 측면에서만 생각하고 계신 것 같아 걱정됩니다. 그러나 앱 개발자가 컨트롤의 버그를 해결하기 위해 수많은 시간을 낭비한다고 생각한 적이 있습니까? 이러한 문제를 소스에서 수정하는 것이 훨씬 더 효율적이며 플랫폼/도구에 대한 인식에도 실제로 도움이 됩니다.

100% 동의 - UWP/WinRT의 버그를 해결하는 데 몇 시간을 소비했는지 기억하고 싶지도 않습니다.

제시,

저는 주로 엔터프라이즈 애플리케이션 개발에 관심이 있습니다. 저는 현재 WinUI 3.0 Alpha를 사용하여 Xaml, GPRC, 다중 창 및 진정한 다중 스레딩이 비즈니스 및 비즈니스 사용자에게 보다 생산적인 애플리케이션 경험을 제공할 수 있는 방법을 보여주기 위한 개념 증명을 구축하고 있습니다.

왜요? 브라우저 기반/작은 화면 애플리케이션에 대한 대안이 필요하기 때문입니다. 그 주제에 대해 더 할 말이 많지만 여기에서 KISS를 하려고 합니다.

WinUI 팀과 실제로 Microsoft에서 바라는 것은 비즈니스용 데스크톱 앱 구축을 수용하고 지원하는 것입니다.

웹 앱이 기업에서 빠르게 채택된 세 가지 주요 이유가 있습니다. 플랫폼 간 지원, 보안 및 배포 용이성 실행 가능한 대안이 되기 위해서는 데스크톱 앱이 이러한 질문에 대한 답변이 필요합니다.

대부분의 소프트웨어 개발 산업은 브라우저 및/또는 모바일/태블릿 폼 팩터용 애플리케이션 제공에 중점을 두고 있는 것 같습니다.

엔터프라이즈 애플리케이션은 "모바일 우선" 애플리케이션과 비교할 때 CPU, 화면 크기, 메모리, 스토리지, 그래픽 및 대역폭이 많은 워크스테이션에서 실행됩니다. 이러한 LOB 응용 프로그램의 사용자는 한 번에 몇 시간씩 참여할 수 있습니다. 이러한 요소를 해결하려면 앱 디자인 지침이 필요합니다.

엔터프라이즈 애플리케이션에는 많은 논의가 이루어지지 않는 다른 차원인 수명과 기술이 있습니다. 여기에서도 할 말이 많지만 요약하겠습니다. 기업은 애플리케이션 구축에 돈을 투자하고 해당 애플리케이션을 "오래" 사용할 계획입니다. 이는 기본 기술이 수십 년 동안 지원되어야 함을 의미합니다. WinUI가 Win32/MFC 및 WinForms를 대체할 차세대 기술이 되었으면 합니다.

IT 부서는 적절한 기술을 갖춘 SE를 찾는 데 끊임없이 어려움을 겪고 있습니다. 웹 기술은 이것을 더욱 어렵게 만들었습니다. 데스크톱 앱 구축에 중점을 둔 새로운 스택 C#, Xaml 및 SQL(C#XS)을 보고 싶습니다.

스타일링과 관련하여 하고 싶은 소소한 포인트도 있다. WinUI 엔터프라이즈 응용 프로그램이 작동하려면 "즉시 사용 가능한" 최소한의 스타일이 필요합니다. 또한 이것은 Fluent에서 직접 지시될 ​​수 있지만 컨트롤(스크롤 막대와 같은)을 숨기지 마십시오. 비즈니스 사용자는 화면의 실제 상태가 충분하고 페이지에 더 많은 것이 있다는 것을 모르는 경우 UI가 얼마나 "멋진"지는 신경 쓰지 않습니다.

강력한(무료) 데이터 그리드 제어가 필요합니다. 충분히 강조할 수 없습니다.

관심이 있으시면 공유할 아이디어가 더 있지만 여기에서 멈추고 요약하겠습니다.

• Microsoft는 포괄적인 데스크톱 응용 프로그램 개발 솔루션을 제공해야 합니다.
• WinUI/Fluent는 기능/양식, 데스크톱용 UX, 다중 창을 보여주는 코드 샘플/프로젝트 템플릿, 진정한 멀티 스레딩, 데이터 유효성 검사, "양식과 유사한" 페이지와 같은 비즈니스 사용자의 요구 사항을 해결해야 합니다.
• Microsoft는 생산성이 높고 수명이 긴 비즈니스 LOB 응용 프로그램을 구축하기 위해 WinUI를 제공하고 있음을 분명히 해야 합니다. 또한 .Net 5 + WinUI가 또 다른 DLL 지옥이 아닌 이유.
• WinUI가 Win32/MFC 및 WinForms를 대체한다는 점을 분명히 하십시오.
• C#XS를 IT를 위한 기술 세트로 푸시합니다.
• (무료) 데이터 그리드

도움이 되셨기를 바랍니다.

@roblo 편히 쉬세요 - 토론이 필요 없습니다! 🙂 나는 초기 코멘트에서 이 오류를 수정하기로 약속했으며 여전히 유효합니다. 저도 계속 일반화를 해서 더 일찍 실수를 한 것 같아요. 당신이 나열한 버그에 대해 이야기합시다. 우리의 주요 휴가 직전에 두 건이 접수되었고( @teaP에 대해서는 말할 수 없지만 12월 대부분은 오프라인 상태였습니다) 엔지니어링 측면에서 관리 변경을 거쳤습니다(@ranjeshj 축하합니다!). 변명의 여지가 없으며 이러한 변경 및 부재 기간 동안 이 두 가지 버그에 대해 보다 신속하게 처리하지 못한 점에 대해 사과드립니다. 여기에 나열된 다른 사람들은 모두 지난 10일 이내에 제출되었습니다.

특히 NumberBox가 범인이고 이러한 것들이 쌓여가고 있다는 점을 지적하는 것은 우리의 시간을 전략적으로 관리하는 데 도움이 되므로 이를 볼 수 있도록 도와주셔서 감사 합니다 . 다음 주 초에 NumberBox 개발자 @teaP 및 (새로 명명된) 엔지니어링 관리자 @ranjesh 와 함께 뛰어난 NumberBox 버그 목록을 검토하여 최대한 빨리 일괄적으로 해결할 수 있는 시간을 예약했습니다.

@SavoySchuler 감사합니다!

@SavoySchuler , 다음 중에서 선택하기 어려운 위치에 있는 것 같습니다.

a) WinUI 2.x 버그 수정 및 WinUI 3.0 출시 연기
또는
b) WinUI 2.x를 커뮤니티에 남겨두고 WinUI 3.0에 내부 리소스를 할당하여 가장 빠른 릴리스 날짜를 달성합니다.

많은 기존 WinUI 2.x 사용자가 현재 영향을 받고 있는 버그를 먼저 수정하기를 원할 것이라고 생각합니다. 그러나 충분한 리소스( WinUI 3.0이 2.x에 대한 추가 수정 사항을 제공한다고 가정).

개인적으로 저는 WinUI 3.0 릴리스가 지연되는 것을 원하지 않으며 커뮤니티가 WinUI 2.x(결국 오픈 소스임)에서 중요한 문제를 해결하는 데 참여하는 것이 합리적이라고 생각합니다. 어떤 사람들은 그것이 마이크로소프트의 프로젝트이기 때문에 모든 일을 해야 한다는 기대를 가지고 있습니다. 불행히도 그것은 현실적이지 않으며 다른 오픈 소스 프로젝트가 작동하는 방식도 아닙니다.

@jesbis , WinUI 3.0과 관련하여 Visual Layer에 대해 흥미롭게 듣습니다. 초기 릴리스의 경우 WinUI 3.0이 Windows.UI.Composition 클래스에 종속된다는 말씀이신가요? WinUI 3.0으로 추출하기 전에 Visual Layer를 지원하기 위해 OS에 더 많은 기능을 추가할 가능성이 있습니까?

참고로 제가 관심 있는 분야는 다음과 같습니다.

• Win32 "AppContainer" 모델. 우리는 다른 OS에서 완전히 샌드박스 호환되지만 "최신" API에 액세스하고 싶습니다.
• 비주얼 레이어( Windows|Microsoft.UI.Composition )
• 비주얼 레이어의 DXGI 스왑 체인 / SwapChainPanel
• 창 관리 API(AppWindow 등)

@infoequipt 자세한 정보 감사합니다! 확실히 도움이됩니다. 가시성을 위한 @marb2000

WinUI 3.0과 관련하여 Visual Layer에 대해 듣는 것은 흥미롭습니다. 초기 릴리스의 경우 WinUI 3.0이 Windows.UI.Composition 클래스에 종속된다는 말씀이신가요?

@MarkIngramUK 아니요, 혼란을 드려 죄송합니다. 이전 요점은 오픈 소싱에 관한 것이었습니다.

Microsoft.UI.Composition은 WinUI 3의 일부가 되며 Microsoft.UI.Xaml은 이에 종속됩니다. 그것은 이미 WinUI 3 Alpha의 경우입니다.

우리는 Xaml을 오픈 소싱하기 위해 노력하고 있습니다. 즉, Xaml 프레임워크 코드가 이 리포지토리에 있고 엔지니어링 팀이 앞으로 GitHub의 Xaml에 대해 하루 종일 작업을 할 것입니다. 그러나 Xaml이 의존하는 Microsoft.UI.Composition 패키지는 여전히 내부적으로 개발되고 바이너리 형식으로만 업데이트됩니다.

@jebis 에 대한 설명 감사합니다. 이를 위해 어떤 배포 방법을 사용할 것입니까? 우리는 플랫폼 간 앱이므로 CMake를 사용하고 Windows.UI.Composition에 종속되어 있으므로 새 dll, lib, 헤더 등을 쉽게 가져올 수 있는 방법을 원합니다.

OS에서 Visual Layer를 추출할 때 성능에 영향이 있습니까? 즉, Visual Layer에만 의존한다면 새 라이브러리로 업데이트할 때 단점이 있습니까?

궁극적으로 Microsoft.UI.Composition을 공개할 계획이 있습니까?

@MarkIngramUK 나는 당신이 말하는 것과 @SavoySchuler 가 '큰 그림' 관점에서 말하는 것에 대체로 동의합니다. 당신이 지적했듯이, 우리는 현재 프로덕션 앱을 가지고 있기 때문에 WinUI 2.0 사용자가 버그를 받아들이기가 더 어렵습니다. WinUI 3.0을 지연시키지 않는 몇 가지 버그를 수정하는 것과 WinUI 3.0을 정상 상태로 유지하는 것 사이에서 타협점을 찾아야 합니다. NumberBox가 즉시 무시된 것처럼 보이는 완전히 새로운 컨트롤이라는 추가적인 좌절감이 있었습니다. Microsoft가 1년 이상 이를 다시 사용하지 않을 것이라는 의견도 있었습니다. 그럼에도 불구하고, 나는 WinUI 3.0이 우선순위라는 데 확실히 동의하며, 그것이 상당한 용량으로 지연되는 것을 원하지 않을 것입니다.

저는 Microsoft가 여기에서 하고 있는 모든 작업과 더 투명하고 방향에 대해 의사 소통하기 위한 노력에 감사한다고 말해야 할 것 같습니다.

이를 위해 어떤 배포 방법을 사용할 것입니까? 우리는 플랫폼 간 앱이므로 CMake를 사용하고 Windows.UI.Composition에 종속되어 있으므로 새 dll, lib, 헤더 등을 쉽게 가져올 수 있는 방법을 원합니다.

@MarkIngramUK 가 NuGet 패키지를 사용하면 효과가 있습니까? 즉, 우리가 WinUI 2.x 및 WinUI 3 Alpha로 무엇을 하고 있는지입니다. 우리는 여전히 Visual Studio 팀과 일부 배포 세부 사항을 작업 중입니다. 현재 WinUI 3 Alpha는 1개의 패키지에 Xaml 및 Composition 바이너리를 모두 포함하지만 오픈 소스 Xaml을 지원하고 Xaml을 별도로 빌드할 수 있도록 분리할 것입니다.

OS에서 Visual Layer를 추출할 때 성능에 영향이 있습니까? 즉, Visual Layer에만 의존한다면 새 라이브러리로 업데이트할 때 단점이 있습니까?

계속 지켜봐 주세요 🙂 성능 벤치마킹 및 작업은 올해 후반에 대한 로드맵에 있으므로 숫자를 갖기에는 너무 이릅니다.

궁극적으로 Microsoft.UI.Composition을 공개할 계획이 있습니까?

잠재적으로 고려할 백로그에 있지만 계획이 없습니다.

@MarkIngramUK 질문할 수 있다면: 오픈 소스를 통해 얻을 수 있는 이점은 무엇입니까?

구성 및 렌더링 코드는 다소 난해할 수 있으므로 사람들이 실제로 기여하거나 참조로 사용하는 데 관심이 있는지 궁금합니다.

현재 프로덕션 앱이 있기 때문에 WinUI 2.0 사용자가 버그를 받아들이는 것이 더 어렵습니다. WinUI 3.0을 지연시키지 않는 몇 가지 버그를 수정하는 것과 WinUI 3.0을 정상 상태로 유지하는 것 사이에서 타협점을 찾아야 합니다. NumberBox가 즉시 무시된 것처럼 보이는 완전히 새로운 컨트롤이라는 추가적인 좌절감이 있었습니다. Microsoft가 1년 이상 이를 다시 사용하지 않을 것이라는 의견도 있었습니다. 그럼에도 불구하고, 나는 WinUI 3.0이 우선순위라는 데 확실히 동의하며, 그것이 상당한 용량으로 지연되는 것을 원하지 않을 것입니다.
저는 Microsoft가 여기에서 하고 있는 모든 작업과 더 투명하고 방향에 대해 의사 소통하기 위한 노력에 감사한다고 말해야 할 것 같습니다.

@roblo 감사합니다! 우리는 정말로 투명하기 위해 노력하고 있으며 그것이 가치 있다는 것을 아는 것이 좋습니다 🙂

Savoy가 언급한 것을 반복하기 위해 WinUI 2.x에서 작업하는 개발자가 있으므로(PR 로그에서도 볼 수 있음) 우리는 여전히 WinUI 2와 3 모두에 병렬로 투자하고 있습니다. 리소스는 WinUI 3에 있습니다. 저는 특히 약간의 주의가 필요한 NumberBox에 대해 동의하며 Xaml 컨트롤 개발 리드가 지금 조사하고 있습니다.

@roblo 당신은 최고입니다! 😄 다시 한 번 혼란을 드려 죄송합니다. 언급된 ~1년 지연의 대상은 3.0으로 예정된 전체 입력 유효성 검사 작업 에서 차단되었기 때문에 NumberBox의 추가 입력 유효성 검사 모드 뿐입니다. 그렇지 않으면 @teaP , @ranjeshj , 그리고 저는 다음 주부터 NumberBox 버그 목록에 올라갑니다. 🙂

@jebis 가 다른 모든 것을 다루었다고 생각합니다!

@제스비스 ,

@MarkIngramUK 가 NuGet 패키지를 사용하면 효과가 있습니까? 즉, 우리가 WinUI 2.x 및 WinUI 3 Alpha로 무엇을 하고 있는지입니다. 우리는 여전히 Visual Studio 팀과 일부 배포 세부 사항을 작업 중입니다. 현재 WinUI 3 Alpha는 1개의 패키지에 Xaml 및 Composition 바이너리를 모두 포함하지만 오픈 소스 Xaml을 지원하고 Xaml을 별도로 빌드할 수 있도록 분리할 것입니다.

솔직히 말해서, 저는 NuGet에 익숙하지 않지만 이 SO 답변 을 보면 CMake를 사용하여 VS 프로젝트 파일을 생성하는 경우에만 작동하는 것으로 보입니다. 이는 일반적으로 작동하는 방식이 아닙니다(일반적으로 폴더 열기 , 생성기로 Ninja를 사용함). vcpkg 도 사용할 수 있으므로 소스를 제공할 수 없다는 것은 유감입니다. 참고로 우리는 소스에서 모든 라이브러리를 빌드합니다(특히 Windows에서도 Clang/LLVM으로 빌드하는 경우 잠재적인 ABI 문제를 피할 수 있음).

궁극적으로 Microsoft.UI.Composition을 공개할 계획이 있습니까?

잠재적으로 고려할 백로그에 있지만 계획이 없습니다.

나는 이것에 관심이 있으므로, 그런 일이 발생하면 토론에 참여하고 싶습니다.

@MarkIngramUK 질문할 수 있다면: 오픈 소스를 통해 얻을 수 있는 이점은 무엇입니까?

구성 및 렌더링 코드는 다소 난해할 수 있으므로 사람들이 실제로 기여하거나 참조로 사용하는 데 관심이 있는지 궁금합니다.

초기 생각은 기여/확장되고 있습니다(이전에 언급했듯이 Xaml Framework/UWP가 아닌 Windows.UI.Composition에 대한 종속성이 있음). 플랫폼은 흥미로울 수 있지만 저는 말 그대로 30초 동안만 고려했습니다. 또한 오픈 소싱은 몇 년 안에 Microsoft에서 결국 포기하게 될 또 다른 프레임워크를 채택해야 하는 골치 아픈 걱정을 덜어줄 것입니다. , 당신은 내가 여기에서 오는 곳을 볼 수 있습니다 ...).

넘버박스

안녕하세요 여러분! @teaP , @ranjeshj , 그리고 저는 오늘 열려 있는 모든 NumberBox 항목을 살펴보았습니다.

• 우리는 이미 몇 개를 닫았습니다.
• @teaP 는 더 많은 것에 대한 결합된 PR 을 제출했습니다( 여기에서 레이블 필터링 ).
• 나머지(#1721 제외)에 대한 조치가 결정되었으며 최대한 빨리 수정 사항에 응답할 것입니다. #1721 앞으로 최선의 경로를 진단하려면 더 많은 작업이 필요합니다. 이 문제를 해결하기 위해 계속 노력할 것입니다.

우리와 함께 일하는 모든 사람에게 감사합니다. 🙂 우리 ❤️ WinUI!

WinUI 커뮤니티 호출에 대한 "캘린더"가 있습니까? 예: 통화 세부정보의 자동 업데이트를 위해 live/google/* 캘린더에 추가/통합할 수 있는 공개 캘린더 형식입니다.

YouTube 이벤트는 미리 예정되어 있으므로 여기 " 예정된 실시간 스트림"에서 Google 알림을 추가할 수 있습니다.

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

우리는 또한 .ics 캘린더 초대를 받았지만 일부 사람들에게 문제를 일으키고 있었고 업데이트할 방법이 없었기 때문에 지금은 그것을 포기했습니다.