Saya pikir Xamarin akan bergabung menjadi .NET 5;
Akan sangat bagus jika mereka mengadopsi UWP XAML sebagai standar dan bekerja dari sana, Microsoft dan UNO menjadikannya yang terbaik untuk Desktop, Seluler, Browser Web (Azure) dan IoT.
Mereka bisa menyebutnya
UWP vNext (berbasis WinUI)/ Silverlight 6 (UNO)

Saya pikir upaya Blazor adalah langkah pertama membawa .NET secara resmi ke WebBrowser, menggunakan rendering default saat ini, yaitu. HTML DOM
Tapi saya percaya bahwa segera mereka bahkan dapat menawarkan Mesin rendering lain, pelengkap ringan untuk WinUI, sesuatu yang mengorbit Silverlight, Platform UNO dan Xamarin... seperti Flutter / WPF

Akan sangat bagus jika mereka mengadopsi UWP XAML sebagai standar dan bekerja dari sana

Semua yang kalian inginkan sudah terjadi dengan Uno. MS akan bijaksana untuk membeli orang-orang itu dan kemudian mempekerjakan mereka untuk menggembalakan sepanjang pengembangan akhir Uno.

Ini mungkin tempat yang salah untuk meminta fitur seperti ini. Karena saya ingin menyetujui semua yang ada dalam permintaan ini, saya percaya tim WinUI dan banyak pengembang senior di komunitas Windows menganggap WinUI didefinisikan dengan sangat sempit.

Di dunia yang ideal, WinUI hanya akan seperti Desain Material. Akan ada cara untuk memilikinya di platform apa pun dengan semua jenis perpustakaan yang mengimplementasikannya. Namun, WinUI bukan bahasa desain, dan juga bukan Desain Lancar. Microsoft tidak berada di ruang model telah membuat penawaran UI mereka di belakang persaingan cukup banyak.

WinUI adalah perpustakaan UI untuk aplikasi Windows, dan ini sejelas yang didapat. Bahasa desain tidak terpisah dari implementasi, dan implementasinya eksklusif platform karena fitur seperti komposisi sangat bergantung pada ketergantungan platform. Ini buruk dalam perspektif pengembang seluler/lintas platform, tetapi upaya di sini benar-benar untuk aplikasi Windows.

Ini juga mengapa Platform Uno tidak pernah bisa benar-benar menjadi WinUI di mana-mana, kecuali mereka mem-port DX 11 ke setiap platform.

Saya akan menyarankan Anda untuk melihat Comet (kerangka kerja dev lintas platform berdasarkan .Net). Ini dalam tahap awal, tetapi konsepnya tidak berbeda dengan Flutter. Itu juga menggunakan Skia (sebagai opsi) untuk menggambar UI dengan pola UI yang dapat dikomposisi/deklaratif, sehingga pengembang dapat mengimplementasikan perpustakaan UI seperti Desain Material dan membuatnya terlihat sama di setiap platform.

Tidak, seharusnya tidak lintas platform. Ini disebut Windows UI karena suatu alasan. Mari kita mulai dengan sistem UI yang berfungsi di semua Windows (platform dan bahasa) hei? Itu bahkan belum tercapai. Kami masih terbagi antara .net framework, .net core, uwp, dan kemudian cerita C++, yang setidaknya memiliki uwp, tetapi tidak ada pengembang game yang menggunakannya, karena UWP/WinRT masih memiliki beberapa masalah - distribusi, bilah tugas paksa & popup bilah judul ketika dalam layar penuh (ya).

Memikirkan lintas platform akan menjadi pemborosan sumber daya yang sangat besar. Lakukan dengan benar di Windows terlebih dahulu. Dan keluarkan .net 5 dari pintu, dan perbaiki UWP dan cerita windowing, dan letakkan DirectX ke C#. Dan perbaiki GC. Masih banyak yang harus dilakukan dalam skenario sempit, hanya di Windows.

Dan untuk OPnya.

• UWP bersifat universal. Mengatakan itu tidak universal adalah klaim yang salah (mereka tidak pernah bermaksud menargetkan Android, syukurlah). Janji asli telah disampaikan. Semua perangkat Windows menjalankan UWP. Windows Mobile adalah OS yang terpisah, mereka harus menyingkirkannya. Semua platform Windows baru akan menjadi Windows (10 atau 10X). Akhirnya berdasarkan CoreOS saya kira. Dan mereka semua akan menjalankan aplikasi Windows. Hanya karena kami tidak memiliki ponsel Windows saat ini adalah insidental. Kami memiliki semua jenis perangkat lainnya. Dan kita akan segera memiliki Neo dan Duo.

• Pembatasan kotak pasir - Ini adalah hal yang baik. Akses seluruh sistem gaya Win32 harus dihilangkan secara umum. Jika Anda memiliki persyaratan khusus, Anda harus mengajukan persyaratan Anda sehingga kami dapat mendiskusikan bagaimana hal itu dapat/harus dilakukan di dalam wadah UWP dan jika Anda diizinkan untuk melakukannya dengan cara yang Anda sarankan. Dan cari tahu apakah UWP membutuhkan fitur itu. Karena saya dapat memikirkan beberapa aplikasi canggih yang dapat ditulis dalam UWP tidak ada masalah. Saya dapat memiliki program! Anda perlu mendiskusikan secara spesifik.

• .net asli sedang diganti dan cerita distribusi akan berubah dengan .net 5. Saya pikir adil untuk mengatakan bahwa Microsoft sedang mengerjakan ini. Pasti mereka tahu masalah-masalah itu. Tetapi Anda harus mengajukan masalah khusus untuk menargetkan masalah mendasar yang sebenarnya di sini.

• "Jangan pasangkan WinUI ke DirectX" - WTF? Ini benar-benar harus digabungkan dengan DirectX, yang merupakan tumpukan grafis Windows asli. Tolong jangan mempertimbangkan hal lain. Saya benar-benar tidak ingin menemukan permukaan rendering OpenGL di bawah tenda. Itu akan merusak kompatibilitas dan menyebabkan segala macam kekacauan.

@Gavin-Williams

Luar biasa, mari lakukan peningkatan yang sedikit evolusioner melalui WPF.

UWP bersifat universal

"Semua perangkat Windows menjalankan UWP" tidak berarti apa-apa tanpa seluler. HoloLens adalah ceruk, Surface Hub adalah ceruk, Windows 10 IoT Core adalah lelucon.

Ini benar-benar harus digabungkan dengan DirectX

Sebagai pengembang, hard coupling membuat saya merinding. Apakah ada alasan utama mengapa tumpukan grafik tidak dapat dipertukarkan?

Ini disebut "modularitas". Microsoft selalu berjuang dengan itu.

Pembatasan kotak pasir adalah hal yang baik

Ya, selama mereka tidak terlalu membatasi jangkauan aplikasi yang dapat dibangun. Sudahkah Anda mencoba mengubah ukuran partisi dari UWP?

