Xamarin أشكال عارض wpf وبعض برامج عرض android مثل ButtonRenderer سريعة ، ونحن نعلم ما الذي تعنيه كلمة "fast" هنا.
هل هؤلاء العارضين سيكونون سريعين أم لا؟
شكرا لك مقدما.

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

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

لماذا لا نصنع إطار عمل UI بمجموعة خاصة من عناصر التحكم بدون أي نوع من التعيينات والمنطق السلوكي مكتوب بالكامل على c # يتم عرضه باستخدام مكتبة رسومات Skia؟ نظرًا لأن الأشخاص يستخدمون تصميمًا مخصصًا بشدة ، فلا داعي لمحاولة مطابقة إرشادات تصميم النظام الأساسي. الحاجة الوحيدة هي إمكانية تخصيصات مرنة. من فضلك صححني إذا فقدت شيئًا ما ، لكنني لا أفهم سبب تجاوز المنفعة هندسة Renderer.

باستخدام هذا النهج ، هل من الممكن كتابة عارض عبر الأنظمة الأساسية بدلاً من العارض الخاص بالنظام الأساسي؟ مثل تعيين زر التحكم مع تحكم skia-sharp.

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

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

أعتقد أن تقديم التطبيق بالكامل كقماش ثنائي الأبعاد مخصص قد يعمل بسلاسة لتطبيق الجوال.

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

لماذا لا نصنع إطار عمل UI بمجموعة خاصة من عناصر التحكم بدون أي نوع من التعيينات والمنطق السلوكي مكتوب بالكامل على c # يتم عرضه باستخدام مكتبة رسومات Skia؟ نظرًا لأن الأشخاص يستخدمون تصميمًا مخصصًا بشدة ، فلا داعي لمحاولة مطابقة إرشادات تصميم النظام الأساسي. الحاجة الوحيدة هي إمكانية تخصيصات مرنة. من فضلك صححني إذا فقدت شيئًا ما ، لكنني لا أفهم سبب تجاوز المنفعة هندسة Renderer.

أعتقد أن تقديم التطبيق بالكامل كقماش ثنائي الأبعاد مخصص قد يعمل بسلاسة لتطبيق الجوال.

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

لماذا لا نصنع إطار عمل UI بمجموعة خاصة من عناصر التحكم بدون أي نوع من التعيينات والمنطق السلوكي مكتوب بالكامل على c # يتم عرضه باستخدام مكتبة رسومات Skia؟ نظرًا لأن الأشخاص يستخدمون تصميمًا مخصصًا بشدة ، فلا داعي لمحاولة مطابقة إرشادات تصميم النظام الأساسي. الحاجة الوحيدة هي إمكانية تخصيصات مرنة. من فضلك صححني إذا فقدت شيئًا ما ، لكنني لا أفهم سبب تجاوز المنفعة هندسة Renderer.

أنت محق تمامًا بشأن كل هذه الأشياء ، لكن الفريق ليس مجبرًا على اختيار الطريقة الوحيدة. أعتقد أن هذا كله يتعلق بضيق الوقت. أعني أنهم يحتاجون فقط إلى إصدار إطار عمل واجهة مستخدم متعدد المنصات "جديد تمامًا" في عام واحد مع .net 6. ومن غير المجازفة اتخاذ إطار عمل قديم جيد تم اختباره على مدار الوقت كأساس. لا بأس ويجب أن يكون. لكنني أعتقد أنه على المدى الطويل ، فإن عرض القماش ثنائي الأبعاد المخصص له فوائد أكثر بكثير ويستحق حقًا أن يُطلق عليه اسم "المنصة المشتركة". أشكال Xamarin هي شيء جيد حقًا ولديها تقدم هائل لهذا اليوم. لكن حان الوقت للمضي قدمًا. لدى فرق Microsoft و xamarin مهندسون أذكياء جدًا وربما يفكرون في مثل هذا النهج أو ربما لديهم بعض الاتصالات مع http://avaloniaui.net/ كبطاقة رابحة

لماذا لا نصنع إطار عمل UI بمجموعة خاصة من عناصر التحكم بدون أي نوع من التعيينات والمنطق السلوكي مكتوب بالكامل على c # يتم عرضه باستخدام مكتبة رسومات Skia؟ نظرًا لأن الأشخاص يستخدمون تصميمًا مخصصًا بشدة ، فلا داعي لمحاولة مطابقة إرشادات تصميم النظام الأساسي. الحاجة الوحيدة هي إمكانية تخصيصات مرنة. من فضلك صححني إذا فقدت شيئًا ما ، لكنني لا أفهم سبب تجاوز المنفعة هندسة Renderer.

