Flutter: ☂ إضافة دعم لـ UWP

ربما ليس الآن ، انظر # 10881.

أود أن أشرك نفسي في طلب الميزة هذا ، سيكون من الرائع أن يدعم Flutter نظام التشغيل Windows 10 UWP.

يجب أن يغطي هذا Xbox One أيضًا ، والذي يمكنك استهدافه في Xamarin / UWP

نعم من فضلك. سيكون دعم Windows بالتأكيد مغيرًا للعبة.

هذا ليس رسميًا ، لكن يمكنك التحقق من هذا المشروع. https://github.com/google/flutter-desktop-embedding أعتقد أن glfw متاح أيضًا على windows لذا يمكنك تجربة: wink:

رجل ... أريد xplat حقيقي :)

كنت أكتب للتو نفس طلب الميزة 😉 ... أتمنى أن يحصل هذا على بعض التأثير!

كمستخدم لديه العديد من أجهزة Windows و MacOS و Chrome OS في منزلي ... فإن أحدث طراز من Surface Pro ينتهي دائمًا بكونه سائق يومي كل عام ؛ منذ إصدار SP4. يبدو أنها تحظى بشعبية كبيرة في الحرم الجامعي وفي العمل الآن أيضًا. ومع ذلك ، لا يزال الاختيار الضئيل لتطبيقات UWP عالية الجودة يمثل أكبر نقطة مؤلمة بالنسبة لي.

أعتقد أن الأناقة وسهولة استخدام Flutter يمكن أن توفر الحافز الذي يحتاجه المطورون / الهيئات ، لتضمين Win10 في إستراتيجيتهم متعددة المنصات ... وفي هذه العملية ، آمل أن تروج Flutter إلى حالة / شعبية مماثلة مثل Java ؛ لمراعاة تكنولوجيا المعلومات التنفيذيين ، عند اختيار الأدوات والأنظمة الأساسية لتطوير المنتجات.

تشمل Xamarin و Ionic وما إلى ذلك UWP ، فلماذا Flutter؟

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

الإزالة من مشروع Window MVP. ما زلنا نقوم بتقييم UWP كهدف ، ومن المحتمل أن ندعمه في النهاية ، لكن التركيز الأولي ينصب على تمكين Win32 من تقييد النطاق.

أعتقد أن هذا خطأ. جميع المنصات التي لا تدعم uwp غير مدعومة اعتبارًا من 20 يناير 2020. أي بحلول الوقت الذي يصبح فيه هذا جاهزًا.

من غير المجدي دعم منصة قديمة عندما لا تضطر إلى ذلك لأن الهجرة الجماعية تحدث الآن بقوة.

يجب أن يكون التركيز الوحيد هو uwp ويجب تجاهل wpf.

جميع المنصات التي لا تدعم uwp غير مدعومة اعتبارًا من 20 يناير 2020

يعتبر قرار التركيز على Win32 APIs أولاً تقنيًا ، ولا يعتمد على الأنظمة الأساسية المستهدفة.

يجب تجاهل wpf

لا توجد خطط حاليًا لاستخدام WPF.

معذرةً ، يجب تجاهل win32.

لماذا ا؟

لأن win32 يحد من الرفرفة على منصات windows. لا تدعم Uwp لأنه بحلول الوقت الذي تحصل فيه على هذا ، لن تكون هناك أنظمة تشغيل Windows مدعومة لا تدعم uwp ، ومع ذلك هناك منصات على windows لا تدعم win32 (arm64 الذي يتطلب إعادة بناء بالكامل)

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

ومع ذلك ، هناك منصات على windows لا تدعم win32 (الذي يتطلب arm64 إعادة بناء بالكامل)

يدعم Windows 10 على ARM Win32 ، ما عليك سوى تجميع التطبيق تحت ARM64 ، كما هو الحال مع UWP.

جميع المنصات التي لا تدعم uwp غير مدعومة اعتبارًا من 20 يناير 2020. أي بحلول الوقت الذي يصبح فيه هذا جاهزًا.

ينتهي دعم Windows 8.1 في عام 2023. وهو لا يدعم UWP.

stuartmorgan مرحبًا ، أنا مهتم بالعمل على دعم UWP.

لقد ذكرت أعلاه "ما زلنا نقيم UWP كهدف" - أود أن أعرف ما الذي اكتشفته.

شكرا،
-جيك

@ Kapranov98 لقد انتهيت للتو من تجربة نقل الرفرفة إلى Windows 10 ARM. Win32 / UWP هو أقل المشاكل. تتطلب Dart نفسها تغييرات جوهرية لتعمل على WinARM. لم يتم تصميم كود ARM المحدد في dart مطلقًا للعمل على أي شيء سوى أنظمة posix'ish (ios ، android ، linux ، إلخ). ناهيك عن أن WinARM يدعم فقط مجموعة تعليمات Thumb-2 ، وكما أفهمها فإن dart jit تستخدم مجموعة تعليمات ARM (على الرغم من أنني بحاجة إلى الحصول على تحقق رسمي من ذلك). سيكون تشغيل الميناء جهدًا كبيرًا إلى حد ما.