Saya pikir perlu disebutkan dan diingatkan bahwa Google sedang mengembangkan Flutter dan mereka tidak menyebutnya GoogleUI atau AndroidUI. Ini berfungsi di mana saja -- bahkan di web dan desktop. Saya menyatakan ini karena tampaknya ada kecenderungan untuk "membuatnya berfungsi di Windows" tetapi jika ada penawaran kompetitif lain yang lebih murah, lebih cepat, lebih mudah digunakan, DAN berfungsi di Windows + yang lainnya ... apa yang akan pengembang ( dan pasar yang sesuai) pilih? Saya dapat memberi tahu Anda sebagai pemilik usaha kecil bahwa saya tahu di mana saya menempatkan investasi saya dengan dua pilihan.

Memindahkan DirectX ke platform lain tampaknya sangat berhasil, mungkin solusinya adalah menggunakan OpenGL atau Vulkan alih-alih DirectX

@Gavin-Williams, saya tidak tahu apakah Anda sudah familiar dengan UWP, tetapi ketika Anda membangun/mendistribusikan Anda menargetkan versi tertentu (atau rentang versi) Windows. Ide itu benar-benar digabungkan, dan salah satu alasan mengapa UWP tidak menjadi mainstream seperti yang dilakukan WPF.
@nerocui seluruh tujuan bahasa UI adalah untuk memisahkan desain UI dari gambar mentah di layar. Itu sebabnya Anda melihat HTML dapat dirender dalam ARM/x64/x64.

XAML menyediakan abstraksi yang luar biasa dari primitif/komposisi/animasi UI, permintaan tersebut sangat masuk akal karena biaya pengembangan dan jangkauan platform.

Saya dengan hormat tidak setuju dengan @SuperJMN. Tentu saja, UWP belum mencapai paritas fitur dengan WPF. Terlepas dari keterbatasannya sebagai kerangka kerja untuk membangun perkakas tingkat kernel, untuk hampir setiap tugas pengembangan perangkat lunak lainnya, dengan kemampuan yang tepat yang ditentukan dalam manifes aplikasi, Anda memiliki pengalaman pengguna yang jauh lebih baik dari berbagai perspektif (keamanan, kemudahan penerapan, pemasangan/pencopotan pemasangan pengalaman, dll). Kotak pasir keamanan UWP adalah fitur penting (penting). Dalam banyak hal, UWP sekarang jauh di depan WPF.

Kompiler UWP .Net menghilangkan kebutuhan akan kebingungan kode dan ketidakstabilan yang dapat ditimbulkannya pada WPF. Kinerja memiliki prospek untuk meningkat dari waktu ke waktu tanpa perubahan kode karena kompiler ditingkatkan. UWP sendiri memiliki desain yang jauh lebih baik dalam hal memanfaatkan DirectX dan sumber daya tingkat sistem lainnya. Ini juga memiliki keuntungan besar dibandingkan WPF ketika berintegrasi dengan bahasa lain, khususnya C++. Mengintegrasikan komponen C++ kinerja tinggi dengan C# adalah hal yang sepele di bawah UWP. Akses ke permukaan DirectX juga jauh lebih baik.

Lubang yang tersisa di UWP dapat dengan mudah dipasang. Saya berpendapat bahwa masalah yang lebih besar adalah kegagalan Microsoft dalam mencapai tingkat kualitas yang terkait dengan WPF. WPF baru saja bekerja. Microsoft juga gagal mengenali pentingnya persyaratan LOB seperti Data Grid, INotifyDataErrorInfo, kontrol yang menampilkan status validasi, dan DB yang kuat di luar kotak. Sebagian besar telah ditangani, tetapi butuh waktu terlalu lama. Daerah non-persegi panjang masih belum ada.

Kegagalan kritis lainnya terletak pada pengembang WPF tertentu yang telah memilih untuk menjauh dari UWP. Adopsi sangat penting untuk membangun momentum. Namun, kisah adopsi dapat dimengerti mengingat berapa kali Microsoft telah gagal dalam inisiatifnya. Jelas sekali lagi Microsoft mengoceh. Menghidupkan kembali WPF dengan mengizinkannya menyambungkan ke layanan UWP UI tampak keren di permukaan, tetapi itu mengalihkan perhatian dari membuat UWP solid.

Saya sepenuhnya setuju dengan pernyataan @SuperJMN bahwa pengembang telah kehilangan harapan Microsoft akan melakukan hal yang benar. Hal yang benar memang berbeda tergantung jenis perangkat lunak yang Anda buat. Jika itu adalah aplikasi LOB berkinerja tinggi yang perlu dibuat dengan cepat dan menunjukkan serangkaian kemampuan yang luas sekaligus aman dan mudah dipasang, UWP sebagian besar ada kecuali dalam hal kualitas. Kesenjangan kualitas itulah yang membunuh UWP lebih dari apa pun.

HTML+JS adalah solusi lintas platform saat ini. Kita tidak perlu menemukan kembali. Memiliki mesin rendering XAML berkinerja tinggi di iOS dan Android lebih masuk akal jika tujuannya adalah untuk membuat XAML lebih portabel.

Saya sangat setuju bahwa WinUI harus bertujuan untuk menjadi lintas platform di masa depan. Berikut adalah beberapa pemikiran lebih lanjut.

Prioritas langsung

Saya setuju dengan beberapa komentar bahwa prioritas utama harus memastikan WinUI 3 bekerja pada Windows dengan integrasi .Net 5 dan bug telah diperbaiki. Namun, jika belum terlambat, ketika membuat keputusan arsitektur, tujuan menjadi lintas platform di masa depan harus dipertimbangkan.

Mengapa WinUI harus lintas platform

Ada alasan yang jelas dan paling penting - pengembang ingin menargetkan audiens sebanyak mungkin tanpa menulis ulang kode dll, dan C# (atau C++ saya kira)/XAML adalah kombinasi yang bagus. Tanpa cerita lintas platform, mereka akan pindah ke teknologi lain seperti Flutter.

Alasan lainnya adalah untuk memastikan bahwa WinUI terus didukung oleh Microsoft. Microsoft kemungkinan hanya akan terus mendukung WinUI jika aplikasi mereka sendiri menggunakannya. Mereka semakin fokus membuat aplikasi mereka sendiri lintas platform. Memang benar bahwa beberapa kerangka kerja lintas platform seperti React Native dan Xamarin akan menggunakan WinUI di bawahnya, tetapi apa yang terjadi jika kerangka kerja lain seperti Flutter atau rendering berbasis browser menang? Kemudian WinUI akan menjadi berlebihan dan akan masuk ke mode pemeliharaan seperti WPF.

Bagaimana seharusnya lintas platform diimplementasikan

