Maui: .NET 5용 크로스 플랫폼 UX

나는 이 아이디어를 좋아한다. 그러나 실제로는 Xamarin.Forms 팀에서 처리할 가능성이 더 높은 항목입니다.
아마도 Core 팀은 UX 프레임워크를 "더 나은"(CoreFxLab이 하는 것과 같이)을 만들기 위해 몇 가지 저수준 구성에 기여할 것입니다.

편집: WebAssembly도 지원되는 플랫폼이 될 수 있습니까?

아이디어가 마음에 듭니다. 여러 환경에서 여러 UI 기술로 고통받는 사람들(저를 포함하여)을 보았습니다.

나는 예측 가능한 미래에 corehost 의 대체품으로 네이티브 애플리케이션을 사용하여 Android 및 iOS 기기로 이식된 .net 코어를 보게 될 것이라고 확신합니다. 즉, UI 기능이 필요합니다.

2D xplat 드로잉 라이브러리(가속 드로잉 포함)의 경우 예를 들어 Skia가 있습니다.

모든 시나리오에서 XAML-Standard는 Fluent Design 지침과 함께 UI를 "설명"하는 표준 방법을 달성하기 위해 이동하는 것이 좋습니다.

그러나 .Net Team에서 xplat System.Drawing.X 프리미티브를 다시 가져오는 것보다 더 많은 시간을 투자할 계획이 있는지 회의적입니다...

@4creators 아마도 이 토론 이 당신에게 흥미로울 것입니다

@vibeeshan025 WebAssembly는 JavaScript를 대체하는 것이 아니므 로 대부분의 의견이 의미가 없습니다. WebAssembly를 DOM과 연결하려면 여전히 JavaScript가 필요합니다. 따라서, 아니요. 단순히 무언가를 wasm으로 컴파일하고 이전에 JavaScript로 수행한 작업을 대체할 것으로 기대할 수 없습니다. 그것은 작동 방식이 아닙니다. UI 기술이 아닙니다.

