Terima kasih telah mendengarkan umpan balik komunitas. Saya sangat senang dengan WinUI 3.0 (Win32 + WinUI + C++). Ini terasa seperti kerangka kerja yang telah kita tunggu-tunggu! RIP GDI

(Model aplikasi Win32) + (WinUI 3.0 UI) + (.NET atau bahasa C++)

Jadi ini pada dasarnya akan menjadi UI UWP, tetapi tanpa siklus hidup dan kotak pasir seperti ponsel? Tampaknya menarik untuk aplikasi desktop, lalu – saya akan bereksperimen dengan ini.

Terima kasih atas pembaruannya, dan semoga lebih banyak pembaruan akan datang saat set fitur awal WinUI 3.0 dikunci, dan kontrol atau fitur kontrol baru apa pun yang telah diusulkan, yang mungkin membuatnya menjadi WinUI 3.0.

Oh dan dokumentasi tentang bagaimana WinUI di Desktop akan bekerja, dan berbeda dari UWP, WPF, dan Win32 akan sangat berguna untuk mendahului sekian banyak pertanyaan yang akan datang.

Mungkin matriks yang bagus dari apa yang disertakan dengan kombinasi kerangka kerja dan API mana, bersama dengan diagram arsitektur yang kami dapatkan di Build!

Kalian luar biasa, terima kasih untuk semuanya!
Bagian xplat membuat hari saya menyenangkan, terutama karena Uno ada di radar.

Fokus kami masih Windows 10 dan 8.1, tetapi kami mendengar umpan balik bahwa beberapa dari Anda masih memiliki pengguna & pelanggan di Win7 dan kami akan mengevaluasi pasar dan opsi dari waktu ke waktu.

Dengan asumsi implantasi kerangka UI ini dirancang dengan gagasan portabilitas, setidaknya cukup sehingga inti UI-nya (rendering / input) dapat berfungsi di bawah OS Windows apa pun yang mendukung .NET Core 3+ apa batasan pada Windows 7 yang akan ada bahkan menjadi? Sepertinya sebagian besar fitur yang digunakan orang di desktop hanya akan berfungsi dan untuk yang khusus/platform yang tidak, mungkin menjauhkan mereka dari menjadi bagian dari sistem UI inti dan menyimpannya dalam paket khusus platform seperti (Win10, Win8.1, Win7 Nuget dll).

Juga jika ada XAML lintas platform yang memiliki tampilan dan nuansa yang sama di semua perangkat (Win32, Android, iOS, dan WASM) seperti yang dapat Anda lakukan dengan HTML (tetapi sayangnya tidak untuk Xamarin), perusahaan saya akan melompatinya bertahun-tahun yang lalu.

Juga senang kalian menganggap ini sebagai "maraton (permainan Bungie yang hebat juga)". Semakin sedikit fragmentasi dalam ruang XAML semakin baik untuk semua orang dan mengambil banyak jalan pintas hanya akan membuat Anda kembali ke tempat Anda memulai;)

dokumentasi tentang bagaimana WinUI di Desktop akan bekerja, dan berbeda dari UWP, WPF, dan Win32 akan sangat berguna

Kami sedang mengerjakannya dan akan membagikan lebih banyak saat ini berkembang!

Dengan asumsi implantasi kerangka UI ini dirancang dengan gagasan portabilitas, setidaknya cukup sehingga inti UI-nya (rendering / input) dapat berfungsi di bawah OS Windows apa pun yang mendukung .NET Core 3+ apa batasan pada Windows 7 yang akan ada bahkan menjadi?

@zezba9000 WinUI tidak menggunakan .NET, dan Anda tidak perlu menggunakan .NET Core dengan WinUI: ini adalah kerangka kerja asli yang dibangun di atas API OS, dan bergantung pada fungsionalitas baru di Win8/Win10 yang tidak ada di Win7 - dalam beberapa kasus untuk fitur inti, bukan hanya fitur tambahan tingkat tinggi seperti kontrol khusus.

dokumentasi tentang bagaimana WinUI di Desktop akan bekerja, dan berbeda dari UWP, WPF, dan Win32 akan sangat berguna

Kami sedang mengerjakannya dan akan membagikan lebih banyak saat ini berkembang!

Dengan asumsi implantasi kerangka UI ini dirancang dengan gagasan portabilitas, setidaknya cukup sehingga inti UI-nya (rendering / input) dapat berfungsi di bawah OS Windows apa pun yang mendukung .NET Core 3+ apa batasan pada Windows 7 yang akan ada bahkan menjadi?

@zezba9000 WinUI tidak menggunakan .NET, dan Anda tidak perlu menggunakan .NET Core dengan WinUI: ini adalah kerangka kerja asli yang dibangun di atas API OS, dan bergantung pada fungsionalitas baru di Win8/Win10 yang tidak ada di Win7 - dalam beberapa kasus untuk fitur inti, bukan hanya fitur tambahan tingkat tinggi seperti kontrol khusus.

Untuk kompatibilitas Windows 7 - itu akan membutuhkan beberapa pihak ketiga untuk membangun penyaji mereka sendiri yang kompatibel untuk XAML, serta semacam Shim alternatif untuk API tingkat OS apa pun yang diperlukan.

Saat ini tidak ada ide apakah ini mungkin - harapannya adalah ketika bit WinUI dihapus dari OS, bit tersebut dimasukkan ke dalam proyek open source dengan cara tertentu, yang akan memungkinkan platform lain untuk menyediakan semacam komponen kompatibilitas. Pikirkan Xamarin, Uno, atau .Net Core dengan perender khusus.

ini adalah kerangka kerja asli yang dibangun di atas API OS, dan itu bergantung pada fungsionalitas baru di Win8/Win10 yang tidak ada di Win7 - dalam beberapa kasus untuk fitur inti

Dalam pikiran saya apa yang merupakan "fitur inti" tidak akan menjadi sesuatu yang bergantung pada spesifikasi OS selain tentu saja rendering dan input. Yang dalam kasus itu akan menjadi lapisan abstraksi yang dapat diperluas siapa pun. Pada tingkat dasar, satu teori harus dapat merender UI dengan perender perangkat lunak khusus dan melakukan Input dengan backend XInput khusus dengan kursor virtual jika diinginkan. Jika Anda dapat melakukan modularitas semacam itu, Anda dapat melakukan banyak hal dan memperluas dukungan platform menjadi sangat mudah (seperti yang dilakukan dalam game). Anda menghabiskan lebih banyak waktu di area ini dan di ujung jalan semuanya membutuhkan lebih sedikit usaha. Jika WPF XAML dirancang dengan cara ini, itu bisa saja diambil dan digunakan di aplikasi UWP. Hutang teknis hanya akan menjadi lingkaran tanpa akhir.

Hal-hal seperti dukungan tray-icon dll bisa dalam paket "WinUI Windows basic features (Win7-Win10)". Hal-hal seperti pemberitahuan push bisa ada dalam paket "Fitur yang diperluas WinUI Windows (Win8-Win10)".

Harapan itu masuk akal.

@mdtauk , @zezba9000 secara teori semuanya mungkin, dan kami memiliki banyak keahlian abstraksi platform dalam tim. Seperti apa pun, itu hanya tergantung pada biaya, jadwal, dan manfaat yang diharapkan 😊

Selain biaya pengembangan dan pengujian (yang akan meluas ke area yang berpotensi tidak terlihat, misalnya memastikan semuanya bekerja dengan teknologi bantu yang lama), kami juga harus mempertimbangkan biaya dukungan dalam rentang waktu yang lama.

Apakah Anda berharap memiliki pelanggan baru di Win7 di 2020+? Umpan balik dan kasus penggunaan yang pasti membantu kami memprioritaskan.

Selain biaya pengembangan dan pengujian (yang akan meluas ke area yang berpotensi tidak terlihat, misalnya memastikan semuanya bekerja dengan teknologi bantu yang lama), kami juga harus mempertimbangkan biaya dukungan dalam rentang waktu yang lama.

Apakah Anda berharap memiliki pelanggan baru di Win7 di 2020+? Umpan balik dan kasus penggunaan yang pasti membantu kami memprioritaskan.

