أعتقد أن Xamarin سوف يندمج في .NET 5 ؛
سيكون أمرًا رائعًا إذا اعتمدوا UWP XAML كمعيار وعملوا من هناك ، فإن Microsoft و UNO تجعله الأفضل لسطح المكتب والجوال ومتصفح الويب (Azure) و IoT.
يمكنهم تسميتها
UWP vNext (مستند إلى WinUI) / Silverlight 6 (UNO)

أعتقد أن جهد Blazor كان الخطوة الأولى لإحضار .NET رسميًا إلى WebBrowser ، باستخدام عرضه الافتراضي الحالي ، أي. في HTML DOM
لكنني أعتقد أنه يمكنهم قريبًا تقديم محرك عرض آخر ، مكمل خفيف الوزن لـ WinUI ، شيء يدور حول Silverlight و UNO Platform و Xamarin ... مثل Flutter / WPF

سيكون رائعًا إذا اعتمدوا UWP XAML كمعيار وعملوا من هناك

كل ما تريدونه يا رفاق يحدث بالفعل مع أونو. سيكون من الحكمة أن تشتري هؤلاء الرجال ثم توظفهم لرعاية التطوير النهائي لـ Uno.

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

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

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

وهذا أيضًا هو السبب الذي يجعل Uno Platform لا يمكن أن تكون حقًا WinUI في كل مكان ، إلا إذا قامت بنقل DX 11 إلى كل منصة.

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

لا ، لا ينبغي أن يكون عبر الأنظمة الأساسية. يطلق عليه Windows UI لسبب ما. دعنا فقط نحصل على نظام واجهة مستخدم يعمل عبر جميع أنظمة Windows (الأنظمة الأساسية واللغات) لتبدأ مرحبًا؟ هذا لم يتحقق حتى الآن. ما زلنا منقسمين بين .net framework و .net core و uwp ثم قصة C ++ ، التي تحتوي على الأقل على uwp ، ولكن لا يستخدمها مطور اللعبة ، لأن UWP / WinRT لا يزال لديه بعض المشكلات - التوزيع ، وشريط المهام القسري ، والنوافذ المنبثقة لشريط العنوان عندما تكون في وضع ملء الشاشة (yikes).

التفكير في الأنظمة الأساسية سيكون إهدارًا هائلاً للموارد. احصل عليه بشكل صحيح على Windows أولاً من فضلك. واحصل على .net 5 خارج الباب ، وأصلح UWP وقصة النوافذ ، وقم بوضع DirectX على C #. وإصلاح GC. لا يزال هناك الكثير للقيام به في السيناريو الضيق ، فقط على نظام التشغيل Windows.

وإلى OP.

• UWP عالمي. القول بأنه ليس عالميًا هو ادعاء خاطئ (لم يقصدوا أبدًا استهداف Android ، والحمد لله). الوعد الأصلي قد تم تسليمه. جميع أجهزة Windows تعمل بنظام UWP. كان Windows Mobile عبارة عن نظام تشغيل منفصل ، وكان عليهم التخلص منه. ستكون جميع أنظمة تشغيل Windows الجديدة من Windows (10 أو 10x). في النهاية على أساس CoreOS أفترض. وسوف يقومون جميعًا بتشغيل تطبيقات Windows. فقط لأننا لا نملك هاتف يعمل بنظام Windows في الوقت الحالي هو أمر عرضي. لدينا جميع أنواع الأجهزة الأخرى. وسيكون لدينا Neo و Duo قريبًا.

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

• يتم استبدال .net الأصلي وستتغير قصة التوزيع مع .net 5. أعتقد أنه من العدل أن نقول إن Microsoft تعمل على هذا. بالتأكيد هم على علم بالقضايا. ولكن يجب عليك تقديم قضايا محددة لاستهداف المشكلات الأساسية الحقيقية هنا.

• "عدم إقران WinUI بـ DirectX" - WTF؟ يجب أن يقترن تمامًا بـ DirectX ، وهو مكدس رسومات Windows الأصلي. من فضلك لا تفكر في أي شيء آخر. لا أرغب مطلقًا في العثور على أسطح عرض OpenGL أسفل الغطاء. هذا من شأنه أن يكسر التوافق ويسبب كل أنواع الفوضى.

@ جافين ويليامز

رائع ، دعنا نجري ترقية تطورية طفيفة على WPF.

UWP عالمي

"جميع أجهزة Windows تعمل بنظام UWP" لا تعني شيئًا بدون الهاتف المحمول. يعد HoloLens مكانًا مناسبًا ، و Surface Hub هو مكان مناسب ، و Windows 10 IoT Core هو مزحة.

يجب أن يقترن تمامًا بـ DirectX

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

يطلق عليه "نمطية". لقد كافحت Microsoft دائمًا مع ذلك.

قيود Sandbox هي أشياء جيدة

نعم ، هم كذلك ، طالما أنهم لم يحدوا بشدة من نطاق التطبيقات التي يمكن بناؤها. هل حاولت تغيير حجم قسم من UWP؟

أعتقد أنه من الجدير بالذكر والتذكير بأن Google تقوم بتطوير Flutter ولا يطلقون عليها اسم GoogleUI أو AndroidUI. إنه يعمل في كل مكان - حتى على الويب وسطح المكتب. أصرح بهذا حيث يبدو أن هناك ميلًا إلى "تشغيله على Windows" ولكن إذا كان هناك عرض تنافسي آخر أرخص وأسرع وأسهل في الاستخدام ويعمل على Windows + كل شيء آخر ... ما الذي سيفعله المطورون ( والسوق المقابل) اختر؟ يمكنني أن أخبرك بصفتي صاحب شركة صغيرة أنني أعرف أين أضع استثماري في ضوء الخيارين.