قد يكون من الرائع الحصول على النسخة الافتراضية الرابعة من اللون الرمادي لمطوري Skia وسيقومون بتغييرها بنسبة 100٪ بالتأكيد لتقديم تصميم غني ،
للاحتكاك الخلفي سيترك هؤلاء الثلاثة كما هم ولكن أضف "ارسمها بنفسك عزيزي المطور" _skia_render وتحمل مسؤولية مطور تكنولوجيا المعلومات بنسبة 90٪.

إذا كان سيتم الحفاظ على مفهوم العارضين ، فهل يمكن التفكير في إزالة الجسر بين كود واجهة المستخدم المشتركة والعارضين عبر INotifyPropertyChanged ومعالجات الأحداث؟ بمعنى آخر

• بدلاً من تعيين _property_ على عنصر التحكم المشترك ويتم نشر حدث PropertyChanged ، هل يمكن تعيين الخاصية وتعيينها مباشرةً على عارض النظام الأساسي؟
• بدلاً من استدعاء _method_ على عنصر التحكم المشترك وحدث يتم تشغيله ومعالجته بواسطة العارض ، هل يمكن تعيين الطريقة وإشراكها مباشرةً في عارض النظام الأساسي؟

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

هذا طويل ولكنه يستحق المشاهدة لبعض "البيسبول الداخلي" على جزيرة ماوي.
https://www.youtube.com/watch؟v=_MGh3xipWm4

يبدو أن بنية Maui ستدعم كلاً من عناصر التحكم في النظام الأساسي وعناصر التحكم المرسومة بالقماش ، علاوة على ذلك ،

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

هذا بعيد قليلاً عن الموضوع ، لكن هذا شيء أردت أن أسأله لمجرد علاقته بهذا الشيء بالتحديد:

كيف تعمل الذاكرة مع SKCanvasView (أو Skia بشكل عام)؟ هل كل واحد يشغل دائمًا ذاكرة تتناسب مع حجمه؟ هل يتغير هذا إذا تداخل مع الآخرين؟

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

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

GalaxiaGuy أعتقد أن استخدام عنصر تحكم skia متداخل مع عنصر تحكم غير Skia ، تمامًا مثل عنصر تحكم winform المستضاف على عنصر تحكم wpf. يمكنك القيام بذلك ، ولكن ليس الأفضل.
إذا كان لديك عنصر تحكم تم تقديمهما بواسطة SKCanvasView ، فلن تتم مشاركة سياق الرسومات. أفضل طريقة هي تجميع الاثنين المرسومين ورسمهما على لوحة قماشية واحدة.
في الاختبار الذي أجريته ، لا يكون أداء SkiaSharp سيئًا للغاية إذا قمت ببعض الأشياء الثابتة. وأحاول القيام ببعض الرسوم المتحركة ، فإن استخدام وحدة المعالجة المركزية مرتفع قليلاً على جهاز الكمبيوتر المحمول.

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

كان أكبر وعد لـ XAML مع WPF منذ العصور ، هو فكرة Lookless Controls حيث تم تأجيل الرسومات الفعلية
لا أعتقد أننا بحاجة إلى مجموعة أخرى من الواجهات والتجريدات على المكونات الموجودة في أنظمة تشغيل وأطر عمل مختلفة ، ولكن عناصر تحكم تستند إلى XAML لا تبدو حقيقية -

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

متفق! وتحتاج حقًا إلى عدد قليل جدًا من أساسيات العرض لإنجاز 99٪ على الأرجح من كل شيء يحتاجه التطبيق:

• الحدود (بما في ذلك خيارات الظل المسقط والحواف الدائرية)
• الخطوط / القطع الناقص / المستطيلات
• عرض نص عادي
• إدخال نص عادي
• عرض نص منسق
• إدخال نص منسق
• عرض HTML
• مقدم الصورة
• مقدم الصوت / الفيديو
• فرش متدرجة صلبة وخطية / شعاعية

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

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

تحتاج حقًا إلى عدد قليل جدًا من أساسيات العرض لإنجاز 99٪ على الأرجح من كل شيء يحتاجه التطبيق.

منصة أونو تستخدم هذا النهج.

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

