ربما شيء بعيد المنال ، لكن Blend يحتاج إلى إصلاح ويحتاج إلى سير عمل يركز على التصميم.

يحتاج مصمم XAML إلى أن يكون قويًا وقويًا.

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

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

تخصيصات التحكم في العرض المصممة لـ CoreOS ، و "Surface Phone" ، و Surface Hub ، و Xbox ، و HoloLens ، وكل ذلك داخل المصمم.

مصممين مجمعين لـ XAML ممزوجين بـ WinForms و WPF و MFC وجميع الأطر الأخرى التي سيعمل معها WinUI Desktop.

طرق جيدة لاستيراد وتصدير XAML ، بحيث يمكن للمصممين العمل في Blend معزولًا عن التطبيق الرئيسي ، ثم تسليمهم إلى فرق التطوير لإحضارهم إلى التطبيق.

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

طرق أفضل لاختبار تحجيم DPI المختلف باستخدام التطبيقات التي تتضمن WinForms و MFC وما إلى ذلك.

قوالب لعناصر التحكم الجديدة ، وقواميس موارد السمات المخصصة ، ودمج محرر السمة Fluent ، والقوالب لمجموعات التطبيقات المدعومة (Win32 MFC مع Xaml UI ، إلخ).

قوالب لنقاط تكامل shell ، مثل منتقي الملفات ، ومنشورات علبة المهام.

هذه مجرد أفكار قليلة ...

أفكاري كما يلي:

1. يعد MSIX جيدًا وجيدًا ، لكنني ما زلت أستخدم MSI القديم الجيد لتثبيت تطبيقات أكثر تعقيدًا تتطلب ميزات لا يدعمها MSIX. أنا أيضًا حريص على استخدام MSIX بسبب تكلفة شهادات رمز المصادقة المطلوبة. (يمكنني بسهولة توقيع الكود الخاص بي بشهادة موقعة ذاتيًا ، والتي أعتقد أنها آمنة تمامًا مثل تلك التي أشتريها من شركة ، ولكن بعد ذلك لن يقوم Windows بتحميلها. سيسعد Windows بقبول ملف MSI موقّع ذاتيًا ، ومع ذلك .) طالما يمكنني استخدام WinUI 3 من تطبيق مستند إلى MSI ، فأنا سعيد.
2. سيكون مصمم XAML الأفضل موضع تقدير كبير ، لكنني لست بحاجة إلى التعقيد الإضافي لدمج مصممي WinUI XAML و WinForms / WPF في واحد. أنا موافق تمامًا على التقليب بين علامات التبويب المختلفة في VS.
3. كما علقت سابقًا ، فإن فصل مترجم XBF عن أنظمة مشروع C # و Visual Basic سيكون مفيدًا للغاية. (سيكون من الأفضل إذا تم إصدار مصدر مترجم XBF ، أو الوثائق الكافية لإعادة إنشائه ، لكنني لا أعرف مدى احتمالية حدوث ذلك.)
4. دعم أفضل لـ C ++ / WinRT و MIDL 3 في نظام مشروع C ++. في الوقت الحالي ، يعد دعم المشروع لاستخدام C ++ / WinRT هشًا وعديم القيمة. (على سبيل المثال ، إذا قمت بتغيير مساحة الاسم في ملف IDL - والذي غالبًا ما يكون مطلوبًا إذا كانت هناك نقطة في اسم المشروع تريد استخدامها في مساحات الأسماء ، حيث يقوم القالب بتحويلها إلى شرطات سفلية تلقائيًا - فسيفشل مشروعك في التحويل البرمجي ، وإصلاح المشكلة في تجربتي يتطلب نقل ملفات *.h و *.cpp جانبًا ، وإعادة إنشائها من البداية ، ونسخ الكود ، ثم تفريغ وتحرير ملف vcxproj لإصلاح التداخل.) بقدر ما أرغب في استخدام شيء أكثر حداثة ومرونة من vcxproj ، لا يمكنني فعل ذلك بسبب الاعتماد الشديد على مترجم XBF.

إذا ظهر أي شيء آخر ، فسأحرص على نشره هنا. شكرا!

1. ما أتساءل هنا هو ... حسنًا ، هل سأحتاج إلى استخدام بادئة مساحة الاسم مثل < winui: Listview أو < controls: listview أو أيًا كان ما يقرره المطورون؟ أعتقد أنه سيكون من الأفضل بكثير ، إذا أمكن ، استخدام نفس التجربة كما هو الحال الآن ، فقط البادئة جيدة ورائعة لعدد قليل من عناصر التحكم. ولكن عندما تبدأ في الاستخدام في كل مكان ، فإن هذا يجعل قراءة XAML كابوسًا للغاية.
   لا معنى لاستخدام بادئة مساحة الاسم ، لأنه لن يكون من الممكن استخدام Windows.UI.Xaml.Controls وستكون WinUI هي الخيار الافتراضي.

2. في الوقت الحالي ، لا أستخدم مصمم XAML. أنا حرفيا تعطيل في الإعدادات. XAML Designer بطيء ، ويحتاج إلى دعم أفضل. لقد كان جيدًا لـ WPF ، ولكن ليس UWP ، خاصة إذا كنت تريد القيام بتصميم سريع الاستجابة ، والتعامل مع الصفحات ، وعرض البيانات ، وما إلى ذلك.
   ربما يكون هذا تعليقًا للمستقبل البعيد ، لكن أعتقد أنه تعليق جيد للنظر فيه. مصمم WPF أسرع بكثير.
   هل هذا بسبب رمل أم ماذا؟

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

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

TL ؛ DR أريد أن يدعم نموذج التطبيق التواجد المشترك للمثيل التعسفي . حتى الإصدار نفسه يمكن تشغيله مع مجموعة بيانات / خيارات مختلفة ، مثل خلايا Visual Studio. يبدو أن الحل الوحيد حاليًا هو xcopy.

هل يمكن لأي شخص أن يخبرني كيف أنهار هذا؟

أولاً ، أستخدم أيضًا التطبيق الذي أقوم بتطويره يوميًا (وأستخدم >> تصحيح الأخطاء لمعظم الأيام). لذا ، اجعل بناء dev يتعايش مع بنية مستقرة سيساعدني كثيرًا. حاليًا لا بد لي من زيادة رقم الإصدار ، حزمة msix تصحيح الأخطاء ، تحديث إصدار الحزمة المثبتة لتصحيح الأخطاء.
أثناء مراحل تصحيح الأخطاء المختلفة ، سأريد إمكانات مختلفة. بالنسبة لبيانات العالم الحقيقي المعقدة ، أريد أن يشارك مثيل التصحيح البيانات مع نسخة مستقرة. بالنسبة للبيانات المزيفة التعسفية ، أريد العزلة رغم ذلك. يتم حل هذا نظريًا عن طريق الوصول إلى البيانات باستخدام منتقي المجلدات ، ولكن من المؤسف جدًا أن SQLite في UWP لا يدعم ذلك ، ولا يوجد محرك ACID مضمن آخر كما أعرف.

أوه ، وشيء آخر. سأكون ممتنًا حقًا ، حقًا ، إذا كان بالإمكان فعل شيء ما حول كيفية تطلب vcxproj استخدام package.config لمراجع حزمة NuGet. يتم توزيع WinUI كحزمة NuGet ، كما هو الحال مع C ++ / WinRT والمكونات الرئيسية الأخرى. أنا حقًا لا أحب استخدام bund.config. يعد PackageReference أكثر فاعلية (ولا ينتج عنه بنية معطلة إذا قمت بنقل vcxproj إلى دليل مختلف). إنه يعمل بالفعل عند استخدامه من vcxproj ، طالما أن هدف الاستعادة يعمل في الوقت المناسب. (هذا لأن أهداف vcxproj تستورد بشكل غير مباشر آلات استعادة PackageReference لمشاريع غير SDK C #.) لقد كتبت مجموعة من الأهداف التي تقوم تلقائيًا بتشغيل هدف الاستعادة عند تغيير مجموعة عناصر PackageReference ، لأن VS لن تفعل ذلك نفسها (حتى الآن). لسوء الحظ ، لا يعرف نظام NuGet شيئًا عن هذا الأمر ، ولذلك فهو يحاول إضافة ملف bund.config عندما أقوم بإضافة قالب ملف C ++ / WinRT. يتسبب هذا في كل أنواع الخراب ، مما يؤدي إلى طرح استثناء وتعطل ملف المشروع. لست متأكدًا من أفضل السبل لحل هذه المشكلة ، لكنني سأكون ممتنًا حقًا إذا كان من الممكن النظر إليها على الأقل قبل إصدار WinUI 3. شكرا!

سيكون من الجيد ، إذا كان WinUI يدعم sdk لمشروع جديد - Microsoft.NET.Sdk أو MSBuild.Sdk.Extras .
يصعب الحفاظ على ملفات csproj ذات النمط القديم. ولا يمكننا استخدام TargetFrameworks متعددة معها ، والتي قد تكون مفيدة للترحيل إلى WinUI.

لماذا لا يوجد دعم F #؟

هل يجب مناقشة وظائف Azure DevOps و Visual Studio App Center هنا؟

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

ستكون أداة الترحيل رائعة بالطبع. إذا كان يعمل مع مزودي الطرف الثالث الكبار (Telerik ، DevExpress ، ...) فسيكون ذلك شيئًا كبيرًا بالفعل.

القوالب

هل هناك اهتمام / حاجة للإصدارات السابقة من قوالب UWP XAML للبقاء في تدفق المشروع الجديد VS؟

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

ربما يكون الأمر محيرًا أيضًا للمطورين إذا كنت قد أنشأت تطبيقًا ولا يمكنك إنشائه بعد الآن باستخدام أحدث إصدار من Visual Studio.

لكن شخصيًا ، ليس لدي اهتمام بالاحتفاظ بالقوالب

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

بالنسبة لي هذا يبدو رائعًا لـ UWP. الآن أريد أن أرى الشيء نفسه بالنسبة لـ Win32. :)

هل هذه الجولة مفيدة وهل ترغب في رؤية المزيد من هذا عندما تتشكل السيناريوهات؟

نعم بالتأكيد. هذه المسيرة مفيدة جدًا لفهم ما يمكن أن يبدو عليه المستقبل وما يجب أن يكون عليه. أود أن أرى المزيد من هذا.

الهجرة

هل سيكون مفيدًا إذا قدمنا ​​أداة ترحيل تعمل تلقائيًا على الخطوات من 1 إلى 3؟

بالتااكيد. ربما يكون ملحق Visual Studio الصغير خيارًا رائعًا لهذه الترحيل. يمكنني أيضًا التفكير في شيء مثل "محلل توافق WinUI" الذي ينتج ما يمكن ترحيله وما لا يمكن ترحيله. شيء مشابه لمحلل نقل .NET.

ما المكتبات التي تستخدمها من خارج مجموعة التحكم في نظام التشغيل Windows 10 الأصلي؟

عادةً ما تكون Telerik DataGrid ومجموعة أدوات المجتمع

ما هي الطرق التي يمكننا بها المساعدة في الهجرة التي لا نفكر فيها حاليًا؟

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

آحرون

كما هو مذكور بالفعل في التعليقات الأخرى ، أعتقد أن الوقت قد حان للتبديل إلى ملفات .csproj على غرار SDK.

أضف قوالب winui 3.0 إلى استوديو قالب windows.

WinUI في تطبيقات سطح المكتب

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

بصفتي مطورًا .net ، هذا هو الجزء الذي أهتم به كثيرًا.

القوالب

• هل هناك اهتمام / حاجة للإصدارات السابقة من قوالب UWP XAML للبقاء في تدفق المشروع الجديد VS؟

