Maui: UX lintas platform untuk .NET 5

Aku suka ide ini. Namun, secara praktis, itu adalah sesuatu yang lebih mungkin untuk ditangani oleh tim Xamarin.Forms.
Mungkin, tim Inti akan menyumbangkan beberapa konstruksi tingkat rendah untuk membuat kerangka kerja UX "lebih baik" (seperti yang dilakukan CoreFxLab).

Sunting: Bisakah WebAssembly juga menjadi platform yang didukung?

Aku suka gagasan itu. Saya telah melihat orang (termasuk saya) menderita dengan beberapa teknologi UI untuk berbagai lingkungan.

Saya cukup yakin di masa mendatang kita akan melihat .net core di-porting ke perangkat Android dan iOS menggunakan aplikasi Native sebagai pengganti corehost . Dengan itu, kemampuan UI akan diperlukan.

Untuk perpustakaan Gambar xplat 2D (termasuk gambar yang Dipercepat), kami memiliki Skia misalnya.

Dalam semua skenario, saya percaya XAML-Standard akan menjadi hal yang baik untuk dipindahkan untuk mencapai cara standar untuk "mendeskripsikan" UI bersama-sama dengan pedoman Desain Lancar.

Namun, saya skeptis bahwa ada rencana dari .Net Team untuk menginvestasikan waktu lebih dari sekadar membawa beberapa xplat System.Drawing.X primitif kembali...

@4creators Mungkin diskusi ini menarik bagi Anda

@ vibeeshan025 WebAssembly bukan pengganti JavaScript, jadi sebagian besar komentar Anda tidak masuk akal. Anda masih memerlukan JavaScript untuk menghubungkan WebAssembly dengan DOM. Jadi, tidak, Anda tidak bisa hanya mengkompilasi sesuatu menjadi wasm dan mengharapkannya untuk menggantikan apa pun yang Anda lakukan sebelumnya dengan JavaScript. Itu bukan cara kerjanya. Ini tidak akan menjadi teknologi UI.

