Bisakah kita berbicara tentang dukungan untuk tipe data nullable dalam kontrol dan nilai default? Sebagai contoh ada DatePicker yang mengembalikan DateTimeOffset dan CalendarDatePicker yang mengembalikan DateTimeOffset?.

• Mengapa salah satu dari ini dapat dibatalkan sementara yang lain tidak? Apakah ini karena DatePicker dikembangkan menggunakan API sebelumnya dalam kerangka waktu Windows 8?
• Haruskah kita mempertimbangkan untuk menambahkan properti konfigurasi ke allow/not-allow null dalam kontrol?
• Haruskah properti DefaultValue dipertimbangkan untuk kontrol baru seperti NumberBox, haruskah NaN disimpan sebagai default, atau haruskah kita beralih ke nullable double dengan default null?
• Apakah ada batasan WinRT/OS XAML dengan mengembalikan dan mendukung nilai nullable yang akan mencegah pembuatan properti Value NumberBox menjadi nullable? Jika demikian, bagaimana CalendarDatePicker diterapkan?
• Ini terkait langsung dengan diskusi NumberBox di #1721 dan #1708

Juga, apa peta jalan untuk memperbaiki masalah terbuka pada NumberBox yang tidak bergantung pada WinUI 3.0? Akan sangat bagus untuk mulai menggunakan kontrol ini di sekitar WinUI 2.4 daripada harus menunggu lebih lama. Ini belum sepenuhnya matang menurut saya dan saya tidak nyaman memasukkan ini ke dalam aplikasi produksi.

Ide lain yang menarik untuk didiskusikan Saya bertanya-tanya tentang: Apa kebijakan Microsoft tentang melanggar perubahan sekarang karena WinUI 3.0 akan menjadi open source?

Di masa lalu, Microsoft hampir tidak pernah membuat perubahan besar. Ini umumnya merupakan hal yang baik sampai semua kekacauan menumpuk setelah beberapa (atau 10) tahun. Ini juga bukan standar untuk proyek sumber terbuka. Misalnya, pada akhirnya ListBox harus dihapus untuk ListView dan MessageDialog dihapus untuk ContentDialog, dll. Saya yakin ada banyak pembersihan kecil yang lebih baik di API juga.

Saya tahu bisnis membenci perubahan -- untuk alasan yang bagus. Juga HARUS ada pengganti drop-in yang relatif mudah (setara secara fungsional) yang tersedia untuk membuat porting ke API baru menjadi mudah. Ini perlu dievaluasi berdasarkan kasus per kasus dan keputusan dibuat.

Saya bertanya-tanya apakah kami dapat membuat rilis utama (WinUI 4.0 misalnya) sebagai memungkinkan perubahan yang melanggar. Ini akan memungkinkan proyek untuk terus berkembang tanpa harus hidup dengan semua kesalahan masa lalu. Pada dasarnya, Microsoft telah memutuskan untuk melakukan ini dengan .NET 5 dengan mendasarkannya pada .NET Core dan menjatuhkan apa yang merupakan .NET Framework penuh.

Ini mungkin bagus untuk didokumentasikan setelah didiskusikan.

Berdasarkan kemajuan yang dibuat sejak panggilan terakhir, kapan tim secara realistis berpikir WinUI 3 akan siap untuk dirilis:

• Build 2020 (Apr-Mei)
• Ignite 2020 (Okt-Nov)
• ~ 2021

Juga, seberapa tergantung pekerjaan Anda pada tim .NET yang menyusun solusi AOT baru dan .NET 5?

Terakhir, apakah ada tekanan di sisi Windows untuk menyiapkannya untuk rilis Windows10X dan/atau sebelum itu bagi pengembang untuk membuat aplikasi khusus?

Akankah ada/haruskah ada alat untuk dengan mudah mengonversi proyek WinUI 2.X ke WinUI 3.0 (karena melakukan ini secara manual mungkin banyak pekerjaan untuk proyek besar)?