@ jesbis Saya tidak melihat banyak manfaat dalam menambahkan kompatibilitas ke Win7 untuk WinUI 3.0 - Linux, Android, iOS, iPadOS dan MacOS, bagaimanapun, mungkin bermanfaat untuk menyediakan solusi lintas platform, yang tidak bergantung pada kerangka kerja UI asli.

@mdtauk
@jesbis Saya tidak melihat banyak manfaat dalam menambahkan kompatibilitas ke Win7 untuk WinUI 3.0 - Linux, Android, iOS, iPadOS dan MacOS, mungkin bermanfaat untuk menyediakan solusi lintas platform.

Setuju untuk itu. Saya baru saja menambahkan web-assembly, bagi saya itu bahkan lebih penting daripada Linux.

Apakah Anda berharap memiliki pelanggan baru di Win7 di 2020+? Umpan balik dan kasus penggunaan yang pasti membantu kami memprioritaskan.

Tidak, perusahaan saya tidak. Saya memberikan lebih banyak argumen desain di area yang saya lihat XAML berjuang dengan semua iterasinya (dari perspektif saya) tapi ya saya benar-benar mengerti mengapa MS tidak ingin menghabiskan waktu di sana. Namun akan lebih keren jika WinUI cukup mampu bagi orang lain untuk melakukan pekerjaan ini jika mereka perlu (yang cenderung terjadi, saya perhatikan) tanpa turun ke lubang kelinci dependensi Windows seperti halnya dengan WPF sekarang.

Untuk memperjelas apa yang ingin dilihat oleh perusahaan saya adalah dukungan Android dan WASM menjadi sedikit lebih resmi daripada UNO (dan 3 tahun yang lalu). Kami membuat perangkat lunak manajemen yang mengatur keadaan kumpulan komputer lokal dan pengaturan sistem biasanya melibatkan kebutuhan besar untuk Win32 API (UWP tidak akan pernah bekerja untuk kami tetapi kami menyukai UI karena kesalahan waktu kompilasi tidak seperti sistem pembuatan HTML) dan kami klien + kami membutuhkan pengalaman Win32 + Android + Browser UI yang memiliki pengalaman dan nuansa yang seragam. HTML hanyalah titik sakit besar karena menambahkan abstraksi dan kompleksitas yang tidak perlu yang seharusnya tidak perlu ada karena basis kode utama kami ada di C#.

Harapan thats umpan balik yang lebih baik untuk ya.

Juga ya WASM adalah target terbesar yang kami inginkan dibandingkan platform lainnya. JAUH!!
Karena ini memecahkan masalah Android / iOS / seluler kami serta hal-hal portal web.

Terima kasih telah mendengarkan umpan balik!

Desktop + WASM akan menjadi emas!

Wow, terima kasih atas teriakannya, @jesbis! Benar-benar tak terduga dan sangat dihargai dan dihormati. 👍

Diskusi seputar Windows 7 sedikit mengganggu, karena jumlah usaha (belum lagi biaya) akan menyebabkan penundaan yang signifikan untuk WinUI 3.0. Windows 7 akan berakhir pada bulan Januari, dan kami mendorong semua pelanggan untuk meningkatkan ke Windows 10. Pelanggan saya mungkin tidak selaras dengan yang lain di sini, tetapi bahkan Windows 8.1 bukanlah platform yang menarik bagi kami.

Cukup senang dengan pembaruannya. Target mendatang untuk WinUI terlihat sangat cerah dan menjanjikan! Bahkan bagian Xplat adalah sesuatu yang tidak saya harapkan tetapi sangat disambut. Akan menantikan untuk menggunakan peningkatan serta barang yang ada di toko untuk WinUI.

Terima kasih atas transparansi tim.

Saya ingin menyebutkan pentingnya perangkat lunak lini bisnis dalam membantu orang dalam memecahkan berbagai masalah.

Saya bekerja untuk sementara waktu dengan alat Lightswitch dan mendapatkan keuntungan yang signifikan dalam waktu konstruksi. Pengembangan aplikasi yang cepat sangat menjanjikan untuk aplikasi LOB. Namun dengan perang paten di USA yang sangat serius, butuh produk untuk dihentikan.

Kami tahu kami memiliki INotifyDataErrorInfo untuk pengiriman berikutnya. Tetapi akan sangat bagus jika WinUI memiliki sumber daya RAD untuk pengiriman di masa mendatang seperti 3.x dan seterusnya.

terima kasih tim, tidak sabar menunggu hari ketika Anda menulis di webassembly. itu akan membuat hari, tahun, dan dekade saya dan akan menempatkan MS di puncak tumpukan teknologi. WinUI + Xamarin + WASM + .NET => kedahsyatan murni !!

@jesbis Terima kasih atas pembaruan ini. Tim kerja yang baik :+1:. Memahaminya masih awal, kapan menurut Anda kita akan melihat tonggak sejarah WinUI 3.0 dibuat dan masalah ditandai dengannya?

kapan menurut Anda kita akan melihat tonggak WinUI 3.0 dibuat dan masalah ditandai?

@shaggygi Pertanyaan bagus! Saya baru saja membuatnya:

Tonggak sejarah WinUI 3.0

Ini luar biasa!

Pertanyaan singkat :
Dan dalam jangka waktu untuk mengharapkan ini, apakah ini saya 2-3 bulan atau lebih seperti, ketika 3.0 tersedia?

Di masa depan, ketika Anda berbicara tentang tahun (seperti dalam "akhir tahun"), tolong jelaskan tentang tahun kalender dan tahun keuangan [Microsoft].
Sangat mudah untuk mengalami kebingungan ketika ini tidak dinyatakan secara eksplisit dan saya telah mengetahui saat-saat ketika hal ini menyebabkan orang percaya bahwa hal-hal akan datang 6 bulan lebih awal dari yang dimaksudkan.

Memindahkan Windows.UI.Composition ke Microsoft.UI.Composition, ini mendekati 2.2 atau 3.0?

@jtorjo ini akan menjadi 3.0 (minimal). Kami berharap untuk menyertakan build awal di pratinjau pertama 3.0, tetapi belum 100% dijamin.

Di masa depan, ketika Anda berbicara tentang tahun (seperti dalam "akhir tahun"), tolong jelaskan tentang tahun kalender dan tahun keuangan [Microsoft].

@mrlacey terima kasih, saya akan mengingatnya! Semua tanggal yang kami gunakan umumnya adalah waktu kalender.

@jesbis Itu agak menyedihkan. Jadi Anda mengatakan bahwa mungkin saja kita tidak memiliki Microsoft.UI.Composition di 3.0?

@jtorjo

Kami berharap untuk menyertakan build awal di pratinjau pertama 3.0 , tetapi belum dijamin 100%

Seringkali ada banyak rilis pratinjau. .NET Core 3 ada di Pratinjau 6, misalnya.

Rencana kami adalah memasukkan API komposisi di 3.0.

Bagian kerangka kerja Xaml akan menjadi sumber terbuka sebelum bagian komposisi.

@jesbis Terima kasih, kedengarannya bagus!

Peta jalan yang fantastis, kerja bagus!

Seperti semua orang di sini, saya menyukai transparansi dan saya sangat menantikan WinUI 3.0. Bagi saya WinUI 3.0 adalah hal yang paling menarik sejak WPF diperkenalkan pada tahun 2006.

Saya juga masih memiliki pelanggan yang menjalankan Windows 7, tetapi saya pikir dukungan Windows 10 adalah yang paling penting dan saya tidak akan menghabiskan waktu dan sumber daya untuk dukungan Win7. Sebagian besar perusahaan tempat saya bekerja beralih ke 10. Dan saya pikir pada akhir tahun 2020 satu-satunya perusahaan yang saya ketahui yang masih menggunakan Windows 7 mungkin adalah dokter gigi saya. Dan jika dia meminta saya untuk menulis aplikasi Windows untuknya, saya akan memigrasikan PC-nya ke Windows 10. :-)

Dukungan WASM di masa depan akan luar biasa.

Kemarin di sebuah konferensi:

Sedikit cerita untuk menunjukkan kepada @jesbis dan tim bahwa kami yang menulis dan berpartisipasi di sini hanyalah puncak gunung es yang heboh. :-)

Baru kemarin saya mengobrol di konferensi pengembang di Jerman dengan beberapa pengembang .NET dan saya memberi tahu mereka tentang WinUI 3.0, dan mereka tidak mengetahuinya. Saya memberi tahu mereka tentang peta jalan dan mereka berkata:

"Wah, luar biasa".

Seorang gadis dari kelompok itu bertanya kepada saya:

"Tapi apakah Anda diizinkan untuk memberi tahu kami semua ini?"

Aku memandangnya dan yang lainnya, dan kemudian aku mengambil kesempatan untuk jeda retorika—

await Task.Delay(3000);

sebelum aku berkata

"Persetan ya! Anda dapat membaca ini semua di GitHub".

Terima kasih @jesbis dan semua orang yang terlibat. Waktu yang tepat untuk menjadi pengembang windows ❤️

Saya berharap aplikasi pihak pertama (seperti Word?) dapat menggunakan lapisan WinUI, dan pengembang akan senang melihat bahwa, "Hei, WinUI adalah hal yang nyata dapat menjalankan bisnis, bukan mainan".
Jika mereka sudah menggunakannya, katakan dengan lantang.

Akrilik untuk WPF, Win32, dan WinUI Desktop.

Oh dan mungkin pertimbangkan kembali Acrylic hanya pada kebijakan windows yang aktif.

Ya, jika Anda memiliki lebih dari 1 monitor, itu hanya merender dalam satu jendela. Setidaknya di beberapa monitor itu harus berfungsi dengan baik ....

Saya sedang memikirkan implikasi pengalaman pengembangan memiliki dua set kontrol UI yang tersedia di aplikasi UWP - ketika kita akan memiliki akses ke kontrol WinUI dan kontrol UI lama, ketika di belakang kode C#, IntelliSense karena akan selalu mengharuskan kita untuk melakukannya dengan benar pilih dari namespace mana kontrol harus berasal alih-alih pergi Alt + Enter untuk hanya menambahkan using dan melanjutkan. Apakah mungkin untuk menghindari ini entah bagaimana?

Setelah WinUI3 keluar untuk pengembang, Windows 10 SDK harus mempertimbangkan untuk menyarankan perubahan namespace untuk proyek yang dibuka dengan SDK yang didukung terpasang. Cobalah untuk menjauhkan orang dari namspaces OS.

Akrilik untuk WPF, Win32, dan WinUI Desktop.

Apa yang ingin saya lihat pertama adalah MS yang mematangkan Pulau Xaml sehingga, sebagai contoh, akrilik di bilah judul dapat digunakan untuk proyek non-UWP yang mendasarkan UI mereka pada WinUI (lihat paragraf terakhir dari posting ini ). @marb2000 mungkin adalah orang yang menanyakan hal ini.

@MartinZikmund Kami ingin menghindari skenario ini. Saat menggunakan WinUI 3 Anda seharusnya hanya memiliki akses ke kontrol dari paket. Idenya adalah bahwa kami memiliki semua yang Anda butuhkan dengan perubahan terbaru dan terhebat.

@MartinZikmund
@LucasHaines

Satu perbaikan seharusnya, bahwa Anda dapat mengecualikan Windows.UI.Xaml.* referensi WinMD dari build. Sekarang target build hanya merujuk pada Unified WinMD alias. Windows.winmd , tambahkan opsi di target untuk juga merujuk masing-masing WinMD, dengan begitu, kita dapat menyertakan atau mengecualikan referensi berdasarkan Aplikasi yang sedang kita buat.

Apakah ini caranya, maka tidak perlu mengubah namespace, karena ia berperilaku seperti .NET dll ia dapat bekerja dengan pengalihan Majelis ke versi lokal di dalam paket daripada yang disediakan sistem.

Saya tahu metode itu khusus untuk .NET Framework, tetapi untuk UAP, harus ada solusi untuk skenario semacam ini. Saya tahu ada FrameworkDependency pada manifes msix/appx . Mungkin kita dapat menggunakannya untuk memasok WinUI baru dengan ruang nama Windows.* daripada Microsoft.* .

Di sisi pengembang, kami tidak akan kesulitan untuk mengupgrade aplikasi kami, karena kami hanya mengubah referensi dan bukan kode !

Saya lebih suka tidak mengubah namespace sama sekali!

Manfaat:

1. Tidak perlu mengubah kode bolak-balik.

2. Setelah kode WinUI lokal distabilkan, Anda dapat menggabungkan kembali ke platform windows, sehingga aplikasi sistem dan aplikasi LOB dapat memanfaatkan peningkatan baru, pada setiap rilis windows baru.

3. Di satu sisi itu adalah kerangka kerja sistem yang sangat stabil dengan kompatibilitas tinggi seperti .NET Framework. Dan di sisi lain seperti .NET Core, dengan perubahan yang lebih cepat, dengan semua manfaat dari keduanya dan tidak ada masalah.

Baru saja menonton presentasi luar biasa oleh Steve Sanderson di UI Blazor + (non html) yang dibungkus dengan aplikasi asli lintas platform. Sekitar 52 menit ke dalam video. A harus melihat untuk UWP , WinUI dan c# penggemar. Saya sangat terkesan dengan blazer !!!

https://youtu.be/uW-Kk7Qpv5U

Satu hal yang saya lupa katakan dalam diskusi ini, yang menurut saya penting adalah...
Apakah WinUI 3.0 sendiri memiliki peningkatan kinerja? Mesin Rendering XAML baru saja dipisahkan atau sedang mengalami perubahan? Akankah kontrol XAML menggunakan Komposisi terutama, dan dengan demikian, digerakkan oleh off-thread dan dwm seperti DirectUI?

Beberapa kontrol kinerja, dan penggunaan RAM, bisa jauh lebih baik, Seperti ListView/GridView = ItemsControl.

Anda melihat ini di Windows itu sendiri. Windows 8 Start Menu (DirectUI) jauh lebih lancar daripada Windows 10 XAML Start Menu.
Coba muat GridView dengan info yang cukup, seperti halaman Album Groove, dan semuanya tidak berjalan dengan baik. Ini adalah sesuatu yang iOS dan Android berperilaku jauh lebih baik, dan begitu juga winforms, QT.
(WPF bahkan lebih buruk dari UWP XAML menurut saya).

Apakah WinUI 3.0 sendiri memiliki peningkatan kinerja? Mesin Rendering XAML baru saja dipisahkan atau sedang mengalami perubahan? Akankah kontrol XAML menggunakan Komposisi terutama, dan dengan demikian, digerakkan oleh off-thread dan dwm seperti DirectUI?

Performa jelas merupakan sesuatu yang ingin kami terus investasikan, tetapi saya tidak mengharapkan peningkatan apa pun untuk 3.0. Upaya 3.0 awal sebagian besar difokuskan pada decoupling Xaml untuk dikirimkan sebagai paket NuGet dan sumber terbuka.

WinUI 3.0 (seperti UWP Xaml hari ini) dibangun di atas lapisan komposisi dan menjalankan banyak rendering dan animasi di luar thread melalui DWM.

Ini adalah sesuatu yang iOS dan Android berperilaku jauh lebih baik, dan begitu juga winforms, QT.
(WPF bahkan lebih buruk dari UWP XAML menurut saya).

Seringkali ada tradeoff kinerja vs. fleksibilitas/kekayaan saat mempertimbangkan skenario ini. Platform berbasis Xaml (termasuk UWP dan WPF) cenderung memiliki pohon objek UI yang lebih besar dan lebih kaya untuk setiap kontrol: yang memberikan banyak fleksibilitas untuk mengubah gaya dan UX dari kontrol apa pun, sedangkan beberapa platform lain cenderung memiliki pohon objek yang jauh lebih datar yang tidak fleksibel tetapi terkadang dapat dimuat lebih cepat.

Pengorbanan itu jelas merupakan sesuatu yang kami pikirkan dan akan kami ingat untuk kemungkinan perubahan di masa depan. Fleksibilitas ekstra dari template kontrol Xaml yang kompleks tidak diperlukan dalam banyak waktu, jadi kami berpotensi menyederhanakan kontrol untuk memuat lebih cepat jika Anda tidak memerlukan fleksibilitas ekstra.

Saya berharap Microsoft dapat menyediakan comctl32.dll dan comdlg32.dll baru yang berbasis WinUI 3.0.

Karena sebagian besar aplikasi Win32 akan memiliki pengalaman UI modern dan ini akan membantu pengembang untuk menyesuaikan aplikasi mereka dengan UI modern.