Hei guys, hanya ingin menempatkan 5c saya di sini.
System.Drawing.X sangat penting untuk pengembangan .NET Core. (baru datang ke sini dari https://github.com/dotnet/corefx/issues/20325)

Pada UI - tanyakan pengembang web (front-end). Mereka menggunakan banyak trik modern seperti hot reload.
Saya pribadi suka bagaimana hal-hal berkembang di sekitar React/ReactNative. Akan luar biasa menggunakan C# untuk menulis React dan kemudian menggunakan berbagai mesin render untuk platform yang berbeda.

FWIW, Mono mengadopsi WebAssembly , jadi jika berfungsi di Mono, itu berfungsi (atau akan berfungsi) di WebAssembly. Itulah ide/pemahaman saat ini, setidaknya.

Juga, saya harus menggemakan sentimen tentang kemungkinan .NET/MSFT menyelesaikan tugas ini. Semua fokus/IQ mereka telah ditempatkan ke dalam inti/internal/kerangka kerja/just-get-it-working dan saya pikir akan seperti ini selama satu tahun atau lebih. Tapi siapa tahu, saya bisa (dengan senang hati) terkejut.

Pendapat saya tentang ini adalah bahwa beberapa upaya eksternal akan mendapatkan momentum dan mungkin dibeli oleh MSFT, ala Xamarin, tetapi lebih berfokus pada UI (sebagai lawan dari kerangka kerja/perkakas, yang merupakan kekuatan inti Xamarin IMO). Jadi, sesuatu seperti Avalonia atau Noesis , yang masing-masing menawarkan proposisi nilainya melalui sumber terbuka dan saluran berbayar. Kebetulan, keduanya adalah built-on/support Mono.

Standar Xaml telah bergerak sedikit dengan rilis Standar XAML (Pratinjau) untuk Xamarin.Forms dan pembaruan yang lama tertunda pada kemajuan proyek . Ada diskusi yang sangat menarik di PR dotnet/designs#111 tentang tujuan proyek yang tampaknya akan menguntungkan proposal ini

Silverilght adalah solusi hebat kodenya sudah ada

1. Kode silverlight open source
2. Buat itu berjalan di atas runtime inti dotnet
3. gunakan moonlight untuk distribusi linux
4. buat alternatif inti dotnet untuk "Elektron" itu akan memakan dunia (penggunaan memori lebih sedikit + peningkatan kinerja besar + kebaikan xaml)
5. compliation asli (jika suatu hari proyek corert melihat cahaya)

Menemukannya relevan- http://platform.uno

@gulshan Menarik, Proyek hebat, Apakah mendukung sebagian besar fitur UWP, Bagaimana mereka dapat mengimplementasikan serangkaian prestasi yang begitu kaya dalam waktu yang sangat singkat hanya dengan 4 kontributor.

@ vibeeshan025 mereka memiliki perusahaan yang mendanainya IIRC...

Masa depan lain yang perlu dijelajahi- HTML/CSS + .net (bukan JS/TS). Sudah dicoba di sini-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

Setelah meneliti tampaknya tcl/tk bisa menjadi opsi gui untuk semua platform. Tidak yakin apakah tcl/tk ketika di Windows memanggil hal-hal gdiplus yang sebenarnya tetapi itu mungkin merupakan opsi untuk membawa WPF dan Winforms ke Linux, Mac, Windows, Android?, iOS?, Dan mungkin formulir web? Tidak yakin apakah tcl/tk mendukung 3 yang terakhir itu. Jika ya, ini membuat GUI jauh lebih mudah dirawat dengan basis kode tunggal di atasnya.

Kemungkinan lib GUI untuk digunakan:

• TclBridge (tampaknya tidak gratis atau open source)
• yang Mono (mungkin yang terbaik mungkin)
• Elang (tidak yakin seberapa bagusnya)
• Mungkin orang lain juga.

Saya mendapat ide untuk menggunakan tcl/tk dari modul tkinner cpython.

Juga tidak yakin apakah .NET Core mendukung pemuatan sumber daya dari *.resources(compiled resx) atau bahkan dari *.resx. Jika itu terjadi, itu akan sangat bagus.

Microsoft.DesktopUI.App saat ini v3.0.0-alpha-26921-3 tersedia dengan build harian Windows .NET Core SDK . Saya ingin tahu apa yang diperlukan untuk menjalankannya di Linux di bawah beberapa lapisan terjemahan untuk GDC dan DirectX.

Perlu lebih dari sekadar UX lintas platform, itu perlu menjadi kerangka kerja pengembangan aplikasi lintas platform.
Membatasinya hanya pada UX adalah sebuah kesalahan. Setidaknya harus memiliki semua fungsi SilverLight + RIA-Services.
Saat Anda menulis sistem kustom besar untuk perusahaan besar yang akan hidup selama beberapa dekade, Anda harus tetap membuka semua opsi karena Anda tidak tahu persyaratan apa yang akan ditambahkan dalam setahun (atau dalam 10 tahun), jadi lingkungan yang tertutup dan terbatas seperti UWP tidak akan pernah dipertimbangkan, sama dengan sesuatu yang berjalan di dalam browser. Harus ada akses penuh, tidak terbatas, dan asli ke setiap fitur, API, dan layanan pada platform yang berbeda.
Dan ketika Anda mengembangkan sistem tempat Anda menulis server dan klien, maka Anda tidak ingin menggunakan REST atau semacamnya (yang dimaksudkan untuk digunakan saat Anda menulis server, dan orang lain menulis klien), alih-alih itu harus dalam semangat RIA, di mana Anda mendefinisikan API server dan kemudian secara otomatis memanggilnya dari klien menggunakan kelas dan metode (===) yang sama seperti yang ada di server. Semuanya harus diketik dengan kuat. Validasi data dimulai dengan batasan keras yang diperoleh dari bidang di server SQL (atau sumber data apa pun yang Anda gunakan), dan diperluas oleh DataAnnotations, yang disebarkan hingga ke klien secara otomatis (dengan mempertimbangkan pelokalan).

Inilah yang dibutuhkan, tidak kurang yang dapat diterima:
Buat Model Pengembangan Aplikasi Klien .NET di mana-mana

Sekarang sudah 20 tahun sejak Visual Basic 6 dirilis, dan kami sama sekali tidak mencapai produktivitas yang kami miliki pada tahun 1998.Microsoft perlu mempresentasikan visi mereka tentang bagaimana sistem kustom yang lebih besar harus dilakukan di "dunia Microsoft", dan bagaimana mereka akan mengembalikan produktivitas yang kami miliki 20 tahun yang lalu.

Microsoft perlu menyelesaikan masalah mereka dan melangkah dan menerima tanggung jawab yang mereka miliki. Microsoft perlu menyadari bahwa semua pelanggan, mitra, dan pengembang mereka yang telah banyak berinvestasi dalam teknologi MS selama beberapa dekade sangat kecewa dan kepercayaan mereka pada MS sangat rendah. MS harus mulai menghormati pelanggan, mitra, dan pengembang mereka dan membangun kembali reputasi dan rasa hormat mereka, tetapi melihat apa yang mereka lakukan sekarang dengan Skype dan bagaimana mereka memperlakukan pelanggan dan pengguna Skype mereka, saya memiliki sedikit harapan ini akan terjadi.

Dan lupakan Xamarin, Microsoft bahkan tidak menggunakannya sendiri , dan lebih memilih menggunakan kerangka kerja memori-hogging berulir tunggal seperti kerangka ElectronJS (berdasarkan Chromium, Node.js, JavaScript dan CSS), daripada menggunakan Xamarin, yang mereka miliki dan memiliki kendali penuh atas, dan yang akan menghasilkan kode asli asli untuk setiap platform.

@Bartolomeus-649

Sekarang sudah 20 tahun sejak Visual Basic 6 dirilis, dan kami sama sekali tidak mencapai produktivitas yang kami miliki pada tahun 1998.

Dan penyebaran penggunaan komputer dan internet serta keragaman platform (OS / mobilitas / faktor bentuk) tidak serendah tahun 1998.

Apa yang saya rasa Anda minta adalah "seseorang untuk menyelesaikan semua masalah Anda". Alasan keragaman ini ada banyak, atau kita semua akan menggunakan perangkat yang sama dengan sistem operasi yang sama. Membangun "abstraksi di atas segalanya" itu sulit dan biasanya hanya memberi Anda set fitur sekecil mungkin. Xamarin masih memiliki pendekatan terbaik di sini, memungkinkan Anda untuk menggunakan API khusus platform jika memungkinkan. Tetapi bahkan abstraksi yang bagus untuk aplikasi seluler mungkin tidak membantu Anda untuk aplikasi desktop dengan produktivitas tinggi.

Pada poin lain yang Anda buat, saya pikir itu sebagian besar pendapat atau pengamatan pribadi yang berlaku untuk pekerjaan spesifik Anda dan bukan pernyataan yang berlaku secara umum.

Saya berharap kami akan mendapatkan pengalaman lintas platform yang lebih baik, tetapi saya tidak berpikir itu akan mudah atau akan bertahan dalam ujian waktu. Bahkan jika WebAssembly dan cangkang mirip Elektron, PWA, dan teman-teman berevolusi menjadi solusi praktis dalam 5 tahun ke depan, kami mungkin akan melakukan sesuatu yang sama sekali berbeda dalam 20 tahun (dan kemudian kami akan mengeluh tentang betapa mudahnya hal-hal di 2018 😂 ).

Microsoft telah memenuhi harapan kami dan kerangka kerja UX open source. Kami sekarang dapat memulai proyek komunitas untuk memindahkannya ke platform lain. Sayangnya, MSFT telah secara eksplisit menyatakan bahwa mereka tidak berencana untuk bekerja pada port mana pun sehingga tampaknya pekerjaan ini diserahkan kepada komunitas.

@richlander @karelz @AdamYoblick @llongley @kmahone

Pertanyaan saya adalah apakah kami - komunitas dapat bekerja di port Linux dan macOS dalam repo yang ada yaitu di cabang terpisah atau haruskah kami membuat repo terpisah untuk mendukung proyek semacam itu? Ini adalah keputusan yang sangat penting karena menggunakan repo yang ada akan memungkinkan kami untuk mengintegrasikan port dengan infrastruktur MSFT CI yang jika tidak, harus disiapkan dari awal oleh komunitas.

Apakah ada alasan mengapa Xamarin.Forms/Avalonia/Platform.Uno tidak sesuai dengan kebutuhan Anda? Tampaknya upaya baru untuk menghadirkan XAML lintas platform membawa sedikit nilai bagi komunitas secara keseluruhan.

Bukan 4 kreator, tapi 2¢/kesan saya:

• Xamarin.Forms tampaknya sebagian besar fokus pada skenario seluler.
• Sama untuk Platform.Uno
• Avalonia belum siap untuk prime time. Terlalu buggy bagi saya untuk mau mempercayainya. (Terakhir kali saya memeriksanya, aplikasi demo bahkan tidak akan membangun rilis stabil saat ini, tidak benar-benar menginspirasi kepercayaan.)

Saya tidak mengatakan port lintas platform WPF atau Winforms adalah solusinya di sini. (Port lintas platform Winforms yang kompatibel dengan API bahkan bukan ide yang bagus, IMO. Tidak ada komentar tentang WPF.) Namun, saya rasa solusi yang ada juga tidak cocok untuk pengembangan aplikasi desktop.

Poin bagus. Namun, kita harus fokus pada peningkatan solusi yang ada daripada membangun solusi lain, yang harganya jauh lebih mahal daripada solusi sebelumnya.

Omong-omong, adakah poin menyakitkan tentang NoesisGUI?

komunitas dapat bekerja di port Linux dan macOS

@4creators Buat garpu yang Anda miliki dan kendalikan penuh.

infrastruktur CI

Infrastruktur .NET Core CI sedang bergerak menuju penggunaan Azure DevOps reguler alih-alih solusi berbasis Jenkins kustom saat ini. Azure DevOps memiliki penawaran gratis untuk proyek sumber terbuka yang dapat Anda manfaatkan.

Berbicara hanya untuk dotnet/winforms:

Winforms sudah menggunakan AzureDevOps, dan PR apa pun yang menjadi master akan menjalankan build PR CI secara otomatis.

Namun, saya cukup yakin pekerjaan apa pun harus dilakukan dengan garpu. Kami tidak berencana memberikan akses tulis ke dotnet/winforms hanya agar orang dapat membuat cabang mereka sendiri. Dengan semua kontribusi publik, itu akan sedikit mencemari repo kami. :)

