<p>Xamarin.Forms رسم المواصفات</p>

تم إنشاؤها على ١٣ أبريل ٢٠١٨ · 69تعليقات · مصدر: xamarin/Xamarin.Forms

Xamarin.Forms رسم المواصفات

تصميم

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

عينة API الرسم البسيط

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button>
</Button>

يجب أن يكون عرض القوالب ، على الأقل في الوقت الحالي ، DrawingTemplate . الطفل الأول من DrawingTemplate هو دائمًا Drawing . داخل Drawing يمكنك استخدام التنسيقات ورسم الأساسيات.

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

قد يستخدم رسم الكائنات الأولية نوع الفرشاة بدلاً من نوع اللون لتوفير الألوان / الخلفيات / إلخ.

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

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

أنواع

رسم

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

public class DrawingTemplate : ControlTemplate {}

رسم

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

public class Drawing : Layout<View> {}

واجهة برمجة تطبيقات جديدة للرسم في العرض

public class View : VisualElement // new API only
{
  public ControlTemplate Template { get; set; }

  protected BindableObject GetTemplateChild(string childName);

  protected virtual void OnApplyTemplate ();
}

فرشاة

public class Brush : BindableObject
{
  public static readonly BindableProperty OpacityProperty;
  public double Opacity { get; set; }
}

SolidColorBrush

public class SolidColorBrush : Brush
{
  public static readonly BindableProperty ColorProperty;
  public Color Color { get; set; }
}

فرشاة التدرج

public class LinearGradientBrush : Brush
{
  public static readonly BindableProperty GradientStopsProperty;
  [Content]
  public GradientStopCollection GradientStops { get; set; }
}

مجموعة GradientStopCollection

public sealed class GradientStopCollection : IEnumerable<GradientStop>, IList<GradientStop>

التدرج توقف

public sealed class GradientStop : BindableObject
{
  public static readonly BindableProperty ColorProperty;
  public Color Color { get; set; }

  public static readonly BindableProperty OffsetProperty;
  public double Offset { get; set; }

  public static readonly BindableProperty StartPointProperty;
  public Point StartPoint { get; set; }

  public static readonly BindableProperty EndPointProperty;
  public Point EndPoint { get; set; }
}

رسم الأوليات

ستكون هناك حاجة لعدد كبير من الرسوم الأولية ذات الخصائص المرتبطة. لا تحاول هذه الوثيقة تعريفها جميعًا ، فقط لاحظ بعضًا منها الواضحة التي يجب أن تكون موجودة. لا يُقصد بواجهة برمجة تطبيقات الرسم البدائية أن تكون بديلاً بالجملة لـ SkiaSharp. ومع ذلك ، من المفترض أن يكون محايدًا لاستخدام Skia أو الخلفيات الخلفية للرسم الأصلي لشكل paltform.

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

شكل

namespace Xamarin.Forms.Shapes 
{
  public class Shape : View
  {
    public static readonly BindableProperty FillProperty;
    public Brush Fill { get; set; }

    public static readonly BindableProperty StrokeProperty;
    public Brush Stroke { get; set; }

    public static readonly BindableProperty StrokeThicknessProperty;
    public double StrokeThickness { get; set; }
  }
}

خط

namespace Xamarin.Forms.Shapes 
{
  public sealed class Line : Shape
  {
    public Point Start { get; set; }
    public Point End { get; set; }
  }
}

الشكل البيضاوي

namespace Xamarin.Forms.Shapes 
{
  public sealed class Ellipse : Shape
  {
  }
}

نص

public sealed class Text : Shape 
{
  // All the same properties as Label more or less
}

مستطيل

namespace Xamarin.Forms.Shapes 
{
  public sealed class Rectangle : Shape
  {
    public CornerRadius CornerRadius { get; set; }
  }
}

بيزير لاين

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

namespace Xamarin.Forms.Shapes 
{
  public sealed class BezierLine : Shape
  {
    public IList<BezierPoint> Points { get; }
    public bool ShouldClose { get; set; }
  }
}

بيزيربوينت

namespace Xamarin.Forms.Shapes 
{
  public sealed class BezierPoint : Point
  {
    public Size LeftControlOffset { get; set; }
    public Size RightControlOffset { get; set; }
  }
}

لكى يفعل

[x] إضافة API للرسم
[x] املأ فرشاة API

مشاكل

الأشكال