얘들아, 여기 내 5c를 넣고 싶다.
System.Drawing.X는 .NET Core 개발에 필수적입니다. (방금 https://github.com/dotnet/corefx/issues/20325에서 왔습니다)

UI 현재 - 웹(프론트 엔드) 개발자에게 문의하십시오. 그들은 핫 리로드와 같은 현대적인 트릭을 많이 사용합니다.
저는 개인적으로 React/ReactNative에서 진행되는 상황을 좋아합니다. C#을 사용하여 React를 작성한 다음 다양한 플랫폼에 대해 다양한 렌더 엔진을 사용하는 것은 정말 멋진 일입니다.

FWIW, Mono는 WebAssembly를 채택하고 있으므로 Mono에서 작동하면 WebAssembly에서 작동합니다(또는 작동할 것입니다). 그것이 적어도 현재의 생각/이해입니다.

또한 .NET/MSFT가 이 작업을 수행할 확률에 대한 감정을 반영해야 합니다. 그들의 모든 초점/IQ는 핵심/내부/프레임워크/그냥 작업에 배치되었으며 앞으로 1년 정도는 이러할 것이라고 생각합니다. 그러나 누가 알겠습니까? (기분 좋게) 놀랄 수 있습니다.

이에 대한 내 견해는 일부 외부 노력이 추진력을 얻고 아마도 MSFT, ala Xamarin에 의해 구매될 것이지만 더 UI 중심입니다(Xamarin의 핵심 강점인 IMO인 프레임워크/도구 중심과 반대). 따라서 각각 오픈 소스 및 유료 채널을 통해 가치 제안을 제공하는 Avalonia 또는 Noesis 와 같은 것입니다. 덧붙여서, 둘 다 내장/지원 Mono입니다.

Xaml Standard는 Xamarin.Forms용 XAML Standard(미리 보기) 릴리스와 프로젝트 진행 상황에 대한 기한이 지난 업데이트 로 약간 이동했습니다. PR dotnet/designs#111에는 이 제안에 도움이 되는 방향으로 가고 있는 것으로 보이는 프로젝트 목표에 대한 매우 흥미로운 토론 이 있습니다.

Silverlight는 코드가 이미 존재하는 훌륭한 솔루션입니다.

1. 오픈 소스 Silverlight 코드
2. dotnet 코어 런타임 위에서 실행되도록 합니다.
3. 리눅스 배포판에 달빛 사용
4. "Electron"에 대한 dotnet 핵심 대안 만들기(메모리 사용량 감소 + 엄청난 성능 향상 + xaml 장점)
5. 기본 컴파일(언젠가 corert 프로젝트가 빛을 볼 경우)

관련성을 찾았습니다- http://platform.uno

@gulshan 흥미롭고 훌륭한 프로젝트입니다. UWP 기능의 대부분을 지원하고 있습니까? 단 4명의 기여자로 매우 짧은 시간에 이렇게 풍부한 기능을 구현할 수 있었던 방법은 무엇입니까?

@vibeeshan025 IIRC에 자금을 지원하는 회사가 있습니다...

탐색할 가치가 있는 또 다른 미래 - HTML/CSS + .net(JS/TS 대신). 여기에서 이미 시도 중입니다-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

조사한 결과 tcl/tk는 모든 플랫폼에 대한 GUI 옵션이 될 수 있습니다. Windows에서 tcl/tk가 실제 gdiplus 항목을 호출하는지 확실하지 않지만 WPF 및 Winforms를 Linux, Mac, Windows, Android, iOS, 그리고 아마도 webforms로 가져오는 옵션이 될 수 있습니다. tcl/tk가 마지막 3가지를 아직 지원하는지 확실하지 않습니다. 이렇게 하면 GUI 지옥을 단일 코드 기반으로 유지 관리하기가 훨씬 쉬워집니다.

사용할 수 있는 GUI 라이브러리:

• TclBridge (무료 또는 오픈 소스로 보이지 않음)
• 모노 하나 (아마도 최고일 것입니다)
• 독수리 (얼마나 좋은지 확실하지 않음)
• 아마도 다른 사람들도 마찬가지일 것입니다.

cpython의 tkinner 모듈에서 tcl/tk를 사용하는 아이디어를 얻었습니다.

또한 .NET Core가 *.resources(컴파일된 resx) 또는 *.resx에서 리소스 로드를 지원하는지 여부도 아직 확실하지 않습니다. 그렇게 하면 훌륭할 것입니다.

Microsoft.DesktopUI.App 현재 v3.0.0-alpha-26921-3은 Windows .NET Core SDK 의 일일 빌드에서 사용할 수 있습니다. GDC 및 DirectX에 대한 일부 번역 계층에서 Linux에서 실행하고 실행하려면 무엇이 필요한지 궁금합니다.

크로스 플랫폼 UX 그 이상을 필요로 하며 크로스 플랫폼 애플리케이션 개발 프레임워크여야 합니다.
UX에만 국한하는 것은 실수입니다. 최소한 SilverLight + RIA-Services의 모든 기능이 있어야 합니다.
수십 년 동안 지속될 대기업을 위한 거대한 맞춤형 시스템을 작성할 때는 1년(또는 10년) 후에 어떤 요구 사항이 추가될지 전혀 알 수 없으므로 모든 옵션을 열어 두어야 합니다. UWP와 마찬가지로 브라우저 내부에서 실행되는 것과 동일하게 고려되지 않습니다. 서로 다른 플랫폼의 모든 단일 기능, API 및 서비스에 대한 완전하고 무제한적인 기본 액세스 권한이 있어야 합니다.
그리고 서버와 클라이언트를 모두 작성하는 시스템을 개발할 때 REST 또는 이와 유사한 것을 사용하고 싶지 않습니다(이는 서버를 작성하고 다른 사람이 클라이언트를 작성할 때 사용하도록 의도됨). 대신 서버 API를 정의한 다음 서버에 있는 것과 동일한(===) 클래스 및 메서드를 사용하여 클라이언트에서 자동으로 호출하는 RIA의 정신이어야 합니다. 모든 것은 강력하게 입력해야 합니다. 데이터 유효성 검사는 SQL 서버의 필드(또는 사용 중인 모든 데이터 소스)에서 얻은 엄격한 제한으로 시작하고 DataAnnotations에 의해 확장됩니다. 이 제한은 자동으로 클라이언트에 끝까지 전파됩니다(현지화 고려).

이것이 필요한 것이며 그 이하도 허용되지 않습니다.
유비쿼터스 .NET 클라이언트 애플리케이션 개발 모델 생성

이제 Visual Basic 6이 출시된 지 20년이 지났고 1998년 당시의 생산성에 근접하지 않습니다.Microsoft는 "Microsoft 세계"에서 더 큰 사용자 지정 시스템을 수행하는 방법과 20년 전의 생산성을 다시 가져올 방법에 대한 비전을 제시해야 합니다.

마이크로소프트는 그들의 똥을 한데 모아 한발 더 나아가 그들이 가진 책임을 받아들여야 합니다. Microsoft는 수십 년 동안 MS 기술에 막대한 투자를 한 모든 고객, 파트너 및 개발자가 크게 실망했으며 MS에 대한 신뢰가 매우 낮다는 사실을 인식해야 합니다. MS는 고객, 파트너 및 개발자를 존중하기 시작하고 명성과 존경을 재건해야 하지만 현재 Skype로 무엇을 하고 있고 Skype 고객과 사용자를 대하는 방법을 보면 이런 일이 일어나기를 거의 희망하지 않습니다.

그리고 Xamarin은 잊어버리세요. Microsoft는 자체적 으로 사용하지도 않고, 소유하고 있는 Xamarin을 사용하는 것보다 ElectronJS 프레임워크(Chromium, Node.js, JavaScript 및 CSS 기반)와 같은 단일 스레드 메모리 호깅 프레임워크를 사용합니다. 각 플랫폼에 대한 실제 네이티브 코드를 생성하는 모든 권한을 갖습니다.

@Bartolomeus-649

이제 Visual Basic 6이 출시된 지 20년이 지났고 1998년 당시의 생산성에 근접하지 않습니다.

그리고 컴퓨터와 인터넷 사용의 확산과 플랫폼의 다양성(OS/이동성/폼팩터)은 1998년만큼 낮지 않습니다.

나는 당신이 요구하는 것이 "당신의 모든 문제를 해결해 줄 사람"을 요구한다고 생각합니다. 이러한 다양성이 존재하는 이유는 여러 가지가 있습니다. 그렇지 않으면 우리 모두는 동일한 운영 체제에서 동일한 장치를 사용하게 될 것입니다. "모든 것에 대한 추상화"를 구축하는 것은 어렵고 일반적으로 가능한 가장 작은 기능 세트만 제공합니다. Xamarin은 가능한 경우 플랫폼별 API를 사용할 수 있도록 하는 최상의 접근 방식을 제공합니다. 그러나 모바일 응용 프로그램에 대한 우수한 추상화라도 생산성이 높은 데스크톱 응용 프로그램에는 도움이 되지 않을 수 있습니다.

당신이 말하고 있는 다른 요점은 일반적으로 적용 가능한 진술이 아닌 특정 작업에 적용되는 대부분의 개인적인 의견이나 관찰이라고 생각합니다.

나는 우리가 더 나은 크로스 플랫폼 경험을 하기를 희망하지만 그것이 쉽거나 시간의 시험을 견디지 못할 것이라고 생각합니다. WebAssembly 및 Electron과 같은 셸, PWA 및 친구들이 향후 5년 안에 최고의 솔루션으로 발전하더라도 20년 후에는 완전히 다른 일을 하게 될 것입니다. ).

