شكرا لك على الاستماع إلى ردود فعل المجتمع. أنا متحمس حقًا لـ WinUI 3.0 (Win32 + WinUI + C ++). هذا يبدو وكأنه إطار العمل الذي كنا ننتظره! RIP GDI 😉

(طراز تطبيق Win32) + (WinUI 3.0 UI) + (لغة .NET أو C ++)

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

شكرًا لك على التحديث ، ونأمل أن تأتي المزيد من التحديثات عندما يتم تأمين مجموعة الميزات الأولية لـ WinUI 3.0 ، وأي عناصر تحكم أو ميزات تحكم جديدة تم اقتراحها ، والتي قد تجعلها في WinUI 3.0.

أوه ، والتوثيق حول كيفية عمل WinUI في سطح المكتب ، وتختلف عن UWP ، و WPF ، و Win32 سيكون مفيدًا للغاية لاستباق العدد الهائل من الأسئلة التي ستظهر.

ربما تكون هناك مصفوفة لطيفة لما يتم تضمينه مع أي مجموعة من الأطر وواجهات برمجة التطبيقات ، جنبًا إلى جنب مع المخططات المعمارية التي حصلنا عليها في Build!

أنتم يا رفاق لا يصدقون ، شكرا على كل شيء!
جعل قسم xplat يومي ، خاصة أن Uno على الرادار.

لا يزال تركيزنا منصباً على نظامي التشغيل Windows 10 و 8.1 ، ولكننا نسمع التعليقات التي تفيد بأن بعضكم لا يزال لديه مستخدمون وعملاء على Win7 وسنقوم بتقييم السوق والخيارات بمرور الوقت.

بافتراض أن هذا الزرع لإطار عمل واجهة المستخدم مصمم مع مراعاة فكرة قابلية النقل ، على الأقل بما يكفي بحيث يمكن أن يعمل جوهر واجهة المستخدم (التقديم / الإدخال) تحت أي نظام تشغيل Windows يدعم NET Core 3+ وما هي القيود الموجودة على Windows 7 حتى يكون؟ يبدو أن معظم الميزات التي يستخدمها الأشخاص على سطح المكتب ستعمل فقط وللميزات الخاصة / الخاصة بالنظام الأساسي التي لا تعمل ، ربما تمنعها من أن تكون جزءًا من نظام واجهة المستخدم الأساسي والاحتفاظ بها في حزم خاصة بالنظام الأساسي مثل (Win10 ، Win8.1 ، Win7 Nugets إلخ).

أيضًا إذا كان هناك XAML متعدد المنصات له نفس الشكل والمظهر عبر جميع الأجهزة (Win32 و Android و iOS و WASM) كما يمكنك فعله باستخدام HTML (ولكن ليس Xamarin للأسف) لكانت شركتي قد قفزت عليه منذ سنوات.

سعيد أيضًا يا رفاق اعتبرتم هذا "ماراثون (لعبة Bungie رائعة أيضًا)". كلما قل التشرذم في مساحة XAML ، كان ذلك أفضل للجميع ، وسيؤدي اتباع العديد من الاختصارات إلى إعادتك إلى حيث بدأت ؛)

وثائق حول كيفية عمل WinUI في سطح المكتب ، والتي تختلف عن UWP و WPF و Win32 ستكون مفيدة جدًا

نحن نعمل على ذلك وسنشارك المزيد مع تطور هذا الأمر!

بافتراض أن هذا الزرع لإطار عمل واجهة المستخدم مصمم مع مراعاة فكرة قابلية النقل ، على الأقل بما يكفي بحيث يمكن أن يعمل جوهر واجهة المستخدم (التقديم / الإدخال) تحت أي نظام تشغيل Windows يدعم NET Core 3+ وما هي القيود الموجودة على Windows 7 حتى يكون؟

@ zezba9000 لا تستخدم WinUI .NET ، وليس عليك بالضرورة استخدام .NET Core مع WinUI: إنه إطار عمل أصلي مبني على واجهات برمجة تطبيقات نظام التشغيل ، ويعتمد على وظائف جديدة في Win8 / Win10 لم تكن موجودة في Win7 - في بعض الحالات للميزات الأساسية ، وليس فقط ميزات الوظائف الإضافية ذات المستوى الأعلى مثل عناصر التحكم المحددة.

وثائق حول كيفية عمل WinUI في سطح المكتب ، والتي تختلف عن UWP و WPF و Win32 ستكون مفيدة جدًا

نحن نعمل على ذلك وسنشارك المزيد مع تطور هذا الأمر!

بافتراض أن هذا الزرع لإطار عمل واجهة المستخدم مصمم مع مراعاة فكرة قابلية النقل ، على الأقل بما يكفي بحيث يمكن أن يعمل جوهر واجهة المستخدم (التقديم / الإدخال) تحت أي نظام تشغيل Windows يدعم NET Core 3+ وما هي القيود الموجودة على Windows 7 حتى يكون؟

@ zezba9000 لا تستخدم WinUI .NET ، وليس عليك بالضرورة استخدام .NET Core مع WinUI: إنه إطار عمل أصلي مبني على واجهات برمجة تطبيقات نظام التشغيل ، ويعتمد على وظائف جديدة في Win8 / Win10 لم تكن موجودة في Win7 - في بعض الحالات للميزات الأساسية ، وليس فقط ميزات الوظائف الإضافية ذات المستوى الأعلى مثل عناصر التحكم المحددة.

للتوافق مع نظام التشغيل Windows 7 - قد يتطلب الأمر من بعض الأطراف الثالثة إنشاء العارض المتوافق الخاص بهم لـ XAML ، بالإضافة إلى نوع من Shim البديل لأي واجهات برمجة تطبيقات على مستوى نظام التشغيل مطلوبة.

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

إنه إطار عمل أصلي مبني على واجهات برمجة تطبيقات نظام التشغيل ، ويعتمد على وظائف جديدة في Win8 / Win10 لم تكن موجودة في Win7 - في بعض الحالات للميزات الأساسية

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

قد تكون أشياء مثل دعم رمز علبة الورق وما إلى ذلك في حزمة "ميزات WinUI Windows الأساسية (Win7-Win10)". يمكن أن تكون أشياء مثل إشعارات الدفع في حزمة "ميزات WinUI Windows الموسعة (Win8-Win10)".

اتمنى ان يكون هذا منطقي

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

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

هل تتوقع أن يكون لديك عملاء جدد على Win7 في 2020+؟ تساعدنا التعليقات وحالات الاستخدام المحددة في تحديد الأولويات.

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

هل تتوقع أن يكون لديك عملاء جدد على Win7 في 2020+؟ تساعدنا التعليقات وحالات الاستخدام المحددة في تحديد الأولويات.

jesbis لا أرى فائدة كبيرة في إضافة التوافق إلى Win7 لـ WinUI 3.0 - ومع ذلك ، قد يكون Linux و Android و iOS و iPadOS و MacOS مفيدًا لتوفير حل عبر الأنظمة الأساسية ، والذي لا يعتمد على أطر عمل واجهة المستخدم الأصلية.

