बस .ui के बारे में क्या?

क्या यह अंतर गैर-द्वीप मामलों के लिए भी मददगार हो सकता है, या यह अधिक भ्रमित करने वाला होगा?

या यदि यह मुख्य रूप से एक ही समाधान में डब्ल्यूपीएफ और विनयूआई एक्सएएमएल के बीच अंतर करने में मदद करने के लिए है तो .winui.xaml या .island.xaml जैसे सम्मेलन के बारे में क्या? इससे संभवतः मौजूदा उपकरणों का उपयोग करना आसान हो जाएगा।

क्या यह एक्सएएमएल द्वीप परिदृश्यों या हर जगह के लिए होगा? हर दूसरे परिदृश्य के लिए मैं नहीं देखता कि इसका क्या मूल्य होगा, भ्रम पैदा करने और लोगों को माइग्रेट करने के लिए मजबूर करने से परे (और शायद वीएस के पुराने संस्करणों जैसे बहुत सारे टूलींग के लिए पिछली संगतता को तोड़ दें)। "whatever.winui.xaml" जैसा एक सम्मेलन शायद कम विनाशकारी होगा, लेकिन मैं अभी भी इसे केवल एक द्वीप के दायरे में उपयोगी देखता हूं, हर जगह नहीं।

दिए गए शीर्षक को बदलना मैं चर्चा को केवल एक्सएएमएल द्वीपों तक सीमित नहीं करना चाहता हूं।

मैं कहता हूं कि .xaml का इस्तेमाल करते रहें। विंडोज़ के बगल में अन्य प्लेटफार्मों को शामिल करने के लिए विनयूआई का दायरा (और नाम) बदल सकता है (शायद यूनोप्लेटफार्म के माध्यम से?) यदि परियोजना का नाम बदल दिया जाए तो क्या होगा?

मैं NO की ओर अधिक झुकता हूँ। Microsoft कभी-कभी उत्पाद/सेवा या उनके उपयोगकर्ताओं (राय) की हानि के लिए उत्पादों और सेवाओं के लिए बहुत सारे नाम बदल रहा है। यह एक और नाम है।

क्या यह एक्सएएमएल द्वीप परिदृश्यों या हर जगह के लिए होगा? हर दूसरे परिदृश्य के लिए मैं नहीं देखता कि इसका क्या मूल्य होगा, भ्रम पैदा करने और लोगों को माइग्रेट करने के लिए मजबूर करने से परे (और शायद वीएस के पुराने संस्करणों जैसे बहुत सारे टूलींग के लिए पिछली संगतता को तोड़ दें)। "whatever.winui.xaml" जैसा एक सम्मेलन शायद कम विनाशकारी होगा, लेकिन मैं अभी भी इसे केवल एक द्वीप के दायरे में उपयोगी देखता हूं, हर जगह नहीं।

हर जगह

मुझे लगता है कि एक्सएएमएल को .xaml रहना चाहिए, लेकिन अगर पारंपरिक एक्सएएमएल के साथ बदलने या उपयोगी होने के लिए कुछ नया दिखाना था, तो उसके लिए एक .winui एक्सटेंशन उपयोगी हो सकता है। #804 :)

यह अनुरोध मुझे पूरी तरह से भ्रमित करता है ... मुझे यह समझने के लिए इस मुद्दे को दो बार पढ़ना पड़ा कि क्या हो रहा था ... यह वास्तव में xaml पारिस्थितिकी तंत्र को कभी भी विभिन्न बोलियों की तुलना में अधिक खंडित करेगा ..

अभी शब्दों के लिए खो गया ...

@liquidboy अच्छी तरह से यह परिवर्तन न करने के पक्ष में प्रतिक्रिया का कम से कम एक स्पष्ट टुकड़ा है :) अपनी आवाज देने के लिए धन्यवाद।

मुझे @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 प्रदर्शन नुकसान, सिल्वरलाइट और विंडोज़ फोन के बाद इसके चारों ओर कुछ कलंक है, इसलिए एक क्लीनर फ़ाइल नाम कोने को मोड़ने में मदद कर सकता है। मुझे अभी भी xaml पसंद है, लेकिन हमें तकनीकी नामों पर और अधिक भ्रम की आवश्यकता नहीं है जब तक कि इसे स्पष्ट रूप से सोचा न जाए।

मुझे लगता है कि इसे केवल .ui के रूप में रखना एक अच्छा विचार है क्योंकि अगर विनुई कभी क्रॉस प्लेटफॉर्म बन जाता है (जैसे कई विंडोज़ सामान हैं), तो यह अधिक उपयुक्त होगा।

इसका मतलब है कि यह भविष्य का प्रमाण होगा।

कोड फाइलों में एक .ui.cs एक्सटेंशन होगा जो स्वयं व्याख्यात्मक और पढ़ने में आसान है।

.विनुई.एक्सएमएल

तो इसका मतलब है कि हमारे पास .winui.xaml.cs फ़ाइलें होंगी? ओह ..

जेसन प्रारूप का प्रयोग करें। 2020 है।

JSON कठोर है और साथ काम करने के लिए बहुत अनुकूल नहीं है।

जेसन प्रारूप का प्रयोग करें। 2020 है।

JSON फॉर्मेट कंप्यूटर को पढ़ने के लिए है, इंसानों के लिए नहीं। इसे पढ़ना मुश्किल है और अच्छा नहीं लगता।

मुझे लगता है कि .winui शुरुआत करने वाले को हार मान लेगा। क्योंकि हम सोचेंगे कि हमें एक नई भाषा सीखनी चाहिए। और अब हमारे पास WinForms और WPF और UWP और SL और ASP और ASP.NET Core हैं। हमें इसे सीखने के लिए ज्यादा से ज्यादा समय देना चाहिए लेकिन विरासत में नहीं मिलना चाहिए। मुझे नहीं लगता कि हमें हमेशा नई तकनीक बनानी चाहिए।

क्षमा करें, मैं और मेरे कई मित्र नई चीजें सीखना पसंद नहीं करते हैं। अगर हम अल्पसंख्यक होने की उम्मीद नहीं करते हैं, तो हमें प्रौद्योगिकी को विरासत में मिलाना चाहिए और पुन: उपयोग और संगत किया जा सकता है।

मेरी राय में, "कौन सा एक्सएएमएल है" के लिए एक और अधिक सुरुचिपूर्ण समाधान डिफ़ॉल्ट xmlns नेमस्पेस पर निर्भर होगा, जैसा कि इस टिप्पणी में @grokys द्वारा सुझाया गया है: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# निर्गम टिप्पणी

हमने UWP के साथ ऐसा नहीं किया, लेकिन शायद हम इसे WinUI के लिए बदल सकते हैं।

मेरी राय में, "कौन सा एक्सएएमएल है" के लिए एक और अधिक सुरुचिपूर्ण समाधान डिफ़ॉल्ट xmlns नामस्थान पर निर्भर होगा, जैसा कि इस टिप्पणी में @grokys द्वारा सुझाया गया है: AvaloniaUI/AvaloniaVS#95 (टिप्पणी)

हमने UWP के साथ ऐसा नहीं किया, लेकिन शायद हम इसे WinUI के लिए बदल सकते हैं।

आप HTML के साथ एक Doctype के समकक्ष का परिचय दे सकते हैं?

आप HTML के साथ एक Doctype के समकक्ष का परिचय दे सकते हैं?

शायद, लेकिन हमें नहीं करना चाहिए। डिफ़ॉल्ट नामस्थान होना चाहिए जो प्रत्येक अलग प्लेटफॉर्म को अलग करता है (वे कोड-बैक में सब के बाद करते हैं)

xaml के आस-पास टूलिंग समर्थन पहले से ही ऐसा लगता है कि यह संघर्ष कर रहा है, और ऐसा लगता है कि इससे यह और भी खराब हो जाएगा।

@keboo यह मेरे लिए घर पर असली मुश्किल है, और कुछ ऐसा है जिसे मैं ठीक करने और सही करने के लिए कड़ी मेहनत कर रहा हूं।
तथ्य यह है कि हम एक ऐसी दुनिया में हैं जहां हम उन्हें अलग नहीं बता सकते (द्वीपों के परिदृश्य के लिए) इस बात का एक उत्पाद है कि कैसे टूलिंग वर्षों में विकसित हुई है। सब कुछ पूरी तरह से अलग है, और विभिन्न बोलियों के बीच मतभेदों को युक्तिसंगत बनाना लगभग असंभव है। मैं इसे बदलना चाहता हूं, और एक्सएएमएल पार्सिंग और संकलन बनाना शुरू करता हूं जिसे सभी एक्सएएमएल बोलियों में आसानी से साझा किया जा सकता है, जहां इस उदाहरण में, विनयूआई और डब्ल्यूपीएफ एक ही मौलिक इंजन का उपयोग कर रहे हैं। टूलिंग प्लगइन-सक्षम होना चाहिए जैसा कि डिफ़ॉल्ट नेमस्पेस द्वारा घोषित किया गया है और जहां आवश्यक हो वहां अनुकूलित किया जा सकता है। मेरी राय में, इस परिदृश्य को ठीक से काम करने के लिए हमें इससे ज्यादा कुछ नहीं चाहिए। हालांकि यह एक बहुत बड़ा प्रयास है, मेरे लिए यह हम सभी के लिए सही काम है।

@stevenbrix प्लेटफ़ॉर्म वर्तमान में समझ जाएगा जब XAML का उपयोग एक द्वीप स्थिति में किया जा रहा है, लेकिन मैंने इस मुद्दे के बारे में जो पढ़ा है, वह डेवलपर के लिए यह बताने और समझने का एक तरीका है कि WinUI 3.0 के भीतर .xaml फ़ाइल का उपभोग कैसे किया जाएगा। परियोजना।

सामान्य रूप से एक्सएएमएल टूलिंग के लिए, इसे आईएमओ डिजाइन समय अनुभव के कुल पुन: कार्य की आवश्यकता है। एक्सप्रेशन ब्लेंड आखिरी बार एक्सएएमएल डिजाइन और विकास को शीर्ष स्तर पर महसूस किया गया था।

XAML की प्रकृति के कारण, यह एक लिखित रूप और एक दृश्य रूप दोनों है। Intellisense को अच्छी गुणवत्ता में लाने के लिए Visual XAML डिज़ाइन ने पीछे ले लिया है। यदि प्रोटोटाइप और पॉलिश XAML डिज़ाइन अनुभव दोनों के लिए एक मजबूत, प्रदर्शनकारी और आसान हो सकता है - जो समुदाय को फिर से जीवंत कर सकता है।

एक प्लगइन दृष्टिकोण, जिसे करने के लिए नियंत्रण या टूलकिट विक्रेताओं के लिए बहुत अधिक काम की आवश्यकता नहीं होती है, जबकि अभी भी एक अच्छा डिज़ाइन समय, टूल पैलेट, तत्व संपत्ति अनुभव देना - बहुत उपयोगी हो सकता है। जैसा कि XAML अन्य गैर-पारंपरिक रूप कारकों में जाता है, डिज़ाइन वर्कफ़्लो पर विचार करने की आवश्यकता है। दो पैन व्यू (नियो और डुओ), नॉन-विंडो होस्टेड एक्सएएमएल सरफेस, शेल इंटीग्रेशन, मिक्स्ड फ्रेमवर्क प्रोजेक्ट्स (एक्सएएमएल आइलैंड्स, जीडीआई और विनयूआई मिक्स), होलोलेंस स्पैटियल 3 डी, रोटेटिंग सरफेस हब आदि।

लेकिन शायद घोषणात्मक मार्कअप अब इसे संभालने का आदर्श तरीका नहीं है। या शायद एक्सएएमएल सामग्री और एक्सएएमएल स्टाइल के बीच और अलगाव होना चाहिए? एचटीएमएल और सीएसएस के साथ के रूप में?

WinUI को न केवल चीजों को उसी रूप में आगे बढ़ाने का एक अच्छा अवसर लगता है, बल्कि आने वाले दशकों के लिए योजना बनाने का भी।

नहीं, मुझे बात समझ में नहीं आ रही है। यह कुछ भी हल नहीं करता है।
यदि कुछ भी हो, तो यह उन संपादकों के साथ समस्याएँ पैदा करता है जो पहले से ही xaml एक्सटेंशन को जानते हैं।
मैं wpf, uwp के साथ काम करता हूं और हर दिन xaml बनाता हूं और विस्तार के कारण मैं कभी भ्रमित नहीं हुआ हूं।

Xaml का पूरा बिंदु नहीं है कि टूलींग के लिए यह आसान है? फ़ाइल एक्सटेंशन के प्राचीन विचार पर भरोसा किए बिना टूलिंग इसका पता नहीं लगा सकता है?

मेरा मतलब आम तौर पर, अगर यूआई ढांचे में कुछ भी नहीं बदल रहा है, यानी यह अभी भी एक्सएएमएल है, तो ऐसा न करें।

यदि यह पूरी तरह से नया UI फ्रेमवर्क होता, तो मुझे कोई समस्या नहीं दिखाई देती।

मैं यह भी नहीं जानता कि आप प्रस्तावित islands.xaml के साथ द्वीपों के लिए XAML घटकों में अंतर क्यों करना चाहेंगे। क्या यह टूलींग में कुछ अलग करेगा या यह सिर्फ समाधान में पठनीयता के लिए है?

मेरा पहला विचार यह है कि मुझे यह विचार बिल्कुल पसंद नहीं है। लेकिन हो सकता है कि मुझे वह वास्तविक समस्याएं न दिखें जो इसे हल कर सकती हैं, और शायद मुझे यह बात समझ में नहीं आती।

अगर इसमें xaml वाली कोई फ़ाइल है, तो मैं इसे .xaml फ़ाइल बनाना चाहता हूं। अतीत में, यह मेरे दिमाग में कभी नहीं आया कि मैं एक UWP .xaml फ़ाइल को wpf .xaml फ़ाइल से अलग नाम देना चाहता हूं।

अगली बात यह है कि फ़ाइल-एक्सटेंशन में एक फ्रेमवर्क नाम एक अच्छा विचार प्रतीत नहीं होता है, क्योंकि फ्रेमवर्क के नाम बदल सकते हैं, और XAML 4ever XAML है।

तो, मेरी राय है: निश्चित रूप से .xaml के साथ रहें।

लेकिन .xaml फ़ाइल एक्सटेंशन के साथ क्या विकल्प हैं?
एक और .islands.xaml फ़ाइल एक्सटेंशन? इसका मतलब यह होगा कि फ़ाइल एक्सटेंशन का उपयोग न केवल प्रारूप का वर्णन करने के लिए किया जाता है, बल्कि फ़ाइल की सामग्री भी होती है। महम... लेकिन इसका एक फायदा यह है कि आप इसे डेवलपर के लिए वैकल्पिक बना सकते हैं। यदि वे इसका उपयोग करना चाहते हैं, तो वे अपनी फ़ाइलें .islands.xaml पर कॉल कर सकते हैं और टूलींग विभिन्न आइकन आदि के साथ उसे उठा लेगा।

एक अन्य डिफ़ॉल्ट-नामस्थान भी एक मान्य विकल्प है। लेकिन टूलिंग के लिए इसका मतलब यह होगा कि यह पता लगाने के लिए कि यह किस प्रकार की फाइल है, प्रत्येक .xaml फ़ाइल को देखना होगा। और इसका मतलब यह भी होगा कि एक्सएएमएल बोलियों को फिर से एक और रूट नेमस्पेस के कारण थोड़ा अलग कर दिया गया है।

लेकिन अब एक पूरी तरह से अलग विचार:

अगर मैंने इसे सही पाया, तो ये सभी परिवर्तन केवल एक्सएएमएल द्वीप मामले के लिए वास्तव में सहायक हैं जहां आप एक ही समाधान में प्लेटफॉर्म मिलाते हैं, है ना? क्योंकि यदि आप केवल WinUI का उपयोग करते हैं, तो आप जानते हैं कि प्रत्येक XAML फ़ाइल WinUI का उपयोग करती है। मुझे यकीन नहीं है कि XAML द्वीपसमूह WinUI के लिए एक मुख्य परिदृश्य होगा या नहीं। अतीत में जब डब्ल्यूपीएफ पेश किया गया था, हमारे पास डब्ल्यूपीएफ और विनफॉर्म इंटरऑप भी थे, और ईमानदार होने के लिए, मैंने शायद ही कभी डेवलपर्स को अपने विनफॉर्म अनुप्रयोगों में डब्ल्यूपीएफ नियंत्रण का उपयोग करते देखा है। इसके बजाय, उन्होंने WInForms में WinForms का उपयोग करना जारी रखा और उन्होंने WinForms के बजाय wpf के साथ नई परियोजनाएं शुरू कीं। और शायद WinUI 3 के लिए भी यही सच हो सकता है, और मुझे लगता है कि ऐसा ही होगा। XAML द्वीपसमूह आधुनिकीकरण का एक शानदार तरीका है, लेकिन मेरे अनुभव में, डेवलपर्स इसे केवल तभी करेंगे जब उन्हें निश्चित रूप से अपने wpf/WinForms ऐप में WinUI से नियंत्रण की आवश्यकता होगी। यदि नहीं, तो वे पुराने स्टैक पर बने रहते हैं और वे नए स्टैक पर नए ऐप्स प्रारंभ करते हैं। ध्यान दें कि यह सच नहीं है, यह सिर्फ मेरा अनुभव है। :-)

इसका मतलब है कि हम एक ऐसे परिदृश्य के लिए फ़ाइल नाम बदलने की बात कर रहे हैं जो प्लेटफ़ॉर्म के लिए मुख्य परिदृश्य नहीं हो सकता है। और मुझे लगता है इसलिए मुझे लगता है कि यह इसके लायक नहीं है। क्या होगा यदि एक डब्ल्यूपीएफ/यूडब्ल्यूपी/सिल्वरलाइट/विंडोज फोन डेवलपर एक नया विनयूआई 3 प्रोजेक्ट बनाता है? वे सोचेंगे

उन्होंने .xaml फ़ाइल एक्सटेंशन को ... में क्यों बदल दिया?

कृपया .xaml फ़ाइल एक्सटेंशन को न निकालें।

कृपया एक्सटेंशन बदलने पर न जाएं!

कई साल पहले हमने अवलोनिया में .paml एक्सटेंशन का उपयोग करना शुरू किया था, लेकिन अंत में इसके कारण होने वाली समस्याओं के कारण .xaml पर वापस चला गया: एक्सएएमएल को संभालने के लिए आईडीई में पहले से ही टूलिंग है (चाहे कितना भी जानदार क्यों न हो) , कम से कम यह कुछ है!)।

अगर हम उम्मीद करते हैं कि प्रत्येक एक्सएएमएल बोली का अपना फाइल एक्सटेंशन होगा तो प्रत्येक प्रोजेक्ट जो एक्सएएमएल का उपयोग करना चाहता है उसे स्क्रैच से टूलिंग का 100% लिखना होगा - यहां तक ​​​​कि फाइलों का नाम बदलने के लिए टूलिंग जैसी चीजें भी जा रही हैं जरूरत है हर बार कोडबेइंड क्लासेस आदि का नाम बदलने के लिए फिर से लिखा जाना है।

जैसा कि @stevenbrix ने ऊपर उल्लेख किया है, यह बताने का एक अच्छा तरीका है कि XAML की कौन सी बोली फ़ाइल का उपयोग कर रही है जो फ़ाइल के शीर्ष पर डिफ़ॉल्ट नामस्थान है। पहले कदम के रूप में, टूलींग को इसका सम्मान करें।

फिर एक्सएएमएल भाषा सेवा खोलें, एक डिजाइनर के साथ बातचीत करने के लिए एक एपीआई प्रदान करें और हर कोई लाभान्वित हो सकता है;)

मान जाओ ना ;)

एक और कारण नहीं: UWP पहले से ही गोद लेने के मुद्दों से जूझ रहा है। इसका नाम बदलने से इसे एक और तकनीक के रूप में बेचा जाता है, "यह कमोबेश wpf के समान ही है"।
WinUI 3.0 के टूटने में पहले से ही बड़े मुद्दे हैं जो मौजूदा uwp पारिस्थितिकी तंत्र को काफी नुकसान पहुंचा रहे हैं। एक और चीज़ न जोड़ें जो अलग हो।
यह अभी भी xaml है, बस अलग-अलग एपीआई सेट मार रहा है, जैसे सी # अभी भी सी # है, यहां तक ​​​​कि मैं इसे विभिन्न यूआई ढांचे के लिए भी उपयोग करता हूं। कोड और एपीआई मैं परिवर्तन का उपयोग कर सकता हूं, लेकिन यह अभी भी वही भाषा है।

मैं वोट नहीं देता, मुझे कोई लाभ नहीं दिख रहा है, बस भ्रम जोड़ा गया है।

एक और कारण नहीं: UWP पहले से ही गोद लेने के मुद्दों से जूझ रहा है। इसका नाम बदलने से इसे एक और तकनीक के रूप में बेचा जाता है, "यह कमोबेश wpf के समान ही है"।
WinUI 3.0 के टूटने में पहले से ही बड़े मुद्दे हैं जो मौजूदा uwp पारिस्थितिकी तंत्र को काफी नुकसान पहुंचा रहे हैं। एक और चीज़ न जोड़ें जो अलग हो।
यह अभी भी xaml है, बस अलग-अलग एपीआई सेट मार रहा है, जैसे सी # अभी भी सी # है, यहां तक ​​​​कि मैं इसे विभिन्न यूआई ढांचे के लिए भी उपयोग करता हूं। कोड और एपीआई मैं परिवर्तन का उपयोग कर सकता हूं, लेकिन यह अभी भी वही भाषा है।

@dotMorten हा, सी # के साथ मेरा भी यही विचार था। अगर हम .xaml फ़ाइलें .winui कहते हैं, तो हमें इसे सुसंगत बनाने के लिए .cs फ़ाइलों .wincode पर कॉल करना चाहिए। :-)

हो सकता है कि मुझे अभी भी कुछ याद आ रहा है, लेकिन मेरे लिए यह और अधिक भ्रम पैदा करता है और मुझे इसका वास्तविक लाभ नहीं दिखता है।

मेरे 2 सेंट, कृपया _.xaml_ के साथ रहें।
कृपया चीजों को अलग करने के बजाय एकजुट करें।

क्या होगा यदि आप डब्ल्यूपीएफ और विनयूआई के बीच छोटे एक्सएएमएल स्निपेट साझा करना चाहते हैं? मैं अनुमान लगा रहा हूं कि कुछ ओवरलैप होना चाहिए, नहीं? यह साझा परियोजनाओं को कम उपयोगी बना देगा ... या वास्तव में कोई बड़ा अंतर है? यदि यह अधिकतर समान एक्सएएमएल है तो वही एक्सटेंशन रखें। यदि प्रारूप संक्रमणकालीन एक्सएएमएल से अधिकतर भिन्न है तो यह विस्तार को बदलने के लिए कुछ हद तक स्वीकार्य हो सकता है। असली सवाल तो यह है कि प्रारूप मूल के कितना करीब है?

XAML का उपयोग Xamarin में भी किया जाता है जो न केवल Windows बल्कि iOS, Android, macOS को लक्षित करता है ...

.xaml को .winui से बदलने से एक ऐसी स्थिति पैदा होगी जहां Xamarin XAML फ़ाइलों के लिए .xaml रखेगा (क्यों कोई .winui का उपयोग iOS या Android के लिए करेगा?) और Windows लक्ष्य जैसे UWP/WPF... XAML फ़ाइलों के लिए .winui पर चले जाएंगे। .

टीएल; डीआर एक फ़ाइल प्रारूप/सम्मेलन दो नाम (विंडोज़ के लिए Winui, Xamarin के लिए .xaml), मेरे लिए यह भ्रमित करने वाला है।

एक्सटेंशन .xaml होना चाहिए क्योंकि सामग्री के सिंटैक्स के रूप में यह xaml है, दूसरा एक्सटेंशन केवल भ्रम पैदा करेगा।
मैं .winui.xaml जैसी किसी चीज़ के लिए वोट करता हूं

".xaml" के साथ रहें, यह शक्तिशाली है

मेरा कहना है, Microsoft के पास पैथोलॉजिकल नामकरण का मुद्दा है!

और यह वास्तव में उन सभी में सबसे ऊपर है।

नहीं

यदि आपको एक ही प्रोजेक्ट फ़ाइल में UWP XAML और WPF XAML की आवश्यकता है, तो इसके बजाय एक नए Custom Tool का उपयोग करें।

इस तरह, टूल यह पता लगाएगा कि क्या एक्सएएमएल फ़ाइल यूडब्ल्यूपी एक्सएएमएल या डब्ल्यूपीएफ एक्सएएमएल का उपयोग कर रही है और उन्हें एमएसबिल्ड लक्ष्यों के माध्यम से सही कंपाइलर को भेजती है।

एक्सएएमएल भाषा को मानकीकृत करना और भी बेहतर तरीका है, ताकि हम एक सामान्य कंपाइलर, बाइनरी फॉर्मेट और फ्रेमवर्क लिब विकसित कर सकें।

इस तरह मैं इसे करूँगा!

चूंकि आप पूछ रहे हैं, नहीं ऐसा मत करो।

यदि टूलिंग अंतर देखने के लिए फ़ाइल को नहीं पढ़ सकता है, तो WORSE CASE ".winui.xaml" या इसी तरह का एक गैर-आवश्यक सम्मेलन होना चाहिए। फिर से कुंजी NOT-REQUIRED है। बस xaml एक्सटेंशन फ़ाइलों को ठीक काम करना चाहिए, लेकिन शायद कुछ उन्नत टूलींग गायब हैं।

जबकि मैं इसके पीछे के विचार को समझता हूं, मुझे लगता है कि यह एक बुरा समाधान है।
सबसे पहले, WinUI फ्रेमवर्क व्यावसायिक नाम है, न कि फ़ाइल स्वरूप। क्या होगा यदि कोई संस्करण 4 का निर्णय करता है कि नाम को UniversalUI या कुछ और में बदलने की आवश्यकता है? आप फ़ाइल स्वरूप से भिन्न फ़ाइल एक्सटेंशन से भिन्न फ़्रेमवर्क नाम के साथ समाप्त करेंगे। यह एक बुरा सपना हो सकता है।

दूसरा, यह मौजूदा टूल और दस्तावेज़ीकरण के साथ संगतता को भंग कर सकता है। भविष्य के देवता यह स्पष्ट नहीं कर सकते थे कि WinUI फ़ाइलें आंतरिक रूप से xaml हैं, इसलिए उन्हें xaml दस्तावेज़ प्रासंगिक के रूप में नहीं मिलेंगे।

तीसरा, यह Microsoft उत्पादों में उपयोग की जाने वाली UI भाषाओं को और अधिक खंडित करेगा। मुझे वास्तव में Xaml में एक मानक के लिए और अधिक जाने की आवश्यकता है, इसलिए उत्पाद इतना महत्वपूर्ण नहीं है। C# Xamarin, Net Core, Windows 10 या WPF के लिए समान है, XAML को अलग होने की आवश्यकता क्यों है?

लोगों को अपनी परियोजनाओं को व्यवस्थित करने दें और कोड को व्यवस्थित करें ताकि यह उनके लिए भ्रमित न हो।

जेसन प्रारूप का प्रयोग करें। 2020 है।

@rickydatta 2020 में भी वेब यूजर इंटरफेस को परिभाषित करने के लिए JSON के बजाय HTML का उपयोग करता है। HTML और XAML जैसी मार्कअप भाषाएं UI को परिभाषित करने के लिए बहुत अच्छे हैं, इसके कई कारण हैं। JSON कई चीजों के लिए बहुत अच्छा है, लेकिन imo UI को परिभाषित करने के लिए नहीं है। जब आप UI के लिए JSON का उपयोग करते हैं और आप डेटा बाइंडिंग, स्थिर संसाधन संदर्भ आदि जैसी सुविधाओं का निर्माण करने का प्रयास करते हैं, तो आप देखेंगे कि यह काफी अपठनीय हो जाता है। लेकिन यह यहाँ विषय से परे है, तो चलिए इसे छोड़ देते हैं। यदि आप JSON चाहते हैं, तो कृपया एक नया मुद्दा बनाएं और देखते हैं कि समुदाय इस पर कैसे प्रतिक्रिया करता है। :-)

मैंने वास्तव में यहां टिप्पणी करने से बचने की कोशिश की क्योंकि इनमें से अधिकांश पहले ही कहा जा चुका है, लेकिन मैंने अंदर दिया है। क्षमा करें। मैं कमजोर हूँ।

यह मत करो।

यदि आप कोई परिवर्तन करना चाहते हैं, तो लाभों का एक स्पष्ट सेट होना चाहिए जो नकारात्मक से अधिक हो।

संभावित लाभ क्या हैं?

• यह उन लोगों के लिए संभावित भ्रम से बच जाएगा जिनके पास कुछ .xaml फ़ाइलें हैं जिनमें पूरी तरह से WinUI नियंत्रण और कुछ .xaml फ़ाइलें नहीं हैं।
• .xaml फ़ाइलों की संभावित रूप से भिन्न सामग्री के साथ काम करने का तरीका निर्धारित करने के लिए टूलिंग को सक्षम करने में सहायता करें।

बस, इतना ही।
मैंने इस पूरे धागे को तीन बार फिर से पढ़ा है, और मुझे यहां सूचीबद्ध कोई अन्य संभावित लाभ नहीं दिख रहा है।

संभावित डाउनसाइड्स क्या हैं?

• यह भ्रम का परिचय देगा।
  -- "यह नया एक्सटेंशन क्या है?" "मुझे इसे खोलने की क्या ज़रूरत है?" "यह कैसे अलग है ...?" "उन्होंने इसे क्यों बदला?"
  -- मौजूदा UWP XAML और WinUI3 तत्वों को मिलाते समय आप किसी फ़ाइल के लिए किस एक्सटेंशन का उपयोग करते हैं जिसमें केवल कुछ WinUI नियंत्रण होते हैं? या क्या इसी सुझाव का अर्थ यह है कि यह क्षमता समाप्त हो जाएगी? (देखें, केवल एक फ़ाइल एक्सटेंशन को बदलने का सुझाव देकर, आप पहले से ही अधिक भ्रम और FUD का परिचय दे रहे हैं। यदि फ़ाइल एक्सटेंशन जैसी चीजें अभी भी बदल सकती हैं, तो शायद मुझे WinUI को किसी भी क्षमता में देखने के लिए इंतजार करना चाहिए, जब तक कि यह अधिक स्थिर न हो जाए। . कई लोगों ने मुझे फ़्लटर की जांच करने के लिए कहा है। शायद मेरे लिए एक बेहतर भविष्य वहीं है।)
  - मौजूदा डब्ल्यूपीएफ ऐप्स में एक्सएएमएल आइलैंड्स के विक्रय बिंदुओं में से एक के बारे में मेरी समझ यह थी कि इसका मतलब एक्सएएमएल के साथ काम करने में मौजूदा कौशल और ज्ञान का पुन: उपयोग करने की क्षमता है। यह परिवर्तन बताता है कि यह सिर्फ एक्सएएमएल नहीं है, इसलिए यह एक और चीज है जिसे सीखा जाना चाहिए, और गोद लेने के लिए एक और संभावित बाधा भी है।)

• यह अनावश्यक है।
  -- अगर लोग समाधान के भीतर फाइलों को तोड़ना चाहते हैं तो वे इसे पहले से ही कई तरीकों से कर सकते हैं: विभिन्न परियोजनाएं; विभिन्न निर्देशिका; फ़ाइल नामों पर उपसर्ग या प्रत्यय; एकाधिक/उप-एक्सटेंशन का उपयोग करना; या वीएस सॉल्यूशन एक्सप्लोरर के भीतर फाइलों को घोंसला बनाना। यह स्पष्ट नहीं है कि एक नया एक्सटेंशन या सभी को एकाधिक/उप एक्सटेंशन का उपयोग करने के लिए मजबूर करना इनमें से किसी भी विकल्प से बेहतर कैसे है।
  - [डिफ़ॉल्ट] फ़ाइल के भीतर नामस्थान पहले से ही टूलिंग को बताते हैं कि एक्सएएमएल की कौन सी बोली उपयोग में है और इसके साथ क्या संभव होना चाहिए। (इस क्षेत्र में कुछ अन्य गैर-दस्तावेज समस्या हो सकती है जिसका अर्थ है कि यह संभव नहीं है, लेकिन यदि ऐसा है, तो फ़ाइल एक्सटेंशन को बदलना उस समस्या का सबसे अच्छा समाधान क्यों है, इस बारे में अधिक जानकारी की आवश्यकता है।)

• यह इतिहास की उपेक्षा करता है।
  - मैंने पहले उन समाधानों के साथ काम किया है जिनमें डब्ल्यूपीएफ, सिल्वरलाइट और विंडोज फोन को लक्षित करने वाली परियोजनाएं शामिल थीं। वे सभी अलग-अलग एक्सएएमएल बोलियों का इस्तेमाल करते थे लेकिन मैं कभी भी भ्रमित नहीं हुआ कि कौन सा उपयोग में था या मैं फ़ाइल में क्या कर सकता था। मैंने उन समाधानों के साथ काम किया है जिनमें UWP और Xamarin.Forms के लिए XAML शामिल है, लेकिन इस मुद्दे के पीछे की धारणा में अनुमानित भ्रम का अनुभव नहीं किया। मैंने इसी तरह के समाधान वाले कई अन्य डेवलपर्स से भी बात की है, और मैंने कभी किसी और को यह कहते नहीं सुना है कि विभिन्न एक्सटेंशन का उपयोग करने से उन्हें मदद मिलेगी।
  - एक्सएएमएल की अलग-अलग बोलियां होने के बारे में मैंने जितनी भी आलोचनाएं सुनी हैं, उनमें से फ़ाइल नामकरण पर आधारित भ्रम कभी भी उनमें से एक नहीं रहा है।
  - डेवलपर्स आमतौर पर इसे पसंद नहीं करते हैं जब आप उन्हें बताते हैं कि उन्हें बिना किसी अच्छे कारण के फाइलों और परियोजनाओं का नाम और संरचना कैसे करनी चाहिए। परिदृश्यों के लिए मार्गदर्शन और अनुशंसित/सुझाई गई प्रथाओं को दस्तावेज करना बेहतर हो सकता है जैसे परियोजनाओं के साथ काम करना जिसमें समान सामग्री वाली फाइलें होती हैं।
  - एक बड़ा कारण यह है कि किसी फ़ाइल पर एकाधिक एक्सटेंशन का व्यापक उपयोग कभी बंद नहीं हुआ है, वह यह है कि फ़ाइल एक्सप्लोरर (या कुछ भी जो फ़ाइल सिस्टम की सामग्री को सूचीबद्ध करता है - जिसमें ओएस प्रदान किए गए पिकर और डायलॉग शामिल हैं) अधिक भ्रम पैदा कर सकते हैं जब वे ( कॉन्फ़िगर किए गए हैं--जो कि डिफ़ॉल्ट है) ज्ञात फ़ाइल एक्सटेंशन छुपाएं। यह MyClass.winui.xaml को MyClass.winui जैसा बना सकता है, जो तब प्रश्नों और भ्रम की ओर ले जाता है कि फ़ाइल क्या है, यह कहाँ से आई है, इसे क्यों दिखाया जा रहा है, आदि।
  -- एकाधिक/उप एक्सटेंशन जोड़ने से फ़ाइल की लंबाई बढ़ जाती है और इसलिए MAXPATH संबंधित मुद्दों में चलने की संभावना बढ़ जाती है। शायद एक दिन यह कोई मुद्दा नहीं होगा, लेकिन हम अभी तक नहीं हैं। मैं डेवलपर्स को अपनी फाइलें (और कक्षाएं, क्योंकि दोनों को आमतौर पर सिंक में रखा जाता है) को कम वर्णनात्मक नाम देने के लिए मजबूर होना पसंद नहीं है क्योंकि टूलिंग को अब एक्सटेंशन के लिए अतिरिक्त छह वर्णों की आवश्यकता है।

• यह टूलिंग डेवलपर्स के लिए और अधिक काम बनाता है। (माइक्रोसॉफ्ट के भीतर और बाहर दोनों।)
  - अधिक मामले को संभालने के लिए।
  - दस्तावेज़ और परीक्षण के लिए और अधिक परिदृश्य।
  - बग फिक्स और नई सुविधाओं पर कम समय बिताया। वर्तमान एक्सएएमएल टूलिंग के साथ अन्य तकनीकों के पीछे कमी और कस्टम टूलिंग बनाने में धीमी होने के कारण, कुछ भी ऐसा क्यों है जो नए टूलिंग को धीमा कर देता है?

• यह एक बहुत खराब मिसाल कायम करने का जोखिम उठाता है।
  -- यदि ऐसा हुआ, तो सभी मौजूदा .xaml फ़ाइलों को .wpf , .uwp , .xamarinforms , आदि से बदलना उचित क्यों नहीं होगा? या .xaml2006 , .xaml20009 , .xaml-uwp5 यदि अंतर्निहित नाम स्थान, बजाय इसके कि उनका उपयोग कहां किया जाता है, प्रमुख मुद्दा है? कम से कम संभावित लाभ होगा (जैसा कि इस मामले में), लेकिन इसे कई लोगों द्वारा देखा जाएगा जिस तरह से माइक्रोसॉफ्ट फाइलों का नामकरण करने का सुझाव देता है। (मुझे आश्चर्य नहीं होगा अगर किसी ने इस तरह के प्रस्ताव सिर्फ यहां चर्चा को देखकर नहीं बनाए।)
  - मुझे इस बात की जानकारी नहीं है (लेकिन इसके बारे में सही होने के लिए खुश) किसी भी एमएस ने उप-एक्सटेंशन के आधार पर अलग-अलग टूलिंग हैंडलिंग फाइलें प्रदान की हैं, लेकिन ऐसा करने से विजुअल स्टूडियो (और अन्य ?, विंडोज शैल सहित?) को होने की आवश्यकता होगी। इन परिदृश्यों को संभालने में सक्षम। फिर, एक बार क्षमता होने के बाद, मैं जटिल की एक विस्तृत श्रृंखला को पेश करने के प्रलोभन की कल्पना कर सकता हूं, लेकिन अन्यथा अनावश्यक नामकरण सुझाव प्रस्तावित किए जा रहे हैं और कुछ डेवलपर्स के लिए बहुत अधिक पेश किए जा रहे हैं, जिससे हममें से बाकी लोगों के लिए भ्रम पैदा हो रहा है।

संक्षेप में, प्रस्ताव सीमित परिस्थितियों में सैद्धांतिक लाभ के लिए भ्रम और अधिक काम लाएगा। यदि आपने ऐसा किया है, तो मैं विंडोज़ विकास को छोड़ दूंगा।

अपनी आवाज देने के लिए सभी को धन्यवाद। हमने आपको सुना! हमने पर्याप्त प्रतिक्रिया एकत्र की है, इसलिए हम दृढ़ता से कह सकते हैं कि .xaml एक्सटेंशन को बदलना एक गैर-जाना है ।

पारिस्थितिकी तंत्र को खंडित करने या तीसरे पक्ष के उपकरणों को तोड़ने का हमारा इरादा नहीं है (और बहुत सारे हैं)। हम सहमत हैं कि XAML भाषा है, और WinUI 3 एक UI फ्रेमवर्क है जो XAML का उपयोग करता है। इन सभी कारणों से, और अन्य कारणों से, xaml एक्सटेंशन का उपयोग जारी रखना समझ में आता है।

हमारी टीम को अभी भी कुछ होमवर्क करना है और अन्य विकल्पों का मूल्यांकन करना है जो हमें बाद में समुदाय के साथ परामर्श करना चाहिए। उदाहरण के लिए:

1. कुछ मत करो। एक्सएएमएल द्वीप देव अनुभव इस प्रकार होगा: एक अलग परियोजना में एक्सएएमएल फाइलें (शायद यह कोई बड़ी बात नहीं है)। WInUI 3 समान नामस्थान का उपयोग करेगा, और इससे कोई फर्क नहीं पड़ता क्योंकि यह प्रोजेक्ट पर उपयोग की जाने वाली एकमात्र XAML भाषा होगी।

2. XAML पर आधारित UI के बीच अंतर करने के लिए नेमस्पेस का उपयोग करें। आज, डब्ल्यूपीएफ एक्सएएमएल और यूडब्ल्यूपी एक्सएएमएल एक ही नामस्थान का उपयोग करते हैं, शायद विनयूआई 3 को एक अलग नामस्थान का उपयोग करना चाहिए जैसे कि ज़ामरीन फॉर्म कर रहा है ("http://xamarin.com/schemas/2014/forms"), इसलिए संकलक, उपकरण और डिजाइनर फाइलों में अंतर कर सकता है। दूसरी तरफ, यह बोलियां बनाएगा, हालांकि यह आज हो रहा है। सिद्धांत रूप में, यह देवों को दस्तावेज़/ब्लॉग से XAML उदाहरणों को कॉपी और पेस्ट करने की सुविधा प्रदान करेगा, हालांकि दुर्भाग्य से, ऐसे बहुत से नमूने हैं जिनमें नामस्थान शामिल नहीं हैं।

3. कुछ करो, लेकिन सिर्फ द्वीपों के लिए। सभी UI फ्रेमवर्क में अंतर करने की आवश्यकता नहीं है। हम सम्मेलनों का उपयोग कर सकते हैं। उदाहरण के लिए, भविष्य में, एक्सएएमएल द्वीप के साथ एक डब्ल्यूपीएफ ऐप में एक विशिष्ट फ़ोल्डर (द्वीप फ़ोल्डर?) में एक्सएएमएल फाइलें हो सकती हैं। यह UWP स्थानीयकरण के समान है (Strings/en-US/Resources.resw)।

आपकी प्रतिक्रिया के लिए फिर से धन्यवाद । जब हम और अधिक विचारों को परिपक्व करेंगे तो मैं नई चर्चाओं की शुरुआत करूंगा।

एक द्वीप फ़ाइल के लिए एक स्निपिट या डॉक्ट टाइप स्टाइल लाइन सहित, टूलींग के लिए पर्याप्त होना चाहिए।

अगर .ui.xaml विचार पसंद है क्योंकि यह एक अच्छा समझौता है। यह अभी भी एक वैध एक्सएएमएल एक्सटेंशन है, और सही संपादक और आइकन चुनने में भी मदद कर सकता है। यह सिर्फ एक प्रकार खोजने के लिए दर्जनों/सैकड़ों एक्सएएमएल फाइलों को खोलने और पार्स करने से भी अधिक कुशल है।

@marb2000 WinUI 3 एक UI फ्रेमवर्क है जो XAML का उपयोग करता है

होना चाहिए: WinUI 3 एक UI फ्रेमवर्क है जो XAML का उपयोग कर सकता है। चूंकि इसे एक्सएएमएल के उपयोग की आवश्यकता नहीं है और इसे एक्सएएमएल भाषा पर निर्भरता की आवश्यकता नहीं है।

हम सहमत हैं कि XAML भाषा है

यह अच्छा है, और बहुत से नामस्थान जिन्हें XAML कहा जाता है, का नाम बदलकर WinUI में करने की आवश्यकता है: कुछ भी जिसका XAML भाषा से कोई लेना-देना नहीं है।

यूडब्ल्यूपी का डी-जोर गवाह के लिए दर्दनाक रहा है। अब, जब आप चैनल 9 पर UWP सामग्री के लिए खोज करते हैं, तो आपको Xamarin सामग्री मिलती है। यह इतना स्पष्ट चाल है। कृपया UWP को किसी और चीज़ में रूपांतरित करने का प्रयास करना बंद करें! फिर से निवेश करें, दोगुना करें और इसे काम करें। UWP को पाठ्यक्रम सुधार की आवश्यकता नहीं है, इसे बोर्ड पर लाने के लिए Xamarin और Office टीमों की आवश्यकता है। आंतरिक Microsoft राजनीति UWP को मार रही है।

@Noemata क्या यह एक आधिकारिक नोट है?