Microsoft-ui-xaml: 👩‍💻📞 WinUI 커뮤니티 콜 (2020년 2월 19일)

Windows 10X 개발에 관해 질문이 있습니다. 이를 위해 개발하려면 에뮬레이터가 필요합니다. 언제 AMD 프로세서(중첩 가상화)가 지원됩니까? Windows 10 2003 버전을 믿을 수 있습니까?

#1958을 기반으로 한 WinUI 관련, Live Tiles의 미래는?

AMD Ryzen 지원으로 인해 에뮬레이터를 실행할 수 없으므로 언제 수정될지에 대한 소식을 듣는 것이 좋습니다.

@jp-weber @mdtauk

이것은 공식 문구입니다(https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools).

AMD 프로세서는 현재 지원되지 않습니다. 에뮬레이터에서 Windows 10X를 실행하려면 중첩 가상화가 필요하며 Windows는 아직 AMD 프로세서에서 이를 지원하지 않습니다. 계속 지켜봐 주세요!

더 자세한 정보를 원하시면 [email protected]에 문의

@Felix-Dev에게 감사드립니다. 맞습니다. 문서는 10X 에뮬레이터의 최신 상태를 얻을 수 있는 가장 좋은 장소이며 해당 이메일 주소는 WinUI와 관련이 없는 다른 10X 질문에 대한 가장 좋은 연락처입니다.

공평하게, 마이크로소프트가 그것에 대해 이야기할 준비가 될 때까지 기다려야 할 것이다.

Windows 10X에서 Win32 앱은 VEIL 컨테이너에서 실행됩니다. UWP가 아닌 WinUI 3.0 앱은 어떻습니까?

기본 UWP 앱이 10X에서 실행되는 것처럼 표시되나요?

@mdtauk WinUI 데스크톱 앱은 기본 UWP 앱이

또한 앞으로 WinUI 앱 격리에 대한 계획이 무엇인지 알고 싶습니다. 엔터프라이즈 관점에서 우리는 격리/샌드박싱 및 기능 제어(사용자 옵트인 아님)가 필요합니다. 그래서 미구엘을 위한 주제로 공개합니다..

@mdtauk WinUI 데스크톱 앱은 기본 UWP 앱이

조금 실망스럽습니다. Win32 앱은 다른 창 동작을 나타내는 것으로 보이며 전경에 있을 때 화면을 어둡게 합니다. 따라서 전환도 다르게 작동합니다.

Xaml UI를 사용하여 WinUI 데스크톱 앱이 최소한 사용자에게 표면적으로는 두 가지 시나리오 모두에서 최고가 되기를 바랍니다.

@mdtauk 우리에게 출시된 현재 10X 에뮬레이터 이미지는 아직 매우 초기 단계이기 때문에 당신이 알아차린 문제/동작(내 테스트에서도 마찬가지)이 출시될 때까지 해결/변경될 것이라고 확신합니다(즉, 지금 로드할 수 없음).

즉, 10X의 WinUI 데스크톱 앱 컨테이너에서 수정하게 되어 기쁩니다. 내 현재 생각은 지금까지 WinUI 데스크톱(Win32 앱 모델), 10X 프레젠테이션 How Windows 10X runs UWP and Win32 apps 및 데스크톱 브리지 테스트 앱에 대해 들었던 내용을 기반으로 합니다. 불행히도 내 XAML Island 테스트 앱은 현재 에뮬레이터에서 로드되지 않으므로( App Launch Initialized 단계에서 멈춤) 어떤 컨테이너를 사용할지 확인할 수 없습니다. 여전히 Win32 앱이기 때문에 Win32 컨테이너가 아니라면 놀랄 것입니다. 이 모든 것이 WinUI 데스크톱 앱이 10X의 Win32 컨테이너에서 실행될 것이라고 믿게 만듭니다.

그것은 확실히 팀에게 물어보는 좋은 질문입니다!

@Felix-Dev가 언급한 동일한 비디오(Windows 10X가 UWP 및 Win32 앱을 실행하는 방법)에 따르면 20:18분에 하이브리드 앱(Win32/UWP)이 지원되지 않는다고(아직?) 내 이해는 다음과 같은 앱입니다. XAML Island를 사용하는 하이브리드 앱입니다.

Q1) SwapchainPanel은 언제 WinUI에서 사용할 수 있습니까? 이것은 나와 다른 많은 사람들이 하는 일에 절대적으로 필요합니다.

Q2) SharpDX는 제작자가 더 이상 지원하지 않기 때문에 Microsoft는 SharpDX와 WinUI의 하드웨어 렌더링 표면 간의 호환성을 강화하고 제공할 예정입니까? MS는 SharpDX 없이 C#으로 하드웨어 렌더링을 한다는 이야기도 봅니까? 그리고 저는 Unity에 대해 관심이 없습니다. 즉, C#에서 자체 그래픽 도구, 엔진 및 Unity가 아닌 게임을 만들기 위한 자유로운 형식의 그래픽 개발을 의미합니다. 또한 Win2d를 의미하는 것이 아니라 전체 하드웨어 렌더링 기능(DirectX)이 필요합니다.

Q3) 응용 프로그램에서 마우스를 화면의 위쪽 및 아래쪽 가장자리로 이동할 때 작업 표시줄 및 제목 표시줄 팝업을 끄는 기능이 없습니다. 이것은 카메라 팬 또는 팝업과 같은 작업을 위해 자체 UI에서 화면 가장자리를 활용하는 많은 게임(및 일부 앱)에 대한 거래 차단기입니다. 이 문제는 언제 수정될 예정입니까(Windows 문제일 수 있지만 API로 구동해야 하므로 WinUI와 관련됨).

Q4) Xaml을 우회하고 창 바인딩된 Swapchain에 직접 렌더링하려는 경우에 대해 CoreWindow(IFrameworkView) 앱 모델을 포함하도록 WinUI를 얻을 수 있습니까?

WinUI가 Xaml이 아닌 표면을 제공하도록 요청하는 것이 약간 이상하게 들릴 수 있습니다. 그러나 CoreWindow는 동일한 라이브러리의 XamlWindow(UWP에서는 Window라고 함)에 속하며 .net 5에서 사용할 수 있도록 UWP와도 분리되어 있다고 생각합니다. .net 5가 uwp뿐만 아니라 비 uwp도 대상으로 지정할 수 있다고 가정합니다. 현재 UWP 외부에는 최신 C++ 애플리케이션 모델이 없습니다. 게임 개발자는 레거시 C 코드(Win32)를 사용하여 게임 또는 그래픽 앱용 애플리케이션 계층을 작성해야 합니다. .net 코어에는 최신 데스크탑 애플리케이션 모델도 없습니다. CoreWindow용 UWP 솔루션은 효과적이고 사용하기 쉽습니다. UWP 외부에 존재하기만 하면 됩니다(C++/비 uwp 및 .net 5 모두). UWP에서 CoreWindow를 가져오는 또 다른 이점은 UWP에서 .net 5(및 uwp가 아닌 최신 응용 프로그램 모델이 있는 경우 C++)로 코드를 직접 이식하는 방법을 제공한다는 것입니다.

게임 개발자는 창 동작이 변경되고 배포 스토리가 정렬될 때까지 UWP를 사용할 수 없습니다. 너무 오래되어서 Microsoft가 문제를 이해하지 못하는 것처럼 보입니다. 따라서 이러한 API를 UWP 외부로 가져와야 합니다. UWP가 수정되었다면 그럴 필요가 없었을 것입니다.

그리고 1215 호의 추가 논평

비포함/비Xaml 시나리오에 대해 Win32 창을 CoreWindow로 바꾸고 CoreWindow를 .Net 5 비 UWP에 제공하면 비 Xaml 작업을 위해 Windows 전체에서 통합된 앱/창 모델을 가질 수 있습니다. 그것은 Win32 FOR EVER를 유지하거나 새로운 앱 모델을 만드는 것보다 더 합리적입니다.

포함된 실행과 포함되지 않은 실행(예: UWP와 Win32 간)을 전환하기 위해 애플리케이션 계층을 다시 작성해야 하는 이유 - 오늘날 게임 개발자가 직면한 일반적인 문제입니다. UWP에 커밋할 수 없기 때문입니다. Win32 배포 자유가 필요합니다. 그래서 그들은 HWnd 또는 .Net Framework 앱 모델을 강제로 사용합니다. UWP 앱/창 모델을 uwp가 포함되지 않은 앱에 사용할 수 있게 된 경우 문제가 없습니다. 애플리케이션 계층에 대해 동일한 코드를 작성하고 동일한 코드 기반에서 MS 스토어와 다른 스토어 모두에 대해 컴파일할 수 있습니다.

