Microsoft-ui-xaml: مناقشة: WinUI مقابل ElectronJS والنظام الأساسي المشترك (تحسين WinUI لإزالة أسباب استخدام ElectronJS بدلاً من WinUI)

الشيء نفسه ينطبق على تطبيق Xbox Beta الجديد. يستخدم 400 ميغا بايت فقط يتم فتحه كمتجر مجيد. يستخدم متجر Microsoft فقط 117 ميجا بايت أثناء النشاط.

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

مثال على السرعة المذهلة لـ ElectronJS / Teams:
أولاً ، على سبيل المقارنة ، قمت بضبط الوقت المستغرق لفتح Microsoft Outlook وعرض أحدث رسالة في البريد الوارد (صندوق وارد يحتوي على عدد كبير جدًا من الرسائل). استغرق الأمر بضع ثوانٍ فقط - في الواقع كانت سريعة جدًا لدرجة أنني لم أتمكن من إيقاف ساعة الإيقاف بالسرعة الكافية للحصول على قياس دقيق.
بعد ذلك ، حددت الوقت الذي يستغرقه فتح Microsoft Teams وعرض أحدث رسالة في الدردشة مع زميل: 27 ثانية! يمكن أن تكون هذه المرة أكثر أو أقل بناءً على عدد الرسائل والصور الموجودة في جزء الدردشة.

( التحديث 9-نوفمبر -2019: تم إصدار إصدار جديد من Teams وهو يعمل على تحسين الوقت المستغرق لعرض أحدث رسالة محادثة. يصف المثال السابق ذكره والذي يبلغ 27 ثانية الآن الإصدار السابق من Teams. شكرًا لموظفي Microsoft الأعضاء الذين عملوا على هذا التحسين ._)

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

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

وبالمثل ، إذا تمت كتابة Teams باستخدام WinUI ، فلن يؤدي ذلك إلى إنشاء 5 عمليات Teams.

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

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

على الرغم من أنني أتفق بشكل عام ، يجب أن تكون هذه القصة أكثر من ذلك ، لأنه على سبيل المثال Microsoft OneNote متاح لأنظمة Windows و Android و Mac ، لكنه لا يستخدم ElectronJS (AFAIK) ولا يعاني من أداء سيئ مثل فرق.

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

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

على الرغم من أنني أتفق بشكل عام ، يجب أن تكون هذه القصة أكثر من ذلك ، لأنه على سبيل المثال Microsoft OneNote متاح لأنظمة Windows و Android و Mac ، لكنه لا يستخدم ElectronJS (AFAIK) ولا يعاني من أداء سيئ مثل فرق.

تمتلك Microsoft الموارد اللازمة لإنشاء تطبيقات لكل نظام أساسي ، ومشاركة التعليمات البرمجية قدر الإمكان - ولكن لا تستخدم واجهة مستخدم مشتركة

أود أن أسمع أي حجج ضد استخدام Uno Platform التي تستهدف منصات متعددة (Windows ، iOS ، Android ، Web) تنتج حزم تطبيقات عالية الأداء باستخدام UWP API الآن ، WinUI لاحقًا. يستخدم كل شيء Microsoft - VS، C #، Xaml، Xamarin، mono، .Net ...
ألا يأتي من مايكروسوفت مباشرة السبب الأساسي الذي يدفع البعض لتجنبه؟

أود أن أسمع أي حجج ضد استخدام Uno Platform التي تستهدف منصات متعددة (Windows ، iOS ، Android ، Web) تنتج حزم تطبيقات عالية الأداء باستخدام UWP API الآن ، WinUI لاحقًا. يستخدم كل شيء Microsoft - VS، C #، Xaml، Xamarin، mono، .Net ...
ألا يأتي من مايكروسوفت مباشرة السبب الأساسي الذي يدفع البعض لتجنبه؟

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

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

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

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

قامت Microsoft بعمل جيد مع دعم .NET و Win32. وقد تكون WinUI فرصة للسماح لـ Win32 و .NET - ولكن باستخدام واجهة مستخدم حديثة.

تم التخلي عن كل من Silverlight و WinRT و UWP. (أعلم أن UWP ليس تقنيًا ، ولكن من المرجح أن يُنظر إلى WinUI على أنه بديل).

Zune و Windows Media Center و Windows Phone 7 و Windows Phone 8 و Windows 8 - خذل المتحمسين وأولئك الذين حاولوا التبشير.

كيف تضع Microsoft موقع WinUI وتضمن أيضًا تأمين مستقبل Windows ، ستكون ضرورية للغاية

يبدو WinUI for Desktop واعدًا ، لكني أشعر أن مجموعة فرعية على الأقل من XAML يجب أن تكون قادرة على العمل على الويب ؛ WinUI على الويب ، مثل Silverlight الجديد ولكنه يعمل على .NET 5 و WebAssembly.

تم التخلي عن كل من Silverlight و WinRT و UWP. (أعلم أن UWP ليس تقنيًا ، ولكن من المرجح أن يُنظر إلى WinUI على أنه بديل).

Zune و Windows Media Center و Windows Phone 7 و Windows Phone 8 و Windows 8 - خذل المتحمسين وأولئك الذين حاولوا التبشير.

