يجب إضافة رابط لعينة Van Arsdel

أعتقد أن عناصر التحكم الأكثر عمومية من Toolkit يجب أن تجد طريقها دائمًا إلى C ++ ومتاحة في مكتبة Windows UI Library. تتحكم علامات التبويب عندما تكون ناضجة ومستقرة بدرجة كافية يجب أن تشق طريقها أيضًا.

حدث ذلك مع عنصر تحكم القائمة الرئيسية :)

تم استدعاء رابط لعينة Tab Tear-Off الواردة في الاقتراح أيضًا.

تم استدعاء رابط لعينة Tab Tear-Off الواردة في الاقتراح أيضًا.

هل يؤدي تمزيق علامة تبويب إلى ظهور AppWindow جديد و CoreWindow جديد وكيف يمكنك التعامل مع الوضع الاحتياطي حيث لا توجد واجهات برمجة تطبيقات للنافذة الجديدة؟

mdtauk يستخدم النموذج واجهة برمجة تطبيقات ApplicationView متعددة النوافذ الأقدم حاليًا ، ويتم إنشاء النافذة في وضع افتراضي بدلاً من مكان السحب. لقد كنت أختبر مع AppWindow وآمل أن أقوم بتحديث نموذج SDK الجديد.

"على الرغم من أن هذه الحلول قد ساعدت في سد فجوة النظام الأساسي من WPF ، إلا أن لديها عددًا من القيود ، بما في ذلك:"

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

تعليقات على الأسئلة المفتوحة مما سمعناه في مجموعة الأدوات:

1. هل يجب أن يكون Tab Tearoff شيئًا يتعامل معه عنصر التحكم أم يتعامل معه التطبيق؟

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

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

قد يكون من الأسهل فقط كشف الحدث والحصول على مساعدين (أو الاستفادة من المساعدين الحاليين مثل تلك الموجودة في Windows Template Studio) للمساعدة في إنشاء / إدارة Windows. أصعب جزء في هذا السيناريو هو "نقل البيانات" بين سلاسل العمليات ، والذي على الأقل يجب أن تساعد واجهة برمجة تطبيقات النوافذ الجديدة في التخفيف منه.

1. هل يجب أن يكون هناك زر "إضافة علامة تبويب جديدة" مدمج؟ (أظن أنه ليس كذلك ، لأن عنصر التحكم لا يمتلك مجموعة علامات التبويب.)

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

1. هل يجب أن يكون TabItem.Icon IconElement أم IconElementSource؟

استخدمنا IconElement لتقليد خاصية NavigationViewItem. أيضًا ، IconElementSource هو IconElement إذن أليس IconElement أفضل لأنه أوسع؟ سيكون من الرائع لو كانت هناك فئة فرعية IconElement في WinUI يمكنها فقط استضافة Image على الرغم من ذلك (على غرار BitmapIcon لكن بدون التقنيع القسري). بهذه الطريقة يمكن أن تستضيف خاصية Icon أي شيء سواء كان رمز Vector / رمز خط لطيف أو ملف ico / png (فكر في رمز فافي لسيناريو نوع المتصفح).

1. كيف يمكن لأحد التطبيقات تخصيص شكل علامة التبويب المحددة (على سبيل المثال ، في Edge)؟

هل تتحدث عن خصائص نمط مكشوفة يمكن تعديلها أو مثل قالب مختلف تمامًا للعنصر المحدد؟

1. تأخذ API حاليًا الكثير من الإلهام من Toolkit. هل هناك أي فرص للتكرار / التحسين؟

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

اسئلة اخرى:

• [] من المثير للاهتمام السحب حول كيفية التعامل مع السحب إلى منطقة المحتوى مقابل الرأس أيضًا هل كلا الهدفين؟ ماذا لو أراد التطبيق السماح بإسقاط شيء آخر في منطقة علامة التبويب (مثل ملف من المستكشف)؟
• [] هل "قد يقرر التطبيق كيفية وضع / حجم علامات التبويب" يتحدث عن خاصية TabStripPlacement ؟

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

لقد انتهينا من استخدام نموذج Edge لأنه كان أسهل في التنفيذ ، حيث لم نكن بحاجة إلى كائن من النوع SplitObservableCollection . لقد بدأت العمل على أحدها كاختبار ، لكنني أتساءل عما إذا كان سيكون من المفيد الكشف عنها؟