بدلاً من تعيين خاصية على عنصر التحكم المشترك ونشر حدث PropertyChanged ، هل يمكن تعيين الخاصية وتعيينها مباشرةً على عارض النظام الأساسي؟

هذا هدف كبير لهذا التغيير أيضًا. بمجرد أن نكون على الجانب الآخر من هذه التغييرات ، لن يكون لدى العارضين أي فكرة عما يعنيه BindableObject أو INPC

هذا هدف كبير لهذا التغيير أيضًا. بمجرد أن نكون على الجانب الآخر من هذه التغييرات ، لن يكون لدى العارضين أي فكرة عما يعنيه BindableObject أو INPC

لذلك سيتم استدعاء طريقة على العارض بواسطة إطار العمل عندما تتغير قيمة BindableProperty بدلاً من أن يشترك العارض في PropertyChanged ؟

legistek الحق

هذا في الأساس يعكس التبعيات

لذا فإن العارضين سيعملون فقط ضد زر IButton.

وبعد ذلك ، سيضيف System.Maui مرجعًا إلى مشروع العارضين يعارض في الوقت الحالي كيف يكون لدى العارضين إشارات إلى Xamarin.Forms.Core

لقد تحققت في ارتفاع لدينا هنا
https://github.com/dotnet/maui/pull/66

لذا يمكنك أن ترى ما قد يبدو عليه هذا

سأجري بثًا اليوم في الساعة 3:30 بتوقيت المحيط davidortinau وسنتحدث عن العارضين النحيفين

https://www.twitch.tv/microsoftdeveloper

انضم إلينا! تحقق من ذلك! وطرح الأسئلة!

@ PureWeen للأسف فاتني ذلك. هل سيكون هناك تسجيل متاح على موقع يوتيوب؟

هذا هدف كبير لهذا التغيير أيضًا. بمجرد أن نكون على الجانب الآخر من هذه التغييرات ، لن يكون لدى العارضين أي فكرة عما يعنيه BindableObject أو INPC.

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

الذهاب إلى مراجعة # 66 اليوم.

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

• هل ستعالج أجهزة العرض Slim مشكلات GC ، خاصةً على نظام Android حيث يوجد عدم تطابق بين دورة حياة التحكم المُدار والمحلي؟ هذا ملحوظ بشكل خاص في عروض الأطفال في التخطيطات الافتراضية التي تؤدي إلى ObjectDisposedException اللعين.
• هل ستؤدي أجهزة عرض Slim إلى إهمال Effect ؟ يمكن أن تكون التأثيرات مفيدة ، ولكنها في النهاية تضيف تعقيدًا وإمكانية أخرى لوقت الاستجابة لدورة حياة التخطيط.
• كيف تعمل خاصية "ثنائية الاتجاه" مع تصميم العارض الجديد؟ على سبيل المثال ، لنفترض أن لديّ MediaElement مع خاصية Position ( TimeSpan ). تقوم أداة Setter بتحديث الموضع الحالي ، وتسترد أداة الاستلام الموضع الحالي من مشغل الوسائط الأصلي ، أي AVPlayer ، MediaPlayer . هل يوجد تصميم لتعيين _getter_ باستخدام أجهزة عرض ضئيلة؟

هل ستعالج أجهزة العرض Slim مشكلات GC ، خاصةً على نظام Android حيث يوجد عدم تطابق بين دورة حياة التحكم المُدار والمحلي؟ هذا ملحوظ بشكل خاص في المشاهدات الفرعية في التخطيطات الافتراضية التي تؤدي إلى ObjectDisposedException اللعين.

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

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

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

كيف تعمل خاصية "ثنائية الاتجاه" مع تصميم العارض الجديد؟ على سبيل المثال ، لنفترض أن لدي MediaElement بخاصية Position (TimeSpan). يقوم Setter بتحديث الموضع الحالي ، ويسترد getter الموضع الحالي من مشغل الوسائط الأصلي ، مثل AVPlayer و MediaPlayer. هل يوجد تصميم لتعيين أداة تصوير باستخدام عارضين رفيعي المستوى؟

ما زلنا نعمل على هذا قليلاً. صححني إذا كنت مخطئًا https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

كيف تعمل خاصية "ثنائية الاتجاه" مع تصميم العارض الجديد؟ على سبيل المثال ، لنفترض أن لدي MediaElement بخاصية Position (TimeSpan). يقوم Setter بتحديث الموضع الحالي ، ويسترد getter الموضع الحالي من مشغل الوسائط الأصلي ، مثل AVPlayer و MediaPlayer. هل يوجد تصميم لتعيين أداة تصوير باستخدام عارضين رفيعي المستوى؟

