Microsoft-ui-xaml: 👩‍💻📞 WinUI Community Call (19 فبراير 2020)

لدي سؤال بخصوص تطوير Windows 10x. لتطويره أحتاج إلى المحاكي ، متى سيكون هناك دعم لمعالجات AMD (محاكاة افتراضية متداخلة)؟ هل يمكننا الاعتماد على إصدار Windows 10 2003؟

أكثر ارتباطًا بـ WinUI ، استنادًا إلى # 1958 ، ما هو مستقبل Live Tiles؟

يمنعني دعم AMD Ryzen من تشغيل المحاكي ، لذا سيكون من الجيد سماع أي كلمة حول موعد تصحيح ذلك.

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

هذه هي الصياغة الرسمية (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):

معالجات AMD غير مدعومة في الوقت الحالي. مطلوب المحاكاة الافتراضية المتداخلة لتشغيل Windows 10x في المحاكي ولا يدعم Windows هذا بعد على معالجات AMD. ابقوا متابعين!

إذا كنت تريد مزيدًا من المعلومات ، فمن المحتمل أن تتصل بـ [email protected]. أشك في أن WinUI هو الفريق الصحيح لطرح أسئلة محددة على Emulator.

شكرًا @ Felix-Dev - هذا صحيح ، المستندات هي أفضل مكان للحصول على أحدث حالة على محاكي 10X ، وعنوان البريد الإلكتروني هذا هو أفضل جهة اتصال لأسئلة 10x الأخرى غير الخاصة بـ WinUI.

عادل بما فيه الكفاية ، سيتعين عليك الانتظار حتى تصبح Microsoft جاهزة للتحدث عنها.

بالنظر إلى Windows 10x ، يتم تشغيل تطبيقات Win32 في حاوية VEIL. ماذا عن تطبيقات WinUI 3.0 بخلاف تطبيقات UWP؟

هل سيبدو أنها تعمل كما تفعل تطبيقات UWP الأصلية على 10x؟

mdtauk نظرًا لأن تطبيقات WinUI Desktop ليست تطبيقات UWP أصلية ، لا أعتقد أنها ستعمل في حاوية UWP. أعتقد أنهم سيعملون في حاوية Win32 المذكورة حيث سيكون لديهم (جميع) إمكانيات تطبيقات Win32.

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

mdtauk نظرًا لأن تطبيقات WinUI Desktop ليست تطبيقات UWP أصلية ، لا أعتقد أنها ستعمل في حاوية UWP. أعتقد أنهم سيعملون في حاوية Win32 المذكورة حيث سيكون لديهم (جميع) إمكانيات تطبيقات Win32.

هذا مخيب للآمال بعض الشيء. يبدو أن تطبيقات Win32 تُظهر سلوكًا مختلفًا للنافذة ، وتظلم الشاشة عندما تكون في المقدمة. لذا فإن التبديل أيضًا يسلك سلوكًا مختلفًا.

باستخدام Xaml UI ، نأمل أن يكون تطبيق WinUI Desktop هو أفضل سيناريو لكلا العالمين على الأقل على السطح للمستخدم

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

ومع ذلك ، سأكون سعيدًا بالتصحيح في حاوية تطبيق WinUI Desktop على 10x. يعتمد تفكيري الحالي على ما قيل لنا عن WinUI Desktop حتى الآن (نموذج تطبيق Win32) ، وعرض 10X How Windows 10X runs UWP and Win32 apps وتطبيقات اختبار جسر سطح المكتب. لسوء الحظ ، فشلت تطبيقات اختبار XAML Island الخاصة بي في التحميل على المحاكي حاليًا (عالق في المرحلة App Launch Initialized ) لذلك لا يمكنني التحقق من الحاوية التي سيستخدمونها. سأفاجأ إذا لم تكن حاوية Win32 على الرغم من أنها لا تزال تطبيقات Win32. كل هذا يقودني إلى الاعتقاد بأن تطبيقات WinUI Desktop ستعمل في حاوية Win32 على 10x.

إنه بالتأكيد سؤال جيد لطرحه على الفريق!

@ Felix-Dev وفقًا لنفس الفيديو الذي ذكرته (كيف يقوم Windows 10X بتشغيل تطبيقات UWP و Win32) في الدقيقة 20:18 يقول أن التطبيقات المختلطة (Win32 / UWP) غير مدعومة (حتى الآن؟) وما أفهمه هو أن التطبيق الذي يستخدم XAML Island هو تطبيق مختلط.

س 1) متى ستتوفر SwapchainPanel في WinUI؟ هذا ضروري للغاية لما أفعله أنا والعديد من الآخرين.

Q2) نظرًا لأن SharpDX لم يعد مدعومًا من قبل منشئها بعد الآن ، فهل ستكثف Microsoft وتوفر التوافق بين أسطح عرض أجهزة SharpDX و WinUI؟ هل ترى MS قصة لعرض الأجهزة باستخدام C # بدون SharpDX؟ وأنا لا أهتم بالوحدة ، أعني تطوير الرسومات بشكل حر وغير مقيد ، لصنع أدوات الرسومات الخاصة بنا والمحركات والألعاب غير التابعة للوحدة في C #. ولا أقصد أيضًا Win2d ، فأنا أحتاج إلى إمكانية عرض الأجهزة الكاملة (DirectX).

Q3) تفتقر التطبيقات إلى القدرة على إيقاف تشغيل النوافذ المنبثقة TaskBar و TitleBar عند تحريك الماوس إلى الحافة العلوية والسفلية للشاشة. يعد هذا بمثابة كسر للصفقات للعديد من الألعاب (وربما بعض التطبيقات) التي تستخدم حافة الشاشة في واجهة المستخدم الخاصة بها لأشياء مثل لوحة الكاميرا أو النوافذ المنبثقة. متى سيتم إصلاح ذلك (قد تكون هذه مشكلة في Windows ، ولكن يجب أن تكون مدفوعة بواجهة برمجة التطبيقات ، لذلك فهي ذات صلة بـ WinUI).

Q4) هل يمكننا الحصول على WinUI لتضمين نموذج تطبيق CoreWindow (IFrameworkView) عندما نريد تجاوز Xaml والعرض مباشرة إلى Swapchain المرتبط بالنافذة.

قد يبدو الأمر غريبًا بعض الشيء ، حيث تطلب من WinUI توفير سطح غير Xaml. لكنني أعتقد أن CoreWindow ينتمي إلى XamlWindow (يسمى Window in UWP) في نفس المكتبة ، منفصلة أيضًا عن UWP لإتاحته في .net 5. بافتراض أن .net 5 سيكون قادرًا على استهداف غير uwp وكذلك uwp. لا يوجد حاليًا نموذج تطبيق C ++ حديث خارج UWP - يجب أن يستخدم مطورو الألعاب كود c القديم (Win32) لكتابة طبقات التطبيق للألعاب أو تطبيقات الرسومات. ولا يوجد أيضًا نموذج تطبيق سطح مكتب حديث في .net core. حل UWP لـ CoreWindow فعال ومريح في الاستخدام. يحتاج فقط إلى الوجود خارج UWP (لكل من C ++ / non-uwp و .net 5). فائدة أخرى لسحب CoreWindow من UWP هي أنه يوفر طريقة مباشرة لكود المنفذ من UWP إلى .net 5 (و C ++ إذا حصل على نموذج تطبيق حديث غير uwp).

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

ومزيد من التعليقات من الإصدار 1215

إذا قمت باستبدال Win32 Window بـ CoreWindow لسيناريوهات غير مضمنة / غير Xaml ، وقمت أيضًا بتوفير CoreWindow لـ .Net 5 Non-UWP ، فيمكننا الحصول على نموذج تطبيق / نافذة موحد عبر Windows للعمل غير Xaml. هذا منطقي أكثر من التمسك بـ Win32 FOR EVER أو إنشاء نماذج تطبيقات جديدة.

