문제 내용에서 질문하신 내용에 대한 저의 초기 생각입니다.

저는 디자인 및 사용자 관점에서 왔으며 약간의 개발 경험이 있으며 당시 Silverlight/Windows Phone 7 개발에 매우 ​​관심이 많았지만 지금은 약간 불타오르는 느낌이 듭니다.

어떤 템플릿이 가장 흥미로우신가요?

템플릿 아이디어 목록을 요청하기 전에 WPF, UWP, WinForms, MFC 등 각 프레임워크에서 가장 크고 가장 많이 사용되는 앱에 대한 일종의 감사가 필요하다고 생각합니다.

이러한 앱의 "실루엣"을 조사하고 일반적인 UX 시나리오를 파악하십시오.

내 머리 꼭대기에는 다음이 있습니다.

• 주 메뉴(모든 프레임워크)
• MDI(한 창에 여러 문서)(대부분 MFC)
• 탭 및 데이터 그리드(WPF, WinForms, MFC)
• 리본(Win32 앱 Office, 3ds max, 페인트, 워드패드, 파일 탐색기 등)
• 시스템 트레이 유틸리티(MFC, WinForms)
• 브라우저
• 마법사(WPF, MFC)
• 복잡한 MDI 앱(Adobe 소프트웨어, Visual Studio)
• 미디어 플레이어
• 데이터 시각화 LoB(WPF 및 웹)
• 소셜 앱(React Native, PWA - Skype, Facebook, Twitter)

이들 모두 또는 일부는 알림/관리 센터와 WinRT/UWP 시스템 통합의 이점을 얻을 수 있습니다.

이러한 모든 새 프로젝트 템플릿은 기본 제공 Windows.Xaml 네임스페이스, WPF 컨트롤 테마 및 WinForms 비주얼 스타일을 피하고 FabricWeb/Fluent 컨트롤 디자인과 일치하는 새 템플릿 및 비주얼 스타일을 선호해야 합니다.

또한 기존 WPF 및 WinForms 앱이 있는 개발자가 간단한 using 문 또는 매니페스트 항목으로 새 컨트롤 디자인을 제공하는 WinUI 3.0 종속성을 추가할 수 있는 쉬운 방법이 있어야 합니다.

XAML 제도

Xaml Islands가 더 쉽게 가능해짐에 따라 기존 webview 컨트롤, 색상 선택기, XAML 기반 대화 상자를 새로 추가 하는 것처럼 쉽게 대체할 수 있고 대화 상자 또는 기존 C# 및 C++ 코드가 호출할 수 있는 표준 컨트롤을 선택할 수 있습니다. 그들만의 코드 숨김이 있습니다.

Xbox Next 앱, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop 및 Pivot과 같은 최신 앱 및 페이지 템플릿은 XAML 아일랜드가 제자리에 있고 샘플 콘텐츠가 있는 모든 Windows 프레젠테이션 플랫폼에서 사용할 수 있습니다.

현재 UWP XAML에서 가능하지 않은 이러한 시나리오는 이러한 작업을 더 쉽게 하기 위해 컨트롤 및 템플릿이 있어야 합니다.

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

누군가가 현재 Windows 10 SDK를 사용하여 최신 버전의 Visual Studio에서 프로젝트를 열 때 묻는 질문이어야 합니다. 버튼을 누르면 네임스페이스와 사용을 대체하거나 익숙한 컨트롤이 아닌 경우 플래그를 지정합니다.

새 프로젝트에서는 기본값이어야 하며 Windows SDK의 향후 버전과 함께 설치된 nuget 패키지여야 합니다.

WinUI 3에서 UWP 구성 요소를 사용하기 위해 선호하는 솔루션은 무엇입니까?

자동 업데이트 답변과 마찬가지로 새 페이지 및 프로젝트에는 기본적으로 포함해야 하며 자동으로 WinUI | 네임스페이스 업데이트를 위해 ToDo 주석 추가 | WinUI로 이동하지 마십시오 .

어떤 종류의 앱에 WinUI 3.0을 사용하고 싶습니까?

사용자로서 저는 Windows에서 실행되는 모든 앱이 어떤 프레임워크를 사용하든 공통 UI와 UX를 공유하기를 바랍니다.

레지스트리를 어지럽히고 정크를 남기지 않고 앱을 설치하고 싶습니다. (그래서 100주년)

모든 앱을 스토어 내에서 또는 Centennial 유형 설치 프로그램에서 설치할 수 있기를 바랍니다. 모든 앱의 시스템 및 Windows 폴더를 가상화합니다.

Fluent UI로 C++ MFC 앱 현대화?

아크릴은 WPF, WinForms 및 MFC 앱에서 사용할 수 있어야 하며 WinUI 3.0 종속성 또는 매니페스트를 통해 기본 새 템플릿에 포함되어야 합니다. CommonControls 및 창 스타일은 아크릴 및 확장된 제목 표시줄을 사용해야 합니다(현재 기본값으로 돌아가기 위해 재정의할 수 있음).

Microsoft의 Win32 비 UWP 앱은 모두 WinUI 3.0으로 다시 컴파일해야 아크릴 창 프레임, 기본 메뉴, ThemeShadows, 컨텍스트 메뉴 , 텍스트 필드, 진행률 표시줄 등을 사용할 수 있습니다.

그런 다음 기존 앱은 WinUI 3.0 이상에 드롭하여 모든 컨트롤의 모양을 업데이트하거나 전체 UI가 업데이트될 때까지 한 번에 하나의 대화 상자를 선택적으로 적용하는 기능이 필요합니다.

re: 네임스페이스, 조건부 네임스페이스가 필요한 경우에도 대상에 따라 변경될 것으로 예상합니다.

내 답변은 다음과 같습니다.

새 앱 만들기

어떤 템플릿이 가장 흥미로우신가요?

• 나는 C++/winRT win32+xaml 및 .net core+xaml을 먼저 보고 싶습니다. UWP 템플릿은 두 번째로, 패키지된 win32 앱은 템플릿으로 제공되어서는 안 됩니다. 현재 앱 패키지 템플릿은 이미 현재와 같이 작동해야 하기 때문입니다. win32/.Net 앱.
• 또한 기존 win32 또는 .net 핵심 앱 응용 프로그램에 표시하기 위해 상용구 코드가 있는 "새 XAML 창"과 같은 항목 템플릿을 보고 싶습니다(예: Docker 데스크톱에서 기존 시스템 트레이 앱 만들기, 새로운 최상위 Xaml 창)

기존 Win32 앱에 WinUI 3.0 추가

• 이전 버전이 아닌 호환성은 실제 프로젝트에서 xaml 섬을 사용하지 않은 정확한 이유입니다. Windows API에서 UI 프레임워크를 분리하는 것은 WinUI 3.0 로드맵에서 발표된 가장 위대한 것 중 하나입니다(비패키지/비uwp 대상 앱이 이를 활용하는 기능과 함께).

기존 UWP Xaml 앱을 WinUI 3.0으로 업데이트

거칠게 들릴 수도 있지만 UWP xaml 앱이 틈새 시장이라고 생각합니다(Windows Phone이 출시된 이후로 대상 플랫폼으로서 UWP에 대한 견인력이 더 이상 없음). 도구/상호 운용성이 있으면 좋겠지만 WinUI 3.0의 주요 초점이 되어야 한다고 생각하지 마십시오.
따라서 네임스페이스 업데이트 도구(실제로는 전역 찾기 및 바꾸기를 사용하여 수행할 수 있음)와 UWP xaml과 WinUI xaml을 혼합하는 것이 중요하게 느껴지지 않습니다.

또한 이것은 매우 환영할만한 조치이며 Github에 전체 UI 프레임워크를 오픈 소스로 제공하는 것은 굉장하다는 것을 언급하고 싶습니다! 이렇게 해주셔서 감사합니다!

우선, 이것은 훌륭한 움직임입니다! 불행히도 나는 마이크로소프트가 그들의 플랫폼에서 마지막 몇 명의 개발자들을 처리한 방식에 약간 상처를 받았다는 사실을 무시할 수 없습니다. 현재 다음과 같은 이유로 소비자용 앱 에만 UWP를 사용합니다.

1. WPF는 WinUI(유효성 검사, 기존 컨트롤 등)보다 훨씬 더 성숙하므로 엔터프라이즈의 경우 WPF가 더 적합합니다.
2. UWP는 소비자가 있는 여러 장치 범주(모바일, 태블릿, 데스크톱 등)에 적합합니다.

1번 포인트가 WinUI로 해결될 수 있다는 사실을 알게 되어 기쁩니다. 그래서 WinUI의 발전에 대해 열광하게 되었습니다. 불행히도 2는 더 이상 적용되지 않습니다(더 이상 멋진 장치가 아니라 데스크탑만 해당). 이 물건이 배송될 때(지금부터 1년 후?) 그 단계에서 개발자에게 필요한 것은 무엇인지 궁금합니다.

나는 소비재가 더 이상 방정식의 일부가 아니라고 생각합니다. 그 배는 축소 "전략"으로 항해했습니다. 따라서 엔터프라이즈 앱에 적합할 수 있는 유일한 방법입니다.

일반적으로 저는 대규모 WPF 코드 기반을 Windows 10으로 마이그레이션하려고 시도하고 마이그레이션하기 위해 WPF에서 WinUI로의 좋은 마이그레이션 전략에 더 관심이 있습니다. 소비자용 앱(현재 UWP)을 업데이트해야 하는 단점은 앱의 외부 구성 요소 개발자(예: win 툴킷 등). 대부분의 개발자(내가 알고 있음)가 소비자/Windows 클라이언트 개발에 관심을 잃었기 때문에 더 이상 업데이트할 수 있는 실행 가능한 옵션이 없다고 생각합니다.

질문에 대한 답변

새 앱 만들기

어떤 템플릿이 가장 흥미로우신가요?

.net core/xaml/C#이 가장 많이 사용되는 언어 조합이라고 생각하기 때문에 여기에서 보고 싶습니다. 그러나 여기에서는 마이그레이션 템플릿이 더 나을 것입니다(가능한 한 빨리 모든 사람을 참여시키려고 하면 시간이 오래 걸리고 더 고통스러울 것입니다).

기존 Win32 앱에 WinUI 3.0 추가

나는 이것이 매우 훌륭하다고 생각하고 우리는 이것을 많이 사용할 것입니다(그러나 실제로는 기업 고객이 여전히 Windows 7을 사용하고 있기 때문에 적어도 1년은 더 있어야 합니다. MS 지원이 종료되더라도 회사는 Windows 7을 사용하게 될 것입니다). 그런 다음 WPF를 WinUI 3으로 천천히 마이그레이션할 수 있습니다.

데스크톱 앱 현대화를 위한 Xaml Islands를 알고 계셨습니까?

예, 하지만 너무 많은 고객이 Windows 7을 사용하고 있으므로 엔터프라이즈 개발자를 위한 옵션이 아니었습니다. 소비자의 경우 어쨌든 UWP를 사용할 수 있습니다.

Windows 10에서 확장된 이전 버전과의 호환성이 Xaml Islands를 더 유용하게 만들까요?

이 제품이 배송될 때 엔터프라이즈에서 지원되는 모든 Windows 10 버전에서 작동하기 때문에 좋은 시작입니다.

기존 UWP Xaml 앱을 WinUI 3.0으로 업데이트

MS용 소비자 앱은 끝났습니다. 모두 MS의 선택으로 인해 더 이상 이를 위한 여지가 없습니다. 이 모든 옵션을 건너뛰고 잊어버리겠습니다. UWP 앱에 수천 시간을 투자했기 때문에 슬프지만 고통을 덜 수 있도록 이 죽음을 빨리 만들어야 한다고 생각합니다.

약속된 전체 이야기는 항상 최신 상태이며 모든 장치를 지원합니다. 그 약속이 어떤 식으로 진행되었는지 우리 모두 알고 있다고 생각합니다.

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

네임스페이스일 경우 검색/바꾸기도 트릭을 수행해야 합니다.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

더 이상 중요하지 않으며 수천 시간의 개발 손실을 감수할 용의가 있습니다. 어쨌든 남은 사용자는 없습니다.

앱 코드와 함께 쉽게 다시 컴파일 및 업데이트할 수 없는 UWP Xaml 제어 라이브러리 또는 WinRT 구성 요소를 만들거나 사용합니까?

아니요.

WinUI 3에서 UWP 구성 요소를 사용하기 위해 선호하는 솔루션은 무엇입니까?

UWP 아일랜드(호스팅된 구성 요소의 일종)

일반적인

위와 로드맵에 요약된 전반적인 3.0 계획에 대해 어떻게 생각하십니까? 신규 및 기존 Windows 앱에 WinUI를 사용할 수 있습니까?

좀 더 성숙해져야 할 필요가 있겠지만, 저는 1~2년 안에 기업 개발을 위해 이 물건을 사용하고 있다고 봅니다. 마이그레이션이 얼마나 어려운지에 따라 WinUI 또는 웹을 선택합니다(Windows 자체가 "진화하는" 방법에 따라 다름).

어떤 종류의 앱에 WinUI 3.0을 사용하고 싶습니까? 새 Win32 앱을 만들고 MSIX로 패키징하시겠습니까? WPF 앱에 새 보기를 추가하시겠습니까? Fluent UI로 C++ MFC 앱 현대화?

아마도 WPF 앱에 새 보기를 추가하고 천천히 마이그레이션을 시작하는 것 같습니다.

나는 이 로드맵을 매우 좋아한다. UWP는 족쇄에서 해방되어야 하며 이것이 바로 이를 수행하는 좋은 방법입니다.

기존 UWP Xaml 앱을 WinUI 3.0으로 업데이트

이것은 내 고용주에게 매우 중요합니다. 스토어에 복잡한 UWP 데스크톱 앱이 있습니다. 이제 .NET 네이티브에서 지원하지 않는 win32 API에 액세스하려면 Desktop Bridge가 필요합니다.

나는 원한다

• 모든 win32 API에 대한 직접 액세스
• 평범한 오래된 win32 실행 모델을 사용합니다. 일부 Desktop Bridge와 같은 샌드박싱(예: 레지스트리 가상화)은 괜찮습니다.
• 현재와 ​​같이 스토어(msix)에 앱을 배치합니다.
• WNS(푸시 알림)를 계속 사용하려면
• UWP에서 새로운 Xaml 데스크톱 앱 유형으로의 간편한 업데이트 환경. 나는 약간의 수작업을 하는 것을 꺼리지 않는다. 어쩌면 나는 여기에서 도구보다 좋은 문서를 선호합니다.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

기존 스타일은 계속 작동해야 합니다. 나는 약간의 시각적 변화로 살 수 있습니다. 그러나 행동의 변화로는 그렇지 않습니다.

앱 코드와 함께 쉽게 다시 컴파일 및 업데이트할 수 없는 UWP Xaml 제어 라이브러리 또는 WinRT 구성 요소를 만들거나 사용합니까?

아니요.

WinUI 3에서 UWP 구성 요소를 사용하기 위해 선호하는 솔루션은 무엇입니까?

재컴파일할 수 없는 경우(타사): Xaml Islands와 유사한 접근 방식입니다. 그렇지 않으면 WinUI 3으로 쉽게 이식할 수 있어야 합니다.

일반적인

어떤 종류의 앱에 WinUI 3.0을 사용하고 싶습니까? 새 Win32 앱을 만들고 MSIX로 패키징하시겠습니까? WPF 앱에 새 보기를 추가하시겠습니까? Fluent UI로 C++ MFC 앱 현대화?

• MSIX와 함께 패키징된 데스크탑 win32 앱.
• Uno 크로스 플랫폼 앱 ;)

_INotifyDataErrorInfo_와 같은 항목에 대해 새 네임스페이스를 도입 하지 마십시오. 일반적으로 크로스 플랫폼이고 WinUI에 대한 종속성이 없어야 하는 뷰 모델에서 사용해야 합니다. 이와 같은 다른 항목이 있는 위치를 정의해야 합니다(예: _INotifyPropertyChanged_ 또는 _INotifyCollectionChanged)_

궁극적인 목표가 플랫폼 간 UI 스택을 만드는 것인지 알고 싶습니다. 그것을 이해하는 것은 우리가 어떻게 거기에 도달하는지 완전히 이해하지 못할 수도 있습니다. 그러나 그것이 의도라면... 이 노력의 시작 부분에서 Win 참조 없이 이것을 브랜드화하는 것이 좋습니다. 그렇게 하면 장기적으로 두통이 덜할 것입니다.

XamlUI 또는 이와 유사한 것으로 레이블을 XamlUI 3.0 또는 이와 유사한 것과 같은

문의해 주셔서 감사합니다. 이 공간에서 무엇이 나올지 기대해주세요 :스마일:

나에게 모든 기술적 세부 사항은 덜 중요합니다.
UWP, WPF 또는 모든 Windows 전용 프레임워크는 아무리 훌륭하더라도 모든 플랫폼(최소한 Windows, Droid, iOS 및 웹)에서 실행되지 않고 모든 화면 크기.

TBH는 지난 빌드에서 MS가 UWP 또는 XAML 크로스 플랫폼을 만들 계획이 없다는 사실을 알고 실망했습니다. 우노 는 연설 외에는 공식적인 인정을 받지 못했다. 더 실망스러운 것은 MS가 책임 있는 .NET 스택 개발자를 무시하면서 다시 React Native 및 HTML/JS 기반 프레임워크(WinJS)에 너무 많은 사랑을 주고 있다는 사실을 알게 된 것입니다.
저는 MS가 공식적으로 Uno와 같은 크로스 플랫폼 UI 스택을 만들고 올바른 도구, 템플릿 및 통합 지원을 제공하는 것을 보고 싶습니다.

그리고 BTW, 저는 MS가 XF를 인수한 이후로 XF와 함께 일해 왔으며 다음과 같은 이유로 XF에 대안이 있기를 바랍니다. 웹 지원 없음, b. 매우 모바일 편향, 데스크탑에 대한 사랑 없음 c. WPF/UWP 제어 라이브러리와 비교할 때 확실히 라이브러리 계층 구조가 엉성하게 느껴집니다. d. MS XAML을 사용하지 않습니다.
다음은 Microsoft 개발자 커뮤니티에 게시한 기능 요청입니다. .NET UI Standard .

감사합니다!

웹(어셈블리)에서도 실행되는 XAML UI가 필요합니다. 최소한 UWP의 하위 집합입니다.
UNO 플랫폼을 수용하고 SkiaSharp를 사용하여 웹 렌더링을 만들지 않겠습니까?
WinUI 의 웹 대응물인 Silverlight 6 일 수 있습니다.

질문에 대한 빠른 답변

어떤 템플릿이 가장 흥미로우신가요?

.NET 핵심 SDK 스타일 프로젝트 또는 일부 단순화된 MSVC 프로젝트 형식.
이전 프로젝트 파일은 수동으로 편집하기에는 너무 복잡하고 이전 프로젝트 시스템과 새 프로젝트 시스템 사이에 수많은 상호 작용 문제가 있습니다. 우리는 완전히 새로운 프로젝트를 위해 기존 프로젝트 시스템을 버려야 합니다.

데스크톱 앱 현대화를 위한 Xaml Islands를 알고 계셨습니까?

아니요. 전체 데이터 모델 변경으로 응용 프로그램을 다시 작성하고 있으므로 점진적 마이그레이션이 없습니다.

Windows 10에서 확장된 이전 버전과의 호환성이 Xaml Islands를 더 유용하게 만들까요?

Windows 7에는 여전히 많은 사용자가 있으며 Xaml Islands는 도움이 되지 않습니다.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

아니요. 모든 구성 요소는 자체 작성되거나 MUX 및 WCTK에서 작성되므로 빠른 수동 마이그레이션을 수행할 수 있습니다.

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

내 프로젝트가 크지 않기 때문입니다(현재 ~20페이지 및 ~10사용자 정의 컨트롤).

WinUI 3에서 UWP 구성 요소를 사용하기 위해 선호하는 솔루션은 무엇입니까?

아주 작은 도구를 만들고 KB 단위로 배송할 수 있도록 OS와 함께 제공되는 버전이 있었으면 합니다. 이 도구는 사용자가 즉시 저에게 연락할 수 있기 때문에 낮은 OS에서 실행되지 않습니다(예: 일부 채팅 소프트웨어를 통해).

어떤 종류의 앱에 WinUI 3.0을 사용하고 싶습니까? 새 Win32 앱을 만들고 MSIX로 패키징하시겠습니까? WPF 앱에 새 보기를 추가하시겠습니까? Fluent UI로 C++ MFC 앱 현대화?

새로운 Windows 10 전용 앱을 만들고 스토어 없이 배송합니다.
신뢰할 수 있는 서명은 개별 개발자에게 비용이 많이 들고 저장소에 업로드하는 것은 장기 애플리케이션이 아닌 도메인 특정에 적용할 수 없습니다.

UI 플랫폼에 대한 개인적인 견해

Xaml 도구 체인

xaml 언어는 어떻게 든 심각하지 않으며 "이를 어떻게 표현해야합니까?"와 같은 많은 문제에 직면 해 있습니다. WPF xaml과 UWP xaml은 완전히 호환되지 않으므로 차이점을 기억해야 합니다. Xaml은 .NET 기능과 완전히 호환되지 않으므로 때때로 내 모델과 도우미 클래스에 몇 가지 추악한 트릭을 작성해야 합니다.

x:Bind 와 함께 오면 상황은 더욱 악화됩니다. 간단한 시나리오는 사용하기 쉽지만 속성 액세스 이상의 작업을 수행하는 것은 매우 복잡합니다. 예를 들어 메서드 오버로딩을 지원하지 않으므로 이 바인딩 식에 대해 어떤 오버로드가 선택되었는지 확인하기 위해 컴파일해야 합니다. 간단한 전환이나 "일부 속성이 false일 때 표시" 변환조차 할 수 없으며 도우미 메서드가 필요합니다. 설명서에는 이러한 자세한 시나리오에 대한 설명이 없으므로 xaml-언어 설계 토론을 위한 입장이 있어야 하며 xaml을 C#과 같이 진지하게 설계된 언어로 만들어야 한다고 생각합니다.

xaml 편집기도 사용하기 어렵습니다. 디자이너가 실제 효과를 표시하기 위해 일부 코드를 실행하는 것은 합리적이지만 텍스트 편집기는 메타데이터만 인식해야 합니다. 소스 보기에서 xaml 파일을 여는 것은 디자이너를 활성화하고 NullReferenceException 및 Cannot convert __ComObject to some type 와 같이 완전히 미세하게 실행되는 xaml에 대한 일부 상호 작용 예외를 발생시키기 때문에 느립니다. 빌드된 라이브러리를 통해 ProjectReference 닿아 의존성 라이브러리(일반적으로 데이터 모델의 구현)에서 non-public-api 영역을 간단하게 편집해도 복잡한 오류가 발생합니다. 따라서 메타데이터와 소스 코드를 인식하는 완전히 Roslyn 통합 xaml 컴파일러가 있어야 한다고 생각합니다.

더 나은 창 모델

정보 전체, 상태 전체 응용 프로그램이 탐색 모델 대신 다중 창 모델을 사용하는 것이 일반적입니다. 현재 UWP에서 ApplicationView 사용하여 새 창을 만드는 것은 스레딩 문제가 있기 때문에 고통스럽습니다. 새로운 AppWindow 는 UI 스레드를 공유하며 UI 성능이 확실하지 않습니다.

나중에 WinUI에서 Visual Studio를 다시 작성하면 성숙한 UI 시스템임을 증명할 수 있습니다.

데이터 바인딩 인터페이스

INotifyPropertyChanged 구현하는 모델을 만드는 데 매우 지쳤습니다. xml을 확장된 속성 접근자로 변환하는 사용자 지정 MSBuild 작업을 작성했지만 속성이 변경될 때 setter에서 사용자 지정 작업을 수행하려는 경우에는 도움이 되지 않습니다.

그리고 스레딩 문제가 있습니다. 내 데이터는 완전히 백그라운드 네트워크 서버에서 가져오기 때문에 await 대한 컨텍스트 캡처가 도움이 되지 않습니다. WPF 및 Binding 에서는 Binding 스레딩 자체를 해결하기 때문에 그대로입니다. x:Bind 변경할 때 이벤트 발생기 내부에서 해결해야 합니다. x:Bind 는 호출 스레드에서만 작동하기 때문입니다. 동일한 데이터를 터치하는 여러 애플리케이션 보기가 있는 경우 상황이 더욱 악화됩니다. 즉, 사용할 수 있는 전역 UI 디스패처가 없고 유일한 솔루션은 이벤트 등록 시 SynchronizationContext.Current 를 캡처하는 것입니다. 컬렉션의 경우 ItemsSource 도 스레드로부터 안전하지 않으며 동일한 해결 방법이 필요합니다.

변경 가능한 바인딩 가능한 모델에 대한 모델링, 스레딩 및 확장 문제를 해결하기 위한 도구 체인이 있어야 합니다. 그리고 바인딩 가능한 컬렉션을 위한 일반적인 기본 제공 솔루션은 "변경된 자식의 지정된 속성"에 대한 메커니즘을 제공해야 합니다.

IObservableVector<T> 는 object 만 사용할 수 있는 가짜 제네릭 유형이고 INotifyCollectionChanged 는 제네릭이 아닙니다. ObservableCollection<T> 와 같은 내장 컬렉션에 대해 구현하는 것만으로는 충분하지 않습니다. 특히 복잡한 ISupportIncrementalLoading / IItemsRangeInfo 지향 시나리오의 경우에는 더욱 그렇습니다. 플랫폼은 사용자가 추상 데이터 채우기 방법을 구현할 수 있도록 모범 사례와 함께 기본 추상 구현을 제공해야 합니다.

@shaggygi @weitzhandler @TonyHenrique

XAML 구문을 추상화하는 UWP/XamlUI3.0에 대한 크로스 플랫폼 미래가 있는 경우 Windows 렌더러 및 나머지 Windows 런타임이 이를 처리하는 방법이 될 것입니다.

프로젝트에 거의 플러그인 사고 방식이 있을 수 있다면 Android 또는 iOS/AppKit Renderer가 있을 수 있으며 Android/iOS AppKit Shim은 ART API를 C# 및 VB는 물론 기존 C++, C 언어로 전달합니다. 지원하다.
여기서 Xamarin이 도움이 될 수 있습니다.

Microsoft는 이러한 대체 플랫폼 렌더러에서 작업하는 사람일 필요가 없습니다.

그러나 지금은 Windows에 집중하고 있습니다. WinUI 3.0은 Fabric Web / React Native / WPF / WinForms / MFC를 포괄할 수 있습니다. PWA는 또한 앱 개발을 위한 1급 시민이 될 것이므로 Windows/.NET/UWP용으로 직접 제작되지 않은 앱에 대한 플랫폼 간 스토리가 있습니다.

지금 필요한 것은 C#/.NET/UWP 개발자가 앱과 투자를 더 넓은 플랫폼 환경으로 가져갈 수 있도록 스토리를 제공하는 것입니다.

내 2센트: 저는 Xamarin.Forms 개발자이고 (다른 많은 사람들과 마찬가지로) 모든 XAML 방언이 모바일 공간을 포함하여 모든 곳에서 작동하는 방언으로 병합되는 것을 보는 데 관심이 있습니다. 그것이 어떻게 될지 확실하지 않지만 적어도 그 문제에 대한 나의 바람입니다.

WinUI 3.0 이상일 수도 있지만 모든 XAML을 다시 작성하고 번역할 것으로 예상하기에는 너무 많은 WPF 앱이 있습니다. 새 WPF 프로젝트는 보다 현대적인 WinRT XAML 언어를 사용할 수 있습니다. 동일한 프로젝트에 다른 방언이 공존할 수 있도록 DocType에 해당하는 항목을 XAML에 도입할 수 있습니다.

물론 말보다 쉽습니다.

@mdtauk 일단 Xaml 플랫폼이 실제로 오픈 소스로 만들어지면 스택의 맨 아래에 의존하는 것에 대해 더 명확하게 이해하게 될 것이라고 생각합니다(우리는 이미 주요 플랫폼별 종속성이 DirectX11, Direct2D 및 Windows Media Foundation, 그러나 Windows SDK의 어떤 부분이 거기에서 사용되는지 아는 사람), 계층화 방법(모든 이식의 실행 가능성에 대한 실제 느낌을 가질 수 있도록).
또한 우리는 소스 코드가 어떤 종류의 라이선스로 배포되는지 아직 알지 못합니다. 아직 결정이 되었는지 모르겠습니다.

Android는 Vulkan을 사용하며 OpenGL을 지원한다고 생각합니다.
iOS 및 macOS는 Metal을 사용합니다.

미디어 코덱의 경우 네이티브 C 기반 API를 사용하여 대체할 수 있습니다.

@simonferquel 코드가 리팩토링되고 체크인되면 더 명확해질 것입니다. 그리고 이러한 노력을 이끌려면 일부 iOS 및 Android 전문가가 필요할 수 있습니다.