Jakesays هل حاولت تمكين / appcontainer كجزء من تجربتك؟

لقد ذكرت أعلاه "ما زلنا نقيم UWP كهدف" - أود أن أعرف ما الذي اكتشفته.

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

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

هل تغيرت هذه المحادثة الآن بعد أن أصبح Windows 10 X شيئًا؟ سيكون Win32 قادرًا على العمل على Windows 10 X ولكن أعتقد أن UWP سيكون أفضل بكثير. هل خطة Flutter تدعم الجهاز بشاشة مزدوجة على الإطلاق؟ Surface Duo و Surface Neo؟

nerocui كما أفهمها ، فإن Duo هو جهاز يعمل بنظام Android لذا أتخيل أن Flutter سيعمل بشكل جيد (على الأقل على شاشة واحدة). لست متأكدًا من وحدة المعالجة المركزية التي يعمل بها Neo ، ولكن إذا كانت ARM ، فإن Flutter ميت إلى حد كبير في الماء. لا يُنشئ Dart حاليًا رمز تجميع متوافق لـ winarm (يستخدم winarm إرشادات الإبهام 2 حصريًا ، ويستخدم IIRC Dart كلاً من الإبهام 2 وتعليمات الذراع). سيكون مهمة غير تافهة لجعلها تعمل.

JakeSays Neo استخدم Intel Lakefield لذا فهو x86. أنا مهتم أكثر بجزء UWP من القصة. على جهاز محمول مثل Neo ، ستكون دورة الحياة المُدارة من طراز تطبيق UWP مفيدة. لن يكون Win32 مثالياً لعمر البطارية. أيضًا ، سيتم تشغيل تطبيقات win32 على Neo في حاوية ، وهو أمر سيء للأداء. استهداف UWP هو في الواقع خطوة ذكية حقًا. يعمل كل من Android و iOS على نموذج تطبيق مُدار ، يجب أن تحقق UWP مزيدًا من الاتساق. يمكن تجاهل Windows 8 إلى حد كبير ، ولا تظهر أي من الإحصائيات أي حصة سوقية ذات مغزى.

nerocui حسنًا ، إذًا سيكون من الممكن الحصول على الرفرفة لاستهداف UWP. أكبر مشكلة هي عدم وجود دعم OpenGL في UWP ، ولكن يجب أن يكون ذلك قابلاً للحل باستخدام ANGLE أسفل الرفرفة.

كنت أبحث في UWP لكن هدفي كان ARM / WinIOT.

يجب أن يكون JakeSays UWP مناسبًا لمعظم الأجهزة ، ولكنه يمثل مشكلة لنظام Windows على ARM. بقدر ما هو مثير للسخرية ، فإن رفرفة UWP (إن وجدت) يجب أن تظل محاكية على أجهزة Windows القائمة على ARM. ما هو مستوى الإنجاز الذي حققته لمنفذ الرفرفة / uwp؟

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

في حين أن UWP مرغوب فيه بالتأكيد ، فإن Win32 بالتأكيد لن يذهب إلى أي مكان. أعلنت Microsoft مؤخرًا أنها تضيف دعم Win32 إلى متجر Windows. أيضًا ، يستمر تطوير العديد من الألعاب ضمن النظام الأساسي Win32.

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

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

البطارية مهمة للأجهزة المحمولة مثل الكمبيوتر المحمول أو جهاز Windows 10x

يجب أن تكون هذه محادثة بسيطة:

اعتبارًا من 14 يناير ، هناك 0 إصدارات مدعومة من Windows لا تدعم UWP.

هناك إصدارات رئيسية من Windows لا تدعم تطبيقات win32 التي يتم نشرها عليها في المتجر أو غير ذلك.

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

لكن الرفرفة هي رمز جديد تمامًا.

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

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

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

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

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

stuartmorgan هل أنت على علم بأي مناقشات حول حل للإبهام 2 فقط قيود winarm؟

يمكن استخدام stuartmorgan UWP في تطبيقات win32 / Winforms / WPF. جزر XAML مباشرة ومدعومة جيدًا. لا يعمل Win32 على winarm كما تم تحديده بواسطةJakeSays. وبالتالي فإن حجتك لا معنى لها وليست مبررًا للرفرفة التي تستهدف واجهة برمجة تطبيقات قديمة في حالة تضمين الرفرفة في التطبيقات القديمة.

علاوة على ذلك لجميع التطورات الجديدة:

قاعدة تثبيت Windows 7 تتساقط مثل الحجر. WinARM على وشك الارتفاع بشكل كبير في العام المقبل. سيكون Windows 7 أقل من 5٪ من سوق Windows (أقل من 50 مليون جهاز ولا يوجد أي من الأجهزة التي تدفع مقابل البرامج) بحلول يوليو بالمعدلات الحالية) وستنتقل إلى الأسفل مع نظامي التشغيل Windows XP و Vista (تقريبًا بسبب الأنظمة المضمنة حيث لن يقوموا أبدًا بطرح تطبيق جديد قائم على Flutter دون استبدال نظام التشغيل به بسبب نقص الدعم.

توضح بياناتك ونهج Win32 هذا فشلاً في فهم كيفية توسيع إصدارات Windows ثم إسقاطها (قبل المراجعات اللانهائية لنظام التشغيل Windows 10 ، والتي تحتوي جميعها على UWP لذا فإن هذا التدفق غير ذي صلة):

1. تم إصدار إصدار جديد ، اعتماد بطيء جدًا على الأجهزة الجديدة فقط وفقط في مساحة المستهلك.
2. (Win 7 => 10) يتم تحديث الأجهزة الاستهلاكية بسرعة أكبر وتنمو حصتها في السوق.
3. النمو مقيد من قبل خبراء التكنولوجيا الذين لا يحبون التغيير بدعوى أن الإصدار الجديد أسوأ من الإصدار القديم على الرغم من أنه ليس كذلك.
4. تستمر الشركات في البقاء على الهامش حيث يكتسب الإصدار الجديد حصة أغلبية في السوق في مساحة المستهلك.
5. تعلن Microsoft عن تاريخ تقاعد الدعم والتصحيحات للإصدار القديم من Windows حيث يبدأ المستهلكون في تجاهل خبراء التكنولوجيا ويدركون أن الإصدار الجديد أفضل بكثير من الإصدار القديم. تصل نسبة التبني إلى حوالي 50٪.
6. الشركات من خلال الضغط من المستخدمين الذين يحبون الإصدار الجديد بطريقة أفضل ؛ البرنامج الذي يعمل بشكل أفضل على الإصدار الجديد ؛ والموعد النهائي الذي يلوح في الأفق للتقادم يبدأ في نشر إصدار جديد على الأجهزة البديلة. يصل معدل التبني إلى حوالي 60-65٪
7. التفكير المستقبلي يبدأ مديرو تكنولوجيا المعلومات في تنفيذ عمليات نشر محكومة للإصدار الجديد على أساس مجموعة تلو الأخرى.
8. تلوح في الأفق أشهر ، وبقية مديري تكنولوجيا المعلومات قاموا بتدويرها ، وتهتموا بالمشاكل لأنهم لم يخططوا لها بشكل صحيح وانتقدوا Windows (هؤلاء هم خبراء التكنولوجيا من الأعلى) لمشاكلهم. ترتفع حصة السوق من 65٪ إلى 90٪ في 6-8 أشهر مع اكتمال الاندفاع في الموعد النهائي للحصول على الدعم.
9. الأنظمة الوحيدة المتبقية هي الأنظمة المضمنة التي تدفع مبلغًا إضافيًا مقابل تصحيحات الأمان بسبب التكلفة العالية لاستبدال هذه الأنظمة التي كانت عبارة عن أجهزة مصممة لنظام التشغيل السابق وتتطلب بشكل عام استبدال الأجهزة.
10. تبدأ الأنظمة المضمنة في التعرض للاختراق ، لذلك تقوم الشركات بفوائد من حيث التكلفة وتبدأ في استبدال الأجهزة.
11. فقط الأشخاص الذين تركوا يستخدمون نظام التشغيل هم دول العالم الثالث التي لا يمكنها استخدام أي شيء آخر ولا يمثل التعرض للاختراق مشكلة.

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

هكذا:

1. تعالج جزر XAML تطبيقات win32 المتزايدة مع رفرفة بداخلها. وسيستخدم 0 ٪ تقريبًا من الأشخاص الذين يشترون (ولا يسرقون) البرامج بالفعل نظامًا أساسيًا لا يمكنه استخدام جزيرة XAML بحلول شهر سبتمبر من هذا العام عندما يكون سطح المكتب الرفرف مستقرًا بدرجة كافية للإنتاج.
2. لا يوجد سوق منطقي لاستهداف Windows 7 لتطبيق جديد. بالتأكيد لا أحد لديه أي فهم للتاريخ وكيفية عمل سوق سطح المكتب بين المستهلك والشركات سيكتب تطبيقًا جديدًا في win32 ما لم يكن هناك مانع مطلق لواجهة برمجة التطبيقات (وهو أمر مشكوك فيه للغاية أن واجهات برمجة التطبيقات يتم عكسها إلى حد كبير الآن). وحتى لو فعلوا ذلك ، فسيتم تشغيله على نظام التشغيل Windows 10 ، وبالتالي لا يوجد سبب يمنعهم من استخدام XAML Islands للرفرفة في تطبيق win32 هذا.

وبالتالي ، فإن قرار الرفرفة لاستخدام Win32 أمر سخيف ويظهر فشلًا تامًا في فهم سوق Windows. (وهذا ليس مفاجئًا الخروج من Google للأسف)

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

إن تشغيل Flutter على winarm ليس مجهودًا تافهًا ، كما تمت الإشارة إليه عدة مرات في هذا الموضوع. يعد تشغيل Flutter على نظام Win32 مسعى تافهًا إلى حد ما لأنه يتطلب تغييرات طفيفة لرفرفة نفسه. من المنطقي أن تبدأ بثمار معلقة منخفضة (win32) ، لا سيما بالنظر إلى أن معظم الاهتمام الذي رأيته بخصوص Flutter والنوافذ كان كل شيء يتعلق بسطح المكتب. هذا ليس له علاقة تذكر بـ win32 vs uwp وأكثر من ذلك يتعلق بحقيقة أن هناك الكثير من أنظمة win32 هناك الآن.

JakeSays لا يسمح WinArm بنشر تطبيقات win32 في المتجر على Arm. (بخلاف المكتب) بصرف النظر عن مشكلات الترجمة.

أي جزء من ادعاءاتي لم يتم إثباته؟ البيانات 100٪ تدعم موقفي. بحلول الوقت الذي يصبح فيه Flutter لسطح المكتب جاهزًا للإصدار على Windows ، سيكون هناك 5٪ أو أقل من أجهزة Windows التي لا يمكنها تشغيل UWP والطن الذي لا يمكنك نشر تطبيق win32 عليه. (على سبيل المثال ، جميع أجهزة ARM بما في ذلك Duo أو Neo أو أي جهاز يعمل بنظام windows ، وجميع إصدارات الجهات الخارجية التي يتم تكثيفها.)

لا ينبغي أن يكون تشغيل الرفرفة تحت UWP الذي يعمل على WinArm و WinX64 و WinX86 أكثر صعوبة من win32. كما أنه يتيح لك التدقيق الإملائي في مربعات النص وما إلى ذلك ، والتحجيم المناسب بناءً على DPI بدون بطولات ، ودعم ثقافي أفضل خارج الصندوق. (ناهيك عن أن تشغيل الوسائط أفضل وأسهل إلى حد كبير من win32. أي يمكنني تشغيل مقطع فيديو مشفر على نطاق واسع ، وجاهز للتشغيل ، ومشفر AES بشكل تافه مع ثلاثة أسطر من التعليمات البرمجية في UWP. والقيام بنفس الشيء في win32 يعد غاية هائلة. عدم قول أي شيء عن التسميات التوضيحية .

لا توجد "ثمار معلقة منخفضة" مع نظام التشغيل Win32 مقابل UWP. UWP هو سطح المكتب. كل شيء آخر هو سطح مكتب قديم. (بخلاف Silverlight من الواضح) لقد عادوا إلى نقل UWP وواجهات برمجة التطبيقات الخاصة بالمنصات القديمة لدعم الشركات التي لا تعيد كتابة تطبيقاتها. لقد أضافوا جزر XAML لحالة الاستخدام الموضحة تمامًا لإضافة Flutter إلى التطبيقات الحالية (وأي شيء UWP آخر).

"هناك الكثير من أنظمة win32 الموجودة الآن".

وإليك كيف يبدو الرسم التخطيطي في سبتمبر: سيتم إغلاق 5٪ من الأشخاص الذين يشغلون النوافذ بحلول سبتمبر. من بين هؤلاء الـ 5٪ تقريبًا ، لا يشتري أي منهم برامج تستند إلى البيانات التاريخية. بحلول أكتوبر ، سيستخدمه 5٪ من مستخدمي windows على ARM من نوع ما وسيتم حظره من Win32.

لذا اختر السم.

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

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

هذا يسمى التفكير العكسي.

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

قل لي أين أنا مخطئ بالفعل. وحتى إذا كانت افتراضاتي وتوقعاتي بعيدة بعض الشيء ، أخبرني كيف أن تأكيدي بمرور الوقت ليس صحيحًا وأقل ضررًا وعمل أقل من البديل الذي هو عمل أكثر إلى حد كبير ، وأخطاء أكثر بكثير ، ووقت أصعب بكثير للوصول إلى التكافؤ مع منصات أخرى بمرور الوقت لأشياء مثل الفيديو والتدقيق الإملائي وما إلى ذلك. بغض النظر عن كيفية تقسيمها ، بحلول هذا الوقت من العام المقبل لن يستخدم أي شخص Windows 7. وهذا يعني أن Flutter سيكون متاحًا بنسبة 100٪ للجميع تقريبًا في كل الوضع إذا تم ذلك في UWP وليس win32. مقابل win32 الذي يلبي احتياجات نظام التشغيل الميت ويقفل مطوري الرفرفة من السوق الجديدة والمتنامية لـ WinARM.

على سبيل المثال ، يمكنني الآن ، في UWP ، إنشاء مشغل فيديو به جميع وظائف مشغل الفيديو الحالي ، بالإضافة إلى التسميات التوضيحية بالإضافة إلى DRM في UWP في بضع دقائق مع الوثائق الممتازة التي يمكن أن يستهلكها Flutter كجزء من مكتبة الفيديو رفرفة. أعرف حقيقة أنهم يعملون على التسميات التوضيحية وإدارة الحقوق الرقمية لمشغل الفيديو الرفرفة في الوقت الحالي. ولست بحاجة إلى معرفة أي شيء سوى مكالمات UWP. هذا يعني أنه من التافه توفير وظائف فيديو كاملة في Flutter مع UWP وتقريباً يمكن لأي C # القيام بذلك وهي مجموعة كبيرة من الأشخاص مقابل أولئك الذين يعرفون كيفية استخدام C ++ ، وإنشاء أسطح DirectX ، وإنشاء أجهزة تشفير / وحدات فك تشفير / محولات وسائط ووسائط ربط كل شيء. (نعم ، في win32 لا يمكنك تشغيل الكثير من التنسيقات بدون مكتبات مخصصة مدعومة خارج الصندوق في UWP) الجهد المبذول لإنشاء نفس المنتج بين UWP (حتى لو كان مكتوبًا بلغة C ++) مقابل win32 هو حوالي 1/100 من مقدار الوقت.

وينطبق الشيء نفسه على الاتصالات التسلسلية ، والبلوتوث ، وتتبع الموقع ، وما إلى ذلك ، وما إلى ذلك (وتتبع المواقع وواجهات برمجة التطبيقات الخاصة بالمستشعرات الآن ، في Windows 10 2020 / H1 ، قادمة إلى win32 ولن تعمل في الإصدارات السابقة من Windows 10 لذا فأنت تعتمد على كل شخص يستخدم أحدث إصدار من Windows 10 حتى يتمكن من الوصول إلى هذه الوظيفة ، مقابل 100٪ من المستخدمين في Windows 10 الذين لديهم حق الوصول إلى وظائف UWP لهذه واجهات برمجة التطبيقات). مع المكونات الإضافية لـ flutter لنظامي التشغيل Android / iOS وسترى نفس الشيء: تنفيذها أمر تافه في UWP مقابل win32 وبالتالي فمن المرجح أن يتم تنفيذها في UWP أكثر مما لو كتبت flutter لسطح المكتب في win32 بصرف النظر عن كل القضايا الأخرى.

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

stuartmorgan هل أنت على علم بأي مناقشات حول حل للإبهام 2 فقط قيود winarm؟

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

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

يستخدم التضمين الحالي لـ Windows بالفعل ANGLE ، وقد كان جيمس يقوم بتجربة دعم UWP منذ الأيام الأولى لعمله على هذا التضمين ، لذلك فإن هذا قد بدأ بالفعل.

stuartmorgan سأفعل ذلك.
ونعم لقد نسيت أن أداة تضمين النوافذ تستخدم ANGLE.

@ JohnGalt1717 ، يرجى مراجعة قواعد السلوك الخاصة بنا. تتطلب معايير مجتمع Flutter خطابًا احترافيًا ومحترمًا ، ونبذل قصارى جهدنا بنشاط لجعل الناس يشعرون بالترحيب.

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

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

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

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

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

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

إذا شعرت بالإهانة من تصريحات لم يتم الإدلاء بها عنك ، فأنا آسف لأنك تشعر بهذه الطريقة. ربما يكون الحل هو أخذ موقفي على محمل الجد والتفكير فيه بشكل منطقي وإثبات أنك بالفعل أخذت هذه الحقائق في الاعتبار ولست جاهلاً بها ولديك خطة طويلة المدى لكيفية عمل win32 على النوافذ التي تتطلب store وهذا المتجر لا يسمح بنشر تطبيقات win32 arm. وأن النفقات العامة لاستخدام Win32 ستضمن أن تكون النوافذ دائمًا خلف الأنظمة الأساسية الأخرى حيث تقوم بخفض المساهمين المحتملين بنسبة 90 +٪ مع هذا الاختيار. عندها سيكون من الواضح أنك لست جاهلاً ولا تفكيرًا متخلفًا ، وبالتالي فإن ما قلته لا ينبغي أن يسيء إليك.

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

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

كان جيمس يقوم بتجربة دعم UWP منذ الأيام الأولى لعمله على هذا التضمين ، لذلك فإن هذا يجري بالفعل.

stuartmorganclarkezone هل هناك أي مثال متاح للجمهور لتشغيل Flutter على UWP ؟ أرغب في تجربة ذلك حتى لو كان في مراحل مبكرة جدًا.

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

شكرا لك على الرد السريع clarkezone

لقد وجدت في مفترق FDE الخاص بك فرعًا يسمى uwptest . هل هي التي تقوم بتجربتها؟ أرغب في متابعة تحديثاتك على هذا الطريق.

NP ، نعم ، هذا هو فرع FDE. على المدى القصير ، سيكون هناك الكثير من القرصنة المؤقتة لإثبات بعض النظريات.

مرحبًا ،clarkezone! هل يمكنني أن أسأل ، هل عملك مدعوم من Microsoft؟ هل نتوقع أن تدعم Microsoft Flutter لإنشاء تطبيقات Windows؟ إذا كان الأمر كذلك ، فهل هناك أي خطط لإتاحة UI Fabric لـ Flutter؟

أعتقد أنه في الآونة الأخيرة كان هناك اهتمام متزايد ببناء برامج مؤسسية جميلة لتحسين مشاركة / رضا الموظفين. أنا أعمل حاليًا على عدد من هذه المشاريع. مؤخرًا ، أصدرنا تطبيق Android المستند إلى Flutter لإحدى الشركات المالية الأربع الكبرى. بينما تميل هذه المؤسسات إلى استخدام C # و Xamarin لبرامجها الداخلية ، فإنها تتوقع جودة أعلى من واجهة المستخدم لتطبيقات الأجهزة المحمولة لتجربة مكان العمل - وفي هذه الحالة ، يثبت Flutter أنه خيار أفضل. في الوقت نفسه ، تنتج Microsoft أجهزة رائعة مستخدمة في بيئة الشركة يمكنها تشغيل تطبيقات Flutter ، لذلك سيكون من الرائع رؤية المزيد من الدعم من Microsoft و / أو Google لتحقيق ذلك.

مرحبًا Lukasz. عملي غير مدعوم بمرض التصلب العصبي المتعدد ، إنه يتم على أساس شخصي في أوقات فراغي. اتفق على نقاطك الأخرى بالتأكيد. FWIW لقد أحرزت بعض التقدم الجيد ، لدي نموذج أولي Flutter runner يعمل من طرف إلى طرف للإخراج / التقديم (لا يوجد إدخال حتى الآن) ، المهمة الكبيرة / التالية التي أعمل عليها حاليًا هي جعل ارتباط كل شيء بشكل صحيح دون سحب في user32 / gdi32 وما إلى ذلك .. هذه الخطوة مطلوبة لتكون قادرًا على رؤية النموذج الأولي يعمل بنجاح على الأجهزة غير المكتبية مثل XBOX و Windows 10x المحاكي ويثبت أنه (آخر) yak shave :-)

الرجاء إضافة متجر Windows !!!!

@ daniele777 هذا ما كنت أعمل عليه ؛-) تحديث الحالة: انخفض من 84 خطأ في الرابط إلى 10