Microsoft는 우리의 기대와 오픈 소스 UX 프레임워크에 부응했습니다. 이제 커뮤니티 프로젝트를 시작하여 다른 플랫폼으로 이식할 수 있습니다. 불행히도 MSFT는 어떤 포트에서도 작업할 계획이 없다고 명시적으로 밝혔으므로 이 작업은 커뮤니티에 맡겨진 것 같습니다.

@Richlander @karelz @AdamYoblick @llongley @kmahone

제 질문은 커뮤니티가 기존 리포지토리 내의 Linux 및 macOS 포트, 즉 별도의 분기에서 작업할 수 있는지 아니면 이러한 프로젝트를 지원하기 위해 별도의 리포지토리를 만들어야 하는지입니다. 기존 리포지토리를 사용하면 커뮤니티에서 처음부터 설정해야 하는 MSFT CI 인프라와 포트를 통합할 수 있으므로 이는 매우 중요한 결정입니다.

Xamarin.Forms/Avalonia/Platform.Uno가 요구 사항에 맞지 않는 이유가 있습니까? 플랫폼 간 XAML을 가져오려는 새로운 시도는 커뮤니티 전체에 거의 가치를 제공하지 않는 것 같습니다.

4creators가 아니라 2¢/impressions:

• Xamarin.Forms는 주로 모바일 시나리오에 중점을 두는 것 같습니다.
• Platform.Uno도 마찬가지입니다.
• 아발로니아는 아직 황금기를 맞이할 준비가 되지 않았습니다. 내가 그것을 믿고 싶어 너무 버그. (지난번에 확인하러 갔을 때 데모 앱은 현재의 안정적인 릴리스에서도 빌드되지 않았으며 자신감을 불러일으키지 않았습니다.)

