Maui: تجربة مستخدم متعددة المنصات لـ .NET 5

اعجبتني هذه الفكرة. ومع ذلك ، من الناحية العملية ، من المرجح أن يتم التعامل معه من قبل فريق Xamarin.Forms.
ربما ، سيساهم الفريق الأساسي ببعض التركيبات منخفضة المستوى لجعل إطار عمل UX "أفضل" (مثل ما تفعله CoreFxLab).

تحرير: هل يمكن أن يصبح WebAssembly أيضًا نظامًا أساسيًا مدعومًا؟

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

أنا متأكد تمامًا في المستقبل المتوقع من أننا سنرى .net core تم نقله إلى أجهزة Android و iOS باستخدام تطبيق Native كبديل لـ corehost . مع ذلك ، ستكون قدرات واجهة المستخدم مطلوبة.

بالنسبة لمكتبات الرسم ثنائية الأبعاد xplat (بما في ذلك الرسم السريع) ، لدينا Skia على سبيل المثال.

في جميع السيناريوهات ، أعتقد أن XAML-Standard سيكون شيئًا جيدًا للانتقال إليه من أجل تحقيق طريقة قياسية "لوصف" واجهة المستخدم كلها جنبًا إلى جنب مع إرشادات تصميم Fluent.

ومع ذلك ، فأنا متشكك في وجود أي خطط من .Net Team لاستثمار الوقت في ذلك أكثر من مجرد إعادة بعض العناصر الأولية لـ xplat System.Drawing.X ...

@ 4creators ربما تهمك هذه المناقشة

@ vibeeshan025 WebAssembly ليس بديلاً عن JavaScript ، لذا فإن معظم تعليقك لا معنى له حقًا. ستظل بحاجة إلى JavaScript لتوصيل WebAssembly بـ DOM. لذا ، لا ، لا يمكنك فقط تجميع شيء ما في wasm وتوقع منه أن يحل محل ما فعلته من قبل بجافا سكريبت. هذه ليست طريقة عمله. لن تكون تقنية واجهة المستخدم.