stmoy هل أغلقت على المشكلات المفتوحة / التعليقات الواردة أعلاه التي حصلنا عليها من تصميمات مجموعة الأدوات؟

كيف تؤثر أخبار مجموعات Windows التي تتخلى عن نموذج Edge Tab على كيفية تطوير عنصر التحكم هذا؟

مع Edge وواجهة المستخدم التي تم التخلي عنها الآن لصالح ChromiumEdge (Edgium) ، هل نحتاج / نريد إعادة التفكير في مظهر أو سلوك عنصر التحكم هذا ليكون أكثر ملاءمة لأنواع التطبيقات التي قد تستخدمه؟

• حوارات الملكية
• MDI (واجهات مستندات متعددة) - مثل Photoshop ؛
• لوحات الأدوات الراسية (Visual Studio / Blend / Adobe CC) ؛

ناهيك عن عناصر تحكم مماثلة مثل Pivot و UWP Ribbon قيد التطوير. أيهما موصى به لحالة الاستخدام ولماذا يختار أحدهما على الآخر؟ يجب أن تكون الإرشادات والأمثلة واضحة للإجابة على هذه الأسئلة لتجنب الارتباك أو استخدام عنصر تحكم أثقل بدلاً من عنصر أداء وأخف وزنًا.

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

في # 629 ، كان لدى mdtauk اقتراح خاص بميزة:

ربما فكرة لقائمة المهام. وضع علامة التبويب؟ أسفل ، يسار ، يمين.

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

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

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

لذلك قد يكون هناك مجال لإعادة التفكير في TabView / Control لجعله أكثر مرونة وفائدة للمستقبل.

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

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

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

شكرا لجميع هذه المحادثة الرائعة! العودة حول ...

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

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

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

هل "قد يقرر التطبيق كيفية وضع / حجم علامات التبويب" يتحدث عن خاصية TabStripPlacement؟

كان هذا يعني وصف خاصية "TabWidthBehavior" والتعداد وليس TabStripPlacement. لقد قمت بتحديث المطلب وأضفت أيضًا شرط وضع علامة التبويب (تمت مناقشته قليلاً أدناه).

اختفت المجموعات من خريطة الطريق ، كما هو الحال مع إصدار XAML من Edge.

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

يجب أن يكون موضع علامة التبويب في أعلى قائمة الأولويات في وقت ما لمطابقة تكافؤ WPF لسيناريوهات الترحيل. إنه شيء لم يكن لدينا الوقت لإضافته في إصدار Toolkit الأولي أيضًا.

يعد Tab Placement فكرة رائعة ، لا سيما فيما يتعلق بتكافؤ WPF. وفقًا لما سبق ، ومع ذلك ، نظرًا لأننا نحدد النطاق إلى حد كبير بناءً على ما تحتاجه المحطة الطرفية ، فإن هذا ينتهي بأن يكون "يمكن" أكثر من "حاجة". ومع ذلك ، أضفته إلى جدول المتطلبات أعلاه.

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

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

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

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

نمط الزر وأمر XAML [لإضافة علامة تبويب جديدة]

mdtauk - فكرة رائعة. سأضيفه إلى المواصفات.

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

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

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

عبرت الأصابع عن شعورها بأنها تشبه علامات تبويب Chrome أكثر من علامات تبويب Edge.

عبرت الأصابع عن شعورها بأنها تشبه علامات تبويب Chrome أكثر من علامات تبويب Edge.

نريد أن يكون التصميم التفاعلي "على ما يرام" ، لذا قم بالتأكيد بتقديم المشكلات مع ملاحظات محددة مقابل إصدار المعاينة حتى نتمكن من الحصول عليها بشكل صحيح قبل الشحن!

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

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

للحصول على أمثلة ، راجع زر الإغلاق في Edge UWP (تغييرات المقدمة فقط) أو زر كتم صوت علامة التبويب في Edge (Chromium).

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

mdtauk - أنت صخرة. شكرا لك على إنشاء تركيبات التصميم هذه. على الرغم من أننا لن نقوم بوضع جانبي للقطرة الأولى من عنصر التحكم ، إلا أنه من الرائع رؤية الشكل الذي يمكن أن يبدو عليه.

