Xamarin이 .NET 5에 병합될 것이라고 생각합니다.
UWP XAML을 표준으로 채택하고 거기에서 작업하면 Microsoft와 UNO가 데스크톱, 모바일, 웹 브라우저(Azure) 및 IoT에 가장 적합하도록 만드는 것이 좋습니다.
그들은 그것을 부를 수 있습니다
UWP vNext(WinUI 기반)/ Silverlight 6(UNO)

Blazor의 노력은 현재 기본 렌더링을 사용하여 .NET을 공식적으로 WebBrowser에 가져오는 첫 번째 단계라고 생각합니다. HTML DOM
그러나 머지 않아 다른 렌더링 엔진, WinUI를 위한 경량 보완, Silverlight, UNO Platform 및 Xamarin을 도는 무언가를 Flutter/WPF와 같이 제공할 수 있다고 믿습니다.

UWP XAML을 표준으로 채택하고 거기에서 작업하면 좋을 것입니다.

여러분이 원하는 모든 것이 이미 Uno에서 이루어지고 있습니다. MS는 그 사람들을 사들인 다음 Uno의 최종 개발을 돕도록 고용하는 것이 현명할 것입니다.

이것은 아마도 이와 같은 기능을 요청하는 잘못된 장소일 것입니다. 이 요청의 모든 것에 동의하고 싶은 만큼 WinUI 팀과 Windows 커뮤니티의 많은 선임 개발자는 WinUI를 매우 좁게 정의해야 한다고 생각합니다.

이상적인 세계에서 WinUI는 머티리얼 디자인과 같습니다. 그것을 구현하는 모든 종류의 라이브러리가 있는 모든 플랫폼에서 사용할 수 있는 방법이 있습니다. 그러나 WinUI는 디자인 언어가 아니므로 Fluent Design도 아닙니다. Microsoft는 모델 공간에 있지 않기 때문에 UI 제품을 경쟁업체보다 훨씬 더 많이 만들었습니다.

WinUI는 Windows 응용 프로그램을 위한 UI 라이브러리이며 이것은 가장 명확합니다. 디자인 언어는 구현과 별개가 아니며 구성과 같은 기능이 플랫폼 종속성에 크게 의존하기 때문에 구현은 플랫폼 배타적입니다. 이것은 모바일/크로스 플랫폼 개발자의 관점에서 볼 때 좋지 않지만 여기서의 노력은 실제로 Windows 앱을 위한 것입니다.

이것이 또한 Uno Platform이 DX 11을 모든 플랫폼에 이식하지 않는 한 모든 곳에서 진정한 WinUI가 될 수 없는 이유이기도 합니다.

Comet(.Net 기반 크로스 플랫폼 개발 프레임워크)를 살펴보는 것이 좋습니다. 초기 단계이지만 개념은 Flutter와 다르지 않습니다. 또한 Skia(옵션)를 사용하여 구성 가능/선언적 UI 패턴으로 UI를 그리므로 개발자는 Material Design과 같은 UI 라이브러리를 구현하고 모든 플랫폼에서 완전히 동일하게 보이게 할 수 있습니다.

아니요, 크로스 플랫폼이 아니어야 합니다. 이유는 Windows UI라고 합니다. 시작하기 위해 모든 Windows(플랫폼 및 언어)에서 작동하는 UI 시스템을 만들어 보겠습니다. 그것은 아직 달성되지도 않았습니다. 우리는 여전히 .net 프레임워크, .net 코어, uwp 및 C++ 스토리로 나뉩니다. 최소한 uwp는 있지만 게임 개발자는 사용하지 않습니다. UWP/WinRT에는 여전히 배포, 강제 작업 표시줄 및 제목 표시줄 팝업과 같은 몇 가지 문제가 있기 때문입니다. 전체 화면일 때(yikes).

크로스 플랫폼에 대해 생각하는 것은 엄청난 자원 낭비입니다. 먼저 Windows에서 올바르게 설치하십시오. 그리고 .net 5를 출시하고 UWP와 윈도우 스토리를 수정하고 DirectX를 C#에 넣습니다. 그리고 GC를 수정합니다. 좁은 시나리오에서는 Windows에서만 해야 할 일이 너무 많습니다.

그리고 OP에게.

• UWP는 보편적입니다. 보편적이지 않다고 말하는 것은 잘못된 주장입니다(Android를 대상으로 하려는 것이 아닙니다. 감사합니다). 원래 약속이 전달되었습니다. 모든 Windows 장치는 UWP를 실행합니다. Windows Mobile은 별도의 OS였으므로 제거해야 했습니다. 모든 새로운 Windows 플랫폼은 Windows(10 또는 10X)입니다. 결국 CoreOS를 기반으로 한다고 생각합니다. 그리고 그들은 모두 Windows 응용 프로그램을 실행할 것입니다. 현재 Windows Phone이 없기 때문에 부수적입니다. 다른 모든 장치 유형이 있습니다. 그리고 우리는 곧 Neo와 Duo를 갖게 될 것입니다.

• 샌드박스 제한 - 이것은 좋은 것입니다. Win32 스타일 시스템 전체 액세스는 일반적으로 금지되어야 합니다. 특정 요구 사항이 있는 경우 요구 사항을 제출하여 UWP 컨테이너 내에서 이를 수행할 수 있거나 수행해야 하는 방법과 제안한 방식으로 수행하도록 허용해야 하는지 여부를 논의할 수 있도록 요구 사항을 제출해야 합니다. UWP에 해당 기능이 필요한지 확인하십시오. UWP로 작성할 수 있는 일부 고급 응용 프로그램을 생각할 수 있기 때문에 문제가 없습니다. 프로그램을 가질 수 있어요! 구체적인 논의가 필요합니다.

• .net 네이티브가 교체되고 배포 스토리가 .net 5로 변경됩니다. Microsoft에서 이 작업을 수행하고 있다고 말하는 것이 타당하다고 생각합니다. 확실히 그들은 문제를 알고 있습니다. 그러나 여기에서 실제 근본적인 문제를 대상으로 하는 특정 문제를 제출해야 합니다.

• "WinUI를 DirectX에 연결하지 마십시오" - WTF? 기본 Windows 그래픽 스택인 DirectX와 절대적으로 결합되어야 합니다. 다른 것은 고려조차 하지 마시기 바랍니다. 나는 절대적으로 후드 아래에서 OpenGL 렌더링 표면을 만나고 싶지 않습니다. 그것은 호환성을 깨고 모든 종류의 혼란을 일으킬 것입니다.

@Gavin-Williams

훌륭합니다. WPF를 통해 약간 진화된 업그레이드를 만들어 보겠습니다.

UWP는 보편적입니다

"모든 Windows 장치는 UWP를 실행합니다"는 모바일 없이는 아무 의미가 없습니다. HoloLens는 틈새 시장이고 Surface Hub는 틈새 시장이며 Windows 10 IoT Core는 농담입니다.

반드시 DirectX와 결합되어야 합니다.

개발자로서 하드 커플링은 소름이 돋습니다. 그래픽 스택을 교환할 수 없는 주요 이유가 있습니까?

"모듈화"라고 합니다. 마이크로소프트는 항상 그것과 씨름해왔습니다.

샌드박스 제한은 좋은 것입니다.

예, 만들 수 있는 응용 프로그램의 범위를 심각하게 제한하지 않는 한 그렇습니다. UWP에서 파티션 크기를 조정해 보셨습니까?