هل يمكنني المساعدة ؟؟ إلى improove المشروع ؟؟ يمكن أن تفعل لي المهمة؟

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

كل الحق كل خير!

لا أستطيع الانتظار حتى يصل هذا إلى هنا عاجلاً. لقد جربت رفرفة Win32 الحالية على النوافذ. OMG العرض منقسم لدرجة أنه بدا وكأنه تصميم حديث ولكنه تم تنفيذه باستخدام إطار عمره 10 سنوات. إنه ليس شيئًا يتوقع المرء رؤيته على شاشة 4K. نظرًا لاستخدام الحواف الناعمة على النص في تطبيقات UWP وتطبيقات الويب الحديثة ، يبدو عرض win32 قديمًا للغاية.

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

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

nerocui يرجع ذلك إلى أن تطبيقات win32 لا تحتوي على مقياس DPI مناسب مقارنةً بـ UWP. من الممكن مع الكثير من العمل لجعل عرض نص win32 يعمل بشكل صحيح ، لكنه صعب للغاية.

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

win32 هو الشيء الوحيد الذي يجعل التطبيقات قبيحة

كما قال dnfield ، من المستبعد جدًا أن يكون هذا هو الحال. يتم إجراء عرض Flutter text بالكامل بواسطة Skia ، في سياق GL (تم تغيير حجمه بشكل مناسب لـ DPI). لن يؤدي إنشاء سياق GL باستخدام واجهات برمجة تطبيقات UWP إلى تغيير العرض.