ما زلنا نعمل على هذا قليلاً. صححني إذا كنت مخطئًا https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

ليس تماما. لذا فإن ActionMapper هو نفس الشيء مثل PropertyMapper مع الاستثناء ، لا يتم استدعاؤها أثناء مرحلة SetElement. لذلك ، لأشياء مثل WebView و GoBack. لا ترغب في استدعاء ذلك أثناء التهيئة ولكنه لا يزال شيئًا تحتاج إلى التواصل مع العارض.

نحن بالفعل نؤيد رسم الخرائط ثنائية الاتجاه. أي الدخول. عندما فرص قيمة النص على الإدخال. يحتوي IEntry على string Text {get;set;} وقمنا ببساطة بتعيين القيمة. لذلك لديك خياران لعناصر الوسائط. واحد هو ببساطة تراجع الموقف / الوقت عندما يتغير. إذا كنت تريد أن تجعله شيئًا تستفسر عنه بدلاً من ذلك. تستطيع فعل ذلك. طرق عرض xplat لها حق الوصول إلى العارض. view.Renderer.NativeView as NativeMediaView يمكنك الآن سحب أي ممتلكات تريدها!

إليك بعض مقاطع الفيديو من التدفقات الخاصة بنا أثناء الإنشاء

Clancey هنا سيكون أكثر تعمقًا
https://www.youtube.com/watch؟v=_MGh3xipWm4

أتطرق إليهم قليلاً هنا مع ديفيد
https://www.youtube.com/watch؟v=lAmwjfZY1IM

كيف تعمل خاصية "ثنائية الاتجاه" مع تصميم العارض الجديد؟ على سبيل المثال ، لنفترض أن لدي MediaElement بخاصية Position (TimeSpan). يقوم Setter بتحديث الموضع الحالي ، ويسترد getter الموضع الحالي من مشغل الوسائط الأصلي ، مثل AVPlayer و MediaPlayer. هل يوجد تصميم لتعيين أداة تصوير باستخدام عارضين رفيعي المستوى؟

ما زلنا نعمل على هذا قليلاً. صححني إذا كنت مخطئًا https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

ليس تماما. لذا فإن ActionMapper هو نفس الشيء مثل PropertyMapper مع الاستثناء ، لا يتم استدعاؤها أثناء مرحلة SetElement. لذلك ، لأشياء مثل WebView و GoBack. لا ترغب في استدعاء ذلك أثناء التهيئة ولكنه لا يزال شيئًا تحتاج إلى التواصل مع العارض.

نحن بالفعل نؤيد رسم الخرائط ثنائية الاتجاه. أي الدخول. عندما فرص قيمة النص على الإدخال. يحتوي IEntry على string Text {get;set;} وقمنا ببساطة بتعيين القيمة. لذلك لديك خياران لعناصر الوسائط. واحد هو ببساطة تراجع الموقف / الوقت عندما يتغير. إذا كنت تريد أن تجعله شيئًا تستفسر عنه بدلاً من ذلك. تستطيع فعل ذلك. طرق عرض xplat لها حق الوصول إلى العارض. view.Renderer.NativeView as NativeMediaView يمكنك الآن سحب أي ممتلكات تريدها!

شيء آخر يجب مراعاته هنا هو السجلات التي تأتي في C # 9. التخصص هو أنها غير قابلة للتغيير ولها ملحق خاصية init . لذلك لجعلها قابلة للاستخدام في ربط ثنائي الاتجاه ، يجب أن يكون مصمم الخرائط قادرًا على إرجاع مثيل جديد باستخدام عامل التشغيل with .

آمل حقًا أن تكون المشاهدات قابلة للربط مع السجلات ، لأن هذا يجعل الكثير من الأشياء أسهل عندما يتعلق الأمر بـ MVVM الخالص أو حتى MVU الخالص.

سؤال: الرسم التخطيطي الذي نشرته يحتوي على عناصر تحكم Windows يتم تقديمها بواسطة Windows.UI.* ، ولكن كما أفهمها ، هذا الآن في طور الإهمال ولن ترى أي تحديثات: جميع التحسينات على عروض التصميم السهلة هي تجري في Microsoft.UI.* كجزء من مشروع WinUI. هل يمكنك التعليق على هذا؟

