هذه هي أفكاري الأولية حول الأسئلة التي طرحتها في محتوى العدد.

لقد جئت من منظور التصميم والمستخدم ، مع القليل من الخبرة في التطوير ، الذين أصبحوا مهتمين جدًا بتطوير Silverlight / Windows Phone 7 مرة أخرى في اليوم الذي يشعر الآن بالإرهاق قليلاً.

ما هي القوالب التي قد تهمك أكثر؟

أعتقد قبل طلب قائمة بأفكار القوالب ، أن يكون هناك نوع من التدقيق يتم إجراؤه لأكبر التطبيقات وأكثرها استخدامًا في كل إطار ، مثل WPF و UWP و WinForms و MFC وما إلى ذلك.

افحص "الصورة الظلية" لهذه التطبيقات واكتشف سيناريوهات UX الشائعة.

من فوق رأسي هناك:

• القائمة الرئيسية (جميع الأطر)
• MDI (مستندات متعددة في نافذة واحدة) (MFC في الغالب)
• علامات التبويب و Datagrid (WPF و WinForms و MFC)
• الشريط (Win32 apps Office و 3ds max والطلاء ولوحة الدفتر ومستكشف الملفات وما إلى ذلك)
• أدوات علبة النظام (MFC ، WinForms)
• المتصفحات
• المعالجات (WPF ، MFC)
• تطبيقات MDI المعقدة (برنامج Adobe ، Visual Studio)
• مشغلات الوسائط
• حلقة تصور البيانات (WPF والويب)
• التطبيقات الاجتماعية (React Native، PWA - Skype، Facebook، Twitter)

كل أو بعض هذه يمكن أن تستفيد من تكامل نظام WinRT / UWP مع Notifications / Action Center.

يجب أن تتجنب جميع قوالب المشروع الجديدة هذه مساحات أسماء Windows.Xaml المضمنة ، وموضوع التحكم WPF ، وأنماط WinForms المرئية لصالح القوالب والأنماط المرئية الجديدة التي تتطابق مع تصميمات التحكم FabricWeb / Fluent.

يجب أن تكون هناك أيضًا طريقة سهلة للمطورين الذين يستخدمون تطبيقات WPF و WinForms الحالية لإضافة تبعية WinUI 3.0 والتي تمنحهم تصميمات التحكم الجديدة باستخدام عبارة بسيطة أو إدخال بيان

جزر XAML

نظرًا لأن Xaml Islands أصبح من الأسهل تحقيقها - استبدال عناصر التحكم القديمة في عرض الويب ، منتقي الألوان ، يمكن أن تكون الحوارات المستندة إلى XAML سهلة مثل إضافة جديد ... واختيار مربع حوار ، أو عنصر تحكم قياسي يمكن أن يتصل به كود C # و C ++ الحالي ، و لديهم خلف الكود الخاص بهم.

التطبيقات الحديثة وقوالب الصفحة مثل تطبيقات Xbox Next و NavigationView و Master / Details و Hubs و Modern Ribbon و NavigationViewTop و Pivot - يمكن توفيرها جميعًا لجميع أنظمة العرض التقديمي لـ Windows - مع وجود جزر XAML في مكانها وعينة من المحتوى.

يجب أن يكون أي من هذه السيناريوهات غير الممكنة حاليًا في UWP XAML مزودًا بعناصر تحكم وقوالب لتسهيل ذلك.

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

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

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

ما هو الحل المفضل لديك لاستخدام مكونات UWP مع WinUI 3؟

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

ما نوع التطبيقات التي ستكون متحمسًا أكثر لاستخدام WinUI 3.0 من أجلها؟

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

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

أريد أن تكون جميع التطبيقات قابلة للتثبيت من داخل المتجر ، أو من مثبت نوع Centennial. اجعل مجلدات النظام و Windows افتراضية لكل تطبيق.

تحديث تطبيق C ++ MFC باستخدام Fluent UI؟

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

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

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

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

ها هي إجاباتي:

إنشاء تطبيق جديد

ما هي القوالب التي قد تهمك أكثر؟

• أرغب في رؤية c ++ / winRT win32 + xaml و .net core + xaml أولاً هناك ، وتأتي قوالب UWP في المرتبة الثانية ، ولا ينبغي أن يأتي تطبيق win32 المعبأ كقالب ، حيث يجب أن تعمل قوالب حزمة التطبيق الحالية تمامًا كما تفعل بالفعل مع الحالي تطبيقات win32 / .Net.
• بالإضافة إلى ذلك ، أود أن أرى قوالب عناصر مثل "New XAML Window" مع رمز لوحة مرجل لإظهاره في تطبيق win32 أو .net core موجود (على سبيل المثال: جعل تطبيق systray الحالي على Docker Desktop قادرًا على إظهار نافذة Xaml الجديدة ذات المستوى الأعلى)

إضافة WinUI 3.0 إلى تطبيقات Win32 الموجودة

• التوافق غير المتخلف هو السبب الدقيق لعدم استخدامي جزر xaml في مشروع حقيقي (استخدمته للتسلية على الأشياء الشخصية رغم ذلك). يعد فصل إطار عمل واجهة المستخدم عن واجهة برمجة تطبيقات Windows أحد أعظم الأشياء التي تم الإعلان عنها باستخدام خارطة طريق WinUI 3.0 (جنبًا إلى جنب مع قدرة التطبيقات المستهدفة غير المعبأة / غير التابعة لـ UWP على الاستفادة منها)

تحديث تطبيق UWP Xaml الحالي إلى WinUI 3.0

قد يبدو الأمر قاسيًا ، لكنني أشعر أن تطبيق UWP xaml هو مكان مناسب (منذ سقوط هاتف windows ، لم يعد هناك مزيد من الجذب نحو UWP كمنصة مستهدفة) ، وحتى إذا كان من الجيد استخدام الأدوات / interop ، لا أعتقد أنه يجب أن يكون التركيز الرئيسي لـ WinUI 3.0.
لذا فإن كل من أدوات تحديث مساحة الاسم (التي يمكن إجراؤها في الواقع باستخدام بحث واستبدال عالمي) وخلط UWP xaml و WinUI xaml لا تشعر بالحرج بالنسبة لي.

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

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

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

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

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

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

إجابات على الأسئلة

إنشاء تطبيق جديد

ما هي القوالب التي قد تهمك أكثر؟

أحب أن أرى .net core / xaml / C # هنا ، لأنني أعتقد أن هذا هو أكثر مجموعات اللغات استخدامًا. ولكن ربما يكون قالب الترحيل أفضل هنا (حاول إشراك الجميع في أسرع وقت ممكن ، فكلما طال الوقت ، زاد الألم).

إضافة WinUI 3.0 إلى تطبيقات Win32 الموجودة

أعتقد أن هذا لطيف للغاية ، وسنستخدمه كثيرًا (ولكن من الناحية الواقعية ، هذا على الأقل عام على الأقل لأن عملاء المؤسسات لا يزالون يستخدمون Windows 7 ، حتى عندما ينتهي دعم MS ، ستكون الشركات تعمل على Windows 7). ثم يمكننا ترحيل WPF ببطء إلى WinUI 3.

هل كنت على علم بجزر Xaml لتحديث تطبيقات سطح المكتب؟

نعم ، ولكن هناك عدد كبير جدًا من العملاء (أو كانوا) يستخدمون Windows 7 ، لذلك لم يكن خيارًا لمطوري المؤسسات. وبالنسبة للمستهلكين ، يمكنك فقط استخدام UWP على أي حال.

هل هذا التوافق مع الإصدارات السابقة على نظام التشغيل Windows 10 يجعل Xaml Islands أكثر إفادة لك؟

إنها بداية جيدة لأنه في الوقت الذي يتم فيه شحن هذه الأشياء ، ستعمل على جميع الإصدارات المدعومة من Windows 10 في المؤسسة.

تحديث تطبيق UWP Xaml الحالي إلى WinUI 3.0

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

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

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

إذا كانت مجرد مساحات أسماء ، فيجب أن يؤدي البحث / الاستبدال إلى الحيلة أيضًا.

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

لم يعد مهمًا ، فأنا على استعداد لخسارة آلاف الساعات من التطوير ، ولم يتبق أي مستخدم على أي حال.

هل تنشئ أو تستخدم مكتبات تحكم UWP Xaml أو مكونات WinRT التي لا يمكنك بسهولة إعادة تجميعها وتحديثها جنبًا إلى جنب مع كود التطبيق؟

لا.

ما هو الحل المفضل لديك لاستخدام مكونات UWP مع WinUI 3؟

جزر UWP (نوع من المكونات المستضافة)

عام

ما رأيك في خطة 3.0 الشاملة الموضحة أعلاه وفي خارطة الطريق؟ هل سيمكنك من استخدام WinUI لتطبيقات Windows الجديدة والحالية؟

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

ما نوع التطبيقات التي ستكون متحمسًا أكثر لاستخدام WinUI 3.0 من أجلها؟ هل تنشئ تطبيق Win32 جديدًا وتعبئته باستخدام MSIX؟ هل تريد إضافة طرق عرض جديدة إلى تطبيق WPF؟ تحديث تطبيق C ++ MFC باستخدام Fluent UI؟

ربما مجرد إضافة طرق عرض جديدة إلى تطبيق WPF والبدء في الترحيل ببطء.

أنا أحب خارطة الطريق هذه كثيرًا. يجب تحرير UWP من أغلالها ، وهذه طريقة رائعة للقيام بذلك.

تحديث تطبيق UWP Xaml الحالي إلى WinUI 3.0

هذا مهم جدًا لصاحب العمل. لدينا تطبيق سطح مكتب UWP معقد في المتجر. نحتاج الآن إلى Desktop Bridge للوصول إلى واجهات برمجة تطبيقات win32 التي لا تدعمها .NET Native.

أود

• الوصول المباشر إلى جميع Win32 API ؛
• باستخدام نموذج تنفيذ Win32 قديم عادي. أنا بخير مع بعض وضع الحماية الذي يشبه جسر سطح المكتب (مثل التمثيل الافتراضي للسجل) ؛
• لوضع تطبيقنا في المتجر (msix) كما هو الآن ؛
• الاستمرار في استخدام WNS (دفع الإخطارات) ؛
• تجربة تحديث غير مؤلمة من UWP إلى نوع تطبيق Xaml Desktop الجديد. لا مانع من القيام ببعض الأعمال اليدوية. ربما أفضل التوثيق الجيد على الأدوات هنا.

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

يجب أن تعمل الأنماط الحالية. يمكنني العيش مع بعض التغييرات المرئية الطفيفة. ولكن ليس مع التغييرات في السلوك.

هل تنشئ أو تستخدم مكتبات تحكم UWP Xaml أو مكونات WinRT التي لا يمكنك بسهولة إعادة تجميعها وتحديثها جنبًا إلى جنب مع كود التطبيق؟

لا.

ما هو الحل المفضل لديك لاستخدام مكونات UWP مع WinUI 3؟

إذا كان لا يمكن إعادة تجميعها (طرف ثالث): نهج يشبه جزر Xaml. وإلا فمن الممكن نقلها بسهولة إلى WinUI 3.

عام

ما نوع التطبيقات التي ستكون متحمسًا أكثر لاستخدام WinUI 3.0 من أجلها؟ هل تنشئ تطبيق Win32 جديدًا وتعبئته باستخدام MSIX؟ هل تريد إضافة طرق عرض جديدة إلى تطبيق WPF؟ تحديث تطبيق C ++ MFC باستخدام Fluent UI؟

• تطبيقات win32 لسطح المكتب ، معبأة مع MSIX.
• تطبيقات أونو عبر النظام الأساسي ؛)

يُرجى عدم إدخال مساحات أسماء جديدة لأشياء مثل _INotifyDataErrorInfo_ - يجب استخدامها في نماذج العرض التي عادةً ما تكون مشتركة بين الأنظمة الأساسية ويجب ألا تعتمد على WinUI. يجب تحديد مكان وجود أشياء أخرى مثل هذه (على سبيل المثال _INotifyPropertyChanged_ أو _INotifyCollectionChanged) _

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

هل سيكون من الأفضل تسمية XamlUI أو ما شابه ذلك؟ تعد مساحات أسماء Microsoft.UI. * جيدة ، ما عليك سوى وضع علامة تجارية على الريبو مثل

شكرا على رسالتك. تطلع إلى ما سيأتي في هذه المساحة: ابتسم:

بالنسبة لي ، كل التفاصيل الفنية أقل أهمية.
UWP أو WPF أو أي إطار عمل يعمل بنظام Windows فقط ، بقدر ما هو رائع ، لن يكون كافيًا لفترة طويلة لأنه لا يعمل على كل نظام أساسي (على الأقل Windows و Droid و iOS والويب) ، وهو سهل الاستخدام أي حجم الشاشة.

أصيبت TBH بخيبة أمل في آخر إصدار لاكتشاف أن MS ليس لديها خطط لإنشاء UWP أو XAML عبر الأنظمة الأساسية. لم يحصل أونو على أي اعتراف رسمي بخلاف الخطاب. الأمر الأكثر إحباطًا ، وأنا أقول إنه مؤلم ، هو اكتشاف أن MS تمنح الكثير من الحب لـ React Native و HTML / JS إطارات العمل مرة أخرى (WinJS) ، مع إهمال مطوري .NET المكدس المسؤول.
أرغب في رؤية MS تنشئ رسميًا مكدس واجهة مستخدم عبر الأنظمة الأساسية مثل Uno ، وتوفر الأدوات والقوالب والدعم المتكامل المناسب.

راجع للشغل ، لقد عملت مع XF منذ استحواذ MS عليها ، وأتمنى أن يكون لديها بديل ، للأسباب التالية: أ. لا يوجد دعم ويب ، ب. متحيزة للغاية للتنقل ، لا حب لأجهزة الكمبيوتر المكتبية ج. يبدو التسلسل الهرمي للمكتبة الخاص به غير واضح ، بالتأكيد عند مقارنته بمكتبة التحكم WPF / UWP د. لا تستخدم MS XAML.
إليك طلب الميزة الذي نشرته على مجتمع مطوري Microsoft: .NET UI Standard .

شكرا لكم جميعا!

نحتاج إلى واجهة مستخدم XAML تعمل أيضًا على الويب (التجميع). مجموعة فرعية على الأقل من UWP.
لماذا لا تتبنى منصة UNO وتجعل عرض الويب باستخدام SkiaSharp؟
يمكن أن يكون Silverlight 6 ، نظير الويب لـ WinUI

ردود سريعة على الأسئلة

ما هي القوالب التي قد تهمك أكثر؟

NET core SDK-style ، أو بعض تنسيق مشروع MSVC المبسط.
ملفات المشروع القديمة معقدة للغاية بحيث لا يمكن تعديلها يدويًا ، وهناك الكثير من مشكلات التفاعل بين نظام المشروع القديم والجديد. يجب أن نتخلى تمامًا عن نظام المشروع القديم للمشاريع الجديدة تمامًا.

هل كنت على علم بجزر Xaml لتحديث تطبيقات سطح المكتب؟

لا ، فأنا أعيد كتابة طلبي بتغيير نموذج البيانات بالكامل ، لذلك لا يوجد ترحيل تدريجي.

هل هذا التوافق مع الإصدارات السابقة على نظام التشغيل Windows 10 يجعل Xaml Islands أكثر إفادة لك؟

لا يزال هناك العديد من المستخدمين على Windows 7 و Xaml Islands لا يمكنهم المساعدة.

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

لا. جميع مكوناتي مكتوبة ذاتيًا ، أو من MUX و WCTK ، لذا يمكنني إجراء ترحيل يدوي سريع.

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

ليس كثيرًا ، لأن مشروعي ليس كبيرًا (حوالي 20 صفحة و ~ 10 عناصر تحكم مخصصة في الوقت الحالي).

ما هو الحل المفضل لديك لاستخدام مكونات UWP مع WinUI 3؟

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

ما نوع التطبيقات التي ستكون متحمسًا أكثر لاستخدام WinUI 3.0 من أجلها؟ هل تنشئ تطبيق Win32 جديدًا وتعبئته باستخدام MSIX؟ هل تريد إضافة طرق عرض جديدة إلى تطبيق WPF؟ تحديث تطبيق C ++ MFC باستخدام Fluent UI؟

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

مظهري الشخصي لمنصة واجهة المستخدم

سلسلة أدوات Xaml

لغة xaml ليست جادة إلى حد ما ، وأواجه العديد من المشكلات مثل "كيف يمكنني تمثيل هذا". WPF xaml و UWP xaml غير متوافقين تمامًا ، لذلك أحتاج إلى تذكر الاختلافات بينهما. Xaml غير متوافق تمامًا مع ميزات .NET ، لذلك أحتاج أحيانًا إلى كتابة بعض الحيل القبيحة في نموذجي ، وفئة مساعدة.

عند الوصول إلى x:Bind ، تصبح الأمور أسوأ. السيناريوهات البسيطة سهلة الاستخدام ، ولكن القيام بأشياء أكثر من مجرد الوصول إلى الممتلكات أمر معقد للغاية. على سبيل المثال ، لا يدعم أسلوب التحميل الزائد ، لذلك يجب أن أقوم بالتجميع للتحقق من التحميل الزائد الذي تم اختياره لهذا التعبير الملزم. لا يمكنني حتى إجراء تحويل بسيط ، أو تحويل "مرئي عندما تكون بعض الخصائص خاطئة" ، وهناك حاجة إلى طريقة مساعدة. لا تذكر الوثائق شيئًا عن هذه السيناريوهات التفصيلية ، لذلك أعتقد أنه يجب أن يكون هناك مكان لمناقشة تصميم لغة xaml ، وجعل xaml لغة مصممة بجدية مثل C #.

من الصعب استخدام محرر xaml أيضًا. من المنطقي أن يحاول المصمم تنفيذ بعض التعليمات البرمجية لإظهار التأثيرات الفعلية ، ولكن يجب أن يكون محرر النصوص على دراية بالبيانات الوصفية فقط. يعد فتح ملف xaml في طريقة العرض المصدر بطيئًا لأنه ينشط المصمم ، ويطرح بعض استثناءات التفاعل لـ xaml جيد التشغيل تمامًا ، مثل NullReferenceException و Cannot convert __ComObject to some type . يلامس ProjectReference خلال المكتبات المبنية ، وينتج عنه خطأ معقد حتى عند التعديل البسيط لمنطقة API غير العامة في مكتبة التبعية ، وعادةً ما يكون تنفيذ نموذج البيانات. لذلك أعتقد أنه يجب أن يكون هناك بيانات وصفية وشفرة مصدر على دراية ، ومترجم xaml متكامل لـ Roslyn بالكامل.

نموذج نافذة أفضل

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

يمكن أن تثبت إعادة كتابة Visual Studio في WinUI في وقت ما في المستقبل أنه نظام واجهة مستخدم ناضج.

واجهات ربط البيانات

لقد سئمنا جدًا من إنشاء نماذج تنفذ INotifyPropertyChanged . لقد قمت بكتابة مهمة MSBuild مخصصة لتحويل xml إلى موصّلات خاصية موسعة ، لكنها لا تساعد عندما أرغب في القيام بشيء مخصص في المُعيِّن عندما تتغير الخاصية.

وهناك قضايا الخيوط. تأتي بياناتي بالكامل من خادم شبكة في الخلفية ، لذا فإن التقاط السياق لـ await لا يمكن أن يساعدني. في WPF و Binding ، يكون الأمر كما هو لأن Binding يحل خيوط المعالجة نفسها. عند التغيير إلى x:Bind ، يجب أن أقوم بحلها داخل جامع الحدث ، لأن x:Bind يعمل فقط على سلسلة المحادثات. تزداد الأمور سوءًا عندما يكون لدي العديد من طرق عرض التطبيق التي تلامس نفس البيانات ، مما يعني أنه لا يتوفر مرسل UI عالمي ، والحل الوحيد هو الحصول على SynchronizationContext.Current عند تسجيل الحدث. بالنسبة للمجموعات ، لا يعتبر ItemsSource آمنًا لسلسلة الرسائل أيضًا ، ونفس الحل مطلوب.

يجب أن يكون هناك بالتأكيد سلسلة أدوات لحل مشكلات النمذجة والترابط والتوسيع للنماذج القابلة للتغيير والربط. ويجب أن يوفر الحل المدمج العام للمجموعة القابلة للربط آلية لـ "خاصية محددة لأي طفل تم تغييره".

IObservableVector<T> هو نوع عام مزيف يمكنه استخدام object فقط ، INotifyCollectionChanged ليس عامًا. فقط قم بتنفيذه للمجموعة المضمنة مثل ObservableCollection<T> لا يكفي ، خاصة بالنسبة للسيناريوهات المعقدة ، ISupportIncrementalLoading / IItemsRangeInfo المنحى. يجب أن يوفر النظام الأساسي تنفيذًا تجريديًا افتراضيًا مع أفضل الممارسات ، مما يسمح للمستخدم بتنفيذ طريقة مجردة لملء البيانات.

shaggygiweitzhandlerTonyHenrique

إذا كان هناك مستقبل عبر النظام الأساسي لـ UWP / XamlUI3.0 يستخلص بنية XAML ، من Windows Renderer ، وستكون بقية Windows Runtime طريقة للتعامل معها.

إذا كان من الممكن أن يكون هناك عقلية مكونة تقريبًا في المشروع ، فقد يكون هناك Android أو iOS / AppKit Renderer ، و Android / iOS AppKit Shim لتمرير واجهات برمجة تطبيقات ART إلى C # و VB ، بالإضافة إلى لغة C ++ و C الحالية الدعم.
يمكن أن يساعد Xamarin هنا.

لا تحتاج Microsoft إلى أن تكون هي التي تعمل على عارضات النظام الأساسي البديل.

لكن التركيز على Windows في الوقت الحالي ... يمكن أن يشمل WinUI 3.0 Fabric Web / React Native / WPF / WinForms / MFC. ستكون PWAs أيضًا مواطنًا من الدرجة الأولى لتطوير التطبيقات ، لذلك هناك قصص عبر الأنظمة الأساسية للتطبيقات غير المصممة لـ Windows / .NET / UWP مباشرة.

ما هو مطلوب الآن ، هو تقديم قصة لمطوري C # /. NET / UWP لجلب تطبيقاتهم واستثماراتهم إلى المشهد الأوسع للمنصات.

سنتان: أنا مطور Xamarin.Forms ، و (مثل العديد من اللغات الأخرى) مهتم برؤية جميع لهجات XAML يتم دمجها في لغة تعمل في كل مكان ، بما في ذلك مساحة الهاتف المحمول. لست متأكدًا من كيفية حدوث ذلك ، لكن هذه على الأقل أمنيتي في هذا الشأن.

