Microsoft-ui-xaml: Panggilan Komunitas WinUI (19 Februari 2020)

Saya punya pertanyaan tentang pengembangan Windows 10X. Untuk mengembangkannya saya membutuhkan emulator, kapan akan ada dukungan untuk prosesor AMD (virtualisasi bersarang)? Bisakah kita mengandalkan versi Windows 10 2003?

Lebih terkait dengan WinUI, berdasarkan #1958, bagaimana masa depan Live Tiles?

Dukungan AMD Ryzen mencegah saya menjalankan Emulator, jadi kabar apa pun tentang kapan itu akan diperbaiki akan bagus untuk didengar.

@jp-weber @mdtauk

Ini adalah kata-kata resmi (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):

Prosesor AMD tidak didukung saat ini. Virtualisasi bersarang diperlukan untuk menjalankan Windows 10X di emulator dan Windows belum mendukung ini pada prosesor AMD. Pantau terus!

Jika Anda ingin info lebih lanjut, Anda mungkin harus menghubungi [email protected]. Saya ragu WinUI adalah tim yang tepat untuk mengajukan pertanyaan spesifik Emulator.

Terima kasih @Felix-Dev - itu benar, dokumen adalah tempat terbaik untuk mendapatkan status terbaru pada emulator 10X, dan alamat email itu adalah kontak terbaik untuk pertanyaan 10X lainnya yang tidak spesifik untuk WinUI.

Cukup adil, harus menunggu sampai Microsoft siap membicarakannya.

Melihat Windows 10X, aplikasi Win32 berjalan dalam wadah VEIL. Bagaimana dengan aplikasi WinUI 3.0 non UWP?

Akankah mereka tampak berjalan seperti yang dilakukan aplikasi UWP asli pada 10X?

@mdtauk Karena aplikasi WinUI Desktop bukan aplikasi UWP asli, saya rasa mereka tidak akan berjalan di wadah UWP. Saya percaya mereka akan berjalan dalam wadah Win32 yang disebutkan karena mereka akan memiliki (semua) kemampuan aplikasi Win32.

Saya juga tertarik untuk mengetahui apa rencananya untuk isolasi aplikasi WinUI ke depan. Dari perspektif perusahaan, kami memerlukan isolasi/kotak pasir dan kontrol kemampuan (bukan keikutsertaan pengguna). Jadi, menempatkan ini sebagai topik untuk Miguel..

@mdtauk Karena aplikasi WinUI Desktop bukan aplikasi UWP asli, saya rasa mereka tidak akan berjalan di wadah UWP. Saya percaya mereka akan berjalan dalam wadah Win32 yang disebutkan karena mereka akan memiliki (semua) kemampuan aplikasi Win32.

Ini sedikit mengecewakan. Aplikasi Win32 tampaknya menunjukkan perilaku windowing yang berbeda, dan menggelapkan layar saat berada di latar depan. Jadi beralih juga berperilaku berbeda.

Menggunakan Xaml UI, diharapkan aplikasi Desktop WinUI akan menjadi skenario terbaik dari kedua dunia setidaknya di permukaan bagi pengguna

@mdtauk Karena gambar emulator 10X saat ini dirilis kepada kami masih sangat awal, saya cukup yakin masalah/perilaku yang Anda perhatikan (saya juga melakukannya dalam pengujian saya) akan ditangani/diubah hingga rilis (yaitu saya juga memiliki aplikasi Win32 yang baru saja gagal memuat sekarang).

Yang mengatakan, saya akan dengan senang hati dikoreksi pada wadah aplikasi WinUI Desktop pada 10X. Pemikiran saya saat ini didasarkan pada apa yang telah kami ketahui tentang Desktop WinUI sejauh ini (model aplikasi Win32), presentasi 10X How Windows 10X runs UWP and Win32 apps dan aplikasi pengujian jembatan desktop. Sayangnya, aplikasi uji Pulau XAML saya gagal dimuat di emulator saat ini (terjebak pada tahap App Launch Initialized ) jadi saya tidak dapat memeriksa wadah mana yang akan mereka gunakan. Saya akan terkejut jika itu bukan wadah Win32 karena mereka masih aplikasi Win32. Semua itu membuat saya percaya bahwa aplikasi Desktop WinUI akan berjalan di wadah Win32 pada 10X.

Ini tentu pertanyaan yang bagus untuk ditanyakan kepada tim!

@Felix-Dev menurut video yang sama yang Anda sebutkan (Bagaimana Windows 10X menjalankan aplikasi UWP dan Win32) pada menit 20:18 mengatakan bahwa aplikasi hybrid (Win32/UWP) tidak didukung (belum?) menggunakan XAML Island adalah aplikasi hybrid.

Q1) Kapan SwapchainPanel akan tersedia di WinUI? Ini sangat penting untuk apa yang saya dan banyak orang lain lakukan.

Q2) Karena SharpDX tidak lagi didukung oleh pembuatnya, apakah Microsoft akan meningkatkan dan menyediakan kompatibilitas antara permukaan rendering perangkat keras SharpDX dan WinUI? Apakah MS bahkan melihat cerita untuk rendering perangkat keras dengan C# tanpa SharpDX? Dan saya tidak peduli dengan Unity, maksud saya untuk pengembangan grafis bentuk bebas tanpa batas, untuk membuat alat grafis, mesin, dan game non-Unity kami sendiri di C#. Dan saya juga tidak bermaksud Win2d, saya memerlukan kemampuan rendering perangkat keras penuh (DirectX).

Q3) Aplikasi tidak memiliki kemampuan untuk mematikan popup TaskBar dan TitleBar saat mouse dipindahkan ke tepi atas dan bawah layar. Ini adalah pemecah kesepakatan untuk banyak game (dan mungkin beberapa aplikasi) yang memanfaatkan tepi layar di UI mereka sendiri untuk hal-hal seperti kamera pan atau popup. Kapan ini akan diperbaiki (ini mungkin masalah Windows, tetapi perlu didorong oleh API, jadi ini relevan dengan WinUI).

Q4) Bisakah kita meminta WinUI untuk menyertakan model aplikasi CoreWindow (IFrameworkView) ketika kita ingin melewati Xaml dan merender langsung ke Swapchain yang terikat jendela.

Mungkin terdengar sedikit aneh, meminta agar WinUI menyediakan permukaan non-Xaml. Tapi saya pikir CoreWindow milik XamlWindow (disebut Window di UWP) di perpustakaan yang sama, juga dipisahkan dari UWP untuk membuatnya tersedia di .net 5. Dengan asumsi .net 5 akan dapat menargetkan non-uwp dan juga uwp. Saat ini tidak ada model aplikasi C++ modern di luar UWP - pengembang game harus menggunakan kode c lama (Win32) untuk menulis lapisan aplikasi untuk game atau aplikasi grafis. Juga tidak ada model aplikasi desktop modern di .net core. Solusi UWP untuk CoreWindow efektif dan nyaman digunakan. Itu hanya perlu ada di luar UWP (untuk C++/non-uwp dan .net 5). Manfaat lain dari menarik CoreWindow dari UWP adalah ia menyediakan cara untuk langsung mem-port kode dari UWP ke .net 5 (dan C++ jika pernah mendapatkan model aplikasi modern non-uwp).

Pengembang game tidak dapat menggunakan UWP hingga perilaku windowing diubah dan cerita distribusi diselesaikan. Sudah lama sekali sepertinya Microsoft bahkan tidak mengerti masalahnya. Jadi kita harus mencoba menarik API ini di luar UWP. Jika UWP diperbaiki, kami tidak perlu melakukannya.

Dan komentar lebih lanjut dari edisi 1215

Jika Anda mengganti Win32 Window dengan CoreWindow untuk skenario non-contained / non-Xaml, dan juga menyediakan CoreWindow ke .Net 5 Non-UWP maka kita dapat memiliki model aplikasi/jendela terpadu di seluruh Windows untuk pekerjaan non-Xaml. Itu lebih masuk akal daripada memegang Win32 SELAMANYA atau membuat model Aplikasi baru.

Mengapa kita harus menulis ulang lapisan aplikasi hanya karena kita ingin beralih antara eksekusi yang terkandung dan yang tidak (misalnya antara UWP dan Win32) - itu adalah masalah umum yang dihadapi pengembang game saat ini, mereka tidak dapat berkomitmen ke UWP karena mereka membutuhkan kebebasan distribusi Win32. Jadi mereka terpaksa menggunakan model aplikasi HWnd atau .Net Framework. Jika model aplikasi/jendela UWP tersedia untuk aplikasi non-uwp, tidak masalah, kami dapat menulis kode yang sama untuk lapisan aplikasi dan mengkompilasi untuk MS Store dan toko lain dari basis kode yang sama.