winui가 컨트롤 모음이었을 때 네임스페이스를 변경하는 것이 합리적인 접근 방식이었다고 생각합니다. 그러나 이제는 기본적으로 플랫폼을 대체하므로 더 이상 정당화되지 않는다고 생각합니다. 이것은 이미 WPF/Winforms에 대해 동일한 방식으로 작동하며, 코드의 네임스페이스를 변경하지 않고 코드를 .net Framework에서 .net 코어로 이동할 수 있습니다. 플랫폼은 활성화되면 필요한 dll의 winui 버전을 자동으로 로드할 수 있어야 합니다. 이러한 방식으로 소스 및 바이너리 호환성(저는 .net 핵심 앱에서 .net 프레임워크 라이브러리를 성공적으로 사용했습니다)을 유지할 수 있습니다.

지금까지 댓글을 남겨주신 모든 분들께 감사하다는 말을 전하고 싶었습니다! WinUI 팀은 모든 응답과 포인트를 주의 깊게 살펴보고 있습니다.
또한 생각을 정리한 후 특정 문제(예: 기존 UWP 프레임워크 및 구성 요소와의 호환성)에 대해 이야기하기 위해 몇 가지 집중 문제를 나눌 것입니다.

더 많은 것을 듣고 .net 개발자에게 멋진 도구를 제공한 MS에 감사하다는 말을 전하고 싶습니다. 하지만 빌드 회의 이후 UWP Xaml의 미래에 실망하지 않을 수 없습니다.
이 블로그와 인터넷에 있는 많은 기사를 읽으면 UWP가 독점적으로 "엔터프라이즈"가 되고 있다는 느낌을 받게 되며, 많은 기업이 OS에 구애받지 않고 작업자가 MacBook Pro를 사용할 수 있게 됨에 따라 이는 논란의 여지가 있습니다.

저는 기본 UWP 및 Xamarin Forms(Android, iOS)에 막대한 투자를 하고 있으며 플랫폼을 사랑하지만 MS가 React에 대한 기본 지원을 발표한 후 곧 출시할 예정입니다.

데스크톱에서 UWP 앱을 플랫폼에 구애받지 않게 만들어야 한다는 것을 알고 있으므로 현재 uwp 앱을 셸로 사용하고 React를 혼합하여 사용하여 점점 더 많은 웹 프런트 엔드 기술을 통합하는 "하이브리드 앱"을 만들 수 있기를 바랐습니다. . 내가 이해하는 제안된 "세트" 기능과 같은 기능은 이제 Edge 내에서 더 높은 우선 순위로 인해 지연되며, 기본 UWP와 웹 기술을 모두 실행하여 기본 UWP와 웹 기술 간의 경계를 완전히 흐리게 하므로 현재 솔루션에 이상적이었습니다. "창/가장자리 탭". 이 "하이브리드" 접근 방식을 통해 웹 기술을 현재 플랫폼에 천천히 수용할 수 있을 뿐만 아니라 "브라우저"에 "네이티브 앱" 탭도 제공할 수 있습니다. (소비자 관점에서) 이것은 또한 "네이티브 uwp 앱"이 데스크탑에서 장기간 실패할 경우 탈출구를 제공합니다.

위의 생각에 대한 이유는 곧 크로스 플랫폼 기능이 없으면 UWP가 다음 Silverlight 희생자가 될 수 있기 때문에 탈출용 해치를 제공하지 않기 때문입니다. MS는 PWA 추세에서 잃지 않도록 하기 위해 내기를 헤지하고 있습니다. 그렇지 않으면 Windows에서 React 기본 지원을 위해 손을 돌리고 있습니다. 문제는 이 시간까지 UWP/c#/.net에 대한 "경로"가 브라우저 또는 교차 플랫폼에 있고 이러한 플랫폼에 대한 대부분의 투자를 재사용할 수 있기를 희망하면서 내기를 걸었다는 것입니다.

모든 개발자가 Xamarin을 사라고 외쳤을 때 MS가 그렇게 하는 데 영원히 걸렸던 것을 기억합니다. 웹 어셈블리에 익숙한 대부분의 개발자는 최근에 웹 어셈블리에서 Windows Server의 "정식 버전"을 실행할 수 있었다는 것을 알고 있다고 생각합니다. 전체 OS가 웹 어셈블리에서 실행될 수 있다면 MS는 모든 .net 개발자에게 기존 투자를 보호하기 위해 플랫폼 간 기능에 대한 마이그레이션 경로를 제공해야 합니다.

Blazor가 거기에 있다고 말할 수 있지만 솔직히 말해서 새 플랫폼에 더 많은 시간을 투자하기 전에 React를 배우거나 우리 MS가 이 모든 것에 대한 리소스가 제한적이라고 말할 수 있습니다. 확실히 Github에 75억 달러를 지불하면 모든 것이 상대적이 됩니다.

기존 UWP/Win32 투자에 대한 플랫폼 간 기능으로의 마이그레이션 실패로 인한 평판 손상을 MS가 이해하는 것이 중요하다고 생각합니다. 플랫폼 간 기능은 .NET 5와 동의어여야 하지만 그렇지 않습니다. 이 경우 플랫폼을 건너는 아기 단계가 MS에서 잘 작동하는지 확신할 수 없으며 저는 항상 xaml/.net/c#의 열렬한 팬이었습니다.

어떤 템플릿이 가장 흥미로우신가요?

프로젝트 템플릿이나 항목 템플릿도 의미합니까?

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

이것은 검색 및 교체(가치가 낮음) 또는 새 버전에 대한 업데이트 종속성을 통합(더 가치가 있지만 어떻게 알 수 있는지 확실하지 않음)

Re: 새로운 기능에 대한 이전 버전과의 호환성

Creators Update(15063)와 역호환되는 것은 고정된 기준점이 됩니까? 아니면 앞으로의 계획은 현재 버전과 그 이전 버전의 X개를 지원하는 것입니까?

공개적으로 공유하고 싶은 확장 기능이나 자체 컨트롤 또는 기능을 만드는 사람에게 이것이 의미하는 바는 무엇입니까? 해당 수준의 하위 호환성도 지원해야 합니까? 심지어 윈도우 8.1까지?

Re: 네임스페이스 마이그레이션

기존 UWP를 단계적으로 마이그레이션할 수 있습니까(페이지를 생각하고 있습니다). 아니면 전체 앱을 한 번에 업데이트해야 합니까? 한 번에 전체 앱을 사용하는 경우 채택 속도가 느려집니다.

WPF 앱 마이그레이션은 어떻습니까? - 마이그레이션 전략은 WinUI 2.x 또는 3.x를 사용할 수 있는 XAML 아일랜드를 사용하는 것입니까? 같은 앱에서 둘 다 사용할 수 있나요?

예, 이 문제를 더 집중된 여러 문제로 나누면 아이디어를 더 명확하게 포착하고 접선을 피하는 데 도움이 됩니다.

무엇을 말하는지 명확하지 않으므로 UWP의 모든 인스턴스를 적절한 이름으로 바꾸십시오.

@mrlacey :

프로젝트 템플릿이나 항목 템플릿도 의미합니까?

아이템이나 라이브러리 템플릿도 재미있습니다! Windows Template Studio 와 같이 시간이 지나면서 추가하는 것을 고려할 수 있는 추가 상용구 및 시작 코드를 제공하는 것에 대한 답변에는 지금까지의 좋은 점이 몇 가지 있습니다.

이것은 검색 및 교체(가치가 낮음) 또는 새 버전에 대한 업데이트 종속성을 통합(더 가치가 있지만 어떻게 알 수 있는지 확실하지 않음)

좋은 질문입니다. 어떤 종류의 종속성 업데이트가 더 가치가 있습니까? 예를 들어 호환되는 새로운 NuGet 패키지 버전을 찾고 계십니까?

Creators Update(15063)와 역호환되는 것은 고정된 기준점이 됩니까? 아니면 앞으로의 계획은 현재 버전과 그 이전 버전의 X개를 지원하는 것입니까?

사용에 따라 시간이 지남에 따라 지원 버전 범위가 변경될 것으로 예상합니다. 특정 수의 버전에 국한되지 않고 계속해서 사용 데이터를 살펴보고 가장 활성화된 Windows 10 출시 버전을 지원할 것입니다.

공개적으로 공유하고 싶은 확장 기능이나 자체 컨트롤 또는 기능을 만드는 사람에게 이것이 의미하는 바는 무엇입니까? 해당 수준의 하위 호환성도 지원해야 합니까? 심지어 윈도우 8.1까지?

우리는 현재 사용자 지정 컨트롤에 대한 추가 요구 사항이나 "인증"을 부과할 계획이 없습니다. 버전 관리는 귀하에게 달려 있습니다. 2019년 5월 업데이트, WinUI 3.0 및 WinUI의 향후 버전에 대한 전반적인 버전 관리 이야기는 분명히 우리가 곧 더 깊이 들어가고 싶은 주제입니다.

기존 UWP를 단계적으로 마이그레이션할 수 있습니까(페이지를 생각하고 있습니다). 아니면 전체 앱을 한 번에 업데이트해야 합니까? 한 번에 전체 앱을 사용하는 경우 채택 속도가 느려집니다.

훌륭한 질문입니다. 지적해 주셔서 감사합니다. 이것은 또한 우리가 곧 더 깊이 들어가고자 하는 주제이기도 합니다.

무엇을 말하는지 명확하지 않으므로 UWP의 모든 인스턴스를 적절한 이름으로 바꾸십시오.

@riverar : 명확하지 않은 특정 사용법이나 섹션이 있습니까?

다른 Xaml 기반 플랫폼(예: WPF)과 구별하기 위해 Windows 10 및 UWP SDK의 일부로 제공되는 Xaml 플랫폼을 나타내기 위해 " UWP Xaml "이라는 용어를 사용합니다.

또한 Win32 앱 모델과 구별되는 " UWP 앱 모델 "(패키징 및 설치, 데이터 및 상태 관리, 런타임 수명 주기 등)을 참조합니다.

Windows 데스크톱에서도 사용자는 웹 검색에 많은 시간을 할애합니다.
() UWP vNext XAML + .NET (C#/F#/VB.NET)을 사용하여 괜찮은 웹 앱을 개발할 방법이 필요하다고 생각합니다.

저는 수년 동안 WPF + ClickOnce로 개발한 다음 UWP를 살펴보기 시작했습니다. 나는 UWP를 좋아하지만 (또는 다음 버전) 독립 실행형 EXE, 더 나은 창 API(원하는 경우 사용자 지정 Winamp 창 스타일 앱을 만들 수 있음), 더 많은 인쇄 API, C dll과의 쉬운 상호 운용성을 실행할 수 있어야 합니다. , OCX, 구성 요소의 하위 집합은 웹에서 실행되어야 합니다.

UNO를 보았을 때 나는 굳게 마음을 먹었습니다. Microsoft는 이 회사를 인수하고 이 개발자들을 UWP 및 Xamarin 팀과 함께 할 수 있습니다. 다음 버전 UWP가 웹, Windows, 모바일 및 IoT에서 실행되는 Azure 제품이 된다면 기쁠 것입니다. IMO는 Azure Portal도 UWP vNext로 작성할 수 있습니다.

마이크로소프트는 할 수 있습니다. Silverlight로, WPF로, UWP로, Xamarin으로 했습니다. 이제 궁극적인 GUI XAML 프레임워크가 필요할 때입니다. 그리고 내 생각에 웹은 최소한 기능의 하위 집합에서 지원되어야 합니다.

_INotifyDataErrorInfo_

_INotifyDataErrorInfo_와 같은 항목에 대해 새 네임스페이스를 도입 하지 마십시오. 일반적으로 크로스 플랫폼이고 WinUI에 대한 종속성이 없어야 하는 뷰 모델에서 사용해야 합니다. 이와 같은 다른 항목이 있는 위치를 정의해야 합니다(예: _INotifyPropertyChanged_ 또는 _INotifyCollectionChanged)_

이 주제에 대해. Windows.UI.Xaml.Interop에는 이미 INotifyCollectionChanged 인터페이스가 있고 Windows.UI.Xaml.Data에는 INotifyPropertyChanged가 있습니다. 이 두 가지는 Microsoft 네임스페이스로 이동됩니다. 아마도 System.Runtime.WindowsRuntime 어셈블리는 WinUI에서 .Net으로 일부 매핑을 수행할 수 있습니다.

아직 추가되지 않은 경우 추가하고 싶은 유일한 것은 MSIX/Appx 패키지 모델을 100% 지원하고 Win10이 Windows의 수명 동안 설치 및 제거 작업을 수정하는 환상적인 작업을 수행했다는 것입니다. 그러나 AppContainer 샌드박스에서 선택한 사용 가능한 API의 이상한 하위 집합 때문에 "UWP" 응용 프로그램을 빌드하는 데 항상 어려움을 겪었습니다. C++ 개발자로서 그것은 실망스러웠고 매년 전체 Win32 API 세트를 허용하기 위해 더 많은 샌드박스를 여는 것을 보고 안도했습니다.

따라서 WinUI 3.0을 사용하여 Win32 스택의 100%에 액세스할 수 있는 앱을 빌드할 수 있다면 이것이 황금이 될 것입니다! 지금 XamlIslands를 사용해 보았는데 환상적인 탈출구이지만 저에게는 불안정했고 결승선을 통과하기 전에 약간의 작업이 남았습니다.

AppContainer 프로세스 내부를 채우지 않고 Win32 앱을 빌드할 수 있는 프로젝트 템플릿을 얻고 UI로 만든 모든 발전 사항에 액세스할 수 있다면 WinUI 3가 저에게 완벽할 것입니다.

@eklipse2k8 편안한 샌드박스에서도 사용자의 파일 및 장치에 액세스하려면 여전히 권한 시스템이 필요합니다. 또한 일종의 공식 테스트 및 코드 서명 요구 사항 없이 사용자 영역을 유지하고 관리자 및 커널 액세스로의 상승을 방지하는 규칙이 있어야 한다고 생각합니다.

안녕하세요 마이크로소프트,

이 게시물이 Font Rendering , ClearType , DirectWrite 및 Windows UI의 미래에 대한 주제에 얼마나 영향을

Windows UI와 글꼴 렌더링에 대한 사람들의 불만 (또는 만족)은 인터넷의 거의 모든 곳 에서 잘 설명되어 좋아하는 사람들도 있고 절대적으로 싫어하는 사람들도 있을 것입니다.

나는 어느 쪽이 다른 쪽보다 나은지 논하기 위해 여기 있는 것이 아닙니다. 또한 레지스트리 해킹, '글꼴 튜너' 또는 글꼴을 더 잘 보이게 하기 위해 OS 설정을 조정하는 방법에 대해 논의하기 위해 여기에 온 것이 아닙니다. 저를 믿으세요. 제가 다 했습니다. 심지어 커널 모드에서 DirectWrite 기능을 패치하기 위해 커널 모드 드라이버를 작성하기 위한 연구를 하기까지 했습니다.

나는 근시 / 근시 라는 매우 일반적인 시신경 질환을

팔 거리를 넘어 교정 렌즈를 착용해야 합니다. :안경: 데스크톱 컴퓨터 화면이 거의 팔 거리에 있다는 사실은 우리 모두가 알고 있을 것입니다. 따라서 문제.

• 매끄럽게 보이는 글꼴이 흐릿하게 보입니다.
• 날카로운 모서리(픽셀 단위로 맞춤)가 있는 글꼴이 더 선명해 보입니다.

글꼴이 픽셀 에 맞춰질 때 날카로운 모서리는 시야가 초점이 맞지 않는다고 생각하게

오랜 시간 동안 코드를 작성하고 텍스트를 보는 동료 개발자로서 답답하고 가슴이 아픕니다. 이것이 내가 여전히 Windows 10이 아닌 7을 실행하는 주된 이유입니다. 거의 모든 Windows 10 기본 Metro UI는 어디에서나 글꼴 다듬기를 사용하고 있습니다.

이 글꼴 다듬기 문제를 설명하기 위해 Windows 7 의 services.msc MMC 스냅인을 살펴보겠습니다.

초점이 맞지 않아 흐릿한 텍스트가 보입니까? 여기. 좀 더 확대해 볼까요...

맙소사, 자동 입체도 에서 십자눈으로 텍스트를 보고 있는 것 같은 느낌이 듭니다.

이 특정 경우에 이 창의 컨트롤 계층을 파고들면 MMC 스냅인이 "설명을 보려면 항목 선택" 패널에서 퍼지 텍스트를 렌더링하는 Internet Explorer DHTML/ActiveX 컨트롤을 호스팅하는 것으로 나타났습니다. 날카로운(픽셀에 맞추기), "도움말" 메뉴 및 서비스 목록은 일반 USER32 및 GDI32 프리미티브로 렌더링됩니다.

이 작은 예는 Windows의 글꼴 렌더링과 관련된 가장 큰 문제 중 하나를 강조합니다. IE8은 ClearType 및 글꼴 다듬기를 비활성화하는 전역 운영 체제 설정을 존중합니다. 그러나 IE9 이상을 설치하면 IE9+는 글꼴 다듬기를 비활성화하려는 모든 노력을 기꺼이 무시합니다. IE9+는 상관하지 않으며 모든 사용자가 글꼴이 부드러운 텍스트로 웹 사이트(및 ActiveX 컨트롤)에서 텍스트를 보도록 강제합니다.

시간이 지남에 따라 Windows 8 및 Windows 10의 탄생, Metro Apps, WPF 및 UWP가 모두 IE9+와 동일한 접근 방식을 취했기 때문에 나와 같은 사용자의 경우 문제가 더 악화됩니다. 내부에 있는 이러한 모든 UI 기술은 시스템에서 준수해야 하는 전역 운영 체제 전체 설정 합니다. 운영 체제 전체 수준에서 ClearType 및 글꼴 다듬기를 비활성화하면 ClearType 및 DirectWrite API(결과적으로 Metro, WPF 및 UWP 앱)가 글꼴 다듬기로 그리지 않을 것으로 예상합니다.

이 문제가 나 혼자만이 아니라는 것을 알고 있습니다.

얼마 전 Google Chrome 은 v31 릴리스 에서 동일한 작업을 수행했으며 IE9+ 접근 방식을 따르고 전체 시스템 전체 설정을 무시하고 모든 글꼴 렌더링을 DirectWrite 로 전환했습니다. 이 변화는 인터넷을 분노케 했습니다. Chromium 문제 319429를 참조하십시오. 마지막으로, 이를 갈기갈기 찢은 후 Google은 근시 시각 장애가 있는 사용자를 위해 Chrome 37 의 문제를 수정하고 이제 글꼴 다듬기를 비활성화하는 운영 체제 전체 설정을 존중합니다.

시장의 힘과 시장의 힘 덕분에 Microsoft 는 브라우저 전쟁에서 지고 현재 Chromium 렌더링 엔진을 채택하고 있지만 Edge 팀이 비활성화된 글꼴 다듬기 설정을 존중할 것이라고 숨을 죽이고 있습니다.

저는 Microsoft가 시력 문제가 있는 사람들을 위해 운영 체제의 모든 앱, 모든 UI 스택에 걸쳐 존중 되어야 하는 하나의 전역 설정

그리고 친숙한 알림으로 이것은 시각적 기본 설정이 아니라 일반적으로 Windows UI에 대한 접근성 문제 입니다.

전세계적인 근시 유병률을 기준으로 현재 세계 인구의 22% 이상, 즉 15억 명이 근시라고 추정할 수 있습니다. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

감사 해요,
브라이언

:walking_man: :walking_woman: 실종자 - LA 워킹

즉, 전체 Xaml 프레임워크가 GitHub에서 개발되고 NuGet 패키지로 대역 외 배송됩니다.

NuGet은 훌륭하지만 vcpkg (및 CMake )를 지원하는 것도 감사할 것입니다(기존의 대규모 크로스 플랫폼 라이브러리가 있는 경우).

어떤 템플릿이 가장 흥미로우신가요?

우선순위:
Win32 + Xaml 데스크톱 + WinUI
Win32 + Xaml 제도 + WinUI
UWP + WinUI

데스크톱 앱 현대화를 위한 Xaml Islands를 알고 계셨습니까?Windows 10에서 확장된 이전 버전과의 호환성이 Xaml Islands를 더 유용하게 만들까요?

예, Xaml Islands는 흥미롭지만 기업 고객이 아닌 소비자를 대상으로 하기 때문에 확장된 이전 버전과의 호환성은 문제가 되지 않습니다. 대부분의 고객은 OS를 업데이트하는 데 상당히 만족합니다(그리고 주어진 시간 범위에서는 새로운 WinUI를 기반으로 변경 사항을 구현합니다. Xaml, 1903년으로 잠그면 아마도 이미 1년이 지났음을 의미합니다).

WinUI의 Xaml, 구성 및 입력 API에 대한 루트 네임스페이스는 Windows UWP SDK 루트 네임스페이스와 다릅니다.

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

UWP 앱이 없기 때문에(현재 직접 판매에는 WPF + Desktop Bridge를 사용) 이것은 나에게 영향을 주지 않습니다. 그러나 네임스페이스를 변경하는 것은 일회성이며 가장 큰 코드 기반에서도 Windows::UI::Xaml 대한 전역 찾기 및 바꾸기는 그리 어렵지 않습니다(우리는 모두 버전 제어를 사용하고 있습니다..?).

WinUI 3.0을 출시하는 가장 빠른 경로는 혼합을 지원하지 않는 것입니다.

그건 괜찮습니다. 그것들은 별도의 호환되지 않는 라이브러리로 취급되어야 합니다. UWP Xaml 또는 WinUI Xaml을 대상으로 합니다. 위에서 언급했듯이 일회성 변환은 그렇게 어렵지 않아야 합니다.

그러나 가장 큰 우려 사항 중 하나는 특히 UWP Xaml 컨트롤 라이브러리를 작성하거나 사용하는 경우 기존 UWP 앱 및 구성 요소 라이브러리에 대해 생성할 수 있는 호환성 문제 및 작업입니다.
예를 들어 기존 버전의 Windows Community Toolkit 은 WinUI 3.0 앱에서 사용할 수 없으므로 Toolkit과 이를 사용하는 모든 앱은 WinUI 3.0을 사용하기 전에 업데이트해야 합니다.

마이크로소프트는 기술을 선택하고 고수해야 합니다. 수년 동안 우리는 최신의 최고의 데스크톱 UI 프레임워크(Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml 및 현재 WinUI Xaml)를 약속해 왔습니다. 선택은 훌륭하지만 기능 및 개발자 지식의 단편화로 이어집니다. 기술에 따라 7개의 다른 기능과 비교하여 Windows의 기능 구현에 대한 하나의 세션/하나의 웹 페이지/하나의 스택 오버플로 답변을 갖는 것이 훨씬 쉽습니다. WinUI Xaml이 미래인 경우 커뮤니티 도구 키트를 업데이트하여 이를 활용해야 합니다.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

기능이 없기 때문에(Win32/WPF와 비교하여) UWP Xaml로 무엇이든 하는 것을 미루고 있습니다. 그리고 저는 그런 면에서 혼자가 아니라고 가정합니다. 따라서 완전한 호환성은 문제가 되지 않습니다.

앱 코드와 함께 쉽게 다시 컴파일 및 업데이트할 수 없는 UWP Xaml 제어 라이브러리 또는 WinRT 구성 요소를 만들거나 사용합니까?

아니요.

WinUI 3에서 UWP Xaml 구성 요소를 사용하는 데 선호하는 솔루션은 무엇입니까?

해당 없음

1. 위와 로드맵 에 요약된 전체 3.0 계획에 대해 어떻게 생각하십니까? 신규 및 기존 Windows 앱에 WinUI를 사용할 수 있습니까?

로드맵에는 Xaml Desktop 에 대한 언급이 없습니다. 이것은 WinUI의 소관에 해당합니까?
//Build/의 사람들에게 이전에 언급했지만 이전에 UWP Xaml을 채택하지 않은 이유는 기존 C++ 라이브러리를 사용하는 응용 프로그램을 만드는 것이 불가능했기 때문입니다. 예를 들어 사용자가 FileOpenPicker 를 사용 하여 파일을 선택하면 결과가 IStorageFile 로 전달되며 이를 기존 타사 라이브러리에 전달하여 열 수 있는 방법이 없습니다(예: libpng , libjpeg 등). 이것이 우리가 WPF를 고수해야 하는 이유입니다. 따라서 Xaml Desktop 또는 Win32 + Xaml Islands 이러한 제한 없이 살 수 있다면 예, 새 응용 프로그램에 WinUI를 사용할 수 있습니다.

1. 어떤 종류의 앱에 WinUI 3.0을 사용하고 싶습니까? 새 Win32 앱을 만들고 MSIX로 패키징 하시겠습니까? WPF 앱에 새 보기를 추가하시겠습니까? Fluent UI로 C++ MFC 앱 현대화?

WinUI(및 MSIX로 패키징)를 사용하여 새 Win32 앱 만들기.

질문이 있는 경우 알려주세요. 기꺼이 더 논의하겠습니다.

실제로 WPF/WinForms에서 Compact Overlay를 호출하는 방법이 있기를 바랍니다.
Android에서 "다른 앱 권한 위에 그리기"와 같은 관리자 권한 시스템만 있으면 됩니다.

이 앱 모델 + 패키징(UWP + AppX, Win32 + MSIX)이 허용하기를 바랍니다(샌드박스 내부의 전체 추상화).

Windows는 최고의 보안과 함께 가장 진보되고 무한한 가능성이 있다고 가정하지 않습니까?
아니요 보안을 위해 기능이 손상되었습니다.

로드맵에 대한 의견을 커뮤니티에 공개해 주셔서 감사합니다.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

요점에 따르면 현재 엔터프라이즈 클라이언트에 사용 중인 UWP 앱이 상당히 많으며 마이그레이션 경로가 그렇게 어렵지 않기를 바랍니다. 주요 변경 사항이 있는 경우 마이그레이션 경로가 얼마나 호환되는지 생성하는 .Net Framework 에서 .Net Core 와 유사한 마이그레이션 도구가 있으면 변경이 필요할 수 있는 모든 것을 보고해야 합니다( 예: 더 이상 사용되지 않거나 다르게 동작할 수 있는 API) 및 가능한 경우 네임스페이스를 자동으로 변경하는 옵션. 이렇게 하면 UWP에서 WInUI로의 마이그레이션 경로가 엔터프라이즈 개발자에게 그다지 불안정하지 않을 것입니다.

데스크톱 앱 현대화를 위한 Xaml Islands를 알고 계셨습니까?
Windows 10에서 확장된 이전 버전과의 호환성이 Xaml Islands를 더 유용하게 만들까요?

예, 하지만 새로 개발된 모든 데스크톱 앱이 API 백엔드를 통해 통신하는 UWP를 사용하고 있고 대부분의 클라이언트가 이미 Windows10을 실행하고 있기 때문에 크게 문제가 되지는 않았습니다.

위와 로드맵에 요약된 전반적인 3.0 계획에 대해 어떻게 생각하십니까? 신규 및 기존 Windows 앱에 WinUI를 사용할 수 있습니까?

데스크톱 팀은 이미 WinUI 3의 소식에 흥분하고 있지만 위에서 언급한 것처럼 경로가 원활하지 않은 경우 모든 UWP 앱이 WinUI 3으로 마이그레이션되는 것을 두려워합니다.

일반 XAML의 경우 전체 XAML UI 프레임워크가 Windows에서 분리되어 다른 사람들이 렌더러를 교체할 수 있도록 하기 때문에 라이브로 분리됩니다. 이것은 다른 플랫폼에서 WinUI XAML을 실행할 수 있는 가능성을 열어줍니다. 이는 오늘날 사람들이 스택을 선택할 때 큰 정의 요소가 됩니다. 플랫폼별 네이티브 코드베이스를 구체적으로 개발할 수 있는 인력.

또한 WinUI 3 이상에서는 XAML 방언도 개선되어야 한다고 추가합니다. 이전 앱에 대한 이전 버전과의 호환성을 유지하기 위해 사용 중인 XAML 버전을 지정하기 위해 버전 네임스페이스/Doctype을 도입할 수도 있습니다. 가 많이 있어요 작성할 필요 같은 XAML 덜 장황 또는 덩어리 일부 상용구를 만드는 만들 수 INotifyPropertyChanged 하나 개인 setter를 백업하는 대신 단지 말하는 간단한 property 속성 인에 NotifyPropertyChangedAttribute 하고하자 빌드 단계는 런타임 오버헤드를 피하기 위해 구현을 주입하거나 구성 요소를 단순화하기 위해 사용자 지정 컨트롤에 대해 DependencyProperties 를 삽입합니다. Razor 팀이 가지고 있는 좋은 부분에 대한 개선 사항 중 일부를 취할 수도 있습니다.

이러한 요청은 실현 가능하거나 불가능할 수 있지만 저는 XAML을 사랑하고 계속 개선되기를 원하므로 개발할 때 나와 우리 팀의 일부 고충(그러나 여전히 서비스 가능)을 언급하겠습니다.

@mdtauk 나는 파일 보안에 반대하지 않지만 기본 커널은 완전히 새로운 API 세트를 사용하고 win32 파일 API를 포기하는 것과 반대로 권한이 없는 곳에 쓰는 것을 방지해야 합니다. 또한 이것이 주제에서 벗어났다는 것을 알고 있지만 StorageFile/StorageFolder API는 파일 보안을 고려하지 않은 끔찍한 대체품입니다. 속도가 느리고 항상 런타임 파일 브로커를 통해 프록시됩니다. 또한 샌드박스 앱이 사용자의 문서 폴더에 쓰기 위해 MS 승인 특별 권한이 필요하다는 제한이 있어서는 안 됩니다. 예를 들어 AppContainer 노력에 대한 파일 스토리가 얼마나 엉망인지, 사용자의 숨겨진 LocalData 폴더를 제외하고는 sqlite DB를 생성하는 것은 불가능했습니다. 사용자가 파일을 만들고, 저장하고, 열고, 다른 이름으로 저장하려는 데스크톱 시스템의 경우 사용자 콘텐츠를 관리하는 방법을 사용자에게 재교육해야 하는 소프트웨어 개발자에게 부담이 되었습니다.

관리자 액세스에 관한 한 2018년 10월 릴리스에는 "allowsElevation"이 자격으로 추가되었으며 이는 의미가 있습니다. 일부 기능 세트에 대해 광범위한 시스템 수준 액세스가 필요한 경우 앱을 통해 사용자가 관리자로 실행할 수 있습니다. 우리 모두가 작고 귀여운 사진 편집기와 순서도 앱을 만드는 것은 아닙니다.

@MarkIngramUK 귀하의 의견에 감사드립니다. 한 가지 설명만. //Build 2019의 Sneak Peek에서 제시된 Xaml Desktop 개념은 WinUI Desktop으로 이름이 변경되었습니다. 이 새로운 Visual Studio 프로젝트는 Win32 앱 모델을 사용하고 WinUI를 프레젠테이션 프레임워크로 사용하며 네이티브 또는 관리형(.NET Core 3 사용)일 수 있습니다.

감사합니다 @marb2000 - 이것은 WinUI 3.0 기간 내에 있습니까?

@marb2000 by WinUI Desktop, Xaml Islands가 포함된 Win32 앱을 의미합니까? 이것은 어느 빌드 세션에 표시되었습니까?

WinUI 팀이 WinUI 3.0 이름 바꾸기와 함께 주의해야 할 한 가지: .NET에서 프로젝션된 유형의 이름을 바꾸면 프로젝션이 작동하지 않습니다. 유지 가능한 확장 가능한 시스템). 다음은 우리가 계획하는 유형 목록입니다. https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