ربما WinUI 3.0 وما بعده - ولكن هناك عددًا كبيرًا جدًا من تطبيقات WPF التي تتوقع منهم جميعًا إعادة كتابة وترجمة كل XAML. يمكن لمشاريع WPF الجديدة استخدام لهجة WinRT XAML الأكثر حداثة. يمكنك تقديم ما يعادل DocType إلى XAML بحيث يمكن أن تتعايش لهجات مختلفة في نفس المشروع.

القول أسهل من الفعل بالطبع.

mdtauk أعتقد أنه بمجرد أن تصبح منصة Xaml مفتوحة المصدر بالفعل ، سيكون لدينا فهم أوضح لما تعتمد عليه في الجزء السفلي من المكدس (نعلم بالفعل أن التبعيات الرئيسية الخاصة بالنظام الأساسي هي DirectX11 و Direct2D و Windows Media Foundation ، ولكن من يعرف أي جزء من Windows SDK يتم استخدامه هناك) ، وكيف يتم وضعه في طبقات (حتى يكون لدينا شعور حقيقي حول جدوى أي نقل).
كما أننا لم نر بعد أي نوع من الترخيص سيتم توزيع الكود المصدري. لست متأكدًا مما إذا كان قد تقرر ذلك بعد.

يستخدم Android Vulkan وأعتقد أنه يدعم OpenGL
يستخدم iOS و macOS Metal

أما بالنسبة لبرامج ترميز الوسائط ، فقد يكون من الممكن الاستفادة من واجهات برمجة التطبيقات الأصلية المستندة إلى C كبديل.

simonferquel سيصبح الأمر أكثر وضوحًا عند إعادة بناء الكود

أعتقد أن تغيير مساحة الاسم كان نهجًا معقولًا عندما كانت Winui عبارة عن مجموعة من الضوابط. ومع ذلك ، الآن بعد أن حل محل النظام الأساسي بشكل أساسي ، أعتقد أن هذا لم يعد مبررًا. يعمل هذا بالفعل بنفس الطريقة مع WPF / Winforms ، حيث يمكن نقل التعليمات البرمجية من .net Framework إلى .net core دون تغيير مساحات الأسماء في التعليمات البرمجية. يجب أن يكون النظام الأساسي قادرًا تلقائيًا على تحميل إصدارات winui لملفات dll الضرورية عند التمكين. بهذه الطريقة ، يمكن الحفاظ على توافق المصدر والثنائي (لقد استخدمت بنجاح مكتبات إطار عمل .net في تطبيقات .net الأساسية).

أردت فقط أن أقول شكرا للجميع على التعليقات حتى الآن! يبحث فريق WinUI بعناية في جميع الردود والنقاط.
من المحتمل أيضًا أن نفصل بعض المشكلات المركزة للتحدث عن نقاط محددة ظهرت (مثل التوافق مع أطر عمل ومكونات UWP الحالية) بمجرد تنظيم أفكارنا.

أريد فقط أن أقول شكراً لـ MS على الاستماع أكثر ومنح مطوري .net أدوات رائعة ، لكن لا يسعني إلا أن أشعر بخيبة أمل من مستقبل UWP Xaml بعد مؤتمر البناء.
عند قراءة هذه المدونة والعديد من المقالات على شبكة الإنترنت ، تشعر أن UWP أصبحت "مؤسسة" حصريًا ، وحتى هذا الأمر قابل للنقاش نظرًا لأن العديد من المؤسسات أصبحت أكثر حيادًا لنظام التشغيل مما يسمح للعاملين باستخدام MacBook Pro على سبيل المثال.

اسمحوا لي أن أكون واضحًا أنني استثمر بشكل كبير في نماذج UWP و Xamarin الأصلية (Android ، iOS) وأحب النظام الأساسي ، ولكن بعد إعلان MS عن الدعم المحلي لـ React ، أنا على وشك القفز.

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

سبب التفكير أعلاه هو أن UWP لا تزودني بفتحة هروب حيث يمكن أن تصبح بسهولة ضحية Silverlight التالية إذا لم تكن هناك إمكانية عبر الأنظمة الأساسية قريبًا. يقوم MS بالتحوط من رهاناتهم من خلال التأكد من عدم خسارتهم في اتجاه PWA أو أن أيديهم يتم تحويلها من أجل دعم React الأصلي على Windows. المشكلة هي أنني أخذت رهانًا على أمل أنه بحلول هذا الوقت سيكون هناك "مسار" لـ UWP / c # /. net في المتصفح أو عبر النظام الأساسي وأن أتمكن من إعادة استخدام معظم استثماري في تلك المنصات.

أتذكر عندما صرخ كل مطور هناك لشراء Xamarin ، استغرق الأمر MS إلى الأبد لفعل ذلك. أعتقد أن معظم المطورين الذين هم على دراية بتجميع الويب يعرفون أنهم تمكنوا مؤخرًا من تشغيل "إصدار كامل" من Windows Server في تجميع الويب سيقولون شراء منصة Uno وجعلها ضخمة باستثمارات كبيرة. إذا كان يمكن تشغيل نظام تشغيل كامل على تجميع الويب ، فيجب أن تعطي MS لكل مطور شبكة مسار ترحيل عبر قدرة النظام الأساسي لحماية استثماراتهم الحالية.

قد تقول إن Blazor موجود ولكن بصراحة قبل أن أستثمر المزيد من الوقت في منصة جديدة سأفضل أن أتعلم React أو قد تقول أن MS لدينا موارد محدودة لكل هذا. بالتأكيد عندما تدفع 7.5 مليار دولار مقابل Github ، يصبح كل شيء نسبيًا.

أعتقد أنه من الأهمية بمكان أن تفهم MS الضرر الذي يلحق بالسمعة نتيجة فشل مسار الترحيل عبر قدرة النظام الأساسي لاستثمارات UWP / Win32 الحالية. يجب أن تكون قدرة النظام الأساسي مترادفة مع .NET 5 وهي ليست كذلك. لست متأكدًا مما إذا كانت الخطوات الصغيرة لعبور النظام الأساسي في هذه الحالة ستعمل على MS وصدقني كنت دائمًا معجبًا كبيرًا بـ xaml / .net / c #

ما هي القوالب التي قد تهمك أكثر؟

هل تقصد قوالب المشروع أو قوالب العناصر أيضًا؟

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

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

إعادة: التوافق مع الإصدارات السابقة للميزات الجديدة

هل سيكون التوافق مع الإصدارات السابقة لـ Creators Update (15063) نقطة مرجعية ثابتة أم أن الخطة المستقبلية هي دعم الإصدار الحالي وعدد X من الإصدارات السابقة لذلك؟

ماذا يعني هذا بالنسبة لأي شخص يقوم بإنشاء ملحق أو عنصر تحكم خاص أو وظيفة يريد مشاركتها بشكل عام؟ هل سيحتاجون إلى دعم هذا المستوى من التوافق العكسي أيضًا؟ حتى Windows 8.1؟

رد: ترحيل مساحات الأسماء

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

ماذا عن ترحيل تطبيقات WPF؟ - هل استراتيجية الترحيل لاستخدام جزر XAML والتي يمكن أن تستخدم WinUI 2.x أو 3.x؟ هل يمكن استخدام كليهما في نفس التطبيق؟

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

يُرجى استبدال جميع مثيلات UWP بالأسماء المناسبة ، حيث إن ما تشير إليه ليس واضحًا.

mrlacey :

هل تقصد قوالب المشروع أو قوالب العناصر أيضًا؟

تعتبر قوالب العناصر أو المكتبة مثيرة للاهتمام أيضًا! هناك بعض النقاط الرائعة في الردود حتى الآن حول توفير رمز معياري إضافي وكود بداية وهو شيء آخر يمكننا التفكير في إضافته بمرور الوقت ، ربما مثل Windows Template Studio .

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

سؤال جيد - ما نوع تحديثات التبعية التي تجعلها أكثر قيمة؟ على سبيل المثال ، إيجاد إصدارات جديدة من حزمة NuGet متوافقة؟

هل سيكون التوافق مع الإصدارات السابقة لـ Creators Update (15063) نقطة مرجعية ثابتة أم أن الخطة المستقبلية هي دعم الإصدار الحالي وعدد X من الإصدارات السابقة لذلك؟

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

ماذا يعني هذا بالنسبة لأي شخص يقوم بإنشاء ملحق أو عنصر تحكم خاص أو وظيفة يريد مشاركتها بشكل عام؟ هل سيحتاجون إلى دعم هذا المستوى من التوافق العكسي أيضًا؟ حتى Windows 8.1؟

لا نتصور حاليًا فرض أي متطلبات إضافية أو "شهادة" لعناصر التحكم المخصصة. تعيين الإصدار سيكون متروكًا لك. قصة الإصدار الشاملة عبر تحديث مايو 2019 و WinUI 3.0 والإصدارات المستقبلية من WinUI هي بالتأكيد موضوع نريد التعمق فيه قريبًا.

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

سؤال رائع - شكرا لملاحظة ذلك. هذا أيضًا موضوع نريد التعمق فيه قريبًا.

يرجى استبدال جميع مثيلات UWP بالأسماء المناسبة ، لأنه ليس من الواضح ما تشير إليه.

riverar : هل هناك استخدام محدد أو قسم غير واضح؟

نستخدم مصطلح " UWP Xaml " للإشارة إلى منصة Xaml التي يتم شحنها كجزء من Windows 10 و UWP SDK ، من أجل تمييزها عن الأنظمة الأساسية الأخرى المستندة إلى Xaml (مثل WPF).

