برنامج Expander مفيد للغاية ولقد كنت أستخدم إصدار Windows Community Toolkit منذ إضافته. لن أعيد ابتكار العجلة كثيرًا ، لكن مجرد نقل الكود من مجموعة الأدوات سيكون مثالياً للإصدار 1.0 في رأيي.

مثال آخر: يمكن أن يستخدم ColorPicker مع "MoreButton" هذا.

شكرا جزيلا لتقديم هذا الاقتراح! سأقوم بإجراء بعض التعديلات ، بما في ذلك التمييز بين ما أعتقد أنه سيناريوهات Expander الحقيقية وما يشبه استخدامات Flyout / MenuFlyout.

لقد قمت بتحديث هذا الاقتراح ليشمل المزيد من التفاصيل حول النطاق وواجهة برمجة التطبيقات المقترحة والسؤال المفتوح التالي.

• هل نحتاج إلى دعم ExpandDirection في v1 Expander؟ هل هناك سيناريوهات شائعة للتطبيق يحتاج فيها برنامج Expander إلى التوسع في اتجاهات أخرى غير الاتجاه التنازلي؟

أود الحصول على تعليقات حول مدى ملاءمتها أو عدم ملاءمتها لحالات الاستخدام الخاصة بك لـ Expander!

لقد قمت بتحديث هذا الاقتراح ليشمل المزيد من التفاصيل حول النطاق وواجهة برمجة التطبيقات المقترحة والسؤال المفتوح التالي.

• هل نحتاج إلى دعم ExpandDirection في v1 Expander؟ هل هناك سيناريوهات شائعة للتطبيق يحتاج فيها برنامج Expander إلى التوسع في اتجاهات أخرى غير الاتجاه التنازلي؟

أود الحصول على تعليقات حول مدى ملاءمتها أو عدم ملاءمتها لحالات الاستخدام الخاصة بك لـ Expander!

يبدو وكأنه وظيفة أساسية للتحكم

يبدو وكأنه وظيفة أساسية للتحكم

mdtauk هل ترى أن ExpandDirection بخلاف downward هو سيناريو تطبيق شائع؟ الأمثلة على سلوكيات Expander التي أراها تتوسع في كثير من الأحيان إلى الأسفل - أود بالتأكيد أن يكون لدى Expand ExpandDirection ولكن هل هذا ضروري في الإصدار 1؟

نعم ، نحن بحاجة إلى توسيع الاتجاه. هناك العديد من الحالات لاستخدامه وسيكون تغيير كسر غير ضروري لقالب التحكم بعد إصدار v1 لإضافته. لم يتغير Expander API كثيرًا منذ WPF ويحتوي الاقتراح هنا على جميع الخصائص / الأحداث / الطرق الضرورية بالفعل. سأقوم بتطبيقها كلها في لقطة واحدة ويمكننا فعل ذلك باستخدام عنصر التحكم هذا. من ناحية التصميم ، أجرت مجموعة أدوات مجتمع UWP التغييرات اللازمة للعمل بشكل أفضل مع اللمس. أعتقد أن لدينا كل القطع ولا داعي لإعادة ابتكار أي شيء.

تحرير: تحتوي مجموعة أدوات المجتمع أيضًا على خاصية ContentOverlay . قد يكون هذا شيئًا يجب تخطيه في V1.

نعم ، نحن بحاجة إلى توسيع الاتجاه. هناك العديد من الحالات لاستخدامه وسيكون تغيير كسر غير ضروري لقالب التحكم بعد إصدار v1 لإضافته.

robloo هل يمكنك توضيح كيف سيكون هذا

يبدو وكأنه وظيفة أساسية للتحكم

mdtauk هل ترى أن ExpandDirection بخلاف downward هو سيناريو تطبيق شائع؟ الأمثلة على سلوكيات Expander التي أراها تتوسع في كثير من الأحيان إلى الأسفل - أود بالتأكيد أن يكون لدى Expand ExpandDirection ولكن هل هذا ضروري في الإصدار 1؟

ربما تكون تطبيقات الدردشة التي تقوم بتحميل محتوى قائمة جديد من الأسفل إلى الأعلى واحدة منها.

أبعد من الأساسيات الأساسية:

• انهار
• يزداد
• موسع
• ينهار

وكذلك IsEnabled

الشيء الأساسي التالي هو أين تتوسع.

• توسيع
• توسيع للأسفل
• توسيع لليسار
• قم بتوسيع يمين

ربما تكون تطبيقات الدردشة التي تقوم بتحميل محتوى قائمة جديد من الأسفل إلى الأعلى واحدة منها.

mdtauk لا أفهم تمامًا ما
بالنسبة للخصائص - تعتمد واجهة برمجة التطبيقات المقترحة على WPF Expander لذا أعتقد أن IsExpanded و ExpandDirection سيغطيانها. ما الذي يمكن استخدام IsEnabled له - هل هناك سيناريو تطبيق تريد فيه تعطيل برنامج Expander؟

مثال آخر استخدمته في الماضي هو الخصائص الثانوية القابلة للتحرير والتي يجب إخفاؤها عادةً. تظهر هذه في الجزء السفلي من المحرر فقط عند النقر فوق زر "خيارات" ويفتح الموسع لأعلى. إنه حقًا يتعلق بالتصميم الذي تريده. هناك العديد من الحالات المفيدة لتوسيع الاتجاهات المختلفة ويبدو أنه من غير الضروري تقييد هذا بشكل مصطنع خاصة عندما تكون الاتفاقية السابقة قوية جدًا. لا أعتقد أن أيًا من هذا سيكون صعبًا للغاية في V1 من عنصر التحكم خاصة وأن جميع المشكلات قد تم حلها بالفعل في مجموعة أدوات المجتمع و WPF.

robloo هل يمكنك توضيح كيف سيكون هذا

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

أفترض أنك إذا كنت حريصًا جدًا في تصميم القالب والحالات المرئية ، فمن الممكن جعله غير قابل للكسر. ومع ذلك ، للقيام بذلك ، تحتاج حقًا إلى تصميم الوظيفة على أي حال حتى تتمكن من تنفيذها أيضًا. كل هذا أساسي إلى حد ما ولا يوجد سبب لخطة V2 من البداية على هذا التحكم.

أعلم أنه من المغري إعادة اختراع العجلة. ولكن يرجى الاحتفاظ بها حتى يتمكن الأشخاص الذين ينقلون التطبيقات من WPF إلى WinUI من القيام بذلك دون أي شيء سوى تغييرات التعليمات البرمجية الضرورية للغاية. يحتاج WinUI إلى البدء في تصحيح بعض الأخطاء باستخدام UWP.

ما الذي يمكن استخدام IsEnabled له - هل هناك سيناريو تطبيق تريد فيه تعطيل برنامج Expander؟

mdtauk صحيح ، هذا يحتاج إلى دعم IsEnabled أيضًا. يعد تعطيل عناصر التحكم بمثابة اصطلاح قوي جدًا في أي وقت توجد فيه إمكانية لتغيير الإدخال أو الحالة. من فضلك لا تجعلنا ندافع عن ذلك.

في لقطات الشاشة أعلاه ، يحتوي أمان windows على موسع لقسم مكافحة الفيروسات بالإضافة إلى قائمة التنقل اليسرى. يوضح هذا استخدامًا واقعيًا جدًا للموسع في أكثر من اتجاه والذي ستحتاج إليه الكثير من التطبيقات. تصويتي هو لدعم اتجاهات متعددة في V1.

تضمين التغريدة

مثال آخر استخدمته في الماضي هو الخصائص الثانوية القابلة للتحرير والتي يجب إخفاؤها عادةً. تظهر هذه في الجزء السفلي من المحرر فقط عند النقر فوق زر "خيارات" ويفتح الموسع لأعلى.

هل يمكنك التفصيل باستخدام لقطة شاشة أو تطبيق محدد حيث يحدث ذلك حتى أتمكن من فهم السيناريو أكثر؟ يمكنني التفكير في المحررين حيث يفتح زر الخيارات نافذة منبثقة بها المزيد من الأزرار ، ولكن في الأزرار التي أعرفها لا يتم دفع المحتوى الآخر لأعلى - سلوك منبثق / منبثق بدلاً من توسيع.

أفترض أنك إذا كنت حريصًا جدًا في تصميم القالب والحالات المرئية ، فمن الممكن جعله غير قابل للكسر. ومع ذلك ، للقيام بذلك ، تحتاج حقًا إلى تصميم الوظيفة على أي حال حتى تتمكن من تنفيذها أيضًا. كل هذا أساسي إلى حد ما ولا يوجد سبب لخطة V2 من البداية على هذا التحكم.
أعلم أنه من المغري إعادة اختراع العجلة. ولكن يرجى الاحتفاظ بها حتى يتمكن الأشخاص الذين ينقلون التطبيقات من WPF إلى WinUI من القيام بذلك دون أي شيء سوى تغييرات التعليمات البرمجية الضرورية للغاية.

أتفق معك في أن نقل التطبيقات من WPF إلى WinUI يجب أن يكون سلسًا قدر الإمكان! أثناء المناقشة مع فريق WinUI ، تم طرح أن الإصدار V1 الذي تم تحديد نطاقه للتوسع إلى أسفل من شأنه أن يقصر وقت التطوير ويجعل Expander متاحًا للمطورين في وقت أقرب (نظرًا لأن سيناريوهات Expander حتى الآن كانت جميعها متجهة إلى أسفل) ، ويمكن لـ V2 المخطط لها إضافة ExpandDirection قريبا. (سأقوم بتحرير السؤال المفتوح للحصول على هذا السياق الإضافي) لهذا السبب آمل أن أفهم ما إذا كانت هناك حالات استخدام محددة لدى المطورين لـ Expander غير المتجه لأسفل! 😄

يعد تعطيل عناصر التحكم بمثابة اصطلاح قوي جدًا في أي وقت توجد فيه إمكانية لتغيير الإدخال أو الحالة. من فضلك لا تجعلنا ندافع عن ذلك.

شكرًا لتوضيح ذلك ، فمن المنطقي تمامًا أن تعطيل تغيير الحالة هو ميزة مرغوبة لهذا النوع من التحكم!

في لقطات الشاشة أعلاه ، يحتوي أمان windows على موسع لقسم مكافحة الفيروسات بالإضافة إلى قائمة التنقل اليسرى. يوضح هذا استخدامًا واقعيًا جدًا للموسع في أكثر من اتجاه والذي ستحتاج إليه الكثير من التطبيقات. تصويتي هو لدعم اتجاهات متعددة في V1.

@ JustABearOz أعتقد أن قائمة التنقل اليسرى عبارة عن NavigationView ، في الواقع. 😃 أوافق على أن قسم مكافحة الفيروسات هو سيناريو Expander ، في هذه الحالة يتم توسيعه نزولاً. أرغب في معرفة أي حالات استخدام محددة لديك لـ Expander غير المتجه لأسفل!

@ kat-y Ok ، هذا يلغي الحاجة إلى اليسار / اليمين ، ولكن هناك مثالان في النوافذ يبدو أنهما يتسعان ويمكن تطبيقهما بسهولة على التطبيقات:
1: لقطة الشاشة أعلاه مع قائمة الإجراءات السريعة. متأكد من أن يتوسع.
2: في النوافذ ، يشتمل التقويم المنبثق من علبة النظام على قسم يتم توسيعه لإظهار جدول الأعمال / المواعيد.

هل من الممكن دعم Up / Down لـ V1 بدلاً من Down فقط؟

1: لقطة الشاشة أعلاه مع قائمة الإجراءات السريعة. متأكد من أن يتوسع.

JustABearOz شكرًا جزيلاً على طرح هذه الأمثلة! بالنسبة إلى 1: أعتقد أن هذه حالة حافة مثيرة للاهتمام - التمدد "لأسفل" من "الرأس" (زر التوسيع) ، ولكن عنصر التحكم نفسه موجود في أسفل السطح بحيث يكون الرأس (والمحتوى الموسع) يجب أن "يتحول" لأعلى (وإلا فإنه سيخرج من الشاشة!). يبدو أنه طريقة جيدة للتعامل مع وجود عنصر موسع في "الجزء السفلي" من التطبيق ، هل توافق؟

2: في النوافذ ، يشتمل التقويم المنبثق من علبة النظام على قسم يتم توسيعه لإظهار جدول الأعمال / المواعيد.
هل من الممكن دعم Up / Down لـ V1 بدلاً من Down فقط؟

أنا أتفق معك ، هذا سيناريو حيث يكون الرأس في أسفل المنطقة ويتوسع لأعلى! في هذه الحالة ، يكون موسع التقويم (والنافذة المنبثقة ككل) مرتبطًا بشريط المهام - هل صادفت سيناريوهات في التطبيقات حيث يكون للموسعين موضع مقيد مشابه يستلزم توسعًا تصاعديًا؟