تضمين التغريدة
jesbis لا أرى فائدة كبيرة في إضافة التوافق إلى Win7 لـ WinUI 3.0 - ومع ذلك ، قد يكون Linux و Android و iOS و iPadOS و MacOS مفيدًا لتوفير حل عبر الأنظمة الأساسية.

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

هل تتوقع أن يكون لديك عملاء جدد على Win7 في 2020+؟ تساعدنا التعليقات وحالات الاستخدام المحددة في تحديد الأولويات.

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

لتوضيح ما تود شركتي رؤيته هو أن دعم Android و WASM يكون رسميًا أكثر قليلاً من UNO (وقبل 3 سنوات). نصنع برنامج إدارة يحكم حالة مجموعة من أجهزة الكمبيوتر المحلية وإعدادات النظام التي تتضمن عادةً حاجة كبيرة لواجهة برمجة تطبيقات Win32 (لن تعمل UWP من أجلنا أبدًا ولكننا نحب واجهة المستخدم بسبب أخطاء وقت الترجمة على عكس أنظمة إنشاء HTML) و يحتاج العملاء + لنا إلى تجارب Win32 + Android + Browser UI التي تتمتع بتجربة وشعور موحد. HTML هو مجرد نقطة ألم كبيرة لأنه يضيف تجريدًا وتعقيدًا لا داعي لهما لا داعي لوجودهما لأن قاعدة الكود الأساسية لدينا في C #.

أتمنى أن يكون ذلك أفضل ردود الفعل بالنسبة لك.

نعم ، WASM هو الهدف الأكبر الذي نرغب فيه مقارنة بأي منصة أخرى. حتى الآن!!
لأنه يحل مشكلة Android / iOS / mobile بالإضافة إلى عناصر بوابة الويب.

شكرا لك على الاستماع إلى ردود الفعل!

سيكون سطح المكتب + WASM ذهبيًا!

واو ، شكرًا على الصراخ ياjesbis! غير متوقع على الإطلاق ، وهو موضع تقدير واحترام كبير جدًا. 👍

المناقشة حول Windows 7 مشتتة قليلاً ، حيث أن مقدار الجهد (ناهيك عن التكلفة) سيؤدي إلى تأخير كبير في WinUI 3.0. انتهى عمر Windows 7 في يناير ، ونحن نشجع جميع العملاء على الترقية إلى Windows 10. قد لا يتوافق عملائي مع الآخرين هنا ، ولكن حتى Windows 8.1 ليس نظامًا أساسيًا يهمنا.

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

شكرا للفريق على الشفافية.

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

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

نحن نعلم أن لدينا INotifyDataErrorInfo للتسليم التالي. ولكن سيكون من الرائع لو كان لدى WinUI مورد RAD لعمليات التسليم المستقبلية مثل 3.x فصاعدًا.

فريق الشكر ، لا يمكن أن تنتظر اليوم الذي تقوم فيه بالقلم الرصاص في webassembly. ستجعل يومي وسنتي وعقدي وسيضع MS في قمة مجموعة التكنولوجيا. WinUI + Xamarin + WASM + .NET => روعة خالصة !!

jesbis شكرا لهذا التحديث. فريق العمل الجيد: +1 :. فهم أنه لا يزال مبكرًا ، متى تعتقد أننا سنشهد إنشاء

متى تعتقد أننا سنرى WinUI 3.0 معلمًا تم إنشاؤه والمشكلات التي تم وضع علامة عليها ضدها؟

shaggygi سؤال جيد! لقد أنشأته للتو:

WinUI 3.0 علامة فارقة

هذا رائع يا رفاق!

سؤال سريع: نقل Windows.UI.Composition إلى Microsoft.UI.Composition ، هل هذا أقرب إلى 2.2 أو 3.0؟
وفي الإطار الزمني لتوقع هذا ، هل هذا لي 2-3 أشهر أو أكثر ، عندما يصبح 3.0 متاحًا؟

في المستقبل ، عندما تتحدث عن السنوات (كما في "بنهاية العام") ، يرجى أن تكون واضحًا بشأن السنوات التقويمية والسنوات المالية لـ [Microsoft].
من السهل الشعور بالارتباك عندما لا يتم ذكر ذلك صراحةً ، وقد عرفت مناسبات أدى فيها ذلك إلى اعتقاد الناس بأن الأشياء قادمة قبل 6 أشهر مما كان مقصودًا.

نقل Windows.UI.Composition إلى Microsoft.UI.Composition ، هل هذا أقرب إلى 2.2 أو 3.0؟

jtorjo سيكون هذا 3.0 (كحد أدنى). نأمل في تضمين إصدار مبكر في المعاينة الأولى لـ 3.0 ، ولكن ليس مضمونًا بنسبة 100٪ حتى الآن.

في المستقبل ، عندما تتحدث عن السنوات (كما في "بنهاية العام") ، يرجى أن تكون واضحًا بشأن السنوات التقويمية والسنوات المالية لـ [Microsoft].

mrlacey شكرًا ،

jesbis هذا نوع من الحزن. إذن أنت تقول أنه من الممكن ألا يكون لدينا تكوين Microsoft.UI. في 3.0؟

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

نأمل في تضمين إصدار مبكر في المعاينة الأولى لـ 3.0 ، ولكن ليس مضمونًا بنسبة 100٪ حتى الآن

غالبًا ما يكون هناك العديد من إصدارات المعاينة. NET Core 3 في Preview 6 ، على سبيل المثال.

خطتنا هي تضمين تكوين واجهات برمجة التطبيقات في 3.0.

سيكون جزء إطار عمل Xaml مفتوح المصدر قبل جزء التكوين بالرغم من ذلك.

jesbis شكرا ، يبدو جيدا!

خارطة طريق رائعة ، عمل رائع!

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

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

سيكون دعم WASM في المستقبل مذهلاً.

أمس في مؤتمر:

قصة قصيرة لإظهار jesbis والفريق أننا نكتب

بالأمس فقط تجاذبت أطراف الحديث في مؤتمر للمطورين في ألمانيا مع بعض مطوري .NET وأخبرتهم عن WinUI 3.0 ، ولم يعرفوا عن ذلك. أخبرتهم عن خريطة الطريق وقالوا:

"واو ، هذا مذهل".

سألتني فتاة من المجموعة:

"لكن هل يسمح لك أن تخبرنا بكل هذا؟"

نظرت إليها وإلى الآخرين ، ثم انتهزت الفرصة لأخذ وقفة رجعية

await Task.Delay(3000);

قبل أن أقول

"نعم الجحيم! يمكنك قراءة هذا كله على GitHub".

شكرا jesbis والجميع المعنيين. أوقات رائعة لتكون مطور Windows ❤️

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

أكريليك لـ WPF و Win32 و WinUI Desktop.

أوه وربما إعادة النظر في الاكريليك فقط على سياسة النوافذ النشطة.

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