نشير أيضًا إلى " نموذج تطبيق UWP " (

حتى على أجهزة كمبيوتر سطح المكتب التي تعمل بنظام Windows ، يقضي المستخدمون الكثير من الوقت في تصفح الويب.
أعتقد أننا بحاجة إلى طريقة لتطوير تطبيقات ويب مناسبة ، باستخدام (مجموعة فرعية من) UWP vNext XAML + .NET (C # / F # / VB.NET)

لقد قمت بالتطوير في WPF + ClickOnce لعدة سنوات ، ثم بدأت في إلقاء نظرة على UWP. أنا أحب UWP ، ولكن (أو الإصدار التالي) يحتاج إلى أن يكون قادرًا على تشغيل EXE مستقل ، وواجهات برمجة تطبيقات Window أفضل (السماح بإنشاء تطبيق Winamp Window مخصص حتى إذا أردنا) ، والمزيد من واجهات برمجة التطبيقات للطباعة ، والتفاعل السهل مع C dll ، OCX ، يجب تشغيل مجموعة فرعية على الأقل من المكونات على الويب.

عندما رأيت UNO ، فكرت: يمكن لـ Microsoft شراء هذه الشركة ، والانضمام إلى هؤلاء المطورين مع فرق UWP و Xamarin. سأكون سعيدًا إذا أصبح الإصدار التالي من UWP شيئًا من Azure ، يتم تشغيله على الويب و Windows و Mobile و IoT. يمكن كتابة بوابة IMO حتى Azure في UWP vNext.

يمكن لمايكروسوفت أن تفعل ذلك. لقد قمت بذلك باستخدام Silverlight ، وقمت بعمل WPF ، وقمت بعمل UWP ، وقمت بعمل Xamarin. حان الوقت الآن لإطار عمل GUI XAML النهائي. وفي رأيي ، يجب دعم الويب ، على الأقل مجموعة فرعية من الوظائف.

_INotifyDataErrorInfo_

يُرجى عدم إدخال مساحات أسماء جديدة لأشياء مثل _INotifyDataErrorInfo_ - يجب استخدامها في نماذج العرض التي عادةً ما تكون مشتركة بين الأنظمة الأساسية ويجب ألا تعتمد على WinUI. يجب تحديد مكان وجود أشياء أخرى مثل هذه (على سبيل المثال _INotifyPropertyChanged_ أو _INotifyCollectionChanged) _

حول هذا الموضوع. يحتوي Windows.UI.Xaml.Interop بالفعل على واجهة INotifyCollectionChanged و Windows.UI.Xaml.Data يحتوي على INotifyPropertyChanged. سيتم نقل هذين إلى مساحات أسماء Microsoft. ربما تستطيع التجميعات System.Runtime.WindowsRuntime القيام ببعض التعيينات من WinUI إلى .Net

الشيء الوحيد الذي أريد إضافته إذا لم تتم إضافته بالفعل هو ، أنا 100٪ أؤيد نموذج حزمة MSIX / Appx وقد قام Win10 بعمل رائع لإصلاح الهراء الذي كان التثبيت والإزالة على مدار عمر النوافذ. ومع ذلك ، فقد كافحت دائمًا لإنشاء تطبيق "UWP" بسبب المجموعة الفرعية الغريبة لخيارات واجهة برمجة التطبيقات المتاحة التي تم إجراؤها في وضع حماية AppContainer. بصفتك مطورًا لـ C ++ ، كان ذلك محبطًا وكل عام كنت تفتح صندوق الحماية لأعلى للسماح لمجموعة Win32 API الكاملة كان أمرًا مريحًا.

لذلك إذا سمح لي WinUI 3.0 بإنشاء تطبيق مع إمكانية الوصول إلى 100٪ من حزمة Win32 ، فسيكون هذا ذهبيًا! لقد حاولت استخدام XamlIslands الآن ، وهي فتحة هروب رائعة ، لكنها كانت غير مستقرة بالنسبة لي ولم يتبق لها سوى بعض العمل قبل أن تعبر خط النهاية حقًا.

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

@ eklipse2k8 لا تزال هناك حاجة إلى نظام إذن للوصول إلى ملفات وأجهزة المستخدم ، حتى في وضع الحماية المريح. أعتقد أيضًا أنه يجب أن تكون هناك قواعد يجب الاحتفاظ بها في userland وتجنب الارتقاء إلى وصول المسؤول والوصول kernal - بدون نوع من الاختبار الرسمي ومتطلبات توقيع الكود.

مرحبا مايكروسوفت ،

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

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

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

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

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

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

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

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

لتوضيح مشكلة تجانس الخطوط هذه ، دعنا نلقي نظرة على الأداة الإضافية services.msc MMC في Windows 7 :

هل ترى أي نص ضبابي يبدو خارج نطاق التركيز؟ هنا. دعونا نكبر قليلا ...

يا إلهي ، يا إلهي ، أشعر وكأنني أنظر إلى نص متقاطع في مخطط أوتوستيريوغرافي .

اتضح ، في هذه الحالة المحددة ، من خلال البحث في التسلسل الهرمي للتحكم في هذه النافذة ، أن الأداة الإضافية MMC تستضيف عنصر تحكم Internet Explorer DHTML / ActiveX الذي يعرض نصًا غامضًا في لوحة "حدد عنصرًا لعرض وصفه". يتم تقديم القائمة الحادة (المفاجئة إلى البكسل) و "المساعدة" وقائمة الخدمات باستخدام بدائل USER32 و GDI32 العادية.

يسلط هذا المثال الصغير الضوء على إحدى أكبر المشكلات المتعلقة بعرض الخط في Windows. اتضح أن IE8 سيحترم إعداد نظام التشغيل العالمي الذي يعطل ClearType وتجانس الخطوط. ومع ذلك ، إذا قمت بتثبيت IE9 أو أعلى ، فسوف يتجاهل IE9 + لحسن الحظ كل الجهود لتعطيل تجانس الخطوط. IE9 + لا يهتم فقط ويفرض على جميع المستخدمين عرض النص على مواقع الويب (وعناصر تحكم ActiveX) بنص مصقول الخط.

تزداد المشكلة سوءًا بالنسبة للمستخدمين مثلي لأنه مع مرور الوقت ، اتبعت ولادة Windows 8 و Windows 10 و Metro Apps و WPF و UWP نفس نهج IE9 +. تتجاهل جميع تقنيات واجهة المستخدم هذه الموجودة أسفل الغطاء الإعدادات الشاملة لنظام التشغيل العالمي التي يجب احترامها على أجهزتنا. إذا قمنا بتعطيل ClearType وتنعيم الخطوط على مستوى نظام التشغيل بأكمله ، فإننا نتوقع أن لا يتم رسم ClearType و DirectWrite API (وبالتالي ، تطبيقات Metro و WPF و UWP) باستخدام أي تجانس للخط.

أعلم أنني لست الوحيد الذي يعاني من هذه المشكلة.

منذ فترة ، فعل Google Chrome نفس الشيء مع إصداره v31 وحاول اتباع نهج IE9 + وقام بتبديل كل عرض الخط إلى DirectWrite متجاهلًا الإعدادات العامة على مستوى النظام. أدى هذا التغيير إلى غضب الإنترنت. راجع إصدار Chromium 319429 . أخيرًا ، بعد الكثير من صرير الأسنان ، عكست Google مسارها وصححت المشكلة في Chrome 37 لأولئك المستخدمين الذين يعانون من ضعف البصر وقصر النظر ، والآن يحترمون الإعداد على مستوى نظام التشغيل الذي يعطل تجانس الخطوط.

بفضل القوى الموجودة وقوى السوق ، خسرت Microsoft حرب المتصفح وهي الآن تعتمد محرك عرض Chromium ، لكنني أتفهم أن فريق Edge سيحترم إعدادات تنعيم الخطوط المعطلة.

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

وكتذكير ودي ، فهذه مشكلة تتعلق بإمكانية الوصول لواجهة مستخدم Windows بشكل عام ، وليست

على أساس انتشار قصر النظر على مستوى العالم ، يمكن تقدير أن أكثر من 22 ٪ من سكان العالم الحاليين ، أي 1.5 مليار شخص يعانون من قصر النظر. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

شكرا،
بريان

: walking_man:: walking_woman: مفقود - يمشى

هذا يعني أنه سيتم تطوير إطار عمل Xaml الكامل على GitHub وشحنه خارج النطاق كحزم NuGet .

يعد NuGet أمرًا رائعًا ، ولكن دعم vcpkg (و CMake ) سيكون موضع تقدير أيضًا (لأولئك منا الذين لديهم مكتبات كبيرة قائمة عبر الأنظمة الأساسية).

ما القوالب التي قد تهمك أكثر؟

في ترتيب التفضيل:
Win32 + Xaml Desktop + WinUI
Win32 + جزر Xaml + WinUI
UWP + WinUI

هل كنت على علم بجزر Xaml لتحديث تطبيقات سطح المكتب؟هل هذا التوافق مع الإصدارات السابقة على نظام التشغيل Windows 10 يجعل Xaml Islands أكثر إفادة لك؟

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

ستكون مساحة اسم الجذر لـ Xaml والتكوين وواجهات برمجة تطبيقات الإدخال في WinUI مختلفة عن مساحة اسم جذر Windows UWP SDK:

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

هذا لا يؤثر علي ، لأنه ليس لدينا تطبيق UWP (نستخدم حاليًا WPF للمبيعات المباشرة و WPF + Desktop Bridge للمتجر) ، ولكن تغيير مساحات الأسماء أمر يحدث لمرة واحدة ، وحتى في أكبر قواعد الرموز ، إن عملية البحث والاستبدال الشاملة لـ Windows::UI::Xaml ليست بهذه الصعوبة (نحن جميعًا نستخدم التحكم في الإصدار بشكل صحيح ..؟).

أسرع مسار لإصدار WinUI 3.0 هو عدم دعم الخلط:

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

ومع ذلك ، فإن أحد أكبر مخاوفنا هو مشكلات التوافق والعمل الذي يمكن أن ينشأ لتطبيقات UWP ومكتبات المكونات الحالية ، خاصةً إذا كنت تقوم بتأليف أو استهلاك مكتبات تحكم UWP Xaml.
على سبيل المثال ، لن تكون الإصدارات الحالية من Windows Community Toolkit قابلة للاستخدام في تطبيقات WinUI 3.0 ، لذلك يجب تحديث كل من Toolkit وأي تطبيقات تستخدمه قبل استخدام WinUI 3.0.

تحتاج Microsoft إلى اختيار تقنية والالتزام بها. لقد وعدنا لسنوات بأحدث وأكبر أطر لواجهة مستخدم سطح المكتب (Win32 و ATL و WTL و MFC و WinForms و WPF و UWP Xaml والآن WinUI Xaml). في حين أن الاختيار رائع ، فإنه يؤدي إلى تجزئة الوظائف ومعرفة المطور. من الأسهل كثيرًا أن يكون لديك جلسة واحدة / صفحة ويب واحدة / إجابة واحدة للتكديس عند تنفيذ ميزة في Windows ، مقابل 7 ميزات مختلفة اعتمادًا على التقنية. إذا كان WinUI Xaml هو المستقبل ، فيجب تحديث مجموعة أدوات المجتمع للاستفادة منها.

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

لقد كنت أؤجل القيام بأي شيء باستخدام UWP Xaml لأن الوظيفة ليست موجودة (بالمقارنة مع Win32 / WPF) ، وأفترض أنني لست وحدي في هذا الصدد. على هذا النحو ، التوافق الكامل ليس مشكلة.

هل تنشئ أو تستخدم مكتبات تحكم UWP Xaml أو مكونات WinRT التي لا يمكنك بسهولة إعادة تجميعها وتحديثها جنبًا إلى جنب مع كود التطبيق؟

لا.

ما هو الحل المفضل لديك لاستخدام مكونات UWP Xaml مع WinUI 3؟

غير متاح

1. ما رأيك في خطة 3.0 الشاملة الموضحة أعلاه وفي خارطة الطريق ؟ هل سيمكنك من استخدام WinUI لتطبيقات Windows الجديدة والحالية؟

لا يوجد ذكر لـ Xaml Desktop في خارطة الطريق. هل يقع هذا ضمن اختصاص WinUI؟
لقد ذكرت هذا من قبل للأشخاص في // Build / ، ولكن سبب عدم اعتماد UWP Xaml من قبل هو أنه كان من المستحيل إنشاء تطبيق يستخدم مكتبات C ++ الحالية. على سبيل المثال ، عندما يختار المستخدم ملفًا باستخدام FileOpenPicker ، يتم تسليم النتيجة كملف IStorageFile ، ولا توجد طريقة لتمرير هذا إلى مكتبة موجودة تابعة لجهة خارجية لفتحها (على سبيل المثال ، libpng ، libjpeg ، إلخ). هذا هو السبب في أننا اضطررنا للالتزام بـ WPF ، لذلك إذا سمح لنا Xaml Desktop أو Win32 + Xaml Islands بالعيش بدون هذه القيود ، فعندئذ نعم ، سيمكننا ذلك من استخدام WinUI لتطبيق جديد.

1. ما نوع التطبيقات التي ستكون متحمسًا أكثر لاستخدام WinUI 3.0 من أجلها؟ هل تنشئ تطبيق Win32 جديدًا MSIX ؟ هل تريد إضافة طرق عرض جديدة إلى تطبيق WPF؟ تحديث تطبيق C ++ MFC باستخدام Fluent UI؟

إنشاء تطبيق Win32 جديد باستخدام WinUI (والتعبئة باستخدام MSIX).

إذا كان لديك أي أسئلة ، فيرجى إبلاغي بها ، ويسعدني إجراء المزيد من المناقشة.

آمل في الواقع أن تكون هناك طريقة لاستدعاء Compact Overlay من WPF / WinForms.
نحتاج فقط إلى نظام إذن المسؤول مثل "السحب على إذن التطبيقات الأخرى" في Android.

آمل أن يسمح نموذج التطبيق هذا + العبوة (UWP + AppX ، Win32 + MSIX) بذلك (التجريد الكامل داخل Sandbox)

ألا يفترض أن يكون Windows هو الأكثر تقدمًا وإمكانيات غير محدودة ، مع أفضل أمان؟
لا من خلال الميزة المعطلة للأمن.

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

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

إلى هذه النقطة ، لدينا عدد كبير من تطبيقات UWP المستخدمة لعملاء المؤسسات في الوقت الحالي ، وآمل ألا يكون مسار الترحيل بهذه الصعوبة. إذا كانت هناك تغييرات مفاجئة ، فسيكون من الجيد جدًا أن يكون لديك أداة ترحيل مشابهة لـ .Net Framework إلى .Net Core التي تولد مدى توافق مسار الترحيل الخاص بنا ، يجب أن يبلغ هذا عن أي شيء قد يحتاج إلى التغيير ( على سبيل المثال واجهات برمجة التطبيقات التي قد يتم إهمالها أو تتصرف بشكل مختلف) وخيار لتغيير مساحة الاسم تلقائيًا إن أمكن. بهذه الطريقة ، لن يكون مسار ترحيل UWP إلى WInUI متقلبًا مثل مطوري المؤسسات.

هل كنت على علم بجزر Xaml لتحديث تطبيقات سطح المكتب؟
هل هذا التوافق مع الإصدارات السابقة على نظام التشغيل Windows 10 يجعل Xaml Islands أكثر إفادة لك؟

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

ما رأيك في خطة 3.0 الشاملة الموضحة أعلاه وفي خارطة الطريق؟ هل سيمكنك من استخدام WinUI لتطبيقات Windows الجديدة والحالية؟

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

بالنسبة إلى XAML العام ، حيث أن إطار XAML UI بأكمله سيعيش منفصلاً عن Windows حيث أعرب الآخرون عن ذلك بحيث يمكن تبديل برامج العرض. سيؤدي هذا إلى فتح إمكانية تشغيل WinUI XAML على منصات أخرى وهو عامل تعريف ضخم في الوقت الحاضر عندما يختار الأشخاص حزمة للتشبث بها ، كما يتضح من شعبية أطر عمل Electron و JS التي تستفيد من مثل هذه الشركات الصغيرة التي ليس لديها القوى العاملة لتطوير قواعد كود أصلية على وجه التحديد لكل منصة.

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

قد تكون هذه الطلبات مجدية وقد لا تكون ممكنة ، لكني أحب XAML وأرغب في استمراره في التحسن ، لذلك سأذكر بعض نقاط الألم (ولكن لا تزال قابلة للخدمة) التي واجهتها أنا وبعض أعضاء فريقنا عند تطويرها لهم.

mdtauk أنا لا أعارض أمان الملفات ولكن يجب أن تمنعك النواة الأساسية من الكتابة في الأماكن التي لا يحق لك استخدامها بدلاً من استخدام مجموعة جديدة كاملة من واجهة برمجة التطبيقات والتخلي عن ملف Win32 API. أيضًا ، أعلم أن هذا أصبح بعيدًا عن الموضوع ، لكن واجهة برمجة تطبيقات StorageFile / StorageFolder هي بدائل مروعة ، ولا تمثل حتى أمان الملفات. إنها بطيئة ودائمًا ما يتم ربطك بالوكيل من خلال وسيط ملفات وقت التشغيل. علاوة على ذلك ، لا ينبغي أبدًا أن يكون هناك قيد على تطبيقات الحماية التي تحتاج إلى إذن خاص معتمد من MS للكتابة في مجلد مستندات المستخدم. فقط على سبيل المثال كيف كانت قصة الملف سيئة لجهود AppContainer ، كان من المستحيل إنشاء قاعدة بيانات sqlite في أي مكان باستثناء مجلد LocalData المخفي للمستخدم. بالنسبة لنظام سطح المكتب حيث يريد المستخدمون إنشاء الملفات وحفظها وفتحها وحفظها باسم yadda yadda ، فإنه يضع العبء على مطوري البرامج الذين يحتاجون إليه لإعادة تدريب المستخدمين على كيفية إدارة محتوى المستخدمين.

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

MarkIngramUK شكرًا لك على تعليقاتك ، توضيح واحد فقط. تمت إعادة تسمية مفهوم Xaml Desktop الذي تم تقديمه في نظرة خاطفة على // Build 2019 إلى WinUI Desktop. سيستخدم مشروع Visual Studio الجديد هذا نموذج تطبيق Win32 ، مع WinUI كإطار عرض تقديمي ، ويمكن أن يكون أصليًا أو مُدارًا (باستخدام .NET Core 3).

شكرًا @ marb2000 - هل هذا ضمن الإطار الزمني لـ WinUI 3.0؟

@ marb2000 بواسطة WinUI Desktop ، هل تقصد تطبيقات Win32 مع Xaml Islands؟ في أي جلسة بناء تم عرض هذا؟

شيء واحد يجب على فريق WinUI الانتباه إليه مع إعادة تسمية WinUI 3.0: إذا قمت بإعادة تسمية أي من الأنواع المعروضة في .NET ، فلن تعمل الإسقاطات (ونحن لا نخطط لإضافة المزيد لأنه ليس كذلك نظام قابل للتوسيع قابل للصيانة). فيما يلي قائمة بالأنواع التي نتوقعها: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

ستتطلب أي تغييرات على أنواع مختلفة من هذه الأنواع من المستخدمين التفاف كائناتهم في كائنات جديدة تقوم بتنفيذ الواجهات الجديدة أو نسخ بياناتهم في الأنواع الجديدة. على وجه الخصوص ، تعتبر الأنواع INotifyPropertyChanged و INotifyCollectionChanged ذات أهمية فيما يتعلق بجزر XAML وتوفر دعم المصب.

INotifyDataErrorInfo

يرجى عدم إدخال مساحات أسماء جديدة لأشياء مثل INotifyDataErrorInfo - يجب استخدامها في نماذج العرض التي عادة ما تكون مشتركة بين الأنظمة الأساسية ويجب ألا تعتمد على WinUI. يجب تحديد مكان وجود أشياء أخرى مثل هذه (مثل INotifyPropertyChanged أو INotifyCollectionChanged)

حول هذا الموضوع. يحتوي Windows.UI.Xaml.Interop بالفعل على واجهة INotifyCollectionChanged و Windows.UI.Xaml.Data يحتوي على INotifyPropertyChanged. سيتم نقل هذين إلى مساحات أسماء Microsoft. ربما تستطيع التجميعات System.Runtime.WindowsRuntime القيام ببعض التعيينات من WinUI إلى .Net

نشكرك على الرد ، ولكن لماذا تحتاجه في مساحة اسم Microsoft إذا كان .NET Standard يحتوي عليه بالفعل في System.ComponentModel؟ https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo؟view=netstandard-2.0

@ meir-pletinsky. NET هو إطار عمل واحد فقط يمكنك استخدامه لإنشاء تطبيقات باستخدام UWP XAML. يريدون التحقق من صحة حقل النص المتاح للمطورين ، بغض النظر عن إطار العمل الذي يستخدمونه

mdtauk ، لا ، يسمح لك WinUI Desktop (سابقًا Xaml Desktop) باستخدام Xaml مع Win32 مباشرةً ، دون استخدام الجزيرة.

@ marb2000 سيكون رائعًا إذا سمح لك مشروع تغليف التطبيقات بإنشاء AppX مع نافذة Win32 وتضمين مكونات WinRT بنفس الطريقة السهلة التي يقوم بها مشروع UWP. هناك الكثير من الأشياء التي لا تعمل بدون تحرير ملفات vcxproj يدويًا مثل إضافة الموارد ومحول cppwinrt الذي ينشئ الرؤوس من مكونات WinRT المضمنة.

مشروع آخر مهم لواجهة المستخدم الجديدة هو _PropertyChanged.Fody_ بواسطة Simon Cropp الذي يسمح بالتنفيذ التلقائي لـ INotifyPropertyChanged (حاولت مع C # / F #). راجع https://github.com/Fody/PropertyChanged

يسمح برمز بسيط مثل هذا:

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

والتي يمكننا استخدامها للربط بواجهة المستخدم.

شيء واحد أود رؤيته في WinUI 3.0: حاليًا ، لا يمكن استدعاء مترجم UWP XAML ( genxbf.dll ) إلا مباشرةً بواسطة MSBuild عند الرجوع إليه من ملف csproj أو vbproj أو vcxproj. هذا بسبب عدم وجود أداة سطر أوامر يمكن استخدامها لاستدعاء هذه الوظيفة. يبدو لي هذا قرارًا غريبًا للغاية ، حيث لا يتطلب تنزيل Windows 10 SDK أي شيء آخر يتطلب Visual Studio. (تتضمن الوظيفة الإضافية WDK أيضًا أهداف Visual Studio ، ولكن هذه الأهداف جميعها تستدعي أدوات سطر الأوامر التي يمكن استخدامها بشكل مستقل عن VS.) سأكون ممتنًا للغاية لإضافة مثل XbfCompiler.exe و XbfCodeGen.exe إلى دليل bin SDK. (سيقوم EXE السابق بترجمة ملفات XAML إلى ملفات XBF ، والأخير سينشئ ملفات الشفرة الخلفية المطلوبة للإشارة إلى أنواع XAML من التعليمات البرمجية.) سيكون هذا مفيدًا بشكل أساسي في مشاريع C ++ التي تستخدم CMake أو غير مرئي آخر أداة إنشاء الاستوديو ، ولكن يمكن استخدامها أيضًا لمشاريع C # و VB.NET إذا لزم الأمر. شكرا!

MarkIngramUK هل تعرف أين يمكنني معرفة المزيد عن WinUI Desktop. جلسات Build 2019 غير متاحة للمشاهدة عبر الإنترنت. يبدو أنه معلومات مهمة يجب ربطها في هذا الريبو

mdtauk تم ذكره في ما يسمى Sneak Peek ، وهو مخصص فقط للحاضرين في Build. افايك لا يوجد تسجيل. لم أكن هناك أيضًا ، ولكن هناك شريحة - ربما أفضل شريحة :-) - متوفرة على Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

mdtauk تحتوي خريطة طريق WinUI 3 على أحدث المعلومات والرسوم البيانية التي هي أكثر حداثة مما تم عرضه في نظرة خاطفة على البناء. لا يوجد شيء مثل "XAML Desktop" أو "WinUI Desktop" ... كان ذلك مجرد اختيار كلمة محير على شريحة تم تصويرها. المفهوم الذي يتم توصيله (وتحاول خارطة الطريق شرح ذلك بشكل أكثر وضوحًا) هو أنه بالنسبة لـ WinUI 3 ، فإننا نعمل على جعله حتى تتمكن من الحصول على قالب مشروع يقوم بإنشاء تطبيق سطح مكتب / Win32 تقليدي جديد باستخدام WinUI 3 لواجهة المستخدم الخاصة به (كما هو الحال اليوم ، توجد قوالب لأطر عمل واجهة المستخدم مثل WinForms و WPF و MFC وما إلى ذلك فوق نموذج سطح المكتب / Win32 التقليدي) بالإضافة إلى نموذج مشروع تطبيق نموذج UWP / WinRT محدث يستخدم WinUI 3. هل ذلك تساعد في توضيح؟

تبدو خارطة الطريق 3.0 معقولة تمامًا بالنسبة للاستراتيجية التالية: تمكين أي تطبيق عميل Windows لاستخدام XAML وعناصر تحكم WinUI "الحديثة".

ومع ذلك ، تبدو هذه الإستراتيجية قصيرة النظر إذا أخذنا في الاعتبار حقيقة سوق اليوم: بالنسبة للكثير من تطوير التطبيقات ، يعتبر Android و iOS هما الهدفان الأساسيان ، و Windows أمر رائع. بالنسبة لمطور .NET ، يمنحك Xamarin دعمًا لائقًا لنظامي التشغيل Android و iOS ، لكن دعم Windows الخاص بهم دون المستوى. لذلك بالنسبة لتطبيقات الأجهزة المحمولة / سطح المكتب الأصلية ، فإن Win UI 3.0 لا يفعل شيئًا لتبسيط التطوير عبر الأنظمة الأساسية لمطوري .NET.

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

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

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

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

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

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

حسب: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

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

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

TonyHenrique عندما تذكر Fody ، هل هذا لأنك تريد خلق وعي به ، أم أنك تقول إنه يجب أن يكون مدمجًا في WinUI؟

تعتبر قوالب العناصر أو المكتبة مثيرة للاهتمام أيضًا! هناك بعض النقاط الرائعة في الردود حتى الآن حول توفير رمز معياري إضافي وكود بداية وهو شيء آخر يمكننا التفكير في إضافته بمرور الوقت ، ربما مثل Windows Template Studio.

Jesbis أنا مساهم أساسي في Windows Template Studio وأشاهد خارطة طريق WinUI بهدف ما نقوم به في المستقبل وكيف نقدم الدعم لـ WPF. ؛)

ما نوع تحديثات التبعية التي تجعلها أكثر قيمة؟ على سبيل المثال ، إيجاد إصدارات جديدة من حزمة NuGet متوافقة؟

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

mrlacey لقد ذكرت Fody لأنني أعتقد أنه حل مثير للاهتمام ونحتاج إلى طريقة أفضل لتجنب الكود المعياري _INotifyPropertyChanged_. سيكون من الجيد أن يكون لديك حل مدعوم من MS لهذا المفهوم الخاص بالكائن التفاعلي الذي يقوم تلقائيًا بإثارة حدث عندما تتغير بعض الخصائص.
إنه يعمل على فئات C # وحتى على F # Records (ولكن واجه بعض الصعوبات).
لذلك في خارطة طريق WinUI يجب أن يكون هناك هذا أيضًا.

ملاحظة: سيكون من الجيد إذا تمكنا أيضًا من استخدام سجلات F # لتحديد كيانات البيانات الخاصة بنا والربط مباشرة بواجهة XAML UI. سيكون من الرائع لو تمكنا من استخدام F # Records + Fody + DataBinding بدون مشاكل.

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

سيكون هذا مألوفًا أكثر للأشخاص القادمين من C #.
نهج آخر سيكون طريقة Elmish. أعتقد أن كلاهما مثير للاهتمام ويمكن دعمهما.

tonyhenrique / mrlacey أعتقد أن أشياء Fody (OAP) يجب أن تكون خارج النطاق. لدى فريق WinUI ما يكفي على صفيحتهم بالفعل ، وأعتقد أنه من الأفضل أن يكون لديهم النسيج في مشاريع منفصلة (دورات إطلاق أسرع بكثير في حالة التحسينات).

وأعتقد أن هذا هو في الواقع تفاصيل تنفيذ .NET (IL) للنماذج ، وليس في الواقع أي شيء له علاقة بـ WinUI (على الرغم من أنه يمكنه الاستماع إلى أحداث التغيير). اقتراحي هو الاحتفاظ بها منفصلة. على سبيل المثال ، أنا أستخدم Catel ولديها نساج Fody الخاص بها للتأكد من أن كل شيء يتم نسجه بشكل صحيح.

ما أود حقًا رؤيته هو لهجة XAML متطورة مع تطلعات عالمية حقًا. يجب أن أكون قادرًا على كتابة تطبيق .NET باستخدام XAML وتشغيل هذا التطبيق على أنظمة تشغيل Windows و iOS و Android. يجب أن يكون التطبيق حقًا من الدرجة الأولى على كل نظام أساسي وأن يكون لديه إمكانية الوصول إلى العناصر الأصلية حسب الحاجة.

هناك اقتراح طويل الأمد للذهاب في هذا الاتجاه: Cross platform UX لـ .NET 5 - العنوان الأصلي Cross platform UX for .NET Core 3.0 . إن الدعم الهائل من المجتمع لذلك واضح ويمكننا أن نأمل أن تدرك MSFT أن هذا هو أفضل اتجاه لتطوير أي إطار عمل لواجهة المستخدم يعمل على .NET. لا يوجد سبب كبير للاحتفاظ بقواعد أكواد منفصلة لمجموعات أنظمة أساسية مختلفة وإنشاء مجموعات مهارات مطور منفصلة بالقوة استنادًا إلى أطر UX المختلفة المدعومة من .NET.

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

mfeingol / @ 4creators ،

يجب أن يكون التطبيق حقًا من الدرجة الأولى على كل منصة

على Windows لتبدأ بـ ...

إنه عام 2019 ، أريد واجهة مستخدم أصلية سريعة ، ولا أريد أن أفكر بجدية في إنشاء واجهة مستخدم بـ CreateWindowExW ، GDI ، إلخ.

الآن ، مع WinUI3.0 وما فوق ، تم فصل الكود عن Windows 10 ، هل هناك خطط في المستقبل لـ WinUI للعمل على Linux و Mac؟

jesbis التفاعلات التي تعمل باللمس وستبقى في WinUI 3.0؟

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

مع تحوله إلى XAML plus Win32 ، يصبح الأمر أكثر منطقية ، خاصة مع نظام التشغيل Windows Core OS الذي يعيد كتابة غلافه في XAML.

كما أفهمها الآن ، فإن هذا الوصول الغني لواجهة برمجة التطبيقات Win32 موجود في C و C ++ | مع أي شيء في C # يعتمد على .NET (كل ذلك الآن NET Core).

ربما يجب أن تكون هناك طريقة آمنة وبسيطة للوصول إلى واجهات برمجة تطبيقات Win32 هذه ، بالإضافة إلى المزيد من نقاط الدخول لعرض واجهة مستخدم التطبيقات؟

• System Tray XAML flyout لتطبيقات WinUI 3

• واجهات مستخدم بسيطة لـ Picker لـ Hololens / Xbox / Surface Hub / IoT ، إلخ

• XAML المحدثة القابلة للتخصيص حوارات الملفات العامة ومنتقي المجلدات

• وصول بسيط لـ C # .NET إلى واجهات برمجة تطبيقات Win32

• إعداد مضغوط لجميع عناصر XAML ، والذي يتطابق مع تحجيم التحكم في Win32 و WPF (سيساعد ذلك الإطارات على الجلوس بشكل مريح معًا)

• مطابقة أنماط التحكم / الخطوط / فرش التشكيل / الأكريليك عند استخدام WinUI

• تعريف واضح للأجهزة التي تتطلب دورة حياة WinRT / Mobile

• يتحكم Xbox Next في الأنماط المضمنة لتطوير تطبيقات Xbox واختبارها على Windows

• تخزين وتنزيل حزمة exe / MSI / APPX مفردة مدعومة افتراضيًا ، بدون مثبتات ، ظاهرية نظام ملفات من نوع المئوية بشكل افتراضي

• WinForms WinUI 3.0 - واجهة مستخدم بسيطة والوصول إلى MFC والماوس ولوحة المفاتيح فقط

• WPF WinUI 3.0 - واجهة مستخدم كثيفة ، عرض ثلاثي الأبعاد ، إدراك DPI ، لمسة محاكاة ودعم أساسي للحبر

• Xaml WinUI 3.0 - اللمس الكامل ، MR ، لوحة الألعاب ، الكتابة بالحبر ، الصوت ، الماوس ، لوحة المفاتيح. واجهات مستخدم كثيفة وبسيطة. دعم النوافذ الجديدة. عرض MR ثلاثي الأبعاد. دورة حياة مُدارة اختيارية أو دورة حياة سطح المكتب. الأفضل من بين جميع العوالم الافتراضية لتطبيقات البريد الوارد والمعاد صياغتها ، مع إصدارات Win32 من تطبيقات البريد الوارد مثل المفكرة ، و charmap ، والطلاء ، ومستكشف الملفات - مفتوح المصدر ومتاح من المتجر.

سيتم الاحتفاظ بالتفاعلات التي تعمل باللمس في WinUI 3.0؟

@ r7dev نعم ، الخطة هي الحفاظ على نفس المستوى من دعم اللمس.

تم تجاهل F # في خارطة طريق WinUI 3.0. تجاهل Microsoft أحد منتجاتها مرة أخرى.

أفكار Win32 API

هناك شيء فكرت فيه أيضًا هو سبب بقاء win32 أيضًا. أعتقد أن هناك افتراضًا بأن هذا بسبب المشاريع القديمة ، لكنه في الواقع أعمق من ذلك. من السهل جدًا ربط Win32 ABI بلغتك التي تختارها ، nodejs ، python ، rust ، go ، ruby ​​، ​​c # ، c ++ ، إلخ. إلخ. إذا كان مشروعي الأساسي في حالة صدأ على سبيل المثال ، وأريد إنشاء نافذة لإدارة الإخراج ، كمطور صدأ ، من القوي جدًا الوصول إلى مجموعة Win32 API وإنشاء واجهة أمامية بنفس اللغة.

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

لذلك إذا كنت ترغب في جعل WinUI 3.x هو المسار الحقيقي للأمام للوصول إلى Win32 UI بزمن انتقال منخفض وذاكرة منخفضة وعالية الجودة ، فأنت بحاجة إلى التفكير في السهولة التي يمكن من خلالها لمشرفي اللغة الآخرين الاستفادة من البنية التحتية.

تناسق واجهة المستخدم

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

ستكون هناك دائمًا ميزات تحتاج إلى الاشتراك ، يمكنني التفكير في Dark Mode كشيء إذا لم يكن التطبيق مصممًا له ، فلن يكون من المنطقي حقًا تقديمه كخيار ، ولكن لا يزال هناك تعديلات على مكونات النظام التي ستتغير بمرور الوقت.

الحجم الثنائي

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

تتمثل إحدى مزايا C ++ في أنه يحتوي على حد أدنى من النفقات العامة للمكتبة اعتمادًا على قاعدة التعليمات البرمجية. بالتأكيد إذا كان كل تطبيق من الآن فصاعدًا يتطلب WinUI 3.x ، فسيكون ذلك 40 ميجابايت × عدد التطبيقات.

الحجم الثنائي

WinUI هي بالفعل تبعية ، تمامًا مثل .NET. إنها بالفعل مكتبة على مستوى النظام. :)
ليس لديك dlls مكررة ، ولن يكون لديك.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

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