Omong-omong, adakah poin menyakitkan tentang NoesisGUI?

Entah bagaimana NeosisGUI terhindar dari catatan saya, saya menyimpan berbagai kerangka UI, jadi saya harus melihatnya lagi.

Saya belum menggunakannya, meskipun saya bermaksud mencobanya. Kesan saya adalah ini dimaksudkan untuk mendukung UI dalam game, jadi mungkin tidak cocok untuk alat. (Meskipun melihat daftar kontrol, ini mungkin asumsi yang buruk.) Untuk UI dalam game, kebutuhan kita tidak membenarkan biaya di masa mendatang. Itu juga tidak mendukung Nintendo Switch karena alasan apa pun. (Meskipun tampaknya ini adalah pekerjaan yang sedang berlangsung .)

@4creators Saya pikir masalah ini salah judul, karena kebingungan dua masalah.

Pertama, mengizinkan kerangka kerja .Net UI untuk menggunakan .Net Core alih-alih runtime .Net lainnya . WPF dapat berjalan di .Net Core sekarang, dan mereka dapat membuat Xamarin.iOS/Android/Mac/GTK berjalan di .Net Core juga. Ini memiliki manfaat kinerja dan pemeliharaan dibandingkan dengan menggunakan Mono atau .Net Framework.

Namun melakukan tidak membuat kerangka UI lintas platform baru . Dan utas yang Anda rujuk dan sebagian besar posting di sini adalah tentang membuat kerangka kerja UI lintas platform baru. Runtime bukanlah masalah utama di sini. Namun, utas ini sangat membingungkan karena tidak mengatasi kesulitan aktual dalam mengimplementasikan UI lintas platform, yang telah ditangani oleh implementasi aktual (Xamarin.Forms sebagian besar menggunakan kontrol asli, dan Avalonia menggunakan rendering umum).