لا توجد تيارات طريقة رائعة لرسم قوس فقط. إن الآلية في UWP للقيام بذلك هي بعض الشيء ... آه فقط ليست ممتعة.

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

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

فرشاة

ربما ستكون هناك حاجة ImageBrush. يجب إجراء البحث للتأكد من أن كل منصة يمكنها دعم ImageBrush في كل مكان يتم استخدام الفرشاة فيه.

رسم

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

brushes shapes in-progress high impact enhancement ➕

مصدر

jassmith

👍28 ❤18 🎉9 👎1

التعليق الأكثر فائدة

يجب أن يحدث هذا قبل مادة الغلاف لأن الهيكل المادي يعتمد على ذلك. أعتقد أنك قصدت أن تقول أنك تفضل رؤية هذا قبل شل؟

لا تركز شل على البدء بشكل أسرع / أسهل. إنه يهدف إلى تحديث الصفحات بطرق لا يمكننا فعلها مع كونها عناصر التحكم الخاصة بهم. الغرض الأساسي منه هو استبدالها بالكامل وسنشجع الناس على التفكير في النقل. تركز شل على توفير تجربة أكثر سلاسة وأكثر ثراءً للمستخدمين النهائيين ، ويمكن تخصيص الرسوم المتحركة الخاصة بها ، ويمكنها تأخير / تحميل الأشياء كسول قبل / بعد الرسوم المتحركة حتى لا توفر الفواق. إنه يوفر 0 مساحة محتوى تجاوز للسحب GPU في Android ، قارن هذا بالصفحات الحالية حيث يكون السحب الزائد في جزء "red go fuck yourself" من الرسم البياني في كل مكان.

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

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

jassmith في ١٨ مايو ٢٠١٨

👍8 ❤1

ال 69 كومينتر

jassmith ،