@ kat-y لا أعني أي إهانة لكني أشعر أننا مضطرون إلى إعادة شرح الأشياء التي كانت معروفة منذ 15 عامًا. لا أفهم سبب مطالبتك بإعطاء أمثلة لتوسيع الاتجاه في الاستخدام في العالم الحقيقي. أتوقع داخليًا عليك أن تأخذ هذا لمراجعة محددة والدفاع عنها للإدارة. ولكن يمكن أن يكون التفسير ببساطة هو (1) أنك تحتاج إلى تمكين المستخدمين من تحقيق أهداف التصميم الخاصة بهم ، فليس الأمر متروكًا لـ Microsoft لتقول ما هو / لا يمكن القيام به باستخدام عناصر التحكم ، فالأمر متروك لمطوري / مصممي التطبيقات لاكتشاف الأفضل لحالة الاستخدام الخاصة بهم (مفهوم حاسم لعناصر التحكم التي لا تبحث) (2) الأهم من ذلك ، هذه ليست فكرة جديدة على الإطلاق. أنت تنسخ واجهة برمجة تطبيقات موجودة في هذه المنطقة وتحتاج إلى الحفاظ على توافق التطبيق. مرة أخرى ، إذا كانت هذه فكرة جديدة ، فسأفهم أكثر لماذا يتعين علينا الدفاع عنها - من الجيد التأكد من أن الميزات مفيدة قبل استثمار الوقت فيها.

بصرف النظر عن العنوان ، توجد خاصيتان حرفيتان في عنصر التحكم هذا ، وإذا كان C # يمكنني كتابته في غضون ساعات قليلة باستخدام قاعدة WCT. سنقضي ساعات عمل في الحديث عنها أكثر من تنفيذها كما هي موجودة اليوم في WPF / WCT.

شكرًا robloo على المدخلات ، أتواصل مع فريق WinUI لمناقشة كيف يمكننا جعل هذه المقترحات أكثر قوة في البداية عندما تكون موجودة في مكتبات الجهات الخارجية الأخرى مثل Toolkit. أعتقد بالتأكيد أنه يجب أن يكون جزءًا من قالب المشكلة لاستدعاء الأمثلة الموجودة.

لمعلوماتكranjeshjryandemopoulosstmoy

robloo شكرا لك على