Meskipun Uno adalah proyek yang hebat, menurut saya lebih masuk akal untuk membuat render (dan input) lapisan lintas platform dan membangun di atasnya, yang dilakukan Flutter dan AvaloniaUI, daripada membungkus kontrol asli. Ada beberapa keuntungan dari pendekatan membuat render dan lapisan input lintas platform. Tampak bagi saya bahwa permukaan API dari lapisan render dan input lebih kecil daripada kontrol (tapi saya kira itu tergantung pada apakah Anda membangun kontrol di atas beberapa yang dasar, dll). Kedua, jika Anda mengandalkan membungkus kontrol asli maka Anda berada di bawah kekuasaan platform. Jika mereka mengubah API mereka, Anda harus mengubah milik Anda atau menerapkan solusi. Jika Anda tidak melakukan ini dengan cukup cepat setelah penghentian, kerangka kerja Anda akan rusak. Jika Anda ingin menambahkan fitur baru ke kontrol, Anda mungkin harus mengimplementasikannya untuk setiap platform. Anda tidak dapat benar-benar memiliki 'visi' tentang bagaimana Anda ingin kerangka kerja Anda berkembang karena Anda terikat dengan kerangka kerja platform. Juga membutuhkan devs untuk menguji pada setiap platform sepanjang waktu karena tampilan dan perilaku kontrol berbeda. Juga, akan sulit/tidak mungkin untuk mengimplementasikan fitur yang lebih kuat seperti lapisan komposisi. Membuat lapisan render lintas platform menyelesaikan semua masalah ini, dan jika Anda menginginkan tampilan yang berbeda pada setiap platform, Anda dapat menambahkan gaya yang berbeda. (Saya akui bahwa, beberapa perilaku, Anda akan tetap berbeda pada platform yang berbeda, seperti menggulir di Mac!).

Karena WinUI saat ini memisahkan kontrol dan membuat dan memasukkan lapisan dari platform, tampaknya dalam posisi yang unik untuk melakukan ini.

Salah satu cara untuk mengabstraksi lapisan render adalah dengan menggunakan Skia. Namun, saya tidak ingin kinerja menderita dengan memaksa abstraksi ini. Saya memiliki saran alternatif untuk melihat untuk mengabstraksi lapisan render, yang merupakan proposal C++ untuk grafik 2D - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . Mereka jelas telah melakukan banyak pekerjaan ke permukaan API dan tampaknya cukup komprehensif. Mereka berpendapat bahwa 'masalah' grafik 2D pada dasarnya telah diselesaikan bertahun-tahun yang lalu dan saya harus setuju dengan mereka bahwa permukaan API mereka tampaknya cukup lengkap. Ada banyak orang yang menentang proposal ini, tetapi meskipun tidak diterima, saya pikir permukaan API dapat digunakan. Jika Anda menulis back-end Direct2D untuk permukaan API ini, maka jika proposal diterima, itu akan menyelamatkan tim MSVC dari keharusan menulisnya. Mungkin tim WinUI dapat menggunakan ini sebagai pembenaran untuk diizinkan mengerjakannya atau menambahkan beberapa anggota tim tambahan. Juga, mungkin penulis makalah akan bersedia membantu. Anda dapat menulis back-end untuk platform lain menggunakan Skia atau sesuatu dan jika proposal akhirnya diterima, maka beralihlah ke implementasi asli saat dibuat.

Akhirnya, melihat lebih jauh ke masa depan, saya ingin menyebutkan WASI - https://wasi.dev/ . Ini tampaknya berfokus pada pemrograman sistem untuk saat ini, tetapi mungkin memiliki potensi untuk berubah menjadi kerangka kerja aplikasi lintas platform yang lengkap (memiliki lintas platform dan keamanan bawaan), dengan proposal C++ di atas mungkin menyediakan kandidat alami untuk API lapisan rendering. (Ini mungkin sangat jauh sekalipun).

Melihat buktinya, orang-orang seperti @SuperJMN memiliki banyak kredibilitas mengingat konten repositori mereka. Saya dapat melihat @SuperJMN mungkin menyerah pada UWP saat masih matang (dapat dimengerti). Microsoft sebaiknya meninjau repositori orang-orang yang berkomentar di sini. Beberapa suara tidak terlalu kredibel berdasarkan karya yang mereka hadirkan kepada dunia.

@Noemata Saya dulunya adalah penggemar berat XAML+MVVM. Saya telah bekerja dengannya di Silverlight, WPF, WindowsPhone, Metro (WinRT). Saya terbakar ketika datang ke UWP dan Xamarin ...

Sulit untuk melihat apa yang membedakan iterasi ini vs semua waktu lain saya telah melihat tumpukan XAML baru.

Microsoft telah mengeluarkan beberapa contoh aplikasi UWP yang fantastis. Mereka benar-benar menampilkan dengan baik apa yang mungkin.

Berikut sebagian daftarnya:

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

Masih banyak lagi contoh yang bagus. Tidak ada yang dibangun dengan cara yang mudah dirancang ulang atau terstruktur sehingga sampelnya kohesif dengan karya lain.

Saya tidak ingat banyak upaya dengan sampel WPF yang sesuai. Ini sebagian besar baik.

Masalah? Butuh waktu terlalu lama untuk sampai ke tempat kita sekarang dengan UWP dan XAML. Dan sekarang pesan itu sekali lagi kacau. Seandainya Microsoft hanya menyediakan templat proyek yang layak dengan Visual Studio ketika UWP pertama kali dirilis, kami tidak akan terlalu negatif tentang UWP. Untuk template VS terbaik, Anda harus pergi ke sini:

https://github.com/microsoft/windowsTemplateStudio

Tidak benar-benar out of the box meskipun merupakan kumpulan blok bangunan yang sangat fleksibel dan lengkap untuk aplikasi UWP. Bagaimana Anda menemukan semua ini? Tidak tahu. Pergi berburu harta karun untuk melakukan pekerjaan Anda tidak membangun kepercayaan diri. Tim Kantor yang menolak untuk mengadopsi WinRT tidak membantu. Mereka mendorong banyak hal yang masuk ke OS terlepas dari jangkauan lengan teoritis mereka. Lemparkan masalah kualitas, bug, kegagalan Windows Phone dan investasi yang tidak konsisten ditambah pengiriman pesan dan inilah kami.

Microsoft telah mengeluarkan beberapa contoh aplikasi UWP yang fantastis. Mereka benar-benar menampilkan dengan baik apa yang mungkin.

@Noemata Saya setuju, mereka sampel yang sangat keren. Tetapi mengembangkan aplikasi yang kompleks itu gila, menggunakan UWP. Itu pasti mungkin, tapi itu jauh lebih sulit. Ya, saya merindukan saat-saat "hanya berfungsi" WPF.

Salah satu hal pertama yang harus diberikan MS sebagai sampel adalah aplikasi UWP sederhana yang dapat Anda publikasikan di luar toko MS (dan ya, itu tidak semudah yang Anda pikirkan)

Hal lain yang tidak cocok dengan saya adalah bahwa UWP dianggap dengan "mobile first" dalam pikiran, membuang pengalaman Desktop yang tepat.

Perbaiki saya jika saya salah, tetapi sebagian besar pengembang menggunakan UWP untuk mengembangkan aplikasi Desktop, dan UI tidak cocok dengan itu. Hal pertama yang terlintas dalam pikiran adalah scrollbar - yang sejak awal dioptimalkan untuk touchpad. Tetapi untuk pengguna desktop, pengalaman gulir sangat buruk (catatan tambahan: Saya pikir tim WinUI sedang memperbaikinya). Saya sudah cukup banyak mencari di Google untuk menemukan solusi yang akan membuat bilah gulir "normal" lagi - sungguh gila bahwa saya tidak bisa memanggil fungsi API untuk melakukan itu.