여기서 WPF 또는 Winforms의 플랫폼 간 포트가 솔루션이라고 말하는 것이 아닙니다. (IMO, Winforms의 API 호환 크로스 플랫폼 포트는 애초에 좋은 아이디어도 아닙니다. WPF에 대한 언급은 없습니다.) 그러나 기존 솔루션도 데스크톱 애플리케이션 개발에 적합하지 않다고 생각합니다.

좋은 점. 그러나 우리는 다른 솔루션을 구축하는 것보다 기존 솔루션을 개선하는 데 집중해야 합니다. 이는 이전 솔루션보다 비용이 훨씬 많이 듭니다.

그런데 NoesisGUI의 문제점은 무엇입니까?

커뮤니티는 Linux 및 macOS 포트에서 작동할 수 있습니다.

@4creators 자신이 소유하고 완전히 제어할 수 있는 포크를 만듭니다.

CI 인프라

.NET Core CI 인프라는 현재 사용자 지정 Jenkins 기반 솔루션 대신 일반 Azure DevOps를 사용하는 방향으로 이동하고 있습니다. Azure DevOps에는 활용할 수 있는 오픈 소스 프로젝트에 대한 무료 제품 이 있습니다.

dotnet/winforms에 대해서만 말하기:

Winforms는 이미 AzureDevOps를 사용하고 있으며 마스터에 대한 모든 PR은 PR CI 빌드를 자동으로 실행합니다.

그러나 모든 작업은 포크에서 수행되어야 한다고 확신합니다. 우리는 사람들이 자신의 분기를 만들 수 있도록 dotnet/winforms에 대한 쓰기 액세스 권한을 부여할 계획이 없습니다. 모든 공개 기부로 인해 저장소가 상당히 오염될 것입니다. :)

그런데 NoesisGUI의 문제점은 무엇입니까?

어쩐지 네오시스GUI는 다양한 UI 프레임워크에 대한 메모에서 제외되어 다시 살펴봐야 했습니다.

나는 그것을 사용하지 않았지만 그것을 시도하려고했습니다. 내 인상은 게임 내 UI를 지원하기 위한 것이므로 도구에는 적합하지 않을 수 있습니다. (컨트롤 목록을 보면 이것은 잘못된 가정일 수 있습니다.) 게임 내 UI의 경우 우리의 요구가 미래 비용을 정당화하지 않습니다. 또한 어떤 이유로든 Nintendo Switch를 지원하지 않습니다. (분명히 그것은 진행중인 작업입니다 .)

@4creators 이 문제는 두 가지 문제의 혼동으로 인해 제목이 잘못되었다고 생각합니다.

첫째, .Net UI 프레임워크가 다른 .Net 런타임 대신 .Net Core를 사용하도록 허용 합니다. WPF는 이제 .Net Core에서 실행할 수 있으며 Xamarin.iOS/Android/Mac/GTK도 .Net Core에서 실행할 수 있습니다. Mono 또는 .Net Framework를 사용하는 것과 비교하여 성능 및 유지 관리 이점이 있습니다.

그러나 그렇게 하면 새로운 플랫폼 간 UI 프레임워크가 생성 되지 않습니다. 그리고 여기에서 참조하는 스레드와 대부분의 게시물은 새로운 플랫폼 간 UI 프레임워크를 만드는 것에 관한 것입니다. 여기서 런타임은 주요 문제가 아닙니다. 그러나 이러한 스레드는 실제 구현(대부분 기본 컨트롤을 사용하는 Xamarin.Forms 및 공통 렌더링을 사용하는 Avalonia)이 해결한 플랫폼 간 UI 구현의 실제 어려움을 해결하지 않기 때문에 매우 혼란스럽습니다.