이러한 유형이 아닌 다른 유형을 변경하려면 사용자가 개체를 새 인터페이스를 구현하는 새 개체로 래핑하거나 데이터를 새 유형에 복사해야 합니다. 특히 INotifyPropertyChanged 및 INotifyCollectionChanged 유형은 XAML 아일랜드와 관련하여 관심이 있고 다운스트림 지원을 제공합니다.

INotifyDataErrorInfo

INotifyDataErrorInfo와 같은 항목에 대해 새 네임스페이스를 도입하지 마십시오. 일반적으로 크로스 플랫폼이고 WinUI에 대한 종속성이 없어야 하는 보기 모델에서 사용해야 합니다. 이와 같은 다른 항목이 있는 위치를 정의해야 합니다(예: INotifyPropertyChanged 또는 INotifyCollectionChanged).

이 주제에 대해. Windows.UI.Xaml.Interop에는 이미 INotifyCollectionChanged 인터페이스가 있고 Windows.UI.Xaml.Data에는 INotifyPropertyChanged가 있습니다. 이 두 가지는 Microsoft 네임스페이스로 이동됩니다. 아마도 System.Runtime.WindowsRuntime 어셈블리는 WinUI에서 .Net으로 일부 매핑을 수행할 수 있습니다.

답장을 보내주셔서 감사합니다. 하지만 .NET Standard에 이미 System.ComponentModel이 있는 경우 Microsoft 네임스페이스에 필요한 이유는 무엇입니까? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky. NET은 UWP XAML로 앱을 만드는 데 사용할 수 있는 단 하나의 프레임워크입니다. 어떤 프레임워크를 사용하든 개발자가 사용할 수 있는 텍스트 필드 유효성 검사를 원합니다.

@mdtauk , 아니요, WinUI Desktop(이전의 Xaml Desktop)을 사용하면 아일랜드를 사용하지 않고 Win32와 함께 Xaml을 직접 사용할 수 있습니다.

@marb2000 응용 프로그램 패키징 프로젝트에서 Win32 창으로 AppX를 빌드하고 UWP 프로젝트와 동일한 쉬운 방법으로 WinRT 구성 요소를 포함할 수 있다면 좋을 것입니다. 리소스 추가 및 포함된 WinRT 구성 요소에서 헤더를 생성하는 cppwinrt 컴파일러와 같이 vcxproj 파일을 수동으로 편집하지 않고는 작동하지 않는 많은 것들이 있습니다.

이 새 UI에 중요한 또 다른 프로젝트는 INotifyPropertyChanged(C#/F#으로 시도) 자동 구현을 허용하는 Simon Cropp 의 _PropertyChanged.Fody_입니다. https://github.com/Fody/PropertyChanged 참조

다음과 같은 간단한 코드를 허용합니다.

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

    public event PropertyChangedEventHandler PropertyChanged;
}

UI에 바인딩하는 데 사용할 수 있습니다.

WinUI 3.0에서 보고 싶은 한 가지: 현재 UWP XAML 컴파일러( genxbf.dll )는 csproj, vbproj 또는 vcxproj 파일에서 참조할 때 MSBuild에서만 직접 호출할 수 있습니다. 이 기능을 호출하는 데 사용할 수 있는 명령줄 도구가 없기 때문입니다. Windows 10 SDK 다운로드에는 Visual Studio가 필요하지 않기 때문에 이것은 매우 이상한 결정으로 생각됩니다. (WDK 추가 기능에는 Visual Studio 대상도 포함되어 있지만 이러한 대상은 모두 VS와 독립적으로 사용할 수 있는 명령줄 도구를 호출합니다.) 예를 들어 XbfCompiler.exe 및 XbfCodeGen.exe 추가해 주시면 감사하겠습니다. SDK의 bin 디렉토리로 이동합니다. (전자의 EXE는 XAML 파일을 XBF 파일로 컴파일하고 후자는 코드에서 XAML 유형을 참조하는 데 필요한 코드 숨김 파일을 생성합니다.) 이것은 CMake 또는 다른 비 Visual을 사용하는 C++ 프로젝트에서 주로 유용합니다. Studio 빌드 도구이지만 필요한 경우 C# 및 VB.NET 프로젝트에도 사용할 수 있습니다. 감사 해요!

@MarkIngramUK WinUI Desktop에 대해 자세히 알아볼 수 있는 곳을 아시나요? 해당 Build 2019 세션은 온라인으로 볼 수 없습니다. 이 리포지토리에 연결되어야 하는 중요한 정보처럼 들립니다.

@mdtauk 빌드 참석자 전용인 이른바 Sneak Peek에서 언급되었습니다. Afaik 녹음이 없습니다. 나도 거기에 없었지만 슬라이드가 있습니다 - 아마도 최고의 슬라이드 :-) - Twitter에서 사용 가능: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk WinUI 3 로드맵에는 Build Snek peek에서 보여진 것보다 훨씬 더 최신인 최신 정보와 다이어그램이 있습니다. "XAML 데스크톱"이나 "WinUI 데스크톱"과 같은 것은 없습니다... 사진이 찍힌 슬라이드에서 혼란스러운 단어 선택이었을 뿐입니다. 전달되고 있는 개념(로드맵은 이를 보다 명확하게 설명하려고 함)은 WinUI 3에 대해 WinUI 3을 사용하여 새로운 기존 데스크탑/Win32 모델 앱을 생성하는 프로젝트 템플릿을 UI에 사용할 수 있도록 만들기 위해 노력하고 있다는 것입니다. (오늘날 기존 Desktop/Win32 모델 위에 WinForms, WPF, MFC 등의 UI 프레임워크용 템플릿이 있는 것처럼) WinUI 3를 사용하는 업데이트된 UWP/WinRT 모델 앱 프로젝트 템플릿 외에도 명확히하는 데 도움이?

3.0 로드맵 은 다음 전략에 대해 매우 합리적으로 보입니다. 모든 Windows 클라이언트 앱에서 XAML 및 "현대적인" WinUI 컨트롤을 사용하도록 설정합니다.

그러나 이 전략은 오늘날 시장의 현실을 고려하면 근시안적으로 보입니다. 많은 앱 개발에서 Android와 iOS가 주요 대상이고 Windows가 있으면 좋습니다. .NET 개발자의 경우 Xamarin은 적절한 Android 및 iOS 지원을 제공하지만 Windows 지원은 하위 수준입니다. 따라서 기본 모바일/데스크톱 앱의 경우 Win UI 3.0은 .NET 개발자를 위한 플랫폼 간 개발을 단순화하기 위해 아무 것도 하지 않습니다.

내가 정말로 보고 싶은 것은 진정으로 보편적인 열망을 가진 진보적인 XAML 방언입니다. XAML을 사용하여 .NET 앱을 작성할 수 있어야 하며 해당 앱을 Windows, iOS 및 Android에서 실행할 수 있어야 합니다. 앱은 각 플랫폼에서 진정으로 일류여야 하며 필요에 따라 기본 요소에 액세스할 수 있어야 합니다. 언급했듯이 Xamarin은 좋은 시작이지만 XAML의 방언이 매우 다르고 Windows 지원이 열악하며 수행 중인 작업이 도움이 되지 않습니다.

따라서 Windows용 최신 UI 플랫폼을 계속 제공하고 계시는 것이 좋습니다. 다양한 앱에서 쉽게 사용할 수 있게 해주셔서 좋습니다. 크로스 플랫폼 지원을 원하지 않는 것은 좋지 않습니다.

선택적으로 일시 중단 + 삭제 표시와 같은 레거시 모바일 애플리케이션 수명 주기 동작을 비활성화하거나 옵트아웃합니다.

현실은 UWP가 데스크톱 환경이고 적어도 게임의 경우 사용자가 앱을 최소화하는 경우가 많아 일반적으로 앱을 일시 중단/삭제 표시하는 경우가 많습니다. 이것은 혼란스러운 경험이며 win32 데스크탑 앱이나 게임과 매우 다릅니다. 아직 만료될 가능성이 있는 연장 연기를 요청하는 것만으로는 이를 원활하게 처리할 수 없습니다.

이 수명 주기는 일부 앱에 유용하지만 다른 앱에는 해롭습니다. 이상적으로 데스크톱 앱 또는 게임은 앱이 일시 중단+삭제 표시 수명 주기 모델을 선택 해제할 수 있는 기능을 선언할 수 있어야 합니다. 그러면 최소화될 때 궁극적으로 일시 중단되지 않습니다.

@natemonster

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

데스크톱 장치에서 ExtendedExecutionReason.Unspecified로 생성된 확장 실행 세션에는 배터리 인식 시간 제한이 있습니다. 장치가 벽 전원에 연결되어 있는 경우 확장된 실행 기간의 길이에 제한이 없습니다. 장치가 배터리 전원으로 켜져 있는 경우 확장된 실행 시간은 백그라운드에서 최대 10분까지 실행될 수 있습니다.

태블릿 또는 랩톱 사용자는 앱 설정별 배터리 사용량에서 앱이 백그라운드 작업을 실행하도록 허용 옵션을 선택한 경우 배터리 수명을 희생하면서 동일한 장기 실행 동작을 얻을 수 있습니다.

@TonyHenrique Fody 를 언급 할 때 입니까 , 아니면 WinUI에 내장되어야 한다는 말씀입니까?

아이템이나 라이브러리 템플릿도 재미있습니다! Windows 템플릿 스튜디오와 같이 시간이 지남에 따라 추가하는 것을 고려할 수 있는 추가 상용구 및 시작 코드를 제공하는 것에 대해 지금까지 답변에 몇 가지 좋은 점이 있습니다.

@Jesbis 저는 Windows Template Studio의 핵심 기여자이며 우리가 미래에 할 일과 WPF 지원을 도입하는 방법에 대한 관점에서 WinUI 로드맵을 보고 있습니다. ;)

어떤 종류의 종속성 업데이트가 더 가치가 있습니까? 예를 들어 호환되는 새로운 NuGet 패키지 버전을 찾고 계십니까?

NuGet 업데이트를 감지할 수 있으면 더 유용하지만 업데이트를 수행할 때 다른 잠재적인 호환성 문제가 있습니다. 나는 새 버전을 감지하고 자동 변환을 낮은 우선 순위로 만들 것입니다. 고려 사항이 너무 많아서 그 자체로 큰 프로젝트가 될 것이며 이러한 도구를 사용하는 플랫폼에 시간을 투자하는 것이 좋습니다.

@mrlacey 저는 Fody가 흥미로운 솔루션이라고 생각 하고 _INotifyPropertyChanged_ 상용구 코드를 피하는 더 나은 방법이 필요하다고 생각하기 때문에 Fody를 언급했습니다 . 일부 속성이 변경될 때 자동으로 이벤트를 발생시키는 Reactive 개체의 개념에 대한 MS 지원 솔루션이 있으면 좋을 것입니다.
C# 클래스와 F# 레코드에서도 작동하지만 몇 가지 어려움이 있습니다.
따라서 WinUI 로드맵에도 이것이 있어야 합니다.

참고: F# 레코드를 사용하여 데이터 엔터티를 정의하고 XAML UI에 직접 바인딩할 수도 있으면 좋을 것입니다. F# Records + Fody + DataBinding을 문제 없이 사용할 수 있다면 정말 좋을 것입니다.

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

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

이것은 C#에서 오는 사람들에게 더 친숙할 것입니다.
또 다른 접근 방식은 Elmish 방식입니다. 둘 다 흥미롭고 지원될 수 있다고 생각합니다.

@tonyhenrique / @mrlacey Fody 항목 (OAP)은 범위를 벗어나야 한다고 생각합니다. WinUI 팀은 이미 충분히 가지고 있고, 나는 별도의 프로젝트에서 짜는 것이 더 낫다고 생각합니다(개선의 경우 훨씬 더 빠른 릴리스 주기).

그리고 이것은 실제로 모델의 .NET(IL) 구현 세부 정보라고 생각합니다. 실제로 WinUI와 관련이 있는 것은 아닙니다(변경 이벤트를 수신할 수 있지만). 제 제안은 그것들을 따로 보관하는 것입니다. 예를 들어, 저는 Catel을 사용하며 모든 것이 올바르게 짜여졌는지 확인하기 위해 자체 Fody weavers가 있습니다.

내가 정말로 보고 싶은 것은 진정으로 보편적인 열망을 가진 진보적인 XAML 방언입니다. XAML을 사용하여 .NET 앱을 작성할 수 있어야 하며 해당 앱을 Windows, iOS 및 Android에서 실행할 수 있어야 합니다. 앱은 각 플랫폼에서 진정으로 일류여야 하며 필요에 따라 기본 요소에 액세스할 수 있어야 합니다.

그 방향으로 나아가기 위한 오랜 제안이 있습니다: .NET 5용 크로스 플랫폼 UX - 원본 제목 Cross platform UX for .NET Core 3.0 . 이에 대한 커뮤니티의 압도적인 지원은 분명하며 MSFT가 이것이 .NET에서 작동하는 모든 UI 프레임워크를 개발하는 최선의 방향임을 깨달을 수 있기를 바랍니다. 서로 다른 플랫폼 그룹에 대해 별도의 코드베이스를 유지하고 .NET에서 지원하는 서로 다른 UX 프레임워크를 기반으로 별도의 개발자 기술 세트를 강제로 생성할 이유가 거의 없습니다.

모든 플랫폼을 위한 단일 UX를 생성함으로써 우리는 프레임워크 개발의 모든 비효율성을 없애고 개발자 채택에 대한 장벽을 낮춥니다.

@mfeingol / @4creators

앱은 각 플랫폼에서 진정으로 일류여야 합니다.

시작하려면 Windows에서...

지금은 2019년, 빠른 네이티브 UI를 원하고 CreateWindowExW , GDI 등으로 사용자 인터페이스를 만드는 것을 심각하게 고려하고 싶지 않습니다.

이제 WinUI 3.0 이상에서는 코드가 Windows 10에서 분리되었으므로 향후 WinUI가 Linux 및 Mac에서 작동할 계획이 있습니까?

@jesbis Touch 상호 작용 은 WinUI 3.0에서 유지됩니까?

설명 감사합니다. 3.0이 작동하는 방식은 Community Toolkit을 사용하는 대신 WinUI에 Xaml Islands를 포함하는 것이라고 가정했습니다.

XAML + Win32가 되면서 특히 Windows Core OS가 XAML에서 셸을 다시 작성하는 것이 더 합리적입니다.

내가 지금 이해하는 것처럼 이 풍부한 Win32 API 액세스는 C 및 C++로 | .NET에 의존하는 C#의 모든 것(지금은 모두 .NET Core임).

아마도 이러한 Win32 API에 액세스하는 안전하고 간단한 방법과 앱 UI를 표시하기 위한 더 많은 진입점이 있어야 합니까?

• WinUI 3 앱용 시스템 트레이 XAML 플라이아웃

• Hololens/Xbox/Surface Hub/IoT 등을 위한 간단한 선택기 UI

• 업데이트된 XAML 사용자 지정 가능한 공통 파일 대화 상자 및 폴더 선택기

• Win32 API에 대한 간단한 C# .NET 액세스

• Win32 및 WPF 컨트롤 크기 조정과 일치하는 모든 XAML 요소에 대한 컴팩트 설정(이렇게 하면 프레임워크가 편안하게 함께 앉는 데 도움이 됩니다)

• WinUI 사용 시 컨트롤 스타일/글꼴/액센트 브러시/아크릴 일치

• WinRT/Mobile 수명 주기가 필요한 장치에 대한 명확한 정의

• Windows에서 Xbox 앱 개발 및 테스트를 위해 기본 제공되는 Xbox Next 컨트롤 스타일

• 기본적으로 저장 및 단일 exe/MSI/APPX 패키징 및 다운로드 지원, 설치자 없음, 기본적으로 100년 유형 파일 시스템 가상화

• WinForms WinUI 3.0 - 간단한 UI, MFC에 대한 액세스, 마우스 및 키보드 전용

• WPF WinUI 3.0 - 고밀도 UI, 3D 렌더링, DPI 인식, 시뮬레이션된 터치 및 기본 잉크 지원

• Xaml WinUI 3.0 - 풀 터치, MR, 게임패드, 잉크, 음성, 마우스, 키보드. 조밀하고 단순한 UI. 새로운 윈도우 지원. MR 3D 렌더링. 선택적 관리형 수명 주기 또는 데스크톱 수명 주기. 메모장, 참 지도, 페인트, 파일 탐색기와 같은 받은 편지함 앱의 Win32 버전과 함께 셸 및 재작업된 받은 편지함 앱에 대한 모든 세계의 기본이 오픈 소스이며 스토어에서 사용할 수 있습니다.

터치 상호 작용은 WinUI 3.0에서 유지됩니까?

@r7dev 네, 동일한 수준의 터치 지원을 유지할 계획입니다.

F#은 WinUI 3.0 로드맵에서 무시됩니다. Microsoft는 다시 한 번 자사 제품 중 하나를 무시합니다.

Win32 API 생각

내가 또한 생각한 것은 win32가 너무 붙어있는 이유입니다. 나는 이것이 레거시 프로젝트 때문이라는 가정이 있다고 생각하지만 실제로는 그보다 훨씬 더 깊습니다. Win32 ABI는 선택한 언어, nodejs, python, rust, go, ruby, C#, C++ 등과 연결하기가 매우 쉽습니다. 예를 들어 내 핵심 프로젝트가 녹슬고 창을 생성하고 싶은 경우 출력을 관리하기 위해 Rust 개발자로서 win32 API 세트에 액세스하고 동일한 언어로 프론트 엔드를 구축하는 것은 매우 강력합니다.

OS X에서 AppKit에 액세스하려면 objc_msgSend C API를 연결하고 전체 obj-c 인프라에 액세스하기만 하면 됩니다. 위의 모든 언어는 이를 연결하는 역할을 훌륭하게 수행했으며 선택한 언어로 쉽게 작성하고 매력적인 것을 생성할 수 있었습니다.

따라서 WinUI 3.x가 낮은 대기 시간, 낮은 메모리, 높은 품질의 Win32 UI에 액세스하기 위한 진정한 경로가 되도록 하려면 다른 언어 유지 관리자가 인프라에 접근할 수 있는 용이성을 고려해야 합니다.

UI 일관성

UI를 시스템에서 분리할 계획이라면 각 OS 업그레이드와 일관되게 유지되는 UI에 대한 계획은 무엇입니까? Apple이 AppKit 또는 iOS에서 그림자 및 그라디언트를 조정할 때 시스템 프레임워크에 의존하는 앱은 이러한 조정을 모두 상속하고 일관성을 유지합니다. 또한 3년 전에 UI 인프라에 잠긴 앱이 일부 새로운 시스템 서비스에서 제대로 작동하지 않을 수 있으므로 시간이 지남에 따라 다른 호환성 계층을 갖게 될 수 있기 때문에 시스템 전체 경험을 추가하기가 어려울 것입니다.

항상 선택해야 하는 기능이 있을 것입니다. 저는 다크 모드를 앱이 이를 위해 설계되지 않았다면 옵션으로 제공하는 것이 정말 의미가 없는 것으로 생각할 수 있지만 여전히 시간이 지남에 따라 변경되는 시스템 구성 요소에 대한 조정.

바이너리 크기

이 모든 UI.dll을 우리 프로젝트와 함께 제공하기 위한 계획된 스토리는 무엇입니까? 이러한 것들이 우리 프로젝트와 함께 제공되어야 하는 40MB의 런타임이 될까요? 프로젝트가 중단되면 오래된 UI 프레임워크를 사용하기 때문에 구식으로 보이기 시작합니까?

C++의 장점 중 하나는 코드베이스에 따라 최소한의 라이브러리 오버헤드가 있다는 것입니다. 확실히 여기에서 나오는 모든 단일 앱에 WinUI 3.x가 필요하다면 40mb x 앱 수가 될 것입니다.

바이너리 크기

WinUI는 .NET과 마찬가지로 이미 종속성입니다. 이미 시스템 전체의 라이브러리입니다. :)
당신은 중복된 dll을 가지고 있지 않으며 당신은 그것을 가지지 않을 것입니다.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

"저도 생각한 것은 win32가 계속 멈춰있는 이유입니다. 이것이 레거시 프로젝트 때문이라는 가정이 있지만 실제로는 그보다 훨씬 더 깊습니다. Win32 ABI는 선택한 언어와 연결하기가 매우 쉽습니다. , nodejs, python, rust, go, ruby, C#, C++ 등. 예를 들어 내 핵심 프로젝트가 녹에 있고 출력을 관리하는 창을 생성하려는 경우 녹 개발자로서 매우 강력합니다. win32 API 세트에 액세스하고 동일한 언어로 프런트 엔드를 구축하십시오."

새 언어에 대한 WinRT 지원을 구현하는 것은 극복해야 할 큰 문제이기 때문에 혼합 백입니다. 일단 수행하면 새 API에 대한 자동 생성된 형식화된 바인딩으로 끝납니다. 저는 최근에 Win32와 WinRT를 연결하는 Rust 프로젝트(Win32 창에서 Composition API 사용)에 대해 작업해 왔으며, 나머지 부분은 서툴게 작업해야 했지만 Win32 부분은 확실히 전반적으로 더 고통스러웠습니다. 클래스 상속과 같은 일부 WinRT 기능에 대한 Rust 지원 부족. (Win32 내에서 컴포지션을 사용하는 것이 이제 가능하다는 것은 확실히 도움이 됩니다. 전체 앱 모델을 한 번에 처리하지 않고도 이 기능에 대한 지원을 점진적으로 개선할 수 있기 때문입니다.)

아마도 가장 큰 문제는 낮은 수준의 WinRT ABI 세부 정보에 대한 문서가 일종의 무질서하고 세계/커뮤니티에서 이에 대한 이해나 인식이 거의 없다는 것입니다. 하지만 xlang 프로젝트를 통해 이 상황이 개선되기를 바랍니다.

어떤 템플릿에 가장 관심이 있습니까?

현재 저는 빈 앱(유니버설 Windows) 프로젝트에서 시작하는 것을 선호합니다. 저는 미리 구성된 프레임워크가 있는 템플릿도 좋아하지만 빠르게 시도하고 싶을 때만 사용합니다. UWP용 "주 메뉴" 템플릿 및 MDI 템플릿도 좋습니다(이러한 템플릿은 WinForms에도 존재하기 때문에).

데스크톱 앱 현대화를 위한 Xaml Islands를 알고 계셨습니까?
Windows 10에서 확장된 이전 버전과의 호환성으로 인해 Xaml Islands가 더 유용합니까?

예, Xaml Island를 알고 있습니다. 가능하다면 순수 WPF 또는 순수 UWP 앱을 사용하려고 합니다. 그런 기능이 필요한 상황은 아니었습니다.

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

예, 안정적으로 작동하는지 확인하십시오! 나는 그런 좋은 기능을 높이 평가하지 않는 많은 의견에 놀랐습니다. 또한 이 기능은 WinUI 3.0 업데이트가 가능한지 확인하고, XAML 코드를 채택하고, 네임스페이스를 조정하고, 필요한 WinUI 너겟을 설치할 수 있습니다.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

WinUI 3.0에서 완전히 작동하도록 컨트롤의 네임스페이스만 변경할 것으로 예상합니다. WinUI 3.0으로 업그레이드하는 데 많은 시간을 투자하고 싶지 않습니다.

앱 코드와 함께 쉽게 다시 컴파일 및 업데이트할 수 없는 UWP Xaml 제어 라이브러리 또는 WinRT 구성 요소를 만들거나 사용합니까?

타사 UWP Xaml 제어 라이브러리(예: Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement )를 사용하고 있습니다. Dockpanel과 같은 타사 라이브러리의 간단한 컨트롤을 혼자서 WinUI 3.0으로 업그레이드할 수 있다고 생각합니다.

WinUI 3에서 UWP Xaml 구성 요소를 사용하는 데 선호하는 솔루션은 무엇입니까?

• UWP용 Visual Studio에서 "WinUI 3.0이 포함된 빈 앱" 프로젝트 템플릿을 만듭니다. WinUI 3.0 종속성은 WinUI 2.0과 같이 nuget으로 설치됩니다.

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . 나는 모든 기본 컨트롤을 얻는 한 그러한 솔루션을 절대적으로 선호합니다. Windows.UI의 모든 클래스가 Microsoft.UI 네임스페이스에 동등한 클래스를 가질 것으로 예상합니다.

WinUI 3.0의 주요 주제는 컨트롤과 Windows 10 호환성에 관한 것이었습니다. 이 호환성은 제가 맞다면 XAML Island를 통해 UWP 및 WPF 또는 WinForms에서 사용할 수 있습니다. UWP XAML 마크업에 추가 기능이 추가될 가능성이 있습니까?