Sama, tombol radio/kotak kombo memiliki ukuran minimum yang juga dioptimalkan untuk seluler. Cukup mengatur Lebar tombol radio diabaikan, Anda sebenarnya perlu mengatur "MinWidth=0" agar diperhitungkan.

Dan warna tombol teksnya putih, lalu hitam pada fokus -- ada apa dengan itu? Dan tombol teks memiliki "x" yang dapat Anda gunakan untuk menghapusnya - itu touchpad - mengapa saya memilikinya di sana ketika tidak ada touchpad?

Kotak teks default telah mengaktifkan ejaan -- mengapa saya menginginkannya?

Ada masalah lain, tetapi saya telah mengatasinya. Tetapi masalah terbesar adalah hal-hal yang seharusnya memakan waktu 10 menit, biasanya memakan waktu 2 jam atau lebih. Saya baru saja kehilangan kemampuan untuk memperkirakan - setiap kali saya mengatakan sesuatu akan memakan waktu setengah hari, itu akan memakan waktu 2-3 hari.

Salam semuanya,
karena ini adalah masalah diskusi umum dan saya tidak tahu di mana lagi untuk menempatkan keinginan / permintaan fitur UWP saya ..... Saya mengambil kesempatan di utas ini:

• Dukungan yang lebih baik untuk mengintegrasikan aplikasi uwp ke dalam menu konteks windows explorer
  
  
  
  • Tolong dukung kami di sini https://aka.ms/AA6rmrk
  
  
• Ekstensi Markup UWP tidak ada IServiceProvider , dan elemen itu sendiri di mana Ekstensi Markup digunakan
• Pemicu Gaya UWP hilang
• Masalah templat data implisit UWP. Lihat contohnya di sini
• tidak ada pencetakan otomatis yang mungkin tanpa interaksi pengguna (hanya berfungsi untuk POS) lihat di sini

Semua fitur atau masalah di atas telah diatasi pada suara pengguna yang sekarang ditinggalkan. Adakah yang tahu apa yang terjadi dengan masalah-masalah itu? Haruskah kita membuatnya ulang di feedbackhub?

Suka ungkapan "Pengembang yang Terlupakan". Saya tahu banyak dari mereka yang berbakat, berpengalaman, bersemangat tentang teknologi. Mereka adalah pengembang .Net veteran. Saya yakin mereka, secara umum, dapat membuat aplikasi yang lebih baik daripada banyak anak yang berkembang pesat dalam pengembangan aplikasi untuk iOS dan Android.
Jika WinUI dapat memberikan jalan yang menyenangkan dan kuat bagi mereka untuk memanfaatkan pengalaman luas mereka di C# + .Net + Xaml untuk membuat aplikasi untuk Windows, Android, iOS dan Web, banyak yang akan melompat dan dunia akan mendapatkan keuntungan dari high- aplikasi berkualitas.
Platform WinUI + Uno bisa menjadi panggilan pamungkas.

Ekstensi Markup UWP tidak memiliki IServiceProvider, dan elemen itu sendiri di mana Ekstensi Markup digunakan

Membuat Anda tercakup di sini @mfe- !

Membuat Anda tercakup di sini @mfe- !

@Mike-EE Wow, itu luar biasa! Saya ingat mengalami ini ketika saya ingin mem-port CalcBinding ke UWP. Apa yang akhirnya saya lakukan adalah solusi di mana saya menambahkan bidang hanya-baca dalam model tampilan.

"tulis sekali, jalankan di mana-mana".

Microsoft pindah dari ini beberapa waktu lalu.

Kerja bagus semua KITA TERKENAL! 😅.

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

Pengembang yang Terlupakan diam atau diabaikan begitu saja

Suka ungkapan "Pengembang yang Terlupakan".

Mari berorganisasi dengan nama itu! 💪.

Saya hanya berharap kerangka UI lintas platform dikembangkan dan didukung oleh Microsoft. Tidak ada apa pun untuk ekosistem .NET di luar sana kecuali _Uno Platform_ dan _Xamarin.Forms_ (jika mereka masih bekerja untuk menargetkan desktop).

Dan bahkan jika saya memutuskan untuk menulis aplikasi bisnis khusus Windows dari awal, saya tidak percaya bahwa Microsoft berkomitmen penuh pada UWP. Perbaiki saya jika saya salah tetapi bukankah mereka meninggalkan aplikasi Office UWP demi Office Online PWA? Jika MS membuang kerangka kerja pihak pertama mereka sendiri, lalu mengapa saya harus percaya pada UWP? _batuk Silverlight_

Untungnya WPF belum ditinggalkan. Tapi itu hanya menambah keraguan saya.

Kerja bagus semua KITA TERKENAL! 😅.

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

Holly

Super! Mari kita kembangkan ke jurnal besar lainnya, situs web, dll

Bagi mereka yang mencari solusi lintas platform untuk mengembangkan aplikasi, Anda tidak perlu mencari lebih jauh dari Unity:

https://unity.com/

Seperti semua solusi semacam itu, Anda berakhir dengan kerangka kerja yang mencakup sistem operasi mini. Java adalah sistem operasi yang secara cerdik menyamar sebagai bahasa pemrograman.

Peramban modern sekarang menjadi OS mini. Saya pikir kita sudah cukup dengan ini. WinUI/UWP seharusnya menjadi UI asli untuk Windows 10 dan seterusnya. Mungkin masuk akal untuk memiliki mesin XAML yang berjalan di lebih banyak tempat. Saya tidak yakin itu akan terbang melawan angin kepala hal-hal seperti Unity. Saya lebih suka melihat UWP yang dipoles dan berkualitas tinggi sebelum Microsoft mati dan mulai menciptakan kembali Silverlight sehingga kami dapat meng-host XAML di platform lain. Kita semua tahu seberapa baik itu berhasil. Jika Anda belum melihat Unity, Anda melewatkannya. Yang mengatakan, bersiaplah untuk melakukan banyak pengkodean dan bahkan lebih banyak debug.

Minggu depan saya akan merilis satu set Template VS untuk UWP yang memungkinkan Anda membuat aplikasi dalam hitungan detik. Ini telah digunakan untuk proyek "internal". Ini akan membuktikan bahwa UWP dapat menjadi kerangka kerja RAD di luar kotak jika hanya VS yang memiliki blok bangunan yang tepat.

Minggu depan saya akan merilis satu set Template VS untuk UWP yang memungkinkan Anda membuat aplikasi dalam hitungan detik. Ini telah digunakan untuk proyek "internal". Ini akan membuktikan bahwa UWP dapat menjadi kerangka kerja RAD di luar kotak jika hanya VS yang memiliki blok bangunan yang tepat.

@Noemata Kedengarannya keren! Saya cukup penasaran!

Jika Anda semua menginginkan kerangka UI lintas platform berbasis .Net yang dapat beradaptasi dengan bahasa desain apa pun. Tidak terlihat lagi, Komet itu.

https://github.com/Clancey/Comet

Jika Anda memiliki waktu luang, berkontribusilah karena masih dalam tahap awal.
Comet pada dasarnya menargetkan semua platform yang ada, dan ini memberi Anda pilihan untuk menargetkan kontrol asli di setiap platform atau menggunakan Skia untuk menggambar semuanya sehingga semuanya konsisten (persis bagaimana Flutter melakukannya).