Banyak pengembang Win32 perlu mengadaptasi beberapa versi Windows. Jadi mereka tidak bisa langsung menggunakan WinUI hari ini. Sangat bagus jika Microsoft dapat menyediakan metode untuk membantu mereka mengurangi beban kerja untuk memodernisasi UI aplikasi mereka.

Juga, saya berharap Microsoft dapat menyediakan desainer XAML untuk C++ Win32 Apps yang menggunakan WinUI.

Kenji Mouri

@MouriNaruto Anda dapat menggunakan FileOpenPicker hari ini (dari Win32).

@MouriNaruto Anda dapat menggunakan FileOpenPicker hari ini (dari Win32).

Saya tahu, tapi saya harap semua kontrol dan dialog umum modern akan dibawa ke Win32.

@MouriNaruto

Secara teknis Itu mungkin. Tetapi pengembang Windows harus membuat ulang tidak hanya perilaku yang tepat dari implementasi COMCTL dan COMDLG tetapi juga bug yang dikenal dan tidak dikenal yang ada di basis kode.

Kompatibilitas adalah musuh kami!

Bahkan jika mereka melakukannya, pada saat mereka menyelesaikannya, Setiap perangkat lunak yang menggunakan lib tersebut akan memiliki cukup waktu untuk bermigrasi ke WinUI! Ironi!! 🤨🤣

@MarkIngramUK

FYI : FileOpenPicker bukan Dialog/Kontrol WinRT asli. Ini pada dasarnya adalah pembungkus ExplorerFrame yang sendiri ditulis dalam DirectUI (dikembangkan oleh Tim ATG dan berdasarkan DirectX ) dan COM !

Secara teknis Itu mungkin. Tetapi pengembang Windows harus membuat ulang tidak hanya perilaku yang tepat dari implementasi COMCTL dan COMDLG tetapi juga bug yang dikenal dan tidak dikenal yang ada di basis kode.
Kompatibilitas adalah musuh kami!
Bahkan jika mereka melakukannya, pada saat mereka menyelesaikannya, Setiap perangkat lunak yang menggunakan lib tersebut akan memiliki cukup waktu untuk bermigrasi ke WinUI! Ironi!! 🤨🤣

Saya tidak berpikir mudah bagi banyak proyek untuk bermigrasi ke WinUI tanpa itu karena kenyataannya.

Anda telah mengatakan "Kompatibilitas adalah musuh kami!". Ya, itu juga salah satu alasan dari saran saya. Ironi!! 🤨🤣

Saya hanya akan senang untuk versi XAML WinUI dari dialog umum, bahkan jika WPF dan WinForms harus memilih untuk menggunakan versi baru.

Target WinUI 3 terdengar sangat menarik dan saya menantikannya. Saya memiliki beberapa pertanyaan tentang distribusi/penyebaran, dalam konteks aplikasi Win32 klasik menggunakan WinUI 3

1. Apakah setiap aplikasi perlu membawa perpustakaan WinUI-nya atau berbagi antar aplikasi mungkin, bahkan mungkin secara otomatis melalui mekanisme Windows
2. Apakah mungkin untuk menautkan WinUI secara statis?
3. Katakanlah saya harus mendistribusikannya kembali, seberapa besar WinUI kira-kira dalam MB?

Apakah setiap aplikasi perlu membawa perpustakaan WinUI-nya atau berbagi antar aplikasi mungkin, bahkan mungkin secara otomatis melalui mekanisme Windows

Kami berencana untuk mendistribusikan WinUI 3 melalui NuGet, yang memiliki mekanisme untuk cache dan berbagi paket secara otomatis - ada info lebih lanjut tersedia di sini:

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

Apakah mungkin untuk menautkan WinUI secara statis?

Ini bukan sesuatu yang kami rencanakan saat ini - apakah Anda memiliki skenario di mana ini akan bermanfaat?

Katakanlah saya harus mendistribusikannya kembali, seberapa besar WinUI kira-kira dalam MB?

Kami masih mencari tahu seperti apa grafik ketergantungan akhir, tetapi untuk bagian UI kemungkinan akan mirip dengan ukuran system32 dll yang relevan (10 MB).

Kami berencana untuk mendistribusikan WinUI 3 melalui NuGet, yang memiliki mekanisme untuk secara otomatis menyimpan dan berbagi paket

Saya pikir nuget hanya untuk pengembangan atau saya melewatkan sesuatu? Sejauh yang saya ketahui, paket berbasis nuget harus digunakan oleh setiap aplikasi satu per satu dan tidak dapat dibagikan. Itulah mengapa ada penginstal khusus untuk runtime inti dotnet bersama, jika tidak, tidak perlu mengingat bahwa paket inti dotnet sudah ada di nuget ...

Anda tidak perlu menginstal alat pengembangan atau SDK hanya untuk berbagi paket kerangka kerja UI. WPF dan WinForms untuk .NET Core mengalami masalah yang sama dan berinvestasi untuk membangun bundel bersama sehingga orang tidak perlu menginstal SDK pada mesin pengguna akhir , itu mungkin layak dilakukan untuk WinUI juga setelah Anda sampai di sana (bahkan mungkin dapatkan diri Anda termasuk dalam bundel WindowsDesktop)

Secara khusus sudah ada opsi build di VS untuk penerapan yang bergantung pada kerangka kerja dan WinUI harus memanfaatkan ini untuk memastikan paket dibagikan. Tentu saja mereka harus menyediakan paket yang dapat dibagikan terlebih dahulu.

Untuk aplikasi yang dikirimkan oleh Microsoft Store, konten paket rilis juga harus dibagikan secara otomatis saat penerapan.

Untuk aplikasi win32 yang digunakan melalui cara lain, ada di daftar tugas kami untuk menyelidiki opsi seperti yang Anda sebutkan 😊

Apakah mungkin untuk menautkan WinUI secara statis?

Ini bukan sesuatu yang kami rencanakan saat ini - apakah Anda memiliki skenario di mana ini akan bermanfaat?

Saya pikir saya perlu mengklarifikasi: apakah mungkin menggunakan WinUI dalam EXE yang ditautkan secara statis (yang secara statis menautkan VC-Runtime)? Saya berasumsi itu seharusnya tidak menjadi masalah karena C++/WinRT tetapi saya hanya ingin memastikan ...

Katakanlah saya harus mendistribusikannya kembali, seberapa besar WinUI kira-kira dalam MB?

Kami masih mencari tahu seperti apa grafik ketergantungan akhir, tetapi untuk bagian UI kemungkinan akan mirip dengan ukuran system32 dll yang relevan (10 MB).

Terima kasih untuk informasinya.

Transparansi yang luar biasa untuk usaha yang begitu besar, saya sangat menyukainya.

Saya pikir saya perlu mengklarifikasi: apakah mungkin menggunakan WinUI dalam EXE yang ditautkan secara statis (yang secara statis menautkan VC-Runtime)? Saya berasumsi itu seharusnya tidak menjadi masalah karena C++/WinRT tetapi saya hanya ingin memastikan

Ini seharusnya mungkin (secara teori) tetapi seperti yang dikatakan @jesbis , kami masih mengerjakan cerita tentang bagaimana aplikasi yang tidak dikemas akan masuk ke kerangka kerja bersama. Kami mungkin harus memiliki penginstal redist, seperti bagaimana .NET Core melakukannya.

Diskusi seputar Windows 7 sedikit mengganggu, karena jumlah usaha (belum lagi biaya) akan menyebabkan penundaan yang signifikan untuk WinUI 3.0. Windows 7 akan berakhir pada bulan Januari, dan kami mendorong semua pelanggan untuk meningkatkan ke Windows 10. Pelanggan saya mungkin tidak selaras dengan yang lain di sini, tetapi bahkan Windows 8.1 bukanlah platform yang menarik bagi kami.

Kamu benar. Tapi kami tidak bisa mengontrol pelanggan saya dan ada lebih dari 60% sistem win7 di Cina. Dan kami tidak dapat melepaskan pasar ini, jadi kami tidak dapat menggunakan teknologi apa pun yang tidak mendukung win7.

Datanya dari baidu, lihat https://tongji.baidu.com/data/os