• 스타일 트리거 누락
• 스타일 `BasedOn={StaticResource {x:Type TextBlock}} 누락
• DataTypes가 있는 정의된 DataTemplates는 WPF와 같이 자동으로 적용되지 않습니다(Key를 통해서만).
• 매초 Windows.UI.Xaml.Controls 컨트롤(TextBlock, Border,...)이 봉인된 것으로 선언
• WPF 패리티용 마크업 확장
• 이것은 이미 언급했지만 한 번 더 언급하겠습니다. UWP가 System.ComponentModel.IDataErrorInfo를 사용하지 않는다는 것은 슬픈 일입니다. 그렇게 하면 내 모델 프로젝트를 UWP 솔루션과 공유할 수 없습니다.
• ReportControl(엔터프라이즈 애플리케이션용)

저는 WinUI 3.0과 이전 버전과의 호환성을 정말 기대하고 있습니다!

F#은 WinUI 3.0 로드맵에서 무시됩니다.

UWP XAML 마크업에 추가 기능이 추가될 가능성이 있습니까?

@Happypig375 , @mfe-:

로드맵은 초기 3.0 릴리스만 다루며 초기 릴리스에서는 소수의 새로운 기능과 함께 기존 기능에 대한 패리티 및 이전 버전과의 호환성에 주로 중점을 둡니다.

더 나은 F# 지원이나 새로운 마크업 기능과 같은 다른 새로운 기능이 중요하다고 생각 되면 새 기능 요청을 열어 별도로 추적할 수 있도록 하십시오!

매초 Windows.UI.Xaml.Controls 컨트롤(TextBlock, Border,...)이 봉인된 것으로 선언되는 이유는 무엇입니까? UWP가 있는 WinUI 3.0에서는 이 작업을 수행하지 마십시오.

잠금 해제 컨트롤은 실제로 3.0에 포함되기를 희망하는 소수의 새로운 기능 중 하나입니다 😊

언어와 관련하여 혼합 및 일치하는 것이 깔끔할 것입니다(패키징 전에 모든 것이 컴파일되면 괜찮을 것입니다).

일부 백엔드 논리에 사용되는 F# - 데이터 바인딩 및 UI 코드를 위한 C# - 컨트롤을 위한 C++ 및 일부 저가 Win32 후크 또는 WinForms 대화 상자를 시작하는 데도 사용됩니다.

모든 코드 언어는 동일하고 상호 교환 가능하며 WinUI 3.0이 모든 UI를 처리합니다.

xlang입니다 😉

xlang입니다 😉

@MarkIngramUK 흠, 단일 프로젝트에서 여러 언어의 코드 파일을 허용하는 것이 아니라 각 언어를 추상화하는 언어 간의 다리라고 생각했습니다.

나는 xlang의 목적을 이해하기 위해 고군분투했습니다 - 리포지토리에서 일어난 업데이트에 대해 설명합니다(그러나 여전히 내 감시 목록에 있습니다)

xlang은 컴파일 전이나 후에 작동합니까? 투영될 수 있는 자체 추상 언어입니까, 아니면 기존 코드 파일 사이에 위치합니까?

예, 단일 프로젝트에서 언어를 혼합할 수 없습니다. 그것은 다리이지만 여전히 그러한 목적에 유용합니다.

@MarkIngramUK 컴파일할 수 있는 코드가 포함된 경우 그렇게 생각합니다.

PInvoke 및 기타 .NET 트릭 없이 C#을 사용하여 기본 Win32 기능에 액세스할 수 있다면 좋을 것입니다.

@jesbis 솔직히 이 프로젝트의 크로스 플랫폼 측면에 더 관심이 있습니다...

처음에는 "Windows"가 아닌 좀 더 _일반적인_ 이름으로 이름을 바꿔야 한다고 생각합니다.

초기 구현은 Win32와 UWP/Xamarin 앱 및 Windows에 엄격하게 초점을 맞춰야 하지만 OSS만 사용하고 처음부터 "Windows 전용" 프레임워크처럼 호출하도록 하면 UWP와 같은 견인력을 얻지 못할 것입니다. 그렇지 않았으며 다른 플랫폼의 개발자는 결코 그것에 관심을 갖지 않을 것입니다.

.Net 5의 목표가 기본적으로 .Net 1.0 이후로 모든 사람들이 항상 기대했던 "One .Net Everywhere"가 되는 것이라면 "Anything but Win UI" 프레임워크의 기반이 교차 플랫폼에서 시작되어야 합니다.

올바르게 만드는 방법에 대한 아주 좋은 예는 Google Flutter입니다. Flutter는 초기 단계에 있지만 핵심(일명 Flutter Engine)이 100% 크로스 플랫폼이고 모든 곳(IoT, Win, OSX, 이제는 웹 포함!)에서 작동한다는 사실 때문에 많은 관심을 받았습니다.

그것은 바로 내 2c입니다. Xaml 작업으로 돌아가고 싶지만 UWP에서와 같은 줄을 계속 유지하면 올바른 견인력을 얻지 못하고 결국 다른 시도가 필요한 WPF를 다시 작성하려는 또 다른 시도가 될 것입니다. 미래 등등.

저를 화나게하지 마시고 제 의견을 나쁜 비판으로 받아들이지 마십시오. .Net 세계의 UI에 대한 노력이 Flutter, .Net Core 3.0/.Net 5, 심지어 Blazor와 같은 것을 얻기를 바랍니다.

참고로 저는 .Net World에 옵션이 없기 때문에 C# 및 .Net Core에서 Flutter 엔진을 완전히 재작성/포팅하는 프로젝트를 시작했습니다...

앗, CoreUI 는 좋은 이름입니다...

그 제안에 대해 Jake Helfert에게 경의를 표합니다 😄

💃

앗, CoreUI 는 좋은 이름입니다...

그 제안에 대해 Jake Helfert에게 경의를 표합니다 😄

💃

CoreUI가 .NET Core와 혼동될 수 있음

WinUI는 Windows에 매우 중점을 두고 있지만 그 안에 있는 XAML 프레임워크는 Metal(iOS 및 macOS) 또는 Vulkan(Android)용 렌더러를 얻을 수 있으며 FabricWeb은 다른 플랫폼을 처리하는 PWA/ChromeOS 방식이 될 수 있습니다.

팀이 프레젠테이션 플랫폼을 가져오기로 선택하고 Xland 또는 Xamarin이 플랫폼 간 앱의 런타임을 처리할 수 있다면.

받은 편지함 UWP UI에서 WinUI 3.0으로의 마이그레이션에 대해 @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP )의 최근 블로그 게시물을 인용

재미있는 요점: UWP에 일어나고 있는 일은 그것이 죽고 있다는 것이 아닙니다. Microsoft는 최고의 부품을 우리가 필요로 하는 곳으로 가져오기 위해 선회하고 있습니다. 이것은 실제로 이전에 발생했지만 불행히도 피벗을 수행할 기회로 사용되지 않았습니다. 실버라이트를 기억하시나요? .NET Core의 플랫폼 간 CLR이 어디에서 왔는지 맞춰보세요. 그리고 Silverlight의 많은 코드도 UWP에 포함되었습니다. 그들이 피벗하고 "예, Silverlight가 소비자용 제품에는 적합하지 않다는 데 동의하지만 엔터프라이즈 영역에서는 번창하고 있으므로 이를 기반으로 구축하고 .NET Core 및 Windows Store로 발전시킬 것입니다."라고 말했습니다. 불행히도 그것은 순조롭게 진행되지 않았으며 많은 사람들이 여전히 PTSD로 고통 받고 있으며 Microsoft가 모든 기술을 죽이는 것으로 보이는 모든 조치를 경계합니다.

개발자와 코드베이스에 좋은 방향을 제시하지 않고 기존 프레임워크를 종료하거나 재설정하는 것으로 인식되는 것은 기존 프레임워크의 개발자에게만 영향을 미치는 것이 아니라 모든 사람들이 왜 새로운 것은 그냥 같은 운명을 맞이하지 않습니다. 이것은 특정 제안된 마이그레이션 접근 방식에 대한 언급이 아니라 기존 받은 편지함 UI 프레임워크를 사용하는 사람이 많지 않기 때문에 마이그레이션이 중요하지 않다는 의견에 대한 응답입니다. 고려 사항은 이뿐만이 아닙니다!

@weitzhandler WinUI 3.0은 다양한 Win32, .NET Core 및 UWP 프레임워크를 단일 XAML 프레임워크와 결합하고 WPF, WinForms 및 MFC++와의 상호 운용에 관한 것입니다.

Windows의 XAML은 Direct X로 렌더링됩니다.

동일한 XAML을 .NET Core와 결합하여 다른 플랫폼에서 작동하도록 하려는 경우. 해당 플랫폼에 대한 새 렌더러를 작성해야 합니다. iOS 및 macOS는 Metal을 Direct X에 상응하는 것으로 사용합니다. 안드로이드는 Vulkan을 사용합니다. Linux가 렌더링을 어떻게 처리하는지 전혀 모르지만 Open GL일 뿐입니다.

마이크로소프트는 그것이 이해가 되지 않기 때문에 스스로 그렇게 하고 싶지 않을 것입니다. 그러나 WinUI 3.0은 오픈 소스가 될 것이므로 다른 사람들이 플랫폼 간에 가져오도록 선택할 수 있습니다.

@mdtauk

해명해주셔서 감사합니다. Flutter는 아마도 제 미래일 것입니다.

그건 제 이해일 뿐입니다. 제가 오해할 수도 있습니다.

Flutter는 향후 Windows 지원을 받을 예정입니다. 그리고 React Native 지원은 Windows에도 제공됩니다. 또한 웹 HTML 및 Javascript 세계에 투자한다면 PWA가 있습니다.

나에게 전체 WinUI 이야기는 웹을 포함하여 플랫폼 간(macOS, iOS, Android)에서 실행되는 기본 하위 집합을 고려하고 더 나은 F# 지원 및 프로젝트 템플릿(포함 F# 레코드에 대한 XAML 양방향 바인딩 및 더욱 기능적인 Elmish 방식)

XAML은 HTML 이 HTML 앱처럼 가장 기본적인 도구 앱에도 100mb 이상을 사용하지 게임 엔진이 시작하는 데 사용하는 것과 같은 불가지론적 렌더링 백엔드가 필요합니다.

이 UWP에 초점을 맞춘 XAML이 XAML과 함께 몇 년 동안 제 회사나 제가 개인적으로 겪었던 문제를 해결하고 있다면 없습니다. TBH MS는 UI에 대해 완전히 잘못된 방향으로 가고 있으며 빠르게 진행되지 않습니다(많은 사람들에게 귀중한 시간을 많이 낭비합니다). 이 UWP XAML 해커는 내가 보여 주는 사람들에게 잘 어울리지 않습니다... 이는 XAML 채택에 대한 끝없는 반발을 의미하기 때문에 슬프고 이 시점에서 더 이상 논쟁할 여지가 없습니다.

내 의견으로는 XAML을 저장하는 유일한 방법은 다음과 같습니다.

• .NET Core 및 C/C++에 대한 새로운 불가지론적/이식 가능한 프레임워크 기반을 만듭니다.
• 누구나 pull-request를 통해 확장할 수 있는 불가지론적 렌더링 추상화 계층을 만듭니다.
• HTML과 마찬가지로 XAML이 단일 창 앱 개념에 초점을 맞추도록 하되(게임에서도 마찬가지임) 그러나 다중 창 등을 위한 확장된 데스크톱 기능을 허용합니다.

간단히 말해서 XAML 적응이 제외되기 전에 하나로 결합되어야 하는 두 가지 조건이 있습니다.

1 MS는 XAML 프로젝트를 지원해야 합니다. 그렇지 않으면 사람들이 프로젝트가 실패할까봐 두려워합니다.

2 크로스 플랫폼이어야 합니다. 그렇지 않으면 모두가 엄청나게 부풀려진 HTML 런타임에 갇히게 될 것입니다.

어쨌든 내 2센트이고 WinUI 3.0이 올바르게 설계되었다면 이식이 가능할 것입니다. 이 시점에서 idk 무엇을 느껴야 합니다.

여기에 크로스 플랫폼에 대한 몇 가지 의견이 있으며 WinUI가 성공하려면 크로스 플랫폼이 필요하다고 확신할 수 없습니다. 어쨌든 Mac이나 Linux에서는 잘 작동하지 않을 것입니다. 왜냐하면 두 플랫폼 중 하나에서 기본적으로 느껴지지 않을 만큼 충분히 다르기 때문입니다. 이 프로젝트는 Windows 내부가 어떻게 작동하는지에 대한 풍부한 지식을 가진 팀이 소유하고 있으며 Mac 또는 Linux에서 동일한 정도로 제대로 작동하도록 하는 방법을 알아내는 것은 그들이 주의를 산만하게 할 것입니다.

또한... Fluent on Mac은 투박하게 느껴질 것입니다. iTunes를 보면 Apple은 전체 UI 시스템을 Windows로 이식해야 했고 확실히 부적절하게 느껴졌습니다. 글꼴 렌더링은 다르며 애니메이션 곡선과 그림자 및 색상 선택은 Win10에서 너무 부적절하게 느껴집니다. 내 말은, 그것은 괜찮고 사용 가능하지만 데스크탑 UI를 에뮬레이트하지 않고 후드 아래에서 웹 브라우저를 사용하는 Spotify를 선호합니다. Mac에서는 모서리가 둥글고 표시 효과가 없는 데스크탑에서 정사각형 구성 요소가 있는 표시 스포트라이트를 보는 것이 너무 힘들 것입니다.

아니요, 이 프로젝트는 Windows 소프트웨어를 구축하려는/필요한 개발자를 위해 기본 Windows 소프트웨어를 만드는 동급 최고의 방법을 제공하는 데 중점을 두어야 한다고 생각합니다. 크로스 플랫폼 문제는 Electron/Typescript 팀에 맡겨 해결하세요.

여기에 크로스 플랫폼에 대한 몇 가지 의견이 있으며 WinUI가 성공하려면 크로스 플랫폼이 필요하다고 확신할 수 없습니다. 어쨌든 Mac이나 Linux에서는 잘 작동하지 않을 것입니다. 왜냐하면 두 플랫폼 중 하나에서 기본적으로 느껴지지 않을 만큼 충분히 다르기 때문입니다. 이 프로젝트는 Windows 내부가 어떻게 작동하는지에 대한 풍부한 지식을 가진 팀이 소유하고 있으며 Mac 또는 Linux에서 동일한 정도로 제대로 작동하도록 하는 방법을 알아내는 것은 그들이 주의를 산만하게 할 것입니다.
또한... Fluent on Mac은 투박하게 느껴질 것입니다. iTunes를 보면 Apple은 전체 UI 시스템을 Windows로 이식해야 했고 확실히 부적절하게 느껴졌습니다. 글꼴 렌더링은 다르며 애니메이션 곡선과 그림자 및 색상 선택은 Win10에서 너무 부적절하게 느껴집니다. 내 말은, 그것은 괜찮고 사용 가능하지만 데스크탑 UI를 에뮬레이트하지 않고 후드 아래에서 웹 브라우저를 사용하는 Spotify를 선호합니다. Mac에서는 모서리가 둥글고 표시 효과가 없는 데스크탑에서 정사각형 구성 요소가 있는 표시 스포트라이트를 보는 것이 너무 힘들 것입니다.
아니요, 이 프로젝트는 Windows 소프트웨어를 구축하려는/필요한 개발자를 위해 기본 Windows 소프트웨어를 만드는 동급 최고의 방법을 제공하는 데 중점을 두어야 한다고 생각합니다. 크로스 플랫폼 문제는 Electron/Typescript 팀에 맡겨 해결하세요.

다른 플랫폼에서 완전한 Fluent 디자인을 원하는 사람은 아무도 없다고 생각합니다. 오히려 플랫폼 간의 공통 코드를 최대화할 수 있기만 하면 됩니다.

이것은 Microsoft 디자인 팀에서 이미 해결한 문제입니다. Fluent 웹사이트는 "기본적으로 iOS이면서 여전히 고유한 Fluent인 맞춤형 앱을 디자인하고 빌드합니다"라고 명시적으로 말합니다. Fluent 문서는 기본 컨트롤 스타일을 사용해야 함을 보여줍니다.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

피해야 할 것은 각 플랫폼에 대해 완전히 별도의 UI를 설계하고 유지 관리해야 하는 것입니다. 즉, 표면적으로 동일하게 보일 필요는 없지만 공통 레이아웃을 공유해야 하며 UI 디자이너는 가능한 한 많이 재사용할 수 있어야 합니다. 실제 스타일은 Windows 10 시스템 스타일과 일치할 필요가 없습니다.

본질적으로 원하는 것은 Fluent 디자인을 다른 플랫폼으로 가져오는 것이 아니라 전체 UI를 다시 만들 필요 없이 다른 플랫폼에서 Windows 앱을 쉽게 실행할 수 있는 방법입니다. 그렇게 하면 사람들이 먼저 Windows용으로 작성한 다음 많은 작업 없이 앱을 다른 플랫폼으로 가져올 수 있습니다.

@KyleNanakdewa 글쎄, 그들이 그것을 오픈 소싱한다면 일부 Xaml 팬이 떠나 기본 플랫폼 비트를 만들게하십시오. 아마도 아키텍처가 충분히 복잡하고 Win32를 충분히 활용하여 포트가 막대한 사업이 될 것이라고 생각합니다.

이 프로젝트는 기본 Windows 소프트웨어를 만들기 위한 동급 최고의 방법을 제공하는 데 중점을 두어야 한다고 생각합니다.

Microsoft가 이미 WinUI와 매우 다른 XAML 방언을 제공하는 기존 크로스 플랫폼 XAML 도구 키트를 소유하지 않은 경우 이 주장은 설득력이 있을 수 있습니다.

또한 웹 HTML 및 Javascript 세계에 투자한다면 PWA가 있습니다.

네... 네이티브 OS/스토어/호스팅 개발에 대해 우리가 알고 있는 모든 것을 빠르게 대체하는 "그 세계"입니다. 😆

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

HTML5 렌더러가 있는 _모든_ 최신 기기에 "그 세계"가 존재한다고 생각해 보세요.

• 애플은 14억
• 25억 드로이드
• Windows 10 8억

이제 Windows의 시장 점유율이 가장 낮음을 알 수 있습니다. 즉, 이 플랫폼에 특별히 맞는 모든 제품은 가장 작은 시장에 도달하는 제품이 될 것입니다. 그렇게 하면 응용 프로그램의 최대 잠재적 시장 도달 범위가 줄어들고 결과적으로 최대 잠재적 수익 한도가 낮아집니다.

이것을 앞서 언급한 마켓 플레이스의 _모든_에 _하나의_ 코드베이스로 도달하는 Flutter 와 웹 이 3가지 모두의 집합체로 구성되어 있는 Flutter와 비교하십시오. 할 수 있습니다.

저는 여기에서 소스를 공개하고, 협업하고, 커뮤니티 피드백을 요청하려는 노력의 열렬한 팬 이지만, 여기에서의 노력이 될 것이라는 확신을 갖고 나에게 신호를 보내는 이러한 토론(나도 즐깁니다 😁)을 아직 보지 못했습니다. Flutter(btw 도 PWA에 적합함 )와 비교할 때 경쟁력이 있으므로 _수익성 있는_입니다.

다이어그램 제어 는 곧 공식 NET CORE 3(2019년 9월)가 될 모든 데이터 기반 최신 데스크톱 환경에서 필수적입니다. NET 5(2020년 11월)

제공된 Networkview 오픈 소스 컨트롤은 Xaml을 사용하여 WPF를 Win UI 컨트롤로 이식하는 방법에 대한 효과적인 사용 사례라고 생각합니다. 이 이식된 Win UI는 다른 사람들이 다른 약간 더 복잡한 WPF 컨트롤을 Win UI로 이식할 수 있는 좋은 길드 역할을 합니다.

앱이 향후 Windows Core OS에서 태블릿 모드를 지원해야 하는 2 in 1 사용 사례를 봅니다. 우리는 NET Core 3의 Winform이 도움이 되지 않을 것이라고 생각합니다. Win UI 다이어그램 컨트롤이 PoC의 연습이 아니라 앞으로 이동하는 Grid 컨트롤과 유사한 FIRST 클래스의 win ui 핵심 컨트롤의 일부여야 하는 또 다른 강력한 정당화입니다.

더 나은 F# 지원이나 새로운 마크업 기능과 같은 다른 새로운 기능이 중요하다고 생각 되면 새 기능 요청을 열어 별도로 추적할 수 있도록 하십시오!

@migueldeicaza 가 스스로 문제를 해결하고 있는 것 같습니다: https://github.com/microsoft/microsoft-ui-xaml/pull/736

크로스 플랫폼에 대한 @eklipse2k8 의 생각을 반영하고 싶습니다. 크로스 플랫폼 UI 라이브러리를 만들 때는 항상 타협을 해야 합니다. WinUI는 타협해서는 안 됩니다. Win32 UI를 현대적으로 대체해야 하며(더 이상 CreateWindowExW 호출하고 싶지 않습니다!) Windows에서 수행할 수 있는 작업의 쇼케이스가 되어야 합니다. macOS 또는 Android의 WinUI는 항상 기본 경험과 일치할 수 없는 경험을 제공합니다. 우리는 크로스 플랫폼 애플리케이션을 작성하고 각 플랫폼에 기본 UI를 작성합니다. 그렇게 하면 고객이 선택한 플랫폼에서 최고의 경험을 얻을 수 있습니다. 사람들이 크로스 플랫폼 솔루션을 원한다면 괜찮습니다. 그 목적을 위해 다른 라이브러리를 찾아야 합니다. 아마도 Windows 플랫폼에서 WinUI를 래핑하는 라이브러리일 것입니다.

그리고 PWA와 관련하여 이들은 Windows UI 시스템의 전체 사용을 나타내지 않으며 "단일 창 응용 프로그램"에 중점을 두는 것이 좋습니다(게임 제외). PWA 및 크로스 플랫폼을 위한 솔루션이 이미 있습니다. 다른 솔루션은 필요하지 않습니다.

의무 XKCD:
https://xkcd.com/927/

@MarkIngramUK 크로스 플랫폼에 대한 이야기는 UI를 선언하기 위해 .NET 및 XAML로 코딩할 수 있다는 것에 관한 것입니다. 그런 다음 해당 앱을 Android, iOS, macOS, Linux에서 실행하는 것인가요?! - 뒤에 있는 코드를 변경하거나 XAML을 포기할 필요가 없습니다.

이제 이러한 다른 플랫폼에 대한 XAML 렌더러가 있는 경우 XAML을 해석하는 방법은 기본 UI 플랫폼으로 전달되는 Xamarin Forms와 같을 수 있습니다. 동일한 컨트롤 스타일.

WinUI 3.0은 다양한 API 및 ABI를 최신 XAML 기반 UI 플랫폼과 통합하기 위해 Windows 중심 프로젝트로 남아 있어야 합니다. 그러나 이것이 Xamarin이나 개인이 렌더링 코드를 사용하여 다른 플랫폼용 버전을 만들 수 없다는 것을 의미하지는 않습니다.

(높은 수준의 사고 방식에서) 실제로 필요한 것은 Windows의 화면에 XAML을 렌더링하는 코드가 포함되도록 하여 다른 렌더러가 플랫폼 간 시나리오에 참여할 수 있도록 하는 것입니다.

WinRT/UWP/XAML은 Windows 10 OS에서 분리하기 위해 약간의 리팩토링이 필요합니다. 따라서 향후 확장을 위해 리팩토링을 수행하는 방법을 염두에 두어야 합니다. 크로스 플랫폼이 현실이 되는지 아닌지.

@MarkIngramUK 나는 @mdtauk에 동의

React를 포함한 다른 라이브러리의 UI 구성 요소를 설명하기 위해 xaml을 사용할 수 없는 이유는 없습니다. http://www.cshtml5.com 과 같은 프로젝트를 보면 html로 변환되는 xaml을 사용합니다.
나는 또한 최종 목표가 UI가 다른 플랫폼에서 동일하게 보이는 것이라는 사실을 아무도 언급하지 않는다고 생각합니다. 그러나 개인적으로 원하는 것은 UWP와 같은 기존 투자를 활용하는 데 사용할 수 있는 UI 측면의 것입니다.

요점은 바로 이것입니다. 내가 기업 고객에게 제안을 하고 모든 면에서 환상적인 멋진 UWP 앱을 제시한다면. 해당 기업 고객에게 예를 들어 MacBook Pro를 사용하는 사용자가 1명 있는 경우 기업 고객은 실행하더라도 내 "기본 앱"보다 모든 곳에서 작동하는 앱(최저 분모 => 웹 사이트)을 택할 것이기 때문에 즉시 문제가 발생합니다. 윈도우 10에서.

그래서 접근성 이 중요합니다. MS가 여전히 크로스 플랫폼 기능에 대한 로드맵 없이 2019년에 "네이티브 앱"에 투자할 것으로 기대하고 있다는 사실은 미친 짓입니다.

엔터프라이즈 관점의 모든 새 프로젝트는 액세스 가능성에 대한 위의 논리를 따를 가능성이 높으므로 XAML/UWP에 크로스 플랫폼 기능을 포함하는 로드맵이 없기 때문에 모든 새 프로젝트는 웹과 모두에 편중됩니다.

그래서 우리는 지금부터 2-3년 후, UWP/win32에 대한 기업의

MS는 XAML이 내일 더 이상 사용되지 않으며 "새로운" UI 라이브러리가 예를 들어 React라고 말할 수도 있습니다. C#을 이 새 라이브러리에 붙일 수 있는 한 저는 손실을 줄이고 XAML을 버리고 이 새로운 교차 플랫폼 UI 라이브러리를 수용할 것입니다. 적어도 내 투자는 내구성이 있고 장기적으로 접근할 수 있습니다.

크로스 플랫폼 UI 기능과 관련된 이 특정 문제에 대한 명확성 을 제공하지 않음으로써 MS는 "네이티브 스택"에 대한 불확실성을 생성하고 있으므로 대부분의 기업은 미지의 것을 포용하기보다 나무 다리로 불길을 헤쳐 나갈 것입니다.

그리고 PWA와 관련하여 Windows UI 시스템의 전체 사용을 나타내지는 않습니다.

충분히 공정하고 동의합니다. PWA에 대한 나의 주요 요점은 시장 점유율이 모든 시장의 집합체로 구성되어 있기 때문에 단일 특정 시장이 왜소하다는 것을 입증하는 것이었습니다.

즉, 여기에서 혼란스러운 부분은 Microsoft.* 를 반영하는 네임스페이스라고 생각합니다. 실제로는 여전히 Windows.* (또는 Microsoft.Windows.* )여야 합니다. .

PWA 및 크로스 플랫폼을 위한 솔루션이 이미 있습니다. 다른 솔루션은 필요하지 않습니다.

불행히도 이것은 .NET 개발의 경우가 아닙니다. 이는 이 발표와 후속 논의에 대한 혼란과 플랫폼 간 불안의 일부입니다.

따라서 응용 프로그램 개발자를 위한 시장 도달 범위와 잠재적 수익을 극대화하는 동시에 응용 프로그램을 구축하는 데 필요한 비용을 줄입니다.

때로는 성능과 UX 세부 사항이 큰 차이를 만들 수 있습니다. Skype는 성능을 희생하면서 Electron 프레임워크를 사용하여 시장 도달 범위를 극대화했으며 결과는 상업적 재앙입니다.

크로스 플랫폼(xplat) 솔루션 관련.
Xplat 솔루션은 여러 기본 기본 시스템에 대한 추상화입니다. WinUI에 대한 나의 이해는 이것이 Windows의 기본 시스템이 될 것이라는 것입니다.

WinUI도 xplat이 된다면 Windows 고유의 기능을 어떻게 통합할까요? 그것이 새롭고 혁신적인 일을 하는 것을 방해하지 않을까요? 아니면 Microsoft가 Windows에서 다른 플랫폼으로 새로운 것을 포팅하거나 차별화하는 것을 의미합니까? 다른 기본 OS가 지원할 수 없기 때문에 이식할 수 없는 것은 Windows에 추가되지 않아야 합니까?

기본 Windows 기술로 무언가를 구축하는 경우 Microsoft가 일정 기간 동안 이를 지원하고 향후 새로운 Windows 기반 시스템으로 나아갈 수 있는 경로를 제공할 것이라고 가정하는 것이 합리적입니다. (SilverLight는 예외로 인정합니다.) 기본 Windows 기술을 사용하여 무언가를 빌드한 다음 경쟁 운영 체제에서 실행하려는 경우 이를 쉽게 만드는 것은 Microsoft/Windows에 달려 있다고 가정하는 것이 합리적이지 않다고 생각합니다. Swift를 사용하여 iPad용 앱을 만들고 Windows 데스크톱에도 가져오고 싶다면 Apple이 iOS 개발을 쉽게 변경하기를 기대하시겠습니까?

기본 Windows 기술 사용을 즐기거나 선호한다면 훌륭합니다. 당신이 할 수 없는 것은 그러한 기술을 선택할 때 내리는 비즈니스 결정을 다른 사람에게 미루는 것입니다. 모든 기술 선택에는 결과가 따르며 향후 몇 년 동안 무엇이 필요할지 또는 고객이 무엇을 요구할지 아무도 모릅니다. Windows용으로 특별히 개발된 소프트웨어를 다른 곳에서도 실행할 수 있도록 요청하면 미래의 어느 시점에서든 부정적인 결과를 초래할 수 있는 기술 결정을 피하는 것이 목표라는 인상을 줄 수 있습니다. 기술의 특성과 변화의 속도에 비추어 볼 때 그것이 현실적이지 않다고 생각합니다.

즉, 현재 여러 운영 체제를 대상으로 하거나 미래에 원할 수 있기 때문에 xplat 솔루션을 구축하려는 경우(많은 사람들이 그렇게 하는 이유와 이유가 있음), 이는 합리적이고 이해할 수 있습니다. 대본.
이를 위해 Microsoft에는 Xamarin이 있습니다. 또는 UWP와 같은 XAML을 사용하는 것을 선호하는 경우 Uno가 있습니다. (다른 옵션도 많이 있습니다.)
저처럼 Xamarin이 Windows 앱 빌드에 대해 더 나은 기본 지원을 제공하는 것을 보고 싶다면 WinUI가 여러 가지 작업을 시도하고 수행하는 것이 답이라고 생각하지 않습니다.

WinUI는 XAML 및 특정 컨트롤 그 이상입니다. 여기에는 이러한 컨트롤과 이를 사용하여 구축된 앱이 기본 운영 체제와 통합되는 방식에 대한 세부 정보가 포함됩니다.
WinUI 계획이 Windows에서 Windows 개발을 최고로 만드는 데 초점을 맞추면 혁신과 좋은 미래 지원을 위한 좋은 사례가 될 수 있습니다. 또한 사람들이 Windows를 계속 사용하기를 원할 가능성이 높아지므로 여러 xplat 솔루션의 견고한 지원이 중요해집니다.

크로스 플랫폼(xplat) 솔루션 관련.
Xplat 솔루션은 여러 기본 기본 시스템에 대한 추상화입니다. WinUI에 대한 나의 이해는 이것이 Windows의 기본 시스템이 될 것이라는 것입니다.

미안하지만 난 그런 느낌이 아니야...

Flutter를 보세요... 지원하는 모든 플랫폼에서 무엇이든 렌더링할 수 있는 핵심 엔진이 있습니다.

또한 엔진 관리 레이어를 사용하여 Dart에서 완전히 구현되고 픽셀 충실도로 표현(그리기/렌더링)하는 구성 요소가 있습니다. 예를 들어 Material.io 및 Apple의 Cupertino와 같이 사용하려는 플랫폼 및 디자인 언어입니다.

따라서 IMHO는 플랫폼 간 무언가를 만드는 가장 좋은 접근 방식이 될 것이며 동시에 기본 플랫폼 기능을 나타냅니다.

기본 Windows 기술로 무언가를 빌드한 다음 경쟁 운영 체제에서 실행하려는 경우 이를 쉽게 만드는 것은 Microsoft/Windows에 달려 있다고 가정하는 것이 합리적이지 않다고 생각합니다.

맞아요... 제 생각에 다른 사람들이 말하고 있는 요점은 이것이 요즘, 특히 새로운 응용 프로그램을 시작하는 맥락에서 약간 후진적이거나 둔감해 보인다는 것입니다. 시장의 작은 %에 불과할 때 누군가가 네이티브 Windows 응용 프로그램을 구축하는 이유는 무엇입니까? 이것은 자본의 좋은 사용이 아닙니다.

레거시 Windows 응용 프로그램을 유지 관리하거나 특별히 Windows 응용 프로그램을 만드는 것이라면 이 모든 것에 동의하며 이해가 됩니다. 그러나 획기적인 변화와 추가 투자가 포함된 것으로 보이기 때문에 이를 수행하는 것과 Flutter를 사용하는 것의 가치 제안은 아직 설명되지 않았습니다.

제가 하는 말이 바로...

예를 들어, Win10(WPF 및 UWP)과 OSX 모두에서 데스크톱용 플러터 임베더가 출시될 예정입니다.

그것들은 플러터 런타임에 의해 100% 관리되지만, 윈도우 관리와 Graphics 포인터를 얻기 위해 (예를 들어) WPF/UWP만을 사용하고 있습니다. 나머지는 모두 엔진에서 관리합니다 ...

우리는 플러터 엔진을 임베디드 ARM 장치에 이식했고 정말 멋진 경험이었습니다. 왜요? "임베더"가 GPU, 소프트웨어 렌더링, 입력 관리 등과 같은 기본 요소에 대한 플랫폼별 구현 세부 정보를 처리하도록 하여 이식 가능하고 어디서나 실행되도록 태어났기 때문에...

내가 말하는거야 이유입니다 WinUI 를 이용하여 UWP: The empire strikes back 장기적으로 작동하지 않을.

MSFT는 플랫폼 간, 개방성, 이식성을 제공해야 합니다. .Net Core, Blazor 등에서 했던 것처럼... Reinvent UWP/XAML은 아무데도 가지 않을 것입니다.

저는 XAML이 UI를 "설명"(또는 일부 사람들이 말하는 것처럼 선언)하는 데 사용되는 의미에서 적절하게 사용된다면 좋은 잠재력을 가지고 있다고 믿습니다. "엔진"은 여기에서 렌더 트리를 빌드한 다음 렌더 명령을 기본 플랫폼에 전달합니다.

MSFT가 최근 Chromium을 Edge의 핵심으로 사용한 것처럼 WinUI(또는 이름이 무엇이든 간에)는 GL, DX, Vulkan, Software Rendering, FB 등에 대한 백엔드가 있으므로 Skia를 활용할 수 있다고 생각합니다. 나중에 다른 플랫폼을 추가할 수 있는 엄청난 잠재력이 있다는 것을...

@galvesribeiro ,

Flutter를 보세요... 지원하는 모든 플랫폼에서 무엇이든 렌더링할 수 있는 핵심 엔진이 있습니다.

또한 엔진 관리 레이어를 사용하여 Dart에서 완전히 구현되고 픽셀 충실도로 표현(그리기/렌더링)하는 구성 요소가 있습니다. 예를 들어 Material.io 및 Apple의 Cupertino와 같이 사용하려는 플랫폼 및 디자인 언어입니다.

좋습니다. Apple이 macOS에 대한 업데이트를 출시하고 UI 업데이트(아마도 버튼 모서리 반경 변경 또는 배경 그라디언트 변경 등)를 하자마자 Flutter 애플리케이션이 업데이트되지 않고 네이티브와 달리 계속 이전 OS처럼 보입니다. 어떤 것이 무료로 혜택을 받을지 제어합니다.

@MarkIngramUK 업데이트를 지원하는 팀의 작업입니다.

Xamarin 팀이 0+1일째부터 업데이트를 제공하는 것처럼 이 팀도 동일한 작업을 수행할 수 있습니다. Google 팀도 그렇게합니다 ...

"네이티브" 컨트롤을 사용하면 래퍼(렌더라고도 함)와 같은 Xamarin 세계로 다시 돌아갑니다.

우리는 네이티브 컨트롤에 대한 C# 바인딩(Xamarin처럼)에 대해 논의하지 않고 있습니다... Flutter에서와 같은 전체 UI 프레임워크에 대해 이야기하고 있습니다...

기록을 위해 아무도 모든 플랫폼에 대해 "기본" 테마를 사용하지 않습니다. 그들은 모두 각 플랫폼의 디자인 언어 위에 고유한 UX를 만듭니다.

항상 기본 구성 요소로 보이는 것이 걱정된다면 앱에 보이는 것처럼 좋은 청중이 없을 것입니다. 음...

나는 우리가 여기서 두 가지 다른 프로젝트에 대해 이야기하고 있다고 생각합니다. WinUI는 Win32를 대체해야 합니다. 사람들이 크로스 플랫폼 솔루션을 요구하고 있는데, 이는 합리적이지만 이 프로젝트는 해서는 안 된다고 생각합니다.

또한 Flutter를 사용하면 모든 플랫폼에서 "테마"를 사용할 수 있습니다. 따라서 Win10 PC에서 Cupertino를 실행할 수 있습니다. 큰 예는 머티리얼 디자인입니다. 컨트롤 세트가 아닌 디자인 언어입니다. 그것은 어디에서나 사용할 수 있습니다 ... Android와 같은 일부 플랫폼에는이를 구현하는 기본 컨트롤이 있습니다 ...

@MarkIngramUK

WinUI가 단순히 Win32를 대체해서는 안 되는 이유를 명확히 하는 것뿐입니다.

그렇다면 UWP와 마찬가지로 가까운 미래에 떨어질 것이라고 확신합니다...

@MarkIngramUK WinUI 자체는 C#, WinRT API, Win32 ABI, C++, F#, VB, .NET Core를 사용하는지 여부에 관계없이 Windows용 통합 UI를 제공하는 데 중점을 두어야 한다는 데 동의합니다.

WinUI 3.0에는 Windows OS에서 모든 코드와 XAML 렌더링을 들어 올려 OS 업데이트 주기와 독립적인 프레임워크로 만들고 오픈 소스로 만드는 작업이 포함됩니다.

그것을 들어 올리고 재포장하는 방법은 여전히 ​​공중입니다. Microsoft 내부 직원만이 어떻게 할 것인지 알고 있습니다. XAML에 대한 향후 교차 플랫폼 지원을 지원하기 위해 Windows에서 XAML을 제거할 때 향후 달성할 수 있는 방법에 대해 약간만 생각하기를 바랍니다.

.NET Core는 이미 다른 플랫폼에서 사용할 수 있습니다. 이것이 이미 양도 가능한 C# 코드입니다. 이제 iOS/macOS/Android/Linux(및 향후 제공될 수 있음)에 대한 경로가 필요한 XAML 및 UI 및 컨트롤만 있습니다.

아마도 WinUI 3.0의 범위를 벗어나지만 이 프로젝트와 노력과 가장 확실하게 연결됩니다.

@jesbis @terrajobst @jevansaks

데스크톱, 모바일(Droid, iOS) 및 웹에서 렌더링되는 UI 프레임워크를 .NET Core로 가져오기 위한 Microsoft의 계획은 무엇입니까?
이에 대한 불확실성은 오랫동안 지속되어 왔습니다.

@weitzhandler , 그들은 이미 다음 단락과 함께 로드맵을 가지고 있습니다.

웹 및 크로스 플랫폼 프레임워크를 위한 기본 Windows 대상
WinUI 3은 빌드할 라이브러리 및 프레임워크 되어 있습니다.
예를 들어, 우리는 WinUI 3에서 새로운 고성능 C++ React Native Windows 구현을 기반으로 할 계획입니다.

강조된 부분인 "to build on"에 유의하십시오. 위에서 말했듯이 다른 라이브러리가 그 위에 구축되는 Windows가 먼저 될 수 없는 이유는 없습니다.

자 그리고 나서...

/me keep working on FluSharp

합리적이지만 이 프로젝트가 되어서는 안 된다고 생각합니다.

목이 말라 @MarkIngramUK , 우리의 예상을 용서하십시오. 😂

다음 단락으로

많은 말을하지 않습니다. C# 및 .NET 개발을 xplat으로 만들려는 MS의 명확한 의도는 밝히지 않습니다. 이식성을 원한다면 HTML JS 및 CSS shi{가 C#보다 더 나은 장비라고 말할 수도 있습니다.

현재 Xamarin 및 Xamarin Forms는 Windows 외부에서 C# 및 .NET Core 개발을 위한 Microsoft의 이야기입니다.

Windows용 React Native는 Javascript 코드 및 기본 UI(WinUI 3.0 XAML 사용)용으로 제공됩니다.

현재 Microsoft는 WinUI 3.0의 XAML을 다른 플랫폼으로 가져올 계획을 발표하지 않았습니다.

WinUI 프로젝트는 단일 최신 XAML 프레젠테이션 프레임워크에서 Win32, WPF, MFC, UWP, .NET Core 개발 프레임워크를 통합하려고 합니다.

그 후에는 macOS, iOS, Android 등과 같은 플랫폼에서 WinUI 3.0용으로 작성된 XAML을 렌더링하는 방법을 찾는 작업이 진행되어야 한다고 생각하지만 아직까지는 의제가 아닙니다.

여기에서 WinUI 3.0 작업이 시작되면 오픈 소스가 될 것이므로 필요한 경우 향후 크로스 플랫폼 작업이 가능합니다. 그리고 궁극적으로 이러한 교차 플랫폼 경로를 제공하는 것은 Microsoft가 아니라 오픈 소스 커뮤니티일 수 있습니다.

.NET의 빨간 머리 의붓자식인 F#을 일류 시민으로 만들 계획이 있습니까? 그러면 사람들은 대다수의 .NET 개발자가 10피트 기둥으로 F#을 만지지 않는 이유를 궁금해합니다.

현재 Xamarin 및 Xamarin Forms는 Windows 외부에서 C# 및 .NET Core 개발을 위한 Microsoft의 이야기입니다.

예, Xamarin.Forms는 macOS, GTK, UWP 및 WPF로 이식되고 작업의 모든 곳에서 머티리얼 디자인이 적용되어 사실상 .NET UI Framework가 되지만 너무 느리고 버그가 있습니다. Microsoft는 어떻게 생각하고 있는지 궁금합니다. 개발자에 대해. 문제 목록만 보세요! 본격적인 개발이 시작되면 버그가 좌우로 강타됩니다. WinUI를 통해 마침내 더 나은 개발 경험을 할 수 있기를 바랍니다.

재: F#

더 나은 F# 지원이나 새로운 마크업 기능과 같은 다른 새로운 기능이 중요하다고 생각되면 새 기능 요청을 열어 별도로 추적할 수 있도록 하십시오!

예, 별도로 추적되고 다시 무시되는 것은 항상 F#입니다. UWP와 .NET Native를 살펴보십시오. 둘 다 F#을 염두에 두지 않았으며 커뮤니티 전체에서 모든 것을 파악해야 했습니다. 🙄 4년이 지난 후에도 F#은 여전히 ​​.NET Native에서 지원되지 않습니다.

F# 제안/질문에 대해 전용 문제를 만들었습니다.
https://github.com/microsoft/microsoft-ui-xaml/issues/740

자유롭게 F# 토론을 진행하세요.

우리는 그것에 대한 피드백을 절대 무시하지 않습니다. 전용 문제를 갖는 것은 우리가 그것을 구성하고 추적하는 데 도움이 될 뿐입니다.
팀은 3.0 이상을 위한 로드맵에 어떻게 맞출 수 있는지 논의하고 있으며 개발이 진행되면 새 문제를 업데이트할 것입니다.

RE: 플랫폼 간 UI:

지금까지 제기된 요점과 .NET 및 Xaml에 대한 열정에 감사드립니다.
모든 피드백을 주의 깊게 듣고 있으며 진행 상황에 따라 생각과 업데이트를 공유할 것임을 다시 한 번 말씀드리고 싶습니다.

현재 로드맵과 나온 몇 가지 사항을 재확인하기 위해:

WinUI는 Windows용 기본 UI 플랫폼(.NET뿐만 아니라 기본 앱 포함)이며 초기 3.0 버전에서는 주로 OS와 독립적으로 만들고 더 빠른 릴리스에서 오픈 소스 개발을 준비하는 데 중점을 두고 있습니다. 주기. 우리는 범위가 올해 미리보기를 할 수 있을 만큼 충분히 실현 가능한지 확인하고 싶습니다.

현재 우리의 다른 단기 목표 중 하나는 WinUI가 Windows에서 사용하는 다른 플랫폼의 기본 대상 역할을 할 수 있도록 하는 것입니다. 예를 들어 우리는 react-native-windows - 고성능 C++ React Native 구현도 보장하기 위해 노력하고 있습니다. Windows용 - WinUI 사용 및 WinUI 컨트롤을 사용하여 React Native 앱에서 기본 UI 보기를 만들 수 있습니다.

완전 정직하겠습니다. 저는 2006년에 WinForms에 작성한 기본 Windows 데스크탑 앱을 가지고 있으며 지금도 온라인에서 판매하고 있습니다.

이 앱을 WPF, UWP로 마이그레이션하거나 독점적인 Windows UI 기술을 사용할 계획이 없습니다. 나는 Windows 데모가 얼마나 매력적인지 신경 쓰지 않습니다. 내가 이 앱을 다시 작업하기로 결정한다면 다음 주요 버전은 MacOS, Linux 및 Windows에서 실행할 수 있는 일종의 교차 플랫폼 구현이 될 것입니다.

현재로서는 Blazor + .NET Core + Electron처럼 보일 것입니다.

@Mike-EEE가 몇 가지 좋은 점을 지적한다고 생각합니다. C# 기술을 활용하여 최대한 많은 청중에게 다가갈 수 있게 해주는 UX/플랫폼은 제가 선택할 가능성이 더 높은 기술입니다.

Microsoft는 개발자가 기존 기술을 활용하여 앱으로 더 많은 청중에게 다가갈 수 있도록 하는 데 중점을 두어야 합니다. 나는 그것이 승리하는 전략이라고 생각하며 게임에서 Microsoft를 유지할 것입니다.

벽에 적힌 글은 운영 체제 소프트웨어가 점점 더 상품처럼 되어 가고 있다는 것입니다. 즉, 사람들은 원하는 OS를 선택하고 사용하려는 앱을 얻을 수 있습니다. 전 세계의 소프트웨어 공급업체가 계속해서 크로스 플랫폼에 초점을 맞추면서 시간이 지남에 따라 이것이 더 분명해질 것이라고 생각합니다.

경제학에서 상품은 완전하거나 실질적인 대체 가능성이 있는 경제적 재화 또는 서비스입니다. https://en.wikipedia.org/wiki/Commodity

Microsoft는 결정해야 합니다. 개발자 도구 이야기의 일부가 되기를 원하는가? 아니면 Microsoft는 점점 더 적은 사람들이 사용하는 UX 스택의 무덤에 합류하게 될 새로운 Windows 전용 UX 스택에 수백만 달러를 투자합니까?

이 프로젝트는 Windows 내부가 어떻게 작동하는지에 대한 풍부한 지식을 가진 팀이 소유하고 있으며 Mac 또는 Linux에서 동일한 정도로 제대로 작동하도록 하는 방법을 알아내는 것은 그들이 주의를 산만하게 할 것입니다.

확실히 하기 힘든 포지션입니다. 그러나 시대가 바뀌었습니다. 오늘날의 세상은 1995년의 세상과 매우 다릅니다. 제가 보기에는 두 가지 옵션이 있습니다.

Windows 이상으로 지식을 확장하기 위해 더 많은 사람을 고용할 수 있습니다.

또는 해당 팀의 지식을 사용하여 Windows에서 더 잘 실행되도록 플랫폼 간 UI 응용 프로그램 프레임워크에 대한 호환성을 향상시키는 Windows 내부의 UX 배관을 구축합니다.

WSL이 Windows에서 Linux를 실행하는 것처럼.

• 팀의 지식을 활용하여 GTK를 200배 더 빠르게 실행하십시오.
• 팀의 지식을 사용하여 QT 앱을 200배 더 빠르게 실행하십시오.
• 팀의 지식을 사용하여 Electron 앱을 다른 어떤 OS보다 빠르게 렌더링할 수 있습니다.

Windows 플랫폼 간 UX 호환성 스토리를 향상시키기 위해 수행할 수 있는 작업이 많이 있습니다. 그러나 완전히 새로운 UX 스택에 투자하고 우리 모두가 (교차 플랫폼 이야기 없이) 전환하기를 희망하는 것은 꽤 큰 베팅입니다. Windows 전용의 새로운 UX 프레임워크를 만드는 이 습관을 깨야 합니다.

그냥 내 2 센트. :돈 가방:

:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (공식 영화) ft. Billy Ray Cyrus

@bchavez

Windows 전용의 새로운 UX 프레임워크를 만드는 이 습관을 깨야 합니다.

-- 뿐만 아니라. Windows 자체의 내부 XAML 이식성을 깨뜨리는 습관조차도. WPF, Siliverlight, UWP 모두 자체 포크... 이러한 종류의 문제는 개인적으로 앞으로 계속 사용하고 싶은 일반적인 Windows 개발 도구에서 점점 더 많은 사람들을 밀어내고 있습니다. Windows 개발 도구의 푸시백이 많을수록 C#의 관련성이 점점 줄어들고 나에게 중요한 것은 C#이 중요하다는 것을 의미합니다.

RE: 플랫폼 간 UI:

... WinUI는 Windows용 기본 UI 플랫폼(_ .NET이 아닌 기본 앱 포함 _)이며 초기 3.0 버전의 경우 주로 OS와 독립적으로 만들고 오픈 소스에 맞게 준비하는 데 중점을 둡니다. 더 빠른 릴리스 주기에 대한 개발. 우리는 범위가 올해 미리보기를 할 수 있을 만큼 충분히 실현 가능한지 확인하고 싶습니다.

Fluent/FabricWeb 컨트롤 스타일과 더 잘 일치하도록 WinUI 3.0과 함께 실행되는 WinForms, MFC, WPF 컨트롤의 시각적 모양을 업데이트하는 아이디어에 +1을 추가합니다.

확실히 다른 컨트롤 크기(WinRT XAML이 아닌 모든 것은 UWP 컨트롤의 Compact 버전과 해당 메트릭과 일치해야 함)가 있지만 일관성 있고 일관된 세련된 모양입니다.

WinForms에 WinUI 3.0 종속성을 추가하면 컨트롤이 변경됩니다.

WinUI 3.0 WPF 앱은 Fluent.Light.xaml 또는 Fluent.Dark.xaml 제어 테마를 감지하고 사용합니다.

@weitzhandler 당신의 심정을 이해합니다. 이 크로스 플랫폼 GUI를 수행하기 위해 JavaScript 및 이와 유사한 것을 만질 필요가 없기를 바랍니다. 전자, 각도, 다트, 플러터를 사용하여 프로젝트를 시작하는 것은 생각조차 하기 싫습니다.
Universal XAML의 꿈을 실현할 .NET 5를 통해 곧 솔루션을 얻을 수 있기를 바랍니다. Microsoft XAML은 WIN, 웹, 모바일, 데스크톱 및 IoT가 가능합니다.
Silverlight는 많은 사용 사례에서 거의 그렇게 했습니다 .

Windows 전용의 새로운 UX 프레임워크를 만드는 이 습관을 깨야 합니다.

WinUI 3.0은 플랫폼 간 지원을 기다려야 하는 경우(모든 플랫폼에서 불가피하게 손상됨) 릴리스되지 않습니다. WinUI는 Windows에서 가장 낮은 수준의 UI 프레임워크여야 하며, 크로스 플랫폼 기능을 원하면 그 위에 빌드(또는 React Native, Xamarin 등 사용)합니다.

Windows 전용의 새로운 UX 프레임워크를 만드는 이 습관을 깨야 합니다.

WinUI 3.0으로 새로운 UI 프레임워크를 만들려는 것이 아님을 분명히 하고 싶습니다.

우리의 초기 목표는 다음과 같습니다.

• 기존 최신 기본 기술(Windows 10 Xaml UI 및 합성기)을 OS에서 분리하고 기존 앱 모델(win32 및 UWP), 언어, 기타 프레임워크(섬을 통해) 및 Windows 버전에서 작동할 수 있도록 하여 기존 기본 기술(Windows 10 Xaml UI 및 합성기) 사용에 대한 장벽을 제거합니다.

• 엔지니어링 프로세스를 오픈 소스로 업데이트

WinUI 3.0은 플랫폼 간 지원을 기다려야 하는 경우(모든 플랫폼에서 불가피하게 손상됨) 릴리스되지 않습니다.

이봐... 정말 그렇게 믿는다면 Flutter와 같은 성공적인 프레임워크가 작동하지 않는다는 뜻입니다...

나는 Dart도 좋아하지 않지만 진화하고 있고 정말 빠르게 견인력을 얻고 있는 꽤 하강하는 제품을 출시했습니다.

WinUI가 그냥 윈도우용이 될 것 같아서 답답하네요...

.Net에는 Blazor(클라이언트 및 서버 측)가 있는 웹용으로 얻은 것처럼 .Net Core 크로스 플랫폼 기능의 우수성과 일치하는 UI 프레임워크가 필요합니다.

현재로서는 여전히 지역사회 주도의 노력에 의존해야 한다고 생각합니다.

나는 당신의 팀이 @jesbis에서 무엇을 하려고 하는지 이해합니다... 우리 중 많은 사람들이 .Net/C++/UWP/MFC/Windows에서 UI를 보는 데 지쳤습니다. 전 세계가 Windows에서만 실행되는 _silo_' (ofc Apple 및 OSX 제외) 개발자에게 더 나은 교차 플랫폼 솔루션을 제공하는 반대 방향으로 가고 있습니다. React와 Rect-Native에 대해 언급한 것처럼(참고로 저는 둘 다 좋아하지 않고 진화하고 있다고 언급했습니다).

그래서 우리가 지금 가지고 있는 것은 Avalonia 또는 Uno와 같은 커뮤니티 주도 이니셔티브와 명백한 이유로 매우 느리게 발전하는 기타 프레임워크(예: 내가 언급한 FluSharp)입니다...

제 제안은 XAML과 합성기를 Windows 코드베이스에서 꺼내서 Windows 전용으로 만드는 것보다 가져와서 적절한 추상화를 만들어 여러 플랫폼에서 작동할 수 있도록 하는 것입니다. 처음에는 Windows 전용이었지만 커뮤니티 주도의 노력으로 Linux, OSX 및 ARM 장치에서도 매우 빠르게 작동하는 .Net Core와 마찬가지로...

(모든 플랫폼에서 불가피하게 손상됨) 플랫폼 간 지원

플랫폼 간 디자인이 UWP의 XAML UI와 Fluent Design의 핵심 측면이고 항상 그랬다는 점을 감안할 때 이것이 문제가 될 것이라고 생각하지 않습니다. Windows 버전 간에 시각적 디자인이 다른 컨트롤이 분명히 있습니다. 이는 원활하게 처리되어 장치의 OS와 일치하는 기본 UI를 얻을 수 있습니다.

예를 들어, Acrylic 및 Reveal이 컨트롤에 내장되어 있고, Pivots 및 NavigationViews의 액센트 색상이 있습니다. 이러한 것들은 Creator의 업데이트에는 나타나지 않지만 FCU 이상에서는 나타납니다. 변경이 필요하지 않습니다.

분명히 완전히 다른 OS에서 UI를 렌더링하는 데에는 훨씬 더 복잡한 배후가 있지만 실제로 UI를 디자인하는 관점에서 보면 그 어느 때보다 취해야 할 새로운 고려 사항이 없다고 생각합니다. UWP 및 WinUI를 사용합니다.

가장 큰 관심사는 장기적인 계획이 진정 무엇인가 하는 것입니다. @jesbis의 답변에 따르면 지금은 단기에만 집중하고 있는 것으로 보이며 장기 계획은 아직 논의 중입니다.

그만큼 이해할 수 있으며 그러한 프로젝트의 범위는 엄청납니다. 단기 계획이 아니라 최종 계획이라면 충분히 이해할 수 있었다. 여기서 투명성이 중요합니다. 분명한 미래 없이 플랫폼을 지원하고 싶어하는 사람은 아무도 없다는 것이 분명합니다.

MS가 전반적으로 크로스 플랫폼에 초점을 맞추고 있음이 분명합니다. Fluent Design(현재 iOS, Android 및 웹에 대한 예제가 있음), 다른 플랫폼의 수많은 MS 제작 앱에서 이를 볼 수 있습니다. 따라서 공유 UI는 정말 그냥 큰 누락된 링크입니다. 그렇기 때문에 이런 일이 일어나지 않는 것이 너무 실망스러울 것입니다. 많은 사람들이 MS에서 만든 범용 앱 플랫폼의 아이디어를 좋아한다고 생각하지만, 지원하지 않는다면 지원이 의미가 없습니다. 그것에 대한 완벽한 솔루션.

요점은... material.io 및 Cupertino와 마찬가지로 우리는 유창한 디자인 언어를 위해 flutter에 "테마"를 설정할 수 있습니다(Google에서 이미 그렇게 하지 않는 경우에도 놀랍지 않습니다!)...

그리고 그것이 진정한 크로스 플랫폼 UI 프레임워크가 그것에 대해 신경 쓰지 않고 Flutter처럼 작동할 것이라고 말했을 때의 요점입니다... 나는 우리가 그것에 대해 타협점이 있는 곳을 보지 못합니다...

@weitzhandler 네이티브 앱용 HTML도 좋아하지 않습니다. 그렇지 않으면 나는 React 😄와 함께 Electron을 사용할 것입니다.

나는 여기서 열정적이지 않고 대신 합리적입니다.

저는 WinUI 3.0을 정말 기대하고 있으며 새로운 C++/WinRT Windows 데스크톱 프로젝트에 즉시 사용할 것입니다. 그리고 3.0 이후의 다음 메이저 버전에서는 (Flutter 런타임과 같은) WinUI 애플리케이션을 호스팅하기 위한 이식 가능한 런타임이 도입되기를 바랍니다. 상당수의 LOB 응용 프로그램 및 Photoshop과 같은 응용 프로그램의 경우 GUI는 각 플랫폼에서 동일할 수 있지만 핵심은 성능 및 소스 코드 재사용입니다. 그리고 xlang 프로젝트는 좋은 아이디어이며 미래에 좋은 소식을 약속한다고 생각합니다.

여기 사용자들은 BUILD 2019 이후에 Win UI, Xamarin Form, UNO, Web Assembly가 어떻게 결합될 수 있는지에 대해 Scott Hunter의 이야기를 듣는 시간을 가질 것을 제안합니다.

Scott Hunter @.NET Rock 과 함께하는 .NET Core 3 이상

Xamarin Forms(XAML)와 UNO(XAML)는 모두 크로스 플랫폼에 대한 비전으로 만들어졌습니다. UNO의 경우(iOS, Android, 웹 어셈블리를 통한 웹용 XAML 추가).

UWP는 웹, Android, iOS와 같은 Microsoft 에코시스템을 넘어서는 비전 없이 만들어졌습니다. 모든 인상적인 Fluent 디자인 노력은 UWP의 느린 채택으로 인해 거의 차지하지 않습니다.

@Mike-EE가 지적했듯이 droid와 iOS에는 2~15억~이 있고 Win10에는 9억이 있습니다. 대부분의 개발자는 여전히 WinForm 및 WPF에서 UWP로 이동하는 것을 꺼립니다.

왜요? 상업용 및 Microsoft의 UWP 컨트롤은 완전하지 않습니다 !!!!! WinForm 및 WPF와 비교됩니다. 이러한 전환을 돕기 위한 Microsoft의 노력은 없습니다. XAML Island 는 개발자가 winForm 및 WPF에서 UWP로 전환하는 데 필요한 누락된 부분이 MICROSOFT에 BLIND SPOT 이 있는 한 이 문제를 해결하지 않습니다.

이러한 누락된 UWP 컨트롤을 사용하여 이제 Win UI를 웹용 React Native로 가져오는 데 상당한 노력을 기울이고 있습니다. ???? WinForm 및 WPF에서 UWP로의 전환을 위해 로비할 수 있도록 UWP에 대한 이러한 누락된 Win UI 컨트롤이 필요합니다.

그러한 컨트롤 중 하나가 Diagram Control 입니다. 모든 데이터 집약적 비즈니스 앱에는 UWP에 대한 다이어그램 제어가 필요합니다.

==> UWP UI를 분리해야 하는 필요성을 이해합니다. 이것은 iOS, Android, 웹과 같은 다른 플랫폼에 Fluent Design 브랜딩을 전파하는 데에만 의미가 있습니다.
==> 더 나은 3D 모델 제어 및 다이어그램 제어(2D/3D 모두) 제공에 집중하십시오.

나는 HOLOLENS 크리에이티브 3D UI의 미래를 보기 때문에 모든 BCL이 Windows의 기본과 병합될 때(웹 어셈블리 등의 경우) NET5를 유지하고 기다리는 것이 합리적입니다.

이를 위해서는 UWP를 위한 2d/3D Diagram Control 과 단순히 모델을 표시하는 것이 아니라 개발자가 골격/정점 애니메이션에 액세스할 수 있도록 하는 3D 모델 제어 가 필요합니다.

@jesbis UWP용 Win UI의 이러한 USP(고유한 판매 포인트)에 더 많은 사람들을 투입할 것을 촉구합니다.

@weitzhandler

이 문제는 WinUI 3.0 로드맵 에 대해 논의하기 위해 작성되었습니다.

@jesbis 는 명확한 성명을 발표했습니다 .

WinUI는 Windows용 기본 UI 플랫폼(.NET뿐만 아니라 기본 앱 포함)이며 초기 3.0 버전에서는 주로 OS와 독립적으로 만들고 더 빠른 릴리스에서 오픈 소스 개발을 준비하는 데 중점을 두고 있습니다. 주기. 우리는 범위가 올해 미리보기를 할 수 있을 만큼 충분히 실현 가능한지 확인하고 싶습니다.

처음 두 개의 댓글은 주제에 관한 것이었습니다.

다음 6개는 비생산적이며 경멸적인 표현이며 Microsoft 오픈 소스 행동 강령 위반에 가깝습니다.

이것은 Microsoft와의 생산적이고 전문적인 대화로 남아 있어야 합니다.

// 나는 하루 종일 어떤 남자 벤트를 듣기 위해 이 대화를 따르는 것이 아닙니다.

여기에는 두 가지 별도의 토론이 있을 수 있지만 여기에는 몇 가지 훌륭한 의견이 있다고 생각합니다. 대부분의 내용이 이전에 언급되었으므로 이만 줄이겠습니다.

크로스 플랫폼 및 웹

.NET Core는 훌륭합니다. 마침내 우리는 훌륭한 도구와 멋진 언어로 모든 플랫폼과 접점을 목표로 삼을 수 있습니다.
누락된 유일한 것은 Blazor를 제외한 UI 스택입니다(HTML/CSS는 형편없지만). 최대의 비교 가능성을 위해 데스크톱 개발자가 동일한 기술, 도구 및 언어(Xaml 및 C#)를 사용하여 웹 및 그 이상으로 마이그레이션할 수 있는 프레임워크가 있으면 좋을 것입니다. Tbh, Silverlight는 거기에서 훌륭한 일을 했습니다. WinUI에 해당 프레임워크가 필요한지 확실하지 않지만 내부적으로 문제를 제기하십시오. 기본적으로 .NET 개발자를 위한 Flutter와 웹을 대상으로 하는 것이 가장 큰 장점이 될 것입니다.

Xamarin이 해당 플랫폼이 될 수 있는지 확실하지 않지만 그렇다면 Xaml이 WinUI와 Xamarin에서 가능한 한 많이 정렬되어 있는지 확인하세요.

WinUI

이런 일이 일어나야 합니다. Windows 플랫폼에서 가능한 최고의 경험을 만들려면 하나의 공통 Xaml 스택이 있어야 합니다. 이상적으로는 컨트롤 및 기능 측면에서 WPF의 누락된 격차가 채워져야 합니다.

HoloLens 및 그 이상

Lite가 등장하고 HoloLens와 같은 매우 흥미로운 새로운 폼 팩터가 나오면 UWP가 UI 측면에서 이에 대해 준비되지 않았다고 주장할 수 있습니다. 예, HoloLens에서 실행할 수 있어 좋습니다. 하지만 Unity를 완전히 사용하지 않고도 3D용으로 앱을 실제로 최적화하는 방법을 보고 싶습니다.

WinUI는 Xamarin보다 훨씬 앞서 있습니다. 그러나 Microsoft Team은 Xamarin 4.0을 밀어냅니다...
저는 개인적으로 Xamarin이 Cross Platform의 가장 낮은 명칭이기 때문에 더 좋아합니다. 앞으로 SaaS용 Native Apps의 수가 증가할 것입니다.

Xamarin 외에 몇 가지 대안이 있습니다.
1) UNO 플랫폼을 수용하고 SkiaSharp를 사용하여 웹 렌더링을 만드는 것이 어떻습니까?
2) @zezba9000 게임 엔진이 시작하는 데 사용하는 것과 같은 불가지론적 렌더링 백엔드가 필요합니다. 사실 어느정도 인정합니다....

다른 크로스 플랫폼 솔루션과 달리 내부에 비 오픈 소스 코드 추적이 없기 때문에 Microsoft가 WinUI를 더 많이 푸시할 수 있습니다. Xamarin, UNO에는 UNIX 라이브러리가 있을 수 있습니다...

어쨌든 힘이 당신과 함께 할 수 있습니다.
추신: Github 스폰서는 Microsoft에서 제공하므로 WPF/Winforms의 크로스 플랫폼 포크에 대해 일부 주목할만한 Mac/Linux 개발자를 후원해 주십시오.

@jkoritzinsky , WinUI 팀이 WinUI 3.0 이름 바꾸기와 함께 주의해야 할 한 가지: .NET에 프로젝션된 유형의 이름을 바꾸면 프로젝션이 작동하지 않으며 더 이상 추가할 계획이 없습니다. 유지 가능한 확장 가능한 시스템이 아니기 때문에). 다음은 우리가 계획하는 유형 목록입니다. https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

이러한 유형이 아닌 다른 유형을 변경하려면 사용자가 개체를 새 인터페이스를 구현하는 새 개체로 래핑하거나 데이터를 새 유형에 복사해야 합니다. 특히 INotifyPropertyChanged 및 INotifyCollectionChanged 유형은 XAML 아일랜드와 관련하여 관심이 있고 다운스트림 지원을 제공합니다.

나는 동의하고 당신이 이 문제를 제기한 것을 기쁘게 생각합니다. 그러나 나는 이러한 예측이 약간 불행한 악이라고 생각한다고 덧붙이고 싶습니다. 우리는 (System.IO API에 대해 생각하면서) 아마도 있어야 할 모든 단일 API를 예상하지 않으므로 이를 수정하거나 다르게 생각해야 합니다. 마음에 떠오르는 한 가지는 유사하지만 다른 유형을 다른 네임스페이스의 .NET 유형에 추가하지 않는 것입니다. 대신 C++ 개발자가 System.ComponentModel.INotifyDataErrorInfo도 사용할 수 있도록 해야 합니다. 이것은 우리가 C++/CLI에서 수행한 작업이지만 순수 C++ 응용 프로그램에 대해 CLR을 로드할 필요가 없습니다. 그게 더 혼란스러울지는 모르겠지만 API 계층에서 .NET 및 WinRT 기술의 근본적이고 근본적인 차이점이 누출되는 것처럼 느껴져서 일관성이 없어집니다.

@meir-pletinsky. NET은 UWP XAML로 앱을 만드는 데 사용할 수 있는 단 하나의 프레임워크입니다. 어떤 프레임워크를 사용하든 개발자가 사용할 수 있는 텍스트 필드 유효성 검사를 원합니다.

이것은 돈이 아깝지 않습니다. 우리가 관심을 갖고 있는 C++ 개발자가 있습니다. 위에서 언급한 것처럼 .NET 커뮤니티에 혼란을 야기하지 않기를 바랍니다.

@mdtauk , 아니요, WinUI Desktop(이전의 Xaml Desktop)을 사용하면 아일랜드를 사용하지 않고 Win32와 함께 Xaml을 직접 사용할 수 있습니다.

내가 뭔가를 놓치고 있지 않는 한 @meir-pletinsky가 .NET/C++를 언급하고 있다고 생각합니까?

@MarkIngramUK 여기에서 두 가지 다른 프로젝트에 대해 이야기하고 있다고 생각합니다. WinUI는 Win32를 대체해야 합니다. 사람들은 크로스 플랫폼 솔루션을 요구하고 있는데, 이는 합리적이지만 _this_ 프로젝트가 되어서는 안 된다고 생각합니다.

예, 전적으로 동의합니다! 나에게 WinUI는 가장 현대적이고 성능이 뛰어나며 Windows용 최고의 UI를 정의하는 것입니다. Xamarin은 Microsoft의 크로스 플랫폼 스토리여야 하며 WinUI를 기반으로 발전해야 합니다.

@mdtauk

Fluent/FabricWeb 컨트롤 스타일과 더 잘 일치하도록 WinUI 3.0과 함께 실행되는 WinForms, MFC, WPF 컨트롤의 시각적 모양을 업데이트하는 아이디어에 +1을 추가합니다.

확실히 다른 컨트롤 크기(WinRT XAML이 아닌 모든 것은 UWP 컨트롤의 Compact 버전과 해당 메트릭과 일치해야 함)가 있지만 일관성 있고 일관된 세련된 모양입니다.

WinForms에 WinUI 3.0 종속성을 추가하면 컨트롤이 변경됩니다.

WinUI 3.0 WPF 앱은 Fluent.Light.xaml 또는 Fluent.Dark.xaml 제어 테마를 감지하고 사용합니다.

MS가 이러한 프레임워크에 시간과 리소스를 투자하여 기본 Windows 10 앱처럼 보이게 만드는 것을 보고 싶지 않습니다. 그렇기 때문에 WinUI 3.0이 있을 것입니다. WPF/WinForms 앱에서 Windows 10 모양과 느낌을 원하십니까? WinUI 3.0을 사용합니다.
MS는 이전 프레임워크를 다시 방문하기보다 UWP/WinUI와 Win32 대응 간의 기존(및 차단) 격차를 줄이는 데 리소스를 투자해야 합니다. 특히 WinUI가 Windows용 프레젠테이션 프레임워크가 될 것이라는 점을 감안할 때...

WinUI에 대한 설명과 UI/UX에 대한 Microsoft의 의도에 대해 묻고 싶습니다.

1. WinUI는 Win32, ATL, MFC, WinForms, Silverlight(나는 알고 있음), WPF, UWP 및/또는 XAML 아일랜드를 모두 대체합니까(가상적으로?)? 본인은 이러한 기술이 계속 존재하고 일정 기간 동안 계속 지원될 것임을 알고 있습니다 . 나는 이것이 마이크로소프트가 말하는 "앞으로의 길"이며, (예를 들어) WinForms와 WPF를 Win32나 MFC를 고려하는 것과 동일하게 고려해야 한다는 것을 분명히 이해하고 싶습니다.

2. WinUI는 UWP에서 파생됩니까? (또는 둘은 얼마나 유사합니까?) WinUI는 UWP, XAML Islands 또는 WPF와 비교하여 얼마나 유사(또는 다릅니까)합니까?

전문적인 C# 및 C++ 개발자로서 저는 WinForms로 작업을 시작한 다음 WPF로 옮겼고, WinForms에서 비즈니스 목적을 위한 UI/UX를 WPF에서 할 수 있는 것보다 대략 두 배 빠르게 디자인할 수 있었기 때문에 WinForms로 다시 옮겼습니다. WPF는 훨씬 더 많은 유연성과 성능을 제공했으며 훨씬 더 좋아 보였습니다. 그러나 누군가가 XAML을 수동으로 편집하는 대신 Designer를 통해 인터페이스를 터치하자마자 발생하는 XAML 맹글링은 끔찍했습니다. 어떤 경우에는 WinForms(디자이너 사용)가 유사한 XAML 양식이나 컨트롤을 수동으로 구성하는 것보다 훨씬 더 빠릅니다.

개인적으로 저는 Microsoft 제품에서 사용 가능하고 동일한 UI를 원합니다. 유사한 방식으로 Win32 또는 .NET에서 활용할 수 있는 프레임워크는 모든 Microsoft 개발자를 위한 일관되고 현대적인 애플리케이션을 의미하며 단일 기술을 대상으로 하는 세션에서 일반적인 질문과 문제를 해결할 수 있음을 의미합니다. 예를 들어, 컨트롤에 대해 질문할 때 Win32 개발자 또는 .NET 개발자의 대답은 동일합니다(거의 동일하지는 않더라도). 그렇게 하면 "WinUI" 학습이 주어진 개발자에게 어느 스택에나 유용하게 될 것이며, 개발 중인 위치에 관계없이 온라인 정보(StackOverflow 등)에 대한 액세스가 훨씬 더 가치가 있게 될 것입니다. Xamarin을 사용하지 않지만 Xamarin이 이러한 발자취를 따르도록 만들 수 있다면(WinUI의 확장으로?) 위의 설명은 Windows 개발자뿐만 아니라 Android, iOS 등을 대상으로 하는 개발자에게도 적용될 수 있습니다.

어떤 종류의 응용 프로그램에 WinUI를 사용하게 될까요?

WinUI에 대한 나의 이해가 정확하고 Win32, MFC, Forms, WPF 등을 대체하는 "앞으로의 길"이고 동일한 프레임워크를 기본 또는 .NET 개발에 사용할 수 있다면 기꺼이 컴포지션을 대체할 것입니다. 내가 지원하는 응용 프로그램의 _ ALL _에서. 플랫폼이나 스택에 관계없이 동일하게 작동(및 동작)하는 현대적이고 일관된 UI? 그것이 우리 모두가 원하는 것이 아닙니까? WinForms 또는 WPF에서 완전히 별도의 방식으로 이벤트를 처리하는 동안 Win32에서 이벤트를 전달하기 위해 CreateWindowEx() 및 메시지 루프를 실행하는 방법을 모두 기억하고 싶어하는 사람은 없을 것입니다. "현대"를 위한 시간입니다. 그것이 WinUI(3.0)가 되기를 진심으로 바랍니다.

OS 호환성 및 하위 수준 지원

WinUI가 OS와 구성을 분리하는 데 주력하고 있다는 점은 좋은데, 아직 Windows 10도 안 된 고객이 엄청나게 많습니다. 이것이 골칫거리라는 것을 압니다. 우리 모두는 타겟 고객이 최신 버전을 실행하기를 바라지만, 이는 우리 모두가 매일 직면하는 실제 문제입니다. 현재 목표로 하는 가장 오래된 플랫폼이라고 생각되는 1703 이후의 이전 플랫폼에서 WinUI를 사용할 수 있도록 하는 것에 대해 어떤 논의가 이루어지고 있습니까?

WinUI를 정적으로 연결 가능하거나 포함 가능(예: .NET Core/5)으로 만드는 것이 옵션입니까? 우리는 Windows 8.1, Windows 8, Windows 7, 심지어 Windows PE까지 목표로 삼아야 할 것입니다. 이러한 요구 사항으로 WinUI를 어떻게 사용할 수 있습니까?

@쉬델 :

WinUI는 UWP에서 파생됩니까? (또는 둘은 얼마나 유사합니까?) WinUI는 UWP, XAML Islands 또는 WPF와 비교하여 얼마나 유사(또는 다릅니까)합니까?

WinUI 3.0은 어떤 의미에서 Xaml 플랫폼, 구성 및 입력을 포함하여 Windows 10/UWP의 UI 플랫폼 구성 요소의 다음 버전이 될 것입니다. 그것은 그 코드베이스에서 왔습니다.

로드맵에 언급된 사항을 제외하고 Windows 10/UWP Xaml 플랫폼 API와 매우 유사해야 합니다. 즉, 다른 루트 네임스페이스, 다른 기술과의 혼합 및 일치에 대한 더 나은 지원(예: UWP 대신 win32 앱 모델 사용) 및 몇 가지 새로운 추가 기능.

WinUI는 Win32, ATL, MFC, WinForms, Silverlight(나는 알고 있음), WPF, UWP 및/또는 XAML 아일랜드를 모두 대체합니까(가상적으로?)? 본인은 이러한 기술이 계속 존재하고 일정 기간 동안 계속 지원될 것임을 알고 있습니다. 나는 이것이 마이크로소프트가 말하는 "앞으로의 길"이며, (예를 들어) WinForms와 WPF를 Win32나 MFC를 고려하는 것과 동일하게 고려해야 한다는 것을 분명히 이해하고 싶습니다.

WinUI는 Windows의 기본 앱 UI에 대한 주요 활성 개발 및 진행 상황입니다. 또한 Windows 자체와 기본 Microsoft 앱 및 장치에서 사용하는 것입니다.

Xaml 섬은 WinUI의 일부이며 WinUI를 사용하여 기존 앱(예: WPF, WinForms)에서 새 보기를 만들 수 있습니다.

현재 목표로 하는 가장 오래된 플랫폼이라고 생각되는 1703 이후의 이전 플랫폼에서 WinUI를 사용할 수 있도록 하는 것에 대해 어떤 논의가 이루어지고 있습니까?
WinUI를 정적으로 연결 가능하거나 포함 가능(예: .NET Core/5)으로 만드는 것이 옵션입니까? 우리는 Windows 8.1, Windows 8, Windows 7, 심지어 Windows PE까지 목표로 삼아야 할 것입니다. 이러한 요구 사항으로 WinUI를 어떻게 사용할 수 있습니까?

이에 대한 피드백을 공유해 주셔서 감사합니다. 3.0의 경우 로드맵의 플랫폼(1703+, 8.1에서 일부 지원 포함)에 중점을 둡니다. 우리는 개발자들에게도 다른 버전의 고객이 있다는 것을 확실히 이해하고 있으며, 이는 우리가 앞으로 평가할 계획입니다.

굉장합니다. WinUI가 "앞으로 나아가는 길"인 것처럼 들리고, 이에 대한 이해를 감안할 때 제가 흥분된다고 말하는 것은 절제된 표현이 될 것입니다.

특히 XAML 아일랜드를 통해 개발자가 WinUI를 WPF 및 WinForms와 같은 이전 기술로 확장할 수 있다는 점은 환상적이라고 생각합니다. 그것은 오래된(어) 프로젝트를 작업/확장하는 동안 "앞으로" 훌륭한 다리입니다.

굉장합니다. WinUI가 "앞으로 나아가는 길"인 것처럼 들리고, 이에 대한 이해를 감안할 때 제가 흥분된다고 말하는 것은 절제된 표현이 될 것입니다.

특히 XAML 아일랜드를 통해 개발자가 WinUI를 WPF 및 WinForms와 같은 이전 기술로 확장할 수 있다는 점은 환상적이라고 생각합니다. 그것은 오래된(어) 프로젝트를 작업/확장하는 동안 "앞으로" 훌륭한 다리입니다.

WinUI 3.0이 포함된 WinForms, MFC 또는 WPF 프로젝트가 생성된 경우 Form/WPF Window/HWND Window에서 XAML Island를 사용하지 않고도 XAML 페이지/컨텐츠/창을 렌더링할 수 있다고 생각하고 싶습니다.

순수 XAML을 사용하거나 섬을 사용하여 프레임워크 제공 표면에 XAML을 배치하는 기능은 WinUI 3.0을 진정으로 "모든 것을 지배하는 하나의 UI"로 만들 것입니다.

진정으로 WinUI 3.0을 "모든 것을 지배하는 하나의 UI"로 만들 것입니다.

... 윈도우에서. 😉

WinUI 3.0은 어떤 의미에서 Xaml 플랫폼, 구성 및 입력을 포함하여 Windows 10/UWP의 UI 플랫폼 구성 요소의 다음 버전이 될 것입니다. 그것은 그 코드베이스에서 왔습니다.

그 메모에서 @jesbis , WPF와 UWP 간의 통합이 어떻게 진행될 것인지에 대해

물론 시도가 있었지만 개발하는 데 2년이 넘게 걸렸음 에도 불구하고

또한 WPF 태그에서 사용할 수 있었던 많은 서비스가 UWP에서 사용 가능하고 구현되어야 합니다. 새로운 UWP 기반 WinUI 3.0 마크업이 WPF와 완전히 일치하도록 하기 위한 노력이 여기에 있습니까? 이것이 어딘가에 설명되어 있다면 사과하지만, 나는 그것을 보기 위해 아직 메시지를 구문 분석하지 않았습니다(그리고 내 이해를 수정/보완하기 위한 모든 리소스를 환영합니다).

진정으로 WinUI 3.0을 "모든 것을 지배하는 하나의 UI"로 만들 것입니다.

... 윈도우에서. 😉

적어도 WinUI 3.0의 릴리스 창에서는. XAML 렌더링을 다른 플랫폼으로 가져오는 프로세스의 시작이 되길 바랍니다...

WPF와 UWP 간의 통합이 어떻게 진행될지 말씀해 주실 수 있는지 궁금합니다. 특히, 몇 년 동안 UWP에서 요청한 마크업 확장과 같은 개념은 거의 성공을 거두지 못했습니다. [...] 새로운 UWP 기반 WinUI 3.0 마크업이 WPF와 완전히 일치하도록 하기 위한 노력이 여기에 있습니까?

@Mike-EEE WPF의 완전한 충실도는 3.0의 목표가 아닙니다. 그러나 우리는 시간이 지남에 따라 격차를 좁히기 위해 많은 작업 항목을 추적하고 있습니다(예: #741 마크업 확장 개선 - 살펴보고 이것이 귀하의 요구 사항을 충족하는지 여부에 대한 의견을 남겨주세요!) WPF(예: # 686 3D 모델 지원).

WinUI에서 사용하고 싶은/필요한 WPF의 다른 특정 기능이 있는 경우 해당 기능에 대한 새로운 기능 제안 문제를 자유롭게 열거하거나 최근 " WPF 기능이 WinRT XAML에 있어야 함 " 문제 #719에 댓글을 남겨주세요. 우리는 무한한 자원을 가지고 있지 않지만 우리 계획에서 커뮤니티의 의견을 반영하려고 확실히 노력하고 있습니다. 모든 것이 오픈 소스가 되면 누구나 잠재적으로 기능을 제공하는 데 도움을 줄 수 있습니다.

격려가 됩니다. @jebis 님,

내 눈에 띄는 관심사는 전체 WPF 충실도가 목표가 아니고 WPF 내에서 WinUI를 활용하는 것이 목표인 경우 WPF 채택과 마찰에 부딪히게 될 것입니다. 우수한(그리고 독창적인) Xaml 모델이 있기 때문입니다.

즉, Xaml Islands에 명백한 가치 제안이 없는 것과 마찬가지로 WinUI3.0을 WPF에 통합하기 위한 명백한 가치 제안이 없는 것 같습니다. 하루가 끝나면 퇴보한/열등한/저개발된 Xaml 모델을 기존의 우수한 Xaml 모델로 가져오려는 것처럼 보일 수 있습니다. 이는 단순히 의미가 없습니다.

WinForms, MFC 등의 사용 사례의 경우 이 접근 방식은 WinUI3.0에 적합합니다. 그러나 WPF를 사용하면 MSFT 또는 외부 공급업체의 다른 이니셔티브와 비교할 수 없는 우수한 프레젠테이션 모델 및 개발자/디자이너 패러다임이 있습니다.

@Mike-EEE Scott Hunter의 말에 따르면 "하나의 BCL이 그들 모두를 지배"하는 목표가 "그들을 모두 지배하는 하나의 UI"보다 더 높은 우선 순위에 온다는 것이 잘못된 것 같습니다.

웹을 통한 웹 어셈블리의 MONO 기본 Xamarin Forms XAML 및 UNO XAML을 AoC, Xamarin Forms XAML 기반 앱이 있는 공통 BCL로 대체함으로써 웹의 Uno XAML은 속도 성능에서 모든 이점을 얻을 수 있습니다.

이 속도 성능은 다른 기술(예: 플러터, 반응 등)에서 오는 치열한 경쟁의 관점에서 크로스 플랫폼용 C#에 투자하는 경력의 미래를 걱정하는 모든 사람에게 매우 중요합니다.

바라건대, .NET5 = 그것들을 모두 지배하는 공통 BCL을 향한 이 여정에서 XAML 표준화는 프로세스를 따라 부분적으로 또는 완전히 처리되지만 .NET5의 주요 목표는 아닙니다.

XAML 표준화의 필요성 외에 또 다른 우선 순위는 모든 플랫폼(모바일, 데스크톱 및 웹)에 유창한 디자인을 통해 Microsoft 브랜딩을 확산하는 것입니다. [기술적으로 WinUI 3.0 로드맵의 목적에 초점을 맞추기 위해 몇 번이고 거듭 묻고 있는 Win UI 3.0을 통한 디커플링]

결국, Win UI가 생성하는 UWP가 .NET5가 출시될 때 2020년 11월까지 모두를 지배하는 이 하나의 BCL에서 실제로 역할을 하는 것 또한 제 생각에는 높은 우선 순위 목표가 아닙니다.

마케팅 관점에서 볼 때 불행히도 우리가 깊이 관심을 갖고 있는 기술로 번역되지는 않았지만 유창한 디자인을 통한 Microsoft 브랜딩은 유비쿼터스 이며 해당 디자인을 홍보하는 앱 은 모든 곳에서 빠르게 진행됩니다.

이것이 내가 모바일 존재의 부족으로 인해 "시장 점유율을 따라잡기" 위한 Microsoft의 장기 전략을 보는 방법입니다.

이것은 Hololens 2와 그 이후에 훨씬 더 큰 가능성이 있다는 점을 제외하고는 분명합니다. 이를 위해 WinUI 3.0이 포함된 UWP 앱에 3D 다이어그램 컨트롤 및 고급 3D 모델 뷰어가 제공되는지 확인해야 합니다.

죄송합니다. 내가 가진 제한된 시간을 BEST OF BEST TECHNOLOGY에 사용하고 싶어서 계속 이 작업을 추진하고 있습니다. :-)

WinUI 3.0 전환 기간에 대해

Microsoft는 다음을 위해 Windows Community Toolkit 유지 관리자(일부는 MS에서 작동)와 직접 협력할 것을 제안합니다.

1. 툴킷을 WinUI 3.0(샘플 앱 포함)으로 대상을 변경하는 동안 예상치 못한 장애물이 있는지 테스트하십시오.
2. Visual Studio 또는 "다른 도구"를 통해 자동 네임스페이스 이름 바꾸기를 테스트하여 얼마나 원활하게 진행되는지 확인하십시오.
3. 프로세스가 어떻게 진행되었는지 공개적으로 보고합니다(블로그 게시물/GitHub 문제/원하는 모든 것).
4. WinUI 3.0 및 프로젝트 관리자가 GitHub/Nuget/기타 추가 정보에 추가할 수 있는 전환에 대한 텍스트의 복사 + 붙여넣기를 제공하거나 이에 대한 간결한 정보가 포함된 적어도 URL을 제공하십시오. 이렇게 하면 해당 프로젝트의 모든 사용자가 WinUI 3.0에 대해 빠르게 이해하고 전환을 완료하기 위해 수행해야 하는 작업을 설명하는 데 도움이 됩니다.
5. 프로젝트/라이브러리 유지 관리자가 채택할 수 있는 제안된 전환 프로세스 및 일정을 간략하게 설명합니다.

마지막 항목과 관련하여 다음과 같은 제안을 포함해야 합니다.

• WinUI 3.0 앱(예: WCT v6.0)과 함께 사용됨을 나타내는 새 주요 릴리스 번호를 만듭니다.
• 선택적으로(?) 아직 WinUI 3.0으로 업데이트되지 않은 프로젝트를 지원하는 레거시 코드를 포함하는 분기를 만듭니다.
• 레거시 프로젝트에 대한 지원이 제공될 기간(예: 3/6/12개월)을 제공합니다(예: 메인 브랜치에서 버그 수정 등 병합). 여기에는 커뮤니티 프로젝트/도서관 전체에서 지원 기간을 '동기화'하기 위한 특정 날짜가 있을 수 있습니다.

마지막으로 Windows 10 버전 1507 및 1607 LTSB를 지원해야 하는 경우 수행할 수 있는 작업을 식별하는 것이 중요하다고 생각합니다. 이들은 W10에서 지원되는 버전 중 유일하게 2가지 버전으로 출시될 예정이며 WinUI 3.0은 릴리스 시점에 호환되지 않습니다.

원래는 프로덕션 품질의 오픈 소스 앱이기 때문에 Windows 10 계산기로 프로세스를 테스트할 것을 제안하려고 했습니다. 그러나 나는 이 앱이 6-7년 동안 1507 & 1607 LTSB에서 실행되어야 한다는 것을 깨달았습니다. 특히 소규모 커뮤니티 프로젝트의 경우 이러한 유형의 앱을 지원하는 것과 관련하여 분명히 약간의 논쟁이 있을 것입니다. 그들이 정말로 이러한 지원을 필요로 한다면, 그렇게 하는 방법에 대한 명확한 장기 전략이 제공되어야 합니다.

WinUI 4.0/3.x/vNext 관련

여기 댓글에서 알 수 있듯이 커뮤니티에는 WinUI의 향후 릴리스에 대한 매우 긴 희망 목록이 있습니다. 우리는 보다 장기적인 계획 중 일부를 공개적으로 문서화하여 여기에서 구축되고 있는 추진력과 열정을 실제로 활용해야 합니다.

이러한 항목의 대부분은 v3.0의 범위를 벗어났기 때문에 WinUI 4.0/3.x/vNext에 대한 커뮤니티 피드백 수집을 시작하려면 조만간 새로운 문제가 생성되어야 한다고 생각합니다. 있다면 WinUI 팀이 고려하고 있는 작업 유형과 WinUI 및/또는 다른 MS 팀의 책임 범위를 벗어난 작업을 식별하는 데 도움이 됩니다.

마지막 요점의 예 - 다음 사항을 정말 보고 싶습니다.

• UWP 프로젝트에 대한 .NET Core 3.0 지원(내가 이해하는 한 .NET 팀의 책임)
• Visual Studio App Center의 Windows 앱(UWP 및 Win32)에 대한 전체 지원(WinUI 팀이 담당하는 것은 아님)
• Material Design 문서에서 찾을 수 있는 것과 유사한 보다 구체적인 Fluent Design 지침(다시 별도 팀의 책임)
• 인박스 W10 앱에서 WinUI 3.0 및 Fluent 디자인 사용(별도의 팀 및 일부 앱은 LTSB 버전을 지원해야 함)

이러한 범위를 벗어난 항목을 식별하여 커뮤니티를 적절한 피드백 지점으로 리디렉션하거나 해당 영역에서 진행 중인 작업을 설명할 수 있습니다.

그 외에도 범위 내 희망 목록이 함께 모이기 시작할 수 있으며 커뮤니티는 향후 WinUI에서 가장 원하는 것에 대한 지원을 표시할 수 있습니다.

예를 들어 C#과 동일한 프로젝트 템플릿을 사용하는 것과 같이 F#이 C#과 동등하게 지원된다면 좋을 것입니다.

WinUI(UWP vNext)에 Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency 및 Show() / ShowDialog() 메서드가 있는 WPF와 같은 적절한 Window 개체가 있기를 바랍니다.

(_이 창이 휴대 전화 및 IoT와 같은 작은 화면 장치에서 어떻게 작동하는지(또는 허용되는지) 잘 모르겠습니다_)

@TonyHenrique 1903년에 UWP를 위한 새로운 윈도우 API가 있지만 아직 끝나지 않았습니다.

WinUI 3.0의 범위 내에서 XAML의 렌더링을 다시 살펴보고 있습니다.

WPF의 렌더링에서 한 단계 떨어진 느낌은 다음과 같습니다.

• ClearType을 사용하지 않는 텍스트 대신 그레이스케일 앤티앨리어싱을 선호합니다.
• 테두리 선과 같은 것에 대한 픽셀 정밀도가 부족합니다.

Windows Phone 7과 Windows Phone 8이 언제 렌더링 시스템을 공유해야 하는지 이해할 수 있습니다. 화면 기술의 유형과 렌더링 속도가 더 나은 성능을 위해 밀어붙이고 있었습니다. 그러나 WinUI가 먼저 데스크탑으로 피벗하고 더 큰 디스플레이로 인해 이러한 품질을 XAML 렌더 엔진으로 복원해야 할 때일 수 있습니다.

그리고 Hololens와 Xbox와 같은 것이 특별한 고려가 필요한 경우, 지금처럼 렌더링이 필요한 장치에서 플랫폼 수준에서 켤 수 있는 성능 모드를 제공하지 않는 이유는 무엇입니까?

f# 템플릿은 어떻습니까?

.NET Framework 4.5 이상을 대상으로 하는 표준 Windows Forms 및 WPF 프로젝트 템플릿에서 기본적으로 작동하지 않는 한 WinUI 라이브러리를 채택할 수 없습니다.

최신 Windows 10 릴리스 및/또는 UWP 응용 프로그램만 필요하면 Fluent 디자인을 채택할 수 있습니다.

Microsoft는 Windows Community Toolkit 유지 관리자(일부는 MS에서 작동)와 직접 협력할 것을 제안합니다.

@kmgallahan
좋은 제안! 이것은 확실히 계획에 있습니다. 우리 팀은 종종 Windows Community Toolkit 유지 관리자와 긴밀하게 협력하며 테스트 프로젝트로 사용하고 싶은 것 중 하나입니다.

WinUI 3.0의 범위 내에서 XAML의 렌더링을 다시 살펴보고 있습니다.

@mdtauk
렌더링 변경 사항은 3.0의 범위를 벗어날 가능성이 높지만 후속 릴리스에 대한 아이디어를 잠재적으로 다시 검토할 수 있도록 문제를 여십시오. 큰 초점은 Windows 8+에서 몇 가지 렌더링 변경으로 이어진 보편적인 성능이었습니다. 성능 모드 스위치는 흥미로운 아이디어입니다.

f# 템플릿은 어떻습니까?

@edgarsanchez , @khoshroomahdi
F#에 대한 관심이 많아지는 것 같습니다! F#을 원하는 이유에 대해 더 듣고 싶습니다. F# 문제에서 원하는 이유와 용도에 대해 자유롭게 의견을 보내주세요. #740

.NET Framework 4.5 이상을 대상으로 하는 표준 Windows Forms 및 WPF 프로젝트 템플릿에서 기본적으로 작동하지 않는 한 WinUI 라이브러리를 채택할 수 없습니다.

@jozefizso
Xaml 군도를 살펴보셨나요? 이 기능을 사용하면 WPF 및 Windows Forms 애플리케이션에서 WinRT Xaml을 사용할 수 있으므로 최신 Xaml 보기/페이지로 향상시킬 수 있습니다.
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

우리는 WinUI 3.0에 섬을 포함하고 Creators Update 이상(최소한 Windows의 마지막 5개 버전인 최신 버전)과 역호환되도록 계획하고 있습니다.

WinUI 3.0과 함께 Creators Update 이상에서 작업하는 Xaml Islands가 요구 사항을 충족할 수 있습니까?

렌더링 변경 사항은 3.0의 범위를 벗어날 가능성이 높지만 후속 릴리스에 대한 아이디어를 잠재적으로 다시 검토할 수 있도록 문제를 여십시오. 큰 초점은 Windows 8+에서 몇 가지 렌더링 변경으로 이어진 보편적인 성능이었습니다. 성능 모드 스위치는 흥미로운 아이디어입니다.

완료 #768

XAML 아일랜드에는 Windows 10, 버전 1903이 필요하고 Windows Community Toolkit 라이브러리에는 프로젝트가 UWP여야 합니다. 그건 안돼.

XAML 아일랜드에는 Windows 10, 버전 1903이 필요하고 Windows Community Toolkit 라이브러리에는 프로젝트가 UWP여야 합니다. 그건 안돼.

WinUI 3.0은 Windows 7/8/8.1로 이동하지 않지만 해당 OS는 곧 단종됩니다. 그리고 현재로서는 여전히 WPF 및 WinForms를 사용할 수 있습니다. 사용자가 Windows 10으로 이동한 경우입니다.

이 경우 프로젝트는 Windows 10용 UWP이므로 WPF/WinForms를 지원하는 것은 의미가 없습니다. 이것은 단지 원을 그리며 개발자 도구를 조각화하는 것입니다.

@jozefizso UWP가 WPF 및 WinForms와 더 유사하도록 변경되고 있고 XAML UI가 WPF 및 WinForms 플랫폼에 가까워지고 있다고 말하는 것이 더 정확합니다.

제한적인 샌드박스를 벗어나고 WPF 및 WinForms 플랫폼에 연결할 수 있는 최신 XAML UI가 포함된 UWP 앱.

이것이 내가 이해하는 방식입니다.

XAML 아일랜드에는 Windows 10, 버전 1903이 필요합니다.

이 경우 프로젝트는 Windows 10용 UWP가 됩니다.

WinUI 3.0에서는 아일랜드를 1703 이상에서 사용할 수 있도록 계획하고 있습니다(훨씬 더 뒤로).

또한 UWP(비공식적으로 "WinUI 데스크톱"이라고 함) 대신 Win32 앱 모델에서 WinUI를 사용할 수 있도록 노력하고 있으므로 UWP 앱일 필요는 없습니다.

또한 UWP(비공식적으로 "WinUI 데스크톱"이라고 함) 대신 Win32 앱 모델에서 WinUI를 사용할 수 있도록 노력하고 있으므로 UWP 앱일 필요는 없습니다.

이것은 내가 가장 흥분되는 것입니다. Windows의 전체 API를 사용할 수 있는 기본 응용 프로그램은 Win32이든 Windows 런타임이든 상관없이 Xaml을 통해 성능이 뛰어난 UI를 가질 수 있습니다.

또한 UWP(비공식적으로 "WinUI 데스크톱"이라고 함) 대신 Win32 앱 모델에서 WinUI를 사용할 수 있도록 노력하고 있으므로 UWP 앱일 필요는 없습니다.

이것은 내가 가장 흥분되는 것입니다. Windows의 전체 API를 사용할 수 있는 기본 응용 프로그램은 Win32이든 Windows 런타임이든 상관없이 Xaml을 통해 성능이 뛰어난 UI를 가질 수 있습니다.

WinForms 앱을 사용하고 코드 숨김을 유지하되 Form을 XAML 창으로 바꾸고 모든 브러시와 XAML 컨트롤에 액세스할 수 있습니다.

WPF는 WinUI XAML을 제자리에 사용하는 것보다 약간 더 복잡하지만 적어도 WPF 컨트롤은 WinUI 컨트롤과 일치하도록 스타일을 지정할 수 있습니다.

1. 네임스페이스의 이름을 바꿔야 합니다. "Xaml"은 Xaml이 기본 UWP 구성 요소에 대한 마케팅 언어(자주 변경됨)로 잘못 사용되고 있는 마크업 언어를 참조하기 때문에 적절하지 않습니다. "Xaml"은 "WinUI"로 바꿔야 합니다. "Xaml"이 .xaml 언어를 나타내는지 또는 ui 구성 요소를 나타내는지 여부가 매우 자주 불분명한 이 스레드에서도 얼마나 많은 혼란이 발생했는지 알 수 있습니다.
2. 이것이 WPF와 UWP를 더 가깝게 이동시키는 한 이것은 좋습니다. 각각 다른 기능에는 없는 기능이 있으며 이 둘을 결합한 "Windows UI"가 있는 것이 좋습니다. 기능의 일부 중복이 있을 수 있지만 전환 경로 WPF -> UWP일 수도 있습니다.
3. Windows 버전에서 분리하는 것은 의미가 있지만 이 작업이 완료되면 Win7이 EOL을 훨씬 능가할 것이라는 점을 감안할 때 상대적으로 업데이트된 Win10을 가정하는 것도 좋습니다.

Xaml은 UI 프레임워크의 이름입니다. 따라서 Windows.UI.Xaml...

Xaml은 UI 프레임워크의 이름입니다.

Xaml은 개발자가 응용 프로그램 내의 프레젠테이션 장면뿐만 아니라 응용 프로그램 자체를 강력하게 설명하고 구성할 수 있도록 하는 WPF의 기술이었습니다. 즉, UI 요소 _및 POCO_를 설명할 수 있습니다. .NET이라면 ​​Xaml로 풍부하게 기술하고 애플리케이션 컨텍스트에 로드할 수 있습니다.

Xaml이 eXtended Application Markup Language의 약자라는 사실을 잊어버리지 않도록 하십시오. Xaml은 .NET _application_ 구성 요소를 우아하고 효율적으로 설명할 수 있는 마크업 언어라는 의미입니다. 주로 사용자 인터페이스 요소를 설명하는 데 사용되었지만 실제로는 그렇게 강등되거나 제한되지 않았습니다.

저는 개인적으로 Xaml을 사용하여 전체 응용 프로그램 구성을 설명하고 App.config(예, Web.config도 포함)를 제거하고 교체하면서 복잡성을 절대적으로 필요로 하는 외부 API의 경우를 제외하고는 복잡하게 만들었습니다.

Xaml은 UI가 _아닌_입니다. 그것들은 완전히 다른 두 가지 개념이지만 불행히도 UWP에서 수년 동안 병합되었습니다. 나는 "Xaml"이라는 용어가 이러한 노력에서 풀려나는 것을 _사랑_ 하고 싶지만, 그러한 조치가 시행되는 것은 고사하고 고려될 것이라고 확신하지 못합니다.

@charlesroddie 나는 명명이 정말로 임의적이라는 데 동의합니다. WUXaml 네임스페이스에서 비롯된 것의 스택 추적을 검사하는 경우 실제로는 내부적으로 DirectUI 네임스페이스에 있는 접선입니다. 다른 이야기가 있을 거라고 생각하기 때문에 그 당시 주변에 누군가가 있었다면 Win8의 이야기를 알고 싶습니다. 레이어 합성을 위한 DirectComp, 부드러운 스크롤 및 러버 밴딩을 위한 DirectManipulation, 그리고 모든 것을 함께 끌어내기 위해 맨 위에 DirectUI가 있는 벡터 그래픽 엔진인 Direct2D/DirectWrite. 그런 다음 어떤 이유로 일부는 Win7으로 다시 포팅되었으며 Xaml 비트만 WinRT 시스템을 통해 노출되었으며 다른 모든 API는 샘플을 보는 데 필요한 이상한 팩토리 및 패턴이 있는 암호 통신 인터페이스로 남겨졌습니다. 부르다.

사실, 지금 생각해보면 WUComposition이 WinRT를 통해 DirectComp와 DirectManipulation을 노출한 것처럼(또는 재작성인 경우) Direct2D/DirectWrite가 여기에도 공식 홈이 있다면 정말 좋을 것입니다. 그들은 모두 함께 작동하여 다양한 수준의 탈출 해치와 원하는 경우 충실도의 접점을 제공합니다. Win2D는 실제로 반쯤 구워졌고 좋은 API도 아닙니다.

Windows.UI.Composition은 내가 믿는 DirectComposition의 재작성입니다. API는 비슷하지만 동일하지는 않습니다.

모든 모니터가 더 이상 sRGB라고 가정하지 마십시오.
모든 레거시 앱의 색상을 sRGB로 처리하고 구성하는 동안 각 모니터에 대해 변환합니다.

이것은 약간 주제에서 벗어난 수 있지만 ++, 당신은 당신이 최소한의 의존성과 WinUI 또는 경화제를 사용 할 수 있도록 단지 인 -없이 사용 경화제처럼의 UI 시스템을 현대화하려는 당신이 이미 C로 작성된 대규모의 Win32 appliation을 가정 할 수 상자 컨트롤 세트 또는 XAML 없이도 가능 합니다.

그것은 이미 가능하지만 우리는 그것을 위해 WinUI 3.0을 기다릴 필요가 없습니다.

네이밍에 대한 피드백을 주셔서 감사합니다. 언급한 바와 같이 오늘날 혼동을 일으킬 수 있는 "Xaml 플랫폼" 과 "Xaml 언어" (자체 사양/방언 포함) 사이에 구별이 있습니다. 나는 주요 리브랜딩이 카드에 있다고 생각하지 않지만 우리는 명명 및 네임스페이스에 대해 확실히 논의하고 있습니다.

Photoshop과 같은 기존 응용 프로그램을 현대화하기 위해 XAML 없이 C++ Win32 응용 프로그램에서 Windows.UI.Composition을 사용합니다. 그들은 이미 UI 아키텍처를 가지고 있습니다.

이것은 주제에서 약간 벗어날 수 있지만 이미 C++로 작성된 대규모 Win32 응용 프로그램이 있다고 가정하고 UI 시스템을 현대화하려고 하므로 In- 없이 Comp만 사용하는 것과 같이 최소한의 종속성으로 WinUI 또는 Comp를 사용할 수 있습니다. 상자 컨트롤 세트 또는 XAML 없이도 가능합니다.

이에 대한 피드백에 감사드립니다. Windows.UI.Composition을 사용하는 "프레임워크가 없는" 앱과 유사하게 오늘날 이미 할 수 있는 WinUI 3에서 이것이 가능하기를 바랍니다. WinUI NuGet 패키지 및 종속성을 구성하는 방법을 결정할 때 이 점을 염두에 두겠습니다.

모든 모니터가 더 이상 sRGB라고 가정하지 마십시오.
모든 레거시 앱의 색상을 sRGB로 처리하고 구성하는 동안 각 모니터에 대해 변환합니다.

@reli-msft 별도의 문제를 열어 추적할 수 있습니까?

@jesbis 👉 # 67

Apple은 오늘 SwiftUI를 발표했습니다...

개발자가 XAML 및 코드 숨김 대신 코드를 사용하여 앱을 만들도록 선택할 수 있도록 Xaml Direct 에 Visual Studio 템플릿이 제공된다면

나는 주요 리브랜딩이 카드에 있다고 생각하지 않지만 우리는 명명 및 네임스페이스에 대해 확실히 논의하고 있습니다.

@jesbis 감사합니다. 이 스레드에 참여해주셔서 감사합니다. 일반적으로 누군가가 이런 게시물/공지사항을 작성하고 죽은 상태로 두는 것 같으므로(또는 다른 사람들이 관리를 제대로 하지 못하는 경우), 스레드 작성자로서 귀하가 참여하고 있을 뿐만 아니라 다른 사람들이 말하는 것. 특히 다른 사람들이 _me_일 때. 😆

1) 사용자 인터페이스 플랫폼과 2) 언어/마크업/설명 메커니즘이 있습니다. 내 비판적 발언에서 나는 (첫 번째) 사용자 인터페이스 플랫폼에 대해 충분한 공을 들인 적이 없다고 말할 것입니다. Windows 팀이 이 문제에 관해 많은 훌륭한 작업을 수행했다는 것을 알고 있기 때문입니다. 그것은 개인적으로 나에게 결코 걱정거리가 되지 않았습니다. 그것은 나의 (그리고 다른 사람들의) 분노와 경악을 불러일으키는 두 번째 영역이며, 우리는 이것을 몇 년 동안 생겨난 UserVoice 문제에서 볼 수 있습니다.

이 모든 것은 내가 이 두 영역을 더 잘 분류하기 위한 브랜딩 노력을 더 고려해 달라고 적어도 요청(간청, 심지어 😅)할 것이라고 말했습니다. 이름이 "마크업 언어"를 의미하기 때문에 "Xaml Direct"가 여기서 혼란의 정점이라고 생각합니다. 이름이 맞습니다! -- 그러나 실제 사용법에는 그런 것이 없습니다. 매우 혼란스럽고 오해의 소지가 있으며 브랜드의 경계선 남용을 제안합니다.

Xaml Direct에 대해 말하자면 @mdtauk :

개발자가 XAML 및 코드 숨김 대신 코드를 사용하여 앱을 만들도록 선택할 수 있도록 Xaml Direct에 Visual Studio 템플릿이 제공된다면 어떨까요?

CSharpForMarkup 과 같은?

Xaml Direct보다 훨씬 낫고 적절한 이름을 제안합니다. 물론 _any_ 이름이 될 것입니다. 😉

Xaml Direct에 대해 말하자면 @mdtauk :

개발자가 XAML 및 코드 숨김 대신 코드를 사용하여 앱을 만들도록 선택할 수 있도록 Xaml Direct에 Visual Studio 템플릿이 제공된다면 어떨까요?

CSharpForMarkup 과 같은?

Xaml Direct보다 훨씬 낫고 적절한 이름을 제안합니다. 물론 _any_ 이름이 될 것입니다. 😉

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

코드에서 XAML UI를 작성하는 미들웨어용으로 설계되었지만 XAML 파일 대신 사용할 템플릿이 있다면 어떻게 될까요? 그냥 놔둘 생각...

@mdtauk 네! SwiftUI는 Xaml처럼 보이지만 코드로 수행됩니다. 나는 React가 하는 방식대로 코드에 있는 모든 것에 대한 아이디어를 정말 좋아합니다. 디자인 파일을 분해한 다음 일종의 코드 숨김과 연결하는 것은 일종의 구식이며 유지 관리가 어렵다는 것을 알았습니다.

친구가 iPad Pro의 120hz 디스플레이와 작동하려면 SwiftUI 레이아웃 엔진이 필요하다고 방금 언급했습니다. 그것이 그들이 집중한 것입니다. 정말 매력적입니다.

나는 SwiftUI에서 영감을 받은 변경 사항에 대한 토론이 @eklipse2k8에 갈 수 있는 새로운 문제 #804를 만들었습니다.

비주얼 Basic.😀을위한 템플릿을 추가하는 것을 잊지 마십시오

WPF가 WinUI 3의 하위 계층을 _on_ 구축하도록 하십시오!

@reli-msft WPF를 업데이트하여 어떤 이점을 얻고 싶습니까?

WinUI에서 보고 싶은 특정 WPF 기능이 있는 경우 "WinRT [WinUI]에 있어야 하는 WPF 기능" 스레드에서 더 많은 정보를 듣고 싶습니다. https://github.com/microsoft /microsoft-ui-xaml/issues/719

새로운 고정 문제 #888에 찬성하여 마감

정말 기대됩니다. 특히 버전과 관련된 많은 문제를 해결할 것입니다.

@weitzhandler [ 2019년 5월 16일

나에게 모든 기술적 세부 사항은 덜 중요합니다.
UWP, WPF 또는 모든 Windows 전용 프레임워크는 아무리 훌륭하더라도 모든 플랫폼(최소한 Windows, Droid, iOS 및 웹)에서 실행되지 않고 모든 화면 크기.

일반적으로 WinUI 및 XAML에 따라 다음과 같은 측면에서 개선을 보고 싶습니다. 그 중 일부는 제 작업을 성가시게 하고 느리게 합니다.

• 훨씬 더 많은 내장 변환기 변환기가 많이 있어야 하며 그 중 일부는 장황함을 줄이기 위해 마크업 확장으로 사용해야 합니다. 여기에는 간단한 산술 작업, 객체 대 부울 변환기(의미론적 값에 의한 false, 즉, 컨텍스트당 빈 문자열, 빈 컬렉션, 숨겨진 가시성 등)를 부정하는 것도 포함되어야 합니다.
• 위와 같지만 동작이 있습니다. 바인딩과 이벤트/액션 간에 쉬운 포트가 있어야 합니다. 그것이 내장되어 있고 개발자가 테스트되지 않은 NuGet을 사용할지 의심하지 않는다면 훨씬 쉬울 것입니다.
• 일부 바인딩 유형, 태그 확장, 일반 보기 등 WPF에서 누락된 모든 항목.

감사합니다!

훨씬 더 많은 내장 변환기

배비지(Babbage)의 분석 엔진과 튜링(Turing)의 보편적 계산 이론 이후, 모든 컴퓨터가 실행할 수 있는 모든 프로그램을 실행할 수 있는 단일 컴퓨터가 가능했습니다. 하고 싶은 모든 계산을 위해 새 컴퓨터를 만들어야 하는 시간으로 돌아가고 싶을 것입니다.

전체 변환기 사업은 무례하게 버려야 합니다.

부울 변환기 개체

부울은 부울입니다. 다른 개체는 부울이 아닙니다. 그리고 객체에서 부울로의 자연스러운 변환은 없습니다. 유형은 .Net에서 중요하며 유형이 지정되지 않은 추가 시스템은 사용자에게 노출되어서는 안 됩니다.

예, 바인딩과 같은 기존의 유형이 지정되지 않은 시스템도 버려야 합니다.

전체 변환기 사업은 무례하게 버려야 합니다.

당신의 대안은 무엇입니까?
변환기에 대한 나의 고충은 사용자가 직접 다시 작성하거나 NuGet에서 선택해야 하고 너무 장황하다는 것입니다. 산술이나 부정 등과 같은 표현을 허용하지 않는 것 외에도 유연하지 않습니다.

부울은 부울입니다. 다른 개체는 부울이 아닙니다.

맞습니다. 하지만 UI에 관해서는 별로 중요하지 않습니다.
기존의 객체 상태를 기반으로 항목을 표시/숨기기를 원합니다. 모든 것이 전용 가시성 속성을 가져야 하는 것은 아닙니다.

바인딩과 같은 기존의 유형이 지정되지 않은 시스템도 버려야 합니다.

뭐? 사실 장점이 있는 것 같아요. V와 VM 간의 느슨한 결합이 좋을 수 있습니다.

바인딩과 같은 기존의 유형이 지정되지 않은 시스템도 버려야 합니다.

V와 VM 간의 느슨한 결합이 좋을 수 있습니다.

소규모 프로젝트의 경우 말 그대로 컴파일러 지원을 끄는 것보다 느슨한 결합에 대한 더 나은 추상화가 있습니다. 수십에서 수백 개의 보기가 있는 대규모 응용 프로그램을 유지 관리해야 하고 여러 사이트에서 사용될 수 있는 것을 리팩터링하려는 경우 컴파일러에서 바인딩 경로의 정확성을 확인하지 않는 것은 개발자 경험의 주요 저하입니다. 우리 언어에 유형 시스템이 있는 데는 이유가 있습니다. 대규모 프로젝트는 프로그래머를 지원하는 도구 없이는 문자 그대로 유지 관리할 수 없으며 현재 UI 언어는 많이 뒤쳐져 있습니다.

컴파일된 바인딩이 많은 도움이 됩니다.

@weitzhandler 내 말은 당신의 대안이 무엇입니까?
... 모든 것이 전용 가시성 속성을 가져야 하는 것은 아닙니다.
뭐? 사실 [바인딩]이 장점이 있는 것 같아요. V와 VM 간의 느슨한 결합이 좋을 수 있습니다.

좋은 반응형 프레임워크에서는 name:Mutable<string> 와 같은 관찰 가능한 변수(코드에서)를 정의한 다음 let visibility = name.map(fun s -> s <> "") 매핑한 다음 visibility.bind someView.set_IsVisible 또는 name.bind(fun s -> someView.IsVisible <- s <> "") 하여 뷰 속성에 바인딩할 수 있습니다.

나는 https://github.com/ReedCopsey/Gjallarhorn을 사용하지만 주변에 다양한 반응 프레임워크가 있습니다.

1. 바인딩과 달리 모든 것이 입력됩니다. 2. 사물(함수, 속성, 보기)은 문자열 이름을 전달하는 것이 아니라 객체라고 합니다. 3. 함수는 함수일 뿐이며 변환기보다 훨씬 덜 투박합니다. 4. 간단한 객체 속성에 추가로 제공해야 하는 바인딩 상용구 "바인딩 가능한 속성" 등을 제거할 수 있습니다.

뷰는 여전히 Xaml로 작성할 수 있습니다. 특히 대부분이 정적 레이아웃인 단순하고 모든 곳에 매직 문자열이 있다는 단점이 있지만 디자이너가 라이브 뷰를 제공할 수 있다는 장점이 있습니다. 라이브 뷰를 제공하는 코드가 있으면 더 좋습니다. 통역사와 함께라면 매우 가능합니다.

리액티브 프레임워크에 대해 말하자면 Chain Reactive 를 확인하고 오픈 소스로 지정해야 하는지 알려주세요.

안녕하세요, ms 팀이 uservoice의 모든 버그/기능을
그렇다면 WinUI 3.0 이상의 훌륭한 단계가 될 것입니다.

@ hupo376787 나는 이것이 Windows 개발 플랫폼을 더 광범위하게 논의하는 스레드가 아니기 때문에 당신이 downvotes를 얻었다고 생각합니다.

하지만 마이크로소프트와 개발자가 참여할 수 있는 윈도우 개발 플랫폼에 대해 공개 토론의 여지가 없는 것이 문제이고, 해당 마이크로소프트 그룹이 피드백 메커니즘을 업데이트하거나 대응하지 않고 유지하지 않는 것이 문제다. 몇 년 동안 사용자 목소리.

@charlesroddie 네, 유저 보이스가 버려진 것 같습니다. 피드백 허브에 제 목소리를 보내드리겠습니다. 아마도 ms는 무시하겠지만 나는 내 일을 할 것입니다.

UserVoice는 이번 달에 완전히 사용 중지됩니다.

특정 제품의 경우 GitHub 저장소(예: 이와 같은)는 관련 엔지니어링 팀에서 적극적으로 사용하기 때문에 피드백을 위한 최고의 장소입니다.

특정 repo의 제품과 관련이 없는 피드백은 Feedback Hub를 이용해주세요. 특히 API 및 개발자 도구에 대한 피드백을 위한 다양한 하위 범주가 있는 "개발자 플랫폼" 범주가 있습니다.

현재 UserVoice에 대한 많은 기록과 이전 피드백이 있다는 것을 알고 있지만(아직도 추적할 예정임) GitHub와 Feedback Hub 모두 UserVoice보다 엔지니어링 팀과 작업 항목 추적에 더 직접적인 경로를 제공합니다. 긍정적인 변화여야 한다. 다양한 지원 및 피드백 링크를 업데이트하는 중입니다.

우리는 두 채널에서 들어오는 모든 것을 보고 있으며 피드백과 버그 보고서에 정말 감사합니다!

@jesbis 알겠습니다.

WinForms의 경우 새 WinUI 프로젝트 템플릿을 사용할 때 속성 창이 계속 작동하고 WinUI 컨트롤의 속성을 설정할 수 있습니까? 하루 종일 HTML을 코딩할 수 있지만(일반적으로 Asp.net MVC) 컨트롤에 사용할 수 있는 설정이 너무 많으면 지난 20년 동안 속성 창을 즐겨 사용했습니다.

@Dean-NC WinFoms/Windows Forms가 아닌 XAML 디자이너에 대해 묻는 것 같은데요? 그렇다면 XAML 디자이너에서 항목을 선택할 때 속성 패널이 WinUI 컨트롤에 대해 계속 작동합니다.

@marb2000 나는 순진하게도 WinUI 3가 새로운 컨트롤을 WinForms에 가져올 것이라고 생각했던 것 같습니다. 대부분 매끄럽고 레거시 컨트롤과 WinUI 컨트롤이 모두 있는 폼을 가질 수 있고 속성 창이 작동한다는 의미입니다. 레거시 및 WinUI 컨트롤 모두에 대해.

나는 위의 전체 게시물을 읽었고 (WinForms 개발자로서) 많은 흥분을 가지고 이것을 따라 왔지만 이것이 어떻게 작동하는지에 대한 높은 수준의 워크 플로우를 오해 한 것 같습니다 (다시 WinForms의 관점에서 ).

나는 오랫동안 WinForms가 앞으로 몇 년 동안 여전히 좋은 일이 될 수 있다고 말했지만, 가장 큰 약점은 기본 컨트롤이 구식으로 보인다는 것입니다(텍스트 상자는 패딩을 허용하지 않으므로 가늘고 작은 라디오 및 확인란 버튼으로 보입니다. , 등.). Win 10 컨트롤(텍스트 상자, 라디오, 확인란)의 아주 기본적인 것만으로도 WinForms에 새로운 생명을 불어넣을 수 있습니다.
기사가 있습니까, 아니면 레거시 컨트롤과 새 컨트롤을 모두 사용하려는 새 WinForms 프로젝트의 워크플로에 대한 간략한 설명을 제공하시겠습니까?
감사 해요.

@marb2000 나는 순진하게도 WinUI 3가 새로운 컨트롤을 WinForms에 가져올 것이라고 생각했던 것 같습니다. 대부분 매끄럽고 레거시 컨트롤과 WinUI 컨트롤이 모두 있는 폼을 가질 수 있고 속성 창이 작동한다는 의미입니다. 레거시 및 WinUI 컨트롤 모두에 대해.

나는 위의 전체 게시물을 읽었고 (WinForms 개발자로서) 많은 흥분을 가지고 이것을 따라 왔지만 이것이 어떻게 작동하는지에 대한 높은 수준의 워크 플로우를 오해 한 것 같습니다 (다시 WinForms의 관점에서 ).

나는 오랫동안 WinForms가 앞으로 몇 년 동안 여전히 좋은 일이 될 수 있다고 말했지만, 가장 큰 약점은 기본 컨트롤이 구식으로 보인다는 것입니다(텍스트 상자는 패딩을 허용하지 않으므로 가늘고 작은 라디오 및 확인란 버튼으로 보입니다. , 등.). Win 10 컨트롤(텍스트 상자, 라디오, 확인란)의 아주 기본적인 것만으로도 WinForms에 새로운 생명을 불어넣을 수 있습니다.
기사가 있습니까, 아니면 레거시 컨트롤과 새 컨트롤을 모두 사용하려는 새 WinForms 프로젝트의 워크플로에 대한 간략한 설명을 제공하시겠습니까?
감사 해요.

앱 프로젝트를 가져오고 WinUI 창과 페이지를 추가하고 최신 XAML UI를 사용하여 UI를 완전히 또는 조금씩 바꿀 수 있을 가능성이 더 큽니다.

그리고 기존 Winforms 및 WPF UI에 XAML을 삽입하기 위한 XAML 아일랜드가 있습니다.

Blazor 팀은 Uno와 협력하여 Uno(특히 서버 측)에 포함된 호스팅 모델 중 일부를 가져오거나 Blazor에서 사용할 수 있는 Uno UI(및 WinUI 3) 렌더링/비주얼 레이어를 가져와야 합니다.... 및/또는 Blazor용 Xaml Islands?

대부분의 피드백이 주로 xaml 공간에서 작업하는 개발자들로부터 나오기 때문에 여기에서 약간 의아합니다. 그들은 일반적으로 이미 가지고 있는 것보다 더 나은 버전을 찾고 있는 것 같습니다. 기존 사용자에게는 좋을지 모르지만 지금까지 UWP를 기피한 많은 개발자를 끌어들일지 모르겠습니다.

우리 팀은 1개의 UWP 앱만 개발했습니다. 우리는 더 이상 발전하지 않을 것입니다.

극복할 수 없는 장애물은 내장된 표로 작성된 보고서 작성기가 없다는 것입니다. 우리는 UWP를 지원한다고 시장에 나와 있는 모든 타사 보고서 작성자를 시험해 보았습니다. 불행히도 그 중 어느 것도 UWP와 잘 작동하지 않습니다. UWP 제품은 일반적으로 WPF/WinForms 변형의 빠른 해킹이며 제대로 작동하지 않습니다.

UWP 제품에서 Stimulsoft Reports를 사용합니다. 그것은 매우 버그가 있으며 UWP 사용률이 너무 낮기 때문에 버그를 수정하지 않을 것이라고 말했습니다.

목록에 데이터 시각화가 있습니다. 그러나 수백만 개의 전함 회색 앱이 여전히 존재하는 이유는 많은 기업이 내부 앱의 비주얼에 그다지 신경을 쓰지 않기 때문입니다. 그들은 소계가 있는 숫자 열을 원합니다.

따라서 WinUI가 최종적으로 데이터 개발자보다 양식을 유인하는 것이라면 내장된 표 형식의 보고서 작성기가 필요합니다.

이것이 시각적인 사람들의 기분을 상하게 하지 않기를 바랍니다 :-)

전적으로 동의합니다. 앱과 쉽게 통합할 수 있는 보고 시스템 없이 어떻게 현대적인 비즈니스 앱을 개발할 수 있습니까? 개발자가 이동하는 것을 막을 수 있는 거대한 협곡입니다.

비즈니스 사용자는 표로 작성된 데이터와 상호 작용한 다음 인쇄하거나 다른 형식으로 내보낼 수 있어야 합니다. 또한 송장, 견적서, 명세서 및 기타 도구 문서를 작성할 수 있어야 합니다.

비즈니스/기업이 여전히 Windows의 가장 큰 소비자라는 것을 알고 있습니다. UWP용으로 개발되지 않은 Windows 에코시스템의 근본적인 이유는 무엇입니까?

피드백 @VagueGit 및 @Elmarcotoro에 감사드립니다! 엔터프라이즈 제어는 현재 우리에게 부족한 부분입니다. 그러나 타이밍이 좋습니다. DataGrid 컨트롤 디자인에 대한 피드백을 수집하고 있습니다. 여기 #1500 을 읽고 피드백을 주세요.

마찬가지로 정사각형 테이블 형식 데이터 제어 외에도 다이어그램 제어를 통해 복잡한 관계를 공유하는 방식으로 창의적으로 민주화하기 위한 오픈 소스 UWP 그래프 제어가 필요합니다.

보고 시스템으로는 Telerik UI가 현재 최고의 선택이라고 생각합니다. 중국 속담에 "어떤 사람은 어떤 직업을 전문으로 하고 어떤 사람은 다른 직업을 가집니다." Telerik, DevExpress 또는 다른 사람은 보고에 능숙합니다.

다양한 컨트롤이 없기 때문에 이 팀을 탓할 것이 아니라 전체 MS 전략을 탓해야 합니다. Satya의 시작부터 모바일 포기, 그들은 ios 및 android를 더 선호하여 보스를 좋아합니다. 전체 UWP 생태계가 약해지고 약해집니다.

현재로서는 트위터에 "UWP는 죽었다"는 주장이 있는데, MS가 이를 명확히 하고 uwp 길을 선언해야 한다고 생각한다.

현재로서는 트위터에 "UWP는 죽었다"는 주장이 있는데, MS가 이를 명확히 하고 uwp 길을 선언해야 한다고 생각한다.

방금 로드맵 스레드에 게시했습니다 ...

@jevansaks DataGrid 컨트롤에 대한 정보를

@hupo376787
"보고 시스템의 경우 Telerik UI가 현재 최고의 선택이라고 생각합니다."

내가 볼 수 있는 바에 따르면 Dev Express는 현재 UWP에 대한 보고서를 만들고 보기 위한 전체 스택을 제공하는 유일한 회사이며 가격은 프리미엄 쪽에 있는 것 같습니다. Telerik을 포함한 다른 모든 제품은 도구에 공백이 있어 UWP용 보고서를 작성할 수 없습니다. 나는 이것에 대해 정정할 의향이 있습니다(희망).

보고 시스템으로는 Telerik UI가 현재 최고의 선택이라고 생각합니다. 중국 속담에 "어떤 사람은 어떤 직업을 전문으로 하고 어떤 사람은 다른 직업을 가집니다." Telerik, DevExpress 또는 다른 사람은 보고에 능숙합니다.

@hupo376787 게시물이 잘못되었다고 암시하기 전에 사실 확인에 각별한 주의를 Telerik Reporting 에는 WPF 및 WinForms용 보고서 디자이너가 있지만 UWP는 없습니다.

DevExpress 에는 WinForms 및 WPF용 보고서 디자이너도 있지만 UWP는 없습니다.

따라서 영원히 보존되고 널리 유포될 오류를 범하기 전에 사실을 확인하십시오. 이야, 언젠가는 옛말이 될 것 같은 소리네요 😉

@hupo376787 게시물이 잘못되었다고 암시하기 전에 사실 확인에 각별한 주의를 Telerik Reporting 에는 WPF 및 WinForms용 보고서 디자이너가 있지만 UWP는 없습니다.

DevExpress 에는 WinForms 및 WPF용 보고서 디자이너도 있지만 UWP는 없습니다.

따라서 영원히 보존되고 널리 유포될 오류를 범하기 전에 사실을 확인하십시오. 이야, 언젠가는 옛말이 될 것 같은 소리네요 😉

알겠습니다. 보고에 대한 이해가 다른 것 같습니다. https://www.telerik.com/universal-windows-platform-ui 및 https://www.devexpress.com/products/net/controls/win10apps/를 의미

내가 틀렸습니다. Dev Express는 UWP에 대한 보고를 제공하지 않습니다. 타사 도구 개발자는 없는 것 같습니다! UWP에 대한 보고를 제공하기 위한 로드맵이 있는지 여부에 대해 채팅을 통해 Dev Express에 문의했습니다.
그들은 말했다,
"XtraReports Suite는 System.Drawing 어셈블리에서 제공하는 기능을 사용하며 Universal Window Applications에 대해 동일한 도구 세트를 구현하지 못하게 하는 것은 이 어셈블리를 사용할 수 없다는 것입니다(https://stackoverflow.com/questions /31545389/windows-universal-app-with-system-drawing-and-possible-alternative) 그래서 우리는 아직 이 분야에 대한 미래 계획을 세우지 않았습니다."

@jevansaks , Microsoft UI 팀과 이러한 타사 도구 제공업체 간의 커뮤니케이션이 부족한 것 같습니다. 타사 도구를 사용하면 좋겠지만 UWP 플랫폼을 사용하면 이러한 회사에서 다른 플랫폼용 도구를 UWP에 통합하기 어려운 것 같습니다.

그들은 보고 요구 사항과 함께 그들의 [email protected] 에 연락하도록 요청했습니다. Win UI 3.0 팀이 그들에게 연락하여 구현을 지원하는 방법인지 확인하는 것이 도움이 될 수 있습니다. 적절한 보고 도구 없이 어떻게 범용 플랫폼에서 비즈니스 개발자를 확보할 수 있을지 모르겠습니다.

https://www.devexpress.com/subscriptions/reporting/

보고: WinForms의 관점에서 저는 Telerik과 DevExpress(최신 버전도 포함)를 모두 사용했으며 Telerik도 좋았지만 DevExpress는 전반적인 디자이너와 경험이 더 나았을 뿐만 아니라 훨씬 더 미묘한 기능이 있다고 생각합니다. Telerik보다 더 복잡한 레이아웃을 수행할 수 있었습니다. DevExpress 렌더링 기술이 더 발전했다고 생각합니다.

Win UI 3.0 팀이 그들과 연락하고 그들이 구현에 도움이 되는 방법인지 확인하는 것이 도움이 될 수 있습니다.

전화주셔서 감사합니다. 우리도 그들에게 다가갈 것입니다.

전화주셔서 감사합니다. 우리도 그들에게 다가갈 것입니다.

그들 모두와 이야기하고 블록이 무엇인지 보는 것이 가치가 있습니까? Telerik, Grapecity, DevExpress 등

전화주셔서 감사합니다. 우리도 그들에게 다가갈 것입니다.

그들 모두와 이야기하고 블록이 무엇인지 보는 것이 가치가 있습니까? Telerik, Grapecity, DevExpress 등

확실히, 그것이 우리의 계획입니다.

우리는 Windows용으로 빌드하는 대부분의 개발자와 약간 다릅니다. 우리는 대부분 키오스크 앱(컴퓨터 소유자가 아닌 다른 사용자가 실행하도록 의도된 앱, 일반적으로 더 넓은 시스템에 대한 액세스 권한 없이 전체 화면으로 표시되는 앱)을 개발합니다. 앱은 일반적으로 고객의 특정 요구 사항에 맞게 빌드되며 스토어 또는 이에 상응하는 것을 통해 배포할 의도가 없습니다.

앱이 전체 화면으로 실행되기 때문에 다른 Windows 앱의 모양과 느낌을 유지 관리하는 기본 제공 컨트롤의 가치는 매우 제한적입니다. 대신 각 고객에 대해 브랜드가 높은 경향이 있습니다. 우리는 여전히 표준 Windows 앱의 많은 공통 _동작_ 및 컨트롤이 필요하지만 일반적으로 각 앱의 컨트롤 템플릿을 많이 사용자 지정하거나 최소한 핵심 스타일을 재정의합니다. 아주 오랫동안 우리는 UI용 Flash 프론트엔드가 포함된 WinForms 백엔드로 많은 앱을 구축했습니다.

대략적으로 말하면 우리가 작성하는 거의 모든 앱은 일종의 웹 기반 백엔드를 일부 하드웨어(예: 프린터, 바코드 스캐너, 마그네틱 스트라이프 리더, RFID 스캐너, 카메라, 카드 결제 하드웨어, 자동 판매기 스타일 현금 결제)와 통합합니다. 구성 요소 등) 및 이러한 구성 요소의 대다수는 역사적으로 UWP SDK가 아닌 Win32 SDK와 함께 제공되었습니다.

이러한 두 가지 이유로 인해 대부분의 과거 앱은 WinForms 앱이고 최신 앱은 대부분 WPF 앱입니다. 우리는 몇 가지 UWP 앱(주로 Windows의 정말 좋은 할당 액세스/키오스크 모드 기능의 이점을 얻기 위해)을 빌드했지만 일반적으로 WPF와 비교하여 작업하기가 힘들고 일반적으로 호환되는 하드웨어 SDK를 얻을 수 없습니다. .

그러나 우리는 최신 UI로 Win32 호환 앱을 작성할 수 있도록 XAML 아일랜드에 매우 흥미를 느낍니다. Fluent 등과 같은 효과).

특정 질문에 답하려면:

어떤 템플릿이 가장 흥미로우신가요?

.NET Core가 있는 C#, WinUI 3.0이 오버레이된 Win32가 좋을 것입니다.

데스크톱 앱 현대화를 위한 Xaml Islands를 알고 계셨습니까?

네, 그리고 저는 그들과 함께 플레이했을 때 상대적으로 만족했습니다. 비록 우리가 _single_ 컨트롤을 사용하지 않을 가능성이 높지만 전체 사용자 정의 UI에 대한 결정을 내리는 정도입니다.

내가 그것을 알고 있었던 주된 이유는 우리가 Win32 앱에 대한 Lottie 지원을 받기 때문이었습니다.

Windows 10에서 확장된 이전 버전과의 호환성이 Xaml Islands를 더 유용하게 만들까요?

설마; 우리는 거의 항상 대상 PC를 제어하고 항상 최신 호환 릴리스를 확보할 수 있습니다.

Visual Studio 또는 다른 도구가 자동으로 네임스페이스를 업데이트하면 도움이 될까요?

예.

기존 UWP Xaml 구성 요소와 WinUI 3.0 앱 간의 완전한 호환성이 얼마나 중요합니까?

아주 최소한의. 주요 호환성 문제는 핵심 요소 스타일 지정을 위해 StaticResource 키를 변경했을 것입니다.

앱 코드와 함께 쉽게 다시 컴파일 및 업데이트할 수 없는 UWP Xaml 제어 라이브러리 또는 WinRT 구성 요소를 만들거나 사용합니까?

예, 과거에 Syncfusion UWP 제어 라이브러리 를 사용했습니다.

WinUI 3에서 UWP Xaml 구성 요소를 사용하는 데 선호하는 솔루션은 무엇입니까?

선호하는 솔루션은 외부 소스(예: 문서 뷰어)에 의존하기보다는 WinUI 자체에서 더 많은 표준 컨트롤을 사용할 수 있도록 하는 것이지만 이러한 외부 구성 요소 라이브러리는 일반적으로 우리가 전환할 때보다 라이브러리 업데이트에 대해 더 진보적일 것으로 예상합니다. 어쨌든 대부분의 경우 WinUI 3.

위와 로드맵에 요약된 전반적인 3.0 계획에 대해 어떻게 생각하십니까? 신규 및 기존 Windows 앱에 WinUI를 사용할 수 있습니까?

특히 WinUI가 공개적으로 설계 및 개발되고 있기 때문에 하드웨어 호환성 이유로 인해 역사적으로 우리를 잠그던 UWP 앱 및 보안 모델에서 UWP 컨트롤이 보다 명확하게 분리되는 것을 보게 되어 기쁩니다.

Microsoft에서 앱 UI를 빌드하도록 권장하는 방법에 대한 명확한 지침을 통해 우리가 지원할 수 있는 백엔드에 관계없이 모든 앱이 WinUI 프론트엔드로 끝날 것으로 예상합니다.

어떤 종류의 앱에 WinUI 3.0을 사용하고 싶습니까? 새 Win32 앱을 만들고 MSIX로 패키징하시겠습니까? WPF 앱에 새 보기를 추가하시겠습니까? Fluent UI로 C++ MFC 앱 현대화?

더 훌륭하고 명확한 문서(또는 표준 컨트롤의 기본 코드에 대한 액세스)를 사용하여 이전 앱에서 보다 적극적으로 유지 관리되는 컨트롤 라이브러리에 액세스하는 방법에 대한 정보는 표준 컨트롤을 적용할 수 있는 시기를 훨씬 더 쉽게 파악할 수 있습니다. 내 자신의 사용자 컨트롤을 롤링해야 할 때. 예를 들어, WPF로 빌드된 최근 앱에는 몇 가지 날짜 선택기가 있었습니다. 해당 컨트롤이 터치에 대해 잘 작동하도록 하고 크기, 글꼴, 팝업 아이콘 등을 사용자 지정하는 것은 매우 성가신 일이었습니다. 다음과 같은 이유로 위의 로드맵을 감안할 때 앞으로 _default_로 이러한 종류의 앱에 WinUI를 사용하는 경향이 있습니다.

1. 최소한 적당히 터치 친화적 인 기본 날짜 선택기 컨트롤이 있다고 합리적으로 확신 할 수 있습니다.
2. 해당 컨트롤의 기본/즉시 사용 가능한 템플릿 등을 검사하여 고객의 룩앤필에 대한 디자인 증명과 일치시키기 위해 재정의해야 하는 항목을 쉽게 확인할 수 있습니다(대략 대표적인 예로, TextBox 컨트롤의 헤더 유형(글꼴 크기, 두께, 패밀리)을 입력 텍스트와 독립적으로 스타일 지정하는 가장 깔끔한 방법을 알아내기 위해 표준 HeaderTemplate이 재정의할 수 있는 마법의 정적 리소스를 사용합니까 아니면 템플릿 자체를 재정의해야 하나요? 템플릿을 재정의하면 기본 템플릿의 마크업이 어떻게 생겼습니까? 내가 고려하지 않은 기능을 수행/지원합니까?).

나는 이것이 닫혔다는 것을 알지만, 내가 제기할 가치가 있지만 사용자들에 의해 제기되는 몇 가지 문제가 있습니다. 많은 양의 데이터로 작업하는 사용자를 위한 생산성 향상입니다.

텍스트 상자:
사용자가 TextBox를 편집해야 하는 경우 먼저 TextBox를 클릭하여 지우기 버튼을 표시한 다음 지우기 버튼을 클릭하여 TextBox를 지워야 합니다. 이것은 많은 양의 데이터로 작업할 때 매우 비효율적입니다. 사용자가 TextBox를 클릭하거나 탭할 때 텍스트가 강조 표시되어 덮어쓸 준비가 된다면 좋을 것입니다.

그리드뷰/리스트뷰:
Gridview 및 ListView는 사용자가 컬렉션을 효과적으로 탭할 수 있도록 허용하지 않는 것 같습니다.
ListView를 사용하면 Tab이 같은 행의 컨트롤로 이동할 수 있지만 다음 컨트롤 행으로 Tab은 이동할 수 없습니다. 대신 ListView가 포커스를 잃고 Tab이 시각적 트리의 다음 컨트롤로 이동합니다.

이것은 사용자가 매우 성가신 것으로 제기한 두 가지 문제입니다.

@엘마르코토로

언급한 각 개선 사항에 대해 새 문제를 만드는 것이 좋습니다. 그런 다음 WinUI 팀은 구현하기 전에 WinUI 3를 릴리스해야 하는지 여부를 결정하기 위해 분류합니다.

이 문제는 주로 게시물 상단에 있는 2개의 "일반 질문"에 대한 피드백을 수집하기 위해 존재했습니다.

WinUI에서 기본적으로 Blazor 호스팅 모델을 지원합니다. 이렇게 하면 Blazor 컨트롤을 클라이언트/서버 웹에서 직접 사용하거나 WinUI에서 직접 사용할 수 있습니다. Blazor 로드맵에는 WebView 컨트롤을 사용하지 않고 이러한 미래 개념이 있습니다. 이렇게 하면 컨트롤의 UI가 네이티브로 실행되는 코드의 .Net Standard 부분과 함께 네이티브로 실행됩니다.

WinUI에서 기본적으로 Blazor 호스팅 모델 지원

Blazor 측에서 FWIW에서 다음과 같이 논의했습니다.
https://github.com/dotnet/aspnetcore/issues/11082

확실히, 그것이 우리의 계획입니다.

@jevansaks 루프에 들어가는

WinUI 3.0에서 트레이 메뉴/아이콘 메뉴의 일관성을 높이고 싶습니다. 모든 앱은 다른 간격을 가지며 Win32 앱은 글꼴 렌더링/간격/테마를 일관되게 따르지 않습니다. 이 문제를 이미 수정하십시오!

바탕 화면의 WinUi는 창 표시/숨기기, 창 위치, 창 크기, 도킹/도킹 해제 등 창 관리 가능성이 없기 때문에 완전히 쓸모가 없습니다.

@alexandrevk 아직 미리보기입니다. 윈도우 API 디자인을 보셨나요? https://github.com/microsoft/ProjectReunion/issues/157

창구 공지 게시물에 링크해

@alexandrevk - Windows에서 다른 프레임워크/스왑체인 콘텐츠를 사용할 때뿐만 아니라 Win32 및 UWP에서 WinUI 콘텐츠와 함께 이러한 유형의 창 작업을 수행할 수 있는 Reunion용 API를 함께 제공합니다. 그런 다음 이러한 창 기능 중 일부는 더 쉽게 액세스할 수 있도록 WinUI 창 클래스로 추상화될 수 있지만 이는 더 먼 길입니다. 창 영역에 대한 기능 사양은 파이프에 있습니다. 계속 지켜봐 주십시오.

개인 사용자(예: 비기업/회사) 및 C++로만 엄밀히 말하면, 제가 공허에 외치는 고독한 목소리일지라도 이러한 새로운 UI 시스템 중 하나라도 UWP와 그들이 구축한 그 끔찍한 패키징 시스템에 묶여 있다면, 당신이 무엇을 하든 항상 어둠 속에 갇히게 될 것입니다. (WinRT 경험에 따르면 아직 WinUI를 시도하지 않았지만 나에게는 거의 비슷하게 보입니다.)
실제로 UWP 앱을 사용하는 사람은 거의 또는 아무도 없다는 사실을 알아야 합니까? (실제로 대부분의 afaik에서 싫어함) '네이티브'라고 하면 왜 진정한 '네이티브'가 아닌지요. 예: 몇 개의 #include, .lib 또는 두 개를 연결하고 STANDARD C++로 앱을 빌드하세요.
1000번째로 win32를 래핑하는 것을 피하기 위해 크로스 플랫폼이 문제가 되지 않을 때 Qt와 같은 것에 의존해야 하는 것은 공정하기 위해 다소 낡아지고 있습니다.
어쨌든 매일 언어를 사용하지만 여기에 댓글을 달 곳이 없을 것입니다.

@nl-n WinUI의 가장 큰 장점 중 하나는 UWP 앱으로 실행할 필요가 없다는 것입니다. 사실 이것은 미리보기 2부터 가능했습니다.
_현재_ msix로 패키징해야 하지만 msix는 실제로 앱을 배포(및 업데이트)하는 꽤 괜찮은 방법입니다.

@dotMorten 그것은 큰 문제 중 하나입니다. 스토어를 통한 사이드 로딩/설치가 필요합니다. Windows를 설치하기 전(또는 설치 직후)에 스토어를 비활성화/제거하지 않은 사람이 한 명도 없는데 어떻게 배포해야 합니까?
나는 그것이 다소 수사학적이라는 것을 알고 있지만 요점을 제공합니다. 빌드 디렉토리를 압축하여 배포할 수 있어야 합니다(또는 필요한 경우 설치 프로그램).
그런 다음 호환성 문제가 있습니다. 많은 사람들이 여전히 W10 설치조차 거부합니다. 그래서 그것도 있습니다...
그러나 그것이 3.0이 향하고 있다는 소식을 듣는 것은 좋지만 xaml을 싫어하는 만큼 환영할 만한 추가 사항이 될 것입니다.
VS에 전체 50GB UWP 워크로드를 설치하지 않고도 얻을 수 있을까요? 🙏 (과장한건 알지만 그래도)

이 스레드의 시작 부분에서 @MarkIngramUK 를 인용하려면:

지금은 2019년, 빠른 네이티브 UI를 원하고 CreateWindowExW , GDI 등으로 사용자 인터페이스를 만드는 것을 심각하게 고려하고 싶지 않습니다.

(재미있게도) 말 그대로 지금 당장 해야 하는 일이며, 소리만큼 고통스럽습니다. :)

@nl-n 누가 가게에 대해 뭐라고 했습니까? MSIX는 MSI에서 설치하는 것과 크게 다르지 않습니다. 바로 앱 설치 프로그램입니다. 두 번 클릭하여 설치합니다. 상점이 필요하지 않습니다. 100% 완전 제거도 보장합니다(거대한 엉망을 만드는 MSI와 반대).

나는 상점을 비활성화/제거하지 않는 사람을 한 명도 모릅니다.

그래도 흔한 일은 아니다.

우리는 그들을 어떻게 배포해야합니까

우선 스토어를 비활성화하지 않도록 사용자에게 알려야 합니다.)

빌드 디렉토리를 압축하여 배포할 수 있어야 합니다.

MSIX는 스토어 없이 설치할 수 있습니다. 최신 Windows 버전을 사용하면 사용자가 이를 위해 아무 것도 활성화할 필요가 없습니다. 물론 패키지가 신뢰할 수 있는 인증서로 이전에 서명된 경우. 하지만 사용자가 PC에서 스토어를 제거한 경우 MSIX/APPX AppInstaller도 제거할 수 있습니다. 이 경우 그들은 응용 프로그램의 모든 가변성을 원하지 않을 것입니다.

많은 사람들이 여전히 W10 설치조차 거부하고 있습니다.

그것은 그들의 선택입니다. 그런가 말했다.

VS에서도 전체 50GB UWP 워크로드

단일 SDK는 약 3GB입니다. 10240부터 시작하여 모든 것을 다운로드할 필요는 없습니다.

@nl-n 누가 가게에 대해 뭐라고 했습니까? MSIX는 MSI에서 설치하는 것과 크게 다르지 않습니다. 바로 앱 설치 프로그램입니다. 두 번 클릭하여 설치합니다. 상점이 필요하지 않습니다. 100% 완전 제거도 보장합니다(거대한 엉망을 만드는 MSI와 반대).

그것은 Visual Studio가 'Microsoft 스토어를 통한 사이드로드/설치'에 대해 제공하는 설명에서 나온 것입니다. msix에서 찾은 유일한 다른 정보는 msdn에서 가져온 것입니다. 기본적으로 msix 패키지는 샌드박스/가상화된 'appx' 응용 프로그램입니다. , winapi와 직접 작동하는 모든 것에 대한 거의 킬러입니다. 그리고 설치가 가능 하려면 서명이

또한 너무 많은 용어가 다른 것으로 생각되는 교차 전선 일 수 있으며 UWP에 대해 많이 모릅니다.

그래도 흔한 일은 아니다.

생각보다 흔하고 이유가 있습니다 😄

어쨌든 탈선하려는 의도는 아니었으므로 지금은 CreateWindowExW를 작성하는 것으로 돌아가겠습니다 🤣