@leoniDEV Banyak dari ini masih spekulasi apa sebenarnya yang dimaksud dengan "aplikasi hybrid". Lihat utas Twitter ini misalnya di mana dikatakan bahwa aplikasi Pulau XAML tidak termasuk dalam kategori itu (Matteo Pagani bekerja di Microsoft sebagai Windows AppConsult Engineer ). Seorang karyawan MS di Komunitas UWP mengatakan bahwa dukungan untuk aplikasi UWP yang menjalankan proses kepercayaan penuh Win32 tidak akan didukung satu hari 1 tetapi direncanakan akan ditambahkan nanti.

@Gavin-Williams Akan ada dua rasa WinUI: WinUI UWP dan WinUI Desktop. Dengan WinUI UWP Anda akan dapat membuat aplikasi UWP lengkap yang akan berjalan di wadah UWP di Windows 10X. Lalu ada Desktop WinUI yang akan memungkinkan aplikasi Win32 memiliki akses penuh ke API UI UWP (XAML, komposisi, input,... - tidak termasuk beberapa API seperti CoreWindow ) juga. Jenis aplikasi ini tidak harus berurusan dengan kotak pasir UWP atau batasan desain UWP lainnya. Karena mereka bukan aplikasi UWP, bagaimanapun, aplikasi Desktop WinUI Anda tidak akan dapat menargetkan berbagai kategori perangkat Windows 10 yang dapat dilakukan oleh aplikasi UWP.
Lihat gambar di bawah yang diambil dari peta jalan WinUI untuk gambaran umum yang baik:

WinUI telah ditulis dalam C++ dari bawah ke atas sehingga dapat digunakan dalam konteks aplikasi yang tidak dikelola.

Seperti yang saya tekankan di atas, tulisan saya I believe they will run in the mentioned Win32 container murni berdasarkan pemahaman saya saat ini tentang WinUI Desktop, aplikasi pengujian jembatan video dan desktop 10X yang saya jalankan pada 10X. Saya tidak memiliki pengetahuan orang dalam. Tim WinUI pasti akan memberi tahu kami apa rencananya dengan aplikasi Desktop WinUI dan wadah 10X yang digunakan dan saya senang dikoreksi di sini dan diberi tahu bahwa ya, aplikasi Desktop WinUI akan berjalan di wadah UWP pada 10X.

Saya ingin mendengar lebih banyak tentang pemikiran tentang kemungkinan dapat menggunakan bahasa pemrograman lain, seperti Java, Python, JavaScript dll, ketika membangun aplikasi menggunakan WinUI / Microsoft UI.

Saya tahu ada proyek bernama Xlang (cross-lang) - yang pada dasarnya tampak seperti .NET yang seharusnya, COM yang lebih baik.

Bagaimana hubungannya dengan WinUI?

xlang pada dasarnya adalah versi open source lintas platform dari Windows Runtime (WinRT), meskipun tidak sepenuhnya kompatibel. Tujuan WinRT adalah apa yang Anda katakan, interoperabilitas antar bahasa, dan didasarkan pada COM. API WinUI dibangun di atas WinRT yang mendukung C++ dan C#. Ada bahasa lain dengan berbagai tingkat dukungan untuk WinRT, termasuk Python , Rust (ini adalah salah satu yang saya kerjakan secara pribadi) dan JavaScript , tetapi sejauh yang saya tahu tidak satupun dari mereka (belum) mendukung WinUI - mendukung WinUI sangat sulit karena Komposisi dan API XAML-nya sangat bergantung pada fitur sistem tipe yang disebut tipe yang dapat dikomposisi (pada dasarnya merupakan bentuk pewarisan implementasi) yang tidak digunakan oleh API WinRT dan UWP lainnya dan yang mungkin sulit dipetakan ke sistem tipe bahasa lain.
Kenny Kerr, pencipta C++/WinRT, sedang mengerjakan proyeksi Rust WinRT baru sekarang.

Saya sebenarnya telah banyak berpikir baru-baru ini tentang bagaimana Rust dapat mendukung tipe yang dapat dikomposisi terbaik (dan dengan demikian WinUI). Itu pasti mungkin tetapi saya belum yakin seberapa alami saya bisa merasakannya untuk pengembang. Pada dasarnya, bahasa apa pun harus dapat mendukung WinRT jika seseorang bekerja untuk membuat proyeksi, tetapi tergantung pada desain bahasanya, terkadang sulit untuk memetakan konstruksi sistem tipe WinRT ke sistem tipe bahasa dengan cara tertentu. yang terasa alami.

xlang tampak mati bagi saya. C++/WinRT tidak pernah benar-benar selesai - itu dibiarkan dengan bug dan cerita penggunaan bola yang sangat aneh, membuatnya tidak diinginkan untuk pengembang rata-rata. Saya berjuang selama berjam-jam agar C++/WinRT berfungsi, dan gagal melakukan apa yang saya lakukan dalam 30 menit dengan C++/CX. Dan C++/CX lebih mudah digunakan. Jika Microsoft ingin alat lintas bahasa ini dapat digunakan oleh Joe Rata-rata, mereka perlu menempatkan tim orang ke dalam masalah dan tidak menyerahkannya kepada Kenny Kerr untuk melakukan semua pekerjaan sendiri. Dia punya beberapa ide bagus. Tetapi alat-alat ini membutuhkan daya tarik yang luas, dan saya pikir dia membutuhkan bantuan untuk membawa produk ini menjadi dewasa dan menjadi semua yang mereka bisa.

Untuk saat ini UWP dan penerusnya, WinUI, belum siap untuk aplikasi LOB

Ada beberapa masalah yang kita hadapi

• Penampilan buruk. Misalnya properti ketergantungan WinUI 50 kali lebih lambat dari https://github.com/microsoft/microsoft-ui-xaml/issues/1633 .
• Kinerja kompilasi yang buruk. Beberapa kali lebih lambat dari wpf
• dotnet asli
• Banyak perubahan yang melanggar antara rilis.
• Kotak pasir dan model izin
• Kemampuan kustomisasi terbatas untuk vendor pihak 3d dibandingkan dengan wpf

Apakah menurut Anda WinUI dapat mengatasi keterbatasan ini dan menjadi kerangka kerja siap LOB berikutnya untuk 10 tahun ke depan. Atau sudah waktunya untuk maju ke aplikasi blazer elektron)

Saya memiliki beberapa masalah dengan status WinUI saat ini.

C++/WinRT masih merupakan pengalaman pengembang yang sangat buruk dibandingkan dengan perkakas C++/CX dan pengalaman pengembang secara keseluruhan. Jika kita diharapkan untuk menangani komponen WinUI yang ditulis dalam C++, setidaknya memiliki cakupan 1:1 untuk apa yang mampu dilakukan oleh perkakas C++/CX.

Menjadi standar C++ 17 tidak ada gunanya bagi saya jika produktivitas saya menderita dibandingkan hanya menggunakan C++/CX, dan dibutuhkan dua kali lebih lama untuk menulis komponen UWP atau UI berbasis XAML.

Yang mengarah ke pertanyaan kedua saya, alasan utama untuk berurusan dengan C++ di UWP/WinUI, adalah karena Microsoft telah menjatuhkan bola dalam segala jenis pengikatan DirectX ke bahasa .NET. Jadi apakah WinUI akan memberikan dukungan untuk XNA seperti penggantian, atau scenegraph 3D WPF? Rupanya kami hanya mendapatkan keheningan radio di sini, dan dipaksa untuk masuk ke proyek komunitas seperti MonoGame atau mesin yang meledak-ledak seperti Unity.

Kapan akhirnya Win2D menjadi bagian dari WinUI? Saat ini tampaknya berada dalam mode pemeliharaan dengan masa depan yang tidak pasti.

Saat ini menjadi sangat sulit untuk tetap menjual mimpi UWP, karena jumlah pendengar di sekitar kotak sabun saya terus berkurang.

Kapan elemen UI Windows 10X akan masuk ke desktop Windows 10?

@carmelellolb 2022-2025?

Sunting: MS mungkin akan menghapus ini, karena mengusulkan jadwal pengiriman produk, yang tidak ada dan karena itu menyesatkan;)

@Felix-Dev "WinUI Desktop .. akan memungkinkan aplikasi Win32 memiliki akses penuh ke API UI UWP .. tidak termasuk beberapa API seperti CoreWindow.