يرجى تقديم خطأ باستخدام لقطات شاشة تسلط الضوء على المشكلات التي تصفها.

قد يكون الأمر بسيطًا مثل التضمين الذي يتجاهل علامة anti-alias في مكان ما على سبيل المثال. لكن بدون خطوات للتكاثر لا يمكننا الجزم بذلك.

https://github.com/flutter/flutter/issues/53308
القضية المحفوظة. يرجى معرفة ما إذا كانت معلومات دقيقة / كافية.

أعتقد أنه إذا قمت بتعيين نقطة لكل بوصة على 150٪ أو أسوأ 175٪ وقمت بتحميل بعض النصوص ، فسترى ذلك.

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

جاهز للنشر في متجر windows؟ أي أخبار؟

لا ، غير جاهز للنشر في المتجر. تعمل وحدات البكسل والمدخلات على XBOX و Windows 10x. لا يزال يتكرر على API. لا يزال هناك الكثير من العمل المتبقي.

لقد كنت أفكر في طريقة مختلفة قليلاً - لم أجربها بعد ولكن قد أفعلها إذا وجدت بعض وقت الفراغ - ماذا عن استخدام Flutter للويب مع Skia WASM على سطح المكتب (والذي يمكن أن يدعمه Blazor)؟ يمكنني التفكير في أن الوصول المحدود إلى الإدخال / الإخراج يمثل جانبًا سلبيًا واحدًا ، ولكن يجب أن يعمل عرض واجهة المستخدم الفعلي ومعالجة الأحداث كما هو متوقع. يبدو أن Windows لديه دعم جيد لـ PWAs (وكذلك نظام التشغيل Chrome OS) ، وقد يكون هذا النهج أسهل في التنفيذ مع الاستمرار في تحقيق أداء جيد.

