Ini adalah pemikiran awal saya tentang pertanyaan yang Anda ajukan dalam konten masalah.

Saya datang dari perspektif desain dan pengguna, dengan hanya sedikit pengalaman pengembangan, yang sangat tertarik dengan pengembangan Silverlight/Windows Phone 7 di masa lalu yang sekarang terasa sedikit terbakar.

Template apa yang paling menarik bagi Anda?

Saya pikir sebelum meminta daftar ide templat, perlu ada semacam audit yang dilakukan terhadap aplikasi terbesar dan paling banyak digunakan di setiap kerangka kerja, jadi WPF, UWP, WinForms, MFC dll.

Periksa "siluet" aplikasi ini dan cari tahu skenario UX yang umum.

Dari atas kepala saya, ada:

• Menu Utama (Semua kerangka kerja)
• MDI (banyak dokumen dalam satu jendela) (kebanyakan MFC)
• Tab dan Datagrid (WPF, WinForms, MFC)
• Ribbon (aplikasi Win32 Office, 3ds max, paint, wordpad, File Explorer dll)
• Utilitas Baki Sistem (MFC, WinForms)
• Browser
• Penyihir (WPF, MFC)
• Aplikasi MDI yang kompleks (perangkat lunak Adobe, Visual Studio)
• Pemutar Media
• Visualisasi Data LoB (WPF dan Web)
• Aplikasi sosial (React Native, PWA - Skype, Facebook, Twitter)

Semua atau sebagian dari ini bisa mendapatkan keuntungan dari integrasi sistem WinRT/UWP dengan Notifications/Action Centre.

Semua template Proyek Baru ini harus menghindari ruang nama Windows.Xaml bawaan, tema kontrol WPF, dan gaya visual WinForms yang mendukung template baru dan gaya visual yang cocok dengan desain kontrol FabricWeb/Fluent.

Juga harus ada cara mudah bagi pengembang dengan aplikasi WPF dan WinForms yang ada untuk menambahkan ketergantungan WinUI 3.0 yang memberi mereka desain kontrol baru dengan pernyataan penggunaan sederhana atau entri manifes

Kepulauan XAML

Karena Pulau Xaml menjadi lebih mudah dimungkinkan - mengganti kontrol tampilan web lama, pemilih warna, Dialog berbasis XAML bisa semudah Add New... mereka memiliki kode mereka sendiri.

Template aplikasi dan halaman modern seperti aplikasi Xbox Next, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop, dan Pivot - semuanya dapat tersedia untuk semua Platform Presentasi Windows - dengan XAML Islands di tempat dan konten sampel.

Skenario apa pun yang saat ini tidak dimungkinkan di UWP XAML, harus dengan kontrol dan template untuk membuatnya lebih mudah.

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Itu harus menjadi pertanyaan yang diajukan ketika seseorang membuka proyek mereka pada versi terbaru Visual Studio dengan Windows 10 SDK saat ini. Tekan tombol dan itu akan menggantikan ruang nama dan menggunakan, atau menandainya jika itu bukan kontrol yang dikenalnya.

Pada proyek baru itu harus menjadi default, dan paket nuget diinstal bersama dengan versi Windows SDK yang akan datang.

Apa solusi pilihan Anda untuk menggunakan komponen UWP dengan WinUI 3?

Seperti jawaban pembaruan otomatis, Halaman dan proyek baru harus menyertakannya secara default, dan pesan yang menanyakan apakah mereka ingin secara otomatis pindah ke WinUI | Tambahkan komentar ToDo untuk memperbarui namespace s | Jangan pindah ke WinUI .

Jenis aplikasi apa yang paling membuat Anda tertarik untuk menggunakan WinUI 3.0?

Sebagai pengguna, saya ingin semua aplikasi yang berjalan di Windows berbagi UI dan UX yang sama, apa pun kerangka kerja yang digunakan.

Saya ingin aplikasi dipasang tanpa mengacaukan registri dan meninggalkan sampah. (begitu Centennial)

Saya ingin semua aplikasi dapat diinstal dari dalam toko, atau dari penginstal tipe Centennial. Virtualisasikan folder Sistem dan Windows untuk setiap aplikasi.

Memodernisasi aplikasi C++ MFC dengan UI Lancar?

Akrilik harus tersedia untuk aplikasi WPF, WinForms, dan MFC, dan disertakan dalam template baru default melalui dependensi atau manifes WinUI 3.0. CommonControls dan gaya jendela harus menggunakan Akrilik dan bilah judul yang diperluas (yang dapat diganti untuk kembali ke default saat ini)

Aplikasi Microsoft Win32 non UWP semuanya harus dikompilasi ulang dengan WinUI 3.0 sehingga semuanya menggunakan bingkai jendela Akrilik, menu utama, ThemeShadows, Menu Konteks , Bidang Teks, Bilah Kemajuan, dll.

Dan kemudian aplikasi yang ada memerlukan solusi sederhana untuk memasukkan WinUI 3.0+ yang kemudian memperbarui tampilan semua kontrol - atau kemampuan untuk menerapkannya secara selektif satu dialog pada satu waktu, hingga seluruh UI diperbarui.

re: namespaces, saya berharap mereka hanya berubah berdasarkan target meskipun membutuhkan ruang nama bersyarat.

Inilah jawaban saya:

Membuat aplikasi baru

Template apa yang paling menarik bagi Anda?

• Saya ingin melihat c++/winRT win32+xaml dan .net core+xaml pertama di sana, template UWP berada di urutan kedua, aplikasi win32 yang dikemas tidak boleh datang sebagai template, karena template paket aplikasi saat ini seharusnya hanya berfungsi seperti yang sudah mereka lakukan dengan saat ini aplikasi win32/.Net.
• Selain itu, saya ingin melihat templat item seperti "Jendela XAML Baru" dengan kode boiler-plate untuk menunjukkannya di aplikasi aplikasi win32 atau .net core yang ada (misalnya: membuat aplikasi systray yang ada la Docker Desktop, dapat menampilkan Jendela Xaml tingkat atas baru)

Menambahkan WinUI 3.0 ke aplikasi Win32 yang ada

• kompatibilitas non-mundur adalah alasan yang tepat mengapa saya tidak pernah menggunakan pulau xaml pada proyek nyata (meskipun menggunakannya untuk bersenang-senang pada hal-hal pribadi). Memisahkan kerangka kerja UI dari Windows API adalah salah satu hal terhebat yang diumumkan dengan peta jalan WinUI 3.0 (di samping kemampuan aplikasi penargetan non-paket/non-uwp untuk memanfaatkannya)

Memperbarui aplikasi UWP Xaml Anda yang ada ke WinUI 3.0

Ini mungkin terdengar kasar, tetapi saya merasa aplikasi UWP xaml adalah ceruk pasar (sejak turunnya windows phone, tidak ada lagi daya tarik terhadap UWP sebagai platform target), dan bahkan jika perkakas/interop akan menyenangkan untuk dimiliki, saya tidak 't berpikir itu harus menjadi fokus utama untuk WinUI 3.0.
Jadi kedua alat pembaruan namespace (yang mungkin sebenarnya dilakukan menggunakan pencarian dan penggantian global) dan mencampur UWP xaml dan WinUI xaml tidak terasa penting bagi saya.

Juga, hanya ingin menyebutkan bahwa ini adalah langkah yang sangat disambut, dan memiliki seluruh kerangka kerja UI open source di Github luar biasa! Terima kasih banyak untuk melakukan ini!

Pertama-tama, ini adalah langkah yang bagus! Sayangnya saya tidak dapat mengabaikan fakta bahwa saya merasa sedikit sakit hati dengan cara Microsoft menangani beberapa pengembang terakhir di platform mereka. Saat ini saya hanya menggunakan UWP untuk aplikasi yang menghadap konsumen karena:

1. WPF jauh lebih matang daripada WinUI (validasi, kontrol yang ada, dll), jadi untuk perusahaan WPF lebih cocok
2. UWP sangat bagus untuk berbagai kategori perangkat (seluler, tablet, desktop, dll), di situlah konsumen berada

Sangat menyenangkan melihat poin 1 dapat diatasi dengan WinUI, sehingga membuat saya antusias dengan kemajuan WinUI. Sayangnya 2 tidak lagi berlaku (tidak ada lagi perangkat keren, hanya desktop). Itu membuat orang bertanya-tanya, pada saat barang ini dikirimkan (1 tahun dari sekarang paling awal?), Apa yang dibutuhkan pengembang pada tahap itu.

Saya pikir barang-barang konsumen tidak lagi menjadi bagian dari persamaan, kapal itu telah berlayar dengan "strategi" penghematan. Jadi satu-satunya hal yang baik adalah aplikasi perusahaan.

Secara umum, saya akan lebih tertarik pada strategi migrasi yang baik dari WPF ke WinUI untuk mencoba dan memigrasi basis kode WPF kami yang besar ke Windows 10. Kelemahan dari harus memperbarui aplikasi yang menghadap konsumen (saat ini UWP) adalah mereka sangat bergantung pada pengembang komponen eksternal (misalnya win toolkit, dll). Saya pikir tidak ada opsi yang layak untuk memperbarui ini lagi karena sebagian besar pengembang (saya tahu) kehilangan minat dalam pengembangan klien konsumen/windows.

Jawaban atas pertanyaan

Membuat aplikasi baru

Template apa yang paling menarik bagi Anda?

Saya ingin melihat .net core / xaml / C# di sini, karena menurut saya itulah kombinasi bahasa yang paling sering digunakan. Tapi mungkin template migrasi akan lebih baik di sini (coba untuk membuat semua orang bergabung secepat mungkin, semakin lama, semakin menyakitkan).

Menambahkan WinUI 3.0 ke aplikasi Win32 yang ada

Saya pikir ini sangat bagus, dan kami akan sering menggunakan ini (tetapi secara realistis, ini setidaknya satu tahun lagi karena pelanggan perusahaan masih menggunakan Windows 7, bahkan ketika dukungan MS berakhir, perusahaan akan menggunakan Windows 7). Kemudian kita perlahan-lahan dapat memigrasi WPF ke WinUI 3.

Apakah Anda mengetahui Pulau Xaml untuk memodernisasi aplikasi desktop?

Ya, tetapi terlalu banyak pelanggan (atau pernah) menggunakan Windows 7, jadi itu bukan pilihan untuk pengembang perusahaan. Dan untuk konsumen Anda bisa menggunakan UWP saja.

Apakah kompatibilitas mundur yang diperluas ini pada Windows 10 membuat Xaml Islands lebih berguna bagi Anda?

Ini adalah awal yang baik karena pada saat barang ini dikirimkan, ini akan bekerja pada semua versi Windows 10 yang didukung di perusahaan.

Memperbarui aplikasi UWP Xaml Anda yang ada ke WinUI 3.0

Aplikasi konsumen untuk MS sudah berakhir, semua karena pilihan yang dibuat MS, tidak ada lagi ruang untuk ini. Saya hanya akan melewatkan seluruh opsi ini dan melupakannya. Menyedihkan karena saya menghabiskan ribuan jam ke dalam aplikasi UWP, tetapi saya pikir kita perlu mempercepat kematian ini agar tidak terlalu menyakitkan.

Seluruh cerita yang dijanjikan selalu up-to-date, mendukung semua perangkat. Saya pikir kita semua tahu ke mana janji itu pergi.

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Jika itu hanya ruang nama, pencarian/penggantian juga harus dilakukan.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

Tidak penting lagi, saya rela menanggung kerugian ribuan jam pengembangan, toh tidak ada pengguna yang tersisa.

Apakah Anda membuat atau menggunakan pustaka kontrol UWP Xaml atau komponen WinRT yang tidak dapat Anda kompilasi ulang dan perbarui dengan mudah bersama kode aplikasi?

Tidak.

Apa solusi pilihan Anda untuk menggunakan komponen UWP dengan WinUI 3?

Kepulauan UWP (semacam komponen yang dihosting)

Umum

Apa pendapat Anda tentang keseluruhan rencana 3.0 yang diuraikan di atas dan di peta jalan? Apakah ini memungkinkan Anda menggunakan WinUI untuk aplikasi Windows baru dan yang sudah ada?

Mungkin perlu beberapa pendewasaan, tetapi saya melihat diri saya menggunakan hal ini dalam 1 - 2 tahun untuk pengembangan perusahaan. Bergantung pada seberapa sulit untuk bermigrasi, kami akan memilih WinUI atau web (tergantung pada bagaimana Windows itu sendiri "berkembang").

Jenis aplikasi apa yang paling membuat Anda tertarik untuk menggunakan WinUI 3.0? Membuat aplikasi Win32 baru dan mengemasnya dengan MSIX? Menambahkan tampilan baru ke aplikasi WPF? Memodernisasi aplikasi C++ MFC dengan UI Lancar?

Mungkin hanya menambahkan tampilan baru ke aplikasi WPF dan perlahan mulai bermigrasi.

Saya sangat menyukai peta jalan ini. UWP perlu dibebaskan dari belenggunya, dan ini adalah cara yang bagus untuk melakukan hal itu.

Memperbarui aplikasi UWP Xaml Anda yang ada ke WinUI 3.0

Ini sangat penting bagi majikan saya. Kami memiliki aplikasi desktop UWP yang kompleks di toko. Kami sekarang membutuhkan Desktop Bridge untuk mendapatkan akses ke API win32 yang tidak didukung oleh .NET Native.

saya ingin

• akses langsung ke semua win32 API;
• menggunakan model eksekusi win32 lama yang polos. Saya baik-baik saja dengan beberapa kotak pasir seperti Desktop Bridge (misalnya virtualisasi registri);
• untuk menempatkan aplikasi kami di toko (msix) seperti sekarang;
• untuk tetap menggunakan WNS (notifikasi push);
• pengalaman pembaruan tanpa rasa sakit dari UWP ke beberapa jenis aplikasi Desktop Xaml baru. Saya tidak keberatan melakukan pekerjaan manual. Mungkin saya lebih suka dokumentasi yang bagus daripada perkakas di sini.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

Gaya yang ada harus tetap berfungsi. Saya bisa hidup dengan beberapa perubahan visual kecil. Tapi tidak dengan perubahan perilaku.

Apakah Anda membuat atau menggunakan pustaka kontrol UWP Xaml atau komponen WinRT yang tidak dapat Anda kompilasi ulang dan perbarui dengan mudah bersama kode aplikasi?

Tidak.

Apa solusi pilihan Anda untuk menggunakan komponen UWP dengan WinUI 3?

Jika mereka tidak dapat dikompilasi ulang (pihak ketiga): Pendekatan seperti Pulau Xaml. Kalau tidak, itu mungkin untuk dengan mudah mem-porting-nya ke WinUI 3.

Umum

Jenis aplikasi apa yang paling membuat Anda tertarik untuk menggunakan WinUI 3.0? Membuat aplikasi Win32 baru dan mengemasnya dengan MSIX? Menambahkan tampilan baru ke aplikasi WPF? Memodernisasi aplikasi C++ MFC dengan UI Lancar?

• Aplikasi desktop win32, dikemas dengan MSIX.
• Uno aplikasi lintas platform ;)

Tolong jangan memperkenalkan ruang nama baru untuk hal-hal seperti _INotifyDataErrorInfo_ - itu harus digunakan dalam model tampilan yang biasanya lintas platform dan tidak boleh memiliki ketergantungan pada WinUI. Itu harus ditentukan di mana hal-hal lain seperti ini berada (yaitu _INotifyPropertyChanged_ atau _INotifyCollectionChanged)_

Saya hanya ingin tahu apakah tujuan utamanya adalah membuat tumpukan UI lintas-plat. Memahami itu mungkin tidak sepenuhnya dipahami bagaimana kita sampai di sana. Namun, jika itu tujuannya... akan lebih baik untuk memberi merek ini tanpa referensi Win di awal upaya ini. Ini akan mengurangi sakit kepala dalam jangka panjang jika Anda melakukannya.

Apakah lebih baik memberi label sebagai XamlUI atau serupa? Ruang nama Microsoft.UI.* baik-baik saja, cukup beri merek repo dan seperti

Terima kasih telah menghubungi kami. Nantikan apa yang akan datang di ruang ini :senyum:

Bagi saya, semua detail teknis kurang penting.
UWP, WPF, atau kerangka kerja khusus Windows apa pun, sehebat apa pun itu, tidak akan cukup lama sehingga tidak berjalan di setiap platform (setidaknya Windows, Droid, iOS, dan web), dan ramah dengan ukuran layar apa pun.

TBH mengecewakan saya pada Build terakhir untuk mengetahui bahwa MS tidak memiliki rencana untuk membuat UWP atau XAML lintas platform. Uno tidak mendapat pengakuan resmi selain pidato. Bahkan yang lebih membuat frustrasi, menurut saya menyakitkan, adalah menemukan bahwa MS memberikan begitu banyak cinta untuk React Native dan kerangka kerja yang digerakkan HTML/JS LAGI (WinJS), sementara mengabaikan pengembang tumpukan .NET yang bertanggung jawab.
Saya ingin melihat MS secara resmi membuat tumpukan UI lintas platform seperti Uno, dan menyediakan perkakas, templat, dan dukungan terintegrasi yang tepat.

Dan BTW, saya telah bekerja dengan XF sejak diakuisisi oleh MS, dan berharap ada alternatif, karena alasan berikut: a. Tidak ada dukungan web, b. Sangat mobile bias, tidak menyukai desktop c. Hirarki library-nya terasa tidak rapi, tentunya jika dibandingkan dengan control-library WPF/UWP d. Tidak menggunakan MS XAML.
Berikut permintaan fitur yang saya posting di Komunitas Pengembang Microsoft: .NET UI Standard .

Terima kasih semuanya!

Kami membutuhkan UI XAML yang juga berjalan di Web (Assembly). Setidaknya sebagian dari UWP.
Mengapa tidak merangkul platform UNO dan membuat rendering web menggunakan SkiaSharp?
Bisa jadi Silverlight 6 , mitra web WinUI

Balasan cepat untuk pertanyaan

Template apa yang paling menarik bagi Anda?

.NET proyek inti SDK-gaya, atau beberapa format proyek MSVC yang disederhanakan.
File proyek lama terlalu rumit untuk diedit secara manual, dan ada banyak masalah interaksi antara sistem proyek lama dan baru. Kita harus benar-benar meninggalkan sistem proyek lama untuk proyek-proyek baru.

Apakah Anda mengetahui Pulau Xaml untuk memodernisasi aplikasi desktop?

Tidak. Saya sedang menulis ulang aplikasi saya dengan perubahan model data penuh, jadi tidak ada migrasi progresif.

Apakah kompatibilitas mundur yang diperluas ini pada Windows 10 membuat Xaml Islands lebih berguna bagi Anda?

Masih banyak pengguna di Windows 7 dan Xaml Islands tidak dapat membantu.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

Tidak. Semua komponen saya ditulis sendiri, atau dari MUX dan WCTK, jadi saya dapat melakukan migrasi manual cepat.

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Tidak banyak, karena proyek saya tidak besar (~ 20 halaman dan ~ 10 kontrol khusus untuk saat ini).

Apa solusi pilihan Anda untuk menggunakan komponen UWP dengan WinUI 3?

Saya ingin ada versi yang dikirimkan dengan OS, untuk memungkinkan pembuatan alat yang sangat kecil dan pengiriman dalam KBs . Alat ini gagal berjalan pada OS yang lebih rendah, karena pengguna yang diharapkan dapat segera menghubungi saya (misalnya melalui beberapa perangkat lunak obrolan).

Jenis aplikasi apa yang paling membuat Anda tertarik untuk menggunakan WinUI 3.0? Membuat aplikasi Win32 baru dan mengemasnya dengan MSIX? Menambahkan tampilan baru ke aplikasi WPF? Memodernisasi aplikasi C++ MFC dengan UI Lancar?

Membuat aplikasi khusus Windows 10 baru dan mengirimkannya tanpa toko.
Penandatanganan tepercaya mahal untuk pengembang individu, dan mengunggah ke toko tidak berlaku untuk domain khusus, bukan aplikasi jangka panjang.

Tampilan pribadi saya untuk platform UI

Rantai alat Xaml

Bahasa xaml entah bagaimana tidak serius, dan saya menghadapi banyak masalah seperti "bagaimana saya harus mewakili ini". WPF xaml dan UWP xaml tidak sepenuhnya kompatibel, jadi saya perlu mengingat perbedaannya. Xaml tidak sepenuhnya kompatibel dengan fitur .NET, jadi terkadang saya perlu menulis beberapa trik jelek di model saya, dan kelas pembantu.

Datang dengan x:Bind , segalanya menjadi lebih buruk. Skenario sederhana mudah digunakan, tetapi sangat rumit untuk melakukan hal-hal yang lebih dari sekadar akses properti. Misalnya, itu tidak mendukung kelebihan metode, jadi saya harus mengkompilasi untuk memeriksa kelebihan mana yang dipilih untuk ekspresi pengikatan ini. Saya bahkan tidak dapat melakukan sakelar sederhana, atau konversi "terlihat ketika beberapa properti salah", dan diperlukan metode pembantu. Dokumentasi tidak mengatakan apa-apa tentang skenario terperinci ini, jadi saya pikir harus ada posisi untuk diskusi desain bahasa-xaml, dan menjadikan xaml bahasa yang dirancang secara serius seperti C#.

Editor xaml juga sulit digunakan. Masuk akal bagi desainer untuk mencoba mengeksekusi beberapa kode untuk menunjukkan efek yang sebenarnya, tetapi editor teks harus mengetahui metadata. Membuka file xaml dalam tampilan sumber lambat karena mengaktifkan desainer, dan melemparkan beberapa pengecualian interaksi untuk xaml yang benar-benar berjalan dengan baik, seperti NullReferenceException dan Cannot convert __ComObject to some type . Itu menyentuh ProjectReference melalui perpustakaan yang dibangun, dan menghasilkan kesalahan yang rumit bahkan ketika pengeditan sederhana ke area api non-publik di perpustakaan ketergantungan, biasanya implementasi model data. Jadi saya pikir harus ada metadata dan kode sumber yang sadar, kompiler xaml terintegrasi Roslyn sepenuhnya.

Model jendela yang lebih baik

Sudah biasa untuk aplikasi penuh informasi dan status penuh untuk menggunakan model multi-jendela alih-alih menavigasi model. Saat ini di UWP, membuat jendela baru menggunakan ApplicationView menyakitkan karena ada masalah threading. AppWindow membagikan utas UI, dan saya tidak yakin tentang kinerja UI-nya.

Menulis ulang Visual Studio di WinUI suatu saat nanti dapat membuktikannya sebagai sistem UI yang matang.

Antarmuka pengikatan data

Kami sangat lelah untuk membuat model yang mengimplementasikan INotifyPropertyChanged . Saya telah menulis tugas MSBuild khusus untuk mengonversi xml menjadi pengakses properti yang diperluas, tetapi itu tidak membantu ketika saya ingin melakukan sesuatu yang khusus di setter ketika properti berubah.

Dan ada masalah threading. Data saya sepenuhnya berasal dari server jaringan latar belakang, jadi pengambilan konteks untuk await tidak dapat membantu saya. Di WPF dan Binding , hanya apa adanya karena Binding menyelesaikan threading itu sendiri. Ketika mengubah ke x:Bind , saya harus menyelesaikannya di dalam event raiser, karena x:Bind hanya beroperasi pada utas panggilan. Hal-hal menjadi lebih buruk ketika saya memiliki beberapa tampilan aplikasi yang menyentuh data yang sama, yang berarti tidak ada operator UI global yang tersedia, dan satu-satunya solusi adalah menangkap SynchronizationContext.Current pada pendaftaran acara. Untuk koleksi, ItemsSource juga tidak aman untuk thread, dan solusi yang sama diperlukan.

Pasti harus ada rantai alat untuk memecahkan masalah pemodelan, threading, dan perluasan untuk model yang dapat diikat yang dapat diubah. Dan solusi bawaan umum untuk koleksi yang dapat diikat harus menyediakan mekanisme untuk "properti tertentu dari setiap anak yang diubah".

IObservableVector<T> adalah tipe generik palsu yang hanya dapat menggunakan object , INotifyCollectionChanged bukan generik. Hanya menerapkannya untuk koleksi bawaan seperti ObservableCollection<T> tidak cukup, terutama untuk skenario berorientasi ISupportIncrementalLoading / IItemsRangeInfo rumit. Platform harus menyediakan implementasi abstrak default dengan praktik terbaik, yang memungkinkan pengguna hanya mengimplementasikan metode pengisian data abstrak.

@shaggygi @weitzhandler @TonyHenrique

Jika ada masa depan Lintas Platform untuk UWP/XamlUI3.0 yang mengabstraksi sintaks XAML, dari Renderer Windows, dan sisa Windows Runtime akan menjadi cara untuk menanganinya.

Jika mungkin ada mentalitas hampir plug-in dengan proyek, mungkin ada Android atau iOS/AppKit Renderer, dan Android/iOS AppKit Shim untuk meneruskan ART API ke C# dan VB, serta bahasa C++, C yang ada mendukung.
Xamarin bisa membantu di sini.

Microsoft tidak perlu menjadi orang yang mengerjakan renderer platform alternatif tersebut.

Tetapi berfokus pada Windows untuk saat ini... WinUI 3.0 dapat mencakup Fabric Web / React Native / WPF / WinForms / MFC. PWA juga akan menjadi warga kelas satu untuk pengembangan aplikasi, jadi ada cerita lintas platform untuk aplikasi yang tidak dibuat untuk Windows/.NET/UWP secara langsung.

Yang dibutuhkan sekarang adalah menyediakan cerita bagi para pengembang C#/.NET/UWP untuk membawa aplikasi dan investasi mereka ke lanskap platform yang lebih luas.

2 sen saya: Saya seorang pengembang Xamarin.Forms, dan (seperti banyak lainnya) tertarik melihat semua dialek XAML digabungkan menjadi satu yang berfungsi di mana saja, termasuk ruang seluler. Tidak yakin bagaimana itu akan turun, tapi setidaknya itulah keinginan saya tentang masalah ini.

WinUI 3.0 dan seterusnya mungkin - tetapi ada terlalu banyak aplikasi WPF di luar sana untuk mengharapkan mereka semua menulis ulang dan menerjemahkan semua XAML itu. Proyek WPF baru dapat menggunakan dialek WinRT XAML yang lebih modern. Anda dapat memperkenalkan padanan DocType ke XAML sehingga dialek yang berbeda dapat hidup berdampingan dalam proyek yang sama.

Lebih mudah diucapkan daripada dilakukan tentu saja.

@mdtauk Saya pikir begitu platform Xaml benar-benar dibuat open-source, kita akan memiliki pemahaman yang lebih jelas tentang apa yang diandalkannya di bagian bawah tumpukan (kita sudah tahu bahwa dependensi khusus platform utama adalah DirectX11, Direct2D dan Windows Media Foundation, tetapi siapa yang tahu bagian mana dari Windows SDK yang digunakan di sana), dan bagaimana lapisannya (sehingga kita dapat memiliki perasaan aktual tentang kelayakan porting apa pun).
Kami juga belum melihat di bawah jenis lisensi apa kode sumber akan didistribusikan. Saya tidak yakin apakah itu sudah diputuskan.

Android menggunakan Vulkan dan saya pikir mendukung OpenGL
iOS dan macOS menggunakan Metal

Adapun codec media, dimungkinkan untuk menggunakan API berbasis C asli sebagai pengganti.

@simonferquel Ini akan menjadi lebih jelas ketika kode

Saya pikir mengubah namespace adalah pendekatan yang masuk akal ketika winui adalah kumpulan kontrol. Namun, sekarang pada dasarnya menggantikan platform, saya pikir ini tidak dibenarkan lagi. Ini sudah bekerja dengan cara yang sama untuk WPF/Winforms, di mana kode dapat dipindahkan dari .net Framework ke .net core tanpa mengubah ruang nama dalam kode. Platform harus secara otomatis dapat memuat versi winui dari dll yang diperlukan saat diaktifkan. Dengan cara ini, kompatibilitas sumber dan biner (saya telah berhasil menggunakan pustaka kerangka kerja .net di aplikasi inti .net) dapat dipertahankan.

Hanya ingin mengucapkan terima kasih semuanya atas komentarnya sejauh ini! Tim WinUI melihat dengan cermat semua tanggapan dan poin.
Kami juga kemungkinan akan membagi beberapa masalah terfokus untuk membicarakan poin-poin spesifik yang muncul (misalnya kompatibilitas dengan kerangka kerja dan komponen UWP yang ada) setelah kami mengatur pemikiran kami.