Tetapi kami tidak dapat mengontrol pelanggan saya dan ada lebih dari 60% sistem adalah win7 di Cina

TBH Saya hanya akan tetap menggunakan .NET Framework 4.8 + WPF jika Anda terjebak di Win7.

Tetapi kami tidak dapat mengontrol pelanggan saya dan ada lebih dari 60% sistem adalah win7 di Cina

TBH Saya hanya akan tetap menggunakan .NET Framework 4.8 + WPF jika Anda terjebak di Win7.

Tetapi Win7 Sp1 dapat menginstal .NET Framework 4.8 dan win7 tanpa sp1 tidak dapat menginstalnya.

Persyaratan sistem .NET Framework |

Jika Anda bahkan tidak memiliki SP1 maka Anda sudah 6 tahun melewati akhir masa pakai.

Dukungan untuk Windows 7 RTM tanpa paket layanan berakhir pada 9 April 2013.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Jika Anda menginginkan dukungan Windows 7, Anda harus menggunakan teknologi yang sudah mendukung Windows 7, dan tidak mengharapkan Microsoft untuk menyelesaikan masalah ini untuk Anda.

@MarkIngramUK Bukannya Microsoft memecahkan masalah ini untuk saya, tetapi saya tidak dapat mendukung pelanggan saya yang menggunakan win7 tanpa sp1. Saya tidak dapat mengontrol pelanggan kami untuk menggunakan sistem apa pun, tetapi mereka yang menggunakan win7 tanpa sp1 akan meninggalkan aplikasi kami dan itu berarti kami kehilangan pasar ini. Tetapi pesaing saya yang tidak menggunakan teknologi baru dapat mendukung win7 tanpa sp1 dan pesaing saya akan memenangkan pasar ini.

Sedih tapi benar, terlalu banyak pelanggan yang tidak peduli teknologi apa yang kita gunakan tetapi mereka peduli aplikasi dapat berjalan dengan baik di semua perangkat mereka.

Ini adalah status quo industri saya, dan kesimpulan di atas mungkin tidak cocok untuk industri lain.

@lindexi seperti yang saya katakan, Anda tidak dapat mengharapkan teknologi baru untuk porting ke OS yang sudah 6 tahun melewati akhir masa pakainya. Jika Anda ingin menargetkan OS lama maka Anda memerlukan teknologi lama.

@lindexi Saya pikir jika pelanggan tidak ingin menggunakan teknologi yang didukung dan lebih suka sesuatu yang ketinggalan zaman, maka mereka tidak dapat berharap memiliki UI modern. Kedua persyaratan itu murni saling eksklusif ...

@MarkIngramUK Sedih. Saya pikir ketika saya bisa menggunakan teknologi baru hari ini, teknologi baru ini telah menjadi teknologi lama.

@lindexi itu benar-benar kebalikan dari apa yang terjadi. Anda tidak dapat menyebut teknologi baru sebagai "teknologi lama" hanya karena tidak di-porting ke OS kuno. Jika Anda menginginkan dukungan Win7 (tanpa SP1), gunakan WinForms atau MFC atau sesuatu.

@MartinZikmund Anda benar. Bahkan, hampir tidak ada pengguna kami yang mengerti teknologi komputer, bahkan win7 dan win10 tidak tahu. Mereka tidak peduli teknologi apa yang kita gunakan.

@jesbis Saya ingin tangan saya kotor dengan WinUI baru menggunakan C++. Saya mencoba yang terbaik dengan menggunakan UWP dan C++/Cx di masa lalu, tetapi selain Aplikasi PhotoEditor dan beberapa sampel Anda selalu berakhir dengan menggaruk-garuk kepala dan mencoba menemukan beberapa dokumentasi yang bagus misalnya untuk mengikat XAML dengan Platform :: Koleksi dan hal-hal seperti itu. Itulah salah satu alasan saya beralih kembali ke C# untuk UWP dan Qt untuk pengembangan C++ di Windows. Tolong, tunjukkan lebih banyak cinta pada C++.

Pada pelanggan saya, saya menggunakan USB Stick (PenDrive) dengan Windows 10 Media, dan cukup memutakhirkannya dari Windows 7 ke Windows 10 terbaru secara gratis. Mereka mendapat manfaat dari OS modern, dengan Antivirus, Pembaruan Windows, Edge WebBrowser dan mendukung teknologi GUI dari yang lebih lama seperti WinForms, WPF, hingga yang lebih baru termasuk UWP dan seterusnya (WinUI). Selain itu, alih-alih Shutdown, saya mengatur Windows ke Hibernate, dan mengajari pengguna untuk cukup menekan tombol daya untuk mulai bekerja dengan PC, dan menekan Tombol Daya saat selesai menggunakan PC.
Juga saya menempatkan ISO di Jaringan, untuk dengan mudah menginstal / mengupgrade mesin.

Dan mereka juga mendapat keuntungan karena Candy Crush sudah terinstal di komputer mereka!

Pendapat

Saya pikir implementasi kontrol WPF dapat digabungkan di WinUI untuk dukungan Windows versi lama. (Misalnya, Windows 7.) Tapi terlalu sulit bagi Microsoft untuk mewujudkannya karena politik kantor, lol.

Balasan

@lindexi
Saya tahu bahwa ada banyak pengguna versi Windows yang ketinggalan zaman di China saat ini. Tapi saya pikir itu perlu untuk meninggalkan pengguna Windows NT 5.x hari ini dan saya tahu itu sulit.

@MartinZikmund

Saya pikir jika pelanggan tidak ingin menggunakan teknologi yang didukung dan lebih suka sesuatu yang ketinggalan zaman, maka mereka tidak dapat berharap memiliki UI modern. Kedua persyaratan itu murni saling eksklusif ...

Baik UI modern maupun dukungan platform lama diperlukan di China jika Anda tidak ingin pekerjaan Anda dilayani oleh minoritas. Jadi salah satu teman saya, pengembang Cina, port Blink dan V8 ke Windows XP tanpa pembaruan apa pun yang diinstal , banyak pengembang menggunakannya untuk menerapkan pengalaman aplikasi modern mereka. Di Cina, persyaratan versi sistem operasi minimum sama dengan versi tanpa pembaruan apa pun yang diinstal . Misalnya, jika Anda mengetahui persyaratan versi sistem operasi aplikasi dari China adalah Windows 7, ini memberi tahu Anda dapat menggunakan aplikasi di bawah "Windows 7 RTM" atau "6.1.7000.16385 (win7_rtm.090713-1255)". Bahkan di dunia Android, banyak aplikasi yang masih mendukung Android 4.4 saat ini.

Inilah sebabnya mengapa sebagian besar aplikasi yang dibuat oleh pengembang non-Cina tidak dapat menjadi pilihan mayoritas di Cina.

PS Kami dapat menggunakan terbaru Visual Studio 2019 untuk membangun aplikasi untuk Windows XP RTM tanpa pembaruan diinstal, dengan terbaru Windows 10 SDK dan C ++

Catatan tentang diriku sendiri

Di sebagian besar waktu saya, saya menggunakan build Windows stabil terbaru. (Saya menggunakan 10.0.18362 hari ini. Saya menggunakan 19H1 dan 19H2.) Tetapi proyek Win32 saya dirancang untuk Windows Vista RTM tanpa pembaruan apa pun yang diinstal , dan proyek UWP saya dirancang untuk Windows 10, versi 1703 tanpa pembaruan apa pun yang diinstal atau yang lebih baru karena kondisional Dukungan XAML diperkenalkan di RS2. (Saya suka XAML bersyarat. Mengapa tidak ada di Windows 10 Build 14393?)

Kenji Mouri

Tolong, tolong, pertimbangkan untuk membuka segel semua kelas kontrol WinUI 3.0!

Sesuai pemahaman saya, Microsoft memutuskan untuk menyegel semua kelas kontrol UWP, karena JavaScript (yang tidak mengenal pewarisan) menyebabkan masalah saat digunakan dengan kelas yang diwarisi. Sekarang JS/HTML tidak digunakan lagi, tidak perlu lagi kerangka UI baru untuk tetap menyegel semua kelas. Un-selaing akan membuatnya lebih mudah untuk menyesuaikan kontrol UWP, seperti yang selalu memungkinkan di WPF. Ini juga akan banyak membantu ketika menulis kontrol atau panel daftar virtualisasi khusus, untuk memiliki kelas dasar virtualisasi yang tidak disegel untuk diwarisi. Baik C#, maupun C++/CX atau C++/WinRT tidak memiliki masalah dengan pewarisan. Hanya kegagalan yang disebut JS/HTML yang memaksa kami melakukan ini.