lukaszciastko لا ، سيكون هذا إلكترونًا آخر. يجب تحويل Flutter إلى نافذة Windows أصلية (HWND) ، والتي بدورها يمكن تضمينها في أي نوع من تطبيقات Windows الأصلية (win32 ، Winforms ، wpf).
لا ينبغي اعتبار IMHO uwp نوعًا رئيسيًا من تطبيقات Windows. حتى MS لم يفعل ذلك.

clarkezone لا أطيق الانتظار حتى أرى عملك يتم إدخاله في المشروع حتى نتمكن من التطبيقات التي تعمل على Windows

حتى نتمكن من التطبيقات التي تعمل على Windows

من الممكن بالفعل تشغيل تطبيقات Flutter على نظام التشغيل Windows ، وكان ذلك متاحًا لبعض الوقت. هذه المشكلة الآن على وجه التحديد حول UWP.

سوف أقوم بتحديث العنوان لتوضيح ذلك.

حتى نتمكن من التطبيقات التي تعمل على Windows

من الممكن بالفعل تشغيل تطبيقات Flutter على نظام التشغيل Windows ، وكان ذلك متاحًا لبعض الوقت. هذه المشكلة الآن على وجه التحديد حول UWP.

سوف أقوم بتحديث العنوان لتوضيح ذلك.

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