Ini menggunakan UI deklaratif dan pola MVU. Ini dikembangkan oleh James Clancey, Arsitek Manajer Program Utama di Microsoft. Meskipun belum didukung secara resmi, tetapi dengan traksi komunitas yang cukup, bisa.

Di Comet, UI hanyalah sebuah perpustakaan, jadi Anda (atau mungkin Microsoft bisa) dapat mengembangkan perpustakaan WinUI seperti halnya Comet memiliki perpustakaan Desain Material.

Jika Anda semua menginginkan kerangka UI lintas platform berbasis .Net yang dapat beradaptasi dengan bahasa desain apa pun. Tidak terlihat lagi, Komet itu.

@nerocui kedengarannya keren, tapi setidaknya dari melihatnya, tidak ada desainer XAML. Membangun UI yang kompleks mungkin gila pada tahap saat ini. Tapi memang terlihat menjanjikan.

Jika Anda semua menginginkan kerangka UI lintas platform berbasis .Net yang dapat beradaptasi dengan bahasa desain apa pun. Tidak terlihat lagi, Komet itu.

@nerocui kedengarannya keren, tapi setidaknya dari melihatnya, tidak ada desainer XAML. Membangun UI yang kompleks mungkin gila pada tahap saat ini. Tapi memang terlihat menjanjikan.

Dan ini bukan tentang drag-and-drop, ini tentang preview real-time dari UI di desainer ketika perubahan dibuat dalam kode.

Minggu depan saya akan merilis satu set Template VS untuk UWP yang memungkinkan Anda membuat aplikasi dalam hitungan detik. Ini telah digunakan untuk proyek "internal". Ini akan membuktikan bahwa UWP dapat menjadi kerangka kerja RAD di luar kotak jika hanya VS yang memiliki blok bangunan yang tepat.

Apakah ini menggunakan NoesisGUI? Jika demikian, ada BANYAK fungsionalitas yang hilang yang diperlukan untuk aplikasi LOB. Sekarang, WinUI yang menargetkan Unity akan luar biasa.

Saya telah membuat repo untuk mendokumentasikan status XAML saat ini dan mudah-mudahan orang-orang akan membantu dan berkontribusi dengan wawasan dan cuplikan kode aktual yang mencantumkan cara menyelesaikan tugas dalam berbagai jenis XAML.

https://github.com/gatewayprogrammingschool/XAML-Standardization

Masalah sederhana, bergerak melampaui sandbox hari ini dan merangkul apa yang diperlukan untuk lintas platform. Sudah melakukannya untuk setiap aspek lain dari Windows/OS mengapa tidak UI.

Ambil platform lintas kotak pasir.

Dari: notifikasi [email protected]
Dikirim: Sabtu, 29 Februari 2020 8:00:13
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Komentar [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Diskusi: WinUI harus lintas platform (#2024)

Masalah sederhana, bergerak melampaui sandbox hari ini dan merangkul apa yang diperlukan untuk lintas platform. Sudah melakukannya untuk setiap aspek lain dari Windows/OS mengapa tidak UI.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 , atau berhenti berlangganan https://github.com/ notifikasi/berhenti berlangganan-auth/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

Mengintegrasikan komponen C++ kinerja tinggi dengan C# adalah hal yang sepele di bawah UWP. Akses ke permukaan DirectX juga jauh lebih baik.

@Noemata Kecuali yang saya pedulikan adalah tidak harus menulis C++ untuk memulai, WinDev terus merusak semua upaya yang akan membuat bahasa .NET sama-sama saling berhadapan dalam hal C++ API, Managed Direct X, XNA, kompilasi AOT yang tepat dari .NET kode, fitur COM, ....

Membuat lintas platform WinUI 3.0 akan menjadi argumen untuk mem-porting aplikasi .NET/Forms yang ada ke WinUI.

Untuk awal sudah cukup support macOS, dan tidak masalah jika tidak memiliki performa yang sama seperti di Windows, atau tidak semua fitur seperti animasi.

Windows adalah platform referensi; tentu saja harus digabungkan ke DirectX untuk kinerja terbaik.

Menurut pendapat saya, tidak masuk akal mencoba menulis ulang aplikasi C# besar di HTML+JS hanya untuk mendukung macOS. Dan juga untuk aplikasi desktop baru C# adalah pilihan yang lebih baik.

Untuk aplikasi desktop C# dan XAML jauh lebih andal daripada HTML+JS.

Membuat lintas platform WinUI 3.0 memastikan masa depan .NET, C# dan XAML.

Halo semua

Saya seorang pengembang kontrak WPF yang bekerja di London. Saya telah membangun antarmuka pengguna berkinerja tinggi yang kompleks dengan WPF untuk sejumlah lembaga keuangan sejak tahun 2006. Inilah pendapat saya tentang hal ini:

1) Saya terus mengawasi pasar kerja di Inggris. 100% pekerjaan WPF yang diiklankan sejak tahun 2006 (dimana ada 1000-an) adalah untuk membangun aplikasi desktop perdagangan keuangan berkinerja tinggi untuk sektor keuangan. Belum ada pekerjaan yang diiklankan untuk pengembang UWP untuk industri apa pun.

2) Aplikasi perdagangan desktop ini tidak dapat menggunakan UWP atau WinUI yang akan datang - ini tidak cukup baik dibandingkan dengan WPF karena banyak alasan kompleks. Selain itu, desain Lancar bukanlah sesuatu yang diminati pengguna ini - hanya perlu terlihat seperti kisi-kisi excel - tanpa animasi, tanpa gaya - hanya data dan kinerja luar biasa.

3) Pelanggan ini sama sekali tidak tertarik dengan solusi lintas platform. Tidak ada yang menggunakan Mac, dan seluler bukanlah sesuatu yang mereka minati.

4) Tim pengembang WPF ini memiliki investasi besar (waktu dan uang) di perpustakaan kontrol WPF pihak ke-3, atau memiliki suite kontrol kustom berkinerja tinggi yang dikembangkan untuk mereka melalui orang-orang seperti saya. Mereka tidak akan pindah dari WPF kecuali ada manfaat yang sangat signifikan (yang tidak akan ada untuk foreeable)

5) Untuk lembaga keuangan ini, aplikasi apa pun yang tidak perlu ditulis secara eksplisit untuk desktop / WPF ditulis dengan teknologi web dan Javascript. Mereka tidak tertarik pada sesuatu yang lebih eksotis dari itu - tidak ada flutter, tidak ada blazer, dll.

Jadi ini adalah situasi di Inggris. Ratusan pengembang WPF tidak ingin pindah ke sesuatu yang baru dalam waktu dekat. Pengembang nol UWP (kecuali mungkin segelintir band satu orang yang mengembangkan aplikasi untuk toko - yang diragukan melihat keadaan toko)