كنت أفكر في الآثار المترتبة على تجربة التطوير لوجود مجموعتين من عناصر التحكم في واجهة المستخدم المتاحة في تطبيقات UWP - عندما يكون لدينا إمكانية الوصول إلى كل من عناصر تحكم WinUI وعناصر تحكم واجهة المستخدم القديمة ، عندما يكون في C # code-behind ، IntelliSense لأنه سيتطلب منا دائمًا بشكل صحيح اختر مساحة الاسم التي يجب أن يأتي عنصر التحكم منها بدلاً من الانتقال إلى Alt + Enter لإضافة using والمتابعة. هل سيكون من الممكن تجنب هذا بطريقة أو بأخرى؟

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

أكريليك لـ WPF و Win32 و WinUI Desktop.

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

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

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

يجب أن يكون أحد الحلول هو أنه يمكنك استبعاد مراجع WinMD Windows.UI.Xaml.* الإنشاء. الآن تشير أهداف البناء إلى WinMD الموحد المعروف أيضًا باسم. Windows.winmd ، أضف خيارًا في الأهداف لإحالة WinMDs الفردية ، وبهذه الطريقة ، يمكننا تضمين أو استبعاد المراجع بناءً على التطبيق الذي نقوم ببنائه.

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

أعلم أن هذه الطريقة مخصصة خصيصًا لـ .NET Framework ، ولكن بالنسبة لـ UAP ، يجب أن يكون هناك حل لهذا النوع من السيناريوهات. أعلم أن هناك FrameworkDependency في ملف msix/appx . ربما يمكننا استخدام ذلك لتزويد WinUI الجديد بمساحات أسماء Windows.* بدلاً من Microsoft.* منها.

من ناحية التطوير ، سيكون لدينا قدر أقل من الألم لترقية تطبيقاتنا ، نظرًا لأننا نغير المرجع فقط وليس الكود !

أفضل عدم تغيير مساحة الاسم على الإطلاق!

فوائد:

1. لا يتعين عليك تغيير الرمز ذهابًا وإيابًا.

2. بمجرد استقرار رمز WinUI المحلي ، يمكنك الاندماج مرة أخرى في نظام Windows الأساسي ، بحيث يمكن لتطبيقات النظام وتطبيقات LOB الاستفادة من التحسينات الجديدة ، في كل إصدار جديد من Windows.

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

شاهدت للتو عرضًا تقديميًا رائعًا بواسطة Steve Sanderson على واجهة مستخدم Blazor + (بدون html) ملفوفة في تطبيق محلي عبر النظام الأساسي. حوالي 52 دقيقة في الفيديو. يجب عرض لمحبي UWP و WinUI و c #. لقد تأثرت بشدة مع السترة !!!

https://youtu.be/uW-Kk7Qpv5U

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

قد تكون بعض عناصر التحكم في الأداء واستخدام ذاكرة الوصول العشوائي أفضل بكثير ، مثل ListView / GridView = ItemsControl.

ترى هذا على Windows نفسه. تعد قائمة ابدأ في Windows 8 (DirectUI) أكثر مرونة من قائمة ابدأ في Windows 10 XAML.
حاول تحميل GridView بمعلومات كافية ، مثل صفحة ألبومات Groove ، والأشياء لا تسير على ما يرام. هذا شيء يتصرف به iOS و Android بشكل أفضل ، وكذلك يفعل Winforms ، QT.
(WPF أسوأ من UWP XAML في رأيي).

هل يحتوي WinUI 3.0 نفسه على أي تحسينات في الأداء؟ إنه محرك عرض XAML يتم فصله للتو أو هل هناك تغييرات؟ هل ستستخدم عناصر تحكم XAML التكوين بشكل أساسي ، وبالتالي ، خارج الخيط و dwm مدفوعة مثل DirectUI؟

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

WinUI 3.0 (مثل UWP Xaml اليوم) مبني على طبقة التكوين ويدير الكثير من العرض والرسوم المتحركة خارج الخيط عبر DWM.

هذا شيء يتصرف به iOS و Android بشكل أفضل ، وكذلك يفعل Winforms ، QT.
(WPF أسوأ من UWP XAML في رأيي).

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

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

آمل أن تتمكن Microsoft من توفير ملف comctl32.dll و comdlg32.dll الجديد الذي يستند إلى WinUI 3.0.

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

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

أيضًا ، آمل أن تتمكن Microsoft من توفير مصمم XAML لتطبيقات C ++ Win32 التي تستخدم WinUI.

كينجي موري

MouriNaruto يمكنك استخدام FileOpenPicker اليوم (من Win32).

MouriNaruto يمكنك استخدام FileOpenPicker اليوم (من Win32).

أعلم ، لكنني آمل أن تجلب جميع عناصر التحكم والحوارات الشائعة الحديثة إلى Win32.

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

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

التوافق هو العدو لدينا!

حتى لو فعلوا ذلك ، بحلول الوقت الذي يكملون فيه ذلك ، سيكون لكل برنامج يستخدم هذه libs وقتًا كافيًا للانتقال إلى WinUI! السخرية!! 🤨🤣

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

لمعلوماتك : FileOpenPicker ليس مربع حوار / تحكم WinRT أصلي. إنه في الأساس غلاف مكون من ExplorerFrame وهو نفسه مكتوب DirectUI (تم تطويره بواسطة فريق ATG وعلى أساس DirectX ) و COM !

من الناحية الفنية ، هذا ممكن. ولكن يتعين على مطوري Windows إعادة إنشاء ليس فقط السلوكيات الدقيقة لتطبيقات COMCTL و COMDLG ولكن أيضًا الأخطاء المعروفة وغير المعروفة الموجودة في قاعدة التعليمات البرمجية.
التوافق هو العدو لدينا!
حتى لو فعلوا ذلك ، بحلول الوقت الذي يكملون فيه ذلك ، سيكون لكل برنامج يستخدم هذه libs وقتًا كافيًا للانتقال إلى WinUI! السخرية!! 🤨🤣

لا أعتقد أنه من السهل على العديد من المشاريع الانتقال إلى WinUI بدون ذلك بسبب الواقع.

لقد قلت "التوافق هو العدو لنا!". نعم ، هذا أيضًا أحد أسباب اقتراحاتي. السخرية!! 🤨🤣

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

يبدو هدف WinUI 3 مثيرًا للغاية وأنا أتطلع إليه. لدي بعض الأسئلة المتعلقة بالتوزيع / النشر ، في سياق تطبيق Win32 كلاسيكي باستخدام WinUI 3

1. هل يحتاج كل تطبيق إلى إحضار مكتبة WinUI معه أم أنه يمكن المشاركة بين التطبيقات ، وربما تلقائيًا من خلال آليات Windows
2. هل سيكون من الممكن ربط WinUI بشكل ثابت؟
3. لنفترض أنه يتعين علي إعادة توزيعه ، فما حجم WinUI تقريبًا بالميجابايت؟

هل يحتاج كل تطبيق إلى إحضار مكتبة WinUI معه أم أنه يمكن المشاركة بين التطبيقات ، وربما تلقائيًا من خلال آليات Windows