steskalja لديك بعض المستندات هنا https://github.com/flutter/flutter/wiki/Desktop-shells#create
في السيرة الذاتية ، يجب أن تكون في الفرع master وتقوم بتشغيل:
flutter config --enable-windows-desktop

في المشروع الذي تريد تجربته:
flutter create . // سيتم إضافة مجلد windows ، كن حذرًا مع التغييرات في مجلدات android و ios ،
flutter run -d windows

بشكل أكثر تحديدًا ، فكرتي حول هذا التطوير. هو الأمل في وجود علاقة ما مع Project Union. أنا أحب الرفرفة وسعيد جدًا لأن SDK هذا شيء. أنا قلق بشأن مستقبل تطبيقات Win32 في نظام التشغيل Windows.

ما هي القاعدة المعرفية التي يمتلكها فريق الرفرفة؟

عند الانتهاء من ذلك ، هل هذا يعني أنه يمكننا تنفيذ مكونات Flutter الإضافية في C # واستخدام أي واجهات برمجة تطبيقات (APIs) و SDK و NuGet من المكونات الإضافية لتطبيقات UWP؟

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

JakeSays من خلال فهمي ، تحدد بيئة التنفيذ (UWP في هذه الحالة) كيفية إنشاء المكونات الإضافية وما هو متاح للمكونات الإضافية. لذلك ربما تكون الإجابة على سؤالي هي "بالطبع" ، لكنني لست متأكدًا تمامًا.

في مكونات Android الإضافية ، يمكنك استخدام Kotlin (أو Java) وأي واجهات برمجة تطبيقات Android و SDKs والحزم. في مكونات iOS الإضافية ، يمكنك استخدام Swift (أو Objective-C) وأي واجهات برمجة تطبيقات iOS و SDK و Pods. أتوقع نفس الشيء مع UWP وسيجعل هذا رائعًا حقًا.

إن تسهيل استخدام المكونات الإضافية C # هو شيء نعتزم القيام به ، ولكنه متعامد مع دعم UWP.

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

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

والأسوأ من ذلك ، أن جميع أنظمة التشغيل Windows 10 S والمتغيرات لا يمكنها تشغيل تطبيقات win32 ، لذلك سيتم حظر الرفرفة من تلك التطبيقات. سيتم أيضًا حظرها من أجهزة ARM / ARM64 أيضًا ما لم يتم تشغيلها على UWP و Windows X التي تشغل تطبيقات win32 في حاوية عامل إرساء باستخدام سطح المكتب البعيد ، وستكون تجربة أسوأ بكثير من تطبيقات UWP الأصلية نتيجة لذلك ، خاصة عندما يتعلق الأمر بـ أداء الرسومات.

لذلك ، إذا كان google / flutter يتطلع إلى الأمام مع دعم Windows ، فسيكون UWP بالكامل من اليوم الأول والذي يسمح لـ C ++ و .NET (الغالبية العظمى من مطوري Windows يستخدمون .net وليس C ++) ويدعم جميع أجهزة windows الحالية والمستقبلية بأفضل التفاعل الممكن. نهج win32 الحالي قصير النظر وسوء البحث (مما يشير إلى وجود نقطة عمياء ضخمة حقًا داخل Google والتي تثير القلق نظرًا لمليارات + الأجهزة التي تعمل بنظام windows).