لماذا يتعين علينا إعادة كتابة طبقة التطبيق لمجرد أننا نريد التبديل بين التنفيذ المحتوي وغير المحتوي (على سبيل المثال بين UWP و Win32) - هذه مشكلة نموذجية تواجه مطوري اللعبة اليوم ، ولا يمكنهم الالتزام بـ UWP لأنهم بحاجة إلى حرية توزيع Win32. لذلك يضطرون إلى استخدام نماذج تطبيقات HWnd أو .Net Framework. إذا كان نموذج تطبيق / نافذة UWP متاحًا للتطبيقات غير المضمنة في uwp ، فلا توجد مشكلة ، يمكننا كتابة نفس الكود لطبقة التطبيق وتجميعه لكل من MS Store والمتاجر الأخرى من نفس قاعدة الكود.

leoniDEV لا يزال الكثير من هذا موضوع Twitter هذا على سبيل المثال حيث يقال إن تطبيقات XAML Island لا تنتمي إلى هذه الفئة (يعمل Matteo Pagani في Microsoft كـ Windows AppConsult Engineer ). قال موظف MS في مجتمع UWP إن دعم تطبيقات UWP التي تشغل عملية ثقة كاملة Win32 لن يتم دعمه يومًا ما 1 ولكن من المخطط إضافته لاحقًا.

@ Gavin-Williams سيكون هناك نوعان من النكهات WinUI: WinUI UWP و WinUI Desktop. باستخدام WinUI UWP ، ستتمكن من إنشاء تطبيقات UWP كاملة والتي سيتم تشغيلها في حاوية UWP على Windows 10x. ثم هناك WinUI Desktop الذي سيمكن تطبيقات Win32 من الوصول الكامل إلى UWP UI APIs (XAML ، التكوين ، الإدخال ، ... - باستثناء عدد قليل من واجهات برمجة التطبيقات مثل CoreWindow ) أيضًا. لا يتعين على هذه الأنواع من التطبيقات التعامل مع وضع الحماية الخاص بـ UWP أو قيود التصميم الأخرى الخاصة بـ UWP. نظرًا لأنها ليست تطبيقات UWP ، فإن تطبيق WinUI Desktop لن يكون قادرًا على استهداف مجموعة واسعة من فئات أجهزة Windows 10 التي يمكن لتطبيق UWP القيام بها.
انظر الصورة أدناه مأخوذة من خارطة طريق WinUI للحصول على نظرة عامة جيدة:

تمت كتابة WinUI بلغة C ++ من الألف إلى الياء بحيث يمكن استخدامها في سياق تطبيق غير مُدار.

كما أكدت أعلاه ، فإن كتابتي I believe they will run in the mentioned Win32 container تعتمد فقط على فهمي الحالي لـ WinUI Desktop ، وتطبيقات اختبار جسر سطح المكتب والفيديو 10X التي قمت بتشغيلها على 10x. ليس لدي معرفة من الداخل. سيعلمنا فريق WinUI بالتأكيد ما هي الخطة مع تطبيقات WinUI Desktop والحاوية 10x المستخدمة ويسعدني أن يتم تصحيح هذا الأمر هنا وإخباري أنه نعم ، سيتم تشغيل تطبيقات WinUI Desktop في حاوية UWP على 10x.

أود أن أسمع المزيد عن أي أفكار حول إمكانية استخدام لغات برمجة أخرى ، مثل Java و Python و JavaScript وما إلى ذلك ، عند إنشاء تطبيقات باستخدام WinUI / Microsoft UI.

أعلم أن هناك مشروعًا يسمى Xlang (لغة متقاطعة) - والذي يبدو أساسًا مثل ما يجب أن يكون عليه .NET ، وهو COM أفضل.

كيف يرتبط ذلك بـ WinUI؟

xlang هو في الأساس إصدار مفتوح المصدر عبر الأنظمة الأساسية من Windows Runtime (WinRT) ، على الرغم من أنه لن يكون متوافقًا تمامًا. الغرض من WinRT هو ما قلته ، إمكانية التشغيل البيني بين اللغات ، وهو قائم على COM. تم بناء واجهات برمجة تطبيقات WinUI على WinRT وهي الطريقة التي تدعم بها C ++ و C #. هناك لغات أخرى بمستويات مختلفة من الدعم لـ WinRT ، بما في ذلك Python و Rust (هذه لغة عملت عليها شخصيًا) وجافا سكريبت ، ولكن على حد علمي لا يدعم أي منها (حتى الآن) WinUI - دعم WinUI صعب بشكل خاص نظرًا لأن تكوينها وواجهات برمجة تطبيقات XAML تعتمد بشكل كبير على ميزة نظام النوع تسمى الأنواع القابلة للتركيب (بشكل أساسي شكل من أشكال وراثة التنفيذ) والتي لا تستخدمها واجهات برمجة تطبيقات WinRT و UWP الأخرى والتي قد يكون من الصعب تعيينها لأنظمة أنواع اللغات الأخرى.
يعمل Kenny Kerr ، مبتكر C ++ / WinRT ، على إسقاط Rust WinRT جديد الآن.

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

xlang تبدو ميتة بالنسبة لي. لم تنتهِ C ++ / WinRT حقًا - لقد تركت بها أخطاء وقصة استخدام غريبة للغاية ، مما يجعلها غير مرغوب فيها للمطور العادي. لقد كافحت لساعات عديدة لتشغيل C ++ / WinRT ، وفشلت في القيام بما فعلته في 30 دقيقة باستخدام C ++ / CX. وكان C ++ / CX أسهل في الاستخدام من خلال تسديدة بعيدة. إذا أرادت Microsoft أن تكون هذه الأدوات متعددة اللغات قابلة للاستخدام من قبل الشخص العادي ، فإنها تحتاج إلى وضع فريق من الأشخاص على المشكلة وعدم ترك الأمر لكيني كير للقيام بكل العمل بنفسه. لديه بعض الأفكار الرائعة. لكن هذه الأدوات تحتاج إلى جاذبية واسعة ، وأعتقد أنه يحتاج إلى مساعدة لجعل هذه المنتجات تصل إلى النضج وأن تكون كل ما في وسعها.

في الوقت الحالي ، UWP وخليفته WinUI غير جاهز لتطبيقات LOB

هناك العديد من المشاكل التي نواجهها

• أداء ضعيف. على سبيل المثال ، تكون خاصية تبعية WinUI أبطأ 50 مرة من https://github.com/microsoft/microsoft-ui-xaml/issues/1633 .
• أداء الترجمة ضعيف. عدة مرات أبطأ من wpf
• دوت نت أصلي
• الكثير من التغييرات الفاصلة بين الإصدارات.
• نموذج وضع الحماية والأذونات
• قدرة تخصيص محدودة لبائعي الأطراف ثلاثية الأبعاد مقارنةً بـ wpf

هل تعتقد أن WinUI يمكنه التغلب على هذه القيود وأن يصبح إطار عمل LOB التالي جاهزًا للسنوات العشر القادمة. أو حان الوقت للمضي قدمًا في تطبيق Electron Blazor)

لدي مشكلتان مع الوضع الحالي لـ WinUI.

لا تزال C ++ / WinRT تجربة مطور سيئة للغاية مقارنة بأدوات C ++ / CX وتجربة المطور الشاملة. إذا كان من المتوقع أن نتعامل مع مكونات WinUI المكتوبة بلغة C ++ ، فمن المتوقع وجود تغطية 1: 1 على الأقل لما يمكن أن توفره أدوات C ++ / CX.

كونك معياريًا C ++ 17 لا يفيدني إذا كان منتجي يعاني مقابل استخدام C ++ / CX فقط ، ويستغرق الأمر ضعف الوقت لكتابة مكون UWP أو واجهة مستخدم XAML.

الأمر الذي يقودني إلى سؤالي الثاني ، السبب الرئيسي لضرورة التعامل مع C ++ على UWP / WinUI ، هو أن Microsoft قد أسقطت الكرة في أي نوع من روابط DirectX مع لغات .NET. فهل ستوفر WinUI دعمًا لـ XNA مثل الاستبدال أو رسم المناظر ثلاثي الأبعاد WPF؟ من الواضح أننا لا نحصل إلا على صمت الراديو هنا ، ونُجبر على الدخول في مشاريع مجتمعية مثل MonoGame أو محركات كاملة النفخ مثل Unity.

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

في الوقت الحالي ، أصبح من الصعب جدًا الاستمرار في بيع حلم UWP ، حيث يتناقص عدد المستمعين حول صندوق الصابون الخاص بي.

متى تشق عناصر واجهة مستخدم Windows 10x طريقها إلى سطح المكتب Windows 10؟