نحن نخطط لتوزيع WinUI 3 بشكل أساسي من خلال NuGet ، والتي لديها آليات لتخزين الحزم ومشاركتها تلقائيًا - هناك المزيد من المعلومات المتاحة هنا:

https://docs.microsoft.com/nuget/what-is-nuget#what -else-do-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

هل سيكون من الممكن ربط WinUI بشكل ثابت؟

هذا ليس شيئًا كنا نخطط له حاليًا - هل لديك سيناريو في الاعتبار حيث سيكون هذا مفيدًا؟

لنفترض أنه يتعين علي إعادة توزيعه ، فما حجم WinUI تقريبًا بالميجابايت؟

ما زلنا نعمل على الشكل الذي سيبدو عليه رسم التبعية النهائي ، ولكن بالنسبة لأجزاء واجهة المستخدم ، فمن المحتمل أن يكون مشابهًا لأحجام system32 dll الحالية ذات الصلة (10 ميجابايت).

نحن نخطط لتوزيع WinUI 3 بشكل أساسي من خلال NuGet ، التي لديها آليات لتخزين الحزم ومشاركتها تلقائيًا

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

لا يجب عليك تثبيت أي أدوات تطوير أو SDK لمجرد مشاركة حزم إطار عمل واجهة المستخدم. واجه كل من WPF و WinForms for .NET Core نفس المشكلة واستثمروا في بناء حزمة مشتركة حتى لا يضطر الأشخاص

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

بالنسبة للتطبيقات التي يتم تسليمها بواسطة Microsoft Store ، يجب مشاركة محتويات حزمة الإصدار تلقائيًا عند النشر أيضًا.

بالنسبة لتطبيقات win32 التي تم نشرها من خلال وسائل أخرى ، فهي مدرجة في قائمة المهام الخاصة بنا للتحقيق في خيارات مثل ما ذكرته 😊

هل سيكون من الممكن ربط WinUI بشكل ثابت؟

هذا ليس شيئًا كنا نخطط له حاليًا - هل لديك سيناريو في الاعتبار حيث سيكون هذا مفيدًا؟

أعتقد أنني بحاجة إلى توضيح: هل سيكون من الممكن استخدام WinUI في EXE مرتبط بشكل ثابت (والذي يربط بشكل ثابت VC-Runtime)؟ أفترض أن هذا لا ينبغي أن يكون مشكلة بسبب C ++ / WinRT لكني أردت فقط أن أتأكد ...

لنفترض أنه يتعين علي إعادة توزيعه ، فما حجم WinUI تقريبًا بالميجابايت؟

ما زلنا نعمل على الشكل الذي سيبدو عليه رسم التبعية النهائي ، ولكن بالنسبة لأجزاء واجهة المستخدم ، فمن المحتمل أن يكون مشابهًا لأحجام system32 dll الحالية ذات الصلة (10 ميجابايت).

شكرا على المعلومه.

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

أعتقد أنني بحاجة إلى توضيح: هل سيكون من الممكن استخدام WinUI في EXE مرتبط بشكل ثابت (والذي يربط بشكل ثابت VC-Runtime)؟ أفترض أن هذا لا ينبغي أن يكون مشكلة بسبب C ++ / WinRT لكني أردت فقط التأكد

يجب أن يكون هذا ممكنًا (من الناحية النظرية) ولكن كما قال jesbis ، ما زلنا نعمل على المجمعة إلى إطار العمل المشترك. قد نضطر إلى الحصول على مثبت redist ، مثل الطريقة التي يقوم بها .NET Core بذلك.

المناقشة حول Windows 7 مشتتة قليلاً ، حيث أن مقدار الجهد (ناهيك عن التكلفة) سيؤدي إلى تأخير كبير في WinUI 3.0. انتهى عمر Windows 7 في يناير ، ونحن نشجع جميع العملاء على الترقية إلى Windows 10. قد لا يتوافق عملائي مع الآخرين هنا ، ولكن حتى Windows 8.1 ليس نظامًا أساسيًا يهمنا.

انت على حق. لكن لا يمكننا التحكم في زبوني وهناك أكثر من 60٪ نظام win7 في الصين. ولا يمكننا التخلي عن هذا السوق ، لذلك لا يمكننا استخدام أي تقنية لا تدعم win7.

البيانات من بايدو ، انظر https://tongji.baidu.com/data/os

لكن لا يمكننا التحكم في زبوني وهناك أكثر من 60٪ نظام win7 في الصين

TBH سألتزم فقط بـ .NET Framework 4.8 + WPF إذا كنت عالقًا في Win7.

لكن لا يمكننا التحكم في زبوني وهناك أكثر من 60٪ نظام win7 في الصين

TBH سألتزم فقط بـ .NET Framework 4.8 + WPF إذا كنت عالقًا في Win7.

لكن Win7 Sp1 يمكنه تثبيت .NET Framework 4.8 ولا يمكن لنظام Win7 بدون sp1 تثبيته.

متطلبات النظام لـ .NET Framework |

إذا لم يكن لديك حتى SP1 ، فأنت بالفعل تجاوزت 6 سنوات من نهاية العمر.

انتهى دعم Windows 7 RTM بدون حزم الخدمة في 9 أبريل 2013.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

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

MarkIngramUK ليس الأمر أن Microsoft حلت هذه المشكلة بالنسبة لي ، لكن لا يمكنني دعم

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

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

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

lindexi أعتقد أنه إذا كان العميل لا يريد استخدام التكنولوجيا المدعومة ويفضل شيئًا

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

lindexi هذا حرفيا عكس ما يحدث. لا يمكنك تسمية التكنولوجيا الجديدة "بالتكنولوجيا القديمة" لمجرد أنها لم يتم تحويلها إلى نظام تشغيل قديم. إذا كنت تريد دعم Win7 (بدون SP1) ، فاستخدم WinForms أو MFC أو شيء من هذا القبيل.

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

jesbis أود أن أتسخ يدي باستخدام WinUI الجديد باستخدام C ++. لقد بذلت قصارى جهدي باستخدام UWP و C ++ / Cx في الماضي ، ولكن بالإضافة إلى تطبيق PhotoEditor وبعض العينات ، انتهى بك الأمر دائمًا إلى حك رأسك ومحاولة العثور على بعض الوثائق الجيدة ، على سبيل المثال لربط XAML مع Platform :: مجموعات وأشياء مثل الذي - التي. كان هذا أحد الأسباب التي جعلتني أعود إلى C # لتطوير UWP و Qt لتطوير C ++ على Windows. من فضلك ، أظهر المزيد من الحب لـ C ++.