يبدو نقل DirectX إلى الأنظمة الأساسية الأخرى عملاً هائلاً ، ربما يكون الحل هو استخدام OpenGL أو Vulkan بدلاً من DirectX

@ Gavin-Williams ، لا أعرف ما إذا كنت معتادًا على UWP ، ولكن عند إنشاء / توزيع ، فإنك تستهدف إصدارًا معينًا (أو نطاق إصدار) من Windows. هذه الفكرة مقترنة تمامًا ، وأحد الأسباب التي جعلت UWP لا تسير على النحو السائد كما فعلت WPF.
nerocui الغرض الكامل من لغة واجهة المستخدم هو فصل تصميم واجهة المستخدم عن الرسم الأولي في الشاشة. لهذا السبب ترى أن HTML قادر على العرض في ARM / x64 / x64.

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

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

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

يمكن سد الثقوب المتبقية في UWP بسهولة. أود أن أزعم أن المشكلة الأكبر هي فشل Microsoft في تحقيق مستوى الجودة المرتبط بـ WPF. WPF عملت للتو. فشلت Microsoft أيضًا في التعرف على الأهمية الحاسمة لمتطلبات LOB مثل Data Grid و INotifyDataErrorInfo وعناصر التحكم التي تتميز بحالات التحقق من الصحة وقاعدة بيانات قوية خارج الصندوق. تمت معالجة معظم هذه المشكلات ، لكن الأمر استغرق وقتًا طويلاً. المناطق غير المستطيلة مفقودة.

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

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

HTML + JS هو الحل عبر الأنظمة الأساسية اليوم. لا نحتاج إلى إعادة اختراعه. إن امتلاك محرك عرض XAML عالي الأداء على IOS و Android يكون أكثر منطقية إذا كان القصد هو جعل XAML أكثر قابلية للحمل.

أوافق بشدة على أن WinUI يجب أن تهدف إلى أن تكون متعددة المنصات في المستقبل. إليك بعض الأفكار الإضافية.

الأولويات الفورية

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

لماذا يجب أن يكون WinUI عبر الأنظمة الأساسية

هناك الأسباب الواضحة والأكثر أهمية - يرغب المطورون في استهداف أكبر عدد ممكن من الجمهور دون إعادة كتابة التعليمات البرمجية وما إلى ذلك ، و C # (أو C ++ أفترض) / XAML هو مزيج رائع. بدون قصة عبر الأنظمة الأساسية ، سينتقلون إلى تقنيات أخرى مثل Flutter.

سبب آخر هو ضمان استمرار دعم Microsoft WinUI. من المحتمل أن تستمر Microsoft في دعم WinUI فقط إذا كانت التطبيقات الخاصة بها تستخدمه. إنهم يركزون بشكل متزايد على إنشاء تطبيقاتهم الخاصة عبر الأنظمة الأساسية. صحيح أن بعض الأطر التي تعمل عبر الأنظمة الأساسية مثل React Native و Xamarin ستستخدم WinUI تحتها ، ولكن ماذا يحدث إذا فازت أطر أخرى مثل Flutter أو العرض المستند إلى المستعرض؟ ثم سيصبح WinUI زائداً عن الحاجة وسوف ينتقل إلى وضع الصيانة مثل WPF.

كيف ينبغي تنفيذ عبر منصة

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

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

تتمثل إحدى طرق تجريد طبقة التجسيد في استخدام Skia. ومع ذلك ، لا أريد أن يعاني الأداء بفرض هذا التجريد. لدي اقتراح بديل للنظر في تجريد طبقة التجسيد ، وهو اقتراح C ++ للرسومات ثنائية الأبعاد - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . من الواضح أنهم بذلوا الكثير من العمل في سطح واجهة برمجة التطبيقات ويبدو شاملاً جدًا. يجادلون بأن "مشكلة" الرسومات ثنائية الأبعاد قد تم حلها أساسًا منذ سنوات عديدة ويجب أن أتفق معهم في أن سطح واجهة برمجة التطبيقات الخاص بهم يبدو مكتملًا إلى حد كبير. هناك الكثير من الأشخاص ضد هذا الاقتراح ، ولكن حتى إذا لم يتم قبوله ، أعتقد أنه يمكن استخدام سطح واجهة برمجة التطبيقات. إذا قمت بكتابة خلفية Direct2D لسطح واجهة برمجة التطبيقات هذا ، فعندئذٍ إذا تم قبول الاقتراح ، فسيوفر فريق MSVC من الاضطرار إلى كتابته. ربما يمكن لفريق WinUI استخدام هذا كمبرر للسماح له بالعمل عليه أو إضافة بعض أعضاء الفريق الإضافيين. أيضًا ، ربما يكون مؤلفو الورقة على استعداد للمساعدة. يمكنك كتابة النهاية الخلفية للأنظمة الأساسية الأخرى باستخدام Skia أو ما شابه ، وإذا تم قبول الاقتراح في النهاية ، فانتقل إلى عمليات التنفيذ الأصلية عند إجرائها.