carmellolb 2022-2025؟

تحرير: من المحتمل أن تقوم MS بحذف هذا ، لأنها تقترح جدولاً زمنيًا لتسليم المنتج ، وهو أمر غير موجود وبالتالي فهو مضلل ؛)

@ Felix-Dev "WinUI Desktop .. سيمكن تطبيقات Win32 من الوصول الكامل إلى واجهات برمجة تطبيقات UWP UI .. باستثناء عدد قليل من واجهات برمجة التطبيقات مثل CoreWindow.

باستثناء CoreWindow؟ OMG - هذا هو أول وأهم واجهة برمجة تطبيقات يجب سحبها من UWP. إنها أكثر واجهة برمجة تطبيقات تأسيسية توفر وظائف النافذة الأساسية. يجب أن تكون عالمية ، داخل وخارج حاوية UWP. حتى يتم طرحها ، لا يمكننا الحصول على قاعدة رمز مشتركة لطبقة التطبيق ونحن عالقون مع رمز Win32 c القديم في C ++ أو أيًا كان. net core سيوفر (فئة Window أخرى مرة أخرى؟) لـ C #.

الرجاء Microsoft - تمامًا كما تقوم بتوفير XamlWindow داخل وخارج UWP ، يرجى أيضًا توفير CoreWindow داخل وخارج UWP.

حول المكالمة: لماذا ابتعدت عن Teams؟ لم يعمل YouTube جيدًا في آخر مرة.

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

من https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216:

نهجنا هو أن WinUI 3 سيستخدم CoreWindow عند التشغيل في UWP و Win32 Window (HWind) عند التشغيل في سطح المكتب (Win32).

سيتمكن WinUI 3 في تطبيقات UWP من استخدام AppWindow APIs. بالنسبة لسطح المكتب ، ستكون هناك حاجة للخروج بشيء مماثل. ما زلنا نصمم هذا ، لذا ليس لدي المزيد من التفاصيل حتى الآن.

قال الفريق أيضًا إنه يتطلع إلى توفير واجهات برمجة تطبيقات مثل CoreApplicationViewTitleBar.ExtendViewIntoTitleBar لـ WinUI Desktop أيضًا حتى نتمكن من الحصول على أفضل ما في العالمين. القوة الكاملة لتصميم نوافذ Win32 (على سبيل المثال لا يوجد شريط عنوان / شريط عنوان مخصص 100٪ ، نافذة التطبيق <الحد الأدنى المطلوب للحجم ، لا يوجد زر شريط المهام ، ...) وواجهات برمجة تطبيقات التخصيص الحديثة UWP. (بالنسبة إلى UWP ، ربما يتعين علينا انتظار AppWindow V2 للحصول على إمكانيات نافذة قريبة من قدرات إطارات Win32 الحالية.)

jesbis سؤال بخصوص WinUI Desktop: في الإصدار https://github.com/microsoft/microsoft-ui-xaml/issues/1939 ، تمت الإشارة إلى أن تنشيط الإعلام المحمص لا يعمل مع تطبيقات سطح المكتب المجمعة MSIX على (على الأقل) 1909 كما ورد في الوثائق :

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

بينما يتعين علي الانتظار ومعرفة ما إذا كان الإصلاح المذكور سيتم نقله إلى إصدارات نظام التشغيل المتأثرة لتطبيقات جسر سطح المكتب ، فإن سؤالي هو: هل ستوفر تطبيقات WinUI Desktop ميزة تنشيط التوست الجاهزة المذكورة أعلاه (لذلك دون الحاجة إلى استخدام a COM Activator) على جميع إصدارات WinUI المستهدفة لنظام التشغيل Windows 10؟ (أو أي مفهوم تنشيط نخب مماثل.)

@ Felix-Dev من الوثائق يبدو أن XAML Island لا تتضمن تطبيقًا هجينًا بشكل صارم ، يمكنك الاتصال بواجهة برمجة تطبيقات استضافة UWP XAML مباشرةً من تطبيق Win32 على حساب فقدان بعض الوظائف ، مثل استخدام عناصر التحكم المخصصة ، إذا فهمت المستندات بشكل صحيح (والملاحظة في المستندات):

استضف عنصر تحكم UWP قياسي في تطبيق WPF باستخدام XAML Islands

المكونات المطلوبة

المشروع وكود المصدر لتطبيقك. يتم دعم استخدام عنصر تحكم WindowsXamlHost لاستضافة عناصر تحكم UWP القياسية للطرف الأول في التطبيقات التي تستهدف .NET Framework أو .NET Core 3.

مشروع تطبيق UWP يحدد فئة تطبيق جذر مشتقة من XamlApplication . يجب أن يتمتع مشروع WPF أو Windows Forms بإمكانية الوصول إلى مثيل لفئة Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication التي توفرها مجموعة أدوات مجتمع Windows. يعمل هذا الكائن كموفر أساسي للبيانات الوصفية لتحميل البيانات الوصفية لأنواع UWP XAML المخصصة في التجميعات في الدليل الحالي للتطبيق الخاص بك.

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

لقد كافحت لساعات عديدة لتشغيل C ++ / WinRT ، وفشلت في القيام بما فعلته في 30 دقيقة باستخدام C ++ / CX

إذا كان من المتوقع أن نتعامل مع مكونات WinUI المكتوبة بلغة C ++ ، فمن المتوقع وجود تغطية 1: 1 على الأقل لما يمكن أن توفره أدوات C ++ / CX.

@ Gavin-Williams ، pjmlp هل فتحت إصدارات في cppwinrt repo الآلة الحاسبة ).

حول المكالمة: لماذا ابتعدت عن Teams؟ لم يعمل YouTube جيدًا في آخر مرة.

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

RE: CoreWindow ، ودعم win32 ، والحاويات - سنتحدث عن اتجاهنا الحالي أثناء مكالمة المجتمع غدًا مع @ marb2000 :)

سنحاول أيضًا الوصول إلى الأسئلة الأخرى حتى الآن (على سبيل المثال ، الوضع الحالي في مخطط SwapChainPanel الزمني ، Win2D / DirectX ، الجزر ، إلخ) - شكرًا على التعليقات والأسئلة حتى الآن!

jesbis شكرًا على عودتك إلينا.

لا توجد مشكلات يجب فتحها ، لأن نهج C ++ / WinRT في التطوير يتراجع تمامًا عن الإنتاجية التي توفرها C ++ / CX.

مع C ++ / CX اعتقدت في البداية أن Microsoft كانت تبيع Visual C ++ أخيرًا بالطريقة الصحيحة ، بعد 25 عامًا ، استحوذ Visual C ++ على تجربة RAD لـ C ++ Builder.

بدلاً من ذلك ، ما تعطيني C ++ / WinRT هو العودة إلى أيام ATL / WTL ، حيث يتعين علي كتابة MIDL المعياري ، على الرغم من أن MIDL 3.0 أفضل بطريقة ما أن MIDL الأصلي ، يجب أن يكتب يدويًا روابط UWP التي يتعامل معها C ++ / CX أنا.

لا يعني ذلك أن C ++ / CX مثالية ، فالطريقة التي تتعامل بها مع معالجات الأحداث لا تزال تفشل دون C # / VB.NET ، أو C ++ Builder لهذه المسألة.

UWP مرتبط على أي حال بنظام Windows ، لذا فإن وجود رابط C ++ خالص ليس شيئًا يشتريني إلى C ++ / Winrt ، بل أن أكون قادرًا على فعل الشيء نفسه تمامًا كما في C # أو VB.NET ، دون الحاجة إلى التعامل مع الكود الذي لا يزال يبدو وكأنه ATL / WTL.

وكما ذكرنا ، أنا مشغول فقط بـ C ++ لأن النداءات لفضح DirectX كمجموعة من مكونات UWP Runtime لا يزال يتم تجاهلها.

لذلك لا أشعر أن فتح المشكلات في cppwinrt سيؤدي إلى تحسين القدرة على استخدام C ++ / Winrt عبر Blend و Visual Studio بنفس سهولة C ++ / CX ، من الناحية المثالية مثل C # و VB.NET ، كما أتوقع أن يقوم فريق cppwinrt بتحويل مشكلة في فريق Visual Studio ، وتقليديًا (MFC / ATL / WTL) لم يهتم فريق أدوات C ++ أبدًا بتوفير نفس الأدوات عالية المستوى التي تتمتع بها لغات .NET ، على الرغم من أن الشركات الأخرى قادرة على القيام بذلك باستخدام C ++ (Qt ، إمباركاديرو).