Google이 Flutter를 개발 중이며 GoogleUI 또는 AndroidUI라고 부르지 않는다는 점을 언급하고 상기시킬 가치가 있다고 생각합니다. 웹과 데스크탑을 포함한 모든 곳에서 작동합니다. "그냥 Windows에서 작동하도록 하는" 경향이 있는 것처럼 보이지만 더 저렴하고 더 빠르고 사용하기 쉽고 Windows와 다른 모든 것에서 작동하는 다른 경쟁 제품이 존재한다면... 개발자는 무엇을 할 것입니까? 및 해당 시장) 선택? 나는 소기업 소유자로서 두 가지 선택이 주어지면 내가 어디에 투자하는지 알고 있다고 말할 수 있습니다.

DirectX를 다른 플랫폼으로 이식하는 것은 방대한 작업으로 보입니다. 아마도 해결책은 DirectX 대신 OpenGL 또는 Vulkan을 사용하는 것입니다.

@Gavin-Williams, UWP에 익숙하신지 모르겠지만 빌드/배포할 때 Windows의 특정 버전(또는 버전 범위)을 대상으로 합니다. 그 아이디어는 절대적으로 결합되어 있으며 UWP가 WPF만큼 주류가 되지 못한 이유 중 하나입니다.
@nerocui UI 언어의 전체 목적은 화면의 원시 도면에서 UI 디자인을 분리하는 것입니다. 이것이 HTML이 ARM/x64/x64에서 렌더링될 수 있는 이유입니다.

XAML은 UI 기본 요소/구성/애니메이션의 뛰어난 추상화를 제공하며 개발 비용과 플랫폼 도달 범위 때문에 요청이 절대적으로 의미가 있습니다.

나는 @SuperJMN에 정중하게 동의하지 않습니다. 확실히 UWP는 아직 WPF와 기능 패리티를 달성하지 못했습니다. 커널 수준 도구를 빌드하기 위한 프레임워크로서의 한계에도 불구하고 앱 매니페스트에 지정된 올바른 기능을 사용하여 거의 모든 다른 소프트웨어 개발 작업에 대해 여러 관점(보안, 배포 용이성, 설치/제거 경험 등). UWP의 보안 샌드박스는 중요한(필수) 기능입니다. 여러 면에서 UWP는 이제 WPF보다 훨씬 앞서 있습니다.

UWP .Net 컴파일러는 코드 난독화의 필요성과 이로 인해 WPF에 발생할 수 있는 불안정성을 제거합니다. 성능은 컴파일러가 향상됨에 따라 코드 변경 없이 시간이 지남에 따라 향상될 가능성이 있습니다. UWP 자체는 DirectX 및 기타 시스템 수준 리소스를 활용하는 방법 측면에서 훨씬 더 나은 디자인을 가지고 있습니다. 또한 다른 언어, 특히 C++와 통합할 때 WPF보다 큰 이점이 있습니다. 고성능 C++ 구성 요소를 C#과 통합하는 것은 UWP에서 간단합니다. DirectX 표면에 대한 액세스도 훨씬 향상되었습니다.

UWP의 나머지 구멍은 쉽게 막을 수 있습니다. 더 큰 문제는 Microsoft가 WPF와 관련된 품질 수준을 달성하지 못했다는 것입니다. WPF가 방금 작동했습니다. Microsoft는 또한 Data Grid, INotifyDataErrorInfo, 유효성 검사 상태를 특징으로 하는 컨트롤 및 즉시 사용 가능한 강력한 DB와 같은 LOB 요구 사항의 중요성을 인식하지 못했습니다. 대부분 해결되었지만 시간이 너무 오래 걸렸습니다. 직사각형이 아닌 영역이 누락되었습니다.

다른 치명적인 오류는 UWP를 사용하지 않기로 선택한 특정 WPF 개발자에게 있습니다. 채택은 추진력을 구축하는 데 필수적입니다. 그러나 Microsoft가 이니셔티브에 대해 몇 번이나 망설였는지를 고려할 때 채택 무용담은 이해할 수 있습니다. 마이크로소프트가 다시 한 번 당황하고 있는 것이 분명합니다. WPF를 UWP UI 서비스에 연결할 수 있도록 하여 WPF를 부활시키는 것은 표면적으로는 멋져 보이지만 UWP를 견고하게 만드는 데에는 방해가 됩니다.

개발자들이 Microsoft가 올바른 일을 할 것이라는 희망을 잃었다는 @SuperJMN의 주장에 전적으로 동의합니다. 어떤 종류의 소프트웨어를 구축하느냐에 따라 옳은 것이 달라집니다. 신속하게 생성되어야 하고 다양한 기능을 나타내야 하는 고성능 LOB 응용 프로그램이라면 안전하고 설치하기 쉬우며 품질 면을 제외하고는 UWP가 대부분입니다. 그 품질 격차는 무엇보다 UWP를 죽이는 것입니다.

HTML+JS는 오늘날의 크로스 플랫폼 솔루션입니다. 다시 발명할 필요가 없습니다. IOS 및 Android에서 고성능 XAML 렌더링 엔진을 사용하는 것이 XAML을 더 이식성 있게 만드는 것이라면 더 의미가 있습니다.

나는 WinUI가 미래에 크로스 플랫폼을 목표로 해야 한다는 데 매우 동의합니다. 여기에 몇 가지 추가 생각이 있습니다.

즉각적인 우선순위

나는 WinUI 3가 .Net 5 통합이 포함된 Windows에서 작동하고 버그가 수정되었는지 확인하는 것이 즉각적인 우선 순위여야 한다는 일부 의견에 동의합니다. 그러나 아직 늦지 않았다면 아키텍처 결정을 내릴 때 향후 크로스 플랫폼 목표를 고려해야 합니다.

WinUI가 크로스 플랫폼이어야 하는 이유

명백하고 가장 중요한 이유가 있습니다. 개발자는 코드를 다시 작성하지 않고 최대한 많은 청중을 대상으로 하기를 원하며 C#(또는 C++은 가정합니다)/XAML이 좋은 조합입니다. 플랫폼 간 스토리가 없으면 Flutter와 같은 다른 기술로 이동할 것입니다.

또 다른 이유는 Microsoft에서 WinUI를 계속 지원하기 위함입니다. Microsoft는 자체 앱에서 WinUI를 사용하는 경우에만 계속 WinUI를 지원할 것입니다. 그들은 자신의 앱을 크로스 플랫폼으로 만드는 데 점점 더 집중하고 있습니다. React Native 및 Xamarin과 같은 일부 플랫폼 간 프레임워크가 아래에서 WinUI를 사용하는 것은 사실이지만 Flutter 또는 브라우저 기반 렌더링과 같은 다른 프레임워크가 승리하면 어떻게 될까요? 그러면 WinUI가 중복되어 WPF와 같은 유지 관리 모드로 전환됩니다.

크로스 플랫폼 구현 방법

