ماذا عن .ui ببساطة؟

هل يمكن أن يكون هذا التمييز مفيدًا للقضايا غير الجزرية أيضًا ، أم أنه سيكون أكثر إرباكًا؟

أو إذا كان هذا في المقام الأول للمساعدة في التمييز بين مثل WPF و WinUI Xaml في نفس الحل ، فماذا عن اصطلاح مثل .winui.xaml أو .island.xaml ؟ من المحتمل أن يسهل ذلك استخدام الأدوات الحالية.

هل سيكون هذا لسيناريوهات جزر XAML أم في كل مكان؟ بالنسبة لكل سيناريو آخر ، لا أرى قيمة هذا ، بخلاف خلق الارتباك وإجبار الأشخاص على الهجرة (وربما كسر التوافق مع الإصدارات السابقة للعديد من الأدوات مثل الإصدارات القديمة من VS). من المحتمل أن تكون اتفاقية مثل "أيا كان. winui.xaml" أقل تدميرًا ، لكنني ما زلت أرى فقط أنها مفيدة في نطاق جزيرة ، وليس في أي مكان آخر.

تغيير الثغر نظرًا لأنني لا أريد أن يقتصر نطاق المناقشة على جزر XAML فقط.

أقول استمر في استخدام .xaml. قد يتغير نطاق (واسم) WinUi ليشمل منصات أخرى بجانب النوافذ (ربما من خلال UnoPlatform؟). ماذا يحدث إذا تغير اسم المشروع؟

أميل أكثر نحو NO. قامت Microsoft بالعديد من عمليات إعادة تسمية المنتجات والخدمات أحيانًا على حساب المنتج / الخدمة أو مستخدميها (رأي). هذه إعادة تسمية أخرى.

هل سيكون هذا لسيناريوهات جزر XAML أم في كل مكان؟ بالنسبة لكل سيناريو آخر ، لا أرى قيمة هذا ، بخلاف خلق الارتباك وإجبار الأشخاص على الهجرة (وربما كسر التوافق مع الإصدارات السابقة للعديد من الأدوات مثل الإصدارات القديمة من VS). من المحتمل أن تكون اتفاقية مثل "أيا كان. winui.xaml" أقل تدميرًا ، لكنني ما زلت أرى فقط أنها مفيدة في نطاق جزيرة ، وليس في أي مكان آخر.

في كل مكان

أعتقد أن XAML يجب أن يظل .xaml ولكن إذا ظهر شيء جديد إما ليحل محل أو يكون مفيدًا إلى جانب XAML التقليدي ، فيمكن أن يكون امتداد winui مفيدًا لذلك. # 804 :)

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

فقدت الكلمات الآن ...

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

تعجبني الفكرة من jesbis ، ربما يمكننا إضافة *.islands.xaml الذي يساعد على التمييز بسهولة أكبر بين ملفات XAML التي يتم تشغيلها في سياق جزر مقابل لا.

فضولي: هل من الأفضل أن يكون لديك .islands.xaml ينطبق فقط على ملفات XAML في الجزيرة ، أم فقط لاستخدام .winui.xaml كملحق عام في كل مكان؟ لست متأكدًا أيهما أفضل من هاتين الفكرتين.

تصويتي هو ".islands.xaml" أو ما شابه ذلك ليكون النمط الموصى به (ولكن غير مطبق بشكل صارم) في الجزر ، وفي كل مكان آخر لا تزال ملفات .xaml ملفات .xaml. بهذه الطريقة نتجنب التأثير غير الضروري على الأشخاص الذين لا يستخدمون الجزر.

