هل يمكننا التحدث عن دعم أنواع البيانات الفارغة في عناصر التحكم والقيم الافتراضية؟ كمثال هناك DatePicker الذي يقوم بإرجاع DateTimeOffset و CalendarDatePicker الذي يقوم بإرجاع DateTimeOffset ؟.

• لماذا أحدهما لاغى بينما الآخر ليس كذلك؟ هل هذا بسبب أن منتقي التاريخ قد تم تطويره باستخدام واجهات برمجة التطبيقات السابقة في الإطار الزمني لنظام التشغيل Windows 8؟
• هل يجب أن نفكر في إضافة خاصية تكوين للسماح / عدم السماح خالية في عناصر التحكم؟
• هل يجب اعتبار خاصية DefaultValue لعناصر التحكم الجديدة مثل NumberBox ، هل يجب الاحتفاظ بـ NaN كخاصية افتراضية ، أم يجب أن ننتقل إلى قيمة nullable مع القيمة الافتراضية الخالية؟
• هل توجد قيود على WinRT / OS XAML مع إرجاع القيم الفارغة ودعمها والتي من شأنها منع جعل خاصية NumberBox Value قابلة للإلغاء؟ إذا كان الأمر كذلك ، كيف تم تنفيذ CalendarDatePicker؟
• يرتبط هذا ارتباطًا مباشرًا بمناقشات NumberBox في # 1721 و # 1708

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

فكرة أخرى مثيرة للاهتمام للمناقشة تساءلت عنها: ما الذي ستكون عليه سياسة Microsoft بشأن التغييرات العاجلة الآن بعد أن أصبح WinUI 3.0 مفتوح المصدر؟

في الماضي ، لم تقم Microsoft فعليًا بإجراء تغييرات جذرية. يعد هذا أمرًا جيدًا بشكل عام حتى تتراكم كل الفوضى بعد بضع سنوات (أو 10). كما أنه ليس معيارًا لمشاريع مفتوحة المصدر. على سبيل المثال ، في النهاية يجب التخلص التدريجي من ListBox لـ ListView و MessageDialog من أجل ContentDialog ، وما إلى ذلك.

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

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

قد يكون هذا جيدًا للتوثيق بمجرد مناقشته.

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

• بناء 2020 (أبريل- مايو)
• Ignite 2020 (أكتوبر-نوفمبر)
• ~ 2021

أيضًا ، ما مدى اعتماد عملك على فريق .NET الذي يجمع بين حل AOT جديد و .NET 5؟

أخيرًا ، هل هناك ضغط على جانب Windows ليكون جاهزًا لإصدار Windows10X و / أو قبل ذلك للمطورين لإنشاء تطبيقات متخصصة؟

هل ستكون هناك / هل يجب أن تكون هناك أداة لتحويل مشاريع WinUI 2.X بسهولة إلى WinUI 3.0 (نظرًا لأن القيام بذلك يدويًا قد يتطلب الكثير من العمل للمشاريع الكبيرة)؟