"هناك شيء فكرت فيه أيضًا هو السبب الذي جعل Win32 عالقًا أيضًا. أعتقد أن هناك افتراضًا بأن هذا بسبب المشاريع القديمة ، ولكنه في الواقع أعمق من ذلك. Win32 ABI سهل جدًا للتواصل مع لغتك التي تختارها ، nodejs ، python ، rust ، go ، ruby ​​، ​​c # ، c ++ ، إلخ. إلخ. إذا كان مشروعي الأساسي في حالة صدأ على سبيل المثال ، وأريد إنشاء نافذة لإدارة الإخراج ، كمطور صدأ ، فهو قوي جدًا الوصول إلى مجموعة Win32 API وإنشاء واجهة أمامية بنفس اللغة. "

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

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

ما هي القوالب التي تهتم بها أكثر؟

أفضل حاليًا أن أبدأ من مشروع فارغ (يونيفرسال ويندوز). أنا أحب القوالب ذات الإطار المكون مسبقًا أيضًا ، ولكن فقط عندما أرغب في تجربة شيء ما بسرعة. نموذج "القائمة الرئيسية" ونموذج MDI لـ UWP سيكونان رائعين أيضًا (حيث توجد هذه القوالب لـ WinForms أيضًا)

هل كنت على علم بجزر Xaml لتحديث تطبيقات سطح المكتب؟
هل هذا التوافق مع الإصدارات السابقة على نظام التشغيل Windows 10 يجعل Xaml Islands أكثر فائدة لك

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

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

نعم ، أكيد ما إذا كان يعمل بشكل موثوق! أنا مندهش من التعليقات العديدة التي لا تقدر هذه الميزة الرائعة. يمكن لهذه الميزة أيضًا التحقق مما إذا كان التحديث إلى WinUI 3.0 ممكنًا ، واعتماد رمز XAML ، وضبط مساحات الأسماء وتثبيت مجموعات WinUI المطلوبة.

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

أتوقع تغيير مساحات أسماء عناصر التحكم فقط للعمل بشكل كامل مع WinUI 3.0. لا أرغب في استثمار الكثير من الوقت في الترقية إلى WinUI 3.0

هل تنشئ أو تستخدم مكتبات تحكم UWP Xaml أو مكونات WinRT التي لا يمكنك بسهولة إعادة تجميعها وتحديثها جنبًا إلى جنب مع كود التطبيق؟