حسب عدد القوالب. إذا كان الرقم منخفضًا (على سبيل المثال فقط "تطبيق فارغ (نظام Windows)" لكل لغة ، لذلك 1 في حالة c #) ، تكون الضوضاء منخفضة ويمكن دعمها. ولكن إذا كان يتضمن أكثر من عدد قليل من القوالب ، فلا تقم بتضمينها افتراضيًا وأضف مكون تثبيت VS اختياريًا لإضافتها.

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

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

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

• هل هذه الجولة مفيدة وهل ترغب في رؤية المزيد من هذا عندما تتشكل السيناريوهات؟

نعم

دعم اللغة

• هل سيكون مفيدًا إذا قدمنا ​​أداة ترحيل تعمل تلقائيًا على الخطوات من 1 إلى 3؟

يجب أن يكون التوثيق الجيد (صفحة واحدة بخطوات واضحة) كافيًا. إذا كان كل شيء يمكن القيام به من داخل VS دون تحرير csproj يدويًا ، أقترح فقط إضافة صفحة توثيق تصف الخطوات.

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

التعبئة والتغليف

MSIX هي طريقة التغليف الحديثة لجميع التطبيقات. بالنسبة إلى WinUI في Win32 ، هل يجب أن ندعم ClickOnce؟ ما هي طرق التعبئة والتغليف الأخرى التي يجب أن تشمل الدعم لها؟ خاصة بالنسبة لـ WinUI في Win32

قارن الاختلافات بين نشر clickonce و msix:

1. لا تقدم ميزة App Installer نفس التجربة على إصدارات Windows الأقدم
2. يتطلب MSIX حزمة موقعة صالحة (داخلية أو عامة). Clickonce يدعم الحزم الموقعة ذاتيا.
3. يحتوي نموذج الحزمة على بعض القيود ، ويرجع ذلك في الغالب إلى البيئة المعزولة (لا يوجد وصول إلى بيانات التطبيق المحلية على سبيل المثال ، لا توجد عملية مرتفعة).

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

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

• تجربة المصمم

العروض والأداء والعروض ودعم الحلول الكبيرة مع الكثير من المشاريع.

هل سيكون إصدار WinUI الخاص بـ Windows 10 SDK ومصمم WinUI Xaml مفتوحين المصدر؟

هل سنتمكن من إرسال طلبات لسير عمل وقت التصميم والخبرة؟

هل ستتبع SDK إيقاع إصدار مشابه لإصدارات WinUI nuget؟

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

نحن نعتمد بشدة على ClickOnce ، لذلك سيكون من الجيد تقديم الدعم على المدى القصير. سنكون على استعداد للانتقال إلى MSIX ، ولكن بعد تقديم ميزات مماثلة.

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

شكرا

نحن نعتمد بشدة على ClickOnce ، لذلك سيكون من الجيد تقديم الدعم على المدى القصير. سنكون على استعداد للانتقال إلى MSIX ، ولكن بعد تقديم ميزات مماثلة.

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

شكرا

يجب أن تكون بنية وأنماط "shell" التطبيقات الأكثر شيوعًا متاحة كقوالب حتى يتمكن المطورون من بدء العمل بسرعة. يجب أن تكون تطبيقات الطرف الأول من Microsoft نماذج في هذه التخطيطات وأن تعمل كأفضل ممارسة من حيث السلوك والاتساق والالتزام بمعايير تصميم واجهة المستخدم الخاصة بـ Fluent Design و WinUI.

تضمين التغريدة
بالنسبة إلى هيكل وأنماط "التطبيق الأكثر شيوعًا" و "بالنسبة إلى القوالب ، سيكون من الجيد أن يكون لديك واحد يوفر واجهة مستخدم معيارية ورمزًا لبرنامج NavigationView والتنقل". يوجد Windows Template Studio الذي يتم صيانته وتطويره بواسطة كل من Microsoft والمجتمع. لنقتبس مقدمتها:

Windows Template Studio (WTS) هو ملحق Visual Studio 2017 و 2019 يعمل على تسريع إنشاء تطبيقات Universal Windows Platform (UWP) الجديدة باستخدام تجربة تعتمد على المعالج. مشروع UWP الناتج هو رمز جيد التكوين وقابل للقراءة يشتمل على أحدث ميزات Windows 10 أثناء تنفيذ الأنماط التي أثبتت جدواها وأفضل الممارسات.

@ Felix-Dev هل سيكون هناك في النهاية قوالب WPF بالإضافة إلى UWP؟

shaggygi قد تكون هناك بعض الأخبار الجيدة لك! انظر هذا الموضوع : بينما يبدو أنه لا يوجد شيء مضمون في هذه المرحلة ، يبدو أنه يتم استكشاف فكرة توفير قوالب خاصة لمشاريع WPF. كما هو مذكور في الخيط المرتبط ، كانت هناك جلسة نظرة خاطفة غير عامة تسمى "Windows Template Studio - WPF Edition" تمت استضافتها في Build 2019.

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

لقد حاولت كتابة XAML لتطبيق C ++ الخاص بي وكانت تجربة الصبي مؤلمة.

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

على سبيل المثال:

• عند إنشاء مشروع لتخزين صفحات XAML الخاصة بي فيه ، اضطررت إلى إضافة <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> و <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> ، وهما خاصيتان للمشروع غير موثقتين تمامًا ولم يتم اكتشافهما إلا من خلال فحص الكود المصدري للوحدة الطرفية الجديدة.
• كان لدي عبارة مشفرة "تعذر إنشاء عرض جديد لأن النافذة الرئيسية لم يتم إنشاؤها بعد" حتى أنشأت واستخدمت فئة التطبيق ، والتي لا توجد طريقة لاستخدامها في VS باستثناء إنشاء صفحة عادية والدخول في خصائص ملف XAML في VS وتغييره إلى تعريف تطبيق ، ثم ضبط MIDL وكود المصدر وملف XAML.
• لقد أضفت حزمة Microsoft.Toolkit.Win32.UI.XamlApplication NuGet لإنشاء فئة التطبيق الخاص بي ولم أتمكن من تحميلها حتى أضفت أيضًا Microsoft.VCRTForwarders ، مرة أخرى وجدت هذا عند فحص مصدر الوحدة الطرفية ، لا يوجد مؤشر حول أي من الحزمة في أي مكان.
• لم يتم دمج PRIs في واحدة حتى أضفت شيئًا ما في ملف .wapproj ، لذلك لم يتمكن من العثور على مورد XAML الخاص بي.
• لم يكن XBF يعمل حتى أضفت <DisableEmbeddedXbf>false</DisableEmbeddedXbf> مما أدى بشكل مفاجئ إلى تعطيل XBF المدمج بدلاً من تمكينه. الخطأ الوحيد الذي أواجهه هو خطأ تحليل XAML مع عدم وجود شيء يشير إلي أن ملفات XBF لا تعمل.
• تم تجاهل maxVersionTested في بيان تطبيقي تمامًا حتى قمت بتغييره بالكامل إلى أحرف صغيرة ، على الرغم من أن التعليمات لاستخدام إصدار حالة الجمل: https://github.com/MicrosoftDocs/windows-uwp/issues/1781 #issuecomment -511173811

بالإضافة إلى ذلك ، كان C ++ / WinRT يمثل أيضًا ألمًا في المؤخرة:

• في كل مرة أقوم بتشغيل بناء تدريجي ، كان لدي [msg]redefinition [context]: MyClass لفصولي المخصصة التي منعتني من البناء ولم أذهب بعيدًا حتى قمت بتشغيل بنية نظيفة والتي بسبب رؤوس C ++ / WinRT تستغرق وقتًا طويلاً. اختفت هذه القضية بطريقة سحرية في منتصف الطريق.
• الآن عندما أقوم بتشغيل الإنشاءات النظيفة ، أحصل على خطأ بخصوص الرؤوس المفقودة. يؤدي الضغط على زر الإنشاء مرة ثانية إلى تشغيله مرة أخرى.
• اضطررت إلى كتابة صنف AppT<> بسبب الترميز السيئ من C ++ / WinRT. يقوم تطبيق Terminal وعينة جزر XAML بالشيء نفسه ، كما لو كان شيئًا سيحتاج المستخدمون إلى فعله بدلاً من إصلاح مشكلة الجذر.
• يؤدي تغيير أي شيء في ملفات MIDL إلى حدوث أخطاء في الإنشاء حتى أقوم بإنشاء بنية نظيفة.

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

الهجرة

يعد التشغيل الآلي للخطوة 1-3 مفيدًا بشكل خاص لأن إعادة تسمية مساحات الأسماء على عدد كبير من الملفات تستغرق وقتًا طويلاً للغاية وعرضة للأخطاء. علاوة على ذلك ، سيكون محلل التوافق لطيفًا تمامًا مثل .net framework> .net core one الذي ينشئ تقريرًا عن مدى توافق قاعدة الكود الحالية ويلاحظ جميع التغييرات الممكنة المطلوبة.

الأدوات

كما قال آخرون بالفعل ، سيكون من الجيد استخدام محرر أكثر ثراءً بالميزات. معظم الوقت هنا في العمل يتم عمل XAML يدويًا ويستخدم المصمم في الغالب كدليل حول الهيكل العظمي التقريبي حول شكل التطبيق. ستكون عمليات إعادة البناء التحسسية والذكية مفيدة حقًا ، مثل CTRL + R + R لإعادة تسمية الأشياء (مثل خصائص التبعية أو حتى العلامة) على سبيل المثال ، خاصةً عندما يكون لديك الكثير من UserControls المخصص وأيضًا GoTo التنفيذ والمراجع. سيكون دعم محلل Roslyn جيدًا أيضًا.

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

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

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

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

هل من الممكن عدم تغيير مساحات الأسماء عند استخدام WinUI؟

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

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

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

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

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

فوائد:

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

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

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

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

واجهت أيضًا المزيد من المشكلات:

• بعد إضافة الموارد إلى فئة App ، لم يتمكن XAML الخاص بي من العثور عليها حتى أضفت هذا ، وتم العثور عليه مرة أخرى من تطبيق Terminal وبدون فكرة كثيرة عما يفعله بالفعل:
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• سوف ينكسر البناء تمامًا بشكل عشوائي مع وجود خطأ مشابه لـ cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication والطريقة الوحيدة لإعادة بناء المشروع مرة أخرى هي القيام ببناء نظيف
• لا يمكنني تشغيل التطبيق عن طريق تعيين vcxproj مباشرة لـ exe الرئيسي كمشروع بدء التشغيل ، يجب أن أبدأ يدويًا إخراج appx غير المعبأ في bin\x64\Debug\AppX ثم حقن مصحح أخطاء من داخل VS ، أو اضبط حزمة التطبيق كعملية بدء التشغيل.

الأشياء ذات الصلة على سطح مكتب Windows: .NET Community Standup - 25 يوليو 2019 إذا كنت مهتمًا.

WinForms وقت طويل ، مطور WPF هنا مع بعض خبرة UWP. هنا سنتان:

الهجرة

• أداة لترحيل تطبيقات UWP الحالية إلى WinUI أمر لا بد منه.
• أداة لتحويل عناصر تحكم WinForms أو WPF إلى عناصر تحكم WinUI في تطبيق موجود ستكون أكثر من رائعة. من خلال تحويل عناصر التحكم ، أعني تغيير المراجع في الحاوية إلى عناصر التحكم الفردية.
• أداة لترحيل نماذج Xamarin إلى WinUI للسماح بنقل تطبيق جوال إلى Windows.

الأدوات

• محرر XAML الحالي فظيع! يحتاج إلى استخدام لوحة محرر النصوص العادية وتوفير ميزات Roslyn ليتم تطبيقها على نموذج كائن XAML لتحسين التحسس وإعادة البناء.
• حتى يصبح Visual Studio 64 بت ، يجب أن يكون محرر XAML تطبيقًا مستقلاً 64 بت خلف الكواليس. أحتاج باستمرار إلى إعادة تشغيل VS 2017 و VS 2019 لإيقاف خطأ نفاد الذاكرة عند العمل مع الكثير من XAML.

القوالب

• نحن بحاجة إلى قوالب المشروع هذه

  • NavigationView WinUI
  • NavigationView WPF
  • WinUI الشريط
  • شريط WPF
  • WinForms الشريط

• نحتاج إلى قوالب الصفحة / النافذة هذه

  • صفحة تحكم الوسائط
  • صفحة المستعرض
  • نافذة الحوار
  • نافذة بلا حدود
  • نافذة عائمة

• نحتاج قوالب التحكم

  • عرض شبكة البيانات المغلفة
  • عرض البيانات الفرعية المغلفة

سيعمل هذان الأخيران معًا لإنشاء نوافذ Master-Detail سهلة.

كل هذه القوالب والصفحات وما إلى ذلك يتم تنفيذها بالفعل في مشروع Windows Template Studio ، فلماذا لا تتبع نفس المسار بدلاً من إعادة إنشائها كلها؟

ملف مشروع SDK Style
أحد أهم الأشياء التي أرغب في رؤيتها - كما ذكر العديد من الآخرين - هو دعم تنسيق ملف مشروع SDK Style الجديد لكل من تطبيقات UWP و "Desktop XAML".

الترحيل بين نماذج تطبيقات UWP و Desktop XAML
إذا بدأنا في إنشاء تطبيق "Desktop XAML" ، فما مدى بُعده عن تطبيق UWP؟ هل سيكون من التافه تحويله إلى تطبيق UWP لاحقًا إذا أدركنا أننا بقينا ضمن قيود وضع الحماية لـ UWP؟ أو إذا بدأنا في إنشاء تطبيق UWP وأدركنا أننا بحاجة إلى المزيد ، فهل سيكون من السهل تحويله إلى تطبيق "Desktop XAML"؟

أنا مع دعم Template Studio.

أنا مع دعم Template Studio.

هل يدعم Template Studio مشاريع XAML C ++؟

ما يفعله Template Studio ، يجب أن يكون جزءًا من WinUI SDK IMO

ما يفعله Template Studio ، يجب أن يكون جزءًا من WinUI SDK IMO

يجب أن يكون جزء Visual Studio IDE IMO! 😎

يا رفاق ، النقطة المهمة هي أن windows template studio يقوم بأشياء الكل في واحد لإنشاء مشروع UWP ، لذا ضع في اعتبارك أنه إذا كان هناك شيء مفقود مثل دعم xaml c ++ ، يجب أن نفكر في إضافة ذلك إلى استوديو قوالب Windows ، أعتقد أنه سيكون أسرع وأكثر كفاءة إذا ظلت جميع الابتكارات الجديدة في مشاريع uwp في مشروع واحد.

يجب أن يكون هناك طريقة ما لاستخدام الطبقة السفلية من مكدس WinUI 3 مباشرة بدون XAML أو حتى MVVM. هذا مفيد بشكل خاص لبرامج C ++ الكبيرة الحالية والتي لديها بالفعل نوع من هندسة MV-أيا كان في قاعدة التعليمات البرمجية الخاصة بهم. إنهم يريدون شيئًا أفضل من HWND + GDI.

ويرجى أن تجعل الناس يعتقدون أن WinUI 3 ليست لعبة ، بل يمكنها حقًا دعم البرامج الجادة .

@ be5invis أوافق تمامًا. الحل الوحيد الآن هو XamlDirect ، ولكنه يستهدف بشكل أكبر مطوري البرامج الوسيطة.

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

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

MarkIngramUK قد يحتاجون إلى شيء "كامل" أكثر ، مثل استبدال CreateWindow بوظائف WinUI.

من أجل التصميم ، أود حقًا أن تحصل قوالب WinUI WPF المستقبلية على دعم لتوسيع محتويات الصفحة في شريط العنوان مثل تطبيقات UWP الحالية. في الوقت الحالي ، مع حل جزر XAML الحالي ، نحن فقط نستضيف عناصر تحكم داخل نافذة WPF / WinForms بدلاً من طريقة عرض حديثة.

LucasHaines قائمة اللغات التي نخطط لدعمها مع WinUI 3.0: C # ، C ++ / WinRT ، Visual Basic. نحن نستكشف دعم F #.

هذا يدل على أنك تفعل ذلك بشكل خاطئ ، ليس فقط للغة F # ولكن لجميع اللغات الصافية. أنت تبدأ بالتفكير في القوالب وملفات .xaml ، والتي تشبه بناء منزل ووضع السجاد والستائر في مكانها دون الانتهاء من الهيكل.

يجب أن تكون قادرًا على تثبيت WinUI في أي مشروع .Net Standard 2.0 / .Net Core 3.0 / .Net 5 كحزمة Nuget. ثم يمكنك الوصول إلى جميع الفئات المحددة بالداخل. يمكنك بعد ذلك الرجوع إلى مثل هذه المشاريع من مشروع WinUI (والذي يمكن أن يكون C # فقط). يسمح هذا بإنشاء عروض WinUI بأي لغة .Net. تعرف على كيفية قيام Xamarin.Forms بذلك .

الفئات متاحة بالفعل للاستخدام في F # (لأنها مكونات Windows Runtime ، والتي يمكن استخدامها من قبل جميع لغات .NET)

ستتمكن من إنشاء تخطيط يدويًا. يمكنك حتى القيام بذلك عبر Python باستخدام Py / WinRT لجميع اهتمامات WinUI.

sylveon ما الطبقات على وجه التحديد؟ سأكون مهتم ...

كلهم. واجهة برمجة التطبيقات العامة لـ WinUI هي مكونات Windows Runtime فقط.

LucasHaines قائمة اللغات التي نخطط لدعمها مع WinUI 3.0: C # ، C ++ / WinRT ، Visual Basic. نحن نستكشف دعم F #.

هذا يدل على أنك تفعل ذلك بشكل خاطئ ، ليس فقط للغة F # ولكن لجميع اللغات الصافية. أنت تبدأ بالتفكير في القوالب وملفات .xaml ، والتي تشبه بناء منزل ووضع السجاد والستائر في مكانها دون الانتهاء من الهيكل.

يجب أن تكون قادرًا على تثبيت WinUI في أي مشروع .Net Standard 2.0 / .Net Core 3.0 / .Net 5 كحزمة Nuget. ثم يمكنك الوصول إلى جميع الفئات المحددة بالداخل. يمكنك بعد ذلك الرجوع إلى مثل هذه المشاريع من مشروع WinUI (والذي يمكن أن يكون C # فقط). يسمح هذا بإنشاء عروض WinUI بأي لغة .Net. تعرف على كيفية قيام Xamarin.Forms بذلك .

هذا الموضوع / السؤال عن الأدوات. نعم ، يمكن الرجوع إلى المكتبات مباشرة من أي لغة قادرة على استهلاكها ولكن هناك تشويش في التعريفات بين الأدوات ودعم اللغة.
أخذ Xamarin.Forms كمثال لك. يوفر ذلك فقط أدوات لـ C # وبدرجة أقل F #. من الممكن إنشاء تطبيقات باستخدام نماذج VB.Net و Xamarin ، لكنها ليست مدعومة رسميًا ، حيث لا توجد أدوات ووثائق محدودة فقط للقيام بذلك.

أيضًا ، نظرًا لأن WinUI خاص بنظام Windows ، فلا يمكن الإشارة إليه في أي مشروع .Net Standard 2.0 / .Net Core 3.0 / .Net 5.
هناك أيضًا حاجة لدعم مستوى المشروع / المترجم / الحزم لبعض السيناريوهات أيضًا.

فريق عمل رائع على إصدار v2.2 . هل من الممكن أن نحصل على تحديث موجز لحالة الإصدار 3.0؟

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

الرجاء إزالة الحاجة إلى xmlns:mux="using:Microsoft.UI.Xaml.Controls" من XAML. أنا أفهم أن التعليمات البرمجية لا تزال بحاجة إلى التغيير. يمكن أن يكون هناك أيضًا تكوين لهذا المكان في المشروع.

الرجاء إزالة الحاجة إلى xmlns:mux="using:Microsoft.UI.Xaml.Controls" من XAML.

لن يكون مطلوبًا في XAML _markup_ ، ولكن تغيير مساحات الأسماء في التعليمات البرمجية الخلفية سيظل مطلوبًا.

إذا كنت تريد استخدام عناصر تحكم Windows (إذا لم تتم إزالتها من نظام التشغيل) - يجب عليك إعلان مساحة الاسم في XAML

إذا كنت تريد استخدام عناصر تحكم Windows (إذا لم تتم إزالتها من نظام التشغيل) - يجب عليك إعلان مساحة الاسم في XAML

مع WinUI 3.0 ، هذا ليس سيناريو - لا يمكنك مزج عناصر التحكم في نظام التشغيل ومطابقتها مع عناصر تحكم WinUI 3.0. يعمل هذا فقط مع WinUI 2.x في الوقت الحالي لأن عناصر التحكم هذه هي إضافات لنظام التشغيل (ولدينا الكثير من الحالات المحرجة حيث قمنا بشحن النوع في كلا المكانين مثل NavigationView و TreeView مما تسبب في الغموض).

إذا كنت تريد استخدام عناصر تحكم Windows (إذا لم تتم إزالتها من نظام التشغيل) - يجب عليك إعلان مساحة الاسم في XAML

مع WinUI 3.0 ، هذا ليس سيناريو - لا يمكنك مزج عناصر التحكم في نظام التشغيل ومطابقتها مع عناصر تحكم WinUI 3.0. يعمل هذا فقط مع WinUI 2.x في الوقت الحالي لأن عناصر التحكم هذه هي إضافات لنظام التشغيل (ولدينا الكثير من الحالات المحرجة حيث قمنا بشحن النوع في كلا المكانين مثل NavigationView و TreeView مما تسبب في الغموض).

من الجيد أن تسمع. سيجعل من السهل إهمال ذلك من نظام التشغيل. آمل أن ينتقل تطبيق الإعدادات و Shell وأجزاء أخرى من نظام التشغيل إلى WinUI 3.0 أيضًا.

ويتيح الأمل في منافذ أدوات المسؤول و Wordpad وما إلى ذلك إلى XAML بإعادة استخدام نفس الرمز قدر الإمكان أيضًا!

jevansaks حسنًا ، مفهوم ، شكرًا على التعليقات!

mdtauk لن تكون هناك حاجة للتمييز بين عناصر التحكم القديمة "OS" وعناصر التحكم في النظام الأساسي الجديدة "WinUI 3.0" في XAML. كل شيء ينتقل إلى WinUI 3.0 ولا تحصل عناصر التحكم في نظام التشغيل على المزيد من تحديثات الميزات كما تعلم. بعد WinUI 3.0 ، إذا كان المطور لا يزال يرغب في استهداف عناصر التحكم القديمة التي يجب تطويرها باستخدام إصدارات SDK القديمة وإصدارات Visual Studio. سيكون الحفاظ على القدرة على الرجوع إلى مكتبتي تحكم Microsoft / Windows UI من XAML مجرد عائق للأسباب المذكورة سابقًا. علاوة على ذلك ، مع فصل تطوير WinUI ، يمكن أن ينتقل أخيرًا إلى مسار مستدام لـ "السماح" بتغييرات مثل هذه - وهو ما لا يمثل حتى كسرًا.

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

robloo يسعدني أن هذا سيحل بالفعل محل الإصدارات السابقة من UWP Xaml. آمل أيضًا أن ينتقل نظام التشغيل إليه من أجل Inbox Apps و Shell.

آمل أيضًا أن يكون هناك الكثير من مقاطع الفيديو للمطورين التي توضح بالتفصيل عملية الانتقال إلى WinUI 3.0 - وكيفية العمل مع WinUI 3.0 مع دورة الحياة نفسها مثل تطبيقات Win32. لا مزيد من الترطيب ، طرق أفضل لحفظ حالة الصفحة والتنقل ، إلخ.

قد يكون من المفيد (اعتمادًا على التطبيقات التي تخطط للانتقال إلى WinUI 3.0) تقديم أمثلة على أخذ Wordpad ونقل الكود إلى واجهة مستخدم جديدة مدمجة في WinUI - بالإضافة إلى استخدام تطبيق صندوق الوارد مثل Groove Music ، ونقله مرة أخرى إلى WinUI 3.0

بالنسبة إلى WinUI 3 ، يجب أن يكون هناك بعض الاتساق فيما يتعلق بوضع وظائف التطبيق في لغة التصميم.

في هذا الصدد ، إعدادات التطبيق.

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

يعتمد حقًا على ما إذا كنت تستخدم NavigationView ...

من: shaheedmalik [email protected]
تاريخ الإرسال: الخميس ، 12 سبتمبر 2019 ، الساعة 3:48:12 مساءً
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ التعليق [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] تجربة مطور WinUI 3.0 والأدوات - الإدخال مطلوب (# 1045)

بالنسبة إلى WinUI 3 ، يجب أن يكون هناك بعض الاتساق فيما يتعلق بوضع وظائف التطبيق في لغة التصميم.

في هذا الصدد ، إعدادات التطبيق.

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

-
أنت تتلقى هذا لأنك علقت.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/microsoft/microsoft-ui-xaml/issues/1045؟email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 ، أو كتم موضوع HTTPS: // جيثب. com / notifications / unsubscribe-auth / AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

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

لا ينبغي بذل جهود كبيرة وسمات تكوين المشروع غير الموثقة لجعل WinUI / XAML Islands تعمل مع C ++ / WinRT في Visual Studio.

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

بمجرد أن رأيت Surface Duo ، تساءلت عن قصة التطوير عبر الأنظمة الأساسية التي ستكون الآن بعد أن أصدرت Microsoft جهازًا يعمل بنظام Android. Xamarin.Forms لا تقطعها لعدد من الأسباب الواضحة. لقد حان الوقت لكي تتبنى Microsoft مجموعة أدوات متعددة الأنظمة الأساسية (مثل منصة UNO ولكنها منتهية ومستقرة) والتي نعلم جميعًا أنها طُلبت بأشكال مختلفة لسنوات. آمل أن يكون لدى Microsoft بعض الخطط التي لم يتم دفعها للمطورين هنا.

صرح ساتيا "لم نرغب فقط في بناء تجربة وجهاز واحد ولكن هذا يشمل جميع الأجهزة في حياتنا." إذا كنت تريد أن يأتي المطورون في هذه الرحلة كما تأمل Panos ، فهذه هي أفضل طريقة للقيام بذلك. بخلاف ذلك ، فإنك تطلب من المطورين كتابة واجهتي مستخدم منفصلتين لتوسيع "التجربة" بين Surface Duo وبقية أفراد العائلة. لا أعتقد أن هذا طلب عادل للمطورين داخل "عائلة" واحدة من الأجهزة.

يتم عرضه بشكل مختلف على كل نظام أساسي ويعرف أيضًا باسم "الشكل والمظهر الأصليان".

أنا لا أفهم هذا. من فضلك لا تفعل ، آخر شيء أريد أن يفعله تطبيق Fluent Design هو التسبب في مزيد من التناقض وليس أقل.

تحرير: تمت إزالة التعليق الأصلي

صرح ساتيا "لم نرغب فقط في بناء تجربة وجهاز واحد ولكن هذا يشمل جميع الأجهزة في حياتنا." إذا كنت تريد أن يأتي المطورون في هذه الرحلة كما تأمل Panos ، فهذه هي أفضل طريقة للقيام بذلك. بخلاف ذلك ، فإنك تطلب من المطورين كتابة واجهتي مستخدم منفصلتين لتوسيع "التجربة" بين Surface Duo وبقية أفراد العائلة. لا أعتقد أن هذا طلب عادل للمطورين داخل "عائلة" واحدة من الأجهزة.

هذا هو بالضبط سبب شعوري بالحزن لأن Duo كان Android.

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

متى سأستخدم WinUI مع WPF ، وعندما أقوم بإنشاء عنصر تحكم جديد برمز مثل:
c# public class MyControl : UserControl { ... }
سيستخدم WinUI.UserControl أو WPF.UserControl؟
هل سيتعين علينا الاختيار وكيفية التعامل معها؟

ومن المثير للاهتمام ، إذا كانت أدوات XAML ستصبح موحدة ، فهل سيكون لدينا القدرة على إنشاء نوع من ملفات xaml المشتركة؟
شيء مثل:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

هل يجب أن يكون نوعًا من اللهجة المشتركة مع مساحة اسم جذر خاصة؟ (مثل المشاريع المشتركة في Visual Studio). يمكن أن يبدو مثل xaml الشرطي.

سيستخدم WinUI.UserControl أو WPF.UserControl؟
هل سيتعين علينا الاختيار وكيفية التعامل معها؟

يجب أن يحدث هذا تلقائيًا في XAML حيث تحدد

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

هذا يخبر المترجم أنه UWP.

public class MyControl : UserControl { ... }

هذا في الواقع غير صحيح. يجب أن تصرح هكذا

public partial class MyControl { }

ليست الوراثة ضرورية لأنها تتم معالجتها بواسطة ملف .g.cs الذي يحدد الوراثة وأيضًا إطار العمل المستخدم.

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

weitzhandler أحب أن أرى هذا أيضًا !!

يجب أن تكون مشاريع نمط SDK لمشاريع C # و Cpp / WinRT ضرورية أيضًا

أعتقد أنه يجب أن يكون هناك قوالب لجميع أنماط تطبيقات Win32 و Inbox الشائعة. قائمة قصيرة من أعلى رأسي:

• شريط
• القائمة الرئيسية
• واجهة المستند المبوب
• طريقة عرض الملاحة
• الأوامر / شريط الأدوات
• عرض التنقل العلوي
• المركز / المعرض (أعلم أن هذا مهمل قليلاً)
• Treeview / MasterDetails (مستكشف الملفات ، RegEdit ، تطبيق الإدارة)

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

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

العمل مع امتداد C ++ لـ VSCode / Visual Studio. أريد أن أرى VS Code كمحرر مدعوم يوفر تجربة مماثلة لبرنامج Visual Studio. من المفترض أن يكون WinUI هو OSS وكذلك VS Code ، لذلك أعتقد أن هذا ممكن.

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

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

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

أدوات مثل Template10 و Windows Template Studio هي علامات على نقص الوظائف الأساسية.

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

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

AntiPasha هل سمعت عن تصميم Ligthweight ؟ باستخدامه يمكنك بسهولة تغيير لون التمرير دون الحاجة إلى إعادة إنشاء النمط بالكامل:

عندئذٍ يكون تغيير لون التمرير لزر ما:

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

تمت إضافة خاصية Control.CornerRadius أيضًا في 17763 SDK ويقوم فريق WinUI أيضًا بتقديم موارد قابلة للتجاوز لإضافة التطبيق أو التخصيص على مستوى الصفحة بسهولة دون الحاجة إلى إعادة تصميم عناصر التحكم: https://github.com/microsoft/microsoft-ui- xaml-specs / blob / user / chigy / roundedcorner / active / RoundedCorner / roundedcorner.md # التخصيص - الخيارات

ومن المثير للاهتمام ، إذا كانت أدوات XAML ستصبح موحدة ، فهل سيكون لدينا القدرة على إنشاء نوع من ملفات xaml المشتركة؟
شيء مثل:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

هل يجب أن يكون نوعًا من اللهجة المشتركة مع مساحة اسم جذر خاصة؟ (مثل المشاريع المشتركة في Visual Studio). يمكن أن يبدو مثل xaml الشرطي.

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

يمكننا استخدام مساحة الاسم الافتراضية للتمييز بين النظام الأساسي "المستوى الأعلى" الذي ينتمي إليه ملف xaml ، لذلك على سبيل المثال ، يمكن أن يكون لدينا مساحات الأسماء الافتراضية التالية لكل منصة XAML (غالبًا ما تكون افتراضية ، لذا خذها بحذر 😄):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
أفالونيا: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

لذلك ، لخلط WinUI مع WPF باستخدام Xaml Islands ، لديك ترميز يشبه هذا:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

ماذا تعتقد؟

تضمين التغريدة
في المثال الخاص بك لـ UWP سوف يعرض كلا الزرين ، أليس كذلك؟
أعني ، على سبيل المثال ، عندما يكون xmlns = "... / xaml / Present" هو مساحة اسم المستوى الأعلى ويكون UserControl wutg StackPanel متاحًا في كل من uwp و wpf ، فلن يكون الزر الثاني متاحًا أيضًا في كلا النظامين الأساسيين؟

عندما نتحدث عن الأدوات الموحدة ، فمن الأفضل أن نبدأ في التفكير بأن الأنظمة الأساسية ستكون موجودة كما هي اليوم

نعم ، أنا أتفق معه تمامًا.

في المثال الخاص بك لـ UWP سوف يعرض كلا الزرين ، أليس كذلك؟
أعني ، على سبيل المثال ، عندما يكون xmlns = "... / xaml / Present" هو مساحة اسم المستوى الأعلى ويكون UserControl wutg StackPanel متاحًا في كل من uwp و wpf ، فلن يكون الزر الثاني متاحًا أيضًا في كلا النظامين الأساسيين؟

Tirraon ، المثال الذي قدمته مخصص فقط لتطبيق WPF الذي يستخدم Xaml Islands لتحديث تطبيقاتهم بشكل تدريجي. إنه غير مخصص للترميز "القياسي" الذي يتم استخدامه بين تطبيقات WPF و WinUI ، فهل هذا منطقي؟

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

أنا على هاتفي الآن ، ولكن يمكنني الحصول على مزيد من التفاصيل قبل وبعد ما أقترحه بمجرد اقترابي من جهاز الكمبيوتر الخاص بي.

تضمين التغريدة
أوه ، الآن حصلت عليك ، شكرا.

تضمين التغريدة
أوه ، الآن حصلت عليك ، شكرا.

Tirraon عظيم! سعيد لأننا في نفس الصفحة ☺️

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

FWIW ، أعتقد بالتأكيد أن هناك ميزة في شيء مثل ما كنت تقترحه. لكني أحاول التركيز على شيء يمكننا إنجازه في الإطار الزمني WinUI3 / .NET5.

اكتشف كيفية عرض WinUI Xaml لبعض خطوط الأنابيب التي تترجم الإخراج إلى لوحة قماشية أصلية وتتلقى مدخلات من نظام رسائل أصلي. مثل WinUi.Adapters.DirectX و WinUI.Adapters.WASM و WinUi.Adapters.X و WinUi.Adapters.Android.

لا يعد تطبيق جميع المحولات ضروريًا عند الإطلاق ، فقط المحولات المطلوبة لدعم Windows 10.

من: Steven Kirbach [email protected]
تاريخ الإرسال: الخميس ، 7 نوفمبر 2019 ، الساعة 9:13:46 صباحًا
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ التعليق [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] تجربة مطور WinUI 3.0 والأدوات - الإدخال مطلوب (# 1045)

stevenbrix https://github.com/stevenbrix
أوه ، الآن حصلت عليك ، شكرا.

Tirraon https://github.com/Tirraon عظيم! سعيد لأننا في نفس الصفحة ☺️

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

FWIW ، أعتقد بالتأكيد أن هناك ميزة في شيء مثل ما كنت تقترحه. لكني أحاول التركيز على شيء يمكننا إنجازه في الإطار الزمني WinUI3 / .NET5.

-
أنت تتلقى هذا لأنك علقت.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/microsoft/microsoft-ui-xaml/issues/1045؟email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 ، أو إلغاء الاشتراك https://github.com/ الإخطارات / إلغاء الاشتراك - المصادقة / AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

نعم من فضلك ، سيناريو جزيرة XAML مروع في الوقت الحالي

تضمين التغريدة
يجب عليك إلقاء نظرة على أونو
https://platform.uno/
كما أنها ستدعم WinUI 3.0 لكل منصة
https://platform.uno/winui-on-windows7-via-unoplatform/

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

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

Tirraon ، نعم لقد فهمت ذلك تمامًا ، وأحب تمامًا مكان رأسك

لقد تحدثت بإيجاز مع jeromelaban والشركة حول ما

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

نعم من فضلك ، سيناريو جزيرة XAML مروع في الوقت الحالي

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

sylveon أرى تعليقاتك (الروابط أدناه) ، وهذا يبدو فظيعًا جدًا. آسف لأنك تعاني من ذلك ، وأنا واثق من أننا سنعمل على تحسينه.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

الكثير من الألم الذي تمر به يبدو مرتبطًا بنظام مشروع ، وأنا أعلم أن هذا شيء موجود على رادارات العديد من الأشخاص (على الرغم من أنني منفصل تمامًا). هل شاهدت هذا الفيديو الذي قام به عدد قليل من أعضاء فريقنا على أدوات XAML؟ يجب أن يبدأ هذا الرابط مقطع فيديو YouTube عند النقطة التي يبدأ فيها @ michael- hawker و

هناك الكثير من الأشياء التي ستجعل تجربة Xaml Island سهلة وطبيعية للاستخدام. الجانب الذي أشير إليه هو أن الطريقة الحالية لتضمين محتوى Island of UWP في WPF تشبه هذا (من الفيديو أعلاه):

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

أعتقد أنه يمكننا القيام بما هو أفضل من ذلك ، وتقديم شيء مثل هذا:

  <Grid>
   <uwp:SamplePage />
  </Grid>

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

لقد تحدثت بإيجاز مع jeromelaban والشركة حول ما

هناك الكثير من الاهتمام! (تنبثق هذه المحادثة في كل مكان) إذا تحولت WinUI post 3.0 إلى تطبيقات عبر الأنظمة الأساسية ، فستحصل على الكثير من دعم المطورين. مجرد إلقاء نظرة على المناقشة على # 1461. على المدى القصير ، سيكون استخدام Uno Platform tech لتحويل XAML / C # إلى HTML / WASM لتشغيل تطبيقات UWP على جميع الأنظمة الأساسية أمرًا رائعًا. على المدى الطويل ، أشعر بالقلق إزاء تأثير الأداء للتشغيل في Electron أو المستعرض وهناك مجال لبنية أكثر كفاءة.

خلاصة القول ، أعلم أن الجميع مشغولون باستخدام WinUI 3.0 في الوقت الحالي. ولكن عند الانتهاء من ذلك ، سيكون من الرائع أن نتواصل مع jeromelaban و @ marb2000 و jevansaks وآخرين UWP يتم عرضه في كل مكان. سيكون هذا أيضًا نقاشًا مجتمعيًا مثيرًا للاهتمام لإجراء مكالمة مستقبلية.

WinUi هو المسار العاقل الوحيد الذي يؤدي إلى بقاء كل من Neo و Duo

من: robloo [email protected]
تاريخ الإرسال: الخميس ، 7 نوفمبر 2019 ، الساعة 12:00:07 مساءً
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ أذكر [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] تجربة مطور WinUI 3.0 والأدوات - الإدخال مطلوب (# 1045)

stevenbrix https://github.com/stevenbrix

لقد تحدثت بإيجاز معjeromelaban https://github.com/jeromelaban والشركة حول ما تقترحه بالضبط ، وهناك بالتأكيد اهتمام. لا توجد خطة أو التزامات محددة حتى الآن ، لأننا ما زلنا في المراحل الأولى من المناقشات. هذا النوع من المدخلات رائع ، ويساعدنا على فهم القيمة التي يجلبها لعملائنا بشكل أفضل

هناك الكثير من الاهتمام! (تنبثق هذه المحادثة في كل مكان) إذا تحولت WinUI post 3.0 إلى تطبيقات عبر الأنظمة الأساسية ، فستحصل على الكثير من دعم المطورين. ما عليك سوى إلقاء نظرة على المناقشة على # 1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . على المدى القصير ، سيكون استخدام Uno Platform tech لتحويل XAML / C # إلى HTML / WASM لتشغيل تطبيقات UWP على جميع الأنظمة الأساسية أمرًا رائعًا. على المدى الطويل ، أشعر بالقلق إزاء تأثير الأداء للتشغيل في Electron أو المستعرض وهناك مجال لبنية أكثر كفاءة.

خلاصة القول ، أعلم أن الجميع مشغولون باستخدام WinUI 3.0 في الوقت الحالي. ولكن عند الانتهاء من ذلك ، سيكون من الرائع أن نتواصل معjeromelaban https://github.com/jeromelaban و @ marb2000 https://github.com/marb2000 وjevansaks https://github.com/jevansaks وآخرين اكتشف أفضل طريقة لعرض UWP في كل مكان. سيكون هذا أيضًا نقاشًا مجتمعيًا مثيرًا للاهتمام لإجراء مكالمة مستقبلية.

-
أنت تتلقى هذا لأنه تم ذكرك.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/microsoft/microsoft-ui-xaml/issues/1045؟email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 ، أو إلغاء الاشتراك https://github.com/ الإخطارات / إلغاء الاشتراك - المصادقة / AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi هو المسار العاقل الوحيد الذي يؤدي إلى بقاء كل من Neo و Duo

أميل إلى الموافقة ، لكنني أحصل على نفس واجهة المستخدم من تطبيق Windows ، يعمل على Android و Surface Duo. بأقل تدخل من المطور - هذا هو الكأس المقدسة.

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

أنا أقوم بإنشاء لغتي الموجهة للتطبيق وأريد دعم استخدام WinUI مع XAML ولغتي للتعليمات البرمجية الخلفية. سيكون من الجيد أن توفر الأدوات القدرة على توفير لغة لإنشاء رمز لـ XAML. ما يمكن أن يكون أفضل هو إذا قام مُنشئ كود XAML ببناء IL كفئة جزئية يمكن إكمالها باستخدام أي لغة. قد يعني ذلك أن مولد الشفرة سينتج تجميع IL قابل للترجمة.

أنا أقوم بإنشاء لغتي الموجهة للتطبيق وأريد دعم استخدام WinUI مع XAML ولغتي للتعليمات البرمجية الخلفية. سيكون من الجيد أن توفر الأدوات القدرة على توفير لغة لإنشاء رمز لـ XAML. ما يمكن أن يكون أفضل هو إذا قام مُنشئ كود XAML ببناء IL كفئة جزئية يمكن إكمالها باستخدام أي لغة. قد يعني ذلك أن مولد الشفرة سينتج تجميع IL قابل للترجمة.

يوجد XAML Direct ، لكنه مدعوم من C # و C ++ في الوقت الحالي.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

هذا ليس ما اعنيه. أعني أن ناتج أداة إنشاء الكود هو IL وليس C # أو C ++. بهذه الطريقة يمكن للمترجم أن يحول XAML إلى IL ثم يرث تلك الفئة.

sharpninja سيكون مفيدًا أيضًا ، إذا كان بإمكانه أيضًا إنشاء LLVM Bytecode بدلاً من رمز C ++ فقط.

بهذه الطريقة يمكننا دمجها مع MIDL و XLang لإنشاء مكتبة COM وملفات WinMD لاستخدامها في جميع السيناريوهات المدعومة من XLang.

مع قبعة C ++ الخاصة بي ، فإن ما أود رؤيته فيما يتعلق بأدوات WinUI لـ C ++ ، سيكون بالنسبة لـ Microsoft أخيرًا ما كان يفعله C ++ Builder منذ منتصف التسعينيات.

توفير أدوات RAD الفعلية للتطوير المستند إلى C ++.

فشلت C ++ / CLI في تحقيق ذلك ، على الرغم من وجود بعض الحلول مع النماذج.

بدا C ++ / CX كما لو كان الأمر كذلك ، لا يزال يتطلب مجهودًا أكثر قليلاً مما يمكن لـ C ++ Builder القيام به.

الآن قد تكون C ++ / WinRT قياسية C ++ 17 ، لكن التجربة الإجمالية لمطوري سطح المكتب تبدو وكأنها الرجوع إلى إصدار أقدم ، مع الزيادة في Boilerplate التي يتعين على المرء كتابتها يدويًا ، والاهتمام الإضافي بكيفية تجاوز أنواع COM لحدود ABI ونقص المصمم الدعم.

لذلك ما زلت أستخدم C ++ / CX في الوقت الحالي ، حيث لا أشعر بالتعامل مع كل النماذج التي يتطلبها مترجم MIDL ، ودعم COM ABI.

على الجانب الآخر ، مع استخدام قبعة .NET الخاصة بي ، أود أن أرى مكتبات C ++ فقط مثل DirectX تتعرض أخيرًا لمكونات WinUI ، وبعضها مزيج الحب ، وتذكر أن F # هي أيضًا لغة .NET من Microsoft.

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

هذه فكرة خطرت لي أثناء الحديث عن شريط الحالة في خلاف مجتمع UWP ..

في Visual Studio ، اجعل مربع الأدوات يتضمن إدخالات لعناصر تحكم WPF المفقودة من UWP وعندما يتم تحديد هذه الإدخالات ، اعرض نافذة منبثقة تشرح كيفية محاكاة عنصر التحكم التقليدي.

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

تعديل:
وللتأكيد ، إليك شيئًا آخر قلته عن Status Bar .. فقط أظهر كيف يمكن لشخص ما أن يتعامل مع UWP (أو WinUI) إذا لم يكن على دراية به ..

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

سيكون رائعًا إذا تم حقن المقتطفات في xaml مع حالة استخدام عادية أيضًا.

من: Gavin-Williams [email protected]
تاريخ الإرسال: الثلاثاء ، 18 فبراير 2020 ، 7:05:39 مساءً
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ أذكر [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] تجربة مطور WinUI 3.0 والأدوات - الإدخال مطلوب (# 1045)

هذه فكرة خطرت لي أثناء الحديث عن شريط الحالة في خلاف مجتمع UWP ..

في Visual Studio ، اجعل مربع الأدوات يتضمن إدخالات لعناصر تحكم WPF المفقودة من UWP وعندما يتم تحديد هذه الإدخالات ، اعرض نافذة منبثقة تشرح كيفية محاكاة عنصر التحكم التقليدي.

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

-
أنت تتلقى هذا لأنه تم ذكرك.
الرد على هذا البريد الإلكتروني مباشرة، مشاهدته على جيثب https://github.com/microsoft/microsoft-ui-xaml/issues/1045؟email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 ، أو إلغاء الاشتراك https://github.com/ الإخطارات / إلغاء الاشتراك - المصادقة / AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

يجب أن تتضمن قصة المطور نوعًا من قائمة المقارنة.

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

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

أسئلة مفتوحة)
هل سيكون مفيدًا إذا قدمنا ​​أداة ترحيل تعمل تلقائيًا على الخطوات من 1 إلى 3؟

نعم فعلا. أنا أؤيد تطبيق Windows Forms واحد "قديم" (يعني القديم عدم وجود ميزانية لإعادة الكتابة) و 2 أو 3 تطبيقات WPF القديمة. قد يكون تطبيق WinForms عالقًا ، ولكن الأداة التي تساعد في نقل تطبيقات WPF بسرعة إلى WinUI 3 ستكون رائعة!

MSIX هي طريقة التغليف الحديثة لجميع التطبيقات. بالنسبة إلى WinUI في Win32 ، هل يجب أن ندعم ClickOnce؟ ما هي طرق التعبئة والتغليف الأخرى التي يجب أن تشمل الدعم لها؟ خاصة بالنسبة لـ WinUI في Win32

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

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

كانت هذه الخطوات تتعلق بتحويل مشاريع WinUI باستخدام الإصدارات السابقة (1-2) إلى الإصدار 3.

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

آمل أن يكون هذا هو الموضوع الصحيح لنشر هذا الطلب.

Rust في حاجة ماسة إلى إطار عمل مناسب لواجهة المستخدم في الوقت الحالي. سيكون من الرائع لو كان بإمكان WinUI دعم Rust في المستقبل باستخدام SDK الأصلي وبعض الأدوات.

آمل أن يكون هذا هو الموضوع الصحيح لنشر هذا الطلب.

Rust في حاجة ماسة إلى إطار عمل مناسب لواجهة المستخدم في الوقت الحالي. سيكون من الرائع لو كان بإمكان WinUI دعم Rust في المستقبل باستخدام SDK الأصلي وبعض الأدوات.

أخبار سارة ، Rust / WinRT قيد التطوير مما سيمكن تطبيقات الصدأ من استخدام واجهات برمجة تطبيقات WinRT مثل WinUI! ألق نظرة على https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

jevansaks مرحبًا ، شكرًا على الرد! نعم ، أعرف أن Kenny يعمل على Rust / WinRT ، لكني أتساءل عما إذا كانت WinRT هي طبقة API الوحيدة التي ستدعمها WinUI؟ لست متأكدًا من مدى توافق ذلك مع حقيقة أن استخدام WinRT API من تطبيقات سطح المكتب أصبح متاحًا فقط في Windows 10 1903 ، بينما يهدف WinUI إلى دعم الإصدارات الأقدم من Windows 10.

يجب أن يعمل Rust / WinRT (مثل C ++ / WinRT) وصولاً إلى Windows 7. يعمل WinRT نفسه دائمًا على تطبيقات سطح المكتب / win32. توجد فقط بعض واجهات برمجة التطبيقات التي لديها متطلبات تخزين / uwp / حزم (وليس WinRT ككل). طالما أن WinUI لا يحتوي على هذه المتطلبات ، فستتمكن من استخدام WinUI من تطبيقات سطح المكتب عبر كل من C ++ / WinRT و Rust / WinRT على أي نظام أساسي مدعوم.

يجب أن تدعم تطبيقات WinUI Desktop "Live Tiles" و "تحديث البلاط" - مع نماذج بسيطة جيدة وأدوات SDK لإنشاء مربعات أسهل من تطبيقات UWP اليوم.

لست متأكدًا من مدى توافق ذلك مع حقيقة أن استخدام WinRT API من تطبيقات سطح المكتب أصبح متاحًا فقط في نظام التشغيل Windows 10 1903

يتم تصميم WinUI Desktop لـ WinUI 3.0 في الوقت الحالي ، وهذا من شأنه أن يمكّن تطبيقات Win32 العادية من استخدام WinUI ذي المستوى الأدنى (الخطة الحالية تنخفض إلى 1803).

يجب أن تدعم واجهة مستخدم Windows على الأقل أطر عمل MVVM الرئيسية - MVVM Light و Prism و Caliburn. لسوء الحظ ، مشكلتك الموثقة مع التغييرات التي تم إجراؤها على INotifyPropertyChanged و INotifyCollectionChanged كسر ObservableCollectionبالتأكيد يكسر MVVM Light ، وربما يكسر الإطارين الآخرين أيضًا. يعتقد أنك يجب أن تعرف.

لسوء الحظ ، فإن مشكلتك الموثقة مع التغييرات في INotifyPropertyChanged و INotifyCollectionChanged كسر ObservableCollection يكسر بالتأكيد MVVM Light ، وربما الإطارين الآخرين أيضًا. يعتقد أنك يجب أن تعرف.

شكراterrycox! نحن على علم بذلك وستتم معالجته بواسطة WinUI 3.0 RTM ، وبشكل مثالي في إنشاء معاينة قبل ذلك ؛)

terrycox Windows UI يجب أن تدعم على الأقل أطر عمل MVVM الرئيسية - MVVM Light و Prism و Caliburn. ... مشكلتك الموثقة

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

ولكن ليست هناك حاجة لمكتبة .Net UI ، بما في ذلك WinUI ، لدعم إطار عمل MVVM.

لكن أشياء مثل الأحداث والواجهات التي تدرك UIElements أنها ضرورية وهذا ما تم كسره.

من: Charles Roddie [email protected]
تاريخ الإرسال: الأربعاء ، 25 مارس 2020 2:28:46 مساءً
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: نينجا شارب [email protected] ؛ أذكر [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] تجربة مطور WinUI 3.0 والأدوات - الإدخال مطلوب (# 1045)

terrycox https://github.com/terrycox Windows UI يجب أن تدعم على الأقل أطر عمل MVVM الرئيسية - MVVM Light و Prism و Caliburn. ... مشكلتك الموثقة

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 ، أو قم بإلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

يجب استخدام أدوات Dotnet cli مع ملف. صافي النواة sdk.
أوامر مثل dotnet new و dotnet build يجب أن تكون كافية ، لا تبعية صلبة لتثبيت Visual Studio. من فضلك ، انضم بالكامل إلى عصر .Net Core!

• سيكون من الجيد إذا كان مصمم xaml سريعًا. مصمم XAML الحالي بطيء ودائمًا ما يلقي ببعض الأخطاء قائلاً أنه حدث استثناء ولن يعمل. يرجى تصحيح ذلك وتقديم مصمم قوي.

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

• شرحت مشكلتي

على غرار تعليق JensNordenbro ، هل هناك احتمال أن يعمل هذا مع رمز Vs فقط؟

أرغب في رؤية قالب تطبيق يقوم بإنشاء تطبيق .NET 5 مع واجهة مستخدم WinUI 3.0 تشير إلى تطبيق مضيف متجر .NET 5. سيسمح هذا بعدد أقل من عمليات التثبيت المتكررة لـ .NET 5.0

في تطبيق WinUI لسطح المكتب ، كيف ينتقل المرء من muxc.Window.ThisPtr إلى hWnd إلى نافذة Win32 الأصلية؟

لقد جربت للتو قوالب مايو 2020 الجديدة لـ WinUI 3 Preview 1 لسطح المكتب لأنني أحب هذه الفكرة.

لكن لدي سؤال واحد. نظرًا لأن WinUI هو النظام الأساسي لواجهة المستخدم الأصلية على Windows ، فأنا مندهش من عدم وجود اتصال لجعله جزءًا من Windows 10 أيضًا؟

كان حجم تطبيق Hello World الناتج حوالي 120 ميغابايت. بالتأكيد ، المساحة رخيصة ، لكن لم يكن لدي تبعيات بمفردي هنا. من هذا ، استهلك WinUI قدرًا كبيرًا من المساحة ، تقريبًا مثل .NET 5 المضمن نفسه. هذا لبناء x64 وحده. قم بتضمين x86 في حزمة متعددة المنصات وضاعف هذا الحجم. أضف بعض التبعيات الأخرى وقد ننظر بسهولة إلى تطبيق 300 ميغابايت لحزمه للتوزيع.

لماذا لا يعتبر WinUI 3 مجرد جزء من إصدار Windows من .NET 5؟ هل هو جزء من جهود إنشاء وحدات .NET Core؟ ولكن إذا لم يكن كذلك ، فأين هو المكان المناسب لذلك؟ حقا ماكرة كل مجلد التطبيق؟ كواجهة مستخدم Windows 10 الرسمية ...؟

أم أنه سيكون جزءًا من Windows 10 في المستقبل؟ إذا تم التعامل مع WinUI كمكتبة أنظمة وسيبدأ .NET 5 في الشحن مع Windows لاحقًا ، فسنبحث في تطبيقات صغيرة نسبيًا بدلاً من ذلك. ولكن نأمل أن تكون هذه هي بالضبط قصة Windows 10x على الأقل ، وربما أيضًا Windows 10 non-X لاحقًا؟ باستثناء هاتين المكتبتين بالإضافة إلى Windows 10 SDK C # / WinRT bridge DLL ، ينخفض ​​حجم التطبيق إلى 1-5 ميغابايت.

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

إن جعل WinUI جزءًا من Windows نفسه من شأنه أن يهزم نقطة فصل WinUI عن نظام التشغيل.

"متوفر بشكل موثوق وليس بحجم التطبيق" هو ​​مصدر القلق. أتمنى أن يتم توزيع .NET 5 بشكل مشابه.

lmcdougald أدعوك لفتح مشكلة في .NET Core Installer وأطلب .NET 5 استخدام Framework Packaging للصيانة أيضًا.

jonasnordlund هناك مناقشة أخرى # 2500 حيث نتحدث عن نشر WinRT Runtime. ربما تجد بعض الإجابة هناك. :)

@ marb2000 لقد فتحت مشكلة ، لكنني في حيرة من أمري. ألا يُنظر إلى هذا على أنه ضروري لأي تطبيق يوفر نظام التشغيل Windows 10x؟

إليك مجموعة من الميزات العديدة ، بعضها ليس WinUI مباشرة ، لكن افتقارها يؤثر بشكل مباشر على تجربة أي تطوير لعميل .NET - عملاء UWP متضمنون ، وخاصة عملاء تطبيق LoB.

• أولاً وقبل كل شيء ، الأولوية القصوى بالنسبة لي ، هي تعزيز منصة Uno. بالنسبة لي ، هذا هو ما يجعل UWP مناسبًا ، كنت سأخترق XF أو تقنية أخرى إذا لم يكن Uno موجودًا. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• واجهة برمجة تطبيقات إدارة الهوية من جانب العميل المجردة لاستخدامها من ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• دعم التعليقات التوضيحية للبيانات الكاملة وعمليات التحقق من الصحة وعناوين واجهة المستخدم وأطوال السلسلة والسمات المطلوبة وحقول القراءة فقط والعلامات المائية وما إلى ذلك وما إلى ذلك (https://bit.ly/3gcMJ3a)
• تحسين OData بحيث يصبح بديلاً مناسبًا لما كانت عليه خدمات RIA. على سبيل المثال: دعم إنشاء السمات ، تطبيقات الواجهة ، الأنواع العامة ، مستندات XML (https://github.com/OData/odata.net/issues/1746)
• جلب جميع الميزات المفقودة من WPF
• x:Bind أيضًا على جميع الميزات التي يمتلكها Binding ، مثل النطاقات أو الارتباطات المتداخلة (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• إعادة التشغيل السريع (https://github.com/microsoft/ProjectReunion/issues/44)
• أكثر من مجرد قوالب Hello World بسيطة. مثل تلك التي تستوعب تسجيل دخول المستخدم ، و MVVM ، والتوجيه ، ومشاريع x-plat (مثل Uno-Platform) ، وما إلى ذلك. وبعبارة أخرى ، يرجى إعطاء المزيد من القوة لـ WTS.
• ميزات تخطيط محرر XAML WYSIWYG كما هو الحال في WinForms ، مثل الإرساء والتباعد وما إلى ذلك - يبدو أن هذا قد اكتمل! ❤

شكرا لتجميع الخاص بك weitzhandler ، مريحة للغاية.

يتمتع فريق WinUI بعلاقة رائعة مع فريق منتج Uno (غير تابع لشركة Microsoft) وفريق Xamarin Forms / MAUI و React Native. نتعاون معهم بنشاط ونتمنى لهم مستقبلًا ناجحًا.

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

مآزر من قوالب أكثر تعقيدًا. يقوم Window Template Studio بهذه المهمة.

لقد أصدرت مشكلة لمحاولة تجميع المناطق التي تفتقر إلى WinUI مقارنةً بـ WPF # 719weitzhandler @ marb2000

مآزر من قوالب أكثر تعقيدًا. يقوم Window Template Studio بهذه المهمة.

@ marb2000 هل يمكننا إحضار Window Template Studio إلى VSIX؟ أو ربما العكس؟ ما عليك سوى استخدام Window Template Studio كوسيلة لشحن جميع قوالب WinUI3 (و Project Reunion) للمضي قدمًا؟

مآزر من قوالب أكثر تعقيدًا. يقوم Window Template Studio بهذه المهمة.

@ marb2000 هل يمكننا إحضار Window Template Studio إلى VSIX؟ أو ربما العكس؟ ما عليك سوى استخدام Window Template Studio كوسيلة لشحن جميع قوالب WinUI3 (و Project Reunion) للمضي قدمًا؟

👀crutkassibille

أقترح قضاء بعض الوقت مع C ++ Builder (VCL / FMX) و Qt Creator / Design studio لمعرفة ما هو ممكن باستخدام C ++ والأدوات الحديثة.

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

ما يهمني هو تجربة تطوير .NET ولديها تجربة مماثلة لحالات الاستخدام التي أجدها مضطرًا لاستخدام C ++ ، والتي لأي سبب من الأسباب لم يتم إتاحتها لنا.

يحقق C ++ Builder و QtCreator مثل هذه التجربة ، وسيكون موضع ترحيب إذا شعر مطورو .NET أنهم في المنزل عندما يواجهون الاضطرار إلى قضاء يومين في كتابة كود C ++ / WinRT.

لماذا جعل هذا عن مطوري .NET؟ تجربة C ++ XAML سيئة للغاية ، لا يهم إذا كنت مطور C ++ أو .NET.

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

متى سنتمكن من استخدام WinUI 3 في مشروع c ++ بدون C # أو Xaml أو مصمم؟
هل هناك أي أخبار عن تاريخ المصدر المفتوح لنواة c ++ الخاصة بـ WinUI 3؟

تحرير: أعتقد أنني حصلت على إجابة لسؤالي الأول ، يبدو أن هناك قالب مشروع c ++ WinUI 3 في WinUI 3.0 Preview 1 :

بعد تثبيت ملحق .vsix ، يمكنك إنشاء مشروع WinUI 3.0 جديد من خلال البحث عن "WinUI" واختيار أحد قوالب C # أو C ++ المتاحة.

حالة الاستخدام التي أرغب في تحسينها من قبل WinUI ، هي صنع أدوات صغيرة قائمة على واجهة المستخدم الرسومية لموظفي دعم تكنولوجيا المعلومات في الخطوط الأمامية والتي غالبًا ما تتم كتابتها في PowerShell. سيكون من الرائع أن تكون قادرًا على إنشاء هذه الأنواع من الأدوات في Visual Studio Code. حتى خيار تطوير VSCode المستند إلى C # سيكون خطوة رائعة. يشعر Visual Studio بالكامل بالثقل والتعقيد في هذه الحالة.

تستخدم بيئات المؤسسات حاليًا أدوات مثل هذه بدلاً من ذلك:

• https://poshgui.com/ (معالج XAML المستند إلى الويب)
• Sapien PowerShell Studio 2020 (ملكية)
• محرر البرنامج النصي للمسؤول (ASE) (مشروع مهجور الآن)

يتم وصف أنماط أخرى شائعة الاستخدام "استخدام Visual Studio لأنماط XAML" هنا:

• إنشاء واجهة رسومية بسيطة لبرنامج PowerShell Script
• كيفية إنشاء واجهة المستخدم الرسومية لـ PowerShell لبرامجك النصية

سؤالي في سياق سؤال mqudsi الذي طرحه في مايو ، لكن لم يرد أحد.

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

نظرًا لأن هذا تطبيق سطح مكتب ، لا يمكننا استخدام ICoreWindowInterop وقد جربت swags العشوائية مثل new HandleRef(this, ThisPtr) حيث يكون 'this' من النوع Microsoft.UI.Xaml.Window ولكن استمر في رؤية الخطأ لـ Invalid Window Handle. بمجرد أن أحصل أخيرًا على هذا hwnd ، يمكنني محاولة استخدام المزيد من COM لتغيير نمط النافذة والمشاركة مع الآخرين حتى لا يشعرون بالألم الذي أفعله الآن :).

بالنسبة لأي شخص مهتم ، هذا هو النهج السريع الذي استخدمته للاستيلاء على hWnd للنافذة الرئيسية حتى أتمكن من جعلها بلا حدود. الحل الكامل لمكافئ WPF لـ WindowStyle = لا شيء انتهى هنا .

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

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

أعتقد أنه ربما يجب أن تختفي المصطلحات UWP و Universal Windows. تحمل المصطلحات بعض الأمتعة المؤسفة التي تقود المطورين إلى الخجل.

ربما يمكننا استبدال قالب WinUI (Universal Windows) بـ WinUI (Win64)؟ إذن هل لديك خيار سطح المكتب أو المتجر؟

يعد Win64 أمرًا محيرًا - فهذا يعني أن Win32 API يدعم 32 بت فقط ، وأن UWP يدعم فقط 64 بت ، وكلاهما خاطئ.

اسم Win32 في حد ذاته يربك بالفعل الكثير من المبتدئين ، ولا نحتاج إلى Win64 لجعل الأمور أسوأ.

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

هذا هو نهجنا (مبسط للغاية):

يمكن استخدام WinUI في "نوعين" من التطبيقات التي تستهدف أجهزة مختلفة:

• يستهدف تطبيقك الكثير من الأجهزة التي تحتوي على الكثير من المدخلات وعوامل الشكل. ثم استخدم UWP. تم إنشاء UWP لذلك ؛ ومن ثم يتعين عليك تلبية متطلبات مثل نموذج التغليف ، المتجر ، نموذج التطبيق ، حاوية الأمان ، إلخ.
• يستهدف تطبيقك سطح المكتب فقط ويتطلب وصولاً كاملاً إلى نظام التشغيل. استخدم Win32 أو سطح المكتب (وهي الطريقة التي يستدعي بها Visual Studio WPF و WinForms و MFC والتطبيقات).

تتلاءم WinUI في تطبيقات UWP و

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

لدينا تطبيق UWP نريد ترحيله إلى WinUI. لا نستخدم Win32 api ، نحن نستهدف سطح المكتب فقط ولا نريد استخدام المتجر. كيف يتناسب ذلك؟

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

لدينا تطبيق UWP نريد ترحيله إلى WinUI. لا نستخدم Win32 api ، نحن نستهدف سطح المكتب فقط ولا نريد استخدام المتجر. كيف يتناسب ذلك؟

لمن التطبيق بالضبط؟

بصفتي مستهلكًا يبذل قصارى جهده لاستخدام تطبيقات UWP ، إذا لم يكن التطبيق في المتجر ، فربما لن أتطرق إليه ، ناهيك عن رؤيته.

لا تقلق shaheedmalik لن نطلب منك لمسها :-). نكتب تطبيقات الأعمال. Win32 و UWP. لدينا تطبيق UWP موجود في المتجر منذ بضع سنوات ولكنه غير مرئي في المتجر. لدينا قاعدة عملاء تجارية راسخة تعود إلى 30 عامًا. إنهم سعداء بتطبيق UWP الخاص بنا ولكنهم غير راضين عن تجربة المتجر ، لذلك نقوم بنقله خارج المتجر.

لذلك نحن نعلم أن هناك سوقًا لتطبيقات الأعمال Win64 ونعتقد أننا من بين عدد قليل من مطوري الأعمال الذين قدموا تطبيقات Win64 التي سيدفع عملاء الأعمال مقابلها. أعلم أن هناك عددًا قليلاً من المطورين في هذا الخيط الذين ينزلون في مسار Universal Windows / متعدد المنصات ، لكنهم نادرون جدًا. تستهدف معظم مطوري الأعمال في تجربتي عامل شكل معين.

إذا تحدثنا من منظور شركة مطورة استثمرت بكثافة في UWP وحققت نجاحًا تجاريًا لـ UWP ، ربما نماذج لـ WinUI (سطح المكتب) و WinUI (المتجر)؟ ما عليك سوى اتباع وسائل الإعلام التقنية للحصول على فكرة عن مدى سوء رؤية UWP كمنصة تطوير.

تضمين التغريدة
"لدينا تطبيق UWP نريد ترحيله إلى WinUI. لا نستخدم Win32 api ، نحن نستهدف سطح المكتب فقط ولا نريد استخدام المتجر. كيف يناسب ذلك؟"

فهل تريد ترحيل UWP إلى WinUI 3 ونشره خارج المتجر؟ سؤال ساذج: هل محاولة MSIX في sideload ؟ أي سبب بخلاف المتجر يمنعك من استخدام UWP؟

تضمين التغريدة
"لذلك نحن نعلم أن هناك سوقًا لتطبيقات Win64 للأعمال."

سؤال واحد ، Win64 يرمز إلى الكثير من الأشياء. على سبيل المثال ، تجميع تطبيقات لـ x64. ماذا يعني Win64 بالنسبة لك؟

@ marb2000 UWP لديها دعم ضعيف لتقارير الأعمال. نعتقد أن تغيير العلامة التجارية قد يساعد في بدء تطوير أدوات الطرف الثالث مثل مؤلفي التقارير. لقد لعبنا مع التحميل الجانبي ولكن لم يكن ذلك ممكنًا بالنسبة لنا حتى 20H1 حيث لم يتم تمكين التحميل الجانبي افتراضيًا.

نعتقد أن Win64 هو الطريق إلى الأمام على Windows. حاول Micro $ في الماضي الترويج لـ Win32 باعتباره إرثًا دون نجاح وهو الآن يتراجع عن هذا الموضع. لكن في النهاية ، يجب أن يختفي Win32 ، في حكمنا (أقول ذلك بعد 30 عامًا من تطوير Win32 بنفسي). لقد تمكنا من التغلب على معظم قيود UWP لتقديم تطبيق أعمال تشتريه الشركات. نحن قلقون من أن تكرارًا آخر لـ UWP سيكون له تأثير محدود دون إعادة تسمية العلامة التجارية.

كما يظهر الارتباك من @ marb2000 ، فإن مصطلح Win64 مستخدم بالفعل (بشكل رديء). لقد أشرت أيضًا إلى ذلك سابقًا.

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

الجميع يفهم أن sylveon UWP فاشل. نحن نحبها ولكن قلة أخرى تحبها. هذا هو سبب أهمية تغيير العلامة التجارية. ما رأيك في WinUI (Deskop) أو WinUI (Store) كقوالب للمشروع؟

WinUI (Store) ليس جيدًا لأنه يمكنك أيضًا شحن تطبيقات Win32 في المتجر ، أو شحن تطبيقات UWP خارج المتجر. WinUI (سطح المكتب) جيد ولكن.

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

إنه أمر سيء بما يكفي لإرباك المبتدئين.

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

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

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

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

أعتقد أن هناك جمهورين على الأقل يجب أخذهما في الاعتبار ؛ المطورين ومستخدمي المنتج النهائي. بصفتي مطورًا / صاحب عمل ، إذا كان لدي عميل يحتاج إلى تطبيق ، وقد تأثرت بأسماء التكنولوجيا الأساسية ، فإن وظيفتي هي زرع الثقة فيهم في أن المنتج الذي يمثله الاسم قد نضج وما يثير قلقهم في تم تحديث الماضي. من ناحية أخرى ، إذا قلت "انظر هناك هذا الشيء العظيم الجديد المسمى WinUI أو MAUI" وهم يمتلكون بالفعل منتجات WPF أو UWP أو Xamarin التي طورناها لهم ، فإن الاستجابة المتوقعة منهم ستكون "رائعًا ، الآن تطبيقاتنا مكتوبة في 2،3 أو ​​4 تقنيات مختلفة ". هذا هو المكان الذي يجب أن أبيعه فيه بعد ذلك. بالنظر إلى اختلاف جميع العملاء ، سأواجه معارضة سواء تركت الاسم كما هو أو غيرته.

المهم في النهاية (بالنسبة لي) هو أن لدينا الأدوات التي نحتاجها لكتابة تطبيقات جذابة وغنية بالميزات التي تحتوي على LTS. أشعر بالضيق عندما أرى المواعيد النهائية لمنتج ما وأتمكن من قراءة الميزة الجديدة وقائمة حل المشكلات عند إصدار المنتج. لقد أحببت هذا حول NetCore / Net5 (تغيير الاسم LOL) منذ عام 2016. (راجع للشغل ، في محاولة لإخبار عملائي أن NET5 هو ما نخطط لاستهدافه بعد عام من إقناعهم بالانتقال إلى NetCore ليس بالأمر السهل!)

في الوقت الحالي ، أريد فقط التقدم سريعًا إلى نقطة يمكنني فيها كتابة تطبيق سطح مكتب بلهجة XAML والحصول على نفس أداء العرض الذي يقدمه UWP / WinUI (بدون وضع الحماية لـ UWP). لهذا السبب وبسبب معاينة سبتمبر التي تم إسقاطها ، سأبدأ باختبار قيادة Avalonia. أحب أوجه التشابه بين WPF أثناء سماعي عن أداء العرض عبر SkiaSharp.

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

أنا أقدر لكم جميعا.

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

ولكن على الرغم من أنه قد يكون جيدًا ، فقد كان xaml بمثابة كارثة بالنسبة لـ Micro $. المطورين بشكل ساحق إما بقوا مع WinForms ، أو قفزوا بالكامل لتطوير الويب. منذ UWP ساء هجرة المطورين.

لكي تكون تقنيات xaml مستدامة ، يجب على Micro $ الفوز بملايين المطورين الذين فشلوا في ضمهم. بالنسبة لأولئك المطورين وبائعي الأدوات ووسائل الإعلام التقنية ، فإن UWP هي طريق مسدود. تكرار آخر لـ UWP لن يفوز بهم.

VagueGit لكن المطورين حريصون بما يكفي على معرفة أن المنتج

تماما أتفق معك jtbrower. كما أقدر مساعدتك لي وآمل أن ينتقد الآخرون أفكارهم. ولكن كيف تُعلم للمطورين والأدوات أن هناك نوعين مختلفين من UWP ، المتجر وسطح المكتب؟

لذلك بكل الوسائل ، أولئك الذين يرغبون في الاستمرار على طول مسار UWP يمكنهم البدء بنموذج UWP Store ، ولكن أولئك الذين يريدون سطح مكتب 64 بت ، وليس وضع الحماية والثقة الكاملة ... حسنًا ، هذا ليس UWP هو؟

تعتبر UWP في السوق معطلة. لقد تخلى جميعًا ما عدا المتعصبين عن استخدام UWP عندما انسحب Micro $ نفسه من إنشاء تطبيقاتهم الخاصة في UWP.

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

VagueGit يسعدني أنك حققت النجاح مع UWP. التسمية صعبة ، وحقيقة أننا نطلق عليها "Universal Windows Platform" ولا يمكن الدفاع عنها من قبل الغالبية العظمى من مطوري Windows تجعلها ، حسناً ، ليست "عالمية". ملخص دقيق لـ Project Reunion هو إصلاح هذا وجعل كل جانب من جوانب UWP يمكن الوصول إليه حقًا من قبل جميع مطوري Windows.

أوافق على أن UWP له اسم سيء ، إذا قمت بكتابة عبارة "UWP is" في محرك بحث ، فإن أول اقتراح تلقائي من Bing أو Google سيقدم لك هو "UWP ميت". ومع ذلك ، أعتقد أن @ marb2000 محق في أننا يجب أن نستمر في استخدام الاسم ، على الرغم من الأمتعة التي يحملها.

بالإضافة إلى ما قيل...

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

1. مكدس واجهة المستخدم (المعروف أيضًا باسم WinUI3)
2. تغليف MSIX
3. موارد MRT

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

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

JeanRoca هو رئيس الوزراء الذي يقود هذا وقد يكون لديه المزيد من المعلومات التي يمكنه مشاركتها

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

عندما يتم إصدار تطبيق UWP خارج المتجر ، تكون الحزمة .appinstaller. إذا قمنا بترقية هذا التطبيق إلى Win UI Desktop ، فستتغير حزمة المثبت من appinstaller إلى msix.

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

من وجهة نظري ، لن يتم استهلاك WinUI 3.0 من .NET Framework <= 4.8. لذلك إذا كنا نتحدث عن WinUI ، فإننا إما نتحدث عن .NET Native أو .NET 3.1 / 5 + (أو مجموعة أخرى من الارتباطات).

هل لديك أي اقتراحات حول كيفية التقدم / طرح المزيد حول حزم إطار العمل لـ .NET 5 (أو أعتقد 6 في هذه المرحلة)؟ فتحت قضية ولم أتلق أي رد. حزمة .NET 5 داخل التطبيق هي عبارة عن برنامج غير مبتدئ.

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

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

لسوء الحظ ، هناك اختلاف كبير آخر يتمثل في إجبار مطوري .NET على التخلي عن C ++ لواجهات برمجة التطبيقات مثل DirectX ، الذي يرفض فريقه بوضوح جعلها متوافقة مع UWP على الرغم من كونها تعتمد على COM.

وفي هذه العملية ، تعود إلى أيام الإنتاجية المتمثلة في كتابة MIDL يدويًا باستخدام مفكرة لطيفة مثل الخبرة ، ونسخ الملفات ، على ما يبدو لا يمكن لفريق Windows التخلي عن ATL مثل تجربة التطوير ، بدلاً من توفير تجربة مثل NET لمهام سير عمل C ++. كان C ++ / CX قريبًا جدًا من C ++ Builder ، لذلك كان لا بد من قتله باسم عناصر ISO ، حتى نتمكن من الحصول عليها مع الحظ في C ++ 23 وفي عام 2025 في VS.

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

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

لا يمكن تعديل DirectX APIs للتوافق مع WinRT لأنه سيكون بمثابة انقطاع كبير لواجهة برمجة التطبيقات للمستهلكين الحاليين ، وهذا لا يمكن أن يحدث.

تتوفر أغلفة مُدارة متعددة لـ DirectX ، مثل TerraFX وهو عبارة عن Vortice وهو عبارة عن غلاف API من طراز C #.

أما بالنسبة لـ CX ، فقد كان يجب أن يذهب بعيدًا. امتدادات اللغة الخاصة بالمترجم سيئة ومثيرة للاستياء. إنه يعيق بشكل كبير قابلية نقل الكود ، وغالبًا ما يتخلف من حيث الدعم القياسي لـ C ++ ، ويتطلب تكاملًا رأسيًا كاملًا من المكتبات الحالية. كان البديل ، WRL ، صعب الاستخدام للغاية ومفرط في الإسهاب. لذلك ، ليس من المستغرب أن الكثير من الناس (بما في ذلك قسم DX) لم يرغبوا في كتابة WinRT APIs.

يعد C ++ / WinRT حلاً أفضل بكثير ، ومن المؤسف أنه كان عليه إعادة IDL (ولكنه شر ضروري حاليًا). كان فريق C ++ يقوم بعمل أفضل بكثير في دعم المعايير من ذي قبل ، لذلك لن يكون مفاجئًا إذا حصلنا بالفعل على الفئات الوصفية قبل الانتهاء من C ++ 23 ، والتي من شأنها تحسين UX المطور بشكل جذري.

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

لا تتفاجأ من أن مجتمع تطوير Windows يتجاهل كل ما يخرج من ريدموند بمثل هذا التبرير لانخفاض الإنتاجية.

كان الشيء نفسه يحدث مع CX ... لم يكن مستخدمًا إلى حد كبير لأن مطوري C ++ لا يحبون امتدادات اللغة الاحتكارية.

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

VagueGit ، هذا سؤال رائع. في نهاية اليوم ، فإن تقنية تثبيت تطبيقات UWP و Desktop هي نفسها. أشعر أن الجواب نعم؟ أعتقد أنه اعتبارًا من مجموعات SDK الأحدث ، حتى تطبيقات UWP لها امتداد msix. (قد أكون مخطئًا ، لذا لا تقتبس مني). أنا متأكد من أنه يمكنك تجربة ذلك محليًا ومعرفة ذلك؟ adambraden لمعلوماتك.

هل لديك أي اقتراحات حول كيفية التقدم / طرح المزيد حول حزم إطار العمل لـ .NET 5 (أو أعتقد 6 في هذه المرحلة)؟ فتحت قضية ولم أتلق أي رد. حزمة .NET 5 داخل التطبيق هي عبارة عن برنامج غير مبتدئ.

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

وفي هذه العملية ، تعود إلى أيام الإنتاجية المتمثلة في كتابة MIDL يدويًا باستخدام مفكرة لطيفة مثل الخبرة ، ونسخ الملفات ، على ما يبدو لا يمكن لفريق Windows التخلي عن ATL مثل تجربة التطوير ، بدلاً من توفير تجربة مثل NET لمهام سير عمل C ++. كان C ++ / CX قريبًا جدًا من C ++ Builder ، لذلك كان لا بد من قتله باسم عناصر ISO ، حتى نتمكن من الحصول عليها مع الحظ في C ++ 23 وفي عام 2025 في VS.

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

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

شكرًا لك على الرد - أنا راضٍ عن "يدرك الجميع أن هذا شيء يجب القيام به" وسأعيش مع ثنائي متضخم لمدة عام أو نحو ذلك.

stevenbrix و VagueGit - يجب أن تظل قادرًا على استخدام ملف مثبت التطبيقات لحزم msix الخاصة بك. ملف appinstaller ليس أكثر من ملف json يوفر uri لحزمك. نظرًا لأنك ذكرت سيناريوهات المؤسسة ، يمكنك تخصيص واجهة uri الخاصة ببرنامج تثبيت التطبيقات بشكل مناسب للمواقع الداخلية ، أو جعلها مختلفة للوصول الخارجي أيضًا - وكلها تتعارض مع CDN الخاص بك. فيما يتعلق بالإصدار - نعم للتطبيقات المجمعة إذا كانت هوية الحزمة هي نفسها ، فإن تثبيت إصدار جديد سيكون له حق الوصول إلى بيانات التطبيق الحالية.

stevenbrixVagueGit سأرد بالمعلومات التي لدي حاليًا على المعالج مثل التجربة. ما زلت جديدًا جدًا في هذا الدور ، لذا لا تتردد في أخذ كل ما أقوله بحذر. مع ذلك ، يقود فريقي حاليًا الجهود في Windows Template Studio . يتيح لك هذا التطبيق حاليًا إنشاء تطبيق WPF أو UWP جديد من القوالب الموجودة في معالجنا بالصفحات والأطر التي تريدها.

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

كان الشيء نفسه يحدث مع CX ... لم يكن مستخدمًا إلى حد كبير لأن مطوري C ++ لا يحبون امتدادات اللغة الاحتكارية.

إنهم يحبونهم على clang، GCC، Intel. xlCC و PGI و CUDA و C ++ Builder وعدد كبير من الأنظمة الأساسية المضمنة.

من الواضح أن CX قد قُتل بسبب السياسة التي لا يمكن أن تقبل بيئة C ++ RAD القادمة من Microsoft ، بل تجعلنا جميعًا نقوم بعمل MDIL / ATL مع تجربة مثل المفكرة بدلاً من ذلك.

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

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

ثم لماذا البرمجة مقابل واجهة مستخدم خاصة مثل WinUI ، ما عليك سوى استخدام معايير مفتوحة مثل X Windows بدلاً من ذلك.

... كما لو كان ذلك قابلاً للاستخدام على Windows. أتجنب امتدادات المترجم لأنني أرغب في استخدام برامج التحويل البرمجي متعددة الأغراض (Clang و MSVC) للتحقق من توافق المعايير وأريد استخدام معايير C ++ أحدث.

يستخدم الكود الخاص بي C ++ 20. تفتقر العديد من امتدادات اللغات إلى دعم C ++ 17 أو حصلت عليها في وقت متأخر جدًا. سيتكرر هذا الموقف مع C ++ 20 (أو يزداد سوءًا لأن C ++ 20 بها أشياء جديدة أكثر بكثير من 17 فعل). على سبيل المثال ، لا يمكنك خلط C ++ 20 ( /std:c++latest ) و CX ( /ZW ) ، ستحصل على خطأ في المترجم يفيد بأن المحولين غير متوافقين.

استغرق الأمر حتى هذا العام حتى تدعم NVCC C ++ 17 من جانب الجهاز. ليست نظرة جيدة.

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

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

sylveon أنت محمول تمامًا C ++ 20 لـ WinUI عديم الفائدة تمامًا خارج Windows ، استمتع مع Qt بدون ملحقات أيضًا.

لأنه لم يتم ترك أي شيء آخر يستحق الاستخدام لمستخدمي سطح المكتب C ++.

شكرًا لتأكيدك على أن السياسة الحمقاء هي التي قتلت تجربة العملاء.

اقتراح أن تكون ودية مع بعضها البعض. لا يمكنني التعليق على الحجج التقنية لـ c ++ ولن أحكم على من هو على حق.
النقطة المهمة هي أن عبارات مثل go have fun with X لا تضفي أجواء ودية وتعاونية هنا. stevenbrix وآخرين يرجى التدخل إذا لزم الأمر.

شكرا hansmbakker ☺️

pjmm و sylveon أقدر المحادثة العاطفية والصادقة ، إنه لأمر رائع أن يكون لديك عملاء مثلك يهتمون بك.

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

pjmlp ، نحن غير راضين عن التجربة الحالية لـ c ++ ، ونعترف أننا بحاجة إلى القيام بشيء ما قبل c ++ metaclasses. لقد أجرينا بعض المناقشات حول c ++ / winrt الخالية من idl ، و kennykerr و @ Scottj1s تحدثا عن ذلك. كانت معظم المشكلات التي واجهتنا تتعلق بالتكامل مع WinUI ، حيث يتطلب المترجم بيانات وصفية. نريد إعادة النظر في سير العمل هذا لمعرفة ما إذا كان بإمكاننا الحصول على قصة متماسكة من شأنها تحسين تجربة المطور بشكل عام. بدلاً من إعادة C ++ / Cx ، هل ستثير اهتمامك نسخة خالية من idl من c ++ / winrt؟

فقط لتحديد التوقعات ، لا أتوقع أن أرى الكثير من التقدم هنا في عام 2020.

سأكون مهتمًا جدًا بـ C ++ / WinRT مجانًا من IDL.

تجربة IDE ليست الأفضل أيضًا. على سبيل المثال ، لا يمكننا إنشاء رد اتصال حدث من محرر XAML كما هو الحال مع C # (القائمة المنسدلة لإنشاء رد اتصال جديد لا تفعل شيئًا). انتقل إلى التعريف من محرر XAML أيضًا لا يعمل.

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

stevenbrix ، أود إضافة صوتي إلى C ++ / WinRT الخالية من IDL (وبالتأكيد لا أريد أن أرى عودة إلى C ++ / CX). نكتب برامج عبر الأنظمة الأساسية ، ونجمعها باستخدام كل من MSVC و LLVM (بما في ذلك على Windows) ، لذا فإن C ++ المتوافقة مع المعايير مهمة جدًا بالنسبة لنا.

stevenbrix ،

pjmlp ، نحن غير راضين عن التجربة الحالية لـ c ++ ، ونعترف أننا بحاجة إلى القيام بشيء ما قبل c ++ metaclasses. لقد أجرينا بعض المناقشات حول c ++ / winrt الخالية من idl ، و kennykerr و @ Scottj1s تحدثا عن ذلك. كانت معظم المشكلات التي واجهتنا تتعلق بالتكامل مع WinUI ، حيث يتطلب المترجم بيانات وصفية. نريد إعادة النظر في سير العمل هذا لمعرفة ما إذا كان بإمكاننا الحصول على قصة متماسكة من شأنها تحسين تجربة المطور بشكل عام. بدلاً من إعادة C ++ / Cx ، هل ستثير اهتمامك نسخة خالية من idl من c ++ / winrt؟

فقط لتحديد التوقعات ، لا أتوقع أن أرى الكثير من التقدم هنا في عام 2020.

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

لوضع هذا في المنظور ، مطور منذ فترة طويلة تعود خبرته في تطوير Windows إلى Windows 3.0 ، وفي الوقت الحاضر ، يعد C ++ ملائمًا لاستخدامه جنبًا إلى جنب مع التطبيقات المستندة إلى .NET ، وليس بمفرده أبدًا.

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

لم يكن Visual C ++ أبدًا _Visual_ كمنشئ C ++ ، ولا حتى مع C ++ / CLI ، نظرًا لعدم تكامله مع النماذج وتجميع AOT.

يبدو أن C ++ / CX أن Microsoft قد حصلت عليها أخيرًا ، فسنحصل بعد 25 عامًا على نفس تدفقات العمل الإنتاجية مثل استخدام Delphi / C ++ Builder جنبًا إلى جنب مع بعضنا البعض.

بدلاً من ذلك ، ما حصلنا عليه كخطوة سياسية لقتل C ++ / CX دون أي اعتبار ليدنا الإنتاجي يلوح بالمسؤولية عن الميزات المفقودة إلى ISO C ++ و WG 21 ، كما لو أن كل شيء يأخذه فريق Visual C ++ منا سيكون تم قبوله بواسطة WG 21.

وحتى إذا تم اعتماد الميزات الضرورية في النهاية بواسطة ISO C ++ ، فهل ستكون 2023 ، 2026 ، ....؟ ثم هناك بيت القصيد من متى سيتم توفير هذه الميزات بالفعل لمطوري Windows ، ما عليك سوى إلقاء نظرة على دعم الوحدات. نحن نستغرق سنوات لا نهاية لها للوصول إلى التكافؤ مع ما تقدمه لنا C ++ / CX منذ إصدار Windows 8 في عام 2012.

لذلك نظرًا لأنه بحلول عام 2020 ، لن نشهد أي تحسينات ، فإننا نتحدث بالفعل عن 9 سنوات هنا ، لذا عفوا إذا كنت أميل إلى الغضب قليلاً من كيفية إدارة كل هذا ، بالإضافة إلى المشكلات الأخرى التي لدينا للتعامل مع فشل UWP ، و Reunion ، وإعادة تشغيل .NET eco-system ، بينما طُلب منا كتابة التعليمات البرمجية كما كانت عام 2000 مع تجربة مفكرة MIDL المجردة وحساء القالب اللانهائي مثل ATL.

لذا ، نعم ، إما إصدار C ++ / WinRT مجاني من IDL ، أو على الأقل تجربة IDL مع دعم Intellisense / Intelicode الكامل وعدم الحاجة إلى نسخ الملفات يدويًا. ومع ذلك ، فإن ذلك لن يزيل ATL مثل التجربة من كود C ++ نفسه.

من وجهة نظر تطوير .NET / C ++ ، لا أهتم بالسفر عبر الزمن إلى ماضي أطر عمل Microsoft ، بل كيف يمكن أن يبدو الأمر إذا تم التعامل مع وجهة نظر C ++ RAD بجدية أكبر ، لسوء الحظ مع طريقة C ++ / لقد تمت إدارة قصة WinRT ، وكل شيء آخر يحدث الآن مع backpedaling من UWP ، أتساءل إلى أين ذهب "المطورون والمطورون والمطورون".

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

C ++ لا تزال قائمة بذاتها وثيقة الصلة بالموضوع. تمت كتابة الكثير من التطبيقات في خام C ++ بدون تشغيل أي كود مُدار. في الواقع ، فإن وقت تشغيل UWP وإطار عمل XAML / WinUI بالكامل هو C ++ الأصلي. تطبيق UWP المكتوب بلغة C ++ لا يحتوي (لحسن الحظ) على أي لغة مُدارة.

أنا أزعم أنه إذا شعرت بالحاجة إلى استخدام C ++ في .NET ، فيجب أن تسأل نفسك لماذا وتحاول معالجة هذه المشكلات مباشرةً داخل .NET. أداء؟ استخدم أنواع الامتداد ، و stackalloc ، و جوهر المتجه. DirectX أم واجهات برمجة التطبيقات الأصلية أم COM؟ استخدم رابطًا مثل TerraFX. التعامل مع lib C ++ فقط؟ أعد تنفيذ ما تحتاجه منه في .NET.

NET أفضل حالًا بدون C ++ ، و C ++ أفضل بدون .NET.

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

sylveon Easy ، نظرًا لواجهات برمجة التطبيقات التي يرفض فريق Windows إتاحتها كـ UWP ولا يتم احتساب ارتباطات طرف ثالث ، لا ينعم الجميع بإدارة قانونية تسمح لأي شيء بالمرور ، دون اعتبارات الترخيص ومشكلات الدعم المستقبلية.

أظهر كل من Borland (الآن Embarcadero) و The Qt Company كيفية القيام بذلك ، الأمر متروك لمايكروسوفت لتقرير مدى الصلة التي يريدون الاحتفاظ بالمنصة.

حاول أن ترى إلى أي مدى ستذهب مع ISO C ++ في macOS و iOS و Android و ChromeOS GUIs.

على أي حال ، التوقف هنا ، هذا لا طائل من ورائه.

pjmlp لدينا تطبيقات عبر الأنظمة الأساسية مع ملايين الأسطر من ISO C ++ التي تعمل بشكل جيد على iOS / macOS / Windows. C ++ هي اللغة الوحيدة التي يجب استخدامها عندما تهتم بالأداء و / أو عمر البطارية. امتدادات C ++ ليست جيدة بالنسبة لنا لأننا نستخدم مترجمين متعددين (من الواضح أنهم لا يطبقون امتدادات بعضهم البعض).
لقد استخدمنا C ++ / CLI سابقًا وهو أمر مؤلم للغاية. القيود مثل السماح لأعضاء الفصل فقط بمؤشرات C ++ الأولية تجعل من الصعب تخزين المؤشرات الذكية. وقت التجميع طويل (يتطلب تغيير حرف واحد 5 دقائق من وقت دمج MD).
يتضمن C ++ يتطلب التفافًا لتغيير pragma مُدار / غير مُدار
المترجم هو إصدار مختلف لـ C ++ / CLI مقارنة بـ C ++ (وقيل لي في البناء أن مترجم C ++ / CLI لن يدعم بعد C ++ 17 ، وهي مشكلة عند تضمين ترويسات من المكتبات التي تستخدم C ++ 20 ميزات).
ما أحاول قوله هو ، ليس لدي العديد من الجهود المتنافسة. التزم بالمعيار واعمل معه. Microsoft عضو في لجنة C ++ ، فهم يساعدون في دفع المعيار إلى الأمام ، يجب أن يكون هذا هو التركيز ، وليس الملكية ، مغلق في الامتدادات.

هل يمكن أن يكون لدينا مترجم xaml ، مثل xaml.exe لتجميع ملفات xaml ، مثل midl.exe أو cl.exe أو link.exe؟ سيكون من المفيد جدًا إنشاء خط أنابيب تلقائي لتطبيق winui.

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

هذا مطلوب لسيناريوهات مثل cmake: https://github.com/microsoft/ProjectReunion/issues/58

هل يمكن أن يكون لدينا مترجم xaml ، مثل xaml.exe لتجميع ملفات xaml ، مثل midl.exe أو cl.exe أو link.exe؟ سيكون من المفيد جدًا إنشاء خط أنابيب تلقائي لتطبيق winui.

sammi هل # 1433 يلخص الحل المعقول لما تبحث عنه؟

هل يمكن أن يكون لدينا مترجم xaml ، مثل xaml.exe لتجميع ملفات xaml ، مثل midl.exe أو cl.exe أو link.exe؟ سيكون من المفيد جدًا إنشاء خط أنابيب تلقائي لتطبيق winui.

sammi هل # 1433 يلخص الحل المعقول لما تبحث عنه؟

jtbrower ، هذه هي بالضبط الميزة التي أبحث عنها ، شكرًا!

من المؤكد أنها معاينة ، وهذا يعني أنه لا ينبغي أن أتوقع الكثير ، لكن WinUI 3 preview 2 كانت مخيبة للآمال بالنسبة لي.

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

نعم ، أوافق على أن مصمم XAML الحالي في Visual Studio بطيء جدًا ، ويتعطل عندما يغير المرء أشياء في الوقت الفعلي لا ينبغي أن يكسرها حقًا. على سبيل المثال ، تغيير Height="*" إلى "Auto" أو 100. (تظهر نافذة الخطأ حوالي 10 أخطاء - تمايل وافر ، وعليك إعادة بناء المشروع)

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

بعد كل ما قيل ، لدى WinUI فكرة رائعة - افصل كل هذه الأشياء "السهلة" عن نظام التشغيل ، ودع عمل المطور يتطور بسرعة أكبر ، ويمكننا تجميع التبعيات مع التطبيق لتجنب الاضطرار إلى ترقية أجهزة 1Bn حتى يتمكنوا من تشغيل الأشياء الرائعة الجديدة.

آمل أن ينتهي Project Reunion أيضًا بفصل واجهة المستخدم الرسومية تمامًا عن حاوية التطبيق. ستكون UX التي تشبه UWP بدون وضع حماية / حدود خطوة رائعة إلى الأمام.

ولكن متى يمكن أن يكون لدينا مصمم XAML يعمل مرة أخرى ... من فضلك؟

أعتقد أن إعادة التحميل السريع قد أهملت في الغالب غرض "العرض فقط" لمصمم XAML.

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

ما قصدته بمصمم العرض فقط هو "يمكنني قبول ذلك إذا كان شيئًا يمكننا وضعه في معاينة قادمة"

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

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

ما قصدته بمصمم العرض فقط هو "يمكنني قبول ذلك إذا كان شيئًا يمكننا وضعه في معاينة قادمة"

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

مرحبًا @ ericleigh007 هل أتيحت لك الفرصة للتحقق من أحدث إصدار من WinUI 3 Preview 3؟ لقد أضفنا مؤخرًا العديد من تحسينات الأدوات مثل IntelliSense و Hot Reload و Live Visual Tree و Live Property Explorer. يمكنك التحقق من ملاحظات الإصدار هنا والحصول على أحدث معاينة هنا . أنا مهتم بأفكارك ، لذا لا تتردد في التواصل معي!

JeanRoca للأسف ، لم

يجعلني أبقى في .NET بقدر ما أستطيع ، أو استمر في استخدام C ++ / CX على الرغم من التحذيرات للانتقال إلى C ++ / WinRT.

شكرا للتحديث؛ سوف نحاول ذلك اليوم ، وسوف يقدم تقريرا. 🤞

تم الإرسال من البريد https://go.microsoft.com/fwlink/؟LinkId=550986 لنظام التشغيل Windows 10

من: JeanRoca [email protected]
تاريخ الإرسال: الأربعاء ، 18 نوفمبر 2020 ، الساعة 4:41 صباحًا
إلى: microsoft / microsoft-ui-xaml [email protected]
نسخة إلى: Eric [email protected] ؛ أذكر [email protected]
الموضوع: Re: [microsoft / microsoft-ui-xaml] تجربة مطور WinUI 3.0 والأدوات - الإدخال مطلوب (# 1045)

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

ما قصدته بمصمم العرض فقط هو "يمكنني قبول ذلك إذا كان شيئًا يمكننا وضعه في معاينة قادمة"

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

مرحبًا @ ericleigh007 https://eur05.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fericleigh007&data=04٪7C01٪7C٪7Cae66199f9c044a728fb108d88b7c470d٪7 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0٪ 3D٪ 7C1000 & sdata = jha7IQJyg٪ 2BKEZJKfKiV2luMzIiLCJBTiI6Ik1haWwiLCJBTiI6Ik1haWwiLCJBTiI6Ik1haWwiLCJBTiI6Ik1haWiLCJBTiI6Ik1haWwiLCJXVCI6Mn0٪ 3D٪ 7C1000 & sdata = jha7IQJyg٪ 2BKEZJKfKiG هل لديك فرصة لإصدار٪ 2BKEZKvWKF2LJAwmda لقد أضفنا مؤخرًا العديد من تحسينات الأدوات مثل IntelliSense و Hot Reload و Live Visual Tree و Live Property Explorer. يمكنك التحقق من ملاحظات الإصدار هنا https://eur05.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fmicrosoft٪2Fmicrosoft-ui-xaml٪2Fissues٪2F3620&data=04٪7C01٪ 7C٪ 7Cae66199f9c044a728fb108d88b7c470d٪ 7C84df9e7fe9f640afb435aaaaaaaaaaaa٪ 7C1٪ 7C0٪ 7C637412713160082691٪ 7CUnknown٪ 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0٪ 3D٪ 7C1000 وsdata = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE٪ 3D & محفوظة = 0 والحصول على أحدث المعاينة هنا https://eur05.safelinks.protection.outlook.com/؟url=https٪ 3A٪ 2F٪ 2Fdocs.microsoft.com٪ 2Fen لنا٪ 2Fwindows٪ 2Fapps٪ 2Fwinui٪ 2Fwinui3٪ 2F & البيانات = 04٪ 7C01٪ 7C٪ 7Cae66199f9c044a728fb108d88b7c470d٪ 7C84df9e7fe9f640afb435aaaaaaaaaaaa٪ 7C1٪ 7C0٪ 7C637412713160092685٪ 7CUnknown٪ 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0٪ 3D٪ 7C1000 وsdata = VF2s7jilqpksevP6Fx7mXW1QCNJN2٪ 2BK5yWOndg3rKoc٪ 3D & محفوظة = 0 . أنا مهتم بأفكارك ، لذا لا تتردد في التواصل معي!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، واعرضها على GitHub https://eur05.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fmicrosoft٪2Fmicrosoft-ui-xaml٪2Fissues٪2F1045٪23issuecomment -729402012 والبيانات = 04٪ 7C01٪ 7C٪ 7Cae66199f9c044a728fb108d88b7c470d٪ 7C84df9e7fe9f640afb435aaaaaaaaaaaa٪ 7C1٪ 7C0٪ 7C637412713160092685٪ 7CUnknown٪ 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0٪ 3D٪ 7C1000 وsdata = R1S2JpfBSzsNKJBAH5٪ 2Fgme8Bq٪ 2FjHbzB9FySk1KnZKbk٪ 3D & محفوظة = 0 ، أو إلغاء الاشتراك الشبكي: //eur05.safelinks.protection.outlook كوم /؟ URL = الشبكي٪ 3A٪ 2F٪ 2Fgithub.com٪ 2Fnotifications٪ 2Funsubscribe-المصادقة٪ 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ والبيانات = 04٪ 7C01٪ 7C٪ 7Cae66199f9c044a728fb108d88b7c470d٪ 7C84df9e7fe9f640afb435aaaaaaaaaaaa٪ 7C1٪ 7C0٪ 7C637412713160102680٪ 7CUnknown٪ 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0٪ 3D٪ 7C1000 وsdata = 0H6IpND3YX1s6oyXy٪ 2FCXNAMN9n8fvSPdWks٪ 2FfmXT0Bc٪ 3D ومحجوز = 0 .

- لا يوجد محرر / طريقة wysiwyg تعمل مع winui3 c ++ (سطح المكتب) الآن ، أليس كذلك؟

مايكروسوفت تتعامل مع مستخدمي C ++ / CX أيضًا؟ هذا الأمر برمته لا يتشكل بشكل جيد على الإطلاق. أي شخص اعتمد التكنولوجيا التي كانت مايكروسوفت تدفعها قبل بضع سنوات من أجل UWP سواء كان .net أو C ++ ، يواجه مشكلة الآن دون دعم من Microsoft.

يبدو أن WinUI 3 يخدم فقط تطبيقات سطح المكتب المكتوبة في WPF - لكنهم سيدركون بسرعة أن UWP لا يزال لا يحتوي على جميع ميزات WPF و WinUI الأقل. سيصاب الجميع بالإحباط وهو مكان سيء لبدء WinUI 3.

robloo كشخص اعتاد على الدفاع عن يفرزوا الفوضى.

كانت C ++ / WinRT خطوة سياسية ، وقد طُلب منا فقط أن نمتصها وننتظر حتى توفر ISO C ++ في النهاية دعمًا للانعكاس والفئات الوصفية ، لفريق Visual Studio لتكرار تجربة C ++ / CX.

كما ذكرنا ، فإن تحرير ملفات IDL لا يختلف عن استخدام برنامج Notepad الخام.

لقد كان علينا في .NET أن نتحمل مع Microsoft لعدم إتاحة جميع مكونات UWP لنا ​​، كان ممنوعًا إلى حد ما مع C ++ / CX التي تقدم تجربة مثل C ++ / CLI. الآن مع C ++ / WinRT عدنا إلى ATL.

ثم من خلال قراءة مناقشات قضايا ريونيون وخريطة الطريق المحدثة ، من الواضح أنهم سيستغرقون عدة سنوات لتصحيح المسار.

قد يكون WPF و Win32 قديمين ، لكنهما موجودان هنا ويعملان ، دون الحاجة إلى إعادة كتابة أخرى وفقدان الميزات.

- لا يوجد محرر / طريقة wysiwyg تعمل مع winui3 c ++ (سطح المكتب) الآن ، أليس كذلك؟

يعمل نوع مصمم XAML ، لكنه لم يكن مصممًا حقًا لتحرير wysiwyg لتبدأ به. إعادة التحميل السريع (الذي يعمل الآن في المعاينة 3) يعمل بشكل أفضل.

تعمل الشجرة المرئية الحية وعرض العناصر الحية بشكل رائع في المعاينة 3. متى تمت جدولة المصمم ليكون متاحًا؟

لاحظت أيضًا أن مصمم سطح المكتب (WPF) (وليس UWP) كان يعمل في 2.4 (أو شيء من هذا القبيل) ولكن الآن لا ترى اختباراتي أنه يعمل مرة أخرى؟ هل أفتقد شيئًا ما مع الوضع الحالي للمصمم؟

آسف لأنني تأخرت على الحفلة. wjk مسمرًا

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

إنني أقدر حقًا جاذبية MSIX ، لكن تفويض توقيع الشهادة هذا يعد بمثابة كسر للصفقة بالنسبة لي. أحتاج إلى معالج مثبت مناسب مناسب لـ SCM يمكنني استخدامه لإنشاء تجربة مثبت سطح المكتب الكلاسيكية. لماذا لا تأخذ التحسينات في MSIX وتنشئ إصدارًا جديدًا من MSI installer دون الحاجة إلى Microsoft Store ومتطلبات الشهادة للحصول على تجربة تطوير أكثر حداثة؟ ربما هذا هو المقصود بميزة "يدعم النشر بخلاف MSIX" المدرجة في خارطة الطريق الحالية؟ إذا كان الأمر كذلك ، أعتقد أنني عالق في انتظار 3.x ، ما لم يكن ذلك بمعجزة ما ، مما يجعله في إصدار سابق. نتطلع إلى ذلك لأن مشاريع VS Installer قديمة بشكل مأساوي وليست صديقة على الإطلاق للتحكم في المصدر. 😓

Chiramisu أتفق مع المشاعر ، لكنني أيضًا مرتبك - ماذا عن تجربة التحميل الجانبي + AppInstaller ليست كافية؟

Chiramisu هل جربت WiX ؟ أستخدمه لجميع أدوات التثبيت المستندة إلى MSI ، وهو يعمل بشكل جيد للغاية. يوجد أيضًا ملحق Visual Studio ، بحيث يمكنك الحصول على مشاريع WiX التي تعمل على أتمتة أوامر التجميع المختلفة.

robloo كشخص اعتاد على الدفاع عن يفرزوا الفوضى.

كانت C ++ / WinRT خطوة سياسية ، وقد طُلب منا فقط أن نمتصها وننتظر حتى توفر ISO C ++ في النهاية دعمًا للانعكاس والفئات الوصفية ، لفريق Visual Studio لتكرار تجربة C ++ / CX.

كما ذكرنا ، فإن تحرير ملفات IDL لا يختلف عن استخدام برنامج Notepad الخام.

لقد كان علينا في .NET أن نتحمل مع Microsoft لعدم إتاحة جميع مكونات UWP لنا ​​، كان ممنوعًا إلى حد ما مع C ++ / CX التي تقدم تجربة مثل C ++ / CLI. الآن مع C ++ / WinRT عدنا إلى ATL.

ثم من خلال قراءة مناقشات قضايا ريونيون وخريطة الطريق المحدثة ، من الواضح أنهم سيستغرقون عدة سنوات لتصحيح المسار.

قد يكون WPF و Win32 قديمين ، لكنهما موجودان هنا ويعملان ، دون الحاجة إلى إعادة كتابة أخرى وفقدان الميزات.

فقط حتى أتمكن من المواكبة ، هل يمكنك أن تدلني في أحد ما هو تحرير IDL الذي تتحدث عنه باستخدام C ++ / WinRT؟ من خلال ما رأيته من صيغة co_await وصيغة C ++ 17 الأخرى ، يبدو أن التعقيد قد ارتفع بمقدار كبير من C ++ / CX.

السيدة؟ أليس من الممكن أن يكون C ++ / WinRT المستند إلى قدرات C ++ 17 معقدًا جدًا ومختلفًا جدًا عن التصميمات الحالية ، ما لم يقم شخص ما بإنشاء بعض الأغلفة الجيدة حقًا حول ذلك؟ ألا يمكن الاحتفاظ بـ C ++ / CX بشكل كافٍ لإنشاء بعض "المجمعات الممتازة" لـ C ++ 17 لجعل C ++ / WinRT سهلة الاستخدام والترحيل إليها؟

(الآن شخص ما سيربط بمقال يوضح كيف يتم ذلك ، وسأشعر بالغباء)

lmcdougald لم أحاول ذلك بعد. وتجدر الإشارة إلى أن مشروعي الخاص لا يزال يعمل على .NET Framework 3.5. اعلم اعلم. لم يُسمح لي بتحديثه حتى الآن ، لذلك أنا عالق مع تقنية Installer التي ستعمل مع هذا الإطار القديم. 😖

wjk لقد بحثت في ذلك في الماضي ، لكن لا ، لم

بلطف

Chiramisu نعم ، يعمل WiX مع الإصدارات القديمة من .NET Framework ، ونعم ، فهو يعمل أيضًا مع تطبيقات winforms. نظرًا لأنه ينشئ ملفات MSI خام ، يمكن لـ WiX تثبيت أي شيء بأي لغة برمجة. فيما يتعلق بتعلمها ، سأبدأ بالدروس التعليمية الأساسية . أود أيضًا أن أوضح كيفية اكتشاف ما إذا كان NET مثبتًا ، وكيفية تشغيل NGEN على الملفات باستخدام WiX ، نظرًا لأنك تستخدم هذه التقنيات في تطبيقك. يأتي ملحق Visual Studio أيضًا مع عدد من قوالب المشروع ، لمنحك رمز الهيكل العظمي المناسب للإضافة إليه. (ملاحظة: لا تستخدم قالب Bootstrapper ، لأنه موضوع أكثر تقدمًا.) أتمنى أن يساعدك هذا!

Chiramisu أنا في حيرة من

تجدر الإشارة إلى أنه يمكن تجميع .NET Framework 3.5 في MSIX. يمكنك إنشاء حزمة MSIX لتطبيقك الحالي باستخدام Package Project في VS 2019 ، ثم تمر بمرحلة انتقالية طويلة إلى حد ما بسلاسة ، ولكنها تتطلب الكثير من العمل:

لن يدعم WinUI 3.0 رسميًا .NET 3.5 أبدًا ، وربما لن يدعم NET Framework في أي إصدار. سأبدأ التحديث الخاص بك من خلال محاولة الترقية إلى .NET 4.6 (أو أعلى من ذلك ، سيكون 4.8 مثاليًا) دون تغيير مشروع التعبئة والتغليف الحالي الخاص بك. إذا سارت الأمور بسلاسة ، فسأبدأ بعد ذلك في نقل الوظيفة إلى مكتبة .NET Standard المشتركة التي تشير إليها من تطبيق .NET 4.6+ المحدّث.

بمجرد استقرار تطبيق .NET 4.6 واختباره ، يمكنك تبديله كتحديث تلقائي لمشروع تغليف MSIX الخاص بك. بعد خطوة .NET Standard ، يمكنك إنشاء رئيس مشروع يستخدم نفس الرمز تقريبًا من .NET Core 3.1 (أو 5 ، ولكني أشعر أن حالة LTS تعني شيئًا لمؤسستك على الأرجح). مرة أخرى ، اختبر ثم قم بتبديل MSIX لاستخدام هذا الإصدار.

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

هذه هي الطريقة التي سأقوم بها في التحديث دون إنشاء مشاريع شديدة التباين في أي نقطة معينة. أود إعطاء الأولوية لإعداد حزمة MSIX وخطوات .NET 4.6 + .NET القياسية ، حيث ستكسبك هذه الخطوات قدرًا هائلاً من أدوات المساعدة والاتصال بدورة تطوير .NET الحديثة. يبدو التبديل إلى .NET 5 بسرعة فكرة سيئة لمؤسستك على المدى القصير ، مع الأخذ في الاعتبار أن دورة حياتها هي 1/10 طالما أن .NET 3.5 كانت موجودة.

فقط حتى أتمكن من المواكبة ، هل يمكنك أن تدلني في أحد ما هو تحرير IDL الذي تتحدث عنه باستخدام C ++ / WinRT؟ من خلال ما رأيته من صيغة co_await وصيغة C ++ 17 الأخرى ، يبدو أن التعقيد قد ارتفع بمقدار كبير من C ++ / CX.

السيدة؟ أليس من الممكن أن يكون C ++ / WinRT المستند إلى قدرات C ++ 17 معقدًا جدًا ومختلفًا جدًا عن التصميمات الحالية ، ما لم يقم شخص ما بإنشاء بعض الأغلفة الجيدة حقًا حول ذلك؟ ألا يمكن الاحتفاظ بـ C ++ / CX بشكل كافٍ لإنشاء بعض "المجمعات الممتازة" لـ C ++ 17 لجعل C ++ / WinRT سهلة الاستخدام والترحيل إليها؟

(الآن شخص ما سيربط بمقال يوضح كيف يتم ذلك ، وسأشعر بالغباء)

نظرًا لأن C ++ العادي لا يحتوي على القدرات اللازمة لاستخراج البيانات الوصفية من النوع المطلوب لإنشاء ملف. winmd ، يجب عليك كتابة فئات WinRT في ملف .idl ، أعلى .hpp و .cpp.

co_await أقل تعقيدًا بكثير من كتابة .then([=](Foo^ thing) { }) كل مكان ، فهو مشابه جدًا لصيغة C # await .

فيما يلي مثال (idl + hpp + cpp) من مشروع Runtime Component الافتراضي:

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

إليك مثال صغير على شريك:

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

أهلا،

نحن نقرأ ملاحظاتك ونقوم بتدوين ملاحظات حول نقاط الألم.

@ ericleigh007 كان مصمم XAML بالخارج لأنه بعد جمع ملاحظات العملاء ، كانت أهم نقاط الألم لدى العميل تتعلق بتحسين الحلقة الداخلية للمطور. كان Hot Reload و Live Visual Tree في المقدمة. شريط الأدوات داخل التطبيق هو آخر في الجزء العلوي أنه لا يمكنه عمل معاينة 3. أنت محق في عدم توضيح متى سيكون مصمم XAML ؛ نحن بحاجة إلى تحديث فكرة خارطة طريق الميزة . وفقًا للخطة الهندسية الحالية ، فهي خارج 3.0 RTM ، لذا فهي ما بعد 3.0.

pjmlp أنا أتعاطف مع الرسم الخاص بك حول C ++ / WinRT والحاجة إلى إضافة IDLs. C ++ / CX أفضل بكثير في هذا الجانب. يعد تحسين تجربة C ++ / WinRT موضوعًا آخر نحتاج إلى معالجته. تعمل أدوات مثل Live Visual Tree و Hot Reload على كل من C # و C ++ ، ولكن هناك أشياء محددة تؤثر فقط على C ++ وتحتاج إلى فصلها. وفقًا للخطة الهندسية الحالية ، يعد حل مشكلة IDL خارج نطاق 3.0 RTM.

robloo ، نحن لا

Chiramisu اسمحوا لي أن أشرح معنى "يدعم نشر غير MSIX". تحتاج اليوم إلى تثبيت وتشغيل تطبيق Desktop WinUI 3 باستخدام MSIX. هذه القدرة هي حول إزالة هذه الحاجة. لتشغيل تطبيق Desktop WinUI 3 ، ما عليك سوى مضاعفة ملف .EXE ، وهذا كل شيء. لتثبيت التطبيق الخاص بك ، يمكنك فقط إجراء xcopy (لا حاجة لتوقيع أي شيء). في الأساس ، ستتمكن من استخدام أنظمة التعبئة والتغليف والتثبيت الأخرى مثل WiX.

@ marb2000 شكرا

في الوقت الحالي ، أركز على ASP.NET و WFP و Win32 ، فقط استمر في متابعة أشياء UWP على أمل أن تدرك Microsoft في النهاية أننا سئمنا إعادة كتابة التطبيقات وسحبنا على التكوينات اليدوية ، كما هو الحال في UAP => UWP الانتقال ، .NET Framework إلى .NET Core ، أو نعم C ++ / CX => C ++ / WinRT.

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

pjmlp لست متأكدًا من سبب

pjmlp لست متأكدًا من سبب

هذه هي المشكلة بالضبط ، صفر دعم الأدوات مقابل تجربة تطوير C ++ / CX في Visual Studio.

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

هذا مثل القيام بـ ATL مرة أخرى في اليوم.

لا يهمني التوافق مع ISO C ++ ، فإن UWP هو على أي حال Windows فقط ولا يوجد أي مترجمين لـ C ++ بدون امتدادات اللغة.

أخفق في رؤية كيف يمكن لأي شخص أن يرى هذا على أنه تقدم ، بخلاف شباب WinDev الذين كانوا المستخدمين الوحيدين لـ WRL.

pjmlp ،

لا يهمني التوافق مع ISO C ++ ، فإن UWP هو على أي حال Windows فقط ولا يوجد أي مترجمين لـ C ++ بدون امتدادات اللغة.

بالنسبة لأولئك منا الذين يكتبون تطبيقات كبيرة عبر منصات C ++ ، فإن الامتثال للمعايير يعد أمرًا مهمًا. كانت قيود C ++ / CX مروعة (لا توجد متغيرات عضو ليست مؤشرات أولية ، قبعات! ( ^ ) إلخ). لدينا حاليًا مكتبة إمكانية التشغيل المتداخل C ++ / CLI كبيرة ، ونقاط الألم كثيرة جدًا بحيث يتعذر سردها.

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

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

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

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

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

لقد كنت أقوم بالترميز لأنظمة Microsoft الأساسية منذ MS-DOS 3.3 ، وأضفت C ++ إلى صندوق الأدوات الخاص بي في عام 1992 باستخدام Turbo C ++ 1.0 ، واستخدمت معظم منتجات Borland و Microsoft فيما يتعلق بتطوير C ++. لا تحتاج إلى أي محاضرة حول ماهية C ++ / WinRT.

ما هو ليس كذلك بالتأكيد ، هو تطابق تجربة مطور C ++ Builder و Qt (مع Qt Designer) ، حيث أظهر C ++ / CX الوعد باللحاق به في النهاية ، بعد 25 عامًا.

ولكن يبدو أن معظم الناس هنا يريدون فقط Visual C ++ 6.0 مع ATL 3.0 ، ويجب على البقية منا الالتزام بتجربة سطح المكتب .NET 5 و WPF و Win32 ، لأننا أقلية لا تستحق الدراسة ، وإلا لما امتلكنا C ++ / WinRT أبدًا تم دفعه بالطريقة التي كان عليها.

لنكن صادقين ، C ++ / WinRT يبلغ عمرها الآن 4 سنوات تقريبًا ، ولم تكن Microsoft قادرة حتى على تقديم الدعم حتى لإبراز بناء الجملة و intelisense؟

شيء صنعه البعض منا في Notepad ++ (تمييز بناء الجملة) ، حقًا؟

إنه يظهر بالتأكيد مكان الأولويات ، وليس بهذه الطريقة سيكتسب WinUI التبني ، العديد من عمليات إعادة الكتابة منذ Windows 8.

pjmlp ، مرة أخرى أنت تتحدث عن الأشياء الخاطئة. C ++ / WinRT هو C ++ فقط ، لذلك فهو يحتوي على تمييز بناء الجملة ولديه دعم Intellisense. تمامًا مثل أي كود C ++ آخر لديك.

يمكن أن يكون تكامل IDE أفضل ، كما ذكرتم تمييز بناء جملة IDL وأشياء مثل اقتراح إنشاء تطبيق افتراضي في .hpp و .cpp من IDL (مثل كيف تطالبك وظيفة معلنة حاليًا بدون تعريف في الرأس بخطوط خضراء إلى إنشاء واحدة) ، ولكن العودة إلى C ++ / CX هو صافي IMO للرجوع إلى إصدار سابق. سيتطلب الأمر الكثير من الجهد لدمج جميع المكتبات والرمز المشترك الذي أستخدمه مع C ++ / CX ، وإجباري على الرجوع إلى إصدار سابق لمشروعي من C ++ 20 إلى C ++ 17 (وهو ما لا أريد التخلي عنه ، 20 يعطيني الكثير من الأشياء الجيدة).

يعد C ++ / WinRT أيضًا أقل تدخلاً من C ++ / CX عندما تريد البرامج فقط استهلاك فئات WinRT ، وليس تأليفها.

يحقق Qt و C ++ Builder خبرتهما في معايير C ++ المتوافقة في الغالب (لاحظ أن Qt لديها شيء مشابه لـ IDL ، المسمى Qt MOC). إذا كان ذلك ممكنًا ، فيمكن لـ VS. إنه يتطلب فقط المزيد من الحب من شخص ما في DevDiv.

وكما ذكرت سابقًا sylveon ، نحن أحرار في البناء مع المجمعين الآخرين (نحن نبني حاليًا باستخدام MSVC و Clang / LLVM). مع C ++ / CX أو ملحقات MS الأخرى ، سيكون هذا مستحيلًا.

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

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

استمتع باستخدام C ++ / WinRT المتوافق مع المعايير.

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

pjmlp أعتقد أنني أفهم بالضبط ما تعنيه.

منذ عام أو نحو ذلك ، تخليت عن فكرة نقل كود UWP C ++ / CX الخاص بي إلى C ++ / WinRT. كان الحافز على النقل هو القدرة على استخدام Clang لتجميع تطبيق UWP الخاص بي لأن MSVC ++ يحتوي على خطأ أبلغت عنه منذ حوالي 18 شهرًا ، لكن يبدو أنهم ببساطة لا يهتمون بالإصلاح.

ومع ذلك ، اتضح بعد ذلك أن Visual Studio لا يدعم إنشاء تطبيقات UWP باستخدام Clang. رائع ، لذا فإن ميزة "ISO C ++ فقط" لـ C ++ / WinRT خرجت مباشرة من النافذة. أضف إلى ذلك حقيقة أن نقل قاعدة كود C ++ / CX عبر C ++ / WinRT يشبه السفر 20 عامًا إلى الوراء.

لقد تخليت بشكل أساسي عن نقل تطبيقات Android / iOS الخاصة بنا إلى Windows. ببساطة ، ليس من المجدي لمتجر صغير مثلنا التعامل مع Clusterfuck وهو تطوير تطبيقات Windows بالإضافة إلى التطوير لنظام Android / iOS.

MarkIngramUK يبدو أنك ببساطة لا

الآن ، بعد التشدق الخاص بي ، ها هي مدخلاتي:

دعم استخدام WinUI 3 مع C ++ / CX. بمجرد قبول الأدوات الخاصة بـ C ++ / WinRT للشركات التي لا تملك الموارد اللازمة لبناء الأدوات الخاصة بها ، قد يكون من المناسب التبديل إلى C ++ / WinRT. الآن هو بالتأكيد ليس كذلك.

pjmlp أعتقد أنني أفهم بالضبط ما تعنيه.

منذ عام أو نحو ذلك ، تخليت عن فكرة نقل كود UWP C ++ / CX الخاص بي إلى C ++ / WinRT. كان الحافز على النقل هو القدرة على استخدام Clang لتجميع تطبيق UWP الخاص بي لأن MSVC ++ يحتوي على خطأ أبلغت عنه منذ حوالي 18 شهرًا ، لكن يبدو أنهم ببساطة لا يهتمون بالإصلاح.

ومع ذلك ، اتضح بعد ذلك أن Visual Studio لا يدعم إنشاء تطبيقات UWP باستخدام Clang. رائع ، لذلك خرجت ميزة "ISO C ++ فقط" من C ++ / WinRT مباشرة من النافذة. أضف إلى ذلك حقيقة أن نقل قاعدة كود C ++ / CX عبر C ++ / WinRT يشبه السفر 20 عامًا إلى الوراء.

لقد تخليت بشكل أساسي عن نقل تطبيقات Android / iOS الخاصة بنا إلى Windows. ببساطة ، ليس من المجدي لمتجر صغير مثلنا التعامل مع Clusterfuck وهو تطوير تطبيقات Windows بالإضافة إلى التطوير لنظام Android / iOS.

MarkIngramUK يبدو أنك ببساطة لا

الآن ، بعد التشدق الخاص بي ، ها هي مدخلاتي:

دعم استخدام WinUI 3 مع C ++ / CX. بمجرد قبول الأدوات الخاصة بـ C ++ / WinRT للشركات التي لا تملك الموارد اللازمة لبناء الأدوات الخاصة بها ، قد يكون من المناسب التبديل إلى C ++ / WinRT. الآن هو بالتأكيد ليس كذلك.

بدافع الفضول ، ما الذي تم الإبلاغ عنه قبل 18 شهرًا؟ هل لديك رابط لها في أي مكان؟

مرحبا ميغيل ،
___ تم تعديله لإصلاح الحالة المروعة للأشياء بعد الرد من Outlook لنظام Android___

كان لدي فكرة قد تجعل أهدافك للمعاينات والإصدارات واضحة لأنك قلت إن منصة Winrt هي ما تستخدمه لتطوير WINUI.

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

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

إذا لم يكن هنا ، فربما يمكننا مناقشة ذلك في مكان آخر.

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

كما هو مذكور في رسالتي السابقة ، فإن التوافق القياسي لـ C ++ 17 لـ C ++ / WinRT في حد ذاته لا يمثل في معظم الحالات حافزًا لترحيل قاعدة رموز C ++ / CX إلى C ++ / WinRT لأنك مجبر على التحويل البرمجي باستخدام برنامج التحويل البرمجي Visual C ++ من Microsoft على أي حال. إذا كان بإمكانك تبديل المترجم ، فسيتغير ذلك تمامًا.

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

نحن نستخدم Clang لتجميع قاعدة الأكواد الخاصة بنا لنظامي Android و iOS. ستكون القدرة على استخدام Clang لتجميع قاعدة الشفرة الخاصة بنا لنظام التشغيل Windows سببًا جيدًا جدًا للترحيل بعيدًا عن C ++ / CX. طلب ميزة Visual Studio لذلك موجود بالفعل ولكن لم يتم تنفيذ أي شيء حتى الآن بواسطة فريق Visual Studio.

لديك امتثال قياسي لـ C ++ ، ولديك دعم Clang في Visual Studio لتطبيقات سطح المكتب. لذا ، يرجى القيام بالخطوة الأخيرة وتقديم سبب حقيقي للترحيل بعيدًا عن C ++ / CX من خلال توفير دعم Clang لمكونات Windows Runtime.

يعد الامتثال للمعايير مفيدًا للمستهلكين - كما ذكرت أن المنتجين عالقون في MSVC. هناك طريقة لفرض clang-cl (وهذا ما تفعله مجموعة أدوات LLVM بالفعل ) عن طريق تعيين الخاصية CLToolExe إلى مسار إلى clang-cl في الملف .vcxproj . لست متأكدًا من مدى نجاح ذلك في مشاريع UWP ، لكن الأمر يستحق المحاولة.

بمجرد فتح أدوات منتج XAML و C ++ / WinRT في مشاريع سطح المكتب ، ستكون أيضًا مشكلة أقل بالنسبة لي.

ackh حصلت على مشروع

هذا ما فعلته:

• قم بتفريغ المشروع ، وأضف التوجيه التالي كأول توجيه تحت <Project>

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• استبدل <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> بـ <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• استبدل <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> بـ <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• أسفل هذا مباشرةً ، أضف <ModuleOutputFile />
• أعد تحميل المشروع
• يبني

ومع ذلك ، فإن لديها بعض المزالق:

• تدعم بعض التحذيرات المتعلقة بالحجج غير المستخدمة: ربما يمكنك إصلاحها عن طريق تغيير / إزالة الحجج غير المستخدمة.
• لسبب ما ، يرسل Clang ملف كائن 64 بت في 32 بت ، قد يحتاج فقط إلى إضافة -m32 إلى CLI tho.
• نظرًا لأن Clang لا تقوم بتنفيذ coroutines بالكامل حتى الآن ، فلن تتمكن من استخدامها.
• يقوم VS بإعادة بناء كاملة ذات ترابط واحد في كل مرة تقوم فيها بتشغيل التطبيق بدلاً من التزايدي و / أو المتوازي.

أود أن أقترح فتح مشكلة على https://github.com/microsoft/ProjectReunion للفت الانتباه إلى هذا الأمر.

sylveon شكرا جزيلا لنشر هذه التعليمات. سأجرب هذه المحاولة في مرحلة ما ولكن ما زلت آمل أن يدعم Visual Studio هذا خارج الصندوق في مرحلة ما.