Tidak termasuk CoreWindow? OMG - Itulah API pertama dan terpenting yang harus dikeluarkan dari UWP. Ini adalah API paling dasar yang menyediakan fungsionalitas jendela dasar. Itu harus universal, di dalam dan di luar wadah UWP. Sampai dikeluarkan, kami tidak dapat memiliki basis kode yang sama untuk lapisan aplikasi dan kami terjebak dengan kode c Win32 lama di C++ atau apa pun yang akan disediakan oleh inti .net (kelas Window lain lagi?) untuk C#.

Tolong Microsoft - Sama seperti Anda menyediakan XamlWindow baik di dalam maupun di luar UWP, harap berikan juga CoreWindow baik di dalam maupun di luar UWP.

Tentang panggilan: mengapa Anda pindah dari Teams? YouTube tidak bekerja dengan baik pada yang terakhir.

@Gavin-Williams

Dari https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216:

Pendekatan kami adalah bahwa WinUI 3 akan menggunakan CoreWindow saat berjalan di UWP dan Win32 Window(HWind) saat berjalan di Desktop (Win32).

WinUI 3 di aplikasi UWP akan dapat menggunakan API AppWindow. Untuk Desktop, akan diperlukan untuk keluar dengan sesuatu yang serupa. Kami masih merancang ini, jadi saya tidak memiliki detail lebih lanjut sejauh ini.

Tim juga mengatakan sedang mencari untuk menyediakan API seperti CoreApplicationViewTitleBar.ExtendViewIntoTitleBar untuk WinUI Desktop juga sehingga kami mungkin bisa mendapatkan yang terbaik dari kedua dunia. Kekuatan penuh dari desain jendela Win32 (yaitu tidak ada bilah judul/100% bilah judul khusus, jendela aplikasi < ukuran minimum yang diperlukan, tidak ada tombol bilah tugas,...) dan API penyesuaian UWP modern yang baru. (Untuk UWP, kita mungkin harus menunggu AppWindow V2 memiliki kemampuan windowing yang dekat dengan windowing Win32 saat ini.)

@jesbis Pertanyaan tentang WinUI Desktop: Dalam masalah https://github.com/microsoft/microsoft-ui-xaml/issues/1939 telah ditunjukkan bahwa aktivasi pemberitahuan roti panggang tidak berfungsi untuk aplikasi desktop paket MSIX pada (setidaknya) 1909 sebagaimana disebutkan dalam dokumen :

Untuk aplikasi Desktop Bridge, cukup kirim pemberitahuan toast seperti yang dilakukan aplikasi UWP. Saat pengguna mengklik roti panggang Anda, aplikasi Anda akan meluncurkan baris perintah dengan argumen peluncuran yang Anda tentukan di roti panggang.

Sementara saya harus menunggu dan melihat apakah perbaikan yang disebutkan akan di-backport ke versi OS yang terpengaruh untuk aplikasi jembatan desktop, pertanyaan saya adalah: Akankah aplikasi WinUI Desktop menyediakan fitur aktivasi roti panggang out-of-the-box yang dikutip di atas (jadi tanpa harus menggunakan COM Activator) pada semua versi Windows 10 yang ditargetkan WinUI? (Atau konsep aktivasi roti panggang serupa.)

@ Felix-Dev Dari dokumentasi tampaknya Pulau XAML tidak sepenuhnya menyiratkan aplikasi hibrida, Anda dapat memanggil API hosting UWP XAML langsung dari aplikasi Win32 Anda dengan mengorbankan kehilangan beberapa fungsi, seperti penggunaan kontrol khusus, jika saya mengerti dengan benar dokumen (dan catatan di dokumen):

Host kontrol UWP standar di aplikasi WPF menggunakan Kepulauan XAML

Komponen yang diperlukan

Proyek dan kode sumber untuk aplikasi Anda. Menggunakan kontrol WindowsXamlHost untuk menghosting kontrol UWP pihak pertama standar didukung di aplikasi yang menargetkan .NET Framework atau .NET Core 3.

Proyek aplikasi UWP yang mendefinisikan kelas Aplikasi root yang berasal dari XamlApplication . Proyek WPF atau Windows Forms Anda harus memiliki akses ke instance kelas Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication yang disediakan oleh Windows Community Toolkit. Objek ini bertindak sebagai penyedia metadata akar untuk memuat metadata untuk jenis UWP XAML khusus dalam rakitan di direktori aplikasi Anda saat ini.

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

Saya berjuang selama berjam-jam untuk membuat C++/WinRT bekerja, dan gagal melakukan apa yang saya lakukan dalam 30 menit dengan C++/CX

Jika kita diharapkan untuk menangani komponen WinUI yang ditulis dalam C++, setidaknya memiliki cakupan 1:1 untuk apa yang mampu dilakukan oleh perkakas C++/CX.

@Gavin-Williams, @pjmlp sudahkah Anda membuka masalah di repo cppwinrt untuk masalah yang Anda temukan? Atau apakah itu masalah khusus untuk WinUI yang dapat Anda buka masalah dalam repo ini? Kami secara aktif bekerja pada dukungan C++/WinRT sehingga akan sangat menyenangkan untuk mendengar detail apa pun tentang apa yang tidak berfungsi dengan baik untuk Anda. Kami juga menggunakannya sendiri - fitur WinUI baru semuanya ada di C++/WinRT, seperti halnya aplikasi kami yang menggunakannya (mis. kalkulator ).

Tentang panggilan: mengapa Anda pindah dari Teams? YouTube tidak bekerja dengan baik pada yang terakhir.

Jika maksud Anda masalah audio: kami pikir kami memiliki kabel yang buruk bulan lalu dan berharap itu akan lebih baik besok. YouTube tampaknya lebih mudah diakses oleh kebanyakan orang, dan studio Channel9 memiliki audio dan video yang jauh lebih baik daripada ruang konferensi yang kami gunakan untuk Teams.

RE: CoreWindow, dukungan win32, container - kami akan membicarakan arah kami saat ini selama panggilan komunitas besok dengan @marb2000 :)

Kami juga akan mencoba menjawab pertanyaan lain sejauh ini (misalnya status terkini di timeline SwapChainPanel, Win2D/DirectX, pulau, dll.) - terima kasih atas komentar & pertanyaannya sejauh ini!

@jesbis Terima kasih telah

Tidak ada masalah untuk dibuka, karena pendekatan C++/WinRT untuk pengembangan sepenuhnya mundur ke produktivitas yang ditawarkan oleh C++/CX.

Dengan C++/CX saya awalnya berpikir bahwa Microsoft akhirnya menjual Visual C++ dengan cara yang benar, 25 tahun kemudian Visual C++ telah menangkap pengalaman RAD dari C++ Builder.

Alih-alih apa yang diberikan C++/WinRT kepada saya adalah kembali ke hari-hari ATL/WTL, di mana saya harus menulis boilerplate MIDL, meskipun MIDL 3.0 entah bagaimana lebih bagus daripada MIDL asli, harus secara manual menulis boilerplate binding UWP yang ditangani C++/CX Aku.

Bukan berarti C++/CX sempurna, cara menangani event handler masih gagal dari C#/VB.NET, atau C++ Builder dalam hal ini.

UWP tetap terikat pada Windows, jadi memiliki pengikatan C++ murni bukanlah sesuatu yang membuat saya tertarik pada C++/Winrt, melainkan mampu melakukan hal yang persis sama seperti di C# atau VB.NET, tanpa harus berurusan dengan kode yang masih terasa seperti ATL/WTL.

Dan seperti yang disebutkan, saya hanya sibuk dengan C++ karena seruan untuk mengekspos DirectX sebagai satu set UWP Runtime Components terus diabaikan.

Jadi saya tidak merasa membuka masalah di cppwinrt akan meningkatkan kemampuan untuk menggunakan C++/Winrt di Blend dan Visual Studio semudah C++/CX, idealnya semudah C# dan VB.NET, seperti yang saya harapkan tim cppwinrt untuk menggeser masalah ke dalam tim Visual Studio, dan secara tradisional (MFC/ATL/WTL) tim perkakas C++ tidak pernah peduli untuk menyediakan perkakas tingkat tinggi yang sama seperti yang dinikmati bahasa .NET, meskipun perusahaan lain dapat melakukannya dengan C++ (Qt, Embarcadero).

@pjmlp terima kasih atas detailnya - Saya memeriksa dengan beberapa orang untuk melihat apakah ada info lebih lanjut untuk dibagikan tentang perkakas C++/WinRT, meskipun saya mungkin tidak akan memiliki jawaban yang baik besok. Kami fokus pada C++/WinRT untuk pengembangan baru, tetapi kami memilikinya di peta jalan kami semoga memiliki template C++/CX untuk WinUI 3 juga jika itu membantu.