Gajah di dalam ruangan - WinRT (#1856)

Gajah di dalam ruangan - WinRT (#1856)

Model aplikasi non-sandbox akan datang - yang akan berjalan dengan cara yang sama seperti WPF (termasuk Win32 API), tetapi dengan akses ke WinRT API modern, dan UI dan kontrol open source dengan XAML baru yang berjalan di Direct X 12.

Model aplikasi non-sandbox akan datang - yang akan berjalan dengan cara yang sama seperti WPF (termasuk Win32 API), tetapi dengan akses ke WinRT API modern, dan UI dan kontrol open source dengan XAML baru yang berjalan di Direct X 12.

Wow. Wah Wah!!!!

Itu luar biasa! Apakah kita memiliki ETA untuk ini, apakah akan dibahas dalam panggilan?

Ini sangat luar biasa!

Model aplikasi non-sandbox akan datang - yang akan berjalan dengan cara yang sama seperti WPF (termasuk Win32 API), tetapi dengan akses ke WinRT API modern, dan UI dan kontrol open source dengan XAML baru yang berjalan di Direct X 12.

Wow. Wah Wah!!!!

Itu luar biasa! Apakah kita memiliki ETA untuk ini, apakah akan dibahas dalam panggilan?

Ini sangat luar biasa!

Itu adalah hal pertama yang kami pelajari tentang WinUI. ETA adalah untuk tahun ini, saya menduga tanggal yang pasti akan diberikan di //Build/ - tetapi jangan ragu untuk bertanya selama panggilan.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo Lihat peta jalan WinUI . Lihat juga https://github.com/microsoft/microsoft-ui-xaml/issues/1045 untuk info lebih lanjut (seperti templat proyek VS).

@mdtauk @Felix-Dev Saya akan membaca ulang dokumen itu. Saya ingat menanyakan ini sebelumnya - selama saya dapat dengan mudah menggunakan win2d dari aplikasi saya (non-kotak pasir), saya akan lebih dari senang!

@jesbis Maaf untuk pertanyaan noob - bagaimana saya bergabung dengan panggilan?

Kami sedang menyiapkan info untuk panggilan besok hari ini - saya akan memposting petunjuknya dalam beberapa jam.

Keterlambatan karena ini pertama kalinya kami menggunakan sistem siaran baru - setelah ini semoga lebih lancar dan siap lebih awal

Saya baru saja memiliki pemikiran yang menarik (bagi saya).

Melirik streaming langsung ASP.NET Community Standup hari ini, pada dasarnya saya melihat 4 pengembang MS melakukan streaming livecoding, meskipun itu lebih merupakan demo teknologi. Saya juga sesekali mendengarkan @csharpfritz di Twitch yang melakukan penuh pada sesi pengkodean langsung.

Jadi pemikiran saya adalah - setelah WinUI 3 dirilis dan basis kode (atau sebagian besar) semuanya open source, apakah ada anggota tim yang siap untuk sesekali menyiarkan langsung beberapa pekerjaan mereka di WinUI?

Ini akan menjadi peluang bagus untuk mengembangkan eksposur WinUI, membantu orang menjelajahi basis kode dengan santai, dan pertanyaan dapat diajukan sesekali. ~Saya tidak akan merekomendasikan penuh pada keterlibatan obrolan sepanjang waktu karena itu akan sangat kontraproduktif, tetapi mungkin T&J sesekali.

Saya tidak tahu apa kebijakan MS tentang hal semacam itu, terutama selama hari kerja. Akan menarik untuk mendengar pikiran Anda.

Ini link live streaming YouTube untuk besok!

https://youtu.be/MXTVqgB4rW0

Terima kasih untuk semua komentar dan pertanyaan selama ini! Kami akan mencoba untuk mendapatkan semuanya, atau melacak untuk tindak lanjut jika kami tidak punya waktu.

Apakah ada sesuatu dalam panduan tentang kinerja / fps ui? Salah satu keluhan terbesar yang saya miliki dengan Windows 10 modern adalah bahwa pada mesin seperti Surface Book Anda mendapatkan kinerja yang buruk pada tampilan DPI tinggi, menjadi lebih buruk ketika Anda menggabungkan transparansi dan monitor tambahan. Mungkin di luar jangkauan dari apa yang mungkin, tetapi apakah ada pertimbangan di sini tentang seberapa lancar dan baik kinerjanya, terutama dalam kondisi ini?

Harap pertimbangkan untuk meningkatkan prioritas jendela tanpa bingkai/transparan (ala https://github.com/microsoft/microsoft-ui-xaml/issues/1247). Ini adalah pemblokir adopsi WinUI untuk aplikasi, seperti milik kami .

cc: @crutkas

Harap pertimbangkan untuk meningkatkan prioritas jendela tanpa bingkai/transparan (ala #1247). Ini adalah pemblokir adopsi WinUI untuk aplikasi, seperti milik kami .

cc: @crutkas

Ini mungkin memerlukan elemen Jendela Tingkat Atas yang ditambahkan ke WinUI Xaml dengan properti, mirip dengan WPF. #1323

Mempelajari lebih lanjut tentang 'masa depan windowing' untuk WinUI akan menyenangkan - ada banyak permintaan terkait yang setidaknya bagus untuk didiskusikan/ditangani.

Mungkin sudah pernah ditanyakan sebelumnya.

Bagi saya, selalu menjadi masalah penggunaan kembali kode.
Ini mengarah pada dua pertanyaan:

1. Apakah dukungan .NET Core 3 dan C# 8.0 akan segera hadir?
2. Apakah kita akan melihat langkah selanjutnya dari tim UWP/WinUI untuk mempermudah dalam mengembangkan aplikasi Uno Platform?

Satu lagi, kapan kita akan melihat bit yang hilang dari WPF didukung di UWP?

Mungkin sudah pernah ditanyakan sebelumnya.

Bagi saya, selalu menjadi masalah penggunaan kembali kode.
Ini mengarah pada dua pertanyaan:

1. Apakah dukungan .NET Core 3 dan C# 8.0 akan segera hadir?
2. Apakah kita akan melihat langkah selanjutnya dari tim UWP/WinUI untuk mempermudah dalam mengembangkan aplikasi Uno Platform?

Satu lagi, kapan kita akan melihat bit yang hilang dari WPF didukung di UWP?

Kode .NET Core harus bekerja pada keduanya, jadi aplikasi WPF hanya perlu mengubah UI Xaml dan kode UI.

Aplikasi UWP harus bekerja dengan baik dengan perubahan namespace untuk WinUI 3.0 - keluar dari kotak pasir mungkin perlu lebih banyak pekerjaan, detailnya masih belum diketahui.

Bit WPF yang hilang belum dikonfirmasi, tetapi saya membuat masalah tentang itu. #719

@weitzhandler

Meskipun tidak didukung secara resmi dan tidak semua fitur C# 8 akan berfungsi, Anda sudah dapat menggunakan sebagian besar C# 8 dengan WinUI/UWP. Lihat di sini .

Saya melakukan ini dan tidak mengalami masalah apa pun. "Anggota antarmuka default dan Indeks dan rentang" tampaknya menjadi satu-satunya bit yang hilang, meskipun saya belum mencoba semuanya.

Hanya memperkuat apa yang kmgallahan katakan tentang penggunaan C# 8. Saya telah menggunakan banyak fitur baru, tetapi sangat menginginkan Anggota Antarmuka Default, yang belum diimplementasikan.

Terima kasih.
Jika saya masih dapat menambahkan, tipe csproj lama juga agak mengganggu.

@jesbis

Saya baru saja membuka masalah ini di Galeri Kontrol XAML. Itu bisa menjadi sesuatu untuk didiskusikan selama panggilan jika Anda mau.

Terima kasih, kami akan mencoba menjawab semua pertanyaan!

Apakah ada sesuatu dalam panduan tentang kinerja / fps ui?

@ryvanvel kami memiliki beberapa panduan kinerja di sini:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

Dan beberapa posting blog dan video lain yang mungkin membantu, misalnya:

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

Bug ini telah dengan Windows 10 sejauh yang saya ingat, saya harap ini akan ditangani lebih cepat: https://github.com/microsoft/microsoft-ui-xaml/issues/597

Sayangnya saya tidak bisa menyetel tepat waktu, apakah akan ada rekaman?

Sunting: rekaman panggilan dapat ditemukan di sini: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis disini :

Ini link live streaming YouTube untuk besok!
https://youtu.be/MXTVqgB4rW0

Mengikuti tautan YT, sepertinya baru akan dimulai pada akhir jam ini, satu jam lebih lambat dari waktu reguler, apakah itu benar?

@weitzhandler Waktu mulai ada di bagian atas pos. Ini juga hanya panggilan ke-3, jadi "biasa" adalah peregangan.

@weitzhandler Saya cukup yakin ketiga panggilan sejauh ini dijadwalkan untuk dimulai pada jam 9 pagi waktu Pasifik.

Terima kasih dua dan maaf untuk mengganggu. Sampai jumpa lagi.

Saya ingin tahu apakah WebView2 didukung Chromium juga akan mengekspos acara seperti WebResourceRequested dari WebView , untuk memungkinkan pengembang memfilter permintaan web individual. Saya sangat mengandalkan fitur khusus itu di salah satu aplikasi saya dan saya bertanya-tanya apakah itu masih ada dengan kontrol baru, dan bekerja dengan cara yang sama.

Terima kasih teman-teman untuk semua kerja keras! 😄🚀

Apakah akan ada alat untuk menghasilkan PDF? Win2D sudah memiliki banyak alat luar biasa, kemampuan untuk menghasilkan PDF dari CanvasRenderTarget akan menjadi tambahan yang bagus.

tidak mengerti - bagaimana cara menginstal vsix? download dimana?

Mungkin hanya saya, tapi saya kecewa dengan panggilan hari ini. Harap sertakan lebih banyak orang teknis. PM harus menjaga agar diskusi tetap fokus dan bergerak sesuai jadwal tetapi mendelegasikan tanggapan kepada para ahli (seperti yang dilakukan lebih banyak menjelang akhir).

Saya kira semua orang dalam panggilan ini adalah pengembang dan kami perlu mengetahui dan mendiskusikan detailnya. PM berfokus pada topik yang sangat mendasar dan tidak dapat masuk ke detailnya. Misalnya, diskusi di awal panggilan tentang dokumentasi/WebView/ProgressRing bagus dalam konsep tetapi sangat mendasar, saya pikir itu tidak berguna bagi kami. Kami telah menggunakan XAML selama bertahun-tahun/dekade dan Anda berbicara kepada audiens ahli (penting untuk menyesuaikan presentasi dengan audiens).

@SavoySchuler Mengutip Anda pada dasarnya mengatakan, beri tahu kami bagaimana kami menggunakan kontrol, termasuk perusahaan kami, dan aplikasi kami. Anda membutuhkan ini untuk memisahkan kebutuhan materi vs bagus untuk dimiliki. Ini membantu Anda memprioritaskan sumber daya pada fitur. Anda perlu memikirkan hal ini secara berbeda untuk dua hal:

1. Fitur -- Dalam hal ini apa yang Anda katakan sebagian besar benar
2. Bug/Masalah -- Dalam hal ini, tidak, Anda tidak perlu komunitas memberikan contoh untuk membantu memprioritaskan. Saat mengirimkan produk apa pun, kualitas adalah prioritas nomor 1 Anda. Kami memberi tahu Anda bug dan Anda berkata, ya, itu bagus untuk dimiliki. Buktikan Anda perlu memperbaikinya. Ini bug. Mungkin Anda tidak pernah mengirimkan aplikasi ke konsumen? Hal-hal kecil yang salah sama sekali mempengaruhi citra dan persepsi Anda yang merupakan bagian paling berharga dari sebuah perusahaan. Industri Aplikasi sangat kompetitif.

Setelah bug dilaporkan oleh komunitas, Anda harus menjadwalkannya untuk diperbaiki. Hentikan pengiriman kontrol yang tidak lengkap tanpa rencana untuk memperbaikinya. Ini mulai terdengar sangat akrab – itulah yang terjadi dengan UWP bertahun-tahun yang lalu.

Dalam panggilan itu, saya memunculkan windowing dua kali dan disebutkan bahwa:

• ini sebenarnya sedang dikerjakan untuk WinUI 3 (meskipun masalah dibekukan https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• proyek Pelacakan Fitur (diperbarui kemarin) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) hanya melacak barang-barang WinUI 2 ???

Bisakah kita mendapatkan kejelasan di sini? Apakah ada lokasi lain untuk melihat backlog WinUI 3? Sangat penting untuk tujuan perencanaan bahwa kita tahu apa yang akan datang dan apa yang tidak. Terima kasih!

@SavoySchuler @jesbis dan seluruh tim WinUI yang cantik, saya pribadi ingin mengucapkan terima kasih atas kerja keras dan upaya besar Anda dan memberi tahu Anda betapa bersyukurnya saya karena membuat WinUI begitu luar biasa dan juga untuk menjawab semua pertanyaan saya.

Terima kasih banyak untuk semua orang yang bisa mendengarkan!

Dan sekali lagi maaf untuk masalah audio dan Tim - kami pikir kami mengidentifikasi masalah perangkat keras dan mudah-mudahan semuanya akan beres untuk bulan depan.

Rekaman itu sekarang juga ditayangkan langsung bagi siapa saja yang tidak dapat hadir.

Kami sedang mencari melalui pertanyaan dan akan mencoba untuk mendapatkan apa pun yang kami lewatkan di utas ini.

Beberapa pertanyaan mengejar:

Apakah akan ada alat untuk menghasilkan PDF?

@MuziburRahman

Kami tidak akan punya waktu untuk mencapai ini untuk WinUI 3.0 RTM tetapi kami melacak ini di backlog dengan #672 - jangan ragu untuk menambahkan komentar pada masalah itu tentang bagaimana Anda akan menggunakannya!

cara install vsixnya gmn? download dimana?

@hannespreishuber

Petunjuk penggunaan WinUI 2.x untuk aplikasi produksi ada di sini: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

Instruksi WinUI 3.0 Alpha untuk menginstal dan mencoba vsix ada di sini:
https://aka.ms/winui/alpha

Mungkin hanya saya, tapi saya kecewa dengan panggilan hari ini. Harap sertakan lebih banyak orang teknis. PM harus menjaga agar diskusi tetap fokus [...] Kami telah menggunakan XAML selama bertahun-tahun/dekade dan Anda berbicara kepada audiens ahli (penting untuk menyesuaikan presentasi dengan audiens).

@robloo terima kasih atas umpan baliknya tentang ini. Kami dapat menyertakan lebih banyak pengembang dan melakukan lebih mendalam pada topik tertentu untuk panggilan mendatang jika itu menarik bagi semua orang - kami tidak ingin mencobanya untuk panggilan pertama karena sudah lama dan kami ingin melakukan tangkapan umum- ke atas.

Kami juga memiliki umpan balik di masa lalu yang terkadang kami terlalu teknis dan terlalu mendalam karena banyak audiens belum terlalu akrab dengan WinUI - jadi kami mencoba untuk menyeimbangkan umpan balik itu juga.

Juga, jika perlu diperhatikan: banyak PM kami di tim platform pengembang sangat teknis dan memiliki pengalaman menulis kode produksi untuk platform utama dan aplikasi nyata. Beberapa dari mereka sebelumnya adalah pengembang penuh waktu di Microsoft dan perusahaan lain. Kami juga masih menulis kode sepanjang waktu sebagai PM, itu bukan satu-satunya fokus kami

Terakhir, tentang bug dan kualitas: kualitas sangat penting bagi kami dan kami menghabiskan banyak waktu untuk bug, pengujian, dan infrastruktur kualitas. Anda dapat melihat rasio perbaikan kualitas vs. fitur baru di log komit untuk WinUI 2, dan setelah itu open source Anda akan dapat melihat hal yang sama untuk WinUI 3. Yang mengatakan, tidak ada basis kode utama yang bebas bug dan kami selalu harus menyeimbangkan prioritas bisnis.

Jika kontrol tampak tidak lengkap maka silakan lakukan masalah terbuka untuk mereka.

Dalam panggilan itu, saya memunculkan windowing dua kali dan disebutkan bahwa:
ini sebenarnya sedang dikerjakan untuk WinUI 3 (meskipun masalah dibekukan #1247)
proyek Pelacakan Fitur (diperbarui kemarin) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) hanya melacak barang-barang WinUI 2 ???
Bisakah kita mendapatkan kejelasan di sini? Apakah ada lokasi lain untuk melihat backlog WinUI 3? Sangat penting untuk tujuan perencanaan bahwa kita tahu apa yang akan datang dan apa yang tidak. Terima kasih!

@riverar bahwa papan proyek saat ini untuk WinUI 2 karena itu satu-satunya kode dalam repo saat ini.

Kami menggunakan label need-winui-3 untuk masalah yang harus menunggu WinUI 3 sebelum dapat ditangani dengan benar, tetapi kami belum memiliki pelacakan publik untuk pekerjaan WinUI 3 kami.

Kami akan terus memposting proposal fitur untuk item utama - seperti spesifikasi Chromium WebView di repo spesifikasi terpisah:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

dan setelah kami dapat membuka sumber terbuka WinUI 3 Xaml, kami dapat mulai memindahkan pelacakan ke GitHub, tetapi sebagian besar pelacakan item kerja sehari-hari kami secara realistis kemungkinan akan tetap internal melalui pengembangan 3.0 karena berbagai alasan (kami memiliki banyak dependensi OS pribadi untuk diurai, perlu berinteraksi secara dekat dengan tim pengembang komponen OS lainnya, dll.)

Saya dapat mengatakan bahwa sebagian besar saran fitur yang ditandai itu tidak akan ditangani untuk rilis 3.0 awal - area fokus utama kami adalah:

• mendapatkan WinUI dipisahkan dari OS dan dikirim secara terpisah
• sumber terbuka kerangka kerja Xaml
• menciptakan pengalaman pengembangan aplikasi desktop WinUI yang baik (penggunaan win32, pengemasan, windowing, dll.)
• mengaktifkan Windows 10X
• mengaktifkan .NET Core/5 + aplikasi WinUI

dan kami tidak ingin menunda atau mengacaukannya dengan mencoba melakukan banyak pengembangan fitur baru secara bersamaan.

Saat kami membuat kemajuan nyata di area besar seperti dukungan desktop/windowing, kami akan memposting proposal dan pembaruan ke repo.

dan setelah kami dapat membuka sumber terbuka WinUI 3 Xaml, kami dapat mulai memindahkan pelacakan ke GitHub, tetapi sebagian besar pelacakan item kerja sehari-hari kami secara realistis kemungkinan akan tetap internal melalui pengembangan 3.0 karena berbagai alasan (kami memiliki banyak dependensi OS pribadi untuk diurai, perlu berinteraksi secara dekat dengan tim pengembang komponen OS lainnya, dll.)

Apakah mungkin untuk mencantumkan item pekerjaan internal ini secara publik, meskipun item tersebut muncul sebagai entri kosong dengan beberapa nama umum seperti Masalah Internal ? Melihat perpindahan ini dari To Do, ke In Progress, dan to Complete - akan menunjukkan beberapa tingkat kemajuan untuk keseluruhan proyek.

Saya dapat mengatakan bahwa sebagian besar saran fitur yang ditandai itu tidak akan ditangani untuk rilis 3.0 awal - area fokus utama kami adalah:

• mendapatkan WinUI dipisahkan dari OS dan dikirim secara terpisah
• sumber terbuka kerangka kerja Xaml

Ini tentu saja inti dari upaya, tetapi dimungkinkan untuk memecahkan berbagai masalah atau masalah dengan implementasi saat ini, karena sedang dikeluarkan dari kode OS.

• menciptakan pengalaman pengembangan aplikasi desktop WinUI yang baik (penggunaan win32, pengemasan, windowing, dll.)
• mengaktifkan Windows 10X

Ini penting untuk mendapatkan yang benar, dan akan membutuhkan kedua hal ini ke tangan pengguna dan pengembang, dengan pikiran terbuka untuk menerima umpan balik. Ini juga akan sulit karena runtime aplikasi dan modal aplikasi tidak dimiliki oleh tim WinUI ini, sehingga memungkinkan umpan balik untuk memfilter kepada mereka yang bertanggung jawab, perlu diterapkan.

• mengaktifkan .NET Core/5 + aplikasi WinUI

Dukungan Asli saat ini hadir dalam bentuk kode C++, dan API Win32 - tetapi apakah ini berarti pengembang C# perlu menargetkan .NET? Akankah model aplikasi non-sandbox memungkinkan pengkodean C# tanpa .NET?

dan kami tidak ingin menunda atau mengacaukannya dengan mencoba melakukan banyak pengembangan fitur baru secara bersamaan.

Saat kami membuat kemajuan nyata di area besar seperti dukungan desktop/windowing, kami akan memposting proposal dan pembaruan ke repo.

Tanpa CoreWindow (yang hanya akan menjadi UWP di masa mendatang) - Windowing adalah salah satu hal yang perlu ada sejak hari pertama. WPF memiliki objek Window di XAML yang menangani kontrol, gaya visual, transparansi, dll. Ini menangani pengubahan ukuran, meminimalkan, dll. Kerangka kerja Win32 yang lebih lama memerlukan pengecatan permukaan secara manual yang bukan merupakan hal untuk UI XAML - jadi bagaimana celah ini dapat dijembatani ?

Ini bahkan sebelum kita sampai ke perangkat layar ganda, dan bagaimana model aplikasi non UWP dan pengaturan windowing akan beradaptasi dengan itu.

Apakah mungkin untuk mencantumkan item pekerjaan internal ini secara publik, bahkan jika item tersebut muncul sebagai entri kosong dengan beberapa nama umum seperti Masalah Internal?

Tujuan kami pasti untuk memindahkan proses kami (termasuk pelacakan masalah) ke open source selain kode.

Sebagai permulaan, kami memiliki pencapaian WinUI 3.0 untuk pelacakan tingkat tinggi dan saat kami memigrasikan kode WinUI 3 Xaml ke open source, kami juga akan membuka lebih banyak masalah "tingkat fitur" dalam pencapaian tersebut.

Namun itu tidak akan mencakup semua tugas dev harian WinUI 3.0 kami segera - untuk referensi, kami saat ini melacak pekerjaan dev terkait senilai ribuan hari untuk tahun 2020 dan kami belum siap untuk memindahkan semua pelacakan super-granular kami ke GitHub hari ini. Kami akan mencapainya seiring waktu, seperti yang kami lakukan dengan WinUI 2.

Jadi, kita akan mulai dengan masalah tingkat fitur (seperti yang telah dimulai sejauh ini - misalnya WebView) dan akan sepenuhnya memigrasikan proses kita ke GitHub dari waktu ke waktu.

Dukungan Asli saat ini hadir dalam bentuk kode C++, dan API Win32 - tetapi apakah ini berarti pengembang C# perlu menargetkan .NET? Akankah model aplikasi non-sandbox memungkinkan pengkodean C# tanpa .NET

Apakah Anda bertanya tentang .NET Native, atau tidak ada .NET sama sekali? Secara teknis saya pikir spesifikasi C# sebagai bahasa tidak bergantung pada .NET, tetapi saat ini kami tidak memiliki rencana untuk mentranspilasikan ke C++ atau semacamnya.

Tanpa CoreWindow (yang hanya akan menjadi UWP di masa mendatang) - Windowing adalah salah satu hal yang perlu ada sejak hari pertama. WPF memiliki objek Window di XAML yang menangani kontrol, gaya visual, transparansi, dll. Ini menangani pengubahan ukuran, meminimalkan, dll. Kerangka kerja Win32 yang lebih lama memerlukan pengecatan permukaan secara manual yang bukan merupakan hal untuk UI XAML - jadi bagaimana celah ini dapat dijembatani ?

@marb2000 sedang mengerjakannya dan akan dapat membagikan lebih banyak info jika tersedia.

Ini bahkan sebelum kita sampai ke perangkat layar ganda, dan bagaimana model aplikasi non UWP dan pengaturan windowing akan beradaptasi dengan itu.

Untuk lebih jelasnya, WinUI 3 tidak akan membawa semua desktop win32 ke platform lain seperti HoloLens: aplikasi dan API universal masih akan menjadi cara untuk menargetkan beberapa perangkat.

Diposting terlalu dini. Komentar lengkap:

@robloo - Saya ingin memulai dengan menyetujui banyak sentimen Anda dan saya menghargai Anda bersama kami melalui rasa sakit kami yang semakin besar. Saya sangat tercerai-berai dengan semua masalah teknis kami dan saya tidak menangani pertanyaan itu sebaik yang saya inginkan. Tolong izinkan saya untuk mencoba lagi di sini:

Piagam dan sumber daya

Saya tahu membahas topik seperti ini tidak akan pernah populer, tetapi saya percaya pada transparansi dan ingin berterus terang kepada Anda sebagai komunitas tentang tantangan yang kami hadapi sehingga Anda dapat menjadi bagian dari diskusi dalam membantu kami memutuskan bagaimana kami menyelesaikannya . Tantangan khusus ini berfokus pada pembagian waktu dan aset sumber daya. Ada tiga inisiatif utama yang dibagi tim kami:

1. Memajukan WinUI 2
2. Memberikan WinUI 3
3. Sumber terbuka WinUI 3

Seperti yang Anda ketahui, kami diarahkan dengan tegas menuju 2 dan 3 karena A) ini adalah tujuan yang digabungkan dan B) sumber terbuka WinUI berarti semua orang dapat berhenti diblokir oleh sumber daya tim kami yang terbatas karena WinUI akhirnya akan diberdayakan untuk menerima permintaan tarik komunitas.

Jika kita keluar terlalu maju pada tujuan 2 dan 3 ke titik di mana WinUI 2 berada di bawah-melayani anggota masyarakat, kita dapat memiliki percakapan itu dan kami terbuka untuk memprioritaskan. Ketahuilah bahwa menyelesaikan semua bug di backlog kami akan menunda rilis WinUI 3 ke pasar hingga ~6 bulan. Jika kami memprioritaskan 2 dan 3, yang tidak hanya membuka sumber WinUI tetapi juga memperluas relevansinya dengan basis besar pengembang Win32 kami, kami akan dapat membersihkan tumpukan bug _dan_ permintaan fitur dengan kekuatan komunitas sumber terbuka dan tim kami. perhatian penuh mendukung kami. Untuk itu, alasan kami saat ini adalah bahwa rencana pendekatan tidak hanya akan memajukan platform ini lebih cepat tetapi juga lebih komprehensif. Ketika saya meminta Anda untuk membantu kami memprioritaskan bug, pertanyaannya bukanlah "apakah mereka cukup penting untuk ditangani oleh tim kami?" tetapi sebaliknya "apakah ini lebih penting daripada open source WinUI lebih cepat?" Pada status quo, kami memiliki subset pengembang yang bekerja untuk memajukan prioritas 1 dan Anda dapat merasakan dampaknya dalam riwayat komitmen dan masalah aktif kami, tetapi mereka menghadapi kebutuhan untuk memprioritaskan dalam tujuan itu secara bersamaan. Gagasan "beri tahu kami betapa pentingnya ini bagi Anda" membantu kami menyaring kebutuhan (misalnya, produk saya diblokir dan saya tidak sabar menunggu WinUI 3) vs. basa-basi (misalnya, saya melihat kesalahan teknis ini tetapi tidak ada pengembangan yang ada diblokir di atasnya sehingga bisa menunggu WinUI 3).

Hal lain yang ingin saya katakan dengan jelas adalah bahwa semua pekerjaan untuk mengajukan bug WinUI 2, mengisi permintaan fitur, dll., _ tidak _ hilang dari kami. Saat WinUI 3 dirilis, kami akan memiliki bagian signifikan dari tim kami yang dibebaskan untuk kembali bekerja item yang memajukan platform selain memberdayakan komunitas untuk mengirimkan kode juga. Ini berarti saat ini kami sedang mempersiapkan backlog yang akan ditangani oleh kekuatan penuh tim kami dengan bantuan komunitas UWP kami yang ada dan, segera, juga Win32.

Satu hal tambahan yang harus diperhatikan adalah bahwa saat kami memigrasikan kode dari OS ke WinUI 3, kami mengambil langkah-langkah sederhana dan membersihkan kode di belakang di mana kami bisa. Ini berarti penambahan fitur dan perbaikan bug tertentu akan membutuhkan waktu dan usaha yang jauh lebih sedikit jika diselesaikan di WinUI 3.

Kotak Nomor

Fitur

Mari kembali ke NumberBox. Anda benar secara faktual dengan mengatakan V1 adalah bagian dari fitur yang diinginkan.
Fitur V1 yang direncanakan ditunda hingga V2 karena ketergantungan pada hal-hal seperti validasi input (yang dalam pratinjau di WinUI 3 alpha). Kami mencoba untuk melengkapi spesifikasi kami dengan mengakui semua yang kami pikir pantas menjadi V1 dalam spesifikasi (di sini) dan berencana untuk sepenuhnya memenuhi komitmen itu dengan rilis kontrol WinUI 3 V2.

Dengan merangkul semangat open source, keinginan saya (dan tolong beri tahu jika saya melakukan kesalahan dengan melakukan ini) adalah untuk sepenuhnya lebih suka merilis kode yang andal dan berguna secepat mungkin dan untuk membangun set fitur secara bertahap. Dalam aplikasi, ini berarti lebih memilih untuk merilis _mostly_ complete V1 kami di WinUI 2 dan menindaklanjutinya dengan rilis berfitur lengkap dengan validasi input yang kami bisa dengan WinUI 3.

Bug

Seperti yang dikatakan @jesbis , tidak ada basis kode yang bebas bug, tetapi kualitas adalah yang utama bagi kami. Kami berkomitmen untuk membersihkan bug dan memiliki subset tim yang bekerja untuk melakukan WinUI 2. Sampai upaya penuh tim kami dipersatukan kembali dengan rilis WinUI 3, ini akan bergerak lebih lambat dari yang diinginkan hati kami, tetapi kami masih bekerja jauh di itu. @jesbis mencatat, Anda dapat melihat rasio perbaikan kualitas vs. fitur baru di log komit untuk WinUI 2, dan setelah open source Anda akan dapat melihat hal yang sama untuk WinUI 3.

Saya tetap berkomitmen untuk membantu menyelesaikan bug ini dengan NumberBox dan saya menyisihkan sisa hari saya untuk menanggapi masalah terbuka, bug, dan pertanyaan di mana saya dapat menjadi aset. Saya akan menyisihkan satu hari minggu depan juga. Silakan kirimkan saya pertanyaan di Twitter atau terlibat dengan saya tentang hal itu di sini di repo.

Langkah selanjutnya

Bagi kami, open source adalah janji merangkul komunitas sebagai anggota tim seolah-olah mereka duduk di sini di kantor Redmond kami. Kami mendengar mendengarkan. Mari kita bicarakan keputusan ini bersama sehingga kita bisa fokus membangun hal-hal hebat sebagai satu tim besar. 🙂

Kami ❤️ WinUI

Dengan merangkul semangat open source, keinginan saya (dan tolong beri tahu jika saya melakukan kesalahan dengan melakukan ini) adalah untuk sepenuhnya lebih suka merilis kode yang andal dan berguna secepat mungkin dan untuk membangun set fitur secara bertahap. Dalam aplikasi, ini berarti lebih memilih untuk merilis V1 kami yang paling lengkap di WinUI 2 dan menindaklanjutinya dengan rilis berfitur lengkap dengan validasi input yang kami bisa dengan WinUI 3.

Ini bisa saja saya, tetapi saya merasa bahwa meskipun penting untuk mengirimkan kode secepat mungkin, ada beberapa jenis masalah yang harus diselesaikan sebelum mengirim apa pun, misalnya #1846 adalah sesuatu yang harus ditangani sebelum mengirim V1 dan di sana mungkin beberapa lainnya juga.

@yaichenbaum saya bisa memilih kata-kata saya lebih baik di sana. 🙂

Jika AD adalah fitur yang _harus dimiliki_ dan EH adalah fitur yang _baik untuk dimiliki_, prioritas saya adalah mengeluarkan AD dan menambahkan EH secara bertahap sesuai kemampuan.

Alasan kami melakukan pementasan pada cabang pratinjau dengan mitra validasi adalah untuk menangkap bug seperti #1846 sebelum kontrol didorong ke rilis stabil. Maaf kami menjatuhkan bola yang satu ini, saya akan bekerja dengan @teaP ASAP untuk melihat seberapa cepat kami dapat menyelesaikan ini! 🙂

Pada satu titik dalam panggilan itu disebutkan bahwa aplikasi WinUI akan memungkinkan kotak pasir melalui AppDomain.

Dapatkah seseorang berbicara tentang bagaimana WinUI 3.0+ akan memposisikan Kemampuan vs. AppDomain untuk isolasi aplikasi dan kontrol sumber daya?

Juga, yang terakhir saya tahu untuk .Net Core, dukungan penuh untuk AppDomain tidak terjadi.

Mungkin saya kehilangan kontak, tetapi apakah Anda mengatakan .Net 5 akan memiliki dukungan penuh AppDomain?

Terima kasih telah mengatur panggilan ini hari ini!

Dapatkah seseorang berbicara tentang bagaimana WinUI 3.0+ akan memposisikan Kemampuan vs. AppDomain untuk isolasi aplikasi dan kontrol sumber daya?

Maaf jika tidak jelas dalam panggilan tetapi saya berbicara tentang AppContainer , bukan AppDomain.

Ah, baiklah, terima kasih atas penjelasannya Jesse.

Pertama-tama terima kasih @SavoySchuler dan @jesbis (dan semua tim WinUI lainnya) untuk mengatur panggilan komunitas hari ini! Meskipun ada beberapa kesulitan teknis, panggilan ini sangat mendalam !!!

Seperti yang disebutkan @jesbis, ada masalah dalam melacak alat dan fitur yang diminta untuk WinUI 3.0 . Apakah lebih baik untuk membagi permintaan alat konversi WinUI 2.x ke 3.0 menjadi masalah terpisah untuk pelacakan yang lebih mudah? Juga apakah sudah ada rencana? Apakah ada rencana untuk membuat alat ini open source sehingga pengembang lain dapat membantu mengembangkannya?

Pertanyaan lain yang lebih umum (yang juga ditujukan untuk anggota tim non WinUI lainnya), adalah tentang berkontribusi. Apakah ada kendala saat ini yang menghalangi orang untuk berkontribusi? Apakah panduan memulai yang lebih baik untuk kontributor membantu?

Menurut pendapat saya, jika Anda mulai berkontribusi pada proyek, Proyek VS mungkin sedikit berlebihan, dan tidak ada banyak dokumentasi mengenai cara mengembangkan, proyek uji mana yang harus digunakan untuk apa, dll...

Mungkin perbaikan di bidang itu akan memudahkan orang untuk berkontribusi

Bagaimana lapisan rendering WinUI 3.0 dilakukan? Apakah langsung menggunakan D3D11, D2D, abstraction layer atau apa? Apakah itu memiliki lapisan rendering perangkat lunak atau menggunakan D3D WARP untuk itu?

@chingucoding

Saya akan mengulangi poin yang baru saja saya buat di sini :

• Tidak menggunakan lang selamanya
• Tidak tahu berapa banyak perubahan kode yang terjadi di latar belakang untuk rilis WinUI 3 yang akan menimpa perubahan yang dibuat hari ini
• Tidak ada akses ke banyak kode sumber yang akan dibutuhkan dan/atau sangat membantu dalam mengatasi masalah

Sunting: Saya akan memberikan contoh. #1555 dan #1849 tampaknya merupakan masalah utama dengan kontrol inti (TextBox) yang mencegah input dan pemilihan teks saat melakukan banyak tugas.

Mereka berada di urutan teratas dalam daftar masalah penting yang harus diselesaikan, tetapi saya tidak tahu harus mulai dari mana. Saya juga tidak tahu apakah kode yang saya inginkan/perlu untuk melakukan debug tersedia.

@SavoySchuler

Jika kita terlalu maju pada tujuan 2 dan 3 ke titik di mana WinUI 2 kurang melayani anggota komunitas, kita dapat melakukan percakapan itu dan kita terbuka untuk memprioritaskan ulang. Ketahuilah bahwa menyelesaikan semua bug di backlog kami akan menunda rilis WinUI 3 ke pasar hingga ~6 bulan.

Saya pasti mengerti. Namun, NumberBox sedikit berbeda di sini dalam pikiran saya dan saya tentu tidak mengatakan bahwa kita harus fokus pada semua bug. Saat ini saya hanya akan berbicara dalam konteks NumberBox. Meskipun tentu ada beberapa masalah mencolok lainnya yang perlu ditangani.

NumberBox adalah kontrol yang baru dikembangkan untuk WinUI 2.3, bukan kontrol lama yang harus diterima semua orang saat ini. Mengapa kita tidak melakukan ini dengan benar untuk memulai? Ini adalah ujian lakmus dari model pengembangan baru.

Jika AD harus memiliki fitur dan EH bagus untuk memiliki fitur, prioritas saya adalah mengeluarkan AD dan menambahkan EH secara bertahap sesuai kemampuan.

Saya sepenuhnya setuju dengan Anda di sini. Tetapi Anda harus memahami perbedaan antara fitur dan bug. Saya khawatir Anda hanya memikirkan sumber daya/tenaga kerja untuk Microsoft. Namun, apakah Anda menganggap pengembang aplikasi menghabiskan waktu berjam-jam untuk mengatasi bug dalam kontrol? Jauh lebih efisien untuk memperbaiki hal-hal ini di sumbernya dan juga sangat membantu persepsi platform/perkakas.

Hal lain yang ingin saya katakan dengan jelas adalah bahwa semua pekerjaan untuk mengajukan bug WinUI 2, mengisi permintaan fitur, dll., tidak akan hilang dari kami. Saat WinUI 3 dirilis, kami akan memiliki bagian signifikan dari tim kami yang dibebaskan untuk kembali bekerja item yang memajukan platform selain memberdayakan komunitas untuk mengirimkan kode juga.

Microsoft memiliki rekam jejak yang sangat buruk dalam merilis perangkat lunak yang tidak lengkap dan kemudian beralih ke teknologi terbaru dan terhebat berikutnya sebelum memiliki kesempatan untuk menyelesaikan yang terakhir. Maafkan aku karena meragukan janjimu.

Mari kembali ke NumberBox. Anda benar secara faktual dengan mengatakan V1 adalah bagian dari fitur yang diinginkan.
...Dengan merangkul semangat open source, keinginan saya (dan tolong beri tahu jika saya melakukan kesalahan dengan melakukan ini) adalah untuk sepenuhnya lebih suka merilis kode yang andal dan berguna secepat mungkin dan untuk membangun set fitur secara bertahap.

Benar-benar pada halaman yang sama dengan Anda dalam hal fitur. Bug berbeda. Anda perlu mengatasi bug secara berbeda dari fitur dan memberikan lebih banyak sumber daya kepada mereka. Tampaknya buruk untuk merilis kontrol baru seperti NumberBox dan kemudian mengatakan Anda tidak dapat melakukan sumber daya untuk memperbaiki bug hingga satu tahun dari sekarang.

Saya meminta Anda untuk mengatasi bug di V1 dari kontrol yang tidak bergantung pada WinUI 3.0. Beberapa cukup mendasar dan yang lain adalah kesalahan mencolok dalam desain (seperti NaN menabrak data terikat dua arah). Setelah Anda berkomitmen untuk merilis fitur/kontrol, Anda harus segera bekerja untuk menutup bug. SELALU ada bug ketika perangkat lunak memiliki rilis luas pertama, Anda hanya perlu merencanakan sumber daya untuk melakukan perbaikan bug cepat V2 (seperti kami pengembang aplikasi lainnya). Karena kami setuju bahwa kualitas adalah prioritas utama, harap perbaiki masalah berikut dengan NumberBox sebelum melanjutkan ke hal lain.

1708 - Teks placeholder mutlak diperlukan dengan segala bentuk penggunaan kontrol dan salah satu fitur dasar yang sudah ada dalam spesifikasi. Jika ini memang telah diperbaiki untuk NaN, kita harus menutupnya. Dukungan nol adalah topik yang berbeda di bawah ini.

1721 - Masalah besar dengan UWP adalah dukungan yang tidak lengkap untuk pengikatan data dalam kontrol tertentu. Banyak pengembang aplikasi berinvestasi dalam desain MVVM bertahun-tahun yang lalu dan kemudian mencoba melompat ke kontrol UWP menemukan pengikatan data hanya didukung sebagian. Ini adalah masalah besar dan tidak dapat diterima mengingat betapa mendasarnya MVVM bagi praktik terbaik Microsoft. Tim perkakas pengembang windows yang lama tidak akan pernah mendukung ini - ini adalah pemikiran Windows/asli di sini.

1839 - Hal-hal dasar di sini. Ini hanyalah bug dasar dalam template kontrol dan HARUS diperbaiki. Tidak ada alasan.

1846 - Kami memiliki masalah ini di banyak kontrol lain sebelumnya. Mengapa tidak ada daftar periksa rilis yang menguji ini sekarang? Sekali lagi, hal-hal dasar yang perlu diperbaiki. Ini memengaruhi kegunaan semua aplikasi yang menggunakan kontrol ini.

1852, #1853, #1854 - Sekali lagi, ini tidak terlalu rumit dan hanya terlewatkan pada implementasi pertama. Namun, itu adalah persyaratan hukum untuk mendukung aksesibilitas dalam perangkat lunak yang dijual di wilayah tertentu atau dikembangkan untuk pemerintah. Sebagai platform, Anda harus segera memperbaikinya agar pengembang aplikasi dapat menggunakan kontrolnya. Sekali lagi, saya tidak perlu memperdebatkan hal semacam ini dengan Anda, ini hal yang mendasar.

Satu hal tambahan yang harus diperhatikan adalah bahwa saat kami memigrasikan kode dari OS ke WinUI 3, kami mengambil langkah-langkah sederhana dan membersihkan kode di belakang di mana kami bisa. Ini berarti penambahan fitur dan perbaikan bug tertentu akan membutuhkan waktu dan usaha yang jauh lebih sedikit jika diselesaikan di WinUI 3.

Memahami pada tingkat tinggi. Namun, memperbaiki masalah di atas tidak akan menunda WinUI 3.0 selama 6 bulan. Mereka juga tidak bergantung pada WinUI 3.0 untuk ditangani (kecuali berpotensi untuk # 1721). Anda menetapkan preseden berbahaya dengan melepaskan NumberBox dan kemudian tidak menggunakannya untuk menutup bug putaran pertama. Anda seharusnya sudah mempelajari pelajaran ini dengan UWP itu sendiri.

Mungkin perbaikan di area itu akan memudahkan orang untuk berkontribusi

Akan senang untuk berkontribusi. Tidak suka bekerja dengan C++/WinRT dan tentu saja tidak merasa memenuhi syarat untuk menyentuh basis kode seperti yang saya lihat. Jika kontrol dikelola C# Anda akan memiliki lebih banyak kontribusi. Saya mengerti mengapa arsitekturnya seperti itu, tetapi salah satu konsekuensinya adalah kontribusi komunitas yang lebih sedikit. Kami bukan pengembang sistem di sini, kami adalah pengembang aplikasi pengguna akhir.

RE: berkontribusi:

Pertanyaan lain yang lebih umum (yang juga ditujukan untuk anggota tim non WinUI lainnya), adalah tentang berkontribusi. Apakah ada kendala saat ini yang menghalangi orang untuk berkontribusi? Apakah panduan memulai yang lebih baik untuk kontributor membantu?
Menurut pendapat saya, jika Anda mulai berkontribusi pada proyek, Proyek VS mungkin sedikit berlebihan, dan tidak ada banyak dokumentasi mengenai cara mengembangkan, proyek uji mana yang harus digunakan untuk apa, dll...
Mungkin perbaikan di area itu akan memudahkan orang untuk berkontribusi

Tidak ada yang bisa menghentikan orang untuk berkontribusi pada WinUI 2, yang merupakan basis kode saat ini dalam repo. Jika ada masalah WinUI 2 yang ingin Anda atasi, beri tahu kami dan kami dapat menyerahkannya kepada Anda!

Kami memiliki banyak item yang ditandai dengan masalah pertama yang baik dan bantuan yang diinginkan jika ada yang ingin membantu dengan item yang seharusnya (relatif) mudah untuk memulai

Untuk perbaikan bug Anda cukup membuka PR. Jika ini adalah fitur baru yang utama, maka kami juga memiliki sedikit proses untuk meninjau masalah terlebih dahulu untuk memastikan proposal tersebut cocok untuk WinUI.

Saya sepenuhnya setuju panduan kontributor bisa lebih baik dan sulit untuk memulai - Saya baru-baru ini menjalani latihan mencoba mengikutinya untuk mengimplementasikan fitur baru ( RadialGradientBrush ) dan menemukan bahwa itu bisa menggunakan banyak peningkatan - sekarang ada di saya todo list untuk meningkatkan panduan.

Saya akan memberikan contoh. #1555 dan #1849 tampaknya merupakan masalah utama dengan kontrol inti (TextBox) yang mencegah input dan pemilihan teks saat melakukan banyak tugas.
Mereka berada di urutan teratas dalam daftar masalah penting yang harus diselesaikan, tetapi saya tidak tahu harus mulai dari mana. Saya juga tidak tahu apakah kode yang saya inginkan/perlu untuk melakukan debug tersedia.

Itu masih perlu diprioritaskan (dikategorikan) oleh pemilik dev kami (karenanya label "needs-triage" - saat ini saya sedang menindaklanjuti mengapa mereka belum melakukannya, maaf) tapi saya berharap itu karena TextBox tidak ada WinUI 2 mereka harus menunggu WinUI3.

Setelah mereka diprioritaskan, mereka harus menerapkan label need-winui-3 yang menunjukkan bahwa mereka harus menunggu WinUI 3 sebelum kami dapat mengatasinya.

Setelah WinUI 3 adalah open source maka siapa pun akan dapat membantu menyelesaikan masalah itu juga.

Tidak suka bekerja dengan C++/WinRT dan tentu saja tidak merasa memenuhi syarat untuk menyentuh basis kode seperti yang saya lihat. Jika kontrol dikelola C# Anda akan memiliki lebih banyak kontribusi.

Kita tahu bahwa C++ adalah penghalang yang lebih tinggi daripada C#, tetapi rencananya adalah bahwa WinUI akan tetap menjadi platform C++.

Proyek hebat lainnya untuk berkontribusi adalah Windows Community Toolkit yang lebih mudah untuk berkontribusi karena C# dan memiliki beberapa persyaratan santai.

Kami bekerja dengan pengelola dan sering menggunakan Community Toolkit untuk menginkubasi kontrol baru yang akhirnya bermigrasi ke platform Xaml (yang memang melibatkan implementasi ulang di C++).

Apakah WinUI memerlukan C++/CX? Jika demikian sepertinya ini adalah masalah untuk Win32 dan target masa depan lainnya?

Bagaimana lapisan rendering WinUI 3.0 dilakukan? Apakah langsung menggunakan D3D11, D2D, abstraction layer atau apa? Apakah itu memiliki lapisan rendering perangkat lunak atau menggunakan D3D WARP untuk itu?

Render kerangka kerja WinUI Xaml terutama diimplementasikan pada mesin komposisi Windows 10 . API lapisan komposisi juga akan menjadi bagian dari WinUI 3.

Pada akhirnya itu umumnya berarti rendering yang dipercepat perangkat keras menggunakan Direct3D, Direct2D dan DirectWrite, dengan rendering perangkat lunak dalam beberapa kasus yang masuk akal.

Anda juga dapat menyertakan konten DirectX yang dibuat khusus menggunakan API interop.

Apakah WinUI memerlukan C++/CX? Jika demikian sepertinya ini adalah masalah untuk Win32 dan target masa depan lainnya?

Tidak - platform WinUI ditulis dalam C++ tetapi aplikasi Anda tidak harus begitu!

Dengan WinUI 2 hari ini Anda dapat membuat aplikasi UWP menggunakan .NET (C#, VB.NET) atau C++.

Dengan WinUI 3, tujuan kami adalah Anda dapat membuat aplikasi yang menggunakan UWP dan/atau win32 API menggunakan .NET 5, atau C++ yang akan datang.

@jesbis Saya pikir Anda mungkin sedikit salah memahami maksud pertanyaan saya.

1) Saya tahu WinUI ditulis dalam C++ namun apakah ada kode WinUI yang hanya memerlukan ekstensi Windows VC++/CX? Jika memang memerlukan ekstensi CX, saya melihat ini mungkin menyebabkan masalah portabilitas jika WinUI ingin memperluas ke platform lain. Ini mungkin menyulitkan tim UNO untuk mengadopsi kode misalnya.

2) Tentang sistem rendering. Beberapa hal di sini.

2.a) Apakah "Lapisan visual" merupakan API abstraksi yang dihapus cukup jauh dari DirectX API sehingga nantinya dapat mendukung backend Vulkan misalnya? (Saya yakin pertanyaan ini akan terjawab ketika sumbernya dirilis tetapi saya hanya ingin tahu)

2.b) Pertanyaan saya tentang rasterisasi perangkat lunak lebih pada baris: Akankah WinUI 3.0 mendukung rendering perangkat lunak penuh (bukan hanya rendering teks atau apa-tidak)? Terkadang perangkat lunak berbagi layar memiliki masalah dengan aplikasi yang dipercepat GPU (setidaknya dengan D3D9 / WPF) dan memaksa rendering perangkat lunak untuk memperbaiki masalah dalam situasi tersebut). Atau jika aplikasi dijalankan dalam VM tanpa GPU perangkat keras.

Instruksi WinUI 3.0 Alpha untuk menginstal dan mencoba vsix ada di sini:
https://aka.ms/winui/alpha

lakukan itu dengan Edge New tautan unduhan tidak muncul, ulangi dengan chrome- unduh di sana

lakukan itu dengan Edge New tautan unduhan tidak muncul, ulangi dengan chrome- unduh di sana

@hannespreishuber tautan unduhan harus ada di halaman terakhir survei. Maksud Anda survei tidak berfungsi di Chromium Edge tetapi berhasil di Chrome?

tautan unduhan harus ada di halaman terakhir survei. Maksud Anda survei tidak berfungsi > di Chromium Edge tetapi berhasil di Chrome?

melakukan survei pada keduanya - tetapi halaman terakhir berbeda, mungkin salahku.

melakukan survei pada keduanya - tetapi halaman terakhir berbeda, mungkin salahku.

Oke, terima kasih - kami menguji survei di kedua versi Edge dan tampaknya berhasil, jadi jika ada yang mengalami masalah dengan unduhan, beri tahu kami, dan laporkan juga masalah di Edge jika konten halaman dirender berbeda dari Chrome (Setelan > Bantuan & Umpan Balik > Kirim Umpan Balik)

Saya tahu WinUI ditulis dalam C++ namun apakah ada kode WinUI yang hanya memerlukan ekstensi Windows VC++/CX? Jika memang memerlukan ekstensi CX, saya melihat ini mungkin menyebabkan masalah portabilitas

@zezba9000 kami telah menerapkan kontrol dan fitur WinUI 2 (kode baru saat ini dalam repo) menggunakan C++/WinRT yang merupakan standar C++17, tetapi sisa WinUI 3 adalah basis kode yang jauh lebih besar dan lebih tua yang saat ini masih akan bergantung pada WRL dll. Kami tidak berfokus pada portabilitas saat ini tetapi terbuka untuk mendiskusikannya di masa mendatang.

Apakah "Lapisan visual" merupakan API abstraksi yang dihapus cukup jauh dari DirectX API sehingga nantinya dapat mendukung backend Vulkan misalnya? (Saya yakin pertanyaan ini akan terjawab ketika sumbernya dirilis tetapi saya hanya ingin tahu)

Kami juga tidak berfokus pada portabilitas saat ini untuk lapisan visual. Ada beberapa sambungan longgar antara lapisan Visual dan API DirectX (tidak termasuk implementasi) tetapi sebagian besar diabstraksikan. Juga, untuk memperjelas tentang open source: target awal kami untuk kode sumber terbuka dan proses pengembangan sehari-hari kami adalah kerangka kerja Xaml, yang tidak akan menyertakan sumber terbuka pada lapisan visual saat ini.

Pertanyaan saya tentang rasterisasi perangkat lunak lebih seperti: Akankah WinUI 3.0 mendukung rendering perangkat lunak penuh (bukan hanya rendering teks atau apa-tidak)? Terkadang perangkat lunak berbagi layar memiliki masalah dengan aplikasi yang dipercepat GPU (setidaknya dengan D3D9 / WPF) dan memaksa rendering perangkat lunak untuk memperbaiki masalah dalam situasi tersebut). Atau jika aplikasi dijalankan dalam VM tanpa GPU perangkat keras.