أكبر ما يشغلني يأتي من كل الأدوات. ليس لدي مشكلة مع الامتداد المختلف ، لكن هذا يعني أن كل أداة تعتمد على امتداد الملف .xaml ستحتاج إلى التحديث (أفكر في أشياء مثل R # ، XamlStyler ، إلخ). يبدو أن دعم الأدوات حول xaml يكافح بالفعل ، ويبدو أنه من المحتمل أن يزيد الأمر سوءًا.

بلدي 0.02 دولار

ربما يجب تغيير عنوان المشكلة إلى شيء مثل:
هل يجب أن يكون لملفات XAML المضمنة في جزر Xaml ، امتداد ملف مختلف مع مشاريع WinUI 3؟

أنا أؤيد بشدة الاحتفاظ بـ .xaml هناك. ربما تذهب .ui.xaml أو .xaml.ui لكن التكنولوجيا قوية وتبقي المساعدة متاحة. على الجانب الآخر ، لسوء الحظ ، فإن xaml لديه وصمة عار حوله بعد عيوب أداء wpf و silverlight وهاتف windows ، لذلك يمكن أن يساعد اسم ملف أنظف في قلب الزاوية. ما زلت أحب xaml ، لكننا لسنا بحاجة إلى مزيد من الالتباس بشأن أسماء التكنولوجيا ما لم يتم التفكير بوضوح في ذلك.

أعتقد أنها فكرة جيدة أن يكون مجرد .ui لأنه إذا أصبح Winui في أي وقت مضى عبر النظام الأساسي (مثل العديد من عناصر windows) ، فسيكون أكثر ملاءمة.

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

سيكون لملفات الشفرة امتداد .ui.cs وهو شرح ذاتي وسهل القراءة.

.winui.xaml

هذا يعني أنه سيكون لدينا ملفات. winui.xaml.cs؟ ييكيس ..

استخدم تنسيق json. إنه عام 2020.

JSON قاسٍ وليس لطيفًا جدًا في العمل معه.

استخدم تنسيق json. إنه عام 2020.

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

أعتقد أن .winui سيجعل المبتدئين يستسلموا. لأننا نعتقد أننا يجب أن نتعلم لغة جديدة. والآن لدينا WinForms و WPF و UWP و SL و ASP و ASP.NET Core. يجب أن ننفق المزيد والمزيد من الوقت لتعلمه ولكن لا نرث. لا أعتقد أننا يجب أن نصنع دائمًا التكنولوجيا الجديدة.

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

في رأيي ، الحل الأكثر أناقة لـ "أي XAML هو" هو الاعتماد على مساحة اسم xmlns الافتراضية ، كما اقترح grokys في هذا التعليق: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# طلب الإصدار -541078633

لم نفعل ذلك باستخدام UWP ، لكن ربما يمكننا تغييره لـ WinUI.

في رأيي ، الحل الأكثر أناقة لـ "أي XAML هو" هو الاعتماد على مساحة اسم xmlns الافتراضية ، كما هو مقترح من grokys في هذا التعليق: AvaloniaUI / AvaloniaVS # 95 (تعليق)

لم نفعل ذلك باستخدام UWP ، لكن ربما يمكننا تغييره لـ WinUI.

هل يمكن أن تقدم ما يعادل Doctype ، كما هو الحال مع HTML؟

هل يمكن أن تقدم ما يعادل Doctype ، كما هو الحال مع HTML؟

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

يبدو أن دعم الأدوات حول xaml يكافح بالفعل ، ويبدو أنه من المحتمل أن يزيد الأمر سوءًا.

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

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

بالنسبة لأدوات XAML بشكل عام ، فإنها تحتاج إلى إعادة كاملة لتجربة وقت التصميم IMO. كانت Expression Blend آخر مرة شعر فيها تصميم XAML وتطويره بمستوى عالٍ.

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

قد يكون نهج البرنامج المساعد ، الذي لا يتطلب الكثير من العمل لموردي أدوات التحكم أو مجموعة الأدوات ، مع توفير وقت تصميم جيد ، ولوحة الأدوات ، وتجربة خصائص العنصر - مفيدًا للغاية. نظرًا لأن XAML ينتقل إلى عوامل الشكل غير التقليدية الأخرى ، يجب مراعاة سير عمل التصميم. عرضان للجزء (Neo و Duo) ، وأسطح XAML مستضافة بدون نافذة ، وتكاملات شل ، ومشاريع إطار مختلطة (جزر xaml ، ومزيج GDI و WinUI) ، و Hololens Spatial 3D ، ومحاور السطح الدوارة ، إلخ.

لكن ربما لم تعد العلامات التوضيحية هي الطريقة المثالية للتعامل معها. أو ربما يجب أن يكون هناك فصل أكبر بين محتوى XAML وتصميم XAML؟ كما هو الحال مع HTML و CSS؟

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

لا ، أنا لا أرى الهدف. لا يحل أي شيء.
إذا كان هناك أي شيء ، فإنه يخلق مشاكل مع المحررين الذين يعرفون بالفعل امتداد xaml.
أنا أعمل مع wpf و uwp ونماذج xaml كل يوم ولم أشعر بالارتباك بسبب الامتداد.

أليس بيت القصيد من Xaml أنه أسهل للأدوات؟ لا يمكن للأدوات معرفة ذلك دون الاعتماد على الفكرة القديمة لملحقات الملفات؟

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

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

لا أعرف أيضًا سبب رغبتك في تمييز مكونات XAML للجزر إما باستخدام islands.xaml المقترح. هل ستفعل أي شيء مختلف في الأدوات أم أنها فقط لسهولة القراءة في حل؟

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

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

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

لذا ، فإن رأيي هو: بالتأكيد ابق مع .xaml.

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

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

لكن الآن فكرة مختلفة تمامًا:

إذا فهمت الأمر بشكل صحيح ، فإن كل هذه التغييرات مفيدة حقًا فقط في حالة XAML Island حيث تقوم بخلط الأنظمة الأساسية في نفس الحل ، أليس كذلك؟ لأنه إذا كنت تستخدم WinUI فقط ، فأنت تعلم أن كل ملف XAML يستخدم WinUI. لست متأكدًا مما إذا كانت جزر XAML ستكون السيناريو الرئيسي لـ WinUI أم لا. في الماضي عندما تم تقديم WPF ، كان لدينا أيضًا إمكانية التشغيل المتداخل WPF و WinForms ، ولكي أكون صادقًا ، نادرًا ما رأيت مطورين يستخدمون عناصر تحكم WPF في تطبيقات WinForms الخاصة بهم. بدلاً من ذلك ، استمروا في استخدام WinForms في WInForms وبدأوا مشاريع جديدة مع WPF بدلاً من WinForms. وربما ينطبق الأمر نفسه على WinUI 3 ، وأعتقد أنه سيكون كذلك. تعد XAML Islands طريقة رائعة للتحديث ، ولكن من واقع خبرتي ، فإن المطورين لن يفعلوا ذلك إلا إذا كانوا بالتأكيد بحاجة إلى تحكم من WinUI في تطبيق WPF / WinForms. إذا لم يكن الأمر كذلك ، فسيستمرون في المكدس القديم ويبدأون تطبيقات جديدة على المكدس الجديد. لاحظ أنه لا يجب أن تكون هذه هي الحقيقة ، إنها فقط تجربتي. :-)