Saya hanya ingin mengucapkan terima kasih kepada MS karena telah mendengarkan lebih banyak dan memberi pengembang .net alat yang luar biasa, tetapi saya merasa kecewa dengan masa depan UWP Xaml setelah konferensi pembangunan.
Membaca blog ini dan banyak artikel di internet Anda mendapatkan perasaan bahwa UWP menjadi eksklusif "perusahaan" dan bahkan itu bisa diperdebatkan karena banyak perusahaan menjadi lebih OS agnostik memungkinkan pekerja untuk menggunakan misalnya MacBook Pro.

Biar saya perjelas bahwa saya banyak berinvestasi dalam UWP dan Xamarin Forms asli (Android, iOS) dan saya menyukai platformnya, tetapi setelah MS mengumumkan dukungan asli untuk React, saya akan segera melompat.

Saya tahu saya harus membuat aplikasi UWP saya lebih platform agnostik di desktop karena itu saya berharap saya dapat membuat "aplikasi hybrid" dengan aplikasi uwp saya saat ini sebagai shell dan menggabungkan lebih banyak teknologi ujung depan web dengan menggunakan Bereaksi dalam campuran . Sesuatu seperti fitur "Set" yang saya pahami sekarang tertunda karena prioritas yang lebih tinggi dalam Edge, akan ideal untuk solusi saya saat ini karena benar-benar mengaburkan batas antara UWP asli dan teknologi web dengan menjalankan teknologi asli dan web di “tab jendela/tepi”. Pendekatan "hibrida" ini akan memungkinkan saya untuk secara perlahan merangkul teknologi web ke dalam platform saya saat ini, tetapi juga memberi "aplikasi asli" tab di "browser" sehingga dapat dikatakan. (dari perspektif konsumen) Ini juga memberi saya jalan keluar jika "aplikasi uwp asli" gagal dalam jangka panjang di desktop.

Alasan pemikiran di atas adalah UWP tidak memberi saya jalan keluar karena dapat dengan mudah menjadi korban Silverlight berikutnya jika tidak ada kemampuan lintas platform segera. MS melakukan lindung nilai taruhan mereka dengan memastikan mereka tidak kalah dalam tren PWA atau tangan mereka diputar untuk React dukungan asli di Windows. Masalahnya adalah saya bertaruh dengan harapan saat ini akan ada "jalur" untuk UWP/c#/.net ke browser atau lintas platform dan saya dapat menggunakan kembali sebagian besar investasi saya ke platform tersebut.

Saya ingat ketika setiap pengembang di luar sana berteriak beli Xamarin, MS butuh selamanya untuk melakukan itu. Saya pikir sebagian besar pengembang yang akrab dengan perakitan web tahu bahwa baru-baru ini mereka berhasil menjalankan "versi lengkap" Windows Server di perakitan web akan mengatakan membeli platform Uno dan membuatnya besar dengan investasi yang signifikan. Jika OS lengkap dapat berjalan pada perakitan web, MS harus memberikan setiap pengembang .net jalur migrasi ke kemampuan lintas platform untuk melindungi investasi mereka yang ada.

Anda mungkin mengatakan Blazor ada di sana tetapi sejujurnya sebelum saya menginvestasikan lebih banyak waktu di platform baru, saya lebih suka belajar Bereaksi atau Anda mungkin mengatakan kami MS memiliki sumber daya terbatas untuk semua ini. Tentunya ketika Anda membayar $7,5 miliar untuk Github, semuanya menjadi relatif.

Saya pikir sangat penting bagi MS untuk memahami kerusakan reputasi yang disebabkan oleh jalur migrasi yang gagal ke kapabilitas lintas platform untuk investasi UWP/Win32 yang ada. Kemampuan lintas platform harus identik dengan .NET 5 dan tidak. Saya tidak yakin apakah langkah kecil untuk melintasi platform dalam hal ini akan berhasil untuk MS dan percayalah, saya selalu menjadi penggemar berat xaml/.net/c#

Template apa yang paling menarik bagi Anda?

Apakah maksud Anda template proyek atau template item juga?

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Apakah ini hanya pencarian dan penggantian (nilai lebih rendah) atau juga menggabungkan pembaruan dependensi ke versi baru (lebih berharga tetapi tidak yakin bagaimana Anda bisa tahu)

Re: Kompatibilitas mundur untuk fitur baru

Akankah kompatibel dengan Pembaruan Pembuat Konten (15063) menjadi titik referensi tetap atau akankah rencana ke depan untuk mendukung versi saat ini dan jumlah X versi sebelumnya?

Apa artinya ini bagi siapa pun yang membuat ekstensi atau memiliki kontrol atau fungsi yang ingin mereka bagikan secara publik? Apakah mereka perlu mendukung tingkat kompatibilitas mundur itu juga? Bahkan ke Windows 8.1?

Re: Memigrasi namespace

Apakah mungkin untuk memigrasikan UWP yang ada secara bertahap (saya sedang memikirkan halaman) atau apakah perlu memperbarui seluruh aplikasi sekaligus? Jika itu adalah seluruh aplikasi sekaligus yang akan membuat adopsi lebih lambat.

Bagaimana dengan migrasi aplikasi WPF? - Apakah strategi migrasi menggunakan XAML Islands yang bisa menggunakan WinUI 2.x atau 3.x? Bisakah keduanya digunakan dalam aplikasi yang sama?

Ya, membagi masalah ini menjadi beberapa masalah yang lebih terfokus akan membantu menangkap ide dengan lebih jelas dan menghindari garis singgung.

Harap ganti semua contoh UWP dengan nama yang sesuai, karena tidak jelas apa yang Anda maksud.

@mrlacey :

Apakah maksud Anda template proyek atau template item juga?

Template item atau library juga menarik! Ada beberapa poin bagus dalam balasan sejauh ini tentang menyediakan boilerplate tambahan dan kode starter yang merupakan hal lain yang dapat kami pertimbangkan untuk ditambahkan seiring waktu, mungkin seperti Windows Template Studio .

Apakah ini hanya pencarian dan penggantian (nilai lebih rendah) atau juga menggabungkan pembaruan dependensi ke versi baru (lebih berharga tetapi tidak yakin bagaimana Anda bisa tahu)

Pertanyaan bagus - pembaruan ketergantungan seperti apa yang membuatnya lebih berharga? misalnya menemukan versi paket NuGet baru yang kompatibel?

Akankah kompatibel dengan Pembaruan Pembuat Konten (15063) menjadi titik referensi tetap atau akankah rencana ke depan untuk mendukung versi saat ini dan jumlah X versi sebelumnya?

Kami membayangkan rentang versi dukungan berubah seiring waktu berdasarkan penggunaan. Daripada dibatasi pada sejumlah versi tertentu, kami kemungkinan akan terus melihat data penggunaan dan mendukung versi Windows 10 yang paling aktif di pasar.

Apa artinya ini bagi siapa pun yang membuat ekstensi atau memiliki kontrol atau fungsi yang ingin mereka bagikan secara publik? Apakah mereka perlu mendukung tingkat kompatibilitas mundur itu juga? Bahkan ke Windows 8.1?

Saat ini kami tidak membayangkan memaksakan persyaratan tambahan atau "sertifikasi" untuk kontrol khusus. Versi akan terserah Anda. Kisah versi keseluruhan di Pembaruan Mei 2019, WinUI 3.0 dan versi WinUI yang akan datang jelas merupakan topik yang ingin kami bahas lebih mendalam segera.

Apakah mungkin untuk memigrasikan UWP yang ada secara bertahap (saya sedang memikirkan halaman) atau apakah perlu memperbarui seluruh aplikasi sekaligus? Jika itu adalah seluruh aplikasi sekaligus yang akan membuat adopsi lebih lambat.

Pertanyaan bagus - terima kasih telah mencatat itu. Ini juga merupakan topik yang ingin kami bahas lebih mendalam segera.

Harap ganti semua contoh UWP dengan nama yang sesuai, karena tidak jelas apa yang Anda maksud.

@riverar : apakah ada penggunaan atau bagian tertentu yang tidak jelas?

Kami menggunakan istilah " UWP Xaml " untuk merujuk pada platform Xaml yang dikirimkan sebagai bagian dari Windows 10 dan UWP SDK, untuk membedakannya dari platform berbasis Xaml lainnya (misalnya WPF).

Kami juga merujuk ke " model aplikasi UWP " (pengemasan dan pemasangan, manajemen data dan status, siklus hidup runtime, dll.), yang berbeda dari model aplikasi Win32.

Bahkan di Desktop Windows, pengguna menghabiskan banyak waktu untuk Menjelajah Web.
Saya pikir kita membutuhkan cara untuk mengembangkan Aplikasi Web yang layak, menggunakan (subset dari ) UWP vNext XAML + .NET (C#/F#/VB.NET)

Saya mengembangkan di WPF + ClickOnce selama bertahun-tahun, kemudian mulai melihat UWP. Saya suka UWP, tetapi (atau versi berikutnya.) harus dapat menjalankan EXE mandiri, API Jendela yang lebih baik (memungkinkan untuk membuat Aplikasi gaya Jendela Winamp khusus jika kita INGIN), lebih banyak API Pencetakan, interop mudah dengan C dll , OCX, setidaknya sebagian Komponen harus Dijalankan di Web.

Ketika saya melihat UNO, saya berpikir: Microsoft dapat membeli perusahaan ini, dan bergabung dengan para pengembang ini dengan tim UWP dan Xamarin. Saya akan senang jika UWP versi berikutnya menjadi Azure, yang berjalan di Web, Windows, Seluler, dan IoT. IMO bahkan portal Azure dapat ditulis dalam UWP vNext.

Microsoft bisa melakukannya. Anda melakukannya dengan Silverlight, Anda melakukan WPF, Anda melakukan UWP, Anda melakukan Xamarin. Sekarang saatnya untuk kerangka kerja GUI XAML terbaik. Dan, menurut saya, Web harus didukung, setidaknya sebagian dari fungsionalitasnya.

_INNotifyDataErrorInfo_

Tolong jangan memperkenalkan ruang nama baru untuk hal-hal seperti _INotifyDataErrorInfo_ - itu harus digunakan dalam model tampilan yang biasanya lintas platform dan tidak boleh memiliki ketergantungan pada WinUI. Itu harus ditentukan di mana hal-hal lain seperti ini berada (yaitu _INotifyPropertyChanged_ atau _INotifyCollectionChanged)_

Tentang topik ini. Windows.UI.Xaml.Interop sudah memiliki antarmuka INotifyCollectionChanged dan Windows.UI.Xaml.Data memiliki INotifyPropertyChanged. Keduanya akan dipindahkan ke ruang nama Microsoft. Mungkin rakitan System.Runtime.WindowsRuntime dapat melakukan pemetaan dari WinUI ke .Net

Satu-satunya hal yang ingin saya tambahkan jika belum ditambahkan adalah, saya 100% mendukung model paket MSIX/Appx dan Win10 telah melakukan pekerjaan yang fantastis untuk memperbaiki masalah instalasi dan penghapusan selama masa pakai windows. Namun, saya selalu berjuang untuk membangun aplikasi "UWP" karena subset aneh dari pilihan API yang tersedia yang dibuat di kotak pasir AppContainer. Sebagai pengembang C++, itu membuat frustrasi dan setiap tahun melihat Anda membuka kotak pasir lebih jauh untuk memungkinkan set API Win32 lengkap telah melegakan.

Jadi jika WinUI 3.0 memungkinkan saya membangun aplikasi dengan akses ke 100% dari tumpukan Win32, maka ini akan menjadi emas! Saya sudah mencoba menggunakan XamlIslands sekarang, dan ini adalah pintu keluar yang fantastis, tapi itu tidak stabil bagi saya dan ada beberapa pekerjaan yang tersisa sebelum benar-benar melintasi garis finish.

Mendapatkan templat proyek yang memungkinkan saya membangun aplikasi Win32, tanpa dimasukkan ke dalam proses AppContainer, dan membiarkan saya mengakses semua kemajuan yang Anda buat dengan UI, maka WinUI 3 akan sangat cocok untuk saya.

@eklipse2k8 Masih perlu ada sistem izin untuk mengakses file dan perangkat pengguna, bahkan di kotak pasir yang santai. Juga saya pikir harus ada aturan untuk tetap di userland dan menghindari peningkatan akses admin dan kernal - tanpa semacam pengujian resmi dan persyaratan penandatanganan kode.

Halo Microsoft,

Saya tidak tahu seberapa besar pengaruh posting ini terhadap topik Font Rendering , ClearType , DirectWrite dan masa depan Windows UI tapi saya salah satu dari sedikit tapi vokal & bersemangat yang memiliki beberapa keluhan serius dengan subsistem rendering font di jendela.

Ini didokumentasikan dengan baik hampir di mana-mana di Internet orang frustrasi (atau kepuasan) dengan Windows UI dan rendering font. Anda akan menemukan beberapa orang yang menyukai penghalusan font, dan Anda akan menemukan orang lain yang benar - benar

Saya di sini bukan untuk membahas apakah yang satu lebih baik dari yang lain. Saya juga tidak di sini untuk membahas peretasan registri, 'penyetel font', atau bagaimana saya dapat mengubah pengaturan OS untuk membuat font tampak lebih baik. Percayalah, saya telah melakukan semuanya; bahkan melakukan penelitian untuk menulis driver mode kernel untuk menambal fungsi DirectWrite dalam mode kernel.

Saya di sini karena saya memiliki kondisi medis optik yang sangat umum yang disebut miopia / rabun jauh . Aku bisa melihat sesuatu dengan jelas dari dekat. Tapi hanya pada jarak lengan, visi saya tepat di tepi ketajaman visual saya dan di mana teks mulai menjadi kabur.

Di luar jarak lengan, saya perlu memakai lensa korektif. :eyeglasses: Saya yakin kita semua sadar, layar komputer desktop berada pada jarak yang dekat. Oleh karena itu masalahnya.

• Font yang terlihat halus, terlihat buram bagi saya.
• Font dengan tepi yang tajam (snapped-to-pixel) terlihat lebih jelas bagi saya.

Saat font diubah menjadi piksel, tepi yang tajam merupakan sinyal visual ke otak saya bahwa penglihatan saya tidak fokus.

Sebagai sesama pengembang yang menghabiskan waktu lama untuk menulis kode dan melihat teks, itu membuat frustrasi dan sakit sekali. Ini adalah alasan utama mengapa saya masih menjalankan Windows 7 dan bukan Windows 10 . Hampir semua UI Metro utama Windows 10 menggunakan penghalusan font di mana-mana.

Untuk mengilustrasikan masalah penghalusan font ini, mari kita lihat snap-in MMC services.msc di Windows 7 :

Apakah Anda melihat teks buram yang terlihat tidak fokus? Di Sini. Mari kita perbesar sedikit lebih dekat...

Ya ampun, anggun rasanya seperti sedang melihat teks dengan mata juling dalam autostereogram .

Ternyata, dalam kasus khusus ini, menggali melalui hierarki kontrol jendela ini, snap-in MMC menghosting kontrol DHTML/ActiveX Internet Explorer yang menampilkan teks kabur di panel "pilih item untuk melihat deskripsinya". Menu "Bantuan" dan daftar layanan yang tajam (snapped-to-pixel), ditampilkan dengan primitif USER32 dan GDI32 normal.

Contoh kecil ini menyoroti salah satu masalah terbesar dengan rendering font di Windows. Ternyata IE8 akan menghormati pengaturan sistem operasi global yang menonaktifkan ClearType dan penghalusan font. Namun, jika Anda menginstal IE9 atau lebih tinggi, IE9+ akan dengan senang hati mengabaikan semua dan SEMUA upaya untuk menonaktifkan penghalusan font. IE9+ tidak peduli dan memaksa semua pengguna untuk melihat teks di situs web (dan di kontrol ActiveX) dengan teks yang dihaluskan font.

Masalahnya menjadi lebih buruk bagi pengguna seperti saya karena seiring berjalannya waktu, kelahiran Windows 8 dan Windows 10, Aplikasi Metro, WPF dan UWP semuanya mengambil pendekatan yang sama seperti IE9+. Semua teknologi UI di bawah tenda mengabaikan pengaturan sistem operasi global yang harus dihormati pada mesin kami. Jika kami menonaktifkan ClearType dan penghalusan font pada tingkat seluruh sistem operasi, kami mengharapkan API ClearType dan DirectWrite (dan akibatnya, aplikasi Metro, WPF, dan UWP) tidak menggambar dengan penghalusan font apa pun.

Aku tahu aku bukan satu-satunya dengan masalah ini.

Beberapa waktu lalu, Google Chrome melakukan hal yang sama dengan rilis v31 mereka dan mencoba mengikuti pendekatan IE9+ dan mengalihkan semua rendering font ke DirectWrite dengan mengabaikan pengaturan seluruh sistem global. Perubahan ini membuat Internet marah. Lihat Edisi Chromium 319429 . Akhirnya, setelah banyak kertakan gigi, Google membalikkan arah dan memperbaiki masalah di Chrome 37 untuk para pengguna dengan gangguan penglihatan rabun dan sekarang menghormati pengaturan seluruh sistem operasi yang menonaktifkan penghalusan font.

Berkat kekuatan yang ada dan kekuatan pasar, Microsoft kalah dalam perang browser dan sekarang mengadopsi mesin rendering Chromium, tetapi saya yakin bahwa tim Edge akan menghormati pengaturan penghalusan font yang dinonaktifkan.

Saya di sini hanya untuk menganjurkan bahwa Microsoft memerlukan satu pengaturan global yang perlu dihormati , untuk semua aplikasi di sistem operasi, di semua tumpukan UI , bagi mereka yang memiliki masalah ketajaman visual.

Dan sebagai pengingat ramah, ini adalah masalah aksesibilitas untuk Windows UI secara umum, bukan salah satu preferensi visual.

Berdasarkan prevalensi miopia di seluruh dunia, dapat diperkirakan bahwa lebih dari 22% populasi dunia saat ini, yaitu 1,5 miliar orang menderita miopia. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Terima kasih,
Brian

:walking_man: :walking_woman: Orang Hilang - Berjalan di LA

Ini berarti bahwa kerangka kerja Xaml lengkap akan dikembangkan di GitHub dan dikirimkan sebagai paket NuGet .

NuGet hebat, tetapi mendukung vcpkg (dan CMake ) juga akan dihargai (bagi kita yang memiliki pustaka lintas platform besar yang sudah ada).

Template apa yang paling menarik bagi Anda?

Dalam urutan preferensi:
Win32 + Xaml Desktop + WinUI
Win32 + Kepulauan Xaml + WinUI
UWP + WinUI

Apakah Anda mengetahui Xaml Islands untuk memodernisasi aplikasi desktop?Apakah kompatibilitas mundur yang diperluas ini pada Windows 10 membuat Xaml Islands lebih berguna bagi Anda?

Ya, Kepulauan Xaml menarik, tetapi karena kami menargetkan konsumen, dan bukan pelanggan perusahaan, kompatibilitas mundur yang diperluas bukanlah pemecah kesepakatan - sebagian besar pelanggan cukup senang memperbarui OS mereka (dan diberikan skala waktu untuk menerapkan perubahan berdasarkan WinUI baru Xaml, menguncinya hingga 1903 mungkin berarti sudah keluar setahun).

Namespace root untuk Xaml, komposisi, dan input API di WinUI akan berbeda dari namespace root Windows UWP SDK:

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Ini tidak mempengaruhi saya, karena kami tidak memiliki aplikasi UWP (saat ini menggunakan WPF untuk penjualan langsung dan WPF + Desktop Bridge untuk toko), tetapi mengubah ruang nama adalah satu hal, dan bahkan di basis kode terbesar, pencarian dan penggantian global untuk Windows::UI::Xaml tidak terlalu menakutkan (kita semua menggunakan kontrol versi kan..?).

Jalur tercepat untuk merilis WinUI 3.0 adalah dengan tidak mendukung pencampuran:

Tidak masalah bagi saya, mereka harus diperlakukan sebagai perpustakaan terpisah yang tidak kompatibel. Anda juga menargetkan UWP Xaml, atau WinUI Xaml. Seperti disebutkan di atas, konversi satu kali seharusnya tidak terlalu sulit.

Namun, salah satu kekhawatiran terbesar kami adalah masalah kompatibilitas dan pekerjaan yang dapat dibuat untuk aplikasi UWP dan pustaka komponen yang ada, terutama jika Anda membuat atau menggunakan pustaka kontrol UWP Xaml.
Misalnya, versi Toolkit Komunitas Windows yang ada tidak akan dapat digunakan di aplikasi WinUI 3.0, jadi Toolkit dan aplikasi apa pun yang menggunakannya perlu diperbarui sebelum menggunakan WinUI 3.0.

Microsoft perlu memilih teknologi dan tetap menggunakannya. Selama bertahun-tahun kami telah dijanjikan kerangka kerja UI desktop terbaru dan terhebat (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml, dan sekarang WinUI Xaml). Meskipun pilihannya bagus, ini mengarah pada fragmentasi fungsionalitas dan pengetahuan pengembang. Jauh lebih mudah untuk memiliki satu sesi / satu halaman web / satu jawaban stackoverflow untuk mengimplementasikan fitur di Windows, vs 7 yang berbeda tergantung pada teknologinya. Jika WinUI Xaml adalah masa depan, Toolkit Komunitas perlu diperbarui untuk memanfaatkannya.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

Saya telah menunda melakukan apa pun dengan UWP Xaml karena fungsinya tidak ada (dibandingkan dengan Win32/WPF), dan saya berasumsi saya tidak sendirian dalam hal itu. Dengan demikian, kompatibilitas penuh tidak menjadi masalah.

Apakah Anda membuat atau menggunakan pustaka kontrol UWP Xaml atau komponen WinRT yang tidak dapat Anda kompilasi ulang dan perbarui dengan mudah bersama kode aplikasi?

Tidak.

Apa solusi pilihan Anda untuk menggunakan komponen UWP Xaml dengan WinUI 3?

T/A

1. Apa pendapat Anda tentang keseluruhan rencana 3.0 yang diuraikan di atas dan di peta jalan ? Apakah ini memungkinkan Anda menggunakan WinUI untuk aplikasi Windows baru dan yang sudah ada?

Tidak disebutkan Xaml Desktop di peta jalan. Apakah ini termasuk dalam kewenangan WinUI?
Saya telah menyebutkan ini sebelumnya kepada orang-orang di //Build/, tetapi alasan untuk tidak mengadopsi UWP Xaml sebelumnya adalah karena tidak mungkin membuat aplikasi yang menggunakan pustaka C++ yang ada. Misalnya, ketika pengguna memilih file dengan FileOpenPicker , hasilnya dikirim sebagai IStorageFile , dan tidak ada cara untuk meneruskan ini ke perpustakaan pihak ke-3 yang ada untuk dibuka (misalnya libpng , libjpeg , dll). Inilah mengapa kami harus tetap menggunakan WPF, jadi jika Xaml Desktop atau Win32 + Xaml Islands memungkinkan kami untuk hidup tanpa batasan ini, maka ya, itu akan memungkinkan kami menggunakan WinUI untuk aplikasi baru.

1. Jenis aplikasi apa yang paling membuat Anda tertarik untuk menggunakan WinUI 3.0? Membuat aplikasi Win32 baru dan mengemasnya dengan MSIX ? Menambahkan tampilan baru ke aplikasi WPF? Memodernisasi aplikasi C++ MFC dengan UI Lancar?

Membuat aplikasi Win32 baru dengan WinUI (dan mengemas dengan MSIX).

Jika Anda memiliki pertanyaan, beri tahu saya, saya senang berdiskusi lebih lanjut.

Sebenarnya berharap ada cara untuk memanggil Compact Overlay dari WPF/WinForms.
Kami hanya membutuhkan sistem izin administrator seperti "Draw over other apps permission" di Android.

Semoga model + pengemasan aplikasi ini (UWP + AppX, Win32 + MSIX) memungkinkan itu (Abstraksi Penuh di dalam Sandbox)

Bukankah Windows seharusnya menjadi kemungkinan yang paling canggih dan tidak terbatas, dengan keamanan terbaik?
Tidak dengan fitur lumpuh untuk keamanan.

Terima kasih telah membuka diri kepada masyarakat atas masukan terkait roadmap tersebut.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

To the point, kami memiliki cukup banyak aplikasi UWP yang digunakan untuk klien perusahaan saat ini, dan saya harap jalur migrasi tidak akan terlalu sulit. Jika ada perubahan yang mengganggu Akan sangat bagus untuk memiliki alat migrasi yang mirip dengan .Net Framework ke .Net Core yang menghasilkan seberapa kompatibel jalur migrasi kita, ini akan melaporkan apa pun yang mungkin perlu diubah ( misalnya API yang mungkin tidak digunakan lagi atau berperilaku berbeda) dan opsi untuk mengubah namespace secara otomatis jika memungkinkan. Dengan cara ini jalur migrasi untuk UWP ke WInUI tidak akan bergejolak bagi kami pengembang perusahaan.

Apakah Anda mengetahui Pulau Xaml untuk memodernisasi aplikasi desktop?
Apakah kompatibilitas mundur yang diperluas ini pada Windows 10 membuat Xaml Islands lebih berguna bagi Anda?

Ya, tetapi tidak terlalu menjadi masalah karena semua aplikasi desktop kami yang baru dikembangkan menggunakan komunikasi UWP melalui backend API, dan sebagian besar klien kami sudah menjalankan Windows10.

Apa pendapat Anda tentang keseluruhan rencana 3.0 yang diuraikan di atas dan di peta jalan? Apakah ini memungkinkan Anda menggunakan WinUI untuk aplikasi Windows baru dan yang sudah ada?

Tim desktop sudah senang dengan berita WinUI 3, tetapi seperti yang dinyatakan di atas takut akan migrasi semua Aplikasi UWP kami ke sana jika jalannya tidak semulus itu.

Adapun XAML umum karena seluruh kerangka kerja UI XAML akan hidup dipisahkan dari Windows seperti yang telah disuarakan orang lain sehingga memungkinkan untuk menukar penyaji. Ini akan membuka kemungkinan menjalankan WinUI XAML pada platform lain yang merupakan faktor penentu yang sangat besar saat ini ketika orang memilih tumpukan untuk digunakan, sebagaimana dibuktikan dengan popularitas kerangka kerja Electron dan JS yang memanfaatkannya untuk perusahaan kecil yang tidak memiliki tenaga kerja untuk secara khusus mengembangkan basis kode asli untuk setiap platform.

Juga tambahkan bahwa dengan WinUI 3 dan seterusnya juga harus meningkatkan dialek XAML, mungkin memperkenalkan namespace versi / Doctype untuk menentukan versi XAML mana yang digunakan sehingga untuk menjaga kompatibilitas mundur untuk aplikasi yang lebih lama. Ada banyak hal yang harus dilakukan untuk membuat XAML kurang bertele-tele atau memotong beberapa boilerplate, seperti harus menulis INotifyPropertyChanged dengan mendukung setter pribadi untuk satu alih-alih hanya menjadi atribut properti sederhana, katakan NotifyPropertyChangedAttribute dan biarkan membangun langkah menyuntikkan implementasi untuk menghindari overhead runtime atau DependencyProperties untuk kontrol kustom untuk menyederhanakan pembuatan komponen. Mungkin juga mengambil beberapa perbaikan pada tim Razor untuk beberapa bagian bagus yang mereka miliki.

Permintaan ini mungkin atau mungkin tidak layak, tetapi saya menyukai XAML dan akan senang untuk terus meningkatkannya, jadi saya akan menyatakan beberapa poin kesulitan (tetapi masih dapat digunakan) yang saya dan beberapa tim kami miliki saat mengembangkannya.

@mdtauk Saya tidak menentang keamanan file tetapi kernel yang mendasarinya harus mencegah Anda menulis di tempat-tempat yang tidak Anda izinkan daripada menggunakan set API yang sama sekali baru dan mengabaikan API file win32. Juga, saya tahu ini keluar dari topik, tetapi api StorageFile/StorageFolder adalah pengganti yang mengerikan, bahkan tidak memperhitungkan keamanan file. Mereka lambat dan Anda selalu diproksi melalui broker file runtime. Lebih lanjut, seharusnya tidak ada batasan bahwa aplikasi kotak pasir memerlukan izin khusus yang disetujui MS untuk menulis di folder dokumen pengguna. Sebagai contoh betapa buruknya cerita file untuk upaya AppContainer, tidak mungkin membuat DB sqlite di mana pun kecuali di folder LocalData tersembunyi pengguna. Untuk sistem desktop di mana pengguna ingin membuat, menyimpan dan membuka file, dan menyimpan sebagai, yadda yadda, hal itu membebani pengembang perangkat lunak yang mereka butuhkan untuk melatih kembali pengguna mereka cara mengelola konten pengguna.

Sejauh akses administrator, rilis Oktober 2018 menambahkan "allowsElevation" sebagai hak, yang masuk akal. Sebuah aplikasi dapat memungkinkan pengguna untuk menjalankan sebagai administrator jika mereka membutuhkan akses tingkat sistem yang luas untuk beberapa set fitur. Kami tidak semua membangun editor foto kecil yang lucu dan aplikasi diagram alur.

@MarkIngramUK Terima kasih atas komentar Anda, Hanya satu klarifikasi. Konsep Desktop Xaml yang disajikan dalam Sneak Peek di //Build 2019 telah diubah namanya menjadi WinUI Desktop. Proyek Visual Studio baru ini akan menggunakan model aplikasi Win32, dengan WinUI sebagai kerangka presentasi, dan dapat asli atau dikelola (menggunakan .NET Core 3).

Terima kasih @marb2000 - apakah ini dalam jangka waktu WinUI 3.0?

@marb2000 oleh WinUI Desktop, maksud Anda aplikasi Win32 dengan Xaml Islands? Di sesi build mana ini ditampilkan?

Satu hal yang harus diperhatikan oleh tim WinUI dengan penggantian nama WinUI 3.0: Jika Anda mengganti nama salah satu jenis yang diproyeksikan di .NET, maka proyeksi tidak akan berfungsi (dan kami tidak berencana menambahkan lagi karena tidak sistem yang dapat diperluas yang dapat dipelihara). Berikut daftar jenis yang kami proyeksikan: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Setiap perubahan pada tipe yang berbeda dari tipe ini akan mengharuskan pengguna untuk membungkus objek mereka dalam objek baru yang mengimplementasikan antarmuka baru atau menyalin data mereka ke tipe baru. Secara khusus, tipe INotifyPropertyChanged dan INotifyCollectionChanged menarik sehubungan dengan Pulau XAML dan memberikan dukungan hilir.

INotifyDataErrorInfo

Tolong jangan perkenalkan ruang nama baru untuk hal-hal seperti INotifyDataErrorInfo - itu harus digunakan dalam model tampilan yang biasanya lintas platform dan tidak boleh memiliki ketergantungan pada WinUI. Itu harus didefinisikan di mana hal-hal lain seperti ini berada (yaitu INotifyPropertyChanged atau INotifyCollectionChanged)

Tentang topik ini. Windows.UI.Xaml.Interop sudah memiliki antarmuka INotifyCollectionChanged dan Windows.UI.Xaml.Data memiliki INotifyPropertyChanged. Keduanya akan dipindahkan ke ruang nama Microsoft. Mungkin rakitan System.Runtime.WindowsRuntime dapat melakukan pemetaan dari WinUI ke .Net

Terima kasih atas jawabannya, tetapi mengapa Anda membutuhkannya di namespace Microsoft jika .NET Standard sudah memilikinya di System.ComponentModel? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky. NET hanya satu kerangka kerja yang dapat Anda gunakan untuk membuat aplikasi dengan UWP XAML. Mereka ingin validasi bidang teks tersedia untuk Pengembang, apa pun kerangka kerja yang mereka gunakan

@mdtauk , tidak, WinUI Desktop (sebelumnya Xaml Desktop) memungkinkan Anda untuk menggunakan Xaml dengan Win32 secara langsung, tanpa menggunakan pulau.

@marb2000 Akan sangat bagus jika Proyek Pengemasan Aplikasi memungkinkan Anda membangun AppX dengan jendela Win32 dan menyertakan komponen WinRT dengan cara yang sama mudahnya dengan proyek UWP. Ada banyak hal yang tidak berfungsi tanpa mengedit file vcxproj secara manual seperti menambahkan sumber daya dan kompiler cppwinrt menghasilkan header dari komponen WinRT yang disertakan.

Proyek lain yang penting untuk UI baru ini adalah _PropertyChanged.Fody_ oleh Simon Cropp yang memungkinkan implementasi otomatis INotifyPropertyChanged (saya mencoba dengan C# / F#). Lihat https://github.com/Fody/PropertyChanged

Ini memungkinkan kode sederhana seperti ini:

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

    public event PropertyChangedEventHandler PropertyChanged;
}

yang bisa kita gunakan untuk Mengikat ke UI.

Satu hal yang ingin saya lihat di WinUI 3.0: Saat ini, kompiler UWP XAML ( genxbf.dll ) hanya dapat dipanggil langsung oleh MSBuild ketika dirujuk dari file csproj, vbproj, atau vcxproj. Ini karena tidak ada alat baris perintah yang dapat digunakan untuk menjalankan fungsi ini. Ini menurut saya sebagai keputusan yang sangat aneh, karena tidak ada hal lain dalam unduhan Windows 10 SDK yang memerlukan Visual Studio. (Pengaya WDK juga menyertakan target Visual Studio, tetapi target tersebut semua memanggil alat baris perintah yang dapat digunakan secara independen dari VS.) Saya akan sangat menghargai penambahan misalnya XbfCompiler.exe dan XbfCodeGen.exe ke direktori bin SDK. (EXE sebelumnya akan mengkompilasi file XAML ke file XBF, dan yang terakhir akan menghasilkan file di belakang kode yang diperlukan untuk mereferensikan tipe XAML dari kode.) Ini akan sangat berguna dalam proyek C++ yang menggunakan CMake atau non-Visual lainnya. Alat pembuatan studio, tetapi juga dapat digunakan untuk proyek C# dan VB.NET jika diperlukan. Terima kasih!

@MarkIngramUK apakah Anda tahu di mana saya bisa mempelajari lebih lanjut tentang WinUI Desktop. Sesi Build 2019 tersebut tidak tersedia untuk ditonton secara online. Kedengarannya seperti informasi penting yang harus ditautkan dalam repo ini

@mdtauk Disebutkan dalam apa yang disebut Sneak Peek, yang hanya untuk peserta Build. Afaik tidak ada rekaman. Saya juga tidak ada di sana, tapi ada slide - mungkin slide terbaik :-) - tersedia di Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk Peta jalan WinUI 3 memiliki informasi dan diagram terbaru yang bahkan lebih mutakhir daripada apa yang ditampilkan di sneak peek Build. Tidak ada yang namanya "XAML Desktop" atau "WinUI Desktop"... itu hanya pilihan kata yang membingungkan pada slide yang difoto. Konsep yang dikomunikasikan (dan peta jalan mencoba menjelaskan ini dengan lebih jelas) adalah bahwa untuk WinUI 3 kami bekerja untuk membuatnya sehingga Anda dapat memiliki templat proyek yang membuat aplikasi model Desktop/Win32 tradisional baru menggunakan WinUI 3 untuk UI-nya (sama seperti hari ini ada templat untuk kerangka kerja UI seperti WinForms, WPF, MFC, dll. di atas model Desktop/Win32 tradisional) selain templat proyek aplikasi model UWP/WinRT yang diperbarui yang menggunakan WinUI 3. Apakah itu bantu klarifikasi?