أعتقد أن التعيين إلى عناصر التحكم الأصلية هو خطأ كبير ، وهذا هو الجزء الرهيب من Xamarin. النماذج ، لا يمكنك إنشاء تخطيطات فريدة وجميلة بسهولة ، كان عليك اتباع مفهوم ونهج عناصر تحكم WPF و Flutter بدون ظهور مع عرض محرك مكتوب بلغة C ++ باستخدام OpenGL / DirectX / Metal ، حيث يسهل ذلك قابلية النقل والأداء والمرونة بالإضافة إلى عدم الاعتماد على هياكل النظام الأساسي التي تتغير باستمرار.

القضية هنا للحديث عن مصممي الخرائط / الهندسة المعمارية الجديدة. ليس ما يخططون له. فقط لإعادة التكرار. لا يعني Slim Render Architecture للأصليين أننا لن نفعل أبدًا ، ولا يمكننا أبدًا اتباع نهج تحكم مرسومة. لكن هذا يسمح لنا بخلط عناصر التحكم الأصلية مقابل غير الأصلية ومطابقتها حيث يكون الأمر أكثر صعوبة إذا تم رسمها تمامًا. أخطط لمواصلة العمل على عناصر التحكم القائمة على Skia والتي تتبع نفس بنية Slim Renderer ، بما في ذلك طبقة الرسم. https://github.com/Clancey/Comet/tree/dev/src/Comet.Skia/Handlers.

2 ¢ الخاص بي على هذا الشيء (الذي أعترف أنني لا أفهمه تمامًا ، TBH):

كانت لدي فكرة عن كيفية تنفيذ كل من عناصر التحكم التي يتم تقديمها في النظام الأساسي (مثل التفاف UIButton) _ و_ عناصر التحكم بدون مظهر (a la WPF) باستخدام نفس فئة التحكم. الأمر بسيط للغاية ، بصراحة: اطلب من فئة Maui Button استخدام قالب تحكم ، وقم بإزالة جميع رموز العارض الخاصة بالنظام الأساسي منه. بعد ذلك ، قم بتوفير قالب داخل الصندوق لـ Button يحتوي على ButtonRenderer. إن ButtonRenderer هو ما يتحدث إلى Cocoa / UIKit / UWP / إلخ ، مع رمز خاص بالمنصة لكل مجموعة أدوات واجهة المستخدم ، وفئة Button التي يستخدمها مطور التطبيق تقوم ببساطة بإعادة توجيه خصائصها إليها. إذا أراد المستخدم استخدام زر مرسوم بشكل مخصص ، فيمكنه ببساطة تجاوز القالب واستخدام فئات الرسم (أيًا كان ما يبدو عليه في النهاية) بدلاً من ButtonRenderer ، تمامًا كما نفعل في WPF. أنا بصراحة لا أعرف ما إذا كان هذا ممكنًا بالفعل (أو حتى تم استخدامه بالفعل) في ماوي اليوم ، لأنني لم أستغل الوقت الكافي لفهم Xamarin.Forms بعمق كما أفهم WPF.

قل لي ما هو رأيك!

أحاول أن أفهم ما تعنيه عارضات Slim لنماذج التطبيقات المختلفة (MVVM ، MVU ، ...).

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

هذا مهم لأن مكتبات الطرف الثالث مثل Fabulous لن يكون لديها القوة العاملة من Microsoft لتنفيذ (مع كل الأخطاء التي تأتي معها) جميع العارضين المناسبين لكل عنصر تحكم على كل نظام أساسي.

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

بهذه الطريقة ، يمكن لـ Fabulous استخدام واجهة IButton كعرض للقارئ على قاموسه الداخلي حتى يتمكن العارضون من العمل.

// This is the type used by our users, sort of a Builder that return a new instance each time
// and append the set value to an internal list 
public struct Button
{
     public Button Text(string value) => (...);

     internal ReadOnlyDictionary<string, obj> Build() { ... }
}

// This will be an implementation of IButton, hidden from our users
internal class FabulousButton : IButton
{
    private ReadOnlyDictionary<string, obj> _properties;
    FabulousButton(ReadOnlyDictionary<string, obj> properties)
    {
        _properties = properties;
    }

    void Update(ReadOnlyDictionary<string, obj> properties)
    {
        var previousProperties = _properties;
        _properties = properties;

        // Diffing of the 2 dictionaries to determine what changed
        // and which mapped functions inside the renderer should be called
        (...)
    }