pjmlp شكرًا على التفاصيل - أتحقق من بعض الأشخاص لمعرفة ما إذا كان هناك المزيد من المعلومات لمشاركتها على أدوات C ++ / WinRT ، على الرغم من أنني ربما لن أحصل على إجابات جيدة بحلول الغد. نحن نركز على C ++ / WinRT من أجل تطوير جديد ، ولكن لدينا في خارطة الطريق لدينا نأمل أن يكون لدينا قوالب C ++ / CX لـ WinUI 3 أيضًا إذا كان ذلك مفيدًا.

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

infoequipt هل يمكنك توضيح ما تعنيه بالعزلة؟ مثل دعم AppContainer ؟

في الوقت الحالي ، UWP وخليفته WinUI غير جاهز لتطبيقات LOB

• الكثير من التغييرات الفاصلة بين الإصدارات.

Xarlot ما التغييرات العاجلة التي تسبب لك المشاكل؟ مع UWP APIs نحاول الحفاظ على درجة عالية من التوافق مع كل إصدار.

@ Gavin-Williams فيما يتعلق بإهمال SharpDX ، قد ترغب في النظر إلى Vortice.Windows ، وهو بديل رائع لذلك. يستخدمAminator حاليًا في محرك ومحرر لعبة UWP / C # / XAML DX12 الخاص به بالكامل ، DX12GameEngine .
نأمل أن يناسب احتياجاتك في تطبيقاتك! 😄

فيما يتعلق بالأسئلة الخاصة بالمكالمة ، لدي أحد التفاصيل الصغيرة ، ولكن أثناء وجودنا فيها: هل يمكننا استخدام التبديل إلى WinUI 3 لإصلاح بعض أخطاء واجهة المستخدم القديمة الصغيرة التي يمكن اعتبارها "تغييرات متقطعة" ، مثل StackPanel تطبيق الخاصية Spacing بشكل غير صحيح على العناصر المطوية؟