كونكور.
لا أصدق بعضًا من Silverlight (تطبيقات الويب 0 لا تزال تستخدم يوميًا من قبل بعض المستخدمين.
كانت متابعة مايكروسوفت صعبة بشكل متزايد. يقوم الأشخاص الذين يقفون وراء Uno Platform بتطويرها وصيانتها لدعم أعمالهم في مجال تطبيق الخبز والزبدة. إنه مفتوح المصدر وله العديد من المساهمين. أشعر أنني أركب حافلة جيدة جدًا مع سائقين من الدرجة الأولى يعرفون جيدًا كيفية التنقل في متاهة Microsoft أو الفوضى.

سنتي 2: الأمل الوحيد لـ UWP و WinUI ، هو أن تجعله سريعًا عبر الأنظمة الأساسية ، متضمنًا على الويب ، قبل أن يتبقى منه شيء.
يعد Uno Platform طريقة سريعة وسهلة وربما أيضًا الطريقة الأكثر أمانًا لتحقيق ذلك.
كما ذكر zipswich ، كان Uno شركة Microsoft طوال الطريق وطوال الوقت ؛ في إرشادات الترميز ، والأدوات ، واختيار اللغة ، والعرض ، وهو جاهز للتصميم بطلاقة.
إنه أكثر انحيازًا لـ Microsoft بمقدار 100 ضعف من Xamarin ، على سبيل المثال. ناهيك عن React أو Electron ، وجميع تقنيات HTML و CSS أو JS القبيحة MS هي مهووسة جدًا بالإطراء والغش.

و lemme كن قاسيًا ، C # ليست سوى لغة خادم مع افتقار .NET Standard إلى إطار عمل لواجهة المستخدم.
كلما طالت مدة بقائها على هذا النحو ، ستصبح Dart أو التقنيات الأخرى لغات خادم ، وستتولى المسؤولية بالكامل.
ترى أن الناس على استعداد لاستخدام لغات سيئة (JS) ، كتضحية لتكون قادرًا على استخدام قاعدة رمز لغة واحدة ، في كل من العميل والخادم. قد يتلاشى C # تمامًا كما فعل XAML ، أو يمكنه الفوز مع XAML إذا تم توفير الإنقاذ في حالات الطوارئ.

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

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

في الواقع ، كان لدى Microsoft بالفعل شيء من هذا القبيل يعمل بشكل جيد للغاية: استندت UWP UI في الغالب على رمز Silverlight ، وكان لدى Microsoft مكونات إضافية لـ Silverlight لجميع الأنظمة الأساسية الرئيسية ، مما يعني أن لديهم بالفعل محركات عرض أساسية لجميع هذه الأنظمة الأساسية. لم يتم تحديثها ، نظرًا لأن UWP لديها الآن الكثير من الإضافات مقارنة بـ Silverlight. لكنها قاعدة يمكن البناء عليها.

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

قد يتلاشى C # تمامًا مثل XAML>

بالتأكيد لا أتفق مع هذا البيان بخصوص C #. C # أكبر بكثير من XAML. إذا كنت تتابع Blazor فستعرف أن هذا لا يمكن أن يكون صحيحًا. أرى Blazor بمثابة مغير للعبة بالنسبة لي باستخدام UWP / Xamarin بشكل أساسي ولمطوري C # بشكل عام الذين يستهدفون بشكل خاص مستخدمي الأعمال.

سيكون من الجيد أن يكون لديك WinUI x-platform ولكني أعتقد أن أسهل طريق إلى الويب / منصة x هو Blazor خاصة الآن حيث يدعم Blazor أيضًا الفصول الجزئية مما يعني أنه يمكنني أخذ معظم الكود الخاص بي كما هو والبدء في استخدامه في بليزر. يمكن أن يكون زوجان من الفواق بدائل لـ Sqlite و Shared Projects و ReactiveUI. يجب أن أكون قادرًا على استخدام بنية MVVM الحالية الخاصة بي ونقلها إلى Blazor بسهولة إلى حد ما.

أهم حجر عثرة بالنسبة لي هو عدم وجود دعم .net core 3 في UWP. أعتقد أنه من الأهمية بمكان بالنسبة لـ MS محاذاة Blazor + UWP في تجربة المطور. أعرف أن فريق UWP يعمل على ذلك.

أود أيضًا أن أرى صفحات Blazor في تطبيقات UWP / WInUI. سيعمل نموذج Hybrid UI بشكل رائع بالنسبة لي في تطبيقات UWP حتى أتمكن من استخدام أفضل أصول واجهة المستخدم المتاحة. (html5 مقابل XAML) وأيضًا عدم تكرار جهدي في واجهة المستخدم بين UWP و Blazor حيث يكون ذلك منطقيًا.

تستخدم Electron حاليًا جافا سكريبت و HTML + CSS. لا يوجد سبب يمنعنا من استخدام Electron مع Blazor => C # و HTML + CSS + gRPC

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

lucasf هل جربت أونو؟ هل تعلم أن Uno يسمح باستخدام أي واجهة برمجة تطبيقات أصلية عبر Xamarin في حالة عدم وجود واجهة برمجة تطبيقات UWP مناسبة. لا أستخدم سوى عدد قليل من واجهات برمجة التطبيقات الأصلية في تطبيقاتي المستندة إلى Uno حتى بالنسبة لتطبيق دفق الفيديو في الوقت الفعلي الذي يستخدم ترميز الأجهزة ويتطلب زمن انتقال منخفض.

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

lukasf هل جربت أونو؟ هل تعلم أن Uno يسمح باستخدام أي واجهة برمجة تطبيقات أصلية عبر Xamarin في حالة عدم وجود واجهة برمجة تطبيقات UWP مناسبة. لا أستخدم سوى عدد قليل من واجهات برمجة التطبيقات الأصلية في تطبيقاتي المستندة إلى Uno حتى بالنسبة لتطبيق دفق الفيديو في الوقت الفعلي الذي يستخدم ترميز الأجهزة ويتطلب زمن انتقال منخفض.

zipswich مجموعة عناصر تحكم Xaml القياسية في Uno صغيرة جدًا ، وليس في أي مكان بالقرب مما يقدمه UWP أو WinUI3 الكامل. لتحقيق واجهات مستخدم جيدة / معقدة ، يتعين عليك عادةً تضمين عناصر تحكم وكود واجهة مستخدم أصلية خاصة بالنظام الأساسي. لذلك في النهاية ستجد نفسك مع مزيج من منصات واجهة المستخدم المتعددة (Uno Xaml أو Android الأصلي أو Native iOS أو ربما Windows الأصلي أو WebAssembly). ليس هذا ما أسميه تجربة مطور رائعة.

إذا كان لدينا عارضين أصليين لـ x-platform لـ WinUI ، فلدينا واجهة مستخدم واحدة فقط مع مجموعة ميزات WinUI الكاملة ، دون أي نوع من عناصر النظام الأساسي الخاصة بها. وسيتم عرض WinUI مباشرةً على وحدة معالجة الرسومات بأداء كامل ، تمامًا كما تتوقعه. لا حاجة لإضافة عناصر تحكم Android إضافية أو عناصر تحكم iOS إضافية. هذا هو الشكل الذي يجب أن يبدو عليه تطوير منصة x.

ما الذي يفتقر إليه WinUI (وكيف يمكن تحسينه) لإقناع مديري برامج Microsoft لـ Microsoft Teams بالتبديل من ElectronJS إلى WinUI / UWP؟

سؤال رائع. سيكون عدد كبير من المستخدمين سعداء جدًا إذا فعلوا ذلك.

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

النقص الحالي في هذا البحث يساعد الأطر غير الفعالة على أن تصبح شائعة.

التحدث بصدق: أشك في أن MS لديها أي خطط لإنشاء "WinUI" ( Windows UI) عبر الأنظمة الأساسية. علاوة على ذلك ، فإن حقيقة أنه مفتوح المصدر الآن يعني عادةً أن Microsoft لم تعد تعتبره تقنية مهمة / إستراتيجية. إنهم يحاولون الاستفادة من موارد المجتمع بدلاً من ذلك لخفض عدد الموظفين الداخليين مع إبقائه على قيد الحياة. لا تفهموني بشكل خاطئ ، أنا سعيد لأن WinUI مفتوح المصدر الآن وأقدر كل الوقت الذي يضعه مطورو Microsoft في النظام الأساسي لنقله إلى WinUI 3.0 - إنها خطوة رائعة لتوحيد النظام الأساسي للعرض التقديمي لـ windows لكل من التطبيقات المدارة. لا أعتقد أن Microsoft ترى Windows على أنه المستقبل ولا أعتقد أنهم مهتمون بأخذه عبر الأنظمة الأساسية (بالطبع هذا خطأهم إذا كان صحيحًا).

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

• مكتبة تحكم وترميز (XAML) يمكن أن يتم عرضهما تمامًا مثل تصميمات النظام الأساسي الأصلية (سنحتاج فقط إلى أنماط تحكم لنظام التشغيل iOS و Android وما إلى ذلك)
• يحتاج إلى أن يكتب في التعليمات البرمجية المدارة مثل WPF كان. فقط الطبقات الأساسية في C ++ ، يجب ألا تكون عناصر التحكم سوى C #.
• يجب أن يتم العرض باستخدام Metal / Vulcan / DirectX (ليس أعلى عناصر التحكم الموجودة مثل Uno)
• يجب إعادة تنفيذ الإدخال بطريقة X-platform
• تعد إمكانية الوصول مشكلة كبيرة يسهل حلها للأسف باستخدام نهج Uno

إذا كان هذا ما نريده ، فإن WinUI لن يفعل ذلك على ما أعتقد. حقيقة وطريقة تنفيذه محليًا (بعض طبقات COM / .net بينهما) وحدها تعني أنه سيكون من الصعب جدًا استخدام هذا النظام الأساسي المتقاطع. بدلاً من ذلك ، لدينا UNO و Avalonia. أفالونيا هو الضوء الحقيقي في نهاية النفق لكن ليس لديهم أي موارد. ما هو أكثر أو أقل ممكنًا الآن هو استخدام تقنية عرض Avalonia كواجهة خلفية لـ WPF (الجزء المُدار). من شأن ذلك أن يمنحنا إطارًا حقيقيًا لواجهة المستخدم عبر الأنظمة الأساسية في فترة زمنية قصيرة. تكمن المشكلة في أن WPF مصمم لسطح المكتب وقد تم بذل الكثير من العمل في UWP لجعل WPF / Silverlight مناسبًا للأجهزة بحجم الهاتف والإدخال التفاعلي / اللمس الحديث.

أعتقد بصدق في هذه المرحلة أننا سنكون أفضل حالًا إذا ألقينا جميعًا بالمال والمساهمات البرمجية في Avalonia. لقد طلبنا من Microsoft واجهة مستخدم عبر الأنظمة الأساسية لفترة طويلة جدًا وهم راضون عن التبديل إلى تقنيات الويب بأنفسهم. تقوم Microsoft بتحويل تطبيقات UWP مثل XBox إلى تقنيات الويب والويب الآن. لا تُباع التطبيقات أيضًا في متجر Microsoft.

المفارقة هي أن Microsoft كانت ناجحة جدًا في الماضي لأنها قدمت للمطورين الأدوات التي يحتاجونها لبناء تطبيقات رائعة. هذا يجذب المستخدمين ولديك حلقة ملاحظات بناءة للغاية. في مرحلة ما تم نسيان ذلك. يلجأ المطورون الآن إلى تقنيات دون المستوى (لم يتم تصميم HTML / CSS في الأصل للتطبيقات ... كان من أجل ترميز المستندات!) ولكن التوفير في الاضطرار فقط إلى تطوير تطبيق مرة واحدة وتشغيله على Electron والويب تفوق بكثير التضحيات في الوظائف وتكامل النظام والأداء في هذا اليوم والوقت.

المفارقة هي أن Microsoft كانت ناجحة جدًا في الماضي لأنها قدمت للمطورين الأدوات التي يحتاجونها لبناء تطبيقات رائعة. هذا يجذب المستخدمين ولديك حلقة ملاحظات بناءة للغاية. في مرحلة ما تم نسيان ذلك. يلجأ المطورون الآن إلى تقنيات دون المستوى (لم يتم تصميم HTML / CSS أصلاً للتطبيقات ... كان من أجل ترميز المستندات!)

احسنت القول. إلى جانب BASIC ، بدأت في استخدام Microsoft IDEs من Quick C ، ثم VC ++ ... اعتادت Microsoft على التطور والابتكار بطريقة ثابتة ومتسقة ويمكن التنبؤ بها إلى حد ما. حاولنا اتباعها ، ويبدو أنها تتبع اتجاه أولئك الذين من المفترض أن يتبعونا. اعتدت على إخبار المتدربين من أفضل الجامعات البحثية باستخدام تقنيات Microsoft لتطبيقات المؤسسات التي طُلب منهم العمل عليها. لم يكن هناك أي مقاومة ، وحسن الحظ التقطوا أشياء Microsoft بسرعة. لقد كنت أتساءل عما إذا كانت Microsoft تبحث في ما يحبه الأطفال هذه الأيام ، ثم تتبعهم.

لا تُباع التطبيقات أيضًا في متجر Microsoft.

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

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

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

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

سيتم فصلي على الفور لأنني بذلت الكثير من الجهد على إصدار UWP الذي يولد القليل جدًا من العائدات.

أسمعك ، لقد أدليت بهذا البيان بناءً على تطبيقي الخاص في متجر Microsoft أيضًا.

robloo لديك بعض النقاط الجيدة هناك ، لكنني لا أتابعك حقًا. إليك بعض الأفكار:

• بذلت Microsoft الكثير من الجهد والموارد في أطر عمل أخرى مفتوحة المصدر أيضًا ، مثل .NET Core و ASP.Net Core و EF Core. من الواضح أنهم يرون المستقبل في تطوير مفتوح المصدر وعبر الأنظمة الأساسية (على الأقل لتطبيقات الخادم). يضعون أيضًا الموارد في تجميع AOT ، لذلك يمكن تجميع .NET Core إلى iOS و Android أيضًا (حيث لا يُسمح بـ JIT). لذلك لا يمكنني أن أتابعك قائلا إن WinUI ميت الآن ، فقط لأنهم جعلوه مفتوح المصدر. أعني ، قد يكون هذا صحيحًا ، لكن إذا كانت حجتك الوحيدة هي "لأنهم يجعلونها مفتوحة المصدر" ، فهذا ليس مقنعًا للغاية.

• Qt عبارة عن إطار عمل لواجهة مستخدم عبر الأنظمة الأساسية ، يتم تنفيذه في لغة C / C ++ الأصلية. يحتوي على عارضين OpenGL / Direct3D مُسرَّع بالأجهزة ، لذلك يبدو كما هو وله أداء رائع على جميع الأنظمة الأساسية. ليست هناك حاجة إلى رمز خاص بالنظام الأساسي ، حيث تعمل جميع عناصر التحكم على جميع الأنظمة الأساسية ، بما في ذلك iOS و Android. فلماذا لا يكون من الممكن تقنيًا تشغيل WinUI على iOS و Android ، إذا كان بإمكان Qt فعل ذلك؟ يتم تنفيذ WinUI في WinRT ، وهي لغة C ++ أصلية ، تمامًا مثل Qt. داخليًا ، لا يستخدم سوى عدد قليل من تقنيات COM (واجهة IUnknown بالإضافة إلى نظام مصنع COM). لا ينبغي أن يكون من الصعب للغاية تجريد ذلك بعيدًا أو إعادة تنفيذ ما هو مطلوب للمنصات الأخرى. لا أعتقد أنه يتم استخدام أي كود COM مباشرة في كود WinUI.

• استخدم Silverlight نفس التقنية وكان متاحًا على منصة x.

• لا يزال Windows هو نظام التشغيل الأول لسطح المكتب ، المستخدم بكثرة ، ليس فقط في المنزل ولكن أيضًا (بشكل خاص) من قبل الشركات. إلى جانب تراخيص Office ، فإنه يولد الكثير من الإيرادات القوية لشركة Microsoft. سيفقدون هذه الإيرادات إذا تركوا جميع منصات تطوير واجهة المستخدم الرئيسية تموت. لقد ماتت WinForms و WPF بالفعل ، لذا فإن WinUI هي منصة واجهة المستخدم النشطة الوحيدة على Windows. لا أعتقد أنهم يريدون التخلص من نظام Windows / Office / Enterprise الكامل ، لذلك لا أعتقد أنهم يريدون التخلص من WinUI.

• يعد جعل WinUI مفتوح المصدر أمرًا رائعًا للمطورين ، وليس فقط لـ Microsoft.

• قد يكون أن UWP سوف يموت. العديد من المطورين يبتعدون عنه بسبب كل القيود الغبية. متجر Windows ليس ناجحًا عن بُعد. توقف Windows Phone ، وهذا كان السبب الرئيسي لبدء تشغيل برنامج UWP بالكامل.

• قد يكون إحضار WinUI إلى تطبيقات سطح المكتب باستخدام WinUI 3.0 وجعله مفتوح المصدر في الواقع خطوة لحفظه وليس قتله!

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

robloo لا يجب أن يكون الأمر كذلك. لقد كنت أقول طوال الوقت إنه أسوأ متجر تطبيقات قتل Windows Phone ، أفضل منصة للهاتف المحمول.

يمكنهم قتل عصفورين بحجر واحد: الاستعانة بمصادر خارجية في المتجر لطرف ثالث مختص وإنهاء كابوس .Net Native. سيقلل من تكلفتها و (أعتقد) مضاعفة ، أربع مرات ... يتم تنزيل تطبيق Windows بسرعة. أكثر من 90٪ من مشكلات تطبيق UWP مرتبطة فقط بكابوس .Net Native.

lukasf أعتقد أنك أساءت تفسير الكثير مما كنت أقوله.

لا أستطيع أن أتابعك قائلا إن WinUI ميت الآن ، فقط لأنهم جعلوه مفتوح المصدر.

لن أقول أبدًا أن WinUI قد مات. لقد قلت أن Microsoft ربما لم تعد تعتبره منتجًا مهمًا / استراتيجيًا طويل الأجل. إنهم يرون أرباحًا أعلى في مجالات أخرى (الخدمات والسحابة) لذا تأكدوا من قضاء وقتهم حيث توجد أرباح أعلى للمساهمين. هذا يعني أنني أعتقد أنهم لن يقوموا بتطوير WinUI بشكل كبير لجعله متعدد المنصات والاحتفاظ به على قيد الحياة والذي حرصت على قوله بدلاً من "ميت". (أنا لست شخصًا في UWP / WinUI هو عربة ميتة). أشعر أيضًا بقوة أن Microsoft تقوم بعمل رائع مع WinUI 3.0 الذي ذكرته. إنه يسمح لجميع أنظمة Windows ، Win32 الأصلية والمدارة ، بالاندماج مع إطار عمل واحد لواجهة المستخدم.

فلماذا لا يكون من الممكن تقنيًا تشغيل WinUI على iOS و Android

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

استخدم Silverlight نفس التقنية وكان متاحًا على منصة x.

ولم يعد Silverlight ميتًا لأنه لم يكن ممكنًا تقنيًا ولكن لأنه لم يعد حالة عمل جيدة وهي بالفعل أكثر النقاط أهمية بالنسبة لي. لاحظ أنه مات أيضًا بسبب تقنيات HTML / CSS / JS نفسها التي تتولى الآن تطوير سطح المكتب والأجهزة المحمولة.

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

ربما يمكن مناقشة هذا بعدد من الطرق المختلفة ولكن ربما يخرج تمامًا عن نطاق الموضوع بسرعة كبيرة (وهو ما أعلم أنني أفعله بالفعل). خلاصة القول ، بالطبع لن تدع Microsoft جميع منصات Windows UI تموت. لا يزال يتعين عليك كتابة تطبيقات لنظام التشغيل Windows ... لم أقل غير ذلك مطلقًا.

يعد جعل WinUI مفتوح المصدر أمرًا رائعًا للمطورين ، وليس فقط لـ Microsoft.

لقد قلت "أنا سعيد أن WinUI مفتوح المصدر الآن وأقدر الوقت الذي يقضيه مطورو Microsoft في النظام الأساسي لنقله إلى WinUI 3.0" وكان الهدف هو نقل شعوري بأنني أعتقد أيضًا أن المصدر المفتوح رائع لعدد من الأشخاص من الأسباب التي لم أتطرق إليها. على سبيل المثال ، حتى منصة Uno التي تتمتع الآن بإمكانية الوصول إلى المصدر يعد أمرًا رائعًا كما ذكروا في UnoConf.

قد يكون أن UWP سوف يموت.

انتظر ، في أي جانب أنت؟ هاها. ولكن بجدية أنا أعتبر WinUI / UWP في الأساس نفس الشيء و UWP سيكون لها تطور طفيف في WinUI مع عدم وجود مشاكل كبيرة للمطورين.

قد يكون إحضار WinUI إلى تطبيقات سطح المكتب باستخدام WinUI 3.0 وجعله مفتوح المصدر في الواقع خطوة لحفظه وليس قتله!

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

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

يمكنهم قتل عصفورين بحجر واحد: الاستعانة بمصادر خارجية في المتجر لطرف ثالث مختص وإنهاء كابوس .Net Native. سيقلل من تكلفتها و (أعتقد) مضاعفة ، أربع مرات.

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

تقوم Microsoft الآن بتطوير تجميع AOT كامل وعالي الأداء باستخدام تقنيات Mono و LLVM. أعتقد أن هذا من المفترض أن يأتي بحلول العام المقبل ، كما أنه مفيد أيضًا لـ Blazor من جانب العميل مع Webassembly. قدم ميكيل دي إيكازا عرضًا تقديميًا جيدًا لمسه في وقت سابق من هذا العام في UnoConf: https://www.youtube.com/watch؟v=tYk2us6W6Gg (هو أول مقدم).

robloo حسنًا ، ربما أخطأت في بعض النقاط.

فلماذا لا يكون من الممكن تقنيًا تشغيل WinUI على iOS و Android

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

استخدم Silverlight نفس التقنية وكان متاحًا على منصة x.

ولم يعد Silverlight ميتًا لأنه لم يكن ممكنًا تقنيًا ولكن لأنه لم يعد حالة عمل جيدة وهي بالفعل أكثر النقاط أهمية بالنسبة لي. لاحظ أنه مات أيضًا بسبب تقنيات HTML / CSS / JS نفسها التي تتولى الآن تطوير سطح المكتب والأجهزة المحمولة.

نقطتي هنا هي: كان Silverlight يعمل بالفعل عبر الأنظمة الأساسية. يمكن استخدامه مع التعليمات البرمجية المدارة. كانت طبقة UWP Xaml UI من Windows 8 أساسًا Silverlight ، فقط مع مساحة اسم جديدة وبعض البيانات الوصفية المضافة. لقد تطور الآن ، ولكن في البداية كان من الواضح أنه كان مجرد Silverlight Xaml مع مساحة اسم جديدة. لذلك إذا كان بإمكانهم تشغيل منصة Silverlight عبر النظام الأساسي في ذلك الوقت ، فيمكنهم تشغيل WinUI عبر النظام الأساسي أيضًا. ولا أعتقد أن هذا سيكون "صعبًا للغاية" لكنني أفضل القول إنه سيكون بالأحرى سهلًا لشركة ضخمة مثل Microsoft. لديهم بالفعل طبقة عرض عبر النظام الأساسي لـ Silverlight Xaml. لا ينبغي أن يكون تحديثه صعبًا للغاية حتى يتمكن من تشغيل أحدث إصدار من WinUI.

قد يكون أن UWP سوف يموت.

انتظر ، في أي جانب أنت؟ هاها. ولكن بجدية أنا أعتبر WinUI / UWP في الأساس نفس الشيء و UWP سيكون لها تطور طفيف في WinUI مع عدم وجود مشاكل كبيرة للمطورين.

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

نقطتي هنا هي: كان Silverlight يعمل بالفعل عبر الأنظمة الأساسية. يمكن استخدامه مع التعليمات البرمجية المدارة. كانت طبقة UWP Xaml UI من Windows 8 أساسًا Silverlight ، فقط مع مساحة اسم جديدة وبعض البيانات الوصفية المضافة. لقد تطور الآن ، ولكن في البداية كان من الواضح أنه كان مجرد Silverlight Xaml مع مساحة اسم جديدة. لذلك إذا كان بإمكانهم تشغيل منصة Silverlight عبر النظام الأساسي في ذلك الوقت ، فيمكنهم تشغيل WinUI عبر النظام الأساسي أيضًا. ولا أعتقد أن هذا سيكون "صعبًا للغاية" لكنني أفضل القول إنه سيكون بالأحرى سهلًا لشركة ضخمة مثل Microsoft. لديهم بالفعل طبقة عرض عبر النظام الأساسي لـ Silverlight Xaml. لا ينبغي أن يكون تحديثه صعبًا للغاية حتى يتمكن من تشغيل أحدث إصدار من WinUI.

لم أكن أعرف أن تاريخ قاعدة Silverlight المستخدمة في UWP / Win8 في ذلك الوقت ، إذا كان هذا هو الحال ، فإنه يجعلني أكثر تفاؤلاً بشأن مدى جدوى ذلك. شكرا على التصحيح!

WinUI هي مجرد طبقة Xaml UI ، في حين أن UWP عبارة عن إطار عمل كامل للتطبيق وطبقة واجهة برمجة تطبيقات للنظام ، وهي مرتبطة بمتجر Windows ، وبها الكثير من القيود مقارنة بتطبيقات سطح المكتب الكلاسيكية. إذن هذان شيئان مختلفان للغاية.

نعم ، أنت محق وكان علي أن أختار صياغتي بعناية أكبر. بالتأكيد سيستمر وجود UWP في نموذج التطبيق والتعبئة في الوقت الحالي. ومع ذلك ، ستتحول طبقة واجهة المستخدم إلى WinUI وهو ما كنت أحاول توصيله. أعتقد أنه سيكون هناك المزيد من التغييرات في السنوات القادمة مع استبدال .net الأصلي ولكن نموذج الحزمة / التطبيق / واجهة برمجة التطبيقات التي تم تقديمها مع UWP ستظل موجودة في شكل ما. أوافق بالتأكيد على أن Microsoft قد لا ترى مستقبلًا هنا بالرغم من ذلك. لحسن الحظ ، طالما أن XAML و C # لا يزالان هناك ، فإن الترحيل إلى نموذج تطبيق جديد أو التعبئة / التوزيع عادة ما يكون سريعًا نسبيًا. إذا تم الانتهاء فقط من Avalonia ...

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

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

لا أستطيع أن أختلف بقوة بما فيه الكفاية مع المعلقين الذين يقولون:

يجب أن يكون WinUI 3.0 متعدد المنصات!

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

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

أتذكر أنني رأيت هذه السطور منذ بضعة أيام:
"لم يعد نظام التشغيل هو الطبقة الأكثر أهمية بالنسبة لنا ... الأهم بالنسبة لنا هو نموذج التطبيق والخبرة."
لذلك من الواضح أن WinUI يجب أن يكون أفضل تجربة واجهة مستخدم رسومية ، وأعتقد أنه سيكون ، مثل أفضل ما في WPF و UWP و Windows 10 ،

ولكن من الواضح أن الويب وجافا سكريبت + HTML القديم الخاص به يتم استخدامهما في كل مكان ، ويتم استخدام أطر الويب والمكدسات على نطاق واسع ، ليس لأنها أفضل ، ولكن لأنها متاحة بسهولة على متصفح الويب للهاتف ، ومستعرض ويب سطح المكتب. يمكنك إنشاء ملف HTML في Notepad ، ووضع علامة Script مع تنبيه ("Hello World") ؛ ولديك تطبيق.

لذلك أرى أنه من الممكن بل ومن الضروري استبداله بـ .NET + XAML باستخدام WebAssembly. نحتاج إلى أن يكون .NET موجودًا في كل مكان مثل جافا سكريبت اليوم.

كان Silverlight نورًا للأمل ... والآن مع WebAssembly ، أرى أنه من الممكن عودة Silverlight.

سأكون سعيدًا بهذا:
WinUI هو واجهة المستخدم الرسومية الكاملة التي تعمل بنظام التشغيل وعلى الأقل مجموعة فرعية من XAML قادرة على العمل على WebBrowser.

لذلك أرى فريق UNO مهمًا جدًا ، وآمل أن ينضموا إلى Microsoft في المستقبل القريب لتوحيد الجهود في هذا الجهد الرائع الذي هو WinUI.

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

اجعل WinUI الخيار الأفضل لواجهة المستخدم لأي شخص يفكر في تطوير Windows الأصلي. ينهي:

• التحقق من صحة الإدخال والتحكم في شبكة البيانات الأصلية
• ميزات أخرى ~ 170 مقترحات هنا
• الأخرى ~ 300 تذكرة مفتوحة
• NET Native> ترحيل .NET Core (لـ .NET Core 3 + 5 و .NET Standard 2.1+ و C # 8 ...)
• مترجم AOT الجديد
• احصل على إرشادات تصميم متماسكة بطلاقة تم مسحها ونشرها
• صقل النمط / نظام الموضوع
• قم بإلغاء التأكيد على ميزات التكوين المشتتة للانتباه (الإمالة ، استخدام الأكريليك الكثيف ، الكشف) وركز أكثر على العمق + نظام الظل والرسوم المتحركة (التي توفر الوضوح وتوجه المستخدمين)

هذه هي الأشياء التي ستجعل WinUI أكثر جاذبية للأشخاص الذين يعتبرونها مقابل Electron في المستقبل.

سيكون الجليد على الكعكة بعد ذلك:

• أداة (أدوات) للمساعدة في الحفاظ على تزامن نمط CSS <-> XAML
• إرشادات للحفاظ على منطق التطبيق منفصلاً عن طرق العرض للحد الأقصى من إعادة استخدام رمز .NET على الأنظمة الأساسية الأخرى
• بعض الأدوات لإنشاء ترجمة تقريبية لمرة واحدة لـ HTML> عناصر تحكم XAML لبدء المطورين في استخدام تطبيقات WinUI الأصلية (بدلاً من افتراض أن معظم المطورين سيبدأون بتطبيقات XAML والرغبة في التوجه نحو HTML)

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

MarkIngramUK كان Silverlight متعدد المنصات ، ومميزات كاملة وعرض نفسه تمامًا على جميع الأنظمة الأساسية. Qt عبارة عن منصة مشتركة وكاملة الميزات ويتم عرضها تمامًا على جميع الأنظمة الأساسية. تحصل فقط على عرض غير متسق وعناصر تحكم في القاسم المشترك الأدنى إذا حاولت إدراك عناصر التحكم الخاصة بك عن طريق ترجمتها داخليًا إلى عناصر تحكم أصلية لمنصة مختلفة (وهو ما يحاول Xamarin و Uno القيام به). إذا قمت بإجراء التجريد ليس على مستوى التحكم ولكن على المستوى الأدنى (طبقة تقديم GPU) ، يمكنك الحصول على نفس الإخراج بنسبة 100٪ على جميع الأنظمة الأساسية مع مجموعة التحكم الكاملة. مجموعة التحكم موجودة بالفعل ، وهي WinUI 3.0 ، وهي مجموعة رائعة حتى الآن. الشيء الوحيد المفقود هو عرض تطبيقات الطبقة للأنظمة الأساسية الأخرى (ويمكن أخذها جزئيًا من مصادر Silverlight القديمة).

أرغب حقًا في تطوير التطبيقات عبر الأنظمة الأساسية. لكن لا يبدو Xamarin ولا Uno جذابين بالنسبة لي ولا أحب JS / HTML وكل ما يعتمد عليه. لسوء الحظ ، يعد التطوير حصريًا لمتجر Windows اختيارًا سيئًا إذا كنت تنوي جني الأموال منه بالفعل. على الأقل كان لدي تجارب سيئة مع ذلك ، وبعد ذلك بعد أن قتلت Microsoft نظام Windows Phone البيئي ، وضعت حدًا له تقريبًا (على الرغم من بعض المشاريع الصغيرة "للمتعة فقط"). سأبدأ على الفور في العمل على تطبيقات جديدة مرة أخرى إذا كان WinUI يعمل عبر الأنظمة الأساسية.

تحتوي جميع الأطر الحالية عبر الأنظمة الأساسية على قيود أكثر أو أقل حدة و / أو تجربة تنمية سيئة. إذا تمكنت Microsoft من إنشاء WinUI عبر الأنظمة الأساسية ، فقد تكون حقًا تقنية رائعة. حققت Xamarin نجاحًا كبيرًا بالفعل ، على الرغم من كل حوافها وزواياها وقيودها. فقط تخيل مدى نجاح WinUI إذا تم تشغيله على جميع الأنظمة الأساسية مع مجموعة ميزات كاملة وتجربة تطوير Visual Studio من الدرجة الأولى.

lukasf ، هذه وجهة نظري:

كان Silverlight متعدد المنصات ، ومميزات كاملة وتم تقديمه تمامًا على جميع الأنظمة الأساسية.

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

MarkIngramUK أرى الأمر على هذا النحو: تلتزم التطبيقات البسيطة بعناصر تحكم واجهة المستخدم الخاصة بالمنصة. التطبيقات الرائعة لها مظهرها الخاص وشعورها. لا يحتاجون إلى ضوابط منصة الأسهم. انظر إلى Spotify أو Netflix أو غيرها من التطبيقات الناجحة الرائعة المتاحة لأنظمة أساسية متعددة. لا يمكنك إخبار النظام الأساسي الذي يستخدمونه ، بمجرد النظر إلى عناصر التحكم الخاصة بهم.

أرغب في أن تبدو تطبيقاتي عبر الأنظمة الأساسية كما هي تمامًا على جميع الأنظمة الأساسية.

MarkIngramUK سعيد لأنك تلمس الواقع بما يتجاوز النظرية. إليكم الحقيقة بالنسبة لي: لدي مجموعة من التطبيقات التي تطورت من SL / WP> WinRT> UWP التي كانت بحاجة لاستهداف منصات متعددة بالأمس. نظرت إلى Phonegap / Cordova ، وقضيت الكثير من الوقت في استكشاف Xamarin بجدية بالغة ، واستسلمت في النهاية. لقد وقعت في حب Uno لعدة أسباب بمجرد أن بدأت في استخدامه. في هذه اللحظة ، لا أعرف أي تقنية أخرى واعدة لمنصة X عملية صديقة لـ C # و Xaml والتي يمكنني استخدامها الآن . عندما يتطور WinUI إلى X-platform API 1 أو 2 أو 3 سنوات بعد ذلك ، فإن مستخدمي Uno من الدرجة الأولى سوف يهاجرون Uno من UWP إلى WinUI ، وستكون جميع تطبيقاتي المستندة إلى Uno قادرة على الترحيل وفقًا لذلك وبسرعة. ليس لدي ما يدعو للقلق الآن.
بأي حال من الأحوال ، أنا ضد فضول المناقشات النظرية هنا. أحب سماع كل أنواع الأفكار.

لا يمكن لـ WinUI / MS الاستفادة من مشروع Blazor لتقديم WinUI كتطبيق "Blazor Native"؟

أعلم أن ستيف ساندرسون قدّم Blutter حيث يمكن عرض Flutter من Google باستخدام Blazor (وهي واجهة مستخدم تعتمد على XML). يبدو أن فريق Blazor لديه بعض التقنيات الرائعة في جانب عرض واجهة المستخدم للاستفادة من أطر واجهة المستخدم المختلفة. إذا كان بإمكان Blazor التعامل مع Flutter ، فيجب أن يكون قادرًا على التعامل مع مكافئ من نوع WinUI / Sillverlight.

الإمكانات هي نظام بيئي MS أقل تجزئة وأكثر قوة ، بدءًا من الويب وانتهاءً بالتطبيقات المحلية x-platform باستخدام .net 5 موحد.

lukasf :

MarkIngramUK أرى الأمر على هذا النحو: تلتزم التطبيقات البسيطة بعناصر تحكم واجهة المستخدم الخاصة بالمنصة. التطبيقات الرائعة لها مظهرها الخاص وشعورها. لا يحتاجون إلى ضوابط منصة الأسهم. انظر إلى Spotify أو Netflix أو غيرها من التطبيقات الناجحة الرائعة المتاحة لأنظمة أساسية متعددة. لا يمكنك إخبار النظام الأساسي الذي يستخدمونه ، بمجرد النظر إلى عناصر التحكم الخاصة بهم.

أرغب في أن تبدو تطبيقاتي عبر الأنظمة الأساسية كما هي تمامًا على جميع الأنظمة الأساسية.

نحن نجمع بين كلا الأسلوبين لتطبيقاتنا (https://affinity.serif.com). يمكن أن يكون عملاؤنا صريحين تمامًا إذا لم نتبنى معايير النظام الأساسي المشتركة ، مثل طلب الأزرار الموجودة في مربعات الحوار (Windows عادة ما يكون جيدًا ثم إلغاء ، بينما macOS هو إلغاء ثم موافق) ، والأزرار ذات الزوايا الدائرية ، وحالات التمرير ، ومربعات الاختيار مقابل المفاتيح ، والتخطيط من عناصر التحكم وما إلى ذلك ، لذا ، نعم ، على السطح ، تبدو تطبيقاتنا متشابهة على أنظمة Windows و macOS ، ولكن لدينا اختلافات دقيقة (العرض وتفاعل واجهة المستخدم). نحن أيضًا نستفيد استفادة كاملة من النظام الأساسي المضيف لدينا من خلال استخدام واجهات برمجة التطبيقات الأصلية الخاصة بهم ، وبالتالي فإننا لا نتعرض أبدًا لمشاكل القاسم المشترك الأقل.

ما زلت أعتقد أن المناقشة أعلاه مضللة ، WinUI هو أدنى مستوى من إطار عمل واجهة المستخدم الذي توفره Microsoft. إذا كنت تريد مكتبة عبر الأنظمة الأساسية ، فابدأ فوق ذلك. إنه يعادل القول ، "يجب أن يكون Win32 عبر الأنظمة الأساسية!". لا ، يجب أن يكون Win32 أفضل إطار عمل لمنصة Windows. إنها نفس الحجة هنا ، يجب أن يكون WinUI أفضل إطار عمل لمنصة Windows 10.

MarkIngramUK كتب:

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

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

1. Microsoft WinUI: ليس عبر الأنظمة الأساسية.
2. Microsoft CrossXYZ-UI: عبر الأنظمة الأساسية. ستتم كتابة تطبيقه الداخلي لنظام التشغيل Windows باستخدام WinUI.

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

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

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

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

لا أعرف ما إذا كان Xamarin يحاول بالفعل العمل بالطريقة المكونة من طبقتين الموصوفة أعلاه ، ولكن إذا حدث ذلك ، فأنا أتخيل أنه يستبعد حاليًا جزء الفكرة حيث يدعم WinUI / يساعد طبقة النظام الأساسي المنفصلة. من الصعب الوثوق بـ Xamarin عندما لا تثق Microsoft في Xamarin بما يكفي لاستخدامه مع Microsoft Teams والعديد من تطبيقات Microsoft الأخرى.

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

بصفتك مطور تطبيقات ، لمجرد أنك _يمكنك_ نظريًا إنتاج تطبيق عبر الأنظمة الأساسية ، فهذا لا يعني دائمًا أنك _يجب_. ومن المثير للاهتمام ، أنني لاحظت في المناقشات عبر الأنظمة الأساسية في الوقت الحاضر أن الناس يذكرون Android وليس Linux بعد الآن. ربما يكون أحد أكبر أسباب هذا التحول هو مشكلة 0 دولار المذكورة أعلاه.

منصة Re Uno:

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

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

أنا أتفق أيضًا مع تعليقmdtauk :

تكمن مشكلة هذه الحجة في أن العقد الماضي أظهر تخلي Microsoft عن الأنظمة الأساسية ،

نعم ، فقدت Microsoft درجة معينة من السمعة / الجدارة بالثقة / الموثوقية من خلال إلغاء الأنظمة الأساسية. أعتقد أن Microsoft بحاجة إلى توخي الحذر لتجنب المزيد من فقدان السمعة والجدارة بالثقة من خلال عمليات الإلغاء الإضافية. الإصدار الجديد من النظام الأساسي الحالي أفضل من النظام الأساسي الجديد.

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

إذا وجدت يا رفاق أن هذا النهج المكون من طبقتين جذاب للغاية ، فيمكنك المتابعة الآن واستخدام Xamarin أو Uno. ليس عليك انتظار مثل هذه الأطر ، فهي موجودة بالفعل وتعمل بشكل جيد للغاية. لكنك ستفقد جميع الفوائد والتحسينات من WinUI بمجرد استهداف Android أو iOS. لا مزيد من NavigationView ، لا AppBars ، لا مزيد من SemanticZoom ، إلخ. أي شيء يتم القيام به في هذا الريبو ، جميع التحسينات ليست متاحة عبر الأنظمة الأساسية ، لأن النظام الأساسي المشترك يعني بالتالي أقل قاسم مشترك. لا يمكنك استخدامها إلا إذا كنت تستهدف نظام Windows الأساسي على وجه التحديد. لذلك سيتعين عليك إعادة تنفيذ جميع عناصر WinUI الرائعة مرة أخرى يدويًا ، باستخدام عناصر تحكم Android أو iOS الأصلية.

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

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

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

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

كل مهندس وكل دولار يتم إنفاقه على WinUI cross-plat هو مهندس ودولار كان من الممكن استخدامه لتحسين WinUI على Windows.

الحجة القائلة بأن الإصدارات ستتأخر لأن "العارض لمنصة أخرى لم يتم تحديثه" هي حجة غير واقعية.

إنها ليست مجرد مهمة بسيطة لإنشاء محرك عرض 1: 1 مثالي يعمل على iOS و Android و MacOS و Linux و Windows 7/8. هناك عدد هائل من واجهات برمجة تطبيقات Windows 10 التي تعتمد عليها التطبيقات والإطار. من المفترض أن تقوم بشكل أساسي بإنشاء إطار عمل جديد تمامًا للتطبيق.

انظر أيضًا إلى موضوع Reddit الأخير هذا: ما الذي يجب أن أستخدمه لواجهة المستخدم في C #

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

lukasf ،

يمكنك الآن استخدام Xamarin أو Uno

لقد أشرت إليها في رسالتي السابقة ، لكننا نكتب واجهات أمامية منفصلة لكل منصة نستهدفها. Windows (WPF) و macOS (Cocoa) و iOS (UIKit).

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

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

تعمل طبقة التقديم على أوامر رسم منخفضة المستوى مثل ...

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

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

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

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

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

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

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

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

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

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

لا يمكن لـ WinUI / MS الاستفادة من مشروع Blazor لتقديم WinUI كتطبيق "Blazor Native"؟

pinox ، نعم يمكننا بالتأكيد ، ولكن بعد ذلك لن يكون Blazor Native متعدد الأنظمة الأساسية ، ما لم يستهدفوا Uno (والذي سيكون تفضيلي الشخصي).

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

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

هناك مجموعة فرعية من XAML لتقديم عناصر تحكم ونوافذ واجهة مستخدم أصلية المظهر - أو يمكنك امتلاك العارض على macOS و iOS و Android و Linux - وتقديم نفس عناصر التحكم والقوالب "Fluent" على جميع الأنظمة الأساسية.

بصرف النظر عن إجراء نوع من المتغير لتطبيق CoreWindow / App Window للعمل مع نظام التشغيل الأصلي - يمكن عرض كل شيء داخل النافذة.

على نظام التشغيل Windows ، يوجد DirectX ، لكن Apple لديها Metal ، و Linux لديها OpenGL. سيتعين على المطورين إجراء نوع من عبارات IF للتعامل مع IO للملف الأصلي ، والإشعارات ، وما إلى ذلك - ولكن Xamarin سيساعد في ذلك

stevenbrix - أراك ترد على فكرة Pinox _ "تقديم WinUI كتطبيق Blazor Native" ، _ ولكن ما رأيك في فكرة Pinox _other_؟ ومن المثير للاهتمام أن Pinox كتب أيضًا:

تستخدم Electron حاليًا جافا سكريبت و HTML + CSS. لا يوجد سبب يمنعنا من استخدام Electron مع Blazor => C # و HTML + CSS + gRPC.

Pinox - أوافق على أن "Electron C #" يبدو أكثر منطقية من "Electron JS" ، ولكن إذا كان يستخدم C # و Blazor كما اقترحت ، فأعتقد أن تطبيق MS Teams ربما لن يحتاج إلى Electron بعد الآن لأن Blazor سيحل محل الإلكترون بالكامل؟ قد أكون مخطئًا - لا أعرف ما يكفي عن الميزات التي يدعمها Electron. على الرغم من أنه إذا كان لدى ElectronJS حاليًا أي ميزة مفيدة يفتقر إليها Blazor ، فمن المحتمل أن تكون هذه الميزة المفقودة مدعومة في الإصدار التالي من Blazor.

لذا أعتقد أنك أثرت نقطة مهمة بذكر Blazor. قد يكون الحل المناسب لتطبيق MS Teams هو التبديل من ElectronJS إلى Blazor + WebAssembly. هذا مثير للاهتمام حقًا.

إذا تحول تطبيق MS Teams من ElectronJS إلى Blazor ، فقد يستخدم أو لا يستخدم أي جزء من WinUI. يمكن استكشاف اتصال أو عدم اتصال بين Blazor و WinUI بشكل أكبر ، كما بدأت بالفعل. مثير للاهتمام!

تم التخلي عن كل من Silverlight و WinRT و UWP. (أعلم أن UWP ليس تقنيًا ، ولكن من المرجح أن يُنظر إلى WinUI على أنه بديل).

ما أفهمه هو أن UWP هو وقت التشغيل ، في حين أن WinUI هي طبقة واجهة المستخدم الرسومية / عنصر واجهة المستخدم / إلخ. أي أن Win UI ستعمل على Win32 ، أو .NET ، بدون UWP API.

الشيء الذي يدفعني إلى الجنون هو أن UWP هي في الواقع واجهة برمجة تطبيقات مختصة جدًا. إنه ليس قويًا مثل Win32 ، ولكن بالمقارنة مع Android (على سبيل المثال) فهو أكثر صحة. أعتقد أن المطورين قد فاتتهم النقطة التي مفادها أن هناك الآن واجهة برمجة تطبيقات موحدة لوقت التشغيل ، والتي تحتوي على نموذج كائن ثابت ، واجهة برمجة تطبيقات ، ليست منفرجة ، وما إلى ذلك ... هل قام أي شخص آخر هنا بكتابة تطبيقات Win32 مرة أخرى في التسعينيات أو في وقت مبكر 00s قبل ظهور .NET على الساحة؟ كان استخدام واجهات برمجة التطبيقات للنظام الأساسي الأصلي أمرًا فظيعًا.

بالعودة إلى المشكلة المطروحة ، أرغب بالتأكيد في رؤية منصة WinUI عبر النظام الأساسي. هناك منشورات حول ارتباطه بـ COM وما إلى ذلك ... إطار عمل المكون الإضافي Core Foundation من Apple (CFPlugin) هو IIRC ، بناءً على COM ، لذلك ربما يكون الرفع والتحويل بسيطًا مثل كتابة عارض لمنصات Apple. الشيء الأكثر منطقية هو مواجهة اختلافات النظام الأساسي والحفاظ على كائنات WinUI عالية المستوى.

أود أن أرى جهدًا متماسكًا عبر الأنظمة الأساسية من Microsoft ، والذي استهدف Windows بشكل أساسي ، ولكنه اشترى نموذج كائن متوافق تمامًا ولهجة XAML للهاتف المحمول و Linux و macOS. يوجد بالفعل نظام بيئي رائع متعدد المنصات (باستثناء واجهة المستخدم الرسومية) في .NET Core. بولت في إطار عمل XAML كفء ولن يكون هناك تفكير لجميع تطوير جانب العميل ، خاصة إذا كانت المرئيات تبدو أصلية. على سبيل المثال CommandBar -> ظهور NSToolbar على نظام Mac ، وطريقة عرض التنقل -> NSOutlineView على جهاز Mac ، إلخ.

قيمتي البالغة 2c ، لكني أرى تركيزًا كبيرًا على هذا.

آمل أيضًا (على الرغم من أنني لن أحبس أنفاسي) أن Microsoft ستعيد دخول السوق باستخدام هاتف يعمل بنظام Windows. أن تكون بيئة منصة مشتركة قوية من شأنه أن يساعد بشكل كبير في تحقيق هذا الهدف.

سأشاهد هذا النقاش باهتمام.

تم التخلي عن كل من Silverlight و WinRT و UWP. (أعلم أن UWP ليس تقنيًا ، ولكن من المرجح أن يُنظر إلى WinUI على أنه بديل).

ما أفهمه هو أن UWP هو وقت التشغيل ، في حين أن WinUI هي طبقة واجهة المستخدم الرسومية / عنصر واجهة المستخدم / إلخ. أي أن Win UI ستعمل على Win32 ، أو .NET ، بدون UWP API.

من الناحية الفنية ، أعتقد أن WinRT (Windows RunTime) هو وقت التشغيل ، وأن UWP (النظام الأساسي العالمي لنظام Windows) مبني على قمة وقت التشغيل هذا. ويدعم UWP استخدام XAML كإطار عمل واحد لواجهة المستخدم.

سيكون WinUI هو جزء XAML من UWP ، ولكن تم توسيعه لتمكين استخدامه مع رمز Win32 ، مع إمكانية التشغيل المتداخل من خلال XAML Islands مع إطار عمل WPF و WinForms.

الشيء الذي يدفعني إلى الجنون هو أن UWP هي في الواقع واجهة برمجة تطبيقات مختصة جدًا. إنه ليس قويًا مثل Win32 ، ولكن بالمقارنة مع Android (على سبيل المثال) فهو أكثر صحة. أعتقد أن المطورين قد فاتتهم النقطة التي مفادها أن هناك الآن واجهة برمجة تطبيقات موحدة لوقت التشغيل ، والتي تحتوي على نموذج كائن ثابت ، واجهة برمجة تطبيقات ، ليست منفرجة ، وما إلى ذلك ... هل قام أي شخص آخر هنا بكتابة تطبيقات Win32 مرة أخرى في التسعينيات أو في وقت مبكر 00s قبل ظهور .NET على الساحة؟ كان استخدام واجهات برمجة التطبيقات للنظام الأساسي الأصلي أمرًا فظيعًا.

تم تصميم UWP بنهج حديث لعمر البطارية والأمان والهوية والتحقق من المتجر - كل الأشياء التي يتوقعها المطورون من منصات مثل macOS و iOS و Android. وبسبب تلك الصفات المتأصلة ، يمكن أن تعمل عبر العديد من عوامل الشكل وأنواع الأجهزة.

بالعودة إلى المشكلة المطروحة ، أرغب بالتأكيد في رؤية منصة WinUI عبر النظام الأساسي. هناك منشورات حول ارتباطه بـ COM وما إلى ذلك ... إطار عمل المكون الإضافي Core Foundation من Apple (CFPlugin) هو IIRC ، بناءً على COM ، لذلك ربما يكون الرفع والتحويل بسيطًا مثل كتابة عارض لمنصات Apple. الشيء الأكثر منطقية هو مواجهة اختلافات النظام الأساسي والحفاظ على كائنات WinUI عالية المستوى.

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

أود أن أرى جهدًا متماسكًا عبر الأنظمة الأساسية من Microsoft ، والذي استهدف Windows بشكل أساسي ، ولكنه اشترى نموذج كائن متوافق تمامًا ولهجة XAML للهاتف المحمول و Linux و macOS. يوجد بالفعل نظام بيئي رائع متعدد المنصات (باستثناء واجهة المستخدم الرسومية) في .NET Core. بولت في إطار عمل XAML كفء ولن يكون هناك تفكير لجميع تطوير جانب العميل ، خاصة إذا كانت المرئيات تبدو أصلية. على سبيل المثال CommandBar -> ظهور NSToolbar على نظام Mac ، وطريقة عرض التنقل -> NSOutlineView على جهاز Mac ، إلخ.

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

قيمتي البالغة 2c ، لكني أرى تركيزًا كبيرًا على هذا.

آمل أيضًا (على الرغم من أنني لن أحبس أنفاسي) أن Microsoft ستعيد دخول السوق باستخدام هاتف يعمل بنظام Windows. أن تكون بيئة منصة مشتركة قوية من شأنه أن يساعد بشكل كبير في تحقيق هذا الهدف.

سأشاهد هذا النقاش باهتمام.

أعتقد أن جزءًا واحدًا من هذه القصة ، لم يتم تفصيله بعد ، هو تمكين تطبيقات UWP من التجميع والتشغيل على Android - مما سيحل مشكلة التطبيقات التي تعمل على Surface Duo.

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

أرى أنك ردت على فكرة Pinox "تقديم WinUI كتطبيق Blazor Native" ، ولكن ما رأيك في فكرة Pinox الأخرى؟ ومن المثير للاهتمام أن Pinox كتب أيضًا:

تستخدم Electron حاليًا جافا سكريبت و HTML + CSS. لا يوجد سبب يمنعنا من استخدام Electron مع Blazor => C # و HTML + CSS + gRPC.

أوافق على أن "Electron C #" يبدو أكثر منطقية من "Electron JS" ، ولكن إذا كان يستخدم C # و Blazor كما اقترحت ، فأعتقد أن تطبيق MS Teams ربما لن يحتاج إلى Electron بعد الآن لأن Blazor تحل محل الإلكترون بالكامل؟ قد أكون مخطئًا - لا أعرف ما يكفي عن الميزات التي يدعمها Electron. على الرغم من أنه إذا كان لدى ElectronJS حاليًا أي ميزة مفيدة يفتقر إليها Blazor ، فمن المحتمل أن تكون هذه الميزة المفقودة مدعومة في الإصدار التالي من Blazor.

verelpode كما أفهمها ، سيحتاج Electron دائمًا إلى أن يكون في الصورة. إذا كانت Teams ستنتقل افتراضيًا إلى Blazor ، فسيظلون يريدون تطبيق عميل مستقل كما يفعلون اليوم ، وسيكون Electron أكثر منطقية بالنسبة لهم. من الناحية النظرية ، يمكن لأي شخص أن يصححني إذا كنت مخطئًا ، لكن التبديل إلى Blazor + WebAssembly من شأنه أن يجعل أداء التطبيق أفضل بكثير عند التشغيل في Electron. على الرغم من أنني أراهن على أن مشكلات الأداء لديهم ناتجة عن مشكلات معمارية أكثر من أي شيء آخر ، فإن VS Code هو تطبيق Electron وأنا معجب جدًا بالأداء هناك.

ضع في اعتبارك أن WebAssembly قد يعمل أيضًا خارج WebBrowser ...
أرى Blazor كوسيلة من أولئك القادمين من ASP.Net ، وهي تجربة تجلب .NET إلى WebBrowser ، ولكن المسار الأكثر اكتمالا سيكون XAML على .NET Core و Xamarin و UWP / WinUI و UNO ؛ يمكن أيضًا تشغيل XAML الكامل على WinUI / Windows 10 وجزء من XAML على الويب.

ما أفهمه هو أن Blazor يعمل على السلك في Electron. لذلك مباشرة من. net core إلى Electron باستخدام gRPC. لذلك تتواصل قناة gRPC مع الإلكترون ولم تعد عارض JS الذي أفترضه. الرجاء تصحيح لي إذا كنت مخطئا. لا يوجد WASM متضمن.

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

في مقطع ستيف ساندرسون على youtube ، ذكر استخدام no WASM (53:13 min في الفيديو)
https://www.youtube.com/watch؟v=uW-Kk7Qpv5U

لا أستطيع أن أتذكر أين قرأت جزء gRPC ، على أي حال ، لذلك سأقوم باستكشاف المجتمع إذا كان شيء مثل Silverlight مكافئ لـ WinUI باستخدام gRPC مع Electron ممكن؟ لا WASM ، على السلك إذا جاز التعبير.

ما أفهمه هو أن Blazor يعمل على السلك في Electron. لذلك مباشرة من. net core إلى Electron باستخدام gRPC. لذلك تتواصل قناة gRPC مع الإلكترون ولم تعد عارض JS الذي أفترضه. الرجاء تصحيح لي إذا كنت مخطئا. لا يوجد WASM متضمن.

سيكون من الممتع حقًا رؤية تحسينات السرعة باستخدام gRPC مباشرة مع Electron. في رأيي يمكن أن تكون ضخمة.

في مقطع ستيف ساندرسون على youtube ، ذكر استخدام no WASM (53:13 min) في الفيديو.
https://www.youtube.com/watch؟v=uW-Kk7Qpv5U

شكراPinox! يبدو أن لدي بعض المشاهدة لأفعله! ما تصفه يبدو لي مثل Blazor من جانب الخادم ، كنت أفكر / أتحدث عن جانب العميل الذي يتم تشغيله في المتصفح ويتعامل بشكل مباشر مع DOM. لن أقول بعد الآن إلا بعد أن أشاهد هذا الفيديو ، لأنني أستطيع أن أضع قدمي في فمي بقول مثل هذه الأشياء 😄

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

أعتقد أنه إذا استخدم عارض JS gRPC للتحدث إلى Electron ، فيمكنك استخدام محرك Blazor razor للقيام بنفس الشيء.

gRPC هي ميزة جديدة في .net core 3.0. دعم Blazor .net core 3.
لذلك فإن gRPC في .net core 3 يفتح إمكانية استبدال تقنيات JS الخارجة بـ c # باستخدام "الارتباط المشترك" (gRPC). ذكي التحرك MS؛))

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

Pinox - نعم هذا حيرة لي بعض الشيء. أظن أنه يستخدم https://github.com/ElectronNET/Electron.NET ، لكن هذا تخمين بحت

إذا تحول تطبيق MS Teams من ElectronJS إلى Blazor ، فقد يستخدم أو لا يستخدم أي جزء من WinUI. يمكن استكشاف اتصال أو عدم اتصال بين Blazor و WinUI بشكل أكبر ، كما بدأت بالفعل. مثير للاهتمام! >

verelpode ما يجعل هذه الصورة مثيرة للغاية هو "مدى الوصول" لبلازور. بصفتي أحد مستخدمي التطبيقات ، يمكنني أن أقول إن تجربتي المحدودة مع Blazor حتى الآن هي => واو ، هذا شعور رائع للغاية ، يشبه التطبيق تقريبًا. بالنظر إلى الصورة ، من شبه المؤكد أن تتضمن خارطة الطريق WinUI كمنصة أصلية. (على الرغم من عدم الالتزام حاليًا)

إذا تمكنوا من جعل الرفرفة تعمل على جانب Blazor Native ، فإن ذلك يمنع فريق Blazor من توصيل النظام الأساسي React Native للوصول إلى كل تلك المنصات الأصلية. يمكن أن يصبح Blazor بسهولة شديدة الغراء لمطوري C # في كل شيء.

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

بالنسبة لي ، دائمًا ما يكون المطلق فائق الأداء. net core (C #) => Blazor ؟؟؟ => واجهة المستخدم الأصلية - سيكون الجهد الهندسي النهائي.

يجب أن أقول إن هذه مناقشة ملهمة للغاية! الكثير من الآراء والحجج المختلفة ، الكثير من الحقائق التي لم أكن أعرفها حتى ("Blazor + Native UI ؟؟ Wow").

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

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

أود أن أقول ، مع وجود Surface Duo و Neo في الأفق ، يجب على Microsoft التوصل إلى قصة مناسبة حول كيفية تطوير التطبيقات عبر الأنظمة الأساسية التي تعمل على كل من Surface Duo و Surface Neo. ربما يتعين على Microsoft شراء Uno وتمويلها بشكل صحيح ، حتى يتمكنوا من إصلاح كل تلك المشكلات المفتوحة وإضافة المزيد من دعم التحكم. أو قم بتطوير طبقة عرض Android لـ WinUI. مع الأجهزة المخطط لها في عطلة 2020 ، يجب أن تبدأ الأمور في التحرك قريبًا.

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

بوجود قوة بشرية كافية ، يمكن التغلب على مشكلة "القاسم المشترك الأدنى"

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

كل مهندس وكل دولار يتم إنفاقه على WinUI cross-plat هو مهندس ودولار كان من الممكن استخدامه لتحسين WinUI على Windows.

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

ماذا لو كان الموضوع متعدد المنصات يعني أننا جميعًا مضطرون للاختيار بين إحدى النتائج التالية؟

1. إصدار ممتاز من WinUI يعمل فقط على Windows ؛ أو
2. WinUI متوسطة الجودة و / أو غير موثوقة و / أو بطيئة تعمل على كل منصة ، وتعاني من وتيرة تطوير بطيئة للغاية مع بقاء العديد من المشكلات العالقة غير ثابتة لمدة 5 إلى 10 سنوات.

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

ماذا لو كان الموضوع متعدد المنصات يعني أننا جميعًا مضطرون للاختيار بين إحدى النتائج التالية؟

1. إصدار ممتاز من WinUI يعمل فقط على Windows ؛ أو

2. WinUI متوسطة الجودة و / أو غير موثوقة و / أو بطيئة تعمل على كل منصة ، وتعاني من وتيرة تطوير بطيئة للغاية مع بقاء العديد من المشكلات العالقة غير ثابتة لمدة 5 إلى 10 سنوات.

verelpode أولاً ، أنت تبالغ كثيرًا هنا. ثانيًا: تمتلك Microsoft موارد هائلة في متناول اليد. لا ينبغي أن يكون تمويل كل من تحسينات WinUI الأصلية والحل عبر الأنظمة الأساسية مشكلة على الإطلاق ، إذا كانت Microsoft مهتمة حقًا بتوفير إطار عمل عبر الأنظمة الأساسية. في الواقع إنهم يفعلون ذلك الآن: إنهم يطورون ويحسنون WinUI ، وفي نفس الوقت يطورون ويحسنون Xamarin. لديهم الكثير من المشاريع الجارية في نفس الوقت. لذلك ، إذا كانت Microsoft ملتزمة حقًا بتوفير إطار عمل رائع لواجهة مستخدم Windows (وهو بالتأكيد موجود) وتوفير إطار عمل عبر الأنظمة الأساسية (والذي سيكون له معنى كبير مع Surface Neo و Duo في الأفق) ، فليس لدينا لإختيار. كلاهما يمكن أن يتحقق دون حل وسط. (وبشكل عام ، ليس الأمر كما لو أن هذا شيء يمكننا اختياره. ستتخذ Microsoft قراراتها وسنرى ماهية النتيجة.)

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

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

مايكروسوفت لديها موارد هائلة في متناول اليد.

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

مايكروسوفت لديها موارد هائلة في متناول اليد.

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

ثم قد تكون المشكلة هي مديري المشاريع والهيكل التنظيمي ؛)

ربما يتعين على Microsoft شراء Uno وتمويلها بشكل صحيح ، حتى يتمكنوا من إصلاح كل تلك المشكلات المفتوحة وإضافة المزيد من دعم التحكم.

أعلم أن nventive كان يغازل Microsoft على مدار الأشهر العديدة الماضية (ربما يكون الاستحواذ على Microsoft هو استراتيجية الخروج الخاصة بهم). في مؤتمر أونو كان هناك أيضا مشاركة كبيرة من مايكروسوفت. حتى Xamarin يستخدم Uno الآن لدعم الويب.

أعلم أنه يمكننا مناقشة الخيارات (1) العروض الأصلية أو (2) تطبيق / طبقة أخرى لواجهة المستخدم إلى ما لا نهاية ، ولكن بالنظر إلى ما هو متاح الآن وما نحتاجه لـ Surface Duo ، فإن Uno هو في الواقع الحل الوحيد المنطقي. كما قال lukasf ، يجب على Microsoft التخلص من مواردها وراءها ومعرفة المدى الذي يمكن أن تصل إليه في عام واحد. إذا نجحت (الميزة كاملة ومستقرة) ، فلا أعتقد أن المطورين سيهتمون كثيرًا بكيفية تنفيذها وراء الكواليس. إذا أصبح من الواضح أن النهج الصحيح هو WinUI معروض أصلاً لكل نظام أساسي يمكن أن يكون مناقشة لبضع سنوات على الطريق. في الوقت الحالي ، من الأفضل أن تبدأ بمنصة Uno كاملة بنسبة 25٪ بدلاً من لا شيء على الإطلاق.

stevenbrix هنا :

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

يا رفاق مخطئون.
لا يتبع Uno شعار "القاسم المشترك الأدنى" الخاص بـ Xamarin ، ولكن العكس ، فهو يحاول التأكد من أن جميع عناصر تحكم XAML (وحتى Windows Community Toolkit!) تعمل على جميع الأنظمة الأساسية.

لا يتبع Uno شعار "القاسم المشترك الأدنى" الخاص بـ Xamarin ، ولكن العكس ، فهو يحاول التأكد من أن جميع عناصر تحكم XAML (وحتى Windows Community Toolkit!) تعمل على جميع الأنظمة الأساسية.

weitzhandler أنت على حق تماما! أعتقد أن تصميمهم سيصلح ليوم ما تكافؤ كامل مع مجموعة التحكم WinUI ، والتي قد لا تكون ممكنة مع Xamarin.Forms. إذا فهمت بشكل صحيح ، فإن مجموعة التحكم هذه لم يتم إنشاؤها بعد ، وهو ما أشير إليه أنا و lukasf . قد أكون مخطئًا رغم ذلك ، فأنا لم ألعب بما يكفي لأعرف ، أنا فقط أثق بما سمعته من أي شخص آخر :)

إن نهج weitzhandler Uno لإعادة تنفيذ واجهات برمجة تطبيقات UWP / WinUI الحقيقية أفضل بكثير من اختراع Xamarin لهجة XAML جديدة. ولكن إذا قمت بتشغيل معرض عناصر تحكم Uno Xaml ، فستجد بعض المناطق فارغة. مجموعة التحكم الخاصة بهم أفضل بالتأكيد من Xamarin.Forms ، لكنها ليست تقريبًا UWP / WinUI كاملة حتى الآن. أعتقد أن Uno يحتاج إلى مزيد من العمل على سطح واجهة برمجة التطبيقات ، وكذلك المزيد من العمل للحصول على عناصر التحكم المتاحة مستقرة بالفعل وكاملة الميزات.

كان بإمكاني رؤية Uno كخيار vialble. لكنها تحتاج إلى بعض التقدم الحقيقي ، وهو المكان الذي يمكن أن تلعبه Microsoft فيه.

في نقطة أخرى ، أوافق تمامًا على ما قاله lukasf هنا :

التطبيقات الرائعة لها مظهرها الخاص وشعورها. لا يحتاجون إلى ضوابط منصة الأسهم. انظر إلى Spotify ، Netflix

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

تعد عناصر التحكم عبر الأنظمة الأساسية مستقلة فعليًا عن أطر العمل عبر الأنظمة الأساسية.

الفرضية: في المستقبل ، لن تقتصر ضوابط الشبكة على منصات معينة.

توجد أطر عمل عبر الأنظمة الأساسية الحالية لـ .Net UI (Xamarin.Forms ، Avalonia). سيكون هناك أيضًا FutureXplatDotNetUI الذي يحلم به الجميع ولا يمكن لأحد تحديده تمامًا.

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

في كلتا الحالتين ، يمكن تثبيت عنصر التحكم الخاص بك في أي مشروع .Net UI.

Corollory: سيحتاج FutureXplatDotNetUI فقط مجموعة قليلة من عناصر التحكم

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

(هذا المنشور عبارة عن تعليق على .Net UI عبر الأنظمة الأساسية وبالتالي فهو غير مرتبط بـ WinUI.)

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

@ rel-msft
أشعر أن فريق WinUI قد تخلى بالفعل عن توقع قيام الأشخاص بكتابة تطبيقات Windows أصلية جديدة ، وأن WinUI مصمم لترقية التطبيقات الحالية

قادمة من شخص يعمل في Microsoft وهذا غريب نوعًا ما.

أشعر أن فريق WinUI قد تخلى بالفعل عن توقع قيام الأشخاص بكتابة تطبيقات Windows أصلية جديدة ، وأن WinUI مصمم لترقية التطبيقات الحالية

قادمة من شخص يعمل في Microsoft وهذا غريب نوعًا ما.

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

كنت تتحدث عما يعتقده فريق WinUI.

بصفتك مرض التصلب العصبي المتعدد بشكل عام ، فإن هذا الأمر يبدو منطقيًا للأسف.
أتمنى أن تمنح Microsoft WinUI الحب React أو Electron أو أي تقنية HTML CSS و JS أخرى تحصل عليها (اقرأ تعليقي أعلاه ).

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

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

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

إضافة إلى ذلك ، فأنا لست متأكدًا حقًا مما إذا كانت .NET هي التقنية الصحيحة لبناء حزمة واجهة مستخدم. جربته Microsoft مع WPF ثم استسلمت أخيرًا وتحولت إلى C ++. إن وجود فواصل GC أثناء التخطيط والعرض لا يعطي أفضل انطباع للمستخدمين النهائيين ، في الأوقات التي تصبح فيها الرسوم المتحركة أكثر أهمية. ربما لم يعد هذا صحيحًا بعد الآن إذا كان Compositor متاحًا ، والذي يعتني بالرسوم المتحركة السلسة بشكل مستقل تمامًا عن مؤشر ترابط واجهة المستخدم. ثم يمكن أن يكون مكدس التحكم هو C # ويكون الجزء المتحرك والعرض الأدنى للمستوى هو الكود الأصلي فقط. ولكن في ذلك الوقت ، كان الأداء هو السبب الرئيسي وراء التخلي عن C # تمامًا في أطر XAML UI التالية (Silverlight و UWP / WinUI).

lukasf لا يمكن لأي عنصر تحكم العمل في أطر متعددة

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

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

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

يمكن تثبيته فقط في تلك التطبيقات التي يتم دعم إطار عملها بشكل صريح بواسطة عنصر التحكم.

هذا صحيح ولكن دعم المزيد من المنصات أصبح أمرًا سهلاً.

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

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

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

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

إذا كنت تريد أن يعمل ربط البيانات في WPF أو WinUI ، فعليك إعلان DependencyProperties. أشك بشدة في أن أي شخص قد يستخدم عنصر تحكم XAML لا يعمل مع ربط البيانات. ربط البيانات هو في صميم هذه الأطر ، ويتطلب DependencyProperties للعمل ، إذا كنت ترغب في ذلك أم لا. إذا لم تقم بإضافتها ، فلا يمكنك استخدام عنصر التحكم الخاص بك في أي من أطر عمل النظام الأساسي الحالية لـ Windows.

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

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

لا يمكنك استخدام عنصر التحكم الخاص بك في أي من أطر عمل النظام الأساسي الحالية لـ Windows

هذا ليس صحيحا. يمكن استخدام عنصر تحكم لا يقوم بتطبيق DependencyProperties في WPF / WinUI. يعد هذا أحد عيوب ربط بيانات .Net التقليدي: فهو يشجع على إضافة خصائص تبعية زائفة إلى عناصر التحكم التي تحدد الخصائص القابلة للتعيين بالفعل. ازدواجية ضخمة في التعليمات البرمجية. (بالمناسبة ، لن يكون عنصر التحكم عبر الأنظمة الأساسية "عنصر تحكم XAML" ولا يجب أن يتم استغراقك من خلال إساءة استخدام "XAML" بلغة التسويق الخاصة بـ WinUI. Xaml هي لغة ترميز اختيارية يمكن استخدامها مع العديد من .Net UI framework.)

الضوابط الفرعية للتحكم في المستوى الأعلى

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

والخبر السار هو أن مايكروسوفت قررت بالفعل قتل .net الأصلي.

robloo سأقيم حفلًا للاحتفال به عندما يحدث هذا.

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

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

1. Nventive تغلق أعمالها. تعتمد Nventive على Uno في أعمالها المتعلقة بالخبز والزبدة.
2. الأشخاص الأساسيون وراء Uno يفقدون اهتمامهم بهذا المشروع الرائع.

بالنسبة إلى رقم 1 ، فقد سمعت أن Nventive تقوم بتطوير مبنىها الحالي والانتقال إلى منشأة أكبر ، لذا فإن Uno Conf 2020 الموسعة (من يومين إلى 3 أيام) سيكون لها جزء مقام في مبنى مختلف. أنا لست خبيرًا اقتصاديًا ، لذا لا يمكنني التنبؤ بما إذا كان هناك ركود حاد يدفع بالعديد من الشركات إلى التراجع عن أعمالها. على الأقل لا أرى انهيارًا اقتصاديًا في المستقبل القريب في الوقت الحالي (كان معدل البطالة في منطقتنا أقل من 2٪ لفترة من الوقت).

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

استنادًا إلى تجربتي الواسعة مع Sliverlight و Windows Phone 7 / 7.1 / 8 / 8.1 SDKs ، Windows 8 / 8.1 / 10 (WinRT ، UWP ...) (كان هاتفي الأساسي هو Windows Phone ، أفضل نظام أساسي للهاتف المحمول في تاريخ البشرية ، حتى في اللحظة الأخيرة قبل أن لم يكن لدي خيار سوى التبديل إلى Android واحد هذا العام) ، لدي ثقة أكبر في طول عمر Uno Platform أكثر من الأشياء المماثلة من Microsoft. نعم ، يعتمد Uno على جميع تقنيات Microsoft ، لكنهم يعتنون بالترحيل عندما تغير Microsoft الأشياء تحت الغطاء.

لقد كنت أتساءل عما إذا كان أحد الأسباب التي جعل ميغيل يؤيد Uno وألقى الكلمة الرئيسية في Uno Conf هو أنه يرى Uno مثل طفله Mono في الأيام الأولى ، و Nventive مثل Ximian.

أنا أستعد لأسوأ سيناريو - موت أونو. نظرًا لأن جميع مشاريع Uno تستخدم تقنيتي المفضلة - C # و Xaml ، يمكنني نقلها إلى أي منصة ناشئة تعتمد عليها بسهولة. على الأقل يمكنني القول أن كود C # يتطور بشكل جيد. الكثير من التعليمات البرمجية الموجودة في مكتبة المرافق الأساسية الخاصة بي والتي يتم مشاركتها بواسطة جميع المشاريع عمرها أكثر من عقد من الزمان. لا يزالون يعملون بشكل مثالي ، وأعتقد أنهم سيفعلون ذلك في العقود القادمة.

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

مناقشة مثيرة للاهتمام ، كما لوحظ ذكر Blazor Native هنا أيضًا.

كان هناك NDC جديد من Steve مع Blazor قد يكون مثيرًا للنظر ، الفيديو أعلاه باستخدام Blazor + Native استخدم Flutter كعارض. ولكن في فيديو NDC Conf جديد ، يستخدم Steve الآن Xamarin.Forms لتقديم واجهة مستخدم للجوال بترميز يشبه XAML. يمكنني أن أرى أن Blazor Native هو الحل الأكثر عملية لمنصة x والذي يمكنه العمل الآن مع WinUI لأنه سيدعم React Native بنفس الطريقة التي يمكن أن أراها تدعم Blazor Native بهذه الطريقة. لذلك يمكن أن يستهدف .Net (الويب والجوال و Win Desktop).

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

شكرًا لموظفي Microsoft الذين عملوا على هذا التحسين. :ابتسامة:

وجهة نظري:

Microsoft: يمكنها تطوير حد أدنى من Webview2 (على غرار Carlo) يمكنه تعطيل جميع الميزات تقريبًا وتقليل ارتباط الحدث إلى واجهة مستخدم HTML فقط ... من المحتمل أن يتم تطوير جميع الميزات الأخرى في C # / native / خارج النطاق من المجتمع (مثل نظام أساسي مشترك مكتبة الخلفية الأصلية).
كنت أعرف مدى تعقيد جانب HTML / CSS ، لكنني أرغب في الاستفادة من معرفة واجهة المستخدم هذه وربط واحد لواحد برمز C # خلف كود الحدث وما إلى ذلك.

مايكروسوفت: يمكنها إيقاف تشغيل ذاكرة وصول عشوائي واحدة بسعة 8/32 جيجا بايت لمن لديهم 4x 8 جيجا بايت / 4x 32 جيجا بايت ... مما يوفر الكثير من الطاقة.

للقيام بذلك ، نتخلص من عشرات التطبيقات التي تم تطويرها باستخدام Electron ... والتي تعتمد على هدف Microsoft و Bill Gates.

على الرغم من أن الهدف الأفضل هو أن يبدأ الجميع في تطوير التطبيق واكتساب قوة دفع من بعض إطار عمل واجهة المستخدم الرسومية القياسي لـ CSS3 ... ممكن مثل QT / GTK ... لكن GTK السيئ جدًا ليس غير متروك الحقوق ، ويمكن مثل QML مع تكافؤ صافي.

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

إن غموض MS Teams ليس مفاجئًا عندما تعتبر أنه مكتوب بلغة JavaScript. _Of course_ التطبيق المكتوب بلغة JavaScript هو عربات التي تجرها الدواب - لماذا يتوقع أي شخص خلاف ذلك؟ يستخدم MS Teams ElectronJS الذي يستخدم JavaScript على الرغم من حقيقة أنه من المعروف جيدًا أن JavaScript لم يكن المقصود منها أن تكون لغة برمجة حقيقية ، بل إنها مجرد إضافة نصية عادية لمتصفحات الويب.

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

ما لا يمكن التسامح معه حقًا هو القرار غير المفهوم باستخدام لغة نصية عادية كما لو كانت لغة برمجة. لقد فوجئت حقًا برؤية Microsoft اختارت لغة غير احترافية لتطبيق لا يقل أهمية عن Teams. لم أكن أعتقد أنه كان من الممكن لأي شخص أن يقول اسم "JavaScript" بينما ننسى في نفس الوقت أن "JavaScript" بها كلمة "Script" في اسمها لأنها بالفعل لغة برمجة وليست لغة برمجة. بطريقة ما ، تم دمج وجود كلمة "Script" في "JavaScript" تمامًا.

يعمل أعضاء فريق WinUI بجد على العديد من التحسينات على WinUI. قرار Microsoft باستخدام لغة برمجة نصية غير رسمية بدلاً من WinUI لا معنى له.

هناك الكثير من تطبيقات الويب JavaScript عالية الأداء ومكتوبة بشكل جيد. بالتأكيد يمكنك الحصول على أداء أفضل باستخدام التقنيات الأخرى. لكن السبب وراء بطء Teams بالنسبة لك ليس بالتأكيد حقيقة أنه يعتمد على JavaScript. يحدث هذا بسبب بعض التنفيذ السيئ على جانب الخادم أو جانب العميل (ربما مشكلات غير متزامنة / مؤشر ترابط). سيكون من الممكن بالتأكيد كتابة Teams في JavaScript بأداء أفضل بكثير.

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

WinUI هو إطار عمل سطح مكتب Windows فقط. لذلك لم يكن من الممكن تطوير تطبيق x-platform Teams بناءً عليه ، وحتى اليوم لم يعد ممكنًا. ولكن ربما ستساعد مشاكل Teams Microsoft على التفكير في إنشاء WinUI عبر الأنظمة الأساسية. باستخدام WinUI حقيقي لمنصة x و .NET Core ، سيكون من الأسهل كثيرًا تطوير تطبيقات سريعة الاستجابة تتسع بشكل جيد.

WinUI هو إطار عمل سطح مكتب Windows فقط. لذلك لم يكن من الممكن تطوير تطبيق x-platform Teams بناءً عليه ، وحتى اليوم لم يعد ممكنًا. ولكن ربما ستساعد مشاكل Teams Microsoft على التفكير في إنشاء WinUI عبر الأنظمة الأساسية. باستخدام WinUI حقيقي لمنصة x و .NET Core ، سيكون من الأسهل كثيرًا تطوير تطبيقات سريعة الاستجابة تتسع بشكل جيد.

باستخدام Uno ، يعد WinUI منصة مشتركة. انظر إلى آلة حاسبة UNO في متجر Google Play. إنها نسخة منقولة من حاسبة Windows 10.

كان شخص ما يسأل عن مقارنة UWP مقابل Electron ، وهنا زوجان:

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

تطبيق XBOX الجديد مثير للسخرية ، حيث يمكنه بسهولة أن يأخذ 1.5 جيجابايت من ذاكرة الوصول العشوائي مقابل لا شيء

سيكون أمرًا رائعًا إذا كان بإمكان شخص ما إنشاء مقطع فيديو لإظهار مدى بطئه مقارنةً بـ UWP

اعتقدت أن معظم المشاركين في هذه المناقشة حول WinUI & X-platform قد قرأوا عن هذه القصة ، ولكن فقط في حالة فقدها البعض ، ها هو WinUI على Windows 7 - نعم ، من الممكن مع Uno Platform . بمجرد أن يعتمد التطبيق على Uno ، فإنه يستهدف Windows و Web و iOS و Android.

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

سيكون من الممكن بالتأكيد كتابة Teams في JavaScript بأداء أفضل بكثير.

نعم ، من الممكن _ ، ومن الممكن أيضًا أن تكتب MS Teams في PowerShell بأداء مقبول (أحب PowerShell) ، ومن الممكن أيضًا أن تنتقل SpaceX إلى روسيا وتستمر في إطلاق الأقمار الصناعية ، لكنها ستظل إدارة غير كفؤة قرار نقل SpaceX إلى روسيا ، أو كتابة تطبيق MS Teams بلغة برمجة نصية مثل PowerShell أو JavaScript. إذا انتقلت شركة سبيس إكس إلى روسيا ، فعندئذٍ ، لا يزال بإمكان سبيس إكس العمل ، هذا ممكن ، لكن بصراحة علينا أن نقول إن إيلون ماسك لن يكون مديرًا فعالًا حقًا ولن يعرف حقًا ما كان يفعله.

لست مقتنعًا بنسبة 100٪ بأن اللوم يقع على إلكترون. يقال إن Visual Studio Code يعتمد على Electron أيضًا ، لكن أدائه قوي جدًا. تطبيقات Electron هي في الأساس تطبيقات ويب ، وهناك الآلاف من الأسباب وراء سوء أداء تطبيق الويب.

ليس هناك الكثير الذي يمكن لـ WinUI القيام به "للفوز بالفرق". إنها ليست التكنولوجيا ، إنها المنتج. تشبه Teams شركة ناشئة أسست نفسها على طريق النمو السريع. يجب أن يتم تشغيله على أنظمة أساسية متعددة مع تكافؤ الميزات ، ويحتاجون إلى تحقيق ذلك في أسرع وقت ممكن. هذا هو السبب الوحيد لاختيار التكنولوجيا المستندة إلى الويب. على الهاتف المحمول يمكنهم استخدام React Native لأنها الطريقة الوحيدة للاستفادة من الأجهزة باستخدام JavaScript ، ولكن على سطح المكتب ، يحتاجون إلى الحفاظ على تكافؤ الميزات وقابلية صيانة الكود مع تطبيق الويب ، و mac ، وإصدار Linux. يتعين عليهم استخدام إطار عمل يستهدف win32 لأنهم لا يستطيعون الانتظار حتى يتمكن نموذج تطبيق UWP من إضافة الميزات التي يحتاجها. تعد القدرة على مشاركة سطح المكتب مع خيار اختيار سطح المكتب أو التطبيق المحدد المراد مشاركته إحدى ميزاته الرئيسية. هذه هي الطريقة التي يتم بها تطوير المنتجات الشبيهة ببدء التشغيل. استخدم Slack jquery لاختراق النمو عندما بدأوا لأول مرة وانتهى بهم الأمر برمز سيء حقًا ، ولكن بمجرد حصولهم على بعض الوقت لإعادة البناء ، سرعان ما أعادوا كتابة كل شيء باستخدام رد الفعل ، وأصبح Slack الآن أسرع بكثير من ذي قبل. WinUI و Electron ليسا في نفس الفئة ، ولهذا السبب لن يحلوا محل Electron للتطبيقات التي تحتاجها حقًا بغض النظر عن الميزة التي يضيفها.