Saya juga tertarik untuk mengetahui apa rencananya untuk isolasi aplikasi WinUI ke depan. Dari perspektif perusahaan, kami memerlukan isolasi/kotak pasir dan kontrol kemampuan (bukan keikutsertaan pengguna). Jadi, menempatkan ini sebagai topik untuk Miguel..

@infoequipt dapatkah Anda menguraikan apa yang Anda maksud dengan isolasi? Misalnya seperti dukungan AppContainer ?

Untuk saat ini UWP dan penerusnya, WinUI, belum siap untuk aplikasi LOB

• Banyak perubahan yang melanggar antara rilis.

@Xarlot perubahan apa yang menyebabkan masalah bagi Anda? Dengan API UWP, kami mencoba mempertahankan tingkat kompatibilitas yang tinggi setiap rilis.

@Gavin-Williams Mengenai SharpDX tidak digunakan lagi, Anda mungkin ingin melihat Vortice.Windows , yang merupakan alternatif yang bagus untuk itu. @Aminator saat ini menggunakannya di mesin dan editor game UWP/C#/XAML DX12 miliknya sendiri, DX12GameEngine .
Semoga itu sesuai dengan kebutuhan Anda di aplikasi Anda! 😄

Mengenai pertanyaan untuk panggilan, saya punya satu yang merupakan detail kecil, tetapi sementara kami melakukannya: bisakah kami menggunakan sakelar ke WinUI 3 untuk juga memperbaiki beberapa bug UI lawas kecil yang dapat dianggap "melanggar perubahan", seperti StackPanel menerapkan properti Spacing ke item yang diciutkan?