نظرًا لأن Skia تعمل بالفعل على UWP ، فليس هناك سبب وجيه لعدم كون هذا هو البيئة الفعلية وتركيز 100٪ من جهود Google على نظام التشغيل Windows. (وفي الحقيقة ، العمل مع Microsoft للحصول على محاكيات Xamarin عن بُعد بأكملها والنشر المباشر لأجهزة iOS على Windows التي تعمل أيضًا)

@ JohnGalt1717 لقد قدمت هذه الحجة عدة مرات في هذه القضية بالفعل ؛ تكراره ليس بناء. إذا كنت ترغب في تسريع تطوير دعم UWP ، فنحن نرحب بك للمساهمة فيه.

stuartmorgan سأكون فضوليًا لمعرفة أفكارك حول استخدام c #. لدي بعض الأفكار حول كيفية جعل هذا العمل.

تعد إضافاتkinex في الواقع مجرد رمز C يتفاعل مع flutter عبر واجهة برمجة تطبيقات بسيطة. لكتابتها في C # يتطلب أساسًا "ملحق .net" مكتوبًا بلغة C يستضيف CLR ويجسر عالم الرفرفة و c #. من الناحية النظرية ، سيكون من الممكن كتابة ملحقات flutter في java على windows ، أو أي لغة طالما يمكن تشغيل بيئة اللغة على نظام التشغيل الهدف.

JakeSays لقد قدمت https://github.com/flutter/flutter/issues/64958 مع أفكاري الحالية حول C # ، حيث يبدو أنني لم أقدمها هنا على ما يبدو. يجب على أي شخص مهتم بـ C # على وجه التحديد متابعة هذه المشكلة.

JakeSays طيب شكرا للتوضيح. بدون معرفة أفضل ، افترضت شيئًا كهذا: سيتم تحميل المكونات الإضافية C # (ربما يتم تنفيذها كمكتبات .NET؟) بواسطة عداء UWP ويمكن أن يتصل بها رمز Dart عبر عملية UWP runner. في هذه البنية التخيلية ، يمكن لمكونات C # الوصول إلى نفس واجهات برمجة التطبيقات و SDKs وحزم NuGet مثل أي مكتبة .NET يستضيفها تطبيق UWP.

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

kinex أنت محق في أن c # plugins سيكون لها حق الوصول إلى مجموعة مكتبات .net الكاملة ، بالإضافة إلى حزم nuget. عندما يتم تنفيذ كود c # يتم تشغيله في بيئة .net كاملة (أو .net core حسب الحالة).

FFI هو حل خفيف الوزن أكثر بكثير للمكونات الإضافية. راجع https://pub.dev/packages/win32 ، على سبيل المثال. لكن هذا بعيد عن الموضوع بالنسبة لمشكلة تتعلق ظاهريًا ببناء عداء قائم على UWP.

timsneath أعتقد أن ffi والمكونات الإضافية تحل مشكلتين مختلفتين. هناك الكثير من القيود على ما يمكنك فعله باستخدام ffi (على سبيل المثال ، متزامن).

مرة أخرى ، قدمت # 64958 لملحقات C # ؛ الرجاء متابعة أي مناقشة حول C # ولكن ليس UWP هناك.

أشياء جميلة تحدث
يجب على شخص ما إخبار Microsoft بالمساهمة هنا أيضًا

@ airbus5717 ماذا تقصد؟ تساهم Microsoft في المناقشة هنا طوال الوقت.

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

• أداة تضمين WinRT Flutter لإثبات صحة المفهوم باستخدام CoreWindow بالتزامن مع واجهات برمجة تطبيقات WinRT التي تعمل في صندوق حماية AppContainer: https://github.com/clarkezone/engine
• اختبار مماثل Flutter UWP runner (115 سطرًا فقط من c ++!) مع تجربة Flutter التجريبي باستخدام معرض Flutter : https://github.com/clarkezone/fluttergalleryuwp
• باستخدام هذه ، تمكنت من نشر إصدار حزمة MSIX من Flutter Gallery بنجاح إلى متجر Microsoft ، وتمرير اختبارات WAC API للحصول على شهادة المتجر (أخيرًا :-))

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

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

في المثال أدناه ، تمكنت من أخذ مصدر ساعة Flutter Particle من https://github.com/miickel/flutter_particle_clock ، وقم بإنشائه في وضع الإصدار الذي يستهدف Windows ، واستخدم app.so binary الناتج ، وقم بتجميعه من أجل UWP باستخدام نفس Flutter Runner كما هو مستخدم أعلاه لمعرض Flutter ، انشر على متجر Microsoft وقم بتثبيته على جهاز XBOX الخاص بي: