Expander sangat berguna dan saya telah menggunakan versi Windows Community Toolkit sejak ditambahkan. Saya tidak akan menemukan kembali roda terlalu banyak, hanya mem-porting kode dari toolkit akan sempurna untuk versi 1.0 menurut saya.

Contoh lain: ColorPicker dengan 'MoreButton' dapat menggunakan ini.

Terima kasih banyak telah mengirimkan proposal ini! Saya akan melakukan beberapa pengeditan, termasuk membedakan antara apa yang menurut saya adalah skenario Expander yang sebenarnya dan apa yang lebih seperti yang digunakan Flyout/MenuFlyout.

Saya telah memperbarui proposal ini untuk menyertakan detail lebih lanjut tentang ruang lingkup, API yang diusulkan, dan pertanyaan terbuka berikut.

• Apakah kita perlu mendukung ExpandDirection di Expander v1? Apakah ada skenario aplikasi umum di mana Expander perlu memperluas ke arah selain ke bawah?

Akan menyukai umpan balik tentang bagaimana ini cocok atau tidak sesuai dengan kasus penggunaan Anda untuk Expander!

Saya telah memperbarui proposal ini untuk menyertakan detail lebih lanjut tentang ruang lingkup, API yang diusulkan, dan pertanyaan terbuka berikut.

• Apakah kita perlu mendukung ExpandDirection di Expander v1? Apakah ada skenario aplikasi umum di mana Expander perlu memperluas ke arah selain ke bawah?

Akan menyukai umpan balik tentang bagaimana ini cocok atau tidak sesuai dengan kasus penggunaan Anda untuk Expander!

Itu memang tampak seperti fungsi dasar dari kontrol

Itu memang tampak seperti fungsi dasar dari kontrol

@mdtauk apakah Anda melihat ExpandDirection selain ke bawah menjadi skenario aplikasi yang umum? Contoh perilaku Expander yang saya lihat jauh lebih sering berkembang ke bawah - Saya pasti ingin Expander memiliki ExpandDirection tetapi apakah perlu di v1?

Ya, kita perlu memperluas arah. Ada banyak kasus untuk menggunakannya dan itu akan menjadi perubahan yang tidak perlu pada template kontrol setelah rilis v1 untuk menambahkannya. Expander API tidak banyak berubah sejak WPF dan proposal di sini sudah memiliki semua properti/peristiwa/metode yang diperlukan. Saya hanya akan menerapkan semuanya dalam satu kesempatan dan kita bisa menyelesaikannya dengan kontrol ini. Dari segi desain, UWP Community Toolkit membuat perubahan yang diperlukan untuk bekerja lebih baik dengan sentuhan. Saya pikir kita memiliki semua bagian dan tidak perlu menemukan kembali apa pun.

Sunting: Toolkit komunitas juga memiliki properti ContentOverlay . Itu mungkin sesuatu untuk dilewati di V1.

Ya, kita perlu memperluas arah. Ada banyak kasus untuk menggunakannya dan itu akan menjadi perubahan yang tidak perlu pada template kontrol setelah rilis v1 untuk menambahkannya.

@robloo Bisakah Anda menguraikan bagaimana ini akan menjadi perubahan yang melanggar? Pemahaman saya adalah kita dapat menghindarinya pecah dengan V1 memiliki ekspansi ke bawah, dan V2 dapat menambahkan ExpandDirection dan default ke bawah.

Itu memang tampak seperti fungsi dasar dari kontrol

@mdtauk apakah Anda melihat ExpandDirection selain ke bawah menjadi skenario aplikasi yang umum? Contoh perilaku Expander yang saya lihat jauh lebih sering berkembang ke bawah - Saya pasti ingin Expander memiliki ExpandDirection tetapi apakah perlu di v1?

Aplikasi obrolan yang memuat konten daftar baru dari bawah ke atas mungkin salah satunya.

Di luar esensi yang sangat mendasar:

• Apakah Runtuh
• AdalahMemperluas
• Diperluas
• Apakah Runtuh

Serta Diaktifkan

Hal inti berikutnya adalah ke mana harus memperluas.

• Perluas
• PerluasKe Bawah
• PerluasKiri
• PerluasKanan

Aplikasi obrolan yang memuat konten daftar baru dari bawah ke atas mungkin salah satunya.

@mdtauk Saya tidak sepenuhnya mengerti apa yang Anda maksud dengan contoh aplikasi obrolan ini - dapatkah Anda menjelaskannya?
Adapun properti - API yang diusulkan didasarkan pada WPF Expander jadi saya pikir IsExpanded dan ExpandDirection akan mencakupnya. Untuk apa IsEnabled digunakan - apakah ada skenario aplikasi di mana Anda ingin menonaktifkan Expander?

Contoh lain yang saya gunakan di masa lalu adalah properti sekunder yang dapat diedit yang biasanya harus disembunyikan. Ini ditampilkan di bagian bawah editor hanya ketika mengklik tombol 'opsi' dan expander terbuka ke atas. Ini benar-benar hanya sampai dengan desain yang Anda tuju. Ada banyak kasus yang berguna untuk memperluas arah yang berbeda dan tampaknya tidak perlu membatasi ini secara artifisial terutama ketika konvensi masa lalu begitu kuat. Saya tidak berpikir semua ini akan terlalu sulit dalam kontrol V1 terutama karena semua masalah telah diselesaikan di toolkit komunitas dan WPF.

@robloo Bisakah Anda menguraikan bagaimana ini akan menjadi perubahan yang melanggar? Pemahaman saya adalah kita dapat menghindarinya pecah dengan V1 memiliki ekspansi ke bawah, dan V2 dapat menambahkan ExpandDirection dan default ke bawah.

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander/Expander.xaml

Saya kira jika Anda sangat berhati-hati dalam mendesain templat dan status visual, Anda dapat membuatnya tidak pecah. Namun, untuk melakukan itu Anda benar-benar perlu merancang fungsionalitasnya sehingga Anda mungkin juga mengimplementasikannya. Ini semua cukup mendasar dan tidak ada alasan untuk rencana V2 sejak awal pada kontrol ini.

Saya tahu itu menarik untuk menemukan kembali roda. Tapi tolong simpan agar orang yang mem-porting aplikasi dari WPF ke WinUI dapat melakukannya tanpa apa pun kecuali perubahan kode yang mutlak diperlukan. WinUI perlu mulai memperbaiki beberapa kesalahan dengan UWP.

Untuk apa IsEnabled digunakan - apakah ada skenario aplikasi di mana Anda ingin menonaktifkan Expander?

@mdtauk Benar, ini perlu mendukung IsEnabled juga. Menonaktifkan kontrol adalah konvensi yang cukup kuat kapan pun ada kemungkinan input atau perubahan status. Tolong jangan buat kami membela itu.

Pada tangkapan layar di atas, keamanan windows memiliki expander untuk bagian antivirus serta menu navigasi kiri. Ini menunjukkan penggunaan expander yang sangat realistis di lebih dari satu arah yang perlu didukung oleh banyak aplikasi. Suara saya adalah untuk mendukung banyak arah di V1.

@robloo

Contoh lain yang saya gunakan di masa lalu adalah properti sekunder yang dapat diedit yang biasanya harus disembunyikan. Ini ditampilkan di bagian bawah editor hanya ketika mengklik tombol 'opsi' dan expander terbuka ke atas.

Bisakah Anda menguraikan dengan tangkapan layar atau aplikasi tertentu di mana ini terjadi sehingga saya dapat lebih memahami skenarionya? Saya dapat memikirkan editor di mana tombol opsi membuka sembulan dengan lebih banyak tombol, tetapi yang saya kenal dengan konten lain tidak didorong ke atas - perilaku sembulan/flyout daripada ekspansi.

Saya kira jika Anda sangat berhati-hati dalam mendesain templat dan status visual, Anda dapat membuatnya tidak pecah. Namun, untuk melakukan itu Anda benar-benar perlu merancang fungsionalitasnya sehingga Anda mungkin juga mengimplementasikannya. Ini semua cukup mendasar dan tidak ada alasan untuk rencana V2 sejak awal pada kontrol ini.
Saya tahu itu menarik untuk menemukan kembali roda. Tapi tolong simpan agar orang yang mem-porting aplikasi dari WPF ke WinUI dapat melakukannya tanpa apa pun kecuali perubahan kode yang mutlak diperlukan.

Saya setuju dengan Anda bahwa porting aplikasi dari WPF ke WinUI harus semulus mungkin! Dalam diskusi dengan tim WinUI, dikemukakan bahwa cakupan V1 untuk memperluas ke bawah akan mempersingkat waktu pengembangan dan membuat Expander tersedia untuk pengembang lebih cepat (karena skenario untuk Expander sejauh ini semuanya menurun), dan V2 yang direncanakan dapat menambahkan ExpandDirection segera setelah. (Saya akan mengedit pertanyaan terbuka untuk memiliki konteks tambahan ini) Inilah mengapa saya berharap untuk memahami jika ada kasus penggunaan khusus yang dimiliki pengembang untuk Expander non-bawah! 😄

Menonaktifkan kontrol adalah konvensi yang cukup kuat kapan pun ada kemungkinan input atau perubahan status. Tolong jangan buat kami membela itu.

Terima kasih telah menjelaskan ini, sangat masuk akal bahwa menonaktifkan perubahan status adalah fitur yang diinginkan untuk kontrol semacam ini!

Pada tangkapan layar di atas, keamanan windows memiliki expander untuk bagian antivirus serta menu navigasi kiri. Ini menunjukkan penggunaan expander yang sangat realistis di lebih dari satu arah yang perlu didukung oleh banyak aplikasi. Suara saya adalah untuk mendukung banyak arah di V1.

@JustABearOz Saya pikir menu navigasi kiri adalah NavigationView , sebenarnya. Saya setuju bahwa bagian antivirus adalah skenario Expander, dalam hal ini berkembang ke bawah. Ingin mengetahui kasus penggunaan khusus yang Anda miliki untuk Expander non-bawah!

@kat-y Oke, itu menghilangkan kebutuhan untuk kiri/kanan, tetapi 2 contoh di windows yang tampaknya diperluas yang dapat dengan mudah diterapkan ke aplikasi:
1: Tangkapan layar di atas dengan menu tindakan cepat. Cukup yakin itu meluas.
2: Di windows, kalender popup dari baki sistem memiliki bagian yang diperluas untuk menunjukkan agenda/janji.

Apakah mungkin untuk mendukung Atas/Bawah untuk V1 alih-alih hanya Turun?

1: Tangkapan layar di atas dengan menu tindakan cepat. Cukup yakin itu meluas.

@JustABearOz terima kasih banyak telah mengemukakan contoh-contoh ini! Untuk 1: Saya pikir ini adalah kasus tepi yang menarik - ekspansi 'ke bawah' dari 'tajuk' (tombol perluas), tetapi kontrol itu sendiri diposisikan di bagian bawah permukaan sehingga tajuk (dan konten yang diperluas) harus 'bergeser' ke atas (jika tidak, layar akan keluar!). Sepertinya cara yang baik untuk menangani memiliki item yang diperluas di 'bawah' aplikasi, apakah Anda setuju?

2: Di windows, kalender popup dari baki sistem memiliki bagian yang diperluas untuk menunjukkan agenda/janji.
Apakah mungkin untuk mendukung Atas/Bawah untuk V1 alih-alih hanya Turun?

Saya setuju dengan Anda, ini adalah skenario di mana header berada di bagian bawah area dan mengembang! Dalam hal ini expander kalender (dan popup secara keseluruhan) terikat ke taskbar - pernahkah Anda menemukan skenario di aplikasi di mana expander memiliki posisi terikat serupa yang memerlukan ekspansi ke atas?