بالنسبة لعملائي ، استخدمت USB Stick (PenDrive) مع Windows 10 Media ، وقمت ببساطة بترقيته من Windows 7 إلى أحدث إصدار من Windows 10 مجانًا. لقد استفادوا من نظام التشغيل الحديث ، مع مكافحة الفيروسات وتحديثات Windows و Edge WebBrowser ويدعم تقنيات واجهة المستخدم الرسومية من أقدم مثل WinForms و WPF إلى أحدث التقنيات بما في ذلك UWP وما بعده (WinUI). أيضًا ، بدلاً من إيقاف التشغيل ، قمت بتعيين Windows على Hibernate ، وعلمت المستخدمين ببساطة الضغط على زر الطاقة لبدء العمل مع الكمبيوتر ، والضغط على زر الطاقة عند الانتهاء من استخدام الكمبيوتر.
كما أنني أضع ISO على الشبكة لتثبيت / ترقية الأجهزة بسهولة.

ولديهم ميزة تثبيت Candy Crush مسبقًا على أجهزة الكمبيوتر أيضًا!

رأي

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

الردود

تضمين التغريدة
أعلم أن هناك الكثير من مستخدمي إصدار Windows الذين عفا عليهم الزمن في الصين اليوم. لكني أعتقد أنه من الضروري التخلي عن مستخدمي Windows NT 5.x اليوم وأنا أعلم أنه صعب.

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

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

كل من واجهة المستخدم الحديثة ودعم النظام الأساسي القديم ضروريان في الصين إذا كنت لا تريد أن يتم تقديم عملك للأقلية. لذلك أحد أصدقائي ، وهو مطور صيني ، ومنفذ Blink و V8 إلى Windows XP دون تثبيت أي تحديثات ، يستخدمه الكثير من المطورين لتنفيذ تجارب تطبيقاتهم الحديثة. في الصين ، يكون الحد الأدنى لمتطلبات إصدار نظام التشغيل مساويًا لإصدار بدون تثبيت أي تحديثات . على سبيل المثال ، إذا كنت تعرف أن متطلبات إصدار نظام التشغيل لأحد التطبيقات من الصين هي Windows 7 ، فإنها تخبرك أنه يمكنك استخدام التطبيق ضمن "Windows 7 RTM" أو "6.1.7600.16385 (win7_rtm.090713-1255)". حتى في عالم Android ، لا تزال العديد من التطبيقات تدعم Android 4.4 اليوم.

هذا هو السبب في أن معظم التطبيقات التي صممها مطورون غير صينيون لا يمكن أن تكون خيار الأغلبية في الصين.

PS يمكننا استخدام أحدث إصدار من Visual Studio 2019 لإنشاء تطبيقات لنظام التشغيل Windows XP RTM دون تثبيت أي تحديثات ، مع أحدث إصدار من Windows 10 SDK وأحدث معيار C ++ 17 أو تجربة C ++ 20 الآن. بسبب VC-LTL (https://github.com/Chuyu-Team/VC-LTL) و YY-Thunks (https://github.com/Chuyu-Team/YY-Thunks).

لاحظ عن نفسي

في معظم وقتي ، أستخدم أحدث إصدار مستقر من Windows. (أنا أستخدم 10.0.18362 اليوم. أنا أستخدم 19H1 و 19H2.) لكن مشاريع Win32 الخاصة بي مصممة لنظام التشغيل Windows Vista RTM دون تثبيت أي تحديثات ، ومشاريع UWP المصممة لنظام التشغيل Windows 10 ، الإصدار 1703 دون تثبيت أي تحديثات أو أحدث بسبب الشرط تم تقديم دعم XAML في RS2. (أنا أحب XAML الشرطي. لماذا لا يوجد في Windows 10 Build 14393؟)

كينجي موري

من فضلك ، من فضلك ، ضع في اعتبارك إلغاء إغلاق كافة فئات التحكم الخاصة بـ WinUI 3.0!

حسب فهمي ، قررت Microsoft إغلاق جميع فئات التحكم في UWP ، لأن JavaScript (الذي لا يعرف الميراث) تسبب في حدوث مشكلات عند استخدامه مع الفئات الموروثة. الآن بعد أن تم إهمال JS / HTML ، لم تعد هناك حاجة لإطار عمل واجهة المستخدم الجديد لإغلاق جميع الفئات. سيجعل إلغاء selaing تخصيص عناصر تحكم UWP أسهل كثيرًا ، كما كان دائمًا ممكنًا في WPF. قد يساعد أيضًا كثيرًا عند كتابة عناصر تحكم أو لوحات قائمة افتراضية مخصصة ، للحصول على فئة أساسية افتراضية غير مختومة ترث منها. لا توجد مشكلات في الوراثة في C # أو C ++ / CX أو C ++ / WinRT. كان فقط الفشل المسمى JS / HTML هو الذي فرض هذا علينا.

لذا يرجى إزالة هذا التقييد غير الضروري عند إنشاء WinUI 3.0.

gisfromscratch شكرا على ردود الفعل! نريد بالتأكيد دعم تطوير C ++ (على وجه التحديد مع C ++ / WinRT).

ما الذي يجعل استخدام C ++ أسهل؟ هل جربت C ++ / WinRT بدلاً من CX؟

هل سيساعد المزيد من نماذج التطبيقات؟

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

من فضلك ، من فضلك ، ضع في اعتبارك إلغاء إغلاق كافة فئات التحكم الخاصة بـ WinUI 3.0!

lukasf هذا شيء من المحتمل أن نفعله 🙂 هناك بعض المناقشات ذات الصلة جارية في # 780

jesbis عليّ أن تطبيق نموذج Photo Editor C ++ / WinRT . ولكن عندما تقرأ من خلال الروابط المتوفرة مثل ربط البيانات بعمق ، ينتهي بك الأمر في الكثير من مقتطفات C # وبعض الملاحظات الجانبية فقط مثل "بالنسبة لـ C ++ / WinRT ، فإن أي فئة وقت تشغيل تعلنها في تطبيقك مشتقة من فئة أساسية هي تُعرف بالفئة القابلة للتكوين. وهناك قيود حول الفئات القابلة للتكوين ... ". تستهدف هذه الصفحة 95٪ C # و 5٪ فقط C ++.

تضمين التغريدة سنضع ذلك في الاعتبار أثناء عملنا على تحديث المستندات لـ WinUI 3.

إذا كان ذلك مفيدًا ، فإن صفحة تقنين البيانات التي ذكرتها ترتبط أيضًا ببعض الصفحات المنفصلة حول ربط البيانات على وجه التحديد باستخدام C ++ / WinRT ، على سبيل المثال:

ضوابط XAML.

عناصر تحكم XAML ؛

هناك عدد من الموضوعات الأخرى الخاصة بـ C ++ / WinRT في هذا القسم أيضًا.

شكرا لعملك الرائع! سعيد جدًا برؤية جزيرة Xaml تمت إزالتها من WinUi 3.0.
راجع للشغل: أنا فقط أتساءل عما إذا كان التنفيذ منخفض المستوى لإسقاط اللغة في WinUi 3.0 سيكون مختلفًا عن مكون WinRT. يبدو أن تنفيذ الإسقاط اللغوي لمكون WinRT قد حقق أداءً هائلاً في مشروع .NET UWP في وقت الترجمة ووقت التشغيل. نظرًا لأن WinUi 3.0 منفصل تمامًا عن UWP ، آمل أن يكون هناك بعض التحسن في تنفيذ التشغيل المتداخل للغة.

لم تتم إزالة zenjia XAML Islands من WinUI 3. سيحتوي WinUI 3 على واجهات برمجة التطبيقات التي تسمح لتطبيقات WPF / WinForms / MFC باستضافة عناصر تحكم WinUI 3.

لقد كنت أحاول متابعة التقدم في WinUI. لقد حاولت كتابة تطبيقات UWP في الماضي باستخدام C # ولكن وجدت أنها كانت معركة شاقة. لكنني حريص على المحاولة مرة أخرى بعد Winui 3.0.

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

• هل ستكون أغلفة .net لعناصر التحكم الأصلية مفتوحة المصدر أيضًا؟ ليس من الواضح أن هذا هو github repro المسؤول عن الجانب الصافي من winui ، مع الأخذ في الاعتبار أن كود c # الوحيد الذي يبدو أنني أجده هو الاختبارات الآلية. أنا أبحث عن أشياء مثل Microsoft.UI.Xaml.UIElement ولكن لا يمكنني العثور على هذا الرمز في أي مكان.

• عندما نصل إلى إصدار winui 3.0 ، هل سيعمل نموذج تطبيق UWP ونموذج تطبيق win32 على نفس وقت تشغيل Net Core؟ لم أفهم مطلقًا ما هو إصدار .Net core الذي تستخدمه تطبيقات UWP. أتخيل أنه شيء مضمن في النوافذ نفسها ، وأن Windows 10 SDK تسمح لـ VS 2019 باستهداف الإصدار الصحيح من .Net core المتوفر في UWP.

• سؤال عن جزر Xaml. هل هناك أي احتمال أن يتشارك كل من WPF و UWP في نفس المجال الجوي؟ لا أتطلع إلى التعامل مع مشكلات المجال الجوي كما فعلنا بين winforms و WPF. نظرًا لأن كل من WPF و UWP مبنيان على Direct-X ، فسيكون من الرائع إذا كان بإمكانهما مشاركة وحدات البكسل مع بعضهما البعض. على سبيل المثال ، إذا كان لديّ قائمة خلف الكواليس على شريط (في WPF) ستحتاج إلى تراكب جزيرة UWP xaml ، فسيكون من الرائع أن يحدث ذلك بسلاسة. لا يبدو أنني يجب أن أقفز عبر أطنان من الحلقات لشيء من هذا القبيل. ... أتذكر أنه في الأيام الأولى من WPF ، حاولوا حل مشكلات المجال الجوي لتطبيقات العميل التي أرادت استخدام عنصر تحكم Winforms "WebBrowser". لقد قاموا بتجربة ميزة في متصفح الويب تسمى "WebBrowser.CompositionMode" وكان من المفترض أن يسمح لـ WebBrowser باللعب بلطف مع WPF. ... لكن أعتقد أنه تم التخلي عن هذه الاستراتيجية في نهاية المطاف. ربما يمكن أن تكون قابلية التشغيل البيني بين UWP و WPF سلسة للغاية لدرجة أنهما يمكنهما مشاركة وحدات البكسل مع بعضها البعض (على عكس winforms و WPF). تتمثل إحدى الميزات المحتملة لذلك في السماح لـ WPF بتحسين وظائف عنصر تحكم UWP. على سبيل المثال ، يمكن لـ WPF تراكب جزيرة xaml مع مرئيات إضافية بطريقة مماثلة لطبقة الزينة. هذا يمكن أن يصبح في متناول اليد في السؤال.

• هل هناك احتمال أن يتم تجميع تطبيق WPF مع جزر xaml (على سبيل المثال 50٪ WPF و 50٪ WINUI) محليًا إلى ARM64 يومًا ما؟ استهداف ARM ممكن مع التطبيقات التي هي 100٪ UWP ، وسيكون من الجيد ألا تجبرنا تبعيات WPF على التخلي عن استهداف ARM64 الأصلي. (سيكون البديل هو تشغيل التطبيق في محاكاة x86 - لكن هذا أبطأ ويحد من الذاكرة المتاحة التي يمكن استخدامها).

نأمل أن تكون هذه الأسئلة كلها ذات صلة بخريطة طريق winui. سيكون موضع تقدير أي نصيحة.

هل ستكون أغلفة .net لعناصر التحكم الأصلية مفتوحة المصدر أيضًا؟ ليس من الواضح أن هذا هو github repro المسؤول عن الجانب الصافي من winui ، مع الأخذ في الاعتبار أن كود c # الوحيد الذي يبدو أنني أجده هو الاختبارات الآلية. أنا أبحث عن أشياء مثل Microsoft.UI.Xaml.UIElement ولكن لا يمكنني العثور على هذا الرمز في أي مكان.

UIElement غير موجود في WinUI 2 ، لذا فهو غير موجود حاليًا في الريبو. سيكون في WinUI 3 الذي لم يتم إصداره أو فتح مصدره بعد ، لكننا نعمل على ذلك!

يمكنك أن ترى أمثلة في الريبو لعناصر التحكم الأصلية الأخرى المعرضة لـ .NET عبر إسقاطات WinRT ، على سبيل المثال عناصر تحكم WinUI 2.2 الموثقة هنا . لا تتطلب في الغالب ملفات غلاف موجودة مسبقًا لكل لغة وهذا هو سبب عدم العثور على ملفات .cs في الريبو.

@ marb2000 يمكنه التعليق بشكل أفضل على أسئلة الجزر / سطح المكتب.

س: هل سيستخدم نظام WinUI 3 UWP وسطح المكتب نفس وقت تشغيل .NET؟ _
ج: نعم هذه هي الخطة. سيستخدم UWP و Desktop .NET Core 3. ستستخدم مكتبات WinRT المُدارة .NET Core 3 بدلاً من .NET Native.

س: هل ستشترك WPF و UWP في نفس المجال الجوي؟ _
ج: على الرغم من أن WPF و WinUI (و XAML UWP) تبدو متشابهة ، إلا أنها ليست كذلك. يستخدم WPF DirectX9 ، ويستخدم WinUI / XAML UWP Windows.UI.Composition لاحتياجات تكوين XAML وعرضه والرسوم المتحركة (إلى جانب الإصدار الحديث من DirectX11). للأسف ، يتسبب هذا في أن التشغيل المتداخل معقد للغاية. اقتراحك حول مزينات WPF مثير للاهتمام. من الناحية النظرية ، يمكن للمتبني إنشاء نافذة منبثقة لوضع محتوى WinUI / XAML فوق محتوى WPF. أو يمكنه إبلاغ الشجرة المرئية لـ WPF أن إعادة التخطيط مطلوبة ، ولكن كل شيء يعتمد على HWnds.
dbeavon هذا اقتراح جيد ، هل يمكنك إنشاء طلب ميزة لهذا؟

س: _هل سيتم ترجمة تطبيق WPF مع Xaml Islands إلى ARM64؟ _
ج: إذا كان .NET Core 3 لنظام التشغيل Windows يدعم ARM64 بالتأكيد. اليوم يدعم ARM32 في Windows. ومع ذلك ، في Linux يدعم ARM64. أعتقد أنه موجود في خارطة طريق .NET Core لدعم ARM64 في Windows أيضًا. على الرغم من AFAIN ، لا يوجد تاريخ حتى الآن. richlander ، أي أخبار؟

@ marb2000

س: هل ستشترك WPF و UWP في نفس المجال الجوي؟

هل يمكن لـ UWP استخدام Windows.UI.Composition لإنشاء طبقة يمكنها الحصول على العرض من صورة نقطية لـ DirectX؟ ثم يقوم WPF بعرض النوافذ على هذه الطبقة مثل win2d. ربما يمكن أن تشترك في نفس المجال الجوي. لكن من الصعب جعل WPF يتم عرضه على طبقة.

@ lindexi أعتقد أنه يمكن أن يكون الجنة: د

هل يمكن لـ UWP استخدام Windows.UI.Composition لإنشاء طبقة يمكنها الحصول على العرض من صورة نقطية لـ DirectX؟

لدى UWP Xaml عدد من الطرق لعرض الصور النقطية لـ DirectX أو سلاسل المبادلة في Xaml وتركيبها مع Windows.UI.Composition بحيث يتشاركون في نفس المجال الجوي ، بما في ذلك SurfaceImageSource و VirtualSurfaceImageSource و SwapChainPanel - يتوفر مزيد من المعلومات هنا:

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

يمكنك أيضًا إدراج Windows.UI.Composition المرئي في شجرة UWP Xaml UI ورسم محتوى DirectX إليها ، على سبيل المثال باستخدام ICompositorInterop و ICompositionDrawingSurfaceInterop و ICompositionGraphicsDeviceInterop كما هو موضح هنا:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

يجب أن تعمل هذه الأساليب بشكل مشابه مع WinUI.

سيتمكن تطبيق سطح مكتب UWP من الرجوع إلى WPF / WinForm DLL وفتح نافذة WPF / WinFrom؟ هذا من شأنه أن يسمح لي بالهجرة تدريجياً.

@ marb2000 - NET Core for Windows ARM64 في خارطة الطريق الخاصة بنا. أنا أعمل على خطة لذلك الآن.

باستخدام WinUI 3.0 ، هل سيكون من الممكن تجميع win2d فوقه؟
(وبالتالي ، فصله عن UWP)
إذا كان الأمر كذلك ، فسيكون ذلك رائعًا بجنون!

ما زلنا نعمل على وضع تفاصيل حول تكامل DirectX ولكن نأمل أن يكون من الممكن تحديث Win2D لاستخدام فئات WinUI الأساسية بدلاً من فئات UWP Xaml الأساسية.

تشابك الأصابع: د

آسف إذا كان هذا خارج الموضوع: تقارير الأخطاء على UWP - هل أقوم بإضافة مشكلة على https://github.com/microsoft/microsoft-ui-xaml/ أو في أي مكان آخر؟

آسف إذا كان هذا خارج الموضوع: تقارير الأخطاء على UWP - هل أقوم بإضافة مشكلة على https://github.com/microsoft/microsoft-ui-xaml/ أو في أي مكان آخر؟

jtorjo سؤال عظيم! هذا الريبو هو أفضل مكان لتقديم أي مشاكل تتعلق بما يلي:

• واجهات برمجة تطبيقات إطار عمل UWP (مثل Windows.UI.Xaml)
• تصميم متقن
• WinUI

بشكل عام ، يجب أن يكون هناك ارتباط "إرسال ملاحظات حول هذا المنتج" أسفل معظم صفحات الوثائق على docs.microsoft.com والذي

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

هل سيتضمن WinUI 3 عنصر تحكم UWP SemanticZoom؟ أعتقد أنه أروع تحكم عليهم جميعًا.

jesbis شكرا! نشرت للتو مناقشة حول System.IO

حتى Microsoft لا تسقط دعم Windows 7 لـ Office ، فلماذا يفعل WinUI 3؟ أعني أن جميع البرامج الجادة تقريبًا لديها دعم Windows 7 (Photoshop ، Office ، Visual Studio 2019 ، VSCode ، ...) إذا كان WinUI لا يدعم Windows 7 ...

حتى Microsoft لا تسقط دعم Windows 7 لـ Office ، فلماذا يفعل WinUI 3؟ أعني أن جميع البرامج الجادة تقريبًا لديها دعم Windows 7 (Photoshop ، Office ، Visual Studio 2019 ، VSCode ، ...) إذا كان WinUI لا يدعم Windows 7 ...

من المحتمل أن يسقط Office الدعم قريبًا ، حيث سينتهي دعم Microsoft لنظام التشغيل Windows 7 قريبًا جدًا. لكنها مبنية على أساس رمز يدعم بالفعل Windows 7.

تم بناء WinUI على نظام التشغيل Windows 10 ، ولذا يجب إعادة توجيهه إلى Windows 7. الجهد المبذول للقيام بذلك لا معنى له مع دخول نظام التشغيل إلى End Of Life ، وبالتالي سيتعين على الأشخاص الترقية إلى Windows 10.

س: هل سيستخدم نظام WinUI 3 UWP وسطح المكتب نفس وقت تشغيل .NET؟
ج: نعم هذه هي الخطة. سيستخدم UWP و Desktop .NET Core 3. ستستخدم مكتبات WinRT المُدارة .NET Core 3 بدلاً من .NET Native.
س: هل ستشترك WPF و UWP في نفس المجال الجوي؟
ج: على الرغم من أن WPF و WinUI (و XAML UWP) تبدو متشابهة ، إلا أنها ليست كذلك. يستخدم WPF DirectX9 ، ويستخدم WinUI / XAML UWP Windows.UI.Composition لاحتياجات تكوين XAML وعرضه والرسوم المتحركة (إلى جانب الإصدار الحديث من DirectX11). للأسف ، يتسبب هذا في أن التشغيل المتداخل معقد للغاية. اقتراحك حول مزينات WPF مثير للاهتمام. من الناحية النظرية ، يمكن للمتبني إنشاء نافذة منبثقة لوضع محتوى WinUI / XAML فوق محتوى WPF. أو يمكنه إبلاغ الشجرة المرئية لـ WPF أن إعادة التخطيط مطلوبة ، ولكن كل شيء يعتمد على HWnds.
dbeavon هذا اقتراح جيد ، هل يمكنك إنشاء طلب ميزة لهذا؟
س: هل سيتم ترجمة تطبيق WPF مع Xaml Islands إلى ARM64؟
ج: إذا كان .NET Core 3 لنظام التشغيل Windows يدعم ARM64 بالتأكيد. اليوم يدعم ARM32 في Windows. ومع ذلك ، في Linux يدعم ARM64. أعتقد أنه موجود في خارطة طريق .NET Core لدعم ARM64 في Windows أيضًا. على الرغم من AFAIN ، لا يوجد تاريخ حتى الآن. richlander ، أي أخبار؟

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

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

سيكون التخلص من صندوق حماية UWP رائعًا بجنون!

هذا بالتأكيد لا يعني أن UWP ستختفي. يعد Universal Windows Platform هو الطريقة الوحيدة للبناء أصليًا لمجموعة كاملة من أجهزة Windows (الكمبيوتر الشخصي ، Xbox ، HoloLens ، إلخ) وهو المكان الذي يركز فيه Windows على استثماراته في النظام الأساسي الأصلي. RE: وضع الحماية على وجه الخصوص: يستمر عزل appcontainer في توفير الكثير من الفوائد المهمة للتطبيقات ومستخدمي كل من تطبيقات UWP وتطبيقات سطح المكتب.

التغييرات الرئيسية هي:

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

هذا يعني أنه بالنسبة للتطبيقات الجديدة ، ستتمكن من الاختيار بين نماذج تطبيقات سطح المكتب و UWP اعتمادًا على ما هو منطقي لتطبيقك ، وإذا كانت لديك تطبيقات سطح مكتب حالية (مثل WPF و WinForms و MFC) ، فيمكنك تحديثها بشكل متزايد باستخدام أحدث وظائف WinUI باستخدام جزر Xaml.

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

سيكون UWP أحد الخيارات لإنشاء تطبيق WinUI 3.0. سيسمح استخدام UWP بتشغيل تطبيقك على Xbox و Hololens وما إلى ذلك.

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

mdtaukjesbis أنا مؤيد تمامًا لـ UWP ، لكن في هذا الوقت:

1. أوقات التجميع بطيئة بجنون! (إلى حد كبير ، أبطأ 6 مرات من WPF - أنا أستخدم الإصدار المستهدف الإصدار 1809 - الإصدار 17783)
2. أعرف أن واجهة برمجة تطبيقات تعداد ملفات StorageFolder ليست جزءًا من UWP ، لكن هذا بطيء للغاية. إن وضع الحماية لـ UWP (على الأقل على سطح مكتب Windows) يضر أكثر من كونه يساعد.
3. من المؤكد أن البرمجة غير المتزامنة ممتعة ، ولكن في UWP ، عندما يحدث استثناء ، يتم تناولها بطريقة ما بواسطة رمز UWP ، ثم تنكسر لاحقًا في مصحح الأخطاء ، مع فقد كل سياق المكدس. في بعض الأحيان ، لدي سياق المكدس داخل الاستثناء الذي تم إلقاؤه نفسه ، ولكن ليس دائمًا.
4. إن تشكيل رمز UWP قريب من المستحيل. ينقطع حدث dotTrace فورًا عند محاولة القيام بذلك.

(لقد استغرق الأمر أكثر من شهر لنقل الكود الخاص بي من WPF إلى UWP ، لأنني بحاجة ماسة إلى win2d ، لذلك لا توجد طريقة بالنسبة لي لتجنب UWP.)

mdtaukjesbis أنا مؤيد تمامًا لـ UWP ، لكن في هذا الوقت:

1. أوقات التجميع بطيئة بجنون! (إلى حد كبير ، أبطأ 6 مرات من WPF - أنا أستخدم الإصدار المستهدف الإصدار 1809 - الإصدار 17783)
2. أعرف أن واجهة برمجة تطبيقات تعداد ملفات StorageFolder ليست جزءًا من UWP ، لكن هذا بطيء للغاية. إن وضع الحماية لـ UWP (على الأقل على سطح مكتب Windows) يضر أكثر من كونه يساعد.
3. من المؤكد أن البرمجة غير المتزامنة ممتعة ، ولكن في UWP ، عندما يحدث استثناء ، يتم تناولها بطريقة ما بواسطة رمز UWP ، ثم تنكسر لاحقًا في مصحح الأخطاء ، مع فقد كل سياق المكدس. في بعض الأحيان ، لدي سياق المكدس داخل الاستثناء الذي تم إلقاؤه نفسه ، ولكن ليس دائمًا.
4. إن تشكيل رمز UWP قريب من المستحيل. ينقطع حدث dotTrace فورًا عند محاولة القيام بذلك.

(لقد استغرق الأمر أكثر من شهر لنقل الكود الخاص بي من WPF إلى UWP ، لأنني بحاجة ماسة إلى win2d ، لذلك لا توجد طريقة بالنسبة لي لتجنب UWP.)

سيكون من المفيد أن يتم نشر هذا في سلسلة الرسائل هذه # 1517 ونأمل أن تتمكن من تضمين اسم شخص ما من فريق SDK

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

أوقات التجميع بطيئة بجنون! (إلى حد كبير ، أبطأ 6 مرات من WPF

هل تستخدم C ++ / WinRT؟ إذا كان الأمر كذلك ، فهل تستخدم الرؤوس المجمعة مسبقًا؟

mdtauk نشر هناك للتو

MarkIngramUK إنه كود c #

الخاتمة - يرجى توجيه خارطة الطريق وردود الفعل الأولية إلى: # 1531

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

هل هذا شيء على خريطة الطريق حقًا أم كان مجرد افتراض؟

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

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

andreinitescu آسف للتشدق والشكاوى ولكن فقط أفكاري من ما أفهمه: بينما سأستخدم WinUI 3 لاستبدال أشياء WPF لنظامي التشغيل Windows / Win32 فقط ... لأن WinUI على Windows يستخدم Windows فقط واجهة برمجة التطبيقات وليس الحياد أولاً ، يبدو أن WinUI يعتمد على الأطراف الثالثة لإعادة تنفيذ / تجزئة WinUI على منصات أخرى (مثل UNO proj ، وهو أمر رائع ولكنه مثل Mono to .NET هو تجزئة غير ضرورية ومضيعة للوقت إذا كانت الأشياء فقط تم تصميمه بشكل صحيح في البداية). بدلاً من استخدام جهاز محمول مثل Skia ، أو إنشاء MS واحد. لا تفهم أيضًا الحاجة إلى دعم 1٪ من الأشخاص الذين لن يستخدموا C # مع WinUI ، مما يجعل C # هدفًا من الدرجة الثانية بمعنى ما ، والأهم من ذلك جعل وقت التطوير يستغرق وقتًا أطول. تمامًا مثل Android يستخدم Java + post-AOT للعديد من التطبيقات الأساسية ، لذلك يجب أن يستخدم Windows C # + pre-AOT. لأنه يوفر الوقت. 70٪ من الأخطاء التي تستخدم C ++ تستخدم ptrs التي تم إلغاء تخصيصها بعد كل شيء.

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

للأسف ، لا تستطيع MS / لن تفعل ما فعلته Apple منذ ما يقرب من 20 عامًا بالانتقال من OS9 إلى OSX. في ذلك ، تقوم بنزع المساعدة الشريطية عن طريق الانتقال إلى نواة UNIX / LINUX ولكن مع وجود محاكي / محاكي مدمج في نظام التشغيل للبرامج القديمة لمدة 5-10 سنوات قادمة بينما يقوم الأشخاص بترحيل البرامج وأدوات التطوير للتشغيل محليًا. (فكر فيما تشاء من هذا ولكن يمكنني أن أحلم)