Jadi tolong hapus batasan yang tidak perlu ini saat membuat WinUI 3.0.

@gisfromscratch terima kasih atas umpan baliknya! Kami pasti ingin mendukung pengembangan C++ (khususnya dengan C++/WinRT).

Apa yang akan membuatnya lebih mudah untuk menggunakan C++? Sudahkah Anda mencoba C++/WinRT alih-alih CX?

Akankah lebih banyak contoh aplikasi membantu?

Anda menyebutkan bahwa sulit untuk menemukan dokumentasi tentang penjilidan: apakah ada fitur khusus lain yang memerlukan dokumentasi yang lebih baik?

Tolong, tolong, pertimbangkan untuk membuka segel semua kelas kontrol WinUI 3.0!

@lukasf ini adalah sesuatu yang kemungkinan besar akan kami lakukan Ada beberapa diskusi terkait yang sedang berlangsung di #780

@jesbis Saya harus mengotori tangan saya menggunakan C++/WinRT lebih banyak lagi. Saya baru saja mengikuti contoh aplikasi Photo Editor C++/WinRT . Tetapi ketika Anda membaca tautan yang disediakan seperti Pengikatan data secara mendalam, Anda berakhir di banyak cuplikan C# dan hanya beberapa catatan tambahan seperti "Untuk C++/WinRT, setiap kelas runtime yang Anda nyatakan dalam aplikasi Anda yang berasal dari kelas dasar adalah dikenal sebagai kelas yang dapat dikomposisi. Dan ada batasan di sekitar kelas yang dapat dikomposisi ...". Halaman ini menargetkan 95% C# dan hanya 5% C++.

@gisfromscratch terima kasih! Kami akan mengingatnya saat kami berupaya memperbarui dokumen untuk WinUI 3.

Jika membantu, halaman penyatuan data yang Anda sebutkan juga menautkan ke beberapa halaman terpisah khususnya tentang penyatuan data dengan C++/WinRT, misalnya:

kontrol XAML;

kontrol item XAML;

Ada sejumlah topik khusus C++/WinRT lainnya di bagian itu juga.

Terima kasih atas pekerjaan hebat Anda! Sangat senang melihat Pulau Xaml dihapus dari WinUi 3.0.
Btw: Saya hanya ingin tahu apakah implementasi proyeksi bahasa tingkat rendah di WinUi 3.0 akan berbeda dari komponen WinRT. Implementasi proyeksi bahasa komponen WinRT tampaknya memiliki kinerja yang sangat besar dalam proyek .NET UWP baik dalam waktu kompilasi maupun waktu berjalan. Karena WinUi 3.0 dipisahkan sepenuhnya dari UWP, saya berharap ada beberapa peningkatan dalam implementasi interop bahasa.

@zenjia XAML Islands tidak dihapus dari WinUI 3. WinUI 3 akan berisi API yang memungkinkan aplikasi WPF/WinForms/MFC menghosting kontrol WinUI 3.

Saya sudah mencoba untuk mengikuti kemajuan di WinUI. Saya sudah mencoba menulis aplikasi UWP di masa lalu dengan C # tetapi ternyata itu adalah perjuangan yang berat. Tapi saya ingin mencoba lagi setelah winui 3.0.

Saya memiliki pertanyaan tentang peta jalan winui. Berikut adalah empat. Maaf jika mereka telah dibahas di tempat lain. Saya belum menemukan jawabannya, meskipun banyak pencarian ... beri tahu saya jika ada forum yang lebih baik untuk mengajukan pertanyaan semacam ini.

• Apakah pembungkus .net untuk kontrol asli juga akan bersumber terbuka? Tidak jelas bahwa ini adalah repro github yang bertanggung jawab untuk sisi .Net dari winui, mengingat satu-satunya kode c# yang tampaknya saya temukan adalah untuk pengujian otomatis. Saya mencari hal-hal seperti Microsoft.UI.Xaml.UIElement tetapi tidak dapat menemukan kode itu di mana pun.

• Ketika kita sampai pada rilis winui 3.0, apakah appmodel UWP dan appmodel win32 akan menjalankan runtime .Net Core yang sama? Saya tidak pernah tahu versi .Net core apa yang digunakan oleh aplikasi UWP. Saya membayangkan bahwa itu adalah sesuatu yang dibangun ke dalam windows itu sendiri, dan Windows 10 SDK memungkinkan VS 2019 untuk menargetkan versi yang benar dari inti .Net yang tersedia di UWP.

• Sebuah pertanyaan tentang pulau Xaml. Apakah ada kemungkinan WPF dan UWP dapat berbagi wilayah udara yang sama? Saya tidak berharap harus berurusan dengan masalah wilayah udara seperti yang kami lakukan antara winforms dan WPF. Mengingat bahwa WPF dan UWP keduanya dibangun di atas direct-X, akan luar biasa jika mereka dapat berbagi piksel satu sama lain. Misalnya, jika saya memiliki menu di belakang panggung pada pita (dalam WPF) yang perlu melapisi pulau xaml UWP, akan sangat bagus jika itu bisa terjadi dengan mulus. Sepertinya saya tidak harus melompat melalui banyak rintangan untuk hal seperti itu. ... Saya ingat bahwa pada hari-hari awal WPF, mereka mencoba memecahkan masalah wilayah udara untuk aplikasi klien yang ingin menggunakan kontrol winforms "WebBrowser". Mereka melakukan uji coba fitur browser web yang disebut "WebBrowser.CompositionMode" dan itu seharusnya memungkinkan WebBrowser bermain bagus dengan WPF. ... Tapi saya pikir strategi itu akhirnya ditinggalkan. Mungkin interoperabilitas antara UWP dan WPF bisa begitu mulus sehingga mereka bahkan dapat berbagi piksel satu sama lain (tidak seperti winforms dan WPF). Salah satu keuntungan potensial dari ini adalah memungkinkan WPF untuk meningkatkan fungsionalitas kontrol UWP. Misalnya WPF dapat melapisi pulau xaml dengan visual tambahan dengan cara yang analog dengan lapisan penghias. Ini bisa menjadi berguna dalam keadaan darurat.

• Adakah kemungkinan aplikasi WPF dengan pulau xaml (katakanlah 50% WPF dan 50% WINUI) dapat dikompilasi secara asli ke ARM64 suatu hari nanti? Penargetan ARM dimungkinkan dengan aplikasi yang 100% UWP, dan alangkah baiknya jika dependensi WPF tidak memaksa kita untuk meninggalkan penargetan ARM64 asli kita. (Alternatifnya adalah menjalankan aplikasi dalam emulasi x86 - tetapi itu lebih lambat dan membatasi memori yang tersedia yang dapat digunakan).

Semoga semua pertanyaan ini relevan dengan peta jalan winui. Saran apa pun akan dihargai.

Apakah pembungkus .net untuk kontrol asli juga akan bersumber terbuka? Tidak jelas bahwa ini adalah repro github yang bertanggung jawab untuk sisi .Net dari winui, mengingat satu-satunya kode c# yang tampaknya saya temukan adalah untuk pengujian otomatis. Saya mencari hal-hal seperti Microsoft.UI.Xaml.UIElement tetapi tidak dapat menemukan kode itu di mana pun.

UIElement tidak ada di WinUI 2 jadi saat ini tidak ada di repo. Itu akan ada di WinUI 3 yang belum dirilis atau open source, tapi kami sedang mengerjakannya!

Anda dapat melihat contoh dalam repo kontrol asli lainnya yang diekspos ke .NET melalui proyeksi WinRT, misalnya kontrol WinUI 2.2 yang didokumentasikan di sini . Mereka sebagian besar tidak memerlukan file pembungkus per bahasa yang sudah ada sebelumnya, itulah sebabnya Anda tidak menemukan file .cs di repo.

@marb2000 dapat memberikan komentar terbaik tentang pertanyaan pulau/desktop.