Lebih baik bekerja untuk meningkatkan kemampuan desktop Xamarin.Forms dengan menambahkan kontrol desktop yang relevan (tidak sulit), atau berkontribusi untuk membuat Avalonia stabil jika Anda mau. Setiap platform baru (bahkan jika itu didasarkan pada platform tunggal yang ada) akan membutuhkan waktu bertahun-tahun untuk mencapai kualitas alfa, dan satu-satunya pembenaran untuk mengulang Xamarin.Forms & Avalonia daripada berkontribusi pada mereka adalah bahwa mereka berdua melakukannya salah.

Saya setuju pada bagian terakhir. Namun, tim Xamarin secara eksplisit mengatakan bahwa mengganti Mono dengan .NET Core tidak mungkin karena dioptimalkan untuk beban kerja yang berbeda dan pekerjaan integrasi nontrivial yang signifikan perlu dilakukan.

Saya pikir masalah ini salah judul, karena kebingungan dua masalah.

@charlesroddie IMO, tidak juga. Intinya bukan untuk memiliki beberapa kerangka kerja UX yang tersedia di platform .NET Core melainkan UX yang merupakan bagian dari ekosistem DotNet yang dibuat dan dipelihara bersama dengan bagian lain. Rencana masa depan MSFT untuk ekosistem .NET berbasis .NET Core dengan .NET Framework tidak digunakan lagi sebagai komponen Windows lama yang tidak direkomendasikan untuk pengembangan aplikasi baru. Saat ini tidak ada rencana untuk mem-port Xamarin.Forms ke .NET Core dengan beberapa alasan yang ditunjukkan di atas oleh @Happypig375 dan alasan lainnya adalah kurangnya keputusan tentang bagaimana melanjutkan dukungan xplat di ponsel. Namun, saya berasumsi bahwa karena upaya pengembangan yang diinvestasikan dalam .NET Core, platform xplat masa depan yang digunakan oleh MSFT akan berbasis .NET Core.