@leoniDEV 이 중 대부분은 "하이브리드 앱"이 정확히 무엇을 의미하는지 여전히 추측입니다. 예를 들어 XAML Island 앱이 해당 범주에 속하지 않는다는 이 트위터 스레드 를 참조하십시오(Matteo Pagani는 Microsoft에서 Windows AppConsult Engineer 로 근무합니다). UWP 커뮤니티 의 MS 직원은 Win32 완전 신뢰 프로세스를 실행하는 UWP 앱에 대한 지원이 하루 만에 지원되지는 않지만 나중에 추가될 예정이라고 말했습니다.

@Gavin-Williams WinUI에는 WinUI UWP와 WinUI Desktop의 두 가지 버전이 있습니다. WinUI UWP를 사용하면 Windows 10X의 UWP 컨테이너에서 실행되는 전체 UWP 앱을 만들 수 있습니다. 그런 다음 Win32 앱이 UWP UI API(XAML, 구성, 입력,... - CoreWindow 와 같은 몇 가지 API 제외)에 대한 전체 액세스 권한을 가질 수 있도록 하는 WinUI 데스크톱이 있습니다. 이러한 유형의 앱은 UWP 샌드박스 또는 UWP의 기타 디자인 제한을 처리할 필요가 없습니다. 그러나 UWP 앱이 아니므로 WinUI 데스크톱 앱은 UWP 앱이 할 수 있는 광범위한 Windows 10 장치 범주를 대상으로 지정할 수 없습니다.
좋은 개요는 WinUI 로드맵 에서 가져온 아래 이미지를 참조하십시오.

WinUI는 처음부터 C++로 작성되었으므로 관리되지 않는 앱 컨텍스트에서 사용할 수 있습니다.

위에서 강조했듯이 I believe they will run in the mentioned Win32 container 은 순수하게 WinUI Desktop, 10X에서 실행한 10X 비디오 및 데스크탑 브리지 테스트 앱에 대한 현재의 이해를 기반으로 합니다. 내부 지식이 없습니다. WinUI 팀은 WinUI 데스크톱 앱과 사용된 10X 컨테이너에 대한 계획이 무엇인지 확실히 알려줄 것이며 여기서 수정하게 되어 기쁩니다. 예, WinUI 데스크톱 앱은 10X의 UWP 컨테이너에서 실행됩니다.

WinUI/Microsoft UI를 사용하여 앱을 빌드할 때 Java, Python, JavaScript 등과 같은 다른 프로그래밍 언어를 잠재적으로 사용할 수 있다는 생각에 대해 더 듣고 싶습니다.

Xlang(cross-lang)이라는 프로젝트가 있다는 것을 알고 있습니다. 이는 본질적으로 .NET이 더 나은 COM이어야 하는 것처럼 보입니다.

WinUI와 어떤 관련이 있습니까?

xlang은 기본적으로 WinRT(Windows 런타임)의 플랫폼 간 오픈 소스 버전이지만 완전히 호환되지는 않습니다. WinRT의 목적은 말씀하신 대로 언어 간의 상호 운용성이며 COM을 기반으로 합니다. WinUI의 API는 C++와 C#을 모두 지원하는 WinRT를 기반으로 합니다. Python , Rust (이것은 내가 개인적으로 작업한 언어) 및 JavaScript를 포함하여 WinRT에 대한 다양한 수준의 지원을 제공하는 다른 언어가 있지만 (아직) WinUI를 지원하지 않는 언어가 있는 한 WinUI 지원은 특히 어렵습니다. 컴포지션 및 XAML API는 다른 WinRT 및 UWP API가 사용하지 않고 다른 언어의 형식 시스템에 매핑하기 까다로울 수 있는 구성 가능한 형식(기본적으로 구현 상속의 한 형태)이라는 형식 시스템 기능에 크게 의존하기 때문입니다.
C++/WinRT의 창시자인 Kenny Kerr는 현재 새로운 Rust WinRT 프로젝션을 작업 중입니다.

저는 사실 최근에 Rust가 구성 가능한 유형(및 WinUI)을 가장 잘 지원할 수 있는 방법에 대해 많이 생각했습니다. 확실히 가능하지만 개발자에게 얼마나 자연스럽게 느낄 수 있는지 아직 확실하지 않습니다. 기본적으로 누군가가 프로젝션을 만드는 작업을 하면 모든 언어가 WinRT를 지원할 수 있어야 하지만 언어의 디자인에 따라 WinRT 유형 시스템 구성을 언어의 유형 시스템에 매핑하는 것이 때때로 어려울 수 있습니다. 자연스럽게 느껴진다.

xlang은 나에게 죽은 것처럼 보입니다. C++/WinRT는 실제로 완성된 적이 없습니다. 버그와 매우 이상한 사용 사례가 남아 있어 일반 개발자에게는 바람직하지 않습니다. 나는 C++/WinRT를 작동시키기 위해 많은 시간 동안 고군분투했고 C++/CX로 30분 만에 했던 일을 하지 못했습니다. 그리고 C++/CX는 장기적으로 사용하기 더 쉬웠습니다. Microsoft가 Average Joe가 이러한 교차 언어 도구를 사용하기를 원하면 문제에 팀을 배치해야 하며 Kenny Kerr가 모든 작업을 혼자 처리하도록 놔두어서는 안 됩니다. 그는 좋은 아이디어를 가지고 있습니다. 그러나 이러한 도구는 폭넓은 매력을 필요로 하며 이러한 제품을 완성하고 최대한 활용하려면 도움이 필요하다고 생각합니다.

현재 UWP 및 후속 제품인 WinUI는 LOB 응용 프로그램에 사용할 준비가 되지 않았습니다.

우리가 직면한 몇 가지 문제가 있습니다

• 성능이 좋지 않습니다. 예를 들어 WinUI 종속성 속성은 https://github.com/microsoft/microsoft-ui-xaml/issues/1633 보다 50배 느립니다.
• 컴파일 성능이 좋지 않습니다. wpf보다 몇 배 느림
• 닷넷 네이티브
• 릴리스 사이에 많은 주요 변경 사항이 있습니다.
• 샌드박싱 및 권한 모델
• wpf에 비해 타사 공급업체에 대한 제한된 사용자 지정 기능

WinUI가 이러한 한계를 극복하고 향후 10년 동안 차세대 LOB 지원 프레임워크가 될 수 있다고 생각하십니까? 또는 전자 블레이저 앱으로 이동할 때입니다)

WinUI의 현재 상태에 몇 가지 문제가 있습니다.

C++/WinRT는 C++/CX 도구 및 전반적인 개발자 경험에 비해 여전히 매우 열악한 개발자 경험입니다. C++로 작성된 WinUI 구성 요소를 처리할 것으로 예상되는 경우 C++/CX 도구가 할 수 있는 범위에 대해 최소한 1:1 적용 범위를 가질 것으로 예상됩니다.

C++/CX를 사용하는 것보다 생산성이 떨어지고 UWP 구성 요소나 XAML 기반 UI를 작성하는 데 두 배의 시간이 걸린다면 표준 C++17이 되는 것은 아무 소용이 없습니다.

UWP/WinUI에서 C++를 다루어야 하는 주된 이유인 두 번째 질문으로 이어지는 것은 Microsoft가 .NET 언어에 대한 모든 종류의 DirectX 바인딩에서 공을 놓쳤기 때문입니다. 그렇다면 WinUI는 대체 또는 WPF 3D 장면 그래프와 같은 XNA에 대한 지원을 제공할 것입니까? 분명히 우리는 여기에서 라디오 침묵을 얻었고 MonoGame과 같은 커뮤니티 프로젝트 또는 Unity와 같은 완전한 엔진에 강제로 참여해야 합니다.

Win2D가 마침내 WinUI의 일부가 되는 시기는 언제입니까? 현재로서는 불확실한 미래와 함께 유지 보수 모드에 있는 것으로 보입니다.

현재 내 비누 상자 주변의 청취자가 계속 줄어들면서 UWP 꿈을 계속 판매하는 것이 매우 어려워지고 있습니다.

Windows 10X UI 요소는 언제 데스크톱 Windows 10에 적용됩니까?

@carmellolb 2022-2025?

편집: MS는 아마도 이것을 삭제할 것입니다. 존재하지 않고 따라서 오해의 소지가 있는 제품 배송 일정을 제안하기 때문입니다 ;)

@Felix-Dev "WinUI Desktop ..을 사용하면 Win32 앱이 CoreWindow와 같은 몇 가지 API를 제외하고 UWP UI API에 대한 전체 액세스 권한을 가질 수 있습니다.