@kat-y maksud saya jangan tersinggung tapi saya merasa kita harus menjelaskan kembali hal-hal yang diketahui 15 tahun yang lalu. Saya tidak mengerti mengapa Anda meminta kami untuk memberikan contoh arah perluasan dalam penggunaan dunia nyata. Saya berharap secara internal Anda harus mengambil ini untuk meninjau spesifikasi dan mempertahankannya kepada manajemen. Tapi penjelasannya bisa saja (1) Anda perlu memberdayakan pengguna untuk mencapai target desain mereka, bukan terserah Microsoft untuk mengatakan apa yang bisa/tidak mungkin dilakukan dengan kontrol, terserah pengembang/desainer aplikasi untuk menemukan apa yang terbaik untuk kasus penggunaan mereka (konsep penting untuk kontrol tanpa tampilan) (2) Yang terpenting, ini sama sekali bukan ide baru. Anda menyalin melalui API yang ada di area ini dan perlu menjaga kompatibilitas aplikasi. Sekali lagi, jika ini adalah ide baru, saya akan lebih memahami mengapa kita harus mempertahankannya -- ada baiknya untuk memastikan fitur berguna sebelum menginvestasikan waktu di dalamnya.

Selain dari header ada dua properti dalam kontrol ini dan jika C# saya bisa menulisnya dalam beberapa jam menggunakan basis WCT. Kami akan menghabiskan lebih banyak waktu hanya untuk membicarakannya daripada mengimplementasikannya seperti yang ada saat ini di WPF/WCT.

Terima kasih @robloo atas masukannya, saya menghubungi tim WinUI untuk membahas bagaimana kami dapat membuat proposal ini lebih kuat pada awalnya ketika mereka ada di perpustakaan pihak ketiga lainnya seperti Toolkit. Saya pasti berpikir itu harus menjadi bagian dari templat masalah untuk memanggil contoh yang ada.

FYI @ranjeshj @ryandemopoulos @stmoy

@robloo Terima kasih telah jujur ​​dengan saya! Saya memahami bahwa pengembang aplikasi harus dapat menentukan apa yang paling sesuai dengan kasus penggunaan mereka, dan kompatibilitas aplikasi itu penting. Saya berharap diskusi dengan @michael-hawker dan tim WinUI akan membantu kami bergerak maju secara produktif dalam scoping Expander!

Sebelumnya saya tidak memiliki contoh konkret dari Ekspander yang digunakan dalam arah non-bawah. Saya akan membawa contoh apa pun dari komunitas WinUI (termasuk flyout kalender yang ditunjukkan oleh @justABearOz ) dan semua yang saya pelajari dari Michael ke diskusi dengan Tim WinUI sebagai bukti untuk menjaga ExpandDirection di v1 dari Expander.

Saya telah memperbarui proposal dengan daftar kontrol Expander yang saya ketahui - beri tahu saya jika saya melewatkan sesuatu.

• WPF
• Toolkit Komunitas Windows
• UI Telerik
• Xamarin.Forms
• Syncfusion.XForms.Expander

Saya telah melihat kode sumber WPF dan kode sumber WCT. Saya yakin ini dapat diimplementasikan di WinUI dalam beberapa jam juga. Kontrol harus mengikuti implementasi WCT dari apa yang saya lihat meskipun properti ContentOverlay mungkin harus diganti namanya atau dikeluarkan dari V1.

WPF:
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/Themes/XAML/Expander.xaml
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/Expander.cs

WC:
https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander

Karena kedua sumber ini berasal dari Microsoft dan MIT berlisensi, mereka harus menjadi basis, jangan mulai dari nol. Formulir Xamarin tidak selaras dengan konsep WPF->WinUI jadi mungkin harus diabaikan (tidak ada fungsi tambahan juga). Solusi pihak ke-3 juga tidak memiliki ide baru yang inovatif dari apa yang saya lihat. Kontrol ini sebagian besar telah teruji oleh waktu.

@robloo Terima kasih telah jujur ​​dengan saya! Saya memahami bahwa pengembang aplikasi harus dapat menentukan apa yang paling sesuai dengan kasus penggunaan mereka, dan kompatibilitas aplikasi itu penting. Saya berharap diskusi dengan @michael-hawker dan tim WinUI akan membantu kami bergerak maju secara produktif dalam scoping Expander!

Sebelumnya saya tidak memiliki contoh konkret dari Ekspander yang digunakan dalam arah non-bawah. Saya akan membawa contoh apa pun dari komunitas WinUI (termasuk flyout kalender yang ditunjukkan oleh @JustABearOz ) dan semua yang saya pelajari dari Michael ke diskusi dengan Tim WinUI sebagai bukti untuk mempertahankan ExpandDirection di v1 dari Expander.

Nah, poin saya adalah seharusnya tidak ada terlalu banyak diskusi tentang ini. Saya memilih untuk menyuarakan frustrasi saya di sini karena kontrol ini adalah contoh sempurna. Kontrol pager baru atau kontrol remah roti memang membutuhkan lebih banyak pengawasan dan penting untuk mengikuti prosesnya. Namun, overhead dari proses besar terlihat di sini dan lagi, Anda akan menghabiskan lebih banyak jam kerja untuk mengerjakan dokumen dan diskusi yang tidak bernilai tambah yang hanya menerapkan kontrol dari WCT. Saya juga belum melihat tim WinUI menggunakan pekerjaan lain sebelumnya yang agak mengkhawatirkan. Tidak perlu merekayasa ulang template kontrol XAML.

Selamat datang di proyek WinUI @kat-y - Xaml memiliki sejarah panjang tetapi bisa sedikit aneh bagi mereka yang baru mengenalnya. Sementara WinUI adalah kesempatan untuk memikirkan kembali cara kerja, dalam hal ini, expander adalah kontrol yang relatif sederhana sehingga perpindahan sederhana dari WPF ke WinUI sudah cukup.

@robloo Saya tidak setuju dengan pernyataan Anda bahwa tidak perlu merekayasa ulang templat kontrol XAML. WPF AFAIR memiliki sejumlah elemen seperti krom yang tidak pada tempatnya di WinUI/Fluent.

Menangani Chevron dan ukuran target sentuh, serta menggunakan ukuran penskalaan font. Chevron harus mudah dilepas, atau ditambahkan.

Contoh ini memiliki chevron sesuai dengan teks.

Contoh ini tidak memiliki chevron sama sekali

Contoh ini memiliki sisi depan yang menghadap chevron

Adapun implementasinya, harus ada transisi animasi saat membuka dan menutup, kecuali jika pengguna telah mematikan animasi, maka itu hanya beralih status.

Adapun implementasinya, harus ada transisi animasi saat membuka dan menutup, kecuali jika pengguna telah mematikan animasi, maka itu hanya beralih status.

Saya baru saja akan bertanya tentang animasi. Haruskah ada cara untuk menonaktifkannya untuk kontrol, misalnya dalam skenario di mana animasi tata letak akan terlalu mahal? Tidak semua pengguna/pengembang menginginkan animasi untuk hal-hal seperti itu mungkin terasa sedikit tidak responsif atau tidak diinginkan (misalnya TreeView). Harus tidak memikirkan kembali kontrol untuk menyesuaikan titik itu mungkin lebih baik. Hal lain yang dapat disesuaikan adalah durasi animasi, dalam beberapa kasus animasi pendek lebih baik daripada yang lebih panjang.

Terima kasih untuk semua diskusi yang luar biasa. beberapa pemikiran

• Kami perlu memperbarui template seperti yang disebutkan @mdtauk untuk memperhitungkan desain baru serta peluang untuk mengurangi elemen/meningkatkan kinerja jika memungkinkan.
• IsEnabled diwarisi dari Control, jadi saya berharap itu berfungsi.

Adapun implementasinya, harus ada transisi animasi saat membuka dan menutup, kecuali jika pengguna telah mematikan animasi, maka itu hanya beralih status.

Saya baru saja akan bertanya tentang animasi. Haruskah ada cara untuk menonaktifkannya untuk kontrol, misalnya dalam skenario di mana animasi tata letak akan terlalu mahal? Tidak semua pengguna/pengembang menginginkan animasi untuk hal-hal seperti itu mungkin terasa sedikit tidak responsif atau tidak diinginkan (misalnya TreeView). Harus tidak memikirkan kembali kontrol untuk menyesuaikan titik itu mungkin lebih baik. Hal lain yang dapat disesuaikan adalah durasi animasi, dalam beberapa kasus animasi pendek lebih baik daripada yang lebih panjang.

Saya percaya beberapa kontrol memiliki properti Transition yang dapat ditugaskan. Jadi, jika storyboard non-animasi dimasukkan sebagai sumber daya, itu dapat diterapkan dan menanganinya tanpa memikirkan ulang.

Anda harus mengganti transisi ketika pengaturan sistem mematikan animasi.

UIElement.Transisi?
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions?view=winrt-19041

Juga dengan properti IsEnabled, harus ada status Disabled. Haruskah ada Disabled Expanded, dan Disabled Diciutkan, atau Disabled selalu diciutkan?

Hal menarik tentang animasi. Kami mematikan semua animasi dengan pengaturan sistem, tapi saya rasa kami tidak mengekspos tombol untuk mematikan animasi selain dengan re-templating saat ini.

Hal menarik tentang animasi. Kami mematikan semua animasi dengan pengaturan sistem, tapi saya rasa kami tidak mengekspos tombol untuk mematikan animasi selain dengan re-templating saat ini.

Saya yakin Anda dapat menambahkan Gaya yang menimpa koleksi Transisi dengan null jika Anda ingin mematikan animasi, dengan asumsi ada koleksi Transisi untuk ditimpa.

Termasuk ExpandTransition dan CollapseTransition , yang dapat menggunakan arah yang ditetapkan oleh properti kontrol - yang memungkinkan dev untuk mengatur transisi untuk masing-masing.

Saya menyukai idenya, tetapi saya rasa hari ini tidak ada cara untuk membuat transisi tema khusus yang akan membatasi kemampuan untuk menyesuaikan. Ini akan memungkinkan dengan mudah menonaktifkannya dengan menghapusnya.

Juga dengan properti IsEnabled, harus ada status Disabled. Haruskah ada Disabled Expanded, dan Disabled Diciutkan, atau Disabled selalu diciutkan?

Mengapa tidak mencerminkan kontrol TreeView di mana Anda dapat menggunakan properti IsExpanded dan IsEnabled untuk membuat kombinasi apa pun yang Anda butuhkan dari keduanya? Jika dinonaktifkan diperluas berfungsi paling baik dalam beberapa kasus, itu bisa dilakukan. Jika Anda perlu dinonaktifkan diciutkan, itu juga mungkin dengan cara ini.

@robloo Saya tidak setuju dengan pernyataan Anda bahwa tidak perlu merekayasa ulang templat kontrol XAML. WPF AFAIR memiliki sejumlah elemen seperti krom yang tidak pada tempatnya di WinUI/Fluent.

@mdtauk Nah, rekomendasi saya adalah kita "harus mengikuti implementasi WCT" di sini: https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander. Perubahan desain untuk beradaptasi dengan sentuhan dan antarmuka yang lebih modern telah dibuat. Tentu saja tidak ada yang bisa membuat desain sebaik Anda, jadi saya yakin ada ruang untuk perbaikan. Masih mengubah 'desain' tidak memerlukan rekayasa ulang template untuk mendukung semua arah perluasan. WCT harus menjadi dasar dan kemudian jika kita memiliki gaya baru untuk diterapkan, sangat baik, itu dapat dilakukan dengan cepat tetapi tidak dari awal.

@robloo Saya tidak setuju dengan pernyataan Anda bahwa tidak perlu merekayasa ulang templat kontrol XAML. WPF AFAIR memiliki sejumlah elemen seperti krom yang tidak pada tempatnya di WinUI/Fluent.