الفيل في الغرفة - WinRT (# 1856)

الفيل في الغرفة - WinRT (# 1856)

سيأتي نموذج تطبيق غير مزود بوضع الحماية - والذي سيعمل بنفس طريقة WPF (بما في ذلك Win32 APIs) ، ولكن مع الوصول إلى واجهات برمجة تطبيقات WinRT الحديثة ، وواجهة مستخدم مفتوحة المصدر وعناصر تحكم مع XAML الجديد الذي يعمل على Direct X 12.

سيأتي نموذج تطبيق غير مزود بوضع الحماية - والذي سيعمل بنفس طريقة WPF (بما في ذلك Win32 APIs) ، ولكن مع الوصول إلى واجهات برمجة تطبيقات WinRT الحديثة ، وواجهة مستخدم مفتوحة المصدر وعناصر تحكم مع XAML الجديد الذي يعمل على Direct X 12.

رائع. واو واو!!!!

هذا مذهل! هل لدينا ETA لهذا الغرض ، هل سيتم مناقشته في المكالمة؟

إنه رائع بجنون!

سيأتي نموذج تطبيق غير مزود بوضع الحماية - والذي سيعمل بنفس طريقة WPF (بما في ذلك Win32 APIs) ، ولكن مع الوصول إلى واجهات برمجة تطبيقات WinRT الحديثة ، وواجهة مستخدم مفتوحة المصدر وعناصر تحكم مع XAML الجديد الذي يعمل على Direct X 12.

رائع. واو واو!!!!

هذا مذهل! هل لدينا ETA لهذا الغرض ، هل سيتم مناقشته في المكالمة؟

إنه رائع بجنون!

كان هذا أول شيء تعلمناه عن WinUI. الوقت المقدر للوصول لهذا العام ، أظن أنه سيتم تحديد تاريخ محدد في // Build / - ولكن لا تتردد في السؤال أثناء المكالمة.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

jtorjo انظر خارطة طريق WinUI . راجع أيضًا https://github.com/microsoft/microsoft-ui-xaml/issues/1045 لمزيد من المعلومات (مثل قوالب مشروع VS).

mdtauk @ Felix-Dev

jesbis آسف على سؤال noob - كيف أشارك في المكالمة؟

نقوم بإعداد المعلومات لمكالمة الغد في وقت لاحق اليوم - سأقوم بنشر الاتجاهات في غضون ساعات قليلة.

يرجع التأخير إلى أنها المرة الأولى التي نستخدم فيها نظام بث جديد - بعد ذلك نأمل أن يصبح أكثر سلاسة وأن يكون جاهزًا في وقت مبكر 🙂

كان لدي فقط فكرة مثيرة للاهتمام (بالنسبة لي على أي حال).

بإلقاء نظرة خاطفة على البث المباشر ASP.NET Community Standup اليوم ، رأيت 4 مطوري MS يقومون ببث ترميز مباشر ، على الرغم من أنه كان أكثر من عرض تقني. أقوم أيضًا أحيانًا بضبط csharpfritz على

لذلك كان تفكيري - بعد إصدار WinUI 3 وقاعدة الكود (أو معظمها) مفتوحة المصدر ، فهل سيكون أي من أعضاء الفريق مستعدًا للبث المباشر لبعض أعمالهم على WinUI من حين لآخر؟

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

ليس لدي أي فكرة عن سياسات مرض التصلب العصبي المتعدد في هذا النوع من الأشياء ، خاصة خلال يوم العمل. سيكون من الممتع سماع أفكارك.

إليك رابط الحدث المباشر على YouTube ليوم غد!

https://youtu.be/MXTVqgB4rW0

شكرا لجميع التعليقات والأسئلة حتى الآن! سنحاول الوصول إلى كل شيء ، أو متابعة المتابعة إذا لم يكن لدينا الوقت.

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

يرجى التفكير في زيادة أولوية النوافذ بلا حدود / الشفافة (على سبيل المثال https://github.com/microsoft/microsoft-ui-xaml/issues/1247). هذا هو مانع اعتماد WinUI للتطبيقات، مثل بلدنا .

نسخة إلى :

يرجى النظر في زيادة أولوية النوافذ بلا حدود / الشفافة (a la # 1247). هذا هو مانع اعتماد WinUI للتطبيقات، مثل بلدنا .

نسخة إلى: crutkas

قد يتطلب هذا على الأرجح إضافة عنصر نافذة المستوى الأعلى إلى WinUI Xaml بخصائص مشابهة لـ WPF. # 1323

سيكون تعلم المزيد عن "مستقبل النوافذ" لـ WinUI أمرًا رائعًا - فهناك الكثير من الطلبات ذات الصلة التي سيكون من الجيد مناقشتها / معالجتها على الأقل.

ربما سئل من قبل.

بالنسبة لي ، كانت دائمًا مسألة إعادة استخدام الكود.
هذا يقودنا إلى سؤالين:

1. هل ستدعم NET Core 3 و C # 8.0 أي شخص قريبًا؟
2. هل سنرى المزيد من الخطوات من فريق UWP / WinUI لتسهيل تطوير تطبيقات Uno Platform؟

واحد آخر ، متى سنرى البتات المفقودة من WPF مدعومة في UWP؟

ربما سئل من قبل.

بالنسبة لي ، كانت دائمًا مسألة إعادة استخدام الكود.
هذا يقودنا إلى سؤالين:

1. هل ستدعم NET Core 3 و C # 8.0 أي شخص قريبًا؟
2. هل سنرى المزيد من الخطوات من فريق UWP / WinUI لتسهيل تطوير تطبيقات Uno Platform؟

واحد آخر ، متى سنرى البتات المفقودة من WPF مدعومة في UWP؟

يجب أن يعمل كود .NET Core على كليهما ، لذلك سيحتاج تطبيق WPF فقط إلى تغيير رمز UI Xaml و UI.

يجب أن تعمل تطبيقات UWP بشكل جيد مع تغيير مساحة الاسم لـ WinUI 3.0 - قد يحتاج الخروج من وضع الحماية إلى مزيد من العمل ، ولا تزال التفاصيل غير معروفة.

لم يتم تأكيد البتات المفقودة لـ WPF ، لكنني أصدرت مشكلة حول هذا الموضوع. # 719

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

على الرغم من أنه غير مدعوم رسميًا ولن تعمل جميع ميزات C # 8 ، يمكنك بالفعل استخدام معظم C # 8 مع WinUI / UWP. انظر هنا .

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

مجرد تضخيم ما قاله kmgallahan حول استخدام C # 8. لقد كنت أستخدم العديد من الميزات الجديدة ، لكنني أردت حقًا أعضاء الواجهة الافتراضية ، والتي لم يتم تنفيذها بعد.

شكرا يا رفاق.
إذا كان لا يزال بإمكاني إضافة ، فإن نوع csproj القديم مزعج أيضًا نوعًا ما.

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

لقد فتحت هذه المشكلة للتو في معرض عناصر تحكم XAML. قد يكون شيئًا للمناقشة أثناء المكالمة إذا كنت ترغب في ذلك.

شكرًا ، سنحاول الإجابة على جميع الأسئلة!

هل يوجد أي شيء في الدليل حول الأداء / الإطارات في الثانية لواجهة المستخدم؟

ryvanvel لدينا بعض إرشادات الأداء هنا:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

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

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

كان هذا الخطأ مع نظام التشغيل Windows 10 بقدر ما أتذكر ، وآمل أن يتم معالجته قريبًا: https://github.com/microsoft/microsoft-ui-xaml/issues/597

لسوء الحظ ، لن أتمكن من الضبط في الوقت المحدد ، فهل سيكون هناك تسجيل؟

تحرير: يمكن العثور على تسجيل المكالمة هنا: https://www.youtube.com/watch؟v=MXTVqgB4rW0

jesbis هنا :

إليك رابط الحدث المباشر على YouTube ليوم غد!
https://youtu.be/MXTVqgB4rW0

باتباع رابط YT ، يبدو أنه سيبدأ فقط في نهاية هذه الساعة ، بعد ساعة من الوقت العادي ، هل هذا صحيح؟

weitzhandler وقت البدء أعلى

weitzhandler أنا متأكد من أن جميع المكالمات الثلاثة حتى الآن كان من المقرر أن تبدأ في 9 صباحًا بتوقيت المحيط الهادئ.

شكرا لكما واعتذر عن الازعاج اراك قريبا.

كنت مهتمًا بمعرفة ما إذا كان WebView2 الذي يدعمه Chromium سيعرض أيضًا حدثًا مثل WebResourceRequested من WebView ، للسماح للمطورين بتصفية طلبات الويب الفردية. أعتمد على هذه الميزة المحددة كثيرًا في أحد تطبيقاتي وكنت أتساءل عما إذا كان ذلك سيظل موجودًا مع عنصر التحكم الجديد ويعمل بنفس الطريقة.

شكرا يا رفاق على كل العمل الشاق! 😄🚀

هل ستكون هناك أي أداة لإنشاء ملفات PDF؟ يحتوي Win2D بالفعل على الكثير من الأدوات المذهلة ، وستكون القدرة على إنشاء ملفات PDF من CanvasRenderTarget إضافة رائعة.

لم تحصل عليه - كيفية تثبيت vsix؟ من أين تحميل؟

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

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

SavoySchuler إعادة

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

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

في المكالمة ، تحدثت عن النافذة مرتين وذكر أن:

• يتم العمل على هذا بالفعل مع WinUI 3 (على الرغم من تجميد المشكلة https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• مشروع تتبع الميزات (تم تحديثه بالأمس) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) يتعقب فقط عناصر WinUI 2 ؟؟؟

هل يمكننا الحصول على بعض الوضوح هنا؟ هل يوجد موقع آخر لمشاهدة تراكم WinUI 3؟ من الأهمية بمكان لأغراض التخطيط أن نعرف ما هو قادم وما لا يأتي. شكرا!

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

شكرًا جزيلاً لكل من استطاع الاستماع!

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

التسجيل مباشر الآن أيضًا لأي شخص لم يتمكن من التسجيل.

نحن نبحث في الأسئلة وسنحاول الوصول إلى أي شيء فاتنا في هذا الموضوع.

بعض الأسئلة اللحاق بالركب:

هل ستكون هناك أي أداة لإنشاء ملفات PDF؟

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

لن يكون لدينا الوقت للوصول إلى هذا من أجل WinUI 3.0 RTM ، لكننا نتتبع ذلك في التراكم مع # 672 - لا تتردد في إضافة تعليق على هذه المشكلة حول كيفية استخدامها!

كيفية تثبيت VSIX؟ من أين تحميل؟

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

تعليمات استخدام WinUI 2.x لتطبيقات الإنتاج موجودة هنا: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

تعليمات WinUI 3.0 Alpha لتثبيت وتجربة vsix هنا:
https://aka.ms/winui/alpha

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

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

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

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

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

إذا بدت الضوابط غير كاملة ، فيرجى فتح المشكلات لهم.

في المكالمة ، تحدثت عن النافذة مرتين وذكر أن:
يتم العمل على هذا بالفعل لـ WinUI 3 (على الرغم من تجميد المشكلة # 1247)
مشروع تتبع الميزات (تم تحديثه بالأمس) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) يتعقب فقط عناصر WinUI 2 ؟؟؟
هل يمكننا الحصول على بعض الوضوح هنا؟ هل يوجد موقع آخر لمشاهدة تراكم WinUI 3؟ من الأهمية بمكان لأغراض التخطيط أن نعرف ما هو قادم وما لا يأتي. شكرا!

riverar هذا المشروع هو حاليًا لـ WinUI 2 لأنه الرمز الوحيد في الريبو حاليًا.

نحن نستخدم تسمية needs-winui-3 للمشكلات التي يجب أن تنتظر WinUI 3 قبل أن يتم معالجتها بشكل صحيح ، ولكن ليس لدينا تتبع عام لعمل WinUI 3 حتى الآن.

سنستمر في نشر مقترحات الميزات للعناصر الرئيسية - مثل مواصفات Chromium WebView في المواصفات المنفصلة الريبو:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

وبمجرد أن نكون قادرين على فتح مصدر WinUI 3 Xaml ، يمكننا البدء في نقل التتبع إلى GitHub ، ولكن من المرجح أن يظل الجزء الأكبر من تتبع عناصر العمل اليومي داخليًا من خلال تطوير 3.0 لأسباب مختلفة (لدينا الكثير من تبعيات نظام التشغيل الخاص لفك التشابك ، والحاجة إلى التفاعل عن كثب مع فرق مطوري مكونات نظام التشغيل الأخرى ، وما إلى ذلك)

أستطيع أن أقول على الرغم من أن معظم اقتراحات الميزات التي تم وضع علامة عليها لن تتم معالجتها للإصدار 3.0 الأولي - مجالات تركيزنا الرئيسية هي:

• فصل WinUI عن نظام التشغيل وشحنه بشكل منفصل
• فتح مصدر إطار Xaml
• إنشاء تجربة تطوير جيدة لتطبيق WinUI لسطح المكتب (استخدام win32 ، والتعبئة ، والنوافذ ، وما إلى ذلك)
• تمكين Windows 10x
• تمكين تطبيقات .NET Core / 5 + WinUI

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

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

وبمجرد أن نكون قادرين على فتح مصدر WinUI 3 Xaml ، يمكننا البدء في نقل التتبع إلى GitHub ، ولكن من المرجح أن يظل الجزء الأكبر من تتبع عناصر العمل اليومي داخليًا من خلال تطوير 3.0 لأسباب مختلفة (لدينا الكثير من تبعيات نظام التشغيل الخاص لفك التشابك ، والحاجة إلى التفاعل عن كثب مع فرق مطوري مكونات نظام التشغيل الأخرى ، وما إلى ذلك)

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

أستطيع أن أقول على الرغم من أن معظم اقتراحات الميزات التي تم وضع علامة عليها لن تتم معالجتها للإصدار 3.0 الأولي - مجالات تركيزنا الرئيسية هي:

• فصل WinUI عن نظام التشغيل وشحنه بشكل منفصل
• فتح مصدر إطار Xaml

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

• إنشاء تجربة تطوير جيدة لتطبيق WinUI لسطح المكتب (استخدام win32 ، والتعبئة ، والنوافذ ، وما إلى ذلك)
• تمكين Windows 10x

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

• تمكين تطبيقات .NET Core / 5 + WinUI

يأتي الدعم الأصلي الحالي في شكل كود C ++ و Win32 APIs - ولكن هل هذا يعني أن أي مطوري C # بحاجة إلى استهداف .NET؟ هل سيسمح نموذج التطبيق غير المزود بوضع الحماية بتشفير C # بدون .NET؟

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

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

بدون CoreWindow (والذي سيكون UWP فقط من الآن فصاعدًا) - يعد Windowing أحد تلك الأشياء التي يجب أن تكون في مكانها منذ اليوم الأول. يحتوي WPF على كائن Window في XAML يتعامل مع عناصر التحكم والتصميم المرئي والشفافية وما إلى ذلك. ويتعامل مع تغيير الحجم والتقليل وما إلى ذلك. تتطلب أطر Win32 الأقدم طلاءًا يدويًا للأسطح التي لا تعتبر شيئًا لواجهة مستخدم XAML - فكيف يتم سد هذه الفجوة ؟

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

هل من الممكن إدراج عناصر العمل الداخلية هذه علنًا ، حتى لو ظهرت كمدخلات فارغة تحمل اسمًا عامًا مثل المشكلة الداخلية؟

يتمثل هدفنا بالتأكيد في نقل عملياتنا (بما في ذلك تتبع المشكلات) إلى مصدر مفتوح بالإضافة إلى الشفرة.

كبداية ، لدينا معلم WinUI 3.0 للتتبع عالي المستوى ، وبينما نقوم بترحيل رمز WinUI 3 Xaml لفتح المصدر ، سنفتح أيضًا المزيد من مشكلات "مستوى الميزات" في هذا المعلم.

ومع ذلك ، لن يشمل ذلك جميع مهام تطوير WinUI 3.0 اليومية على الفور - كمرجع ، نحن نتتبع حاليًا آلاف الأيام من أعمال التطوير ذات الصلة لعام 2020 ، ونحن لسنا مستعدين بعد لنقل جميع تتبعنا عالي الدقة إلى GitHub اليوم. سنصل إلى ذلك بمرور الوقت ، كما فعلنا مع WinUI 2.

لذلك ، سنبدأ بالمشكلات على مستوى الميزات (مثل التي بدأت حتى الآن - مثل WebView) وسنقوم بترحيل عملياتنا بالكامل إلى GitHub بمرور الوقت.

يأتي الدعم الأصلي الحالي في شكل كود C ++ و Win32 APIs - ولكن هل هذا يعني أن أي مطوري C # بحاجة إلى استهداف .NET؟ هل سيسمح نموذج التطبيق غير المزود بوضع الحماية بتشفير C # بدون .NET

هل تسأل عن .NET Native أو no .NET على الإطلاق؟ من الناحية الفنية ، أعتقد أن مواصفات C # كلغة لا تعتمد على .NET ، لكن ليس لدينا حاليًا أي خطط للتحويل إلى C ++ أو أي شيء من هذا القبيل.

بدون CoreWindow (والذي سيكون UWP فقط من الآن فصاعدًا) - يعد Windowing أحد تلك الأشياء التي يجب أن تكون في مكانها منذ اليوم الأول. يحتوي WPF على كائن Window في XAML يتعامل مع عناصر التحكم والتصميم المرئي والشفافية وما إلى ذلك. ويتعامل مع تغيير الحجم والتقليل وما إلى ذلك. تتطلب أطر Win32 الأقدم طلاءًا يدويًا للأسطح التي لا تعتبر شيئًا لواجهة مستخدم XAML - فكيف يتم سد هذه الفجوة ؟

@ marb2000 يعمل على ذلك وسيكون قادرًا على مشاركة المزيد من المعلومات كما هو متاح.

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

لكي نكون واضحين ، لن يقوم WinUI 3 بإحضار كل سطح مكتب win32 إلى منصات أخرى مثل HoloLens: ستظل التطبيقات العامة وواجهات برمجة التطبيقات هي السبيل للذهاب عند استهداف أجهزة متعددة.

تم النشر مبكرًا جدًا. تعليق كامل:

robloo - أريد أن أبدأ بالاتفاق مع الكثير من

الميثاق والموارد

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

1. تطوير WinUI 2
2. تسليم WinUI 3
3. المصدر المفتوح WinUI 3

كما تعلم ، نحن مطالبون بحزم نحو 2 و 3 لأن أ) هذه أهداف مقترنة و ب) مصادر مفتوحة WinUI تعني أنه يمكن للجميع التوقف عن الحظر من قبل الموارد المحدودة لفريقنا لأن WinUI سيتم تمكينه أخيرًا لقبول طلبات سحب المجتمع.

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

والشيء الآخر أريد أن أقول بوضوح هو أن كل عمل الخوض في تقديم WinUI 2 البق، وملء طلبات جديدة، وما إلى ذلك، سوف _ لا _ تضيع علينا. عندما يتم إصدار WinUI 3 ، سيكون لدينا مجموعة فرعية كبيرة من فريقنا متحررًا للعودة إلى عناصر العمل التي تعمل على تطوير النظام الأساسي بالإضافة إلى تمكين المجتمع من إرسال التعليمات البرمجية أيضًا. هذا يعني أننا نجهز الآن تراكمًا ستتعامل معه القوة الكاملة لفريقنا بمساعدة مجتمع UWP الحالي وقريبًا Win32 أيضًا.

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

NumberBox

سمات

دعنا نعود إلى NumberBox. أنت محق من الناحية الواقعية في قولك أن V1 هي مجموعة فرعية من الميزات المطلوبة.
تم تأخير ميزات V1 المخططة حتى V2 بسبب التبعيات على أشياء مثل التحقق من صحة الإدخال (وهو بالمناسبة في المعاينة في WinUI 3 alpha). لقد حاولنا أن نكون كاملين في المواصفات الخاصة بنا من خلال الاعتراف بكل شيء نعتقد أنه يستحق أن يكون V1 في المواصفات (هنا) ونخطط للوفاء الكامل بهذا الالتزام من خلال إصدار WinUI 3 V2 لعنصر التحكم.

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

البق

كما قال jesbis ، لا توجد قاعدة أكواد خالية من الأخطاء ، ولكن الجودة هي jesbis ، أنه يمكنك رؤية نسبة إصلاحات الجودة مقابل الميزات الجديدة في سجل الالتزام لـ WinUI 2 ، وبمجرد أن يكون مفتوح المصدر ، ستتمكن من رؤية نفس الشيء لـ WinUI 3.

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

الخطوات التالية

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

نحن ❤️ WinUI

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

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

yaichenbaum كان بإمكاني اختيار كلماتي بشكل أفضل هناك. 🙂

إذا كانت AD هي _يجب أن تمتلك_ ميزات و EH _ جيدة أن يكون لها _ ميزات ، فإن أولويتي هي إخراج AD من الباب وإضافة EH بشكل تدريجي قدر المستطاع.

السبب في أننا نقوم بالتدريج في فرع المعاينة مع شركاء التحقق من الصحة هو اكتشاف الأخطاء مثل # 1846 قبل دفع عناصر التحكم إلى إصدار مستقر. نأسف لأننا أسقطنا الكرة على هذه الكرة ، سأعمل مع teaP في أسرع وقت ممكن لمعرفة مدى السرعة التي يمكننا بها حل هذا الأمر! 🙂

في وقت ما من المكالمة ، تم ذكر أن تطبيقات WinUI ستسمح بوضع الحماية عبر AppDomain.

هل يمكن لأي شخص التحدث عن كيفية قيام WinUI 3.0+ بتحديد موقع القدرات مقابل AppDomain لعزل التطبيق والتحكم في الموارد؟

أيضًا ، آخر ما عرفته لـ .Net Core ، لم يكن الدعم الكامل لـ AppDomain يحدث.

ربما أنا بعيد المنال ، لكن هل تقول أن Net 5 سيحصل على دعم AppDomain الكامل؟

شكرا لتنظيم هذه المكالمة اليوم!

هل يمكن لأي شخص التحدث عن كيفية قيام WinUI 3.0+ بتحديد موقع القدرات مقابل AppDomain لعزل التطبيق والتحكم في الموارد؟

آسف إذا لم يكن الأمر واضحًا في المكالمة ولكني كنت أتحدث عن AppContainer ، وليس AppDomain.

آه ، حسنًا ، شكرًا على التوضيح جيسي.

بادئ ذي بدء ، شكرًا jesbis (وجميع أعضاء فريق WinUI) على تنظيم مكالمة المجتمع اليوم! على الرغم من وجود بعض الصعوبات التقنية ، إلا أن هذه المكالمة كانت ثاقبة للغاية !!!

كما ذكر jesbis ، هناك مشكلة في تتبع الأدوات والميزات المطلوبة لـ WinUI 3.0. هل من الأفضل تقسيم طلب أداة التحويل WinUI 2.x إلى 3.0 إلى مشكلة منفصلة لتسهيل التتبع؟ أيضا هل هناك بالفعل أي خطط؟ هل هناك خطط لجعل الأداة مفتوحة المصدر بحيث يمكن للمطورين الآخرين المساعدة في تطويرها؟

سؤال آخر أكثر عمومية (والذي سيكون أيضًا لأعضاء فريق WinUI الآخرين) ، يتعلق بالمساهمة. هل هناك حاليا معوقات تمنع الناس من المساهمة؟ هل سيساعد دليل البدء الأفضل للمساهمين؟

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

ربما ستجعل التحسينات في هذا المجال من السهل على الناس المساهمة 😅

كيف يتم عمل طبقة التقديم WinUI 3.0؟ هل تستخدم مباشرة D3D11 ، D2D ، طبقة التجريد أم ماذا؟ هل تحتوي على طبقة عرض برمجية أو تستخدم D3D WARP لذلك؟

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

سأكرر النقاط التي ذكرتها للتو هنا :

• عدم استخدام اللغة إلى الأبد
• لا توجد فكرة عن مقدار اضطراب الكود الذي يحدث في الخلفية لإصدار WinUI 3 الذي سيحل محل التغييرات التي تم إجراؤها اليوم
• لا يوجد وصول إلى مجموعة من التعليمات البرمجية المصدر التي ستكون مطلوبة و / أو تساعد بشكل كبير في حل المشكلات

تحرير: سأعطي مثالا. يبدو أن # 1555 و # 1849 مشكلتان رئيسيتان مع عنصر تحكم أساسي (TextBox) يمنع إدخال النص والاختيار أثناء تعدد المهام.

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

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

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

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

NumberBox هو عنصر تحكم تم تطويره حديثًا لـ WinUI 2.3 وليس عنصر تحكم قديم يجب على الجميع قبوله في هذه المرحلة. لماذا لا نفعل هذا بشكل صحيح للبدء؟ هذا اختبار حقيقي لنموذج التطوير الجديد.

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

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

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

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

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

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

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

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

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

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

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

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

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

فهم على مستوى عال. ومع ذلك ، فإن إصلاح المشكلات المذكورة أعلاه لن يؤدي إلى تأخير WinUI 3.0 لمدة 6 أشهر. كما أنها لا تعتمد على WinUI 3.0 في العنوان (باستثناء احتمال # 1721). أنت تضع سابقة خطيرة من خلال إطلاق NumberBox ثم عدم التمسك بها لإغلاق الجولة الأولى من الأخطاء. يجب أن تكون قد تعلمت هذا الدرس بالفعل مع UWP نفسها.

ربما ستجعل التحسينات في هذا المجال من السهل على الناس المساهمة

أحب المساهمة. لا تحب العمل مع C ++ / WinRT وبالتأكيد لا تشعر أنك مؤهل للمس قاعدة التعليمات البرمجية كما رأيتها. إذا تمت إدارة عناصر التحكم C # لكانت قد حصلت على مساهمات أكثر بكثير. أفهم سبب كون الهندسة على ما هي عليه ، لكن إحدى النتائج هي تقليل مساهمات المجتمع. نحن لسنا مطوري أنظمة هنا ، نحن مطورو تطبيقات المستخدم النهائي.

RE: المساهمة:

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

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

لدينا الكثير من العناصر التي تم وضع علامة عليها بعدد أول جيد ونريد المساعدة إذا

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

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

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

هؤلاء لا يزالون بحاجة إلى فرزهم (تصنيفهم) من قِبل مالكي مطوري البرامج لدينا (ومن هنا جاءت تسمية "الاحتياجات-الفرز" - أتابع حاليًا سبب عدم ظهورهم بعد ، آسف) ولكني أتوقع ذلك نظرًا لأن TextBox ليس في WinUI 2 سيتعين على هؤلاء انتظار WinUI3.

بمجرد أن يتم فرزهم ، يجب أن يكون لديهم ملصق needs-winui-3 مطبق مما يشير إلى أنه سيتعين عليهم انتظار WinUI 3 قبل أن نتمكن من معالجتها.

بمجرد أن يصبح WinUI 3 مفتوح المصدر ، سيتمكن أي شخص من المساعدة في حل هذه المشكلات أيضًا.

لا تحب العمل مع C ++ / WinRT وبالتأكيد لا تشعر أنك مؤهل للمس قاعدة التعليمات البرمجية كما رأيتها. إذا تمت إدارة عناصر التحكم C # لكانت قد حصلت على مساهمات أكثر بكثير.

نحن نعلم أن C ++ تمثل حاجزًا أعلى من C # ، لكن الخطة هي أن WinUI ستظل منصة C ++.

مشروع آخر رائع للمساهمة فيه هو Windows Community Toolkit الذي يسهل المساهمة فيه نظرًا لأنه C # ولديه بعض المتطلبات المريحة.

نحن نعمل مع المشرفين وغالبًا ما نستخدم مجموعة أدوات المجتمع لاحتضان عناصر تحكم جديدة تنتقل في النهاية إلى منصة Xaml (والتي تتضمن إعادة التنفيذ في C ++).

هل تتطلب WinUI C ++ / CX؟ إذا كان الأمر كذلك ، يبدو أن هذه مشكلة لـ Win32 والأهداف المستقبلية الأخرى؟

كيف يتم عمل طبقة التقديم WinUI 3.0؟ هل تستخدم مباشرة D3D11 ، D2D ، طبقة التجريد أم ماذا؟ هل تحتوي على طبقة عرض برمجية أو تستخدم D3D WARP لذلك؟

يتم تنفيذ عرض إطار عمل WinUI Xaml بشكل أساسي على محرك تكوين Windows 10 . ستكون واجهات برمجة التطبيقات لطبقة التكوين جزءًا من WinUI 3.

في النهاية ، يعني هذا عمومًا العرض المسرع للأجهزة باستخدام Direct3D و Direct2D و DirectWrite ، مع عرض البرنامج في بعض الحالات حيث يكون ذلك منطقيًا.

يمكنك أيضًا تضمين محتوى DirectX المخصص الخاص بك باستخدام واجهات برمجة تطبيقات التشغيل المتداخل.

هل تتطلب WinUI C ++ / CX؟ إذا كان الأمر كذلك ، يبدو أن هذه مشكلة لـ Win32 والأهداف المستقبلية الأخرى؟

لا - منصة WinUI مكتوبة بلغة C ++ ولكن بالتأكيد لا يجب أن تكون تطبيقاتك!

باستخدام WinUI 2 اليوم ، يمكنك إنشاء تطبيقات UWP باستخدام .NET (C # ، VB.NET) أو C ++.

مع WinUI 3 ، هدفنا هو أن تكون قادرًا على إنشاء تطبيقات تستخدم UWP و / أو win32 APIs باستخدام .NET 5 أو C ++ القادم.

jesbis أعتقد أنك ربما تكون قد أسيء فهم نية أسئلتي قليلاً.

1) أعرف أن WinUI مكتوب بلغة C ++ ، ولكن هل يتطلب أي كود WinUI امتدادات Windows فقط VC ++ / CX؟ إذا تطلب الأمر امتدادات CX ، فأنا أرى أن هذا ربما يتسبب في حدوث مشكلات في قابلية النقل إذا أراد WinUI التوسع إلى أنظمة أساسية أخرى. هذا قد يجعل من الصعب على فريق UNO اعتماد رمز على سبيل المثال.

2) حول نظام التقديم. زوجان من الأشياء هنا.

2.a) هل "الطبقة المرئية" هي واجهة برمجة تطبيقات تجريدية تمت إزالتها بعيدًا بما يكفي عن DirectX APIs بحيث يمكن أن تدعم لاحقًا واجهة Vulkan الخلفية على سبيل المثال؟ (أنا متأكد من أنه سيتم الرد على هذا السؤال عند إصدار المصدر ولكني أتساءل فقط)

2. ب) كان سؤالي حول تنقيط البرامج يتماشى بشكل أكبر مع الأسطر التالية: هل يدعم WinUI 3.0 عرض البرامج بالكامل (ليس فقط عرض النص أو ما لا)؟ في بعض الأحيان ، يواجه برنامج مشاركة الشاشة مشكلات مع تطبيقات تسريع GPU (على الأقل مع D3D9 / WPF) وإجبار عرض البرامج على إصلاح المشكلة في تلك المواقف). أو إذا تم تشغيل التطبيق في جهاز افتراضي بدون وحدة معالجة رسومات للأجهزة.