أخيرًا ، بالنظر إلى المستقبل ، أردت أن أذكر WASI - https://wasi.dev/ . يبدو أن هذا يركز على برمجة الأنظمة في الوقت الحالي ، ولكن قد يكون من المحتمل أن يتحول إلى إطار عمل كامل للتطبيقات عبر الأنظمة الأساسية (يحتوي على أنظمة أساسية متعددة وأمن مدمج) ، مع اقتراح C ++ أعلاه ربما يوفر مرشحًا طبيعيًا لـ طبقة التقديم API. (من المحتمل أن يكون هذا بعيدًا جدًا).

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

Noemata اعتدت أن أكون معجبًا ضخمًا بـ XAML + MVVM. لقد عملت معها في Silverlight و WPF و WindowsPhone و Metro (WinRT). لقد انهكت عندما يتعلق الأمر بـ UWP و Xamarin ...

من الصعب رؤية ما يفصل بين هذا التكرار مقابل جميع المرات الأخرى التي نظرت فيها إلى مكدس XAML جديد.

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

هذه قائمة جزئية:

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

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

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

المشكلة؟ لقد استغرق الأمر وقتًا طويلاً للوصول إلى ما وصلنا إليه الآن مع UWP و XAML. والآن أصبحت الرسالة مشوشة مرة أخرى. لو قدمت Microsoft قوالب مشروع لائقة باستخدام Visual Studio عندما تم إصدار UWP لأول مرة ، فسنكون أقل سلبية بشأن UWP. للحصول على أفضل قوالب VS ، عليك الذهاب هنا:

https://github.com/microsoft/windowsTemplateStudio

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

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

Noemata أوافق ، إنها عينات رائعة حقًا. لكن تطوير تطبيق معقد أمر مجنون باستخدام UWP. إنه ممكن بالتأكيد ، لكنه أصعب بكثير. نعم ، أفتقد أوقات "إنها تعمل فقط" الخاصة بـ WPF.

من أول الأشياء التي يجب أن تقدمها MS كعينة هو تطبيق UWP بسيط يمكنك نشره خارج متجر MS (ونعم ، ليس الأمر بالسهولة التي تعتقدها)

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

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

وبالمثل ، فإن أزرار الاختيار / مربعات التحرير والسرد لها حجم أدنى محسّن أيضًا للجوال. يتم تجاهل ببساطة تعيين عرض زر الاختيار ، فأنت في الواقع تحتاج إلى تعيين "MinWidth = 0" لأخذها في الاعتبار.

ولون زر النص أبيض ، ثم أسود عند التركيز - ما المشكلة في ذلك؟ ولزر النص علامة "x" يمكنك استخدامها لمسحها - هذه لوحة اللمس - لماذا أحصل عليها هناك عندما لا تكون هناك لوحة لمس؟

تم تمكين التدقيق الإملائي في مربع النص الافتراضي - فلماذا أريد ذلك؟

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

تحية طيبة للجميع ،
نظرًا لأن هذه مسألة مناقشة عامة ولا أعرف في أي مكان آخر أضع فيه رغبات / طلبات ميزات UWP الخاصة بي ..... أغتنم الفرصة في هذا الموضوع:

• دعم أفضل لدمج تطبيقات uwp في قائمة سياق مستكشف Windows
  
  
  
  • يرجى دعمنا هنا https://aka.ms/AA6rmrk
  
  
• يفتقد ملحق ترميز UWP IServiceProvider ، والعنصر نفسه الذي يتم استخدام ملحق الترميز عليه
• مشغل نمط UWP مفقود
• مشكلة قوالب البيانات الضمنية UWP. انظر على سبيل المثال هنا
• لا توجد طباعة تلقائية ممكنة بدون تدخل المستخدم (تعمل فقط لنقاط البيع) انظر هنا

تمت معالجة جميع الميزات أو المشكلات المذكورة أعلاه في uservoice التي تم التخلي عنها الآن. لا أحد يعرف ما حدث مع هذه القضايا؟ هل يجب علينا إعادة إنشائها على feedbackhub؟

أحب عبارة "المطورون المنسيون". أعرف الكثير منهم من الموهوبين وذوي الخبرة والمتحمسين للتقنيات. هم مطورو. صافي المخضرمين. ليس لدي شك في أنهم ، بشكل عام ، يمكنهم إنشاء تطبيقات أفضل من العديد من الأطفال الذين يزدهرون في تطوير التطبيقات لنظامي التشغيل iOS و Android.
إذا كان بإمكان WinUI توفير مسار ممتع وقوي بالنسبة لهم للاستفادة من خبرتهم الواسعة في C # + .Net + Xaml لإنشاء تطبيقات لنظام التشغيل Windows و Android و iOS و Web ، فسيقفز الكثيرون إلى العربة وسيستفيد العالم من هذه التطبيقات العالية. تطبيقات الجودة.
WinUI + Uno Platform يمكن أن تكون المكالمة النهائية.

يفتقد ملحق توصيف UWP IServiceProvider والعنصر نفسه الذي يتم استخدام ملحق التوصيف عليه

حصلت على تغطية هنا @ mfe-!

حصلت على تغطية هنا @ mfe-!

@ Mike-EE واو ، هذا رائع! أتذكر أنني واجهت هذا عندما أردت نقل CalcBinding إلى UWP. ما انتهى بي الأمر هو حل بديل حيث أقوم بإضافة حقول للقراءة فقط في نموذج العرض.

"اكتب مرة واحدة ، اركض في كل مكان".

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