هذا يعني أننا نتحدث عن تغيير اسم ملف لسيناريو قد لا يكون السيناريو الرئيسي للنظام الأساسي. وأعتقد أن هذا هو السبب في أنني أعتقد أن الأمر لا يستحق كل هذا العناء. ماذا لو قام مطور WPF / UWP / Silverlight / Windows Phone بإنشاء مشروع WinUI 3 جديد؟ سوف يفكرون

لماذا هيك غيروا امتداد الملف .xaml إلى ...؟

من فضلك لا تقم بإزالة امتداد الملف .xaml.

من فضلك لا تذهب لتغيير الامتدادات!

منذ عدة سنوات ، بدأنا في استخدام الامتداد .paml في Avalonia ولكن في النهاية عاد إلى .xaml بسبب المشاكل التي تسببت فيه: هناك بالفعل أدوات في IDEs للتعامل مع XAML (بغض النظر عن مدى سوء المعاملة ، على الأقل شيء!).

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

كما ذكر stevenbrix أعلاه ، هناك طريقة جيدة تمامًا لمعرفة لهجة XAML التي يستخدمها الملف وهي مساحة الاسم الافتراضية أعلى الملف. كخطوة أولى ، اجعل الأدوات تحترم هذا.

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

جميلة من فضلك؛)