Peta jalan 3.0 tampaknya cukup masuk akal untuk strategi berikut: aktifkan aplikasi klien Windows apa pun untuk menggunakan XAML dan kontrol WinUI "modern".

Namun, strategi ini tampaknya picik jika kita mempertimbangkan realitas pasar saat ini: untuk banyak pengembangan aplikasi, Android dan iOS adalah target utama, dan Windows bagus untuk dimiliki. Untuk pengembang .NET, Xamarin memberi Anda dukungan Android dan iOS yang layak, tetapi dukungan Windows mereka di bawah standar. Jadi untuk aplikasi seluler/desktop asli, Win UI 3.0 tidak menyederhanakan pengembangan lintas platform untuk pengembang .NET.

Apa yang benar-benar ingin saya lihat adalah dialek XAML yang maju dengan aspirasi yang benar-benar universal. Saya seharusnya bisa menulis aplikasi .NET menggunakan XAML, dan menjalankan aplikasi itu di Windows, iOS, dan Android. Aplikasi harus benar-benar kelas satu di setiap platform dan memiliki akses ke elemen asli sesuai kebutuhan. Seperti disebutkan, Xamarin adalah awal yang baik, tetapi dialek XAML-nya sangat berbeda, ia memiliki dukungan Windows yang buruk, dan tidak ada pekerjaan yang Anda lakukan yang membantu.

Jadi, tldr, bagus bahwa Anda terus menyediakan platform UI modern untuk Windows. Bagus bahwa Anda membuatnya lebih mudah digunakan dari berbagai jenis aplikasi. Buruk bahwa Anda tidak bercita-cita untuk dukungan lintas platform.

Secara opsional, nonaktifkan atau keluar dari perilaku siklus hidup aplikasi seluler lama, seperti menangguhkan + batu nisan.

Kenyataannya adalah bahwa UWP adalah lingkungan desktop dan setidaknya untuk game, pengguna mungkin sering meminimalkan aplikasi yang biasanya mengarah pada penangguhan/pemblokiran aplikasi. Ini adalah pengalaman yang menggelegar dan sangat berbeda dari aplikasi atau game desktop win32 mana pun. Meminta perpanjangan penangguhan, yang kemungkinan masih akan berakhir, tidak cukup untuk menangani hal ini dengan mulus.

Meskipun siklus hidup ini berguna untuk beberapa aplikasi, itu merugikan orang lain. Idealnya, aplikasi atau game desktop harus dapat mendeklarasikan kemampuan yang memungkinkan aplikasi menyisih dari model siklus hidup penangguhan+batu nisan, yang akan mencegahnya akhirnya ditangguhkan saat diminimalkan.

@namonster

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

Pada perangkat desktop, sesi eksekusi yang diperpanjang yang dibuat dengan ExtendedExecutionReason.Unspecified memiliki batas waktu penggunaan baterai. Jika perangkat terhubung ke listrik dinding, tidak ada batasan panjang periode waktu eksekusi yang diperpanjang. Jika perangkat menggunakan daya baterai, periode waktu eksekusi yang diperpanjang dapat berjalan hingga sepuluh menit di latar belakang.

Pengguna tablet atau laptop bisa mendapatkan perilaku berjalan lama yang sama--dengan mengorbankan masa pakai baterai--bila opsi Izinkan aplikasi menjalankan tugas latar belakang dipilih di Penggunaan baterai oleh pengaturan aplikasi.

@TonyHenrique ketika Anda menyebutkan Fody , apakah ini karena Anda ingin menciptakan kesadaran akan hal itu, atau apakah Anda mengatakan itu harus dibangun di WinUI?

Template item atau library juga menarik! Ada beberapa poin bagus dalam balasan sejauh ini tentang menyediakan boilerplate tambahan dan kode starter yang merupakan hal lain yang dapat kami pertimbangkan untuk ditambahkan seiring waktu, mungkin seperti Windows Template Studio.

@Jesbis Saya adalah kontributor inti untuk Windows Template Studio dan saya menonton peta jalan WinUI dengan pandangan terhadap apa yang kami lakukan di masa depan dan bagaimana kami memperkenalkan dukungan untuk WPF. ;)

pembaruan ketergantungan seperti apa yang akan membuatnya lebih berharga? misalnya menemukan versi paket NuGet baru yang kompatibel?

Mampu mendeteksi pembaruan NuGet akan lebih berguna tetapi ada masalah kompatibilitas potensial lainnya dengan mengambil pembaruan. Saya akan menjadikan deteksi versi baru dan konversi otomatis sebagai prioritas rendah. Ada begitu banyak pertimbangan bahwa itu akan menjadi proyek besar dalam dirinya sendiri dan saya lebih suka melihat waktu yang diinvestasikan dalam platform daripada alat seperti ini.

@mrlacey Saya menyebutkan Fody karena saya pikir ini adalah solusi yang menarik dan kami membutuhkan cara yang lebih baik untuk menghindari kode boilerplate _INotifyPropertyChanged_. Akan lebih baik untuk memiliki solusi yang didukung MS untuk konsep objek Reaktif ini yang secara otomatis memunculkan peristiwa ketika beberapa properti berubah.
Ini bekerja pada kelas C# dan bahkan pada F# Records (tetapi mengalami beberapa kesulitan).
Jadi di peta jalan WinUI juga harus ada ini.

Catatan: Akan lebih baik jika kita juga bisa menggunakan catatan F# untuk mendefinisikan entitas data kita dan Bind kemudian langsung ke UI XAML. Akan lebih keren jika kita bisa menggunakan F# Records + Fody + DataBinding tanpa masalah .

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

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

Ini akan lebih akrab bagi orang-orang yang berasal dari C#.
Pendekatan lain adalah cara Elmish. Menurut saya keduanya menarik, dan bisa didukung.

@tonyhenrique / @mrlacey Saya pikir hal-hal Fody (OAP) harus di luar jangkauan. Tim WinUI sudah memiliki cukup banyak di piring mereka, dan saya pikir lebih baik memiliki tenun di proyek terpisah (siklus rilis jauh lebih cepat jika ada perbaikan).

Dan saya pikir ini sebenarnya adalah detail implementasi .NET (IL) dari model, sebenarnya tidak ada hubungannya dengan WinUI (meskipun dapat mendengarkan acara perubahan). Saran saya adalah untuk memisahkan mereka. Misalnya, saya menggunakan Catel dan memiliki penenun Fody sendiri untuk memastikan semuanya ditenun dengan benar.

Apa yang benar-benar ingin saya lihat adalah dialek XAML yang maju dengan aspirasi yang benar-benar universal. Saya seharusnya bisa menulis aplikasi .NET menggunakan XAML, dan menjalankan aplikasi itu di Windows, iOS, dan Android. Aplikasi harus benar-benar kelas satu di setiap platform dan memiliki akses ke elemen asli sesuai kebutuhan.

Ada proposal lama untuk menuju ke arah itu: UX lintas platform untuk .NET 5 - judul asli Cross platform UX for .NET Core 3.0 . Dukungan luar biasa dari komunitas sudah jelas dan kami berharap MSFT akan menyadari bahwa ini adalah arah terbaik untuk mengembangkan kerangka kerja UI apa pun yang bekerja di .NET. Hampir tidak ada alasan untuk menyimpan basis kode terpisah untuk grup platform yang berbeda dan secara paksa membuat kumpulan keterampilan pengembang terpisah berdasarkan kerangka kerja UX yang berbeda yang didukung oleh .NET.

Dengan membuat UX tunggal untuk semua platform, kami membatalkan semua inefisiensi dalam pengembangan kerangka kerja dan menurunkan hambatan untuk adopsi pengembang.

@mfeingol / @4creators , saya akan puas

Aplikasi harus benar-benar kelas satu di setiap platform

pada Windows untuk memulai dengan...

Ini tahun 2019, saya menginginkan UI asli yang cepat, dan saya tidak ingin terlalu mempertimbangkan untuk membuat antarmuka pengguna dengan CreateWindowExW , GDI, dll.

Sekarang dengan WinUI3.0 dan di atasnya kode dipisahkan dari Windows 10, apakah ada rencana di masa depan untuk WinUI bekerja di Linux dan Mac?

Interaksi @jesbis Touch akan disimpan di WinUI 3.0?

Terima kasih atas klarifikasinya, saya berasumsi cara 3.0 akan bekerja adalah dengan memasukkan Xaml Islands di WinUI, daripada menggunakan Community Toolkit.

Dengan menjadi XAML plus Win32, itu lebih masuk akal, terutama dengan OS Windows Core yang menulis ulang shell-nya di XAML.

Seperti yang saya pahami sekarang, akses API Win32 yang kaya ini ada di C dan C++ | dengan apa pun di C# mengandalkan .NET (semuanya sekarang .NET Core).

Mungkin harus ada cara yang aman dan sederhana untuk mengakses API Win32 ini, serta lebih banyak titik masuk untuk menampilkan UI aplikasi?

• Sistem Tray XAML flyout untuk aplikasi WinUI 3

• UI Picker sederhana untuk Hololens/Xbox/Surface Hub/IoT, dll

• Dialog File Umum XAML yang dapat disesuaikan, dan pemetik folder

• akses C# .NET sederhana ke API Win32

• pengaturan ringkas untuk semua elemen XAML, yang cocok dengan ukuran kontrol Win32 dan WPF (ini akan membantu Kerangka untuk duduk bersama dengan nyaman)

• pencocokan gaya kontrol/font/kuas aksen/akrilik saat menggunakan WinUI

• definisi yang jelas tentang perangkat mana yang memerlukan siklus hidup WinRT/Mobile

• Gaya kontrol Xbox Next bawaan untuk pengembangan dan pengujian aplikasi Xbox di Windows

• Penyimpanan dan pengemasan dan pengunduhan exe/MSI/APPX tunggal didukung secara default, NO INSTALLERS, virtualisasi sistem file tipe seratus tahun secara default

• WinForms WinUI 3.0 - UI sederhana, akses ke MFC, mouse dan keyboard saja

• WPF WinUI 3.0 - UI padat, rendering 3D, sadar DPI, sentuhan simulasi, dan dukungan tinta dasar

• Xaml WinUI 3.0 - sentuhan penuh, MR, gamepad, tinta, suara, mouse, keyboard. UI yang padat dan sederhana. Dukungan windowing baru. Rendering MR 3D. Siklus hidup terkelola opsional, atau siklus hidup desktop. Terbaik dari semua dunia default untuk shell dan aplikasi kotak masuk ulang, dengan versi Win32 aplikasi kotak masuk seperti notepad, charmap, cat, file explorer - open source dan tersedia dari toko.

Interaksi sentuh akan disimpan di WinUI 3.0?

@ r7dev ya, rencananya adalah untuk menjaga tingkat dukungan sentuhan yang sama.

F# diabaikan pada peta jalan WinUI 3.0. Microsoft mengabaikan salah satu produknya sekali lagi.

Win32 API Pikiran

Sesuatu yang juga saya pikirkan adalah alasan win32 telah bertahan juga. Saya pikir ada asumsi bahwa ini karena proyek warisan, tetapi sebenarnya lebih dalam dari itu. Win32 ABI sangat mudah untuk dihubungkan dengan bahasa pilihan Anda, nodejs, python, rust, go, ruby, c#, c++, dll. dll. Jika proyek inti saya berkarat misalnya, dan saya ingin membuat jendela untuk mengelola output, sebagai pengembang karat, sangat kuat untuk mengakses set API win32 dan membangun ujung depan dalam bahasa yang sama.

Di OS X, untuk mengakses AppKit Anda hanya perlu menjembatani objc_msgSend C API dan mendapatkan akses ke seluruh infrastruktur obj-c. Semua bahasa di atas melakukan pekerjaan yang sangat baik untuk menjembatani itu dan membuatnya mudah untuk menulis dalam bahasa pilihan Anda dan menghasilkan sesuatu yang menarik.

Jadi, jika Anda ingin menjadikan WinUI 3.x sebagai jalur maju yang sebenarnya untuk mengakses UI Win32 berlatensi rendah, memori rendah, dan berkualitas tinggi, Anda perlu mempertimbangkan kemudahan yang dapat dimanfaatkan oleh pengelola bahasa lain untuk memanfaatkan infrastruktur.

Konsistensi UI

Jika Anda benar-benar berencana untuk memisahkan UI dari sistem, apa rencana agar UI tetap konsisten dengan setiap peningkatan OS? Saat Apple membuat penyesuaian pada bayangan dan gradien di AppKit atau iOS, Aplikasi yang mengandalkan kerangka kerja sistem mewarisi semua penyesuaian tersebut dan tetap konsisten. Ini juga akan menyulitkan Anda untuk menambahkan pengalaman di seluruh sistem karena Aplikasi yang dikunci ke infrastruktur UI 3 tahun yang lalu mungkin tidak beroperasi dengan baik dengan beberapa layanan sistem baru, sehingga mereka akan memiliki lapisan kompatibilitas lain seiring berjalannya waktu.

Akan selalu ada fitur yang perlu diikutsertakan, saya dapat menganggap Mode Gelap sebagai sesuatu yang jika aplikasi tidak dirancang untuk itu, tidak masuk akal untuk menawarkannya sebagai opsi, tetapi masih ada tweak untuk komponen sistem yang akan berubah dari waktu ke waktu.

Ukuran Biner

Apa cerita yang direncanakan untuk memberikan semua UI.dlls ini dengan proyek kami? Akankah hal-hal ini menjadi 40mb runtime yang perlu dikirimkan bersama proyek kami? Apa yang akan terjadi jika sebuah proyek ditinggalkan, apakah mereka akan mulai terlihat ketinggalan zaman karena menggunakan kerangka kerja UI lama?

Salah satu manfaat C++ adalah memiliki jumlah overhead perpustakaan yang minimal tergantung pada basis kode. Tentu saja jika setiap aplikasi mulai sekarang membutuhkan WinUI 3.x, itu akan menjadi 40mb x jumlah aplikasi.

Ukuran Biner

WinUI sudah menjadi ketergantungan, sama seperti .NET. Ini sudah menjadi perpustakaan seluruh sistem. :)
Anda tidak memiliki dll duplikat, dan Anda tidak akan memilikinya.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

"Sesuatu yang juga saya pikirkan adalah alasan win32 bertahan juga. Saya pikir ada asumsi bahwa ini karena proyek lama, tetapi sebenarnya lebih dalam dari itu. ABI Win32 sangat mudah untuk dihubungkan dengan bahasa pilihan Anda. , nodejs, python, rust, go, ruby, c#, c++, dll. dll. Jika proyek inti saya berkarat misalnya, dan saya ingin membuat jendela untuk mengelola output, sebagai pengembang karat, itu sangat kuat untuk mengakses set API win32 dan membangun front end dalam bahasa yang sama."

Ini adalah tas campuran meskipun saat menerapkan dukungan WinRT untuk bahasa baru adalah punuk besar untuk diatasi, setelah Anda melakukannya, Anda berakhir dengan binding yang diketik secara otomatis ke API baru apa pun. Saya telah mengerjakan proyek Rust yang menjembatani Win32 dan WinRT baru-baru ini (menggunakan API Komposisi di jendela Win32), dan bagian-bagian Win32 pasti lebih merepotkan secara keseluruhan meskipun saya harus dengan kikuk mengerjakan sisanya kurangnya dukungan Rust untuk beberapa fitur WinRT seperti pewarisan kelas. (Ini benar-benar membantu bahwa menggunakan Komposisi di dalam Win32 sekarang dimungkinkan, karena memungkinkan peningkatan dukungan untuk fitur ini secara bertahap daripada harus menangani seluruh model aplikasi sekaligus)

Mungkin masalah terbesar adalah bahwa dokumentasi untuk detail WinRT ABI tingkat rendah agak tidak teratur, dan hanya ada sedikit pemahaman atau kesadaran tentang mereka di dunia/komunitas, saya harap situasi ini akan membaik dengan proyek xlang.

Template apa yang paling Anda minati?

Saat ini saya lebih suka memulai dari proyek Aplikasi Kosong (Universal Windows). Saya suka template dengan kerangka kerja yang telah dikonfigurasikan juga, tetapi hanya ketika saya ingin mencoba sesuatu dengan cepat. Template "Menu Utama" dan Template MDI untuk UWP juga akan bagus (karena template itu juga ada untuk WinForms)

Apakah Anda mengetahui Pulau Xaml untuk memodernisasi aplikasi desktop?
Apakah kompatibilitas mundur yang diperluas ini pada Windows 10 membuat Xaml Islands lebih berguna bagi Anda?

Ya, saya tahu tentang Pulau Xaml. Jika saya bisa, saya akan mencoba untuk tetap menggunakan aplikasi WPF murni atau UWP murni. Saya tidak dalam situasi di mana saya akan membutuhkan fitur seperti itu.

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Ya, tentu jika itu berfungsi dapat diandalkan! Saya terkejut dengan banyaknya komentar yang tidak menghargai fitur yang begitu bagus. Juga fitur ini dapat memeriksa apakah pembaruan ke WinUI 3.0 dapat dilakukan, mengadopsi Kode XAML, menyesuaikan ruang nama dan menginstal nuget WinUI yang diperlukan.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

Saya berharap untuk mengubah hanya ruang nama kontrol agar berfungsi penuh dengan WinUI 3.0. Saya tidak ingin menginvestasikan banyak waktu untuk meningkatkan ke WinUI 3.0

Apakah Anda membuat atau menggunakan pustaka kontrol UWP Xaml atau komponen WinRT yang tidak dapat Anda kompilasi ulang dan perbarui dengan mudah bersama kode aplikasi?

Saya menggunakan perpustakaan kontrol UWP Xaml pihak ketiga (seperti Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement ). Saya pikir saya akan dapat memutakhirkan kontrol sederhana dari perpustakaan pihak ketiga seperti Dockpanel sendiri ke WinUI 3.0.

Apa solusi pilihan Anda untuk menggunakan komponen UWP Xaml dengan WinUI 3?