تعليمات WinUI 3.0 Alpha لتثبيت وتجربة vsix هنا:
https://aka.ms/winui/alpha

فعل ذلك باستخدام Edge New ، ظهر رابط التنزيل ، وكرره مع chrome- قم بالتنزيل هناك

فعل ذلك باستخدام Edge New ، ظهر رابط التنزيل ، وكرره مع chrome- قم بالتنزيل هناك

hannespreishuber يجب أن يكون رابط التنزيل في الصفحة الأخيرة من الاستطلاع. هل تقصد أن الاستطلاع لم يعمل في Chromium Edge ولكنه عمل في Chrome؟

يجب أن يكون رابط التنزيل في الصفحة الأخيرة من الاستبيان. هل تقصد أن الاستطلاع لم ينجح في Chromium Edge ولكنه عمل في Chrome؟

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

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

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

أعرف أن WinUI مكتوب بلغة C ++ ، لكن هل يتطلب أي كود WinUI امتدادات Windows فقط VC ++ / CX؟ إذا كان يتطلب امتدادات CX ، فأنا أرى أن هذا ربما يتسبب في حدوث مشكلات في قابلية النقل

@ zezba9000 ، قمنا بتنفيذ عناصر تحكم وميزات WinUI 2 (الكود الجديد الموجود حاليًا في الريبو) باستخدام C ++ / WinRT وهو معيار C ++ 17 ، لكن بقية WinUI 3 هي قاعدة بيانات أكبر وأقدم بكثير والتي لا تزال تعتمد حاليًا على WRL وما إلى ذلك. نحن لا نركز على قابلية النقل في هذا الوقت ولكننا منفتحون على مناقشتها في المستقبل.