نعمل أنا و chigy معًا لإنشاء بعض تركيبات التصميم التي تتوافق مع مبادئ Windows (بما في ذلك أشياء مثل الزوايا الدائرية والظل القياسي وما إلى ذلك) ولكن تركيبات التصميم التي قدمتها ستساعدنا في إلهامنا.

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

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

تستخدم علامات التبويب Edge خلفية خلف الصورة الرمزية القريبة ، لكنها أصغر من تلك التي اقترحتها - لكن علامات تبويب Edgium لا تدعم أي أوضاع Touch حتى الآن.

عندما كنا نفكر في علامات التبويب الجانبية لتصميم مجموعة الأدوات ، كنا ممزقين بين القيام بها عموديًا باستخدام نص مستدير كما أظهر mdtauk أو ما زلنا نضعها في وضع أفقي وأخذ هامش أكبر إلى الجانب الأيسر / الأيمن مثل استخدام OneNote لـ قبل إعادة تصميمهم الأخيرة وقريبًا لـ WPF (والذي كنا نظن أنه سيكون مهمًا للتوافق).

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

@ michael-hawker أؤيد وجود قائمة عمودية بعلامات التبويب إلى اليمين بهامش عريض ، وتسهيل تدويرها كما هو الحال في Visual Studio.

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

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

أنا في المنزل ، وهذا هو التصميم:

لقد قمت بتحسين نموذج تصميم بالحجم الطبيعي للتحكم.

_ تجاوز علامة التبويب المضافة وتحجيم علامات التبويب_

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

ما زلت آمل أن يتم إنشاء زر إغلاق علامة التبويب كما هو الحال في Edge UWP ، حيث يتم عرض الزر فقط لعلامة التبويب المحددة حاليًا أو عند تمرير الماوس فوق علامة التبويب.