عمل جميل كلنا مشهورون! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

المطورون المنسيون صامتون أو يتم تجاهلهم فقط

أحب عبارة "المطورون المنسيون".

دعونا ننظم تحت هذا الاسم! 💪

أرغب فقط في وجود إطار عمل لواجهة مستخدم عبر الأنظمة الأساسية تم تطويره ودعمه بواسطة Microsoft. لا يوجد شيء لنظام .NET البيئي باستثناء _Uno Platform_ و _Xamarin.Forms_ (إذا كانا لا يزالان يعملان على استهداف سطح المكتب).

وحتى إذا قررت كتابة تطبيق أعمال يعمل بنظام Windows فقط من البداية ، فأنا لا أعتقد أن Microsoft ملتزمة تمامًا بـ UWP. صححني إذا كنت مخطئًا ولكن ألم يتخلوا عن تطبيقات Office UWP لصالح Office Online PWAs؟ إذا تخلت MS عن إطار عمل الطرف الأول الخاص بها ، فلماذا يجب أن أثق في UWP؟ _ سعال سيلفرلايت_

لحسن الحظ لم يتم التخلي عن WPF بعد. لكن هذا يزيد من شكوكي.

عمل جميل كلنا مشهورون! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

هولي 🤭

ممتاز! دعنا نتوسع في المجلات الكبيرة الأخرى ، ومواقع الويب ، وما إلى ذلك 😛

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

https://unity.com/

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

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

سأصدر الأسبوع المقبل مجموعة من قوالب VS لـ UWP والتي تتيح لك إنشاء تطبيقات في ثوانٍ. تم استخدام هذا للمشاريع "الداخلية". ستثبت النقطة التي مفادها أن UWP يمكن أن يكون إطار عمل RAD خارج الصندوق إذا كان VS فقط يحتوي على اللبنات الأساسية الصحيحة المضمنة فيه.

سأصدر الأسبوع المقبل مجموعة من قوالب VS لـ UWP والتي تتيح لك إنشاء تطبيقات في ثوانٍ. تم استخدام هذا للمشاريع "الداخلية". ستثبت النقطة التي مفادها أن UWP يمكن أن يكون إطار عمل RAD خارج الصندوق إذا كان VS فقط يحتوي على اللبنات الأساسية الصحيحة المضمنة فيه.

Noemata هذا يبدو رائع! أنا فضولي للغاية!

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

https://github.com/Clancey/Comet

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

يستخدم نمط واجهة المستخدم التعريفي ونمط MVU. تم تطويره بواسطة جيمس كلانسي ، مهندس مدير برنامج رئيسي في Microsoft. على الرغم من أنه لم يتم دعمه رسميًا حتى الآن ، ولكن مع وجود ما يكفي من الجذب المجتمعي ، يمكن أن يكون كذلك.

في Comet ، تعد واجهة المستخدم مجرد مكتبة ، لذا يمكنك (أو ربما تستطيع Microsoft) تطوير مكتبة WinUI تمامًا مثلما يحتوي Comet على مكتبة تصميم المواد.

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

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

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

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

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

سأصدر الأسبوع المقبل مجموعة من قوالب VS لـ UWP والتي تتيح لك إنشاء تطبيقات في ثوانٍ. تم استخدام هذا للمشاريع "الداخلية". ستثبت النقطة التي مفادها أن UWP يمكن أن يكون إطار عمل RAD خارج الصندوق إذا كان VS فقط يحتوي على اللبنات الأساسية الصحيحة المضمنة فيه.

هل هذا باستخدام NoesisGUI؟ إذا كان الأمر كذلك ، فهناك الكثير من الوظائف المفقودة والتي ستكون ضرورية لتطبيقات LOB. الآن ، استهداف WinUI للوحدة سيكون رائعًا.

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

https://github.com/gatewayprogrammingschool/XAML-Standardization

مسألة بسيطة ، تجاوز وضع الحماية اليوم واحتضن ما هو مطلوب عبر النظام الأساسي. تفعل ذلك بالفعل مع كل جانب آخر من جوانب Windows / OS لماذا لا واجهة المستخدم.

خذ منصة الصليب الرمل.