CoreWindow 제외? OMG - UWP에서 제거해야 하는 첫 번째이자 가장 중요한 API입니다. 기본 창 기능을 제공하는 가장 기본적인 API입니다. UWP 컨테이너 내부 및 외부에서 보편적이어야 합니다. 그것이 나올 때까지 우리는 응용 프로그램 계층에 대한 공통 코드 기반을 가질 수 없으며 C++의 레거시 Win32 c 코드 또는 C#에 대해 .net 코어가 제공할 모든 것(또 다른 Window 클래스?)에 갇혀 있습니다.

Microsoft를 사용하세요. UWP 안팎에서 XamlWindow를 제공하는 것처럼 UWP 안팎에서 CoreWindow도 제공하세요.

통화 정보: Teams에서 멀어진 이유는 무엇인가요? YouTube는 마지막에 그렇게 잘 작동하지 않았습니다.

@Gavin-Williams

https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216에서:

우리의 접근 방식은 WinUI 3가 UWP에서 실행할 때 CoreWindow를 사용하고 데스크톱(Win32)에서 실행할 때 Win32 Window(HWind)를 사용한다는 것입니다.

UWP 앱의 WinUI 3은 AppWindow API를 사용할 수 있습니다. Desktop의 경우 비슷한 것이 나와야 합니다. 우리는 여전히 이것을 설계하고 있으므로 지금까지 자세한 내용이 없습니다.

이 팀은 또한 같은 API를 제공하기 위해 찾고 말했다 CoreApplicationViewTitleBar.ExtendViewIntoTitleBar 우리는 두 세계의 최고 얻을 수있을 수 있도록뿐만 아니라 WinUI 데스크탑을. Win32 창 디자인(예: 제목 표시줄 없음/100% 사용자 지정 제목 표시줄, 앱 창 < 필요한 최소 크기, 작업 표시줄 버튼 없음 등) 및 새로운 최신 UWP 사용자 지정 API의 모든 기능. (UWP의 경우 AppWindow V2가 현재 Win32 윈도우 기능에 가까운 윈도우 기능을 가질 때까지 기다려야 합니다.)

@jesbis WinUI 데스크톱 관련 질문: https://github.com/microsoft/microsoft-ui-xaml/issues/1939 문제에서 (적어도) MSIX 패키지 데스크톱 앱에서 알림 활성화가 작동하지 않는다고 지적되었습니다. 문서에 언급된 1909년:

Desktop Bridge 앱의 경우 UWP 앱처럼 알림을 보내십시오. 사용자가 알림을 클릭하면 알림에서 지정한 시작 인수와 함께 앱이 명령줄에서 시작됩니다.

언급된 수정 사항이 데스크톱 브리지 앱의 영향을 받는 OS 버전으로 백포트되는지 확인하고 기다려야 하는 동안 내 질문은 다음과 같습니다. WinUI 데스크톱 앱이 위에 인용된 기본 토스트 활성화 기능을 제공합니까 COM Activator) 모든 WinUI 대상 Windows 10 버전에서? (또는 유사한 토스트 활성화 개념.)

@Felix-Dev 설명서에서 XAML Island는 하이브리드 앱을 엄격하게 의미하지 않는 것 같습니다. 이해하는 경우 사용자 지정 컨트롤 사용과 같은 일부 기능을 잃는 대신 Win32 앱에서 UWP XAML 호스팅 API를 직접 호출할 수 있습니다. 올바르게 문서(및 문서의 참고):

XAML 아일랜드를 사용하여 WPF 앱에서 표준 UWP 컨트롤 호스팅

필수 구성 요소

앱의 프로젝트 및 소스 코드입니다. WindowsXamlHost 컨트롤을 사용하여 표준 자사 UWP 컨트롤을 호스트하는 것은 .NET Framework 또는 .NET Core 3을 대상으로 하는 앱에서 지원됩니다.

XamlApplication 에서 파생되는 루트 Application 클래스를 정의하는 UWP 앱 프로젝트입니다 . WPF 또는 Windows Forms 프로젝트에는 Windows Community Toolkit에서 제공하는 Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication 클래스의 인스턴스에 대한 액세스 권한이 있어야 합니다. 이 개체는 애플리케이션의 현재 디렉터리에 있는 어셈블리의 사용자 지정 UWP XAML 형식에 대한 메타데이터를 로드하기 위한 루트 메타데이터 공급자 역할을 합니다.

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

나는 C++/WinRT를 작동시키기 위해 많은 시간 동안 고군분투했고 C++/CX로 30분 만에 했던 일을 하지 못했습니다.

C++로 작성된 WinUI 구성 요소를 처리할 것으로 예상되는 경우 C++/CX 도구가 할 수 있는 범위에 대해 최소한 1:1 적용 범위를 가질 것으로 예상됩니다.

@Gavin-Williams, @pjmlp 찾고 있는 문제에 대해 cppwinrt 리포지토리 에서 문제를 열었습니까? 아니면 이 리포지토리에서 문제를 열 ​​수 있는 WinUI 관련 문제입니까? 우리는 C++/WinRT 지원에 대해 적극적으로 노력하고 있으므로 잘 작동하지 않는 부분에 대한 세부 정보를 듣는 것이 좋습니다. 우리도 이를 사용하고 있습니다. 새로운 WinUI 기능은 모두 C++/WinRT에 있으며 이를 사용하는 앱(예: 계산기 )도 마찬가지입니다.

통화 정보: Teams에서 멀어진 이유는 무엇인가요? YouTube는 마지막에 그렇게 잘 작동하지 않았습니다.

오디오 문제를 의미한다면: 우리는 지난 달에 케이블이 불량했으며 내일은 더 나아지기를 바라고 있습니다. YouTube는 대부분의 사람들이 더 쉽게 접근할 수 있는 것 같았고 Channel9 스튜디오는 우리가 Teams에서 사용했던 회의실보다 훨씬 더 나은 오디오 및 비디오를 제공합니다.

RE: CoreWindow, win32 지원, 컨테이너 - 내일 커뮤니티 콜에서 @marb2000 과 함께 현재 방향에 대해 이야기

또한 지금까지의 다른 질문(예: SwapChainPanel 타임라인, Win2D/DirectX, 섬 등의 현재 상태)에 대해 알아보겠습니다. 지금까지 의견과 질문에 감사드립니다!

@jebis 다시

개발에 대한 C++/WinRT 접근 방식은 C++/CX가 제공하는 생산성에 완전히 뒤떨어지기 때문에 열어야 할 문제가 없습니다.

C++/CX를 사용하여 처음에는 Microsoft가 마침내 Visual C++를 올바른 방법으로 판매하고 있다고 생각했지만 25년 후 Visual C++는 C++ Builder의 RAD 경험을 따라 잡았습니다.

대신 C++/WinRT가 제공하는 것은 MIDL 상용구를 작성해야 하는 ATL/WTL 시절로 돌아가는 것입니다. MIDL 3.0이 원래 MIDL보다 다소 낫긴 하지만 C++/CX가 처리하는 UWP 바인딩 상용구를 수동으로 작성해야 합니다. 나.

C++/CX가 완벽하다는 것은 아니지만 이벤트 핸들러를 처리하는 방식은 여전히 ​​C#/VB.NET 또는 C++ Builder에 미치지 못합니다.

UWP는 어쨌든 Windows에 연결되어 있으므로 순수한 C++ 바인딩을 사용하는 것은 C++/Winrt를 구입하는 것이 아니라 C# 또는 VB.NET에서와 똑같은 작업을 수행할 수 있다는 것입니다. ATL/WTL.

그리고 언급했듯이 DirectX를 UWP 런타임 구성 요소 집합으로 노출하려는 호소가 계속 무시되기 때문에 저는 C++로만 바쁩니다.

따라서 cppwinrt에서 문제를 여는 것이 C++/CX만큼 쉽게 Blend 및 Visual Studio에서 C++/Winrt를 사용하는 기능을 향상시킬 것이라고 생각하지 않습니다. cppwinrt 팀이 Visual Studio 팀에 문제를 제기했고, 전통적으로(MFC/ATL/WTL) C++ 도구 팀은 다른 회사가 C++(Qt, 엠바카데로).

@pjmlp 세부 정보 감사합니다. C++/WinRT 도구에 대해 공유할 정보가 더 있는지 확인하기 위해 일부 사람들과 확인 중입니다. 하지만 내일까지 좋은 답변을 얻지 못할 수도 있습니다. 우리는 새로운 개발을 위해 C++/WinRT에 중점을 두고 있지만, 도움이된다면 WinUI 3용 C++/CX 템플릿도 포함하도록 로드맵에 있습니다.