T: _Apakah WinUI 3 UWP dan Desktop menggunakan runtime .NET yang sama?_
A: Ya, ini rencananya. UWP dan Desktop akan menggunakan .NET Core 3. Pustaka WinRT yang dikelola akan menggunakan .NET Core 3 alih-alih .NET Native.

Q: _Apakah WPF dan UWP akan berbagi wilayah udara yang sama?_
A: Meskipun WPF dan WinUI (dan XAML UWP) tampak serupa, sebenarnya tidak. WPF menggunakan DirectX9, dan WinUI/XAML UWP menggunakan Windows.UI.Composition untuk kebutuhan komposisi, rendering, dan animasi XAML (selain DirectX11 versi modern). Sayangnya, ini menyebabkan interop sangat rumit. Proposal Anda tentang perhiasan WPF menarik. Secara teori, pengadopsi dapat membuat popup untuk menempatkan konten WinUI/XAML di atas konten WPF. Atau dapat menginformasikan ke pohon visual WPF bahwa tata letak ulang diperlukan, tetapi semuanya didasarkan pada HWnds.
@dbeavon Ini adalah proposal yang bagus, dapatkah Anda membuat permintaan fitur untuk ini?

T: _Akankah aplikasi WPF dengan Xaml Islands dikompilasi ke ARM64?_
A: Jika .NET Core 3 untuk Windows mendukung ARM64 pasti. Hari ini mendukung ARM32 di Windows. Namun, di Linux mendukung ARM64. Saya pikir itu ada di peta jalan .NET Core untuk mendukung ARM64 di Windows juga. Meski AFAIN, belum ada tanggalnya. @richlander , ada kabar?

@marb2000

T: Apakah WPF dan UWP akan berbagi wilayah udara yang sama?

Bisakah UWP menggunakan Windows.UI.Composition untuk membuat layer yang bisa mendapatkan render dari bitmap DirectX? Dan kemudian WPF membuat jendela ke lapisan ini seperti win2d. Mungkin bisa berbagi wilayah udara yang sama. Tetapi sulit untuk membuat WPF untuk dirender ke sebuah layer.

@lindexi saya kira itu bisa menjadi surga :D

Bisakah UWP menggunakan Windows.UI.Composition untuk membuat layer yang bisa mendapatkan render dari bitmap DirectX?

UWP Xaml memiliki sejumlah cara untuk merender bitmap DirectX atau menukar rantai di Xaml dan menggabungkannya dengan Windows.UI.Composition sehingga mereka berbagi wilayah udara yang sama, termasuk SurfaceImageSource , VirtualSurfaceImageSource dan SwapChainPanel - info lebih lanjut tersedia di sini:

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

Anda juga dapat menyisipkan visual Windows.UI.Composition ke dalam struktur UI Xaml UWP dan menggambar konten DirectX ke dalamnya, misalnya menggunakan ICompositorInterop , ICompositionDrawingSurfaceInterop dan ICompositionGraphicsDeviceInterop seperti diuraikan di sini:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

Pendekatan tersebut harus bekerja sama dengan WinUI.

Aplikasi desktop UWP akan dapat mereferensikan WPF/WinForm DLL dan membuka jendela WPF/WinFrom? Ini akan memungkinkan saya untuk bermigrasi secara bertahap.

@marb2000 -- .NET Core untuk Windows ARM64 ada di peta jalan kami. Saya sedang mengerjakan rencana untuk itu sekarang.

Dengan WinUI 3.0, apakah mungkin untuk mengkompilasi win2d di atasnya?
(dengan demikian, memisahkannya dari UWP)
Jika demikian, itu akan sangat luar biasa!

Kami masih mengerjakan detail tentang integrasi DirectX tetapi mudah-mudahan dimungkinkan untuk memperbarui Win2D untuk menggunakan kelas dasar WinUI alih-alih kelas dasar UWP Xaml.

menyilangkan jari :D

maaf jika ini di luar topik: laporan bug di UWP - apakah saya menambahkan masalah di https://github.com/microsoft/microsoft-ui-xaml/ atau di tempat lain?

maaf jika ini di luar topik: laporan bug di UWP - apakah saya menambahkan masalah di https://github.com/microsoft/microsoft-ui-xaml/ atau di tempat lain?

@jtorjo pertanyaan bagus! Repo ini adalah tempat terbaik untuk mengajukan masalah apa pun yang terkait dengan:

• API kerangka kerja UI UWP (mis. Windows.UI.Xaml)
• Desain yang lancar
• WinUI

Secara umum harus ada tautan "Kirim umpan balik tentang produk ini" di bagian bawah sebagian besar halaman dokumentasi di docs.microsoft.com yang akan memberi tahu Anda cara terbaik untuk memberikan umpan balik tentang fitur atau API tertentu.

Untuk sebagian besar aspek UWP selain di atas, itu akan mengajukan bug di bawah kategori Platform Pengembang di Hub Umpan Balik yang memiliki sejumlah subkategori yang relevan.

Akankah WinUI 3 menyertakan kontrol UWP SemanticZoom? Saya pikir itu kontrol paling keren dari mereka semua.

@jesbis Terima kasih! Baru saja memposting diskusi tentang System.IO

Bahkan Microsoft tidak menjatuhkan dukungan Windows 7 untuk Office, mengapa WinUI 3 melakukannya? Maksud saya, hampir semua perangkat lunak serius memiliki dukungan Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Jika WinUI tidak mendukung Windows 7...

Bahkan Microsoft tidak menjatuhkan dukungan Windows 7 untuk Office, mengapa WinUI 3 melakukannya? Maksud saya, hampir semua perangkat lunak serius memiliki dukungan Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Jika WinUI tidak mendukung Windows 7...

Office mungkin akan segera menghentikan dukungan, karena dukungan Microsoft untuk Windows 7 akan segera berakhir. Tapi itu dibangun di atas basis kode yang sudah mendukung Windows 7.

WinUI dibangun di atas Windows 10, dan karenanya perlu di-porting kembali ke Windows 7. Upaya untuk melakukan itu tidak masuk akal dengan OS yang memasuki End Of Life, dan orang-orang harus meningkatkan ke Windows 10.

T: Akankah WinUI 3 UWP dan Desktop menggunakan runtime .NET yang sama?
A: Ya, ini rencananya. UWP dan Desktop akan menggunakan .NET Core 3. Pustaka WinRT yang dikelola akan menggunakan .NET Core 3 alih-alih .NET Native.
T: Apakah WPF dan UWP akan berbagi wilayah udara yang sama?
J: Meskipun WPF dan WinUI (dan XAML UWP) tampak serupa, sebenarnya tidak. WPF menggunakan DirectX9, dan WinUI/XAML UWP menggunakan Windows.UI.Composition untuk kebutuhan komposisi, rendering, dan animasi XAML (selain DirectX11 versi modern). Sayangnya, ini menyebabkan interop sangat rumit. Proposal Anda tentang perhiasan WPF menarik. Secara teori, pengadopsi dapat membuat popup untuk menempatkan konten WinUI/XAML di atas konten WPF. Atau dapat menginformasikan ke pohon visual WPF bahwa tata letak ulang diperlukan, tetapi semuanya didasarkan pada HWnds.
@dbeavon Ini adalah proposal yang bagus, dapatkah Anda membuat permintaan fitur untuk ini?
T: Apakah aplikasi WPF dengan Xaml Islands akan dikompilasi ke ARM64?
A: Jika .NET Core 3 untuk Windows mendukung ARM64 pasti. Hari ini mendukung ARM32 di Windows. Namun, di Linux mendukung ARM64. Saya pikir itu ada di peta jalan .NET Core untuk mendukung ARM64 di Windows juga. Meski AFAIN, belum ada tanggalnya. @richlander , ada kabar?

Jadi, apakah kita menyingkirkan kotak pasir UWP? Yang pada gilirannya menyiratkan UWP dalam bentuknya saat ini juga akan hilang, dan dengan itu kotak pasir App Store yang dilindungi seperti yang kita kenal?

Jadi, apakah kita menyingkirkan kotak pasir UWP? Yang pada gilirannya menyiratkan UWP dalam bentuknya saat ini juga akan hilang, dan dengan itu kotak pasir App Store yang dilindungi seperti yang kita kenal?

menyingkirkan kotak pasir UWP akan sangat luar biasa!