Uno는 훌륭한 프로젝트이지만 내 생각에는 렌더링(및 입력) 레이어를 플랫폼 간에 만들고 이를 기반으로 빌드하는 것이 기본 컨트롤을 래핑하는 것보다 Flutter와 AvaloniaUI가 하는 일입니다. 렌더 및 입력 레이어를 교차 플랫폼으로 만드는 접근 방식에는 몇 가지 이점이 있습니다. 렌더 및 입력 레이어의 API 표면이 컨트롤보다 작은 것 같습니다(그러나 몇 가지 기본 레이어 등 위에 컨트롤을 빌드하는지 여부에 따라 다릅니다). 둘째, 네이티브 컨트롤을 래핑하는 데 의존하는 경우 플랫폼에 종속됩니다. 그들이 API를 변경하는 경우 API를 변경하거나 해결 방법을 구현해야 합니다. 지원 중단 시 이 작업을 충분히 빨리 수행하지 않으면 프레임워크가 손상됩니다. 컨트롤에 새 기능을 추가하려면 각 플랫폼에 대해 구현해야 할 수 있습니다. 플랫폼 프레임워크에 묶여 있기 때문에 프레임워크가 어떻게 발전하기를 원하는지에 대한 '비전'을 실제로 가질 수 없습니다. 또한 컨트롤의 모양과 동작이 다르기 때문에 개발자가 각 플랫폼에서 항상 테스트해야 합니다. 또한 합성 레이어와 같은 더 강력한 기능을 구현하는 것은 어렵거나 불가능할 것입니다. 렌더 레이어를 교차 플랫폼으로 만들면 이러한 모든 문제가 해결되며, 각 플랫폼에서 다른 모양을 원하면 다른 스타일을 추가할 수 있습니다. (일부 동작은 Mac에서 스크롤하는 것과 같이 다른 플랫폼에서 다르게 유지된다는 것을 인정합니다!).

WinUI는 현재 플랫폼에서 컨트롤과 렌더링 및 입력 레이어를 분리하고 있기 때문에 이를 수행할 수 있는 고유한 위치에 있는 것 같습니다.

렌더 레이어를 추상화하는 한 가지 방법은 Skia를 사용하는 것입니다. 그러나 이 추상화를 강제하여 성능이 저하되는 것을 원하지 않습니다. 2D 그래픽을 위한 C++ 제안인 렌더 레이어를 추상화하기 위해 살펴봐야 할 대안이 있습니다 . . 그들은 분명히 API 표면에 많은 노력을 기울였으며 꽤 포괄적인 것 같습니다. 그들은 2D 그래픽의 '문제'가 본질적으로 몇 년 전에 해결되었다고 주장하며 나는 그들의 API 표면이 꽤 완벽해 보인다는 데 동의해야 합니다. 이 제안에 반대하는 사람들이 많이 있지만 승인되지 않더라도 API 표면을 사용할 수 있다고 생각합니다. 이 API 표면에 대해 Direct2D 백엔드를 작성하면 제안이 수락되면 MSVC 팀이 작성하지 않아도 됩니다. 아마도 WinUI 팀은 작업을 허용하거나 팀 구성원을 추가하는 것을 정당화하기 위해 이것을 사용할 수 있습니다. 또한, 아마도 논문의 저자들이 기꺼이 도울 것입니다. Skia 또는 기타를 사용하여 다른 플랫폼에 대한 백엔드를 작성할 수 있으며 제안이 결국 수락되면 제안이 만들어졌을 때 기본 구현으로 전환합니다.

마지막으로 미래를 내다보면서 WASI - https://wasi.dev/ 를 언급하고 싶었습니다. 이것은 현재로서는 시스템 프로그래밍에 초점을 맞춘 것처럼 보이지만, 위의 C++ 제안이 아마도 다음을 위한 자연스러운 후보를 제공할 수 있는 완전한 크로스 플랫폼 앱 프레임워크(크로스 플랫폼 및 보안이 내장되어 있음)로 전환할 가능성이 있습니다. 렌더링 레이어 API. (그러나 이것은 아마도 매우 멀리 떨어져 있을 것입니다).

증거를 살펴보면 @SuperJMN 과 같은 사람들은 저장소의 내용을 고려할 때 많은 신뢰를 받고 있습니다. @SuperJMN 이 UWP가 아직 성숙하는 동안(이해할 수 있음) UWP를 포기한 것을 볼 수 있습니다. Microsoft는 여기에 댓글을 달고 있는 사람들의 저장소를 검토하는 것이 좋습니다. 일부 목소리는 그들이 세상에 제시하는 작업의 본체를 기반으로 특별히 신뢰할 수 없습니다.

@Noemata 저는 XAML+MVVM의 열렬한 팬이었습니다. Silverlight, WPF, WindowsPhone, Metro(WinRT)에서 작업했습니다. UWP와 Xamarin에 와서 지쳤습니다 ...

새로운 XAML 스택을 살펴본 다른 모든 시간과 이 반복을 구분하는 요소를 파악하기는 어렵습니다.

Microsoft는 환상적인 UWP 샘플 앱을 출시했습니다. 그들은 실제로 가능한 것을 멋지게 보여줍니다.

다음은 일부 목록입니다.

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

더 많은 좋은 예가 있습니다. 샘플이 다른 작업과 응집력이 있도록 쉽게 용도 변경되거나 구조화되는 방식으로 구축된 것은 없습니다.

해당 WPF 샘플에 대한 노력은 거의 기억나지 않습니다. 이것은 대부분 좋습니다.

문제? UWP 및 XAML을 사용하여 현재 위치에 도달하는 데 너무 오랜 시간이 걸렸습니다. 그리고 이제 메시지는 다시 한 번 혼란스러워집니다. UWP가 처음 릴리스되었을 때 Microsoft가 Visual Studio와 함께 적절한 프로젝트 템플릿을 제공하기만 했다면 UWP에 대해 덜 부정적이었을 것입니다. 최고의 VS 템플릿을 보려면 여기로 이동해야 합니다.

https://github.com/microsoft/windowsTemplateStudio

UWP 앱을 위한 매우 유연하고 완전한 구성 요소 집합임에도 불구하고 바로 사용 가능한 것은 아닙니다. 이 모든 것을 어떻게 찾습니까? 실마리 없음. 일을 하기 위해 보물 찾기에 가는 것은 자신감을 키우지 못합니다. WinRT 채택을 거부한 Office 팀은 도움이 되지 않았습니다. 그들은 이론적 팔 길이에 관계없이 OS에 들어가는 많은 것을 추진합니다. 품질 문제, 버그, Windows Phone의 실패 및 일관되지 않은 투자와 메시징을 던지고 여기 있습니다.

Microsoft는 환상적인 UWP 샘플 앱을 출시했습니다. 그들은 실제로 가능한 것을 멋지게 보여줍니다.

@Noemata 동의합니다. 정말 멋진 샘플입니다. 그러나 UWP를 사용하여 복잡한 앱을 개발하는 것은 미친 짓입니다. 물론 가능하지만 훨씬 어렵습니다. 예, WPF의 "그냥 작동하는" 시간이 그리워집니다.

MS가 샘플로 제공해야 하는 첫 번째 항목 중 하나는 MS 스토어 외부에 게시할 수 있는 간단한 UWP 앱입니다(예, 생각만큼 쉽지 않습니다).

나와 잘 맞지 않는 또 다른 점은 UWP가 올바른 데스크톱 경험을 버리고 "모바일 우선"을 염두에 두고 생각했다는 것입니다.

내가 틀렸다면 정정해 주세요. 하지만 대부분의 개발자는 UWP를 사용하여 데스크톱 앱을 개발하는데 UI가 일치하지 않습니다. 가장 먼저 떠오르는 것은 스크롤바입니다. 처음부터 터치패드에 최적화되어 있습니다. 그러나 데스크탑 사용자의 경우 스크롤 경험이 매우 나쁩니다(참고: WinUI 팀이 이 문제를 해결하기 위해 노력하고 있다고 생각합니다). 스크롤바를 다시 "정상"으로 만들 수 있는 솔루션을 찾기 위해 구글링을 많이 했습니다. 그렇게 하기 위해 API 함수를 호출할 수 없다는 것은 정말 미친 짓입니다.