또한 앞으로 WinUI 앱 격리에 대한 계획이 무엇인지 알고 싶습니다. 엔터프라이즈 관점에서 우리는 격리/샌드박싱 및 기능 제어(사용자 옵트인 아님)가 필요합니다. 그래서 미구엘을 위한 주제로 공개합니다..

@infoequipt 격리가 무엇을 의미하는지 자세히 AppContainer 지원과 같은가요?

현재 UWP 및 후속 제품인 WinUI는 LOB 응용 프로그램에 사용할 준비가 되지 않았습니다.

• 릴리스 사이에 많은 주요 변경 사항이 있습니다.

@Xarlot 어떤 주요 변경 사항으로 인해 문제가 발생했습니까? UWP API를 사용하여 릴리스마다 높은 수준의 호환성을 유지하려고 합니다.

에 관한 개빈 윌리엄 @ SharpDX 사용되지를, 당신은 보길 원하는 것일 수도 Vortice.Windows 그것에 대한 훌륭한 대안이다. @Aminator 는 현재 자신의 완전한 UWP/C#/XAML DX12 게임 엔진 및 편집기인 DX12GameEngine 있습니다.
귀하의 앱에서 귀하의 요구 사항에 적합하기를 바랍니다! 😄

통화에 대한 질문과 관련하여 사소한 세부 사항이 하나 있습니다. 그러나 우리가 진행하는 동안 WinUI 3으로 전환하여 다음과 같이 "중요한 변경 사항"으로 간주될 수 있는 작은 레거시 UI 버그를 수정할 수 있습니까? StackPanel Spacing 속성을 접힌 항목에 잘못 적용했습니까?