مرحبًا يا رفاق ، أريد فقط وضع 5c هنا.
يعد System.Drawing.X ضروريًا لتطوير .NET Core. (جئت للتو إلى هنا من https://github.com/dotnet/corefx/issues/20325)

اعتبارًا من واجهة المستخدم - اسأل مطوري الويب (الواجهة الأمامية). يستخدمون الكثير من الحيل الحديثة مثل إعادة التحميل الساخن.
أنا شخصياً أحب كيف تسير الأمور حول React / ReactNative. سيكون من الرائع استخدام C # لكتابة React ثم استخدام محركات تصيير مختلفة لمنصات مختلفة.

FWIW ، Mono تعتمد WebAssembly ، لذلك إذا كان يعمل في Mono ، فإنه يعمل (أو سيعمل) في WebAssembly. هذه هي الفكرة / الفهم الحالي ، على الأقل.

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

رأيي في هذا هو أن بعض الجهود الخارجية ستكتسب الزخم وربما يتم شراؤها بواسطة MSFT و ala Xamarin ، ولكن أكثر تركيزًا على واجهة المستخدم (على عكس الإطار / التركيز على الأدوات ، وهو القوة الأساسية لـ Xamarin IMO). لذلك ، شيء مثل Avalonia أو Noesis ، اللذان يقدمان قيمتهما المقترحة عبر القنوات المفتوحة المصدر والقنوات المدفوعة ، على التوالي. بالمناسبة ، كلاهما مدمج / يدعم Mono.

تحرك Xaml Standard قليلاً مع إصدار معيار XAML (معاينة) لـ Xamarin. النماذج والتحديث الذي طال انتظاره بشأن تقدم المشروع . هناك مناقشة شيقة للغاية في العلاقات العامة dotnet / Design # 111 حول أهداف المشروع التي يبدو أنها تسير في الاتجاه الذي يستفيد منه هذا الاقتراح

Silverilght هو حل رائع ، الكود موجود بالفعل

1. فتح كود silverlight المصدر
2. يتم تشغيله على رأس وقت تشغيل dotnet الأساسي
3. استخدام ضوء القمر لتوزيع لينكس
4. إنشاء بديل dotnet core لـ "Electron" سوف يكون في العالم (استخدام أقل للذاكرة + تحسين كبير للأداء + جودة xaml)
5. امتثال أصلي (إذا رأى مشروع كوريرت يومًا ما الضوء)

وجدت أنها ذات صلة- http://platform.uno

gulshan مثير للاهتمام ، مشروع رائع ، هل يدعم معظم ميزة UWP ، كيف تمكنوا من تنفيذ مجموعة غنية من الميزات في وقت قصير جدًا مع 4 مساهمين فقط.

@ vibeeshan025 لديهم شركة تمولها IIRC ...

مستقبل آخر يستحق الاستكشاف - HTML / CSS + .net (بدلاً من JS / TS). يجري تجربتها بالفعل هنا-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

بعد البحث ، يبدو أن tcl / tk يمكن أن يكون خيار واجهة المستخدم الرسومية لجميع الأنظمة الأساسية. لست متأكدًا مما إذا كان tcl / tk عند تشغيل Windows يستدعي عناصر gdiplus الفعلية ولكن قد يكون خيارًا لإحضار WPF و Winforms إلى Linux و Mac و Windows و Android ؟، و iOS ؟، وربما Webforms؟ لست متأكدًا مما إذا كان tcl / tk يدعم هؤلاء الثلاثة الأخيرة حتى الآن. إذا كان الأمر كذلك ، فهذا يجعل صيانة واجهة المستخدم الرسومية أسهل بكثير من خلال قاعدة رمز واحدة عليها.

ممكن استخدام واجهة المستخدم الرسومية:

• TclBridge (لا يبدو أنه مجاني أو مفتوح المصدر)
• واحد أحادي (ربما الأفضل)
• النسر (غير متأكد من مدى جودته)
• ربما الآخرين كذلك.

خطرت لي فكرة استخدام tcl / tk من وحدة tkinner في cpython.

لست متأكدًا أيضًا مما إذا كان .NET Core يدعم تحميل الموارد من * .resources (مجمع resx) أو حتى من * .resx حتى الآن. إذا كان الأمر كذلك فسيكون رائعًا.

يتوفر Microsoft.DesktopUI.App حاليًا الإصدار 3.0.0-alpha-26921-3 مع الإصدارات اليومية من Windows .NET Core SDK . لدي فضول لمعرفة ما هو المطلوب للحصول عليه وتشغيله على Linux ضمن بعض طبقات الترجمة لـ GDC و DirectX.

تحتاج إلى أكثر بكثير من منصة UX ، يجب أن تكون إطارًا لتطوير التطبيقات عبر الأنظمة الأساسية.
إن حصرها في UX فقط هو خطأ. يجب أن تحتوي على الأقل على جميع وظائف SilverLight + RIA-Services.
عندما تكتب أنظمة مخصصة ضخمة لشركات أكبر ستستمر لعقود من الزمان ، فأنت بحاجة إلى إبقاء جميع الخيارات مفتوحة نظرًا لعدم وجود فكرة عن المتطلبات التي ستتم إضافتها في غضون عام (أو خلال 10 سنوات) ، لذلك بيئة مغلقة ومحدودة مثل UWP لن يتم النظر إليه أبدًا ، نفس الشيء مع شيء يعمل داخل المتصفح. يجب أن يكون هناك وصول كامل وغير محدود وأصلي إلى كل ميزة واحدة وواجهة برمجة تطبيقات وخدمة على الأنظمة الأساسية المختلفة.
وعندما تقوم بتطوير نظام حيث تكتب كل من الخادم والعميل ، فأنت لا تريد استخدام REST أو شيء من هذا القبيل (الذي يُقصد استخدامه عند كتابة الخادم ، وكتابة شخص آخر للعميل) ، بدلاً من ذلك ، يجب أن يكون بروح RIA ، حيث تحدد واجهة برمجة تطبيقات الخادم ثم تسميتها تلقائيًا من العميل باستخدام نفس الفئات والطرق (===) مثل تلك الموجودة على الخادم. كل شيء يحتاج إلى كتابته بقوة. يبدأ التحقق من صحة البيانات بالحدود الصارمة التي تم الحصول عليها من الحقول في خادم SQL (أو أي مصدر بيانات تستخدمه) ، ويتم توسيعه بواسطة DataAnnotations ، والتي يتم نشرها على طول الطريق إلى العميل تلقائيًا (مع مراعاة الترجمة).

وهذا هو المطلوب فلا شيء أقل منه مقبول:
إنشاء نموذج تطوير تطبيق عميل .NET واسع الانتشار

لقد مر الآن 20 عامًا على إصدار Visual Basic 6 ، ولم نكن قريبين من الإنتاجية التي كانت لدينا في ذلك الوقت في عام 1998.تحتاج Microsoft إلى تقديم رؤيتها حول كيفية عمل نظام مخصص أكبر في "عالم Microsoft" ، وكيف سيعيدون الإنتاجية التي كانت لدينا قبل 20 عامًا.

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

وننسى أمر Xamarin ، فإن Microsoft لا تستخدمه بنفسها ، بل تختار إطار عمل واحد للذاكرة المترابطة مثل إطار عمل ElectronJS (استنادًا إلى Chromium و Node.js و JavaScript و CSS) ، بدلاً من استخدام Xamarin ، التي يمتلكونها و لديك سيطرة كاملة على ، والتي من شأنها أن تنتج رمزًا أصليًا حقيقيًا لكل نظام أساسي.

@ Bartolomeus-649

لقد مر الآن 20 عامًا على إصدار Visual Basic 6 ، ولم نكن قريبين من الإنتاجية التي كانت لدينا في ذلك الوقت في عام 1998.

كما أن انتشار استخدام الكمبيوتر والإنترنت بالإضافة إلى تنوع المنصات (عوامل نظام التشغيل / التنقل / الشكل) لم يكن قريبًا من أدنى مستوى له في عام 1998.

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

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

آمل أن نحصل على تجارب أفضل عبر الأنظمة الأساسية ، لكنني لا أعتقد أنها ستكون سهلة أو ستصمد أمام اختبار الزمن. حتى لو تطورت أغلفة WebAssembly والأغلفة الشبيهة بالإلكترون و PWAs والأصدقاء إلى حل go-to في السنوات الخمس المقبلة ، فربما نفعل شيئًا مختلفًا تمامًا خلال 20 عامًا (ثم نشكو من مدى سهولة الأمور في 2018 😂 ).

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

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

سؤالي هو ما إذا كنا - يمكن للمجتمع أن يعمل على منافذ Linux و macOS داخل مستودعات إعادة الشراء الحالية ، أي في فروع منفصلة أم يجب علينا إنشاء مستودعات منفصلة لدعم مثل هذه المشاريع؟ هذا قرار مهم للغاية لأن استخدام المستودعات الحالية سيسمح لنا بدمج المنافذ مع البنية التحتية MSFT CI والتي لولا ذلك سيتعين على المجتمع إعدادها من البداية.

هل هناك سبب يجعل Xamarin.Forms / Avalonia / Platform.U لا يناسب احتياجاتك؟ يبدو أن محاولة جديدة لجلب XAML عبر الأنظمة الأساسية لا تجلب قيمة تذكر للمجتمع ككل.

ليس 4 المبدعين ، ولكن 2 ¢ / انطباعاتي:

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

أنا لا أقول أن منفذ WPF أو Winforms عبر الأنظمة الأساسية هو الحل هنا. (لا يعد منفذ Winforms المتوافق مع API المتوافق مع الأنظمة الأساسية فكرة رائعة في المقام الأول ، IMO. لا تعليق على WPF.) ومع ذلك ، لا أعتقد أن الحلول الحالية مناسبة لتطوير تطبيقات سطح المكتب أيضًا.

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

بالمناسبة ، أي نقاط ألم حول NoesisGUI؟

يمكن أن يعمل المجتمع على منافذ Linux و macOS

@ 4creators قم بإنشاء مفترقات تمتلكها وتتحكم فيها بشكل كامل.

البنية التحتية CI

تتجه البنية الأساسية لـ .NET Core CI نحو استخدام Azure DevOps العادي بدلاً من حل Jenkins المخصص الحالي. يقدم Azure DevOps عروض مجانية لمشاريع مفتوحة المصدر يمكنك الاستفادة منها.

التحدث فقط من أجل dotnet / winforms:

يستخدم Winforms AzureDevOps بالفعل ، وأي علاقات عامة في المستوى الرئيسي ستقوم بتشغيل بناء PR CI تلقائيًا.

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

بالمناسبة ، أي نقاط ألم حول NoesisGUI؟

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

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

@ 4creators أعتقد أن عنوان هذه المشكلة خطأ بسبب الخلط بين مسألتين.

أولاً ، السماح لأطر عمل .Net UI باستخدام .Net Core بدلاً من أوقات تشغيل .Net الأخرى . يمكن تشغيل WPF على .Net Core الآن ، ويمكنهم تشغيل Xamarin.iOS / Android / Mac / GTK على NET Core أيضًا. هذا له فوائد الأداء والصيانة مقارنة باستخدام Mono أو .Net Framework.

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

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

أوافق على الجزء الأخير. ومع ذلك ، قال فريق Xamarin صراحةً أن استبدال Mono بـ .NET Core غير ممكن لأنه تم تحسينه لأحمال العمل المختلفة وسيتعين القيام بعمل تكامل غير بسيط.

أعتقد أن عنوان هذه القضية خطأ بسبب الخلط بين مسألتين.

@ charlesroddie IMO ، ليس حقًا. لا تكمن النقطة في أن يكون بعض إطار عمل UX متاحًا على منصة .NET Core ولكن بالأحرى UX الذي يعد جزءًا من نظام DotNet البيئي الذي تم إنشاؤه وصيانته بالاشتراك مع أجزاء أخرى. تعتمد خطط MSFT المستقبلية لنظام .NET الإيكولوجي على .NET Core مع إهمال .NET Framework لكونه مكونًا قديمًا من Windows غير موصى به لتطوير التطبيقات الجديدة. لا توجد خطط حاليًا لنقل Xamarin.Forms إلى .NET Core مع بعض الأسباب الموضحة أعلاه بواسطة @ Happypig375 والسبب الآخر هو عدم اتخاذ قرار بشأن كيفية متابعة دعم xplat على الهاتف المحمول. ومع ذلك ، أفترض أنه نظرًا لجهود التطوير المستثمرة في .NET Core ، فإن منصة xplat المستقبلية التي تستخدمها MSFT ستكون قائمة على .NET Core.

لم يتم تحسين Mono بشكل كافٍ للعديد من أحمال العمل حتى على Linux ولا توجد ميزات جديدة رئيسية تم تطويرها فوق وقت التشغيل هذا بعد الآن. تتم مشاركة BCL حاليًا بين Mono و .NET Core. يشير هذا إلى احتمال كبير لحدوث إهلاك أحادي في المستقبل.

بناءً على هذه الافتراضات ، أعتقد أنه من المفيد أن يكون لديك منصة UX واحدة تعتمد على .NET Core كجزء من نظامها البيئي. لذلك ، عنوان المشكلة هو تمامًا كما ينبغي لأنني لا أطلب بعض إطار عمل UX الذي هو xplat ومعيار CLI المستند إلى إطار UX الذي يعد جزءًا من نظام .NET Core البيئي المصمم والمدعوم من قبل فريق DotNet.

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

من المبالغة القول إن منصة تجربة المستخدم "تعتمد" على وقت تشغيل معين. @ Happypig375 ليس في خطط Xamarin حاليًا التبديل إلى .Net Core (الخطط بدلاً من ذلك هي السماح لـ Mono بأن تصبح أكثر شبهاً بـ .Net Core من خلال مشاركة الكود). ولكن لا ينبغي أن يكون الأمر أصعب من نقل WPF إلى NET Core.

(راجع للشغل ، ليس صحيحًا أن Mono ليس لديها ميزات جديدة حيث يتم تحديثها لدعم .Net Standard 2.1 ، ويتم تنفيذ العمل الحالي على Webassembly في Mono بدلاً من .Net Core. ولكن هذا جانباً حيث يمكن نقل هذا العمل إلى NET Core.)

خارطة طريق WinUI 3.0 - نحن بحاجة إلى مدخلاتك!

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

يجب أن يفكروا في تسميته MicrosoftUI 1.0 إذا كان هذا هو الحال ، @ 4creators. 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

أعتقد أن هذا الريبو يعالج هذه المشكلة.