هذه فكرة جيدة جدًا من وجهة نظر توحيد XAML ، وستوفر وظائف قوية ، ومع ذلك ، سأكون حريصًا على السير في هذا المسار. سيساهم بالتأكيد في الهدف العام المتمثل في نقل Xamarin.Forms نحو XAML Standard (https://github.com/Microsoft/xaml-standard). ولكن ، جنبًا إلى جنب مع VisualStates ، هناك علامات استفهام كبيرة حول مدى فائدة ذلك في الواقع.

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

هناك أيضًا مسألة التوازن بين الرسم الأصلي واختلافات الرسم عبر الأنظمة الأساسية. النص هو نقطة مهمة. هل يجب تقديم النص بنفس الطريقة على جميع الأنظمة الأساسية؟ أي هل يجب أن يتم تمرير عرض الخط إلى XF للقيام بذلك لتحقيق التوحيد على جميع الأنظمة الأساسية؟ ربما. لكن ، لا أشعر أن هذا يجب أن يكون المشروع العام لـ XF. يكتشف الناس دون وعي التفاصيل المرئية الصغيرة. قد تكون التفاصيل في صورة متحركة أو ما إلى ذلك. حتى الخروج البسيط عن القاعدة في نظام أساسي معين يمكن أن يجعل المستخدم يشعر بعدم الارتياح. لذلك ، ليس بالضرورة أن يكون كل الرسم موحدًا فكرة جيدة. من المؤكد أن Avalonia تسير في هذا المسار ، لكن هذه حالة منفصلة تمامًا ، وهذه نقطة اختلاف بين نماذج Avalonia و Xamarin.

أيضًا ، هناك تعليق آخر هو أنه يجب توخي الحذر للتأكد من تسمية أي أنواع بدائية بنفس الاسم ، ومحاذاة أقرب ما يمكن إلى الأنظمة الأساسية الأخرى مثل UWP و WPF بحيث تكون متوافقة مع معيار XAML.

davidortinau ، هل لديك أفكار حول هذا؟

MelbourneDeveloper في ١٣ أبريل ٢٠١٨

👍2

تموج واحدة من الميزات الرائعة في تصميم المواد. هل تتوقع أن تدعم هذا؟
بشكل عام أعتقد أن هذا رائع!

ChaseFlorell في ١٣ أبريل ٢٠١٨

أنا حقا أحب هذا الاتجاه. بالنسبة لنظام التشغيل iOS ، كنت أستخدم خلايا العرض الأصلية باستخدام العناصر الأصلية (i ،> الخيارات) ، ولكن كلما قمت بتطبيق المزيد من السمات المخصصة ، أجد نفسي أحاكي قليلاً الخلايا الأصلية وأذهب أكثر للحصول على مظهر لطيف / عامل يتسم بطلاقة متوافق مع التطبيق ولكن ليس في حد ذاته أصليًا بصرف النظر عن التفاصيل. أعتقد أنه إذا تم استخدام مكتبة العرض الأساسية المناسبة ، فلن تكون GPU مشكلة ، اقرأ Skia. نفس الشيء الذي يعمل على تشغيل Flutter.

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

رأيي هو أنك تريد في النهاية عناصر تحكم قوية ، غنية ، ذات مظهر أصلي (ليست في حد ذاتها أصلية!) يسهل برمجتها بسلوك متسق عبر الأنظمة الأساسية ، مع استثناء غريب لاستيعاب غرابة أصلية لمنصة. على سبيل المثال تأثير مضاعف لنظام Android.

rogihee في ١٣ أبريل ٢٠١٨

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

rogihee SVG ليس تنسيق شحن آسفًا: / لا أريد أن أكون مسؤولاً عن محاولة عرض SVG عبر الأنظمة الأساسية باستمرار. متى سيضيفون تلميحًا إلى SVG على أي حال ...

jassmith في ١٤ أبريل ٢٠١٨

👍1

jassmith ، هل هذا لنا تسريع رسومات الأجهزة؟

MelbourneDeveloper في ١٦ أبريل ٢٠١٨

قادم من Qt's QML ، أود أن أرى هذا. إلى جانب عدد قليل من عناصر التحكم المضمنة الواضحة ، يمكن أن تقرب الكثير من الأرض.

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

RichiCoder1 في ١٦ أبريل ٢٠١٨

@ RichiCoder1 a11y هو بالتأكيد شيء يحتاج إلى العمل بشكل صحيح. من الناحية المثالية ، يقوم عنصر النص تلقائيًا بتعيين معظم الخصائص المطلوبة لعناصر تحكم بسيطة.

jassmith في ١٧ أبريل ٢٠١٨

هل هذه ميزة لـ xf 4.0

juepiezhongren في ١٨ أبريل ٢٠١٨

سلسلة 3.0

jassmith في ١٩ أبريل ٢٠١٨

🎉1

jassmith لا يوجد شيء حول الرسم والصدفة في خارطة الطريق

juepiezhongren في ٢٢ أبريل ٢٠١٨

AFAIK لا تتضمن خارطة الطريق العامة أي شيء لم يتم جدولته بالكامل

jassmith في ٢٢ أبريل ٢٠١٨

سوف كل هذه المعاينة في 2018？jassmith

juepiezhongren في ٢٤ أبريل ٢٠١٨

juepiezhongren لم نلتزم بالقيام بهذه المقترحات. يتم تقديمها هنا لمناقشة مفتوحة حول مزاياها وأوجه قصورها وما إلى ذلك.

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

أي أمثلة وقصص من العالم الحقيقي يمكنك مشاركتها ستكون مفيدة للغاية في مساعدتنا على التحقق من أن هذا يمكن أن يوفر قيمة حقيقية.

كما هو الحال دائمًا ، يمكن لأي شخص ألا يتردد في مراسلتي عبر البريد الإلكتروني إذا فضل ذلك. ديفيد. [email protected]

davidortinau في ٢٤ أبريل ٢٠١٨

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

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

هل سيعطينا هذا الاقتراح بدائل واجهة المستخدم التركيبية ذات النظام الأساسي المحايدة؟

timahrentlov في ٢٤ أبريل ٢٠١٨

🎉2 ❤1

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

opcodewriter في ٢٤ أبريل ٢٠١٨

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

juepiezhongren في ٢٤ أبريل ٢٠١٨

juepiezhongren إذا كنت تبحث عن هذا النوع من تخصيص واجهة المستخدم ، فلا أعتقد أن هناك أي إطار عمل عبر الأنظمة الأساسية يمكنه القيام بذلك. وحول WPF: إنها فكرة سيئة أن تخلط WPF مع الهاتف المحمول.

opcodewriter في ٢٤ أبريل ٢٠١٨

يستخدم فريقي أيضًا رد الفعل الأصلي ، حيث يساهم الكثير من jsers كثيرًا ، حيث توصلنا بعد 3 أشهر إلى أنه ليس منتجًا على الإطلاق. بالنسبة إلى xf ، فهو يحتوي على عيوب ، مع وجود أخطاء ، ولكنه في الأساس حل قوي ، حيث يجعل eps x.native جميع واجهات برمجة التطبيقات الأصلية صالحة. ما ينقصه هو مظهر ubi فقط ، ورفرفة منسقة مؤخرًا. إلى جانب ذلك ، مع الصدفة ، يجب أن تكون الرفرفة عديمة الفائدة ، بدون شيء مثل flutter.ios ، يجب أن تكون الرفرفة مثل rn مع معاناة لا حدود لها مع api الأصلي.

juepiezhongren في ٢٤ أبريل ٢٠١٨

تضمين التغريدة
نحن نستخدم skiasharp بشكل متكرر ، مما يجعل تحكمًا خاصًا ، وأدائها مرضي

juepiezhongren في ٢٤ أبريل ٢٠١٨

jassmith لقد فكرت في نقل المواد من الصدف إلى الصنف باستخدام webgl ، بالنسبة إلى skia ، ربما يكون حجمه أكبر من أن يتم تنزيله

juepiezhongren في ٢٥ أبريل ٢٠١٨

صحيح أننا لا نريد أن نتخذ إجراءات صارمة على أي libs طرف ثالث لواجهة الرسم الافتراضية. \يمكن أن تفعل ذلك

jassmith في ٢٥ أبريل ٢٠١٨

👍2

باستخدام xamarin.mono و shell في wasm ، فإن أي منتج ألفا سيؤدي إلى نهضة dotnet في الصين ، حيث تنتشر الكراهية ضد dotnet كثيرًا

juepiezhongren في ٢٦ أبريل ٢٠١٨

👍2

jassmith أي أخبار جيدة حول هذه المسألة؟

juepiezhongren في ٤ مايو ٢٠١٨

ما الأخبار التي تبحث عنهاjuepiezhongren؟ في هذه المرحلة ، يتم نشر المواصفات لاستدعاء المناقشة.

ChaseFlorell في ٤ مايو ٢٠١٨

نريد أن نرى متى يتم تضمين الرسم والصدفة في خريطة الطريق @ ChaseFlorell
العرض الشامل صالح بالفعل للأفالونيا والرفرفة

juepiezhongren في ٥ مايو ٢٠١٨

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

jassmith في ٦ مايو ٢٠١٨

🎉1

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

jassmith في ٦ مايو ٢٠١٨

كل هذا جميل جدًا ، لكن هل سيستخدم تسريع الرسومات؟

MelbourneDeveloper في ٧ مايو ٢٠١٨

jassmith على ios ، system.draw لاستخدامه ؛ على android ، يمكن استخدام skiasharp || skiasharp لكل شيء؟

juepiezhongren في ٧ مايو ٢٠١٨

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

jassmith في ٧ مايو ٢٠١٨

jassmith ، إنه أمر سلكي حقًا أن system.draw متاح لنظام iOS بينما ليس لنظام Android

juepiezhongren في ٧ مايو ٢٠١٨

juepiezhongren إضافة دعم لـ System.Drawing ليس شيئًا ضمن اختصاصي هنا. لا شيء سيستخدم System.Drawing ولكن مع هذه المواصفات.

jassmith في ٧ مايو ٢٠١٨

في الأساس ، سوف يتسبب الرسم في عدد أقل بكثير من عمليات التصيير

juepiezhongren في ٨ مايو ٢٠١٨

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

jassmith في ٨ مايو ٢٠١٨

أنا في معسكر "افعل ذلك بالقرب من wpf / uwp قدر الإمكان" ، والذي أعرف أنه ليس دائمًا المكان الأكثر شعبية هنا.

ولكن ، هذا يبدو وكأنه حل وسط كبير بين المظهر الخالي تمامًا مع الإطار الذي يقوم بجميع عمليات العرض ، ونموذج XF الحالي.

أفترض أن الأوليات سيكون لها نظراء على كل منصة وبالتالي لن يكون تسريع الأجهزة مشكلة. لا يزال Windows / iOS / Android / إلخ يعرض المستطيلات والدوائر والتدرجات وما شابه ، وسيستخدم تسريع الأجهزة بنفس القدر الذي يستخدمه بالفعل. هذا من شأنه أن يمنحنا فقط لمصممي التحكم القدرة على تصميم عناصر التحكم الخاصة بنا باستخدام العناصر الأولية بدلاً من أن نعلق بفكرة Apple عن الزر مقابل زر Microsoft.

هل ألخص ذلك بشكل صحيح؟

legistek في ١٧ مايو ٢٠١٨

🎉2 👍1

pmoorelegistek هذه في الأساس فكرة نعم. ونحن نتعامل مع المواد أولاً في المقام الأول لأنه لا يوجد خلفها تمويه كعنصر تصميم رئيسي. هذا يعني أنه يمكننا فعلاً جعله يعمل في كل مكان (بالنظر إليك في Android).

jassmith في ١٧ مايو ٢٠١٨

🎉2

عندما أنهي برنامج شل v1 ، سأنتقل على الفور إلى هذا

jassmith في ١٧ مايو ٢٠١٨

jassmith هذا ذهبي. استخدم عناصر التحكم الأصلية حيث تناسب تصميم UX وأضف بسهولة عناصر تحكم مرسومة تشبه skia فقط لعناصر التصميم (ويفضل القليل منها) التي تحتاج إلى ذلك.

لا مزيد من المحادثات "لا يمكنني فعل ذلك في نماذج Xamarin" مع المصممين والعملاء. هذا يزيل قيود التصميم مع الحفاظ على الشعور الأصلي الحقيقي (على عكس الرفرفة).

أود أن أرى هذا قبل الصدفة المادية. هذا يحل القيود الحقيقية لـ XF.
شل هي الميزة التاسعة لبدء التشغيل بسهولة / أسرع. لقد كان الحصول على _started_ هو التركيز لفترة طويلة جدًا ، ولكن ميزات مثل هذه للحصول على _ المزيد _ ستحافظ على _ XF devs على متن الطائرة.

VincentH-Net في ١٨ مايو ٢٠١٨

jassmith في ١٨ مايو ٢٠١٨

👍8 ❤1

weitzhandler آمل أن أنتقل إلى هذا في الأسابيع 4-6 المقبلة. سيكون هذا أسرع بكثير للعمل على تلك القشرة. لم يتم تحديد أي من تلك الأوقات على الحجر.

jassmith في ٢١ مايو ٢٠١٨

timahrentlov في ٢٣ مايو ٢٠١٨

هههههههههههههههههههههه _
هذا عظيم.
uni-rendering رائع

juepiezhongren في ٢٦ مايو ٢٠١٨

ستكون النماذج مستكشفًا جذريًا ، بينما سيكون uno مستكشفًا محافظًا
نحن نحب كليهما

juepiezhongren في ٢٦ مايو ٢٠١٨

+1 ميزة رائعة ستحل الكثير من مشاكل واجهة المستخدم المخصصة التي نريد رؤيتها في أسرع وقت ممكن

RadwanIbrahim في ٢٢ يونيو ٢٠١٨

👍2

يبدو jassmith أن السحب يجب أن يتم لـ 3.3.0？

juepiezhongren في ٩ يوليو ٢٠١٨

❤1

أي تحديث على هذا؟

بالنسبة لنا ، هذه هي الميزة الأكثر إلحاحًا التي نأمل أن تنفذها Xamarin.

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

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

Shell & Material Shell نعمة وأخبار رائعة ، يرجى دفع هذا إلى الأمام! هذا هو الشيء الوحيد الذي سيجعل المستخدمين ينتقلون إلى مكان آخر (Uno و Flutter وغيرهما).

weitzhandler في ٢٠ يوليو ٢٠١٨

👍1

الأخبار المحزنة التي قرعة لن تظهر لـ 3.3

juepiezhongren في ٢٤ يوليو ٢٠١٨

👍1

+1 لهذا ، قادمًا من خلفية uwp ، أريد حقًا استخدام XF ولكن به عيوبه ، حاليًا أحاول الرفرفة ولكن بالتأكيد سأصل إلى XF إذا تم تنفيذ ذلك في أسرع وقت ممكن.

touseefbsb في ٣ أغسطس ٢٠١٨

👍1

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

jrahma في ٧ أغسطس ٢٠١٨

أى اخبار؟ خطط؟ خريطة الطريق؟

weitzhandler في ٦ سبتمبر ٢٠١٨

👍2

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

legistek في ٦ سبتمبر ٢٠١٨

👍1

تضمين التغريدة
إذن ، Line و Rectangle على سبيل المثال ، هل ستكون مشاهدات حقيقية؟ (لأنني أرى في المثال أن هناك Grid مع Ellipse كعرض طفل). إرادة
هل سأتمكن من إرفاق إضافة TapGestureRecognizer إلى Rectangle للتعامل مع حدث النقر؟
نظرًا لأن هذه وجهات نظر حقيقية ، ألا يكون وجود وجهات نظر فعلية للرسم البدائي ضارًا بسرعة العرض؟

andreinitescu في ١٥ أكتوبر ٢٠١٨

andreinitescu أعتقد أن القصد من ذلك هو أن يكونوا آراء حقيقية من جانب نماذج Xamarin ، ولكن لا يتم إدراكها أبدًا كوجهات نظر أصلي:

_ الرسم البدائي هو مجرد عرض ليس له عارض_

لذا فإن العارض أعلى السلسلة ( Drawing ؟ DrawingTemplate ؟) مسؤول عن التكرار من خلال الأحفاد القابلة للرسم ورسمها.

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

GalaxiaGuy في ١٦ أكتوبر ٢٠١٨

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

andreinitescu في ١٦ أكتوبر ٢٠١٨

عمل جيد فقط عينة صحيحة

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button.Template> --> correct this line
</Button>

minaairsupport في ١١ فبراير ٢٠١٩

👍1

ربما سيكون في 4.0؟

KSemenenko في ٥ مارس ٢٠١٩

يعد Drawing جيدًا من حيث أنه ينفذ عناصر تحكم باستخدام أساسيات الرسومات المستقلة عن النظام الأساسي المستهدف. كان هناك NControl ولكن هذا واجه مشاكل (من قبل netstandard2.0 ، ما قبل SkiaSharp أيام) ، ولم يتم تحديثه.

المواصفات 1. تكرر الوظائف التي تم تنفيذها بالفعل في شكل أكثر اكتمالاً بكثير في SkiaSharp، 2. تضيف طبقات غير ضرورية من التعقيد عبر XAML / Binding الذي يدخل داخل مستودع Xamarin.Forms الذي لا يمكن إدارته بالفعل.

أفضل طريقة هي إنشاء مكتبة تحكم صغيرة تعتمد على SkiaSharp. NControl ++

jassmithrogihee SVG ليس تنسيق شحن في الحقيقة آسف: / لا أريد أن أكون مسؤولاً عن محاولة عرض SVG عبر الأنظمة الأساسية باستمرار.

SkiaSharp لديه دعم SVG.

charlesroddie في ١٠ مايو ٢٠١٩

👎2 👍1

أي خبر عن هذا؟

timahrentlov في ١٢ أغسطس ٢٠١٩

أي خبر عن هذا؟

wuxueqicai في ١٨ سبتمبر ٢٠١٩

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

legistek في ٢٥ نوفمبر ٢٠١٩

legistek يمكنك استخدام SkiaSharp للرسم عبر الأنظمة الأساسية بدون مظهر. ما هي مزايا Xamarin.Forms محددة في عقلك؟

charlesroddie في ٢٥ نوفمبر ٢٠١٩

هناك ما هو أكثر قليلاً من إطار عمل واجهة المستخدم من الرسم.

legistek في ٢٥ نوفمبر ٢٠١٩

لكن هذا الموضوع يناقش إطار رسم وليس إطار عمل لواجهة المستخدم ...

charlesroddie في ٢٥ نوفمبر ٢٠١٩

اعتقدت أنه كان يناقش إطار رسم _لنماذج Xamarin_.

legistek في ٢٥ نوفمبر ٢٠١٩

SkiaSharp هو إطار رسم لنماذج Xamarin. حقيقة أنها تعمل أيضًا على منصات .Net UI الأخرى هي بالتأكيد ميزة وليست عيبًا.

charlesroddie في ٢٥ نوفمبر ٢٠١٩

وكما قيل في OP ، يمكن أن يكون SkiaSharp محرك الرسم الأساسي على الأنظمة الأساسية الفردية ولكن فكرة هذا الاقتراح هي إضافة طبقة تجريد ودعم الرسم من خلال XAML بكل مزاياها ، وأبرزها ربط البيانات. ما تسميه التعقيد غير الضروري أسميه الأنيق.

legistek في ٢٥ نوفمبر ٢٠١٩

هل هذا لا يزال على قيد الحياة و / أو سيتم طرحه في MAUI؟

legistek في ٢٠ مايو ٢٠٢٠

👍1

legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap تسرد الأشكال والمسارات والفرش كما في خريطة طريق Xamarin.Forms 4.7.0.