즉. StackPanel 접힌 항목이 있는 경우 여전히 항목 사이에 간격이 적용되어 프로그래밍 방식으로 표시/숨길 수 있는 항목이 있는 경우 항목 사이에 수동 패딩/여백으로 대체해야 합니다. 나는에 대한 PR이 특정 버그를 수정 한 WrapPanel 윈도우 커뮤니티 툴킷 ( # 2838 ), 그리고 분명히이 행동 StackPanel 알려진 문제는 다른 MS의 엔지니어에 의해 인정되었다 또한. 🤔

앞으로도 힘써주세요! 🚀

@leoniDEV 지적해 주셔서 감사합니다. 내일 확실한 답이 나올지 지켜봅시다 🙂

@jesbis WinUI Desktop에 관한 두 가지 추가 질문(서로 관련됨):

1. WinUI 데스크톱 앱에 다중 인스턴스(Win32 표준)와 단일 인스턴스(UWP 표준) 간에 내장된 스위치가 있습니까? 지금 당장 Win32 앱이 단일 인스턴스가 되도록 하려면 이 동작을 직접 구현해야 합니다. 이것은 앱 잠금(예: 인스턴스가 이미 실행 중인지 확인하기 위한 뮤텍스)뿐만 아니라 두 번째 앱 인스턴스에서 기본 앱 인스턴스로 작업을 전달하기 위해 SendMessage 와 같은 Win32 API가 필요할 수도 있습니다(질문 2 참조). WinUI 데스크톱 앱용 UWP 앱의 단일 인스턴스 동작을 갖는 옵션을 얻을 수 있다면 좋을 것입니다.

1. WinUI 데스크톱 앱에서 UWP Jumplist API를 사용할 수 있습니까? 현재 데스크톱 브리지 앱은 앱을 활성화할 수 없는 것처럼 보이기 때문에 이를 효과적으로 사용할 수 없습니다(문제에 대한 간략한 개요는 Windows 터미널 문제 https://github.com/microsoft/terminal/issues/576 참조). Win32/WPF API보다 작업하기가 훨씬 쉽기 때문에 WinUI 데스크톱 앱에 대해 이 API를 완벽하게 지원하고 싶습니다. 예를 들어 점프 목록 작업 아이콘은 이미지가 포함된 .exe 또는 .dll을 만든 다음 해당 바이너리 파일의 경로를 설정하는 대신 ms-appx:/// 또는 ms-appdata:/// URI 체계를 사용하여 쉽게 설정할 수 있습니다 또한 특정 아이콘에 대한 파일의 오프셋 입니다.

   문서 에는 UWP Jumplist API의 장점이 요약되어 있습니다.

   또는 UWP Windows.UI.StartScreen.JumpList API를 대신 사용하면 패키지 관련 ms-resource URI 체계(언어, DPI 및 고대비 인식)를 사용하여 문자열 및 이미지 자산을 참조할 수 있습니다.

UWP 앱의 단일 인스턴스 동작은 잠재적으로 점프 목록 작업을 훨씬 쉽게 만듭니다. 현재 실행 중인 앱 인스턴스에서 작동해야 하는 점프 목록 작업이 있는 경우 WPF/Win32에서 두 번째 앱 인스턴스가 시작됩니다. 그런 다음 요청된 작업을 보내기 위해 SendMessage Win32 API를 사용해야 합니다. 기본 앱 인스턴스에. 실행 중인 앱에서 UWP의 단일 인스턴스 동작을 사용 하면 호출된 점프 작업을 쉽게 얻을 수 있습니다. Win32의 경우 모든 추가 작업 없이.

@pjmlp 당신이 보지 못했다면 흥미로울 수 있는 또 다른 것은 지난 Build 컨퍼런스의 Kenny Kerr와 Scott Jones의 이 세션입니다. 특히 바인딩에 대한 프로토타입 개선 사항과 일부 C++에 대해 이야기하는 마지막 ~11분입니다. 현재 IDL 및 메타데이터 코드 생성 요구 사항을 완전히 제거할 수 있는 리플렉션 및 메타클래스 지원을 추가하기 위한 기술 사양:

https://youtu.be/X41j_gzSwOY?t=2659

시간이 된다면 내일 통화에서도 이에 대해 조금 이야기할 수 있습니다.

@jesbis 감사합니다. 그 이야기를 알고 있습니다. 내가 말할 수 있는 것은 아직 너무 먼 미래다.

지금 당장은 기존 DirectX 코드를 @Sergio0694 가 지적한 이식하는 것이 그러한 도구가 열매를

나는 당신의 노력에 감탄하지만 Silverlight, XNA, WinRT, UAP, UWP, WinUI, .NET Framework, WCF, EF6 이후에 참호에서 결국 우리는 계속 재작성을 하는 데 지쳤습니다.

WinUI는 모든 면에서 WPF보다 우수해야 하며 이유 때문에 C++를 사용해야 하는 경우 해당 도구는 .NET 개발자가 좋아하게 된 것과 동일한 수준이어야 합니다. Electron 스타일 앱을 사용하려는 비즈니스를 피하는 것이 좋습니다.

@Sergio0694가 이미 질문한 것처럼 WinUi 3.0은 네임스페이스를 전환할 뿐만 아니라 잘못 적용된 공백과 같은 버그를 수정하는 데 필요한 다른 주요 변경 사항을 포함하는 데 사용됩니까?

그렇다면 이름과 유형이 현재 실제로 정렬되지 않으므로 NavigationView.IsBackButtonVisible 속성의 이름을 BackButtonVisibility 로 변경할 수 있습니다(IsBackButtonVisible은 bool이 아닌 NavigationViewBackButtonVisible 열거형임). 이것 은 여기 에서도 논의

@chingucoding 팀에서 WinUI 3.0 자체의 경우 기존(UWP) 앱을 가능한 한 간단하게 이식하려면 변경 사항을 최소화해야 한다고 말한 것을 기억합니다. 이러한 변경 사항이 승인되면 후속 WinUI 3.x/4/5/.... 릴리스에서 구현될 것이라고 생각합니다.

Q: WinUI 3.x는 AcrylicBrush 와 함께 HostBackdrop AcrylicBrush 를 지원합니까? 현재 알파에서 깨진 것으로 알려져 있지만 릴리스 전에 수정해야 할 로드맵에 있는지 궁금합니다.

Q: WinUI Desktop을 사용하면 데스크톱 앱 개발자가 AcrylicBrush 와 함께 HostBackdrop AcrylicBrush 를 _마침내_ 사용할 수 있습니까? 우리는 이전에 구성 속성 사용 WCA_ACCENT_POLICY 가진 ACCENT_ENABLE_ACRYLICBLURBEHIND 그러나 마이크로 소프트는 비판적 19H1 +이 파산하고 우리의 응용 프로그램은 이후 고통을하고있다. (이는 Emoji Picker와 같은 것들에도 영향을 주었지만 Microsoft는 대신 아크릴이 아닌 방법을 사용하도록 해당 구성 요소를 서비스했습니다.)

WebView2 정보:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"개발자 미리보기는 Windows 10, Windows 8.1, Windows 8 및 Windows 7에서 Win32 C++에 사용할 수 있습니다. 앞으로 .NET에서 WebView2 및 XAML을 지원할 계획입니다."

제 질문은 .. WebView2 SDK의 .NET 버전이 Win8.1, 8 및 7에 적용되도록 계획되어 있습니까?
.NET의 WebView2는 WinUI3을 통해서만 지원된다는 우려가 있습니다. 내 이해에 따르면 WinUI3 WinForms 앱 지원은 .NET Core 기반 및 Win10에만 적용 가능합니다.
내 상황을 설명하겠습니다. 내 클라이언트에는 IE BrowserControl을 사용하는 WinForm 데스크톱 앱이 많이 있습니다. 그러나 IE는 더 이상 사용되지 않으며 최신 브라우저로 마이그레이션하려고 합니다. 그리고 이러한 앱은 Win7, 8, 8.1을 지원해야 합니다(SHOULD). (오래된 os 지원에 대해 나를 비난하지 마십시오)

가능하다면:

• WinUI 3.0용 미리 보기 빌드의 Win32 ETA

• 소스 코드를 공유할 준비가 되지 않은 경우 다운로드하여 실행할 수 있는 실행 중인 일부 UI 요소의 이미 컴파일된 데모 exe를 제공하면 동료 동료에게 자랑할 수 있습니다.

• WinUI 3.0은 WPF/Silverlight와 같은 사용자 지정 셰이더 효과를 지원합니까? 그렇지 않다면 나중에 추가할 생각이 있습니까? WinUI에서 사용하는 렌더링 레이어에서도 이것이 가능합니까?

@leoniDEV 강조 표시한 대로 XAML Island 프로젝트를 만들었습니다(별도의 UWP 프로젝트 없음). 단일 UWP 받은 편지함 컨트롤(버튼)이 포함되어 있으며 10X에서 제대로 작동합니다. 컨테이너 이야기는 놀랍지 않습니다... 예상대로 Win32 컨테이너에서 실행됩니다.

따라서 최소한 현재로서는 별도의 UWP 프로젝트를 사용하는 XAML Island 앱에 대한 완전한 지원이 아직 없는 것 같습니다.

레거시 WPF 앱의 v-next를 찾고 있습니다. 아마도 .NET Core WPF를 사용할 수 있지만 실제로 WinUI를 사용하고 싶습니다. 여전히 Windows.UI.Xaml(Microsoft.UI.Xaml과 반대)에서 파생되는 Prism과 같은 라이브러리에 문제가 있습니다. 이러한 유형의 문제는 기본이라고 생각합니다. WinUI에 대한 확실한 PnP 지침이 아직 있습니까, 아니면 너무 이른 것입니까?

Windows 10x의 시작 메뉴와 파일 탐색기가 WinUI를 사용하는 대신 웹 기반인 이유에 대해 셸 팀이나 받은 편지함 앱 팀의 누군가에게 이야기하도록 할 수 있습니까?

필요한 것은 현재 UWP 앱(데스크톱 확장 포함)에서 WinUI 데스크톱 앱(데스크톱 확장 없음)으로의 원활한 포팅 환경입니다. 이것이 가능할까요? 이 시나리오의 함정은 무엇입니까?

이것이 어려운 것으로 판명되면 앞으로 항상 백그라운드에서 앱을 실행하고 P/Invoke를 통해 모든 win32 API를 호출하고 로드되는 dll을 허용하도록 UWP(데스크톱에서 실행되는 앱용)를 개선할 수 있습니까? LoadPackagedLibrary가 없는 다른 dll(그러나 LoadLibrary가 있음).

첫 번째 Windows 10X 장치가 실행될 때 WinUI 3.0이 실행될 가능성은 얼마나 됩니까? 저는 Windows 개발 세계로 뛰어드는 데 관심이 있으며 이 시점에서 어떤 접근 방식이 가장 타당한지 결정하려고 합니다.

질문을 해주신 모든 분들께 감사드리며, 시청해 주셔서 감사합니다! 녹음은 같은 링크에서 생중계됩니다.

우리가 얻지 못한 많은 질문이 있습니다. 나는 그것들을 요약하고 여기에 몇 가지 답변을 곧 게시하려고 노력할 것입니다.

좋은 쇼 여러분, 제 질문을 받아주시고 Miguel이 발표해주셔서 감사합니다.

해결되기를 바라는 마음으로 몇 가지 질문을 더 추가하겠습니다.

1. 기존 Win32 앱은 WM_PAINT의 화면에 그립니다. XAML 앱은 유지 모드입니다. 개별 개체/컨트롤을 만들기에는 너무 많은 것을 화면에 그립니다. 창에 그릴 수 있지만 더 현대적인 API를 사용할 수 있는 WM_PAINT가 여전히 있습니까? Win2D 또는 다른 즉시 모드 API?

2. 접근성은 Win32(COM API)와 WPF(자동화 피어)에서 다르게 처리됩니다. Win32 + WinUI 응용 프로그램을 작성하면 접근성 트리를 더 쉽게 확장하거나 제어할 수 있습니까? 아니면 이전 COM API를 계속 사용할 것입니까? 내 사용자 지정 그린 콘텐츠를 접근성 트리의 접근성 컨트롤과 어떻게 혼합합니까?

3. 오늘날 우리는 프린터 DC에 그림을 그려서 인쇄합니다. Win32+WinUI로 새로운 인쇄가 있습니까?

4. 나는 여전히 HWND, CoreWindow 및 WinUI에 대해 다음에 오는 모든 것 사이의 관계와 관련하여 약간 당황합니다. HWND가 여전히 존재합니까, 아니면 CreateWindow 호출을 다른 것으로 대체합니까? 나는 그렇게 가정합니다... 그러나 만약 그렇다면 우리가 하나를 외부 구성 요소에 넘겨야 하는 경우에 대한 기본 HWND가 여전히 있어야 한다고 가정합니다(예: 상위 HWND).

5. Win32+WinUI 앱에서 WebView2를 사용하면 임베디드 IE 컨트롤에서 발생하는 공역 문제가 있습니까?

몇 가지 질문을 따라잡기 시작:

WinUI는 단지 UWP 개발이지만 더 현대적인 사양입니까? WinUI에 대한 대화를 보고 UWP 개발, UWP 개발의 특정 라이브러리 또는 완전히 다른 것에 대해 이야기하는지 100% 확신할 수 없습니다.

WinUI는 특히 UI 계층이며 일시 중단/재개용 앱 모델, 백그라운드 작업 등과 같은 UWP 앱 플랫폼의 다른 측면을 포함하지 않습니다.

UWP 앱의 경우 특히 Windows.UI.Xaml , Windows.UI.Composition 및 Windows.UI.Input 일부를 대체할 수 있습니다.

WinUI 앱에 다중 인스턴스(Win32 표준)와 단일 인스턴스(UWP 표준) 간에 내장된 스위치가 있습니까?

@Felix-Dev 우리는 아직 win32 앱에 대한 더 나은 단일 인스턴스 지원에 대한 아이디어를 탐색하지 않았습니다. 제안이 있는 경우 이 리포지토리에서 자유롭게 문제를 열 ​​수 있습니다!

WinUI 3.x는 HostBackdrop과 함께 AcrylicBrush를 지원합니까? 현재 알파에서 깨진 것으로 알려져 있지만 릴리스 전에 수정해야 할 로드맵에 있는지 궁금합니다. WinUI Desktop을 사용하면 데스크톱 앱 개발자가 마침내 HostBackdrop과 함께 AcrylicBrush를 사용할 수 있습니까?

@riverar 불행히도 이것은 WinUI 3.0 RTM 계획에 없습니다. OS와 분리된 UI 플랫폼에서 이를 지원하는 데 어려움이 있지만 3.0 이후에 다시 검토할 계획입니다.

WebView2 정보: 제 질문은 .. WebView2 SDK의 .NET 버전이 Win8.1, 8 및 7에 적용되도록 계획되어 있습니까?
.NET의 WebView2는 WinUI3을 통해서만 지원된다는 우려가 있습니다.

@pnp0a03 WinUI Xaml 컨트롤은 WinUI 3에서만 지원되지만 win32 앱용 Windows 7, 8 및 8.1용 핵심 WebView 2 SDK의 개발자 미리보기가 있습니다.

https://docs.microsoft.com/microsoft-edge/hosting/webview2

여전히 Windows.UI.Xaml(Microsoft.UI.Xaml과 반대)에서 파생되는 Prism과 같은 라이브러리에 문제가 있습니다. 이러한 유형의 문제는 기본이라고 생각합니다. WinUI에 대한 확실한 PnP 지침이 아직 있습니까, 아니면 너무 이른 것입니까?

@GraniteStateHacker 내 생각에는 너무 이르다고 생각합니다. WinUI 3은 아직 많은 생태계 지원을 하기에는 너무 새롭지만(알파에만 있음) @hassanuz 는 라이브러리 호환성/마이그레이션 옵션을 조사하기 위한 작업

WinUI는 스토어 앱 전용입니까?

아니오 - 다음과 같은 다양한 방법으로 사용할 수 있습니다.

• Xaml Islands를 사용하여 기존 win32 앱(WPF, WinForms, MFC 등)에 포함
• MSIX 설치 프로그램을 빌드하고 원하는 대로 배포하십시오.
• 패키징되지 않은 앱을 만들고 xcopy 또는 다른 수단을 통해 배포합니다(WinUI 3에서는 아직 지원되지 않지만 RTM에서는 계획됨).

첫 번째 Windows 10X 장치가 실행될 때 WinUI 3.0이 실행될 가능성은 얼마나 됩니까? 저는 Windows 개발 세계로 뛰어드는 데 관심이 있으며 이 시점에서 어떤 접근 방식이 가장 타당한지 결정하려고 합니다.

@dwalleck WinUI 3에는 이미 알파가 있으며 빌드 회의 기간 동안 더 기능적인 미리 보기가 있어야 하며 둘 다 2020년 후반을 목표로 합니다. UWP Xaml 및/또는 WinUI로 시작하는 경우 10X 개발을 위한 좋은 경로에 있어야 합니다. .

기존 Win32 앱은 WM_PAINT의 화면에 그립니다. XAML 앱은 유지 모드입니다. 개별 개체/컨트롤을 만들기에는 너무 많은 것을 화면에 그립니다. 창에 그릴 수 있지만 더 현대적인 API를 사용할 수 있는 WM_PAINT가 여전히 있습니까? Win2D 또는 다른 즉시 모드 API?

@jschroedl Xaml 요소 트리 및 브러시는 유지 모드이지만 여러 옵션 중 하나 이상을 사용하여 더 가벼운 렌더링 기본 요소를 포함할 수 있습니다.

• 컴포지션 레이어 비주얼
• 컴포지션 레이어 매우 고성능으로 유지된 형상을 그릴 수 있는 모양 - 또한 Lottie 모양/애니메이션을 재생할 수 있는 WinUI AnimatedVisualPlayer 컨트롤과 같은 용도로도 사용됩니다.
• SwapChainPanel, SurfaceImageSource 또는 VirtualSurfaceImageSource를 사용하여 Xaml과 DirectX 상호
• 위의 DirectX 상호 운용성을 추상화하고(Direct2D, DirectWrite 사용) .NET API를 제공하는 Win2D

접근성은 Win32(COM API)와 WPF(자동화 피어)에서 다르게 처리됩니다. Win32 + WinUI 응용 프로그램을 작성하면 접근성 트리를 더 쉽게 확장하거나 제어할 수 있습니까? 아니면 이전 COM API를 계속 사용할 것입니까? 내 사용자 지정 그린 콘텐츠를 접근성 트리의 접근성 컨트롤과 어떻게 혼합합니까?

좋은 질문입니다! @marb2000 에 페이징하여 이것이 포함되는지 확인하고 최신 업데이트를 제공합니다. 일반적으로 WinUI Xaml 트리는 AutomationPeers를 사용해야 하지만 이것이 새로운 기능을 WinUI가 아닌 win32 콘텐츠로 확장할지 여부는 아직 확실하지 않습니다.

오늘날 우리는 프린터 DC에 그림을 그려서 인쇄합니다. Win32+WinUI로 새로운 인쇄가 있습니까?

WinUI 콘텐츠의 주요 인쇄 기능은 WinRT PrintDocument API의 WinUI 버전을 통해 이루어져야 합니다.

나는 여전히 HWND, CoreWindow 및 WinUI에 대해 다음에 오는 모든 것 사이의 관계와 관련하여 약간 당황합니다. HWND가 여전히 존재합니까, 아니면 CreateWindow 호출을 다른 것으로 대체합니까? 나는 그렇게 가정합니다... 하지만 만약 그렇다면 우리가 하나를 외부 구성 요소에 넘겨야 하는 경우에 대한 기본 HWND가 여전히 있어야 한다고 가정합니다(예:

WinUI는 hwnds를 대체하지 않지만 목표는 WPF 작동 방식과 유사한 Xaml API를 제공하여 일반적인 사용 사례에 대한 사용법을 추상화하는 것입니다. Xaml API는 여전히 기본 구현 세부 정보로 hwnds/CoreWindows를 사용하며 필요할 때 hwnd에 직접 액세스할 수 있는 "backdoor"/"escape-hatch" API가 있을 수 있습니다. 몇 주 안에 제안 초안이 있어야 이를 더 명확하게 할 수 있습니다.

@jebis 답변 감사
현재 WebView2 SDK Win32 "C++"(미리보기) 버전이 이 사이트에서 릴리스되었습니다. Win7, 8 및 8.1을 지원합니다.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
제 질문은 .NET 버전에 관한 것입니다. 현재 .NET 버전은 WinUI 3에서만 지원되지만, 아시다시피 Win7, 8, 8.1에서는 WinUI 3을 사용할 수 없습니다(맞나요?).
그래서 아래와 같이 질문글을 올립니다.

제 질문은 .. WebView2 SDK의 .NET 버전이 Win8.1, 8 및 7에 적용되도록 계획되어 있습니까?

@jebis 의욕이 들긴 했지만 제 질문에 답

여기에 건설적인 노력을 기울이고 있습니다.

따라서 Microsoft가 C++/WinRT 도구와 관련하여 제공할 수 있는 최선은 일부 공개 제안을 지적하는 것입니다. 운이 좋으면 ISO가 C++23 또는 C++26 사이에 있을 수 있습니다. 그런 다음 Visual Studio 팀이 결국 그 위에 C++/CX를 다시 빌드할 때까지 기다리십시오. 그러면 지금으로부터 약 6년이 됩니다.

훌륭한 C++ UI 도구를 원한다면 WinUI는 확실히 플랫폼 이식성의 이점이 추가된 Qt 또는 C++ Builder가 아닙니다.

따라서 프레젠테이션을 본 후에도 여전히 XNA(DirectXTK를 사용하여 C++로 다시 작성), WinRT 8.0, WinRT UAP 8.1, UWP W10, C++ Direct2D의 흉터를 System 대신 착용하고 있습니다. 그리기(Win2D가 나오기 전까지, 지금은 정체 상태), WinUI는 확실히 보류할 것입니다.

앞으로 저는 고객에게 .NET을 사용할 때는 WPF를 사용하고 C++를 사용할 때는 Qt를 사용하거나 웹 기술로 가능한 경우 PWA에 집중하라고 조언할 것입니다.

WinUI 3.0 로드맵은 데스크톱 시장에서 UWP 판매가 계속 실패할 경우 또 다른 재부팅이 임박했다는 확신을 불러일으키지 않습니다.

어떤 의미에서 내가 지적하고 싶은 것은 Microsoft 경영진이 Windows 8 릴리스 이후로 우리를 수없이 실패시킨 후 WinUI 채택에 대한 아이디어를 우리에게 판매하는 방법을 통해 생각해야 한다는 것입니다.

@pjmlp 일반 C++/WinRT 피드백은 아마도 cppwinrt 리포지토리로 가장 잘 전달될 것입니다. ISO 표준 업데이트에는 시간이 걸리지만 언급하신 기간보다 짧았으면 합니다. 반영 지원이 최우선 과제이며 지난 주 프라하에서 열린 C++ 회의에서 이에 대해 논의한 것입니다.

DirectXTK는 아직 개발 중이며 정기적인 업데이트를 받고 있습니다.

Xaml 프레임워크 API의 관점에서 WinUI는 앞으로 나아가는 길이며 Windows 8로 돌아가는 상당히 깨지지 않은 호환성 계보를 가지고 있습니다. 우리는 높은 수준의 호환성을 유지하기 위해 많은 시간을 할애합니다 🙂 몇 가지 변경 사항이 있습니다(셸 통합으로 인해, VS 프로젝트 구조 등) 그러나 대부분의 경우 Windows 8 Xaml을 현재 Windows 10 앱으로 이식하고 다시 컴파일하고 최신 내부자 비행에서 실행하면 작동합니다.

WinUI의 높은 수준의 이점 중 일부에는 UWP WinRT API와 win32 API 간의 장벽 제거, .NET 5 지원, 새로운 기능에 대한 즉각적인 하위 수준 지원 활성화, 많은 조건부 OS 버전 확인 수행의 필요성 제거, OSS 기여 활성화 및 Xaml 섬을 사용하여 기존 win32 앱에 대한 증분 업데이트를 활성화합니다.

@pnp0a03 .NET 요소를 시장에 내놓기 위한 노력도 있습니다. 구체적인 날짜를 말씀드릴 수는 없지만 이에 대한 수요를 인지하고 있으며 세부 사항을 조율 중입니다.

@jschroedl 우리는 영공 문제를 제거하기를 원하며 이를 달성하는 데 도움이 될 렌더링 계획을 세우려고 노력하고 있습니다.

@jesbis 언급했듯이 cppwinrt에 대해 불평하는 것이 아무 것도 할 수 없다고 생각합니다. 특히 로드맵이 수용되지 않을 수 있는 기능을 채택하는 것이기 때문에 피할 수 없는 사용 사례가 아닌 한 C++/WinRT를 채택하지 않음으로써 불평합니다. ISO.

DirectXTK와 관련하여 저는 Microsoft가 XNA를 삭제하고 DirectXTK를 "대안"으로 제공하여 성능이 떨어지는 도구를 사용하여 C# 코드를 C++로 다시 작성하도록 강요한 방법에 대한 또 다른 예를 제공했습니다.

고맙게도 오픈 소스 커뮤니티는 MonoGame을 고안하고 Microsoft가 XNA로 추구하기를 거부한 작업을 수행할 수 있었습니다.

프레젠테이션 중 그리고 여기의 일부 댓글에서 C++가 얼마나 훌륭하고 재미있는지, WinDev(Longhorn이 인수한 이후 한 번 더)가 C++를 먼저 판매하고 .NET을 나중에 판매하는 방법을 보았습니다.

훌륭한 C++ 도구를 원하면 Visual C++가 아니라 Qt 및 C++ Builder를 선택합니다.

ISO에서 일부 메타클래스와 리플렉션 아이디어가 받아들여지기를 기대하는 대신 팀이 경쟁에서 오늘날 가능한 것을 볼 수 있도록 경영진에게 정말로 요청해야 합니다.

.NET Framework에서 .NET Core로 전달되지 않는 API 및 타사 라이브러리를 처리해야 할 뿐만 아니라 WPF/UWP에서 WinUI로의 모든 마이그레이션 문제와 "그냥 쓰기 C++/WinRT에서는 멋지고 몇 년 안에 더 좋아질 것입니다."

Microsoft 경영진은 이 재작성을 불타버린 .NET 개발자에게 판매하는 방법을 깊이 생각해야 합니다. 그렇지 않으면 이미 제 역할을 하고 있는 스택에서 멀어지지 않을 것입니다.

@pjmlp DirectX에 대해 말하자면 저는 자유 시간 에 WinUI 보기에서 D3D12/11 등을 실행할 수 있는 휴대용 및 불가지론적 C# 그래픽, 오디오 및 입력 프레임워크 적극적으로 작업하고 있습니다.

XNA와 같은 렌더링에 대한 훨씬 더 현대적이고 성능 중심적인 접근 방식을 지원합니다. 아직 사용할 준비가 되지 않았지만 저를 포함해 많은 분들이 원하셔서 만들어 봤습니다. D3D12 및 Vulkan이 지원되는 첫 번째 대상이 됩니다. HLSL이나 GLSL 등 대신 C#으로 셰이더를 작성할 수도 있습니다.

사용할 준비가 되면 더 많은 정보를 공유하겠습니다. 그러나 이것은 대규모 SDK나 게임 엔진이 아닌 프레임워크이기 때문에 휴대가 간편하고 가벼우면서도 강력하고 사용하기 쉽습니다. WinUI, WPF 또는 일부 기본 C# Win32 또는 WinRT 앱에서 3D 콘텐츠를 렌더링하는 데 적합합니다.

https://github.com/reignstudios/Orbital-Framework

@zezba9000 정보 감사합니다, 많은 인상적인 일을 하셨습니다.

DirectX에 대한 관리 지원과 관련하여 우리는 Managed DirectX 및 XNA를 탱킹한 후 DirectX 개발 노력을 인수한 C++ MS 군중과 같은 커뮤니티 노력에만 의존할 수 있다고 생각합니다.

WinDev가 추진하기를 좋아하는 "C++ 또는 하이 로드"일 필요는 없다는 것을 다른 사람들에게 보여주기 위한 마케팅으로서 이러한 프로젝트 중 적어도 모든 프로젝트는 내 옹호로 간주될 수 있습니다. 여기에서 그들은 OpenGL ES/Metal with Swift 또는 OpenGL ES/Vulkan with Java/Kotlin에서 교훈을 얻을 수 있습니다. 분명히 3D 프로그래밍을 위해 관리되는 언어를 사용하는 것은 모바일 플랫폼이 Windows를 이기는 문제가 아니었습니다(슬프게도 WP는 훌륭한 경험이었습니다).

여러분의 노력에 행운을 빕니다. C#으로 셰이더를 작성하는 것은 정말 매력적으로 보이지만 CS2X를 알지 못했습니다.

@pjmlp Ya CS2X 부분은 C#에서 불가지론적 GPU 셰이더를 작성할 수 있게 해주는 부분입니다(이론적으로 셰이더를 단위 테스트할 수 있기 때문에 멋진 기능입니다). C# 하위 집합을 사용할 수 있는 대상의 경우 CS2X를 사용하면 CS2X가 C# 하위 집합을 C89 런타임으로 컴파일할 수 있기 때문에 현재 .NET 런타임이 지원하는 것 이외의 플랫폼을 대상으로 지정할 수 있습니다. CS2X => C89 런타임을 대상으로 할 수 있으며 차례로 이러한 플랫폼도 대상으로 할 수 있습니다.

큰 프로젝트지만 내가 관심을 갖고 있는 일을 하기 위해 최선을 다하고 있습니다.

WinUI 2.4에서 HwndHost를 사용할 수 있습니까?
시험판 버전에서 시도했지만 작동하지 않았습니다.
또한 이 모든 새로운 계획된 창(XAML 창) 및 응용 프로그램(XAML 응용 프로그램)이 포함된 WinUI3에서 가능할 것이며, 그렇다면 첫 번째 미리 보기에서 이를 확인할 수 있을 때입니다.
실제로 WinUI3에서 가능하게 된다면 이 기능이 WinUI 2 새 릴리스에 추가되거나 WinUI 2가 Uwp 앱에서 작동할 것입니다.
예를 들어 지금 우리는 HwndHost를 통해 많은 C++ 코드를 사용하는 WPF 앱을 가지고 있으며 모든 것을 WinUI로 이동할 계획이기 때문에 이 부분은 WinUI 또는 다른 것으로 이동하기로 결정하는 데 매우 중요합니다. 또한 WinUI 2도 보기에 좋고 XAML 부분은 전송하기 매우 쉽고 Composition Api는 훌륭하게 작동하며 Uwp Community Toolkit은 훌륭하게 작동하지만 HwndHost 및 C++ Win32 코드만 사용할 수 없습니다. 그렇다면 언제 WinUI3가 이 문제를 해결할 것입니까? 또한 x:Bind를 많이 좋아하지만 WinUI3 릴리스의 경우에도 위험합니다.

@zezba9000

DirectX에 대해 말하자면, 저는 여가 시간 에 WinUI 보기에서.... 다른 많은 것들 중에서 D3D12/11 등을 실행할 수 있는 휴대용 및 불가지론적 C# 그래픽, 오디오 및 입력 프레임워크 적극적으로 작업하고 있습니다.

행운을 빕니다! 미친 작업량입니다!

WinUI 2.4에서 HwndHost를 사용할 수 있습니까?
시험판 버전에서 시도했지만 작동하지 않았습니다.
또한 이 모든 새로운 계획된 창(XAML 창) 및 응용 프로그램(XAML 응용 프로그램)이 포함된 WinUI3에서 가능할 것이며, 그렇다면 첫 번째 미리 보기에서 이를 확인할 수 있을 때입니다.
실제로 WinUI3에서 가능하게 된다면 이 기능이 WinUI 2 새 릴리스에 추가되거나 WinUI 2가 Uwp 앱에서 작동할 것입니다.
예를 들어 지금 우리는 HwndHost를 통해 많은 C++ 코드를 사용하는 WPF 앱을 가지고 있으며 모든 것을 WinUI로 이동할 계획이기 때문에 이 부분은 WinUI 또는 다른 것으로 이동하기로 결정하는 데 매우 중요합니다.

WinUI XAML 내에서 user32/comctl 또는 WPF UI를 호스팅하는 방법에 대해 열려 있는 문제가 있습니다. https://github.com/microsoft/microsoft-ui-xaml/issues/1833

만들어지면 3.0 이후에는 만들어지지 않을 것 같습니다.

나는 이것을 #1833에 게시한다
https://github.com/microsoft/microsoft-ui-xaml/issues/1833 하지만 복사하겠습니다.
그것은 여기에도 있습니다: 지금 우리는 많은 C++ 코드를 사용하는 WPF 앱을 가지고 있습니다.
HwndHost 컨트롤. Wpf 앱을 WinUI로 옮기고 Xaml을 옮길 계획입니다.
문제 없이 잘 작동하지만 HwndHost는 어떻습니까?
WinUI3에서 가능합니다. 우리의 경우 상호 운용성을 수행하고 있습니다.
HwndHost를 통한 DirectShow와 현재 WinUI 2에서는 그렇지 않습니다.
가능한. WinUI3에서 HwndHost를 사용하는 현실적인 날짜는 언제입니까? 도
이 새로운 Xaml 창 및 응용 프로그램은 최근 2월에 논의된 것과 같습니다.
WinUI 커뮤니티 호출, 도움이 될 수 있습니까?

엘돔, 2월 23일 de 2020 a la(s) 13:42, Max Strini(
[email protected]) 설명:

WinUI 2.4에서 HwndHost를 사용할 수 있습니까?
시험판 버전에서 시도했지만 작동하지 않았습니다.
또한 이 모든 새로운 계획이 있는 WinUI3에서 가능할까요?
윈도우(XAML 창) 및 응용 프로그램(XAML 응용 프로그램) 및 예인 경우
우리는 그것을 볼 첫 번째 미리보기를 기대할 수 있습니다.
실제로 WinUI3에서 가능하게 된다면 이 기능은
WinUI 2 새 릴리스에 추가되지 않으면 WinUI 2가 Uwp 앱에서만 작동합니다.
예를 들어 지금 우리는 많은 C++ 코드를 사용하는 WPF 앱을 가지고 있습니다.
HwndHost, 그리고 우리는 모든 것을 WinUI로 옮길 계획이기 때문에 이 부분은
WinUI 또는 다른 것을 사용하기로 결정하는 것은 우리에게 매우 중요합니다.

내부에 user32/comctl 또는 WPF UI를 호스팅하는 방법에 대해 열려 있는 문제가 있습니다.
WinUI XAML: #1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

만들어지면 3.0 이후에는 만들어지지 않을 것 같습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVEXG43VM
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

--
마리오 란치치
소프트웨어 엔지니어
마이크로소프트 공인 전문가

지난 주에 정말 좋은 WinUI 커뮤니티 호출이었습니다! 내용은 많은 통찰력을 제공하기에 충분히 흥미롭고 상세하고/기술적이었습니다. 로드맵/개발 상태 업데이트는 WinUI 소비자와 자체 개발 로드맵에게도 매우 중요합니다. 다음 전화를 기다리겠습니다!

WinUI 3의 HwndHost 정보.
HwndHost를 사용하면 WPF 내부에서 Win32 콘텐츠를 호스팅할 수 있습니다. 불행히도 WinUI 3.0 데스크톱 또는 WinUI 아일랜드를 포함하여 WinUI 3.0에는 이를 지원할 계획이 없습니다. @mariorancic01에서 설명한 시나리오에 대해 DirectShow 대신 UWP MediaPlayer API를 평가했습니까?

Uwp 카메라가 더 좋아 보이지만 시나리오에서 사용할 수 있는지 확실하지 않습니다.
우리는 카메라를 DirectShow와 함께 가상 카메라로 사용하고 있으며 그것이 필요합니다.
비디오, 사진 및 PjSip을 사용하여 카메라 스트림을 가져옵니다.
같은 시간에 DirectShow로 하기 전에 말이죠. 이 Uwp를 사용할 수 있습니까?
PjSip이 있는 MediaPlayer.

El mié., 2월 26일 de 2020 a la(s) 23:47, Miguel Ramos(
[email protected]) 설명:

WinUI 3의 HwndHost 정보.
HwndHost를 사용하면 WPF 내부에서 Win32 콘텐츠를 호스팅할 수 있습니다. 불행히도 거기
WinUI 3.0 Desktop을 포함하여 WinUI 3.0에서는 이를 지원할 계획이 없습니다.
WinUI 제도. 시나리오 정보 @mariorancic01
https://github.com/mariorancic01 설명, UWP를 평가했습니까?
DirectShow 대신 MediaPlayer API?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMXVBW
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

--
마리오 란치치
소프트웨어 엔지니어
마이크로소프트 공인 전문가

비즈니스용 Windows Store에 대해 질문이 있습니다. 이것은 LOB 앱에 매우 유용하고 매우 유용해 보이지만 포기할 수 있다는 것을 읽었습니다. 아무도 이것 에 대한 계획 에 대해 말할 수 있습니다 .

@marionrancic01 이제 MSIX 패키징을 통해 UWP 앱을 배포할 수 있으므로 실제로 필요하지 않습니다.

슬프게도 @mariorancic01 처럼 비즈니스용 Windows 스토어도 유용합니다 😞

@kmgallahan 말했듯이 @leoniDEV 난 당신이 단순히 MSIX로 게시 할 수 있습니다 때 비즈니스, 용 Windows 스토어를 필요로하는 이유 솔직히 궁금합니다

@kmgallahan @jtorjo 그들이 찾고 있는 것은 사설 애플리케이션 카탈로그를 갖는 것이라고 생각합니다. MSIX는 내가 믿는 것을 제공하지 않습니까? 회사에서 제공하는 MSIX를 나열하는 웹 사이트를 구축하거나 일부 관리 도구를 사용하여 사용자에게 배포하지 않는 한?
비슷한 방식으로 이전 MSI 설치 프로그램은 앱을 검색하는 방법도 제공하지 않습니다.

Windows 스토어에 게시하는 것은 쉬운 일이 아닙니다. 생각보다 훨씬 복잡합니다. 먼저 MS의 인증서를 기다려야 합니다. 이 인증서는 게시하는 데 사용할 인증서입니다(지금 정확한 단계는 기억나지 않습니다). 그런 다음 앱이 스토어 요구 사항을 위반하지 않는지 확인해야 합니다. 그런 다음 업데이트를 수락하는 데 며칠이 걸릴 수 있으며(또는 거부될 수 있음) 사람들이 앱을 찾는 데 스토어의 알고리즘에 의존하게 됩니다.

그러나 직접 배포하면 설정하기가 약간 어려울 수 있지만(알겠습니다) 일단 완료되면 쉬울 것입니다. 하지만 네, 당신은 당신의 앱을 세상에 보여줄 책임이 있습니다.

비즈니스용 스토어를 포함하여 Microsoft Store에 여러 앱을 가지고 있는 사람으로서 저는 지난 몇 개월 동안 Microsoft Store에 게시하는 것이 훨씬 좋아졌다고 말할 수 있습니다. 정기 업데이트에 대한 인증은 때때로 몇 시간 내에 이루어집니다. 매장 가이드라인도 준수하기가 매우 쉽습니다.
반면에 독립 실행형 msix를 방해하는 것은 복잡할 수 있습니다. 패키지에 서명하는 스토어와 달리 스토어 외부에 앱을 배포하는 경우 직접 서명해야 합니다.

@jtorjo 인증서가 필요하지 않습니다.

분명히 스토어에 문제가 있고 개발자 대시보드가 ​​가끔 다운되는 경우가 있지만, 위의 요점은 비즈니스 앱용 스토어가 있으면 꽤 편리하다는 것입니다.

비즈니스용 스토어를 포함하여 Microsoft Store에 여러 앱을 가지고 있는 사람으로서 저는 지난 몇 개월 동안 Microsoft Store에 게시하는 것이 훨씬 좋아졌다고 말할 수 있습니다. 정기 업데이트에 대한 인증은 때때로 몇 시간 내에 이루어집니다. 매장 가이드라인도 준수하기가 매우 쉽습니다.

@yaichenbaum 확실히 알고 있어서 좋습니다. 제가 출판할 때(2년 전쯤)에는 훨씬 더 어려웠습니다. 예, 직접 서명해야 합니다. 실제로 인증서를 구입하고 "게시" 프로세스의 일부로 서명합니다. 따라서 한 번 설정하면 잊어버릴 수 있습니다.

@riverar 내가 출판할 때(2년 전쯤), 이름을 예약해야 하고, 그런 다음 MS가 앱에 서명하는 데 사용할 무언가를 기다려야 한다는 것을 기억합니다(이는 인증서로 의미하는 것입니다. > MS가 귀하를 위해 발행할 것).