Yaitu. jika Anda memiliki beberapa item yang diciutkan dalam StackPanel , itu masih akan menerapkan spasi di antara mereka, memaksa Anda untuk mundur ke padding/margin manual antar item jika Anda memiliki beberapa item yang dapat ditampilkan/disembunyikan secara terprogram. Saya telah memperbaiki bug khusus ini dalam PR untuk WrapPanel di Windows Community Toolkit ( #2838 ), dan tampaknya perilaku ini di StackPanel adalah masalah yang diketahui yang dikenali oleh beberapa insinyur MS lainnya demikian juga. 🤔

Pertahankan pekerjaan hebat! 🚀

@leoniDEV Terima kasih telah menunjukkan ini. Mari kita lihat apakah kita akan mendapatkan jawaban yang pasti besok

@jesbis Dua pertanyaan lagi tentang WinUI Desktop (terkait satu sama lain):

1. Akankah aplikasi Desktop WinUI memiliki sakelar bawaan antara multi-instance (standar Win32) dan satu-instance (standar UWP)? Saat ini jika kita ingin aplikasi Win32 menjadi instance tunggal, kita harus mengimplementasikan perilaku ini sendiri. Ini mungkin tidak hanya memerlukan kunci aplikasi (seperti mutex untuk memeriksa apakah instance sudah berjalan) tetapi juga Win32 API seperti SendMessage untuk meneruskan operasi dari instance aplikasi kedua ke instance aplikasi utama (lihat pertanyaan 2). Akan sangat bagus jika kita bisa mendapatkan opsi untuk memiliki perilaku instans tunggal aplikasi UWP untuk aplikasi WinUI Desktop.

1. Apakah aplikasi Desktop WinUI dapat menggunakan API Jumplist UWP ? Saat ini, aplikasi jembatan desktop tidak dapat menggunakannya secara efektif karena aplikasi tampaknya tidak dapat diaktifkan (lihat masalah Terminal Windows https://github.com/microsoft/terminal/issues/576 untuk ikhtisar singkat tentang masalah). Saya ingin dukungan penuh dari API ini untuk aplikasi Desktop WinUI karena mereka jauh lebih mudah untuk digunakan daripada API Win32/WPF. Misalnya, ikon tugas jumplist dapat dengan mudah diatur menggunakan skema URI ms-appx:/// atau ms-appdata:/// daripada harus membuat .exe atau .dll yang berisi gambar, lalu mengatur jalur ke file biner tersebut dan juga offset ke dalam file untuk ikon tertentu .

   Dokumen meringkas keuntungan dari UWP Jumplist API:

   Atau, gunakan UWP Windows.UI.StartScreen.JumpList API sebagai gantinya, yang memungkinkan Anda untuk mereferensikan string dan aset gambar menggunakan skema URI ms-resource relatif paket (yang juga merupakan bahasa, DPI, dan sadar kontras tinggi).

Perilaku instans tunggal aplikasi UWP juga berpotensi membuat bekerja dengan jumplist menjadi lebih mudah. Jika Anda memiliki tugas jumplist yang harus beroperasi pada instans aplikasi yang sedang berjalan, di WPF/Win32, instans aplikasi kedua diluncurkan yang kemudian perlu menggunakan, misalnya, SendMessage Win32 API untuk mengirim operasi yang diminta ke instance aplikasi utama. Menggunakan perilaku instans tunggal di UWP, aplikasi yang berjalan dengan mudah mendapatkan tugas lompatan yang dipanggil. tanpa semua pekerjaan tambahan dalam kasus Win32.

@pjmlp hal lain yang mungkin menarik jika Anda belum melihatnya adalah sesi ini oleh Kenny Kerr dan Scott Jones dari konferensi Build terakhir, terutama ~11 menit terakhir di mana mereka berbicara tentang beberapa perbaikan prototipe untuk binding, dan beberapa C++ spesifikasi teknis untuk menambahkan refleksi dan dukungan metaclass yang dapat sepenuhnya menghapus persyaratan codegen IDL & metadata saat ini:

https://youtu.be/X41j_gzSwOY?t=2659

Jika kita punya waktu maka kita bisa membicarakan ini sedikit di telepon besok juga.

Terima kasih @jesbis , saya mengetahui pembicaraan itu. Masih terlalu jauh di masa depan seperti yang saya tahu.

Saat ini sepertinya saya akan mem - @Sergio0694 daripada menunggu perkakas tersebut

Saya mengagumi upaya Anda, tetapi di sini dari parit, setelah Silverlight, XNA, WinRT, UAP, UWP, WinUI, .NET Framework, WCF, EF6, akhirnya kami lelah untuk terus menulis ulang.

WinUI harus lebih baik daripada WPF dalam semua hal, dan jika kita terpaksa menggunakan C++ karena alasan, maka perkakasnya harus pada tingkat yang sama dengan yang disukai pengembang .NET, untuk benar-benar layak untuk bergerak melampaui WPF atau membuat titik untuk menghindari bisnis yang ingin pergi dengan aplikasi gaya Electron.

Seperti yang sudah ditanyakan oleh @Sergio0694 , akankah WinUi 3.0 digunakan tidak hanya untuk mengganti ruang nama tetapi juga berisi perubahan yang melanggar lainnya, yang diperlukan untuk memperbaiki bug seperti spasi yang salah diterapkan?

Jika demikian, apakah akan ada peluang untuk mengganti nama properti NavigationView.IsBackButtonVisible menjadi BackButtonVisibility karena nama dan jenis saat ini tidak benar-benar sesuai (IsBackButtonVisible adalah enum NavigationViewBackButtonVisible, bukan bool). Ini juga dibahas di sini .

@chingucoding Saya ingat tim mengatakan bahwa untuk WinUI 3.0 itu sendiri, perubahan yang melanggar harus minimal untuk membuat porting aplikasi yang ada (UWP) semudah mungkin. Saya menduga perubahan ini, jika disetujui, akan diterapkan pada rilis WinUI 3.x/4/5/.... berikutnya.

T: Akankah WinUI 3.x mendukung AcrylicBrush dengan HostBackdrop ? Saat ini diketahui rusak di alfa tetapi saya ingin tahu apakah itu ada di peta jalan untuk diperbaiki sebelum rilis.

T: Akankah WinUI Desktop mengaktifkan pengembang aplikasi desktop untuk _finally_ menggunakan AcrylicBrush dengan HostBackdrop ? Kami sebelumnya menggunakan atribut komposisi WCA_ACCENT_POLICY dengan ACCENT_ENABLE_ACRYLICBLURBEHIND tetapi Microsoft secara kritis memecahkannya pada 19H1+ dan aplikasi kami telah menderita sejak itu. (Ini juga memengaruhi hal-hal seperti Emoji Picker tetapi Microsoft memperbaiki komponen tersebut untuk menggunakan metode non-akrilik.)

Tentang WebView2:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"Pratinjau pengembang tersedia untuk Win32 C++ di Windows 10, Windows 8.1, Windows 8, dan Windows 7. Di masa mendatang, kami berencana untuk mendukung WebView2 di .NET, dan XAML."

Pertanyaan saya adalah .. Apakah direncanakan versi .NET WebView2 SDK yang berlaku untuk Win8.1, 8 dan 7?
Saya khawatir bahwa mungkin WebView2 di .NET hanya didukung melalui WinUI3. Dalam pemahaman saya, dukungan aplikasi WinUI3 WinForms hanya berlaku untuk berbasis .NET Core dan hanya untuk Win10.
Mari saya jelaskan situasi saya.. Klien saya memiliki banyak aplikasi desktop WinForm yang menggunakan IE BrowserControl. Tetapi IE sudah usang dan ingin bermigrasi ke browser modern. Dan, aplikasi ini HARUS mendukung Win7, 8, 8.1. (jangan salahkan saya untuk dukungan os lama)

Jika memungkinkan:

• Win32 ETA pada build pratinjau untuk WinUI 3.0

• Jika kode sumber belum siap untuk dibagikan, mungkin memberikan demo exe yang sudah sesuai dari beberapa elemen UI yang berjalan yang dapat kita unduh dan mainkan akan keren untuk dipamerkan kepada rekan kerja.

• Apakah WinUI 3.0 mendukung efek shader khusus seperti yang dilakukan WPF/Silverlight? Jika tidak, apakah ada pemikiran untuk menambahkannya nanti? Apakah lapisan rendering yang digunakan oleh WinUI mampu melakukan ini?

@leoniDEV Saya melanjutkan dan membuat proyek Pulau XAML seperti yang Anda soroti (jadi tidak ada proyek UWP terpisah). Ini berisi satu kontrol kotak masuk UWP (tombol) dan berfungsi dengan baik pada 10X. Tidak mengherankan untuk cerita kontainer ... itu berjalan di kontainer Win32 seperti yang diharapkan.

Jadi tampaknya setidaknya saat ini belum ada dukungan penuh untuk aplikasi Pulau XAML yang menggunakan proyek UWP terpisah.

Saya sedang melihat melakukan v-next dari aplikasi WPF lawas. Saya mungkin dapat menggunakan .NET Core WPF, tetapi saya sangat ingin menggunakan WinUI. Saya mengalami masalah dengan lib seperti Prism yang masih berasal dari Windows.UI.Xaml (sebagai lawan dari Microsoft.UI.Xaml). Sepertinya jenis masalah ini mendasar. Apakah ada panduan PnP yang solid untuk WinUI, atau terlalu cepat?

Apakah mungkin untuk meminta seseorang dari tim shell atau tim aplikasi kotak masuk untuk berbicara tentang mengapa menu mulai dan penjelajah file pada Windows 10x berbasis web daripada menggunakan WinUI?

Yang saya butuhkan hanyalah pengalaman porting yang mulus dari aplikasi UWP kami saat ini (dengan ekstensi desktop) ke aplikasi WinUI Desktop (tanpa ekstensi desktop). Apakah ini mungkin? Apa jebakan dalam skenario ini?

Jika ini terbukti sulit, apakah mungkin di masa depan untuk meningkatkan UWP (untuk aplikasi yang berjalan di desktop) untuk selalu menjalankan aplikasi di latar belakang dan memungkinkan mereka untuk memanggil semua API win32 melalui P/Invoke dan mengizinkan dll yang memuat dll lain tanpa LoadPackagedLibrary (tetapi dengan LoadLibrary).

Seberapa besar kemungkinan WinUI 3.0 akan siap diluncurkan ketika perangkat Windows 10X pertama diluncurkan? Saya tertarik untuk terjun ke dunia pengembang Windows dan saya mencoba memutuskan pendekatan apa yang paling masuk akal saat ini.

Terima kasih semuanya atas pertanyaannya dan untuk menonton jika Anda bisa melakukannya! Rekaman itu langsung di tautan yang sama.

Ada banyak pertanyaan yang tidak kami dapatkan - saya akan mencoba meringkasnya dan mengirimkan beberapa tanggapan di sini segera.

Pertunjukan yang bagus, terima kasih telah menjawab pertanyaan saya dan untuk presentasi Miguel.

Saya akan menambahkan beberapa pertanyaan lagi yang tersisa dengan harapan akan dijawab.

1. Aplikasi Win32 tradisional menggambar ke layar di WM_PAINT. Aplikasi XAML adalah mode yang dipertahankan. Kami menggambar terlalu banyak hal ke layar untuk membuat objek/kontrol individual. Apakah masih ada WM_PAINT yang setara untuk memungkinkan saya menggambar ke jendela tetapi dengan API yang lebih modern? Win2D atau API mode langsung lainnya?

2. Aksesibilitas ditangani secara berbeda di Win32 (COM API) vs, katakanlah, WPF (Automation Peers). Jika saya menulis aplikasi Win32 + WinUI, apakah saya dapat menambah atau mengontrol pohon aksesibilitas dengan lebih mudah? Atau apakah saya akan tetap menggunakan COM API yang lama? Bagaimana saya memadukan konten yang digambar khusus dengan kontrol yang dapat diakses di pohon aksesibilitas?

3. Hari ini, kami mencetak dengan menggambar ke dalam printer DC. Apakah ada pencetakan baru dengan Win32+WinUI?

4. Saya masih agak bingung sehubungan dengan hubungan antara HWND, CoreWindow, dan apa pun yang muncul berikutnya untuk WinUI. Apakah HWND akan tetap ada atau akankah kita mengganti panggilan CreateWindow dengan yang lain? Saya berasumsi begitu ... tetapi jika itu masalahnya, saya berasumsi pasti masih ada HWND yang mendasari untuk kasus-kasus di mana kita harus menyerahkan satu ke komponen eksternal (induk HWND misalnya).

5. Akankah WebView2 yang digunakan dalam aplikasi Win32+WinUI memiliki masalah wilayah udara yang kami temui dengan kontrol IE yang disematkan?

Mulai mengejar beberapa pertanyaan:

Apakah WinUI hanya pengembangan UWP tetapi spesifikasi yang lebih modern? Saya melihat percakapan tentang WinUI dan saya tidak 100% yakin apakah mereka berbicara tentang UWP dev, libs tertentu di UWP dev atau sesuatu yang sama sekali berbeda

WinUI secara khusus adalah lapisan UI dan tidak menyertakan aspek lain dari platform aplikasi UWP seperti model aplikasi untuk penangguhan/melanjutkan, tugas latar belakang, dll.

Untuk aplikasi UWP, itu dapat secara khusus menggantikan Windows.UI.Xaml , Windows.UI.Composition dan bagian dari Windows.UI.Input .

Akankah aplikasi WinUI memiliki sakelar bawaan antara multi-instance (standar Win32) dan single-instance (standar UWP)?

@ Felix-Dev, kami belum mengeksplorasi ide dukungan instance tunggal yang lebih baik untuk aplikasi win32 - jika Anda memiliki proposal, silakan buka masalah di repo ini untuk itu!

Akankah WinUI 3.x mendukung AcrylicBrush dengan HostBackdrop? Saat ini diketahui rusak di alfa tetapi saya ingin tahu apakah itu ada di peta jalan untuk diperbaiki sebelum rilis. Akankah WinUI Desktop memungkinkan pengembang aplikasi desktop untuk akhirnya menggunakan AcrylicBrush dengan HostBackdrop?

@riverar sayangnya ini tidak ada dalam rencana untuk WinUI 3.0 RTM. Ada tantangan dengan mendukung ini di platform UI yang dipisahkan dari OS, tetapi kami berencana untuk meninjau kembali ini setelah 3.0.

Tentang WebView2: Pertanyaan saya adalah .. Apakah direncanakan versi .NET WebView2 SDK yang berlaku untuk Win8.1, 8 dan 7?
Saya khawatir bahwa mungkin WebView2 di .NET hanya didukung melalui WinUI3.

@ pnp0a03 kontrol WinUI Xaml hanya didukung di WinUI 3, tetapi ada pratinjau pengembang dari inti WebView 2 SDK untuk Windows 7, 8 dan 8.1 untuk aplikasi win32:

https://docs.microsoft.com/microsoft-edge/hosting/webview2

Saya mengalami masalah dengan lib seperti Prism yang masih berasal dari Windows.UI.Xaml (sebagai lawan dari Microsoft.UI.Xaml). Sepertinya jenis masalah ini mendasar. Apakah ada panduan PnP yang solid untuk WinUI, atau terlalu cepat?

@GraniteStateHacker Agak terlalu cepat menurut saya - WinUI 3 masih terlalu baru untuk memiliki banyak dukungan ekosistem (hanya dalam alfa) tetapi @hassanuz memulai alur kerja untuk menyelidiki opsi kompatibilitas/migrasi perpustakaan.

Apakah WinUI hanya untuk aplikasi Store?

Tidak - Anda dapat menggunakannya dengan berbagai cara, misalnya:

• sertakan dalam aplikasi win32 yang ada (WPF, WinForms, MFC, dll.) menggunakan Xaml Islands
• buat penginstal MSIX dan gunakan sesuka Anda
• buat aplikasi yang belum dikemas dan distribusikan melalui xcopy atau cara lain (belum didukung untuk WinUI 3 tetapi direncanakan untuk RTM)

Seberapa besar kemungkinan WinUI 3.0 akan siap diluncurkan ketika perangkat Windows 10X pertama diluncurkan? Saya tertarik untuk terjun ke dunia pengembang Windows dan saya mencoba memutuskan pendekatan apa yang paling masuk akal saat ini.

@dwalleck WinUI 3 sudah memiliki alpha out dan harus memiliki pratinjau yang lebih fungsional di sekitar kerangka waktu konferensi Build , dan keduanya menargetkan akhir 2020. Jika Anda memulai dengan UWP Xaml dan/atau WinUI maka Anda harus berada di jalur yang baik untuk pengembangan 10X .

Aplikasi Win32 tradisional menggambar ke layar di WM_PAINT. Aplikasi XAML adalah mode yang dipertahankan. Kami menggambar terlalu banyak hal ke layar untuk membuat objek/kontrol individual. Apakah masih ada WM_PAINT yang setara untuk memungkinkan saya menggambar ke jendela tetapi dengan API yang lebih modern? Win2D atau API mode langsung lainnya?

@jschroedl Pohon elemen & kuas

• lapisan komposisi Visual
• lapisan komposisi Bentuk yang memungkinkan menggambar geometri yang dipertahankan berkinerja sangat tinggi - juga digunakan untuk hal-hal seperti kontrol WinUI AnimatedVisualPlayer yang dapat memainkan bentuk/animasi Lottie
• Interop DirectX dengan Xaml menggunakan
• Win2D, yang mengabstraksikan interop DirectX di atas untuk Anda (dengan Direct2D, DirectWrite) dan menyediakan .NET API

Aksesibilitas ditangani secara berbeda di Win32 (COM API) vs, katakanlah, WPF (Automation Peers). Jika saya menulis aplikasi Win32 + WinUI, apakah saya dapat menambah atau mengontrol pohon aksesibilitas dengan lebih mudah? Atau apakah saya akan tetap menggunakan COM API yang lama? Bagaimana saya memadukan konten yang digambar khusus dengan kontrol yang dapat diakses di pohon aksesibilitas?

Pertanyaan bagus! Paging @marb2000 untuk memastikan ini tercakup dan memberikan pembaruan terbaru. Secara umum pohon WinUI Xaml harus menggunakan AutomationPeers tapi saya belum yakin apakah itu akan memperluas fungsionalitas baru ke konten win32 non-WinUI.

Hari ini, kami mencetak dengan menggambar ke dalam printer DC. Apakah ada pencetakan baru dengan Win32+WinUI?

Fungsi pencetakan utama untuk konten WinUI harus melalui versi WinUI dari WinRT PrintDocument API.

Saya masih agak bingung sehubungan dengan hubungan antara HWND, CoreWindow, dan apa pun yang muncul berikutnya untuk WinUI. Apakah HWND akan tetap ada atau akankah kita mengganti panggilan CreateWindow dengan yang lain? Saya berasumsi begitu ... tetapi jika itu masalahnya, saya berasumsi pasti masih ada HWND yang mendasari untuk kasus-kasus di mana kita harus menyerahkan satu ke komponen eksternal (induk HWND misalnya

WinUI tidak menggantikan hwnds tetapi tujuannya adalah untuk mengabstraksikan penggunaannya untuk kasus penggunaan umum dengan menyediakan Xaml API - mirip dengan cara kerja WPF. Xaml API memang masih akan menggunakan hwnds/CoreWindows sebagai detail implementasi yang mendasarinya, dan kami kemungkinan akan memiliki API "pintu belakang"/"escape-hatch" untuk mendapatkan akses langsung ke hwnds saat dibutuhkan. Kita harus memiliki draft proposal dalam beberapa minggu yang akan membuat ini lebih jelas.

@jesbis Terima kasih atas jawaban Anda, tetapi sayangnya kekhawatiran saya tidak terpecahkan.
Saat ini, versi WebView2 SDK Win32 "C++" (pratinjau) dirilis dari situs ini. Mendukung Win7, 8 dan 8.1.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
Pertanyaan saya adalah tentang versi .NET. Saat ini, versi .NET hanya didukung oleh WinUI 3, Tapi, seperti yang Anda tahu, kami tidak dapat menggunakan WinUI 3 di Win7, 8, dan 8.1 (benarkah? ).
Jadi, saya telah memposting pertanyaan saya seperti di bawah ini.

Pertanyaan saya adalah .. Apakah direncanakan versi .NET WebView2 SDK yang berlaku untuk Win8.1, 8 dan 7?

@jesbis Terima kasih telah menjawab pertanyaan saya, meskipun itu terasa mendemotivasi.

Mencoba untuk menjadi konstruktif di sini.

Jadi yang terbaik yang dapat ditawarkan Microsoft mengenai perkakas C++/WinRT adalah dengan menunjukkan beberapa proposal yang beredar, bahwa dengan keberuntungan mungkin mendarat di ISO di suatu tempat antara C++23 atau C++26, jika sama sekali. Dan kemudian tunggu tim Visual Studio untuk akhirnya membangun kembali C++/CX di atasnya, yang membuatnya sekitar 6 tahun dari sekarang.

Jika saya menginginkan perkakas C++ UI yang hebat, WinUI jelas bukan, bukan Qt atau C++ Builder, dengan manfaat tambahan dari portabilitas platform.

Jadi setelah menonton presentasi, dan masih memakai bekas dari XNA (telah menulis ulang di C++ dengan DirectXTK), WinRT 8.0, WinRT UAP 8.1, UWP W10, C++ Direct2D bukan System. Menggambar (sampai Win2D datang, sekarang stagnan), WinUI jelas merupakan sesuatu yang akan saya tunda.

Ke depan, saya akan menyarankan pelanggan saya untuk menggunakan WPF saat menggunakan .NET, Qt saat menggunakan C++, atau fokus pada PWA jika dapat dilakukan dengan teknologi Web.

Peta jalan WinUI 3.0 tidak menginspirasi kepercayaan bahwa reboot lain sudah dekat, jika penjualan UWP terus gagal di pasar desktop.

Dalam arti apa yang ingin saya tunjukkan adalah bahwa manajemen Microsoft harus memikirkannya dengan cara menjual kepada kami gagasan untuk mengadopsi WinUI, setelah mengecewakan kami berkali-kali sejak rilis Windows 8.

@pjmlp umpan balik umum C++/WinRT mungkin paling baik diarahkan ke repo cppwinrt. Pembaruan standar ISO membutuhkan waktu tetapi saya harap ini akan kurang dari kerangka waktu yang Anda sebutkan - dukungan refleksi adalah prioritas utama dan mereka baru saja mendiskusikannya pada konferensi C++ di Praha minggu lalu.

DirectXTK yang masih dalam pengembangan telah mendapatkan pembaruan rutin.

Dalam hal API kerangka Xaml, WinUI adalah jalur ke depan dan memiliki garis keturunan kompatibilitas yang cukup tak terputus kembali ke Windows 8 - kami menghabiskan banyak waktu untuk mencoba mempertahankan tingkat kompatibilitas yang tinggi Ada beberapa perubahan (karena integrasi shell, Struktur proyek VS, dll.) tetapi sebagian besar Anda mungkin dapat mem-porting Windows 8 Xaml ke aplikasi Windows 10 saat ini, mengkompilasi ulang dan menjalankannya pada penerbangan orang dalam terbaru dan itu akan berhasil.

Beberapa manfaat tingkat tinggi dari WinUI akan mencakup menghilangkan penghalang antara API UWP WinRT dan API win32, mendukung .NET 5, memungkinkan dukungan downlevel langsung untuk fitur baru, menghilangkan kebutuhan untuk melakukan banyak pemeriksaan versi OS bersyarat, mengaktifkan kontribusi OSS dan mengaktifkan pembaruan tambahan untuk aplikasi win32 yang ada menggunakan pulau Xaml.

@pnp0a03 ada upaya untuk membawa elemen .NET ke pasar juga. Saya tidak dapat memberikan tanggal spesifik, tetapi kami mengetahui permintaan untuk ini dan sedang mengerjakan detailnya.

@jschroedl kami ingin menghilangkan masalah wilayah udara, kami mencoba menyusun rencana rendering yang akan membantu kami mencapai ini.

@jesbis Seperti yang disebutkan saya tidak percaya mengeluh pada cppwinrt akan melakukan apa pun, saya lebih suka mengeluh dengan tidak mengadopsi C++/WinRT kecuali untuk kasus penggunaan yang tidak dapat saya hindari, khususnya karena peta jalan adalah untuk mengadopsi fitur yang bahkan mungkin tidak diterima ke ISO.

Mengenai DirectXTK, saya memberikan contoh lain tentang bagaimana Microsoft telah memaksa kami untuk menulis ulang kode C# kami ke C++, dengan alat yang kurang mampu, dengan menjatuhkan XNA dan menyediakan DirectXTK sebagai "alternatif".

Untungnya komunitas open source berhasil membuat MonoGame dan melakukan pekerjaan yang ditolak Microsoft dengan XNA.

Saya melihatnya selama presentasi dan di beberapa komentar di sini, betapa C++ hebat dan menyenangkan, bagaimana WinDev (sekali lagi sejak Longhorn mengambil alih) terus menjual C++ dulu, .NET kemudian.

Jika saya menginginkan perkakas C++ yang hebat, Qt dan C++ Builder adalah lingkungan pilihan saya, bukan Visual C++.

Anda benar-benar harus meminta manajemen untuk mengizinkan tim Anda melihat apa yang mungkin terjadi hari ini dalam kompetisi, daripada mengharapkan beberapa metaclass dan ide refleksi untuk diterima di ISO.

Kami tidak hanya harus repot dengan API dan perpustakaan pihak ketiga yang tidak akan terbawa dari .NET Framework ke .NET Core, kami juga harus menangani semua masalah migrasi dari WPF/UWP ke WinUI dan "hanya menulis dalam C++/WinRT, itu keren dan lebih baik dalam beberapa tahun" mentalitas.

Manajemen Microsoft benar-benar harus memikirkannya dengan matang, bagaimana menjual penulisan ulang ini kepada pengembang .NET yang dibakar, jika tidak, kami tidak akan menjauh dari tumpukan yang sudah melakukan tugasnya.

@pjmlp Berbicara tentang DirectX, saya secara aktif bekerja pada grafis C# portabel dan agnostik, kerangka kerja audio dan input di waktu luang saya yang akan mampu menjalankan D3D12/11 dll dalam tampilan WinUI.... di antara banyak hal lainnya.

Ini mendukung pendekatan rendering yang jauh lebih modern dan berfokus pada kinerja vs sesuatu seperti XNA. Ini belum siap untuk digunakan tetapi merupakan sesuatu yang diinginkan banyak orang termasuk saya... jadi saya membuatnya. D3D12 dan Vulkan akan menjadi target pertama yang didukung. Anda juga dapat menulis shader dalam C# alih-alih HLSL atau GLSL dll.

Ketika sudah siap untuk digunakan, saya akan membagikan lebih banyak tetapi karena ini adalah kerangka kerja dan bukan SDK atau mesin permainan yang besar, itu akan sangat portabel dan ringan namun kuat dan mudah digunakan. Sempurna untuk merender konten 3D di WinUI, WPF, atau beberapa aplikasi C# Win32 atau WinRT asli.

https://github.com/reignstudios/Orbital-Framework

@zezba9000 Terima kasih atas informasinya, banyak hal mengesankan yang telah Anda lakukan, pujian!

Saya kira dalam hal apa dukungan terkelola untuk DirectX kami hanya dapat mengandalkan upaya komunitas seperti Anda, setelah mengatasi Managed DirectX dan XNA, kerumunan C++ MS mengambil alih upaya pengembangan DirectX.

Setidaknya salah satu dari proyek ini dapat diperhitungkan dengan advokasi saya, sebagai pemasaran untuk menunjukkan kepada orang lain bahwa itu tidak perlu hanya "C++ atau jalan raya" karena WinDev suka mendorongnya. Di sini mereka bisa mengambil pelajaran dari OpenGL ES/Metal dengan Swift, atau OpenGL ES/Vulkan dengan Java/Kotlin. Rupanya menggunakan bahasa terkelola untuk pemrograman 3D bukan masalah bagi platform seluler untuk memenangkan Windows (sayangnya, WP adalah pengalaman hebat).

Semoga berhasil atas upaya Anda, menulis shader di C # terlihat sangat menarik dan saya tidak mengetahui CS2X.

@pjmlp Ya bagian CS2X adalah yang memungkinkan untuk menulis shader GPU agnostik di C # (yang keren karena Anda akan dapat Menguji Unit shader Anda secara teori). Untuk target yang dapat menggunakan subset C#, CS2X memungkinkan saya/orang lain untuk menargetkan platform di luar apa yang didukung runtime .NET saat ini dengan runtime yang sangat ringan karena CS2X dapat mengkompilasi subset C# ke runtime C89... dan karena Orbital-Framework dapat menargetkan runtime CS2X => C89, pada gilirannya dapat menargetkan platform ini juga.

Proyek besar tapi itu yang saya pedulikan dan saya berdedikasi untuk mewujudkannya.

Apakah mungkin menggunakan HwndHost dengan WinUI 2.4
Saya mencoba di versi pra-rilis dan ini tidak berhasil.
Juga apakah akan mungkin dengan WinUI3 dengan semua Windowing (Jendela XAML) dan Aplikasi (Aplikasi XAML) yang direncanakan baru ini dan jika ya ketika kita dapat mengharapkan pratinjau pertama untuk melihatnya.
Sebenarnya jika dimungkinkan di WinUI3, apakah fungsi ini akan ditambahkan ke rilis baru WinUI 2, atau WinUI 2 hanya akan berfungsi di aplikasi Uwp.
Misalnya sekarang, kami memiliki aplikasi WPF, yang menggunakan banyak kode C++ melalui HwndHost, dan karena kami berencana untuk memindahkan semuanya ke WinUI, bagian ini sangat penting bagi kami untuk memutuskan untuk menggunakan WinUI atau yang lainnya. Juga bahkan WinUI 2 terlihat bagus untuk kami, bagian XAML sangat mudah untuk ditransfer, Komposisi Api berfungsi dengan baik, Alat Komunitas Uwp berfungsi dengan baik, hanya saja kami tidak dapat menggunakan kode HwndHost dan c++ Win32. Jadi dan kapan WinUI3 akan menyelesaikan ini? Saya juga sangat menyukai x:Bind tetapi ini bahkan berisiko untuk rilis WinUI3.

@zezba9000

Berbicara tentang DirectX, saya secara aktif bekerja pada grafis C# portabel dan agnostik, kerangka audio dan masukan di waktu luang saya yang akan mampu menjalankan D3D12/11 dll dalam tampilan WinUI.... di antara banyak hal lainnya.

Semoga berhasil dengan ini! Ini jumlah pekerjaan yang gila!

Apakah mungkin menggunakan HwndHost dengan WinUI 2.4
Saya mencoba di versi pra-rilis dan ini tidak berhasil.
Juga apakah akan mungkin dengan WinUI3 dengan semua Windowing (Jendela XAML) dan Aplikasi (Aplikasi XAML) yang direncanakan baru ini dan jika ya ketika kita dapat mengharapkan pratinjau pertama untuk melihatnya.
Sebenarnya jika dimungkinkan di WinUI3, apakah fungsi ini akan ditambahkan ke rilis baru WinUI 2, atau WinUI 2 hanya akan berfungsi di aplikasi Uwp.
Misalnya sekarang, kami memiliki aplikasi WPF, yang menggunakan banyak kode C++ melalui HwndHost, dan karena kami berencana untuk memindahkan semuanya ke WinUI, bagian ini sangat penting bagi kami untuk memutuskan untuk menggunakan WinUI atau yang lainnya.

Ada masalah terbuka untuk cara meng-host user32/comctl atau WPF UI di dalam WinUI XAML: https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Sepertinya itu tidak akan dibuat sampai setelah 3.0, jika dibuat.

Saya memposting ini ke #1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833 tapi saya akan menyalin
di sini juga: Saat ini kami memiliki aplikasi WPF yang menggunakan banyak kode c++ melalui
Kontrol HwndHost. Kami berencana untuk memindahkan aplikasi Wpf ke WinUI dan memindahkan Xaml
berfungsi dengan baik tanpa masalah, tetapi bagaimana dengan HwndHost, apakah ini akan terjadi?
mungkin dengan WinUI3. Dalam kasus kami, kami melakukan interoperabilitas dengan
DirectShow melalui HwndHost dan sekarang di WinUI 2 , ini bukan
mungkin. Apa tanggal realistis untuk menggunakan HwndHost di WinUI3? Juga adalah
Jendela dan Aplikasi Xaml baru ini seperti yang dibahas paling lambat Februari
Panggilan Komunitas WinUI, bisa membantu atau tidak?

El dom., 23 de feb. de 2020 a la 13:42, Max Strini (
[email protected]) penjelasan:

Apakah mungkin menggunakan HwndHost dengan WinUI 2.4
Saya mencoba di versi pra-rilis dan ini tidak berhasil.
Juga apakah akan mungkin dengan WinUI3 dengan semua rencana baru ini?
Windowing (XAML Window) dan Application (XAML Application) dan jika ya kapan
kita dapat mengharapkan pratinjau pertama untuk melihatnya.
Sebenarnya jika dimungkinkan di WinUI3, akankah fungsi ini?
ditambahkan ke rilis baru WinUI 2, atau WinUI 2 hanya akan berfungsi di aplikasi Uwp.
Misalnya sekarang, kami memiliki aplikasi WPF, yang menggunakan banyak kode C++ melalui
HwndHost, dan karena kami berencana untuk memindahkan semuanya ke WinUI, bagian ini
sangat penting bagi kami untuk memutuskan untuk menggunakan WinUI atau yang lainnya.

Ada masalah terbuka untuk cara meng-host user32/comctl atau WPF UI di dalamnya
WinUI XAML: #1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Sepertinya itu tidak akan dibuat sampai setelah 3.0, jika dibuat.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/microsoft/Microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMV2JKTOR5ZWRWZW63LNMVX8
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

--
Mario Rancic
Insinyur Perangkat Lunak
Profesional Bersertifikat Microsoft

Panggilan Komunitas WinUI yang sangat bagus minggu lalu! Kontennya sangat menarik dan cukup detail/teknis untuk memberikan banyak wawasan. Pembaruan status peta jalan/pengembangan juga sangat berharga bagi konsumen WinUI dan peta jalan pengembangan kami sendiri. Saya menantikan panggilan berikutnya!

Tentang HwndHost di WinUI 3.
HwndHost memungkinkan untuk meng-host konten Win32 di dalam WPF. Sayangnya tidak ada rencana di WinUI 3.0 untuk mendukung ini, termasuk di Desktop WinUI 3.0 atau Kepulauan WinUI. Tentang skenario yang dijelaskan @mariorancic01 , apakah Anda mengevaluasi API UWP MediaPlayer alih-alih DirectShow?

Nah Kamera Uwp terlihat lebih baik, tetapi tidak yakin dapatkah kita menggunakannya dalam skenario kita.
Kami menggunakan kamera sebagai kamera virtual dengan DirectShow dan kami membutuhkannya untuk ditampilkan
video, untuk mengambil aliran kamera untuk foto dan juga dengan PjSip di
waktu yang sama, sebelum kita bisa melakukannya dengan DirectShow. Bisakah kita menggunakan Uwp ini?
MediaPlayer dengan PjSip.

El mié., 26 de feb. de 2020 a la 23:47, Miguel Ramos (
[email protected]) penjelasan:

Tentang HwndHost di WinUI 3.
HwndHost memungkinkan untuk meng-host konten Win32 di dalam WPF. Sayangnya disana
tidak ada rencana di WinUI 3.0 untuk mendukung ini, termasuk di Desktop WinUI 3.0 atau
Kepulauan WinUI. Tentang skenario @mariorancic01
https://github.com/mariorancic01 dijelaskan, apakah Anda mengevaluasi UWP
API MediaPlayer bukannya DirectShow?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX39
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

--
Mario Rancic
Insinyur Perangkat Lunak
Profesional Bersertifikat Microsoft

Saya memiliki pertanyaan tentang Windows Store for Business, ini terlihat sangat keren dan sangat berguna untuk aplikasi LOB, tetapi saya membaca ini mungkin akan ditinggalkan. Adakah yang bisa mengatakan sesuatu tentang rencana tentang ini.

@marionrancic01 Ini tidak terlalu diperlukan karena Anda sekarang dapat mendistribusikan aplikasi UWP melalui kemasan MSIX.

sedih, seperti @mariorancic01 juga menurut saya Windows Store for Business berguna

@leoniDEV Sejujurnya saya ingin tahu mengapa Anda membutuhkan Windows Store for Business, ketika Anda cukup mempublikasikan sebagai msix, seperti yang dikatakan @kmgallahan

@kmgallahan @jtorjo Saya kira yang mereka cari adalah memiliki katalog aplikasi pribadi. MSIX tidak menawarkan yang saya percaya? Kecuali Anda membuat situs web tempat Anda mencantumkan MSIX yang disediakan perusahaan Anda, atau menggunakan beberapa alat manajemen untuk menyebarkan sesuatu kepada pengguna Anda?
Dengan cara yang sama, penginstal MSI lama tidak menyediakan cara untuk menemukan aplikasi juga.

Menerbitkan ke Windows Store bukanlah hal yang mudah - ini jauh lebih kompleks daripada yang Anda pikirkan. Pertama, Anda harus menunggu sertifikat dari MS - sertifikat yang akan Anda gunakan untuk menerbitkan (saya tidak ingat langkah persisnya sekarang). Kemudian, Anda perlu memastikan aplikasi Anda tidak melanggar persyaratan Store apa pun. Kemudian, pembaruan apa pun yang Anda buat dapat memakan waktu berhari-hari untuk diterima (atau dapat ditolak), dan Anda akan mengandalkan algoritme toko agar orang-orang dapat menemukan aplikasi Anda.

Tetapi jika Anda menggunakan sendiri, akan agak sulit untuk mengaturnya (saya akan tahu), tetapi setelah selesai, itu akan mudah. Tapi ya, Anda akan bertanggung jawab untuk menunjukkan aplikasi Anda kepada dunia.

Sebagai seseorang yang memiliki banyak aplikasi di Microsoft Store, termasuk toko untuk bisnis, saya dapat memberi tahu Anda bahwa penerbitan ke toko Microsoft telah menjadi jauh lebih baik dalam beberapa bulan terakhir. Sertifikasi untuk pembaruan rutin terkadang terjadi secepat beberapa jam. Pedoman toko juga cukup mudah untuk dipenuhi.
Di sisi lain, mengganggu msix mandiri bisa jadi rumit. Tidak seperti toko yang menandatangani paket untuk Anda, jika Anda mendistribusikan aplikasi di luar toko, Anda harus menandatanganinya sendiri.

@jtorjo Anda tidak memerlukan sertifikat apa pun.

Untuk lebih jelasnya, ada masalah dengan toko dan dasbor pengembang turun dari waktu ke waktu, tetapi poin saya di atas adalah cukup nyaman untuk memiliki toko untuk aplikasi bisnis.

Sebagai seseorang yang memiliki banyak aplikasi di Microsoft Store, termasuk toko untuk bisnis, saya dapat memberi tahu Anda bahwa penerbitan ke toko Microsoft telah menjadi jauh lebih baik dalam beberapa bulan terakhir. Sertifikasi untuk pembaruan rutin terkadang terjadi secepat beberapa jam. Pedoman toko juga cukup mudah untuk dipenuhi.

@yaichenbaum Itu pasti bagus untuk diketahui. Ketika saya menerbitkan (2 tahun yang lalu atau lebih), itu jauh lebih sulit. Ya, Anda perlu menandatanganinya sendiri - sebenarnya, Anda membeli sertifikat, dan menandatanganinya sebagai bagian dari proses "Terbitkan". Jadi setelah Anda mengaturnya, Anda bisa melupakannya.

@riverar Ketika saya menerbitkan (2 tahun yang lalu atau lebih), saya ingat Anda perlu memesan nama, dan kemudian Anda harus menunggu sesuatu yang akan digunakan MS untuk menandatangani aplikasi Anda (yang saya maksud, dengan sertifikat - > yang akan dikeluarkan MS untuk Anda).