هل "الطبقة المرئية" عبارة عن واجهة برمجة تطبيقات للتجريد تمت إزالتها بعيدًا بما يكفي عن DirectX APIs بحيث يمكنها لاحقًا دعم Vulkan الخلفية على سبيل المثال؟ (أنا متأكد من أنه سيتم الرد على هذا السؤال عند إصدار المصدر ولكني أتساءل فقط)

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

كان سؤالي حول تنقيط البرامج يتماشى مع الأسطر التالية: هل يدعم WinUI 3.0 عرض البرامج بالكامل (ليس فقط عرض النص أو ما لا)؟ في بعض الأحيان ، يواجه برنامج مشاركة الشاشة مشكلات مع تطبيقات تسريع GPU (على الأقل مع D3D9 / WPF) وإجبار عرض البرامج على إصلاح المشكلة في تلك المواقف). أو إذا تم تشغيل التطبيق في جهاز افتراضي بدون وحدة معالجة رسومات للأجهزة.

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

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

أوافق بنسبة 100٪ - لا أريد حتى أن أتذكر عدد الساعات التي أقضيها في حل الأخطاء من UWP / WinRT.

جيسي ،

أنا مهتم بشكل أساسي بتطوير تطبيقات المؤسسة. أنا أستخدم حاليًا WinUI 3.0 Alpha لبناء دليل على المفهوم لإظهار كيف يمكن لـ Xaml و GPRC والنوافذ المتعددة والخيوط المتعددة الحقيقية أن توفر لمستخدم الأعمال والمستخدمين تجربة تطبيق أكثر إنتاجية.