마찬가지로 라디오 버튼/콤보 박스도 모바일에 최적화된 최소 크기를 가지고 있습니다. 단순히 라디오 버튼의 너비를 설정하는 것은 무시됩니다. 실제로 "MinWidth=0"을 설정해야 고려됩니다.

그리고 텍스트 버튼 색상은 흰색이고 초점이 맞춰지면 검정색이 됩니다. 무슨 일이죠? 그리고 텍스트 버튼에는 지우는 데 사용할 수 있는 "x"가 있습니다. 그게 터치패드입니다. 터치패드가 없는데 왜 거기에 있죠?

기본 텍스트 상자에 맞춤법이 활성화되어 있습니다. 왜 필요할까요?

다른 문제가 있지만 해결했습니다. 하지만 가장 큰 문제는 10분 걸릴 일들이 보통 2시간 이상 걸린다는 점이다. 나는 단순히 예측하는 능력을 잃었습니다. 내가 무언가를 할 때 반나절이 걸릴 것이라고 말할 때마다 2-3일이 걸릴 것입니다.

안녕하세요 여러분,
이것은 일반적인 토론 문제이고 UWP 희망/기능 요청을 어디에 둘지 모르기 때문에..... 이 스레드에서 기회를 잡습니다.

• uwp 앱을 Windows 탐색기의 컨텍스트 메뉴 에 통합하기 위한 더 나은 지원
  
  
  
  • https://aka.ms/AA6rmrk 에서 저희를 지원해 주세요.
  
  
• IServiceProvider 누락된 UWP 마크업 확장 및 마크업 확장이 사용되는 요소 자체
• UWP 스타일 트리거 누락
• UWP 암시적 데이터 템플릿 문제. 예를 들어 여기 를 참조하십시오
• 사용자 상호 작용 없이는 자동 인쇄가 불가능합니다(POS에서만 작동) 여기를 참조하십시오

위의 모든 기능 또는 문제는 현재 중단된 uservoice에서 해결되었습니다. 아무도 그 문제로 무슨 일이 일어 났는지 알고 있습니까? 피드백 허브에서 다시 만들어야 하나요?

"잊혀진 개발자"라는 문구를 좋아합니다. 나는 재능 있고 경험이 많으며 기술에 열정을 가진 많은 사람들을 알고 있습니다. 그들은 베테랑 .Net 개발자입니다. 일반적으로 iOS 및 Android용 앱 개발로 번창하는 많은 아이들보다 더 나은 앱을 만들 수 있다는 점에는 의심의 여지가 없습니다.
WinUI가 C# + .Net + Xaml에 대한 광범위한 경험을 활용하여 Windows, Android, iOS 및 웹용 앱을 만들 수 있는 쾌적하고 강력한 경로를 제공할 수 있다면 많은 사람들이 왜건에 뛰어들 것이며 전 세계는 높은 수준의 혜택을 받을 것입니다. 양질의 앱.
WinUI + Uno Platform 은 궁극적인 호출이 될 수 있습니다.

IServiceProvider가 누락된 UWP 마크업 확장 및 마크업 확장이 사용되는 요소 자체

여기 @mfe- !

여기 @mfe- !

@Mike-EE 와, 굉장합니다! CalcBinding을 UWP로 이식하려고 할 때 이 문제가 발생했던 것을 기억합니다. 내가 한 일은 보기 모델에 읽기 전용 필드를 추가하는 해결 방법입니다.

"한 번 작성, 모든 곳에서 실행".

Microsoft는 얼마 전에 이 문제에서 멀어졌습니다.

멋진 작품 모두 우리는 유명합니다! 😂

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

잊혀진 개발자는 침묵하거나 그냥 무시됩니다.

"잊혀진 개발자"라는 문구를 좋아합니다.

그 이름으로 조직하자! 💪

Microsoft에서 개발하고 지원하는 크로스 플랫폼 UI 프레임워크를 원합니다. _Uno Platform_ 및 _Xamarin.Forms_를 제외하고는 .NET 에코시스템을 위한 것이 없습니다(아직 데스크톱을 대상으로 작업하는 경우).

그리고 Windows 전용 비즈니스 응용 프로그램을 처음부터 작성하기로 결정하더라도 Microsoft가 UWP에 완전히 전념했다고는 생각하지 않습니다. 내가 틀렸다면 정정하지만 Office Online PWA를 위해 Office UWP 앱을 포기하지 않았습니까? MS가 자체 프레임워크를 버리는 경우 UWP를 신뢰해야 하는 이유는 무엇입니까? _기침 실버라이트_

고맙게도 WPF는 아직 포기되지 않았습니다. 그러나 그것은 내 의심을 더할 뿐입니다.

멋진 작품 모두 우리는 유명합니다! 😂

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

홀리 🤭

감독자! 다른 큰 저널, 웹 사이트 등으로 확장합시다 😛

앱 개발을 위한 크로스 플랫폼 솔루션을 찾고 있다면 Unity만 있으면 됩니다.

https://unity.com/

이러한 모든 솔루션과 마찬가지로 미니 운영 체제를 포함하는 프레임워크가 완성됩니다. Java는 프로그래밍 언어로 교묘하게 위장한 운영 체제였습니다.

최신 브라우저는 이제 미니 OS입니다. 나는 우리가 이것들로 충분하다고 생각합니다. WinUI/UWP는 Windows 10 이상의 기본 UI여야 합니다. 더 많은 곳에서 실행되는 XAML 엔진을 갖는 것이 합리적일 수 있습니다. 그것이 Unity와 같은 역풍에 맞서 날지 확신하지 못합니다. Microsoft가 다른 플랫폼에서 XAML을 호스팅할 수 있도록 Silverlight를 다시 개발하기 전에 세련된 고품질 UWP를 보고 싶습니다. 우리 모두는 그것이 얼마나 잘 작동했는지 압니다. Unity를 보지 않았다면 놓치고 있는 것입니다. 즉, 많은 코딩과 더 많은 디버깅을 수행할 준비가 되어 있어야 합니다.

다음 주에는 몇 초 만에 앱을 만들 수 있는 UWP용 VS 템플릿 세트를 출시하겠습니다. 이것은 "내부" 프로젝트에 사용되었습니다. VS에만 올바른 빌딩 블록이 내장되어 있다면 UWP가 기본적으로 RAD 프레임워크가 될 수 있다는 점을 증명할 것입니다.

다음 주에는 몇 초 만에 앱을 만들 수 있는 UWP용 VS 템플릿 세트를 출시하겠습니다. 이것은 "내부" 프로젝트에 사용되었습니다. VS에만 올바른 빌딩 블록이 내장되어 있다면 UWP가 기본적으로 RAD 프레임워크가 될 수 있다는 점을 증명할 것입니다.

@Noemata 멋지네요 ! 상당히 궁금합니다!

모든 디자인 언어에 적용할 수 있는 .Net 기반 크로스 플랫폼 UI 프레임워크를 원하는 경우. 더 이상 보지 마십시오. Comet입니다.

https://github.com/Clancey/Comet

아직 초기 단계이므로 여유 시간이 있으면 참여하십시오.
Comet은 기본적으로 존재하는 모든 플랫폼을 대상으로 하며, 각 플랫폼에서 기본 컨트롤을 대상으로 하거나 Skia를 사용하여 모든 것을 일관성 있게 그릴 수 있도록 선택할 수 있습니다(Flutter가 수행하는 방식과 정확히 일치함).

선언적 UI와 MVU 패턴을 사용합니다. Microsoft의 수석 프로그램 관리자 설계자인 James Clancey가 개발했습니다. 아직 공식적으로 지원되지는 않지만 커뮤니티의 관심이 충분하다면 가능합니다.

Comet에서 UI는 단지 라이브러리일 뿐이므로 Comet이 Material Design 라이브러리를 가지고 있는 것처럼 사용자(또는 Microsoft가 할 수 있음)가 WinUI 라이브러리를 개발할 수 있습니다.

모든 디자인 언어에 적용할 수 있는 .Net 기반 크로스 플랫폼 UI 프레임워크를 원하는 경우. 더 이상 보지 마십시오. Comet입니다.

@nerocui 멋있게 들리지만 적어도 보기에는 XAML 디자이너가 없습니다. 복잡한 UI를 구축하는 것은 아마도 현재 단계에서 미친 짓일 것입니다. 하지만 유망해 보입니다.

모든 디자인 언어에 적용할 수 있는 .Net 기반 크로스 플랫폼 UI 프레임워크를 원하는 경우. 더 이상 보지 마십시오. Comet입니다.

@nerocui 멋있게 들리지만 적어도 보기에는 XAML 디자이너가 없습니다. 복잡한 UI를 구축하는 것은 아마도 현재 단계에서 미친 짓일 것입니다. 하지만 유망해 보입니다.

그리고 드래그 앤 드롭이 아니라 코드가 변경될 때 디자이너에서 UI를 실시간으로 미리 보는 것입니다.

다음 주에는 몇 초 만에 앱을 만들 수 있는 UWP용 VS 템플릿 세트를 출시하겠습니다. 이것은 "내부" 프로젝트에 사용되었습니다. VS에만 올바른 빌딩 블록이 내장되어 있다면 UWP가 기본적으로 RAD 프레임워크가 될 수 있다는 점을 증명할 것입니다.

NoesisGUI를 사용하고 있습니까? 그렇다면 LOB 앱에 필요한 많은 기능이 누락되었습니다. 이제 Unity를 대상으로 하는 WinUI는 굉장할 것입니다.

저는 XAML의 현재 상태를 문서화하기 위한 리포지토리를 만들었으며 사람들이 XAML의 다양한 버전에서 작업을 수행하는 방법을 나열하는 통찰력과 실제 코드 조각으로 도움을 주고 기여할 수 있기를 바랍니다.

https://github.com/gatewayprogrammingschool/XAML-표준화

간단한 문제, 오늘날의 샌드박스를 넘어 크로스 플랫폼에 필요한 것을 수용하십시오. 이미 UI가 아닌 Windows/OS의 다른 모든 측면에 대해 수행하고 있습니다.

샌드박스 크로스 플랫폼을 이용하세요.

보낸 사람: anthonyadame [email protected]
보낸 날짜: 2020년 2월 29일 토요일 오후 8:00:13
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 댓글 [email protected]
제목: Re: [microsoft/microsoft-ui-xaml] 토론: WinUI는 플랫폼 간(#2024)이어야 합니다.

간단한 문제, 오늘날의 샌드박스를 넘어 크로스 플랫폼에 필요한 것을 수용하십시오. 이미 UI가 아닌 Windows/OS의 다른 모든 측면에 대해 수행하고 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
GitHub의에 그것을 직접이 이메일에 회신 볼 https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 , 또는 탈퇴 https://github.com/ 알림/구독 취소-인증/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

고성능 C++ 구성 요소를 C#과 통합하는 것은 UWP에서 간단합니다. DirectX 표면에 대한 액세스도 훨씬 향상되었습니다.

@Noemata 내가 관심 있는 것은 처음부터 C++를 작성할 필요가 없다는 점을 제외하고 WinDev는 C++ API, Managed Direct X, XNA, .NET의 적절한 AOT 컴파일과 관련하여 .NET 언어를 눈과 눈을 동일하게 만드는 모든 시도를 계속 방해합니다. 코드, COM 기능, ....

WinUI 3.0을 크로스 플랫폼으로 만드는 것은 기존 .NET/Forms 애플리케이션을 WinUI로 이식하기 위한 인수가 될 것입니다.

처음에는 macOS를 지원하는 것으로 충분하며 Windows와 동일한 성능이 아니거나 애니메이션과 같은 모든 기능이 아닌 경우 문제가 되지 않습니다.

Windows는 참조 플랫폼입니다. 물론 최상의 성능을 위해서는 DirectX에 연결해야 합니다.

내 생각에 macOS를 지원하기 위해 HTML+JS에서 대규모 C# 응용 프로그램을 다시 작성하는 것은 의미가 없습니다. 또한 새로운 데스크톱 응용 프로그램의 경우 C#이 더 나은 선택입니다.

데스크톱 응용 프로그램의 경우 C# 및 XAML이 HTML+JS보다 훨씬 더 안정적입니다.

WinUI 3.0을 크로스 플랫폼으로 만드는 것은 .NET, C# 및 XAML의 미래를 보장합니다.

안녕 모두

저는 런던에서 일하는 WPF 계약 개발자입니다. 저는 2006년부터 여러 금융 기관을 위해 WPF를 사용하여 복잡한 고성능 사용자 인터페이스를 구축해 왔습니다. 이에 대한 제 의견은 다음과 같습니다.

1) 나는 영국의 고용 시장을 예의주시하고 있습니다. 2006년 이후 광고된 WPF 작업의 100%(그 중 1000개)는 금융 부문을 위한 고성능 금융 거래 데스크탑 앱을 구축하기 위한 것입니다. 모든 산업 분야의 UWP 개발자에 대해 아직 구인 광고가 없습니다.

2) 이러한 데스크톱 거래 앱은 UWP 또는 곧 출시될 WinUI를 사용할 수 없습니다. 여러 가지 복잡한 이유로 WPF에 비해 충분하지 않습니다. 또한 Fluent 디자인은 이러한 사용자가 관심을 갖는 것이 아닙니다. Excel 그리드처럼 보이기만 하면 됩니다. 애니메이션, 스타일 지정 없이 데이터와 놀라운 성능만 있으면 됩니다.

3) 이 고객은 크로스 플랫폼 솔루션에 전혀 관심이 없습니다. 아무도 Mac을 사용하지 않으며 모바일에는 관심이 없습니다.

4) 이러한 WPF 개발 팀은 타사 WPF 제어 라이브러리에 막대한 투자(시간과 비용)를 가하거나 나 같은 사람을 통해 개발된 복잡하고 성능이 뛰어난 사용자 지정 제어 제품군을 가지고 있습니다. 그들은 매우 중요한 이점이 없는 한 WPF에서 멀어지지 않을 것입니다.

5) 이러한 금융 기관의 경우 데스크탑/WPF용으로 명시적으로 작성할 필요가 없는 모든 애플리케이션은 웹 기술 및 Javascript로 작성됩니다. 그들은 그보다 더 이국적인 것에는 관심이 없습니다. 플러터, 블레이저 등.

이것이 영국의 상황입니다. 수백 명의 WPF 개발자가 빠른 시일 내에 새로운 분야로 이동할 생각을 하지 않습니다. UWP 개발자 없음

또한 크로스 플랫폼에 대한 모든 히스테리를 이해하지 못합니다. 모바일과 데스크톱을 아우르는 크로스 플랫폼은 어리석은 일입니다. 결코 흥미롭지 않을 것입니다. Microsoft는 데스크톱 및 전화에서 실행되는 UWP 앱으로 이것을 시도했습니다. 이는 재앙이었습니다. 앱을 복잡하거나 흥미로운 작업을 수행할 수 없는 가장 단순한 UI로 제한했습니다. 데스크톱 및 모바일 장치는 다양한 작업과 사용 사례에 맞게 제작되었으며 다양한 앱이 필요합니다. 우리 모두가 이 사실을 알고 있습니다.

저에게는 이전 버전과의 호환성을 희생하지 않고 Microsoft에서 WPF에 직접 더 많은 투자를 하고 싶습니다. 우리가 금속에 더 가깝게 작업할 수 있도록 관리되지 않는 C++에서 WPF 지원 제어 개발을 보고 싶습니다. 더 나은 바인딩 기술, 더 나은 데이터 템플릿, 부분 상속을 포함한 더 나은 컨트롤 템플릿 기능을 보고 싶습니다. 더 나은 디버깅 도구와 시각적 트리 분석기를 보고 싶습니다. XAML 디버깅이 더 구체화되는 것을 보고 싶습니다. UI에서 더 나은 멀티 스레딩 지원을 원합니다. 나는 많은 것을 원하고 동료 영국 WPF 계약자들도 원합니다.
현재 Microsoft 로드맵은 내가 원하는 것은 하나도 없고 관심도 없는 모든 것을 제공합니다.

Microsoft가 이 비전을 지원하지 않는다면(지금 당장은 분명하지 않음), 계획 B는 WPF를 오픈 소스 기여를 통해 필요한 플랫폼으로 성형하는 커뮤니티가 될 것입니다. 코드와 아이디어는 WPF 프레임워크의 일부가 됩니다.

@deanchalk 나는 이것의 대부분이 WPF에 대한 관심이 있음을 보여주기 위해 WPF 리포지토리에 더 잘 배치되었을 수 있다고 생각합니다. 여기에 게시하면 대부분 WinUI 리포지토리에서 수행되는 작업/이 문제에서 논의된 작업에 관심이 없다고 말합니다. 그것이 유효한 입력이지만 무효 토론을 넘어 건설적인 것으로 이어지지는 않을 것입니다.

@weltkante @deanchalk WinUI 에서 "레거시 제어 지원"을 요청하는 저장소에 문제가 있습니다: https://github.com/microsoft/microsoft-ui-xaml/issues/1833
최소한 4) 항목은 해당 문제에 적합하며 Microsoft의 투자 사례를 만들기 위해 해당 항목에 다시 게시해야 합니다.

@deanchalk , 저는 여전히 WPF의 열렬한 팬입니다. 고맙게도 Microsoft의 사랑을 받기 시작한 훌륭한 도구입니다. Microsoft가 처음에 WPF를 삭제하기로 선택한 방식은 가장 불행했습니다. UWP는 빛나는 새 장난감이기 때문에 WPF에 대한 지속적인 투자를 방해해서는 안 됩니다.

UWP는 여러 면에서 올바른 방향이었습니다. 불행히도 첫 번째 반복에서는 WPF를 사용하고 있고 마이그레이션을 고려했을 수 있는 사람들에게 가장 중요한 요구 사항 중 일부를 무시했습니다. 무엇보다도 단일 조직의 벽 내에서 XAML 조각화의 다소 놀라운 상태입니다. WPF != Silverlight != UWP != 자마린. 와!

저는 2020년에 WPF에 자신을 확고히 하기로 선택한 WPF 개발자에게 덜 동정적입니다. 상황이 상당히 진행되었습니다. WinRT API를 사용하는 기능이 있는 XAML 아일랜드는 UWP로 마이그레이션을 시작하는 매우 쉬운 경로를 제공합니다. 그리고 도매 전환을 선택한 경우 UWP가 더 이상 부족하지 않습니다.

더 큰 문제는 다음 단계에 대한 Microsoft의 명확성이 부족하다는 것입니다. XAML Nirvana를 기대했던 모든 사람들은 UWP로 다시 한 번 재생되고 있는 Silverlight의 실패를 포기했습니다.

WinUI는 분명히 UWP로 레이블이 변경되었으므로 목격하는 것이 고통스럽습니다. Microsoft는 우리 모두가 UWP가 무엇인지 잊어버리기를 희망합니다.

그러나 마이크로소프트의 왼손이 오른손이 하는 일과 항상 일치하는 것은 아닙니다. WindowsX는 Win32와 함께 제공되는 모든 것(WPF/Winforms/etc.)을 낮은 성능의 샌드박스에서 "실행될 수 있는" 응용 프로그램에 대한 희미한 전망으로 만들었습니다. UWP는 현재 Windows 10, WindowsX 및 이후 버전의 기본 UI입니다. WinRT API는 Win32에 비해 크게 개선되었습니다. 그래서 2020년대로 넘어갈지 2010년대에 내놓을지 선택해야 할 것 같아요.

WinUI는 분명히 UWP로 레이블이 변경되었으므로 목격하는 것이 고통스럽습니다. Microsoft는 우리 모두가 UWP가 무엇인지 잊어버리기를 희망합니다.

@Noemata WinUI는 UWP API(XAML, Composition, Input,...)를 기반으로 하는 신제품입니다. 이름은 기본 앱 모델에 관계없이 Windows 앱용 UI를 빌드하는 데 사용할 수 있으므로 의미가 있습니다.

혼란스러워요. 당신은 마지막 단락에서 10X를 언급하고 있습니다. UWP 앱 모델 자체가 Windows 10X에서 추진되고 있습니다. 이제 10X가 성공할지 여부는 시간이 말할 수 있을 것입니다. 그러나 MS는 메시지에서 분명했습니다. UWP는 귀하가 지적한 대로 10X(웹과 함께)의 기본 플랫폼입니다.

@Noemata 는 2020년까지 2010년에 사용할 수 있는 기능을 따라잡았고 우리 중 많은 사람들이 2010년에 머물러야 했습니다.

우리 중 많은 사람들이 Silverlight, XNA를 삭제하고 MS가 .NET Core, WinUI에 필요한 재작성을 어떻게 손으로 흔드는지 보면서 시작하는 재작성 트레인에 지쳤습니다. 더 적은 기능을 되찾기 위해 재작성 비용을 지불해야 하는 이유를 모르는 완전히 작동하는 애플리케이션을 사용하는 고객.

현재 Android 및 Windows 10 X 태블릿이 있는 영리함 덕분에 우리가 기대하는 것은 WinUI가 아니라 Xamarin 및 PWA입니다.

@pjmlp , 아마도. 어떤 기능이 누락되었는지 궁금합니다. 꽤 큰 WPF 앱을 UWP로 이식했습니다. 가장 큰 골칫거리는 보안 샌드박스와 이에 맞서 싸우기보다는 함께 일하는 법을 배우는 것이었습니다. 이전에는 Data Grid, DB 연결, 고속 통신을 위한 적절한 API 등과 같은 누락된 부분이 있었습니다. 지금은 부족한 것이 거의 없습니다. WPF에서는 거의 쉽게 할 수 없는 일이 많이 있습니다. 공평하게 말해서, 현재로서는 UWP가 더 최적의 방식으로 기계 코드로 컴파일하고 더 나은 DirectX 렌더링 스택을 사용하기 때문에 성능이 더 낮다는 점을 제외하고 WinRT API에 대한 액세스를 활용하여 WPF에서 할 수 없는 일은 없습니다. 또한 IP를 보호하거나 침입자를 방지하려는 경우 WPF 코드를 난독화(더 취약하게 만들기)해야 합니다.

휴대폰/태블릿은 포인트 솔루션 종류의 앱을 위한 훌륭한 장치입니다. 나는 전화로 교향곡을 악보하거나 고층 건물을 디자인하고 싶지 않으며, 내 데스크톱에서 모바일이 작동하도록 하는 것보다 내 데스크톱 앱의 포인트 솔루션 부분을 모바일로 타겟팅할 수 있기를 원합니다.

@Felix-Dev WinUI가 무엇인지 알았습니다. WPF, Winforms 및 MFC/Win32 개발자가 구매하지 않기 때문에 또 다른 포크가 필요한 이유가 궁금합니다. 더 나은 전략은 마이그레이션을 더 매력적으로 만들거나 덜 고통스럽게 만들거나 둘 다를 만드는 것이었습니다.

Microsoft는 UWP로 많은 일을 해냈습니다. 모든 종류의 사용 사례를 다루는 풍부한 샘플 앱이 있습니다. 누락된 기능과 마찬가지로 늦게 도착했습니다. 정말 너무 늦었나요?

@Noemata WinUI는 OS에서 UWP UI 스택을 분리하는 것이 절대적으로 필요한 단계이므로 WinUI Desktop이 있든 없든 어느 쪽이든 발생했을 것입니다. Windows 10이 처음 출시되었을 때 WinUI가 이미 존재했다면 가장 좋았겠지만 그렇지 않은 이유가 있습니다.

너무 늦었다는 것은.... UWP 커뮤니티 디스코드 채널에서 그런 토론을 많이 했고 여기에서도 수없이 열정적인 교류를 했습니다. 우리 중 일부는 배가 이미 항해했다고 생각하는 반면 다른 일부는 여전히 UWP 플랫폼/WinUI가 성장하고 성숙하여 주요 개발 플랫폼이 될 가능성이 있다고 생각합니다. MS에 대한 최선의 접근 방식이 어떻게 생겼는지 많은 아이디어를 가진 많은 사람들이 있습니다(예: xplatform으로 갈지 말지?). 사실, 팀은 현재 WinUI 3에 대해 열심히 작업하고 있으며 이 릴리스는 진정한 도전에 착수하기 시작했음을 알릴 것입니다. 커뮤니티의 도움을 받아 WinUI를 발전시켜 Windows를 목표로 하는 개발자가 선택하는 프레임워크가 될 것입니다. .

@Noemata , 우선 Telerik, Component One 등과 같은 기존 타사 구성 요소 라이브러리와의 호환성...

그런 다음 처음부터 다시 작성할 필요가 없습니다. 언급한 대로 우리는 다시 작성하는 데 지쳤습니다.

DirectX와 관련하여 WPF의 3D 모델링 클래스가 지원되지 않을 뿐만 아니라 Microsoft가 DirectX에 대한 런타임 프로젝션을 생성하는 데 신경을 쓸 수 없고 다소 유쾌한 C++/CX 방언이 단어로 대체되었기 때문에 C++를 작성할 것으로 예상됩니다. 능력은 떨어지지만 C++/WinRT와 더 잘 호환됩니다.

게다가 완벽하게 작동하는 WPF 코드를 버려야 할 뿐만 아니라 WCF, EF6 코드에도 똑같이 해야 합니다.

나는 여전히 UWP가 Win32보다 훨씬 더 나은 API라고 생각합니다. 어떻게든 Longhorn이 있어야 하는 것입니다. 그러나 Microsoft가 많은 조직의 재작성 예산을 소진했기 때문에 이것이 실행되는 방식이 너무 많은 다리를 태워버렸습니다.

@pjmlp , 그것들은 모두 다소 온건한 반론을 가진 좋은 점이므로 시도조차하지 않을 것입니다. WPF 3D API에 대한 지원이 없다는 것은 개인적으로 큰 타격이었습니다. 3D용 WPF 바인딩 옵션을 고려할 때 새로운 접근 방식을 배우는 것은 재미도 없고 능력도 훨씬 떨어집니다. UWP에서 3D에 대한 C# 대안이 있지만 3D 모델에 바인딩할 때의 이점을 경험하고 나면 훨씬 덜 유용합니다.

C++/CX는 C++/WinRT에서 해결하는 데 너무 오랜 시간이 소요된 또 다른 문제였습니다.

WCF는 죽었습니다(죄송합니다. 새로운 옵션이 훨씬 더 좋습니다). EF6에는 훨씬 더 나은 마이그레이션 스토리가 있어야 했습니다. 재작성 예산 실패 @pjmlp 에 대한 당신의 생각은 절대적으로 옳습니다. 분명히 이것은 Microsoft가 사용하던 것이었고 미친/일관되지 않은 기술 변동을 감안할 때 더 이상 고려하지 않습니다.