Juga, saya tidak mengerti semua histeria tentang lintas platform. Lintas platform yang mencakup seluler dan desktop adalah tugas yang bodoh. Tidak akan pernah menarik. Microsoft mencoba ini dengan aplikasi UWP yang berjalan di desktop dan telepon - itu adalah bencana - membatasi aplikasi ke UI paling sederhana yang tidak dapat melakukan hal yang rumit atau menarik. Perangkat desktop dan seluler dibuat untuk tugas dan kasus penggunaan yang berbeda, dan memerlukan aplikasi yang berbeda - kita semua tahu ini.

Bagi saya, saya ingin melihat lebih banyak investasi Microsoft saya ke WPF secara langsung, tanpa mengorbankan kompatibilitas ke belakang. Saya ingin melihat pengembangan kontrol dukungan WPF di c++ yang tidak dikelola sehingga kami dapat bekerja lebih dekat dengan logam. Saya ingin melihat teknologi pengikatan yang lebih baik, templat data yang lebih baik, fungsionalitas templat kontrol yang lebih baik termasuk pewarisan sebagian. Saya ingin melihat alat debugging yang lebih baik, dan penganalisis pohon visual. Saya ingin melihat debugging XAML disempurnakan lebih lanjut. Saya ingin dukungan multi-threading yang lebih baik di UI. Saya menginginkan banyak hal, dan begitu juga rekan-rekan kontraktor WPF Inggris saya.
Peta jalan Microsoft saat ini tidak memberi saya apa pun yang saya inginkan, dan semua hal yang tidak saya pedulikan.

Jika Microsoft tidak mendukung visi ini (yang jelas mereka tidak mendukungnya sekarang), maka rencana B akan menjadi komunitas yang membentuk WPF ke dalam platform yang diperlukan melalui kontribusi sumber terbuka - dengan asumsi bahwa Microsoft menerima sentuhan yang lebih ringan dalam hal mengizinkan yang baru kode dan ide untuk menjadi bagian dari kerangka kerja WPF.

@deanchalk Saya pikir sebagian besar dari ini mungkin lebih baik ditempatkan di repo WPF untuk menunjukkan kepada mereka ada minat pada WPF, mempostingnya di sini sebagian besar mengatakan Anda tidak tertarik dengan apa yang dilakukan di repo WinUI / dibahas dalam masalah ini. Meskipun itu masukan yang valid, itu mungkin tidak akan mengarah pada sesuatu yang konstruktif di luar diskusi kosong.

@weltkante @deanchalk Ada masalah dalam repo yang meminta "dukungan kontrol lama" di WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/1833
Setidaknya poin 4) cocok dengan masalah itu dan mungkin harus diposting ulang di sana untuk membuat kasus untuk investasi oleh Microsoft.

@deanchalk , saya masih penggemar berat WPF. Ini adalah alat yang luar biasa, untungnya, mulai mendapatkan cinta dari Microsoft. Cara Microsoft memilih untuk menjatuhkan WPF di tempat pertama, sangat disayangkan. UWP menjadi mainan baru yang mengkilap, seharusnya tidak menghalangi investasi lanjutan di WPF.

UWP dalam banyak hal, jalan yang benar ke depan. Sayangnya, iterasi pertama mengabaikan beberapa persyaratan paling penting bagi orang-orang yang menggunakan WPF dan mungkin telah mempertimbangkan untuk bermigrasi. Tidak sedikit di antaranya adalah keadaan fragmentasi XAML yang agak mengejutkan di dalam dinding satu organisasi. WPF != Cahaya perak != UWP != Xamarin. Wow!

Saya kurang bersimpati kepada pengembang WPF yang telah memilih untuk mengakar di WPF di tahun 2020. Banyak hal telah berubah. Kepulauan XAML dengan kemampuan untuk menggunakan WinRT API memberi Anda jalur yang cukup mudah untuk memulai migrasi Anda ke UWP. Dan UWP tidak lagi kurang jika Anda memilih untuk melakukan konversi grosir.

Masalah yang lebih besar tetap kurangnya kejelasan dari Microsoft tentang apa yang sebenarnya terjadi selanjutnya. Semua orang yang telah berharap untuk XAML Nirvana menyerah dengan kegagalan Silverlight yang kembali bermain sendiri sekali lagi dengan UWP.

WinUI jelas merupakan UWP yang diberi label ulang, menyakitkan untuk disaksikan. Dan Microsoft berharap kita semua akan melupakan apa itu UWP.

Namun, tangan kiri Microsoft tidak selalu selaras dengan apa yang dilakukan tangan kanan. WindowsX telah membuat Win32 dan segala sesuatu yang menyertainya (WPF/Winforms/dll.) prospek yang lemah untuk aplikasi yang "mungkin" berjalan di kotak pasir dengan kinerja yang lebih rendah. UWP adalah, dan saat ini tetap menjadi UI asli untuk Windows 10, WindowsX dan seterusnya. WinRT API adalah peningkatan besar dari Win32. Jadi saya kira Anda harus memilih apakah Anda ingin pindah ke tahun 2020 atau bertahan di tahun 2010.

WinUI jelas merupakan UWP yang diberi label ulang, menyakitkan untuk disaksikan. Dan Microsoft berharap kita semua akan melupakan apa itu UWP.

@Noemata WinUI adalah produk baru berdasarkan API UWP (XAML, Komposisi, Input,...). Nama itu masuk akal karena Anda akan dapat menggunakannya untuk membangun UI untuk aplikasi Windows, apa pun model aplikasi yang mendasarinya.

Saya bingung. Anda sendiri menyebutkan 10X di paragraf terakhir. Model aplikasi UWP sendiri mendapatkan dorongan dengan Windows 10X. Sekarang, apakah 10X akan berhasil adalah sesuatu yang hanya waktu yang tahu. Tapi MS jelas dalam pesannya: UWP adalah platform asli 10X (bersama web) seperti yang Anda tunjukkan.

@Noemata hingga 2020 mengejar fitur-fitur yang tersedia di 2010, banyak dari kita yang terpaksa bertahan di 2010.

Banyak dari kita yang merasa lelah dengan proses penulisan ulang yang dimulai dengan menjatuhkan Silverlight, XNA dan melihat bagaimana tangan MS melambai penulisan ulang yang diperlukan untuk .NET Core, WinUI, sambil menjatuhkan fitur dalam proses, tidak memenangkan hati banyak dari kita. pelanggan, dengan aplikasi yang berfungsi penuh yang tidak mengerti mengapa mereka harus membayar penulisan ulang untuk mendapatkan kembali lebih sedikit fitur.

Saat ini, berkat kepandaian memiliki tablet Android dan Windows 10 X, Xamarin dan PWA adalah yang kami nantikan, bukan WinUI.

@pjmlp , mungkin. Saya ingin tahu fitur apa yang Anda lewatkan? Saya telah mem-porting beberapa aplikasi WPF yang cukup besar ke UWP. Sakit kepala terbesar adalah sandbox keamanan dan belajar untuk bekerja dengannya daripada melawannya. Sebelumnya ada bagian yang hilang, seperti Data Grid, konektivitas DB, API yang layak untuk komunikasi kecepatan tinggi dan sebagainya. Ada sangat sedikit yang hilang sekarang. Ada banyak hal yang tidak bisa saya lakukan dengan mudah di WPF. Agar adil, saat ini, tidak ada yang tidak dapat saya lakukan di WPF dengan memanfaatkan akses ke WinRT API kecuali saya akan memiliki kinerja yang lebih rendah karena UWP mengkompilasi ke kode mesin dengan cara yang lebih optimal dan menggunakan tumpukan rendering DirectX yang lebih baik. Plus, Anda harus mengaburkan kode WPF Anda (membuatnya lebih rapuh) jika Anda ingin melindungi IP Anda atau mencegah penyusup.