لماذا ا؟ لأننا نحتاج إلى بديل للتطبيقات المستندة إلى المستعرض / الشاشة الصغيرة. لدي الكثير لأقوله حول هذا الموضوع ، لكنني سأذهب إلى KISS هنا.

ما أريده من فريق WinUI وفي الواقع Microsoft هو احتضان ودعم إنشاء تطبيقات سطح المكتب للأعمال.

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

يبدو أن معظم صناعة تطوير البرمجيات تركز على تقديم تطبيقات للمتصفح و / أو عامل شكل الهاتف / الجهاز اللوحي.

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

هناك أبعاد أخرى في تطبيقات المؤسسة لا تحظى بالكثير من النقاش - طول العمر ومجموعة المهارات. مرة أخرى ، الكثير لأقوله هنا ، لكنني سألخص. تستثمر الشركات الأموال في إنشاء التطبيقات وتخطط لاستخدام هذه التطبيقات لفترة "طويلة". هذا يعني أن التكنولوجيا الأساسية بحاجة إلى الدعم لعقود. أود أن أرى أن WinUI هي تلك التقنية طويلة الأمد التالية لتحل محل Win32 / MFC و WinForms.

تكافح أقسام تكنولوجيا المعلومات باستمرار للعثور على SE مع مجموعة المهارات المناسبة. جعلت تقنية الويب هذا الأمر أكثر صعوبة. أرغب في رؤية مكدس جديد C # و Xaml و SQL (C # XS) يحدد التركيز على بناء تطبيقات سطح المكتب.

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

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