Ya, rendering melalui berbagi layar, di VM, dll. Semua harus berfungsi. Untuk sebagian besar konten seharusnya tidak ada perbedaan yang terlihat. Jika Anda melihat melalui kode WinUI 2 di repo, Anda mungkin juga melihat penggunaan API yang kami gunakan untuk menanyakan apakah efek tertentu didukung/"cepat" saat runtime dan kembali ke rendering efek tertentu yang lebih sederhana dalam beberapa kasus, tetapi aplikasi seharusnya 'tidak perlu melakukan sesuatu yang khusus untuk mendukung rendering perangkat lunak saat menggunakan kontrol dan fitur platform default.

Saya sepenuhnya setuju dengan Anda di sini. Tetapi Anda harus memahami perbedaan antara fitur dan bug. Saya khawatir Anda hanya memikirkan sumber daya/tenaga kerja untuk Microsoft. Namun, apakah Anda menganggap pengembang aplikasi menghabiskan waktu berjam-jam untuk mengatasi bug dalam kontrol? Jauh lebih efisien untuk memperbaiki hal-hal ini di sumbernya dan juga sangat membantu persepsi platform/perkakas.

Setuju 100% - Saya bahkan tidak ingin mengingat jumlah jam yang saya habiskan untuk mengatasi bug dari UWP/WinRT.