    public string Text => _properties["Text"];
}

TimLariviere كل ما قلته هو كيف يعمل :-)

الرسم هناك مربك بقدر العارضين.

الجزء الوحيد من هذا الذي ستحتاج إلى القلق بشأنه هو الزر الرائع ثم كل شيء آخر من هناك سنهتم به

بالنسبة للجزء الأكبر ، تكون الواجهات للقراءة فقط

هذه هي الواجهة التي يستخدمها الزر
https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Views/IText.cs

كل ما يتعلق بك حقًا (بقدر ما يتعلق بالعارضين) هو إرسال إشارة إلى العارض بأنه يجب عليه إعادة استهلاك زر IB

على سبيل المثال ، في إصدار BindableObject لكل هذا ، نحن فقط نستدعي طريقة تحديث العارض هنا

https://github.com/dotnet/maui/blob/slim-renderer-samples/System.Maui.Core/VisualElement.cs#L1132

نقطة ما (قريبًا؟) سيكون لدى Clancey نسخة عامة من Comet يمكنك إلقاء نظرة عليها لترى كيف يفعل ذلك.

أود أن تحقق
https://github.com/dotnet/maui/blob/slim-renderer-samples

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

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

PureWeenClancey أنا متأكد من أن فريق Maui سينتهي من كل هذا ، ولكن رجاءًا هل يمكن العرض Slim الجدد أن

تضمين التغريدة
هذا URL
https://github.com/dotnet/maui/blob/slim-renderer-samples

يعطي 404 ، هل هو خاص؟

@ راند عشوائي

https://github.com/dotnet/maui/tree/slim-renderer-samples

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

أنا متأكد من أن فريق Maui سينتهي في كل هذا ، ولكن رجاءًا ، هل يمكن أن يفضل عارضو Slim الجديدون التركيب على الميراث. الوراثة مفيدة ، ولكن للأسف في XF ، جعلت بعض التسلسلات الهرمية للعارض معقدة بشكل لا يصدق ويصعب الحفاظ عليها.

هذه هي الطريقة التي تم بناؤها. هناك فئة أساسية رفيعة جدًا ترث مباشرة من الجيد ol ' System.Object

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.Android.cs

وليس له روابط محلية.

من هناك يتم تعريف كل شيء من خلال ما هو في الأساس قاموس

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.cs#L31

الذي يعمل في الأساس مثل الديكور.

يمكنك تزيين رسامي الخرائط بمصممي خرائط إضافيين ويمكنك حقن وظائفك الخاصة وما إلى ذلك.

نحن نهدف إلى تغطية 95 بالمائة من سيناريوهات المستخدمين فقط عن طريق إضافة Func الخاص بك إلى مصمم الخرائط أو مجرد الوصول إلى العناصر الأصلية مباشرة حيث ستكون جميعها متعددة الاستهدافات

PureWeen ما هي القناة الأنسب لمناقشة تنفيذ تلك العارضين النحيفين في عينتك؟

لدي بعض الأسئلة مثل:

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

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

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

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

نعم! نأمل في تقليص جميع فئات التطبيقات (الأصلية و xplat) إلى فئة تطبيق واحدة. لماذا تسأل عن هذا؟ أنا فقط أشعر بالفضول بشأن حالة الاستخدام الخاصة بك هنا حتى نتمكن من التأكد من معالجتها

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

في هذه المرحلة هذه هي الخطة. ستتمثل الفكرة في استخراج كل شفرة التخطيط الخاصة بنا بحيث لا يعتمد أي منها على BindableObject / Property .. وبهذه الطريقة يمكن لـ Blazor / Comet / الآخرين استخدام StackLayout وستكون النتيجة هي نفسها.

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

لست متأكدًا تمامًا مما أريده بعد. ولكن في Fabulous ، ليس لدينا حاليًا قصة جيدة لتحديد الأنماط العالمية والقائمة الرئيسية (مثل نظام macOS). نظرًا لأننا نسمح لمستخدمينا بفئة فرعية فئة التطبيق بأنفسهم ، فإننا نخبرهم أساسًا بتحديد الموارد / القائمة كما يفعلون في نماذج Xamarin الكلاسيكية.

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

شئ مثل هذا

public interface IAppRoot
{
    IEnumerable<object> Resources { get; }
    IMenu MainMenu { get; }
    IPage MainPage { get; }
}