لدي المزيد من الأفكار لمشاركتها إذا كنت مهتمًا ، لكنني سأتوقف هنا وألخص:

• تحتاج Microsoft إلى توفير حل شامل لتطوير تطبيقات سطح المكتب.
• تحتاج WinUI / Fluent إلى تلبية متطلبات مستخدم الأعمال مثل الوظيفة / النموذج ، UX لسطح المكتب ، نماذج التعليمات البرمجية / قوالب المشاريع التي توضح نوافذ متعددة ، خيوط متعددة حقيقية ، التحقق من صحة البيانات ، صفحات "تشبه النموذج".
• تحتاج Microsoft إلى توضيح أنها تقدم WinUI لإنشاء تطبيقات LOB للأعمال عالية الإنتاجية وطويلة الأمد. أيضًا ، لماذا لن يكون NET 5 + WinUI بمثابة جحيم DLL آخر.
• توضيح أن WinUI هو بديل Win32 / MFC و WinForms.
• ادفع C # XS كمجموعة مهارات لتقنية المعلومات.
• (مجاني) Datagrid

آمل أن تكون قد وجدت هذا مفيدًا.

robloo الراحة بسهولة - لا حاجة للنقاش! 🙂 لقد التزمت بإصلاح هذا الخطأ في تعليقي المبكر ولا يزال هذا صحيحًا. أعتقد أنني ارتكبت خطأ في وقت سابق بمواصلة التعميم. دعنا نتحدث عن الأخطاء التي ذكرتها. تم تقديم اثنين قبل عطلتنا الرئيسية هنا (لا يمكنني التحدث عن

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

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

SavoySchuler ، يبدو أنك عالق في موقف صعب للاختيار بين:

أ) إصلاح الخلل في WinUI 2.x وتأخير إصدار WinUI 3.0
أو
ب) اترك WinUI 2.x للمجتمع ، وخصص الموارد الداخلية نحو WinUI 3.0 لتحقيق أقرب تاريخ للإصدار

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

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