من: anthonyadame [email protected]
تاريخ الإرسال: السبت ، 29 فبراير 2020 ، 8:00:13 مساءً
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ التعليق [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] المناقشة: يجب أن تكون WinUI مشتركة بين الأنظمة الأساسية (# 2024)

مسألة بسيطة ، تجاوز وضع الحماية اليوم واحتضن ما هو مطلوب عبر النظام الأساسي. تفعل ذلك بالفعل مع كل جانب آخر من جوانب Windows / OS لماذا لا واجهة المستخدم.

-
أنت تتلقى هذا لأنك علقت.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/microsoft/microsoft-ui-xaml/issues/2024؟email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 ، أو إلغاء الاشتراك https://github.com/ الإخطارات / unsubscribe-auth / AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

يعد دمج مكونات C ++ عالية الأداء مع C # أمرًا تافهًا في إطار UWP. تم أيضًا تحسين الوصول إلى أسطح DirectX بشكل كبير.

Noemata باستثناء ما يهمني هو عدم الاضطرار إلى كتابة C ++ لتبدأ به ، يستمر WinDev في إفساد جميع المحاولات التي من شأنها أن تجعل لغات .NET متساوية فيما يتعلق بواجهات برمجة تطبيقات C ++ ، وإدارة Direct X ، و XNA ، وتجميع AOT المناسب لـ .NET كود ، ميزات COM ، ....

سيكون جعل نظام WinUI 3.0 عبر الأنظمة الأساسية هو تلك الوسيطة لنقل تطبيقات .NET / Forms الحالية إلى WinUI.

في البداية سيكون كافيًا لدعم macOS ، ولا توجد مشكلة عندما لا يكون له نفس الأداء كما هو الحال في Windows ، أو عندما لا يكون لديه جميع الميزات مثل الرسوم المتحركة.

Windows هو النظام الأساسي المرجعي ؛ بالطبع يجب أن يقترن بـ DirectX للحصول على أفضل أداء.

في رأيي ، لا معنى لمحاولة إعادة كتابة تطبيقات C # الكبيرة في HTML + JS فقط لدعم macOS. وأيضًا بالنسبة لتطبيقات سطح المكتب الجديدة ، يعد C # الخيار الأفضل.

بالنسبة لتطبيقات سطح المكتب ، تعد C # و XAML أكثر موثوقية من HTML + JS.

يضمن جعل نظام WinUI 3.0 متعدد الأنظمة الأساسية مستقبل .NET و C # و XAML.

أهلا بكم

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

1) أراقب عن كثب سوق الوظائف في المملكة المتحدة. 100٪ من وظائف WPF المُعلن عنها منذ عام 2006 (والتي كان هناك 1000 منها) مخصصة لبناء تطبيقات سطح مكتب تداول مالي عالية الأداء للقطاع المالي. لم يتم الإعلان عن أي وظيفة لمطور UWP لأي صناعة حتى الآن.

2) لا يمكن أن تستخدم تطبيقات تداول سطح المكتب UWP أو WinUI القادم - فهي ليست جيدة بما يكفي مقارنة بـ WPF للعديد من الأسباب المعقدة. كما أن تصميم Fluent ليس شيئًا يهتم به هؤلاء المستخدمون - إنه يحتاج فقط أن يبدو مثل شبكة Excel - لا توجد رسوم متحركة ولا تصميم - فقط بيانات وأداء مذهل.

3) لا يهتم هؤلاء العملاء على الإطلاق بالحلول عبر الأنظمة الأساسية. لا أحد يستخدم جهاز Mac ، والجوال ليس شيئًا يهتم به.

4) تمتلك فرق مطوري WPF استثمارات كبيرة (الوقت والمال) في مكتبات تحكم WPF التابعة لجهات خارجية ، أو لديها مجموعات تحكم مخصصة معقدة وفائقة الأداء تم تطويرها لهم عبر أشخاص مثلي. لن يبتعدوا عن WPF ما لم تكن هناك فائدة كبيرة جدًا (لن تكون موجودة للأمام)

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

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

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

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

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

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

weltkantedeanchalk توجد مشكلة في الريبو تطلب "دعم التحكم القديم" في WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/1833
النقطة 4 على الأقل) تناسب هذه المشكلة ويجب إعادة نشرها هناك لإثبات حالة الاستثمار من قبل Microsoft.

deanchalk ، ما زلت معجبًا كبيرًا بـ WPF. إنها أداة رائعة ، لحسن الحظ ، بدأت تحصل على بعض الحب من Microsoft. الطريقة التي اختارت بها Microsoft إسقاط WPF في المقام الأول ، كانت مؤسفة للغاية. تعتبر UWP هي اللعبة الجديدة اللامعة ، ولا ينبغي أن تمنع استمرار الاستثمارات في WPF.

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

أنا أقل تعاطفاً مع مطوري WPF الذين اختاروا ترسيخ أنفسهم في WPF في عام 2020. لقد تطورت الأمور إلى حد كبير. تمنحك جزر XAML مع القدرة على استخدام WinRT API مسارًا سهلًا إلى حد ما لبدء الترحيل إلى UWP. ولم تعد UWP مفقودة إذا اخترت إجراء تحويل بالجملة.

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

من الواضح أن WinUI هو UWP المعاد تسميته ، ومن المؤلم أن نشهد. ومن الواضح أيضًا أن Microsoft تأمل في أن ننسى جميعًا ما هو / كان UWP.

ومع ذلك ، لا تتوافق اليد اليسرى لـ Microsoft دائمًا مع ما تفعله اليد اليمنى. لقد جعل WindowsX Win32 وكل ما يأتي معه (WPF / Winforms / وما إلى ذلك) احتمالًا ضعيفًا للتطبيقات التي "قد" تعمل في وضع الحماية المنخفض للأداء. UWP هي ولا تزال حاليًا واجهة المستخدم الأصلية لنظامي التشغيل Windows 10 و WindowsX وما بعده. يعد WinRT API تحسينًا كبيرًا على Win32. لذلك أعتقد أنه عليك أن تختار ما إذا كنت تريد الانتقال إلى عام 2020 أو الاستمرار في عام 2010.

من الواضح أن WinUI هو UWP المعاد تسميته ، ومن المؤلم أن نشهد. ومن الواضح أيضًا أن Microsoft تأمل في أن ننسى جميعًا ما هو / كان UWP.

Noemata WinUI هو منتج جديد يعتمد على UWP APIs (XAML ، التركيب ، الإدخال ، ...). يعتبر الاسم منطقيًا حيث ستتمكن من استخدامه لإنشاء واجهة مستخدم لتطبيقات Windows بغض النظر عن طراز التطبيق الأساسي.