بالنسبة لفريق WinUI: stmoy على ما يبدو ، لا يمكن لفريق Windows Terminal استخدام الأكريليك كخلفية للتحكم في علامة التبويب (راجع https://github.com/microsoft/terminal/issues/1375). يدعي فريق المحطة أن ذلك يرجع إلى قيود معمارية. هل هذا شيء يمكن لفريق WinUI المساعدة فيه؟ يبدو أن هناك عددًا غير قليل من المعجبين بخلفية الأكريليك للتحكم في علامة التبويب كما هو الحال في Edge UWP.

@ Felix-Dev أعرف أن Edgeium هو التصميم الجديد الذي يجب المضي قدمًا نحوه ، لكنني أعتقد أن تصميم UWP Edge أجمل قليلاً - لذلك أردت محاولة سد هذه الفجوة

ما زلت آمل أن يتم إنشاء زر إغلاق علامة التبويب كما هو الحال في Edge UWP ، حيث يتم عرض الزر فقط لعلامة التبويب المحددة حاليًا أو عند تمرير الماوس فوق علامة التبويب.

CloseButtonOverlay هي الخاصية التي من شأنها أن تفعل ذلك على ما أعتقد

تضمين التغريدة
للتوضيح ، أود أن أرى CloseButtonOverlay = OnHover ليصبح الافتراضي للتحكم في علامة التبويب ، بدلاً من عرض زر الإغلاق باستمرار في جميع علامات التبويب (بدون داعٍ يأخذ مساحة من عنوان علامة التبويب imo).

المرئي دائمًا هو الأفضل لمستخدمي اللمس ، لذلك أعتقد أن الإعداد الافتراضي يجب أن يكون شاملاً قدر الإمكان

ربما يمكن جعل وضع التراكب لزر الإغلاق يعتمد على إمكانيات شاشة المستخدم بعد ذلك؟

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

ربما يمكن جعل وضع التراكب لزر الإغلاق يعتمد على إمكانيات شاشة المستخدم بعد ذلك؟

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

يعمل هذا مع أشياء مثل flyouts لأنه يمكنه اكتشاف نوع الإدخال الذي أدى إلى تشغيله ، مما يوفر أهدافًا أكبر للمس إذا تم استدعاؤها عن طريق إدخال اللمس.

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

سيتمكن المطورون من تغيير الخيار الافتراضي بالطبع ، وإذا تلقى التطبيق الكثير من التعليقات التي تطلب عرض زر الإغلاق عند التمرير فقط - فيمكنهم اختيار تغييره.

لقد أضفت فكرة عن تجاوز علامة التبويب

احب هذا.

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

احب هذا.

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

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

تبويب التحجيم

mdtauk : أحب رؤية هذه التصاميم! لدي بعض الأسئلة الاستقصائية:

• هل اللون الأرجواني هو لون التمييز؟
• هل الغرض من لقطة الشاشة الفائضة هو إظهار الملصقات الصغيرة؟ أريد فقط التأكد من أنني أقرأ الصورة بشكل صحيح.
• ما هو نصف قطر الزاوية لعلامات التبويب؟
• كم يبلغ ارتفاع علامات التبويب؟
• ما هو حجم الخط المستخدم؟

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

@ فيليكس ديف: شكرا لك على ردود الفعل ؛ معالجة بعض النقاط الخاصة بك أدناه.

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

نحن نكرر بنشاط مع فرق مختلفة (بما في ذلك فرق Terminal و Edge) لمحاولة محاذاة علامات التبويب عبر تجارب التطبيقات هذه. مع استمرارنا في التكرار (وتنفيذ عناصر مثل # 524) ، سيبدو تصميم التحكم في علامات التبويب أكثر اتساقًا مع عناصر التحكم المحدثة.

ما زلت آمل أن يتم إنشاء زر إغلاق علامة التبويب كما هو الحال في Edge UWP ، حيث يتم عرض الزر فقط لعلامة التبويب المحددة حاليًا أو عند تمرير الماوس فوق علامة التبويب.

على المدى القصير ، نركز على تنفيذ السيناريوهات التي تحتاجها الوحدة الطرفية وتقليم سطح واجهة برمجة التطبيقات عند الاقتضاء. بالنسبة للإصدار 1 ، فإننا ندعم استمرار فقط. ومع ذلك ، فقد حددت في الأصل سلوك التمرير أيضًا لأنني أعتقد أنها فكرة رائعة. أنا أتابع هذه الأنواع من الطلبات (مثل x-on-hover ، وموضع الجدولة ، وما إلى ذلك) حتى نتمكن من إعادة التقييم في المراجعة التالية لعنصر التحكم.

بالنسبة لفريق WinUI: stmoy على ما يبدو ، لا يمكن لفريق Windows Terminal استخدام الأكريليك كخلفية للتحكم في علامة التبويب (راجع Microsoft / Terminal # 1375). يدعي فريق المحطة أن ذلك يرجع إلى قيود معمارية. هل هذا شيء يمكن لفريق WinUI المساعدة فيه؟ يبدو أن هناك عددًا غير قليل من المعجبين بخلفية الأكريليك للتحكم في علامة التبويب كما هو الحال في Edge UWP.

نحن نعمل بنشاط مع فريق Terminal. لسوء الحظ ، هذا السيناريو هو نتيجة قيود معروفة مع جزر Xaml وليس مع علامات التبويب. نتوقع أن تتمكن التطبيقات غير الطرفية من استخدام خلفية أكريليك كميزة "اشتراك" إذا قام التطبيق بتعيين TabControl.Background على فرشاة أكريليك.

هل اللون الأرجواني هو لون التمييز؟

نعم - لم أرغب في الخلط بين تصميمي وشركات تصميم رسمية

هل الغرض من لقطة الشاشة الفائضة هو إظهار الملصقات الصغيرة؟ أريد فقط التأكد من أنني أقرأ الصورة بشكل صحيح.

نعم ، يُظهر كيف سيبدو الزران الأيمن والأيسر ، وكيف سيتم قص علامات التبويب.

ما هو نصف قطر الزاوية لعلامات التبويب؟

4 epx - أعلم أن التوجيه هو 2epx ، لكن ارتفاع 4epx للمؤشر المحدد بدا أفضل مع 4

كم يبلغ ارتفاع علامات التبويب؟

40 epx

ما هو حجم الخط المستخدم؟

14 لنص عنوان علامة التبويب ، و 16 لرموز MDL2

يوجد في Edge Canary علامة تسمى رسوم متحركة جديدة لتحميل علامات التبويب - edge: // flags # new -tab-loading-animation

يجب أن يشتمل جزء من المواصفات على سمة و / أو رسوم متحركة ضمنية مثل:

• TabAdd الرسوم المتحركة
• TabRemoveAnimation
• TabSwitchToAnimation
• TabSwitchFromAnimation
• TabSelectedSwitchToAnimation
• TabSelectedSwitchFromAnimation
• TabDragOutAnimation
• TabPlacedAnimation

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

نحن نعمل بنشاط مع فريق Terminal. لسوء الحظ ، هذا السيناريو هو نتيجة قيود معروفة مع جزر Xaml وليس مع علامات التبويب.

هل من الممكن معالجة هذا القيد في الإصدارات المستقبلية من Xaml Island؟ يبدو أن هناك رغبة قوية في استخدام أكريليك الخلفية في تطبيق Windows Terminal ، على سبيل المثال. راجع https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390 وخاصة الصورة الأخيرة في هذا المنشور (مع خلفية أكريليك في شريط العنوان). لاحظ أيضًا العديد من الأصوات المؤيدة التي حصلت عليها هذه المشاركة 😉. منشور آخر به العديد من الأصوات الإيجابية هنا: https://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

عند التحدث على نطاق أوسع عن تصميم واجهة مستخدم Tabs ، لاحظ أيضًا ردود الفعل الداعمة لتعليقات المستخدم التي تفضل أن تنظر علامات تبويب Edge UWP فوق مظهر علامة تبويب Edge Chromium: https://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 و نشر مباشرة تحتها.

إذا كانت علامات تبويب Edge Chromium تهدف إلى تمثيل المظهر المستقبلي لعلامات تبويب Windows (الحديثة) ، فقد تكون ردود فعل المستخدم الساحقة هذه سببًا لإعادة التفكير في مظهر علامات التبويب المستخدمة في كل من Edge Chromium و WinUI. (يمكنك أيضًا إضافة chigy هنا حتى تتمكن من ملاحظة تفاعلات واجهة مستخدم علامة التبويب هذه في Windows Terminal repo.)

تحرير: لفت انتباه @ marb2000 أيضًا إلى هذا الموضوع حيث أكد فريق Windows Terminal للتو أنهم "لن يتمكنوا من إصلاح" هذه المشكلة. كيف يرى فريق WinUI فرص ظهور شريط عناوين أكريليك (مطلوب بشدة!) يحدث لويندوز تيرمينال؟ تضمين التغريدة

@ marb2000stmoy يرجى التعليق على السؤال أدناه:

كما لفت انتباه @ marb2000 إلى هذا الموضوع حيث أكد فريق Windows Terminal للتو أنهم "لن يتمكنوا من إصلاح" هذه المشكلة [(شريط عنوان أكريليك في المحطة)]. كيف يرى فريق WinUI فرص ظهور شريط عناوين أكريليك (مطلوب بشدة!) يحدث لويندوز تيرمينال؟

MustafaHosny اللهم امين يارب

تم إرسال تنبيه لكل شخص منكم يا رفاق من مكالمة المجتمع الأخيرة 😁
حول الدعم الفني لشريط العنوان الأكريليكي في جزر Xaml (Windows Terminal) ، راجع منشوراتي أعلاه والتي تم الرد عليها جزئيًا بواسطة stmoy

فيما يلي ثلاث نقاط رئيسية مأخوذة من مشاركاتي والردود أعلاه:

بالنسبة لفريق WinUI: من الواضح أن فريق Windows Terminal لا يمكنه استخدام الأكريليك كخلفية للتحكم في علامة التبويب (انظر Microsoft / Terminal # 1375). يدعي فريق المحطة أن ذلك يرجع إلى قيود معمارية. هل هذا شيء يمكن لفريق WinUI المساعدة فيه؟ يبدو أن هناك عددًا غير قليل من المعجبين بخلفية الأكريليك للتحكم في علامة التبويب كما هو الحال في Edge UWP.

رد بواسطة stmoy :

نحن نعمل بنشاط مع فريق Terminal. لسوء الحظ ، هذا السيناريو هو نتيجة قيود معروفة مع جزر Xaml وليس مع علامات التبويب. نتوقع أن تتمكن التطبيقات غير الطرفية من استخدام خلفية أكريليك كميزة "اشتراك" إذا قام التطبيق بتعيين TabControl.Background على فرشاة أكريليك.

سؤالي:

كما لفت انتباه @ marb2000 إلى هذا الموضوع حيث أكد فريق Windows Terminal للتو أنهم "لن يتمكنوا من إصلاح" هذه المشكلة [(شريط عنوان أكريليك في المحطة)]. كيف يرى فريق WinUI فرص ظهور شريط عناوين أكريليك (مطلوب بشدة!) يحدث لويندوز تيرمينال؟

شكرا على الرد 😁