Ponsel/tablet adalah perangkat hebat untuk jenis aplikasi solusi titik. Saya tidak ingin mencetak simfoni di telepon, atau mendesain gedung pencakar langit, dan saya lebih suka dapat menargetkan bagian dari solusi titik bagian dari aplikasi desktop saya ke seluler, daripada mencoba dan membuat seluler berfungsi di desktop saya.

@Felix-Dev Saya mengerti apa itu WinUI. Saya mempertanyakan mengapa garpu lain diperlukan hanya karena pengembang WPF, Winforms, dan MFC/Win32 tidak mau menerimanya. Strategi yang lebih baik adalah membuat migrasi menjadi lebih menarik atau tidak terlalu menyakitkan atau keduanya.

Microsoft telah melakukan banyak hal yang benar dengan UWP. Ada banyak contoh aplikasi di luar sana yang mencakup semua jenis kasus penggunaan. Mereka datang terlambat, begitu pula fitur-fitur yang hilang. Apakah ini benar-benar terlambat?

@Noemata WinUI mungkin akan terjadi dengan cara apa pun (dengan atau tanpa WinUI Desktop) karena memisahkan tumpukan UI UWP dari OS adalah langkah yang mutlak diperlukan. Akan lebih baik jika WinUI sudah ada ketika Windows 10 pertama kali dirilis tetapi ada alasan mengapa tidak demikian.

Adapun apakah sudah terlambat .... kami memiliki banyak diskusi seperti itu di saluran perselisihan komunitas UWP dan juga pertukaran penuh gairah yang tak terhitung jumlahnya di sini. Beberapa dari kita berpikir kapal telah berlayar sementara yang lain masih berpikir ada kemungkinan platform UWP/WinUI dapat tumbuh dan matang untuk menjadi platform pengembang utama. Banyak orang dengan banyak ide bagaimana pendekatan terbaik untuk MS bisa terlihat seperti (yaitu pergi xplatform atau tidak?). Faktanya, tim saat ini sedang bekerja keras untuk WinUI 3 dan peluncurannya akan menandai dimulainya tantangan nyata: Mendorong WinUI ke depan - dengan bantuan komunitas - sehingga ini akan menjadi kerangka kerja pilihan bagi pengembang yang menargetkan Windows .

@Noemata , pertama-tama kompatibilitas dengan perpustakaan komponen pihak ketiga yang ada seperti Telerik, Component One, ...

Kemudian tidak harus menulis ulang apa pun untuk memulai, seperti yang disebutkan, kami muak dengan penulisan ulang.

Dalam hal DirectX, tidak hanya kelas pemodelan 3D dari WPF yang tidak didukung, kami diharapkan untuk menulis C++, karena Microsoft tidak dapat diganggu untuk membuat proyeksi Runtime untuk DirectX, dan dialek C++/CX yang entah bagaimana menyenangkan digantikan oleh kata-kata yang bertele-tele. kurang mampu, tapi hei lebih baik, C++/WinRT.

Selain itu, kita tidak hanya harus membuang kode WPF yang berfungsi sempurna, kita juga harus melakukan hal yang sama pada kode WCF, EF6.

Saya masih percaya bahwa UWP adalah API yang jauh lebih baik daripada Win32, entah bagaimana seharusnya Longhorn, tetapi cara ini dimainkan telah membakar terlalu banyak jembatan, karena Microsoft telah membakar anggaran penulisan ulang dari banyak organisasi.

@pjmlp , itu semua adalah poin bagus dengan argumen kontra yang agak lemah lembut, jadi saya bahkan tidak akan mencoba. Tidak ada dukungan untuk WPF 3D API merupakan pukulan besar bagi saya pribadi. Harus mempelajari pendekatan baru tidak menyenangkan dan kurang mampu mengingat opsi pengikatan WPF untuk 3D. Alternatif C# untuk 3D di bawah UWP ada, hanya saja kurang berguna setelah Anda merasakan manfaat mengikat pada model 3D.

C++/CX adalah masalah lain yang membutuhkan waktu terlalu lama untuk diselesaikan oleh C++/WinRT yang mungkin akan stabil minggu depan (masih bergeser).

WCF sudah mati (maaf, opsi baru jauh, jauh lebih baik). EF6 seharusnya memiliki cerita migrasi yang jauh lebih baik. Anda benar sekali tentang kegagalan penulisan ulang anggaran @pjmlp , jelas ini adalah sesuatu yang digunakan Microsoft untuk mendapatkan dan tidak lagi peduli untuk mempertimbangkan mengingat churn yang gila/tidak konsisten pada teknologi.