Jesse,

Saya terutama prihatin tentang mengembangkan aplikasi perusahaan. Saat ini saya menggunakan WinUI 3.0 Alpha untuk membangun bukti konsep untuk menunjukkan bagaimana Xaml, GPRC, beberapa jendela dan multi-threading benar dapat menawarkan bisnis dan pengguna bisnis pengalaman aplikasi yang lebih produktif.

Mengapa? Karena kami membutuhkan alternatif untuk aplikasi berbasis browser/layar kecil. Saya memiliki banyak hal untuk dikatakan tentang topik itu, tetapi saya akan berciuman di sini.

Apa yang saya inginkan dari tim WinUI dan memang Microsoft adalah merangkul dan mendukung pembuatan aplikasi desktop untuk bisnis.

Ada 3 alasan utama aplikasi web diadopsi di perusahaan dengan begitu cepat - dukungan lintas platform, keamanan, dan kemudahan penerapan Untuk menjadi alternatif yang layak, aplikasi desktop memerlukan jawaban atas pertanyaan tersebut.

Tampaknya sebagian besar industri pengembangan perangkat lunak berfokus pada pengiriman aplikasi untuk browser dan/atau faktor bentuk seluler/tablet.

Aplikasi perusahaan berjalan di workstation dengan banyak CPU, ukuran layar, memori, penyimpanan, grafik, dan bandwidth jika dibandingkan dengan aplikasi "mobile first". Pengguna aplikasi LOB ini dapat terlibat selama berjam-jam pada suatu waktu. Kami membutuhkan panduan desain aplikasi untuk mengatasi faktor-faktor ini.