@Felix-Dev, 당신도 완전히 유효한 지적을합니다. UI 디커플링은 처음부터 존재했어야 합니다. XAML 기반 xplatform UI를 요청하는 사람들은 요청을 다시 표현하고 API 표면(다른 Java/Silveright/Uno Platform/Unity/Whatever… 금속 앱에 가까운 HTML로 끝나는 것은 고려할 수 없습니다). 저는 현재 최신 MS 내부 이니셔티브에 대해 잘 모릅니다. 밖을 내다보면 WinUI는 배가 다시 교정되고 있음을 나타내는 깃발을 흔들고 있습니다(몇 번 더?). Silverlight의 죽음으로 Microsoft를 방어하는 것은 불가능해졌습니다. 다시는 그 검을 들지 않을 것이다. 내가 진짜 하고 있는 일이 UWP의 죽음을 한탄하는 것 같다 :-( ... 고통스럽다. https://www.youtube.com/watch?v=uBiewQrpBBA

찰리 == 마이크로소프트

크로스 플랫폼? 마이크로소프트는 UNO를 사서 끝내야 합니다.

크로스 플랫폼? 마이크로소프트는 UNO를 사서 끝내야 합니다.

어떤 솔루션이 제공되든 웹 브라우저나 일종의 웹 보기에 의존하지 않기를 바랍니다. 플랫폼의 기본 창이나 UI 표면이 무엇이든 간에 UI를 표시하지만 Windows에서와 동일하게 보입니다.

크로스 플랫폼? 마이크로소프트는 UNO를 사서 끝내야 합니다.

어떤 솔루션이 제공되든 웹 브라우저나 일종의 웹 보기에 의존하지 않기를 바랍니다. 플랫폼의 기본 창이나 UI 표면이 무엇이든 간에 UI를 표시하지만 Windows에서와 동일하게 보입니다.

이것이 Windows 7을 제외하고 UNO가 수행하는 방식입니다. Windows 7은 웹 브라우저를 사용하는 유일한 예외입니다.

크로스 플랫폼 데스크톱 솔루션이 필요한 WPF 개발자에게는 Wine이 실행 가능한 옵션일 수 있습니다. 저는 Linux에서 Wine을 실행하기 위해 대규모 WPF 응용 프로그램(대부분 .NET Core WPF)을 이식하는 데 큰 성공을 거두었습니다. 시작하는 데 도움이 되는 글이 있습니다.
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

또한 일부 WinForms 앱을 Linux에 이식하기 시작했습니다. 지금까지 나는 어떤 문제도 겪지 않았습니다.

Wine은 또한 Mac, Chrome OS 및 Android에서 실행할 수 있어야 합니다. 나는 리눅스 만 시도했습니다.

나에게 이것은 DirectX를 추상화 계층으로 사용하는 것이 작동하고 따라야 할 실행 가능한 모델임을 보여줍니다. .NET WASM이 더 성숙해지면 WebGL을 사용하는 웹에서도 잘 작동할 것이라고 생각합니다.

Microsoft가 Wine을 돕도록 하는 것(최소한 와인이 깨지지 않도록 하는 것)은 많은 도움이 될 것입니다. 그들은 WineLib을 사용하여 진정한 기본 솔루션을 만드는 데 도움을 줄 수 있으며 전문 지식을 감안할 때 너무 많은 노력이 필요하지 않다고 생각합니다.

AvaloniaUI는 이미 크로스 플랫폼입니다. 프로젝트의 사람들에게 WinUI 개선을 위한 도움과 피드백을 요청하지 않는 이유는 무엇입니까?

글쎄요, Uno Platform만큼은 아닙니다. Uno Platform은 웹에서도 실행됩니다(WASM). 아발로니아에는 이 기능이 없습니다.

Avalonia는 또한 Uno가 피하려고 하는 자체 XAML 방언을 사용합니다.

보낸 사람: Shimmy [email protected]
보낸 날짜: 2020년 3월 27일 금요일 오전 4:09:30
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 댓글 [email protected]
제목: Re: [microsoft/microsoft-ui-xaml] 토론: WinUI는 플랫폼 간(#2024)이어야 합니다.

AvaloniaUI는 이미 크로스 플랫폼입니다. 프로젝트의 사람들에게 WinUI 개선을 위한 도움과 피드백을 요청하지 않는 이유는 무엇입니까?

글쎄요, Uno Platform만큼은 아닙니다. Uno Platform은 웹에서도 실행됩니다(WASM). 아발로니아에는 이 기능이 없습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/ 구독을 취소합니다.

대부분의 WinUI 기술은 Sliverlight에서 나왔고 Sliverlight는 실제로 크로스 플랫폼을 달성했습니다. 따라서 WinUI 크로스 플랫폼은 기술이 아니라 전략에 의존합니다.

솔직히... 실제로 Microsoft가 따라잡기 위해 노력하고 있는 것은 정말 한심한 일입니다... 그들은 "큰" 시장 점유율에만 관심이 있고 고객/제품 팬이 원하는 것을 찾고 있지 않습니다.

마이크로소프트는 DESKTOP APP 개발이 웹 개발이 너무 끔찍할 때에도 구식 WEB 개발로 옮겨간 이유입니다.

모든 XAML 개발자는 HTML/CSS가 너무 쓰레기라는 데 동의합니다.

하지만 여전히... HTML, CSS, DOM... React, Angular, Vue와 같은 프레임워크를 사용하여 좀 더 즐겁게 만들려고 합니다. 사람들은 여전히 ​​이 구식 웹에 집중했고, 2-4년마다 새로운 플랫폼을 위해 죽는 Microsoft의 새로운 폐쇄 소스 Windows 전용 플랫폼이 아닙니다.

XAML 기반 Win-app 플랫폼은 몇 년 전에 오픈 소스여야 합니다. WEBSITE, Windows, Mac, Linux, Android(고객이 원하는 모든 플랫폼)에 한 번만 배포할 수 있어야 합니다. Windows 스토어는 XAML/UWP 앱 렌더러와 플랫폼 간이어야 합니다. (Google 크롬이 HTML/CSS 렌더러와 크로스 플랫폼인 것과 유사).

Microsoft의 황금기에는 XAML 기반 크로스 플랫폼 앱이 웹을 파괴할 수 있었습니다. 그러면 우리는 이 CSS, HTML, DOM 및 수많은 프레임워크를 처리할 필요가 없었을 것입니다.

그러나 아닙니다. 독점 소프트웨어에 대한 Microsoft의 집착으로 인해 웹에서 패배했습니다.

한편 Google의 Flutter는 XAML에 대해 항상 원하던 것이 되었습니다.

WinUI 3가 MAUI의 대상 플랫폼이 될 것으로 기대합니다. Uno 플랫폼은 이미 WinUI 3 Preview가 지원된다고 발표했습니다.
그래서 @jeromelaban /Microsoft 우리가 정말로 필요로 하는 것은 Uno/MAUI 통합입니까? MAUI는 웹(브라우저) 대상이 없는 Flutter 또는 Uno보다 덜 유용한 IMO입니다.

MAUI 저장소 에도 의견을 남겨주세요.

어디서나 WPF(실버라이트)!

DirectX를 다른 플랫폼으로 이식하는 것은 방대한 작업으로 보입니다. 아마도 해결책은 DirectX 대신 OpenGL 또는 Vulkan을 사용하는 것입니다.

Google에는 호출 및 셰이더를 기본 API(데스크톱 gl[swiftshader 소프트웨어 렌더러에서 제공], vulkan, directx, metal)로 변환하여 모든 플랫폼에서 기본적으로 OpenGL ES를 실행할 수 있는 ANGLE이 있습니다. 또한 Skia와 함께 실행되는 Chrome 및 Flutter의 핵심 부분입니다.

Microsoft는 GUI 앱용 DirectX의 작은 부분(시작점으로 삼을 수 있음)을 수행하고 ANGLE처럼 네이티브 API로 변환할 수 있습니다.

"다른 Linux 배포판 지원" 문제와 관련하여 Linux 사용자는 종종 비호환성을 스스로 해결할 만큼 충분히 숙련되어 있으며 Docker가 서버용으로 하는 것처럼 데스크탑용 패키징을 통합하는 Flatpak이 있습니다.

Lonje 채팅 https://www.lonje.com/message/1968439855/ 에서 언급됨

나는 정말로 WinUI가 사용자 정의 테마를 계속 지원하면서 Mac과 Linux에서 기본 테마도 지원해야 한다고 생각합니다.
Mac 사용자에 대해서는 잘 모르겠지만 Linux 커뮤니티는 데스크탑이 어떻게 보이는지 제어하는 ​​것을 좋아합니다.
그들은 이미 Gtk를 가지고 있으며 WinUi 프레임워크에 포함시키는 것이 좋습니다.

나는 정말로 WinUI가 사용자 정의 테마를 계속 지원하면서 Mac과 Linux에서 기본 테마도 지원해야 한다고 생각합니다.
Mac 사용자에 대해서는 잘 모르겠지만 Linux 커뮤니티는 데스크탑이 어떻게 보이는지 제어하는 ​​것을 좋아합니다.
그들은 이미 Gtk를 가지고 있으며 WinUi 프레임워크에 포함시키는 것이 좋습니다.

WinUI는 스타일 언어이기 때문에 가장 확실히 하기 어려운 작업이며 기본 XAML 프레임워크에서는 기본 테마도 제공되는 동안 사용자가 직접 테마를 지정해야 합니다.

나는 과거에 커뮤니티가 macOS 및 iOS용 Metal Renderer를 개발하고 Android용 Skia 렌더러를 개발할 수 있는 방식으로 프로젝트를 구성해야 한다고 제안한 적이 있습니다.

모든 플랫폼에서 동일한 기본 스타일 및 템플릿을 사용하거나 Android 및 macOS 스타일의 기본 템플릿 및 리소스를 생성할 수 있습니다.