Itu jelas tidak berarti bahwa UWP akan hilang. Universal Windows Platform adalah satu-satunya cara untuk secara native membangun spektrum penuh perangkat Windows (PC, Xbox, HoloLens, dll.) dan merupakan tempat Windows memfokuskan investasi platform aslinya. RE: khususnya sandboxing: isolasi wadah aplikasi terus memberikan banyak manfaat penting bagi aplikasi dan pengguna aplikasi UWP dan desktop.

Perubahan utamanya adalah:

• kami sedang mengembangkan cakupan platform UX (yaitu WinUI) sehingga dapat juga digunakan dengan model aplikasi desktop (win32)
• kami memisahkan WinUI dari Windows sehingga kami dapat memperbaruinya lebih sering, membuat fitur baru yang kompatibel ke belakang, dan lebih mudah membukanya

Itu berarti untuk aplikasi baru Anda akan dapat memilih antara UWP dan model aplikasi desktop tergantung pada apa yang masuk akal untuk aplikasi Anda, dan jika Anda memiliki aplikasi desktop yang sudah ada (misalnya WPF, WinForms, MFC) maka Anda dapat memperbaruinya secara bertahap dengan modern Fungsionalitas WinUI menggunakan Xaml Islands.

Jadi, apakah kita menyingkirkan kotak pasir UWP? Yang pada gilirannya menyiratkan UWP dalam bentuknya saat ini juga akan hilang, dan dengan itu kotak pasir App Store yang dilindungi seperti yang kita kenal?

UWP akan menjadi salah satu opsi untuk membangun aplikasi WinUI 3.0. Menggunakan UWP akan memungkinkan aplikasi Anda berjalan di Xbox, Hololens, dll.

Tetapi Anda juga dapat membangun aplikasi Win32 dengan WinUI 3.0 dan mengakses API UWP - tetapi tempat aplikasi Anda dapat berjalan akan lebih terbatas.

@mdtauk @jesbis Saya sepenuhnya mendukung UWP, tetapi saat ini:

1. waktu kompilasi sangat lambat! (cukup banyak, 6 kali lebih lambat dari WPF - saya menggunakan versi target build 1809 - build 17783)
2. Saya tahu API enumerasi file StorageFolder bukan bagian dari UWP, tapi itu sangat lambat. Kotak pasir UWP (setidaknya di Desktop Windows) lebih menyakitkan daripada membantu.
3. Tentu, pemrograman async menyenangkan, tetapi di UWP, ketika pengecualian terjadi, itu entah bagaimana dimakan oleh kode UWP, dan kemudian pecah di debugger, dengan semua konteks tumpukan hilang. Terkadang, saya memiliki konteks tumpukan di dalam pengecualian yang dilemparkan itu sendiri, tetapi tidak selalu.
4. Membuat profil kode UWP hampir tidak mungkin. Acara dotTrace langsung rusak saat mencoba melakukannya.

(Butuh waktu lebih dari sebulan untuk mem-porting kode saya dari WPF ke UWP, karena saya sangat membutuhkan win2d, jadi tidak ada cara bagi saya untuk menghindari UWP.)

@mdtauk @jesbis Saya sepenuhnya mendukung UWP, tetapi saat ini:

1. waktu kompilasi sangat lambat! (cukup banyak, 6 kali lebih lambat dari WPF - saya menggunakan versi target build 1809 - build 17783)
2. Saya tahu API enumerasi file StorageFolder bukan bagian dari UWP, tapi itu sangat lambat. Kotak pasir UWP (setidaknya di Desktop Windows) lebih menyakitkan daripada membantu.
3. Tentu, pemrograman async menyenangkan, tetapi di UWP, ketika pengecualian terjadi, itu entah bagaimana dimakan oleh kode UWP, dan kemudian pecah di debugger, dengan semua konteks tumpukan hilang. Terkadang, saya memiliki konteks tumpukan di dalam pengecualian yang dilemparkan itu sendiri, tetapi tidak selalu.
4. Membuat profil kode UWP hampir tidak mungkin. Acara dotTrace langsung rusak saat mencoba melakukannya.

(Butuh waktu lebih dari sebulan untuk mem-porting kode saya dari WPF ke UWP, karena saya sangat membutuhkan win2d, jadi tidak ada cara bagi saya untuk menghindari UWP.)

Ini akan berguna untuk diposting di utas ini #1517 dan mudah-mudahan Anda dapat memasukkan nama seseorang dari tim SDK

@jtorjo

waktu kompilasi sangat lambat! (cukup banyak, 6 kali lebih lambat dari WPF

Apakah Anda menggunakan C++/WinRT? Jika demikian, apakah Anda menggunakan header yang telah dikompilasi sebelumnya?

@mdtauk baru saja memposting di sana

@MarkIngramUK Ini kode c#

Penutupan - harap arahkan peta jalan dan umpan balik alfa ke: #1531

Saat ini tidak ada ide apakah ini mungkin - harapannya adalah ketika bit WinUI dihapus dari OS, bit tersebut dimasukkan ke dalam proyek open source dengan cara tertentu, yang akan memungkinkan platform lain untuk menyediakan semacam komponen kompatibilitas. Pikirkan Xamarin, Uno, atau .Net Core dengan perender khusus.

Apakah ini sesuatu yang benar-benar ada di peta jalan atau hanya asumsi?

@mdtauk , @zezba9000 secara teori semuanya mungkin, dan kami memiliki banyak keahlian abstraksi platform dalam tim. Seperti apa pun, itu hanya tergantung pada biaya, jadwal, dan manfaat yang diharapkan 😊

Mungkin saja mengabstraksikannya dengan cara yang memungkinkan pihak ketiga membuatnya bekerja di Android atau iOS akan sangat besar. Saya yakin masyarakat bisa melakukannya. Saya pasti akan berkontribusi untuk itu.

@andreinitescu Maaf untuk kata-kata kasar dan keluhan tetapi hanya pikiran saya dari apa yang saya mengerti: Sementara saya akan menggunakan WinUI 3 untuk menggantikan WPF untuk Windows / Win32 saja... Karena WinUI di Windows menggunakan API rendering Windows saja dan bukan agnostik satu, WinUI tampaknya mengandalkan pihak ke-3 untuk mengimplementasikan kembali / fragmen (ugg) WinUI pada platform lain (seperti proj UNO, yang keren tapi seperti Mono ke .NET adalah fragmentasi yang tidak perlu dan membuang waktu jika semuanya hanya dirancang dengan benar untuk memulai). Alih-alih menggunakan yang portabel seperti Skia, atau membuat yang MS. Juga tidak mengerti kebutuhan untuk mendukung 1% orang yang tidak akan menggunakan C# dengan WinUI, menjadikan C# target kelas kedua dalam arti tertentu dan yang lebih penting membuat waktu dev memakan waktu lebih lama. Sama seperti Android yang menggunakan Java + post-AOT untuk banyak aplikasi inti, Windows juga harus menggunakan C# + pre-AOT. Karena menghemat waktu. 70% bug yang menggunakan C++ menggunakan ptrs yang tidak dialokasikan.

Kurangnya komunikasi antar grup dalam sebuah perusahaan untuk kasus penggunaan jangka panjang ketika itu akan menjadi semakin menjadi masalah ketika mereka merilis rasa OS Android mereka untuk platform seluler (yang saya rencanakan untuk digunakan) dan lebih banyak orang ingin menargetkannya dengan alat MS ... merasa itu hanya akan menjadi situasi seperti WinPhone7 lagi dengan cara. Windows sebagai istilah seharusnya tidak lagi terikat dengan kernel WinNT. Sistem eko ​​lebih dari satu platform atau satu kerangka kerja perusahaan yang dibangun di atasnya.

Untuk MS yang buruk tidak dapat/tidak akan melakukan apa yang Apple lakukan hampir 20 tahun yang lalu dengan perpindahan dari OS9 ke OSX. Dalam hal itu Anda merobek bantuan pita dengan pindah ke kernel UNIX/LINUX TETAPI memiliki emulator/simulator yang dibangun ke dalam OS untuk perangkat lunak lawas selama 5-10 tahun ke depan sementara orang memigrasikan perangkat lunak dan alat dev untuk dijalankan secara asli. (Pikirkan apa yang Anda inginkan dari ini tapi saya bisa bermimpi)