public class Application
{
    /// Bootstrapping and other logic of MAUI

   public IAppRoot Root { get; set; } // Replaces MainPage, which is typed for pages only
}

PureWeen سؤال آخر: من سيكون مسؤولاً عن إطلاق أحداث مثل TextChanged ، Toggled ، إلخ؟ الضوابط أو العارضين؟

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

على سبيل المثال ، اليوم ، يتم تشغيل TextChanged on Entry عندما يكتب المستخدم شيئًا ما أو عندما نقوم بكتابة MyEntry.Text = "New value"; .
أعتقد أن الرد على تغيير برمجي ليس مفيدًا حقًا ، وضمنيًا وهو أمر سيئ للتفكير في الكود.

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

سؤال فضولي. عندما يكون MAUI حياديًا للهندسة المعمارية ، فلماذا يتم تسمية عناصر التحكم بأسماء العمارة؟ على سبيل المثال في الرسم البياني أعلاه لدينا ماوي. Mvvm. ButtonRenderer.Android؟ تضمين التغريدة

يحتوي XF على شيء يسمى التنسيقات المضغوطة (وهو عربات التي تجرها الدواب)
هل لدينا مثل هذا الشيء (بدون أخطاء بالتأكيد!) في MAUI؟

أرى كيف يتفاعل الأشخاص في هذا الموضوع حول استخدام نهج Flutter / Skia لعرض واجهة المستخدم وأنا أتفق معهم في الغالب.
أنا سعيد حقًا لأن MAUI من المحتمل أن يكون لديها دعم لعناصر تحكم وعروض مخصصة / غير أصلية.
ومع ذلك ، يجب أن أقول إن القدرة على العمل مع واجهة المستخدم الأصلية تؤمن الإطار على الجانب السياسي للأشياء.
ونعم ، أشير إلى Apple. نظرًا لآخر الأخبار ، لن أتفاجأ إذا كان استخدام Flutter في وقت ما لسبب ما يعتبر بمثابة "استغلال ميزات غير موثقة / مقيدة" أو "عدم اتباع إرشادات Apple UI" وما إلى ذلك.

أرى كيف يتفاعل الأشخاص في هذا الموضوع حول استخدام نهج Flutter / Skia لعرض واجهة المستخدم وأنا أتفق معهم في الغالب.
أنا سعيد حقًا أنه في MAUI يحتمل أن يكون لديه دعم لعناصر تحكم وعروض مخصصة / غير أصلية.
ومع ذلك ، يجب أن أقول إن القدرة على العمل مع واجهة المستخدم الأصلية تؤمن الإطار على الجانب السياسي للأشياء.
ونعم ، أشير إلى Apple. نظرًا لآخر الأخبار ، لن أتفاجأ إذا كان استخدام Flutter في وقت ما لسبب ما يعتبر بمثابة "استغلال ميزات غير موثقة / مقيدة" أو "عدم اتباع إرشادات Apple UI" وما إلى ذلك.

إذا كان MAUI يدعم الويب (مثل Flitter) ، فيمكننا دائمًا تقديمه إلى WebView.
من غير المحتمل أن تجرؤ Apple على حظر التطبيقات المستندة إلى WebView ، لأن بعض الشركات الكبيرة يتم تمثيلها في AppStore من خلال WebView فقط

أرى كيف يتفاعل الأشخاص في هذا الموضوع حول استخدام نهج Flutter / Skia لعرض واجهة المستخدم وأنا أتفق معهم في الغالب.
أنا سعيد حقًا أنه في MAUI يحتمل أن يكون لديه دعم لعناصر تحكم وعروض مخصصة / غير أصلية.
ومع ذلك ، يجب أن أقول إن القدرة على العمل مع واجهة المستخدم الأصلية تؤمن الإطار على الجانب السياسي للأشياء.
ونعم ، أشير إلى Apple. نظرًا لآخر الأخبار ، لن أتفاجأ إذا كان استخدام Flutter في وقت ما لسبب ما يعتبر بمثابة "استغلال ميزات غير موثقة / مقيدة" أو "عدم اتباع إرشادات Apple UI" وما إلى ذلك.

إذا كان MAUI يدعم الويب (مثل Flitter) ، فيمكننا دائمًا تقديمه إلى WebView.
من غير المحتمل أن تجرؤ Apple على حظر التطبيقات المستندة إلى WebView ، لأن بعض الشركات الكبيرة يتم تمثيلها في AppStore من خلال WebView فقط