Ada dimensi lain dalam aplikasi perusahaan yang tidak banyak dibahas – umur panjang dan keahlian. Sekali lagi, banyak yang ingin dikatakan di sini, tetapi saya akan meringkasnya. Bisnis menginvestasikan uang dalam membangun aplikasi dan mereka berencana untuk menggunakan aplikasi tersebut untuk waktu yang "lama". Ini berarti teknologi yang mendasarinya perlu didukung selama beberapa dekade. Saya ingin melihat WinUI menjadi teknologi berumur panjang berikutnya untuk menggantikan Win32/MFC dan WinForms.

Departemen TI terus-menerus berjuang untuk menemukan SE dengan keahlian yang tepat. Teknologi web telah membuat ini semakin menantang. Saya ingin melihat tumpukan baru C#, Xaml, dan SQL (C#XS) yang mengidentifikasi fokus pada pembuatan aplikasi desktop.

Ada juga poin kecil yang ingin saya sampaikan sehubungan dengan gaya. Aplikasi perusahaan WinUI harus memerlukan gaya minimal "di luar kotak" agar berfungsi. Juga, dan ini mungkin diarahkan langsung ke Lancar, tetapi jangan sembunyikan kontrol (seperti bilah gulir). Pengguna bisnis memiliki banyak layar real-state dan tidak peduli seberapa "cantik" UI jika mereka tidak tahu ada lebih banyak di halaman.

Kami membutuhkan kontrol datagrid yang kuat (gratis). Tidak bisa cukup menekankan itu.

Saya memiliki lebih banyak ide untuk dibagikan jika Anda tertarik, tetapi saya akan berhenti di sini dan meringkas:

• Microsoft perlu menyediakan solusi pengembangan aplikasi desktop yang komprehensif.
• WinUI/Fluent perlu memenuhi kebutuhan pengguna bisnis seperti fungsi/formulir, UX untuk desktop, contoh kode/template proyek yang mendemonstrasikan banyak jendela, multi-threading sejati, validasi data, halaman "seperti Formulir".
• Microsoft perlu menjelaskan bahwa mereka menawarkan WinUI untuk membangun aplikasi LOB bisnis yang sangat produktif dan berumur panjang. Juga, mengapa .Net 5 + WinUI TIDAK akan menjadi DLL lagi.
• Jelaskan bahwa WinUI adalah pengganti Win32/MFC dan WinForms.
• Dorong C#XS sebagai keahlian untuk TI.
• (Gratis) Datagrid

Semoga Anda menemukan ini bermanfaat.

@robloo Tenang - tidak perlu debat! Saya berkomitmen untuk memperbaiki kesalahan ini di komentar awal saya dan itu masih berlaku. Saya pikir saya juga melakukan kesalahan sebelumnya dengan terus menggeneralisasi. Mari kita bicara tentang bug yang Anda daftarkan. Dua diajukan tepat sebelum liburan besar kami di sini (saya tidak dapat berbicara untuk @teaP , tetapi saya offline hampir sepanjang bulan Desember) dan kami mengalami perubahan manajemen di sisi teknik kami (selamat @ranjeshj!). Ini bukan alasan dan saya mohon maaf karena kedua bug ini tidak ditangani lebih cepat selama perubahan dan ketidakhadiran ini. Yang lain yang tercantum di sini semuanya telah diajukan dalam 10 hari terakhir atau kurang.

Untuk memilikinya menunjukkan bahwa NumberBox khususnya adalah pelakunya dan yang ini menumpuk membantu kita menjadi strategis dengan waktu kita, jadi terima kasih untuk membantu kita melihat ini. Saya telah menjadwalkan waktu awal minggu depan untuk meninjau daftar bug NumberBox kami yang luar biasa dengan pengembang NumberBox @teaP dan manajer teknik kami (yang baru diberi judul) @ranjesh sehingga kami dapat menyelesaikannya secara kolektif secepatnya.

@SavoySchuler Terima kasih!

@SavoySchuler , sepertinya Anda terjebak dalam posisi sulit untuk memilih antara:

a) Perbaiki bug di WinUI 2.x, dan tunda rilis WinUI 3.0
atau
b) Serahkan WinUI 2.x ke komunitas, dan persembahkan sumber daya internal untuk WinUI 3.0 untuk mencapai tanggal rilis paling awal

Saya kira banyak pengguna WinUI 2.x yang ada ingin Anda memperbaiki bug terlebih dahulu, karena mereka saat ini terpengaruh, tetapi mungkin ini dapat dikurangi dengan menawarkan harapan yang realistis kapan WinUI 3.0 _bisa_ tersedia, dengan sumber daya yang cukup ( dan dengan asumsi WinUI 3.0 akan menawarkan perbaikan tambahan pada 2.x).

Secara pribadi, saya tidak ingin melihat penundaan dalam rilis WinUI 3.0, dan berpikir masuk akal bahwa komunitas terlibat dalam memecahkan masalah yang kritis di WinUI 2.x (setelah semua, ini adalah open source). Beberapa orang memiliki harapan bahwa karena ini adalah proyek Microsoft, mereka harus melakukan semua pekerjaan. Sayangnya itu tidak realistis, dan juga bukan cara kerja proyek open source lainnya.

@jesbis , menarik mendengar tentang Lapisan Visual sehubungan dengan WinUI 3.0. Apakah Anda mengatakan bahwa untuk rilis awal, WinUI 3.0 akan memiliki ketergantungan pada kelas Windows.UI.Composition ? Apakah ada kemungkinan untuk menambahkan lebih banyak fitur ke dalam OS untuk mendukung Lapisan Visual sebelum ekstraksi ke WinUI 3.0?

Untuk referensi, hal-hal yang saya minati:

• Win32 "AppContainer" model. Kami sepenuhnya kompatibel dengan kotak pasir di OS lain, tetapi kami ingin akses ke API "modern"
• Lapisan Visual ( Windows|Microsoft.UI.Composition )
• DXGI Tukar rantai di lapisan visual / SwapChainPanel
• API manajemen jendela (AppWindow dll)

@infoequipt terima kasih atas catatan mendalamnya! Pasti membantu. @marb2000 untuk visibilitas

itu menarik mendengar tentang Lapisan Visual berkaitan dengan WinUI 3.0. Apakah Anda mengatakan bahwa untuk rilis awal, WinUI 3.0 akan memiliki ketergantungan pada kelas Windows.UI.Composition?

@MarkIngramUK tidak, maaf atas kebingungan - poin saya sebelumnya hanya tentang open source.

Microsoft.UI.Composition akan menjadi bagian dari WinUI 3 dan Microsoft.UI.Xaml akan bergantung padanya. Itu sudah terjadi dengan WinUI 3 Alpha.