Mono tidak cukup dioptimalkan untuk banyak beban kerja bahkan di Linux dan tidak ada fitur baru utama yang dikembangkan di atas runtime itu lagi. BCL saat ini digunakan bersama antara Mono dan .NET Core. Ini menunjukkan kemungkinan besar penghentian Mono di masa depan.

Berdasarkan asumsi ini, saya pikir layak untuk memiliki satu platform UX berdasarkan .NET Core sebagai bagian dari ekosistemnya. Oleh karena itu, judul masalah persis seperti yang seharusnya karena saya tidak meminta beberapa kerangka kerja UX yang merupakan standar xplat dan CLI berbasis tetapi untuk kerangka kerja UX yang merupakan bagian dari ekosistem .NET Core yang dirancang dan didukung oleh tim DotNet.

.Net Standard memastikan bahwa runtime UI yang berbeda dapat menjadi bagian dari ekosistem yang sama tanpa masalah. Meskipun .Net Core memiliki keunggulan dibandingkan runtime lain, yang pada akhirnya dapat disusutkan, tidak perlu menautkan runtime dengan menemukan pendekatan yang tepat untuk ui lintas platform. Itu hanya memperumit pertanyaan.

Terlalu jauh untuk mengatakan bahwa platform UX "berdasarkan" runtime tertentu. @Happypig375 Saat ini Xamarin tidak berencana untuk beralih ke .Net Core (rencananya adalah membiarkan Mono menjadi lebih mirip dengan .Net Core dengan berbagi kode). Tapi itu seharusnya tidak lebih sulit daripada memindahkan WPF ke .Net Core.

(BTW, itu tidak benar bahwa Mono tidak memiliki fitur baru karena sedang diperbarui untuk mendukung .Net Standard 2.1, dan pekerjaan saat ini di webassembly sedang dilakukan di Mono daripada .Net Core. Tapi itu sampingan karena pekerjaan ini dapat di-porting ke .Net Core.)

Peta jalan WinUI 3.0 - kami membutuhkan masukan Anda!

Tampaknya proposal pengembangan ini dapat membuka kemungkinan xplat baru setelah semua komponen yang diperlukan bersumber terbuka.

Mereka harus mempertimbangkan untuk menyebutnya MicrosoftUI 1.0 jika itu masalahnya, @4creators. 😆.

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

Saya percaya masalah ini telah diatasi oleh repo ini.