انا مرتبك. أنت نفسك تذكر 10x في الفقرة الأخيرة. نموذج تطبيق UWP نفسه يحصل على دفعة مع Windows 10x. الآن ، ما إذا كانت 10X ستنجح أم لا هو شيء فقط الوقت سيكون قادرًا على إخباره. لكن MS كانت واضحة في رسالتها: UWP هي النظام الأساسي الأصلي لـ 10x (جنبًا إلى جنب مع الويب) كما أشرت.

Noemata حتى عام 2020 يلحق بالميزات المتاحة في عام 2010 ، ويضطر الكثير منا إلى البقاء في عام 2010.

لقد سئم الكثير منا للتو من قطار إعادة الكتابة الذي بدأ بإسقاط Silverlight و XNA ورؤية كيف تلوح يد MS بإعادة الكتابة التي تتطلب .NET Core ، WinUI ، أثناء إسقاط الميزات في هذه العملية ، لا يفوز بقلوب العديد من العملاء ، مع تطبيقات تعمل بشكل كامل ولا ترى سبب وجوب دفعهم لإعادة الكتابة لاستعادة ميزات أقل.

في الوقت الحالي ، بفضل الذكاء في امتلاك أجهزة لوحية تعمل بنظامي Android و Windows 10 X ، فإن Xamarin و PWAs هما ما نتطلع إليه ، وليس WinUI.

pjmlp ، ربما. أنا فضولي ما هي الميزة التي تفتقدها؟ لقد قمت بنقل بعض تطبيقات WPF الكبيرة إلى حد ما إلى UWP. كان أكبر صداع هو وضع الحماية للأمان وتعلم العمل معه بدلاً من محاربته. في السابق كانت هناك أجزاء مفقودة ، مثل شبكة البيانات واتصال قاعدة البيانات وواجهة برمجة تطبيقات مناسبة للاتصالات عالية السرعة وما إلى ذلك. هناك القليل جدًا في عداد المفقودين الآن. هناك الكثير الذي لم أستطع فعله بنفس السهولة تقريبًا في WPF. لكي نكون منصفين ، في الوقت الحالي ، لا يوجد شيء لا يمكنني القيام به في WPF من خلال الاستفادة من الوصول إلى WinRT API إلا أنه سيكون لدي أداء أقل لأن UWP يقوم بترجمة التعليمات البرمجية للجهاز بطريقة أكثر مثالية ويستخدم مكدس عرض DirectX أفضل. بالإضافة إلى أنه يتعين عليك إخفاء رمز WPF (جعله أكثر هشاشة) إذا كنت عازمًا على حماية عنوان IP الخاص بك أو منع المتسللين.

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

@ فيليكس ديف أحصل على ما هو WinUI. أتساءل لماذا كانت هناك حاجة إلى شوكة أخرى لمجرد أن مطوري WPF و Winforms و MFC / Win32 لن يشتركوا فيها. كان من الممكن أن تكون الإستراتيجية الأفضل هي جعل الهجرة إما أكثر جاذبية أو أقل إيلامًا أو كليهما.

قامت Microsoft بالكثير من الأشياء بشكل صحيح مع UWP. هناك ثروة من تطبيقات العينات التي تغطي جميع أنواع حالات الاستخدام. وصلوا متأخرين ، كما فعلت الميزات المفقودة. هل فات الأوان حقا؟

من المحتمل أن يحدث Noemata WinUI في كلتا الحالتين (مع WinUI Desktop أو بدونه) لأن فصل حزمة UWP UI عن نظام التشغيل يعد خطوة ضرورية للغاية. كان من الأفضل لو كان WinUI موجودًا بالفعل عند إصدار Windows 10 لأول مرة ولكن هناك أسباب وراء عدم حدوث ذلك.

أما لقد فات الأوان .... فقد أجرينا العديد من هذه المناقشات في قناة الخلاف المجتمعي الخاصة بـ UWP وكذلك عدد لا يحصى من التبادلات العاطفية هنا. يعتقد البعض منا أن السفينة قد أبحرت بالفعل بينما لا يزال البعض الآخر يعتقد أن هناك فرصة أن تنمو منصة UWP / WinUI وتنضج لتصبح منصة تطوير رئيسية. كثير من الناس لديهم العديد من الأفكار كيف يمكن أن يبدو أفضل نهج للتصلب المتعدد (على سبيل المثال ، الانتقال إلى xplatform أم لا؟). الحقيقة هي أن الفريق يعمل بجد حاليًا على WinUI 3 وسيشير إصداره إلى بداية مواجهة التحدي الحقيقي: دفع WinUI للأمام - بمساعدة المجتمع - بحيث يصبح إطار العمل المفضل للمطورين الذين يستهدفون Windows .

Noemata ، أولاً وقبل كل شيء التوافق مع مكتبات مكونات الطرف الثالث الحالية من أمثال Telerik ، و Component One ، ...

ثم عدم الاضطرار إلى إعادة كتابة أي شيء لتبدأ به ، كما ذكرنا ، سئمنا من إعادة الكتابة.

فيما يتعلق بـ DirectX ، ليس فقط فئات النمذجة ثلاثية الأبعاد من WPF غير مدعومة ، فمن المتوقع أن نكتب C ++ ، لأن Microsoft لا يمكن أن تزعج نفسها لإنشاء إسقاطات وقت التشغيل لـ DirectX ، وقد تم استبدال لهجة C ++ / CX اللطيفة إلى حد ما بالكلمات أقل قدرة ، ولكن أفضل توافقًا ، C ++ / WinRT.