في السابق لم يكن لدي أي أمثلة ملموسة لاستخدام الموسعات في اتجاه غير تنازلي. سأحضر أي أمثلة من مجتمع WinUI (بما في ذلك قائمة التقويم المنبثقة التي أشار إليها

لقد قمت بتحديث الاقتراح بقائمة من عناصر تحكم Expander التي أعلم بها - أعلمني إذا فاتني شيء ما.

• WPF
• مجموعة أدوات مجتمع Windows
• Telerik UI
• Xamarin. الأشكال
• Syncfusion.XForms.Expander

لقد ألقيت نظرة على كود مصدر WPF وكود مصدر WCT. أنا واثق من أنه يمكن تنفيذ ذلك في WinUI في غضون ساعات قليلة أيضًا. يجب أن يتبع عنصر التحكم تنفيذ WCT مما رأيته على الرغم من أنه ربما يجب إعادة تسمية الخاصية ContentOverlay أو تركها خارج 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

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

نظرًا لأن كلا هذين المصدرين من Microsoft ومرخص لهما من معهد ماساتشوستس للتكنولوجيا ، فيجب أن يكونا القاعدة ، ولا تبدأ من الصفر. لا تتوافق نماذج Xamarin مع مفاهيم WPF-> WinUI ، لذا من المحتمل أن يتم تجاهلها (لا توجد وظائف إضافية أيضًا). لا تحتوي حلول الجهات الخارجية أيضًا على أي أفكار جديدة رائدة مما رأيته. لقد صمد هذا التحكم إلى حد كبير أمام اختبار الزمن.

robloo شكرا لك على

في السابق لم يكن لدي أي أمثلة ملموسة لاستخدام الموسعات في اتجاه غير تنازلي. سأحضر أي أمثلة من مجتمع WinUI (بما في ذلك القائمة المنبثقة للتقويم التي أشار إليها

حسنًا ، وجهة نظري هي أنه لا ينبغي أن يكون هناك الكثير من المناقشات حول هذا الموضوع. أختار التعبير عن إحباطاتي هنا لأن عنصر التحكم هذا هو مثال ممتاز. تحتاج عناصر التحكم الجديدة أو عناصر التحكم في فتات الخبز إلى مزيد من الإشراف ومن المهم متابعة العملية. ومع ذلك ، فإن النفقات العامة لعملية كبيرة تظهر هنا ومرة ​​أخرى ، وسوف تقضي ساعات عمل أكثر بكثير في القيام بالأعمال الورقية غير ذات القيمة المضافة والمناقشات التي تنفذ فقط التحكم من WCT. كما أنني لم أرَ حتى الآن فريق WinUI يستخدم عملًا سابقًا آخر يمثل مصدر قلق إلى حد ما. ليست هناك حاجة لإعادة هندسة قالب تحكم XAML.

مرحبًا بكم في مشروع WinUI @ kat-y - تتمتع Xaml بتاريخ طويل ولكن يمكن أن تكون غريبة بعض الشيء بالنسبة لأولئك الجدد. في حين أن WinUI هي فرصة لإعادة التفكير في كيفية عمل الأشياء ، في هذه الحالة ، يعد المتوسع عنصر تحكم بسيط نسبيًا وبالتالي فإن الانتقال البسيط من WPF إلى WinUI يجب أن يكون كافياً.

robloo أنا لا أتفق مع

التعامل مع أحجام شيفرون واللمس المستهدفة ، وكذلك استخدام أحجام تحجيم الخط. يجب أن تكون شيفرون سهلة الإزالة أو الإضافة.

يحتوي هذا المثال على شارة رتبة تتماشى مع النص.

هذا المثال لا يحتوي على شيفرون على الإطلاق

هذا المثال له جانب سابق يواجه شيفرون

بالنسبة للتنفيذ ، يجب أن يكون هناك انتقال متحرك عند الفتح والإغلاق ، ما لم يقم المستخدم بإيقاف تشغيل الرسوم المتحركة ، فإنه يقوم فقط بتبديل الحالات.

بالنسبة للتنفيذ ، يجب أن يكون هناك انتقال متحرك عند الفتح والإغلاق ، ما لم يقم المستخدم بإيقاف تشغيل الرسوم المتحركة ، فإنه يقوم فقط بتبديل الحالات.

كنت على وشك السؤال عن الرسوم المتحركة. هل يجب أن تكون هناك طريقة لتعطيلها من أجل التحكم ، على سبيل المثال في السيناريوهات التي تكون فيها المخططات المتحركة باهظة الثمن؟ لا يرغب جميع المستخدمين / المطورين في الحصول على رسوم متحركة لمثل هذه الأشياء حيث قد تشعر أنها غير مستجيبة أو غير مرغوب فيها (مثل TreeView). قد يكون من الأفضل عدم إعادة صياغة عنصر التحكم لتخصيص تلك النقطة. هناك شيء آخر يمكن تخصيصه وهو مدة الرسوم المتحركة ، وفي بعض الحالات تكون الرسوم المتحركة القصيرة أفضل من الرسوم المتحركة الأطول.

شكرا لجميع المناقشات العظيمة. بعض الأفكار

• سنحتاج إلى تحديث النموذج كما يذكر mdtauk لحساب التصميم الجديد بالإضافة إلى فرص تقليل العناصر / تحسين الأداء إن أمكن.
• IsEnabled موروثًا من Control ، لذلك أتوقع أن يعمل ذلك.

بالنسبة للتنفيذ ، يجب أن يكون هناك انتقال متحرك عند الفتح والإغلاق ، ما لم يقم المستخدم بإيقاف تشغيل الرسوم المتحركة ، فإنه يقوم فقط بتبديل الحالات.

كنت على وشك السؤال عن الرسوم المتحركة. هل يجب أن تكون هناك طريقة لتعطيلها من أجل التحكم ، على سبيل المثال في السيناريوهات التي تكون فيها المخططات المتحركة باهظة الثمن؟ لا يرغب جميع المستخدمين / المطورين في الحصول على رسوم متحركة لمثل هذه الأشياء حيث قد تشعر أنها غير مستجيبة أو غير مرغوب فيها (مثل TreeView). قد يكون من الأفضل عدم إعادة صياغة عنصر التحكم لتخصيص تلك النقطة. هناك شيء آخر يمكن تخصيصه وهو مدة الرسوم المتحركة ، وفي بعض الحالات تكون الرسوم المتحركة القصيرة أفضل من الرسوم المتحركة الأطول.

أعتقد أن بعض عناصر التحكم لها خاصية انتقال يمكن تعيينها إليها. لذلك إذا تم تضمين لوحة عمل غير متحركة كمورد ، فيمكن تطبيقها وهذا يعالج ذلك دون أي إعادة صياغة.

سيكون عليك تجاوز الانتقال عندما يقوم إعداد النظام بإيقاف تشغيل الرسوم المتحركة.

UIElement انتقالات؟
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions؟view=winrt-19041

أيضًا مع خاصية IsEnabled ، يجب أن تكون هناك حالة معطل. هل يجب أن يكون هناك معطل موسع ، ومعطل مطوي ، أم معطل دائمًا مطوي؟

نقطة مثيرة للاهتمام حول الرسوم المتحركة. نقوم بإيقاف تشغيل جميع الرسوم المتحركة باستخدام إعداد النظام ، لكنني لا أعتقد أننا نكشف المقابض لإيقاف الرسوم المتحركة بخلاف إعادة التشكيل حاليًا.

نقطة مثيرة للاهتمام حول الرسوم المتحركة. نقوم بإيقاف تشغيل جميع الرسوم المتحركة باستخدام إعداد النظام ، لكنني لا أعتقد أننا نكشف المقابض لإيقاف الرسوم المتحركة بخلاف إعادة التشكيل حاليًا.

أعتقد أنه يمكنك إضافة نمط يستبدل المجموعة الانتقالية بـ null في حالة رغبتك في إيقاف تشغيل الرسوم المتحركة ، بافتراض وجود مجموعة انتقالية للكتابة فوقها.

بما في ذلك ExpandTransition و CollapseTransition ، والتي يمكن أن تستخدم الاتجاه الذي تحدده خاصية عنصر التحكم - مما قد يسمح للمطور بتعيين الانتقال لكل منهما.

تعجبني الفكرة ، لكن لا أعتقد أن هناك طريقة اليوم لإنشاء انتقالات سمة مخصصة من شأنها أن تحد من القدرة على التخصيص. سيسمح هذا بتعطيله بسهولة عن طريق إزالته.

أيضًا مع خاصية IsEnabled ، يجب أن تكون هناك حالة معطل. هل يجب أن يكون هناك معطل موسع ، ومعطل مطوي ، أم معطل دائمًا مطوي؟

لماذا لا تعكس عنصر تحكم TreeView حيث يمكنك استخدام الخصائص IsExpanded و IsEnabled لإنشاء أي توليفة تحتاجها من الاثنين؟ إذا كان المعطل الموسع يعمل بشكل أفضل في بعض الحالات ، فيمكن القيام بذلك. إذا كنت بحاجة إلى تعطيل مطوي ، فهذا ممكن أيضًا بهذه الطريقة.

robloo أنا لا أتفق مع

mdtauk حسنًا ، كانت توصيتي "يجب أن نتبع تطبيق WCT" هنا: https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander. تم تغيير التصميم للتكيف مع اللمس وتم بالفعل إجراء واجهة أكثر حداثة. بالطبع لا أحد يستطيع عمل تصميمات جيدة مثلك لذا أنا متأكد من أن هناك مجالًا للتحسين. لا يتطلب الاستمرار في تغيير "التصميم" إعادة هندسة القالب لدعم جميع اتجاهات التوسيع. يجب أن يكون WCT هو الأساس ، وبعد ذلك إذا كان لدينا تصميم جديد لتطبيقه ، جيدًا جدًا ، فيمكن تنفيذه بسرعة ولكن ليس من نقطة الصفر.

robloo أنا لا أتفق مع

mdtauk حسنًا ، كانت توصيتي "يجب أن نتبع تنفيذ WCT" هنا ...
افترضت أنك لا تقصد أي تغييرات من XAML الخاص بإصدار WPF

لكنني ما زلت أعتقد أن فريق تصميم WinUI سيحتاج إلى الموافقة عليه ومتغيراته - فقط لتأكيد المواصفات لتضمينها في مجموعات أدوات figma

@ kat-y إذا كنت جديدًا في المشروع ، أعتذر إذا كنت أبدو قاسيًا. أنا أقف إلى جانب النقاط التي ذكرتها أعلاه حول كيفية تحسين سرعة المشروع في بعض المجالات التي هي بالتأكيد بحاجة إليها. أيضًا ، كيف يجب أن نستخدم ما تم إنجازه بالفعل في الماضي واختبار المعركة المكثفة على مدار الخمسة عشر عامًا الماضية. بالطبع لا شيء من هذا موجه لك أو لأي شخص. إنها مشكلة "سخام" عامة رأيتها مع Microsoft لسنوات حيث تحتاج الفرق إلى أن تكون أكثر تبسيطًا وإعادة توازن لصالح المزيد من الترميز / إدارة أقل للمشروع. على الرغم من أن الخطط جيدة مثل لا شيء يتفوق على التجربة والخطأ ، فإن سرعة التكرار تفوز في النهاية.

ranjeshj @ michael-

ranjeshj @ michael-

أعتقد أن مجموعة أدوات المجتمع موجودة في C # ، ويتطلب WinUI كود C / C ++.

كما أن فريق تصميم WinUI لم يكن لديه رأي AFAIK مع إصدار Toolkit ، وبالتالي فإن احتياجات فرق تصميم Windows والتطبيقات قد يكون لها احتياجات محددة إذا كانوا سيتبنون التحكم في حلولهم المخصصة.

أعتقد أن مجموعة أدوات المجتمع موجودة في C # ، ويتطلب WinUI كود C / C ++.

تعد ترجمة التعليمات البرمجية من / إلى C # & C ++ / WinRT أمرًا بسيطًا نسبيًا. خاصة بالنسبة لبرنامج Expander حيث نظرت بالفعل إلى الكود https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander. الغالبية العظمى من التعقيد موجود في XAML وهو 1: 1 قابل للاستخدام في WinUI طالما لم يتم استخدام امتدادات WCT. يمكنني نقل هذا الرمز إلى C ++ بنفسي إذا لزم الأمر.

كما أن فريق تصميم WinUI لم يكن لديه رأي AFAIK مع إصدار Toolkit ، وبالتالي فإن احتياجات فرق تصميم Windows والتطبيقات قد يكون لها احتياجات محددة إذا كانوا سيتبنون التحكم في حلولهم المخصصة.

لنقاط محددة ، نعم. ومع ذلك ، بالنسبة لوظيفة التحكم العامة ، يجب أن أختلف. سوف يكتمل WCT بنسبة 95 ٪ بالفعل و 100 ٪ في الوظائف. أي تغييرات في التصميم يتم تطبيقها في الأعلى ستكون تافهة.

robloo هل يمكن أن توضح تفاصيل الوظائف المختلفة؟ تتطابق واجهة برمجة التطبيقات المقترحة أعلاه بشكل وثيق جدًا مع WPF / WCT أثناء محاولة الحفاظ على الاتساق مع الأنماط الموجودة في WinUI.

ranjeshj قد لا نكون في نفس الصفحة. لم أكن أقترح أن واجهة برمجة التطبيقات المقترحة كانت مختلفة بشكل كبير عن WCT أو WPF.

تم ذكر أنه قد لا يتم دعم ExpandDirection في الإصدار الأول من عنصر التحكم هذا. يبدو أن هذا يمثل مشكلة بالنسبة للمتوسع الذي له تاريخ طويل مع هذه الوظيفة. ثم بدا أنه يتعين علينا تبرير سبب الحاجة إلى هذه الميزة على الإطلاق.

اقترحت استخدام WCT كقاعدة لتنفيذ ذلك بسرعة مع توسيع الاتجاه. ليست هناك حاجة لإعادة اختراع العجلة حيث لا يلزم سوى منفذ C # -> C ++ (والرمز الخلفي صغير جدًا لهذا الغرض) أثناء نسخ ولصق قالب XAML. سيؤدي ذلك إلى تنفيذ جميع الوظائف التي نحتاجها وتجنب المخاوف من عدم وجود وقت كافٍ لإضافة ExpandDirection. سيعطينا هذا النهج تحكمًا وظيفيًا بالكامل. بعد ذلك ، يمكن إجراء أي تغييرات في التصميم / النمط بناءً على

نعم ، إن إحباطاتي تجاه تطوير WinUI 3 بشكل عام تتسرب إلى هذه الأماكن القليلة وأنا أعتذر عن ذلك.

robloo لا يتعلق الأمر أيها هي أكبر الأولويات - وربما إزالة التلاعب عند جلب عناصر تحكم جديدة ، أو نقل الضوابط إلى WinUI.

عند تحديد أولويات الميزات الأساسية ليتم تضمينها في V1 ، ثم في V2 ، ستكون الخصائص والسلوكيات الأساسية والأساسية فقط موجودة ، وليس الأشياء القديمة التي لم يتم استخدامها بشكل شائع.

يبدو أن Microsoft تحدد الميزات التي يجب إضافتها بناءً على احتياجات العملاء ورغباتهم - وليس فقط الوصول إلى التكافؤ مع الأطر القديمة.

لذلك ، ليس هذا _ مبررًا_ ، ولكن مجرد محاولة فهم ما يفعله المطورون في الواقع بأنماط التحكم هذه في واجهة المستخدم الخاصة بهم.
حقيقة أن Windows Shell وحده لديه عدة إصدارات من نمط التحكم في الموسع ، سيكون سببًا واضحًا كافيًا لتضمينه. وحقيقة أن كل تطبيق يبدو مختلفًا ، إن لم يكن يتصرف بشكل مختلف - هو سبب كافٍ لفريق التصميم لتوحيد تصميم التحكم لتلبية احتياجات الفرق الداخلية.

mdtauk كما هو الحال دائمًا ، يمكنك الحصول على نقاط جيدة. ومع ذلك ، يجب أن أختلف مع هذه الفلسفة بطريقة رئيسية واحدة إذا كان هذا هو النهج الذي تتبعه Microsoft حقًا. لكي تنجح WinUI ، يجب أن يكون ذلك منطقيًا لمطوري التطبيقات الحاليين. أحاول تجنب سيناريو UWP آخر لأننا نعلم جميعًا أن UWP لم ينطلق أبدًا. يحتاج المطورون Microsoft إلى إقناعهم بالقدوم إلى WinUI ، تمامًا مثل UWP من قبل ، هم مطورو WPF. أحد الأسباب التي تجعل تطبيقات WPF لم تنتقل أبدًا إلى UWP هو أن UWP ، خاصة عندما تم إصداره لأول مرة ، كان مكافئًا ضعيفًا للغاية في العديد من مجالات الوظائف الرئيسية. لهذا السبب عندما رأيت زوايا مستديرة مفقودة في خريطة الطريق ، بدأت في تذكر كابوس UWP (تم ترك الزوايا الدائرية الأساسية لـ WPF خارج UWP لأطول وقت). يجب أن تكون الأولوية رقم 1 للحصول على تجربة نقل سلسة قادمة من كل من WPF و UWP وبصراحة من المحتمل أن يكون WPF أولوية أعلى نظرًا لوجود المزيد من التطبيقات هناك وتركز Microsoft بوضوح على حالات سطح المكتب باستخدام WinUI أولاً. لذا ، مرة أخرى ، يجب أن نكون حذرين للغاية بشأن إعادة اختراع العجلة ، وأن نتجنب بنشاط.

وحقيقة أن كل تطبيق يبدو مختلفًا ، إن لم يكن يتصرف بشكل مختلف - هو سبب كافٍ لفريق التصميم لتوحيد تصميم التحكم لتلبية احتياجات الفرق الداخلية.

لقد فهمت دائمًا أن التصميم قد يحتاج إلى تعديل. باستخدام مفاهيم التحكم غير المرئي ، فهذه مشكلة منفصلة عن ExpandDirection. إذا احتجنا إلى تحديث التصميم أكثر أو جعله أكثر فائدة في بعض الحالات ، فهذا رائع - يجب أن يكون تافهًا نسبيًا. في نهاية اليوم ، قد يتم أيضًا إعادة تشكيله بالكامل لأولئك الذين يحتاجون إلى تحكم دقيق.

نقطة مثيرة للاهتمام حول الرسوم المتحركة. نقوم بإيقاف تشغيل جميع الرسوم المتحركة باستخدام إعداد النظام ، لكنني لا أعتقد أننا نكشف المقابض لإيقاف الرسوم المتحركة بخلاف إعادة التشكيل حاليًا.

لكي نكون منصفين ، لا توجد عناصر تحكم تقريبًا تستخدم الرسوم المتحركة. يستخدم TreeView و NavigationView بشكل أساسي أداة Expander ولكن كلاهما لا يستخدم الرسوم المتحركة للتوسيع / ​​الانهيار. تعتمد معظم عناصر التحكم التي تستخدم الرسوم المتحركة عليها ، على سبيل المثال ، ProgressBar أو ProgressRing. المتوسع مع ذلك لا يعتمد عليه ، سيكون من "اللطيف أن يكون لديك". ومن الأمثلة الأخرى على ذلك أن بعض الأشخاص لم يستخدموا عنصر تحكم WCT Expander لأنهم لم يعجبهم الرسوم المتحركة. إذا أردنا تضمين أكبر عدد ممكن من الأشخاص ، فإن وجود طريقة سهلة لتعطيل الرسوم المتحركة غير المرغوب فيها سيجعل ذلك أسهل.

أعتقد أنه يمكنك إضافة نمط يستبدل المجموعة الانتقالية بـ null في حالة رغبتك في إيقاف تشغيل الرسوم المتحركة ، بافتراض وجود مجموعة انتقالية للكتابة فوقها.

ولكن هل ستكون هذه طريقة شائعة لتعطيل / تمكين ذلك؟ في معظم الأوقات ، عندما نقدم أنماطًا متعددة ، فإنها تختلف بشكل جذري أكثر من رسم متحرك واحد فقط ، مثل AccentColorButtonStyle أو RevealButtonStyle.

بما في ذلك ExpandTransition و CollapseTransition ، والتي يمكن أن تستخدم الاتجاه الذي تحدده خاصية عنصر التحكم - مما قد يسمح للمطور بتعيين الانتقال لكل منهما.

أنا بالفعل أعجبتني هذه الفكرة!

تعجبني الفكرة ، لكن لا أعتقد أن هناك طريقة اليوم لإنشاء انتقالات سمة مخصصة من شأنها أن تحد من القدرة على التخصيص. سيسمح هذا بتعطيله بسهولة عن طريق إزالته.

أنا أيضا قلق بشأن ذلك. مع ExpandTransition و CollapseTransition API دون أي انتقالات سمة مخصصة ، هذا قريب من مجرد وجود "ExpendTransitionEnabled" و "CollapseTransitionEnabled".

robloo إذا كنت ترغب في الدردشة حول الإحباط فيما يتعلق بتطوير WinUI 3 ، أرحب بكم لتكتب إليّ (البريد الإلكتروني الخاص بي على Twitter والعمل موجودان في ملفي الشخصي على GitHub). لست على دراية كاملة بإحباطاتك الحالية ، لكنني بشكل عام شخص جيد أبدأ به فيما يتعلق بالموضوعات المتعلقة بالعميل أو المشاركة المجتمعية / التنمية ، كما قمت بتشغيل عدد كبير من مجموعات التركيز لدينا على مدار العام الماضي التي غطت الاعتبارات التي أدرجتها حول الأدوات وتكافؤ الميزات وما إلى ذلك.

سألاحظ أن خريطة الطريق الخاصة بنا ضيقة للغاية ، لذا لا يمكنني أن أعدك بأنني سأمتلك القدرة على إجراء التغييرات التي تريد رؤيتها ، ولكن من المفيد دائمًا بالنسبة لي معرفة ما يمكن فعله لدعمك بشكل أفضل العميل و / أو المساهم في WinUI ، وبالتالي فإن أسوأ نتيجة هي أن احتياجاتك على الأقل يتم أخذها في الاعتبار جيدًا من قبل فريقنا في المضي قدمًا. لأفضل حالة ، أفترض أن ذلك سيعتمد على ما تبحث عنه. دعنا نتحدث؟ 😄

mdtauk شكرًا على دعمك في التوضيح - أنت دائمًا في تناغم جيد! سأقول أنه من الواضح أن هناك الكثير على صحننا والفرق ملتزمة بأن تكون رشيقًا وفعالًا قدر الإمكان في محاولة تقديم أكثر تقدم هادف ومؤثر في جميع المجالات. لمواصلة الاستثمار في عناصر التحكم / الميزات الجديدة من بين جميع المجالات الأخرى للتقدم المستمر ، فإنه يتطلب من أعضاء فريقنا مثل @ kat-y تطوير _very_ مواصفات المتطلبات الحادة لأن أسوأ شيء بالنسبة لنا هو إلقاء جزء من مواردنا المحدودة في مقبض أو واجهة برمجة التطبيقات (API) التي لا ترى بالفعل استخدامًا واسع النطاق حيث لا يوجد فقط تكلفة التطوير مقدمًا ولكن أيضًا تكلفة الصيانة المستمرة بعد ذلك. لقد قمت للتو بتحليل هذا الموضوع بشكل طفيف ، ولكن من الصواب لـ @ kat-y ، خاصة كعضو جديد في الفريق ، أن ترغب في أن تكون واضحًا تمامًا في ضمان وجود سيناريو حقيقي في تطبيق حقيقي يحتاج إلى الوظيفة المطلوبة ( للسبب المذكور وأيضًا للتأكد من أن لدينا شركاء التحقق من المعاينة قادرون على المساعدة في ضمان أداء جميع الميزات المطورة كما هو مطلوب في بيئات الإنتاج التي توفر تغطية حالة متطورة). قد لا يتم دائمًا بث الامتثال لهذا الطموح علنًا ، كما هو الحال في الحالات التي يكون فيها شركاء التحقق من الصحة خاصين (ويسعدك التواصل مع @ kat-y مباشرةً إذا كانت احتياجاتك غير مناسبة لنشرها علنًا هنا. في هذا الوقت) ، ولكن كانت هذه سابقة في جميع إصدارات التحكم WinUI 2+ الخاصة بنا.

آمل أن يكون هذا قد ساعد؟ إن هدفي هو إعادة هذا الموضوع مرة أخرى إلى @ kat-y وموضوعات Expander المطروحة ، ولكن يرجى التواصل مباشرة إذا كان هناك المزيد الذي يمكنني الإجابة عليه أو إذا كانت هناك تعليقات تود أن تراها في الاعتبار. شكرًا لكما على كل العمل والشغف والطاقة اللذين بذلتهما في هذا الموضوع وفي WinUI! 😄

mdtauk كما هو الحال دائمًا ، يمكنك الحصول على نقاط جيدة. ومع ذلك ، يجب أن أختلف مع هذه الفلسفة بطريقة رئيسية واحدة إذا كان هذا هو النهج الذي تتبعه Microsoft حقًا ..

لم أكن أعلق على ما إذا كنت أتفق مع النهج أم لا ، فقط من الوقت الذي قضيته هنا ومشاهدة كيفية تقييم اتفاقيات إعادة الشراء ، أعتقد أن الفريق يعمل على هذا الأمر.

(للسبب المذكور وأيضًا للتأكد من أن لدينا شركاء التحقق من المعاينة قادرون على المساعدة في ضمان أداء جميع الميزات المطورة كما هو مطلوب في بيئات الإنتاج التي توفر تغطية حالة متطورة). قد لا يتم دائمًا بث الامتثال لهذا الطموح علنًا ، كما هو الحال في الحالات التي يكون فيها شركاء التحقق من الصحة خاصين (ويسعدك التواصل مع @ kat-y مباشرةً إذا كانت احتياجاتك غير مناسبة لنشرها علنًا هنا. في هذا الوقت) ، ولكن كانت هذه سابقة في جميع إصدارات التحكم WinUI 2+ الخاصة بنا.

أعتقد أن استخدام تطبيقات Microsoft الخاصة ، وشل كأمثلة من المرجح أن تثير الاعتراف ، لأنها تُظهر وجود حاجة داخلية لشيء ما ، لم يكن موجودًا ، أو لم يكن مناسبًا للغرض ، لدرجة أنه كان عليهم ذلك " قم بتشغيل ملفاتهم الخاصة "- ولكن بالطبع الوحوش الكبيرة مثل Netflix و Facebook وما إلى ذلك التي تصمم تطبيقات لنظام التشغيل Windows - ستطلب أيضًا عناصر تحكم وأجزاء أخرى.

لا يقتصر WinUI فقط على الوصول إلى التكافؤ مع WPF و MFC و CommonControls و WinForms وما إلى ذلك - (ولكن يجب النظر بجدية إلى أكثر عناصر التحكم القديمة هذه استخدامًا بدون مكافئ حديث)

حقيقة أن Breadcrumb Bars and Expanders تم اقتراحها هي علامة على أن هذا بدأ يحدث IMO. ويجب تقييم كل عنصر تحكم أو إضافة لواجهة برمجة التطبيقات و "تبريرها" في بيئة مثالية ، تمامًا كما يجب على مصممي التطبيقات دائمًا إعادة تقييم واجهات المستخدم وتجربة المستخدم للتأكد من ملاءمتها للغرض. - في هذه الحالة ، قد يبدو الأمر واضحًا ، ولكن لا يزال يتعين علينا تقديم أمثلة حيث يتم استخدام هذا النمط وواجهات برمجة التطبيقات - لتعزيز حالة التضمين.

حول الرسوم المتحركة: ماذا عن استخدام نهج ElementAnimator مثل عروض ItemsRepeater؟ تبدو واجهة برمجة تطبيقات StartShowAnimation() و StartHideAnimation() واعدة ("إظهار" لاستخدامها للتوسيع ، و "إخفاء" المستخدمة في الانهيار). يمكن تقديم خاصية ElementAnimator على عنصر التحكم باستخدام تطبيق رسوم متحركة افتراضي. إذا لم تكن هناك حاجة إلى رسم متحرك ، فيمكن تعيين الخاصية إلى قيمة خالية أو إذا كانت هناك حاجة إلى مزيد من التحكم الدقيق ، فيمكن توفير رسم متحرك إظهار أو إخفاء فقط إلى ElementAnimator.

لست على دراية كبيرة بـ ElementAnimator API ويبدو أنه قد لا يكون قابلاً للاستخدام في جميع السيناريوهات نظرًا لوجود مشكلة https://github.com/microsoft/microsoft-ui-xaml/issues/166 . ومع ذلك ، إذا كانت لا تزال هناك فجوة وظيفية ، فربما يمكن مزامنة عناصر العمل هذه (التحكم في المتوسع والعنصر لجعلها قابلة للاستخدام بواسطة عنصر التحكم المتوسع) وهندستها معًا.

حسنًا ، فكرة ElementAnimator مثيرة حقًا. ما يقلقني هنا هو أن هذا قد يكون معقدًا للغاية أو مفرط في الهندسة. بعد كل شيء ، بالنسبة لـ ExpanderControl ، سنحتاج بعد ذلك إلى توفير ElementAnimator مخصص بينما يمكننا إعادة استخدام الرسوم المتحركة للقوالب الموجودة. أيضًا ، يوفر ElementAnimator طرقًا أكثر مما يحتاجه عنصر التحكم في الموسع بالفعل ، لذا يبدو وكأنه ملائم إلى حد ما.

هل أنا محق في التفكير في أن ElementAnimator مخصص للتعامل مع تعويضات الطفل أو العناصر المضمنة التي تظهر على الشاشة؟

قد يكون الأمر مبالغة اعتمادًا على ما هو موجود داخل اللوحة والذي يظهر على شكل موسع ، يتوسع. ولكن إذا كانت هناك طريقة لربطها بطريقة ما ، لذلك إذا كانت اللوحة الموسعة التي تحتوي على عناصر - يمكن أن تدفع الرسوم المتحركة للأطفال إذا قام المطور بإلحاق شيء ما بالعنصر.

لذلك لا يتحكم المتوسع بشكل مباشر في انتقالات العنصر الفرعي ، ولكن يمكنه تمكينها إذا أراد المطوِّر ذلك

نعم ، إذا تمكنا من إنشاء أشكال قابلة لإعادة الاستخدام هنا ، مع الاستمرار في منح العملاء مستوى مُرضيًا من خيارات التخصيص ، فسيكون هذا أمرًا يستحق الاستكشاف. على سبيل المثال ، لقد رأينا بالفعل يطلب إضافة رسوم متحركة إلى عنصر تحكم TreeView عند توسيع / ​​تصغير العنصر (https://github.com/microsoft/microsoft-ui-xaml/issues/208). أتخيل أنه يمكن صنع حالة هنا حيث يمكن إنشاء مجموعة واحدة من الرسوم المتحركة لتبدو رائعة لكل من عنصر التحكم Expander و TreeView. والذي سيأتي تلقائيًا بمستوى من الاتساق ثم بين عناصر التحكم المختلفة. خلق معرفة مرئية للمستخدم وهي أيضًا حجة مقنعة.

أعتقد أنه من الناحية المثالية ، يجب أن ينتقل TreeView و NavigationView الهرمي إلى التحكم في Expander عندما يكون عنصر التحكم جاهزًا. بعد كل شيء ، يحتاج كلا الضابطين حاليًا إلى التعامل مع نفس المشكلة بالضبط التي سيتم حلها بواسطة ExpanderControl. لذا فإن الرسوم المتحركة المشتركة لن تحدث فرقًا كبيرًا في TreeView.

الشيء مع ElementAnimator (كيف فهمته) هو أنه سيتعين علينا كتابة رسوم متحركة جديدة. ومع ذلك ، هناك رسوم متحركة مضمنة بالفعل يمكننا الاستفادة منها في Expander.

قد يكون الأمر مبالغة اعتمادًا على ما هو موجود داخل اللوحة والذي يظهر على شكل موسع ، يتوسع. ولكن إذا كانت هناك طريقة لربطها بطريقة ما ، لذلك إذا كانت اللوحة الموسعة التي تحتوي على عناصر - يمكن أن تدفع الرسوم المتحركة للأطفال إذا قام المطور بإلحاق شيء ما بالعنصر.

أعتقد أن إحدى النقاط الرئيسية لـ ElementAnimator كانت السماح بإضافة رسوم متحركة إلى اللوحات والمجموعات ، على سبيل المثال ItemsRepeater. في حالة Expander ، هذا ليس هو الحال حقًا ، على الرغم من أن الموسع ليس لوحة تعرض مجموعة من العناصر.

خارج الجزء العلوي من رأسي ، تغيير حجم اللوحة الأم مع التخفيف. بعد ذلك ستشعر الشريحة والتلاشي للكائن (الكائنات) المحتوية على حق.

إذا كان سيصبح انتقالًا عامًا واسع النطاق لنظام التشغيل مع التسهيل المناسب الذي يحدده فريق حركة Fluent Design - فسيكون ذلك جيدًا.

وضع علامة على stmoy لأننا نتحدث عن الرسوم المتحركة.

شكرًا لك SavoySchuler على الانضمام وتوفير المزيد من السياق لالتزامات فريقنا - آمل أن يساعد هذا في توضيح سبب بحثي تحديدًا عن أمثلة للتطبيقات التي تتطلب وظائف ExpandDirection! لتكرار ما قاله سافوي ، يرجى التواصل معي مباشرةً (Twitter DMs إذا كنت بحاجة إلى الخصوصية) إذا كانت احتياجات Expander الخاصة بك هي تلك التي لا يمكن مشاركتها هنا.

robloo شكرًا لك على

في هذه الملاحظة ، أنا متحمس لقراءة هذه التعليقات الأخيرة حول الرسوم المتحركة!

بعد قراءة التعليقات المتعلقة بالرسوم المتحركة ، يبدو أن هناك 3 طرق ممكنة ، من أجل زيادة حجم العمل:

عدم تضمين مجموعة رسوم متحركة - هذا له فائدة حيث أشار chingucoding إلى عدم ردع المطورين عندما لا يعمل السيناريو الخاص بهم أو يبدو جيدًا مع الرسوم المتحركة المحددة. الخطر هنا هو عدم الاتساق المحتمل ، على الرغم من أنه لا يبدو أن هناك مساحة كبيرة للتضارب في هذا المسار.

اقترح mdtauk تضمين ExpandTransition و CollapseTransition ،

يمكن أن يستخدم الاتجاه الذي تحدده خاصية عنصر التحكم - مما قد يسمح للمطور بتعيين الانتقال لكل منهما.

يبدو وكأنه نطاق أصغر من استخدام ElementAnimator. هل سيعطي هذا للمطورين مرونة كاملة في تعيين الانتقالات؟

خارج الجزء العلوي من رأسي ، تغيير حجم اللوحة الأم مع التخفيف. بعد ذلك ستشعر الشريحة والتلاشي للكائن (الكائنات) المحتوية على حق.

أنا أفهم أجزاءً من هذا ، لكن يصعب عليّ أن أتخيل بدون ، حسنًا ، مرئي 😄. هل يعني "تغيير حجم اللوحة الرئيسية" أن الرأس سيتغير في الحجم؟ هل يمكنك توضيح ما تعنيه بعبارة "شريحة وتلاشي للكائن (العناصر) التي تحتوي عليها"؟

اقترح @ Felix-Dev استخدام ElementAnimator

تبدو واجهة برمجة تطبيقات ElementAnimator مع StartShowAnimation () و StartHideAnimation () واعدة ("إظهار" لاستخدامها في التوسيع ، و "إخفاء" المستخدم في الانهيار). يمكن تقديم خاصية ElementAnimator على عنصر التحكم باستخدام تطبيق رسوم متحركة افتراضي. إذا لم تكن هناك حاجة إلى رسم متحرك ، فيمكن تعيين الخاصية إلى قيمة خالية أو إذا كانت هناك حاجة إلى مزيد من التحكم الدقيق ، فيمكن توفير رسم متحرك إظهار أو إخفاء فقط إلى ElementAnimator.

chingucoding لاحظ ذلك

سنحتاج بعد ذلك إلى توفير ElementAnimator مخصص بينما يمكننا إعادة استخدام الرسوم المتحركة الموجودة في السمات. أيضًا ، يوفر ElementAnimator طرقًا أكثر مما يحتاجه عنصر التحكم في الموسع بالفعل ، لذا يبدو وكأنه ملائم إلى حد ما.

كانت إحدى النقاط الرئيسية لـ ElementAnimator هي السماح بإضافة رسوم متحركة إلى اللوحات والمجموعات ، على سبيل المثال ItemsRepeater. في حالة Expander ، هذا ليس هو الحال حقًا ، على الرغم من أن الموسع ليس لوحة تعرض مجموعة من العناصر.

يجب أن يتحول TreeView و NavigationView الهرمي إلى التحكم الموسع عندما يكون عنصر التحكم جاهزًا. بعد كل شيء ، يحتاج كلا الضابطين حاليًا إلى التعامل مع نفس المشكلة بالضبط التي سيتم حلها بواسطة ExpanderControl. لذا فإن الرسوم المتحركة المشتركة لن تحدث فرقًا كبيرًا في TreeView.

لست متأكدًا من أن TreeView و NavigationView الهرمي لهما نفس سيناريو الرسوم المتحركة تمامًا مثل Expander ، فماذا عن الوقت الذي سيدفع فيه Expander أي محتوى (ليس بالضرورة نصًا / أزرارًا) في مكان قريب والسيناريوهات عندما تكون Expanders `` أكورديون '' مع بعضها البعض و من المحتمل أن يكون لديك منطق للإغلاق / الفتح اعتمادًا على توسع الآخرين.

هل ElementAnimator مبالغة في الرسوم المتحركة المتوسعة نظرًا لأنها مخصصة للوحة / مجموعة الرسوم المتحركة؟

اقترح mdtauk تضمين ExpandTransition و CollapseTransition ،

يمكن أن يستخدم الاتجاه الذي تحدده خاصية عنصر التحكم - مما قد يسمح للمطور بتعيين الانتقال لكل منهما.

يبدو وكأنه نطاق أصغر من استخدام ElementAnimator. هل سيعطي هذا للمطورين مرونة كاملة في تعيين الانتقالات؟

خارج الجزء العلوي من رأسي ، تغيير حجم اللوحة الأم مع التخفيف. بعد ذلك ستشعر الشريحة والتلاشي للكائن (الكائنات) المحتوية على حق.

أنا أفهم أجزاءً من هذا ، لكن يصعب عليّ أن أتخيل بدون ، حسنًا ، مرئي 😄. هل يعني "تغيير حجم اللوحة الرئيسية" أن الرأس سيتغير في الحجم؟ هل يمكنك توضيح ما تعنيه بعبارة "شريحة وتلاشي للكائن (العناصر) التي تحتوي عليها"؟

آسف على التأخير ، اضطررت إلى عمل هذه الرسوم المتحركة الصغيرة.
تجاهل توقيتات الرسوم المتحركة الفعلية ، فهي فقط للتوضيح. المخطط التفصيلي الوردي هو رأس المتوسع - والحدود الخضراء للجزء الموسع / المحتوى وما إلى ذلك

لست متأكدًا من أن TreeView و NavigationView الهرمي لهما نفس سيناريو الرسوم المتحركة تمامًا مثل Expander ، فماذا عن الوقت الذي سيدفع فيه Expander أي محتوى (ليس بالضرورة نصًا / أزرارًا) في مكان قريب والسيناريوهات عندما تكون Expanders `` أكورديون '' مع بعضها البعض و من المحتمل أن يكون لديك منطق للإغلاق / الفتح اعتمادًا على توسع الآخرين.

السؤال هو ، هل يجب على Expander فرض الرسوم المتحركة على الرغم من ذلك؟ من المؤكد أن TreeView و Hierarchical NavigationView سيستفيدان من وجود عنصر تحكم موسع مدمج يعتني بالتوسع / الانهيار ويسمح لنا بالحصول على تجربة موحدة أكثر في هذا المجال. على سبيل المثال ، لا يقوم TreeView بتحريك أي شيء بينما يقوم نظام NavigationView الهرمي بتحريك دوران الشيفرون.

هل ElementAnimator مبالغة في الرسوم المتحركة المتوسعة نظرًا لأنها مخصصة للوحة / مجموعة الرسوم المتحركة؟

قد يكون أحد عناصر التحكم التي تدعم ElementAnimator بنشاط (على الأقل في المعاينة) هو ItemsRepeater الذي يتعامل مع اللوحات الكبيرة التي تعرض عشرات العناصر. من ناحية أخرى ، لا يحتوي برنامج Expander على مثل هذا السيناريو المعقد ولكنه عنصر واحد لإظهاره / إخفاءه.

شيء آخر لاحظته هو أنه لن تكون هناك طريقة لتخصيص مكان وضع الشيفرون (يسار / يمين أو أعلى / أسفل). ربما يكون هذا مفيدًا كنقطة تخصيص؟ يضع نظام NavigationView الشيفرون على اليمين بينما يضعه TreeView على اليسار. ينطبق الأمر نفسه على الموسعات الموجودة في النظام ، حيث تضعها بعض مناطق تطبيق الإعدادات على اليسار بينما تضع الإشعارات ، على سبيل المثال ، على اليمين.

شيء آخر لاحظته هو أنه لن تكون هناك طريقة لتخصيص مكان وضع الشيفرون (يسار / يمين أو أعلى / أسفل). ربما يكون هذا مفيدًا كنقطة تخصيص؟ يضع نظام NavigationView الشيفرون على اليمين بينما يضعه TreeView على اليسار. ينطبق الأمر نفسه على الموسعات الموجودة في النظام ، حيث تضعها بعض مناطق تطبيق الإعدادات على اليسار بينما تضع الإشعارات ، على سبيل المثال ، على اليمين.

يمكننا تقديم شيء مثل ExpandGlyphPlacementMode بقيم مثل TopLeft و TopRight و BottomCentered (وربما أكثر (Left، Right، ...)) و ExpandGlyphPlacementOffset يمكن لمطوري العقارات استخدامها لتعديل الوضع الأساسي (يتم تحديده بواسطة وضع التنسيب) إذا لزم الأمر.

بالإضافة إلى ذلك ، كما لاحظ mdtauk بالفعل ، واجهات برمجة التطبيقات لتخصيص الحروف الرسومية للتوسيع / ​​الطي (تستخدم بعض عناصر التحكم > ، والبعض الآخر يستخدم v لتوسيع الصورة الرمزية الخاصة بهم) وللتحكم في رؤية الصورة الرمزية.

يمكننا تقديم شيء مثل ExpandGlyphPlacementMode بقيم مثل TopLeft و TopRight و BottomCentered (وربما أكثر (Left، Right، ...)) ويمكن لمطوري خاصية ExpandGlyphPlacementOffset الإضافية استخدامها لتعديل الموضع الأساسي (تم تعيينه بواسطة وضع الموضع) إذا لزم الأمر .

لست متأكدًا مما إذا كان TopLeft و TopRight ... هو الخيار الصحيح هنا. ربما شيء مثل "ابدأ" و "إنهاء" قد يكون أكثر ملاءمة هنا؟
في التنسيقات الأفقية ، ستكون البداية على اليسار (على اليمين في لغات RTL) ، في وضع الفتح الرأسي ، سيكون هذا في الأعلى. يمكن تعريف "النهاية" وفقًا لذلك. المشكلة التي أراها مع TopLeft ... هي أنها تقدم الكثير من التعقيد (انظر تلميح التدريس) من أجل القليل من الفائدة. ستكون TopLeft و TopRight هي نفسها إذا تم فتح ExpanderControl إلى اليمين. أعتقد أن وجود شيء مثل مركز القاع سيبدو محرجًا بعض الشيء في الكثير من المساحات وسيشغل مساحة كبيرة.

بالإضافة إلى ذلك ، نظرًا لأن @ mdtauk (التقسيم ذكر عدم إرسال بريد عشوائي إلى صندوق الوارد الخاص به) قد لاحظت بالفعل ، واجهات برمجة التطبيقات لتخصيص الحروف الرسومية للتوسيع / ​​الانهيار (تستخدم بعض عناصر التحكم> ، بينما يستخدم البعض الآخر v لتوسيع الصورة الرمزية الخاصة بهم) وللتحكم في رؤية الصورة الرمزية.

السؤال هو كيف نحقق ذلك. إذا أردنا تحريك الرمز بشكل مشابه لما يفعله نظام NavigationView الهرمي ، فلن نتمكن من السماح لواجهة برمجة التطبيقات بتبديل الصورة الرمزية الموسعة والمنخفضة والتي يمكن استخدامها للتبديل إلى v أو> للانهيار. ربما يمكن أن يكون لدينا واجهة برمجة تطبيقات تشير إلى اتجاه الصورة الرمزية المنهارة؟

تبدو أفكار الرسوم المتحركة جيدة جدًا. يجب أن يكون من الممكن تشغيلها / إيقاف تشغيلها تمامًا مثل List View ، وآخرون. يحتاج الرأس والحرف الرسومي أيضًا إلى تبديل الجوانب للغات RTL تلقائيًا. ومع ذلك ، يبدو أن كل تخصيص الصورة الرمزية يبالغ في هندسة المشكلة. من المستحيل إنشاء نمط يعمل مع كل الحالات التي تم تحديدها والتي لها تطبيقات مخصصة. بدلاً من ذلك ، تمامًا مثل CheckBox وعناصر التحكم الأخرى ، يجب أن يكون التصميم الافتراضي هو أفضل ما يمكننا القيام به ولكن يجب أن يكون النمط الافتراضي بسيطًا بما يكفي لإعادة النموذج. لا أعرف لماذا يتعارض الجميع مع عناصر التحكم في إعادة التشكيل ، فهو الحل إلى حد كبير وهو في الواقع قوة كبيرة للتحكم في المظهر الأقل. تؤدي إضافة المزيد من الخصائص إلى زيادة عبء الصيانة الذي أسمع عنه كثيرًا.

تحرير: قد يكون تحديد الموارد لبعض الأشياء لتحسين التصميم الخفيف خيارًا معقولًا أيضًا.

لست متأكدًا مما إذا كان TopLeft و TopRight ... هو الخيار الصحيح هنا. ربما شيء مثل "ابدأ" و "إنهاء" قد يكون أكثر ملاءمة هنا؟
في التنسيقات الأفقية ، ستكون البداية على اليسار (على اليمين في لغات RTL) ، في وضع الفتح الرأسي ، سيكون هذا في الأعلى. يمكن تعريف "النهاية" وفقًا لذلك. المشكلة التي أراها مع TopLeft ... هي أنها تقدم الكثير من التعقيد (انظر تلميح التدريس) من أجل القليل من الفائدة.

chingucoding يستخدم NavigationView وضع فتح عمودي (نظرًا ExpandGlyphPlacementOffset لشيء نراه بشكل شائع.

أعتقد أن وجود شيء مثل مركز القاع سيبدو محرجًا بعض الشيء في الكثير من المساحات وسيشغل مساحة كبيرة.

أنا متأكد من أنني رأيت أمثلة على ذلك على الويب وفي التطبيقات وما إلى ذلك ... ولهذا السبب خطرت لي هذه الفكرة. على الرغم من أنه من الأفضل نشر أمثلة هنا لمعرفة ما إذا كان هذا أمرًا يستحق الدعم المباشر أو ما إذا كنا سنترك هذا الأمر لإعادة التشكيل.

ومع ذلك ، يبدو أن كل تخصيص الصورة الرمزية يبالغ في هندسة المشكلة. من المستحيل إنشاء نمط يعمل مع كل الحالات التي تم تحديدها والتي لها تطبيقات مخصصة. بدلاً من ذلك ، تمامًا مثل CheckBox وعناصر التحكم الأخرى ، يجب أن يكون التصميم الافتراضي هو أفضل ما يمكننا القيام به ولكن يجب أن يكون النمط الافتراضي بسيطًا بما يكفي لإعادة النموذج. لا أعرف لماذا يتعارض الجميع مع عناصر التحكم في إعادة التشكيل ، فهو الحل إلى حد كبير وهو في الواقع قوة كبيرة للتحكم في المظهر الأقل.

robloo أنا لست

يجب أن نحدد سيناريوهات التخصيص الشائعة ونسعى جاهدين لجعلها في متناول اليد قدر الإمكان بواسطة عنصر تحكم Expander.

خذ ، على سبيل المثال ، حالة الحروف الرسومية المخصصة (الموجودة على موقع Fluent UI الإلكتروني ):

يعني تخصيص رمز Glyph بالضرورة أنه يجب النظر بعناية في أي رسوم متحركة مضمنة. من المثير للاهتمام أيضًا معرفة: ما الذي قد يرغب فيه العملاء أكثر - القدرة على تخصيص الصور الرمزية بسهولة وفقًا لرغبتهم أو الحصول على رسوم متحركة مدمجة للصورة الرمزية (كما هو موضح في NavigationView). أنا شخصياً أعتقد أن الأول سيكون أكثر أهمية ولكن ليس لدي أي بيانات صلبة لدعم ذلك.

عنصر تحكم Expander آخر هو عنصر التحكم Telerik Expander الذي يعرض بعض واجهات برمجة التطبيقات للتخصيص التي ناقشناها هنا (مثل القدرة على تغيير موضع glyoh أو رمز الصورة الرمزية) والتي يمكننا استخدامها أيضًا لبعض الإلهام.

رسم موسع
انهار رسومي
الذي يمكن للمطور تجاوزه بالشكل الذي يراه مناسبًا

وضع الرسم البياني ، البدء ، والنهاية ، أعلاه ، أدناه
يمكن؟

ربما تستخدم أيضًا محاذاة المحتوى للتعامل مع رأس ملء العرض ، أو جعل الحرف الرسومي والنص مجمعين معًا

بالنسبة لمركز الإشعارات ، يوجد كل شيء واضح على نفس خط الموسع ، فكيف يمكن التعامل مع هذا؟ نوع من الطرق لفصل اللوحة الموسعة عن الرأس الموسع؟

chingucoding يستخدم NavigationView وضع فتح عمودي (نظرًا

تمت صياغة ذلك بشكل سيئ من نهايتي باستخدام "وضع الفتح الأفقي" ، كنت أعني أن البعد الأفقي ثابت ، لذلك يتم تقديم المحتوى بطريقة أفقية. نفس الشيء بالنسبة للوضع الرأسي. أيضا ما هي الزاوية اليسرى العليا والسفلى اليسرى؟ أفترض أن تكون الأيقونة في المنتصف ، في معظم الأوقات لا ينبغي / لا يشغل الرأس حتى مساحة كبيرة في المنطقة المتوسعة ، وينتهي الأمر بأن يكون أعلى اليسار وأسفل اليسار متماثلًا تقريبًا.

للتوضيح ، إذا تمدد الموسع في الاتجاه الرأسي ، فسيكون start يسارًا (يمينًا في RTL) و end يمينًا (يسارًا في RTL) ؛ في التوسع الأفقي ، يكون start للأعلى و end الأسفل. على غرار CSS Flex-start و flex-end.

يستخدم Visual Studio رمزًا مركزيًا ، إلا أن منطقة زر التوسيع تمد عنصر التحكم بالكامل:

مغلق:

موسع:

وضع الرسم البياني ، البدء ، والنهاية ، أعلاه ، أدناه
يمكن؟

تبدو فكرة رائعة جدا! كيف ستبدو فوق وتحت؟ على غرار ما يفعله Visual Studio؟

رسم موسع
انهار رسومي
الذي يمكن للمطور تجاوزه بالشكل الذي يراه مناسبًا

قد تكون هذه طريقة للقيام بذلك ، ولكن هذا لن يسمح لنا بتحريك الرمز (مثل التدوير). ومع ذلك ، أعتقد أنه من المنطقي إعطاء الأولوية لإمكانية تبديل الرمز تمامًا بدلاً من الحصول على رسم متحرك هنا.

ربما تستخدم أيضًا محاذاة المحتوى للتعامل مع رأس ملء العرض ، أو جعل الحرف الرسومي والنص مجمعين معًا

100٪

بالنسبة لمركز الإشعارات ، يوجد كل شيء واضح على نفس خط الموسع ، فكيف يمكن التعامل مع هذا؟ نوع من الطرق لفصل اللوحة الموسعة عن الرأس الموسع؟

إنني قلق من أن هذا السيناريو المحدد قد يكون معقدًا للغاية بحيث لا يمكن تحقيقه ببساطة من خلال التحكم في الموسع. يعد وضع الأزرار أمرًا فريدًا تمامًا ، ولكن الأهم من ذلك ، أن الرأس وأيقونة التوسيع ليسا على نفس السطر الذي سيكون من الصعب جدًا القيام به باستخدام عنصر تحكم موسع قياسي يضع الرأس والرمز بجوار بعضهما البعض. هنا مثال للرجوع اليها:

أنا لست معارضًا لإعادة القوالب ولكن بالنظر إلى الأمثلة المنشورة حتى الآن ، يستخدم بعض المطورين ">" للتوسع glyoh والبعض الآخر يستخدم "v" للصورة الرمزية للتوسيع عند التوسيع عموديًا. نفس الشيء بالنسبة لموضع الصورة الرمزية. يجب أن يسهل عنصر التحكم Expander على المطورين تعيين الصورة الرمزية وفقًا لرغباتهم.

@ Felix-Dev هذا أحد الأشياء التي يجب توحيدها في نظام التصميم الطليق. من المهم أن يكون لدى المستخدمين شكل وأداء متسقين. الوقت الوحيد الذي يجب أن يتغير فيه هذا هو ما إذا كان يجب على التطبيق القيام بذلك لتلبية لغة التصميم الخاصة به أو إذا كانت هناك حالة استخدام جديدة لم نفكر فيها. في هذه الحالة - إعادة قالب.

تحرير: فاتني مثال Telerik الخاص بك في القراءة الأولى. ما زلنا نعتقد أننا نزيد التعقيد كثيرًا ونسمح بالعديد من خيارات التصميم التي من شأنها: (1) عدم التعرف عليها بسهولة من قبل المستخدمين (2) ستكشف الكثير من التعقيد الذي لم تكن هناك حاجة إليه تاريخيًا. بالطبع هناك خط رفيع هنا. نريد الكشف عن وظائف كافية لا يحتاج المستخدمون إلى إعادة تشكيلها ، لكننا أيضًا لا نريد الكشف عن الكثير من الوظائف بحيث تصبح لغة التصميم مشوشة.

WPF ، أو أي عناصر تحكم موسعة أخرى يمكنني التفكير فيها ، لم تكشف أبدًا عن خاصية للتحكم في هذا. إنه حقًا جزء كبير من العرض ويجب أن يستمر فقط في XAML. يجب ألا يعرف نموذج العرض (أي DPs لعنصر التحكم في هذه الحالة) أي شيء عن اختيار التصميم هذا في عنصر تحكم نظيف بلا مظهر.

WPF ، أو أي عناصر تحكم موسعة أخرى يمكنني التفكير فيها ، لم تكشف أبدًا عن خاصية للتحكم في هذا. إنه حقًا جزء كبير من العرض ويجب أن يستمر فقط في XAML. يجب ألا يعرف نموذج العرض (أي DPs لعنصر التحكم في هذه الحالة) أي شيء عن اختيار التصميم هذا في عنصر تحكم نظيف بلا مظهر.

robloo أحد الاحتمالات لفضح تخصيص الحروف الرسومية سيكون من خلال التصميم الخفيف الوزن. يجب اعتبار هذه الموارد ، تمامًا مثل DPs ، جزءًا من سطح API العام لعنصر تحكم ، لكنها أقرب بكثير إلى قالب التحكم (مظهر عنصر التحكم). لذلك يمكننا الكشف عن موارد مثل ExpanderExpandGlyph و ExpanderCollapseGlyph (يحتوي NavigationView على سبيل المثال على مورد NavigationViewItemExpandedGlyph ).

يمكن أيضًا قراءة الكشف عن تخصيص رمز الصورة الرمزية بهذه الطريقة كتوصية لتزويد عناصر الخط الموجودة في خط MDL2 ، وبالتالي استخدام الرموز المعتمدة من Fluent Design. بالنظر إلى خط MDL2 ، يبدو أنه يحتوي على جميع رموز التوسيع / ​​الانهيار الشائعة الاستخدام التي رأيتها في أمثلة حول الويب (الشيفرون المختلفة ، +/- ، +/- في الدوائر ، ...). على الرغم من أنه ربما لا يزال بإمكان المطورين تجاوز FontFamily (المقدم من المورد SymbolThemeFontFamily ) ، فإننا نعرض فقط موارد ExpanderExpandGlyph ، ... كموارد عامة للتحكم ، وبالتالي من المحتمل أن يكون المطورون أولًا انظر إلى عائلة خطوط MDL2 إذا كانوا يريدون تخصيص الرموز (نظرًا لأن هذه ستكون عائلة الخطوط الافتراضية التي يستخدمها Expander للحروف الرسومية).

بالنسبة للمهتمين ، هناك أيضًا مشكلة واحدة أخرى على الأقل لم يتم حلها حول المدى الذي نرغب في الوصول إليه بصفتنا WinUI لتوفير خيارات صور رمزية سهلة للتخصيص عندما تكون مجموعة الرموز الثابتة فقط منطقية في السياق المحدد (تخصيص NumberBox spin glyph) : https://github.com/microsoft/microsoft-ui-xaml/issues/2789 أعرف على الأقل أن البعض منكم على دراية بالفعل بهذه المشكلة ، لكن كما أرى بعض أوجه التشابه في المناقشة هناك كما هو الحال هنا فيما يتعلق بكيفية عرض خيار التخصيص (الصورة الرمزية) شعرت أنه يستحق الرجوع هنا. ربما يمكن أيضًا تطبيق الحل الموجود هنا في حالة NumberBox من أجل الاتساق في WinUI.

@ Felix-Dev توصيتك الخاصة بالتصميم الخفيف تبدو أكثر منطقية بالنسبة لي. هذا ما قصدته بعبارة "تحرير: قد يكون تحديد الموارد لبعض الأشياء لتحسين التصميم خفيف الوزن خيارًا معقولًا أيضًا." بعض التعليقات أعلاه.

السؤال هو كيف يحتمل أن المطورين لن يقدموا صورة رمزية ولكن لديهم شكل من أشكال الرموز الأخرى ، على سبيل المثال BitmapIcon أو شكل من أشكال FontIcon المخصصة. إذا لم تكن الرموز غير الرمزية حقًا نقطة تخصيص يستخدمها العديد من المطورين ، أعتقد أن مورد تصميم خفيف الوزن للصورة الرمزية (وربما واحد لخط الرمز) لاستخدامه هو أفضل شيء هنا ، كما اقترح robloo و @

تعد إعادة القوالب دائمًا خيارًا ، إذا كان الخط الرسومي أو الخط المخصص غير كافٍ.

• الحروف الرسومية للخطوط إما مع Segoe MDL2 أو FluentIcons هي الأكثر احتمالا وربما يجب أن تكون الافتراضية ؛

• لا يوجد حرف رسومي شائع أيضًا ؛

• ثم هناك مسارات ، SVGs أقل احتمالًا ولكنها ممكنة جدًا ؛

• ومن ثم ، فإن PNGs أو الصور النقطية الكاملة ليست خيارًا محتملًا ولكنها قد تكون خيارًا ممكنًا للمطورين.

أيا كان النهج المستخدم ، يجب أن يركز على الأرجح على السيناريوهين الأولين ، ولكن يسمح دائمًا بإعادة صياغة السيناريو الثالث.

ثم هناك إمكانية أن يكون لديك ContentPresenter للحرف الرسومي ، والسماح بوضع أي شيء عليه. لكن لست متأكدًا من كيفية عمل ذلك مع VisualStates للانتقال من مطوي إلى موسع.

بالنسبة لتحريك الأيقونة - ربما يمكن استخدام عنصر التحكم Lottie هنا؟

فكرة أخرى ، تمامًا مثل RadioButton و RadioButtons كمجموعة منهم ...

هل يجب أن تقوم مجموعة من الموسعات بعمل تحكم الأكورديون؟ ما من شأنه أن يسمح بسلوك يمكن فيه توسيع موسع واحد فقط في المرة الواحدة؟

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

تعد إعادة القوالب دائمًا خيارًا ، إذا كان الخط الرسومي أو الخط المخصص غير كافٍ.

الحروف الرسومية للخطوط إما مع Segoe MDL2 أو FluentIcons هي الأكثر احتمالا وربما يجب أن تكون الافتراضية ؛

لا يوجد حرف رسومي شائع أيضًا ؛

ثم هناك مسارات ، SVGs أقل احتمالًا ولكنها ممكنة جدًا ؛

ومن ثم ، فإن PNGs أو الصور النقطية الكاملة ليست خيارًا محتملًا ولكنها قد تكون خيارًا ممكنًا للمطورين.

أيا كان النهج المستخدم ، يجب أن يركز على الأرجح على السيناريوهين الأولين ، ولكن يسمح دائمًا بإعادة صياغة السيناريو الثالث.

ستكون إعادة التفكير دائمًا خيارًا ، ولكن بالطبع هذا شيء يمكن أن ينكسر بمرور الوقت إذا كانت هناك تغييرات (كبيرة) على عنصر التحكم. لذا من المحتمل أن يكون الحصول على مورد خفيف هو الأفضل هنا لأن تبديل الحروف الرسومية (وخط الأيقونة) هي السيناريوهات الأكثر شيوعًا.

ثم هناك إمكانية أن يكون لديك ContentPresenter للحرف الرسومي ، والسماح بوضع أي شيء عليه. لكن لست متأكدًا من كيفية عمل ذلك مع VisualStates للانتقال من مطوي إلى موسع.

لا يُحدث استخدام ContentPresenter فرقًا فيما يتعلق بالانهيار / التوسيع ، بل سيكون مجرد عنصر مثل العناصر الأخرى.

بالنسبة لتحريك الأيقونة - ربما يمكن استخدام عنصر التحكم Lottie هنا؟

السؤال هو ما نوع الرسوم المتحركة التي تريدها. يمكن أن يتم التناوب البسيط (وهو) بالفعل بدون لوتي.

فكرة أخرى ، تمامًا مثل RadioButton و RadioButtons كمجموعة منهم ...

هل يجب أن تقوم مجموعة من الموسعات بعمل تحكم الأكورديون؟ ما من شأنه أن يسمح بسلوك يمكن فيه توسيع موسع واحد فقط في المرة الواحدة؟

ربما يمكن أن يكون ذلك سيطرة منفصلة؟ في حين أن هناك سيناريوهات يمكن أن تكون حصرية لبعضها البعض ، أعتقد أنه في كثير من الحالات ، لا يهم حقًا ما إذا كانت العديد مفتوحة.

ثم هناك إمكانية أن يكون لديك ContentPresenter للحرف الرسومي ، والسماح بوضع أي شيء عليه. لكن لست متأكدًا من كيفية عمل ذلك مع VisualStates للانتقال من مطوي إلى موسع.

لا يُحدث استخدام ContentPresenter فرقًا فيما يتعلق بالانهيار / التوسيع ، بل سيكون مجرد عنصر مثل العناصر الأخرى.

ولكن هل سيكون ContentPresenter الذي تستخدمه كلتا الولايتين ، أم واحدًا لكل ولاية يتم تبديله / تبديله؟

بالنسبة لتحريك الأيقونة - ربما يمكن استخدام عنصر التحكم Lottie هنا؟

السؤال هو ما نوع الرسوم المتحركة التي تريدها. يمكن أن يتم التناوب البسيط (وهو) بالفعل بدون لوتي.

تكون التدويرات منطقية عندما يكون الحرف الرسومي سهمًا اتجاهيًا / شيفرونًا - ولكن ماذا لو كان المصباح الكهربائي يعمل وينطفئ لنوع من سيناريو تلميح أو تلميح؟ هناك اقتراح لعنصر تحكم عام للرموز المتحركة باستخدام Lottie # 2802 - هل يستدعي هذا الموقف ذلك ، حتى لو كان استخدامه الافتراضي / الأكثر شيوعًا هو تدوير رمز بسيط؟

فكرة أخرى ، تمامًا مثل RadioButton و RadioButtons كمجموعة منهم ...
هل يجب أن تقوم مجموعة من الموسعات بعمل تحكم الأكورديون؟ ما من شأنه أن يسمح بسلوك يمكن فيه توسيع موسع واحد فقط في المرة الواحدة؟

ربما يمكن أن يكون ذلك سيطرة منفصلة؟ في حين أن هناك سيناريوهات يمكن أن تكون حصرية لبعضها البعض ، أعتقد أنه في كثير من الحالات ، لا يهم حقًا ما إذا كانت العديد مفتوحة.

أذكرها فقط لأن Fast Design يتضمن عنصر تحكم أكورديون ، وهو في الأساس نفس مجموعة من الموسعات - فقط أن هناك واجهة برمجة تطبيقات متعددة وسلوك فردي والتي تغير كيفية عملهم معًا. باستخدام عنصر تحكم Expander ، سيكون الأكورديون الخطوة المنطقية التالية ويجب أن يكون من السهل نسبيًا تحقيقه باستخدام خاصية التوجيه لتجاوز الاتجاهات الفردية.

ثم هناك إمكانية أن يكون لديك ContentPresenter للحرف الرسومي ، والسماح بوضع أي شيء عليه. لكن لست متأكدًا من كيفية عمل ذلك مع VisualStates للانتقال من مطوي إلى موسع.

لا يُحدث استخدام ContentPresenter فرقًا فيما يتعلق بالانهيار / التوسيع ، بل سيكون مجرد عنصر مثل العناصر الأخرى.

ولكن هل سيكون ContentPresenter الذي تستخدمه كلتا الولايتين ، أم واحدًا لكل ولاية يتم تبديله / تبديله؟

كلا الخيارين منطقي. أعتقد أن تبديل محتوى ContentPresenter أفضل من تبديل ContentPresenter أو وجود اثنين وإخفاء / إظهار واحد.

بالنسبة لتحريك الأيقونة - ربما يمكن استخدام عنصر التحكم Lottie هنا؟

السؤال هو ما نوع الرسوم المتحركة التي تريدها. يمكن أن يتم التناوب البسيط (وهو) بالفعل بدون لوتي.

تكون التدويرات منطقية عندما يكون الحرف الرسومي سهمًا اتجاهيًا / شيفرونًا - ولكن ماذا لو كان المصباح الكهربائي يعمل وينطفئ لنوع من سيناريو تلميح أو تلميح؟ هناك اقتراح لعنصر تحكم عام للرموز المتحركة باستخدام Lottie # 2802 - هل يستدعي هذا الموقف ذلك ، حتى لو كان استخدامه الافتراضي / الأكثر شيوعًا هو تدوير رمز بسيط؟

ستكون الرسوم المتحركة بالتناوب إحدى طرق التحريك وسيكون من السهل تحقيقها. سيكون وجود رمز متحرك في رمز مختلف مختلفًا تمامًا. قد يؤدي ذلك أيضًا إلى جعل واجهة برمجة التطبيقات أكثر تعقيدًا (كيف يمكنك دعم مثل هذا السلوك؟ رسمتان متحركتان ورمزان؟ أو رسم متحرك واحد تتوقف عنه؟)

فكرة أخرى ، تمامًا مثل RadioButton و RadioButtons كمجموعة منهم ...
هل يجب أن تقوم مجموعة من الموسعات بعمل تحكم الأكورديون؟ ما من شأنه أن يسمح بسلوك يمكن فيه توسيع موسع واحد فقط في المرة الواحدة؟

ربما يمكن أن يكون ذلك سيطرة منفصلة؟ في حين أن هناك سيناريوهات يمكن أن تكون حصرية لبعضها البعض ، أعتقد أنه في كثير من الحالات ، لا يهم حقًا ما إذا كانت العديد مفتوحة.

أذكرها فقط لأن Fast Design يتضمن عنصر تحكم أكورديون ، وهو في الأساس نفس مجموعة من الموسعات - فقط أن هناك واجهة برمجة تطبيقات متعددة وسلوك فردي والتي تغير كيفية عملهم معًا. باستخدام عنصر تحكم Expander ، سيكون الأكورديون الخطوة المنطقية التالية ويجب أن يكون من السهل نسبيًا تحقيقه باستخدام خاصية التوجيه لتجاوز الاتجاهات الفردية.

صحيح ، فهمت. نعم ، يعد التحكم في الأكورديون فكرة جيدة بالتأكيد بعد التحكم في الموسع وربما يكون من السهل تنفيذه!

تكون التدويرات منطقية عندما يكون الحرف الرسومي سهمًا اتجاهيًا / شيفرونًا - ولكن ماذا لو كان المصباح الكهربائي يعمل وينطفئ لنوع من سيناريو تلميح أو تلميح؟ هناك اقتراح لعنصر تحكم عام للرموز المتحركة باستخدام Lottie # 2802 - هل يستدعي هذا الموقف ذلك ، حتى لو كان استخدامه الافتراضي / الأكثر شيوعًا هو تدوير رمز بسيط؟

ستكون الرسوم المتحركة بالتناوب إحدى طرق التحريك وسيكون من السهل تحقيقها. سيكون وجود رمز متحرك في رمز مختلف مختلفًا تمامًا. قد يؤدي ذلك أيضًا إلى جعل واجهة برمجة التطبيقات أكثر تعقيدًا (كيف يمكنك دعم مثل هذا السلوك؟ رسمتان متحركتان ورمزان؟ أو رسم متحرك واحد تتوقف عنه؟)

هذا سؤال كبير ، ولكي أكون صادقًا ، فهو شيء يتعلق باقتراح Animated Icon.

يعد تحريك الصورة الرمزية / الرمز جيدًا إذا كان سيظل دائمًا سهمًا. لكنه نوع من تأمين ذلك ، إلا إذا كان لديك طريقة سهلة لإزالة الرسوم المتحركة نفسها أو تغييرها.

يحافظ عمل رسم متحرك لوتي على الرسوم المتحركة الافتراضية ، ويعني مزيدًا من العمل المطلوب تنفيذه ، ولكنه أكثر مرونة في السماح بتغيير الرمز والرسوم المتحركة إذا لزم الأمر.

الخيار الأسهل هو عدم وجود رسوم متحركة للصورة الرمزية. ولكن كلما أضفت المزيد ، يصبح تسهيل التجاوز أو التغيير أكثر أهمية.

من خلال تصفح الويب ، أرى عددًا كبيرًا من الرموز الثابتة المستخدمة في الصور الرمزية للتوسيع / ​​الانهيار في أمثلة نموذجية لـ Expander UI. ومع ذلك ، في نظام التشغيل Windows ، لدينا أيضًا عملاء محتملون لعنصر التحكم هذا والذين يبدو أنهم يفضلون الرسوم المتحركة (انظر على سبيل المثال NavigationView وإشعارات التوست في الغلاف). يعد Motion أحد الركائز الأساسية لـ Fluent Design ، لذا فمن المنطقي هنا إبقاء الخيارات مفتوحة للعملاء الذين يريدون رسمًا متحركًا دون الحاجة إلى إعادة قالب عنصر التحكم.

من الناحية المثالية ، إذا رغبت فرق مختلفة في MS في استخدام المتوسع مع صورة رمزية متحركة (أي حرف سهم متحرك) ، فإن عنصر التحكم سيوفر خيارًا مدمجًا بحيث ينتهي بنا المطاف بتجربة متسقة افتراضيًا. إذا كان كل فريق مسؤولاً بنفسه عن الرسوم المتحركة ، فقد ينتهي بنا الأمر إلى رؤية مدة رسوم متحركة مختلفة ، واتجاهات رسوم متحركة مختلفة (أي في اتجاه عقارب الساعة أو عكس اتجاه عقارب الساعة) ، ... إذا كنت أتذكر بشكل صحيح ، الرسوم المتحركة للصورة الرمزية للإشعارات في يختلف مركز الإجراءات عن حركة الصورة الرمزية في NavigationView. يجب تجنب ذلك ، إذا أمكن.

تعتبر الرسوم المتحركة أكثر إشراقًا وتساعد في جعل واجهة المستخدم سلسة. يعد الترميز الثابت في Rotation Storyboard طريقة بسيطة لإضافة رسم متحرك ، ولكن إذا كان من الصعب إزالة هذه الرسوم المتحركة أو تغييرها - فربما يكون استخدام عنصر التحكم AnimatedIcon طريقة جيدة لإنشاء طريقة مرنة لتمكين التخصيص.

أنا لا أقول أن طريقة واحدة أفضل من الأخرى - فقط لفت الانتباه إليها هنا ، لأنها تقوم بتحريك أيقونة ، وهذا هو Raison Detra للتحكم الجديد.

وإذا تم الاعتراف بأن الصور الرمزية يجب أن تكون قابلة للتخصيص - فقد لا تكون الرسوم المتحركة بالتناوب مناسبة دائمًا.

ما يجب تحريكه وما لا يجب تحريكه هو سؤال صعب للغاية. كما ذكر مارتن بالفعل ، فإن الرسوم المتحركة بالتناوب لا تكون دائمًا منطقية. ولا يزال لدى الرموز المتحركة الكثير من الأسئلة المفتوحة.

أعتقد أنه قد يكون من الأفضل خدش الرسوم المتحركة glyph / icon لـ v1 بعد ذلك ، خاصةً لأنها ليست شائعة جدًا. شيء واحد يجب إعادة النظر فيه هو إذا قمنا بإزالة الرسوم المتحركة الموجودة في NavigationView الهرمي للحصول على تجربة موحدة. يوجد حاليًا بالفعل عدم تناسق بين TreeView و h-NavigationView في تنشيط / عدم تنشيط تبديل الرمز.

بالضبط. لم أكن أقصد عدم تشجيع أي استكشاف هنا مع فقرتي الأخيرة ، ولكن فقط أكتب مرة أخرى أن أحد التحديات التي نواجهها هنا يتعلق بتوفير خيارات تخصيص كافية خارج "الخيار النهائي" - إعادة التشكيل - لإرضاء العملاء المشتركين يريد ، مع التأكد من أن عنصر التحكم سيساعد في تحقيق المزيد من التناسق لنظام التشغيل Windows ، بدلاً من تقليله.

كما رأينا بالفعل ، قد لا يكون هناك حل مثالي هنا لأن الرغبة في توفير كل من تخصيصات الرموز ودعم الرسوم المتحركة (ربما بالإضافة إلى الرسوم المتحركة المضمنة لتحقيق التناسق) يمكن أن تتعارض بسهولة مع بعضها البعض.

قد يكون من المفيد الحصول على عملاء محتملين مثل Windows Shell هنا لمعرفة كيفية عرض الرسوم المتحركة. من المفترض أن يركز 10X بعض التركيز على الرسوم المتحركة ويمكن أن تكون تطبيقات Windows Shell وتطبيقات Windows المضمنة "عملاء" هنا. إذا تم اعتبار الصورة الرمزية المتحركة جزءًا مهمًا في UX بشكل عام ، فإن فريق Windows يسعى للحصول عليه مع 10x ، فقد يتطلب ذلك عدم "تنفيذ الركلات" في هذا التحدي في الوقت الحالي ، ولكن بدلاً من ذلك ، يتميز بدعم الرسوم المتحركة في V1.

أود أن أرى نهجًا ثابتًا لتحريك الرموز ، والذي يبدو الآن أنه اقتراح الرموز المتحركة.

لن أزيل أي رسم متحرك من NavigationView ، لأنه نموذج جديد تمامًا لـ WinUI - ويبدو أن الهدف هو إضافة رسوم متحركة إلى جميع عناصر التحكم المماثلة - لذلك ربما بمجرد أن يصبح جاهزًا ، يمكن أن يكون عنصر التحكم تمت إضافته إلى NavigationView

يبدو أن ElementAnimator أكثر من اللازم لتحريك Expander ، وأن ExpandTransition و CollapseTransition سيكون كافيًا.

mdtauk أشكركم على صنع الرسوم المتحركة بالحجم

أعتقد أن سلوك الأكورديون سيتحقق من خلال منطق على مستوى القائمة (بدلاً من عنصر تحكم أكورديون جديد) مع IsExpanded للمطورين لتخصيص هذا لسيناريوهات مختلفة (على سبيل المثال: حيث يغلق بعض الموسعين بعضهم البعض ويمكن توسيع البعض الآخر في نفس الوقت).

@ Felix-Dev - لقد أضفت Telerik Expander إلى الاقتراح ، شكرًا لمشاركته!

يبدو أن هناك رغبة في التخصيص في الاتجاهات التالية:

مظهر الحرف الرسومي : يبدو أن التصميم الخفيف هو المسار المفضل لتبديل الحروف الرسومية وخط الأيقونة ، من خلال الحصول على ExpanderExpandGlyph و ExpanderCollapseGlyph . هل هذا المستوى من التخصيص مطلوب في v1 Expander؟

@ Felix-Dev بينما ربما لا يزال بإمكان المطورين تجاوز FontFamily (الذي يوفره مورد SymbolThemeFontFamily) ، فإننا نعرض فقط ExpanderExpandGlyph ... وبالتالي من المحتمل أن ينظر المطورون أولاً إلى عائلة خطوط MDL2 إذا كانوا يريدون ذلك تخصيص الرموز (حيث ستكون عائلة الخطوط الافتراضية التي يستخدمها Expander للحروف الرسومية).

الرسوم المتحركة للصورة الرسومية : بما في ذلك التغيير إلى حرف رسومي مختلف عند التوسيع - والذي تم حله جزئيًا باستخدام AnimatedIcon # 2802. يبدو أن هذا المستوى من التخصيص ليس ضروريًا لـ v1 Expander.
وذكر chingucoding وأنا أميل إلى الموافقة:

أعتقد أنه قد يكون من الأفضل خدش الرسوم المتحركة glyph / icon لـ v1 بعد ذلك ، خاصةً لأنها ليست شائعة جدًا.

موضع الصورة الرمزية : هل هذا المستوى من التخصيص مطلوب في v1 Expander؟ ويتعقد هذا أيضا إذا تضمن V1 ExpandDirection والخيار لتغير موقف الصورة الرمزية. وصف @ فيليكس ديف

شيء مثل ExpandGlyphPlacementMode بقيم مثل TopLeft و TopRight و BottomCentered (وربما أكثر (Left، Right، ...)) ويمكن لمطوري خاصية ExpandGlyphPlacementOffset استخدام لتعديل الموضع الأساسي (تم تعيينه بواسطة وضع الموضع) إذا لزم الأمر.

آمل أن أكون قد فهمت بشكل صحيح المناقشة الرائعة من نهاية هذا الأسبوع - أخبرني إذا كنت مخطئًا في مكان ما! شكرًا جزيلاً لكم جميعًا على أفكاركم الثاقبة في هذا الشأن. 😄

مظهر الصورة الرمزية
موقف الصورة الرمزية

أعتقد أن هذه هي التخصيصات الأسهل والأكثر أهمية لتضمينها في V1.

أود أيضًا إضافة طريقة لإخفاء الصورة الرمزية

الرسوم المتحركة Glyph
انتقالات الدولة

يمكن منحها أولوية أقل إذا كانت هناك حاجة إلى تحديد الأولويات وكان السلوك الأساسي والوظائف يستغرق وقتًا طويلاً.

شكرا لترتيب الأولويةmdtauk!

لقد قمت بإضافة سؤال مفتوح جديد:

• كيف يجب أن يعمل Expander مع InfoBar؟ إضافة وظائف موسعة إلى شريط المعلومات؟ وضع InfoBar كمحتوى لبرنامج Expander؟ العكس؟

أتخيل أنه سيحل محل المحتوى ، لكن أعتقد أن أولئك الذين يصممون شريط المعلومات يجب أن يوفروا مواصفات تصميم لشريط قابل للطي ، يمكن لمصممي الموسع الاطلاع عليه.

إنها محادثة يجب إجراؤها

هناك مجموعة من المحادثات الرائعة هنا! في موضوع الرسوم المتحركة ...

يبدو أن ElementAnimator أكثر من اللازم لتحريك Expander ، وأن ExpandTransition و CollapseTransition سيكونان كافيين.

توافق على أن ElementAnimator أكثر من اللازم لتحريك برنامج Expander. قد ينجح الأمر إذا كان كل شيء موجودًا في ItemsRepeater ، لكن ElementAnimator لا يعمل خارج ItemsRepeater حتى الآن ، لذا سنحتاج إلى معرفة ذلك.

تعجبني فكرة وجود ExpandTransition و CollapseTransition نظريًا ، لكننا حصلنا على الكثير من التعليقات التي تفيد بأن واجهات برمجة التطبيقات الانتقالية جيدة من الناحية النظرية ولكنها أقل جودة في الممارسة لأنها غير قابلة للتخصيص ، فهي مرتبطة بشكل عام بعناصر التحكم في التي يتم استخدامها ، ولا أعتقد أنه يمكن بناؤها في سلسلة WinUI 2.x لأنها تعتمد على خطافات نظام التشغيل. نظرًا لعدم وجود هذه الانتقالات المحددة ، فإنني أفضل استكشاف خيارات أخرى بدلاً من الإضافة إلى مجموعتنا من واجهات برمجة تطبيقات ThemeTransition.

علاوة على كل ذلك ، فإن المنطقة العامة من "الرسوم المتحركة للتخطيط" حيث يتحرك المحتوى كنتيجة لعناصر واجهة المستخدم الجديدة التي تدخل / تنمو / تتقلص / تغادر الصفحة ليست مدعومة جيدًا في Xaml كمنصة اليوم. سيتطلب إصلاح هذا أيضًا WinUI 3 ، ولكنه ليس في خريطة الطريق الفورية.

بالنسبة إلى Expander على وجه الخصوص ، أعتقد أن الإجراء المناسب سينتهي به الأمر على الأرجح إلى:
1) قم بتثبيت الكود الثابت للرسوم المتحركة للنمو / التقلص في كود Expander (وفكر في تضمين واجهة برمجة التطبيقات لإيقاف تشغيلها - على الرغم من أنني لا أعتقد شخصياً أن أحدها ضروري)
2) تقديم إرشادات لمطوري التطبيقات حول كيفية تحريك المحتوى حول Expander بحيث ينزلق المحتوى الموجود أسفل Expander إلى الأسفل بدلاً من "القفز" لأسفل

لا أعتقد أن (2) يمكن حلها بشكل عام بدون "رسوم متحركة للتخطيط" ولكن ربما يمكن حلها باستخدام RepositionThemeAnimation على المحتوى الموجود أسفل Expander.

stmoy يمكننا استخدام PopInThemeAnimation لـ (1) إذا أردنا استخدام العناصر الموجودة.

تمت الموافقة على هذا الاقتراح لكتابة المواصفات .

كجزء من المناقشة مع فريق WinUI ، قررنا أنه يمكن تحديد نطاق Expander لدعم ExpandDirection للتوسع لأعلى / لأسفل في V1. يغطي هذا السيناريوهات التي رأيناها لـ Expander ويضع أساسًا لإضافة توسع يسار / يمين في المستقبل.

يرجى الشعور بالتشجيع لمواصلة المناقشة هنا ، وستحدث مناقشة أكثر تفصيلاً حول المواصفات والعلاقات العامة المرتبطة بها بمجرد توفرها. سأحب بشكل خاص سماع أفكارك حول هذا السؤال المفتوح:

• كيف يجب أن يعمل Expander مع InfoBar؟ إضافة وظائف موسعة إلى شريط المعلومات؟ وضع InfoBar كمحتوى لبرنامج Expander؟ العكس؟

بالنسبة إلى InfoBar ، أعتقد أنني بحاجة إلى فتح اقتراح منفصل للتعمق في ما يحتاجه على وجه التحديد وكيف يمكنه الاستفادة من عنصر تحكم Expander هذا. إليكم بعض أفكاري الأولى:

• يحتاج شريط المعلومات إلى تخصيص الرأس والمحتوى / جزء عنصر التحكم الموسع. يجب أن يُظهر شريط المعلومات رسالة "قطع" في الرأس عند طيها ورسالة كاملة في الجزء / المحتوى الموسع عند فتحه.
• لا _have_ شريط المعلومات للسماح بالاقتطاع ويجب أن يكون الخيار موجودًا للمطور لاختيار سلوك الالتفاف الحالي إذا لزم الأمر عبر خاصية "shouldTruncate".
• يمكن / يجب أن يصبح "شريط المعلومات" موسعًا إذا لم يعد المحتوى ملائمًا في سطر واحد وكان يجب أن يتم تعيينه على "صحيح". تنفيذ هذا وفهم متى بالضبط لإضافة السلوك الموسع هو المكان الذي يصبح فيه صعبًا 😊 يخفف MessageBar من ذلك عبر خاصية isMultiline الخاصة بهم ولكن يحتاج مزيد من التفكير إلى هذا المجال.

أعتقد أنه يمكننا أيضًا النظر في عناصر التحكم الأخرى في WinUI حاليًا والتي قد تستفيد من سلوك Expander هذا.

بعض التركيبات الأولية لاقتطاع شريط المعلومات:

بالنسبة للتنفيذ ، فإن أفكاري الأولية هي أن InfoBar يجب أن يُشتق من أداة Expander وألا يكون متداخلاً داخل محتوى Expander. أفكار؟

أعتقد أنه يمكننا أيضًا النظر في عناصر التحكم الأخرى في WinUI حاليًا والتي قد تستفيد من سلوك Expander هذا.

بعض التركيبات الأولية لاقتطاع شريط المعلومات:

أعتقد أن برنامج Expander قد يحتاج إلى أن يكون قادرًا على فصل زر شيفرون عن المحتوى الجاري توسيعه.

إخطارات تفعل هذا

سيسمح أيضًا لعنصر تحكم InformationBar بدمج برنامج Expander الخاص به.

إذا قمت بفصلها ، فهل يصبح ذلك سلوكًا / خاصية؟ لذلك إذا قمت بتحديد عنصر واجهة المستخدم أو زر لهذه الخاصية ، فلن يعرض Expander Header الزر الخاص به؟

بالنسبة للتنفيذ ، فإن أفكاري الأولية هي أن InfoBar يجب أن يُشتق من أداة Expander وألا يكون متداخلاً داخل محتوى Expander. أفكار؟

إذا لم يتمكن برنامج Expander من فصل المحتوى والرأس عن زر Toggle / Disclose - فسيتطلب ذلك مزيدًا من العمل حتى يتم تنفيذ InformationBar.

يجب أن يكون عنصر التحكم في برنامج Expander مرنًا قدر الإمكان خصيصًا للدمج في عناصر تحكم أخرى متنوعة من الآن فصاعدًا ، وكذلك للاستخدام في Windows Shell

لقد أضفت معلومات أولية إلى مواصفات Expander وفتحت العلاقات العامة - لا تتردد في متابعة مناقشة المواصفات هناك! إنه PR 100 في المواصفات الريبو 😄