관련 데스크톱 컨트롤(하드 아님)을 추가하여 Xamarin.Forms 데스크톱 기능을 개선하거나 원하는 경우 Avalonia를 안정적으로 만드는 데 기여하는 것이 좋습니다. 모든 새로운 플랫폼(기존 단일 플랫폼을 기반으로 하는 경우에도)은 알파 품질에 도달하는 데 수년이 걸릴 것이며 Xamarin.Forms & Avalonia에 기여하는 대신 다시 수행하는 유일한 정당성은 둘 다 수행하고 있다는 것입니다. 잘못된.

후반부에 동의합니다. 그러나 Xamarin 팀은 Mono를 .NET Core로 교체하는 것은 서로 다른 워크로드에 최적화되어 있고 중요한 통합 작업을 수행해야 하므로 실행 불가능하다고 명시적으로 말했습니다.

이 문제는 두 가지 문제의 혼동으로 인해 제목이 잘못되었다고 생각합니다.

@charlesroddie IMO, 실제로는 아닙니다. 요점은 .NET Core 플랫폼에서 사용할 수 있는 UX 프레임워크가 아니라 DotNet 생태계의 일부인 UX를 다른 부분과 공동으로 만들고 유지 관리하는 것입니다. .NET 에코시스템에 대한 MSFT의 향후 계획은 새 애플리케이션 개발에 권장되지 않는 레거시 Windows 구성 요소로 더 이상 사용되지 않는 .NET Framework 기반 .NET Core입니다. 위에 @Happypig375 로 표시된 몇 가지 이유와 모바일에서 xplat 지원을 진행하는 방법에 대한 결정이 부족하기 때문에 현재 Xamarin.Forms를 .NET Core로 이식할 계획이 없습니다. 그러나 .NET Core에 투자된 개발 노력으로 인해 MSFT에서 사용하는 미래 xplat 플랫폼은 .NET Core 기반이 될 것이라고 가정합니다.

Mono는 Linux에서도 많은 작업 부하에 대해 충분히 최적화되지 않았으며 더 이상 해당 런타임을 기반으로 개발된 주요 새 기능이 없습니다. BCL은 현재 Mono와 .NET Core 간에 공유됩니다. 이것은 미래에 Mono가 더 이상 사용되지 않을 가능성이 높다는 것을 나타냅니다.

이 가정을 바탕으로 에코시스템의 일부로 .NET Core 기반 단일 UX 플랫폼을 보유하는 것이 가치가 있다고 생각합니다. 따라서 xplat 및 기반 CLI 표준인 일부 UX 프레임워크를 요청하지 않고 DotNet 팀에서 설계 및 지원하는 .NET Core 생태계의 일부인 UX 프레임워크에 대해 문제 제목을 지정해야 합니다.

.Net Standard는 UI 다른 런타임이 문제 없이 동일한 에코시스템의 일부가 될 수 있도록 합니다. .Net Core가 다른 런타임에 비해 장점이 있지만 결국에는 가치가 떨어질 수 있지만 플랫폼 간 UI에 대한 올바른 접근 방식을 찾는 데 런타임을 연결할 필요는 없습니다. 질문을 복잡하게 만들 뿐입니다.

UX 플랫폼이 특정 런타임을 "기반으로" 한다고 말하는 것은 너무 지나칩니다. @ Happypig375 현재 Xamarin은 .Net Core로 전환할 계획이 아닙니다(대신 코드를 공유하여 Mono가 .Net Core와 더 유사해지도록 하는 계획). 그러나 WPF를 .Net Core로 옮기는 것보다 어렵지 않아야 합니다.

(BTW, .Net Standard 2.1을 지원하도록 업데이트되고 있는 Mono에 새로운 기능이 없다는 것은 사실이 아니며, 현재 웹 어셈블리 작업은 .Net Core가 아닌 Mono에서 수행되고 있습니다. 그러나 이 작업은 포팅될 수 있으므로 제쳐두고 있습니다. .Net Core로.)

WinUI 3.0 로드맵 - 귀하의 의견이 필요합니다!

이 개발 제안은 필요한 모든 구성 요소가 소스가 공개되면 새로운 xplat 가능성을 열 수 있는 것 같습니다.

그렇다면 MicrosoftUI 1.0 라고 부르는 것을 고려해야 합니다. @4creators. 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

이 문제는 이 리포지토리에서 해결되었다고 생각합니다.