علاوة على ذلك ، لا يتعين علينا فقط التخلص من كود WPF الذي يعمل بشكل مثالي ، بل يتعين علينا أن نفعل الشيء نفسه مع كود WCF ، EF6.

ما زلت أعتقد أن UWP هي واجهة برمجة تطبيقات أفضل بكثير من Win32 ، بطريقة ما كان يجب أن تكون Longhorn ، ولكن الطريقة التي يتم بها هذا الأمر قد أحرقت الكثير من الجسور ، حيث قامت Microsoft بحرق ميزانية إعادة الكتابة من العديد من المؤسسات.

pjmlp ، هذه كلها نقاط جيدة مع حجج مضادة وداعية إلى حد ما ، لذلك لن أحاول حتى. كان عدم وجود دعم لواجهة برمجة تطبيقات WPF 3D بمثابة ضربة كبيرة بالنسبة لي شخصيًا. لم يكن الاضطرار إلى تعلم نهج جديد أمرًا ممتعًا وكان أقل قدرة بكثير نظرًا لخيارات ربط WPF لـ 3D. توجد بدائل C # لـ 3D ضمن UWP ، وهي طريقة أقل فائدة بمجرد تجربة فوائد الربط على نموذج ثلاثي الأبعاد.

كانت C ++ / CX نقطة ألم أخرى استغرقت وقتًا طويلاً ليتم حلها بواسطة C ++ / WinRT والتي قد تكون مستقرة الأسبوع المقبل في وقت ما (لا تزال تتغير).

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