أنا أستخدم مكتبات تحكم UWP Xaml تابعة لجهات خارجية (مثل Windows Community Toolkit ، https://github.com/kakone/VLC.MediaElement). أعتقد أنني سأكون قادرًا على ترقية عناصر تحكم بسيطة من مكتبات الطرف الثالث مثل Dockpanel بنفسي إلى WinUI 3.0.

ما هو الحل المفضل لديك لاستخدام مكونات UWP Xaml مع WinUI 3؟

• إنشاء قالب مشروع "تطبيق فارغ مع WinUI 3.0" في Visual Studio لـ UWP. سيتم تثبيت تبعية WinUI 3.0 كـ nuget (كما هو الحال في WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . أنا بالتأكيد أفضل مثل هذا الحل طالما أنني أحصل على جميع الضوابط الأساسية. أتوقع أن جميع الفئات من Windows.UI لها فئة مكافئة في Microsoft.UI Namespace.

كان الموضوع الرئيسي في WinUI 3.0 يدور حول عناصر التحكم وتوافق Windows 10 والذي يمكن استخدامه من UWP و WPF أو WinForms عبر XAML Island ، إذا كنت على صواب. هل هناك أي فرص في أن تحصل UWP XAML Markup على ميزات إضافية بطريقة أو بأخرى؟

• مشغلات النمط مفقودة
• النمط `BasedOn = {StaticResource {x: Type TextBlock}} مفقود
• لا يتم تطبيق قوالب البيانات المحددة مع أنواع البيانات تلقائيًا كما هو الحال في WPF (فقط عبر المفتاح)
• لماذا يتم إعلان كل ثانية Windows.UI.Xaml.Controls تحكم (TextBlock، Border، ...) على أنها مختومة ؟! من فضلك لا تفعل هذا في WinUI 3.0 مع UWP.
• امتدادات العلامات لتكافؤ WPF
• تم ذكر هذا بالفعل ، لكنني سأذكره مرة أخرى. من المحزن أن UWP لا تستخدم System.ComponentModel.IDataErrorInfo. بهذه الطريقة لا يمكنني مشاركة مشروعي النموذجي مع حل UWP.
• ReportControl (لتطبيقات المؤسسة)

أنا أتطلع حقًا إلى WinUI 3.0 وتوافقه مع الإصدارات السابقة!

تم تجاهل F # في خارطة طريق WinUI 3.0

هل هناك أي فرص في أن تحصل UWP XAML Markup على ميزات إضافية بطريقة أو بأخرى؟

@ Happypig375 ، @ mfe-:

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

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

لماذا يتم إعلان كل عنصر تحكم Windows.UI.Xaml.Controls ثاني (TextBlock ، Border ، ...) على أنه مغلق ؟! من فضلك لا تفعل هذا في WinUI 3.0 مع UWP.

إن فك الضوابط هي في الواقع واحدة من عدد قليل من الميزات الجديدة التي نأمل في تضمينها في 3.0 😊

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

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

جميع لغات الشفرة متساوية وقابلة للتبديل ، حيث يتعامل WinUI 3.0 مع كل واجهة المستخدم

هذا هو xlang 😉

هذا هو xlang 😉

MarkIngramUK Hmm ، اعتقدت أنه جسر بين اللغات ، والذي

لقد كافحت نوعًا ما لفهم الغرض من xlang - التمويه على التحديثات التي كانت تحدث في الريبو (ولكن لا يزال موجودًا في قائمة المشاهدة الخاصة بي)

هل يعمل xlang قبل التجميع أو بعده؟ هل هي لغتها المستخرجة التي يمكن إسقاطها ، أم أنها تقع فقط بين ملفات الكود الموجودة؟

نعم ، لا يمكنك مزج اللغات في مشروع واحد. إنه جسر ، لكنه لا يزال مفيدًا لهذه الأغراض.

MarkIngramUK أعتقد أنه إذا تم تضمين الكود الخاص به الذي يمكن تجميعه.

سيكون من الجيد أن تكون قادرًا على استخدام C # للوصول إلى ميزات Win32 الأصلية ، بدون PInvokes وحيل .NET الأخرى

jesbis أنا بصراحة أكثر اهتمامًا بالجوانب المشتركة بين الأنظمة الأساسية لهذا المشروع ...

أعتقد أنه في البداية ، يجب أن تعيدوا تسميته إلى شيء أكثر _ عام_ وليس بشكل صارم إلى "Windows".

أدركت أن التنفيذ الأولي يجب أن يركز بشكل صارم على Win32 وتطبيقات UWP / Xamarin الخلفية و Windows ولكن فقط OSS وجعلها من البداية تسمى مثل إطار عمل "Windows-only" ، بالتأكيد لن تحصل على الكثير من الجذب تمامًا مثل UWP لم ولن يهتم به المطورون من منصات أخرى.

إذا كان الهدف على .Net 5 هو أن يكون "One .Net Everywhere" ، وهو ما توقعه الجميع دائمًا منذ .Net 1.0 ، يجب أن تبدأ أسس إطار عمل "أي شيء عدا Win UI".

يعد Google Flutter مثالاً جيدًا على كيفية تصحيح ذلك. لا تزال Flutter في أيامها الأولى ، ولكنها حصلت على الكثير من الجر نظرًا لحقيقة أن جوهرها (المعروف أيضًا باسم Flutter Engine) هو 100 ٪ متقاطع ويعمل في كل مكان (بما في ذلك IoT و Win و OSX وحتى الويب!).

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

من فضلك لا تغضبني ولا تأخذ تعليقي على أنه نقد سيئ. أتمنى أن تحصل الجهود المبذولة على واجهة المستخدم على شبكة الإنترنت على شيء مثل Flutter و .Net Core 3.0 / .Net 5 وحتى Blazor.

للتسجيل ، بدأت مشروعًا لإعادة كتابة / منفذ محرك Flutter بالكامل على C # و .Net Core بسبب نقص الخيارات على .Net World ...

راجع للشغل ، CoreUI اسم جيد ...

مجد لجيك هيلفرت لهذا الاقتراح 😄

💃

راجع للشغل ، CoreUI اسم جيد ...

مجد لجيك هيلفرت لهذا الاقتراح 😄

💃

قد يتم الخلط بين CoreUI و .NET Core

يركز WinUI بشكل كبير على Windows ، ولكن إطار XAML بداخله ، يمكن أن يحصل على عارضين لـ Metal (iOS و macOS) أو Vulkan (Android) - ويمكن أن يكون FabricWeb هو طريقة PWA / ChromeOS للتعامل مع الأنظمة الأساسية الأخرى.

إذا اختار الفريق في أي وقت إحضار نظام العرض التقديمي ، ويمكن لـ Xland أو Xamarin التعامل مع وقت تشغيل التطبيقات عبر الأنظمة الأساسية.

حول الترحيل من Inbox UWP UI إلى WinUI 3.0 ، سأقتبس مشاركة مدونة حديثة من dotMorten (https://www.sharpgis.net/post/2019/05/14/The-future-UWP):

ملاحظة سفلية ممتعة: ما يحدث لـ UWP ليس أنه يتم قتله: تعمل Microsoft على تقديم أفضل الأجزاء إلى حيث نحتاج إليها. حدث هذا بالفعل من قبل ، ولكن للأسف لم يتم استخدامه كفرصة لأداء المحور. تذكر Silverlight؟ خمن من أين جاء CLR عبر الأنظمة الأساسية لـ .NET Core. وانتهى الأمر أيضًا بالكثير من رموز Silverlight في UWP. لو قاموا بالتدوير فقط وقالوا "نعم ، نحن نتفق على أن Silverlight غير منطقي في قطع الغيار الخاصة بالمستهلكين ، ولكنه يزدهر في مساحة المؤسسة ، لذلك دعونا نبني على ذلك ، وسنطوره إلى .NET Core و Windows Store". لسوء الحظ ، لم يكن ذلك سلسًا ، ولا يزال الكثير من الناس يعانون من اضطراب ما بعد الصدمة ويخشون مما تفعله Microsoft ويبدو أنه يقضي على أي تقنية.

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

weitzhandler يدور WinUI 3.0 عن الجمع بين العديد من أطر عمل Win32 و .NET Core و UWP مع إطار عمل XAML واحد والتفاعل مع WPF و WinForms و MFC ++

يتم تحويل XAML على Windows إلى Direct X.

إذا كنت تريد أن تأخذ نفس XAML ، مع .NET Core ، وتجعله يعمل على أنظمة أساسية أخرى. سوف تحتاج إلى كتابة عارضين جدد لتلك المنصات. يستخدم iOS و macOS Metal كمكافئ لـ Direct X. يستخدم Android Vulkan. لا توجد فكرة عن كيفية تعامل Linux مع العرض ، أعتقد أنه مجرد Open GL.

لن ترغب Microsoft في القيام بذلك بنفسها لأنه لا معنى لها بالنسبة لهم. لكن WinUI 3.0 سيكون مفتوح المصدر - لذلك يمكن للآخرين اختيار محاولة جلبه عبر النظام الأساسي

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

شكرا لتوضيح ذلك. ربما يكون Flutter هو المستقبل بالنسبة لي.

هذا مجرد فهمي ، يمكن أن أكون مخطئا.

من المفترض أن يحصل Flutter على دعم Windows في المستقبل. ويأتي دعم React Native إلى Windows أيضًا. بالإضافة إلى وجود PWAs إذا كنت مستثمرًا في عالم Web HTML و Javascript.

بالنسبة لي ، يمكن أن تكون قصة WinUI بأكملها أكثر منطقية إذا أخذوا في الاعتبار أيضًا السماح لمجموعة فرعية أساسية منها على الأقل بالعمل عبر الأنظمة الأساسية (macOS و iOS و Android) بما في ذلك الويب ، كما تقدم دعمًا أفضل لـ F # وقوالب المشروع (بما في ذلك ربط XAML ثنائي الاتجاه بسجلات F # ، وأيضًا بطريقة Elmish أكثر فاعلية)

يجب أن يكون XAML محايدًا للبيئة تمامًا مثل HTML دون أخذ 100 ميجابايت + حتى لأبسط تطبيقات الأدوات كما تفعل تطبيقات HTML. هذا يعني أن إطار عمل XAML مكتوب بلغة C / C ++ أو C # ويمكن استضافته في WASM و Win32 و UWP و iOS و Android و macOS و Linux وغيرها بأقل جهد عندما يتعلق الأمر بالنقل. أنت بحاجة إلى خلفية عرض محايدة مثل استخدام محركات اللعبة لتبدأ.

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

الطريقة الوحيدة لحفظ XAML في رأيي هي:

• قم بإنشاء قاعدة إطار عمل محايدة / محمولة جديدة لـ .NET Core و C / C ++.
• قم بإنشاء طبقة تجريدية محايدة يمكن لأي شخص تمديدها عبر طلبات السحب.
• تمامًا مثل HTML ، حافظ على تركيز XAML على مفاهيم التطبيقات ذات النافذة الواحدة (تمامًا كما هو الحال في الألعاب أيضًا) ولكن تسمح بميزات سطح المكتب الموسعة للنوافذ المتعددة وما إلى ذلك (يسمح هذا للتطبيق بالتشغيل في أي سياق تقريبًا تمامًا كما يمكن لواجهة مستخدم الألعاب)

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

1 يحتاج MS إلى دعم مشروع XAML أو يخشى الناس سقوطه.

2 يجب أن يكون عبر الأنظمة الأساسية وإلا فسيظل الجميع عالقًا بأوقات تشغيل HTML المتضخمة المجنونة.

على أي حال ، هذا هو سنتي ، وإذا تم تصميم WinUI 3.0 بشكل صحيح ، فربما يكون النقل ممكنًا. في هذه المرحلة على الرغم من أنني أتساءل ما الذي تشعر به.

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

أيضًا ... سيشعر إتقان نظام التشغيل Mac بالضيق ، ما عليك سوى إلقاء نظرة على iTunes ، وكان على Apple نقل نظام واجهة المستخدم بالكامل إلى Windows ، وهو بالتأكيد في غير محله. يختلف عرض الخط ، حيث تبدو منحنيات الرسوم المتحركة والظلال وخيارات الألوان في غير محله في Win10. أعني ، إنه جيد وقابل للاستخدام بالتأكيد ، لكنني أفضل Spotify الذي لا يحاول محاكاة أي واجهة مستخدم لسطح المكتب ويستخدم فقط متصفح ويب تحت الغطاء. على نظام Mac ، فإن رؤية ضوء موضعي مع مكونات مربعة في سطح مكتب مليء بالزوايا الدائرية وعدم وجود تأثير للكشف سوف يتعارض بشدة.

لا ، أعتقد أن هذا المشروع يجب أن يركز على تقديم أفضل طريقة في الفصل لإنشاء برامج Windows أصلية ، للمطورين الذين يريدون / يحتاجون إلى إنشاء برامج Windows. اترك عناصر النظام الأساسي لفرق Electron / Typescript لحلها.

هناك بعض التعليقات حول أن تكون عبر النظام الأساسي هنا ، ولست متأكدًا من أن WinUI يجب أن يكون عبر النظام الأساسي ليكون ناجحًا. لن يعمل بشكل جيد على نظام Mac أو Linux على أي حال ، لأنه مختلف بما يكفي بحيث لا يشعر بأنه أصلي على أي من هذه الأنظمة الأساسية. هذا المشروع مملوك لفريق لديه ثروة من المعرفة حول كيفية عمل الأجزاء الداخلية من Windows ، وسيكون من الأمور التي تشتت انتباههم أن ينطلقوا ويكتشفوا أيضًا كيفية جعل شيء ما يعمل بشكل جيد حقًا على Mac أو Linux بنفس الدرجة.
أيضًا ... سيشعر إتقان نظام التشغيل Mac بالضيق ، ما عليك سوى إلقاء نظرة على iTunes ، وكان على Apple نقل نظام واجهة المستخدم بالكامل إلى Windows ، وهو بالتأكيد في غير محله. يختلف عرض الخط ، حيث تبدو منحنيات الرسوم المتحركة والظلال وخيارات الألوان في غير محله في Win10. أعني ، إنه جيد وقابل للاستخدام بالتأكيد ، لكنني أفضل Spotify الذي لا يحاول محاكاة أي واجهة مستخدم لسطح المكتب ويستخدم فقط متصفح ويب تحت الغطاء. على نظام Mac ، فإن رؤية ضوء موضعي مع مكونات مربعة في سطح مكتب مليء بالزوايا الدائرية وعدم وجود تأثير للكشف سوف يتعارض بشدة.
لا ، أعتقد أن هذا المشروع يجب أن يركز على تقديم أفضل طريقة في الفصل لإنشاء برامج Windows أصلية ، للمطورين الذين يريدون / يحتاجون إلى إنشاء برامج Windows. اترك عناصر النظام الأساسي لفرق Electron / Typescript لحلها.

لا أعتقد أن أي شخص يريد حقًا تصميم Fluent كاملًا على منصات أخرى ، ولكن بدلاً من ذلك يكون قادرًا على تعظيم الكود المشترك بين الأنظمة الأساسية.

هذا شيء تمت معالجته بالفعل من قبل فريق تصميم Microsoft. يقول موقع Fluent صراحةً "تصميم وبناء تطبيقات مخصصة تكون في الأصل iOS بينما لا تزال بطلاقة بشكل فريد". تُظهر مستندات Fluent أنه يجب استخدام أسلوب التحكم الأصلي.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

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

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

KyleNanakdewa حسنًا إذا كانوا

أعتقد أن هذا المشروع يجب أن يركز على تقديم أفضل طريقة في الفصل لإنشاء برنامج Windows أصلي

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

بالإضافة إلى وجود PWAs إذا كنت مستثمرًا في عالم Web HTML و Javascript.

نعم ... "هذا العالم" الذي يحل بسرعة محل كل ما نعرفه عن نظام التشغيل الأصلي / المتجر / التطوير المستضاف. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

ضع في اعتبارك أن "هذا العالم" موجود على _ جميع_ الأجهزة الحديثة مع عارض HTML5:

• آبل بـ 1.4 مليار
• الروبوت مع 2.5 مليار
• Windows 10 بـ 800 مليون

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

قارن هذا مع Flutter ، التي تصل مع _one_ codebase إلى _ كل _ من الأسواق المذكورة أعلاه ، جنبًا إلى جنب مع الويب ، والتي تتكون في مجموعها كما ذكرنا من الثلاثة - وبالتالي زيادة الوصول إلى السوق والعائدات المحتملة لمطوري التطبيقات مع تقليل التكاليف اللازمة للإنشاء تطبيقات للقيام بذلك.

على الرغم من أنني معجب كبير بالجهود المبذولة هنا لفتح المصدر والتعاون وطلب تعليقات المجتمع ، إلا أنني لم أر أي شيء من هذه المناقشات (التي أستمتع بها أيضًا 😁) والتي تشير إلي بأي ثقة بأن الجهود هنا ستكون تنافسية - وبالتالي _مربحة_ - عند مقارنتها بأمثال Flutter (والتي بالمناسبة تستعد أيضًا لـ PWAs ).

يعد التحكم في الرسم التخطيطي ضروريًا في أي تجربة سطح مكتب حديثة تعتمد على البيانات في القريب العاجل ليكون NET CORE 3 رسميًا (سبتمبر 2019) وفي النهاية. NET 5 (نوفمبر 2020)

أرى التحكم في المصدر المفتوح Networkview كحالة استخدام فعالة حول كيفية العمل مع Xaml إلى منفذ WPF للتحكم في Win UI. ستعمل واجهة Win UI المنقولة هذه كنقابة جيدة للآخرين لنقل عناصر تحكم WPF الأخرى الأكثر تعقيدًا إلى Win UI.

نرى حالة استخدام 2 في 1 حيث يحتاج تطبيقنا إلى دعم وضع الجهاز اللوحي في نظام التشغيل Windows Core المستقبلي. نشك في أن Winform في NET Core 3 لن يساعد .. تبرير قوي آخر يجعل التحكم في مخطط Win UI ليس مجرد تمرين لـ PoC ولكن يجب أن يكون جزءًا من عناصر تحكم win ui الأساسية في فئة FIRST مماثلة لتحريك التحكم في الشبكة للأمام ..

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

يبدو أن migueldeicaza يأخذ الأمور بين يديه: https://github.com/microsoft/microsoft-ui-xaml/pull/736

أريد أن أردد صدى أفكار @ eklipse2k8 على منصات متعددة. عند إنشاء مكتبة واجهة مستخدم متعددة الأنظمة الأساسية ، سيتعين عليك دائمًا تقديم تنازلات. يجب ألا تتنازل WinUI - يجب أن تكون البديل الحديث لـ Win32 UI (لا أريد الاتصال بـ CreateWindowExW !) ويجب أن يكون عرضًا لما يمكنك القيام به على Windows. سيقدم WinUI على macOS أو Android دائمًا تجربة لا يمكن أن تتطابق أبدًا مع التجربة الأصلية. نكتب تطبيقات عبر الأنظمة الأساسية ، ونكتب واجهة مستخدم أصلية على كل منصة. بهذه الطريقة يحصل العملاء على أفضل تجربة في اختيارهم للمنصة. إذا كان الناس يريدون حلاً عبر الأنظمة الأساسية ، فلا بأس بذلك ، فعليهم أن يبحثوا عن مكتبة أخرى لهذا الغرض - ربما تلك التي تغلف WinUI على نظام Windows الأساسي.

وفيما يتعلق بـ PWA ، فهذه لا تمثل الاستخدام الكامل لنظام Windows UI ، والتوصية بالتركيز على "تطبيقات النافذة الواحدة" ستستبعد على الفور أي برنامج احترافي (باستثناء الألعاب). توجد حلول بالفعل لـ PWA والنظام الأساسي المشترك - لسنا بحاجة إلى حل آخر.

XKCD الإجباري:
https://xkcd.com/927/

MarkIngramUK أعتقد أن الحديث عن Cross Platform يتعلق أكثر بالقدرة على

الآن ، إذا كان هناك XAML Renderers لهذه الأنظمة الأساسية الأخرى - فإن كيفية تفسيرهم لـ XAML يمكن أن يكون مثل Xamarin Forms ، الذي يسلم إلى منصات UI الأصلية - أو فقط الرسم بشكل أساسي إلى المخزن المؤقت لبطاقة الرسومات ورسم وحدات البكسل على الشاشة - مع الحفاظ على معظم نفس أنماط الضوابط.

يجب أن يظل WinUI 3.0 مشروعًا يركز على Windows لتوحيد واجهات برمجة التطبيقات (API) المختلفة و ABIs باستخدام نظام أساسي لواجهة مستخدم XAML حديث. لكن هذا لا يعني أن Xamarin أو الأفراد لا يمكنهم أخذ كود العرض وإنشاء إصدارات لمنصات أخرى.

كل ما هو مطلوب حقًا (على مستوى عالٍ من التفكير) هو التأكد من احتواء الكود الذي يعرض XAML على الشاشة في Windows ، بحيث يمكن لعارضين آخرين التدخل في سيناريوهات عبر الأنظمة الأساسية.

ستحتاج WinRT / UWP / XAML إلى بعض إعادة البناء لاستخراجها من نظام التشغيل Windows 10 - لذا فإن كيفية إجراء إعادة البناء هذه ، للسماح بالتوسع في المستقبل ، أمر يجب مراعاته. سواء أصبحت المنصة المشتركة حقيقة أم لا.

MarkIngramUK أتفق مع mdtauk

يجب ألا يكون هناك سبب يمنعنا من استخدام xaml لوصف مكونات واجهة المستخدم في مكتبات أخرى بما في ذلك React. إذا نظرت إلى مشروع مثل http://www.cshtml5.com ، فإنهم يستخدمون xaml الذي يتم تحويله إلى html.
لا أعتقد أيضًا أن أي شخص يلمح إلى حقيقة أن الهدف النهائي هو أن تبدو واجهة المستخدم كما هي على الأنظمة الأساسية الأخرى ولكن ما أريده شخصيًا هو شيء على جانب واجهة المستخدم يمكنني استخدامه للاستفادة من استثماري الحالي في مثل UWP

النقطة ببساطة هي هذا. إذا قدمت اقتراحًا إلى عميل مؤسسة وقدمت تطبيق UWP رائعًا رائعًا من جميع النواحي. إذا كان لدى عميل المؤسسة هذا مستخدم واحد يستخدم جهاز MacBook Pro على سبيل المثال ، فعندئذٍ لدي مشكلة على الفور لأن عميل المؤسسة سيأخذ شيئًا يعمل في كل مكان (المقام الأدنى => موقع الويب) بدلاً من "تطبيقي الأصلي" حتى إذا تم تشغيله على نظام التشغيل Windows 10.

لذا فإن إمكانية الوصول هي المفتاح. حقيقة أن MS لا تزال تتوقع منا أن نقوم باستثمارات في "التطبيقات الأصلية" في عام 2019 دون أي خارطة طريق لتجاوز قدرة النظام الأساسي هو أمر مجنون.

من المرجح أن يتبع أي مشروع جديد من منظور المؤسسة المنطق أعلاه لإمكانية الوصول ومن ثم فإن جميع المشاريع الجديدة ستكون منحازة نحو الويب وكل ذلك بسبب عدم وجود خارطة طريق تتضمن إمكانية عبر النظام الأساسي على XAML / UWP

لذا فإننا نقدم سريعًا بعد 2-3 سنوات من الآن ، لا يوجد استثمار جديد من الشركات في UWP / win32 وأنت جالس مع "Silverlight" آخر لا يهتم به أحد.

يمكن أن تخبرني MS حتى أن XAML سيتم إهماله غدًا وأن مكتبة واجهة المستخدم "الجديدة" هي على سبيل المثال React. طالما أنه يمكن لصق c # بهذه المكتبة الجديدة ، فسوف أقوم بخفض خسائري ، وتفريغ XAML واحتضان مكتبة واجهة المستخدم الجديدة عبر النظام الأساسي. على الأقل ، يتمتع استثماري بالمتانة ويمكن الوصول إليه على المدى الطويل.

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

وفيما يتعلق بـ PWA ، فهذه لا تمثل الاستخدام الكامل لنظام Windows UI

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

ومع ذلك ، أفترض أن جزءًا من الالتباس هنا من جانبي هو تباعد الأسماء ليعكس Microsoft.* ، في حين يبدو أنه يجب أن يظل Windows.* (أو حتى Microsoft.Windows.* ) .

توجد حلول بالفعل لـ PWA والنظام الأساسي المشترك - لسنا بحاجة إلى حل آخر.

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

وبالتالي زيادة الوصول إلى السوق والعائدات المحتملة لمطوري التطبيقات مع تقليل التكاليف اللازمة لإنشاء التطبيقات للقيام بذلك.

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

فيما يتعلق بالحلول عبر الأنظمة الأساسية (xplat).
تعد حلول Xplat تجريدًا لأنظمة أساسية متعددة أصلية. ما أفهمه من WinUI هو أنه سيكون النظام الأصلي لنظام Windows.

إذا كان WinUI سيكون أيضًا xplat ، فكيف يمكن أن يدمج أشياء فريدة لنظام Windows؟ ألن يمنعها ذلك من القيام بأشياء جديدة ومبتكرة؟ أم أن هذا يعني أنه يتعين على Microsoft نقل أي شيء جديد أو تمييزه من Windows إلى الأنظمة الأساسية الأخرى أيضًا؟ ماذا عن الأشياء التي لا يمكن نقلها لأن نظام التشغيل الأساسي الآخر لا يمكنه دعمها - ألا يجب إضافتها إلى Windows؟

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

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

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

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

فيما يتعلق بالحلول عبر الأنظمة الأساسية (xplat).
تعد حلول Xplat تجريدًا لأنظمة أساسية متعددة أصلية. ما أفهمه من WinUI هو أنه سيكون النظام الأصلي لنظام Windows.

آسف لكني لا أشعر بهذه الطريقة ...

انظر إلى Flutter ... إنه يحتوي على محرك أساسي يمكنه عرض أي شيء على أي نظام أساسي يدعمه.

علاوة على ذلك ، يحتوي على مكونات يتم تنفيذها بالكامل على Dart باستخدام الطبقة المُدارة للمحرك والتي تمثل (السحب / التصيير) بدقة بكسل النظام الأساسي ولغة التصميم التي تريد استخدامها على سبيل المثال ، Material.io و Apple's Cupertino.

لذلك ، هذا IMHO ، سيكون هذا هو أفضل نهج لعمل شيء عبر النظام الأساسي والذي يمثل في نفس الوقت قدرات النظام الأساسي الأساسية.

لا أعتقد أنه من المعقول افتراض أنك إذا قمت ببناء شيء باستخدام تقنيات Windows الأصلية ثم أردت تشغيله على نظام تشغيل منافس ، فإن الأمر متروك لـ Microsoft / Windows لتسهيل ذلك

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

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

هذا بالضبط ما أقوله ...

على سبيل المثال ، تأتي أدوات تضمين الرفرفة لسطح المكتب على كل من Win10 (WPF و UWP) وكذلك OSX.

تتم إدارتها بنسبة 100 ٪ من خلال وقت تشغيل الرفرفة ، لكنهم يستخدمون فقط (على سبيل المثال) WPF / UWP للحصول على إدارة النوافذ ومؤشر Graphics . كل الباقي يديره المحرك ...

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

هذا هو السبب في أنني أقول أن WinUI عن طريق UWP: The empire strikes back لن يعمل على المدى الطويل.

يجب أن يأتي MSFT بشيء متعدد المنصات ومفتوح وقابل للحمل. تمامًا كما فعلوا مع .Net Core ، و Blazor ، وما إلى ذلك ... لن تذهب Reinvent UWP / XAML إلى أي مكان.

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

مثلما فعلت MSFT مؤخرًا مع Chromium باعتباره جوهر Edge ، أعتقد أن WinUI (أو أيًا كان الاسم الذي أصبح عليه) يمكن أن تستفيد من Skia حيث أن لها خلفيات خلفية لـ GL و DX و Vulkan و Software Rendering و FB وما إلى ذلك ... فقط بالبدء بـ أن لديك إمكانات هائلة لإضافة منصات أخرى لاحقًا ...

galvesribeiro ،

انظر إلى Flutter ... إنه يحتوي على محرك أساسي يمكنه عرض أي شيء على أي نظام أساسي يدعمه.

علاوة على ذلك ، يحتوي على مكونات يتم تنفيذها بالكامل على Dart باستخدام الطبقة المُدارة للمحرك والتي تمثل (السحب / التصيير) بدقة بكسل النظام الأساسي ولغة التصميم التي تريد استخدامها على سبيل المثال ، Material.io و Apple's Cupertino.

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

MarkIngramUK هذا هو العمل على الفريق لدعم التحديثات.

تمامًا مثل فريق Xamarin الذي يقدم تحديثات من اليوم 0 + 1 ، يمكن لهذا الفريق أن يفعل الشيء نفسه. يقوم فريق Google بذلك أيضًا ...

باستخدام عنصر التحكم "الأصلي" ، ستعود مرة أخرى إلى عالم Xamarin كما فعلت فقط ، أغلفة (تُعرف أيضًا باسم Renders) ...

نحن لا نناقش ارتباطات C # بعناصر التحكم الأصلية (كما يفعل Xamarin) ... نحن نتحدث عن إطار عمل كامل لواجهة المستخدم كما تفعل مع Flutter ...

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

إذا كنت مهتمًا جدًا بالظهور دائمًا كمكوِّن أصلي ، فمن المحتمل ألا يحظى تطبيقك أبدًا بجمهور جيد كما سيبدو ... مه ...

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

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

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

أنا فقط أوضح لماذا لا يجب أن يكون WinUI مجرد بديل Win32 ، هذا كل شيء.

إذا كان هذا هو الحال ، فأنا متأكد من أنه سيقع في المستقبل المنظور تمامًا مثل UWP ...

أوافق MarkIngramUK يجب أن تركز WinUI نفسها على توفير واجهة مستخدم موحدة لنظام التشغيل Windows ، بغض النظر عما إذا كنت تستخدم C # أو WinRT APIs أو Win32 ABIs أو C ++ أو F # أو VB أو .NET Core.

يتضمن WinUI 3.0 إزالة كل هذه التعليمات البرمجية وعرض XAML من نظام التشغيل Windows ، وجعله إطار عمل مستقل عن دورة تحديث نظام التشغيل ، وجعله مفتوح المصدر.

كيف يتم رفعه وإعادة تعبئته لا يزال في الهواء. فقط أولئك الداخليون في Microsoft يعرفون كيف سيفعلون ذلك. من أجل دعم الدعم المستقبلي عبر الأنظمة الأساسية لـ XAML ، آمل فقط أن يتم التفكير في كيفية تحقيق ذلك في المستقبل ، حيث يقومون بإخراجها من Windows.

NET Core متاح بالفعل على منصات أخرى. إذن هذا هو رمز C # الموجود خلف قابل للتحويل بالفعل. إنها الآن فقط XAML وواجهة المستخدم وعناصر التحكم ، والتي تحتاج إلى مسار إلى iOS / macOS / Android / Linux (وأي شيء قد يأتي في المستقبل)

ربما خارج نطاق WinUI 3.0 ، لكنه مرتبط بالتأكيد بهذا المشروع والجهد.

jesbisterrajobstjevansaks

ما خطط Microsoft لجلب إطار عمل UI إلى .NET Core يتم عرضه على سطح المكتب والجوال (Droid و iOS) والويب؟
وقد استمر عدم اليقين بشأن هذا الأمر لفترة طويلة جدًا.

weitzhandler ، لديهم بالفعل خريطة طريق ، مع الفقرة التالية:

هدف Windows أصلي للويب وأطر العمل عبر الأنظمة الأساسية
تم تحسين WinUI 3 بشكل أفضل للمكتبات والأطر للبناء عليها .
على سبيل المثال ، نحن نخطط لتأسيس تطبيق C ++ React Native Windows الجديد عالي الأداء على WinUI 3.

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

حسنا إذا...

/me keep working on FluSharp

وهو أمر معقول ، لكنني لا أعتقد أنه يجب أن يكون هذا المشروع.

إنه عطشان بالخارج MarkIngramUK ، عفواً عن توقعاتنا. 😅

بالفقرة التالية

لا يقول الكثير. لا يكشف عن نية MS الواضحة لجعل C # و .NET Development xplat. ربما يُقال أن HTML JS & CSS shi {هي معدات أفضل بالنسبة لك من C # إذا كنت تريد أن تكون محمولاً.

في الوقت الحالي ، تمثل Xamarin و Xamarin Forms قصة Microsoft لتطوير C # و .NET Core خارج Windows.

React Native for Windows قادم لرمز Javascript وواجهة مستخدم Native (والتي ستستخدم WinUI 3.0 XAML)

في الوقت الحالي ، ليس لدى Microsoft أي خطط معلنة لجلب WinUI 3.0's XAML إلى منصات أخرى.

WinUI يحاول المشروع توحيد إطارات Win32 و WPF و MFC و UWP و .NET Core dev ، ضمن إطار عرض XAML حديث واحد.

أعتقد أنه بعد ذلك ، يجب أن يبدأ العمل في إيجاد طرق لجعل XAML مكتوبًا لـ WinUI 3.0 - على منصات مثل macOS و iOS و Android وما إلى ذلك - ولكن هذا ليس على جدول الأعمال حتى الآن.

بمجرد بدء عمل WinUI 3.0 هنا ، سيكون مفتوح المصدر ، مما يجعل العمل عبر الأنظمة الأساسية المستقبلية ممكنًا في المستقبل ، إذا كانت هناك حاجة كافية لذلك. وقد لا تكون Microsoft هي التي أتاحت هذه المسارات عبر الأنظمة الأساسية في النهاية ، فقد يكون مجتمع المصدر المفتوح.

أي خطط لجعل F # ، ابن الزوج ذو الرأس الأحمر من .NET مواطنًا من الدرجة الأولى؟ ثم يتساءل الناس لماذا لا تلمس الغالبية العظمى من مطوري .NET F # بعمود يبلغ طوله عشرة أقدام.

في الوقت الحالي ، تمثل Xamarin و Xamarin Forms قصة Microsoft لتطوير C # و .NET Core خارج Windows.

نعم ، Xamarin.Forms يتم نقلها إلى macOS و GTK و UWP و WPF ، بالإضافة إلى وجود تصميم مادي في كل مكان في الأعمال ، مما يجعله فعليًا .NET UI Framework ، ولكنه بطيء جدًا وعربات التي تجرها الدواب ، وأتساءل عما تفكر فيه Microsoft عن مطوريها. مجرد إلقاء نظرة على قائمة القضايا! بمجرد أن يبدأ التطور الجاد ، يتم ضرب الحشرات إلى اليسار واليمين. آمل مع WinUI أن نتمكن أخيرًا من الحصول على تجربة تطوير أفضل.

رد: F #

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

نعم ، دائمًا ما يتم تتبع F # بشكل منفصل ويتم تجاهله مرة أخرى. ما عليك سوى إلقاء نظرة على UWP و .NET Native - كلاهما لم يكن في الاعتبار F # وكان على المجتمع ككل اكتشاف كل شيء. 🙄 بعد 4 سنوات ، لا يزال F # غير مدعوم على .NET Native.

بالنسبة إلى اقتراحات / أسئلة F # ، قمت بإنشاء مشكلة مخصصة:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

لا تتردد في توجيه مناقشات F # هناك.

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

RE: واجهة مستخدم عبر الأنظمة الأساسية:

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

فقط لإعادة التأكيد على خريطة الطريق الحالية وبعض النقاط التي ظهرت:

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

يتمثل أحد أهدافنا الحالية قصيرة المدى في تمكين WinUI من العمل كهدف أصلي للأنظمة الأساسية الأخرى لاستخدامها على Windows: على سبيل المثال ، نحن نعمل أيضًا على ضمان react-native-windows - أداء عالي لتطبيق C ++ React Native لنظام التشغيل Windows - يستخدم WinUI ، ويمكن استخدام عناصر تحكم WinUI لإنشاء طرق عرض أصلية لواجهة المستخدم في تطبيقات React Native.

سأكون صادقًا تمامًا. لدي تطبيق سطح مكتب Windows أصلي كتبته في 2006 على WinForms وما زلت أبيعه عبر الإنترنت اليوم.

ليس لدي أي خطط لترحيل هذا التطبيق إلى WPF أو UWP أو استخدام أي تقنية حصرية لواجهة مستخدم Windows. لا يهمني كيف تبدو العروض التوضيحية لـ Windows مقنعة. إذا قررت العمل على هذا التطبيق مرة أخرى ، فسيكون الإصدار الرئيسي التالي نوعًا من التنفيذ عبر الأنظمة الأساسية التي يمكن تشغيلها على أنظمة MacOS و Linux و Windows.

حاليًا ، من المحتمل أن يبدو هذا مثل Blazor + .NET Core + Electron.

أعتقد أن @ Mike-EEE يقدم بعض النقاط الرائعة. UX / النظام الأساسي الذي يسمح لي بالاستفادة من مهارات C # للوصول إلى أكبر عدد من الجمهور هو التكنولوجيا التي سأختارها على الأرجح.

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

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

في علم الاقتصاد ، تعتبر السلعة سلعة أو خدمة اقتصادية لها قابلية استبدال كاملة أو جوهرية: أي أن السوق يتعامل مع أمثلة السلعة على أنها معادلة أو تقريبًا دون أي اعتبار لمن أنتجها. https://en.wikipedia.org/wiki/Customity

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

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

إنه موقف صعب أن تكون فيه بالتأكيد. لكن الزمن تغير. العالم اليوم مختلف تمامًا عن العالم الذي كان عام 1995. بالطريقة التي أراها ، هناك خياران:

يمكنك توظيف المزيد من الأشخاص لتوسيع هذه المعرفة خارج Windows.

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

تمامًا كما فعل WSL لتشغيل Linux على Windows.

• استخدم معرفة الفريق لجعل GTK يعمل 200 مرة بشكل أسرع.
• استخدم معرفة الفريق لجعل تطبيقات QT تعمل 200 مرة بشكل أسرع.
• استخدم معرفة الفريق لجعل تطبيقات Electron تقدم أسرع من أي نظام تشغيل آخر.

هناك الكثير من العمل الذي يمكن القيام به لتحسين قصة التوافق مع نظام التشغيل Windows عبر الأنظمة الأساسية. لكن الاستثمار في مكدس UX جديد تمامًا ونأمل أن نغير جميعًا (بدون أي قصة عبر الأنظمة الأساسية) يعد رهانًا كبيرًا جدًا. يجب عليك كسر هذه العادة بإنشاء أطر UX جديدة لنظام Windows فقط.

جمعية البناء الخيرية. :حقيبة المال:

: horse_racing:: cowboy_hat_face: ليل ناس إكس - طريق المدينة القديمة (فيلم رسمي) مع بيلي راي سايروس

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

يجب عليك كسر هذه العادة بإنشاء أطر UX جديدة لنظام Windows فقط.

-- ليس فقط هذا. حتى عادة كسر Windows الخاصة بإمكانية نقل XAML الداخلية. WPF و Siliverlight و UWP كلها تعمل على مفترقها الخاص ... هذا النوع من الأشياء يدفع المزيد والمزيد من الأشخاص بعيدًا عن أدوات تطوير Windows بشكل عام والتي أود شخصياً الاستمرار في استخدامها في المستقبل. كلما زاد الضغط من أدوات تطوير Windows ، كلما قلت أهمية C # وأقلها ، وبالنسبة لي هذا ما يهمني عندما أنزل إليه.

RE: واجهة مستخدم عبر الأنظمة الأساسية:

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

أضف +1 لفكرة تحديث المظهر المرئي لعناصر تحكم WinForms و MFC و WPF التي تعمل مع WinUI 3.0 لمطابقة أنماط التحكم Fluent / FabricWeb بشكل أفضل.

تأكد من اختلاف أحجام التحكم (أي شيء ليس WinRT XAML يجب أن يتطابق على الأرجح مع مقاييسها مع الإصدار المضغوط من عناصر تحكم UWP) ولكن مظهرًا واحدًا متماسكًا ومتناسقًا.

إضافة تبعية WinUI 3.0 إلى WinForms وتغيير عناصر التحكم.

تكتشف تطبيقات WinUI 3.0 WPF وتستخدم Fluent.Light.xaml أو Fluent.Dark.xaml سمات التحكم.

weitzhandler أنا أفهم
آمل أن نحصل على حل قريبًا مع .NET 5 ، والذي سيجلب حلم Universal XAML. يمكن لـ Microsoft XAML الفوز والويب والجوال وسطح المكتب وإنترنت الأشياء.
كاد Silverlight أن يفعل ذلك ، في العديد من حالات الاستخدام .

يجب عليك كسر هذه العادة بإنشاء أطر UX جديدة لنظام Windows فقط.

لن يتم إصدار WinUI 3.0 أبدًا إذا كان علينا الانتظار (تعرض للخطر حتمًا على جميع الأنظمة الأساسية) دعم عبر الأنظمة الأساسية. يجب أن يكون WinUI هو أقل مستوى من إطار عمل واجهة المستخدم على Windows ، وإذا كنت تريد قدرة مشتركة بين الأنظمة الأساسية ، فقم بالبناء فوق ذلك (أو استخدم React Native ، Xamarin ، إلخ).

يجب عليك كسر هذه العادة بإنشاء أطر UX جديدة لنظام Windows فقط.

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

هدفنا الأولي هو:

• إزالة الحواجز التي تحول دون استخدام التقنيات الأصلية الحالية (Windows 10 Xaml UI and Compositor) عن طريق فصلها عن نظام التشغيل وتمكينها من العمل عبر نماذج التطبيقات الحالية (win32 و UWP) واللغات وأطر العمل الأخرى (عبر الجزر) وإصدارات Windows

• تحديث عمليتنا الهندسية لتكون مفتوحة المصدر

لن يتم إصدار WinUI 3.0 أبدًا إذا كان علينا الانتظار (تعرض للخطر حتمًا على جميع الأنظمة الأساسية) دعم عبر الأنظمة الأساسية.

رجل ... إذا كنت تؤمن حقًا بذلك ، فأنت تقصد أن الأطر الناجحة مثل Flutter لا تعمل ...

لا أحب Dart أيضًا ، لكنهم أطلقوا منتجًا جميلًا يتطور ويحصل على جر سريع حقًا.

أشعر بالإحباط لأن WinUI ستصبح مجرد أشياء Windows ...

يحتاج .Net إلى إطار عمل لواجهة مستخدم يتناسب مع روعة قدرات النظام الأساسي المتقاطع .Net Core تمامًا كما حصلنا للتو على الويب مع Blazor (جانب العميل والخادم).

أعتقد أنه في الوقت الحالي ، لا يزال يتعين علينا الاعتماد على الجهود التي يقودها المجتمع.

أتفهم ما يحاول فريقك القيام بهjesbis ... لقد سئم الكثير منا من رؤية واجهة المستخدم على .Net / C ++ / UWP / MFC / Windows وهو شيء يعمل على Windows فقط بينما كل العالم (OFC باستثناء Apple و OSX) يسيرون في الاتجاه المعاكس لتقديم حلول أفضل وأفضل عبر الأنظمة الأساسية للمطورين. كما ذكرت React و Rect-Native (للسجل لا يعجبني أيضًا ، فقط أذكر أنها تتطور).

إذن ما لدينا الآن هو مجرد مبادرات يقودها المجتمع مثل Avalonia أو حتى Uno وأطر أخرى (مثل FluSharp التي أعملها كما ذكرنا) والتي تتطور ببطء شديد لأسباب واضحة ...

اقتراحي هو أنه بدلاً من مجرد رفع XAML والمُنشئ من قاعدة رموز Windows وجعله يعمل بنظام Windows فقط ، للحصول عليه وعمل تجريدات مناسبة حتى يمكن أن يعمل على منصات متعددة. تمامًا كما فعلنا مع .Net Core ، والذي كان في البداية يعمل بنظام Windows فقط ولكن الجهود التي قادها المجتمع جعلته يعمل بسرعة كبيرة على Linux و OSX وحتى على أجهزة ARM ...

(اختراق حتمي على جميع المنصات) دعم عبر الأنظمة الأساسية

لا أعتقد حقًا أن هذا سيكون مشكلة ، نظرًا لأن التصميم عبر الأنظمة الأساسية كان ، ولا يزال دائمًا ، جانبًا رئيسيًا في XAML UI و Fluent Design في UWP. هناك بالتأكيد بعض عناصر التحكم التي يختلف فيها التصميم المرئي بين إصدارات Windows - يتم التعامل مع هذا بسلاسة ، وستحصل على واجهة مستخدم أصلية تتوافق مع نظام تشغيل الجهاز.

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

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

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

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

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

النقطة المهمة هي ... كما هو الحال مع material.io و Cupertino ، يمكننا (ولست مندهشًا إذا لم تكن Google تفعل ذلك بالفعل!) لدينا "السمة" على الرفرفة للغة التصميم بطلاقة ...

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

weitzhandler أنا لا أحب HTML للتطبيقات الأصلية أيضًا. وإلا سأستخدم Electron مع React 😄

أنا فقط لا أكون عاطفيًا هنا ، وأكون عقلانيًا فقط بدلاً من ذلك.

إنني أتطلع حقًا إلى WinUI 3.0 وسأستخدمه على الفور لمشروع سطح مكتب C ++ / WinRT Windows جديد. وآمل أن يقدم الإصدار الرئيسي التالي بعد 3.0 وقت تشغيل محمول لاستضافة تطبيقات WinUI (مثل Flutter runtime). بالنسبة لعدد كبير من تطبيقات LOB والتطبيقات المشابهة لـ Photoshop ، يمكن أن تكون واجهة المستخدم الرسومية هي نفسها في كل نظام أساسي ، ولكن المفتاح هو إعادة استخدام كود المصدر والأداء. وأعتقد أيضًا أن مشروع xlang فكرة رائعة ويعد ببعض الأخبار الجيدة في المستقبل.

أقترح على المستخدمين هنا قضاء بعض الوقت للاستماع إلى Scott Hunter بعد BUILD 2019 حول كيفية تجميع Win UI و Xamarin Form و UNO و Web Assembly معًا.

NET Core 3 وما بعده مع Scott Hunter @ .NET Rock

تم إنشاء كل من نماذج Xamarin (XAML) و UNO (XAML) مع الرؤية عبر النظام الأساسي. في حالة UNO (بالإضافة إلى iOS و Android و XAML للويب عبر Web Assembly).

تم إنشاء UWP بدون رؤية أبعد من نظام Microsoft البيئي ، مثل الويب و Android و iOS. كل جهود تصميم Fluent المثيرة للإعجاب لم تأخذ إلا القليل بسبب التبني البطيء لـ UWP

كما أشار @ Mike-EE ، يمتلك الروبوت و iOS 2 ~ و 1.5 ~ مليار بينما يحتوي Win10 على 0.9 مليار. معظم المطورين لا يزالون مترددين في القفز من WinForm و WPF إلى UWP.

لماذا ا؟ ضوابط UWP ، من التجارية ومايكروسوفت ، غير مكتملة !!!!! مقارنة بتلك الموجودة في WinForm و WPF. لا تبذل Microsoft أي جهد للمساعدة في هذا الانتقال. لن تتناول XAML Island هذا AS LONG AS MICROSOFT به BLIND SPOT لأنه ما ينقص المطورين يحتاجون للانتقال إلى UWP من winForm و WPF.

مع عناصر تحكم UWP المفقودة ، يتم الآن بذل جهد كبير لجلب Win UI إلى React Native for Web. ؟؟؟؟؟؟ نحتاج إلى عناصر تحكم Win UI المفقودة لـ UWP حتى نتمكن من الضغط من أجل الانتقال من WinForm و WPF إلى UWP .

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

==> أفهم الحاجة إلى فصل UWP UI. هذا منطقي فقط لنشر علامة Fluent Design على منصات أخرى مثل iOS و Android و Web.
==> يرجى التركيز على تقديم تحكم أفضل في النماذج ثلاثية الأبعاد وعناصر تحكم الرسم التخطيطي (كلاهما ثنائي الأبعاد / ثلاثي الأبعاد)

من المنطقي فقط البقاء وانتظار NET5 عندما يتم دمج ALL BCL من (mono مع النسخة الأصلية من Windows ، لتجميع الويب وما إلى ذلك) ، لأنني أرى مستقبل HOLOLENS Creative 3D UI.

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

jesbis ، أحثك ​​على وضع المزيد من الأشخاص في USP (نقاط البيع الفريدة) من Win UI لـ UWP.

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

تم إنشاء هذه المشكلة لمناقشة خارطة طريق WinUI 3.0 .

أدلى jesbis ببيان توضيحى :

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

كان أول تعليقين لك حول الموضوع.

الستة التالية عبارة عن مزيج من غير المنتج والازدراء ، وأنت على وشك كسر مدونة قواعد السلوك لـ Microsoft Open Source .

يجب أن تظل هذه محادثة مثمرة ومهنية مع Microsoft.

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

أعتقد أن هناك بعض التعليقات الرائعة هنا ، على الرغم من أنه قد تكون هناك مناقشتان منفصلتان. سأبقيها قصيرة لأن معظمها قيل من قبل.

عبر النظام الأساسي والويب

NET Core رائع. يمكننا أخيرًا استهداف كل منصة ونقطة اتصال بأدوات رائعة ولغة رائعة.
الشيء الوحيد المفقود هو مكدس واجهة المستخدم باستثناء Blazor (تمتص HTML / CSS رغم ذلك). لتحقيق أقصى قدر من المقارنة ، سيكون من الرائع أن يكون لديك إطار عمل يسمح لمطوري سطح المكتب بالانتقال إلى الويب وما بعده بنفس المهارات والأدوات واللغة (Xaml و C #). Tbh ، قام Silverlight بعمل رائع هناك - لقد نجح للتو). لست متأكدًا مما إذا كان WinUI يجب أن يكون هذا الإطار ، ولكن يرجى طرح المشكلة داخليًا. يعد Flutter for .NET devs ، واستهداف الويب أكبر ميزة.

لست متأكدًا مما إذا كان Xamarin هو هذا النظام الأساسي ، ولكن إذا كان الأمر كذلك - فتأكد من محاذاة Xaml قدر الإمكان عبر WinUI و Xamarin.

WinUI

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

HoloLens وما بعده

مع ظهور Lite ، وعوامل شكل جديدة ومثيرة للغاية مثل HoloLens ، يمكن للمرء أن يجادل بأن UWP ليس جاهزًا له من حيث واجهة المستخدم. نعم ، يمكننا تشغيلها على HoloLens ، وهو أمر رائع ، لكني أود أن أرى طريقة لتحسين التطبيقات حقًا للأبعاد الثلاثية دون الحاجة إلى الوحدة الكاملة.

WinUI يتقدم على Xamarin. لكن فريق Microsoft فقط دفع Xamarin 4.0 للخارج ...
أنا شخصياً أحب Xamarin أكثر لأنه يمثل أقل فئة لـ Cross Platform ، وسيزداد عدد التطبيقات الأصلية لـ SaaS في المستقبل.

بخلاف Xamarin ، هناك بعض البدائل.
1) لماذا لا تتبنى منصة UNO وتجعل عرض الويب باستخدام SkiaSharp؟
2) @ zezba9000 أنت بحاجة إلى خلفية عرض

ربما تدفع Microsoft WinUI أكثر ، نظرًا لوجود تتبع رمز غير مفتوح المصدر بداخله بخلاف حل الأنظمة الأساسية الأخرى: قد يكون لدى Xamarin و UNO مكتبات UNIX ...

على أي حال ، قد تكون القوة معك.
ملاحظة: راعي Github من Microsoft ، لذا يرجى رعاية بعض مطوري Mac / Linux المرموقين لـ WPF / Winforms's Cross Platform fork.

jkoritzinsky ، شيء واحد يجب على فريق WinUI الانتباه إليه مع إعادة تسمية WinUI 3.0: إذا قمت بإعادة تسمية أي من الأنواع المعروضة في .NET ، فلن تعمل الإسقاطات (ولا نخطط لإضافة المزيد نظرًا لأنه ليس نظامًا قابلًا للتوسيع يمكن صيانته). فيما يلي قائمة بالأنواع التي نتوقعها: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

ستتطلب أي تغييرات على أنواع مختلفة من هذه الأنواع من المستخدمين التفاف كائناتهم في كائنات جديدة تقوم بتنفيذ الواجهات الجديدة أو نسخ بياناتهم في الأنواع الجديدة. على وجه الخصوص ، تعتبر الأنواع INotifyPropertyChanged و INotifyCollectionChanged ذات أهمية فيما يتعلق بجزر XAML وتوفر دعم المصب.

أوافقك الرأي ويسعدني أنك طرحت هذه المشكلة ، على الرغم من أنني أود أن أضيف أنني أعتقد أن هذه التوقعات هي نوع من الشر المؤسف. نحن لا نتوقع كل واجهة برمجة تطبيقات من المحتمل أن تكون (التفكير في واجهات برمجة تطبيقات System.IO) ، لذلك يجب علينا إما معالجة ذلك ، أو التفكير بشكل مختلف. شيء واحد يتبادر إلى الذهن هو عدم إضافة أنواع متشابهة ، ولكنها مختلفة ، لأنواع .NET في مساحة اسم مختلفة. بدلاً من ذلك ، يجب علينا تمكين مطوري C ++ لدينا أيضًا من استخدام System.ComponentModel.INotifyDataErrorInfo. هذا نوع من ما فعلناه مع C ++ / CLI ، لكن هذا لا يتطلب تحميل CLR لتطبيق C ++ خالص. لا أعرف ما إذا كان ذلك سيكون أكثر إرباكًا ، ولكن يبدو أننا نسرب الاختلافات الأساسية والكامنة في تقنيات .NET و WinRT في طبقة API ، مما يجعل الأمور تبدو غير متماسكة.

@ meir-pletinsky. NET هو إطار عمل واحد فقط يمكنك استخدامه لإنشاء تطبيقات باستخدام UWP XAML. يريدون التحقق من صحة حقل النص المتاح للمطورين ، بغض النظر عن إطار العمل الذي يستخدمونه

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

mdtauk ، لا ، يسمح لك WinUI Desktop (سابقًا Xaml Desktop) باستخدام Xaml مع Win32 مباشرةً ، دون استخدام الجزيرة.

أعتقد أن @ meir-pletinsky كان يشير إلى .NET / C ++ ، إلا إذا فاتني شيء ما؟

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

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

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

أضف +1 لفكرة تحديث المظهر المرئي لعناصر تحكم WinForms و MFC و WPF التي تعمل مع WinUI 3.0 لمطابقة أنماط التحكم Fluent / FabricWeb بشكل أفضل.

تأكد من اختلاف أحجام التحكم (أي شيء ليس WinRT XAML يجب أن يتطابق على الأرجح مع مقاييسها مع الإصدار المضغوط من عناصر تحكم UWP) ولكن مظهرًا واحدًا متماسكًا ومتناسقًا.

إضافة تبعية WinUI 3.0 إلى WinForms وتغيير عناصر التحكم.

تكتشف تطبيقات WinUI 3.0 WPF وتستخدم Fluent.Light.xaml أو Fluent.Dark.xaml سمات التحكم.

لا أريد حقًا أن أرى MS يستثمر الوقت والموارد في تلك الأطر لجعلها تبدو مثل تطبيقات Windows 10 الأصلية. لهذا السبب سيكون هناك WinUI 3.0. هل تريد مظهر وأسلوب Windows 10 في تطبيقات WPF / WinForms؟ استخدم WinUI 3.0.
يجب أن تستثمر MS مواردها في سد الفجوات الموجودة (ومنعها) بين UWP / WinUI ونظيراتها من Win32 ، بدلاً من إعادة زيارة الأطر القديمة. خاصة وأن المقصود من WinUI أن يصبح إطار العرض التقديمي لنظام Windows ...

أرغب في طلب توضيح حول WinUI ونوايا Microsoft بشأن UI / UX:

1. هل يحل WinUI محل كل ما يلي (افتراضيًا؟): Win32 و ATL و MFC و WinForms و Silverlight (أعرف) و WPF و UWP و / أو جزر XAML؟ أدرك أن هذه التقنيات ستستمر في الوجود ، وسيستمر دعمها لبعض الوقت غير المحدود ؛ أريد فقط أن أفهم بوضوح أن هذا ما تقوله Microsoft هو "الطريق إلى الأمام" ، وأنه (على سبيل المثال) ، يجب أن نعتبر WinForms و WPF كما نعتبر Win32 أو MFC.

2. هل WinUI مشتق من UWP؟ (أو ، ما مدى تشابه الاثنين؟) ما مدى تشابه (أو اختلاف) WinUI مقارنةً بـ UWP أو جزر XAML أو WPF؟

بصفتي مطورًا محترفًا لـ C # و C ++ ، بدأت العمل مع WinForms ، ثم انتقلت إلى WPF ، ثم عدت إلى WinForms لمجرد أنني أستطيع تصميم UI / UX للأغراض التجارية في WinForms تقريبًا أسرع مرتين مما يمكنني في WPF. أعطى WPF قدرًا أكبر من المرونة والأداء وبدا أفضل بكثير - لكن تشويه XAML الذي حدث بمجرد لمس أحد الأشخاص للواجهة عبر المصمم بدلاً من تحرير XAML يدويًا كان فظيعًا. في بعض الحالات ، أعتقد أن WinForms (باستخدام المصمم) كانت أوامر من حيث الحجم أسرع من الإنشاء اليدوي لنموذج XAML أو عنصر تحكم مشابه.

أنا شخصياً أحب أن تكون واجهة المستخدم متوفرة ومتطابقة عبر منتجات Microsoft. قد يعني إطار العمل الذي يمكن الاستفادة منه بواسطة Win32 أو .NET بطريقة مماثلة تطبيقات متسقة وحديثة المظهر لجميع مطوري Microsoft ، ويعني أيضًا أنه يمكن حل الأسئلة والمشكلات الشائعة في الجلسات التي تستهدف تقنية واحدة - على سبيل المثال ، عند طرح سؤال حول عنصر تحكم ، ستكون الإجابة متطابقة (إن لم تكن متطابقة تقريبًا) لمطور Win32 أو مطور .NET. هذا من شأنه أن يجعل تعلم "WinUI" مفيدًا لأي من المكدس لأي مطور معين ، كما أنه سيجعل الوصول إلى المعلومات عبر الإنترنت (StackOverflow ، إلخ) أكثر قيمة ، بغض النظر عن المكان الذي تقوم بتطويره. على الرغم من أنني لا أستخدم Xamarin ، إذا كان من الممكن جعل Xamarin يتبع هذه الخطوات (كامتداد لـ WinUI؟) ، فيمكن تطبيق البيان أعلاه ليس فقط على مطوري Windows ، ولكن أيضًا على أولئك الذين يستهدفون Android و iOS وما إلى ذلك.

ما نوع التطبيقات التي سأكون متحمسًا لاستخدام WinUI لها؟

إذا كان فهمي لـ WinUI صحيحًا ، وهو "الطريق إلى الأمام" ، واستبدال Win32 ، و MFC ، و Forms ، و WPF ، وما إلى ذلك ، وكان نفس الإطار متاحًا للتطوير الأصلي أو .NET ، فسأستبدل التكوين بشغف في _ ALL _ التطبيقات التي أدعمها. واجهات مستخدم حديثة ومتسقة ، تعمل (وتتصرف) بنفس الطريقة بغض النظر عن النظام الأساسي أو المكدس؟ أليس هذا ما نريده جميعًا؟ لا أعتقد أن أي شخص يريد أن يتذكر كيفية كلاً من CreateWindowEx () وتشغيل حلقة الرسائل لإرسال الأحداث في Win32 أثناء معالجة الأحداث بطريقة منفصلة تمامًا في WinForms أو WPF. حان الوقت لشيء "حديث". آمل حقًا أن يكون هذا هو WinUI (3.0).

التوافق مع أنظمة التشغيل ودعم المستوى الأدنى

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

هل جعل WinUI قابل للربط بشكل ثابت أو قابل للتضمين (مثل .NET Core / 5) خيارًا؟ سنضطر إلى استهداف Windows 8.1 و Windows 8 و Windows 7 - حتى Windows PE. كيف يمكننا استخدام WinUI مع هذه المتطلبات؟

shidell :

هل WinUI مشتق من UWP؟ (أو ، ما مدى تشابه الاثنين؟) ما مدى تشابه (أو اختلاف) WinUI مقارنةً بـ UWP أو جزر XAML أو WPF؟

سيكون WinUI 3.0 الإصدار التالي من مكونات النظام الأساسي لواجهة المستخدم لنظام التشغيل Windows 10 / UWP ، بما في ذلك نظام Xaml الأساسي والتكوين والإدخال. إنها تأتي من قاعدة البيانات تلك.

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

هل يحل WinUI محل كل ما يلي (افتراضيًا؟): Win32 و ATL و MFC و WinForms و Silverlight (أعرف) و WPF و UWP و / أو جزر XAML؟ أدرك أن هذه التقنيات ستستمر في الوجود ، وسيستمر دعمها لبعض الوقت غير المحدود ؛ أريد فقط أن أفهم بوضوح أن هذا ما تقوله Microsoft هو "الطريق إلى الأمام" ، وأنه (على سبيل المثال) ، يجب أن نعتبر WinForms و WPF كما نعتبر Win32 أو MFC.

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

ستكون جزر Xaml جزءًا من WinUI ، وتمكنك من استخدام WinUI لإنشاء طرق عرض جديدة في التطبيقات الحالية (مثل WPF و WinForms).

ما هو النقاش الدائر حول جعل WinUI متاحًا للمنصات القديمة التي تتجاوز 1703 ، والتي أعتقد أنها أقدم منصة مستهدفة حاليًا؟
هل جعل WinUI قابل للربط بشكل ثابت أو قابل للتضمين (مثل .NET Core / 5) خيارًا؟ سنضطر إلى استهداف Windows 8.1 و Windows 8 و Windows 7 - حتى Windows PE. كيف يمكننا استخدام WinUI مع هذه المتطلبات؟

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

رائع - يبدو أن WinUI هو "الطريق إلى الأمام" ، وبالنظر إلى هذا الفهم له ، فإن القول بأنني متحمس سيكون أقل مما ينبغي.

على وجه الخصوص ، أعتقد أنه من الرائع أن تسمح XAML Islands للمطورين بتوسيع WinUI إلى التقنيات القديمة ، مثل WPF و WinForms. هذا جسر رائع "للأمام" أثناء العمل على / تمديد المشاريع القديمة.

رائع - يبدو أن WinUI هو "الطريق إلى الأمام" ، وبالنظر إلى هذا الفهم له ، فإن القول بأنني متحمس سيكون أقل مما ينبغي.

على وجه الخصوص ، أعتقد أنه من الرائع أن تسمح XAML Islands للمطورين بتوسيع WinUI إلى التقنيات القديمة ، مثل WPF و WinForms. هذا جسر رائع "للأمام" أثناء العمل على / تمديد المشاريع القديمة.

أود أن أفكر فيما إذا تم إنشاء مشروع WinForms أو MFC أو WPF مع تضمين WinUI 3.0 - يمكنهم فقط عرض صفحات / محتوى / نوافذ XAML دون الحاجة إلى استخدام جزيرة XAML في نموذج / نافذة WPF / نافذة HWND.

إن القدرة على استخدام XAML الخالص فقط ، أو استخدام جزيرة لوضع XAML في الأسطح المتوفرة في إطار العمل - ستجعل حقًا WinUI 3.0 "واجهة المستخدم الواحدة للسيطرة عليهم جميعًا"

سيجعل WinUI 3.0 حقًا "واجهة المستخدم الواحدة التي تحكمهم جميعًا"

... على نظام التشغيل Windows. 😉

سيكون WinUI 3.0 الإصدار التالي من مكونات النظام الأساسي لواجهة المستخدم لنظام التشغيل Windows 10 / UWP ، بما في ذلك نظام Xaml الأساسي والتكوين والإدخال. إنها تأتي من قاعدة البيانات تلك.

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

تم إجراء محاولة ، بالطبع ، لكنها في تنفيذ برنامج WPF على الرغم

بالإضافة إلى ذلك ، فإن قدرًا كبيرًا من الخدمات التي كانت متوفرة في ترميز WPF لا يزال متاحًا وتنفيذها في UWP. هل الجهد المبذول هنا للتأكد من أن ترميز WinUI 3.0 الجديد المستند إلى UWP سيكون دقيقًا تمامًا مع WPF؟ أعتذر إذا تم شرح ذلك في مكان ما ، ولكن لا يزال يتعين علي تحليل الرسائل لمشاهدتها (وأرحب بأي موارد لتصحيح / استكمال فهمي).

سيجعل WinUI 3.0 حقًا "واجهة المستخدم الواحدة التي تحكمهم جميعًا"

... على نظام التشغيل Windows. 😉

على الأقل بالنسبة لنافذة إصدار WinUI 3.0. آمل أن تكون هذه بداية عملية لإحضار عرض XAML إلى الأنظمة الأساسية الأخرى ...

أتساءل عما إذا كان بإمكانك التحدث عن كيفية التكامل بين WPF و UWP. على وجه الخصوص ، مع مفاهيم مثل امتدادات الترميز التي كنا نطلبها في UWP لسنوات حتى الآن ، مع نجاح ضئيل للغاية. [...] هل الجهد المبذول هنا للتأكد من أن ترميز WinUI 3.0 الجديد المستند إلى UWP سيكون دقيقًا تمامًا مع WPF؟

@ Mike-EEE الإخلاص الكامل مع WPF ليس هدفًا لـ 3.0. ومع ذلك ، فإننا نتتبع عددًا من عناصر العمل لسد الفجوات بمرور الوقت (على سبيل المثال ، تحسينات امتداد الترميز # 741 - يرجى إلقاء نظرة وترك تعليق حول ما إذا كان هذا سيلبي احتياجاتك!) والاستمرار في توسيع WinUI إلى ما بعد WPF (على سبيل المثال # 686 دعم نموذج ثلاثي الأبعاد).

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

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

أعتقد أن قلقي الكبير هو ما إذا لم يكن الإخلاص الكامل لـ WPF هدفًا ، أثناء استخدام WinUI داخل WPF _is_ ، فإنك ستواجه احتكاكًا مع اعتماد WPF ، نظرًا لأنه يحتوي على نموذج Xaml المتفوق (والأصلي).

أي أنه لا يبدو أن هناك عرضًا واضحًا للقيمة لدمج WinUI3.0 في WPF ، بنفس الطريقة التي لا تمتلك بها Xaml Islands عرضًا واضحًا للقيمة. في نهاية اليوم ، يبدو أنك تحاول إدخال نموذج Xaml متراجع / أدنى / متخلفًا إلى نموذج Xaml الراسخ والمتفوق ، والذي ببساطة لا معنى له.

بالنسبة لحالات الاستخدام في WinForms و MFC وما إلى ذلك ، نعم ، هذا الأسلوب مناسب لـ WinUI3.0. ومع ذلك ، مع WPF ، فإنه يحتوي على نموذج عرض تقديمي متميز ونموذج مطور / مصمم لم تتم مطابقته بأي مبادرة أخرى من قبل MSFT أو البائعين الخارجيين.

@ Mike-EEE استنادًا إلى حديث سكوت هانتر ، يبدو لي ، والذي قد يكون خاطئًا ، أن هدف "ONE BCL To Rule them all" يأتي في أولوية أعلى من "One UI للحكم عليهم جميعًا".

من خلال استبدال MONO الأساسي Xamarin Forms XAML و UNO XAML في الويب من خلال تجميع الويب باستخدام BCL مشترك يحتوي على AoC ، فإن التطبيقات المستندة إلى Xamarin Forms XAML و Uno XAML على الويب ستستفيد من أداء السرعة.

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

نأمل ، في هذه الرحلة نحو .NET5 = BCL مشترك للحكم عليهم جميعًا ، يتم الاهتمام بتوحيد XAML ، جزئيًا أو كليًا ، على طول العملية ، ولكن ليس الهدف الرئيسي لـ .NET5.

أولوية أخرى على رأس الحاجة إلى توحيد XAML هي نشر علامة Microsoft التجارية من خلال التصميم السلس لجميع الأنظمة الأساسية (الأجهزة المحمولة وسطح المكتب والويب). [من الناحية الفنية ، الفصل من خلال Win UI 3.0 ، والذي يُطلب منا مرارًا وتكرارًا التركيز على الغرض من خارطة طريق WinUI 3.0]

في النهاية ، مقدار UWP ، الذي نشأته Win UI ، يلعب دورًا فعليًا في هذا BCL واحد للسيطرة عليهم جميعًا بحلول NOV2020 عند إصدار .NET5 ، ليس أيضًا هدفًا ذا أولوية عالية من وجهة نظري.

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

هذه هي الطريقة التي أرى بها استراتيجية Microsoft طويلة المدى "لمواكبة الحصة السوقية" بسبب قلة وجود الأجهزة المحمولة.

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

آسف يا رفاق ، أواصل دفع هذا لأنني أرغب في استخدام الوقت المحدود المتاح لي في أفضل التقنيات. :-)

فيما يتعلق بفترة انتقال WinUI 3.0

أود أن أقترح أن تعمل Microsoft مباشرةً مع مشرفين على مجموعة أدوات مجتمع Windows (بعضهم يعمل مع MS) من أجل:

1. اختبر لمعرفة ما إذا كانت هناك أي حواجز غير متوقعة أثناء إعادة توجيه مجموعة الأدوات إلى WinUI 3.0 (بما في ذلك نموذج التطبيق).
2. اختبر إعادة تسمية مساحة الاسم تلقائيًا عبر Visual Studio أو "أداة أخرى" لمعرفة مدى سلاسة الأمر.
3. قم بالإبلاغ علنًا عن كيفية سير العملية (منشور مدونة / مشكلة GitHub / أي شيء تريده).
4. قم بتوفير نسخة ولصق جزء من النص حول WinUI 3.0 والانتقال الذي يمكن لمسؤولي المشروع إلحاقه بـ GitHub / Nuget / الملف التمهيدي الآخر ، أو على الأقل عنوان URL يحتوي على معلومات موجزة حول هذا الموضوع. سيساعد هذا بسرعة على زيادة سرعة أي مستخدمين لهذه المشاريع على WinUI 3.0 ، وشرح ما سيحتاجون إلى القيام به لإكمال الانتقال.
5. حدد الخطوط العريضة لعملية الانتقال المقترحة والجدول الزمني الذي يمكن لمسؤولي المشروع / المكتبة اختيار اعتماده.

فيما يتعلق بالعنصر الأخير ، يجب أن يغطي هذا اقتراحات مثل:

• قم بإنشاء رقم إصدار رئيسي جديد يشير إلى أنه سيتم استخدامه مع تطبيقات WinUI 3.0 (مثل WCT v6.0).
• اختياريًا (؟) قم بإنشاء فرع لاحتواء الكود القديم الذي سيدعم المشاريع التي لم يتم تحديثها إلى WinUI 3.0 حتى الآن.
• قم بتوفير فترة زمنية (على سبيل المثال ، 3/6/12 شهرًا) يتم خلالها تقديم الدعم للمشاريع القديمة (مثل دمج إصلاحات الأخطاء وما إلى ذلك من الفرع الرئيسي). من المحتمل أن يكون لهذا تواريخ محددة "لمزامنة" فترة الدعم عبر مشاريع / مكتبات المجتمع.

أخيرًا ، أشعر أنه سيكون من المهم تحديد ما يمكن القيام به إذا كنت بحاجة إلى دعم Windows 10 الإصدار 1507 و 1607 LTSB. هذان هما الإصداران الوحيدان المدعومان من W10 اللذان سيكونان في البرية ولن يكون WinUI 3.0 متوافقًا معه في وقت الإصدار.

في الأصل ، كنت أقترح اختبار العملية باستخدام Windows 10 Calculator ، نظرًا لأنه تطبيق مفتوح المصدر بجودة الإنتاج. ومع ذلك ، أدركت بعد ذلك أن هذا التطبيق يحتاج إلى العمل على 1507 و 1607 LTSB لمدة 6-7 سنوات أخرى. من الواضح أنه سيكون هناك بعض الخلاف حول دعم هذه الأنواع من التطبيقات ، خاصة عندما يتعلق الأمر بالمشاريع المجتمعية الصغيرة. إذا كانوا يحتاجون حقًا إلى هذا الدعم ، فيجب توفير استراتيجية واضحة طويلة الأجل لكيفية القيام بذلك.

بخصوص WinUI 4.0 / 3.x / vNext

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

نظرًا لأن معظم هذه العناصر خارج نطاق الإصدار 3.0 ، أشعر أنه يجب إنشاء مشكلة جديدة عاجلاً وليس آجلاً لبدء جمع تعليقات المجتمع على WinUI 4.0 / 3.x / vNext. إذا كان هناك أي شيء ، فسيساعد ذلك في تحديد كل من أنواع العمل التي يفكر فيها فريق WinUI ، وما هو خارج نطاق WinUI و / أو مسؤولية فرق MS الأخرى.

مثال على النقطة الأخيرة - أود حقًا رؤية هذه الأشياء:

• دعم .NET Core 3.0 لمشاريع UWP (مسؤولية فريق .NET ، كما أفهمها)
• الدعم الكامل لتطبيقات Windows (UWP و Win32) من مركز تطبيقات Visual Studio (من الواضح أنه ليس شيئًا مسؤولاً عن فريق WinUI)
• إرشادات أكثر واقعية عن تصميم Fluent Design ، على غرار ما تجده في مستندات التصميم متعدد الأبعاد (مرة أخرى ، مسؤولية الفريق المنفصلة)
• استخدام WinUI 3.0 و Fluent design في تطبيقات W10 المضمنة (تحتاج الفرق المنفصلة وبعض هذه التطبيقات إلى دعم إصدارات LTSB)

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

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

سيكون من الرائع لو أن F # سيحصل على دعم متكافئ مع C # ، على سبيل المثال وجود نفس قوالب المشروع مثل C #.

أود أن يكون لـ WinUI (UWP vNext) كائن Window مناسب مثل WPF ، مع أساليب Top و Left و Width و Height و StartupPosition و IsTopMost و AllowTransparency و Show () / ShowDialog ().

(_لست متأكدًا من كيفية عمل هذه النافذة (أو السماح بها) على الأجهزة ذات الشاشات الصغيرة ، مثل الهواتف المحمولة و IoT_)

TonyHenrique ، هناك واجهة برمجة تطبيقات جديدة UWP في عام 1903 ، لكنها بعيدة عن الانتهاء.

يبحث مرة أخرى في عرض XAML ضمن نطاق WinUI 3.0.

الأشياء التي أشعر أنها خطوة إلى أسفل من تقديم WPF هي:

• لا يستخدم النص ClearType ، بل يفضل بدلاً من ذلك تنعيم التدرج الرمادي ؛
• عدم وجود دقة البكسل لأشياء مثل حدود الحدود ؛

يمكنني أن أفهم متى كان على Windows Phone 7 و Windows Phone 8 مشاركة نظام عرض - كان نوع تقنية الشاشة وسرعة العرض يدفعان نحو أن يكونا أكثر أداءً. ولكن مع تمحور WinUI على سطح المكتب أولاً ، والشاشات الأكبر - ربما حان الوقت لاستعادة هذه الصفات إلى محرك XAML Render.

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

ماذا عن f # template؟

ما لم يعمل خارج الصندوق في نماذج Windows القياسية وقوالب مشروع WPF التي تستهدف .NET Framework 4.5 أو أحدث ، لا يمكننا اعتماد مكتبة WinUI.

إن طلب أحدث إصدار من نظام التشغيل Windows 10 و / أو تطبيق UWP هو أمر أساسي لاعتماد التصميم السلس.

أود أن أقترح أن تعمل Microsoft مباشرة مع مشرفين على Windows Community Toolkit (بعضهم يعمل مع MS)

تضمين التغريدة
اقتراح رائع! هذا بالتأكيد في الخطة. غالبًا ما يعمل فريقنا بشكل وثيق مع مسؤولي صيانة Windows Community Toolkit وهو أحد الأشياء التي نرغب في استخدامها كمشروع اختباري.

يبحث مرة أخرى في عرض XAML ضمن نطاق WinUI 3.0.

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

ماذا عن f # template؟

edgarsanchez ،khoshroomahdi
يبدو أننا نحظى باهتمام كبير بـ F #! نود أن نسمع المزيد عن سبب رغبتك في F #: لا تتردد في التعليق في قضية F # حول سبب رغبتك في ذلك وما الذي ستستخدمه من أجله: # 740

ما لم يعمل خارج الصندوق في نماذج Windows القياسية وقوالب مشروع WPF التي تستهدف .NET Framework 4.5 أو أحدث ، لا يمكننا اعتماد مكتبة WinUI.

تضمين التغريدة
هل بحثت في جزر Xaml؟ تتيح لك هذه الميزة استخدام WinRT Xaml في تطبيقات WPF و Windows Forms حتى تتمكن من البدء في تحسينها باستخدام طرق عرض / صفحات Xaml الحديثة:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

نحن نخطط لـ WinUI 3.0 لتضمين الجزر وأن تكون متوافقة مع الإصدارات السابقة لتحديث Creators والإصدارات الأحدث ، والتي هي على الأقل الإصدارات الخمسة الأخيرة من Windows.

هل يمكن أن تعمل Xaml Islands على تحديث Creators والإصدارات الأحدث باستخدام WinUI 3.0 لتلبية احتياجاتك؟

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

فعل # 768

تتطلب جزر XAML الإصدار 1903 من Windows 10 وتتطلب مكتبة Windows Community Toolkit أن يكون المشروع UWP. هذا لا يذهب.

تتطلب جزر XAML الإصدار 1903 من Windows 10 وتتطلب مكتبة Windows Community Toolkit أن يكون المشروع UWP. هذا لا يذهب.

لن ينتقل WinUI 3.0 إلى Windows 7/8 / 8.1 - ولكن أنظمة التشغيل هذه ستصل إلى نهاية عمرها قريبًا جدًا. ولا يزال بإمكانك استخدام WPF و WinForms لهؤلاء في الوقت الحالي. هذا عندما ينتقل المستخدمون لديك إلى Windows 10

في هذه الحالة سيكون المشروع هو UWP لنظام التشغيل Windows 10 ، لذلك لا فائدة من دعم WPF / WinForms. هذا مجرد تحرك في دائرة وتفتيت أدوات المطور.

jozefizso أكثر دقة للقول إن UWP يتغير للسماح له بأن يكون مثل WPF و WinForms ، وتقترب واجهة مستخدم XAML من منصات WPF و WinForms.

تطبيقات UWP مع XAML UI الحديثة تخرج من وضع الحماية التقييدي ، وقادرة على الاتصال بمنصات WPF و WinForms.

هذه هي الطريقة التي أفهمها.

تتطلب جزر XAML الإصدار 1903 من Windows 10

في هذه الحالة سيكون المشروع UWP لنظام التشغيل Windows 10

باستخدام WinUI 3.0 ، نخطط لإتاحة الجزر في عام 1703 وما بعده (في السابق كثيرًا).

نحن نعمل أيضًا على جعل WinUI قابلاً للاستخدام مع نموذج تطبيق Win32 بدلاً من UWP (يُطلق عليه بشكل غير رسمي "WinUI desktop") ، لذلك لن يكون بالضرورة أحد تطبيقات UWP.

نحن نعمل أيضًا على جعل WinUI قابلاً للاستخدام مع نموذج تطبيق Win32 بدلاً من UWP (يُطلق عليه بشكل غير رسمي "WinUI desktop") ، لذلك لن يكون بالضرورة أحد تطبيقات UWP.

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

نحن نعمل أيضًا على جعل WinUI قابلاً للاستخدام مع نموذج تطبيق Win32 بدلاً من UWP (يُطلق عليه بشكل غير رسمي "WinUI desktop") ، لذلك لن يكون بالضرورة أحد تطبيقات UWP.

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

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

سيكون WPF أكثر تعقيدًا بعض الشيء لمجرد استخدام WinUI XAML في مكانه - ولكن على الأقل يمكن تصميم عناصر تحكم WPF لمطابقة عناصر WinUI

1. يجب إعادة تسمية مساحة الاسم. "Xaml" غير مناسب لأن Xaml يشير إلى لغة ترميز ، والتي يتم استخدامها بشكل غير صحيح كلغة تسويق (والتي تتغير غالبًا) لمكونات UWP الأصلية. يجب استبدال "Xaml" بـ "WinUI". يمكنك معرفة مقدار الالتباس الذي يحدث حتى في هذا الموضوع ، حيث غالبًا ما يكون من غير الواضح ما إذا كان "Xaml" يشير إلى لغة .xaml أو إلى مكونات واجهة المستخدم.
2. بقدر ما يقترب هذا من WPF و UWP من بعضهما البعض ، فهذا جيد. لكل منهما ميزات غير موجودة في الآخر ، ومن المنطقي أن يكون لديك "واجهة مستخدم Windows" تجمع بين الاثنين. قد يكون هناك بعض الازدواجية في الميزات ولكن يمكن أن يكون هذا أيضًا مسارًا انتقاليًا WPF -> UWP.
3. يعد الفصل عن إصدارات Windows أمرًا منطقيًا ، ولكن لا بأس أيضًا في افتراض تحديث Win10 نسبيًا ، نظرًا لأن Win7 سيكون قد تجاوز EOL بشكل جيد عند انتهاء هذا العمل.

Xaml هو اسم إطار عمل واجهة المستخدم. ومن ثم Windows.UI.Xaml ...

Xaml هو اسم إطار عمل واجهة المستخدم

كانت Xaml عبارة عن تقنية في WPF مكنت المطورين من وصف وبناء ليس فقط مشاهد العرض داخل تطبيقاتهم ، ولكن التطبيقات نفسها. بمعنى ، يمكنك وصف عناصر واجهة المستخدم _ بالإضافة إلى POCOs_. إذا كانت .NET ، فيمكن وصفها بشكل غني باستخدام Xaml وتحميلها في سياق التطبيق.

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

لقد انتهيت شخصيًا من استخدام Xaml لوصف تكوين التطبيق بالكامل ، وإزالة واستبدال تعقيد App.config - ونعم ، حتى Web.config - إلا في حالات واجهات برمجة التطبيقات الخارجية التي تتطلب ذلك تمامًا.

Xaml هو _not_ UI. إنهما مفهومان مختلفان تمامًا ولكن للأسف تم الخلط بينهما منذ سنوات تحت UWP. أنا شخصياً أحب أن أرى مصطلح "Xaml" غير متشابك من هذه الجهود ، لكنني لست واثقًا جدًا من أن مثل هذه التدابير سيتم النظر فيها ، ناهيك عن اتخاذها.

@ charlesroddie أوافق نوعًا ما على أن التسمية تعسفية حقًا. مجرد ظل ، إذا قمت بفحص آثار المكدس للأشياء التي تنشأ في مساحة اسم WUXaml ، فهي في الواقع داخليًا في مساحة اسم DirectUI. أود أن أعرف قصة Win8 إذا كان هناك أي شخص هنا خلال تلك الأيام ، لأنني أتخيل أن هناك قصة مختلفة. DirectComp لطبقات التركيب ، والمعالجة المباشرة للتمرير السلس والنطاقات المطاطية ، ثم Direct2D / DirectWrite كمحرك رسومات متجه مع DirectUI في الأعلى لسحبها جميعًا معًا. ثم لسبب ما ، تم إعادة نقل جزء منه إلى Win7 ، وتم الكشف عن وحدات بت Xaml فقط من خلال نظام WinRT ، في حين تم ترك جميع واجهات برمجة التطبيقات الأخرى كواجهات com مشفرة مع مصانع وأنماط غريبة تحتاجها لرؤية عينات تشرح كيفية القيام بذلك. يستحضر.

في الواقع ، الآن بعد أن فكرت في الأمر ، سيكون من الرائع حقًا ، تمامًا مثل عرض WUComposition لـ DirectComp و DirectManipulation من خلال WinRT (أو إعادة كتابة) ، Direct2D / DirectWrite كان لديه منزل رسمي هنا أيضًا. تعمل جميعها معًا لتمكين مستويات مختلفة من فتحات الهروب ونقاط اللمس من الإخلاص إذا كنت تبحث عنها. Win2D نصف مخبوز حقًا وليس واجهة برمجة تطبيقات جيدة أيضًا.

Windows.UI.Composition هو إعادة كتابة لـ DirectComposition على ما أعتقد. واجهات برمجة التطبيقات متشابهة ولكنها ليست متشابهة.

توقف عن افتراض أن جميع الشاشات sRGB بعد الآن.
تعامل مع جميع ألوان التطبيقات القديمة على أنها sRGB وقم بالتحويل لكل شاشة أثناء التركيب.

قد يكون هذا خارج الموضوع قليلاً ، ولكن افترض أن لديك بالفعل تطبيق Win32 كبير مكتوب بلغة C ++ ، فأنت تريد تحديث نظام واجهة المستخدم ، لذلك قد ترغب في استخدام WinUI أو Comp مع الحد الأدنى من التبعية ، مثل استخدام Comp فقط بدون in- مجموعة التحكم في الصندوق ، أو حتى بدون XAML .

هذا ممكن بالفعل على الرغم من ذلك ، لا نحتاج إلى انتظار WinUI 3.0 لذلك.

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

استخدم Windows.UI.Composition في تطبيق C ++ Win32 بدون XAML لتحديث التطبيقات الموجودة (مثل Photoshop). لديهم بالفعل بنية واجهة المستخدم.

قد يكون هذا خارج الموضوع قليلاً ، ولكن افترض أن لديك بالفعل تطبيق Win32 كبير مكتوب بلغة C ++ ، فأنت تريد تحديث نظام واجهة المستخدم ، لذلك قد ترغب في استخدام WinUI أو Comp مع الحد الأدنى من التبعية ، مثل استخدام Comp فقط بدون in- مجموعة التحكم في الصندوق ، أو حتى بدون XAML.

شكرًا على التعليقات حول هذا - أعتقد أن هذا يجب أن يكون ممكنًا في النهاية مع WinUI 3 ، على غرار تطبيق "بدون إطار" باستخدام Windows.UI.Composition الذي يمكنك القيام به بالفعل اليوم. سنضع ذلك في الاعتبار عندما نحدد كيفية هيكلة حزمة (حزم) WinUI NuGet والتبعيات.

توقف عن افتراض أن جميع الشاشات sRGB بعد الآن.
تعامل مع جميع ألوان التطبيقات القديمة على أنها sRGB وقم بالتحويل لكل شاشة أثناء التركيب.

@ rel-msft هل يمكنك فتح مشكلة منفصلة لتتبع ذلك؟

jesbis # 67

أعلنت Apple اليوم عن SwiftUI ...

ماذا لو تم منح Xaml Direct قوالب Visual Studio لتمكين المطورين من اختيار إنشاء التطبيقات باستخدام التعليمات البرمجية بدلاً من XAML والتعليمات البرمجية الموجودة خلفها.

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

شكرًا لك jesbis ، أقدر لك

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

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

وتحدث عن Xaml Directmdtauk :

ماذا لو تم منح Xaml Direct قوالب Visual Studio لتمكين المطورين من اختيار إنشاء التطبيقات باستخدام التعليمات البرمجية بدلاً من XAML والتعليمات البرمجية الموجودة خلفها.

كما في شيء مثل CSharpForMarkup ؟

اسم أفضل بكثير وملائم من Xaml Direct ، أود أن أقترح. بالطبع ، سيكون أي اسم. 😉

وتحدث عن Xaml Directmdtauk :

ماذا لو تم منح Xaml Direct قوالب Visual Studio لتمكين المطورين من اختيار إنشاء التطبيقات باستخدام التعليمات البرمجية بدلاً من XAML والتعليمات البرمجية الموجودة خلفها.

كما في شيء مثل CSharpForMarkup ؟

اسم أفضل بكثير وملائم من Xaml Direct ، أود أن أقترح. بالطبع ، سيكون أي اسم. 😉

@ Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

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

mdtauk نعم! يبدو نوع SwiftUI مثل Xaml ولكنه يتم في الكود. أحب حقًا فكرة كل شيء في الكود بالطريقة التي يقوم بها React. إنه نوع من المدرسة القديمة لتفكيك ملفات التصميم الخاصة بك ثم الارتباط بنوع من التعليمات البرمجية الخلفية ، وأجد أنه يجعل من الصعب الحفاظ عليها.

ذكر أحد الأصدقاء للتو أنهم بحاجة إلى محرك تخطيط SwiftUI للعمل مع شاشة iPad Pro 120 هرتز. هذا ما ركزوا عليه. رائعة حقا.

لقد قدمت إصدارًا جديدًا رقم 804 حيث يمكن أن تذهب المناقشة حول التغييرات المستوحاة من SwiftUI @ eklipse2k8

من فضلك لا تنسى إضافة قوالب ل Visual Basic

اسمح لـ WPF ببناء الطبقات السفلية لـ _on_ WinUI 3!

@ rel-msft ما هي الفوائد التي تريد الحصول عليها من تحديث WPF؟

إذا كانت هناك ميزات معينة لـ WPF تعتمد عليها والتي ترغب في رؤيتها في WinUI ، فنحن نحب أن نسمع المزيد في سلسلة محادثات "ميزات WPF التي يجب أن تكون في WinRT [WinUI]": https://github.com/microsoft / microsoft-ui-xaml / issues / 719

تم الإغلاق لصالح الإصدار المثبت الجديد # 888

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

weitzhandler [بتاريخ 16 مايو 2019

بالنسبة لي ، كل التفاصيل الفنية أقل أهمية.
UWP أو WPF أو أي إطار عمل يعمل بنظام Windows فقط ، بقدر ما هو رائع ، لن يكون كافيًا لفترة طويلة لأنه لا يعمل على كل نظام أساسي (على الأقل Windows و Droid و iOS والويب) ، وهو سهل الاستخدام أي حجم الشاشة.

وفقًا لـ WinUI و XAML بشكل عام ، أود أن أرى تحسنًا في الجوانب التالية ، والتي أجد بعضها مزعجًا ويبطئ عملي.

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

شكرا لك!

وهناك الكثير من المحولات المدمجة

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

يجب التخلص من أعمال المحولات بالكامل بشكل غير رسمي.

كائن على المحول المنطقي

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

نعم ، ويجب أيضًا التخلص من الأنظمة غير المصنفة الحالية مثل الروابط.

يجب التخلص من أعمال المحولات بالكامل بشكل غير رسمي.

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

القيم المنطقية هي قيمة منطقية. الأشياء الأخرى ليست منطقية.

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

يجب أيضًا التخلص من الأنظمة غير المصنفة الحالية مثل الروابط.

هاه؟ أعتقد في الواقع أن لديها ميزة. يمكن أن يكون الاقتران السائب بين V و VM جيدًا.

يجب أيضًا التخلص من الأنظمة غير المصنفة الحالية مثل الروابط.

يمكن أن يكون الاقتران السائب بين V و VM جيدًا.

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

تساعد الارتباطات المجمعة كثيرًا على ذلك.

weitzhandler أعني ما هي
... لا يجب أن يكون لكل شيء خاصية رؤية مخصصة.
هاه؟ أعتقد في الواقع أن [الروابط] لها ميزة. يمكن أن يكون الاقتران السائب بين V و VM جيدًا.

في إطار العمل التفاعلي الجيد ، يمكنك تحديد المتغيرات التي يمكن ملاحظتها (في الكود) مثل name:Mutable<string> ثم تعيينها إلى let visibility = name.map(fun s -> s <> "") ثم ربطها لعرض الخصائص بـ visibility.bind someView.set_IsVisible أو name.bind(fun s -> someView.IsVisible <- s <> "") .

أستخدم https://github.com/ReedCopsey/Gjallarhorn ولكن هناك العديد من الأطر التفاعلية.

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

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

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

مرحبًا ، هل يستطيع فريق ms حل جميع الأخطاء / الميزات الموجودة في uservoice ؟
إذا كان الأمر كذلك ، فستكون هذه خطوة رائعة ، أكثر من WinUI 3.0.

@ hupo376787 أعتقد أنك حصلت على تصويتات معارِضة لأن هذا ليس موضوع مناقشة نظام تطوير Windows على نطاق أوسع ، وحتى هذا الريبو ليس هو المكان المناسب على الأرجح لأنه يركز على جانب واحد فقط من هذه المنصة.

لكنها مشكلة تتمثل في عدم وجود مكان للمناقشة المفتوحة لمنصات تطوير Windows التي يمكن لمايكروسوفت والمطورين المشاركة فيها ، وهي مشكلة أن مجموعة Microsoft ذات الصلة لا تحتفظ بأي آليات للتعليقات ، بعد أن لم تقم بتحديثها أو الرد عليها. uservoice لعدة سنوات.

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

يتم إيقاف تشغيل UserVoice بالكامل هذا الشهر.

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

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

أعلم أن هناك الكثير من المحفوظات والتعليقات السابقة حاليًا على UserVoice (والتي ما زلنا نتتبعها) ، ولكن كلا من GitHub و Feedback Hub يوفران مسارًا مباشرًا لفرقنا الهندسية وتتبع عناصر العمل أكثر من UserVoice ، لذلك نأمل أن يكون هذا يجب أن يكون تغييرا إيجابيا. نحن بصدد تحديث العديد من روابط الدعم والتعليقات.

نحن نرى كل ما يأتي من أي من القناتين ونقدر حقًا التعليقات وتقارير الأخطاء!

jesbis حسنًا ، موافق.

بالنسبة إلى WinForms ، عند استخدام قالب مشروع WinUI الجديد ، هل ستستمر نافذة الخصائص في العمل وستكون قادرة على تعيين خصائص عناصر تحكم WinUI؟ يمكنني ترميز HTML طوال اليوم دون أي مشكلة (عادةً Asp.net MVC) ، ولكن عندما يكون هناك العديد من الإعدادات المتاحة لعناصر التحكم ، فقد استمتعت باستخدام نافذة الخصائص على مدار العشرين عامًا الماضية.

@ Dean-NC أعتقد أنك تسأل عن مصمم XAML ، ولا توجد نماذج WinFoms / Windows ، أليس كذلك؟ إذا كان الأمر كذلك ، نعم ، ستظل لوحة الخصائص تعمل مع عناصر تحكم WinUI عند تحديد عنصر في مصمم XAML.

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

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

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

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

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

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

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

وهناك جزر XAML لإدخال XAML في Winforms و WPF UIs الموجودة

يجب أن يعمل فريق Blazor الخاص بك مع Uno لتضمين بعض نماذج الاستضافة في Uno (على وجه الخصوص جانب الخادم) ، و / أو الحصول على Uno UI (وبالتالي WinUI 3) عرض / طبقة مرئية قابلة للاستخدام بواسطة Blazor .... و / أو ربما جزر Xaml لبلازور؟

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

طور فريقي تطبيقًا واحدًا فقط لـ UWP. لن نطور بعد الآن.

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

نستخدم تقارير Stimulsoft في منتج UWP الخاص بنا. إنها عربات التي تجرها الدواب للغاية وقد أخبرونا أنهم لن يقوموا بإصلاح الخلل لأن امتصاص UWP منخفض جدًا.

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

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

آمل ألا يسيء هذا إلى الأشخاص المرئيين :-)

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

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

أفهم أن الأعمال / المؤسسات لا تزال أكبر مستهلك لنظام Windows. لماذا لا يتم تطوير شيء أساسي لنظام Windows البيئي من أجل UWP؟

شكرا لملاحظاتك @ VagueGit و Elmarcotoro ! ضوابط المؤسسة هي فجوة بالنسبة لنا الآن. لكن توقيتك جيد ، فنحن نجمع التعليقات لتصميم عنصر تحكم DataGrid. يرجى قراءة وتقديم الملاحظات هنا: # 1500.

وبالمثل ، بجانب التحكم في البيانات الجدولية المربعة ، نحتاج إلى عنصر تحكم في الرسم البياني UWP مفتوح المصدر لإضفاء الطابع الديمقراطي بطريقة إبداعية على العلاقات المعقدة من خلال التحكم في الرسم التخطيطي

بالنسبة لنظام الإبلاغ ، أعتقد أن Telerik UI هو الخيار الأفضل حاليًا. مثل صيني يقول "بعض الناس يتخصصون في بعض المهن والبعض الآخر في مهن أخرى". Telerik ، أو DevExpress أو أي شخص آخر ، يجيدون الإبلاغ.

لعدم وجود ضوابط مختلفة ، لا ينبغي أن نلوم هذا الفريق ، ولكن على استراتيجية MS بأكملها. منذ بداية Satya يتخلى عن الهاتف المحمول ، يفضلون iOS و android بشكل أفضل ، لأن الرئيس مثلهم. يصبح النظام البيئي UWP بأكمله ضعيفًا وضعيفًا.

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

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

لقد قمت للتو بنشر ذلك في سلسلة خارطة الطريق ...

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

@ hupo376787
"بالنسبة لنظام إعداد التقارير ، أعتقد أن Telerik UI هو الخيار الأفضل حاليًا."

من خلال ما يمكنني رؤيته ، فإن Dev Express هم الوحيدون الذين يقدمون حاليًا مجموعة كاملة لإنشاء التقارير وعرضها لـ UWP ، ويبدو أن أسعارهم على الجانب المتميز. كل الآخرين بما في ذلك Telerik لديهم فجوات في الأدوات الخاصة بهم مما يعني أنه لا يمكن إنشاء تقارير لـ UWP. أنا على استعداد (آمل) أن يتم تصحيح هذا الأمر.

بالنسبة لنظام الإبلاغ ، أعتقد أن Telerik UI هو الخيار الأفضل حاليًا. مثل صيني يقول "بعض الناس يتخصصون في بعض المهن والبعض الآخر في مهن أخرى". Telerik ، أو DevExpress أو أي شخص آخر ، يجيدون الإبلاغ.

@ hupo376787 يرجى Telerik Reporting لديه مصمم تقرير لـ WPF و WinForms ولكن ليس UWP.

لدى DevExpress أيضًا مصمم تقرير لـ WinForms و WPF ، ولكن ليس UWP

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

@ hupo376787 يرجى Telerik Reporting لديه مصمم تقرير لـ WPF و WinForms ولكن ليس UWP.

لدى DevExpress أيضًا مصمم تقرير لـ WinForms و WPF ، ولكن ليس UWP

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

حسنًا ، أعتقد أن لدينا فهمًا مختلفًا لإعداد التقارير. أعني https://www.telerik.com/universal-windows-platform-ui و https://www.devexpress.com/products/net/controls/win10apps/.

لم أكن غير صحيح ، لا تقدم Dev Express تقارير لـ UWP. يبدو أنه لا يوجد مطور أدوات تابع لجهة خارجية يفعل ذلك! اتصلت بـ Dev express من خلال الدردشة ، حول ما إذا كان لديهم خريطة طريق لتقديم التقارير لـ UWP.
قالوا ،
"تستخدم مجموعة XtraReports Suite الوظائف التي يوفرها System.Drawing التجميع والشيء الذي يمنعنا من تنفيذ نفس مجموعة الأدوات لتطبيقات Universal Window هو أن هذا التجميع غير متاح هناك (https://stackoverflow.com/questions / 31545389 / windows-universal-app-with-system-drawing-and-الممكن-البديل). لذا ، لم نقم بعد بوضع خططنا المستقبلية في هذا المجال. "

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

طلبوا مني أن اتصل بهم [email protected] مع متطلبات الإبلاغ دينا، فإنه قد يكون من المفيد للفريق 3.0 فوز UI للحصول على اتصال معهم، ومعرفة ما إذا كان من هو وسيلة لمساعدتهم في التنفيذ. لا أرى كيف ستحصل على مطوري الأعمال على النظام الأساسي العالمي بدون أدوات إعداد التقارير المناسبة.

https://www.devexpress.com/subscriptions/reporting/

إعداد التقارير: من منظور WinForms فقط ، لقد استخدمت كل من Telerik و DevExpress (حتى أحدث إصداراتهما) ، وبينما كانت Telerik جيدة ، أعتقد أن DevExpress ليس لديه مصممًا عامًا وخبرة أفضل فحسب ، بل لديه أيضًا ميزات أكثر دقة سمح لي بعمل تخطيطات أكثر تعقيدًا من Telerik. أعتقد أن تقنية العرض DevExpress هي أكثر تقدمًا.

قد يكون من المفيد لفريق Win UI 3.0 الاتصال بهم ومعرفة ما إذا كانت وسيلة لمساعدتهم في التنفيذ.

شكرا على الاستدعاء. سنتواصل معهم أيضًا.

شكرا على الاستدعاء. سنتواصل معهم أيضًا.

قد يكون من المفيد التحدث معهم جميعًا ورؤية ما هي الكتل؟ Telerik و Grapecity و DevExpress إلخ.

شكرا على الاستدعاء. سنتواصل معهم أيضًا.

قد يكون من المفيد التحدث معهم جميعًا ورؤية ما هي الكتل؟ Telerik و Grapecity و DevExpress إلخ.

بالتأكيد ، هذه هي خطتنا.

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

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

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

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

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

للإجابة على أسئلتك المحددة:

ما هي القوالب التي قد تهمك أكثر؟

C # مع NET Core ، سيكون Win32 مع WinUI 3.0 متراكبًا رائعًا.

هل كنت على علم بجزر Xaml لتحديث تطبيقات سطح المكتب؟

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

السبب الرئيسي الذي كنت على علم به هو أننا سنحصل على دعم Lottie لتطبيقات Win32.

هل هذا التوافق مع الإصدارات السابقة على نظام التشغيل Windows 10 يجعل Xaml Islands أكثر إفادة لك؟

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

هل من المفيد أن يقوم Visual Studio أو أداة أخرى بتحديث مساحات الأسماء تلقائيًا من أجلك؟

نعم فعلا.

ما مدى أهمية التوافق الكامل بين مكونات UWP Xaml الحالية وتطبيقات WinUI 3.0 بالنسبة إليك؟

ضئيل للغاية. سيكون صداع التوافق الرئيسي الذي سنواجهه هو تغيير مفاتيح StaticResource لتصميم العناصر الأساسية.

هل تنشئ أو تستخدم مكتبات تحكم UWP Xaml أو مكونات WinRT التي لا يمكنك بسهولة إعادة تجميعها وتحديثها جنبًا إلى جنب مع كود التطبيق؟

نعم ، لقد استخدمنا مكتبة التحكم Syncfusion UWP في الماضي.

ما هو الحل المفضل لديك لاستخدام مكونات UWP Xaml مع WinUI 3؟

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

ما رأيك في خطة 3.0 الشاملة الموضحة أعلاه وفي خارطة الطريق؟ هل سيمكنك من استخدام WinUI لتطبيقات Windows الجديدة والحالية؟

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

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

ما نوع التطبيقات التي ستكون متحمسًا أكثر لاستخدام WinUI 3.0 من أجلها؟ هل تنشئ تطبيق Win32 جديدًا وتعبئته باستخدام MSIX؟ هل تريد إضافة طرق عرض جديدة إلى تطبيق WPF؟ تحديث تطبيق C ++ MFC باستخدام Fluent UI؟

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

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

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

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

Gridview / ListView:
لا يبدو أن Gridview و ListView يسمحان للمستخدم بالتبويب بشكل فعال من خلال المجموعة.
لا تسمح ListView لـ Tab بالانتقال إلى عناصر التحكم في نفس الصف ، ولكنها لن تنتقل إلى الصف التالي من عناصر التحكم. بدلاً من ذلك ، يفقد ListView التركيز وينتقل Tab إلى عنصر التحكم التالي في الشجرة المرئية.

هاتان المسألتان اللتان أثارهما مستخدمونا مزعجتان للغاية.

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

أوصي بإنشاء عدد جديد لكل من التحسينات التي ذكرتها. سيقوم فريق WinUI بعد ذلك بالفرز لتحديد ما إذا كانوا سيطلبون إصدار WinUI 3 قبل التنفيذ أم لا.

وُجدت هذه المشكلة بشكل أساسي للحصول على تعليقات بخصوص "الأسئلة العامة" 2 في أعلى المنشور.

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

دعم نموذج استضافة Blazor الأصلي في WinUI

تمت مناقشته على جانب Blazor ، FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

بالتأكيد ، هذه هي خطتنا.

jevansaks سيكون من الرائع الدخول في الحلقة أيضًا.

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

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

alexandrevk لا تزال معاينة. هل رأيت تصميم API للنافذة؟ https://github.com/microsoft/ProjectReunion/issues/157

شكرًا لك dotMorten على الارتباط

alexandrevk - نحن نجمع واجهات برمجة التطبيقات لـ Reunion والتي ستتيح لك القيام بهذا النوع من عمليات النوافذ من كل من Win32 و UWP مع محتوى WinUI وكذلك عند استخدام محتوى الأطر / swapchain الأخرى في نافذتك. قد يتم بعد ذلك تلخيص بعض ميزات النوافذ هذه في فئة نافذة WinUI لتسهيل الوصول إليها أيضًا ، ولكن هذا أبعد ما يكون عن الطريق. مواصفات الميزات لمنطقة النوافذ موجودة في الأنبوب ، ترقبوا ذلك.

التحدث بصرامة كمستخدم غير مباشر (على سبيل المثال: غير شركة / شركة) و ++ C فقط ، حتى لو كنت مجرد صوت وحيد أصرخ في الفراغ ، أشعر بالحاجة إلى القول ، طالما أن أيًا من أنظمة واجهة المستخدم الجديدة هذه موجودة مرتبطة بـ UWP ونظام التغليف الرهيب الذي يبنون فيه ، فأنا أخشى أنه سيكون دائمًا في الظلام مهما فعلت. (بالحديث عن تجربة WinRT ، لم تجرب WinUI حتى الآن لكنها تبدو متشابهة إلى حد كبير بالنسبة لي).
بالتأكيد يجب أن يكون معروفًا أن القليل أو لا أحد يستخدم بالفعل تطبيقات UWP؟ (في الواقع يكره معظم afaik) لذا إذا كان سيتم تسميته "أصلي" فلماذا ليس "أصليًا" حقًا ، على سبيل المثال: عدد قليل # يتضمن ، اربط ملف .lib أو اثنين وقم بإنشاء تطبيقك في STANDARD c ++.
إن الاضطرار إلى اللجوء إلى أشياء مثل Qt عندما لا يكون هناك أي قلق ، فقط لتجنب التفاف win32 للمرة الألف هو تقدم العمر نوعًا ما ليكون عادلاً.
على أي حال ، فقط سنتان ، من شخص يستخدم اللغة كل يوم ، ولكن ربما ليس له مكان للتعليق هنا.

@ nl-n ، يجب أن تكون سعيدًا بمعرفة أن إحدى الصفقات الكبيرة مع WinUI هي أنها لا تتطلب تشغيلها كتطبيق UWP. في الواقع ، كان هذا ممكنًا منذ المعاينة 2.
_ حاليًا_ يتطلب الأمر حزمًا مثل msix ، لكن msix هي في الواقع طريقة جيدة جدًا لتوزيع (وتحديث) تطبيقاتك.

dotMorten هذه إحدى المشكلات الكبيرة: تتطلب التحميل الجانبي / التثبيت عبر المتجر. لا أعرف شخصًا واحدًا لا يقوم بتعطيل / تجريد المتجر قبل (أو بعد) تثبيت النوافذ ، فكيف يفترض بنا توزيعها ؟.
أعلم أن هذا كلام بلاغي إلى حد ما لكنه يخدم الهدف. يجب أن أكون قادرًا فقط على ضغط دليل الإنشاء وتوزيعه (أو المثبت إذا لزم الأمر).
ثم هناك مشكلة التوافق ، لا يزال الكثير من الأشخاص يرفضون حتى تثبيت W10 ، لذلك هناك أيضًا ...
من الجيد أن نسمع أن هذا هو الاتجاه الذي يتجه 3.0 ، على الرغم من أنني أكره xaml ، فسيكون هذا إضافة مرحب بها.
ربما يمكننا الحصول عليه دون الحاجة إلى تثبيت عبء عمل UWP سعة 50 جيجابايت بالكامل في VS أيضًا؟ 🙏 (أبالغ وأنا أعلم ، لكن لا يزال)

للاقتباس من MarkIngramUK بالقرب من بداية هذا الموضوع:

إنه عام 2019 ، أريد واجهة مستخدم أصلية سريعة ، ولا أريد أن أفكر بجدية في إنشاء واجهة مستخدم بـ CreateWindowExW ، GDI ، إلخ.

وهو ما (مضحك بما فيه الكفاية) يتعين علي فعله الآن ، ونعم إنه مؤلم تمامًا كما يبدو :)

@ nl-n الذي قال أي شيء عن المتجر؟ لا يختلف MSIX حقًا عن التثبيت من MSI. إنه مجرد مثبت تطبيقات. انقر نقرًا مزدوجًا فوقه للتثبيت. لا حاجة إلى متجر. يضمن أيضًا إلغاء التثبيت النظيف بنسبة 100٪ (على عكس MSI الذي يتسبب في حدوث فوضى كبيرة)

لا أعرف شخصًا واحدًا لا يقوم بتعطيل / تجريد المتجر

على الرغم من أنه ليس شائعًا.

كيف يفترض بنا أن نوزعها

بادئ ذي بدء ، تحتاج إلى إبلاغ المستخدمين بعدم تعطيل المتجر)

يجب أن أكون قادرًا فقط على ضغط دليل الإنشاء وتوزيعه

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

لا يزال عدد كبير جدًا من الأشخاص يرفضون حتى تثبيت W10 ،

إنه اختيارهم. قال ناف.

كامل عبء العمل 50 جيجابايت UWP في VS أيضًا

SDK واحد حوالي 3 غيغابايت. ليس مطلوبًا تنزيل كل واحد بدءًا من 10240.

@ nl-n الذي قال أي شيء عن المتجر؟ لا يختلف MSIX حقًا عن التثبيت من MSI. إنه مجرد مثبت تطبيقات. انقر نقرًا مزدوجًا فوقه للتثبيت. لا حاجة إلى متجر. يضمن أيضًا إلغاء التثبيت النظيف بنسبة 100٪ (على عكس MSI الذي يتسبب في حدوث فوضى كبيرة)

كان ذلك من الوصف المرئي الذي يوفره لك الاستوديو ، "للتحميل الجانبي / التثبيت عبر متجر Microsoft" ، المعلومات الأخرى الوحيدة التي وجدتها في msix هي من msdn ، والتي تقول أساسًا: حزم msix هي تطبيقات آلية / تطبيقات "appx" افتراضية ، وهو قاتل إلى حد كبير لأي شيء يعمل مباشرة مع winapi. وهم يحتاجون إلى التوقيع حتى يكون قابلاً للتثبيت؟ ...

يمكن أيضًا أن تكون مجرد أسلاك متقاطعة ، على ما أفترض ، الكثير من الاختلاف في علم الحركة ، ولا أعرف الكثير عن UWP.

على الرغم من أنه ليس شائعًا.

أكثر شيوعًا مما تعتقد ، وبسبب 😄

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