سبب آخر لعدم: UWP تعاني بالفعل من مشكلات التبني. إعادة تسميتها تبيعها على أنها تقنية أخرى ، بدلاً من "أنها تشبه إلى حد ما الشيء نفسه مثل wpf".
توجد بالفعل مشكلات أكبر في تغييرات تعطل WinUI 3.0 والتي ستضر بشكل كبير بنظام uwp البيئي الحالي. لا تضف شيئًا آخر مختلف.
لا يزال xaml ، فقط يصل إلى مجموعات API مختلفة ، تمامًا مثل c # لا يزال c # حتى أستخدمه في إطار عمل مختلف لواجهة المستخدم. يمكنك تغيير التعليمات البرمجية وواجهات برمجة التطبيقات التي يمكنني استخدامها ، لكنها لا تزال نفس اللغة.

أنا أصوت لا ، لا أرى أي فوائد ، فقط الارتباك الإضافي.

سبب آخر لعدم: UWP تعاني بالفعل من مشكلات التبني. إعادة تسميتها تبيعها على أنها تقنية أخرى ، بدلاً من "أنها تشبه إلى حد ما الشيء نفسه مثل wpf".
توجد بالفعل مشكلات أكبر في تغييرات تعطل WinUI 3.0 والتي ستضر بشكل كبير بنظام uwp البيئي الحالي. لا تضف شيئًا آخر مختلف.
لا يزال xaml ، فقط يصل إلى مجموعات API مختلفة ، تمامًا مثل c # لا يزال c # حتى أستخدمه في إطار عمل مختلف لواجهة المستخدم. يمكنك تغيير التعليمات البرمجية وواجهات برمجة التطبيقات التي يمكنني استخدامها ، لكنها لا تزال نفس اللغة.

dotMorten Ha ، كان لدي نفس الفكرة مع C #. إذا استدعينا ملفات .xaml .winui ، يجب أن نطلق على ملفات .cs .wincode لجعلها متسقة. :-)

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

2 سنتي ، التزم بـ _.xaml_ ، من فضلك.
الرجاء توحيد الأشياء بدلاً من تباعدها.

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

يستخدم XAML أيضًا في Xamarin والذي لا يستهدف أنظمة Windows فقط ولكن iOS و Android و macOS ...

سيؤدي استبدال .xaml بواسطة .winui إلى إنشاء موقف حيث سيحتفظ Xamarin بامتداد .xaml لملفات XAML (لماذا قد يستخدم المرء .winui لنظام iOS أو Android؟) وستنتقل أهداف Windows مثل UWP / WPF ... إلى .winui لملفات XAML .

TL ؛ DR تنسيق ملف واحد / اصطلاح اسمين (.winui لنظام التشغيل Windows ، .xaml لـ Xamarin) ، بالنسبة لي إنه أمر محير.

يجب أن يكون الامتداد .xaml نظرًا لأن بناء الجملة للمحتوى هو xaml ، فإن الامتداد الآخر لن يؤدي إلا إلى حدوث ارتباك.
أصوت لشيء مثل .winui.xaml

البقاء مع ".xaml" ، إنه قوي

يجب أن أقول ، Microsoft لديها مشكلة تسمية مرضية!

وهذا بالفعل يتصدرهم جميعًا.

رقم

إذا كنت بحاجة إلى أن يكون لديك UWP XAML و WPF XAML في نفس ملف المشروع ، فاستخدم Custom Tool بدلاً من ذلك.

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

أفضل طريقة هي توحيد لغة XAML ، حتى نتمكن من تطوير مترجم مشترك وتنسيق ثنائي وإطار عمل lib.

هكذا كنت سأفعل ذلك!