jesbis ، من المثير للاهتمام أن نسمع عن الطبقة المرئية فيما يتعلق بـ WinUI 3.0. هل تقول أنه بالنسبة للإصدارات الأولية ، سيكون لبرنامج WinUI 3.0 تبعية على فئات Windows.UI.Composition ؟ هل هناك إمكانية لإضافة المزيد من الميزات إلى نظام التشغيل لدعم الطبقة المرئية قبل الاستخراج في WinUI 3.0؟

للإشارة ، الأشياء التي تثير اهتمامي:

• نموذج Win32 "AppContainer". نحن في وضع الحماية متوافقين تمامًا مع أنظمة تشغيل أخرى ، لكننا نرغب في الوصول إلى واجهات برمجة التطبيقات "الحديثة"
• الطبقة المرئية ( Windows|Microsoft.UI.Composition )
• سلاسل التبادل DXGI في الطبقة المرئية / SwapChainPanel
• واجهات برمجة تطبيقات إدارة النوافذ (AppWindow ، إلخ)

infoequipt شكرا على الملاحظات المتعمقة! بالتأكيد مفيد. @ marb2000 للرؤية

من المثير للاهتمام أن نسمع عن الطبقة المرئية فيما يتعلق بـ WinUI 3.0. هل تقول أنه بالنسبة للإصدارات الأولية ، سيكون لبرنامج WinUI 3.0 تبعية على فئات Windows.UI.Composition؟

MarkIngramUK لا ، آسف لأي ارتباك - كانت نقطتي السابقة تتعلق فقط بمصادر مفتوحة.

سيكون Microsoft.UI.Composition جزءًا من WinUI 3 وسيعتمد عليه Microsoft.UI.Xaml. هذا هو الحال بالفعل مع WinUI 3 Alpha.

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

شكرا للتوضيح jesbis أقدر كثيرا. ما هي طرق التوزيع التي ستستخدمها لهذا؟ نحن تطبيق متعدد المنصات ، لذلك نستخدم CMake ، ونعتمد على Windows.UI.Composition ، لذلك أحب طريقة لإحضار dll الجديد ، lib ، الرؤوس وما إلى ذلك بسهولة.

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

هل هناك خطة لفتح مصدر Microsoft.UI.Composition في النهاية؟

MarkIngramUK أنا أتفق إلى حد كبير مع ما تقوله ، وما تقوله @ SavoySchuler في عرض "الصورة الكبيرة". كما أشرت ، يصعب علينا مستخدمي WinUI 2.0 قبول الأخطاء نظرًا لأن لدينا تطبيقات إنتاج في الوقت الحالي. نحتاج إلى إيجاد حل وسط بين إصلاح بعض الأخطاء التي لن تؤخر WinUI 3.0 وأيضًا إبقاء WinUI 3.0 على المسار الصحيح. كان هناك إحباط إضافي من أن NumberBox كان عنصر تحكم جديد تمامًا بدا أنه تم إهماله على الفور - مع تعليق بأن Microsoft لن تعود إليه لأكثر من عام. بغض النظر ، أنا أوافق بالتأكيد على أن WinUI 3.0 هي الأولوية ولا أريد أن يتأخر بأي سعة كبيرة.