@Felix-Dev, Anda juga membuat poin yang benar-benar valid. Pemisahan UI seharusnya sudah ada sejak awal. Orang-orang yang meminta xplatform UI berdasarkan XAML harus mengungkapkan kembali permintaan mereka dan meminta mesin rendering XAML pada platform pilihan mereka dengan mini OS untuk mereplikasi permukaan API (Platform Java/Silveright/Uno lain/Unity/Apa pun … akhirnya diakhiri dengan HTML yang dekat dengan aplikasi logam tidak dapat mulai dipertimbangkan). Saya tidak mengetahui rahasia inisiatif internal MS terbaru saat ini. Melihat ke luar ke dalam, WinUI adalah bendera yang melambai yang menunjukkan kapal sedang diluruskan lagi (berapa kali lagi?). Membela Microsoft menjadi tidak mungkin dengan kematian Silverlight. Aku tidak akan mengambil pedang itu lagi. Saya kira yang sebenarnya saya lakukan adalah meratapi kematian UWP :-( ...menyakitkan. https://www.youtube.com/watch?v=uBiewQrpBBA

Charlie == Microsoft

Lintas Platform? Microsoft hanya harus membeli UNO dan selesai dengan tit.

Lintas Platform? Microsoft hanya harus membeli UNO dan selesai dengan tit.

Saya berharap solusi apa pun yang muncul dengan sendirinya, tidak akan bergantung pada browser web atau tampilan web semacam itu. Tampilkan UI di jendela asli atau permukaan UI platform apa pun - tetapi terlihat identik dengan tampilannya di Windows.

Lintas Platform? Microsoft hanya harus membeli UNO dan selesai dengan tit.

Saya berharap solusi apa pun yang muncul dengan sendirinya, tidak akan bergantung pada browser web atau tampilan web semacam itu. Tampilkan UI di jendela asli atau permukaan UI platform apa pun - tetapi terlihat identik dengan tampilannya di Windows.

Begitulah cara UNO melakukannya kecuali pada Windows 7. Windows 7 adalah satu-satunya pengecualian karena menggunakan browser Web.

Bagi para pengembang WPF yang membutuhkan solusi desktop lintas platform, Wine dapat menjadi pilihan yang layak untuk Anda. Saya sangat sukses mem-porting aplikasi WPF besar (.NET Core WPF kebanyakan) untuk dijalankan di Linux dengan Wine. Saya memiliki artikel yang dapat membantu Anda memulai:
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

Saya juga sudah mulai mem-porting beberapa aplikasi WinForms ke Linux. Sejauh ini saya tidak mengalami masalah apapun.

Wine juga harus memungkinkan Anda untuk berjalan di Mac, Chrome OS, dan Android. Saya hanya mencoba Linux.

Bagi saya ini menunjukkan bahwa menggunakan DirectX sebagai lapisan abstraksi berfungsi dan merupakan model yang layak untuk diikuti. Saya menduga itu bahkan akan bekerja dengan baik di Web dengan WebGL setelah .NET WASM lebih matang.

Membuat Microsoft membantu dengan Wine (setidaknya memastikan mereka tidak merusaknya) akan banyak membantu. Mereka dapat membantu menciptakan solusi yang benar-benar asli dengan WineLib dan dengan keahlian mereka, saya rasa itu tidak akan terlalu merepotkan.

AvaloniaUI sudah IS sudah lintas platform. Mengapa tidak meminta bantuan dan umpan balik dari orang-orang dalam proyek untuk meningkatkan WinUI?

Yah, tidak sebanyak Uno Platform. Platform Uno juga berjalan di web (WASM). Avalonia tidak memiliki kemampuan ini.

Avalonia juga menggunakan dialek XAML-nya sendiri, yang coba dihindari oleh Uno.

Dari: Notifikasi [email protected]
Dikirim: Jumat, 27 Maret 2020 04:09:30
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Komentar [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Diskusi: WinUI harus lintas platform (#2024)

AvaloniaUI sudah IS sudah lintas platform. Mengapa tidak meminta bantuan dan umpan balik dari orang-orang dalam proyek untuk meningkatkan WinUI?

Yah, tidak sebanyak Uno Platform. Platform Uno juga berjalan di web (WASM). Avalonia tidak memiliki kemampuan ini.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 , atau berhenti berlangganan https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA .

Sebagian besar teknologi WinUI berasal dari Sliverlight, dan Sliverlight sebenarnya telah mencapai lintas platform. Jadi lintas platform WinUI bergantung pada strategi, bukan teknologi.

Sejujurnya... sebenarnya sangat menyedihkan Microsoft sekarang mencoba mengejar ketinggalan... mereka hanya peduli dengan pangsa pasar "besar", mereka tidak melihat apa yang diinginkan pelanggan/penggemar produk mereka.

Microsoft adalah alasan mengapa pengembangan APLIKASI DESKTOP telah bergeser ke pengembangan WEB yang sudah ketinggalan zaman, bahkan ketika web begitu mengerikan.

Saya yakin setiap pengembang XAML setuju bahwa HTML/CSS sangat sampah.

Tapi tetap saja... HTML, CSS, DOM... dengan kerangka kerja seperti React, Angular, Vue yang mencoba membuatnya menjadi sesuatu yang sedikit lebih menyenangkan. Orang-orang masih fokus pada web usang ini, bukan pada platform Microsoft Windows sumber tertutup baru yang mati setiap 2-4 tahun untuk yang baru.

Platform Win-app berbasis XAML seharusnya memiliki sumber terbuka TAHUN yang lalu. Seharusnya menulis sekali menyebarkan di SITUS WEB, Windows, Mac, Linux, Android (platform apa pun yang diinginkan pelanggan). Windows Store seharusnya lintas platform dengan perender aplikasi XAML/UWP. (mirip bagaimana Google Chrome adalah crossplatform dengan HTML/CSS renderer).

Selama zaman keemasan Microsoft, aplikasi lintas platform berbasis XAML dapat menghancurkan web, maka kita tidak perlu berurusan dengan CSS, HTML, DOM, dan kerangka kerja yang tak terhitung jumlahnya ini.

Tapi tidak, obsesi Microsoft dengan perangkat lunak berpemilik membuat mereka kalah dari web.

Sementara itu Google's Flutter menjadi apa yang selalu saya inginkan untuk XAML.

Saya berharap WinUI 3 akan menjadi platform target di MAUI. Platform Uno telah mengumumkan bahwa Pratinjau WinUI 3 mendapat dukungan.
Jadi, @jeromelaban / Microsoft yang mungkin benar-benar kita butuhkan adalah penyatuan Uno/MAUI? MAUI adalah IMO yang kurang berguna daripada Flutter atau Uno tanpa target web (browser).

Silakan tinggalkan komentar Anda di repositori MAUI juga.

WPF (Silverlight) di mana-mana!

Memindahkan DirectX ke platform lain tampaknya sangat berhasil, mungkin solusinya adalah menggunakan OpenGL atau Vulkan alih-alih DirectX

Google memiliki ANGLE yang memungkinkan menjalankan OpenGL ES secara native di platform apa pun dengan menerjemahkan panggilan dan shader ke API asli (desktop gl [mungkin disediakan oleh renderer perangkat lunak swiftshader], vulkan, directx, metal). Ini juga merupakan bagian inti dari Chrome dan Flutter, berjalan bersama dengan Skia.

Microsoft dapat melakukan subset kecil (mungkin hanya sebagai titik awal) dari DirectX untuk aplikasi GUI dan membuatnya diterjemahkan ke dalam API asli seperti halnya ANGLE.

Apa yang datang ke masalah "dukungan distro linux yang berbeda", pengguna linux sering cukup terampil untuk memperbaiki ketidakcocokan sendiri, dan bahkan kemudian ada Flatpak yang menyatukan kemasan untuk desktop seperti yang dilakukan Docker untuk server.

Disebutkan dalam obrolan Lonje https://www.lonje.com/message/1968439855/

Saya benar-benar berpikir WinUI juga harus mendukung tema asli di Mac dan Linux sambil tetap mendukung tema khusus.
Saya tidak yakin tentang pengguna Mac tetapi komunitas Linux suka mengontrol tampilan desktop mereka.
Mereka sudah memiliki Gtk yang menurut saya akan menjadi hal yang baik untuk dimasukkan ke dalam kerangka kerja WinUi

Saya benar-benar berpikir WinUI juga harus mendukung tema asli di Mac dan Linux sambil tetap mendukung tema khusus.
Saya tidak yakin tentang pengguna Mac tetapi komunitas Linux suka mengontrol tampilan desktop mereka.
Mereka sudah memiliki Gtk yang menurut saya akan menjadi hal yang baik untuk dimasukkan ke dalam kerangka kerja WinUi

Ini pasti sulit dilakukan karena WinUI adalah bahasa gaya, dan kerangka kerja XAML yang mendasarinya mengharuskan Anda untuk membuat tema sendiri, sementara tema default juga disediakan.

Saya telah menyarankan di masa lalu, bahwa proyek harus terstruktur dengan cara yang memungkinkan komunitas untuk mengembangkan Renderer Logam untuk macOS dan iOS - dan mungkin perender Skia untuk Android.

Gaya dan Template default yang sama dapat digunakan di semua platform, atau template dan sumber daya default bergaya Android dan macOS dapat dibuat.