@ Felix-Dev ، أنت أيضًا تقوم بعمل نقاط صحيحة تمامًا. يجب أن يكون فصل واجهة المستخدم موجودًا منذ البداية. يجب على الأشخاص الذين يطلبون واجهة مستخدم xplatform المستندة إلى XAML إعادة صياغة طلبهم وطلب محرك عرض XAML على النظام الأساسي الذي يختارونه مع نظام تشغيل صغير لتكرار سطح واجهة برمجة التطبيقات (Java / Silveright / Uno Platform / Unity / Whatever ... في النهاية تنتهي بـ HTML الذي لا يمكن أن تبدأ التطبيقات القريبة من المعدن في الاعتبار). لست مطلعا على أحدث المبادرات الداخلية للتصلّب العصبي المتعدد في الوقت الحالي. بالنظر إلى الخارج ، فإن WinUI هو العلم الملوح الذي يشير إلى أن السفينة يتم تصحيحها مرة أخرى (كم مرة أخرى؟). أصبح الدفاع عن مايكروسوفت مستحيلاً مع وفاة سيلفرلايت. لن أحمل هذا السيف مرة أخرى. أفترض أن ما أفعله حقًا هو البكاء على موت UWP :- (... مؤلم. https://www.youtube.com/watch ؟v=uBiewQrpBBA

تشارلي == مايكروسوفت

عبر منصة؟ يجب على Microsoft فقط شراء UNO والانتهاء من حلمة الثدي.

عبر منصة؟ يجب على Microsoft فقط شراء UNO والانتهاء من حلمة الثدي.

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

عبر منصة؟ يجب على Microsoft فقط شراء UNO والانتهاء من حلمة الثدي.

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

هذه هي الطريقة التي يقوم بها UNO باستثناء Windows 7. Windows 7 هو الاستثناء الوحيد لأنه يستخدم متصفح الويب.

بالنسبة لمطوري WPF الذين يحتاجون إلى حل سطح مكتب عبر الأنظمة الأساسية ، قد يكون Wine خيارًا قابلاً للتطبيق بالنسبة لك. لقد حققت نجاحًا كبيرًا في نقل تطبيقات WPF الكبيرة (.NET Core WPF في الغالب) للتشغيل على Linux مع Wine. لدي كتابة يمكن أن تساعدك في البدء:
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

لقد بدأت أيضًا في نقل بعض تطبيقات WinForms إلى Linux أيضًا. حتى الآن لم أواجه أي مشاكل.

يجب أن يمكّنك النبيذ أيضًا من التشغيل على أنظمة تشغيل Mac و Chrome OS و Android. لقد جربت لينكس فقط.

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

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

AvaloniaUI بالفعل عبر منصة. لماذا لا تطلب من الأشخاص في المشروع المساعدة والتعليقات لتحسين WinUI؟

حسنًا ، ليس بقدر منصة Uno. يعمل Uno Platform على الويب أيضًا (WASM). أفالونيا تفتقر إلى هذه القدرة.

تستخدم Avalonia أيضًا لهجة XAML الخاصة بها ، وهو أمر تحاول Uno تجنبه.

من: Shimmy [email protected]
تاريخ الإرسال: الجمعة 27 مارس 2020 ، الساعة 4:09:30 صباحًا
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ التعليق [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] المناقشة: يجب أن تكون WinUI مشتركة بين الأنظمة الأساسية (# 2024)

AvaloniaUI بالفعل عبر منصة. لماذا لا تطلب من الأشخاص في المشروع المساعدة والتعليقات لتحسين WinUI؟

حسنًا ، ليس بقدر منصة Uno. يعمل Uno Platform على الويب أيضًا (WASM). أفالونيا تفتقر إلى هذه القدرة.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً ، أو قم بعرضه على GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 ، أو قم بإلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA .

تأتي معظم تقنيات WinUI من Sliverlight ، وقد حقق Sliverlight بالفعل منصة مشتركة. لذا فإن نظام WinUI المتعدّد يعتمد على الإستراتيجية وليس التكنولوجيا.

بصراحة ... إنه أمر مثير للشفقة في الواقع تحاول Microsoft الآن اللحاق بالركب ... إنهم يهتمون فقط بحصة السوق "الكبيرة" ، ولا يبحثون عما يريده عملاؤهم / عشاق المنتج.

Microsoft هي السبب في تحول تطوير تطبيق DESKTOP APP إلى تطوير WEB القديم ، حتى عندما يكون الويب فظيعًا للغاية.

أنا متأكد من أن كل مطوري XAML يوافقون على أن HTML / CSS تافهة جدًا.

لكن لا يزال ... HTML و CSS و DOM ... مع أطر مثل React و Angular و Vue الذين يحاولون جعله شيئًا أكثر متعة. لا يزال الناس يركزون على هذا الويب القديم ، وليس على النظام الأساسي الجديد لنظام التشغيل Windows الجديد والمغلق المصدر من Microsoft والذي يموت كل عامين إلى أربعة أعوام للحصول على واحد جديد.

يجب أن يكون النظام الأساسي لتطبيق Win المستند إلى XAML مفتوح المصدر منذ سنوات. يجب أن يكون قد تم نشره مرة واحدة على WEBSITE و Windows و Mac و Linux و Android (أي منصة يريدها عميل). يجب أن يكون متجر Windows عبر الأنظمة الأساسية مع عارض تطبيق XAML / UWP. (مشابهة لكيفية استخدام Google Chrome لأنظمة متعددة مع عارض HTML / CSS).

خلال العصر الذهبي لمايكروسوفت ، كان من الممكن أن يكون تطبيق النظام الأساسي المتقاطع المستند إلى XAML قد دمر الويب ، ثم لم يكن علينا التعامل مع أطر CSS و HTML و DOM وعدد لا يحصى من الأطر.

لكن لا ، هوس مايكروسوفت بالبرمجيات الاحتكارية جعلهم يخسرون على الويب.

في هذه الأثناء ، أصبح Flutter من Google هو ما أردته دائمًا لـ XAML.

أتوقع أن يكون WinUI 3 منصة مستهدفة في MAUI. أعلنت منصة Uno بالفعل أن WinUI 3 Preview حصلت على دعم.
إذن ، jeromelaban / Microsoft ما نحتاجه حقًا هو توحيد Uno / MAUI؟ MAUI هو IMO أقل فائدة من Flutter أو Uno بدون هدف ويب (مستعرض).

الرجاء ترك تعليقاتك في مستودع MAUI أيضًا.

WPF (Silverlight) في كل مكان!

يبدو نقل DirectX إلى الأنظمة الأساسية الأخرى عملاً هائلاً ، ربما يكون الحل هو استخدام OpenGL أو Vulkan بدلاً من DirectX

تمتلك Google ANGLE الذي يسمح بتشغيل OpenGL ES محليًا على أي نظام أساسي عن طريق ترجمة الاستدعاءات والتظليل إلى واجهة برمجة تطبيقات أصلية (سطح المكتب [ربما يتم توفيره بواسطة عارض برنامج swiftshader] ، فولكان ، ديريكتكس ، ميتال). إنه أيضًا جزء أساسي من Chrome و Flutter ، يعمل جنبًا إلى جنب مع Skia.

يمكن أن تقوم Microsoft بمجموعة فرعية صغيرة (ربما كنقطة بداية) من DirectX لتطبيقات واجهة المستخدم الرسومية وتجعلها تترجم إلى واجهات برمجة تطبيقات أصلية تمامًا كما يفعل ANGLE.

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

مذكور في دردشة Lonje https://www.lonje.com/message/1968439855/

أعتقد حقًا أن WinUI يجب أن يدعم أيضًا السمات الأصلية على Mac و Linux مع الاستمرار في دعم السمات المخصصة.
لست متأكدًا من مستخدمي Mac ولكن مجتمع Linux يحب التحكم في شكل سطح المكتب الخاص بهم.
لديهم بالفعل Gtk والتي أعتقد أنه سيكون من الجيد لفها في إطار عمل WinUi

أعتقد حقًا أن WinUI يجب أن يدعم أيضًا السمات الأصلية على Mac و Linux مع الاستمرار في دعم السمات المخصصة.
لست متأكدًا من مستخدمي Mac ولكن مجتمع Linux يحب التحكم في شكل سطح المكتب الخاص بهم.
لديهم بالفعل Gtk والتي أعتقد أنه سيكون من الجيد لفها في إطار عمل WinUi

من الصعب فعل ذلك لأن WinUI هي لغة نمط ، وأطر XAML الأساسية تتطلب منك القيام بها بنفسك ، بينما يتم توفير السمات الافتراضية أيضًا.

لقد اقترحت في الماضي ، أن يتم تنظيم المشروع بطريقة تمكن المجتمع من تطوير عارض معدني لنظامي التشغيل macOS و iOS - وربما عارض Skia لنظام Android.

يمكن استخدام نفس الأنماط والقوالب الافتراضية على جميع الأنظمة الأساسية ، أو يمكن إنشاء قوالب وموارد افتراضية على غرار Android و macOS.