ربما ينبغي أن أقول إنني أقدر كل العمل الذي تقوم به Microsoft هنا وجهودهم لتكون أكثر شفافية وتواصلًا مع التوجيه.

ما هي طرق التوزيع التي ستستخدمها لهذا؟ نحن تطبيق متعدد المنصات ، لذلك نستخدم CMake ، ونعتمد على Windows.UI.Composition ، لذلك أحب طريقة لإحضار dll الجديد ، lib ، الرؤوس وما إلى ذلك بسهولة.

MarkIngramUK هل تعمل حزم NuGet المستهلكة من أجلك؟ أي ما نفعله مع WinUI 2.x و WinUI 3 Alpha. ما زلنا نعمل على بعض تفاصيل التوزيع مع فريق Visual Studio. في الوقت الحالي ، يحتوي WinUI 3 Alpha على ثنائيات Xaml و Composition في حزمة واحدة ولكننا سنقوم بفصلها لدعم المصادر المفتوحة Xaml والقدرة على إنشاء Xaml بشكل منفصل.

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

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

هل هناك خطة لفتح مصدر Microsoft.UI.Composition في النهاية؟

من المحتمل أن نفكر في عملنا المتراكم ولكن ليس لدينا خطة لذلك.

MarkIngramUK إذا كان بإمكاني أن أسأل: ما الفائدة التي تأمل في الحصول عليها من كونها مفتوحة المصدر؟

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

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

robloo شكرا! نحن نحاول حقًا أن نتحلى بالشفافية ومن الجيد أن نعرف أن هذه قيمة 🙂

فقط لتكرار ما ذكره سافوي ، لدينا مطورون يعملون على WinUI 2.x (كما يمكن أن نرى من سجل العلاقات العامة أيضًا) لذلك نحن بالتأكيد لا نزال نستثمر في كل من WinUI 2 و 3 بالتوازي - إنه فقط معظم أعمالنا الموارد موجودة على WinUI 3. أوافق على أن NumberBox على وجه الخصوص يحتاج إلى بعض الاهتمام وأن قائد مطوري ضوابط Xaml يبحث في الأمر الآن.

robloo أنت الأفضل! 😄 آسف مرة أخرى للارتباك - الشيء الوحيد الذي يخضع لذلك التأخير لمدة عام تقريبًا هو أوضاع التحقق الإضافية من عمل التحقق من صحة الإدخال الشامل والمقرر لـ 3.0. إلاteaP،ranjeshj، وسوف أكون على قائمة NumberBox الأخطاء بدءا من الأسبوع المقبل. 🙂

أعتقد أن jesbis غطت كل شيء آخر!

jesbis ،

MarkIngramUK هل تعمل حزم NuGet المستهلكة من أجلك؟ أي ما نفعله مع WinUI 2.x و WinUI 3 Alpha. ما زلنا نعمل على بعض تفاصيل التوزيع مع فريق Visual Studio. في الوقت الحالي ، يحتوي WinUI 3 Alpha على ثنائيات Xaml و Composition في حزمة واحدة ولكننا سنقوم بفصلها لدعم المصادر المفتوحة Xaml والقدرة على إنشاء Xaml بشكل منفصل.

سأكون صادقًا ، فأنا لست على دراية بـ NuGet ، ولكن بالنظر إلى إجابة SO هذه ، يبدو أنها ستنجح فقط إذا استخدمت CMake لإنشاء ملفات مشروع VS ، وهي ليست الطريقة التي نعمل بها عادةً (عادةً ما نفتح المجلد فقط ، والذي يستخدم Ninja كمولد). إنه لأمر مخز أنه لا يمكنك شحن المصدر ، حيث يمكنك استخدام vcpkg أيضًا. كمرجع ، نقوم ببناء جميع المكتبات من المصدر (مما يتجنب أي مشاكل ABI محتملة ، خاصة بالنظر إلى أننا قمنا بالبناء باستخدام Clang / LLVM على Windows أيضًا).

هل هناك خطة لفتح مصدر Microsoft.UI.Composition في النهاية؟

من المحتمل أن نفكر في عملنا المتراكم ولكن ليس لدينا خطة لذلك.

لدي اهتمام بهذا الأمر ، لذا أود أن أشارك في المناقشة إذا / عندما يحدث ذلك.

MarkIngramUK إذا كان بإمكاني أن أسأل: ما الفائدة التي تأمل في الحصول عليها من كونها مفتوحة المصدر؟

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

الأفكار الأولية تساهم / تتوسع (كما ذكرت سابقًا ، لدينا اعتماد على Windows.UI.Composition ، ولكن ليس Xaml Framework / UWP) ، على الرغم من التفكير بصوت عالٍ ، ونقل الطبقة المرئية إلى Vulkan أو Metal الخلفية للتقاطع قد يكون النظام الأساسي مثيرًا ، لكنني لم أفكر إلا في 30 ثانية حرفيًا. أيضًا ، من شأن فتح المصادر أن يخفف من القلق المزعج بشأن اعتماد إطار عمل آخر ستتخلى عنه Microsoft في النهاية في غضون بضع سنوات (تم تصميم تطبيقاتنا الحالية على WPF ، وتم تصميم تطبيقاتنا السابقة على MFC ، وكان لدينا مكونات ويب باستخدام Silverlight ، لذلك ، قد ترى من أين أتيت من هنا ...).

NumberBox

مرحبا جميعا! لقد عملت مع teaP و ranjeshj على جميع عناصر NumberBox المفتوحة اليوم.

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

شكرا للجميع على العمل معنا. 🙂 نحن WinUI!

هل يوجد "تقويم" لمكالمات مجتمع WinUI؟ مثال: في شكل تقويم عام يمكننا إضافته / دمجه في تقويمنا المباشر / google / * ، للحصول على تحديثات تلقائية لتفاصيل المكالمات.

تمت جدولة أحداث YouTube مسبقًا بحيث يمكنك إضافة تذكير Google هنا ضمن "مجموعات البث المباشر القادمة":

https://www.YouTube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

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