بمعنى آخر. إذا كان لديك بعض العناصر المطوية في StackPanel ، فسيظل هناك تباعد بينها ، مما يجبرك على الرجوع إلى الحشو اليدوي / الهامش بين العناصر إذا كان لديك بعض عناصرك التي يمكن إظهارها / إخفاؤها برمجيًا. لقد أصلحت هذا الخطأ المحدد في العلاقات العامة لـ WrapPanel في Windows Community Toolkit ( # 2838 ) ، ويبدو أن هذا السلوك في StackPanel كان مشكلة معروفة تعرف عليها بعض مهندسي MS الآخرين أيضا. 🤔

استمروا في العمل العظيم! 🚀

leoniDEV شكرا للإشارة إلى هذا. لنرى ما إذا كنا سنحصل على بعض الإجابات المحددة غدًا 🙂

jesbis سؤالان آخران بخصوص WinUI Desktop (مرتبطان ببعضهما البعض):

1. هل ستحتوي تطبيقات WinUI Desktop على مفتاح مضمن بين المثيل المتعدد (معيار Win32) والمثيل الفردي (معيار UWP)؟ في الوقت الحالي ، إذا أردنا أن يكون تطبيق Win32 أحادي المثيل ، فعلينا تنفيذ هذا السلوك بأنفسنا. قد لا يتطلب هذا فقط قفل التطبيق (مثل كائن المزامنة (mutex) للتحقق مما إذا كان هناك مثيل قيد التشغيل بالفعل) ولكن أيضًا Win32 API مثل SendMessage لتمرير العمليات من مثيل التطبيق الثاني إلى مثيل التطبيق الأساسي (انظر السؤال 2). سيكون من الرائع أن نحصل على خيار الحصول على سلوك المثيل الفردي لتطبيقات UWP لتطبيقات WinUI Desktop.

1. هل ستتمكن تطبيقات WinUI Desktop من استخدام UWP Jumplist API؟ في الوقت الحالي ، لا يمكن لتطبيقات جسر سطح المكتب استخدامها بفعالية لأنه يبدو أن التطبيق لا يمكن تنشيطه (راجع مشكلة Windows Terminal https://github.com/microsoft/terminal/issues/576 للحصول على نظرة عامة موجزة عن المشاكل). أرغب في الحصول على دعم كامل لواجهة برمجة التطبيقات هذه لتطبيقات WinUI Desktop لأنها أسهل في التعامل معها من واجهات برمجة تطبيقات Win32 / WPF. على سبيل المثال ، يمكن تعيين رموز مهام jumplist بسهولة باستخدام مخططات URI ms-appx:/// أو ms-appdata:/// بدلاً من الاضطرار إلى إنشاء ملف .exe أو .dll يحتوي على الصور ، ثم تعيين المسار إلى هذا الملف الثنائي وأيضًا إزاحة في الملف للرمز المحدد .

   تلخص المستندات مزايا UWP Jumplist API:

   بدلاً من ذلك ، استخدم UWP Windows.UI.StartScreen.JumpList APIs بدلاً من ذلك ، مما يسمح لك بالإشارة إلى أصول السلسلة والصور باستخدام مخطط ms-Resource الخاص بالحزمة (وهو أيضًا لغة ، DPI ، ومعرفة التباين العالي).

من المحتمل أيضًا أن يؤدي سلوك المثيل الفردي لتطبيقات UWP إلى تسهيل العمل مع قوائم jumplists كثيرًا. إذا كانت لديك مهمة jumplist والتي يجب أن تعمل على مثيل التطبيق الجاري تشغيله ، في WPF / Win32 ، فسيتم تشغيل مثيل تطبيق ثانٍ يحتاج بعد ذلك إلى استخدام ، على سبيل المثال ، SendMessage Win32 API لإرسال العملية المطلوبة إلى مثيل التطبيق الأساسي. باستخدام سلوك المثيل الفردي على UWP ، يحصل التطبيق قيد التشغيل

pjmlp شيء آخر قد يكون مهمًا إذا لم تكن قد رأيته في هذه الجلسة بواسطة Kenny Kerr و Scott Jones من آخر مؤتمر Build ، ولا سيما آخر 11 دقيقة حيث تحدثوا عن بعض التحسينات النموذجية للربط ، وبعض C ++ المواصفات الفنية لإضافة دعم الانعكاس والفئة الوصفية التي يمكن أن تزيل تمامًا متطلبات IDL وبيانات التعريف الحالية:

https://youtu.be/X41j_gzSwOY؟t=2659

إذا كان لدينا وقت ، فيمكننا التحدث عن هذا قليلاً في المكالمة غدًا أيضًا.

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

في الوقت الحالي ، يبدو من الأرجح أنني سأقوم بنقل كود DirectX الحالي الخاص بي إلى شيء مثل مكتبة Vortice ، التي أشار إليها @ Sergio0694 بدلاً من انتظار مثل هذه الأدوات

أنا معجب بجهودك ، ولكن هنا من الخنادق ، بعد Silverlight ، XNA ، WinRT ، UAP ، UWP ، WinUI ، .NET Framework ، WCF ، EF6 ، في النهاية نتعب من إعادة الكتابة.

يجب أن يكون WinUI أفضل من WPF من جميع النواحي ، وإذا اضطررنا إلى استخدام C ++ لأسباب ، فيجب أن تكون أدواته في نفس المستوى الذي أصبح مطورو .NET يحبونه ، حتى يستحقوا تجاوز WPF أو عمل نقطة لتجنب رغبة العمل في استخدام تطبيقات نمط الإلكترون.

كما سأل @ Sergio0694 بالفعل ، هل سيتم استخدام WinUi 3.0 ليس فقط لتبديل مساحات الأسماء ولكن أيضًا يحتوي على تغييرات كسر أخرى ضرورية لإصلاح الأخطاء مثل المساحات المطبقة بشكل غير صحيح؟

إذا كان الأمر كذلك ، فستكون هناك فرصة لإعادة تسمية الخاصية NavigationView.IsBackButtonVisible إلى BackButtonVisibility حيث أن الاسم والنوع حاليًا لا يصطفان بالفعل (IsBackButtonVisible هو تعداد NavigationViewBackButtonVisible ، وليس منطقيًا). هذا ايضا نوقش هنا

chingucoding ، أتذكر أن الفريق قال إنه بالنسبة لـ WinUI 3.0 نفسه ، يجب أن تكون التغييرات العاجلة في حدها الأدنى لجعل نقل التطبيقات الحالية (UWP) إليها أمرًا سهلاً قدر الإمكان. أظن أن هذه التغييرات ، في حالة الموافقة عليها ، سيتم تنفيذها في إصدارات WinUI 3.x / 4/5 / .... اللاحقة.

س: هل ستدعم WinUI 3.x AcrylicBrush مع HostBackdrop ؟ من المعروف حاليًا أنه تم كسره في ألفا ولكني أشعر بالفضول إذا كان على خريطة الطريق ليتم إصلاحه قبل الإصدار.

س: هل سيقوم WinUI Desktop بتمكين مطوري تطبيقات سطح المكتب من _ أخيرًا_ استخدام AcrylicBrush مع HostBackdrop ؟ كنا سابقا السمة تكوين WCA_ACCENT_POLICY مع ACCENT_ENABLE_ACRYLICBLURBEHIND ولكن مايكروسوفت كسر حاسم هذا في 19H1 + و التطبيق لدينا وكانت المعاناة منذ ذلك الحين. (لقد أثرت أيضًا على أشياء مثل Emoji Picker لكن Microsoft قامت بصيانة هذه المكونات لاستخدام طريقة غير أكريليك بدلاً من ذلك.)

حول WebView2:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"معاينة المطور متاحة لـ Win32 C ++ على أنظمة التشغيل Windows 10 و Windows 8.1 و Windows 8 و Windows 7. في المستقبل ، نخطط لدعم WebView2 على .NET و XAML."

سؤالي هو .. هل من المخطط أن يكون الإصدار .NET من WebView2 SDK المطبق على أنظمة التشغيل Win8.1 و 8 و 7؟
لدي قلق من أن WebView2 على .NET مدعوم فقط عبر WinUI3. حسب فهمي ، فإن دعم تطبيق WinUI3 WinForms ينطبق فقط على .NET Core و Win10 فقط.
اسمحوا لي أن أشرح موقفي .. يمتلك موكلي العديد من تطبيقات WinForm لسطح المكتب التي تستخدم IE BrowserControl. لكن IE قديم ويريد الانتقال إلى المتصفحات الحديثة. ويجب أن تدعم هذه التطبيقات أنظمة Win7 و 8 و 8.1. (لا تلومني على دعم نظام التشغيل القديم)

اذا كان ممكنا:

• Win32 ETA على إصدار معاينة لـ WinUI 3.0

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

• هل يدعم WinUI 3.0 تأثيرات تظليل مخصصة مثل WPF / Silverlight؟ إذا لم يكن هناك أي أفكار حول إضافتها لاحقًا؟ هل طبقة العرض المستخدمة بواسطة WinUI قادرة على ذلك؟

leoniDEV لقد تقدمت وأنشأت مشروع جزيرة XAML كما

لذلك يبدو أنه في الوقت الحالي على الأقل لا يوجد دعم كامل لتطبيقات XAML Island التي تستهلك مشروع UWP منفصل.

إنني أتطلع إلى إجراء v-next لتطبيق WPF القديم. يمكنني على الأرجح استخدام .NET Core WPF ، لكنني أريد حقًا استخدام WinUI. أواجه مشكلات مع libs مثل Prism لا تزال مشتقة من Windows.UI.Xaml (على عكس Microsoft.UI.Xaml). يبدو أن هذه الأنواع من القضايا أساسية. هل توجد إرشادات قوية لـ PnP لـ WinUI ، حتى الآن ، أم أنه مبكر جدًا؟

هل من الممكن الاستعانة بشخص ما من فريق shell أو فريق تطبيقات البريد الوارد للتحدث عن سبب كون قائمة البدء ومستكشف الملفات في Windows 10x مستندة إلى الويب بدلاً من استخدام WinUI؟

كل ما أحتاجه هو تجربة نقل سلسة من تطبيق UWP الحالي (مع امتداد سطح المكتب) إلى تطبيق WinUI Desktop (بدون ملحق سطح المكتب). هل هذا ممكن؟ ما هي المخاطر في هذا السيناريو؟

إذا ثبت أن هذا صعب ، فهل سيكون من الممكن في المستقبل تحسين UWP (للتطبيقات التي تعمل على سطح المكتب) لتشغيل التطبيقات دائمًا في الخلفية والسماح لهم باستدعاء جميع واجهات برمجة تطبيقات win32 من خلال P / Invoke والسماح بتحميل dll دلل أخرى بدون LoadPackagedLibrary (ولكن مع LoadLibrary).

ما مدى احتمالية أن يكون WinUI 3.0 جاهزًا للتشغيل عند إطلاق أول أجهزة Windows 10x؟ أنا مهتم بالقفز إلى عالم مطوري Windows وأحاول تحديد النهج الأكثر منطقية في هذه المرحلة.

شكرًا لكم جميعًا على الأسئلة والمشاهدة إذا كنتم تستطيعون فعل ذلك! التسجيل مباشر على نفس الرابط.

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

عرض جيد يا شباب ، شكرًا على الرد على سؤالي وعلى تقديم ميغيل.

سأضيف المزيد من الأسئلة التي بقيت لدي على أمل أن تتم معالجتها.

1. ترسم تطبيقات Win32 التقليدية على الشاشة في WM_PAINT. يتم الاحتفاظ بتطبيقات XAML في الوضع. نرسم الكثير من الأشياء على الشاشة لإنشاء كائنات / عناصر تحكم فردية. هل سيظل هناك مكافئ WM_PAINT للسماح لي بالرسم إلى النافذة ولكن باستخدام واجهة برمجة تطبيقات أكثر حداثة؟ Win2D أو بعض واجهة برمجة تطبيقات الوضع الفوري الأخرى؟

2. يتم التعامل مع إمكانية الوصول بشكل مختلف في Win32 (COM APIs) مقابل ، على سبيل المثال ، WPF (نظراء التشغيل الآلي). إذا قمت بكتابة تطبيق Win32 + WinUI ، فهل سأتمكن من زيادة أو التحكم في شجرة الوصول بشكل أسهل؟ أم سألتزم بواجهات برمجة تطبيقات COM القديمة؟ كيف يمكنني مزج المحتوى المرسوم المخصص الخاص بي مع عناصر التحكم التي يمكن الوصول إليها في شجرة إمكانية الوصول؟

3. اليوم ، نطبع من خلال الرسم في طابعة DC. هل توجد طباعة جديدة باستخدام Win32 + WinUI؟

4. ما زلت محيرًا قليلاً فيما يتعلق بالعلاقة بين HWND و CoreWindow وأي شيء يأتي بعد ذلك لـ WinUI. هل ستظل HWNDs موجودة أم أننا سنستبدل مكالمات CreateWindow بشيء آخر؟ أفترض ذلك ... ولكن إذا كان هذا هو الحال أفترض أنه لا يزال هناك HWND أساسي للحالات التي يتعين علينا فيها تسليم واحد إلى مكونات خارجية (الأصل HWND على سبيل المثال).

5. هل سيواجه استخدام WebView2 في تطبيق Win32 + WinUI مشكلات المجال الجوي التي نواجهها مع عنصر تحكم IE المضمن؟

البدء في اللحاق ببعض الأسئلة:

هل WinUI مجرد تطوير UWP ولكن مواصفات أكثر حداثة؟ أرى محادثات حول WinUI ولست متأكدًا بنسبة 100٪ ما إذا كانوا يتحدثون عن مطور UWP أو libs معينين في UWP dev أو شيء مختلف تمامًا

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

بالنسبة لتطبيقات UWP ، يمكن أن تحل على وجه التحديد محل Windows.UI.Xaml ، Windows.UI.Composition وأجزاء من Windows.UI.Input .

هل ستحتوي تطبيقات WinUI على مفتاح مضمن بين المثيل المتعدد (معيار Win32) والمثيل الفردي (معيار UWP)؟

@ Felix-Dev ، لم نستكشف حتى الآن فكرة دعم المثيل الفردي الأفضل لتطبيقات win32 حتى الآن - إذا كان لديك اقتراح ، فلا تتردد في فتح مشكلة في هذا الريبو من أجلها!

هل ستدعم WinUI 3.x AcrylicBrush مع HostBackdrop؟ من المعروف حاليًا أنه تم كسره في ألفا ولكني أشعر بالفضول إذا كان على خريطة الطريق ليتم إصلاحه قبل الإصدار. هل سيقوم WinUI Desktop بتمكين مطوري تطبيقات سطح المكتب من استخدام AcrylicBrush أخيرًا مع HostBackdrop؟

riverar هذا للأسف ليس في خطة WinUI 3.0 RTM. هناك تحديات في دعم هذا في منصة واجهة المستخدم المنفصلة عن نظام التشغيل ، لكننا نخطط لإعادة النظر في هذا بعد 3.0.

حول WebView2: سؤالي هو .. هل من المخطط أن يكون الإصدار .NET من WebView2 SDK مناسبًا لأنظمة Win8.1 و 8 و 7؟
لدي قلق من أن WebView2 على .NET مدعوم فقط عبر WinUI3.

@ pnp0a03 ، لا يتم دعم عنصر تحكم WinUI Xaml إلا في WinUI 3 ، ولكن هناك معاينة مطور لـ WebView 2 SDK الأساسية لنظام التشغيل Windows 7 و 8 و 8.1 لتطبيقات win32:

https://docs.microsoft.com/microsoft-edge/hosting/webview2

أواجه مشكلات مع libs مثل Prism لا تزال مشتقة من Windows.UI.Xaml (على عكس Microsoft.UI.Xaml). يبدو أن هذه الأنواع من القضايا أساسية. هل توجد إرشادات قوية لـ PnP لـ WinUI ، حتى الآن ، أم أنه مبكر جدًا؟

GraniteStateHacker إنه وقت مبكر جدًا على ما أعتقد - لا يزال WinUI 3 جديدًا جدًا للحصول على الكثير من دعم النظام البيئي ( متوفر فقط في alpha) ولكن

هل WinUI مخصص فقط لتطبيقات المتجر؟

لا - يمكنك استخدامه بعدة طرق ، على سبيل المثال:

• قم بتضمينه في تطبيق win32 موجود (WPF و WinForms و MFC وما إلى ذلك) باستخدام Xaml Islands
• بناء مثبّت MSIX ونشره بالطريقة التي تريدها
• إنشاء تطبيق غير معبأ وتوزيعه عبر xcopy أو وسائل أخرى (غير مدعوم لـ WinUI 3 حتى الآن ولكن مخطط لـ RTM)

ما مدى احتمالية أن يكون WinUI 3.0 جاهزًا للتشغيل عند إطلاق أول أجهزة Windows 10x؟ أنا مهتم بالقفز إلى عالم مطوري Windows وأحاول تحديد النهج الأكثر منطقية في هذه المرحلة.

dwalleck WinUI 3 لديه بالفعل خرج ألفا ويجب أن يكون لديه معاينة أكثر فاعلية حول الإطار الزمني لمؤتمر البناء ، وكلاهما يستهدف أواخر عام 2020. إذا بدأت بـ UWP Xaml و / أو WinUI ، فيجب أن تكون على مسار جيد لتطوير 10x .

ترسم تطبيقات Win32 التقليدية على الشاشة في WM_PAINT. يتم الاحتفاظ بتطبيقات XAML في الوضع. نرسم الكثير من الأشياء على الشاشة لإنشاء كائنات / عناصر تحكم فردية. هل سيظل هناك مكافئ WM_PAINT للسماح لي بالرسم إلى النافذة ولكن باستخدام واجهة برمجة تطبيقات أكثر حداثة؟ Win2D أو بعض واجهة برمجة تطبيقات الوضع الفوري الأخرى؟

يتم الاحتفاظ بالأشجار والفرش في وضع jschroedl Xaml ، ولكن يمكنك استخدام خيار واحد أو أكثر من الخيارات العديدة لتضمين بدائل عرض أخف وزنًا:

• مرئيات طبقة التكوين
• أشكال طبقة التكوين التي تتيح رسم AnimatedVisualPlayer الذي يمكنه تشغيل أشكال / رسوم متحركة لوتي
• توافق DirectX مع Xaml باستخدام SwapChainPanel أو SurfaceImageSource أو VirtualSurfaceImageSource (اعتمادًا على ما إذا كنت تريد سلسلة مبادلة أو نموذج فرشاة افتراضي / غير افتراضي)
• Win2D ، الذي يلخص لك إمكانية التشغيل المتداخل DirectX أعلاه (مع Direct2D و DirectWrite) ويوفر واجهة برمجة تطبيقات .NET

يتم التعامل مع إمكانية الوصول بشكل مختلف في Win32 (COM APIs) مقابل ، على سبيل المثال ، WPF (نظراء التشغيل الآلي). إذا قمت بكتابة تطبيق Win32 + WinUI ، فهل سأتمكن من زيادة أو التحكم في شجرة الوصول بشكل أسهل؟ أم سألتزم بواجهات برمجة تطبيقات COM القديمة؟ كيف يمكنني مزج المحتوى المرسوم المخصص الخاص بي مع عناصر التحكم التي يمكن الوصول إليها في شجرة إمكانية الوصول؟

سؤال رائع! Paging @ marb2000 للتأكد من تغطية ذلك وإعطاء آخر التحديثات. بشكل عام ، يجب أن تستخدم أشجار WinUI Xaml AutomationPeers ولكني لست متأكدًا حتى الآن مما إذا كان ذلك سيوسع أي وظيفة جديدة لمحتوى Win32 غير WinUI.

اليوم ، نطبع من خلال الرسم في طابعة DC. هل توجد طباعة جديدة باستخدام Win32 + WinUI؟

يجب أن تكون وظيفة الطباعة الرئيسية لمحتوى WinUI من خلال إصدار WinUI من WinRT PrintDocument API.

ما زلت محيرًا قليلاً فيما يتعلق بالعلاقة بين HWND و CoreWindow وأي شيء يأتي بعد ذلك لـ WinUI. هل ستظل HWNDs موجودة أم أننا سنستبدل مكالمات CreateWindow بشيء آخر؟ أفترض ذلك ... ولكن إذا كان هذا هو الحال أفترض أنه لا يزال هناك HWND أساسي للحالات التي يجب علينا فيها تسليم واحد إلى مكونات خارجية (الأصل HWND على سبيل المثال

لا يحل WinUI محل hwnds ولكن الهدف هو التخلص من استخدامها لحالات الاستخدام الشائعة من خلال توفير واجهة برمجة تطبيقات Xaml - تشبه إلى حد ما طريقة عمل WPF. ستستمر واجهة برمجة تطبيقات Xaml بالفعل في استخدام hwnds / CoreWindows كتفاصيل تنفيذ أساسية ، ومن المحتمل أن يكون لدينا واجهات برمجة تطبيقات "backdoor" / "escape-hatch" للحصول على وصول مباشر إلى hwnds عند الحاجة. ينبغي أن يكون لدينا مسودة اقتراح في غضون أسابيع قليلة مما سيجعل ذلك أكثر وضوحا.

jesbis شكرًا لك على إجابتك ، لكن ما يقلقني لم يتم حله للأسف.
حاليًا ، تم إطلاق إصدار WebView2 SDK Win32 "C ++" (معاينة) من هذا الموقع. يدعم Win7 و 8 و 8.1.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
سؤالي حول إصدار .NET. حاليًا ، إصدار .NET مدعوم فقط بواسطة WinUI 3 ، ولكن كما تعلم ، لا يمكننا استخدام WinUI 3 على Win7 و 8 و 8.1 (هل هذا صحيح؟).
وبالتالي ، قمت بنشر سؤالي على النحو التالي.

سؤالي هو .. هل من المخطط أن يكون الإصدار .NET من WebView2 SDK المطبق على أنظمة التشغيل Win8.1 و 8 و 7؟

jesbis شكرًا على الرد على أسئلتي ، على الرغم من أنها شعرت بالإحباط.

تحاول أن تكون بناءة هنا.

لذا فإن أفضل ما يمكن أن تقدمه Microsoft فيما يتعلق بأدوات C ++ / WinRT هو الإشارة إلى بعض المقترحات الجوية ، مع الحظ ، قد تهبط على ISO في مكان ما بين C ++ 23 أو C ++ 26 ، على كل حال. ثم انتظر حتى يقوم فريق Visual Studio بإعادة إنشاء C ++ / CX في النهاية فوقهم ، مما يجعله حوالي 6 سنوات من الآن.

إذا كنت أرغب في استخدام أدوات رائعة لواجهة مستخدم C ++ ، فإن WinUI بالتأكيد ليس كذلك ، بل Qt أو C ++ Builder ، مع ميزة إضافية تتمثل في إمكانية نقل النظام الأساسي.

لذلك بعد مشاهدة العرض التقديمي ، وما زلت ترتدي ندوبًا من XNA (تمت إعادة الكتابة في C ++ باستخدام DirectXTK) ، WinRT 8.0 ، WinRT UAP 8.1 ، UWP W10 ، C ++ Direct2D بدلاً من النظام. الرسم (حتى ظهور Win2D ، أصبح الآن في حالة ركود) ، WinUI هو بالتأكيد شيء سأعلقه.

للمضي قدمًا ، سوف أنصح زبائني بالذهاب إلى WPF عند استخدام .NET ، Qt عند استخدام C ++ ، أو التركيز على PWAs إذا كان ذلك ممكنًا باستخدام تقنيات الويب.

لا توحي خارطة طريق WinUI 3.0 بأي ثقة في أن إعادة تشغيل أخرى على وشك الحدوث ، إذا استمر بيع UWP في الفشل في سوق سطح المكتب.

ما أريد أن أشير إليه هو أن إدارة Microsoft يجب أن تفكر في كيفية بيعنا لفكرة اعتماد WinUI ، بعد فشلنا عدة مرات منذ إصدار Windows 8.

من الأفضل توجيه ملاحظات

لا يزال DirectXTK قيد التطوير وقد تم الحصول على تحديثات منتظمة.

فيما يتعلق بواجهات برمجة تطبيقات إطار عمل Xaml ، فإن WinUI هو المسار إلى الأمام ولديه نسب توافق غير منقطعة إلى حد ما تعود إلى Windows 8 - نقضي الكثير من الوقت في محاولة الحفاظ على درجة عالية من التوافق 🙂 هناك بعض التغييرات (بسبب تكامل shell ، هيكل مشروع VS ، وما إلى ذلك) ولكن بالنسبة للجزء الأكبر ، من المحتمل أن تقوم بنقل Windows 8 Xaml إلى تطبيق Windows 10 حالي ، وإعادة تجميعه وتشغيله في أحدث رحلة داخلية وستنجح.

ستشمل بعض الفوائد عالية المستوى لـ WinUI إزالة الحواجز بين واجهات برمجة تطبيقات UWP WinRT و Win32 APIs ، ودعم .NET 5 ، وتمكين الدعم الفوري من المستوى الأدنى للميزات الجديدة ، وإزالة الحاجة إلى إجراء العديد من عمليات التحقق من إصدار نظام التشغيل الشرطي ، وتمكين مساهمات OSS و تمكين التحديثات الإضافية لتطبيقات win32 الحالية باستخدام جزر Xaml.

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

jschroedl ، نريد التخلص من مشكلات المجال الجوي ، ونحاول وضع خطة عرض تساعدنا على تحقيق ذلك.

jesbis كما ذكرنا ، لا أعتقد أن الشكوى على cppwinrt ستفعل أي شيء ، بل أشكو من عدم اعتماد C ++ / WinRT إلا في حالات الاستخدام التي لا يمكنني تجنبها ، خاصة لأن خارطة الطريق هي اعتماد ميزة قد لا يتم قبولها حتى ISO.

فيما يتعلق بـ DirectXTK ، كنت أعطي مثالًا آخر على كيفية إجبارنا Microsoft على إعادة كتابة كود C # إلى C ++ ، بأدوات أقل قدرة ، عن طريق إسقاط XNA وتقديم DirectXTK كـ "بديل".

لحسن الحظ ، تمكن مجتمع المصدر المفتوح من ابتكار لعبة MonoGame والقيام بالعمل الذي رفضت Microsoft متابعته مع XNA.

لقد رأيته أثناء العرض التقديمي وفي بعض التعليقات هنا ، كيف أن C ++ رائعة وممتعة ، وكيف يستمر WinDev (مرة أخرى منذ تولي Longhorn) في بيع C ++ أولاً ، .NET لاحقًا.

إذا كنت أرغب في استخدام أدوات C ++ رائعة ، فإن Qt و C ++ Builder هي بيئتي المفضلة ، وليست Visual C ++.

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

لا يتعين علينا فقط الاهتمام بواجهات برمجة التطبيقات ومكتبات الجهات الخارجية التي لن تنتقل من .NET Framework إلى .NET Core ، بل يتعين علينا أيضًا التعامل مع جميع مشكلات الترحيل من WPF / UWP إلى WinUI و "اكتب فقط" إنه في C ++ / WinRT ، إنه رائع وسيصبح أفضل في غضون عامين ".

يتعين على إدارة Microsoft أن تفكر مليًا في الأمر ، وكيفية بيع إعادة الكتابة هذه لمطوري .NET المحترقين ، وإلا فلن نبتعد عن الحزم التي تؤدي وظيفتها بالفعل.

pjmlp متحدثا من DirectX، أنا أعمل بنشاط على المحمولة والملحد C # الرسومات والصوت وإطار مساهمة في وقت فراغي من شأنها أن تكون قادرة على تشغيل D3D12 / 11 وغيرها في وجهة نظر WinUI .... من بين أمور أخرى كثيرة.

وهو يدعم نهجًا أكثر حداثة ويركز على الأداء في العرض مقابل شيء مثل XNA. إنه ليس جاهزًا للاستخدام ولكنه شيء يريده الكثير من الأشخاص بما فيهم أنا ... لذلك أنا أصنعه. ستكون D3D12 و Vulkan هي الأهداف الأولى المدعومة. ستتمكن أيضًا من كتابة التظليل في C # بدلاً من HLSL أو GLSL وما إلى ذلك.

عندما يكون جاهزًا للاستخدام ، سأشارك المزيد ولكن نظرًا لأن هذا إطار وليس بعض SDK أو محرك ألعاب ضخم ، فسيكون محمولًا جدًا وخفيف الوزن ولكنه قوي وسهل الاستخدام. مثالي لتقديم محتوى ثلاثي الأبعاد في WinUI أو WPF أو بعض تطبيقات C # Win32 أو WinRT الأصلية.

https://github.com/reignstudios/Orbital-Framework

@ zezba9000 شكرا لك على المعلومات ، الكثير من الأشياء الرائعة التي قمت بها ، مجد!

أعتقد أنه فيما يتعلق بالدعم المُدار لـ DirectX ، لا يمكننا الاعتماد إلا على جهود المجتمع مثل جهودك ، بعد تخزين Managed DirectX و XNA ، تولى جمهور C ++ MS مسؤولية جهود تطوير DirectX.

على الأقل ، يمكن لأي من هذه المشاريع الاعتماد على مؤيدي ، كتسويق لإظهار للآخرين أنه لا يحتاج إلى أن يكون "C ++ أو الطريق السريع" فقط كما يحب WinDev دفعه. هنا يمكنهم أخذ درس من OpenGL ES / Metal with Swift أو OpenGL ES / Vulkan مع Java / Kotlin. من الواضح أن استخدام اللغات المُدارة للبرمجة ثلاثية الأبعاد لم يكن مشكلة بالنسبة لمنصات الأجهزة المحمولة للفوز على Windows (للأسف ، كانت WP تجربة رائعة).

حظًا سعيدًا لجهودك ، تبدو كتابة التظليل في C # جذابة حقًا ولم أكن على علم بـ CS2X.

pjmlp Ya ، الجزء CS2X هو ما سيسمح لك بكتابة تظليل GPU الحيادي في C # (وهو أمر رائع لأنك ستتمكن من اختبار وحدات التظليل من الناحية النظرية). بالنسبة للأهداف التي يمكنها الاستفادة من مجموعة فرعية C # ، يسمح CS2X لي / للآخرين باستهداف الأنظمة الأساسية خارج ما تدعمه أوقات تشغيل .NET الحالية مع وقت تشغيل خفيف للغاية حيث يمكن لـ CS2X تجميع مجموعة فرعية C # لوقت تشغيل C89 ... ولأن Orbital-Framework يمكن أن تستهدف CS2X => C89 وقت التشغيل ، ويمكنها بدورها استهداف هذه الأنظمة الأساسية أيضًا.

مشروع كبير ولكن هذا ما يهمني وأنا مكرس لتحقيقه.

هل سيكون من الممكن استخدام HwndHost مع WinUI 2.4
حاولت في الإصدار التجريبي ولكن هذا لم ينجح.
سيكون من الممكن أيضًا مع WinUI3 مع كل هذه النوافذ الجديدة المخطط لها (نافذة XAML) والتطبيق (تطبيق XAML) وإذا كانت الإجابة بنعم عندما نتوقع المعاينة الأولى لرؤية ذلك.
في الواقع ، إذا كان ذلك ممكنًا في WinUI3 ، فهل ستتم إضافة هذه الوظيفة إلى إصدارات WinUI 2 الجديدة ، أم أن WinUI 2 سيعمل فقط في تطبيقات Uwp.
على سبيل المثال في الوقت الحالي ، لدينا تطبيق WPF ، والذي يستخدم الكثير من كود C ++ من خلال HwndHost ، ولأننا نخطط لنقل كل شيء إلى WinUI ، فإن هذا الجزء مهم للغاية بالنسبة لنا لاتخاذ قرار باستخدام WinUI أو أي شيء آخر. أيضًا حتى WinUI 2 يبدو جيدًا بالنسبة لنا ، جزء XAML سهل النقل ، تكوين Api يعمل بشكل رائع ، Uwp Community Toolkit يعمل بشكل رائع ، فقط لا يمكننا استخدام HwndHost و c ++ Win32 code. فهل ومتى سيحل WinUI3 هذا؟ كما أنني أحب كثيرًا x: ​​Bind ولكن هذا معرض لخطر إصدار WinUI3.

@ zezba9000

يتحدث من DirectX، أنا أعمل بنشاط على المحمولة والملحد C # الرسومات والصوت وإطار مساهمة في وقت فراغي من شأنها أن تكون قادرة على تشغيل D3D12 / 11 وغيرها في وجهة نظر WinUI .... من بين أمور أخرى كثيرة.

حظا سعيدا مع هذا! إنه قدر مجنون من العمل!

هل سيكون من الممكن استخدام HwndHost مع WinUI 2.4
حاولت في الإصدار التجريبي ولكن هذا لم ينجح.
سيكون من الممكن أيضًا مع WinUI3 مع كل هذه النوافذ الجديدة المخطط لها (نافذة XAML) والتطبيق (تطبيق XAML) وإذا كانت الإجابة بنعم عندما نتوقع المعاينة الأولى لرؤية ذلك.
في الواقع ، إذا كان ذلك ممكنًا في WinUI3 ، فهل ستتم إضافة هذه الوظيفة إلى إصدارات WinUI 2 الجديدة ، أم أن WinUI 2 سيعمل فقط في تطبيقات Uwp.
على سبيل المثال في الوقت الحالي ، لدينا تطبيق WPF ، والذي يستخدم الكثير من كود C ++ من خلال HwndHost ، ولأننا نخطط لنقل كل شيء إلى WinUI ، فإن هذا الجزء مهم للغاية بالنسبة لنا لاتخاذ قرار باستخدام WinUI أو أي شيء آخر.

هناك مشكلة مفتوحة لطريقة استضافة user32 / comctl أو WPF UI داخل WinUI XAML: https://github.com/microsoft/microsoft-ui-xaml/issues/1833

يبدو أنه لن يتم إجراؤه إلا بعد الإصدار 3.0 ، إذا تم إجراؤه.

أنشر هذا على # 1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833 لكنني سأقوم بالنسخ
هنا أيضًا: لدينا الآن تطبيق WPF الذي يستخدم الكثير من كود c ++ من خلاله
HwndHost control. نحن نخطط لنقل تطبيق Wpf إلى WinUI ونقل Xaml
يعمل بشكل رائع بدون مشاكل ، ولكن ماذا عن HwndHost ، هل سيكون هذا
ممكن مع WinUI3. في حالتنا نحن نقوم بإمكانية التشغيل البيني مع
DirectShow من خلال HwndHost والآن في WinUI 2 ، هذا ليس كذلك
المستطاع. ما هو التاريخ الواقعي لاستخدام HwndHost في WinUI3؟ هو أيضا
نافذة Xaml الجديدة والتطبيق الجديد الذي تمت مناقشته في فبراير الماضي
دعوة مجتمع WinUI ، يمكن أن تساعد أم لا؟

الدوم، 23 دى فبراير. de 2020 على طول 13:42، Max Strini (
[email protected]) escribió:

هل سيكون من الممكن استخدام HwndHost مع WinUI 2.4
حاولت في الإصدار التجريبي ولكن هذا لم ينجح.
كما أنه سيكون ممكنًا مع WinUI3 مع كل هذا المخطط الجديد
وضع النوافذ (نافذة XAML) والتطبيق (تطبيق XAML) وإذا كانت الإجابة بنعم فمتى
يمكننا أن نتوقع المعاينة الأولى لرؤية ذلك.
في الواقع ، إذا كان ذلك ممكنًا في WinUI3 ، فستكون هذه الوظيفة
تضاف إلى إصدارات WinUI 2 الجديدة ، أو سيعمل WinUI 2 فقط في تطبيقات Uwp.
على سبيل المثال في الوقت الحالي ، لدينا تطبيق WPF ، والذي يستخدم الكثير من كود C ++ من خلاله
HwndHost ، ولأننا نخطط لنقل كل شيء إلى WinUI ، هذا الجزء
أمر بالغ الأهمية بالنسبة لنا لاتخاذ قرار باستخدام WinUI أو أي شيء آخر.

هناك مشكلة مفتوحة لإيجاد طريقة لاستضافة user32 / comctl أو WPF UI بالداخل
WinUI XAML: # 1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

يبدو أنه لن يتم إجراؤه إلا بعد الإصدار 3.0 ، إذا تم إجراؤه.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972؟email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52GS4DFVRE38
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

-
ماريو رانسيك
مهندس برمجيات
محترف معتمد من Microsoft

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

حول HwndHost في WinUI 3.
يسمح HwndHost باستضافة محتوى Win32 داخل WPF. لسوء الحظ ، لا توجد خطة في WinUI 3.0 لدعم هذا ، بما في ذلك WinUI 3.0 Desktop أو WinUI Islands. حول السيناريو الذي وصفه @ mariorancic01 ، هل قمت بتقييم

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

المي ، 26 د. de 2020 على غرار 23:47 ، ميغيل راموس (
[email protected]) escribió:

حول HwndHost في WinUI 3.
يسمح HwndHost باستضافة محتوى Win32 داخل WPF. للأسف هناك
لا توجد خطة في WinUI 3.0 لدعم هذا ، بما في ذلك WinUI 3.0 Desktop أو
جزر WinUI. حول السيناريو @ mariorancic01
وصف https://github.com/mariorancic01 ، هل قمت بتقييم UWP
MediaPlayer APIs بدلاً من DirectShow؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972؟email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCGCSY#issuecomment-591683915 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

-
ماريو رانسيك
مهندس برمجيات
محترف معتمد من Microsoft

لدي سؤال حول Windows Store for Business ، يبدو هذا رائعًا ومفيدًا جدًا لتطبيقات LOB ، لكني قرأت أنه قد يتم التخلي عن هذا. يمكن لأي شخص أن يقول شيئا عن خطط حول هذا.

@ marionrancic01 ليس من الضروري حقًا حيث يمكنك الآن توزيع تطبيقات UWP عبر عبوة MSIX.

حزين ، مثل @ mariorancic01 أيضًا أجد متجر Windows للأعمال مفيدًا 😞

leoniDEV أنا أشعر بالفضول بصدق عن سبب احتياجك لمتجر Windows للأعمال ، في حين يمكنك ببساطة النشر كـ msix ، كما قال kmgallahan

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

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

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

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

jtorjo لست بحاجة إلى أي شهادات.

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

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

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

riverar عندما كنت