@mdtauk Nah, rekomendasi saya adalah kita "harus mengikuti implementasi WCT" di sini ...
Saya berasumsi Anda tidak bermaksud mengubah XAML versi WPF

Tapi saya masih berpikir tim desain WinUI perlu menyetujuinya dan variannya - jika hanya untuk mengonfirmasi spesifikasi untuk disertakan dalam toolkit figma

@kat-y Jika Anda baru dalam proyek ini, saya minta maaf jika saya terdengar kasar. Saya mendukung poin saya di atas tentang bagaimana kecepatan proyek dapat ditingkatkan di beberapa area yang tentunya dibutuhkan. Juga, bagaimana kita harus menggunakan apa yang telah dilakukan di masa lalu dan pertempuran yang sangat diuji selama 15 tahun terakhir. Tentu saja semua ini tidak ditujukan secara pribadi kepada Anda atau siapa pun. Ini adalah masalah umum 'mengembang' yang pernah saya lihat dengan Microsoft selama bertahun-tahun di mana tim harus lebih ramping dan seimbang untuk mendukung lebih banyak pengkodean/manajemen proyek yang lebih sedikit. Sebagus rencana tidak ada yang mengalahkan coba-coba sehingga kecepatan iterasi pada akhirnya menang.

@ranjeshj @michael-hawker Mengapa tidak menggunakan apa yang sudah dilakukan di toolkit komunitas? Ini bukan pertama kalinya tim WinUI mengambil pendekatan baru. Itu menduplikasi pekerjaan yang tidak perlu dan menyebabkan fragmentasi dalam kasus terburuk. Versi WCT sudah didasarkan pada ide-ide WPF dan membuat perubahan 'modern' yang diperlukan.

@ranjeshj @michael-hawker Mengapa tidak menggunakan apa yang sudah dilakukan di toolkit komunitas? Ini bukan pertama kalinya tim WinUI mengambil pendekatan baru. Itu menduplikasi pekerjaan yang tidak perlu dan menyebabkan fragmentasi dalam kasus terburuk. Versi WCT sudah didasarkan pada ide-ide WPF dan membuat perubahan 'modern' yang diperlukan.

Toolkit Komunitas dalam C# saya percaya, dan WinUI memerlukan kode C/C++.

Juga tim desain WinUI tidak mengatakan AFAIK dengan versi Toolkit, sehingga kebutuhan tim desain Windows dan Aplikasi mungkin memiliki kebutuhan khusus jika mereka ingin mengadopsi kontrol, atas solusi kustom mereka.

Toolkit Komunitas dalam C# saya percaya, dan WinUI memerlukan kode C/C++.

Menerjemahkan kode ke/dari C# & C++/WinRT relatif sepele. Khusus untuk Expander di mana saya sudah melihat kode https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander. Sebagian besar kompleksitas ada di XAML yang 1:1 dapat digunakan di WinUI selama tidak ada ekstensi WCT yang digunakan. Saya dapat mem-porting kode ini ke C++ sendiri jika diperlukan.

Juga tim desain WinUI tidak mengatakan AFAIK dengan versi Toolkit, sehingga kebutuhan tim desain Windows dan Aplikasi mungkin memiliki kebutuhan khusus jika mereka ingin mengadopsi kontrol, atas solusi kustom mereka.

Untuk poin-poin tertentu, ya. Namun, untuk fungsi kontrol umum saya harus tidak setuju. WCT akan membuat kita 95% selesai dan 100% selesai dalam fungsionalitas. Perubahan desain apa pun yang diterapkan di atas akan menjadi sepele.

@robloo Bisakah Anda menguraikan fungsi mana yang berbeda? API yang diusulkan di atas sangat cocok dengan WPF/WCT saat mencoba menjaga konsistensi dengan pola yang ada di WinUI.

@ranjeshj Kami mungkin tidak berada di halaman yang sama. Saya tidak menyarankan bahwa API yang diusulkan berbeda secara signifikan dari WCT atau WPF.

Disebutkan bahwa ExpandDirection mungkin tidak didukung di versi pertama dari kontrol ini. Itu sepertinya masalah bagi seorang Expander yang memiliki sejarah panjang dengan fungsi ini. Kemudian sepertinya kita harus membenarkan mengapa fitur ini dibutuhkan sama sekali.

Saya menyarankan untuk menggunakan WCT sebagai basis untuk mengimplementasikan ini dengan cepat dengan arah perluasan. Tidak perlu menemukan kembali roda karena hanya port C# -> C++ yang diperlukan (dan kode di belakang sangat kecil untuk ini) saat menyalin-menempel template XAML. Itu akan mengimplementasikan semua fungsionalitas yang kita perlukan dan menghindari kekhawatiran bahwa tidak ada cukup waktu untuk menambahkan ExpandDirection. Pendekatan ini akan memberi kita kontrol yang berfungsi penuh. Kemudian setiap perubahan desain/gaya dapat dilakukan di atas berdasarkan @mdtauk atau saran orang lain. Saya tidak mengerti (1) Mengapa ExpandDirection berpotensi di blok pemotongan untuk V1 (2) Mengapa jika waktu adalah batasan kami tidak menggunakan kode yang ada.

Ya frustrasi saya untuk pengembangan WinUI 3 secara umum tumpah ke beberapa tempat ini dan saya minta maaf untuk itu.

@robloo Ini bukan tentang sesuatu yang ada di blok pemotongan - tapi saya percaya orang-orang baru yang bergabung dengan tim ada di sana untuk menawarkan tampilan baru pada kontrol dan API ini untuk melihat mana yang merupakan prioritas terbesar - dan berpotensi menghapus cruft saat membawa kontrol baru, atau porting kontrol ke WinUI.

Saat memprioritaskan fitur apa yang penting untuk disertakan dalam V1, dan kemudian di V2, hanya properti dan perilaku inti dan esensial yang akan ada di sana, dan bukan hal-hal lama yang tidak umum digunakan.

Microsoft tampaknya menentukan fitur mana yang akan ditambahkan berdasarkan kebutuhan dan keinginan pelanggan - tidak hanya mencapai kesetaraan dengan kerangka kerja yang lebih lama.

Jadi ini bukan _membenarkan_, tetapi hanya mencoba memahami apa yang sebenarnya dilakukan pengembang dengan pola kontrol ini di UI mereka.
Fakta bahwa Windows Shell sendiri memiliki beberapa versi pola kontrol expander, akan menjadi alasan yang cukup jelas mengapa menyertakannya. Dan fakta bahwa setiap implementasi terlihat berbeda, jika tidak berperilaku berbeda - adalah alasan yang cukup bagi tim desain untuk mengkonsolidasikan desain kontrol untuk memenuhi kebutuhan tim internal.

@mdtauk Seperti biasa Anda membuat poin bagus. Namun, saya harus tidak setuju dengan filosofi ini dalam satu cara utama jika itu benar-benar pendekatan yang diambil Microsoft. Agar WinUI berhasil, itu harus masuk akal bagi pengembang aplikasi yang ada. Saya mencoba menghindari skenario UWP lain karena kita semua tahu UWP tidak pernah lepas landas. Pengembang yang perlu diyakinkan Microsoft untuk datang ke WinUI, sama seperti UWP sebelumnya, adalah pengembang WPF. Salah satu alasan aplikasi WPF tidak pernah melompat ke UWP adalah karena UWP, terutama ketika pertama kali dirilis, adalah padanan yang sangat buruk di beberapa area fungsi utama. Itu sebabnya ketika saya melihat sudut membulat hilang di peta jalan, saya mulai mengingat mimpi buruk UWP (sudut membulat yang mendasar untuk WPF ditinggalkan dari UWP untuk waktu yang lama). Prioritas nomor # 1 harus untuk pengalaman porting yang lancar yang berasal dari KEDUA WPF dan UWP dan sejujurnya WPF mungkin harus menjadi prioritas yang lebih tinggi karena ada lebih banyak aplikasi di sana dan Microsoft jelas berfokus pada kasing desktop dengan WinUI terlebih dahulu. Jadi sekali lagi, kita harus sangat berhati-hati, dan secara aktif menghindari, menciptakan kembali roda.

Dan fakta bahwa setiap implementasi terlihat berbeda, jika tidak berperilaku berbeda - adalah alasan yang cukup bagi tim desain untuk mengkonsolidasikan desain kontrol untuk memenuhi kebutuhan tim internal.

Saya selalu mengerti bahwa desain mungkin perlu dimodifikasi. Menggunakan konsep kontrol tanpa tampilan, ini adalah masalah terpisah dari ExpandDirection. Jika kita perlu lebih memodernisasi desain atau membuatnya lebih berguna dalam beberapa kasus, bagus - itu harus relatif sepele. Di penghujung hari itu juga dapat sepenuhnya ditempa ulang untuk mereka yang membutuhkan kontrol yang baik.

Hal menarik tentang animasi. Kami mematikan semua animasi dengan pengaturan sistem, tapi saya rasa kami tidak mengekspos tombol untuk mematikan animasi selain dengan re-templating saat ini.

Agar adil, hampir tidak ada kontrol yang menggunakan animasi. TreeView dan NavigationView pada dasarnya menggunakan Expander tetapi keduanya tidak menggunakan animasi untuk memperluas/menciutkan. Sebagian besar kontrol yang menggunakan animasi biasanya mengandalkannya, misalnya ProgressBar atau ProgressRing. Namun Expander tidak bergantung padanya, itu akan lebih "menyenangkan untuk dimiliki". Contoh kasus lainnya adalah bahwa beberapa orang tidak menggunakan kontrol WCT Expander karena mereka tidak menyukai animasinya. Jika kita ingin menyertakan orang sebanyak mungkin, memiliki cara mudah untuk menonaktifkan animasi yang tidak diinginkan akan membuatnya lebih mudah.

Saya yakin Anda dapat menambahkan Gaya yang menimpa koleksi Transisi dengan null jika Anda ingin mematikan animasi, dengan asumsi ada koleksi Transisi untuk ditimpa.

Tetapi apakah ini akan menjadi cara umum untuk menonaktifkan/mengaktifkan itu? Sebagian besar waktu, ketika kami menyediakan beberapa gaya, mereka berbeda secara drastis daripada hanya satu animasi, misalnya AccentColorButtonStyle atau RevealButtonStyle.

Termasuk ExpandTransition dan CollapseTransition, yang dapat menggunakan arah yang ditetapkan oleh properti kontrol - yang memungkinkan pengembang untuk mengatur transisi untuk masing-masing.

Saya sangat menyukai ide ini!

Saya menyukai idenya, tetapi saya rasa hari ini tidak ada cara untuk membuat transisi tema khusus yang akan membatasi kemampuan untuk menyesuaikan. Ini akan memungkinkan dengan mudah menonaktifkannya dengan menghapusnya.

Saya juga prihatin tentang itu. dengan ExpandTransition dan CollapseTransition API tanpa transisi tema khusus, ini hampir hanya memiliki "ExpendTransitionEnabled" dan "CollapseTransitionEnabled".

@robloo Jika Anda ingin mengobrol tentang frustrasi terkait pengembangan WinUI 3, saya menyambut Anda untuk menulis kepada saya (Twitter dan email kantor saya ada di profil GitHub saya). Saya tidak sepenuhnya menyadari frustrasi Anda saat ini, tetapi saya biasanya orang yang baik untuk memulai topik yang berkaitan dengan keterlibatan/pengembangan pelanggan atau komunitas serta saya telah menjalankan sejumlah besar grup fokus kami selama setahun terakhir yang mencakup pertimbangan yang Anda cantumkan di seputar perkakas, paritas fitur, dll.

Saya perhatikan bahwa peta jalan kami sangat ketat, jadi saya tidak bisa menjanjikan saya akan memiliki kemampuan untuk membuat perubahan yang ingin Anda lihat, tetapi selalu membantu bagi saya untuk mengetahui apa yang dapat dilakukan untuk lebih mendukung Anda sebagai pelanggan dan/atau kontributor WinUI, jadi hasil terburuknya adalah setidaknya kebutuhan Anda dipertimbangkan dengan baik oleh tim kami untuk bergerak maju. Untuk kasus terbaik, saya kira itu akan tergantung pada apa yang Anda cari. Mari berbincang? 😄

@mdtauk Terima kasih atas dukungan Anda dalam mengklarifikasi - Anda selalu selaras! Saya akan mengatakan bahwa jelas ada BANYAK di piring kami dan tim berkomitmen untuk menjadi ramping dan seefektif mungkin dalam mencoba memberikan kemajuan yang paling berarti dan berdampak di semua bidang. Untuk terus berinvestasi dalam kontrol/fitur baru di antara semua bidang kemajuan berkelanjutan lainnya, anggota tim kami seperti @kat-y mengembangkan _sangat_ spesifikasi persyaratan yang tajam karena hal terburuk bagi kami adalah membuang sebagian dari sumber daya kami yang terbatas ke tombol atau API yang sebenarnya tidak digunakan secara luas karena tidak hanya biaya pengembangan di muka tetapi juga biaya pemeliharaan lanjutan setelahnya. Saya baru saja menguraikan utas ini dengan ringan, tetapi itu benar untuk @kat-y, terutama sebagai anggota tim baru, ingin benar-benar tajam dalam memastikan bahwa ada skenario nyata dalam aplikasi nyata yang membutuhkan fungsionalitas yang diminta ( baik untuk alasan yang disebutkan dan juga untuk memastikan kami memiliki mitra validasi Pratinjau yang dapat membantu memastikan semua fitur yang dikembangkan berfungsi seperti yang diperlukan dalam lingkungan produksi yang menyediakan cakupan kasus tepi). Kepatuhan terhadap aspirasi ini mungkin tidak selalu disiarkan secara publik seperti dalam kasus di mana mitra yang memvalidasi bersifat pribadi (dan Anda dipersilakan untuk menghubungi @kat-y secara langsung jika kebutuhan Anda tidak sesuai untuk diposting secara publik di sini saat ini), tetapi ini telah menjadi preseden di semua rilis kontrol WinUI 2+ kami.

Saya harap ini membantu? Adalah tujuan saya untuk mengembalikan utas ini ke @kat-y dan topik Expander yang ada, tetapi harap hubungi langsung jika ada lebih banyak yang dapat saya jawab atau jika ada umpan balik yang ingin Anda pertimbangkan. Terima kasih kepada Anda berdua atas semua pekerjaan, semangat, dan energi yang telah Anda masukkan ke dalam utas ini dan ke WinUI! 😄

@mdtauk Seperti biasa Anda membuat poin bagus. Namun, saya harus tidak setuju dengan filosofi ini dalam satu cara utama jika itu benar-benar pendekatan yang diambil Microsoft..

Saya tidak mengomentari apakah saya setuju atau tidak dengan pendekatan ini, hanya saja dari waktu saya di sini dan melihat bagaimana repo dievaluasi, begitulah cara saya percaya tim sedang mengerjakan ini.

(baik untuk alasan yang disebutkan dan juga untuk memastikan kami memiliki mitra validasi Pratinjau yang dapat membantu memastikan semua fitur yang dikembangkan berfungsi seperti yang diperlukan dalam lingkungan produksi yang menyediakan cakupan kasus tepi). Kepatuhan terhadap aspirasi ini mungkin tidak selalu disiarkan secara publik seperti dalam kasus di mana mitra yang memvalidasi bersifat pribadi (dan Anda dipersilakan untuk menghubungi @kat-y secara langsung jika kebutuhan Anda tidak sesuai untuk diposting secara publik di sini saat ini), tetapi ini telah menjadi preseden di semua rilis kontrol WinUI 2+ kami.

Saya percaya menggunakan aplikasi Microsoft sendiri, dan Shell sebagai contoh lebih mungkin untuk mendapatkan pengakuan, karena menunjukkan di mana ada kebutuhan internal untuk sesuatu, yang tidak ada, atau tidak sesuai untuk tujuan, sampai-sampai mereka harus " gulung sendiri" - tetapi tentu saja binatang besar seperti Netflix, Facebook, dll yang membuat aplikasi untuk Windows - juga akan meminta kontrol dan bit lainnya.

WinUI bukan hanya tentang mencapai paritas dengan WPF, MFC, CommonControls, WinForms dll - (tetapi yang lebih umum digunakan dari kontrol warisan ini tanpa padanan modern, harus diperhatikan dengan serius)

Fakta Breadcrumb Bars dan Expanders sedang diusulkan adalah tanda bahwa ini mulai terjadi IMO. Dan setiap kontrol atau penambahan API harus dievaluasi dan "dibenarkan" dalam lingkungan yang ideal, seperti halnya desainer aplikasi harus selalu mengevaluasi ulang UI dan UX mereka untuk memastikan mereka sesuai dengan tujuan. - Dalam hal ini mungkin tampak jelas, tetapi kita harus tetap menyajikan contoh di mana pola ini dan API ini digunakan - untuk memperkuat kasus penyertaan.

Tentang animasi: Bagaimana dengan menggunakan pendekatan ElementAnimator seperti yang ditawarkan ItemsRepeater? ElementAnimator API dengan StartShowAnimation() dan StartHideAnimation() terlihat menjanjikan ("tampilkan" untuk digunakan untuk ekspansi, "sembunyikan" untuk menciutkan). Properti ElementAnimator dapat ditawarkan pada kontrol dengan implementasi animasi default. Jika tidak ada animasi yang diinginkan, properti dapat disetel ke null atau jika diperlukan kontrol yang lebih halus, hanya animasi Perlihatkan atau Sembunyikan yang dapat diberikan ke ElementAnimator.

Saya tidak terlalu akrab dengan ElementAnimator API dan sepertinya itu mungkin belum dapat digunakan di semua skenario karena ada masalah https://github.com/microsoft/microsoft-ui-xaml/issues/166 . Namun, jika masih ada celah fungsionalitas, mungkin item kerja ini (kontrol Expander & ElementAnimator berfungsi untuk membuatnya dapat digunakan oleh kontrol Expander) dapat disinkronkan dan direkayasa bersama.

Hmm ide ElementAnimator sangat menarik. Kekhawatiran saya di sini adalah bahwa ini mungkin terlalu rumit atau direkayasa berlebihan. Lagi pula, untuk ExpanderControl, kita kemudian perlu menyediakan ElementAnimator khusus sementara kita dapat menggunakan kembali animasi tema yang ada. Juga, ElementAnimator menyediakan lebih banyak metode daripada yang sebenarnya dibutuhkan oleh kontrol expander sehingga sepertinya agak canggung.

Apakah saya benar dalam berpikir bahwa ElementAnimator adalah untuk menangani offset untuk anak atau elemen yang terkandung yang muncul di layar?

Ini mungkin berlebihan tergantung pada apa yang ada di dalam panel yang ditampilkan sebagai expander, mengembang. Tetapi jika ada cara untuk menghubungkannya, jadi jika panel perluasan yang berisi elemen - dapat menggerakkan animasi anak jika pengembang menambahkan sesuatu ke elemen.

Jadi Expander tidak secara langsung mengontrol transisi elemen anak, tetapi dapat mengaktifkannya jika pengembang menginginkannya

Ya, jika kami dapat membuat animasi yang dapat digunakan kembali di sini, sambil tetap memberi pelanggan beberapa tingkat pilihan penyesuaian yang memuaskan, maka ini akan layak untuk ditelusuri. Misalnya, kita telah melihat permintaan untuk menambahkan animasi ke kontrol TreeView saat item meluas/runtuh (https://github.com/microsoft/microsoft-ui-xaml/issues/208). Saya membayangkan sebuah kasus dapat dibuat di sini bahwa satu set animasi dapat dibangun agar terlihat bagus untuk kontrol Expander dan TreeView. Yang secara otomatis akan datang dengan tingkat konsistensi kemudian di antara kontrol yang berbeda. menciptakan keakraban visual bagi pengguna yang juga merupakan argumen yang menarik.

Saya pikir idealnya, TreeView dan hierachical NavigationView seharusnya hanya beralih ke kontrol Expander ketika kontrol sudah siap. Lagi pula, saat ini kedua kontrol perlu menangani masalah yang sama persis yang akan diselesaikan oleh ExpanderControl. Jadi animasi bersama tidak akan membuat perbedaan besar untuk TreeView.

Masalahnya dengan ElementAnimator (bagaimana saya memahaminya) adalah kita harus menulis animasi baru. Namun sudah ada animasi bawaan yang dapat kami manfaatkan untuk Expander.

Ini mungkin berlebihan tergantung pada apa yang ada di dalam panel yang ditampilkan sebagai expander, mengembang. Tetapi jika ada cara untuk menghubungkannya, jadi jika panel perluasan yang berisi elemen - dapat menggerakkan animasi anak jika pengembang menambahkan sesuatu ke elemen.

Saya pikir salah satu poin utama untuk ElementAnimator adalah mengizinkan penambahan animasi ke panel dan koleksi, misalnya ItemsRepeater. Dalam kasus Expander, ini tidak benar-benar terjadi, expander bukanlah panel yang merender kumpulan item.

Dari atas kepala saya, pengubahan ukuran untuk panel induk dengan easing. Kemudian slide dan fade untuk objek yang berisi akan terasa benar.

Jika itu menjadi transisi luas OS yang digeneralisasi dengan easing yang tepat ditentukan oleh tim gerak Desain Lancar - itu akan bagus.

Menandai @stmoy karena kita berbicara tentang animasi.

Terima kasih @SavoySchuler telah bergabung dan memberikan lebih banyak konteks pada komitmen tim kami - Saya harap ini membantu menjelaskan mengapa saya secara khusus mencari contoh aplikasi yang membutuhkan fungsionalitas ExpandDirection! Untuk menggemakan apa yang dikatakan Savoy, silakan hubungi saya secara langsung (DM Twitter jika Anda membutuhkan privasi) jika kebutuhan Expander Anda tidak dapat dibagikan di sini.

@robloo Terima kasih atas permintaan maaf Anda, saya sepenuhnya memahami niat Anda dan pasti ingin kontrol WinUI dicakup dan dikembangkan dengan cara yang bermakna dan efisien. Saya baru di tim dan sangat menghargai bahwa komunitas WinUI sangat ramah dan antusias dalam membahas ruang lingkup dan implementasi Expander!

Pada catatan itu, saya senang membaca komentar terbaru tentang animasi ini!

Setelah membaca komentar terkait animasi, sepertinya ada 3 rute yang mungkin, dalam urutan peningkatan jumlah pekerjaan:

Tidak termasuk animasi set - ini memiliki manfaat seperti yang ditunjukkan oleh @chingucoding untuk tidak menghalangi pengembang ketika skenario mereka tidak berfungsi atau terlihat bagus dengan animasi yang disetel. Risiko di sini adalah kemungkinan inkonsistensi, meskipun tampaknya tidak ada banyak 'ruang' untuk inkonsistensi dalam rute ini.

@mdtauk diusulkan Termasuk ExpandTransition dan CollapseTransition,

yang dapat menggunakan arah yang ditetapkan oleh properti kontrol - yang memungkinkan pengembang untuk mengatur transisi untuk masing-masing.

Kedengarannya seperti lingkup yang lebih kecil daripada menggunakan ElementAnimator. Apakah ini akan memberikan fleksibilitas penuh kepada pengembang dalam mengatur transisi?

Dari atas kepala saya, pengubahan ukuran untuk panel induk dengan easing. Kemudian slide dan fade untuk objek yang berisi akan terasa benar.

Saya mengerti sebagian dari ini, tetapi sulit bagi saya untuk memvisualisasikannya tanpa, yah, visual . Apakah "mengubah ukuran untuk panel induk" berarti ukuran header akan berubah? Bisakah Anda menguraikan apa yang Anda maksud dengan "slide dan fade untuk objek yang berisi"?

@Felix-Dev diusulkan menggunakan ElementAnimator

ElementAnimator API dengan StartShowAnimation() dan StartHideAnimation() terlihat menjanjikan ("show" untuk digunakan untuk ekspansi, "hide" digunakan untuk menciutkan). Properti ElementAnimator dapat ditawarkan pada kontrol dengan implementasi animasi default. Jika tidak ada animasi yang diinginkan, properti dapat disetel ke null atau jika diperlukan kontrol yang lebih halus, hanya animasi Perlihatkan atau Sembunyikan yang dapat diberikan ke ElementAnimator.

@chingucoding mencatat bahwa

kita kemudian perlu menyediakan ElementAnimator khusus sementara kita dapat menggunakan kembali animasi tema yang ada. Juga, ElementAnimator menyediakan lebih banyak metode daripada yang sebenarnya dibutuhkan oleh kontrol expander sehingga sepertinya agak canggung.

salah satu poin utama untuk ElementAnimator adalah memungkinkan penambahan animasi ke panel dan koleksi, misalnya ItemsRepeater. Dalam kasus Expander, ini tidak benar-benar terjadi, expander bukanlah panel yang merender kumpulan item.

TreeView dan Navigasi Hierachical seharusnya hanya beralih ke kontrol Expander saat kontrol sudah siap. Lagi pula, saat ini kedua kontrol perlu menangani masalah yang sama persis yang akan diselesaikan oleh ExpanderControl. Jadi animasi bersama tidak akan membuat perbedaan besar untuk TreeView.

Saya tidak yakin bahwa TreeView dan hierachical NavigationView memiliki skenario animasi yang sama persis dengan Expander, bagaimana dengan kapan Expander akan mendorong konten apa pun (tidak harus teks/tombol) di dekatnya dan skenario ketika Expander 'akordeon'-ed satu sama lain dan berpotensi memiliki logika untuk menutup/membuka tergantung pada ekspansi satu sama lain.

Apakah ElementAnimator berlebihan untuk animasi Expander mengingat itu ditujukan untuk animasi panel/koleksi?

@mdtauk diusulkan Termasuk ExpandTransition dan CollapseTransition,

yang dapat menggunakan arah yang ditetapkan oleh properti kontrol - yang memungkinkan pengembang untuk mengatur transisi untuk masing-masing.

Kedengarannya seperti lingkup yang lebih kecil daripada menggunakan ElementAnimator. Apakah ini akan memberikan fleksibilitas penuh kepada pengembang dalam mengatur transisi?

Dari atas kepala saya, pengubahan ukuran untuk panel induk dengan easing. Kemudian slide dan fade untuk objek yang berisi akan terasa benar.

Saya mengerti sebagian dari ini, tetapi sulit bagi saya untuk memvisualisasikannya tanpa, yah, visual . Apakah "mengubah ukuran untuk panel induk" berarti ukuran header akan berubah? Bisakah Anda menguraikan apa yang Anda maksud dengan "slide dan fade untuk objek yang berisi"?

Maaf atas keterlambatannya, saya harus membuat animasi mock-up kecil ini.
Abaikan waktu animasi yang sebenarnya, itu hanya untuk ilustrasi. Garis merah muda adalah Header Expander - dan Perbatasan Hijau untuk Panel/Konten Expander dll

Saya tidak yakin bahwa TreeView dan hierachical NavigationView memiliki skenario animasi yang sama persis dengan Expander, bagaimana dengan kapan Expander akan mendorong konten apa pun (tidak harus teks/tombol) di dekatnya dan skenario ketika Expander 'akordeon'-ed satu sama lain dan berpotensi memiliki logika untuk menutup/membuka tergantung pada ekspansi satu sama lain.

Pertanyaannya adalah, haruskah Expander menerapkan animasi? TreeView dan Hierarchical NavigationView pasti akan mendapat manfaat dari memiliki kontrol expander bawaan yang menangani perluasan/penciutan dan akan memungkinkan kita untuk dapat memiliki pengalaman yang lebih terpadu di area itu. Misalnya, TreeView tidak menganimasikan apa pun sementara NavigationView hierarki menganimasikan rotasi chevron.

Apakah ElementAnimator berlebihan untuk animasi Expander mengingat itu ditujukan untuk animasi panel/koleksi?

Bisa jadi, salah satu kontrol yang secara aktif mendukung ElementAnimator (setidaknya dalam pratinjau) adalah ItemsRepeater yang menangani panel besar yang merender lusinan item. Expander di sisi lain tidak memiliki skenario yang rumit melainkan satu item untuk ditampilkan/sembunyikan.

Hal berbeda yang saya perhatikan adalah bahwa tidak akan ada cara untuk menyesuaikan di mana chevron akan ditempatkan (kiri/kanan atau atas/bawah). Mungkin ini akan berguna sebagai titik penyesuaian? NavigationView menempatkan chevron di sebelah kanan sementara TreeView menempatkannya di sebelah kiri. Hal yang sama berlaku untuk ekspander yang ada di sistem, beberapa area aplikasi pengaturan menempatkannya di sebelah kiri sementara Pemberitahuan misalnya, menempatkannya di sebelah kanan.

Hal berbeda yang saya perhatikan adalah bahwa tidak akan ada cara untuk menyesuaikan di mana chevron akan ditempatkan (kiri/kanan atau atas/bawah). Mungkin ini akan berguna sebagai titik penyesuaian? NavigationView menempatkan chevron di sebelah kanan sementara TreeView menempatkannya di sebelah kiri. Hal yang sama berlaku untuk ekspander yang ada di sistem, beberapa area aplikasi pengaturan menempatkannya di sebelah kiri sementara Pemberitahuan misalnya, menempatkannya di sebelah kanan.

Kami dapat memperkenalkan sesuatu seperti ExpandGlyphPlacementMode dengan nilai seperti TopLeft, TopRight, BottomCentered (dan mungkin lebih banyak lagi (Kiri, Kanan, ...)) dan ExpandGlyphPlacementOffset dapat digunakan pengembang properti untuk memodifikasi posisi dasar (diatur oleh mode penempatan) jika diperlukan.

Selain itu, seperti yang sudah diperhatikan oleh @mdtauk , API untuk menyesuaikan glyph perluasan/ciutkan (beberapa kontrol menggunakan > , yang lain menggunakan v untuk mesin terbang perluasannya) dan untuk mengontrol visibilitas mesin terbang

Kami dapat memperkenalkan sesuatu seperti ExpandGlyphPlacementMode dengan nilai seperti TopLeft, TopRight, BottomCentered (dan mungkin lebih (Kiri, Kanan, ...)) dan pengembang properti ExpandGlyphPlacementOffset tambahan yang dapat digunakan untuk mengubah posisi dasar (ditetapkan oleh mode penempatan) jika diperlukan .

Saya tidak yakin apakah TopLeft, TopRight ... adalah pilihan yang tepat di sini. Mungkin sesuatu seperti "Mulai" dan "Akhir" mungkin lebih cocok di sini?
Dalam tata letak horizontal, Mulai akan berada di kiri (kanan dalam bahasa RTL), dalam mode pembukaan vertikal, ini akan berada di atas. "Akhir" dapat didefinisikan sesuai itu. Masalah yang saya lihat dengan TopLeft ... adalah bahwa hal itu menimbulkan banyak kerumitan (lihat Tip Pengajaran) dengan sedikit manfaat. TopLeft dan TopRight akan sama jika ExpanderControl terbuka ke kanan. Saya pikir memiliki sesuatu seperti bagian tengah bawah akan terlihat sedikit canggung di banyak ruang dan memakan banyak ruang.

Selain itu, seperti @mdtauk (membagi menyebutkan untuk tidak mengirim spam ke kotak masuknya), API untuk menyesuaikan glyph perluasan/ciutkan (beberapa kontrol menggunakan >, yang lain menggunakan v untuk perluasan glyph) dan untuk mengontrol visibilitas mesin terbang

Pertanyaannya adalah, bagaimana mencapai ini. Jika kita ingin menganimasikan ikon yang mirip dengan apa yang dilakukan NavigationView hierarkis, kita tidak akan dapat mengizinkan API untuk menukar glyph yang diperluas dan diciutkan yang dapat digunakan untuk beralih ke v atau > untuk diciutkan. Mungkin kita bisa memiliki API yang menunjukkan arah mesin terbang yang diciutkan?

Ide untuk animasi tampaknya cukup bagus. Harus dimungkinkan untuk mengaktifkan/menonaktifkannya seperti Tampilan Daftar, dkk. Header dan mesin terbang juga perlu beralih sisi untuk bahasa RTL secara otomatis. Namun, semua kustomisasi mesin terbang tampaknya merekayasa masalah secara berlebihan. Tidak mungkin membuat gaya yang akan berfungsi untuk semua kasus yang diidentifikasi yang memiliki implementasi khusus. Sebagai gantinya, seperti Kotak Centang dan kontrol lainnya, desain default harus menjadi yang terbaik yang dapat kita lakukan tetapi gaya default harus cukup sederhana untuk ditempa ulang. Saya tidak tahu mengapa semua orang sangat tidak suka dengan re-templating kontrol. Ini adalah solusi dan sebenarnya merupakan kekuatan besar dari kontrol tampilan yang lebih sedikit. Menambahkan lebih banyak properti juga meningkatkan beban pemeliharaan yang sering saya dengar.

Sunting: mendefinisikan sumber daya untuk beberapa hal untuk meningkatkan gaya ringan mungkin juga merupakan opsi yang masuk akal.

Saya tidak yakin apakah TopLeft, TopRight ... adalah pilihan yang tepat di sini. Mungkin sesuatu seperti "Mulai" dan "Akhir" mungkin lebih cocok di sini?
Dalam tata letak horizontal, Mulai akan berada di kiri (kanan dalam bahasa RTL), dalam mode pembukaan vertikal, ini akan berada di atas. "Akhir" dapat didefinisikan sesuai itu. Masalah yang saya lihat dengan TopLeft ... adalah bahwa hal itu menimbulkan banyak kerumitan (lihat Tip Pengajaran) dengan sedikit manfaat.

@chingucoding NavigationView menggunakan mode pembukaan vertikal (karena NavigationViewItem mengembang secara vertikal), bukan? Bagaimana saya kemudian dapat mengatur mesin terbang di sisi kiri atau kanan header? Saya membaca komentar Anda karena "mulai" akan berada di atas, "akhir" mungkin berada di bawah tajuk. Tapi saya tidak melihat cara untuk menentukan apakah mesin terbang dapat ditempatkan di sudut kiri atas atau sudut kanan atas. Saya tidak perlu menggunakan API seperti ExpandGlyphPlacementOffset untuk sesuatu yang biasa kita lihat.

Saya pikir memiliki sesuatu seperti bagian tengah bawah akan terlihat sedikit canggung di banyak ruang dan memakan banyak ruang.

Saya yakin saya telah melihat contohnya di web, di aplikasi, dll...itulah sebabnya saya mendapatkan ide itu. Meskipun akan lebih baik jika contoh dapat diposting di sini untuk melihat apakah itu adalah sesuatu yang layak untuk didukung secara langsung atau apakah kita akan membiarkannya untuk ditempa ulang.

Namun, semua kustomisasi mesin terbang tampaknya merekayasa masalah secara berlebihan. Tidak mungkin membuat gaya yang akan berfungsi untuk semua kasus yang diidentifikasi yang memiliki implementasi khusus. Sebagai gantinya, seperti Kotak Centang dan kontrol lainnya, desain default harus menjadi yang terbaik yang dapat kita lakukan tetapi gaya default harus cukup sederhana untuk ditempa ulang. Saya tidak tahu mengapa semua orang sangat tidak suka dengan re-templating kontrol. Ini adalah solusi dan sebenarnya merupakan kekuatan besar dari kontrol tampilan yang lebih sedikit.

@robloo Saya tidak

Kita harus mengidentifikasi skenario kustomisasi umum dan berusaha membuatnya sedapat mungkin diakses oleh kontrol Expander.

Ambil, misalnya, kasus mesin terbang yang disesuaikan ini (ditemukan di situs web Fluent UI ):

Kustomisasi simbol mesin terbang berarti setiap animasi mesin terbang bawaan harus dipertimbangkan dengan hati-hati. Juga menarik untuk diketahui: Apa yang lebih diinginkan oleh pelanggan - kemampuan untuk dengan mudah menyesuaikan mesin terbang sesuai dengan keinginan mereka atau memiliki animasi built-in untuk mesin terbang (seperti terlihat di NavigationView). Saya pribadi berpikir yang pertama akan lebih penting untuk dimiliki tetapi saya tidak memiliki data keras untuk mendukungnya.

Kontrol Expander lainnya adalah kontrol Telerik Expander yang memperlihatkan beberapa API kustomisasi yang telah kita bahas di sini (seperti kemampuan untuk mengubah posisi glyoh atau simbol mesin terbang) yang juga dapat kita gunakan untuk beberapa inspirasi.

ExpandedGlyph
RuntuhGlyph
Yang dapat ditimpa oleh pengembang sesuai keinginan mereka

GlyphPlacement.Start .End .Above .Below
Mungkin?

Mungkin juga menggunakan perataan konten untuk menangani tajuk yang mengisi lebar, atau membuat Glyph dan teks digabungkan menjadi satu

Untuk Pusat Notifikasi ada yang jelas semua pada baris yang sama dengan expander, jadi bagaimana ini akan ditangani? Semacam cara untuk memisahkan panel yang diperluas dari header yang diperluas?

@chingucoding NavigationView menggunakan mode pembukaan vertikal (karena NavigationViewItem mengembang secara vertikal), bukan? Bagaimana saya kemudian dapat mengatur mesin terbang di sisi kiri atau kanan header? Saya membaca komentar Anda karena "mulai" akan berada di atas, "akhir" mungkin berada di bawah tajuk. Tapi saya tidak melihat cara untuk menentukan apakah mesin terbang dapat ditempatkan di sudut kiri atas atau sudut kanan atas. Saya tidak perlu menggunakan API seperti ExpandGlyphPlacementOffset untuk sesuatu yang biasa kita lihat.

Itu kata-kata yang buruk di pihak saya Dengan "mode pembukaan horizontal", maksud saya bahwa dimensi horizontal adalah tetap, sehingga konten disajikan secara horizontal. Sama untuk mode vertikal. Juga apa sudut kiri atas dan kiri bawah? Saya akan menganggap ikon berada di tengah, sebagian besar waktu tajuk tidak boleh/bahkan tidak memakan banyak ruang di wilayah yang berkembang dan kiri atas dan kiri bawah akan berakhir hampir sama.

Jadi untuk memperjelas, jika expander mengembang ke arah vertikal, start kiri (kanan di RTL) dan end kanan (kiri di RTL); dalam ekspansi horizontal, start berada di atas dan end berada di bawah. Mirip dengan CSS flex-start dan flex-end.

Visual Studio menggunakan ikon tengah, namun wilayah tombol perluas merentangkan seluruh kontrol:

Tertutup:

Diperluas:

GlyphPlacement.Start .End .Above .Below
Mungkin?

Kedengarannya seperti ide yang sangat keren! Bagaimana di atas dan di bawah terlihat seperti? Mirip dengan apa yang dilakukan Visual Studio?

ExpandedGlyph
RuntuhGlyph
Yang dapat ditimpa oleh pengembang sesuai keinginan mereka

Ini akan menjadi cara untuk melakukan ini, namun ini tidak memungkinkan kita untuk menganimasikan ikon (misalnya memutar). Namun saya pikir lebih masuk akal untuk memprioritaskan kemungkinan untuk mengganti ikon sepenuhnya daripada memiliki animasi di sini.

Mungkin juga menggunakan perataan konten untuk menangani tajuk yang mengisi lebar, atau membuat Glyph dan teks digabungkan menjadi satu

100%

Untuk Pusat Notifikasi ada yang jelas semua pada baris yang sama dengan expander, jadi bagaimana ini akan ditangani? Semacam cara untuk memisahkan panel yang diperluas dari header yang diperluas?

Saya khawatir bahwa skenario khusus ini mungkin terlalu rumit untuk dicapai hanya dengan kontrol expander. Penempatan tombol cukup unik, tetapi yang lebih penting, header dan ikon expand tidak berada pada baris yang sama yang akan cukup sulit dilakukan dengan kontrol expander standar yang menempatkan header dan ikon bersebelahan. Berikut adalah contoh untuk referensi:

Saya tidak menentang re-templating tetapi melihat contoh yang diposting sejauh ini, beberapa pengembang menggunakan ">" untuk glyoh ekspansi dan yang lain menggunakan "v" untuk mesin terbang ekspansi saat memperluas secara vertikal. Sama seperti untuk posisi mesin terbang. Kontrol Expander seharusnya sangat memudahkan pengembang untuk mengatur mesin terbang sesuai keinginan mereka.

@Felix-Dev Ini adalah salah satu hal yang harus distandarisasi dalam sistem desain yang lancar. Sangat penting bagi pengguna untuk memiliki tampilan dan nuansa yang konsisten. Satu-satunya saat ini harus berubah adalah jika aplikasi harus melakukannya untuk memenuhi bahasa desain mereka sendiri atau ada kasus penggunaan baru yang tidak kami pikirkan. Dalam hal ini -- re-templat.

Sunting: Saya melewatkan contoh Telerik Anda saat pertama kali membaca. Masih berpikir kami meningkatkan kompleksitas terlalu banyak dan membiarkan terlalu banyak pilihan desain yang akan: (1) tidak mudah dikenali oleh pengguna (2) akan mengekspos banyak kompleksitas yang secara historis tidak diperlukan. Tentu saja ada garis tipis di sini. Kami ingin mengekspos fungsionalitas yang cukup sehingga pengguna tidak perlu membuat template ulang, tetapi kami juga tidak ingin mengekspos begitu banyak fungsionalitas sehingga bahasa desain menjadi kacau.

WPF, atau kontrol expander lainnya yang dapat saya pikirkan, tidak pernah mengekspos properti untuk mengontrol ini. Ini benar-benar bagian dari tampilan dan harus bertahan hanya di XAML. Model tampilan (yaitu DP kontrol dalam kasus ini) seharusnya tidak mengetahui apa pun tentang pilihan gaya seperti itu dalam kontrol tanpa tampilan yang bersih.

WPF, atau kontrol expander lainnya yang dapat saya pikirkan, tidak pernah mengekspos properti untuk mengontrol ini. Ini benar-benar bagian dari tampilan dan harus bertahan hanya di XAML. Model tampilan (yaitu DP kontrol dalam kasus ini) seharusnya tidak mengetahui apa pun tentang pilihan gaya seperti itu dalam kontrol tanpa tampilan yang bersih.

@robloo Satu kemungkinan untuk mengekspos kustomisasi mesin terbang adalah melalui gaya ringan. Sumber daya ini, seperti halnya DP, harus dianggap sebagai bagian dari permukaan API publik dari sebuah kontrol, tetapi mereka lebih dekat dengan template kontrol (tampilan kontrol). Jadi kita bisa mengekspos sumber daya seperti ExpanderExpandGlyph dan ExpanderCollapseGlyph (NavigasiView misalnya memiliki sumber daya NavigationViewItemExpandedGlyph ).

Mengekspos kustomisasi simbol mesin terbang seperti itu juga dapat dibaca sebagai rekomendasi untuk menyediakan elemen font yang ada dalam font MDL2, sehingga menggunakan ikon yang disetujui Desain Lancar. Melihat font MDL2, tampaknya menampilkan semua ikon mesin terbang luaskan/runtuh yang umum digunakan yang pernah saya lihat dalam contoh di web (chevron yang berbeda, +/-, +/- dalam lingkaran,...). Sementara pengembang mungkin masih dapat mengganti FontFamily (disediakan oleh sumber daya SymbolThemeFontFamily ), kami hanya akan secara langsung mengekspos ExpanderExpandGlyph ,... sumber daya sebagai sumber daya publik untuk kontrol, sehingga pengembang berpotensi pertama kali lihat keluarga font MDL2 jika mereka ingin menyesuaikan ikon (karena itu akan menjadi keluarga font default yang digunakan oleh Expander untuk mesin terbang).

Bagi mereka yang tertarik, ada juga setidaknya satu masalah lain yang belum terselesaikan tentang seberapa jauh kita sebagai WinUI ingin memberikan opsi mesin terbang kustomisasi yang mudah ketika hanya satu set ikon tetap yang masuk akal dalam konteks yang diberikan (tombol putar NumberBox kustomisasi mesin terbang) : https://github.com/microsoft/microsoft-ui-xaml/issues/2789 Saya tahu setidaknya beberapa dari Anda sudah mengetahui masalah itu, tetapi karena saya melihat beberapa kesamaan dalam diskusi di sana seperti di sini mengenai cara mengekspos opsi penyesuaian (mesin terbang), saya merasa perlu dirujuk di sini. Mungkin solusi yang ditemukan di sini juga dapat diterapkan dalam kasus NumberBox untuk konsistensi di WinUI.

@Felix-Dev Rekomendasi Anda untuk gaya ringan paling masuk akal bagi saya. Itulah yang saya maksud dengan "Edit: mendefinisikan sumber daya untuk beberapa hal guna meningkatkan gaya ringan mungkin juga merupakan opsi yang masuk akal." beberapa komentar di atas.

Pertanyaannya adalah seberapa besar kemungkinan pengembang tidak akan menyediakan mesin terbang melainkan memiliki beberapa bentuk ikon lain, misalnya BitmapIcon atau beberapa bentuk FontIcon khusus. Jika ikon non mesin terbang bukan benar-benar titik penyesuaian yang akan digunakan banyak pengembang, saya pikir sumber daya gaya ringan untuk mesin terbang (dan mungkin satu untuk font simbol) untuk digunakan adalah hal terbaik di sini, seperti yang diusulkan oleh @robloo dan @Felix- Dev.

Re-templating selalu menjadi pilihan, jika mesin terbang atau font khusus tidak cukup.

• Font Glyphs baik dengan Segoe MDL2 atau FluentIcons adalah yang paling mungkin dan mungkin harus menjadi default;

• Tidak ada mesin terbang sama sekali juga umum;

• Lalu ada jalur, SVG yang kecil kemungkinannya tetapi sangat mungkin;

• Dan kemudian PNG atau bitmap penuh sebagai opsi yang tidak mungkin tetapi mungkin untuk pengembang.

Pendekatan apa pun yang digunakan, mungkin harus fokus pada dua skenario pertama, tetapi selalu memungkinkan re-templating untuk yang ketiga.

Lalu ada kemungkinan untuk memiliki ContentPresenter untuk mesin terbang, dan mengizinkan apa pun untuk diletakkan di atasnya. Tetapi tidak yakin bagaimana cara kerjanya dengan VisualStates untuk berpindah dari Diciutkan ke Diperluas.

Untuk menganimasikan ikon - mungkin kontrol Lottie dapat digunakan di sini?

Pikiran lain, sama seperti Anda memiliki RadioButton dan RadioButtons sebagai grup dari mereka...

Haruskah sekelompok Ekspander membuat Kontrol Akordeon? Mana yang memungkinkan perilaku di mana hanya satu expander yang dapat diperluas pada satu waktu?

https://explore.fast.design/components/fast-accordion

Re-templating selalu menjadi pilihan, jika mesin terbang atau font khusus tidak cukup.

Font Glyphs baik dengan Segoe MDL2 atau FluentIcons adalah yang paling mungkin dan mungkin harus menjadi default;

Tidak ada mesin terbang sama sekali juga umum;

Lalu ada jalur, SVG yang kecil kemungkinannya tetapi sangat mungkin;

Dan kemudian PNG atau bitmap penuh sebagai opsi yang tidak mungkin tetapi mungkin untuk pengembang.

Pendekatan apa pun yang digunakan, mungkin harus fokus pada dua skenario pertama, tetapi selalu memungkinkan re-templating untuk yang ketiga.

Retemplating akan selalu menjadi pilihan, namun tentu saja itu adalah sesuatu yang bisa rusak seiring waktu jika ada perubahan (besar) pada kontrol. Jadi memiliki sumber daya yang ringan mungkin adalah yang terbaik di sini karena mengganti mesin terbang (dan font ikon) adalah skenario yang paling umum.

Lalu ada kemungkinan untuk memiliki ContentPresenter untuk mesin terbang, dan mengizinkan apa pun untuk diletakkan di atasnya. Tetapi tidak yakin bagaimana cara kerjanya dengan VisualStates untuk berpindah dari Diciutkan ke Diperluas.

Menggunakan ContentPresenter tidak membuat perbedaan tentang menciutkan/memperluas, itu hanya akan menjadi elemen seperti yang lain.

Untuk menganimasikan ikon - mungkin kontrol Lottie dapat digunakan di sini?

Pertanyaannya adalah jenis animasi apa yang ingin Anda miliki. Rotasi sederhana dapat (dan sedang) dilakukan tanpa lottie.

Pikiran lain, sama seperti Anda memiliki RadioButton dan RadioButtons sebagai grup dari mereka...

Haruskah sekelompok Ekspander membuat Kontrol Akordeon? Mana yang memungkinkan perilaku di mana hanya satu expander yang dapat diperluas pada satu waktu?

Mungkin itu bisa menjadi kontrol terpisah? Meskipun ada skenario di mana mereka bisa eksklusif satu sama lain, saya pikir dalam banyak kasus, tidak masalah jika banyak yang terbuka.

Lalu ada kemungkinan untuk memiliki ContentPresenter untuk mesin terbang, dan mengizinkan apa pun untuk diletakkan di atasnya. Tetapi tidak yakin bagaimana cara kerjanya dengan VisualStates untuk berpindah dari Diciutkan ke Diperluas.

Menggunakan ContentPresenter tidak membuat perbedaan tentang menciutkan/memperluas, itu hanya akan menjadi elemen seperti yang lain.

Tetapi apakah itu ContentPresenter yang digunakan oleh kedua negara bagian, atau satu per negara bagian yang ditukar/dimatikan?

Untuk menganimasikan ikon - mungkin kontrol Lottie dapat digunakan di sini?

Pertanyaannya adalah jenis animasi apa yang ingin Anda miliki. Rotasi sederhana dapat (dan sedang) dilakukan tanpa lottie.

Rotasi masuk akal ketika mesin terbang adalah panah arah / chevron - tetapi bagaimana jika bola lampu menyala dan mati untuk beberapa jenis tip atau skenario petunjuk? Ada proposal untuk kontrol ikon animasi umum menggunakan Lottie #2802 - apakah situasi ini memerlukan ini, bahkan jika penggunaan default/paling umum mungkin berupa rotasi ikon sederhana?

Pikiran lain, sama seperti Anda memiliki RadioButton dan RadioButtons sebagai grup dari mereka...
Haruskah sekelompok Ekspander membuat Kontrol Akordeon? Mana yang memungkinkan perilaku di mana hanya satu expander yang dapat diperluas pada satu waktu?

Mungkin itu bisa menjadi kontrol terpisah? Meskipun ada skenario di mana mereka bisa eksklusif satu sama lain, saya pikir dalam banyak kasus, tidak masalah jika banyak yang terbuka.

Saya menyebutkannya hanya karena Desain Cepat menyertakan kontrol akordeon, dan pada dasarnya sama dengan sekelompok ekspander - hanya saja ada API perilaku Multi dan Tunggal yang mengubah cara mereka bekerja bersama. Dengan kontrol Expander yang dibuat, Accordion akan menjadi langkah logis berikutnya dan harus relatif mudah dicapai dengan properti orientasi untuk mengesampingkan arah individu.

Lalu ada kemungkinan untuk memiliki ContentPresenter untuk mesin terbang, dan mengizinkan apa pun untuk diletakkan di atasnya. Tetapi tidak yakin bagaimana cara kerjanya dengan VisualStates untuk berpindah dari Diciutkan ke Diperluas.

Menggunakan ContentPresenter tidak membuat perbedaan tentang menciutkan/memperluas, itu hanya akan menjadi elemen seperti yang lain.

Tetapi apakah itu ContentPresenter yang digunakan oleh kedua negara bagian, atau satu per negara bagian yang ditukar/dimatikan?

Kedua opsi masuk akal. Saya pikir mengganti konten ContentPresenter lebih baik daripada menukar ContentPresenter atau memiliki dua dan menyembunyikan/menampilkan satu.

Untuk menganimasikan ikon - mungkin kontrol Lottie dapat digunakan di sini?

Pertanyaannya adalah jenis animasi apa yang ingin Anda miliki. Rotasi sederhana dapat (dan sedang) dilakukan tanpa lottie.

Rotasi masuk akal ketika mesin terbang adalah panah arah / chevron - tetapi bagaimana jika bola lampu menyala dan mati untuk beberapa jenis tip atau skenario petunjuk? Ada proposal untuk kontrol ikon animasi umum menggunakan Lottie #2802 - apakah situasi ini memerlukan ini, bahkan jika penggunaan default/paling umum mungkin berupa rotasi ikon sederhana?

Animasi rotasi akan menjadi salah satu cara untuk menghidupkan dan akan mudah dicapai. Memiliki ikon yang dianimasikan menjadi ikon yang berbeda akan sangat berbeda. Itu juga mungkin akan membuat API lebih rumit (bagaimana Anda mendukung perilaku seperti itu? 2 animasi dan 2 ikon? atau satu animasi yang Anda hentikan?)

Pikiran lain, sama seperti Anda memiliki RadioButton dan RadioButtons sebagai grup dari mereka...
Haruskah sekelompok Ekspander membuat Kontrol Akordeon? Mana yang memungkinkan perilaku di mana hanya satu expander yang dapat diperluas pada satu waktu?

Mungkin itu bisa menjadi kontrol terpisah? Meskipun ada skenario di mana mereka bisa eksklusif satu sama lain, saya pikir dalam banyak kasus, tidak masalah jika banyak yang terbuka.

Saya menyebutkannya hanya karena Desain Cepat menyertakan kontrol akordeon, dan pada dasarnya sama dengan sekelompok ekspander - hanya saja ada API perilaku Multi dan Tunggal yang mengubah cara mereka bekerja bersama. Dengan kontrol Expander yang dibuat, Accordion akan menjadi langkah logis berikutnya dan harus relatif mudah dicapai dengan properti orientasi untuk mengesampingkan arah individu.

Benar, saya mengerti. Ya, kontrol akordeon jelas merupakan ide bagus setelah kontrol expander dan mungkin akan mudah diterapkan!

Rotasi masuk akal ketika mesin terbang adalah panah arah / chevron - tetapi bagaimana jika bola lampu menyala dan mati untuk beberapa jenis tip atau skenario petunjuk? Ada proposal untuk kontrol ikon animasi umum menggunakan Lottie #2802 - apakah situasi ini memerlukan ini, bahkan jika penggunaan default/paling umum mungkin berupa rotasi ikon sederhana?

Animasi rotasi akan menjadi salah satu cara untuk menghidupkan dan akan mudah dicapai. Memiliki ikon yang dianimasikan menjadi ikon yang berbeda akan sangat berbeda. Itu juga mungkin akan membuat API lebih rumit (bagaimana Anda mendukung perilaku seperti itu? 2 animasi dan 2 ikon? atau satu animasi yang Anda hentikan?)

Ini adalah pertanyaan besar, dan sejujurnya, adalah sesuatu untuk proposal Ikon Animasi.

Menganimasikan mesin terbang/ikon baik-baik saja jika itu akan selalu berupa panah. Tapi itu semacam mengunci itu, kecuali jika Anda memiliki cara mudah untuk menghapus atau mengubah animasi itu sendiri.

Membuat animasi Lottie yang berputar mempertahankan animasi default, berarti sedikit lebih banyak pekerjaan untuk diterapkan, tetapi lebih fleksibel dalam memungkinkan mengubah ikon dan animasi jika diperlukan.

Opsi termudah adalah tidak memiliki animasi untuk mesin terbang. Tetapi semakin banyak Anda menambahkan, membuatnya mudah untuk ditimpa atau diubah menjadi lebih penting.

Melihat melalui web, saya melihat cukup banyak ikon statis yang digunakan untuk mesin terbang yang diperluas/diciutkan dalam contoh UI Expander yang khas. Namun, di Windows, kami juga memiliki pelanggan potensial dari kontrol ini yang tampaknya lebih menyukai animasi (lihat misalnya NavigationView dan pemberitahuan toast di shell). Motion adalah salah satu landasan Fluent Design, jadi mungkin masuk akal di sini untuk tetap membuka opsi bagi pelanggan yang menginginkan mesin terbang animasi tanpa perlu mengubah template kontrol.

Idealnya, jika tim yang berbeda di MS ingin menggunakan Expander dengan mesin terbang animasi (yaitu mesin terbang panah animasi), kontrol akan memberikan opsi bawaan sehingga kami akhirnya memiliki pengalaman yang konsisten secara default. Jika masing-masing tim bertanggung jawab atas animasinya sendiri, kita mungkin akan melihat durasi animasi yang berbeda, arah animasi yang berbeda (yaitu searah jarum jam atau berlawanan arah jarum jam),...Jika saya ingat dengan benar, animasi mesin terbang untuk pemberitahuan di pusat tindakan berbeda dengan animasi mesin terbang di NavigationView. Itu harus dihindari, jika memungkinkan.

Animasi sangat menyenangkan, dan membantu membuat UI terasa mulus. Pengodean keras dalam Storyboard rotasi, adalah cara sederhana untuk menambahkan animasi, tetapi jika animasi itu sulit untuk dihapus, atau diubah - mungkin menggunakan kontrol AnimatedIcon akan menjadi cara yang baik untuk membuat cara yang fleksibel untuk mengaktifkan penyesuaian.

Saya tidak mengatakan satu cara lebih baik dari yang lain - hanya membawanya ke perhatian di sini, karena menjiwai ikon, dan itu adalah Raison Detra untuk kontrol baru.

Dan jika telah diakui bahwa mesin terbang harus dapat disesuaikan - animasi rotasi mungkin tidak selalu sesuai.

Apa yang harus dianimasikan dan apa yang tidak dianimasikan adalah pertanyaan yang sangat sulit. Seperti yang telah disebutkan Martin, animasi rotasi tidak selalu masuk akal. Dan ikon animasi masih memiliki banyak pertanyaan terbuka.

Saya pikir mungkin lebih baik untuk menggores animasi mesin terbang/ikon untuk v1, terutama karena itu tidak terlalu umum. Satu hal yang perlu dipertimbangkan kembali adalah jika kita menghapus animasi yang ada pada NavigationView hierarki untuk mendapatkan pengalaman yang seragam. Saat ini sudah ada inkonsistensi antara TreeView dan h-NavigationView untuk menganimasikan/tidak menganimasikan pergantian ikon.

Tepat. Saya tidak bermaksud untuk mencegah eksplorasi apa pun di sini dengan paragraf terakhir saya, tetapi hanya menulis sekali lagi bahwa salah satu tantangan yang kami hadapi di sini adalah tentang menyediakan opsi penyesuaian yang cukup di luar "yang utama" - re-templating - untuk memuaskan pelanggan umum ingin, namun tetap memastikan bahwa kontrol akan membantu membawa lebih banyak konsistensi ke Windows, bukannya berpotensi lebih sedikit.

Seperti yang telah kita lihat mungkin tidak ada solusi sempurna di sini karena keinginan untuk menyediakan kustomisasi ikon dan dukungan animasi (mungkin selain animasi bawaan untuk konsistensi) dapat dengan mudah bertabrakan satu sama lain.

Akan sangat membantu untuk mendapatkan pelanggan potensial seperti Windows Shell di sini untuk melihat bagaimana mereka melihat animasi. 10X seharusnya akan menempatkan beberapa fokus pada animasi dan Windows Shell dan aplikasi Windows dalam kotak bisa menjadi "pelanggan" di sini. Jika mesin terbang animasi dianggap sebagai bagian penting dalam keseluruhan UX yang diperjuangkan oleh tim Windows dengan 10X, itu mungkin tidak memerlukan "punting" pada tantangan ini untuk saat ini, melainkan menampilkan dukungan animasi di V1.

Saya ingin melihat pendekatan yang konsisten untuk menganimasikan ikon, yang saat ini tampaknya merupakan proposal Ikon Animasi.

Saya tidak akan menghapus animasi apa pun dari NavigationView, karena ini adalah paradigma baru yang sepenuhnya mandiri untuk WinUI - dan sepertinya tujuannya adalah untuk menambahkan animasi ke semua kontrol serupa ini - jadi mungkin setelah siap, kontrolnya bisa ditambahkan ke NavigationView

Kedengarannya ElementAnimator terlalu banyak untuk menganimasikan Expander, dan ExpandTransition dan CollapseTransition sudah cukup.

@mdtauk terima kasih telah membuat animasi mock-up! Saya mengerti apa yang Anda maksud dengan animasi yang mengembang dan menciut.

Saya percaya bahwa perilaku akordeon akan dicapai melalui logika tingkat daftar (daripada kontrol Accordion baru) dengan IsExpanded bagi pengembang untuk menyesuaikan ini dengan skenario yang berbeda (Mis: di mana beberapa Ekspander saling menutup dan yang lainnya dapat diperluas secara bersamaan).

@Felix-Dev - Saya telah menambahkan Telerik Expander ke proposal, terima kasih telah membagikannya!

Kedengarannya ada keinginan untuk penyesuaian dalam arah berikut:

Penampilan mesin terbang : gaya ringan tampaknya menjadi rute yang lebih disukai untuk mengganti mesin terbang dan font ikon, dengan memiliki ExpanderExpandGlyph dan ExpanderCollapseGlyph . Apakah tingkat penyesuaian ini diperlukan di v1 Expander?

@Felix-Dev Sementara pengembang mungkin masih bisa menimpa FontFamily (disediakan oleh sumber SymbolThemeFontFamily), kami hanya akan langsung mengekspos ExpanderExpandGlyph ... sehingga pengembang berpotensi pertama kali melihat keluarga font MDL2 jika mereka ingin sesuaikan ikon (karena itu akan menjadi keluarga font default yang digunakan oleh Expander untuk mesin terbang).

Animasi mesin terbang : termasuk perubahan ke mesin terbang yang berbeda saat ekspansi - yang sebagian diselesaikan dengan AnimatedIcon #2802. Sepertinya tingkat penyesuaian ini tidak diperlukan untuk v1 Expander.
@chingucoding menyatakan dan saya cenderung setuju:

Saya pikir mungkin lebih baik untuk menggores animasi mesin terbang/ikon untuk v1, terutama karena itu tidak terlalu umum.

Posisi mesin terbang : Apakah tingkat penyesuaian ini diperlukan di v1 Expander? Ini lebih rumit jika v1 menyertakan ExpandDirection dan opsi untuk mengubah posisi mesin terbang. @Felix-Dev dijelaskan

Sesuatu seperti ExpandGlyphPlacementMode dengan nilai seperti TopLeft, TopRight, BottomCentered (dan mungkin lebih (Kiri, Kanan, ...)) dan pengembang properti ExpandGlyphPlacementOffset tambahan dapat digunakan untuk mengubah posisi dasar (ditetapkan oleh mode penempatan) jika diperlukan.

Semoga saya telah memahami dengan benar diskusi hebat dari akhir pekan ini - beri tahu saya jika saya salah di suatu tempat! Terima kasih banyak atas pemikiran Anda yang mendalam tentang ini. 😄

Penampilan Glyph
Posisi Glyph

Saya pikir ini adalah penyesuaian yang paling mudah dan paling penting untuk disertakan dalam V1.

Saya juga akan menambahkan cara untuk menyembunyikan Glyph

Animasi Glyph
Transisi Negara

Ini dapat diberikan prioritas yang lebih rendah jika Prioritas diperlukan dan perilaku serta fungsionalitas inti memakan waktu terlalu lama.

Terima kasih atas prioritas ordernya @mdtauk!

Saya telah menambahkan pertanyaan terbuka baru:

• Bagaimana seharusnya Expander bekerja dengan InfoBar? Menambahkan fungsionalitas yang diperluas ke InfoBar? Menempatkan InfoBar sebagai konten Expander? Kebalikannya?

Saya akan membayangkan itu akan menggantikan konten, tetapi saya pikir mereka yang mendesain bilah informasi harus memberikan spesifikasi desain untuk bilah yang dapat dilipat, yang dapat dilihat oleh perancang expander.

Ini adalah percakapan yang harus dilakukan

Ada _banyak_ percakapan hebat di sini! Tema animasi...

Kedengarannya seperti ElementAnimator terlalu banyak untuk menganimasikan Expander, dan ExpandTransition dan CollapseTransition sudah cukup.

Setuju bahwa ElementAnimator terlalu banyak untuk menganimasikan Expander. Mungkin berhasil jika semuanya ada di ItemsRepeater, tetapi ElementAnimator belum berfungsi di luar ItemsRepeater jadi kami harus mencari tahu.

Saya menyukai gagasan memiliki ExpandTransition dan CollapseTransition dalam teori, tetapi kami mendapat banyak umpan balik bahwa API Transisi bagus secara teori tetapi kurang bagus dalam praktiknya karena tidak dapat disesuaikan, umumnya digabungkan erat dengan kontrol di yang mereka gunakan, dan saya tidak berpikir mereka dapat dibangun di seri WinUI 2.x karena mereka bergantung pada kait OS. Karena transisi khusus ini tidak ada, saya lebih suka menjelajahi opsi lain daripada menambahkan ke koleksi API ThemeTransition kami.

Di atas semua itu, area umum "animasi tata letak" di mana konten bergerak sebagai akibat dari elemen UI baru yang masuk/meningkat/menyusut/meninggalkan halaman tidak didukung dengan baik di Xaml sebagai platform saat ini. Memperbaiki ini juga akan membutuhkan WinUI 3, tetapi tidak ada di peta jalan langsung.

Khususnya untuk Expander, saya pikir tindakan yang tepat kemungkinan akan berakhir sebagai:
1) Hard-code animasi grow/shrink dalam kode Expander (dan pertimbangkan untuk menyertakan API untuk mematikannya - meskipun menurut saya pribadi tidak perlu)
2) Memberikan panduan kepada pengembang aplikasi tentang cara menganimasikan konten di sekitar Expander sehingga konten di bawah Expander meluncur ke bawah daripada "melompat" ke bawah

Saya tidak berpikir (2) dapat diselesaikan secara umum tanpa "animasi tata letak" tetapi mungkin dapat diselesaikan menggunakan RepositionThemeAnimation pada konten di bawah Expander.

@stmoy Kita bisa menggunakan PopInThemeAnimation untuk (1) jika kita ingin menggunakan yang sudah ada.

Proposal ini telah disetujui untuk penulisan spesifikasi .

Sebagai bagian dari diskusi dengan tim WinUI, kami memutuskan bahwa Expander dapat dicakup untuk mendukung ExpandDirection untuk ekspansi naik/turun di V1. Ini mencakup skenario yang telah kami lihat untuk Expander dan meletakkan dasar untuk berpotensi menambahkan ekspansi kiri/kanan di masa mendatang.

Harap didorong untuk melanjutkan diskusi di sini, dan diskusi yang lebih mendetail akan terjadi pada Spec dan PR terkait setelah tersedia. Akan sangat senang mendengar pendapat Anda tentang pertanyaan terbuka ini:

• Bagaimana seharusnya Expander bekerja dengan InfoBar? Menambahkan fungsionalitas yang diperluas ke InfoBar? Menempatkan InfoBar sebagai konten Expander? Kebalikannya?

Untuk InfoBar, saya rasa saya perlu membuka proposal terpisah untuk menyelami apa yang secara spesifik dibutuhkan dan bagaimana ia dapat memanfaatkan kontrol Expander ini. Inilah beberapa pemikiran pertama saya:

• InfoBar perlu menyesuaikan header dan konten/panel kontrol Expander. InfoBar akan menampilkan pesan "cut-off" di header saat diciutkan dan pesan lengkap di konten/panel yang diperluas saat dibuka.
• InfoBar tidak _memiliki_ untuk mengizinkan pemotongan dan opsi harus ada di sana bagi pengembang untuk memilih perilaku pembungkusan saat ini jika diperlukan melalui properti "shouldTruncate".
• InfoBar dapat/harus "menjadi" Expander jika konten tidak lagi muat pada satu baris dan shouldTruncate disetel ke true. Menerapkan ini dan memahami kapan tepatnya untuk menambahkan perilaku perluasan adalah tempat yang rumit 😊 MessageBar mengurangi ini melalui properti isMultiline mereka tetapi pemikiran lebih lanjut perlu masuk ke area ini.

Saya pikir kita juga dapat melihat kontrol lain di WinUI saat ini yang mungkin mendapat manfaat dari perilaku Expander ini.

Beberapa comps awal untuk memotong InfoBar:

Untuk implementasi, pemikiran awal saya adalah bahwa InfoBar harus berasal dari Expander dan tidak bersarang di dalam konten Expander. Pikiran?

Saya pikir kita juga dapat melihat kontrol lain di WinUI saat ini yang mungkin mendapat manfaat dari perilaku Expander ini.

Beberapa comps awal untuk memotong InfoBar:

Saya pikir Expander mungkin harus dapat memisahkan Tombol Chevron dari Konten yang sedang diperluas.

Pemberitahuan melakukan ini

Itu juga akan memungkinkan kontrol InformationBar untuk mengintegrasikan Expander-nya.

Jika Anda memisahkannya, apakah itu menjadi perilaku/properti? Jadi jika Anda menentukan Elemen atau Tombol UI untuk properti ini, Header Expander tidak menampilkan Tombolnya?

Untuk implementasi, pemikiran awal saya adalah bahwa InfoBar harus berasal dari Expander dan tidak bersarang di dalam konten Expander. Pikiran?

Jika Expander tidak dapat memisahkan Konten dan Header dari Tombol Toggle/Disclose - maka itu akan membutuhkan lebih banyak pekerjaan untuk diterapkan oleh InformationBar.

Kontrol Expander harus sefleksibel mungkin secara khusus untuk diintegrasikan ke dalam berbagai Kontrol lainnya di masa mendatang, serta untuk digunakan di Shell Windows

Saya telah menambahkan info awal ke spesifikasi Expander dan membuka PR - silakan lanjutkan diskusi spesifikasi di sana! Ini PR 100 pada repo spesifikasi