بما أنك تسأل ، لا لا تفعل ذلك.

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

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

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

ثالثًا ، سيؤدي إلى تجزئة المزيد من لغات واجهة المستخدم المستخدمة في منتجات Microsoft. أنا حقًا بحاجة لأن نذهب أكثر إلى معيار في Xaml ، لذا فإن المنتج ليس مهمًا جدًا. C # هو نفسه بالنسبة إلى Xamarin أو Net Core أو Windows 10 أو WPF ، فلماذا يجب أن يكون XAML مختلفًا؟

دع الأشخاص يرتبون مشاريعهم وينظمون الكود بحيث لا يكون مربكًا لهم.

استخدم تنسيق json. إنه عام 2020.

rickydatta حتى في عام 2020 ، يستخدم الويب HTML بدلاً من JSON لتحديد واجهات المستخدم. هناك العديد من الأسباب التي تجعل لغات الترميز مثل HTML و XAML رائعة لتعريف واجهات المستخدم. يعد JSON رائعًا للعديد من الأشياء ، لكن imo ليس لتعريف واجهات المستخدم. عندما تستخدم JSON لواجهة مستخدم وتحاول إنشاء ميزات مثل ربط البيانات ومراجع الموارد الثابتة وما إلى ذلك ، فسترى أنها أصبحت غير قابلة للقراءة تمامًا. لكن الأمر بعيد المنال هنا ، فلنتركه. إذا كنت تريد JSON ، فيرجى إنشاء إصدار جديد ودعنا نرى كيف يتفاعل المجتمع معها. :-)

لقد حاولت حقًا تجنب التعليق هنا لأن معظم هذا قد قيل بالفعل ، لكني استسلمت. آسف. أنا ضعيف.

لا تفعل هذا.

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

ما هي الفوائد المحتملة؟

• من شأنه تجنب حدوث ارتباك محتمل للأشخاص الذين لديهم بعض ملفات .xaml التي تحتوي بالكامل على عناصر تحكم WinUI وبعض ملفات .xaml التي لا تحتوي على ذلك.
• ساعد في تمكين الأدوات لتحديد كيفية العمل مع المحتوى المختلف المحتمل لملفات .xaml.

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

ما هي الجوانب السيئة المحتملة؟

• من شأنه أن يسبب الارتباك.
  - "ما هذا التمديد الجديد؟" "ما الذي أحتاجه لفتحه؟" "كيف تختلف عن ...؟" "لماذا لم تغييره؟"
  - ما الامتداد الذي تستخدمه لملف يحتوي فقط على بعض عناصر تحكم WinUI ، عند خلط عناصر UWP XAML و WinUI3 الموجودة؟ أم أن هذا الاقتراح بالذات يعني ضمناً أن هذه القدرة ستزول؟ (انظر ، بمجرد تقديم اقتراح لتغيير امتداد الملف ، فأنت تقدم بالفعل مزيدًا من الارتباك و FUD. إذا كانت أشياء مثل امتدادات الملفات قد تتغير ، فربما يجب أن أنتظر النظر في WinUI ، بأي صفة ، حتى يصبح أكثر استقرارًا . طلب ​​مني العديد من الأشخاص التحقيق في Flutter. ربما يكمن هناك مستقبل أفضل بالنسبة لي.)
  - كان فهمي لإحدى نقاط البيع في Xaml Islands في تطبيقات WPF الحالية أنه يعني القدرة على إعادة استخدام المهارات والمعرفة الحالية في العمل مع XAML. يشير هذا التغيير إلى أنه ليس XAML فقط ، لذا فهو شيء آخر يجب تعلمه ، وكذلك هناك عائق آخر محتمل للتبني.)

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

• يتجاهل التاريخ.
  - لقد عملت سابقًا مع حلول احتوت على مشاريع تستهدف WPF و Silverlight و Windows Phone. لقد استخدموا جميعًا لهجات XAML مختلفة ، لكنني لم أشعر بالحيرة بشأن أي منها كان قيد الاستخدام أو ما يمكنني فعله داخل ملف. لقد عملت مع الحلول التي تحتوي على XAML لـ UWP و Xamarin. لكن لم أعاني من الارتباك المتوقع في الافتراض الكامن وراء هذه المشكلة. لقد تحدثت أيضًا إلى العديد من المطورين الآخرين الذين لديهم حلول مماثلة ، ولم أسمع أبدًا أي شخص آخر يقول إن استخدام ملحقات مختلفة سيساعدهم.
  - من بين جميع الانتقادات التي سمعتها عن وجود لهجات مختلفة لـ XAML ، لم يكن الارتباك القائم على تسمية الملفات أحد هذه الانتقادات مطلقًا.
  - لا يحب المطورون عمومًا ذلك عندما تخبرهم كيف يجب عليهم تسمية وتنظيم الملفات والمشاريع دون سبب وجيه. قد يكون من الأفضل توثيق الإرشادات والممارسات الموصى بها / المقترحة لسيناريوهات مثل العمل مع المشاريع التي تحتوي على ملفات ذات محتويات مماثلة.
  - أحد الأسباب الرئيسية لعدم انتشار الاستخدام الواسع للامتدادات المتعددة على ملف ما هو أن File Explorer (أو أي شيء يسرد محتويات نظام الملفات - بما في ذلك المنتقيات والحوار المقدمان من نظام التشغيل) يمكن أن يؤدي إلى مزيد من الالتباس عندما ( تم تكوينه إلى - وهو الافتراضي) إخفاء امتدادات الملفات المعروفة. هذا يمكن أن يجعل MyClass.winui.xaml يبدو مثل MyClass.winui مما يؤدي بعد ذلك إلى أسئلة والتباس حول ماهية الملف ، ومن أين أتى ، ولماذا يتم عرضه ، وما إلى ذلك.
  - تؤدي إضافة امتدادات متعددة / فرعية إلى زيادة طول الملف وبالتالي زيادة فرص الوقوع في مشكلات متعلقة بـ MAXPATH. ربما لن تكون هذه مشكلة في يوم من الأيام ، لكننا لم نصل بعد. أكره أن أرى المطورين مجبرين على إعطاء ملفاتهم (والفئات ، حيث يتم الاحتفاظ بالمزامنة عادةً) أسماء وصفية أقل لأن الأدوات تحتاج الآن إلى ستة أحرف إضافية للملحق (الإضافات).

• يخلق المزيد من العمل لمطوري الأدوات. (سواء داخل Microsoft أو خارجها.)
  - المزيد من الحالات للتعامل معها.
  - المزيد من السيناريوهات لتوثيقها واختبارها.
  - قضاء وقت أقل في إصلاحات الأخطاء والميزات الجديدة. مع أدوات XAML الحالية التي يُنظر إليها على أنها تفتقر إلى التقنيات الأخرى وبطيئة في إنشاء أدوات مخصصة ، لماذا تفعل أي شيء يجعل بناء أدوات جديدة أبطأ؟

• إنها تخاطر بوضع سابقة سيئة للغاية.
  - إذا حدث هذا ، فلماذا لا يكون من المناسب استبدال جميع ملفات .xaml الحالية بـ .wpf ، .uwp ، .xamarinforms ، وما إلى ذلك؟ أو .xaml2006 ، .xaml20009 ، .xaml-uwp5 إذا كانت المشكلة الأساسية هي مساحة الاسم الأساسية بدلاً من مكان استخدامها؟ سيكون هناك حد أدنى من الفوائد المحتملة (كما في هذه الحالة) ، ولكن قد يراها الكثيرون على أنها الطريقة التي تقترح بها Microsoft تسمية الملفات. (لن أتفاجأ إذا لم يقدم شخص ما مثل هذه المقترحات لمجرد رؤية المناقشة هنا.)
  - لست على دراية (ولكن يسعدني تصحيح الأمر) بأي من الأدوات المقدمة من MS والتي تتعامل مع الملفات بشكل مختلف بناءً على الامتدادات الفرعية ولكن القيام بذلك من المحتمل أن يجبر Visual Studio (وغيرها؟ ، بما في ذلك Windows Shell؟) قادرة على التعامل مع هذه السيناريوهات. بعد ذلك ، بمجرد توفر الإمكانية ، يمكنني أن أتخيل إغراء تقديم مجموعة واسعة من اقتراحات التسمية المعقدة ولكن غير الضرورية التي يتم اقتراحها وتقديمها كثيرًا بالنسبة لبعض المطورين ، مما يؤدي إلى الارتباك لبقيتنا.

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

شكرا للجميع لإعارة صوتك. سمعناك! لقد جمعنا ما يكفي من التعليقات ، لذلك يمكننا القول بحزم أن تغيير امتداد .xaml يعد أمرًا غير متكرر .

لا نعتزم تفتيت النظام البيئي أو كسر أدوات الطرف الثالث (وهناك الكثير). نوافق على أن XAML هي اللغة ، وأن WinUI 3 هو إطار عمل UI يستخدم XAML. لكل هذه الأسباب وأسباب أخرى ، من المنطقي الاستمرار في استخدام امتداد xaml.

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

1. لا تفعل شيئا. ستكون تجربة مطوري XAML Islands كما هي: ملفات XAML في مشروع مختلف (ربما لا تكون هذه مشكلة كبيرة). ستستخدم WInUI 3 نفس مساحة الاسم ، ولا يهم لأنها ستكون لغة XAML الوحيدة المستخدمة في المشروع.

2. استخدم مساحات الأسماء للتمييز بين واجهات المستخدم بناءً على XAML. اليوم ، يستخدم كل من WPF XAML و UWP XAML نفس مساحات الأسماء ، ربما يجب على WinUI 3 استخدام مساحة اسم مختلفة مثل Xamarin Forms ("http://xamarin.com/schemas/2014/forms") ، لذا فإن المجمعين والأدوات والمصممين يمكن التفريق بين الملفات. على الجانب الآخر ، سيخلق هذا لهجات ، على الرغم من أن هذا يحدث اليوم. من الناحية النظرية ، سيسهل هذا على المطورين نسخ ولصق أمثلة XAML من المستندات / المدونات ، على الرغم من للأسف ، هناك الكثير من العينات التي لا تتضمن مساحات الأسماء.

3. افعل شيئًا ، لكن فقط للجزر. لا حاجة للتمييز في جميع أطر عمل واجهة المستخدم. يمكننا استخدام الاصطلاحات. على سبيل المثال ، في المستقبل ، يمكن أن يحتوي تطبيق WPF مع XAML Island على ملفات XAML في مجلد معين (مجلد الجزر؟). هذا مشابه لتعريب UWP (Strings / en-US / Resources.resw).

شكرا لك مرة أخرى على ملاحظاتك . سأفتح مناقشات جديدة عندما ننضج المزيد من الأفكار.

يجب أن يكون تضمين سطر نمط مقتطف أو مستند لملف الجزيرة كافيًا للأدوات.

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

@ marb2000 WinUI 3 هو إطار عمل UI يستخدم XAML

يجب أن يكون: WinUI 3 هو إطار عمل UI يمكنه استخدام XAML. نظرًا لأنه لا يتطلب استخدام XAML ولا يحتاج إلى الاعتماد على لغة XAML.

نحن نتفق على أن XAML هي اللغة

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

لقد كان عدم التركيز على UWP أمرًا مؤلمًا. الآن ، عندما تجري بحثًا على القناة 9 عن محتوى UWP ، تحصل على محتوى Xamarin. إنها حيلة واضحة. من فضلك توقف عن محاولة تحويل UWP إلى شيء آخر! أعد الاستثمار ، ومضاعفة القيمة ، واجعلها تعمل. لا تحتاج UWP إلى تصحيح المسار ، فهي بحاجة إلى فرق Xamarin و Office للانضمام. تقتل سياسات Microsoft الداخلية UWP.

Noemata هل هي ملاحظة رسمية؟