Kami sedang bekerja menuju sumber terbuka Xaml, yang berarti kode kerangka kerja Xaml akan tinggal di repo ini dan tim teknik kami akan melakukan semua pekerjaan sehari-hari kami di Xaml di GitHub ke depan. Namun paket Microsoft.UI.Composition yang bergantung pada Xaml akan tetap dikembangkan secara internal dan hanya diperbarui dalam bentuk biner.

Terima kasih atas klarifikasinya @jesbis sangat dihargai. Metode distribusi apa yang akan Anda gunakan untuk ini? Kami adalah aplikasi lintas platform, jadi menggunakan CMake, dan memiliki ketergantungan pada Windows.UI.Composition, jadi saya ingin cara mudah membawa dll baru, lib, header, dll.

Apakah ada implikasi kinerja untuk mengekstraksi Lapisan Visual dari OS? Yaitu jika Anda hanya bergantung pada Lapisan Visual, apakah akan ada kerugian untuk memperbarui ke perpustakaan baru?

Apakah ada rencana untuk akhirnya membuka sumber Microsoft.UI.Composition?

@MarkIngramUK Saya sangat setuju dengan apa yang Anda katakan, dan apa yang dikatakan @SavoySchuler dalam tampilan 'gambaran besar'. Seperti yang Anda tunjukkan, lebih sulit bagi kami pengguna WinUI 2.0 untuk menerima bug karena kami memiliki aplikasi produksi sekarang. Kita perlu menemukan kompromi antara memperbaiki beberapa bug yang tidak akan menunda WinUI 3.0 dan juga menjaga WinUI 3.0 di jalurnya. Ada frustrasi tambahan bahwa NumberBox adalah kontrol baru yang tampaknya segera diabaikan -- dengan komentar bahwa Microsoft tidak akan kembali ke sana selama lebih dari setahun. Terlepas dari itu, saya tentu setuju WinUI 3.0 adalah prioritas dan tidak ingin ditunda dalam kapasitas yang signifikan.

Saya mungkin harus mengatakan bahwa saya menghargai semua pekerjaan yang dilakukan Microsoft di sini dan upaya mereka untuk lebih transparan dan komunikatif dengan arahan.

Metode distribusi apa yang akan Anda gunakan untuk ini? Kami adalah aplikasi lintas platform, jadi menggunakan CMake, dan memiliki ketergantungan pada Windows.UI.Composition, jadi saya ingin cara mudah membawa dll baru, lib, header, dll.

@MarkIngramUK akankah mengkonsumsi paket NuGet bekerja untuk Anda? Yaitu apa yang kita lakukan dengan WinUI 2.x dan WinUI 3 Alpha. Kami masih mengerjakan beberapa detail distribusi dengan tim Visual Studio. Saat ini WinUI 3 Alpha berisi binari Xaml dan Komposisi dalam 1 paket tetapi kami akan memisahkannya untuk mendukung Xaml sumber terbuka dan dapat membangun Xaml secara terpisah.

Apakah ada implikasi kinerja untuk mengekstraksi Lapisan Visual dari OS? Yaitu jika Anda hanya bergantung pada Lapisan Visual, apakah akan ada kerugian untuk memperbarui ke perpustakaan baru?

Tetap disini Patokan kinerja dan pekerjaan ada di peta jalan kami untuk akhir tahun ini jadi agak terlalu dini untuk memiliki angka apa pun.

Apakah ada rencana untuk akhirnya membuka sumber Microsoft.UI.Composition?

Ada di backlog kami untuk berpotensi dipertimbangkan tetapi kami tidak memiliki rencana untuk itu.

@MarkIngramUK jika saya bisa bertanya: manfaat apa yang Anda harapkan dari menjadi open source?

Komposisi dan kode rendering bisa menjadi sedikit membingungkan jadi saya ingin tahu apakah orang benar-benar tertarik untuk berkontribusi atau menggunakannya sebagai referensi.

lebih sulit bagi kami pengguna WinUI 2.0 untuk menerima bug karena kami memiliki aplikasi produksi sekarang. Kita perlu menemukan kompromi antara memperbaiki beberapa bug yang tidak akan menunda WinUI 3.0 dan juga menjaga WinUI 3.0 di jalurnya. Ada frustrasi tambahan bahwa NumberBox adalah kontrol baru yang tampaknya segera diabaikan -- dengan komentar bahwa Microsoft tidak akan kembali ke sana selama lebih dari setahun. Terlepas dari itu, saya tentu setuju WinUI 3.0 adalah prioritas dan tidak ingin ditunda dalam kapasitas yang signifikan.
Saya mungkin harus mengatakan bahwa saya menghargai semua pekerjaan yang dilakukan Microsoft di sini dan upaya mereka untuk lebih transparan dan komunikatif dengan arahan.

@robloo terima kasih! Kami benar-benar berusaha transparan dan senang mengetahui bahwa itu berharga

Hanya untuk mengulangi apa yang disebutkan Savoy, kami memiliki pengembang yang mengerjakan WinUI 2.x (seperti yang diharapkan dapat dilihat dari log PR juga) jadi kami pasti masih berinvestasi di WinUI 2 dan 3 secara paralel - hanya saja sebagian besar dari kami sumber daya ada di WinUI 3. Saya setuju tentang NumberBox khususnya yang membutuhkan perhatian dan pimpinan pengembang kontrol Xaml kami sedang menyelidikinya sekarang.

@robloo Kamu yang terbaik! Sekali lagi maaf atas kebingungannya - satu-satunya hal yang tunduk pada penundaan ~1 tahun yang disebutkan adalah mode validasi input tambahan NumberBox karena mereka diblokir pada pekerjaan validasi input lengkap kami yang dijadwalkan untuk 3.0. Jika tidak @teaP , @ranjeshj , dan saya akan berada di daftar bug NumberBox mulai minggu depan. 🙂

Saya pikir @jesbis menutupi semuanya!

@jesbis ,

@MarkIngramUK akankah mengkonsumsi paket NuGet bekerja untuk Anda? Yaitu apa yang kita lakukan dengan WinUI 2.x dan WinUI 3 Alpha. Kami masih mengerjakan beberapa detail distribusi dengan tim Visual Studio. Saat ini WinUI 3 Alpha berisi binari Xaml dan Komposisi dalam 1 paket tetapi kami akan memisahkannya untuk mendukung Xaml sumber terbuka dan dapat membangun Xaml secara terpisah.

Saya akan jujur, saya tidak begitu akrab dengan NuGet, tetapi melihat jawaban SO ini sepertinya hanya akan berfungsi jika Anda menggunakan CMake untuk menghasilkan file proyek VS, yang bukan cara kami biasanya bekerja (biasanya cukup buka folder , yang menggunakan Ninja sebagai generator). Sayang sekali Anda tidak dapat mengirimkan sumbernya, karena Anda juga dapat menggunakan vcpkg . Sebagai referensi, kami membangun semua pustaka dari sumber (yang menghindari potensi masalah ABI, terutama karena kami juga membangun dengan Clang/LLVM di Windows).

Apakah ada rencana untuk akhirnya membuka sumber Microsoft.UI.Composition?

Ada di backlog kami untuk berpotensi dipertimbangkan tetapi kami tidak memiliki rencana untuk itu.

Saya tertarik dengan hal ini, jadi saya ingin terlibat dalam diskusi jika / ketika itu terjadi.

@MarkIngramUK jika saya bisa bertanya: manfaat apa yang Anda harapkan dari menjadi open source?

Komposisi dan kode rendering bisa menjadi sedikit membingungkan jadi saya ingin tahu apakah orang benar-benar tertarik untuk berkontribusi atau menggunakannya sebagai referensi.

Pemikiran awal berkontribusi / berkembang (seperti yang saya sebutkan sebelumnya, kami memiliki ketergantungan pada Windows.UI.Composition, tetapi bukan Xaml Framework / UWP), meskipun berpikir keras, porting Layer Visual ke backend Vulkan atau Metal untuk lintas- platform mungkin menarik, tetapi saya hanya mempertimbangkannya secara harfiah selama 30 detik. Selain itu, sumber terbuka akan mengurangi kekhawatiran yang mengganggu untuk mengadopsi kerangka kerja lain yang pada akhirnya akan ditinggalkan oleh Microsoft dalam waktu beberapa tahun (aplikasi kami saat ini dibangun di WPF, aplikasi kami sebelumnya dibangun di MFC, kami memiliki komponen web menggunakan Silverlight, jadi , Anda mungkin melihat dari mana saya berasal dari sini ...).

Kotak Nomor

Halo semuanya! @teaP , @ranjeshj , dan saya mengerjakan semua item NumberBox kami yang terbuka hari ini.

• Kami sudah menutup beberapa.
• @teaP mengirimkan PR gabungan untuk beberapa lagi ( pemfilteran label di sini ).
• Kami memiliki tindakan yang diputuskan untuk sisanya (dengan pengecualian #1721) dan akan merespons dengan perbaikan secepatnya. #1721 membutuhkan lebih banyak pekerjaan pada kami untuk mendiagnosis jalur terbaik ke depan. Kami akan terus bekerja untuk menyelesaikan yang satu ini.

Terima kasih kepada semua orang untuk bekerja sama dengan kami. Kami ❤️ WinUI!

Apakah ada "kalender" untuk panggilan Komunitas WinUI? Mis: dalam bentuk kalender publik yang dapat kami tambahkan/integrasikan ke kalender live/google/* kami, untuk pembaruan otomatis detail panggilan.

Acara YouTube dijadwalkan sebelumnya sehingga Anda dapat menambahkan pengingat Google di sini di bawah " streaming langsung mendatang":

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

Kami juga memiliki undangan kalender .ics tetapi itu menyebabkan masalah bagi beberapa orang dan tidak ada cara untuk memperbaruinya sehingga kami menyerah untuk saat ini.