• Buat templat proyek "Aplikasi Kosong dengan WinUI 3.0" di Visual Studio untuk UWP. Ketergantungan WinUI 3.0 akan diinstal sebagai nuget (seperti di WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . Saya benar-benar lebih suka solusi seperti itu selama saya mendapatkan semua kontrol dasar. Saya berharap bahwa semua kelas dari Windows.UI memiliki kelas yang setara di Microsoft.UI Namespace.

Topik utama di WinUI 3.0 adalah semua tentang kontrol dan kompatibilitas windows 10 yang dapat digunakan dari UWP dan WPF atau WinForms melalui Pulau XAML, jika saya benar. Apakah ada kemungkinan bahwa UWP XAML Markup mendapatkan fitur tambahan?

• Pemicu Gaya hilang
• Gaya `BasedOn={StaticResource {x:Type TextBlock}} hilang
• DataTemplates yang Ditentukan dengan DataTypes tidak secara otomatis diterapkan seperti di WPF (hanya melalui Kunci)
• Mengapa setiap detik Windows.UI.Xaml.Controls control (TextBlock, Border,...) dinyatakan sebagai disegel ?! Tolong jangan lakukan ini di WinUI 3.0 dengan UWP.
• Ekstensi Markup untuk paritas WPF
• Ini sudah disebutkan, tapi saya akan menyebutkannya sekali lagi. Sangat disayangkan bahwa UWP tidak menggunakan System.ComponentModel.IDataErrorInfo. Dengan begitu saya tidak dapat membagikan proyek Model saya dengan solusi UWP.
• ReportControl (untuk Aplikasi Perusahaan)

Saya sangat menantikan WinUI 3.0 dan kompatibilitasnya ke belakang!

F# diabaikan pada peta jalan WinUI 3.0

Apakah ada kemungkinan bahwa UWP XAML Markup mendapatkan fitur tambahan?

@Happypig375 , @mfe-:

Peta jalan hanya mencakup rilis 3.0 awal, dan untuk rilis awal kami terutama berfokus pada paritas dan kompatibilitas mundur untuk fitur yang ada, dengan sejumlah kecil fitur baru.

Jika menurut Anda fitur baru lainnya seperti dukungan F# yang lebih baik atau kemampuan markup baru itu penting, silakan buka permintaan fitur baru sehingga kami dapat melacaknya secara terpisah!

Mengapa setiap detik kontrol Windows.UI.Xaml.Controls (TextBlock, Border,...) dinyatakan sebagai disegel?! Tolong jangan lakukan ini di WinUI 3.0 dengan UWP.

Kontrol yang tidak disegel sebenarnya adalah salah satu dari sedikit fitur baru yang kami harap dapat disertakan dalam 3.0 😊

Ketika datang ke bahasa, akan rapi untuk dipadupadankan (yang seharusnya baik-baik saja jika semuanya dikompilasi sebelum dikemas)

F# digunakan untuk beberapa logika back-end - C# untuk Pengikatan Data dan kode UI - C++ untuk kontrol dan mungkin beberapa kait Win32 kelas bawah atau bahkan untuk meluncurkan dialog WinForms.

Semua bahasa kode sama, dapat dipertukarkan, dengan WinUI 3.0 menangani semua UI

Itu xlang

Itu xlang

@MarkIngramUK Hmm, saya pikir itu adalah jembatan antar bahasa, yang mengabstraksi setiap bahasa, daripada mengizinkan file kode dari berbagai bahasa dalam satu proyek.

Saya agak kesulitan memahami tujuan xlang - mengabaikan pembaruan yang telah terjadi di repo (tetapi masih ada di daftar tontonan saya)

Apakah xlang berfungsi sebelum atau sesudah kompilasi? Apakah bahasa abstraknya sendiri yang dapat diproyeksikan, atau hanya duduk di antara file kode yang ada?

Ya, Anda tidak dapat mencampur bahasa dalam satu proyek. Ini adalah jembatan, tetapi masih berguna untuk tujuan itu.

@MarkIngramUK Saya kira begitu jika kodenya dapat dikompilasi maka disertakan.

Akan lebih baik jika dapat menggunakan C# untuk mengakses fitur asli Win32, tanpa PIN dan trik .NET lainnya

@jesbis Sejujurnya saya lebih tertarik pada aspek lintas platform dari proyek ini ...

Saya pikir pada awalnya, kalian harus mengganti namanya menjadi sesuatu yang lebih _generic_ dan tidak sepenuhnya menjadi "Windows".

Saya mengerti bahwa implementasi awal harus benar-benar difokuskan pada Win32 dan mendukung aplikasi UWP/Xamarin dan Windows tetapi hanya OSS dan membuatnya dari awal disebut seperti kerangka "hanya Windows", pasti tidak akan mendapatkan banyak daya tarik seperti UWP tidak dan pengembang dari platform lain tidak akan pernah tertarik.

Jika target pada .Net 5 adalah menjadi "One .Net Everywhere", yang pada dasarnya adalah apa yang selalu diharapkan semua orang sejak .Net 1.0, fondasi untuk kerangka kerja "Apa pun kecuali Win UI" harus dimulai lintas platform.

Contoh yang sangat bagus tentang cara memperbaikinya adalah Google Flutter. Flutter masih sangat awal, tetapi mendapat BANYAK daya tarik karena fakta bahwa inti mereka (alias Flutter Engine) adalah 100% lintas-plat dan berfungsi di mana saja (termasuk IoT, Win, OSX, dan sekarang bahkan Web!).

Itu hanya 2c saya. Saya ingin kembali bekerja di Xaml tetapi jika tetap pada baris yang sama seperti di UWP, saya khawatir itu tidak akan mendapatkan daya tarik yang tepat dan akan menjadi upaya lain untuk menulis ulang WPF yang pada akhirnya akan membutuhkan upaya lain dalam masa depan dan lain sebagainya.

Tolong jangan membuat saya marah dan jangan menganggap komentar saya sebagai kritik yang buruk. Saya hanya berharap bahwa upaya UI di dunia .Net akan mendapatkan sesuatu seperti Flutter, .Net Core 3.0/.Net 5, dan bahkan Blazor.

Sebagai catatan, saya memulai proyek untuk menulis ulang/porting mesin Flutter sepenuhnya di C# dan .Net Core karena kurangnya opsi di .Net World...

BTW, CoreUI adalah nama yang bagus...

Kudos to Jake Helpert atas sarannya

💃

BTW, CoreUI adalah nama yang bagus...

Kudos to Jake Helpert atas sarannya

💃

CoreUI mungkin bingung dengan .NET Core

WinUI sangat terfokus pada Windows, tetapi kerangka kerja XAML di dalamnya, bisa mendapatkan penyaji untuk Metal (iOS dan macOS) atau Vulkan (Android) - dan FabricWeb bisa menjadi cara PWA/ChromeOS untuk menangani platform lain.

Jika tim pernah memilih untuk membawa platform presentasi, dan Xland atau Xamarin dapat menangani runtime untuk aplikasi lintas platform.

Tentang migrasi dari inbox UWP UI ke WinUI 3.0, saya akan mengutip posting blog terbaru dari @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ):

Catatan bawah yang menyenangkan: Apa yang terjadi pada UWP bukanlah bahwa itu sedang dimatikan: Microsoft berputar membawa bagian-bagian terbaik ke tempat yang kita butuhkan. Hal ini sebenarnya pernah terjadi sebelumnya, namun sayangnya tidak dijadikan sebagai kesempatan untuk melakukan pivot. Ingat Silverlight? Tebak dari mana CLR lintas platform .NET Core berasal. Dan banyak kode Silverlight juga berakhir di UWP. Seandainya mereka hanya berputar dan berkata "Ya, kami setuju Silverlight tidak masuk akal di sisi konsumen, tetapi berkembang di ruang perusahaan, jadi mari kita kembangkan itu, dan kami akan mengembangkannya menjadi .NET Core dan Windows Store". Sayangnya itu tidak berjalan mulus, dan banyak orang masih menderita PTSD dan waspada terhadap apa pun yang dilakukan Microsoft yang tampaknya mematikan teknologi apa pun.

Saya benar-benar berpikir penting untuk diingat bahwa dianggap mematikan atau menyetel ulang kerangka kerja yang ada tanpa memberi pengembang dan basis kode jalan ke depan yang baik tidak hanya memengaruhi pengembang pada kerangka kerja yang ada - ini dapat menimbulkan awan di atas upaya di masa depan karena semua orang bertanya-tanya mengapa hal baru tidak hanya akan menemui nasib yang sama. Ini tidak dimaksudkan sebagai komentar pada pendekatan migrasi yang diusulkan tertentu, lebih merupakan tanggapan terhadap komentar yang menyatakan bahwa migrasi tidak menjadi masalah karena tidak banyak orang yang menggunakan kerangka kerja UI kotak masuk yang ada. Itu bukan satu-satunya pertimbangan!

@weitzhandler WinUI 3.0 adalah tentang menggabungkan berbagai kerangka kerja Win32, .NET Core dan UWP dengan kerangka kerja XAML tunggal, dan bekerja sama dengan WPF, WinForms, dan MFC++

XAML di Windows dirender ke Direct X.

Jika Anda ingin menggunakan XAML yang sama, dikombinasikan dengan .NET Core, dan membuatnya berfungsi di platform lain. Anda perlu menulis perender baru untuk platform tersebut. iOS dan macOS menggunakan Metal sebagai setara Direct X mereka. Android menggunakan Vulkan. Tidak tahu bagaimana Linux menangani rendering, saya kira itu hanya Open GL.

Microsoft tidak akan mau melakukannya sendiri karena tidak masuk akal bagi mereka. Tetapi WinUI 3.0 akan menjadi open source - sehingga orang lain dapat memilih untuk mencoba membawanya lintas platform

@mdtauk

Terima kasih telah mengklarifikasi itu. Flutter mungkin adalah masa depan bagi saya.

Itu hanya pemahaman saya, saya bisa salah.

Flutter seharusnya mendapatkan dukungan Windows di masa depan. Dan dukungan React Native juga akan hadir di Windows. Plus ada PWA jika Anda berinvestasi di dunia HTML dan Javascript Web itu.

Bagi saya, keseluruhan cerita WinUI dapat lebih masuk akal jika mereka juga mempertimbangkan untuk mengizinkan setidaknya subset dasar menjalankan lintas platform (macOS, iOS, Android) termasuk Web, dan juga menawarkan dukungan F# dan templat proyek yang lebih baik (termasuk XAML Two-Way Binding ke F# Records, dan juga cara Elmish yang lebih fungsional)

XAML harus agnostik lingkungan seperti HTML tanpa mengambil 100mb+ bahkan untuk aplikasi alat paling dasar seperti yang dilakukan aplikasi HTML. Ini berarti kerangka kerja XAML yang ditulis dalam C/C++ atau C# murni dan dapat di-host di WASM, Win32, UWP, iOS, Android, macOS, Linux dll dengan sedikit usaha dalam hal porting. Anda memerlukan backend rendering agnostik seperti yang digunakan mesin game untuk memulai.

Tidak ada jika XAML yang berfokus pada UWP ini menyelesaikan masalah apa pun yang dialami perusahaan saya atau saya pribadi selama bertahun-tahun dengan XAML ... TBH MS membahas UI sepenuhnya salah dan tidak akan sampai ke mana-mana dengan cepat (membuang banyak waktu berharga bagi banyak orang). Peretasan UWP XAML ini tidak cocok dengan orang yang saya tunjukkan ... yang menyedihkan karena itu hanya berarti dorongan balik yang tidak pernah berakhir terhadap adopsi XAML dan saya tidak memiliki argumen lagi pada saat ini.

Satu-satunya cara untuk menyimpan XAML menurut saya adalah:

• Buat basis kerangka kerja agnostik/portabel baru untuk .NET Core dan C/C++.
• Buat lapisan abstraksi rendering agnostik yang dapat diperluas siapa pun melalui permintaan tarik.
• Sama seperti HTML, jaga agar XAML tetap fokus pada konsep aplikasi berjendela tunggal (seperti yang dilakukan dalam game juga) TETAPI memungkinkan fitur desktop yang diperluas untuk multi windows dll. (Ini memungkinkan aplikasi untuk berjalan di hampir semua konteks seperti halnya UI game)

Sederhananya ada dua kondisi yang harus digabungkan menjadi satu sebelum adaptasi XAML akan dikecualikan.

1 MS perlu mendukung proyek XAML atau orang takut gagal.

2 Itu harus lintas platform atau semua orang akan terjebak dengan runtime HTML yang membengkak.

Pokoknya itu dua sen saya dan jika WinUI 3.0 dirancang dengan benar mungkin porting akan mungkin. Pada titik ini meskipun tidak tahu apa yang harus dirasakan.

Ada beberapa komentar tentang menjadi lintas platform di sini, dan saya tidak begitu yakin bahwa WinUI harus lintas platform agar berhasil. Itu tidak akan bekerja dengan baik di Mac atau Linux, karena cukup berbeda sehingga tidak akan terasa asli di salah satu platform tersebut. Proyek ini dimiliki oleh tim yang memiliki banyak pengetahuan tentang cara kerja internal Windows, dan itu akan menjadi gangguan bagi mereka untuk keluar dan mencari cara juga membuat sesuatu bekerja dengan sangat baik di Mac atau Linux pada tingkat yang sama.

Juga... Lancar di Mac akan terasa kikuk, lihat saja iTunes, Apple harus mem-port seluruh sistem UI mereka ke Windows, dan itu pasti terasa tidak pada tempatnya. Render font berbeda, kurva animasi dan bayangan serta pilihan warna terasa sangat tidak pada tempatnya di Win10. Maksud saya, itu baik-baik saja dan dapat digunakan, tetapi saya lebih suka spotify yang tidak mencoba meniru UI desktop apa pun dan hanya menggunakan browser web di bawah tenda. Di Mac, melihat sorotan terbuka dengan komponen persegi di desktop yang penuh dengan sudut membulat dan tanpa efek terbuka akan sangat berbenturan.

Tidak, saya pikir proyek ini harus fokus pada penawaran cara terbaik di kelasnya untuk membuat perangkat lunak Windows asli, untuk pengembang yang ingin/perlu membangun perangkat lunak windows. Serahkan masalah lintas platform ke tim Electron/TypeScript untuk diselesaikan.

Ada beberapa komentar tentang menjadi lintas platform di sini, dan saya tidak begitu yakin bahwa WinUI harus lintas platform agar berhasil. Itu tidak akan bekerja dengan baik di Mac atau Linux, karena cukup berbeda sehingga tidak akan terasa asli di salah satu platform tersebut. Proyek ini dimiliki oleh tim yang memiliki banyak pengetahuan tentang cara kerja internal Windows, dan itu akan menjadi gangguan bagi mereka untuk keluar dan mencari cara juga membuat sesuatu bekerja dengan sangat baik di Mac atau Linux pada tingkat yang sama.
Juga... Lancar di Mac akan terasa kikuk, lihat saja iTunes, Apple harus mem-port seluruh sistem UI mereka ke Windows, dan itu pasti terasa tidak pada tempatnya. Render font berbeda, kurva animasi dan bayangan serta pilihan warna terasa sangat tidak pada tempatnya di Win10. Maksud saya, itu baik-baik saja dan dapat digunakan, tetapi saya lebih suka spotify yang tidak mencoba meniru UI desktop apa pun dan hanya menggunakan browser web di bawah tenda. Di Mac, melihat sorotan terbuka dengan komponen persegi di desktop yang penuh dengan sudut membulat dan tanpa efek terbuka akan sangat berbenturan.
Tidak, saya pikir proyek ini harus fokus pada penawaran cara terbaik di kelasnya untuk membuat perangkat lunak Windows asli, untuk pengembang yang ingin/perlu membangun perangkat lunak windows. Serahkan masalah lintas platform ke tim Electron/TypeScript untuk diselesaikan.

Saya tidak berpikir ada orang yang benar-benar menginginkan desain Lancar penuh pada platform lain, melainkan hanya dapat memaksimalkan kode umum antar platform.

Ini adalah sesuatu yang telah ditangani oleh tim Desain Microsoft. Situs web Fluent secara eksplisit mengatakan "rancang dan buat aplikasi khusus yang asli iOS sambil tetap Lancar secara unik". Dokumen Lancar menunjukkan bahwa gaya kontrol asli harus digunakan.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

Apa yang harus dihindari, adalah harus merancang dan memelihara UI yang sepenuhnya terpisah untuk setiap platform. Itu tidak berarti bahwa itu perlu terlihat identik di permukaan, tetapi harus berbagi tata letak yang sama, dan desainer UI harus dapat menggunakan kembali sebanyak mungkin. Gaya sebenarnya tidak (dan tidak seharusnya) harus cocok dengan gaya sistem Windows 10.

Intinya, yang diinginkan adalah cara mudah untuk menjalankan aplikasi Windows di platform lain, tanpa harus me-remake seluruh UI - bukan untuk membawa desain Fluent ke platform lain. Itu akan memungkinkan orang untuk menulis untuk Windows terlebih dahulu, dan kemudian membawa aplikasi mereka ke platform lain tanpa banyak pekerjaan.

@KyleNanakdewa Nah jika mereka open source, biarkan beberapa penggemar Xaml pergi dan membuat bit platform yang mendasarinya. Saya pikir itu mungkin cukup rumit secara arsitektur dan cukup memanfaatkan Win32 sehingga saya curiga port akan menjadi pekerjaan besar.

Saya pikir proyek ini harus fokus untuk menawarkan cara terbaik di kelasnya untuk membuat perangkat lunak Windows asli

Argumen ini mungkin menarik jika Microsoft belum memiliki toolkit XAML lintas platform yang ada yang kebetulan menawarkan dialek XAML yang sangat berbeda dari WinUI.

Plus ada PWA jika Anda berinvestasi di dunia HTML dan Javascript Web itu.

Ya... "dunia itu" yang dengan cepat menggantikan semua yang kita ketahui tentang pengembangan OS/Store/Hosted asli. 😆

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

Pertimbangkan "dunia itu" ada di _semua_ perangkat modern dengan perender HTML5:

• Apple dengan 1,4 miliar
• Droid dengan 2,5 miliar
• Windows 10 dengan 800 juta

Anda akan melihat bahwa Windows sekarang memiliki pangsa pasar terkecil, yang berarti bahwa setiap penawaran yang secara khusus melayani platform ini akan menjadi salah satu yang mencapai pasar terkecil. Melakukan hal itu hanya akan menurunkan jangkauan pasar potensial maksimum aplikasi yang, pada gilirannya, menurunkan plafon pendapatan potensial maksimumnya.

Bandingkan ini dengan Flutter, yang dengan _satu_ basis kode menjangkau _semua_ pasar yang disebutkan di atas, bersama dengan web , yang seperti disebutkan terdiri dari ketiganya -- sehingga memaksimalkan jangkauan pasar dan pendapatan potensial untuk pengembang aplikasi sekaligus mengurangi biaya yang diperlukan untuk membangun aplikasi untuk melakukannya.

Meskipun saya penggemar berat upaya di sini untuk membuka sumber, berkolaborasi, dan mengumpulkan umpan balik komunitas , saya belum melihat apa pun dari diskusi ini (yang juga saya nikmati 😁) yang memberi sinyal kepada saya dengan keyakinan bahwa upaya di sini akan berhasil kompetitif -- dan karenanya _menguntungkan_ -- jika dibandingkan dengan Flutter (yang juga ditujukan untuk PWA ).

Kontrol diagram sangat penting dalam pengalaman desktop modern berbasis data apa pun yang akan segera menjadi NET CORE 3 resmi (September 2019) dan akhirnya. NET 5 (Nov 2020)

Saya melihat kontrol sumber terbuka Networkview yang disediakan sebagai kasus penggunaan yang efektif tentang cara bekerja dengan Xaml ke port WPF ke kontrol Win UI. Win UI porting ini akan berfungsi sebagai serikat yang baik bagi orang lain untuk port kontrol WPF lain yang sedikit lebih kompleks ke Win UI.

Kami melihat kasus penggunaan 2 in 1 di mana aplikasi kami perlu mendukung mode tablet di OS Windows Core mendatang. Kami menduga Winform masuk. NET Core 3 tidak akan membantu .. pembenaran kuat lainnya mengapa kontrol diagram Win UI BUKAN hanya latihan PoC TAPI harus menjadi bagian dari kontrol inti win ui di kelas PERTAMA yang serupa dengan kontrol Grid yang bergerak Maju ..

Jika menurut Anda fitur baru lainnya seperti dukungan F# yang lebih baik atau kemampuan markup baru itu penting, silakan buka permintaan fitur baru sehingga kami dapat melacaknya secara terpisah!

Sepertinya @migueldeicaza mengambil tindakan sendiri: https://github.com/microsoft/microsoft-ui-xaml/pull/736

Saya ingin menggemakan pemikiran @ eklipse2k8 di lintas platform. Saat membuat pustaka UI lintas platform, Anda harus selalu berkompromi. WinUI tidak boleh berkompromi - itu harus menjadi pengganti modern dari Win32 UI (saya tidak ingin memanggil CreateWindowExW lagi!) WinUI di macOS atau Android akan selalu menghadirkan pengalaman yang tidak akan pernah bisa menandingi pengalaman asli. Kami menulis aplikasi lintas platform, dan kami menulis UI asli di setiap platform. Dengan begitu pelanggan mendapatkan pengalaman terbaik pada platform pilihan mereka. Jika orang menginginkan solusi lintas platform, tidak apa-apa, mereka harus melihat ke perpustakaan lain untuk tujuan itu - mungkin yang membungkus WinUI pada platform Windows.

Dan sehubungan dengan PWA, ini tidak mewakili penggunaan penuh sistem UI Windows, merekomendasikan untuk fokus pada "aplikasi satu jendela" akan segera mengesampingkan perangkat lunak profesional apa pun (kecuali game). Sudah ada solusi untuk PWA dan lintas platform - kami tidak membutuhkan yang lain.

XKCD wajib:
https://xkcd.com/927/

@MarkIngramUK Saya pikir pembicaraan tentang Cross Platform lebih tentang kemampuan membuat kode ke .NET dan XAML untuk mendeklarasikan UI - lalu menjalankan aplikasi itu di Android, iOS, macOS, Linux?! - tanpa harus mengubah kode di belakang atau meninggalkan XAML.

Sekarang jika ada XAML Renderer untuk platform lain ini - bagaimana mereka menafsirkan XAML bisa seperti Xamarin Forms, yang menyerahkan ke platform UI asli - atau pada dasarnya menggambar ke buffer kartu grafis dan menggambar piksel di layar - mempertahankan sebagian besar gaya kontrol yang sama.

WinUI 3.0 harus tetap menjadi proyek yang berfokus pada Windows untuk menyatukan berbagai API dan ABI dengan platform UI berbasis XAML modern. Tapi itu tidak berarti Xamarin atau individu tidak dapat mengambil kode rendering dan membuat versi untuk platform lain.

Semua yang benar-benar diperlukan (pada tingkat pemikiran yang tinggi) adalah memastikan kode yang merender XAML ke layar di Windows terkandung, sehingga penyaji lain dapat masuk untuk skenario lintas platform.

WinRT/UWP/XAML akan memerlukan beberapa refactoring untuk mengeluarkannya dari OS Windows 10 - jadi bagaimana refactoring itu dilakukan, untuk memungkinkan ekspansi di masa mendatang, adalah sesuatu yang perlu diingat. Apakah lintas platform menjadi kenyataan atau tidak.

@MarkIngramUK Saya setuju dengan @mdtauk

Seharusnya tidak ada alasan mengapa kami tidak dapat menggunakan xaml untuk mendeskripsikan komponen UI di perpustakaan lain termasuk React. Jika Anda melihat proyek seperti http://www.cshtml5.com , mereka menggunakan xaml yang dikonversi ke html.
Saya juga tidak berpikir ada orang yang menyinggung fakta bahwa tujuan akhirnya adalah agar UI terlihat sama di platform lain, tetapi yang saya inginkan secara pribadi adalah sesuatu di sisi UI yang dapat saya gunakan untuk meningkatkan investasi saya yang ada, misalnya UWP

Intinya hanya ini. Jika saya membuat proposal ke pelanggan perusahaan dan menyajikan aplikasi UWP luar biasa yang fantastis dalam segala hal. Jika pelanggan perusahaan itu memiliki 1 pengguna yang menggunakan misalnya MacBook Pro, maka saya segera memiliki masalah karena pelanggan perusahaan lebih suka mengambil sesuatu yang berfungsi di mana-mana (penyebut terendah => situs web) daripada "aplikasi asli" saya bahkan jika mereka berjalan pada Windows 10.

Jadi aksesibilitas adalah kuncinya. Fakta bahwa MS masih mengharapkan kami untuk melakukan investasi di "aplikasi asli" pada tahun 2019 tanpa peta jalan untuk kemampuan lintas platform adalah gila.

Setiap proyek baru dari perspektif perusahaan kemungkinan akan mengikuti logika aksesibilitas di atas dan karenanya semua proyek baru akan bias ke web dan semuanya karena tidak ada peta jalan yang mencakup kemampuan lintas platform pada XAML/UWP

Jadi kami mempercepat 2-3 tahun dari sekarang, tidak ada investasi baru dari perusahaan ke UWP/win32 dan Anda duduk dengan "Silverlight" lain yang tidak dipedulikan siapa pun.

MS bahkan dapat memberi tahu saya bahwa XAML tidak digunakan lagi besok dan perpustakaan UI "baru" misalnya React. Selama c# dapat direkatkan ke perpustakaan baru ini maka saya akan mengurangi kerugian saya, membuang XAML dan merangkul perpustakaan UI lintas platform baru ini. Setidaknya investasi saya memiliki daya tahan dan dapat diakses dalam jangka panjang.

Dengan tidak memberikan kejelasan tentang masalah khusus ini seputar kemampuan UI lintas platform, MS menciptakan ketidakpastian di sekitar "tumpukan asli" mereka dan oleh karena itu sebagian besar perusahaan lebih suka berjalan melalui api dengan kaki kayu daripada merangkul yang tidak diketahui.

Dan sehubungan dengan PWA, ini tidak mewakili penggunaan penuh sistem UI Windows

Cukup adil, dan saya setuju. Poin utama saya dengan PWA adalah untuk menunjukkan bahwa pangsa pasarnya mengerdilkan setiap pasar tertentu, karena terdiri dari agregat semua pasar.

Yang mengatakan, saya kira bagian dari kebingungan di sini di pihak saya adalah penspasian nama untuk mencerminkan Microsoft.* , padahal kedengarannya masih harus Windows.* (atau bahkan Microsoft.Windows.* ) .

Sudah ada solusi untuk PWA dan lintas platform - kami tidak membutuhkan yang lain.

Sayangnya, hal ini tidak berlaku untuk pengembangan .NET, yang merupakan bagian dari kebingungan dan kecemasan lintas platform seputar pengumuman ini dan diskusi selanjutnya.

oleh karena itu memaksimalkan jangkauan pasar dan potensi pendapatan bagi pengembang aplikasi sekaligus mengurangi biaya yang diperlukan untuk membangun aplikasi untuk melakukannya.

Terkadang performa dan detail UX dapat membuat perbedaan besar. Skype telah memaksimalkan jangkauan pasar menggunakan kerangka Electron dengan mengorbankan kinerja dan hasilnya adalah bencana komersial.

Mengenai solusi lintas platform (xplat).
Solusi Xplat adalah abstraksi dari beberapa sistem dasar asli. Pemahaman saya tentang WinUI adalah bahwa itu akan menjadi sistem asli untuk Windows.

Jika WinUI juga menjadi xplat, bagaimana cara menggabungkan hal-hal yang unik untuk Windows? Bukankah itu akan mencegahnya melakukan hal-hal baru dan inovatif? Atau apakah itu berarti ada di Microsoft untuk mem-porting sesuatu yang baru atau membedakan dari Windows ke platform lain juga? Bagaimana dengan hal-hal yang tidak dapat di-porting karena OS lain yang mendasarinya tidak dapat mendukungnya--haruskah tidak ditambahkan ke Windows?

Jika Anda membangun sesuatu dengan teknologi Windows asli, masuk akal untuk berasumsi bahwa Microsoft akan mendukungnya untuk jangka waktu tertentu dan menyediakan jalan ke depan ke sistem berbasis Windows yang lebih baru di masa mendatang. (Mengakui SilverLight sebagai pengecualian.) Saya rasa tidak masuk akal untuk berasumsi bahwa jika Anda membangun sesuatu dengan teknologi Windows asli dan kemudian ingin menjalankannya pada sistem operasi pesaing maka terserah Microsoft/Windows untuk membuatnya mudah. Jika Anda membuat aplikasi untuk iPad dengan Swift dan ingin juga membawanya ke desktop Windows, apakah Anda berharap Apple mengubah pengembangan iOS untuk membuatnya mudah?

Jika Anda menikmati atau lebih suka menggunakan teknologi Windows asli, itu bagus. Yang tidak dapat Anda lakukan adalah menunda keputusan bisnis yang Anda buat dalam memilih teknologi tersebut kepada orang lain. Semua pilihan teknologi memiliki konsekuensi dan tidak ada yang tahu apa yang mungkin diperlukan beberapa tahun ke depan atau apa yang mungkin diminta pelanggan Anda. Meminta perangkat lunak yang dikembangkan khusus untuk Windows juga dapat dijalankan di tempat lain dapat memberikan kesan bahwa tujuannya adalah untuk menghindari pengambilan keputusan teknologi yang dapat menimbulkan kemungkinan konsekuensi negatif di masa mendatang. Berdasarkan sifat teknologi dan kecepatan perubahan, saya rasa itu tidak realistis.

Yang mengatakan, jika Anda ingin membangun solusi xplat (dan ada banyak orang yang melakukan & alasan untuk itu) karena Anda ingin menargetkan beberapa sistem operasi sekarang, atau mungkin ingin di masa depan, maka itu masuk akal dan dapat dimengerti skenario.
Untuk itu Microsoft memiliki Xamarin. Atau, jika Anda lebih suka sesuatu dengan XAML seperti UWP, ada Uno. (Ada banyak pilihan lain juga.)
Jika, seperti saya, Anda ingin melihat Xamarin memiliki dukungan asli yang lebih baik untuk membangun aplikasi Windows, saya rasa WinUI tidak mencoba dan melakukan banyak hal adalah jawabannya.

WinUI lebih dari sekadar XAML dan kontrol khusus. Ini mencakup detail tentang bagaimana kontrol tersebut dan aplikasi yang dibuat dengannya terintegrasi dengan sistem operasi yang mendasarinya.
Jika perencanaan WinUI berfokus untuk membuat pengembangan Windows di Windows menjadi yang terbaik, maka itu adalah kasus yang bagus untuk memiliki inovasi dan dukungan masa depan yang baik. Ini juga cenderung meningkatkan kemungkinan orang ingin terus menggunakan Windows dan oleh karena itu menjadi penting bahwa ia memiliki dukungan yang kuat dari beberapa solusi xplat.

Mengenai solusi lintas platform (xplat).
Solusi Xplat adalah abstraksi dari beberapa sistem dasar asli. Pemahaman saya tentang WinUI adalah bahwa itu akan menjadi sistem asli untuk Windows.

Maaf tapi saya tidak merasa seperti itu...

Lihat Flutter... Ia memiliki mesin inti yang dapat merender apa pun di platform apa pun yang didukungnya.

Selain itu, ia memiliki komponen yang sepenuhnya diimplementasikan pada Dart menggunakan lapisan yang dikelola mesin dan yang mewakili (menggambar/merender) dalam kesetiaan piksel platform dan bahasa desain yang ingin Anda gunakan misalnya, Material.io dan Cupertino Apple.

Jadi, IMHO itu, itu akan menjadi pendekatan terbaik untuk membuat sesuatu lintas platform dan pada saat yang sama mewakili kemampuan platform yang mendasarinya.

Saya tidak berpikir masuk akal untuk berasumsi bahwa jika Anda membangun sesuatu dengan teknologi Windows asli dan kemudian ingin menjalankannya pada sistem operasi yang bersaing maka terserah Microsoft/Windows untuk membuatnya mudah

Benar... Saya pikir poin di sini yang dibuat orang lain adalah bahwa ini tampaknya agak terbelakang/tuli nada akhir-akhir ini, terutama dalam konteks memulai aplikasi baru. Mengapa seseorang membangun aplikasi Windows asli ketika itu hanya mencapai sebagian kecil dari pasar? Ini bukan penggunaan modal yang baik.

Jika untuk memelihara aplikasi Windows lama atau secara khusus membuat aplikasi Windows, maka ya saya setuju dengan semua ini dan itu masuk akal. Namun, karena tampaknya ada perubahan besar dan investasi lebih lanjut yang terlibat, proposisi nilai untuk melakukan ini vs. menggunakan Flutter belum dijelaskan.

Justru itulah yang saya katakan...

Misalnya, penyemat flutter untuk Desktop di Win10 (WPF dan UWP) serta OSX akan datang.

Mereka 100% dikelola oleh flutter runtime, tetapi mereka hanya menggunakan (misalnya) WPF/UWP untuk mendapatkan manajemen windowing dan pointer Graphics . Sisanya diatur oleh mesin...

Kami telah mem-porting mesin flutter sendiri ke perangkat ARM yang disematkan dan saya harus mengatakan itu adalah pengalaman yang luar biasa. Mengapa? Karena ia dilahirkan untuk portabel dan dijalankan di mana saja dengan membiarkan "embedder" menangani detail implementasi spesifik platform pada primitif seperti GPU, rendering Software, manajemen Input, dll...

Itulah mengapa saya mengatakan bahwa WinUI melalui UWP: The empire strikes back tidak akan bekerja dalam jangka panjang.

MSFT harus datang dengan sesuatu yang lintas platform, terbuka, dan portabel. Sama seperti yang mereka lakukan dengan .Net Core, dengan Blazor, dll... Reinvent UWP/XAML tidak akan kemana-mana.

Saya percaya XAML memiliki potensi yang baik jika digunakan dengan benar dalam arti di mana ia digunakan untuk "menggambarkan" (atau mendeklarasikan seperti yang dikatakan beberapa orang) UI. "Mesin" membangun pohon render darinya, dan kemudian mengirimkan perintah render ke platform yang mendasarinya.

Seperti yang baru-baru ini dilakukan MSFT dengan Chromium sebagai inti untuk Edge, saya yakin WinUI (atau apa pun namanya) dapat memanfaatkan Skia karena memiliki backend untuk GL, DX, Vulkan, Software Rendering, FB, dll... Hanya dengan memulai dengan bahwa Anda memiliki potensi BESAR untuk menambahkan platform lain nanti...

@galvesribeiro ,

Lihat Flutter... Ia memiliki mesin inti yang dapat merender apa pun di platform apa pun yang didukungnya.

Selain itu, ia memiliki komponen yang sepenuhnya diimplementasikan pada Dart menggunakan lapisan yang dikelola mesin dan yang mewakili (menggambar/merender) dalam kesetiaan piksel platform dan bahasa desain yang ingin Anda gunakan misalnya, Material.io dan Cupertino Apple.

Bagus, jadi segera setelah Apple merilis pembaruan untuk macOS, dan pembaruan UI (mungkin radius sudut tombol berubah, atau gradien latar belakang berubah, dll) aplikasi Flutter Anda tidak diperbarui dan terus terlihat seperti OS sebelumnya - tidak seperti aslinya kontrol yang akan mendapatkan manfaat secara gratis.

@MarkIngramUK itu adalah pekerjaan tim untuk mendukung pembaruan.

Sama seperti tim Xamarin memberikan update dari hari 0+1, tim ini bisa melakukan hal yang sama. Tim Google juga melakukan itu...

Dengan menggunakan kontrol "asli", Anda kembali lagi di dunia Xamarin yang hanya Anda lakukan, pembungkus (alias Renders)...

Kami tidak membahas pengikatan C# ke kontrol asli (Seperti yang dilakukan Xamarin)... Kami berbicara tentang kerangka kerja UI lengkap seperti yang Anda lakukan dengan Flutter...

Sebagai catatan, tidak ada yang menggunakan tema "default" untuk platform apa pun. Mereka semua membuat UX unik mereka di atas bahasa desain setiap platform.

Jika Anda sangat khawatir untuk selalu terlihat sebagai komponen asli, aplikasi Anda mungkin tidak akan pernah memiliki audiens yang baik seperti yang terlihat... Meh...

Saya percaya kita sedang berbicara tentang dua proyek yang berbeda di sini. WinUI harus menjadi pengganti Win32. Orang-orang meminta solusi lintas platform, yang masuk akal, tetapi saya tidak berpikir itu harus proyek ini .

Selain itu, Flutter memungkinkan Anda menggunakan "tema" di semua platform. Jadi Anda dapat menjalankan Cupertino di PC Win10 Anda. Contoh BESAR adalah desain Material. Ini adalah bahasa desain, bukan seperangkat kontrol. Ini dapat digunakan di mana saja... Kebetulan beberapa platform (seperti Android) memiliki kontrol asli yang mengimplementasikannya...

@MarkIngramUK

Saya hanya mengklarifikasi mengapa WinUI bukan hanya pengganti Win32, itu saja.

Jika itu masalahnya, maka saya cukup yakin itu akan jatuh di masa mendatang seperti UWP ...

Saya setuju @MarkIngramUK WinUI sendiri harus fokus pada penyediaan UI terpadu untuk Windows, tidak peduli apakah Anda menggunakan C#, WinRT API, Win32 ABI, C++, F#, VB, .NET Core.

WinUI 3.0 melibatkan pengangkatan semua kode dan rendering XAML dari OS Windows, dan menjadikannya kerangka kerja, independen dari siklus pembaruan OS, dan menjadikannya open source.

Bagaimana itu diangkat dan dikemas ulang masih di udara. Hanya orang-orang internal Microsoft yang tahu bagaimana mereka akan melakukannya. Untuk mendukung dukungan lintas platform di masa depan untuk XAML, saya hanya berharap beberapa pemikiran dimasukkan ke dalam bagaimana hal itu dapat dicapai di masa depan, karena mereka mengeluarkannya dari Windows.

.NET Core sudah tersedia di platform lain. Jadi itulah kode C# di belakang yang sudah dapat dipindahtangankan. Sekarang hanya XAML dan UI dan kontrol, yang memerlukan jalur ke iOS/macOS/Android/Linux (dan apa pun yang mungkin datang di masa mendatang)

Di luar lingkup WinUI 3.0 mungkin, tetapi paling pasti terkait dengan proyek dan upaya ini.

@jesbis @terrajobst @jevansaks

Apa rencana Microsoft untuk menghadirkan kerangka kerja UI ke .NET Core yang ditampilkan di desktop, seluler (Droid, iOS), dan web?
Ketidakpastian tentang hal ini telah berlangsung sangat lama.

@weitzhandler , mereka sudah memiliki roadmap , dengan paragraf berikut:

Target Windows asli untuk web dan kerangka kerja lintas platform
WinUI 3 lebih baik dioptimalkan untuk perpustakaan dan kerangka kerja untuk membangun .
Misalnya, kami berencana untuk mendasarkan implementasi C++ React Native Windows berkinerja tinggi yang baru pada WinUI 3.

Perhatikan bagian yang ditekankan, "untuk membangun". Seperti yang telah saya katakan di atas, tidak ada alasan mengapa ini tidak bisa menjadi Windows terlebih dahulu, dengan perpustakaan lain dibangun di atasnya.

Oke kalau begitu...

/me keep working on FluSharp

yang masuk akal, tetapi saya tidak berpikir itu harus menjadi proyek ini.

Di luar sana haus @MarkIngramUK , maafkan proyeksi kami. 😅

dengan paragraf berikut

Tidak banyak bicara. Itu tidak mengungkapkan niat jelas MS untuk membuat C# dan .NET development xplat. Mungkin dikatakan bahwa HTML JS & CSS shi{ adalah peralatan yang lebih baik untuk Anda daripada C# jika Anda ingin portabel.

Saat ini, Xamarin dan Xamarin Forms adalah kisah Microsoft untuk pengembangan C# dan .NET Core di luar Windows.

React Native untuk Windows akan hadir untuk kode Javascript dan Native UI (yang akan menggunakan WinUI 3.0 XAML)

Saat ini Microsoft belum mengumumkan rencana untuk membawa XAML WinUI 3.0 ke platform lain.

WinUI proyek ini mencoba untuk menyatukan kerangka kerja pengembang Win32, WPF, MFC, UWP, .NET Core, di bawah satu kerangka presentasi XAML modern.

Saya pikir setelah itu, pekerjaan harus mencari cara untuk membuat XAML yang ditulis untuk WinUI 3.0 - pada platform seperti macOS, iOS, Android, dll - tetapi itu tidak ada dalam agenda sejauh ini.

Setelah pekerjaan WinUI 3.0 dimulai di sini, itu akan menjadi open source, sehingga memungkinkan kerja lintas platform di masa depan, jika ada cukup kebutuhan untuk itu. Dan mungkin bukan Microsoft yang akhirnya membuat jalur lintas platform ini tersedia, bisa jadi komunitas open source.

Adakah rencana untuk menjadikan F#, anak tiri berambut merah .NET sebagai warga negara kelas satu? Dan kemudian orang bertanya-tanya mengapa sebagian besar pengembang .NET tidak akan menyentuh F# dengan tiang setinggi sepuluh kaki.

Saat ini, Xamarin dan Xamarin Forms adalah kisah Microsoft untuk pengembangan C# dan .NET Core di luar Windows.

Ya, Xamarin.Forms sedang porting ke macOS, GTK, UWP dan WPF, ditambah memiliki desain material di mana-mana dalam karya, yang menjadikannya .NET UI Framework de facto, tetapi sangat lambat dan bermasalah. Saya bertanya-tanya apa yang dipikirkan Microsoft tentang pengembangnya. Lihat saja daftar masalah! Setelah pengembangan serius dimulai, bug dipukul ke kiri dan kanan. Saya berharap dengan WinUI kami akhirnya dapat memiliki pengalaman pengembangan yang lebih baik.

Re: F#

Jika menurut Anda fitur baru lainnya seperti dukungan F# yang lebih baik atau kemampuan markup baru itu penting, silakan buka permintaan fitur baru sehingga kami dapat melacaknya secara terpisah!

Ya, selalu F# yang dilacak secara terpisah dan diabaikan lagi. Lihat saja UWP dan .NET Native - keduanya tidak memikirkan F# dan komunitas pada umumnya harus mencari tahu semuanya. Setelah 4 tahun, F# masih tidak didukung di .NET Native.

Untuk saran/pertanyaan F# , saya membuat masalah khusus:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

Jangan ragu untuk mengarahkan diskusi F# di sana.

Kami jelas tidak mengabaikan umpan baliknya - memiliki masalah khusus hanya membantu kami mengatur dan melacaknya.
Tim sedang mendiskusikan bagaimana itu bisa masuk ke dalam peta jalan untuk 3.0 dan seterusnya dan akan memperbarui masalah baru dengan perkembangan apa pun.

RE: UI lintas platform:

Terima kasih semuanya untuk poin yang diangkat sejauh ini, dan untuk semangat tentang .NET dan Xaml.
Saya hanya ingin mengatakan sekali lagi bahwa kami mendengarkan dengan cermat semua masukan, dan kami akan membagikan pemikiran dan pembaruan kami seiring kemajuan kami.

Sekedar menegaskan kembali peta jalan saat ini dan beberapa poin yang muncul:

WinUI adalah platform UI asli untuk Windows (termasuk aplikasi asli, bukan hanya .NET) dan untuk versi awal 3.0 kami terutama berfokus untuk menjadikannya independen dari OS dan berupaya menyiapkannya untuk pengembangan sumber terbuka pada rilis yang lebih cepat siklus. Kami ingin memastikan ruang lingkupnya cukup layak bagi kami untuk mendapatkan pratinjau tahun ini.

Salah satu tujuan jangka pendek kami lainnya saat ini adalah untuk memungkinkan WinUI berfungsi sebagai target asli untuk platform lain untuk digunakan di Windows: misalnya kami juga bekerja untuk memastikan react-native-windows - implementasi C++ React Native berkinerja tinggi untuk Windows - menggunakan WinUI , dan kontrol WinUI itu dapat digunakan untuk membuat tampilan UI asli di aplikasi React Native.

Aku akan sangat jujur. Saya memiliki aplikasi desktop Windows asli yang saya tulis pada tahun 2006 di WinForms yang masih saya jual secara online hari ini.

Saya tidak punya rencana untuk memigrasikan aplikasi ini ke WPF, UWP, atau menggunakan teknologi UI windows eksklusif. Saya tidak peduli seberapa menarik tampilan demo Windows. Jika saya memutuskan untuk mengerjakan aplikasi ini lagi, versi utama berikutnya adalah semacam implementasi lintas platform yang dapat berjalan di MacOS, Linux, dan Windows.

Saat ini, itu mungkin akan terlihat seperti Blazor + .NET Core + Electron.

Saya pikir @Mike-EEE membuat beberapa poin bagus. UX/platform yang memungkinkan saya untuk meningkatkan keterampilan C# saya untuk menjangkau jumlah audiens terbesar adalah teknologi yang lebih mungkin saya pilih.

Microsoft harus fokus pada pemberdayaan pengembang untuk memanfaatkan keterampilan mereka yang ada untuk menjangkau audiens yang lebih besar dengan aplikasi mereka. Saya pikir itu adalah strategi kemenangan dan akan membuat Microsoft tetap dalam permainan.

Tulisan di dinding adalah bahwa perangkat lunak Sistem Operasi menjadi lebih seperti komoditas. Karena itu, orang dapat memilih OS apa pun yang mereka inginkan dan mendapatkan aplikasi yang ingin mereka gunakan. Saya pikir ini akan menjadi lebih jelas seiring berjalannya waktu karena vendor perangkat lunak dunia terus fokus pada lintas platform.

Dalam ilmu ekonomi, komoditas adalah barang atau jasa ekonomi yang memiliki kesepadanan penuh atau substansial: yaitu, pasar memperlakukan barang tersebut setara atau hampir sama tanpa memperhatikan siapa yang memproduksinya. https://en.wikipedia.org/wiki/Commodity

Microsoft harus memutuskan, apakah ia ingin menjadi bagian dari cerita alat pengembang? Atau apakah Microsoft menginvestasikan jutaan dolar ke dalam tumpukan UX khusus Windows baru yang akhirnya akan bergabung dengan tumpukan tumpukan UX yang semakin sedikit digunakan orang?

Proyek ini dimiliki oleh tim yang memiliki banyak pengetahuan tentang cara kerja internal Windows, dan itu akan menjadi gangguan bagi mereka untuk keluar dan mencari cara juga membuat sesuatu bekerja dengan sangat baik di Mac atau Linux pada tingkat yang sama.

Ini adalah posisi yang sulit untuk dipastikan. Tapi waktu telah berubah. Dunia saat ini sangat berbeda dengan dunia pada tahun 1995. Cara saya melihatnya, ada beberapa pilihan:

Anda dapat mempekerjakan lebih banyak orang untuk memperluas pengetahuan itu di luar Windows.

Atau, gunakan pengetahuan tim tersebut untuk membangun pipa UX di dalam Windows yang meningkatkan kompatibilitas untuk kerangka kerja aplikasi UI lintas platform agar berjalan lebih baik di Windows.

Sama seperti yang dilakukan WSL untuk menjalankan Linux di Windows.

• Gunakan pengetahuan tim untuk membuat GTK berjalan 200x lebih cepat.
• Gunakan pengetahuan tim untuk membuat aplikasi QT berjalan 200x lebih cepat.
• Gunakan pengetahuan tim untuk membuat aplikasi Electron merender lebih cepat daripada OS lainnya.

Ada banyak pekerjaan yang dapat dilakukan untuk meningkatkan kisah kompatibilitas UX lintas platform Windows. Tetapi berinvestasi dalam tumpukan UX yang sama sekali baru dan berharap bahwa kita semua beralih (tanpa cerita lintas platform) adalah taruhan yang cukup besar. Anda harus menghentikan kebiasaan ini dengan membuat kerangka kerja UX baru hanya untuk Windows.

Hanya dua sen saya. :kandung uang:

:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (Film Resmi) ft Billy Ray Cyrus

@bchavez

Anda harus menghentikan kebiasaan ini dengan membuat kerangka kerja UX baru hanya untuk Windows.

-- Tidak hanya itu. Bahkan kebiasaan merusak portabilitas XAML internal Windows sendiri. WPF, Siliverlight, UWP semuanya dengan garpu mereka sendiri... Hal semacam ini mendorong semakin banyak orang menjauh dari alat pengembang Windows secara umum yang secara pribadi saya ingin terus gunakan di masa depan. Semakin banyak dorongan kembali dari alat dev Windows berarti semakin sedikit C # yang relevan dan bagi saya itu yang saya pedulikan ketika saya mulai melakukannya.

RE: UI lintas platform:

... WinUI adalah platform UI asli untuk Windows (_ termasuk aplikasi asli _, bukan hanya .NET) dan untuk versi awal 3.0 kami terutama berfokus untuk menjadikannya independen dari OS dan berupaya menyiapkannya untuk sumber terbuka pengembangan pada siklus rilis yang lebih cepat. Kami ingin memastikan ruang lingkupnya cukup layak bagi kami untuk mendapatkan pratinjau tahun ini.

Tambahkan +1 untuk gagasan memperbarui tampilan visual untuk kontrol WinForms, MFC, WPF yang berjalan dengan WinUI 3.0 agar lebih cocok dengan gaya kontrol Fluent/FabricWeb.

Tentu ukuran kontrol yang berbeda (apa pun yang bukan WinRT XAML mungkin harus mencocokkan metriknya dengan versi Compact dari kontrol UWP) tetapi satu tampilan yang koheren dan konsisten.

Tambahkan ketergantungan WinUI 3.0 ke WinForms dan kontrol berubah.

Aplikasi WinUI 3.0 WPF mendeteksi dan menggunakan Tema kontrol Fluent.Light.xaml atau Fluent.Dark.xaml.

@weitzhandler Saya mengerti sentimen Anda. Saya berharap tidak perlu menyentuh javaScript, dan sejenisnya untuk melakukan GUI lintas platform ini. Saya bahkan tidak suka berpikir untuk memulai proyek menggunakan elektron, sudut, panah, bergetar.
Saya berharap kami dapat segera memiliki solusi dengan .NET 5, yang akan membawa impian Universal XAML. Microsoft XAML dapat MENANG, Web, Seluler, Desktop, dan IoT.
Silverlight hampir melakukannya, untuk banyak kasus penggunaan .

Anda harus menghentikan kebiasaan ini dengan membuat kerangka kerja UX baru hanya untuk Windows.

WinUI 3.0 tidak akan pernah dirilis jika kita harus menunggu (yang pasti dikompromikan pada semua platform) dukungan lintas platform. WinUI harus menjadi kerangka kerja UI level terendah di Windows, dan jika Anda menginginkan kemampuan lintas platform, bangun di atasnya (atau gunakan React Native, Xamarin, dll).

Anda harus menghentikan kebiasaan ini dengan membuat kerangka kerja UX baru hanya untuk Windows.

Saya hanya ingin mengklarifikasi bahwa kami tidak mencoba membuat kerangka kerja UI baru dengan WinUI 3.0.

Tujuan awal kami adalah untuk:

• menghilangkan hambatan untuk menggunakan teknologi asli modern yang ada (Windows 10 Xaml UI dan compositor) dengan memisahkannya dari OS dan memungkinkannya untuk bekerja di seluruh model aplikasi yang ada (win32 dan UWP), bahasa, kerangka kerja lain (melalui pulau), dan versi Windows

• perbarui proses rekayasa kami menjadi open source

WinUI 3.0 tidak akan pernah dirilis jika kita harus menunggu (yang pasti dikompromikan pada semua platform) dukungan lintas platform.

Man... Jika Anda benar-benar percaya akan hal itu, maksud Anda framework yang sukses seperti Flutter tidak berfungsi...

Saya juga tidak suka Dart, tetapi mereka merilis produk turunan cantik yang berkembang dan mendapatkan daya tarik yang BENAR-BENAR cepat.

Saya frustrasi karena WinUI hanya akan menjadi Windows ...

.Net membutuhkan kerangka kerja UI yang cocok dengan kehebatan kemampuan lintas platform .Net Core seperti yang baru saja kita dapatkan untuk Web dengan Blazor (sisi klien dan server).

Saya pikir untuk saat ini, kita masih harus mengandalkan upaya berbasis masyarakat.

Saya mengerti apa yang tim Anda coba lakukan @jesbis... Hanya saja banyak dari kita yang bosan melihat UI di .Net/C++/UWP/MFC/Windows hal _silo_'ed yang hanya berjalan di Windows sementara di seluruh dunia (ofc kecuali Apple dan OSX) sebaliknya menawarkan solusi lintas platform yang lebih baik dan lebih baik kepada pengembang. Seperti yang Anda sebutkan React dan Rect-Native (sebagai catatan saya juga tidak suka, hanya menyebutkan bahwa mereka berkembang).

Jadi yang kami miliki sekarang hanyalah inisiatif berbasis komunitas seperti Avalonia atau bahkan Uno dan kerangka kerja lainnya (seperti FluSharp yang saya kerjakan seperti yang disebutkan) yang berkembang SANGAT LAMBAT karena alasan yang jelas...

Saran saya adalah daripada hanya mengangkat XAML dan compositor dari basis kode Windows dan menjadikannya hanya untuk Windows, untuk mendapatkannya dan membuat abstraksi yang tepat sehingga dapat bekerja di berbagai platform. Sama seperti yang kami lakukan dengan .Net Core, yang awalnya hanya untuk Windows tetapi upaya yang didorong oleh komunitas itu membuatnya bekerja cukup cepat di Linux, OSX dan bahkan pada perangkat ARM...

(yang pasti dikompromikan di semua platform) dukungan lintas platform

Saya benar-benar tidak berpikir ini akan menjadi masalah, mengingat bahwa desain lintas platform, dan selalu, merupakan aspek kunci dari UI XAML UWP, dan Desain Lancar. Pasti ada beberapa kontrol di mana desain visual berbeda antara versi Windows - ini ditangani dengan mulus, Anda mendapatkan UI asli yang cocok dengan OS perangkat.

Misalnya, Akrilik dan Reveal terintegrasi ke dalam kontrol, warna aksen pada Pivots dan NavigationViews - hal-hal ini tidak muncul di Creator's Update, tetapi muncul di FCU dan yang lebih baru. Tidak ada perubahan yang diperlukan.

Jelas ada lebih banyak kerumitan di balik layar untuk merender UI pada OS yang sama sekali berbeda, tetapi dalam hal mendesain UI sebenarnya, saya tidak berpikir ada pertimbangan baru yang perlu diambil, daripada yang pernah ada. dengan UWP dan WinUI.

Saya pikir perhatian besar adalah apa rencana jangka panjang yang sebenarnya. Berdasarkan tanggapan dari @jesbis sepertinya mereka hanya fokus pada jangka pendek saat ini, dan rencana jangka panjang masih terbuka untuk didiskusikan.

Itu bisa dimengerti, ruang lingkup proyek semacam itu sangat besar. Saya benar-benar bisa mengerti jika itu bukan rencana jangka pendek, melainkan rencana akhir permainan. Transparansi penting di sini, jelas bahwa tidak ada yang ingin mendukung platform tanpa masa depan yang jelas.

Jelas bahwa MS secara keseluruhan berfokus pada lintas platform - kami melihat ini dengan Desain Lancar (yang sekarang memiliki contoh untuk iOS, Android, dan web), sejumlah besar aplikasi buatan MS di platform lain - jadi UI bersama adalah benar-benar hanya sebuah missing link besar. Dan itulah mengapa akan sangat mengecewakan untuk tidak melihatnya terjadi - saya pikir banyak orang menyukai ide platform aplikasi universal buatan MS, tetapi tidak masuk akal untuk mendukungnya, jika kita tidak memilikinya. solusi lengkap untuk itu.

Intinya adalah... Seperti halnya material.io dan Cupertino, kita dapat (dan saya tidak terkejut jika Google belum melakukannya!) memiliki "tema" pada flutter untuk bahasa desain yang fasih...

Dan itulah poin saya ketika saya mengatakan bahwa kerangka UI lintas-plat yang benar-benar tidak akan peduli tentang itu dan hanya akan berfungsi, seperti Flutter... Saya tidak melihat di mana kita memiliki kompromi tentang itu...

@weitzhandler Saya juga tidak suka HTML untuk aplikasi asli. Kalau tidak, saya akan menggunakan Electron dengan React

Saya hanya tidak bersemangat di sini, dan hanya bersikap rasional saja.

Saya sangat menantikan WinUI 3.0 dan saya akan segera menggunakannya untuk proyek desktop Windows C++/WinRT baru. Dan saya berharap versi utama berikutnya setelah 3.0 akan memperkenalkan runtime portabel untuk menghosting aplikasi WinUI (seperti runtime Flutter). Untuk sejumlah besar aplikasi LOB dan aplikasi seperti Photoshop, GUI bisa sama di setiap platform, tetapi kuncinya adalah kinerja dan penggunaan kembali kode sumber. Dan saya juga berpikir bahwa proyek xlang adalah ide bagus dan menjanjikan kabar baik di masa depan.

Saya menyarankan pengguna di sini meluangkan waktu untuk mendengarkan Scott Hunter setelah BUILD 2019 tentang bagaimana Win UI, Xamarin Form, UNO, Majelis Web dapat bersatu.

.NET Core 3 dan Selanjutnya dengan Scott Hunter @.NET Rock

Baik Xamarin Forms (XAML) dan UNO (XAML) dibuat dengan visi untuk lintas platform. Dalam kasus UNO (selain iOS, Android, XAML untuk Web melalui Majelis Web).

UWP dibuat tanpa visi di luar ekosistem Microsoft misalnya Web, Android, iOS. Semua upaya desain Lancar yang mengesankan tidak banyak dilakukan karena lambatnya adopsi UWP

Seperti yang ditunjukkan @Mike-EE, droid dan iOS memiliki 2~ dan 1,5~ miliar sementara Win10 memiliki 0,9 miliar. Sebagian besar pengembang masih enggan untuk melompat dari WinForm dan WPF ke UWP.

MENGAPA? Kontrol UWP, dari komersial dan Microsoft, TIDAK LENGKAP !!!!! dibandingkan dengan yang ada di WinForm dan WPF. Tidak ada upaya dari Microsoft untuk membantu transisi itu. Pulau XAML tidak akan membahas ini SELAMA MICROSOFT memiliki BLIND SPOT sebagai apa yang hilang sehingga pengembang PERLU untuk transisi ke UWP dari winForm dan WPF.

Dengan Kontrol UWP yang hilang ini, sekarang upaya yang signifikan dilakukan untuk membawa Win UI ke React Native untuk Web. ???? Kami membutuhkan Kontrol UI Win yang hilang ini untuk UWP sehingga kami dapat melobi untuk transisi dari WinForm dan WPF ke UWP .

Salah satu kontrol tersebut adalah Kontrol Diagram . Semua aplikasi bisnis intensif data memerlukan kontrol diagram untuk UWP.

==> Saya memahami kebutuhan untuk memisahkan UI UWP. Ini masuk akal untuk menyebarkan branding Desain Lancar ke platform lain misalnya iOS, Android, Web.
==> Harap fokus untuk memberikan kontrol model 3D dan Kontrol Diagram yang lebih baik (keduanya 2D/3D)

Masuk akal untuk tinggal dan menunggu NET5 ketika SEMUA BCL dari (mono digabungkan dengan asli Windows, untuk Majelis Web dll), karena saya MELIHAT MASA DEPAN HOLOLENS kreatif 3D UI.

Untuk itu diperlukan Kontrol Diagram 2d/3D untuk UWP dan kontrol model 3D yang seharusnya tidak hanya sekedar menampilkan model tetapi memungkinkan pengembang untuk mengakses animasi kerangka/vertex.

@jesbis Saya mendorong Anda untuk memasukkan lebih banyak orang ke dalam USP (nilai jual unik) Win UI untuk UWP ini.

@weitzhandler

Masalah ini dibuat untuk membahas Peta Jalan WinUI 3.0 .

@jesbis membuat pernyataan klarifikasi :

WinUI adalah platform UI asli untuk Windows (termasuk aplikasi asli, bukan hanya .NET) dan untuk versi awal 3.0 kami terutama berfokus untuk menjadikannya independen dari OS dan berupaya menyiapkannya untuk pengembangan sumber terbuka pada rilis yang lebih cepat siklus. Kami ingin memastikan ruang lingkupnya cukup layak bagi kami untuk mendapatkan pratinjau tahun ini.

Dua komentar pertama Anda sesuai topik.

Enam berikut adalah kombinasi dari tidak produktif dan menghina, dan Anda hampir melanggar Kode Etik Sumber Terbuka Microsoft .

Ini harus tetap menjadi percakapan yang produktif dan profesional dengan Microsoft.

// Aku tidak mengikuti percakapan ini untuk mendengarkan curhatan pria sepanjang hari.

Saya pikir ada beberapa komentar bagus di sini, meskipun tampaknya mungkin ada dua diskusi terpisah. Saya akan membuatnya singkat karena sebagian besar telah dikatakan sebelumnya.

Lintas platform & web

.NET Core sangat bagus. Kami akhirnya dapat menargetkan setiap platform dan titik kontak dengan alat yang hebat dan bahasa yang luar biasa.
Satu-satunya hal yang hilang adalah tumpukan UI kecuali Blazor (HTML/CSS menyebalkan). Untuk komparabilitas maksimal, akan sangat bagus untuk memiliki kerangka kerja yang memungkinkan pengembang desktop bermigrasi ke web dan seterusnya dengan keterampilan, peralatan, dan bahasa yang sama (Xaml dan C#). Tbh, Silverlight melakukan hal yang hebat di sana - itu berhasil). Saya tidak yakin apakah WinUI perlu menjadi kerangka kerja itu, tetapi tolong angkat masalah ini secara internal. Pada dasarnya Flutter untuk .NET devs, dan menargetkan web akan menjadi keuntungan terbesar.

Tidak yakin apakah Xamarin bisa menjadi platform itu, tetapi jika demikian - pastikan Xaml disejajarkan sebanyak mungkin di seluruh WinUI dan Xamarin.

WinUI

Ini perlu terjadi. Harus ada satu tumpukan Xaml umum untuk menciptakan pengalaman terbaik di platform Windows. Idealnya celah yang hilang dari WPF dalam hal kontrol dan fungsionalitas harus diisi.

HoloLens dan seterusnya

Dengan hadirnya Lite, dan faktor bentuk baru yang sangat menarik seperti HoloLens, orang dapat berargumen bahwa UWP belum siap untuk itu dalam hal UI. Ya, kami dapat menjalankannya di HoloLens yang bagus, tetapi saya ingin melihat cara untuk benar-benar mengoptimalkan aplikasi untuk 3D tanpa menggunakan Unity penuh.

WinUI jauh di depan Xamarin. Tetapi Tim Microsoft baru saja mendorong Xamarin 4.0 keluar ...
Saya pribadi lebih menyukai Xamarin karena ini adalah denominasi terendah untuk Cross Platform, akan ada peningkatan jumlah Aplikasi Asli untuk SaaS di masa depan.

Selain Xamarin, ada beberapa alternatif.
1) Mengapa tidak merangkul platform UNO dan membuat rendering web menggunakan SkiaSharp?
2) @zezba9000 Anda memerlukan backend rendering agnostik seperti yang digunakan mesin game untuk memulai. Sebenarnya aku agak mengakuinya....

Mungkin Microsoft mendorong WinUI lebih banyak, karena ada jejak kode sumber non-terbuka di dalamnya tidak seperti solusi lintas platform lainnya: Xamarin, UNO, mungkin memiliki perpustakaan UNIX ...

Bagaimanapun, semoga kekuatan menyertai Anda.
PS: Sponsor Github berasal dari Microsoft, jadi tolong sponsori beberapa Pengembang Mac/Linux terkemuka untuk fork Cross Platform WPF/Winforms.

@jkoritzinsky , Satu hal yang harus diwaspadai oleh tim WinUI dengan penggantian nama WinUI 3.0: Jika Anda mengganti nama salah satu jenis yang diproyeksikan di .NET, maka proyeksi tidak akan berfungsi (dan kami tidak berencana menambahkan lagi karena ini bukan sistem yang dapat diperluas yang dapat dipelihara). Berikut daftar jenis yang kami proyeksikan: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Setiap perubahan pada tipe yang berbeda dari tipe ini akan mengharuskan pengguna untuk membungkus objek mereka dalam objek baru yang mengimplementasikan antarmuka baru atau menyalin data mereka ke tipe baru. Secara khusus, tipe INotifyPropertyChanged dan INotifyCollectionChanged menarik sehubungan dengan Pulau XAML dan memberikan dukungan hilir.

Saya setuju dan saya senang Anda mengangkat masalah ini, meskipun saya ingin menambahkan bahwa saya pikir proyeksi ini sedikit buruk. Kami tidak memproyeksikan setiap API yang mungkin seharusnya (berpikir tentang API System.IO), jadi kami harus memperbaikinya, atau berpikir secara berbeda. Satu hal yang terlintas dalam pikiran adalah untuk tidak menambahkan tipe yang serupa, tetapi berbeda, ke tipe .NET di namespace yang berbeda. Sebagai gantinya, kita harus mengaktifkan pengembang C++ untuk juga menggunakan System.ComponentModel.INotifyDataErrorInfo. Ini seperti yang kami lakukan dengan C++/CLI, tetapi ini tidak memerlukan pemuatan CLR untuk aplikasi C++ murni. Saya tidak tahu apakah itu akan lebih membingungkan, tetapi rasanya seperti kami membocorkan perbedaan mendasar dan mendasar dalam teknologi .NET dan WinRT di lapisan API, yang membuat segalanya terasa tidak koheren.

@meir-pletinsky. NET hanya satu kerangka kerja yang dapat Anda gunakan untuk membuat aplikasi dengan UWP XAML. Mereka ingin validasi bidang teks tersedia untuk Pengembang, apa pun kerangka kerja yang mereka gunakan

Ini tepat untuk uang, kami memiliki pengembang C++ yang kami pedulikan. Meskipun seperti yang saya sebutkan di atas, saya ingin kami tidak membuat kebingungan di komunitas .NET hanya untuk mewujudkannya.

@mdtauk , tidak, WinUI Desktop (sebelumnya Xaml Desktop) memungkinkan Anda untuk menggunakan Xaml dengan Win32 secara langsung, tanpa menggunakan pulau.

Saya pikir @meir-pletinsky mengacu pada .NET/C++, kecuali saya melewatkan sesuatu?

@MarkIngramUK Saya yakin kita sedang membicarakan dua proyek berbeda di sini. WinUI harus menjadi pengganti Win32. Orang-orang meminta solusi lintas platform, yang masuk akal, tetapi menurut saya itu bukan proyek _this_.

Ya, saya sangat setuju! Bagi saya, WinUI adalah tentang mendefinisikan UI yang paling modern, berkinerja, dan terbaik untuk Windows. Xamarin harus menjadi cerita lintas platform dari Microsoft dan harus berkembang menjadi di atas WinUI.

@mdtauk

Tambahkan +1 untuk gagasan memperbarui tampilan visual untuk kontrol WinForms, MFC, WPF yang berjalan dengan WinUI 3.0 agar lebih cocok dengan gaya kontrol Fluent/FabricWeb.

Tentu ukuran kontrol yang berbeda (apa pun yang bukan WinRT XAML mungkin harus mencocokkan metriknya dengan versi Compact dari kontrol UWP) tetapi satu tampilan yang koheren dan konsisten.

Tambahkan ketergantungan WinUI 3.0 ke WinForms dan kontrol berubah.

Aplikasi WinUI 3.0 WPF mendeteksi dan menggunakan Tema kontrol Fluent.Light.xaml atau Fluent.Dark.xaml.

Saya tidak benar-benar ingin melihat MS menginvestasikan waktu dan sumber daya ke dalam kerangka kerja tersebut untuk membuatnya terlihat seperti aplikasi Windows 10 asli. Itu sebabnya akan ada WinUI 3.0. Anda ingin tampilan & nuansa Windows 10 di aplikasi WPF/WinForms? Gunakan WinUI 3.0.
MS sebaiknya menginvestasikan sumber daya mereka untuk menutup celah yang ada (dan memblokir) antara UWP/WinUI dan rekan-rekan Win32 mereka, daripada mengunjungi kembali kerangka kerja mereka yang lebih lama. Terutama mengingat bahwa WinUI dimaksudkan untuk menjadi kerangka presentasi _the_ untuk Windows...

Saya ingin meminta klarifikasi tentang WinUI dan niat Microsoft di UI/UX:

1. Apakah WinUI menggantikan SEMUA yang berikut (secara hipotesis?): Win32, ATL, MFC, WinForms, Silverlight (saya tahu), WPF, UWP dan/atau XAML Islands? Saya menyadari bahwa teknologi ini akan terus ada, dan akan terus didukung untuk waktu yang tidak terbatas ; Saya hanya ingin memahami dengan jelas bahwa inilah yang dikatakan Microsoft sebagai "jalan ke depan", dan bahwa (misalnya), kita harus mempertimbangkan WinForms dan WPF sama seperti kita menganggap Win32 atau MFC.

2. Apakah WinUI berasal dari UWP? (Atau, seberapa mirip keduanya?) Seberapa mirip (atau berbeda) WinUI dibandingkan dengan UWP, XAML Islands, atau WPF?

Sebagai pengembang C# dan C++ profesional, saya mulai bekerja dengan WinForms, dan kemudian pindah ke WPF, dan kemudian kembali ke WinForms hanya karena saya bisa mendesain UI/UX untuk tujuan bisnis di WinForms kira-kira dua kali lebih cepat dari yang saya bisa di WPF. WPF memberikan lebih banyak fleksibilitas, kinerja, dan terlihat jauh lebih baik—tetapi gangguan XAML yang terjadi segera setelah seseorang menyentuh antarmuka melalui Perancang alih-alih mengedit XAML dengan tangan, sangat buruk. Dalam beberapa kasus, saya pikir WinForms (menggunakan Perancang) lebih cepat daripada membuat bentuk atau kontrol XAML secara manual.

Secara pribadi, saya ingin UI yang tersedia dan identik di seluruh produk Microsoft. Kerangka kerja yang dapat dimanfaatkan oleh Win32 atau .NET dengan cara yang sama berarti aplikasi yang terlihat modern dan konsisten untuk SEMUA pengembang Microsoft, dan juga berarti bahwa pertanyaan dan masalah umum dapat diselesaikan dalam sesi yang menargetkan satu teknologi—misalnya, ketika mengajukan pertanyaan tentang kontrol, jawabannya akan identik (jika tidak hampir identik) untuk pengembang Win32 ATAU pengembang .NET. Itu akan membuat pembelajaran "WinUI" berguna untuk tumpukan mana pun untuk pengembang tertentu, dan juga akan membuat akses ke informasi online (StackOverflow, dll.) jauh lebih berharga, di mana pun Anda mengembangkannya. Meskipun saya tidak menggunakan Xamarin, jika Xamarin dapat dibuat mengikuti jejak ini (sebagai perpanjangan dari WinUI?), maka pernyataan di atas dapat diterapkan tidak hanya untuk pengembang Windows, tetapi juga yang menargetkan Android, iOS, dll.

Aplikasi seperti apa yang membuat saya tertarik untuk menggunakan WinUI?

Jika pemahaman saya tentang WinUI benar, dan itu "jalan ke depan", menggantikan Win32, MFC, Formulir, WPF, dll., Dan kerangka kerja yang sama tersedia untuk pengembangan asli atau .NET, maka saya akan dengan bersemangat mengganti komposisi di _ SEMUA _ aplikasi yang saya dukung. UI modern dan konsisten, yang berfungsi (dan berperilaku) sama terlepas dari platform atau tumpukan? Bukankah itu yang kita semua inginkan? Saya tidak berpikir ada yang ingin mengingat bagaimana keduanya CreateWindowEx() dan menjalankan Message Loop untuk mengirimkan acara di Win32 sambil menangani acara dengan cara yang benar-benar terpisah di WinForms atau WPF. Saatnya untuk sesuatu yang "modern". Saya sangat berharap itulah WinUI (3.0).

Kompatibilitas OS dan Dukungan Downlevel

Saya pikir itu bagus bahwa WinUI berfokus pada pemisahan komposisi dari OS, tetapi ada sejumlah besar pelanggan yang bahkan belum menggunakan Windows 10. Saya tahu ini adalah titik yang menyakitkan, dan kami semua berharap audiens target kami menjalankan yang terbaru, tetapi itu adalah masalah nyata yang kita semua hadapi setiap hari. Diskusi apa yang sedang dilakukan tentang membuat WinUI tersedia untuk platform lama di luar 1703, yang saya yakini sebagai platform tertua yang saat ini ditargetkan?

Apakah menjadikan WinUI dapat ditautkan secara statis atau dapat disematkan (seperti .NET Core/5) sebagai opsi? Kita harus menargetkan Windows 8.1, Windows 8, Windows 7—bahkan Windows PE. Bagaimana kita bisa menggunakan WinUI dengan persyaratan itu?

@shidell :

Apakah WinUI berasal dari UWP? (Atau, seberapa mirip keduanya?) Seberapa mirip (atau berbeda) WinUI dibandingkan dengan UWP, XAML Islands, atau WPF?

WinUI 3.0 dalam arti tertentu akan menjadi versi berikutnya dari komponen platform UI Windows 10/UWP, termasuk platform Xaml, komposisi dan input. Itu berasal dari basis kode itu.

Itu harus sangat mirip dengan API platform Windows 10/UWP Xaml selain dari apa yang disebutkan dalam peta jalan : yaitu ruang nama root yang berbeda, dukungan yang lebih baik untuk mencampur dan mencocokkan dengan teknologi lain (misalnya menggunakan model aplikasi win32 daripada UWP), dan beberapa fitur tambahan baru.

Apakah WinUI menggantikan SEMUA yang berikut (secara hipotesis?): Win32, ATL, MFC, WinForms, Silverlight (saya tahu), WPF, UWP dan/atau XAML Islands? Saya menyadari bahwa teknologi ini akan terus ada, dan akan terus didukung untuk waktu yang tidak terbatas; Saya hanya ingin memahami dengan jelas bahwa inilah yang dikatakan Microsoft sebagai "jalan ke depan", dan bahwa (misalnya), kita harus mempertimbangkan WinForms dan WPF sama seperti kita menganggap Win32 atau MFC.

WinUI adalah tempat pengembangan dan kemajuan aktif utama kami untuk UI aplikasi asli di Windows. Itu juga yang digunakan oleh Windows itu sendiri dan aplikasi serta perangkat asli Microsoft.

Pulau Xaml akan menjadi bagian dari WinUI, dan memungkinkan Anda menggunakan WinUI untuk membuat tampilan baru di aplikasi yang ada (misalnya WPF, WinForms).

Diskusi apa yang sedang dilakukan tentang membuat WinUI tersedia untuk platform lama di luar 1703, yang saya yakini sebagai platform tertua yang saat ini ditargetkan?
Apakah menjadikan WinUI dapat ditautkan secara statis atau dapat disematkan (seperti .NET Core/5) sebagai opsi? Kita harus menargetkan Windows 8.1, Windows 8, Windows 7—bahkan Windows PE. Bagaimana kita bisa menggunakan WinUI dengan persyaratan itu?

Terima kasih telah berbagi umpan balik tentang ini. Untuk 3.0 kami fokus pada platform di peta jalan (1703+, dengan beberapa dukungan pada 8.1). Kami benar-benar memahami bahwa pengembang juga memiliki pelanggan di versi lain, dan itu adalah sesuatu yang kami rencanakan untuk dievaluasi ke depan.

Luar biasa—kedengarannya seperti WinUI adalah "jalan ke depan", dan dengan pemahaman ini, untuk mengatakan bahwa saya senang akan menjadi pernyataan yang meremehkan.

Secara khusus, saya pikir itu fantastis bahwa Kepulauan XAML akan memungkinkan pengembang untuk memperluas WinUI ke teknologi yang lebih tua, seperti WPF dan WinForms. Itu adalah jembatan "maju" yang bagus saat mengerjakan/memperpanjang proyek lama.

Luar biasa—kedengarannya seperti WinUI adalah "jalan ke depan", dan dengan pemahaman ini, untuk mengatakan bahwa saya senang akan menjadi pernyataan yang meremehkan.

Secara khusus, saya pikir itu fantastis bahwa Kepulauan XAML akan memungkinkan pengembang untuk memperluas WinUI ke teknologi yang lebih tua, seperti WPF dan WinForms. Itu adalah jembatan "maju" yang bagus saat mengerjakan/memperpanjang proyek lama.

Saya ingin berpikir jika proyek WinForms, MFC, atau WPF dibuat dengan menyertakan WinUI 3.0 - mereka hanya dapat membuat halaman/konten/jendela XAML tanpa harus menggunakan Pulau XAML dalam Formulir/Jendela WPF/Jendela HWND.

Kemampuan untuk hanya menggunakan XAML murni, atau menggunakan Pulau untuk menempatkan XAML ke dalam kerangka yang disediakan permukaan - akan benar-benar membuat WinUI 3.0 "The One UI untuk mengatur semuanya"

akan benar-benar membuat WinUI 3.0 "The One UI untuk mengatur semuanya"

... di Windows. 😉

WinUI 3.0 dalam arti tertentu akan menjadi versi berikutnya dari komponen platform UI Windows 10/UWP, termasuk platform Xaml, komposisi dan input. Itu berasal dari basis kode itu.

Pada catatan itu, @jesbis , saya ingin tahu apakah Anda dapat berbicara tentang bagaimana integrasi antara WPF dan UWP. Secara khusus, dengan konsep seperti ekstensi markup yang telah kami minta di UWP selama bertahun-tahun sekarang, dengan sedikit keberhasilan.

Upaya telah dilakukan , tentu saja, tetapi gagal dalam implementasi WPF meskipun membutuhkan waktu lebih dari dua tahun penuh untuk dikembangkan.

Selain itu, banyak layanan yang tersedia di markup WPF tetap tersedia dan diimplementasikan di UWP. Apakah upaya di sini untuk memastikan bahwa markup WinUI 3.0 berbasis UWP baru akan memiliki kesetiaan penuh dengan WPF? Maaf jika ini dijelaskan di suatu tempat, tetapi saya belum menguraikan pesan untuk melihatnya (dan menyambut sumber daya apa pun untuk memperbaiki/menambah pemahaman saya).

akan benar-benar membuat WinUI 3.0 "The One UI untuk mengatur semuanya"

... di Windows. 😉

Setidaknya untuk jendela rilis WinUI 3.0. Saya berharap ini bisa menjadi awal dari proses untuk membawa rendering XAML ke platform lain...

Saya ingin tahu apakah Anda dapat berbicara tentang bagaimana integrasi antara WPF dan UWP. Secara khusus, dengan konsep seperti ekstensi markup yang telah kami minta di UWP selama bertahun-tahun sekarang, dengan sedikit keberhasilan. [...] Apakah upaya di sini untuk memastikan bahwa markup WinUI 3.0 berbasis UWP baru akan memiliki kesetiaan penuh dengan WPF?

@Mike-EEE kesetiaan penuh dengan WPF bukanlah tujuan untuk 3.0. Namun kami melacak sejumlah item pekerjaan untuk menutup kesenjangan dari waktu ke waktu (misalnya peningkatan ekstensi markup #741 - silakan lihat dan tinggalkan komentar apakah ini akan memenuhi kebutuhan Anda!) dan terus memperluas WinUI di luar WPF (misalnya # 686 dukungan model 3D).

Jika ada fitur khusus lainnya di WPF yang ingin/perlu Anda gunakan di WinUI, silakan buka masalah proposal fitur baru untuk mereka, atau beri komentar di " Fitur WPF yang seharusnya ada di WinRT XAML " edisi #719 . Kami tidak memiliki sumber daya yang tak terbatas tetapi kami pasti mencoba untuk memperhitungkan masukan masyarakat dalam perencanaan kami. Setelah semuanya open source, akan ada juga peluang bagi siapa saja untuk berpotensi membantu menyumbangkan fitur.

Itu menggembirakan, @jesbis terima kasih telah berbagi itu. Saya telah memperbarui suara yang relevan di UserVoice untuk mengarahkan pelanggan ke masalah itu.

Saya kira kekhawatiran saya yang luar biasa adalah jika kesetiaan WPF penuh bukanlah tujuan, sementara WinUI digunakan dalam WPF _adalah_ tujuan, maka Anda akan menghadapi gesekan dengan adopsi WPF, karena ia memiliki model Xaml yang unggul (dan asli).

Artinya, tampaknya tidak ada proposisi nilai yang jelas untuk memasukkan WinUI3.0 ke dalam WPF, seperti halnya Kepulauan Xaml yang tidak memiliki proposisi nilai yang jelas. Pada akhirnya, tampaknya Anda mencoba memasukkan model Xaml yang terbelakang/inferior/terbelakang ke dalam model Xaml yang mapan dan unggul, yang sama sekali tidak masuk akal.

Untuk kasus penggunaan di WinForms, MFC, dll., ya, pendekatan ini masuk akal untuk WinUI3.0. Namun, dengan WPF, ia memiliki model presentasi yang unggul dan paradigma pengembang/perancang yang tidak dapat ditandingi oleh inisiatif lain oleh MSFT atau vendor eksternal.

@Mike-EEE berdasarkan pembicaraan Scott Hunter , menurut saya, yang mungkin salah, bahwa tujuan "ONE BCL To Rule them all" memiliki prioritas yang lebih tinggi daripada "One UI to rule them all".

Dengan mengganti MONO yang mendasari Xamarin Forms XAML dan UNO XAML di Web melalui perakitan Web dengan BCL umum yang memiliki AoC, aplikasi berdasarkan Xamarin Forms XAML, Uno XAML di Web akan SEMUA MANFAAT dari kinerja kecepatan.

Performa kecepatan ini SANGAT PENTING bagi siapa saja yang peduli dengan masa depan karir mereka, berinvestasi di C# untuk lintas platform mengingat persaingan ketat yang datang dari teknologi lain, misalnya flutter, react, dll.

Mudah-mudahan, dalam perjalanan menuju .NET5 = BCL umum untuk mengatur semuanya , standardisasi XAML diperhatikan, sebagian atau seluruhnya, sepanjang proses, TAPI bukan tujuan utama .NET5.

Prioritas lain di atas kebutuhan standarisasi XAML adalah penyebaran branding Microsoft melalui desain yang lancar ke semua platform (seluler, desktop, dan web). [Dalam istilah teknis, decoupling melalui Win UI 3.0, yang kami diminta berkali-kali untuk memfokuskan tujuan dari roadmap WinUI 3.0]

PADA AKHIRNYA, berapa banyak UWP, yang berasal dari Win UI, sebenarnya berperan dalam SATU BCL UNTUK MENGATASI MEREKA SEMUA pada NOV2020 ketika .NET5 dirilis, JUGA BUKAN tujuan prioritas tinggi dalam pandangan saya.

Dari sudut pandang pemasaran, sayangnya tidak diterjemahkan ke dalam teknologi yang sangat kami pedulikan, adalah bahwa branding Microsoft melalui desain yang lancar ada di mana - itu CEPAT DI MANA SAJA.

Ini adalah bagaimana saya melihat strategi jangka panjang Microsoft untuk "Mengejar pangsa pasar" karena kurangnya kehadiran seluler.

Ini jelas kecuali SAYA MELIHAT POTENSI YANG JAUH LEBIH BESAR terletak pada Hololens 2 dan seterusnya. Untuk itu, KITA PERLU PASTIKAN APLIKASI UWP dengan WinUI 3.0 hadir dengan kontrol Diagram 3D dan penampil model 3D tingkat lanjut.

Maaf teman-teman, saya terus mendorong ini karena saya ingin menggunakan waktu terbatas yang saya miliki untuk TEKNOLOGI TERBAIK DARI YANG TERBAIK. :-)

Mengenai masa transisi WinUI 3.0

Saya menyarankan agar Microsoft bekerja secara langsung dengan pengelola Windows Community Toolkit (beberapa di antaranya berfungsi untuk MS) untuk:

1. Uji untuk melihat apakah ada hambatan yang tidak terduga saat menargetkan ulang toolkit ke WinUI 3.0 (termasuk aplikasi sampel).
2. Uji penggantian nama namespace otomatis melalui Visual Studio atau "alat lain" untuk melihat seberapa lancarnya.
3. Laporkan secara publik tentang bagaimana proses berjalan (posting blog/masalah GitHub/apa pun yang Anda suka).
4. Berikan potongan teks salin + tempel tentang WinUI 3.0 & transisi yang dapat ditambahkan oleh pengelola proyek ke GitHub/Nuget/Readme lainnya, atau setidaknya URL dengan informasi ringkas tentangnya. Ini akan membantu mempercepat pengguna proyek tersebut dengan cepat di WinUI 3.0, dan menjelaskan apa yang harus mereka lakukan untuk menyelesaikan transisi.
5. Uraikan proses transisi yang disarankan dan garis waktu yang dapat dipilih oleh pengelola proyek/pustaka untuk diadopsi.

Sehubungan dengan item terakhir, ini harus mencakup saran-saran seperti:

• Buat nomor rilis utama baru yang menunjukkan bahwa itu akan digunakan dengan aplikasi WinUI 3.0 (seperti WCT v6.0).
• Secara opsional (?) buat cabang untuk memuat kode lama yang akan mendukung proyek yang belum diperbarui ke WinUI 3.0.
• Berikan periode waktu (misalnya 3/6/12 bulan) di mana dukungan untuk proyek lama akan diberikan (yaitu menggabungkan perbaikan bug dan semacamnya dari cabang utama). Ini berpotensi memiliki tanggal tertentu untuk 'menyinkronkan' periode dukungan di seluruh proyek/perpustakaan komunitas.

Terakhir, saya merasa penting untuk mengidentifikasi apa yang dapat dilakukan jika Anda perlu mendukung Windows 10 versi 1507 & 1607 LTSB. Ini adalah satu-satunya 2 versi W10 yang didukung yang akan tersedia dan WinUI 3.0 tidak akan kompatibel dengannya pada waktu rilis.

Awalnya saya akan menyarankan untuk menguji proses dengan Kalkulator Windows 10, karena ini adalah aplikasi open source kualitas produksi. Namun, saya kemudian menyadari bahwa aplikasi ini perlu berjalan pada 1507 & 1607 LTSB selama 6-7 tahun lagi. Jelas akan ada beberapa perdebatan seputar mendukung jenis aplikasi ini, terutama ketika menyangkut proyek komunitas yang lebih kecil. Jika mereka benar-benar membutuhkan dukungan ini, maka strategi jangka panjang yang jelas tentang bagaimana melakukannya harus disediakan.

Mengenai WinUI 4.0/3.x/vNext

Seperti yang ditunjukkan oleh komentar di sini, komunitas memiliki daftar keinginan yang cukup panjang untuk rilis WinUI di masa mendatang. Kita harus benar-benar memanfaatkan momentum dan antusiasme yang sedang dibangun di sini dengan mendokumentasikan secara terbuka beberapa rencana jangka panjang.

Karena sebagian besar item ini berada di luar cakupan untuk v3.0, saya merasa masalah baru harus dibuat lebih cepat daripada nanti untuk mulai mengumpulkan umpan balik komunitas di WinUI 4.0/3.x/vNext. Jika ada, ini akan membantu mengidentifikasi kedua jenis pekerjaan yang sedang dipertimbangkan oleh tim WinUI, dan apa yang di luar cakupan untuk WinUI dan/atau tanggung jawab tim MS lainnya.

Contoh dari poin terakhir - Saya sangat ingin melihat hal-hal ini:

• Dukungan .NET Core 3.0 untuk proyek UWP (tanggung jawab tim .NET, seperti yang saya pahami)
• Dukungan penuh untuk Aplikasi Windows (UWP & Win32) dari Pusat Aplikasi Visual Studio (jelas bukan sesuatu yang menjadi tanggung jawab tim WinUI)
• Panduan Desain Lancar yang lebih konkret, mirip dengan yang dapat Anda temukan di dokumen Desain Material (sekali lagi, tanggung jawab tim terpisah)
• Penggunaan WinUI 3.0 & desain Lancar di aplikasi W10 dalam kotak (tim terpisah & beberapa aplikasi tersebut perlu mendukung versi LTSB)

Dengan mengidentifikasi item di luar cakupan ini, kami dapat mengarahkan komunitas ke titik umpan balik yang tepat, dan/atau menjelaskan apa yang terjadi di area tersebut.

Di luar hal-hal itu, daftar keinginan dalam lingkup dapat mulai berkumpul, dan komunitas dapat mulai menunjukkan dukungan mereka untuk apa yang paling mereka inginkan dari WinUI di masa depan.

Akan sangat bagus jika F# memiliki dukungan yang setara dengan C#, misalnya memiliki template proyek yang sama dengan C#.

Saya ingin WinUI (UWP vNext) memiliki objek Window yang tepat seperti yang dimiliki WPF, dengan metode Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency, dan Show() / ShowDialog().

(_Saya tidak yakin tentang bagaimana Jendela ini akan bekerja (atau diizinkan) pada perangkat layar kecil, seperti Ponsel dan IoT_)

@TonyHenrique ada API windowing baru untuk UWP pada tahun 1903, tetapi masih jauh dari selesai.

Sedang melihat kembali rendering XAML dalam lingkup WinUI 3.0.

Hal-hal yang saya rasakan sebagai langkah mundur dari rendering WPF adalah:

• Teks tidak menggunakan ClearType, alih-alih mendukung anti-aliasing skala abu-abu;
• Kurangnya Pixel Precision untuk hal-hal seperti garis tepi;

Saya bisa mengerti ketika Windows Phone 7 dan Windows Phone 8 harus berbagi sistem rendering - jenis teknologi layar, dan kecepatan rendering mendorong untuk menjadi lebih berperforma. Tetapi dengan WinUI berputar ke Desktop terlebih dahulu, dan tampilan yang lebih besar - mungkin sudah waktunya untuk mengembalikan kualitas ini ke mesin Render XAML.

Dan jika hal-hal seperti Hololens dan Xbox memerlukan pertimbangan khusus, mengapa tidak menawarkan mode kinerja yang dapat diaktifkan pada tingkat platform pada perangkat yang memerlukan rendering seperti sekarang?

Bagaimana dengan template f#?

Kecuali jika itu bekerja di luar kotak dalam formulir Windows standar dan templat proyek WPF yang menargetkan .NET Framework 4.5 atau yang lebih baru, kami tidak dapat mengadopsi perpustakaan WinUI.

Hanya membutuhkan rilis Windows 10 terbaru dan/atau aplikasi UWP adalah penghenti untuk mengadopsi desain Lancar.

Saya menyarankan agar Microsoft bekerja secara langsung dengan pengelola Windows Community Toolkit (beberapa di antaranya berfungsi untuk MS)

@kmgallahan
Saran yang bagus! Ini pasti dalam rencananya. Tim kami sering bekerja sama dengan pengelola Windows Community Toolkit dan ini adalah salah satu hal yang ingin kami gunakan sebagai proyek uji coba.

Sedang melihat kembali rendering XAML dalam lingkup WinUI 3.0.

@mdtauk
Setiap perubahan rendering kemungkinan berada di luar cakupan untuk 3.0, tetapi tolong buka masalah untuk itu sehingga kami berpotensi dapat meninjau kembali ide untuk rilis berikutnya. Fokus besar pasti adalah kinerja universal yang seperti yang Anda perhatikan menyebabkan beberapa perubahan rendering di Windows 8+. Sakelar mode kinerja adalah ide yang menarik.

Bagaimana dengan template f#?

@edgarsanchez , @khoshroomahdi
Sepertinya kami mendapatkan banyak minat pada F#! Kami ingin mendengar lebih banyak tentang mengapa Anda menginginkan F#: jangan ragu untuk berkomentar di edisi F# tentang mengapa Anda menginginkannya dan untuk apa Anda akan menggunakannya: #740

Kecuali jika itu bekerja di luar kotak dalam formulir Windows standar dan templat proyek WPF yang menargetkan .NET Framework 4.5 atau yang lebih baru, kami tidak dapat mengadopsi perpustakaan WinUI.

@jozefizso
Sudahkah Anda melihat ke Kepulauan Xaml? Fitur ini memungkinkan Anda menggunakan WinRT Xaml di aplikasi WPF dan Windows Forms sehingga Anda dapat mulai menyempurnakannya dengan tampilan/halaman Xaml modern:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

Kami berencana untuk WinUI 3.0 untuk menyertakan pulau dan kompatibel dengan Pembaruan Pembuat Konten dan yang lebih baru, yang setidaknya merupakan 5 versi Windows terakhir.

Bisakah Kepulauan Xaml yang bekerja pada Pembaruan Pembuat Konten dan yang lebih baru dengan WinUI 3.0 memenuhi kebutuhan Anda?

Setiap perubahan rendering kemungkinan berada di luar cakupan untuk 3.0, tetapi tolong buka masalah untuk itu sehingga kami berpotensi dapat meninjau kembali ide untuk rilis berikutnya. Fokus besar pasti adalah kinerja universal yang seperti yang Anda perhatikan menyebabkan beberapa perubahan rendering di Windows 8+. Sakelar mode kinerja adalah ide yang menarik.

Selesai #768

Kepulauan XAML memerlukan Windows 10, versi 1903 dan pustaka Windows Community Toolkit mengharuskan proyek menjadi UWP. Itu tidak boleh.

Kepulauan XAML memerlukan Windows 10, versi 1903 dan pustaka Windows Community Toolkit mengharuskan proyek menjadi UWP. Itu tidak boleh.

WinUI 3.0 tidak akan masuk ke Windows 7/8/8.1 - tetapi OS tersebut akan segera berakhir. Dan Anda masih dapat menggunakan WPF dan WinForms untuk saat ini. Ini untuk saat pengguna Anda telah pindah ke Windows 10

Dalam hal ini proyek akan menjadi UWP untuk Windows 10, jadi tidak ada gunanya mendukung WPF/WinForms. Ini hanya bergerak dalam lingkaran dan memecah-mecah alat pengembang.

@jozefizso Lebih akurat untuk mengatakan bahwa UWP berubah untuk memungkinkannya menjadi lebih seperti WPF dan WinForms, dan UI XAML semakin dekat dengan platform WPF dan WinForms.

Aplikasi UWP dengan UI XAML modern keluar dari kotak pasir yang membatasi, dan dapat terhubung ke platform WPF dan WinForms.

Ini adalah bagaimana saya memahaminya.

Kepulauan XAML memerlukan Windows 10, versi 1903

Dalam hal ini proyek akan menjadi UWP untuk Windows 10

Dengan WinUI 3.0, kami berencana untuk membuat pulau tersedia pada 1703 dan lebih tinggi (jauh lebih jauh ke belakang).

Kami juga berupaya agar WinUI dapat digunakan dengan model aplikasi Win32 alih-alih UWP (secara informal disebut "desktop WinUI"), jadi itu tidak harus berupa aplikasi UWP.

Kami juga berupaya agar WinUI dapat digunakan dengan model aplikasi Win32 alih-alih UWP (secara informal disebut "desktop WinUI"), jadi itu tidak harus berupa aplikasi UWP.

Ini adalah hal yang paling saya senangi. Aplikasi asli dengan API lengkap Windows yang tersedia, baik itu Win32 atau Windows Runtime, dapat memiliki UI berkinerja melalui Xaml.

Kami juga berupaya agar WinUI dapat digunakan dengan model aplikasi Win32 alih-alih UWP (secara informal disebut "desktop WinUI"), jadi itu tidak harus berupa aplikasi UWP.

Ini adalah hal yang paling saya senangi. Aplikasi asli dengan API lengkap Windows yang tersedia, baik itu Win32 atau Windows Runtime, dapat memiliki UI berkinerja melalui Xaml.

Ambil aplikasi WinForms, simpan kode di belakang, tetapi ganti Formulir dengan Jendela XAML, dan dapatkan akses ke semua kuas dan Kontrol XAML.

WPF akan sedikit lebih rumit untuk hanya menggunakan WinUI XAML di tempat - tetapi setidaknya kontrol WPF dapat ditata agar sesuai dengan yang WinUI

1. Namespace harus diganti namanya. "Xaml" tidak sesuai karena Xaml mengacu pada bahasa markup, yang salah digunakan sebagai bahasa pemasaran (yang sering berubah) untuk komponen UWP asli. "Xaml" harus diganti dengan "WinUI". Anda dapat melihat berapa banyak kebingungan yang disebabkan bahkan di utas ini, di mana sangat sering tidak jelas apakah "Xaml" merujuk ke bahasa .xaml atau ke komponen ui.
2. Sejauh ini menggerakkan WPF dan UWP lebih dekat, ini bagus. Mereka masing-masing memiliki fitur yang tidak ada di yang lain, dan masuk akal untuk memiliki "Windows UI" yang menggabungkan keduanya. Mungkin ada beberapa duplikasi fitur tetapi ini juga bisa menjadi jalur transisi WPF -> UWP.
3. Memisahkan dari versi windows masuk akal, tetapi juga OK untuk mengasumsikan Win10 yang relatif diperbarui, mengingat bahwa Win7 akan melewati EOL ketika pekerjaan ini selesai.

Xaml adalah nama kerangka UI. Oleh karena itu Windows.UI.Xaml...

Xaml adalah nama kerangka kerja UI

Xaml adalah teknologi di WPF yang memungkinkan pengembang untuk mendeskripsikan dan membangun tidak hanya adegan presentasi di dalam aplikasi mereka, tetapi juga aplikasi itu sendiri. Artinya, Anda dapat mendeskripsikan elemen UI _serta POCO_. Jika itu .NET, itu bisa dijelaskan dengan Xaml dan dimuat ke dalam konteks aplikasi.

Jangan sampai kita lupa (dan sepertinya kita punya) bahwa Xaml adalah singkatan dari eXtended Application Markup Language, yang berarti bahwa ini adalah bahasa markup yang memungkinkan Anda untuk mendeskripsikan komponen .NET _application_ secara elegan dan efisien. Sementara itu terutama digunakan untuk menggambarkan elemen antarmuka pengguna, itu tidak dalam praktiknya diturunkan atau dibatasi seperti itu.

Saya pribadi akhirnya menggunakan Xaml untuk menjelaskan seluruh konfigurasi aplikasi saya, menghapus dan mengganti App.config -- dan ya, bahkan Web.config -- kompleksitas kecuali dalam kasus untuk API eksternal yang benar-benar membutuhkannya.

Xaml adalah _not_ UI. Mereka adalah dua konsep yang sama sekali berbeda tetapi sayangnya telah digabungkan selama bertahun-tahun sekarang di bawah UWP. Saya sendiri akan _suka_ melihat istilah "Xaml" terlepas dari upaya ini, tetapi saya tidak terlalu yakin bahwa tindakan seperti itu akan dipertimbangkan, apalagi dilakukan.

@charlesroddie Saya agak setuju penamaannya benar-benar sewenang-wenang. Hanya garis singgung, jika Anda pernah memeriksa jejak tumpukan hal-hal yang berasal dari namespace WUXaml, itu sebenarnya secara internal di DirectUI namespace. Saya ingin mengetahui kisah Win8 jika ada orang di sini pada masa itu, karena saya membayangkan ada cerita yang berbeda. DirectComp untuk mengomposisi lapisan, DirectManipulation untuk pengguliran halus dan pita karet, dan kemudian Direct2D/DirectWrite sebagai mesin grafis vektor dengan DirectUI di atas untuk menyatukan semuanya. Kemudian untuk beberapa alasan, beberapa di antaranya kembali di-porting ke Win7, hanya bit Xaml yang diekspos melalui sistem WinRT, sementara semua API lainnya dibiarkan sebagai antarmuka com samar dengan pabrik dan pola aneh yang Anda perlukan untuk melihat sampel menjelaskan caranya memohon.

Sebenarnya, sekarang saya memikirkannya, akan sangat bagus jika, seperti WUComposition mengekspos DirectComp dan DirectManipulation melalui WinRT (atau itu menulis ulang), Direct2D/DirectWrite memiliki rumah resmi di sini juga. Mereka semua bekerja sama untuk mengaktifkan berbagai tingkat palka pelarian dan titik sentuh kesetiaan jika Anda mencarinya. Win2D benar-benar setengah matang dan juga bukan API yang bagus.

Windows.UI.Composition adalah penulisan ulang DirectComposition yang saya percaya. API serupa tetapi tidak sama.

Berhentilah menganggap semua monitor adalah sRGB lagi.
Perlakukan semua warna aplikasi lama sebagai sRGB dan lakukan konversi untuk setiap monitor selama komposisi.

Ini mungkin sedikit di luar topik, tetapi anggap Anda sudah memiliki aplikasi Win32 besar yang ditulis dalam C++, Anda ingin memodernisasi sistem UI, jadi Anda mungkin ingin menggunakan WinUI atau Comp dengan ketergantungan minimal, seperti menggunakan Comp saja tanpa in- set kontrol kotak, atau bahkan tanpa XAML .

Itu sudah mungkin sekarang, kita tidak perlu menunggu WinUI 3.0 untuk itu.

Terima kasih semua untuk umpan balik pada penamaan. Seperti yang dicatat, kami memiliki perbedaan hari ini antara "platform Xaml" dan "bahasa Xaml" (dengan spesifikasi/dialeknya sendiri yang berbeda) yang dapat membingungkan. Saya tidak berpikir rebranding besar ada di kartu tapi kami pasti mendiskusikan penamaan dan ruang nama.

Gunakan Windows.UI.Composition dalam aplikasi C++ Win32 tanpa XAML untuk memodernisasi aplikasi yang ada (seperti Photoshop). Mereka sudah memiliki arsitektur UI.

Ini mungkin sedikit di luar topik, tetapi anggap Anda sudah memiliki aplikasi Win32 besar yang ditulis dalam C++, Anda ingin memodernisasi sistem UI, jadi Anda mungkin ingin menggunakan WinUI atau Comp dengan ketergantungan minimal, seperti menggunakan Comp saja tanpa in- set kontrol kotak, atau bahkan tanpa XAML.

Terima kasih atas umpan baliknya - Saya pikir semoga ini bisa dilakukan pada akhirnya dengan WinUI 3, mirip dengan aplikasi "tanpa kerangka" menggunakan Windows.UI.Composition yang sudah dapat Anda lakukan hari ini. Kami akan mengingat hal ini saat kami menentukan cara menyusun paket dan dependensi WinUI NuGet.

Berhentilah menganggap semua monitor adalah sRGB lagi.
Perlakukan semua warna aplikasi lama sebagai sRGB dan lakukan konversi untuk setiap monitor selama komposisi.

@reli-msft bisakah Anda membuka masalah terpisah untuk melacaknya?

@jesbis #67

Apple hari ini mengumumkan SwiftUI...

Bagaimana jika Xaml Direct diberikan template Visual Studio untuk memungkinkan pengembang memilih untuk membuat aplikasi menggunakan kode alih-alih XAML dan kode di belakang.

Saya tidak berpikir rebranding besar ada di kartu tapi kami pasti mendiskusikan penamaan dan ruang nama.

Terima kasih @jesbis Saya menghargai Anda begitu terlibat dalam utas ini. Biasanya, sepertinya seseorang akan membuat postingan/pengumuman seperti ini dan kemudian membiarkannya mati (atau untuk dikelola oleh orang lain), jadi sangat menggembirakan melihat Anda sebagai penulis thread tidak hanya terlibat tetapi juga memperhatikan apa yang orang lain katakan. Terutama ketika yang lain adalah _me_. 😆

Dan Anda benar: ada 1) platform antarmuka pengguna dan 2) mekanisme bahasa/markup/deskripsi. Dalam sambutan kritis saya, saya akan mengatakan bahwa saya tidak pernah memberikan kredit yang cukup untuk platform antarmuka pengguna (pertama), karena saya tahu ada banyak pekerjaan hebat oleh tim Windows di sekitar ini. Itu tidak pernah menjadi perhatian bagi saya, secara pribadi. Ini adalah area ke-2 yang menarik kemarahan dan kekhawatiran saya (dan orang lain), dan kami melihat ini dalam masalah UserVoice yang muncul selama bertahun-tahun.

Semua ini mengatakan saya setidaknya akan meminta (memohon, bahkan ) untuk mempertimbangkan lebih lanjut upaya branding untuk mengkategorikan dua bidang ini dengan lebih baik. Saya pikir "Xaml Direct" adalah puncak kebingungan di sini, karena namanya menyiratkan "Bahasa Markup" - itu tepat dalam namanya! -- tetapi tidak ada yang seperti itu dalam penggunaan sebenarnya. Sangat membingungkan dan menyesatkan, dan penyalahgunaan merek, saya akan menawarkan.

Dan berbicara tentang Xaml Direct, @mdtauk :

Bagaimana jika Xaml Direct diberikan template Visual Studio untuk memungkinkan pengembang memilih untuk membuat aplikasi menggunakan kode alih-alih XAML dan kode di belakang.

Seperti pada sesuatu seperti CSharpForMarkup ?

Nama yang jauh lebih baik dan tepat daripada Xaml Direct, saya sarankan. Tentu saja, _any_ name adalah. 😉

Dan berbicara tentang Xaml Direct, @mdtauk :

Bagaimana jika Xaml Direct diberikan template Visual Studio untuk memungkinkan pengembang memilih untuk membuat aplikasi menggunakan kode alih-alih XAML dan kode di belakang.

Seperti pada sesuatu seperti CSharpForMarkup ?

Nama yang jauh lebih baik dan tepat daripada Xaml Direct, saya sarankan. Tentu saja, _any_ name adalah. 😉

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

Ini dirancang untuk middle-ware untuk menulis XAML UI dari kode, tetapi bagaimana jika ada template untuk menggunakannya sebagai ganti file XAML? Hanya sebuah pemikiran untuk diletakkan di luar sana...

@mdtauk YA! Jenis SwiftUI terlihat seperti Xaml tetapi dilakukan dalam kode. Saya sangat menyukai gagasan tentang segala sesuatu dalam kode seperti yang dilakukan React. Ini semacam sekolah lama untuk memecah file desain Anda dan kemudian menautkan dengan semacam kode di belakang, dan saya merasa sulit untuk mempertahankannya.

Seorang teman baru saja menyebutkan bahwa mereka membutuhkan mesin tata letak SwiftUI untuk bekerja dengan layar 120hz iPad Pro. Jadi itulah yang mereka fokuskan. Cukup menarik sebenarnya.

Saya membuat masalah baru #804 di mana diskusi tentang perubahan yang terinspirasi SwiftUI bisa dilakukan @ eklipse2k8

Tolong JANGAN LUPA untuk menambahkan template untuk Visual Basic.

Biarkan WPF untuk membangun lapisan bawah _on_ WinUI 3!

@reli-msft manfaat apa yang ingin Anda dapatkan dari memperbarui WPF?

Jika ada fitur WPF tertentu yang Anda andalkan yang ingin Anda lihat di WinUI maka kami akan senang mendengar lebih banyak di utas "Fitur WPF yang seharusnya ada di WinRT [WinUI]": https://github.com/microsoft /microsoft-ui-xaml/issues/719

Menutup demi terbitan baru yang disematkan #888

Sangat menantikan ini. Akan memecahkan banyak masalah khusus terkait versi.

@weitzhandler [pada 16 Mei 2019

Bagi saya, semua detail teknis kurang penting.
UWP, WPF, atau kerangka kerja khusus Windows apa pun, sehebat apa pun itu, tidak akan cukup lama sehingga tidak berjalan di setiap platform (setidaknya Windows, Droid, iOS, dan web), dan ramah dengan ukuran layar apa pun.

Sesuai dengan WinUI dan XAML secara umum, saya ingin melihat peningkatan dalam aspek-aspek berikut, beberapa di antaranya menurut saya mengganggu dan memperlambat pekerjaan saya.

• BANYAK lebih banyak konverter bawaan Harus ada satu ton konverter, beberapa di antaranya bahkan harus digunakan sebagai ekstensi markup untuk mengurangi verbositas. Ini juga harus mencakup meniadakan tindakan aritmatika sederhana, konverter objek ke boolean (salah menurut nilai semantik, yaitu string kosong, koleksi kosong, visibilitas tersembunyi, dll. per konteks).
• Sama seperti di atas tetapi dengan perilaku. Harus ada port yang mudah antara pengikatan dan peristiwa/tindakan. Akan jauh lebih mudah jika itu sudah built-in dan tidak membuat dev ragu-ragu NuGet mana yang tidak diuji untuk digunakan.
• Semua hal yang hilang dari WPF, seperti beberapa jenis pengikatan, ekstensi markup, tampilan umum, dan lainnya.

Terima kasih!

BANYAK lebih banyak konverter bawaan

Sejak mesin analitik Babbage, dan teori komputasi universal Turing, telah dimungkinkan untuk satu komputer yang dapat menjalankan program apa pun yang dapat dijalankan oleh komputer mana pun. Anda ingin kembali ke masa ketika kita harus membuat komputer baru untuk setiap perhitungan yang ingin Anda lakukan.

Seluruh bisnis konverter harus dibuang begitu saja.

objek ke konverter boolean

boolean adalah boolean. Objek lain bukan boolean. Dan tidak ada konversi alami dari objek ke boolean. Jenis penting dalam .Net dan sistem yang tidak diketik lebih lanjut tidak boleh diekspos ke pengguna.

Ya dan sistem yang tidak diketik seperti binding juga harus dibuang.

Seluruh bisnis konverter harus dibuang begitu saja.

Maksud saya apa alternatif Anda?
Titik sakit saya dengan konverter hanya Anda harus menulis ulang sendiri / memilih dari NuGet, dan mereka sangat bertele-tele. Bahwa selain mereka tidak fleksibel, tidak ada ekspresi seperti aritmatika atau negasi, dll.

boolean adalah boolean. Objek lain bukan boolean.

Anda benar, tetapi ketika datang ke UI, itu tidak terlalu penting.
Anda ingin menampilkan/menyembunyikan barang berdasarkan keadaan objek konvensional. Tidak semuanya harus memiliki properti visibilitas khusus.

sistem untyped yang ada seperti binding harus dibuang juga.

Hah? Saya sebenarnya berpikir itu memiliki keuntungan. Kopling longgar antara V dan VM bisa bagus.

sistem untyped yang ada seperti binding harus dibuang juga.

Kopling longgar antara V dan VM bisa bagus.

Untuk proyek kecil mungkin, tetapi ada abstraksi yang lebih baik untuk kopling longgar daripada benar-benar mematikan bantuan kompiler. Jika Anda pernah harus memelihara aplikasi besar dengan puluhan hingga ratusan tampilan dan ingin memfaktorkan ulang sesuatu yang dapat digunakan di banyak situs, tidak meminta kompiler memverifikasi kebenaran jalur pengikatan adalah penurunan besar dalam pengalaman pengembang. Ada alasan mengapa kami memiliki sistem tipe dalam bahasa kami, proyek besar benar-benar tidak dapat dipertahankan tanpa alat untuk membantu programmer, saat ini bahasa UI sangat tertinggal.

Binding yang dikompilasi sangat membantu untuk itu.

@weitzhandler maksud saya apa alternatif Anda?
... Tidak semuanya harus memiliki properti visibilitas khusus.
Hah? Saya sebenarnya berpikir [binding] memiliki keuntungan. Kopling longgar antara V dan VM bisa bagus.

Dalam kerangka reaktif yang baik, Anda dapat mendefinisikan variabel yang dapat diamati (dalam kode) seperti name:Mutable<string> dan kemudian memetakannya ke let visibility = name.map(fun s -> s <> "") dan kemudian mengikatnya untuk melihat properti dengan visibility.bind someView.set_IsVisible atau name.bind(fun s -> someView.IsVisible <- s <> "") .

Saya menggunakan https://github.com/ReedCopsey/Gjallarhorn tetapi ada berbagai kerangka kerja reaktif.

Perhatikan bahwa: 1. semuanya diketik, tidak seperti binding. 2. Hal-hal (fungsi, properti, tampilan) dirujuk sebagai objek, bukan dengan melewatkan nama string, 3. fungsi hanyalah fungsi, apalagi kikuk daripada konverter, 4. mengikat boilerplate, di mana properti objek sederhana perlu diberi tambahan "properti yang dapat diikat" dll., Dapat dihapus.

Tampilan masih dapat ditulis dalam Xaml, terutama jika kebanyakan layout statis sederhana, dengan kelemahan string ajaib di mana-mana, tetapi keuntungan memiliki desainer untuk memberikan tampilan langsung. Lebih baik memiliki kode yang memberikan tampilan langsung. Sangat mungkin dengan juru bahasa.

Berbicara tentang kerangka kerja reaktif, silakan periksa Chain Reactive dan beri tahu apakah saya harus membukanya.

Hai, dapatkah tim ms menyelesaikan semua bug/fitur pada suara pengguna ?
Jika ya, itu akan menjadi langkah yang bagus, lebih dari WinUI 3.0.

@ hupo376787 Saya pikir Anda mendapat downvotes karena ini bukan utas untuk membahas platform pengembangan windows secara lebih luas, dan bahkan repo ini kemungkinan juga bukan tempat yang tepat karena berfokus hanya pada satu aspek platform ini.

Tapi itu adalah masalah bahwa tidak ada tempat untuk diskusi terbuka tentang platform pengembangan windows yang dapat diikuti oleh microsoft dan pengembang, dan itu adalah masalah bahwa grup microsoft yang relevan tidak memelihara mekanisme umpan balik apa pun, karena tidak memperbarui atau menanggapinya suara pengguna selama beberapa tahun.

@charlesroddie Ya, sepertinya suara pengguna ditinggalkan. Saya akan mengirimkan suara saya ke Hub Umpan Balik. Mungkin ms akan mengabaikannya, tetapi saya akan melakukan pekerjaan saya.

UserVoice akan dihentikan sepenuhnya bulan ini.

Untuk produk tertentu, repo GitHub (seperti ini) adalah tempat terbaik untuk umpan balik karena tim teknik yang relevan secara aktif menggunakannya.

Untuk umpan balik yang tidak terkait dengan produk repo tertentu, harap gunakan Hub Umpan Balik. Ada kategori "Platform Pengembang" dengan berbagai subkategori khusus untuk umpan balik tentang API dan alat pengembang.

Saya tahu ada banyak riwayat dan umpan balik sebelumnya saat ini di UserVoice (yang masih akan kami lacak), tetapi GitHub dan Umpan Balik Hub memberikan jalur yang lebih langsung ke tim teknik dan pelacakan item kerja kami daripada yang bisa dilakukan UserVoice, jadi semoga ini harus menjadi perubahan yang positif. Kami sedang dalam proses memperbarui berbagai tautan dukungan dan umpan balik.

Kami melihat semua yang masuk dari salah satu saluran dan sangat menghargai umpan balik dan laporan bug!

@jesbis Oke, mengerti.

Untuk WinForms, saat menggunakan templat proyek WinUI yang baru, akankah Jendela Properti masih berfungsi dan dapat mengatur properti kontrol WinUI? Saya dapat mengkodekan HTML sepanjang hari tanpa masalah (biasanya Asp.net MVC), tetapi ketika ada begitu banyak pengaturan yang tersedia untuk kontrol, saya menikmati menggunakan jendela properti selama 20 tahun terakhir.

@Dean-NC Saya kira Anda bertanya tentang perancang XAML, tidak ada Formulir WinFoms/Windows, bukan? Jika demikian, ya, Panel Properti akan tetap berfungsi untuk kontrol WinUI saat Anda memilih item pada desainer XAML.

@ marb2000 Saya kira saya secara naif berpikir bahwa WinUI 3 akan membawa kontrol baru ke WinForms dalam arti bahwa sebagian besar akan mulus, dan bahwa saya dapat memiliki formulir dengan kontrol warisan dan WinUI di atasnya, dan bahwa Jendela Properti akan berfungsi untuk kontrol warisan dan WinUI.

Saya membaca seluruh posting di atas, dan saya telah mengikuti ini dengan banyak kegembiraan (sebagai pengembang WinForms), tetapi saya kira saya telah salah memahami alur kerja tingkat tinggi tentang bagaimana ini akan bekerja (sekali lagi, dari sudut pandang WinForms ).

Saya sudah mengatakan sejak lama bahwa WinForms masih bisa menjadi hal yang hebat untuk tahun-tahun mendatang, tetapi kelemahan terbesarnya adalah kontrol dasarnya terlihat kuno (kotak teks tidak mengizinkan padding, sehingga terlihat kurus, radio kecil dan tombol kotak centang , dll.). Hanya dasar-dasar kontrol Win 10 (kotak teks, radio, kotak centang) akan membawa kehidupan baru ke WinForms.
Apakah ada artikel, atau apakah Anda keberatan memberikan deskripsi singkat tentang bagaimana alur kerja untuk proyek WinForms baru yang ingin menggunakan kontrol lama dan yang baru?
Terima kasih.

@ marb2000 Saya kira saya secara naif berpikir bahwa WinUI 3 akan membawa kontrol baru ke WinForms dalam arti bahwa sebagian besar akan mulus, dan bahwa saya dapat memiliki formulir dengan kontrol warisan dan WinUI di atasnya, dan bahwa Jendela Properti akan berfungsi untuk kontrol warisan dan WinUI.

Saya membaca seluruh posting di atas, dan saya telah mengikuti ini dengan banyak kegembiraan (sebagai pengembang WinForms), tetapi saya kira saya telah salah memahami alur kerja tingkat tinggi tentang bagaimana ini akan bekerja (sekali lagi, dari sudut pandang WinForms ).

Saya sudah mengatakan sejak lama bahwa WinForms masih bisa menjadi hal yang hebat untuk tahun-tahun mendatang, tetapi kelemahan terbesarnya adalah kontrol dasarnya terlihat kuno (kotak teks tidak mengizinkan padding, sehingga terlihat kurus, radio kecil dan tombol kotak centang , dll.). Hanya dasar-dasar kontrol Win 10 (kotak teks, radio, kotak centang) akan membawa kehidupan baru ke WinForms.
Apakah ada artikel, atau apakah Anda keberatan memberikan deskripsi singkat tentang bagaimana alur kerja untuk proyek WinForms baru yang ingin menggunakan kontrol lama dan yang baru?
Terima kasih.

Kemungkinan besar Anda akan dapat mengambil proyek aplikasi Anda, menambahkan jendela dan halaman WinUI, dan menggunakan UI XAML modern untuk mengganti UI Anda secara total, atau sedikit demi sedikit.

Dan ada Pulau XAML untuk memasukkan XAML ke dalam Winforms dan WPF UI yang ada

Tim Blazor Anda harus bekerja dengan Uno untuk mendapatkan beberapa model hosting yang disertakan dalam Uno (khususnya sisi server), dan/atau untuk mendapatkan UI Uno (dan dengan demikian WinUI 3) rendering/lapisan visual yang dapat digunakan oleh Blazor.... dan/atau mungkin Xaml Islands untuk Blazor ?

Saya merasa sedikit keluar dari sini karena sebagian besar umpan balik berasal dari pengembang yang bekerja terutama di ruang xaml. Mereka umumnya tampaknya mencari versi yang lebih baik dari apa yang sudah mereka miliki. Itu mungkin bagus untuk pengguna yang sudah ada tetapi saya tidak tahu apakah itu akan menarik banyak pengembang yang telah menghindari UWP hingga saat ini.

Tim saya hanya mengembangkan 1 aplikasi UWP. Kami tidak akan berkembang lagi.

Hambatan yang tidak dapat diatasi adalah kurangnya penulis laporan yang ditabulasikan. Kami telah mencoba semua penulis laporan pihak ke-3 di pasar yang mengatakan bahwa mereka mendukung UWP. Sayangnya tidak satupun dari mereka bekerja dengan baik dengan UWP. Penawaran UWP mereka biasanya merupakan peretasan cepat dari varian WPF/WinForms mereka dan tidak akan berfungsi dengan baik.

Kami menggunakan Laporan Stimulsoft dalam produk UWP kami. Ini sangat buggy dan mereka telah memberi tahu kami bahwa mereka tidak akan memperbaiki bug karena serapan UWP mereka sangat rendah.

Saya melihat Anda memiliki visualisasi data dalam daftar. Tetapi alasan masih ada jutaan aplikasi abu-abu kapal perang di luar sana adalah karena banyak bisnis tidak terlalu peduli dengan visual untuk aplikasi internal. Mereka menginginkan kolom angka dengan sub-total.

Jadi jika WinUI dimaksudkan untuk akhirnya memikat formulir di atas pengembang data, maka kita memerlukan penulis laporan tabulasi bawaan.

Saya harap ini tidak menyinggung orang-orang visual :-)

Saya setuju sepenuhnya. Bagaimana kita bisa mengembangkan aplikasi bisnis modern tanpa sistem pelaporan yang dapat dengan mudah diintegrasikan dengan aplikasi? itu adalah ngarai besar yang akan menghentikan pengembang pindah.

Pengguna bisnis harus dapat berinteraksi dengan data yang ditabulasi dan kemudian mencetaknya atau mengekspornya ke format lain. Mereka juga harus mampu membuat Faktur, kutipan, pernyataan dan dokumen instrumental lainnya.

Ini pemahaman saya bahwa bisnis/perusahaan masih merupakan konsumen terbesar Windows. Mengapa sesuatu yang sangat mendasar bagi ekosistem Windows tidak dikembangkan untuk UWP?

Terima kasih atas umpan baliknya @VagueGit dan @Elmarcotoro ! Kontrol perusahaan adalah celah bagi kami saat ini. Tapi waktu Anda tepat, kami mengumpulkan umpan balik untuk desain kontrol DataGrid. Silakan baca dan beri umpan balik di sini: #1500 .

Demikian juga, selain kontrol data tabular persegi, kita membutuhkan kontrol grafik UWP opensource untuk secara kreatif dalam mendemokratisasikan cara berbagi hubungan yang kompleks melalui kontrol diagram

Untuk sistem pelaporan, menurut saya Telerik UI adalah pilihan terbaik saat ini. Sebuah pepatah Cina mengatakan "Beberapa orang mengkhususkan diri dalam beberapa profesi sementara yang lain dalam profesi lain.". Telerik, atau DevExpress atau orang lain, pandai melaporkan.

Untuk kurangnya berbagai kontrol, kita tidak harus menyalahkan tim ini, tetapi untuk keseluruhan strategi MS. Dari awal Satya meninggalkan ponsel, mereka lebih memilih ios & android lebih baik, karena bos seperti mereka. Seluruh ekosistem UWP menjadi lemah dan lemah.

Untuk saat ini, ada argumen bernama "UWP sudah mati" di twitter, saya pikir MS harus mengklarifikasi ini dan menyatakan jalan uwp mereka.

Untuk saat ini, ada argumen bernama "UWP sudah mati" di twitter, saya pikir MS harus mengklarifikasi ini dan menyatakan jalan uwp mereka.

Anda baru saja mempostingnya di utas peta jalan ...

@jevansaks Terima kasih atas info tentang kontrol Datagrid. Ini tidak berurusan dengan masalah pencetakan laporan dan pagination, mengekspor dan semacamnya. Ini adalah skenario bisnis kehidupan nyata yang perlu ditangani, bukan apakah beberapa tombol bernyawa (sebagus dan sekeren ini).

@hupo376787
"Untuk sistem pelaporan, saya pikir Telerik UI adalah pilihan terbaik saat ini."

Dari apa yang saya lihat, Dev Express adalah satu-satunya yang saat ini menyediakan tumpukan lengkap untuk membuat dan melihat laporan untuk UWP, dan harga mereka tampaknya berada di sisi premium. Semua yang lain termasuk Telerik memiliki celah dalam alat mereka yang berarti laporan untuk UWP tidak dapat dibuat. Saya bersedia (berharap) untuk dikoreksi dalam hal ini.

Untuk sistem pelaporan, menurut saya Telerik UI adalah pilihan terbaik saat ini. Sebuah pepatah Cina mengatakan "Beberapa orang mengkhususkan diri dalam beberapa profesi sementara yang lain dalam profesi lain.". Telerik, atau DevExpress atau orang lain, pandai melaporkan.

@hupo376787 harap berhati-hati untuk memeriksa fakta Anda sebelum menyiratkan bahwa postingan itu salah. Telerik Reporting memiliki perancang laporan untuk WPF dan WinForms tetapi tidak untuk UWP.

DevExpress juga memiliki perancang laporan untuk WinForms dan WPF, tetapi tidak untuk UWP

Jadi tolong periksa fakta Anda sebelum melakukan kesalahan yang akan disimpan selamanya dan diedarkan secara luas. Hei itu terdengar seperti pepatah lama suatu hari nanti

@hupo376787 harap berhati-hati untuk memeriksa fakta Anda sebelum menyiratkan bahwa postingan itu salah. Telerik Reporting memiliki perancang laporan untuk WPF dan WinForms tetapi tidak untuk UWP.

DevExpress juga memiliki perancang laporan untuk WinForms dan WPF, tetapi tidak untuk UWP

Jadi tolong periksa fakta Anda sebelum melakukan kesalahan yang akan disimpan selamanya dan diedarkan secara luas. Hei itu terdengar seperti pepatah lama suatu hari nanti

Oke, saya pikir kita memiliki pemahaman yang berbeda tentang Pelaporan. Maksud saya https://www.telerik.com/universal-windows-platform-ui dan https://www.devexpress.com/products/net/controls/win10apps/.

Saya salah, Dev Express tidak menyediakan pelaporan untuk UWP. Tampaknya tidak ada pengembang alat pihak ketiga yang melakukannya! Saya menghubungi Dev express melalui obrolan mereka, tentang apakah mereka memiliki peta jalan untuk menyediakan pelaporan untuk UWP.
Mereka berkata,
"XtraReports Suite menggunakan fungsionalitas yang disediakan oleh rakitan System.Drawing dan hal yang mencegah kami mengimplementasikan seperangkat alat yang sama untuk Aplikasi Jendela Universal adalah bahwa rakitan ini tidak tersedia di sana (https://stackoverflow.com/questions /31545389/windows-universal-app-with-system-drawing-and-possible-alternative). Jadi, kami belum menetapkan rencana masa depan kami di area ini."

@jevansaks , sepertinya ada kekurangan komunikasi antara tim Microsoft UI dan penyedia alat pihak ketiga ini. Kami akan senang menggunakan alat pihak ketiga, tetapi sepertinya platform UWP mempersulit perusahaan-perusahaan ini untuk mengintegrasikan alat yang mereka miliki untuk platform lain ke dalam UWP.

Mereka meminta saya untuk menghubungi [email protected] mereka dengan persyaratan pelaporan kami, mungkin akan membantu tim Win UI 3.0 untuk menghubungi mereka dan melihat apakah mereka adalah cara untuk membantu mereka dalam implementasi. Saya tidak melihat bagaimana Anda akan mendapatkan pengembang bisnis di platform universal tanpa alat pelaporan yang tepat.

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

Pelaporan: hanya dari perspektif WinForms, saya telah menggunakan Telerik dan DevExpress (bahkan versi terbaru mereka), dan meskipun Telerik bagus, saya pikir DevExpress tidak hanya memiliki desain dan pengalaman keseluruhan yang lebih baik, tetapi juga memiliki lebih banyak fitur halus yang memungkinkan saya untuk melakukan tata letak yang lebih kompleks daripada Telerik. Saya pikir teknologi rendering DevExpress lebih maju.

mungkin bermanfaat bagi tim Win UI 3.0 untuk menghubungi mereka dan melihat apakah mereka adalah cara untuk membantu mereka dalam implementasi.

Terima kasih atas panggilannya. Kami juga akan menghubungi mereka.

Terima kasih atas panggilannya. Kami juga akan menghubungi mereka.

Mungkin ada baiknya berbicara dengan mereka semua dan melihat apa bloknya? Telerik, Grapecity, DevExpress dll.

Terima kasih atas panggilannya. Kami juga akan menghubungi mereka.

Mungkin ada baiknya berbicara dengan mereka semua dan melihat apa bloknya? Telerik, Grapecity, DevExpress dll.

Yang pasti, itu rencana kami.

Kami sedikit berbeda dari kebanyakan pengembang yang membangun untuk Windows. Kami mengembangkan sebagian besar aplikasi kios (aplikasi yang dimaksudkan untuk dijalankan oleh pengguna selain pemilik komputer, dan biasanya layar penuh tanpa akses ke sistem yang lebih luas). Aplikasi umumnya dibuat untuk kebutuhan spesifik pelanggan, tanpa niat untuk mendistribusikannya melalui toko atau yang setara.

Karena aplikasi berjalan dalam layar penuh, ada nilai yang sangat terbatas dalam kontrol bawaan yang mempertahankan tampilan dan nuansa aplikasi Windows lainnya; sebaliknya mereka cenderung sangat bermerek untuk setiap pelanggan. Kami masih membutuhkan banyak _behaviour_ umum dan kontrol dari aplikasi Windows standar, tetapi kami biasanya melakukan banyak penyesuaian dari masing-masing template kontrol atau setidaknya mengganti gaya intinya. Untuk waktu yang sangat lama kami membangun banyak aplikasi sebagai backend WinForms dengan frontend Flash tertanam untuk UI.

Secara garis besar hampir setiap aplikasi yang kami tulis mengintegrasikan beberapa jenis backend berbasis web dengan beberapa perangkat keras (misalnya printer, pemindai kode batang, pembaca garis mag, pemindai RFID, kamera, perangkat keras pembayaran kartu, pembayaran tunai gaya penjual otomatis komponen, dll.), dan sebagian besar komponen tersebut secara historis telah datang dengan SDK Win32 dan bukan yang UWP.

Karena dua alasan tersebut, sebagian besar aplikasi historis kami adalah aplikasi WinForms, dan sebagian besar aplikasi modern kami adalah aplikasi WPF. Kami telah membangun beberapa aplikasi UWP (sebagian besar untuk mendapatkan manfaat dari kemampuan mode Akses/Kios yang Ditugaskan yang sangat bagus dari Windows), tetapi mereka biasanya sulit untuk dikerjakan dibandingkan dengan WPF, dan kami biasanya tidak bisa mendapatkan SDK perangkat keras yang kompatibel. .

Kami sangat tertarik dengan Pulau XAML, untuk memungkinkan kami menulis aplikasi yang kompatibel dengan Win32 dengan UI modern (walaupun keuntungan UWP dibandingkan WPF bagi kami tidak selalu jelas, terutama jika kami tidak menggunakan kontrol standar atau khusus Microsoft efek seperti Lancar, dll.).

Untuk menjawab pertanyaan spesifik Anda:

Template apa yang paling menarik bagi Anda?

C# dengan .NET Core, Win32 dengan overlay WinUI 3.0 akan menyenangkan.

Apakah Anda mengetahui Pulau Xaml untuk memodernisasi aplikasi desktop?

Ya, dan saya relatif senang dengan mereka ketika saya telah bermain dengan mereka, meskipun kami tidak akan menggunakan _single_ kontrol, seperti membuat keputusan untuk seluruh UI kustom.

Alasan utama saya mengetahuinya adalah karena kami akan mendapatkan dukungan Lottie untuk aplikasi Win32.

Apakah kompatibilitas mundur yang diperluas ini pada Windows 10 membuat Xaml Islands lebih berguna bagi Anda?

Tidak juga; kami hampir selalu mengontrol PC target dan dapat memastikan kami selalu mendapatkan rilis terbaru yang kompatibel.

Apakah akan membantu jika Visual Studio atau alat lain secara otomatis memperbarui ruang nama untuk Anda?

Ya.

Seberapa penting bagi Anda kompatibilitas penuh antara komponen UWP Xaml yang ada dan aplikasi WinUI 3.0?

Sangat minim. Sakit kepala kompatibilitas utama yang kami miliki akan mengubah kunci StaticResource untuk menata elemen inti.

Apakah Anda membuat atau menggunakan pustaka kontrol UWP Xaml atau komponen WinRT yang tidak dapat Anda kompilasi ulang dan perbarui dengan mudah bersama kode aplikasi?

Ya, kami telah menggunakan perpustakaan kontrol Syncfusion UWP di masa lalu.

Apa solusi pilihan Anda untuk menggunakan komponen UWP Xaml dengan WinUI 3?

Solusi yang lebih disukai adalah memiliki lebih banyak kontrol standar yang tersedia di WinUI sendiri daripada bersandar pada sumber luar (misalnya pemirsa dokumen), tetapi saya berharap perpustakaan komponen eksternal tersebut biasanya akan lebih progresif dalam memperbarui perpustakaan mereka daripada saat kita beralih ke WinUI 3 untuk sebagian besar.

Apa pendapat Anda tentang keseluruhan rencana 3.0 yang diuraikan di atas dan di peta jalan? Apakah ini memungkinkan Anda menggunakan WinUI untuk aplikasi Windows baru dan yang sudah ada?

Saya senang melihat kontrol UWP menjadi lebih jelas dipisahkan dari aplikasi UWP dan model keamanan yang secara historis mengunci kami karena alasan kompatibilitas perangkat keras, terutama karena WinUI sedang dirancang dan dikembangkan di tempat terbuka.

Dengan panduan yang jelas tentang bagaimana Microsoft merekomendasikan kami untuk membangun UI aplikasi, saya berharap semua aplikasi kami akan berakhir dengan frontend WinUI, terlepas dari backend mana yang dapat kami dukung.

Jenis aplikasi apa yang paling membuat Anda tertarik untuk menggunakan WinUI 3.0? Membuat aplikasi Win32 baru dan mengemasnya dengan MSIX? Menambahkan tampilan baru ke aplikasi WPF? Memodernisasi aplikasi C++ MFC dengan UI Lancar?

Sebagian besar tentang mendapatkan akses ke perpustakaan kontrol yang lebih aktif dipelihara di aplikasi saya yang lebih lama, dengan dokumentasi yang lebih bagus dan lebih jelas (atau bahkan akses ke kode yang mendasari untuk kontrol standar) membuatnya lebih mudah untuk mengetahui kapan saya dapat mengadaptasi kontrol standar dan ketika saya perlu menggulung kontrol pengguna saya sendiri. Misalnya, dalam aplikasi terbaru yang dibangun di WPF, saya memiliki beberapa pemilih tanggal; membuat kontrol itu berfungsi dengan baik untuk sentuhan, dan menyesuaikan ukuran, font, ikon pop-up, dll. sangat mengganggu. Saya cenderung menggunakan WinUI untuk aplikasi semacam itu dengan _default_ di masa mendatang mengingat peta jalan di atas, karena:

1. Saya cukup yakin bahwa ada kontrol pemilih tanggal asli yang setidaknya cukup ramah sentuhan
2. Saya dapat memeriksa templat asli/di luar kotak kontrol itu, dll., Dengan mudah untuk melihat apa yang perlu saya timpa agar sesuai dengan bukti desain untuk tampilan dan nuansa pelanggan (sebagai contoh yang kurang lebih representatif, saya mungkin ingin untuk mengetahui cara terbersih untuk menata jenis — ukuran font, berat, keluarga — dari Header kontrol TextBox secara independen dari teks inputnya; apakah HeaderTemplate standar menggunakan sumber daya statis ajaib yang dapat saya definisikan ulang atau apakah saya perlu mengganti templat itu sendiri? Jika saya mengganti template, seperti apa tampilan markup template default; apakah itu melakukan/mendukung apa pun yang tidak saya pertimbangkan?).

Saya melihat bahwa ini telah ditutup, tetapi ada beberapa masalah yang diangkat oleh pengguna kami yang menurut saya layak untuk diangkat. Mereka adalah peningkatan produktivitas bagi pengguna yang bekerja dengan data dalam jumlah besar.

Kotak teks:
Jika pengguna perlu mengedit TextBox, pertama-tama mereka harus mengklik TextBox untuk menampilkan tombol hapus dan kemudian klik tombol clear untuk mengosongkan TextBox. Ini sangat tidak efisien ketika bekerja dengan data dalam jumlah besar. Akan lebih baik jika ketika pengguna mengklik atau tab ke dalam TextBox teks dapat disorot siap untuk ditulis.

Tampilan Grid/ Tampilan Daftar:
Gridview dan ListView tampaknya tidak memungkinkan pengguna untuk secara efektif Tab melalui koleksi.
ListView memungkinkan Tab untuk berpindah ke kontrol pada baris yang sama, tetapi Tab tidak akan berpindah ke baris kontrol berikutnya. Sebaliknya ListView kehilangan fokus dan Tab berpindah ke kontrol berikutnya di pohon visual.

Ini adalah dua masalah yang diangkat oleh pengguna kami sebagai sangat mengganggu.

@Elmarcotoro

Saya sarankan Anda membuat masalah baru untuk setiap peningkatan yang Anda sebutkan. Tim WinUI kemudian akan melakukan triase untuk menentukan apakah mereka memerlukan WinUI 3 untuk dirilis sebelum diterapkan atau tidak.

Masalah ini muncul terutama untuk mengumpulkan umpan balik mengenai 2 "Pertanyaan Umum" di bagian atas postingan.

Mendukung model hosting asli Blazor di WinUI. Ini akan memungkinkan kontrol Blazor untuk digunakan langsung di web Klien/Server, atau digunakan langsung di WinUI. Peta jalan Blazor memiliki konsep masa depan ini tanpa menggunakan kontrol WebView. Dengan cara ini UI kontrol berjalan asli dengan bagian .Net Standard dari kode juga menjalankan asli.

Mendukung model hosting asli Blazor di WinUI

Dibahas di pihak Blazor, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

Yang pasti, itu rencana kami.

@jevansaks Akan sangat bagus untuk masuk ke loop juga.

Saya ingin konsistensi yang lebih baik dari Menu Baki / Menu Ikon dengan WinUI 3.0. Setiap Aplikasi memiliki spasi yang berbeda, dan aplikasi Win32 tidak mengikuti rendering font / spasi / tema secara konsisten. Tolong perbaiki ini sudah!

WinUi di desktop sama sekali tidak berguna bagi saya karena kurangnya kemungkinan manajemen windows: tampilkan/sembunyikan jendela, posisi jendela, ukuran jendela, dok/undock ...

@alexandrevk itu masih pratinjau. Apakah Anda melihat desain API windowing? https://github.com/microsoft/ProjectReunion/issues/157

Terima kasih @dotMorten telah menautkan ke posting pengumuman windowing!

@alexandrevk - kami menyusun API untuk Reunion yang memungkinkan Anda melakukan jenis operasi windowing ini dari Win32 dan UWP dengan konten WinUI serta saat menggunakan kerangka kerja/konten swapchain lain di jendela Anda. Beberapa fitur windowing ini kemudian dapat diabstraksikan ke dalam kelas window WinUI untuk akses yang lebih mudah juga, tapi itu lebih jauh lagi. Spesifikasi fitur untuk area windowing ada di dalam pipa, pantau terus.

Berbicara secara ketat sebagai pengguna individu (yaitu: non-perusahaan/perusahaan) dan hanya c++, bahkan jika saya hanya seorang suara yang berteriak ke dalam kehampaan, saya merasa perlu untuk mengatakan, bahwa selama ada sistem UI baru ini terikat dengan UWP dan sistem pengemasan mengerikan yang mereka bangun, maka saya khawatir itu akan selalu dalam kegelapan apa pun yang Anda lakukan. (Berbicara dari pengalaman WinRT, belum mencoba WinUI tetapi terlihat hampir sama bagi saya).
Tentunya harus diketahui bahwa sedikit atau tidak ada yang benar-benar menggunakan aplikasi UWP? (sebenarnya dibenci oleh sebagian besar afaik) jadi jika itu akan disebut 'asli' lalu mengapa tidak benar -
Harus menggunakan hal-hal seperti Qt ketika cross-plat tidak menjadi perhatian, hanya untuk menghindari membungkus win32 untuk yang ke-1000 sudah agak tua untuk bersikap adil.
Pokoknya hanya 2 sen saya, dari seseorang yang menggunakan bahasa itu setiap hari, tetapi mungkin tidak punya tempat untuk berkomentar di sini.

@nl-n Anda harus senang mengetahui bahwa salah satu masalah besar dengan WinUI adalah tidak perlu dijalankan sebagai aplikasi UWP. Sebenarnya ini telah dimungkinkan sejak pratinjau 2.
_Saat ini_ memang membutuhkan pengemasan sebagai msix, tetapi msix sebenarnya adalah cara yang cukup baik untuk mendistribusikan (dan memperbarui) aplikasi Anda.

@dotMorten Itu salah satu masalah besar: membutuhkan pemuatan samping/pemasangan melalui toko. saya tidak tahu satu orang pun yang tidak menonaktifkan/mencabut toko sebelum (atau setelah) menginstal windows, jadi bagaimana kita harus mendistribusikannya?.
Saya tahu itu agak retoris tetapi itu benar. Saya seharusnya dapat meng-zip direktori build dan mendistribusikannya (atau penginstal jika diperlukan).
Lalu ada masalah kompatibilitas, banyak orang masih menolak untuk menginstal W10, jadi ada juga ...
Namun bagus untuk mendengar bahwa arah 3.0 sedang menuju, meskipun saya membenci xaml, itu akan menjadi tambahan yang disambut baik.
Mungkin kita bisa mendapatkannya tanpa perlu menginstal seluruh beban kerja UWP 50gb di VS juga? 🙏 (melebih-lebihkan saya tahu, tapi tetap saja)

Mengutip @MarkIngramUK di dekat awal utas ini:

Ini tahun 2019, saya menginginkan UI asli yang cepat, dan saya tidak ingin terlalu mempertimbangkan untuk membuat antarmuka pengguna dengan CreateWindowExW , GDI, dll.

yang (lucunya) benar-benar harus saya lakukan sekarang, dan ya itu sama menyakitkannya dengan kedengarannya :)

@nl-n siapa yang mengatakan sesuatu tentang toko? MSIX tidak jauh berbeda dengan menginstal dari MSI. Ini hanya penginstal aplikasi. Klik dua kali untuk menginstal. Tidak perlu toko. Menjamin penghapusan 100% bersih juga (berlawanan dengan MSI yang membuat kekacauan besar)

saya tidak tahu satu orang pun yang tidak menonaktifkan/mencopot toko

Padahal itu tidak umum.

bagaimana kita harus mendistribusikannya

Pertama-tama, Anda perlu memberi tahu pengguna untuk tidak menonaktifkan toko)

Saya seharusnya bisa meng-zip direktori build dan mendistribusikannya

MSIX dapat diinstal tanpa toko. Dengan versi Windows terbaru, pengguna tidak perlu mengaktifkan apa pun untuk itu. Tentu saja jika paket ditandatangani sebelumnya dengan sertifikat terpercaya. Tapi ya, jika pengguna menghapus toko dari PC, maka dia juga bisa menghapus MSIX/APPX AppInstaller darinya. Dalam hal ini mereka mungkin tidak menginginkan semua variabilitas aplikasi.

banyak orang masih menolak untuk menginstal W10,

Itu pilihan mereka. kata Nuf.

seluruh beban kerja UWP 50gb di VS juga

SDK tunggal sekitar 3GB. Tidak perlu mengunduh semuanya mulai 10240 satu.

@nl-n siapa yang mengatakan sesuatu tentang toko? MSIX tidak jauh berbeda dengan menginstal dari MSI. Ini hanya penginstal aplikasi. Klik dua kali untuk menginstal. Tidak perlu toko. Menjamin penghapusan 100% bersih juga (berlawanan dengan MSI yang membuat kekacauan besar)

Itu dari deskripsi yang diberikan studio visual kepada Anda, 'untuk sideloading/instalasi melalui toko microsoft', satu-satunya informasi lain yang saya temukan di msix adalah dari msdn, yang pada dasarnya mengatakan: paket msix adalah aplikasi 'appx' sandbox/virtualized , yang cukup mematikan untuk apa pun yang bekerja secara langsung dengan winapi. Dan mereka memerlukan penandatanganan agar dapat diinstal?...

Itu juga bisa jadi kabel silang saya kira, terlalu banyak terminologi yang berbeda, dan saya tidak tahu banyak tentang UWP.

Padahal itu tidak umum.

Lebih umum dari yang Anda pikirkan, dan dengan alasan

Bagaimanapun, itu bukan niat saya untuk menggagalkan, jadi saya akan kembali menulis hal-hal CreateWindowExW saya untuk saat ini