هذا بالفعل ضد المبادئ التوجيهية - https://developer.apple.com/app-store/review/guidelines/#minimum -functionality

بعد قراءة ما يبدو عليه هذا العالم الجديد بالكامل من MAUI ، من فضلك ، من أجل حب كل ما هو مقدس ، قم بعمل كتابة بمجرد استخدام محرك تقديم في كل مكان مثل SKIA أو محرك عرض متعدد الأنظمة الأخرى ، مع الاضطرار إلى تنفيذ مخصص تبدو واجهة المستخدم على كل منصة كما في نماذج Xamarin قديمة ومثلها حل تم إنشاؤه في الدائرة السابعة للجحيم.

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

@ jackie0100
انا اوافق تماما

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

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

ثم يمكنك القيام بأشياء مثل ، في iOS land ، فقط قم بإلقاء نظرة على أن تكون UIView ، وأضف إليها طفلًا أصليًا (أيًا كان النوع الذي تريده) لأن IView هو UIView. وبالمثل ، إذا كنت تريد إجراء "التضمين الأصلي" ، فهذا سهل لأن IView هو UIView ، يمكنك فقط إضافة أحد أشكال IView إلى العرض الأصلي الخاص بك لأنهما نفس الشيء. سيؤدي هذا إلى تمكين إمكانية التشغيل المتداخل الأصلي <-> maui بشكل كبير ، وبأعلى مستوى من الأداء وأقل استهلاك للذاكرة.

أشعر نوعًا ما بالرغبة في عمل نماذج أولية لهذا بنفسي. ربما مشروع عطلة نهاية الأسبوع / المساء ...

إذا كان MAUI يدعم الويب (مثل Flitter) ، فيمكننا دائمًا تقديمه إلى WebView.

لست بحاجة إلى WebView على iOS: يمكن العرض مباشرة في OpenGL أو Metal .

أو استخدم Skia مع OpenGL أو Metal تحتها.

القدرة على العمل مع واجهة المستخدم الأصلية يؤمن الإطار على الجانب السياسي للأشياء. [تفاح]

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

بغض النظر ، أن تكون قادرًا على العمل مع عناصر التحكم الأصلية يعد خيارًا جيدًا.

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

لماذا الكثير من الناس مهووسون بـ Skia؟ ستكون مواصفات العرض الجيدة محايدة لمحرك العرض ...

على الرغم من أنني أوافق تمامًا على أن أكون "محايدًا" ، إلا أن هناك الكثير من التفاصيل التي يجب تنفيذها لتقديم أي واجهة مستخدم تفاعلية - إذا انتقلت مباشرةً إلى OpenGL / Metal / Vulkan / أي محرك عرض منخفض المستوى. الناس مهووسون بـ Skia لأنها طبقة متوسطة فعالة بين اهتمامات واجهة مستخدم التطبيق ومحرك العرض الفعلي: تتعامل Skia مع الكثير مما يجب تصميمه وتنفيذه ، إذا كان كل ما لديك هو المعدن. لا يوجد سبب لإعادة اختراع هذا العمل. على الرغم من أنه لا ينبغي أن يكون الهدف _ فقط_ ، إلا أنه هدف قيم للغاية وناضج ، مما يجعل الانتقال من OpenGL إلى Vulkan أسهل كثيرًا ، على سبيل المثال.

أظن أيضًا أن استهداف Skia سيكون أقل إرهاقًا بكثير من صيانة Xamarin Forms لتسلسلَي عناصر واجهة مستخدم متوازيين - عناصر واجهة المستخدم عبر الأنظمة الأساسية والأدوات الأصلية.

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

مرحبًا بكم جميعًا ، لا تنسوا ذلك:
https://github.com/dotnet/maui/discussions/103

بعد مشاهدة مقاطع فيديو maui الأخيرة ، ما لم أكن مخطئًا ، يبدو أنه كان هناك انجراف للحصول على المزيد من عناصر التحكم المصممة مع تراكب التحكم الأصلي مع الرسم المنجز على جانب النظام الأساسي. سواء أكان ذلك skia أو نوعًا من البينية المجمعة إلى رسم قماش أصلي ، آمل أن يتم اتباع هذا النهج! لطالما كان نموذج عارض النظام الأساسي XF يضر بشكل كبير بأنظمة Microsoft UI الأساسية ، كونها الأقل استخدامًا.

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

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

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