शायद एक दूर की बात है, लेकिन ब्लेंड को ओवरहाल करने की जरूरत है और एक डिजाइन केंद्रित वर्कफ़्लो की आवश्यकता है।

XAML डिज़ाइनर को मज़बूत और शक्तिशाली होने की आवश्यकता है।

पृष्ठ/विंडो की स्तरित संरचना की कल्पना करने का कोई तरीका, विशेष रूप से उन्नत नियंत्रणों के साथ महत्वपूर्ण।

किसी पृष्ठ के बाहर UI तत्वों की कल्पना करने के तरीके, जैसे व्यक्तिगत नियंत्रण/टेम्पलेट।

डिज़ाइनर के भीतर CoreOS, "सरफेस फ़ोन", सरफेस हब, Xbox, HoloLens, के लिए बनाए गए नियंत्रण अनुकूलन प्रदर्शित करें।

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

XAML को आयात और निर्यात करने के अच्छे तरीके, इसलिए डिज़ाइनर मुख्य ऐप से अलग ब्लेंड में काम कर सकते हैं, और फिर उन्हें ऐप में लाने के लिए विकास टीमों को सौंप सकते हैं।

बेहतर विज़ुअलाइज़ेशन और सिस्टम संसाधनों की सूची, साथ ही उन वैश्विक संसाधनों को बाहर निकालने के शानदार तरीके जिन्हें डिफ़ॉल्ट को ओवरराइड करने के लिए हल्का स्टाइल किया जा सकता है, और डिज़ाइन की सतह वास्तविक समय में उन परिवर्तनों को दर्शाती है।

WinForms, MFC आदि वाले ऐप्स के साथ विभिन्न DPI स्केलिंग के परीक्षण के बेहतर तरीके।

नए नियंत्रणों के लिए टेम्प्लेट, अनुकूलित थीम संसाधन शब्दकोश, फ़्लुएंट थीम संपादक को एकीकृत करें, समर्थित ऐप संयोजनों के लिए टेम्प्लेट (Xaml UI के साथ Win32 MFC, आदि)।

फ़ाइल पिकर, टास्क ट्रे फ़्लायआउट जैसे शेल एकीकरण बिंदुओं के लिए टेम्पलेट।

ये बस कुछ विचार हैं...

मेरे विचार इस प्रकार हैं:

1. MSIX सब ठीक है और अच्छा है, लेकिन मैं अभी भी अधिक जटिल अनुप्रयोगों को स्थापित करने के लिए अच्छे पुराने MSI का उपयोग करता हूं जिनके लिए ऐसी सुविधाओं की आवश्यकता होती है जो MSIX का समर्थन नहीं करती हैं। मैं एमएसआईएक्स का उपयोग करने के लिए भी इच्छुक हूं क्योंकि आवश्यक ऑथेंटिकोड प्रमाणपत्र कितने महंगे हैं। (मैं एक स्व-हस्ताक्षरित प्रमाण पत्र के साथ आसानी से अपने कोड पर हस्ताक्षर कर सकता हूं, जो मुझे लगता है कि वह उतना ही सुरक्षित है जितना कि मैं एक फर्म से खरीदता हूं, लेकिन फिर विंडोज इसे लोड नहीं करेगा। विंडोज खुशी से एक स्व-हस्ताक्षरित एमएसआई फ़ाइल को स्वीकार करेगा, हालांकि .) जब तक मैं एमएसआई-आधारित एप्लिकेशन से विनयूआई 3 का उपयोग कर सकता हूं, मुझे खुशी है।
2. एक बेहतर XAML डिज़ाइनर की बहुत सराहना की जाएगी, लेकिन मुझे WinUI XAML और WinForms/WPF डिज़ाइनरों को एक में एकीकृत करने की अतिरिक्त जटिलता की आवश्यकता नहीं है। मैं वीएस में विभिन्न टैब के बीच फ्लिप-फ्लॉपिंग के साथ बिल्कुल ठीक हूं।
3. जैसा कि मैंने पहले टिप्पणी की थी , C# और विजुअल बेसिक प्रोजेक्ट सिस्टम से XBF कंपाइलर को डिकूप करना बहुत उपयोगी होगा। (यह और भी बेहतर होगा यदि एक्सबीएफ कंपाइलर स्रोत, या इसे फिर से बनाने के लिए पर्याप्त दस्तावेज जारी किया गया था, लेकिन मुझे नहीं पता कि ऐसा होने की कितनी संभावना है।)
4. C++ प्रोजेक्ट सिस्टम में C++/WinRT और MIDL 3 के लिए बेहतर सपोर्ट। वर्तमान में, C++/WinRT का उपयोग करने के लिए परियोजना समर्थन भंगुर और भद्दा है। (उदाहरण के लिए, यदि आप आईडीएल फ़ाइल में नाम स्थान बदलते हैं - जिसकी अक्सर आवश्यकता होती है यदि प्रोजेक्ट नाम में एक बिंदु है जिसे आप नामस्थान में उपयोग करना चाहते हैं, क्योंकि टेम्पलेट उन्हें स्वचालित रूप से अंडरस्कोर में परिवर्तित कर देता है - आपका प्रोजेक्ट संकलित करने में विफल रहेगा , और मेरे अनुभव में समस्या को ठीक करने के लिए *.h और *.cpp फ़ाइलों को एक तरफ ले जाना, उन्हें स्क्रैच से पुन: उत्पन्न करना, कोड पर कॉपी करना, और फिर नेस्टिंग को ठीक करने के लिए vcxproj फ़ाइल को उतारना और संपादित करना आवश्यक है।) जितना अधिक मैं vcxproj की तुलना में कुछ अधिक आधुनिक और लचीला उपयोग करना चाहता हूं, मैं ऐसा नहीं कर सकता क्योंकि एक्सबीएफ कंपाइलर की कड़ी निर्भरता के कारण मैं ऐसा नहीं कर सकता।

अगर कुछ और आता है, तो मैं इसे यहाँ पोस्ट करना सुनिश्चित करूँगा। धन्यवाद!

1. मैं यहां जो सोच रहा हूं, वह है... ठीक है, क्या मुझे नामस्थान उपसर्ग का उपयोग करने की आवश्यकता होगी जैसे < winui:Listview या < controls:listview या जो भी देव निर्णय लेते हैं? मुझे लगता है कि यह बहुत बेहतर होगा, यदि संभव हो तो उपयोग करने के लिए अब जैसा ही अनुभव है, बस केवल कुछ नियंत्रणों के लिए उपसर्ग ठीक है, और बढ़िया है। लेकिन जब आप हर जगह उपयोग करना शुरू करते हैं, तो यह एक्सएएमएल को एक दुःस्वप्न और बहुत कुछ पढ़ता है।
   नामस्थान उपसर्ग का उपयोग करने का कोई मतलब नहीं है, क्योंकि Windows.UI.Xaml.Controls का उपयोग करना संभव नहीं होगा और WinUI डिफ़ॉल्ट विकल्प होगा।

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

3. माइग्रेशन करने के लिए एक टूल दिलचस्प होगा। विशेष रूप से क्योंकि इसमें स्क्रॉलव्यूअर जैसे अद्यतन WinUI 3.0 नियंत्रणों के साथ कुछ संगत समस्याएं हो सकती हैं। इसलिए यदि कोई उपकरण है, तो उसे इन अद्यतन/पुनः लिखित नियंत्रणों पर कम से कम संभावित चेतावनियां दिखाने की आवश्यकता होगी।

1. हमें डिजाइनर से अलग IntelliSense के साथ मजबूत, xaml कोड संपादक की आवश्यकता है।
   ज्यादातर समय मैं सिर्फ सी # जैसे एक्सएमएल कोड लिख रहा हूं। वर्तमान में, कोड संपादक धीमा और नाजुक है, जिसे मेरी पिछली टिप्पणी में समझाया गया है। IntelliSense का अनुभव भी काफी सरल है। कोई त्वरित दस्तावेज़ीकरण जानकारी नहीं, कोई सदस्य नाम नहीं बदल रहा है।
2. x:Bind लिए डिज़ाइन डेटा समर्थन काफी कठिन हो सकता है, क्योंकि मैं फ़ंक्शन बाइंडिंग में जटिल सहायक लिख रहा हूं। लेकिन चीजें बेहतर हो सकती हैं अगर xaml बिल्ट-इन फंक्शंस कुछ हेल्पर्स को बदल सकते हैं।
3. मैं अपने अनुप्रयोगों के लिए पैकेजिंग मॉडल के और अधिक निःशुल्क संयोजन चाहता हूं। विषय से परे हो सकता है, लेकिन मुझे ऐप मॉडल टीम को फीडबैक देने के लिए कहीं भी नहीं मिल रहा है।

टीएल; डीआर मैं एक ऐप मॉडल समर्थन आर्बिटरी इंस्टेंस सह-अस्तित्व चाहता हूं। यहां तक ​​​​कि वही संस्करण अंतर डेटा/विकल्प सेट के साथ चल सकता है, जैसे विजुअल स्टूडियो हाइव्स। वर्तमान में एकमात्र समाधान xcopy प्रतीत होता है।

क्या कोई मुझे बता सकता है कि इसे कैसे ध्वस्त किया जाए?

सबसे पहले, मैं उस ऐप का भी उपयोग कर रहा हूं जिसे मैं दैनिक विकसित कर रहा हूं (और अधिकांश दिनों के लिए >> डीबग का उपयोग करें)। तो देव निर्माण को स्थिर निर्माण के साथ सह-अस्तित्व में बनाने से मुझे बहुत मदद मिलेगी। वर्तमान में मुझे संस्करण संख्या बढ़ानी है, डीबग एमएसिक्स पैकेज करना है, डीबग करने के लिए स्थापित पैकेज संस्करण अपडेट करना है।
विभिन्न डिबग चरणों के दौरान, मुझे अलग क्षमता चाहिए। जटिल वास्तविक दुनिया डेटा के लिए, मैं चाहता हूं कि डीबग इंस्टेंस डेटा को स्थिर के साथ साझा करे। मनमाना नकली डेटा के लिए, मैं हालांकि अलगाव चाहता हूँ। यह सैद्धांतिक रूप से फ़ोल्डर पिकर का उपयोग करके डेटा तक पहुंच द्वारा हल किया गया है, लेकिन यह बहुत खेद है कि यूडब्ल्यूपी में SQLite इसका समर्थन नहीं करता है, और कोई अन्य एम्बेडेड एसीआईडी ​​​​इंजन नहीं है जैसा कि मुझे पता है।

ओह, और दूसरी बात। अगर vcxproj को NuGet पैकेज संदर्भों के लिए package.config के उपयोग की आवश्यकता के बारे में कुछ किया जा सकता है, तो मैं वास्तव में इसकी सराहना करता हूं। WinUI को NuGet पैकेज के रूप में वितरित किया जाता है, जैसा कि C++/WinRT और अन्य प्रमुख घटकों में है। मुझे वास्तव में package.config का उपयोग करना पसंद नहीं है। PackageReference बहुत अधिक कुशल है (और यदि आप vcxproj को किसी भिन्न निर्देशिका में ले जाते हैं तो इसका परिणाम टूटा हुआ निर्माण नहीं होता है)। यह वास्तव में तब तक काम करता है जब vcxproj से उपयोग किया जाता है, जब तक कि पुनर्स्थापना लक्ष्य उचित समय पर चलाया जाता है। (ऐसा इसलिए है क्योंकि vcxproj लक्ष्य अप्रत्यक्ष रूप से गैर-SDK C# प्रोजेक्ट्स के लिए PackageReference पुनर्स्थापना मशीनरी आयात करते हैं।) मैंने ऐसे लक्ष्यों का एक सेट लिखा है जो PackageReference आइटम के सेट में परिवर्तन होने पर स्वचालित रूप से पुनर्स्थापना लक्ष्य चलाते हैं, क्योंकि VS ऐसा नहीं करेगा। खुद (अभी तक)। दुर्भाग्य से, NuGet सिस्टम इस बारे में कुछ नहीं जानता है, और जब मैं C++/WinRT फ़ाइल टेम्पलेट जोड़ता हूं तो यह एक package.config फ़ाइल जोड़ने का प्रयास करता है। यह सभी प्रकार के कहर का कारण बनता है, जिसके परिणामस्वरूप एक अपवाद फेंका जाता है और एक टूटी हुई परियोजना फ़ाइल होती है। मुझे यकीन नहीं है कि इसे कैसे हल किया जाए, लेकिन मैं वास्तव में इसकी सराहना करता हूं अगर इसे कम से कम WinUI 3 जारी होने से पहले देखा जा सके। धन्यवाद!

यह अच्छा होगा, अगर WinUI नए प्रोजेक्ट sdk - Microsoft.NET.Sdk या MSBuild.Sdk.Extras का समर्थन करता है।
पुरानी शैली की csproj फ़ाइलों को बनाए रखना कठिन है। और हम इसके साथ कई

एफ # सपोर्ट क्यों नहीं?

क्या Azure DevOps और Visual Studio ऐप सेंटर की कार्यक्षमता पर यहाँ चर्चा की जानी चाहिए?

@vitorgrs की तरह, मैं नामस्थान उपसर्ग के बिना मूल नियंत्रण पसंद करता हूं, यह कोड में "शोर" जोड़ता है। और यह देखने में मदद करता है कि कौन से देशी नियंत्रण हैं, और कौन से तृतीय पक्ष हैं।

एक माइग्रेशन टूल निश्चित रूप से अच्छा होगा। अगर यह तीसरे पक्ष के बड़े प्रदाताओं (टेलीरिक, डेवएक्सप्रेस,...) के साथ काम करता है तो यह पहले से ही एक बड़ी बात होगी।

टेम्पलेट्स

क्या यूडब्ल्यूपी एक्सएएमएल टेम्पलेट्स के पिछले संस्करणों के लिए वीएस नए प्रोजेक्ट प्रवाह में बने रहने के लिए रुचि/आवश्यकता है?

मेरी तरफ से टेम्प्लेट रखने की कोई जरूरत नहीं है। लेकिन क्या ऐसा हो सकता है कि UWP का एक Control हो जो WinUI में नहीं है? यदि ऐसा हो सकता है, तो पारंपरिक UWP ऐप बनाने और आवश्यक नियंत्रण होने पर इसे WinUI में माइग्रेट करने का यह एक वैध कारण हो सकता है। तब टेम्पलेट की आवश्यकता हो सकती है।

हो सकता है कि यह डेवलपर्स के लिए भी भ्रमित करने वाला हो यदि आपने एक ऐप बनाया है और आप इसे नवीनतम विज़ुअल स्टूडियो संस्करण के साथ नहीं बना सकते हैं।

लेकिन व्यक्तिगत रूप से, मुझे टेम्प्लेट रखने में कोई दिलचस्पी नहीं है

विजुअल स्टूडियो में टेम्प्लेट और घटकों के संबंध में हम आपको अधिक कुशल या सफल होने में कैसे मदद कर सकते हैं?

मेरे लिए यह यूडब्ल्यूपी के लिए बहुत अच्छा लग रहा है। अब मैं इसे Win32 के लिए देखना चाहता हूं। :)

क्या यह चलना मददगार है और क्या आप इसे और अधिक देखना चाहेंगे क्योंकि परिदृश्य आकार लेते हैं?

हाँ निश्चित रूप से। भविष्य क्या हो सकता है और कैसा दिखना चाहिए, यह समझने के लिए यह चलना बहुत मददगार है। मैं इसे और देखना चाहूंगा।

प्रवास

क्या यह फायदेमंद होगा यदि हम एक माइग्रेशन टूल प्रदान करते हैं जो स्वचालित चरणों को 1-3 करता है?

निश्चित रूप से। शायद इस माइग्रेशन के लिए थोड़ा सा विजुअल स्टूडियो एक्सटेंशन एक बढ़िया विकल्प होगा। मैं "WinUI संगतता विश्लेषक" जैसा कुछ भी सोच सकता हूं जो आउटपुट करता है कि क्या माइग्रेट किया जा सकता है और क्या नहीं। .NET पोर्टेबिलिटी विश्लेषक के समान कुछ।

नेटिव विंडोज 10 कंट्रोल सेट के बाहर से आप किन पुस्तकालयों का उपयोग कर रहे हैं?

आमतौर पर टेलीरिक डेटाग्रिड और सामुदायिक टूलकिट

हम किस तरह से प्रवासन में सहायता कर सकते हैं जिसके बारे में हम वर्तमान में नहीं सोच रहे हैं?

यदि आप विजुअल स्टूडियो में एक यूडब्ल्यूपी ऐप खोलते हैं जिसमें आपके द्वारा इंस्टॉल किए गए विन एसडीके से कम संस्करण है, तो विजुअल स्टूडियो इसे आपके लिए माइग्रेट करता है। हो सकता है कि आपको WinUI माइग्रेशन के लिए भी कुछ ऐसा ही सोचना चाहिए। मुझे यकीन नहीं है, लेकिन यह ध्यान में रखने वाली बात है। विशेष रूप से जब विजुअल स्टूडियो में अब सामान्य UWP टेम्प्लेट नहीं होते हैं, तो डेवलपर्स के लिए एक ऐसा एप्लिकेशन होना भ्रमित करने वाला हो सकता है जिसे आप टेम्प्लेट के साथ नहीं बना सकते।

अन्य

जैसा कि अन्य टिप्पणियों में पहले ही उल्लेख किया गया है, मुझे लगता है कि यह एसडीके-शैली .csproj फ़ाइलों पर स्विच करने का समय है।

विंडोज़ टेम्पलेट स्टूडियो में विनुई 3.0 टेम्पलेट जोड़ें।

डेस्कटॉप ऐप्स में WinUI

डेस्कटॉप में WinUI डेवलपर्स को डेस्कटॉप एप्लिकेशन मॉडल पर विंडोज यूआई लाइब्रेरी का उपयोग करने की अनुमति देगा। @marb2000 आने वाले हफ्तों में अधिक विस्तृत चर्चा पोस्ट पर काम कर रहा है। सुझावों के लिए तब तक इस धागे का उपयोग करने के लिए स्वतंत्र महसूस करें।

एक .net डेवलपर के रूप में, यह वह हिस्सा है जिसमें मुझे सबसे अधिक दिलचस्पी है।

टेम्पलेट्स

• क्या यूडब्ल्यूपी एक्सएएमएल टेम्पलेट्स के पिछले संस्करणों के लिए वीएस नए प्रोजेक्ट प्रवाह में बने रहने के लिए रुचि/आवश्यकता है?

टेम्पलेट्स की संख्या के आधार पर। यदि संख्या कम है (उदाहरण के लिए प्रति भाषा केवल "ब्लैंक ऐप (यूनिवर्सल विंडोज)", तो सी # के मामले में 1, शोर कम है और इसका समर्थन किया जा सकता है। लेकिन अगर इसमें कुछ से अधिक टेम्प्लेट शामिल हैं, तो उन्हें डिफ़ॉल्ट रूप से शामिल न करें और उन्हें जोड़ने के लिए एक वैकल्पिक VS इंस्टॉल घटक जोड़ें।

• विजुअल स्टूडियो में टेम्प्लेट और घटकों के संबंध में हम आपको अधिक कुशल या सफल होने में कैसे मदद कर सकते हैं?

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

परियोजनाओं के बीच टूलबॉक्स में घटकों के लिए भी अच्छा समर्थन प्रदान करें। प्रोजेक्ट द्वारा समूहीकृत टूलबॉक्स में तुरंत नए नियंत्रण प्रदर्शित किए जाने चाहिए। शायद उन्हें अलग करने में मदद करने के लिए डिज़ाइनर आइकन के लिए समर्थन।

• क्या यह चलना मददगार है और क्या आप इसे और अधिक देखना चाहेंगे क्योंकि परिदृश्य आकार लेते हैं?

हां

भाषा समर्थन

• क्या यह फायदेमंद होगा यदि हम एक माइग्रेशन टूल प्रदान करते हैं जो स्वचालित चरणों को 1-3 करता है?

एक अच्छा दस्तावेज़ीकरण (स्पष्ट चरणों वाला एक पृष्ठ) पर्याप्त होना चाहिए। यदि सब कुछ वीएस के भीतर से csproj को हाथ से संपादित किए बिना किया जा सकता है, तो मेरा सुझाव है कि केवल चरणों का वर्णन करने वाला एक दस्तावेज़ पृष्ठ जोड़ें।

यदि आप नए csproj प्रारूप में स्विच करने का निर्णय लेते हैं (और मुझे आशा है कि आप करेंगे), तो निश्चित रूप से एक माइग्रेशन टूल की आवश्यकता होगी, क्योंकि माइग्रेशन के लिए csproj फ़ाइल को संपादित करने की आवश्यकता होगी।

पैकेजिंग

MSIX सभी ऐप्स के लिए आधुनिक पैकेजिंग विधि है। Win32 में WinUI के लिए क्या हमें ClickOnce का समर्थन करना चाहिए? हमें किन अन्य पैकेजिंग विधियों के लिए समर्थन शामिल करना चाहिए? विशेष रूप से Win32 में WinUI के लिए

Clickonce और msix परिनियोजन के बीच अंतर की तुलना करें:

1. ऐप इंस्टालर सुविधा पुराने विंडोज़ संस्करणों पर समान अनुभव प्रदान नहीं करती है
2. MSIX को एक मान्य हस्ताक्षरित पैकेज (आंतरिक या सार्वजनिक) की आवश्यकता है। क्लिकऑन्स स्व-हस्ताक्षरित पैकेजों का समर्थन करता है।
3. पैकेज मॉडल की कुछ सीमाएँ हैं, जो ज्यादातर अलग-थलग वातावरण के कारण होती हैं (उदाहरण के लिए कोई स्थानीय ऐपडेटा एक्सेस नहीं, कोई एलिवेटेड ऑपरेशन नहीं)।

मेरे लिए सबसे कष्टप्रद समस्या 2 है। हमारे पास आम तौर पर एक बार क्लिक करने वाले ऐप्स होते हैं जो आंतरिक रूप से उन कंप्यूटरों के साथ तैनात होते हैं जो किसी डोमेन के साथ पंजीकृत नहीं होते हैं। तो इस तरह के ऐप्स के लिए हमें एक वैध सार्वजनिक हस्ताक्षर प्रमाणपत्र के साथ पैकेज पर हस्ताक्षर करने की आवश्यकता होगी।

इन दो ढांचे के बीच सभी अंतरों का अनुमान लगाना कठिन है, क्योंकि एपएक्स पैकेजिंग प्रारूप अक्सर केवल स्टोर को लक्षित करने वाले ऐप्स के लिए विज्ञापित किया जाता है, और जब हम सीमाएं देखते हैं, तो हम हमेशा नहीं जानते कि वे वेब वितरण प्रारूप पर भी लागू होते हैं या नहीं।

• डिजाइनर अनुभव

कई परियोजनाओं के साथ बड़े समाधानों के लिए प्रदर्शन, प्रदर्शन, प्रदर्शन और समर्थन।

क्या Windows 10 SDK के WinUI संस्करण और WinUI Xaml डिज़ाइनर को खुला स्रोत बनाया जाएगा?

क्या हम डिज़ाइन टाइम वर्कफ़्लो और अनुभव के लिए अनुरोध पोस्ट करने में सक्षम होंगे?

क्या एसडीके एक समान रिलीज ताल का पालन करेगा जैसे कि विनयूआई की नगेट रिलीज?

कुछ अतिरिक्त दर्द:
प्रबंधित-अप्रबंधित मिश्रण डीबग अनुभव में सुधार करें।
वर्तमान में जब अप्रबंधित कोड में अपवाद होता है, तो प्रबंधित डीबग साइट में COMException दिखाया जाता है। यदि कॉल स्टैक 1 से अधिक बार प्रबंधित/अप्रबंधित सीमा को पार करता है तो स्थिति और खराब हो सकती है।
डब्ल्यूपीएफ की तुलना में, प्रबंधित कॉल स्टैक हमेशा उपलब्ध होता है, और फेंके गए अपवाद में एक स्ट्रिंग होती है जो डीबग के लिए सहायक होती है।
मैं अप्रबंधित दुनिया को जानता हूं और COM मॉडल प्रबंधित के रूप में इतना सुविधाजनक नहीं है। लेकिन कम से कम, जब ढांचे द्वारा एक अपवाद (गलत HResult) फेंक दिया जाता है, तो मुझे खुले सोर्स किए गए रेपो से कोड की रेखा का पता लगाने के लिए आवश्यक जानकारी चाहिए। रास्ता मैनुअल हो सकता है, लेकिन नियतात्मक होना चाहिए।

हम क्लिकऑन पर बहुत अधिक भरोसा करते हैं, इसलिए अल्पावधि के लिए समर्थन करना अच्छा होगा। हम MSIX में माइग्रेट करने के इच्छुक होंगे, लेकिन समान सुविधाओं की पेशकश के बाद।

टेम्पलेट्स के लिए, यह अच्छा होगा कि एक नेविगेशन व्यू और नेविगेशन के लिए बॉयलरप्लेट यूआई और कोड प्रदान करे।

धन्यवाद

हम क्लिकऑन पर बहुत अधिक भरोसा करते हैं, इसलिए अल्पावधि के लिए समर्थन करना अच्छा होगा। हम MSIX में माइग्रेट करने के इच्छुक होंगे, लेकिन समान सुविधाओं की पेशकश के बाद।

टेम्पलेट्स के लिए, यह अच्छा होगा कि एक नेविगेशन व्यू और नेविगेशन के लिए बॉयलरप्लेट यूआई और कोड प्रदान करे।

धन्यवाद

सबसे आम ऐप "खोल" संरचना और पैटर्न - टेम्पलेट के रूप में उपलब्ध होना चाहिए ताकि डेवलपर्स जल्दी से उठ सकें और चल सकें। Microsoft के प्रथम पक्ष एप्लिकेशन इन लेआउट में अनुकरणीय होने चाहिए और व्यवहार, निरंतरता, और फ़्लुएंट डिज़ाइन और WinUI के लिए UI डिज़ाइन मानदंडों का पालन करने के मामले में सर्वोत्तम अभ्यास के रूप में कार्य करना चाहिए।

@shaggygi @mdtauk
"सबसे आम ऐप "शेल" संरचना और पैटर्स के लिए और "टेम्पलेट्स के लिए, यह अच्छा होगा कि एक नेविगेशन व्यू और नेविगेशन के लिए बॉयलरप्लेट यूआई और कोड प्रदान करे।" विंडोज टेम्प्लेट स्टूडियो है जिसे माइक्रोसॉफ्ट और समुदाय दोनों द्वारा बनाए रखा और विकसित किया गया है। इसका परिचय उद्धृत करने के लिए:

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

@ फ़ेलिक्स-देव अंततः यूडब्ल्यूपी के अतिरिक्त डब्ल्यूपीएफ टेम्पलेट्स होंगे?

@shaggygi आपके लिए कुछ अच्छी खबर हो सकती है! यह धागा देखें: हालांकि इस बिंदु पर कुछ भी गारंटी नहीं है, विशेष रूप से डब्ल्यूपीएफ परियोजनाओं के लिए टेम्पलेट प्रदान करने का विचार स्पष्ट रूप से खोजा जा रहा है। जैसा कि लिंक किए गए थ्रेड में उल्लेख किया गया है, बिल्ड 2019 में होस्ट किया गया "विंडोज टेम्प्लेट स्टूडियो - डब्ल्यूपीएफ संस्करण" नामक एक गैर-सार्वजनिक चुपके सत्र था।

हम सी ++/विनआरटी का उपयोग कर रहे हैं। हम इस समय xaml डिज़ाइनर या बाइंडिंग का उपयोग नहीं करते हैं। लेकिन हम रनटाइम पर नियंत्रण बनाएंगे और संभवतः उन्हें UWP xaml के माध्यम से स्टाइल करेंगे। हमें डॉकिंग/फ्लोटिंग विंडो आदि सहित xaml द्वीपों के साथ संवाद और मॉडललेस चाइल्ड विंडोज की भी आवश्यकता होगी।

मैंने अपने सी ++ ऐप के लिए एक्सएएमएल लिखने की कोशिश की है और लड़का दर्दनाक अनुभव था।

मुझे कई प्रोजेक्ट गुण जोड़ने पड़े हैं जो अनिर्दिष्ट हैं और कुछ अन्य हैक सब कुछ सही ढंग से उत्पन्न करने और इसे सही ढंग से पैकेज करने के लिए हैं।

उदाहरण के लिए:

• अपने एक्सएएमएल पृष्ठों को स्टोर करने के लिए एक प्रोजेक्ट बनाते समय, मुझे <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> और <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> जोड़ना पड़ा, दो प्रोजेक्ट गुण जो पूरी तरह से अनियंत्रित हैं और केवल नए टर्मिनल के स्रोत कोड का निरीक्षण करके पता लगाया गया है।
• मेरे पास एक गुप्त "नया दृश्य नहीं बना सका क्योंकि मुख्य विंडो अभी तक नहीं बनाई गई है" जब तक मैंने एक ऐप क्लास बनाया और उपयोग नहीं किया, जिसमें सामान्य पृष्ठ बनाने और गुणों में जाने के अलावा वीएस में कोई रास्ता नहीं है वीएस में एक्सएएमएल फ़ाइल और इसे एक एप्लिकेशन परिभाषा में बदलना, फिर एमआईडीएल, स्रोत कोड और एक्सएएमएल फ़ाइल को समायोजित करना।
• मैंने अपनी एप्लिकेशन क्लास बनाने के लिए Microsoft.Toolkit.Win32.UI.XamlApplication NuGet पैकेज जोड़ा और इसे तब तक लोड नहीं कर सका जब तक कि मैंने Microsoft.VCRTForwarders भी नहीं जोड़ा, फिर से टर्मिनल के स्रोत का निरीक्षण करते समय मुझे यह मिला, कहीं भी पैकेज के बारे में कोई संकेत नहीं है।
• जब तक मैंने .wapproj फ़ाइल में कुछ नहीं जोड़ा, तब तक पंचायती राज संस्थाओं का एक में विलय नहीं हो रहा था, इसलिए इसे मेरा XAML संसाधन नहीं मिला।
• XBF तब तक काम नहीं कर रहा था जब तक कि मैंने <DisableEmbeddedXbf>false</DisableEmbeddedXbf> नहीं जोड़ा जो आश्चर्यजनक रूप से एम्बेडेड XBF को सक्षम करने के बजाय अक्षम कर देता है। मेरे पास एकमात्र त्रुटि एक एक्सएएमएल पार्स त्रुटि थी जिसमें मुझे कुछ भी इंगित नहीं किया गया था कि एक्सबीएफ फाइलें काम नहीं कर रही थीं।
• मेरे ऐप मेनिफेस्ट में maxVersionTested को तब तक पूरी तरह से अनदेखा कर दिया गया जब तक कि मैंने इसे लोअरकेस में नहीं बदल दिया, भले ही निर्देश ऊंट केस संस्करण का उपयोग करने के लिए कहा गया हो: https://github.com/MicrosoftDocs/windows-uwp/issues/1781 # इश्यू

इसके अतिरिक्त, सी ++/विनआरटी भी गधे में दर्द हो रहा था:

• हर बार जब मैंने एक वृद्धिशील निर्माण चलाया, तो मेरे पास मेरी कस्टम कक्षाओं के लिए [msg]redefinition [context]: MyClass जो मुझे निर्माण से रोकता था और तब तक दूर नहीं जाता जब तक कि मैं एक साफ निर्माण नहीं चलाता जो सी ++/विनआरटी हेडर के कारण उम्र लेता है। वह मुद्दा किसी तरह जादुई रूप से बीच में ही चला गया।
• अब जब मैं क्लीन बिल्ड चलाता हूं तो मुझे लापता हेडर के बारे में एक त्रुटि मिलती है। बिल्ड बटन को दूसरी बार हिट करने से यह फिर से काम करने लगता है।
• C++/WinRT से खराब कोडजन के कारण मुझे अपनी खुद की AppT<> कक्षा लिखनी पड़ी। टर्मिनल ऐप और एक्सएएमएल द्वीप नमूना वही करते हैं, जैसे कि यह कुछ ऐसा था जिसे उपयोगकर्ताओं को रूट समस्या को ठीक करने के बजाय करने की आवश्यकता होगी।
• जब तक मैं क्लीन बिल्ड नहीं करता, तब तक MIDL फ़ाइलों में कुछ भी बदलने से बिल्ड त्रुटियाँ होती हैं।

फिर भी, यह मेरे ऐप मेनिफेस्ट में activatableClass सामान जोड़ने पर भी अनपैक्ड काम नहीं करता है (कुछ ऐसा जो XAML संसाधन को खोजने में सक्षम नहीं होने के बारे में है, जैसे कि जब मैंने PRI को मर्ज नहीं किया था), जो महत्वपूर्ण है मेरे ऐप का समर्थन करने के लिए।

प्रवास

चरण 1-3 के लिए स्वचालन निश्चित रूप से सहायक है क्योंकि सैकड़ों फाइलों पर नाम स्थान का नाम बदलने में बहुत समय लगता है और त्रुटियों की संभावना होती है। उसके ऊपर एक कॉम्पेट एनालाइज़र .net Framework > .net core की तरह ही अच्छा होगा जो एक रिपोर्ट तैयार करता है कि वर्तमान कोडबेस कितना अनुकूल है और आवश्यक सभी संभावित परिवर्तनों को नोट करता है।

टूलींग

जैसा कि अन्य पहले ही कह चुके हैं कि एक अधिक सुविधा संपन्न संपादक अच्छा होगा। काम पर ज्यादातर समय एक्सएएमएल हाथ से किया जाता है और ज्यादातर डिजाइनर का उपयोग किसी न किसी कंकाल पर एक गाइड के रूप में करते हैं कि ऐप कैसा दिखता है। इंटेलिजेंस और स्मार्ट रिफैक्टरिंग वास्तव में मददगार होंगे, क्यूओएल चीजें जैसे CTRL + R + R का नाम बदलने के लिए (उदाहरण के लिए निर्भरता गुण या यहां तक ​​​​कि टैग) उदाहरण के लिए विशेष रूप से जब आपके पास बहुत सारे कस्टम UserControls और यह भी गोटो कार्यान्वयन और संदर्भ। रोसलिन विश्लेषक का समर्थन भी वास्तव में अच्छा होगा।

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

अधिकतर टूलिंग पर यह अच्छा होगा यदि यह सी # संपादक की तरह व्यवहार करता है ताकि रिफैक्टरिंग कम नाजुक या परेशानी हो और मार्कअप को आसान बना सके। इसके अलावा एक्सएएमएल भाषा के लिए ही वर्बोसिटी को कम करना एक अच्छा उदाहरण होगा स्टाइलिंग जैसा कि # 62 और # 279 पर चर्चा की गई है।

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

मैं यह सोचना चाहूंगा कि पृष्ठ नियंत्रण का WinUI 3.0 संस्करण उन नियंत्रणों के लिए उपसर्ग का उपयोग करने की आवश्यकता को समाप्त कर देगा। मुझे लगता है कि यह एक एसडीके स्तर की बात होगी।

क्या WinUI का उपयोग करते समय नेमस्पेस को बदलना संभव नहीं है?

एक फिक्स यह होना चाहिए, कि आप Windows.UI.Xaml.* WinMD संदर्भों को बिल्ड से बाहर कर सकते हैं। अब निर्माण लक्ष्य केवल एकीकृत WinMD उर्फ ​​का संदर्भ देता है। Windows.winmd , अलग-अलग WinMDs को भी संदर्भित करने के लिए लक्ष्य में एक विकल्प जोड़ें, इस तरह, हम अपने द्वारा बनाए जा रहे ऐप के आधार पर संदर्भों को शामिल या बहिष्कृत कर सकते हैं।

क्या यह तरीका है, तो नामस्थान बदलने की कोई आवश्यकता नहीं है, क्योंकि यह .NET dll तरह व्यवहार करता है, यह सिस्टम द्वारा आपूर्ति किए गए लोगों के बजाय पैकेज के अंदर एक स्थानीय संस्करण में असेंबली रीडायरेक्ट के साथ काम कर सकता है।

मुझे पता है कि विधि विशेष रूप से .NET फ्रेमवर्क के लिए है, लेकिन यूएपी के लिए, इस तरह के परिदृश्यों के लिए समाधान होना चाहिए। मुझे पता है कि msix/appx मेनिफेस्ट पर फ्रेमवर्क निर्भरता है। हो सकता है हम उस का उपयोग के साथ नए WinUI आपूर्ति करने के लिए कर सकते हैं Windows.* बजाय नामस्थान Microsoft.* वाले।

देव पक्ष पर, हमें अपने ऐप्स को अपग्रेड करने में कम दर्द होगा, क्योंकि हम केवल संदर्भ बदल रहे हैं, कोड नहीं!

मैं नामस्थान बिल्कुल नहीं बदलना पसंद करूंगा!

लाभ:

1. कोड को आगे और पीछे बदलने की जरूरत नहीं है।

2. एक बार स्थानीय WinUI कोड स्थिर हो जाने के बाद, आप विंडोज़ प्लेटफ़ॉर्म में वापस विलय कर सकते हैं, ताकि सिस्टम ऐप्स और LOB ऐप्स प्रत्येक नए विंडोज़ रिलीज़ पर नए सुधारों का लाभ उठा सकें।

3. एक तरफ यह .NET फ्रेमवर्क जैसी उच्च संगतता के साथ एक अत्यधिक स्थिर सिस्टम फ्रेमवर्क है। और दूसरी तरफ यह .NET कोर की तरह है, तेज गति से परिवर्तन के साथ, दोनों के सभी लाभों के साथ और कोई भी समस्या नहीं है।

मुझे नहीं लगता कि पोर्टिंग टूल प्रदान करना आवश्यक था। यह एक बार का परिवर्तन है, ढूँढें और बदलें के साथ काफी आसान है, और उदाहरणों की संख्या काफी कम होने वाली है।

और भी समस्याओं का सामना करना पड़ा:

• App वर्ग में संसाधन जोड़ने के बाद, मेरा एक्सएएमएल इसे तब तक नहीं ढूंढ सका जब तक कि मैंने इसे नहीं जोड़ा, फिर से टर्मिनल ऐप से मिला और यह वास्तव में क्या करता है इसके बारे में ज्यादा जानकारी नहीं है:
  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 जैसी त्रुटि के साथ टूट जाएगा और प्रोजेक्ट बिल्डिंग को फिर से प्राप्त करने का एकमात्र तरीका एक साफ निर्माण करना है
• मैं स्टार्टअप प्रोजेक्ट के रूप में मुख्य exe के लिए सीधे vcxproj सेट करके ऐप नहीं चला सकता, मुझे मैन्युअल रूप से अनपैक्ड एपेक्स आउटपुट bin\x64\Debug\AppX और फिर वीएस के भीतर से डीबगर इंजेक्ट करना होगा, या ऐप पैकेज सेट करना होगा स्टार्टअप प्रक्रिया के रूप में।

विंडोज डेस्कटॉप पर संबंधित सामग्री

कुछ यूडब्ल्यूपी अनुभव के साथ यहां लंबे समय तक विनफॉर्म, डब्ल्यूपीएफ डेवलपर। यहाँ मेरे 2 सेंट हैं:

प्रवास

• मौजूदा UWP ऐप्स को WinUI में माइग्रेट करने के लिए एक टूल आवश्यक है।
• किसी मौजूदा ऐप में WinForms या wpf नियंत्रणों को WinUI नियंत्रणों में कनवर्ट करने का एक टूल कमाल से परे होगा। नियंत्रणों को परिवर्तित करके, मेरा मतलब कंटेनर में संदर्भों को अलग-अलग नियंत्रणों में बदलना है।
• विंडोज़ में मोबाइल ऐप को बैक-पोर्ट करने की अनुमति देने के लिए एक्समरीन फॉर्म को विनयूआई में माइग्रेट करने का एक टूल।

टूलींग

• वर्तमान XAML संपादक भयानक है! इसे सामान्य टेक्स्ट एडिटर कैनवास का उपयोग करने की आवश्यकता है और बेहतर इंटेलिजेंस और रिफैक्टरिंग के लिए एक्सएएमएल ऑब्जेक्ट मॉडल पर रोसलिन सुविधाओं को लागू करने की आवश्यकता है।
• विजुअल स्टूडियो के 64 बिट होने तक, XAML संपादक को पर्दे के पीछे एक स्टैंड-अलोन 64-बिट ऐप होना चाहिए। बहुत सारे एक्सएएमएल के साथ काम करते समय आउट-ऑफ-मेमोरी त्रुटि को रोकने के लिए मुझे लगातार वीएस 2017 और वीएस 201 9 को पुनरारंभ करना पड़ रहा है।

टेम्पलेट्स

• हमें इन प्रोजेक्ट टेम्प्लेट की आवश्यकता है

  • नेविगेशन व्यू विनयूआई
  • नेविगेशन व्यू डब्ल्यूपीएफ
  • रिबन विनयूआई
  • रिबन डब्ल्यूपीएफ
  • रिबन विनफॉर्म

• हमें इन पेज/विंडो टेम्पलेट्स की आवश्यकता है

  • मीडिया नियंत्रक पृष्ठ
  • ब्राउज़र पेज
  • डायलॉग विंडो
  • सीमा रहित खिड़की
  • फ्लोटिंग विंडो

• हमें नियंत्रण टेम्पलेट्स की आवश्यकता है

  • इनकैप्सुलेटेड डेटा ग्रिड व्यू
  • इनकैप्सुलेटेड चाइल्ड डेटा व्यू

ये अंतिम दो आसान मास्टर-विवरण विंडो बनाने के लिए मिलकर काम करेंगे।

ये सभी टेम्प्लेट और पेज आदि पहले से ही विंडोज टेम्प्लेट स्टूडियो प्रोजेक्ट में किए जा रहे हैं, क्यों न इन सभी को फिर से बनाने के बजाय उसी रूट का अनुसरण किया जाए?

एसडीके स्टाइल प्रोजेक्ट फाइल
सबसे महत्वपूर्ण बिट में से एक जिसे मैं देखना चाहता हूं - जैसा कि कई अन्य ने भी उल्लेख किया है - यूडब्ल्यूपी और "डेस्कटॉप एक्सएएमएल" ऐप्स दोनों के लिए नए एसडीके स्टाइल प्रोजेक्ट फ़ाइल प्रारूप का समर्थन है।

UWP और डेस्कटॉप XAML ऐप मॉडल के बीच माइग्रेशन
यदि हम "डेस्कटॉप एक्सएएमएल" ऐप बनाना शुरू करते हैं, तो यह यूडब्ल्यूपी ऐप से कितनी दूर होगा? क्या बाद में इसे UWP ऐप में बदलना मामूली होगा यदि हमें पता चलता है कि हम UWP सैंडबॉक्स की बाधाओं के भीतर रहे हैं? या अगर हमने एक यूडब्ल्यूपी ऐप बनाना शुरू किया और महसूस किया कि हमें और चाहिए, तो क्या इसे "डेस्कटॉप एक्सएएमएल" ऐप में बदलना आसान होगा?

मैं टेम्प्लेट स्टूडियो समर्थन के साथ हूं।

मैं टेम्प्लेट स्टूडियो समर्थन के साथ हूं।

क्या टेम्प्लेट स्टूडियो XAML C++ प्रोजेक्ट्स का समर्थन करता है?

टेम्प्लेट स्टूडियो जो कर रहा है, उसे WinUI SDK IMO का हिस्सा होना चाहिए

टेम्प्लेट स्टूडियो जो कर रहा है, उसे WinUI SDK IMO का हिस्सा होना चाहिए

विजुअल स्टूडियो आईडीई आईएमओ का हिस्सा होना चाहिए! मैं

दोस्तों बात यह है कि विंडोज़ टेम्पलेट स्टूडियो यूडब्ल्यूपी प्रोजेक्ट निर्माण के लिए एक सामान में सब कुछ कर रहा है, इसलिए इसे ध्यान में रखते हुए कि अगर xaml c ++ समर्थन की तरह कुछ गुम है, तो हमें इसे विंडोज़ टेम्पलेट स्टूडियो में जोड़ने पर विचार करना चाहिए, मुझे लगता है कि यह तेज़ और अधिक होगा कुशल यदि यूडब्ल्यूपी परियोजनाओं में सभी नए नवाचार एक परियोजना में रहते हैं।

XAML या यहां तक ​​कि MVVM के बिना सीधे WinUI 3 के स्टैक की निचली परत का उपयोग करने के लिए कुछ विधि होने दें। यह मौजूदा बड़े-लौह सी ++ सॉफ़्टवेयर के लिए विशेष रूप से उपयोगी है, जिनके पास पहले से ही किसी प्रकार का एमवी है-उनके कोडबेस में जो भी आर्किटेक्चर है। वे सिर्फ HWND + GDI से बेहतर कुछ चाहते हैं।

और, कृपया लोगों को यह सोचें कि WinUI 3 कोई खिलौना नहीं है, यह वास्तव में गंभीर सॉफ़्टवेयर का समर्थन कर सकता है ।

@be5invis मैं पूरी तरह सहमत हूं। अभी एकमात्र समाधान XamlDirect है, लेकिन यह मिडलवेयर डेवलपर्स पर अधिक लक्षित है।

आप पहले से ही Xaml द्वीप समूह के साथ मैन्युअल रूप से सामग्री बना सकते हैं। बस एक DesktopWindowXamlSource काम कर रहा है और एक विंडो से जुड़ा हुआ है, फिर कोड में नियंत्रण/लेआउट नियंत्रण बनाएं और व्यवस्थित करें।

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

@MarkIngramUK उन्हें कुछ और "पूर्ण" की आवश्यकता हो सकती है, जैसे CreateWindow को WinUI फ़ंक्शंस से बदलना।

डिजाइन के लिए, मैं वास्तव में भविष्य के विनयूआई डब्ल्यूपीएफ टेम्पलेट्स को मौजूदा यूडब्ल्यूपी ऐप्स की तरह टाइटलबार में पेज की सामग्री को विस्तारित करने के लिए समर्थन प्राप्त करना चाहता हूं। अभी, मौजूदा एक्सएएमएल द्वीप समाधान के साथ, हम आधुनिक दृश्य के बजाय केवल एक wpf/WinForms विंडो के अंदर नियंत्रण होस्ट कर रहे हैं।

@LucasHaines उन भाषाओं की सूची जिन्हें हम WinUI 3.0 के साथ समर्थन देने की योजना बना रहे हैं: C#, C++/WinRT, Visual Basic। हम F# का समर्थन तलाश रहे हैं।

यह दिखाता है कि आप इसे गलत कर रहे हैं, न केवल F# के लिए बल्कि सभी .Net भाषाओं के लिए। आप टेम्प्लेट और .xaml फ़ाइलों के बारे में सोचकर शुरुआत कर रहे हैं, जो एक घर बनाने और संरचना को समाप्त किए बिना कालीन और पर्दे लगाने जैसा है।

आपको किसी भी .Net Standard 2.0/.Net Core 3.0/.Net 5 प्रोजेक्ट में WinUI को Nuget पैकेज के रूप में स्थापित करने में सक्षम होना चाहिए। फिर आपके पास अंदर परिभाषित सभी वर्गों तक पहुंच है। फिर आप ऐसी परियोजनाओं को WinUI प्रोजेक्ट से संदर्भित कर सकते हैं (जो सी #-केवल हो सकता है)। यह किसी भी .Net भाषा में WinUI दृश्य बनाने की अनुमति देता है। देखें कि कैसे Xamarin.Forms करता है ।

कक्षाएं एफ # में उपयोग के लिए पहले से ही उपलब्ध हैं (चूंकि वे विंडोज रनटाइम घटक हैं, जो सभी .NET भाषाओं द्वारा प्रयोग योग्य हैं)

आप मैन्युअल रूप से एक लेआउट बनाने में सक्षम होंगे। आप इसे सभी WinUI देखभाल के लिए Py/WinRT का उपयोग करके Python के माध्यम से भी कर सकते हैं।

@sylveon विशेष रूप से कौन सी कक्षाएं? मुझे दिलचस्पी होगी ...

उन सभी को। WinUI का सार्वजनिक API केवल Windows रनटाइम घटक है।

@LucasHaines उन भाषाओं की सूची जिन्हें हम WinUI 3.0 के साथ समर्थन देने की योजना बना रहे हैं: C#, C++/WinRT, Visual Basic। हम F# का समर्थन तलाश रहे हैं।

यह दिखाता है कि आप इसे गलत कर रहे हैं, न केवल F# के लिए बल्कि सभी .Net भाषाओं के लिए। आप टेम्प्लेट और .xaml फ़ाइलों के बारे में सोचकर शुरुआत कर रहे हैं, जो एक घर बनाने और संरचना को समाप्त किए बिना कालीन और पर्दे लगाने जैसा है।

आपको किसी भी .Net Standard 2.0/.Net Core 3.0/.Net 5 प्रोजेक्ट में WinUI को Nuget पैकेज के रूप में स्थापित करने में सक्षम होना चाहिए। फिर आपके पास अंदर परिभाषित सभी वर्गों तक पहुंच है। फिर आप ऐसी परियोजनाओं को WinUI प्रोजेक्ट से संदर्भित कर सकते हैं (जो सी #-केवल हो सकता है)। यह किसी भी .Net भाषा में WinUI दृश्य बनाने की अनुमति देता है। देखें कि कैसे Xamarin.Forms करता है ।

यह विषय/प्रश्न टूलिंग के बारे में है। हां, पुस्तकालयों को सीधे किसी भी भाषा से संदर्भित किया जा सकता है जो उन्हें उपभोग करने में सक्षम है लेकिन टूलिंग और भाषा समर्थन के बीच परिभाषाओं का धुंधलापन है।
Xamarin.Forms को अपने उदाहरण के रूप में लेना। यह केवल सी # और कुछ हद तक एफ # के लिए टूलिंग प्रदान करता है। VB.Net और Xamarin.Forms के साथ ऐप्स बनाना संभव है, लेकिन यह _आधिकारिक रूप से समर्थित नहीं है क्योंकि ऐसा करने के लिए कोई उपकरण नहीं हैं और केवल सीमित दस्तावेज़ हैं।

साथ ही, चूंकि WinUI विंडोज़ विशिष्ट है, इसलिए इसे किसी भी .Net Standard 2.0/.Net Core 3.0/.Net 5 प्रोजेक्ट में संदर्भित नहीं किया जा सकता है।
कुछ परिदृश्यों के लिए प्रोजेक्ट/कंपाइलर/पैकेजिंग स्तर के समर्थन की भी आवश्यकता है।

v2.2 रिलीज पर शानदार काम करने वाली टीम। किसी भी मौके पर हम v3.0 स्थिति पर एक संक्षिप्त अपडेट प्राप्त कर सकते हैं?

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

कृपया XAML से xmlns:mux="using:Microsoft.UI.Xaml.Controls" की आवश्यकता को हटा दें। मैं समझता हूं कि पीछे के कोड को अभी भी बदलने की जरूरत है। इसके लिए परियोजना में किसी स्थान पर एक विन्यास भी हो सकता है।

कृपया XAML से xmlns:mux="using:Microsoft.UI.Xaml.Controls" की आवश्यकता को हटा दें।

XAML _markup_ में इसकी आवश्यकता नहीं होगी, लेकिन कोड-बैक में नामस्थान बदलना अभी भी आवश्यक होगा।

यदि आप विंडोज नियंत्रणों का उपयोग करना चाहते हैं (यदि उन्हें ओएस से नहीं हटाया जाता है) - आपको एक्सएएमएल में नेमस्पेस घोषित करना होगा

यदि आप विंडोज नियंत्रणों का उपयोग करना चाहते हैं (यदि उन्हें ओएस से नहीं हटाया जाता है) - आपको एक्सएएमएल में नेमस्पेस घोषित करना होगा

WinUI 3.0 के साथ जो एक परिदृश्य नहीं है -- आप WinUI 3.0 नियंत्रणों के साथ OS नियंत्रणों को मिश्रित और मिलान नहीं कर सकते हैं। यह अभी केवल WinUI 2.x के साथ काम करता है क्योंकि वे नियंत्रण OS के लिए ऐड-ऑन हैं (और हमारे पास बहुत सारे अजीब मामले हैं जहां हमने नेविगेशन व्यू और ट्री व्यू जैसे अस्पष्टता के कारण दोनों जगहों पर टाइप भेज दिया है)।

यदि आप विंडोज नियंत्रणों का उपयोग करना चाहते हैं (यदि उन्हें ओएस से नहीं हटाया जाता है) - आपको एक्सएएमएल में नेमस्पेस घोषित करना होगा

WinUI 3.0 के साथ जो एक परिदृश्य नहीं है -- आप WinUI 3.0 नियंत्रणों के साथ OS नियंत्रणों को मिश्रित और मिलान नहीं कर सकते हैं। यह अभी केवल WinUI 2.x के साथ काम करता है क्योंकि वे नियंत्रण OS के लिए ऐड-ऑन हैं (और हमारे पास बहुत सारे अजीब मामले हैं जहां हमने नेविगेशन व्यू और ट्री व्यू जैसे अस्पष्टता के कारण दोनों जगहों पर टाइप भेज दिया है)।

सुन कर अच्छा लगा। ओएस से इसे हटाना आसान बना देगा। मुझे उम्मीद है कि सेटिंग्स ऐप, शेल और ओएस के अन्य हिस्से भी WinUI 3.0 में चले जाएंगे।

और एक्सएएमएल पर एडमिनिस्ट्रेटर टूल्स, वर्डपैड, आदि के पोर्ट्स के लिए जितना संभव हो उतना ही कोड का पुन: उपयोग करने की उम्मीद करता है!

@jevansaks ठीक है, समझा, प्रतिक्रिया के लिए धन्यवाद!

@mdtauk एक्सएएमएल में 'ओएस' विरासत नियंत्रण और नए 'विनयूआई 3.0' प्लेटफॉर्म नियंत्रण के बीच अंतर करने की कोई आवश्यकता नहीं होगी। सब कुछ WinUI 3.0 की ओर बढ़ रहा है और जैसा कि आप जानते हैं, OS नियंत्रणों को और अधिक फीचर अपडेट नहीं मिल रहे हैं। WinUI 3.0 के बाद यदि कोई डेवलपर अभी भी पुराने नियंत्रणों को लक्षित करना चाहता है तो उन्हें पुराने SDK और Visual Studio संस्करणों के साथ विकसित करना चाहिए। XAML से दो Microsoft/Windows UI नियंत्रण पुस्तकालयों को संदर्भित करने की क्षमता बनाए रखना पहले बताए गए कारणों के लिए एक बाधा होगी। इसके अलावा, WinUI के डिकॉउलिंग के साथ विकास अंतत: इस तरह के परिवर्तनों को 'अनुमति' देने के एक स्थायी पथ पर स्विच कर सकता है - जो एक ब्रेकिंग भी नहीं है।

संपादित करें: उत्तर देने से पहले ताज़ा करना भूल गए, इसमें से अधिकांश अब बेमानी है।

@robloo मुझे खुशी है कि यह वास्तव में UWP Xaml के पिछले संस्करणों को बदल देगा। मुझे यह भी उम्मीद है कि ओएस इनबॉक्स ऐप्स और शेल के लिए इसमें स्थानांतरित हो सकता है।

मुझे यह भी उम्मीद है कि बहुत सारे डेवलपर वीडियो होंगे जो WinUI 3.0 पर जाने की प्रक्रिया का विवरण देंगे - और Win32 ऐप्स के समान जीवनचक्र के साथ WinUI 3.0 के साथ कैसे काम करें। कोई और अधिक पुनर्जलीकरण नहीं, पृष्ठ स्थिति और नेविगेशन को बचाने के बेहतर तरीके, आदि।

यह मददगार हो सकता है (इस पर निर्भर करता है कि कौन से ऐप्स WinUI 3.0 पर जाने की योजना बना रहे हैं) वर्डपैड लेने और कोड को WinUI में निर्मित एक नए UI पर ले जाने के उदाहरण प्रदान करने के लिए - साथ ही साथ Groove Music जैसे इनबॉक्स ऐप लेना, और उस पर आगे बढ़ना विनयूआई 3.0

WinUI 3 के लिए, डिज़ाइन भाषा में ऐप फ़ंक्शंस की नियुक्ति के संबंध में कुछ स्थिरता होनी चाहिए।

इस संबंध में, ऐप सेटिंग्स।

मुझे ऐप सेटिंग कहां मिलेगी? क्या मैं ऊपरी दाएं कोने में स्थित गियर पर क्लिक करता हूं? निचला बायां किनारा? क्या मैं ऊपरी दाएं और हिट सेटिंग में प्रोफ़ाइल अवतार पर क्लिक करता हूं? क्या मैं ऊपर बाईं ओर क्लिक करूं? तली छोड़ें? क्या मैं संपादन > वरीयताएँ पर जाता हूँ?

वास्तव में इस पर निर्भर करता है कि क्या आप नेविगेशन व्यू का उपयोग करते हैं ...

से: शहीद मलिक सूचनाएं @github.com
भेजा गया: गुरुवार, सितंबर 12, 2019 3:48:12 अपराह्न
प्रति: Microsoft/Microsoft-ui-xaml [email protected]
सीसी: द शार्प निंजा [email protected] ; टिप्पणी टिप्पणी @noreply.github.com
विषय: पुन: [माइक्रोसॉफ्ट/माइक्रोसॉफ्ट-यूआई-एक्सएएमएल] विनयूआई 3.0 डेवलपर अनुभव और टूलिंग - इनपुट की आवश्यकता (#1045)

WinUI 3 के लिए, डिज़ाइन भाषा में ऐप फ़ंक्शंस की नियुक्ति के संबंध में कुछ स्थिरता होनी चाहिए।

इस संबंध में, ऐप सेटिंग्स।

मुझे ऐप सेटिंग कहां मिलेगी? क्या मैं ऊपरी दाएं कोने में स्थित गियर पर क्लिक करता हूं? निचला बायां किनारा? क्या मैं ऊपरी दाएं और हिट सेटिंग में प्रोफ़ाइल अवतार पर क्लिक करता हूं? क्या मैं ऊपर बाईं ओर क्लिक करूं? तली छोड़ें? क्या मैं संपादन > वरीयताएँ पर जाता हूँ?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
सीधे इस ईमेल का जवाब है, यह GitHub पर देखने https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , या धागे मूक https: // GitHub। कॉम/नोटिफिकेशन/अनसब्सक्राइब-ऑथ/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ ।

विजुअल स्टूडियो में टेम्प्लेट और घटकों के संबंध में हम आपको अधिक कुशल या सफल होने में कैसे मदद कर सकते हैं?

विजुअल स्टूडियो में WinUI/XAML द्वीप समूह को C++/WinRT के साथ काम करने के लिए महत्वपूर्ण प्रयास और अनियंत्रित परियोजना कॉन्फ़िगरेशन विशेषताओं को नहीं लेना चाहिए।

इस पर पर्याप्त जोर नहीं दिया जा सकता है, लेकिन मेरे लिए सबसे महत्वपूर्ण बात यह है कि WinUI केवल विंडोज़ से अधिक को प्रस्तुत करता है।

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

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

प्रत्येक प्लेटफ़ॉर्म उर्फ ​​"मूल रूप और अनुभव" पर अलग-अलग प्रस्तुत करता है।

मुझे यह नहीं मिला। कृपया न करें, आखिरी चीज जो मैं चाहता हूं कि फ्लुएंट डिज़ाइन करें, अधिक असंगति कम नहीं कर रही है।

संपादित करें: मूल टिप्पणी हटा दी गई

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

यही कारण है कि मैं निराश था कि डुओ एंड्रॉइड था।

उनमें उत्पन्न होने वाली किसी भी समस्या को दूर करने के लिए टेम्पलेट्स को खुला स्रोत होना चाहिए।

जब मैं डब्ल्यूपीएफ के साथ विनयूआई का उपयोग करूंगा, और जब मैं कोड के साथ नया नियंत्रण बनाउंगा जैसे:
c# public class MyControl : UserControl { ... }
यह WinUI.UserControl या WPF.UserControl का उपयोग करेगा?
क्या हमें चुनने की आवश्यकता होगी और इससे कैसे निपटना है?

और दिलचस्प है, अगर एक्सएएमएल टूलिंग एकीकृत होने जा रही है, तो क्या हमारे पास किसी प्रकार की साझा एक्सएमएल फाइल बनाने की क्षमता होगी?
कुछ इस तरह:

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

क्या यह विशेष रूट नेमस्पेस के साथ किसी प्रकार की साझा बोली होनी चाहिए? (विजुअल स्टूडियो में साझा परियोजनाओं की तरह)। यह सशर्त xaml जैसा दिख सकता है।

यह WinUI.UserControl या WPF.UserControl का उपयोग करेगा?
क्या हमें चुनने की आवश्यकता होगी और इससे कैसे निपटना है?

यह एक्सएएमएल में स्वचालित रूप से होना चाहिए जहां आप परिभाषित करते हैं

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

यह संकलक को बताता है कि यह यूडब्ल्यूपी है।

public class MyControl : UserControl { ... }

यह वास्तव में गलत है। आपको इस तरह घोषित करना चाहिए

public partial class MyControl { }

कोई विरासत आवश्यक नहीं है क्योंकि इसे .g.cs फ़ाइल द्वारा नियंत्रित किया जाता है जो विरासत और उपयोग किए जा रहे ढांचे को निर्दिष्ट करता है।

टेम्प्लेट के बारे में, मुझे अधिक खुशी होगी यदि हैलो वर्ल्ड टेम्प्लेट से अधिक हो। मेरा मतलब यह है कि माइक्रोसॉफ्ट को क्लाइंट ऐप्स के साथ काम करने के लिए आवश्यक कुछ परिधीय मान्यता प्राप्त ढांचे का बैक अप लेना चाहिए

@weitzhandler मुझे यह भी देखना अच्छा लगेगा !!

सी # और सीपीपी/विनआरटी परियोजनाओं के लिए एसडीके शैली परियोजनाएं भी होनी चाहिए

मुझे लगता है कि सभी सामान्य Win32 और इनबॉक्स ऐप पैटर्न के लिए टेम्पलेट्स होने चाहिए। मेरे सिर के ऊपर से एक छोटी सूची:

• फीता
• मुख्य मेनू
• टैब्ड दस्तावेज़ इंटरफ़ेस
• नेविगेशन दृश्य
• कमांड/टूलबार
• शीर्ष नेविगेशन दृश्य
• हब/गैलरी (मुझे पता है कि यह थोड़ा बहिष्कृत है)
• ट्रीव्यू/मास्टर विवरण (फ़ाइल एक्सप्लोरर, RegEdit, व्यवस्थापन ऐप)

लेकिन सामान्य संवाद, पेज, सेटिंग पेज आदि के लिए आइटम टेम्प्लेट भी होने चाहिए।

विजुअल स्टूडियो में टेम्प्लेट और घटकों के संबंध में हम आपको अधिक कुशल या सफल होने में कैसे मदद कर सकते हैं?

VSCode/Visual Studio के लिए C++ एक्सटेंशन के साथ काम करें। मैं वीएस कोड को एक समर्थित संपादक के रूप में भी देखना चाहता हूं जो विजुअल स्टूडियो के समान अनुभव प्रदान करता है। विनयूआई को ओएसएस माना जाता है और वीएस कोड भी है, इसलिए मुझे लगता है कि यह करने योग्य है।

टेम्प्लेट 10 और विंडोज टेम्प्लेट स्टूडियो जैसे उपकरण बुनियादी कार्यक्षमता की कमी के संकेत हैं। WinUI3 के साथ इन उपकरणों के लिए कार्यक्षमता होनी चाहिए। मैं शर्त लगा रहा हूं कि बहुत से डेवलपर इस बुनियादी मचान को बार-बार कर रहे हैं ... यह ढांचे का हिस्सा होना चाहिए। कोई अतिरिक्त उपकरण की आवश्यकता नहीं होनी चाहिए। हो सकता है कि आपको उन दुर्लभ मामलों के लिए एमवीवीएम मचान बंद करना पड़े, जब आप बिना रहना चाहेंगे।

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

मुझे नहीं लगता कि टेम्प्लेट सिस्टम की उपस्थिति बुनियादी कार्यक्षमता की कमी को दर्शाती है, मुझे लगता है कि यह उन सहायक समुदायों की गुणवत्ता पर प्रकाश डालता है जो इन टेम्प्लेट सिस्टम को एक साथ रखेंगे।

टेम्प्लेट 10 और विंडोज टेम्प्लेट स्टूडियो जैसे उपकरण बुनियादी कार्यक्षमता की कमी के संकेत हैं।

मैं इस तरह की चीजों को बुनियादी कार्यक्षमता के विस्तार के रूप में देखता हूं। बेशक, इस तरह की चीजें घर में लाई जा सकती हैं लेकिन कोर टीम के लिए इसे बनाए रखना और समर्थन करना अधिक है। जैसा कि कोर टीम अधिक करती है, इसका मतलब यह होता है कि वे अधिक पतले होते हैं और इसलिए हर चीज में अधिक समय लगता है। अगर एमएसएफटी को लगता है कि इस तरह की चीजों को मुख्य टीम में लाने के लिए उनके पास बजट है तो मुझे इसके बारे में किसी के साथ बात करना अच्छा लगेगा;)

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

@AntiPasha क्या आपने लाइटवेट स्टाइल के बारे में सुना है? इसके साथ आप पूरी शैली को फिर से बनाए बिना आसानी से होवर रंग बदल सकते हैं:

एक बटन के लिए होवर रंग बदलना तो बस होगा:

            <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>

17763 एसडीके में एक Control.CornerRadius संपत्ति भी जोड़ी गई थी और WinUI टीम नियंत्रणों को बहाल किए बिना आसानी से ऐप या पेज-वाइड अनुकूलन जोड़ने के लिए अत्यधिक संसाधनों को भी पेश कर रही है: https://github.com/microsoft/microsoft-ui- xaml-specs/blob/user/chigy/roundedcorner/active/RoundedCorner/roundedcorner.md#customization -options

और दिलचस्प है, अगर एक्सएएमएल टूलिंग एकीकृत होने जा रही है, तो क्या हमारे पास किसी प्रकार की साझा एक्सएमएल फाइल बनाने की क्षमता होगी?
कुछ इस तरह:

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

क्या यह विशेष रूट नेमस्पेस के साथ किसी प्रकार की साझा बोली होनी चाहिए? (विजुअल स्टूडियो में साझा परियोजनाओं की तरह)। यह सशर्त xaml जैसा दिख सकता है।

@Tirraon यह वास्तव में एक दिलचस्प उदाहरण है, लेकिन मुझे लगता है कि जब हम टूलिंग को एकीकृत करने के बारे में बात करते हैं, तो मानसिकता में शुरू करना बेहतर होता है कि प्लेटफॉर्म आज भी मौजूद हैं, और हम एक और Xaml मानक बनाने की कोशिश नहीं कर रहे हैं समकक्ष।

हम डिफ़ॉल्ट नाम स्थान का उपयोग यह अंतर करने के लिए कर सकते हैं कि xaml फ़ाइल किस "शीर्ष-स्तरीय" प्लेटफ़ॉर्म से संबंधित है, इसलिए उदाहरण के लिए, हमारे पास प्रत्येक XAML प्लेटफ़ॉर्म के लिए निम्नलिखित डिफ़ॉल्ट नामस्थान हो सकते हैं (ये ज्यादातर काल्पनिक हैं, इसलिए उन्हें नमक के दाने के साथ लें ):

डब्ल्यूपीएफ: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
यूडब्ल्यूपी: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
अवलोनिया: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
यूनो: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

तो Xaml द्वीप समूह का उपयोग करके wpf के साथ WinUI को इंटरमिक्स करने के लिए, आपके पास मार्कअप है जो इस तरह दिखता है:

<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>

तुम क्या सोचते हो?

@ स्टीवनब्रिक्स
यूडब्ल्यूपी के लिए आपके उदाहरण में यह दोनों बटन प्रस्तुत करेगा, है ना?
मेरा मतलब है, मामले के लिए, जब xmlns=".../xaml/प्रस्तुति" शीर्ष स्तर का नाम स्थान है और UserControl wutg StackPanel दोनों uwp और wpf में उपलब्ध हैं, तो क्या दूसरा बटन दोनों प्लेटफार्मों में भी उपलब्ध नहीं होगा?

जब हम टूलिंग को एकीकृत करने के बारे में बात करते हैं, तो इस मानसिकता में शुरुआत करना बेहतर होता है कि प्लेटफ़ॉर्म मौजूद रहेंगे जैसे वे आज करते हैं

हाँ, मैं इससे पूरी तरह सहमत हूँ।

यूडब्ल्यूपी के लिए आपके उदाहरण में यह दोनों बटन प्रस्तुत करेगा, है ना?
मेरा मतलब है, मामले के लिए, जब xmlns=".../xaml/प्रस्तुति" शीर्ष स्तर का नाम स्थान है और UserControl wutg StackPanel दोनों uwp और wpf में उपलब्ध हैं, तो क्या दूसरा बटन दोनों प्लेटफार्मों में भी उपलब्ध नहीं होगा?

@Tirraon , मैंने जो उदाहरण दिया है वह पूरी तरह से wpf एप्लिकेशन के लिए है जो Xaml द्वीप समूह का उपयोग उनके आवेदन को बढ़ाने के लिए करता है। यह "मानक" मार्कअप के लिए अभिप्रेत नहीं है जिसका उपयोग wpf और WinUI अनुप्रयोगों के बीच किया जाता है, क्या इसका कोई मतलब है?

वर्तमान में, Xaml द्वीप समूह का उपयोग करने के इच्छुक ऐप लेखकों को प्रत्येक द्वीप के लिए उपयोगकर्ता नियंत्रण बनाना होगा। फिर वे wpf मार्कअप में स्वाभाविक रूप से WinUI तत्वों को एम्बेड करने के बजाय, उनके wpf मार्कअप में एक स्ट्रिंग के माध्यम से प्रकार का संदर्भ देते हैं।

मैं अभी अपने फोन पर हूं, लेकिन अपने पीसी के पास होने के बाद मैं जो प्रस्तावित कर रहा हूं उससे पहले और बाद में मैं और अधिक ठोस प्राप्त कर सकता हूं।

@ स्टीवनब्रिक्स
ओह, अब मैं तुम्हें मिल गया, धन्यवाद।

@ स्टीवनब्रिक्स
ओह, अब मैं तुम्हें मिल गया, धन्यवाद।

@Tirraon बढ़िया! खुशी है कि हम एक ही पेज पर हैं ️

क्षमा करें यदि मेरा विचार बाएं क्षेत्र से बाहर आया है, तो हम शुरुआती चर्चा में हैं कि हम Xaml द्वीप परिदृश्य में सुधार के लक्ष्य के साथ टूलिंग को संभावित रूप से कैसे एकीकृत कर सकते हैं। क्या आपको लगता है कि ऐसी किसी चीज़ में कोई मूल्य है?

एफडब्ल्यूआईडब्ल्यू, मुझे निश्चित रूप से लगता है कि आप जो प्रस्ताव दे रहे थे उसमें योग्यता है। लेकिन मैं कुछ ऐसा करने पर ध्यान केंद्रित करने की कोशिश कर रहा हूं जिसे हम WinUI3/.NET5 समय सीमा में कर सकते हैं।

कुछ पाइपलाइन में WinUI Xaml को प्रस्तुत करने का तरीका जानें जो आउटपुट को मूल कैनवास में अनुवादित करता है और मूल संदेश सिस्टम से इनपुट प्राप्त करता है। जैसे WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android।

लॉन्च के समय सभी एडेप्टर को लागू करना आवश्यक नहीं है, केवल वही जो विंडोज 10 का समर्थन करने के लिए आवश्यक हैं।

से: स्टीवन किरबैक सूचनाएं @github.com
भेजा गया: गुरुवार, 7 नवंबर 2019 9:13:46 AM
प्रति: Microsoft/Microsoft-ui-xaml [email protected]
सीसी: द शार्प निंजा [email protected] ; टिप्पणी टिप्पणी @noreply.github.com
विषय: पुन: [माइक्रोसॉफ्ट/माइक्रोसॉफ्ट-यूआई-एक्सएएमएल] विनयूआई 3.0 डेवलपर अनुभव और टूलिंग - इनपुट की आवश्यकता (#1045)

@stevenbrix https://github.com/stevenbrix
ओह, अब मैं तुम्हें मिल गया, धन्यवाद।

@Tirraon https://github.com/Tirraon बढ़िया! खुशी है कि हम एक ही पेज पर हैं ️

क्षमा करें यदि मेरा विचार बाएं क्षेत्र से बाहर आया है, तो हम शुरुआती चर्चा में हैं कि हम Xaml द्वीप परिदृश्य में सुधार के लक्ष्य के साथ टूलिंग को संभावित रूप से कैसे एकीकृत कर सकते हैं। क्या आपको लगता है कि ऐसी किसी चीज़ में कोई मूल्य है?

एफडब्ल्यूआईडब्ल्यू, मुझे निश्चित रूप से लगता है कि आप जो प्रस्ताव दे रहे थे उसमें योग्यता है। लेकिन मैं कुछ ऐसा करने पर ध्यान केंद्रित करने की कोशिश कर रहा हूं जिसे हम WinUI3/.NET5 समय सीमा में कर सकते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52VMX://PMV नोटिफिकेशन/अनसब्सक्राइब-ऑथ/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ ।

हाँ कृपया, XAML द्वीप परिदृश्य इस समय भयानक है

@sharpninja
आपको Uno . पर एक नज़र डालनी चाहिए
https://platform.uno/
साथ ही यह हर प्लेटफॉर्म के लिए WinUI 3.0 को सपोर्ट करेगा
https://platform.uno/winui-on-windows7-via-unoplatform/

@ स्टीवनब्रिक्स
मैं वास्तव में Xaml द्वीप समूह के साथ अनुभव नहीं कर रहा हूं और आमतौर पर सादे यूडब्ल्यूपी के साथ काम करता हूं। लेकिन मुझे निश्चित रूप से इसे करीब से देखने की जरूरत है।
मेरा प्रस्ताव Xaml द्वीप से संबंधित नहीं था, लेकिन सामान्य रूप से WinUI के लिए अधिक संबंधित था, क्योंकि यह एक से अधिक प्लेटफॉर्म पर काम करेगा।

मेरा प्रस्ताव Xaml द्वीप से संबंधित नहीं था, लेकिन सामान्य रूप से WinUI के लिए अधिक संबंधित था, क्योंकि यह एक से अधिक प्लेटफॉर्म पर काम करेगा।

@Tirraon , हाँ, मैं इसे पूरी तरह से प्राप्त करता हूं, और बिल्कुल प्यार करता हूँ जहाँ आपका सिर . पर है

मैंने @jeromelaban और कंपनी के साथ संक्षेप में बात की है कि आप वास्तव में क्या प्रस्तावित कर रहे हैं, और निश्चित रूप से रुचि है। अभी तक कोई ठोस योजना या प्रतिबद्धता नहीं है, क्योंकि हम अभी भी चर्चा के शुरुआती चरण में हैं। इस प्रकार का इनपुट बहुत अच्छा है, और यह हमारे ग्राहकों के लिए लाए गए मूल्य को बेहतर ढंग से समझने में हमारी सहायता करता है

एक्सएएमएल द्वीप परिदृश्य से मेरा मतलब सी ++ एक है। मैंने जिन मुद्दों का सामना किया है, उनकी सूची के लिए इस थ्रेड में मेरे पिछले संदेश देखें।

हाँ कृपया, XAML द्वीप परिदृश्य इस समय भयानक है

एक्सएएमएल द्वीप परिदृश्य से मेरा मतलब सी ++ एक है। मैंने जिन मुद्दों का सामना किया है, उनकी सूची के लिए इस थ्रेड में मेरे पिछले संदेश देखें।

@sylveon मैं आपकी टिप्पणियां (नीचे लिंक)
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

बहुत सारे दर्द जो आप ध्वनि परियोजना प्रणाली से संबंधित हैं, और मुझे पता है कि यह कुछ ऐसा है जो कई लोगों के रडार पर है (हालांकि मैं काफी अलग हूं)। क्या आपने यह वीडियो देखा है जो हमारी टीम के कुछ सदस्यों ने एक्सएएमएल टूलिंग पर किया था? उस लिंक को YouTube वीडियो को उस बिंदु से शुरू करना चाहिए जहां @ Michael - @ marb2000 नए Xaml द्वीप अनुभव में जाने लगते हैं। हम निश्चित रूप से सी ++ के बारे में परवाह करते हैं, लेकिन मुझे नहीं पता कि हमने अभी तक केवल .NET अनुभव को संबोधित किया है, या यदि सी ++ में भी सुधार हुआ है। वे शायद उस पर अधिक टिप्पणी कर सकते थे।

ऐसी बहुत सी चीज़ें हैं जो Xaml द्वीप के अनुभव को उपयोग में आसान और स्वाभाविक बनाने में मदद करेंगी। जिस पहलू का मैं जिक्र कर रहा हूं वह यह है कि वर्तमान में, जिस तरह से आप डब्ल्यूपीएफ में यूडब्ल्यूपी सामग्री का एक द्वीप शामिल करते हैं वह इस तरह है (उपरोक्त वीडियो से):

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

मुझे लगता है कि हम इससे बेहतर कर सकते हैं, और कुछ इस तरह प्रदान कर सकते हैं:

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

@ स्टीवनब्रिक्स

मैंने @jeromelaban और कंपनी के साथ संक्षेप में बात की है कि आप वास्तव में क्या प्रस्तावित कर रहे हैं, और निश्चित रूप से रुचि है। अभी तक कोई ठोस योजना या प्रतिबद्धता नहीं है, क्योंकि हम अभी भी चर्चा के शुरुआती चरण में हैं। इस प्रकार का इनपुट बहुत अच्छा है, और यह हमारे ग्राहकों के लिए लाए गए मूल्य को बेहतर ढंग से समझने में हमारी सहायता करता है

इतनी दिलचस्पी है, इतनी दिलचस्पी! (यह वार्तालाप हर जगह दिखाई देता है) यदि WinUI पोस्ट 3.0 को क्रॉस-प्लेटफ़ॉर्म कार्यान्वयन में स्थानांतरित कर दिया जाता है तो आपके पास बहुत अधिक डेवलपर समर्थन होगा। बस #1461 पर चर्चा को देखें। अल्पावधि में XAML/C# को HTML/WASM में बदलने के लिए Uno Platform तकनीक का उपयोग करके UWP ऐप्स को सभी प्लेटफॉर्म पर चलाना आश्चर्यजनक होगा। लंबे समय तक मैं इलेक्ट्रॉन या ब्राउज़र में चलने के प्रदर्शन प्रभाव के बारे में चिंतित हूं और अधिक कुशल वास्तुकला के लिए जगह है।

निचला रेखा, मुझे पता है कि इस समय हर कोई WinUI 3.0 पर व्यस्त है। लेकिन जब यह खत्म हो रहा है तो यह बहुत अच्छा होगा यदि हम @jeromelaban , @marb2000 , @jevansaks और अन्य को हर जगह UWP रेंडर करने का सबसे अच्छा तरीका जानने के लिए कनेक्ट करें। यह भविष्य की कॉल के लिए एक बहुत ही दिलचस्प सामुदायिक चर्चा भी होगी।

WinUi एकमात्र समझदार मार्ग है जो नियो और डुओ दोनों को जीवित रहने की ओर ले जाता है

से: रोबलू नोटिफिकेशन @github.com
भेजा गया: गुरुवार, नवंबर ७, २०१९ दोपहर १२:००:०७ अपराह्न
प्रति: Microsoft/Microsoft-ui-xaml [email protected]
सीसी: द शार्प निंजा [email protected] ; उल्लेख करें @noreply.github.com
विषय: पुन: [माइक्रोसॉफ्ट/माइक्रोसॉफ्ट-यूआई-एक्सएएमएल] विनयूआई 3.0 डेवलपर अनुभव और टूलिंग - इनपुट की आवश्यकता (#1045)

@stevenbrix https://github.com/stevenbrix

मैंने @jeromelaban https://github.com/jeromelaban और कंपनी के साथ संक्षेप में बात की है कि आप वास्तव में क्या प्रस्तावित कर रहे हैं, और निश्चित रूप से रुचि है। अभी तक कोई ठोस योजना या प्रतिबद्धता नहीं है, क्योंकि हम अभी भी चर्चा के शुरुआती चरण में हैं। इस प्रकार का इनपुट बहुत अच्छा है, और यह हमारे ग्राहकों के लिए लाए गए मूल्य को बेहतर ढंग से समझने में हमारी सहायता करता है

इतनी दिलचस्पी है, इतनी दिलचस्पी! (यह वार्तालाप हर जगह दिखाई देता है) यदि WinUI पोस्ट 3.0 को क्रॉस-प्लेटफ़ॉर्म कार्यान्वयन में स्थानांतरित कर दिया जाता है तो आपके पास बहुत अधिक डेवलपर समर्थन होगा। #1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 पर चर्चा

निचला रेखा, मुझे पता है कि इस समय हर कोई WinUI 3.0 पर व्यस्त है। लेकिन जब यह खत्म हो रहा है तो यह बहुत अच्छा होगा अगर हम @jeromelaban https://github.com/jeromelaban , @marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks और अन्य को कनेक्ट

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे जवाब दें, इसे GitHub पर देखें https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DN20. नोटिफिकेशन/अनसब्सक्राइब-ऑथ/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ ।

WinUi एकमात्र समझदार मार्ग है जो नियो और डुओ दोनों को जीवित रहने की ओर ले जाता है

मैं सहमत हूं, लेकिन एंड्रॉइड और सरफेस डुओ पर चलने वाले विंडोज ऐप से समान यूआई प्राप्त करना। डेवलपर से न्यूनतम हस्तक्षेप के साथ - वह पवित्र कब्र है।

यदि विनयूआई के पास प्राथमिक विकास मंच होने का कोई मौका है, और विंडोज़ को लंबी अवधि में अन्य प्लेटफॉर्म के ऐप्स का एक ग्रहण बनने का मौका देता है। (हमेशा एक बुरी बात नहीं है, जब बड़े स्थापित ऐप्स की बात आती है, लेकिन एलओबी और अगले बड़े ऐप्स के लिए ...)

मैं अपनी खुद की एप्लिकेशन उन्मुख भाषा बना रहा हूं और कोड-बैक के लिए XAML और मेरी भाषा के साथ WinUI का उपयोग करने में सहायता करना चाहता हूं। यह अच्छा होगा यदि टूलिंग ने XAML के लिए कोड जनरेशन प्रदान करने के लिए भाषा की क्षमता की पेशकश की। क्या बेहतर होगा यदि एक्सएएमएल कोड-जनरेटर ने आईएल को आंशिक वर्ग के रूप में बनाया है जिसे किसी भी भाषा का उपयोग करके पूरा किया जा सकता है। इसका मतलब यह होगा कि कोड जनरेटर कंपाइल करने योग्य आईएल असेंबली का उत्पादन करेगा।

मैं अपनी खुद की एप्लिकेशन उन्मुख भाषा बना रहा हूं और कोड-बैक के लिए XAML और मेरी भाषा के साथ WinUI का उपयोग करने में सहायता करना चाहता हूं। यह अच्छा होगा यदि टूलिंग ने XAML के लिए कोड जनरेशन प्रदान करने के लिए भाषा की क्षमता की पेशकश की। क्या बेहतर होगा यदि एक्सएएमएल कोड-जनरेटर ने आईएल को आंशिक वर्ग के रूप में बनाया है जिसे किसी भी भाषा का उपयोग करके पूरा किया जा सकता है। इसका मतलब यह होगा कि कोड जनरेटर कंपाइल करने योग्य आईएल असेंबली का उत्पादन करेगा।

एक्सएएमएल डायरेक्ट है, लेकिन इस समय सी # और सी ++ द्वारा समर्थित है।
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

मेरा यह मतलब नहीं था। मेरा मतलब है कि कोड जनरेशन टूल का आउटपुट आईएल होना चाहिए, सी # या सी ++ नहीं। इस तरह मेरा कंपाइलर एक्सएएमएल को आईएल में बदल सकता है और फिर उस वर्ग को प्राप्त कर सकता है।

@sharpninja यह भी फायदेमंद होगा, अगर यह केवल सी ++ कोड के बजाय एलएलवीएम बाइटकोड भी उत्पन्न कर सकता है।

इस तरह हम सभी XLang समर्थित परिदृश्यों में उपयोग करने के लिए COM लाइब्रेरी और WinMD फ़ाइलों को उत्पन्न करने के लिए इसे MIDL और XLang के साथ जोड़ सकते हैं।

मेरी सी++ हैट ऑन के साथ, मैं सी++ के लिए विनयूआई टूलिंग के संबंध में जो देखना चाहता हूं, वह माइक्रोसॉफ्ट के लिए अंतत: 90 के दशक के मध्य से सी++ बिल्डर द्वारा किए जा रहे कार्यों को पूरा करने के लिए होगा।

C++ आधारित विकास के लिए वास्तविक RAD टूलिंग प्रदान करें।

सी ++/सीएलआई इससे कम विफल रहा, हालांकि फॉर्म के साथ कुछ कामकाज थे।

सी ++/सीएक्स ऐसा लग रहा था कि यह होगा, फिर भी इसे सी ++ बिल्डर की तुलना में थोड़ा अधिक प्रयास करने की आवश्यकता है।

अब सी ++/विनआरटी मानक सी ++ 17 हो सकता है, लेकिन डेस्कटॉप डेवलपर्स के लिए समग्र अनुभव डाउनग्रेड की तरह लगता है, बॉयलरप्लेट में वृद्धि के साथ जिसे मैन्युअल रूप से लिखना पड़ता है, अतिरिक्त देखभाल कैसे COM प्रकार एबीआई सीमा पर जाते हैं और डिजाइनर की कमी सहयोग।

तो मैं अभी भी सी ++/सीएक्स का उपयोग कर रहा हूं, क्योंकि मुझे एमआईडीएल कंपाइलर और COM एबीआई समर्थन द्वारा आवश्यक सभी बॉयलरप्लेट से निपटने का मन नहीं है।

दूसरी तरफ, मेरी .NET टोपी के साथ, मैं सी ++ को केवल डायरेक्टएक्स जैसे पुस्तकालयों को विनयूआई घटकों के रूप में उजागर करना चाहता हूं, कुछ ब्लेंड प्यार, और यह याद रखना कि एफ # माना जाता है कि माइक्रोसॉफ्ट से भी एक .NET भाषा है।

मुझे WinUI पर स्विच करने की कोशिश में काफी संघर्ष करना पड़ा है। ऐसे कई प्रथम और तृतीय पक्ष पुस्तकालय हैं जो इस समय WinUI का उपयोग नहीं कर रहे हैं और उन पर निर्भरता समस्याग्रस्त हो जाती है। उदाहरण के लिए, व्यवहार एसडीके।

यूडब्ल्यूपी कम्युनिटी डिसॉर्डर में स्टेटसबार के बारे में बात करते समय यह एक विचार है ..

विजुअल स्टूडियो में, टूलबॉक्स में डब्ल्यूपीएफ नियंत्रणों के लिए प्रविष्टियां शामिल हैं जो यूडब्ल्यूपी से गायब हैं और जब उन प्रविष्टियों का चयन किया जाता है, तो पारंपरिक नियंत्रण को अनुकरण करने का तरीका बताते हुए एक पॉपअप दिखाएं।

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

संपादित करें:
और पूर्णता के लिए, यहाँ कुछ और है जो मैंने Status Bar के बारे में कहा था .. बस यह दिखा रहा है कि कोई व्यक्ति UWP (या WinUI) से कैसे संपर्क कर सकता है यदि वे इससे परिचित नहीं हैं ..

पुन: StatusBar - मैं UWP की कोशिश कर रहे पारंपरिक ढांचे के उपयोगकर्ताओं के दृष्टिकोण से सोच रहा था - और यह देखते हुए कि इसमें StatusBar नहीं है - अभी भी कई ऐप्स में एक प्रधान है। हां, कमांडबार और भी बेहतर हो सकता है। लेकिन लोग नहीं जानते कि कमांडबार क्या है या शायद यह अनुमान लगा सकता है कि यह कुछ और है। ऊपर किसी ने यह भी सुझाव दिया कि मैं एक ग्रिड जोड़ता हूं, इसे नीचे रखता हूं, इसे एक पंक्ति ऊंचा करता हूं और सामान प्रदर्शित करने के लिए विभिन्न नियंत्रण जोड़ता हूं। तो ऐसा लगता है कि मौजूदा Xaml डिज़ाइनर भी CommandBar के बारे में नहीं जानते हैं। वैसे भी, शायद आप सही हैं, शायद कमांडबार बेहतर है, लेकिन पॉल थुरोट ने अपने यूडब्ल्यूपी नोटपैड ऐप में इसका इस्तेमाल नहीं किया, उन्होंने एक ग्रिड का इस्तेमाल किया। तो ऐसा लगता है कि CommandBar को StatusBar के प्रतिस्थापन के रूप में संप्रेषित नहीं किया जा रहा है। आकस्मिक (या नए) डेवलपर्स अभी भी StatusBar की तलाश कर रहे हैं और इसे नहीं ढूंढ रहे हैं। मुझे पता है कि पॉल थुरोट एक डेवलपर नहीं है, लेकिन आप मेरी बात समझ सकते हैं।

यह बहुत अच्छा होगा यदि स्निपेट्स को सामान्य उपयोग के मामले में भी xaml में इंजेक्ट किया गया हो।

से: गेविन-विलियम्स सूचनाएं @github.com
भेजा गया: मंगलवार, फरवरी 18, 2020 शाम 7:05:39 अपराह्न
प्रति: Microsoft/Microsoft-ui-xaml [email protected]
सीसी: द शार्प निंजा [email protected] ; उल्लेख करें @noreply.github.com
विषय: पुन: [माइक्रोसॉफ्ट/माइक्रोसॉफ्ट-यूआई-एक्सएएमएल] विनयूआई 3.0 डेवलपर अनुभव और टूलिंग - इनपुट की आवश्यकता (#1045)

यूडब्ल्यूपी कम्युनिटी डिसॉर्डर में स्टेटसबार के बारे में बात करते समय यह एक विचार है ..

विजुअल स्टूडियो में, टूलबॉक्स में डब्ल्यूपीएफ नियंत्रणों के लिए प्रविष्टियां शामिल हैं जो यूडब्ल्यूपी से गायब हैं और जब उन प्रविष्टियों का चयन किया जाता है, तो पारंपरिक नियंत्रण को अनुकरण करने का तरीका बताते हुए एक पॉपअप दिखाएं।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4Dcom नोटिफिकेशन/अनसब्सक्राइब-ऑथ/AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ ।

डेवलपर कहानी में एक प्रकार की तुलना सूची शामिल होनी चाहिए।

अवधारणाएं जो Win32 ऐप्स के लिए आंतरिक हैं, इसलिए एक सूची में स्टेटस बार, टूलबार, मेनू, ग्रिपर, टैब इत्यादि, और दूसरी सूची में WinUI समकक्ष।

पृष्ठ में दोनों के कोड नमूने शामिल हैं, यह दिखाने के लिए कि मौजूदा ऐप के UI को WinUI पर कैसे स्थानांतरित किया जा सकता है।

प्रश्न खोलें)
क्या यह फायदेमंद होगा यदि हम एक माइग्रेशन टूल प्रदान करते हैं जो स्वचालित चरणों को 1-3 करता है?

हां। मैं 1 "विरासत" विंडोज फॉर्म ऐप का समर्थन करता हूं (विरासत का मतलब फिर से लिखने के लिए कोई बजट नहीं है) और 2 या 3 विरासत wpf ऐप्स। WinForms ऐप फंसे हो सकता है, लेकिन wpf ऐप्स को जल्दी से WinUI 3 में पोर्ट करने में मदद करने के लिए एक टूल बहुत अच्छा होगा!

MSIX सभी ऐप्स के लिए आधुनिक पैकेजिंग विधि है। Win32 में WinUI के लिए क्या हमें ClickOnce का समर्थन करना चाहिए? हमें किन अन्य पैकेजिंग विधियों के लिए समर्थन शामिल करना चाहिए? विशेष रूप से Win32 में WinUI के लिए

वर्तमान में हम अपने उपयोगकर्ताओं के डेस्कटॉप पर ऐप्स प्रकाशित करने के लिए क्लिकऑन का उपयोग करते हैं। स्वचालित अपडेट के कुछ मॉडल अभी भी वांछित होंगे।

@JeffSchwandt

वे चरण पुराने संस्करणों (1-2) का उपयोग करके संस्करण 3 में WinUI परियोजनाओं को परिवर्तित करने के संबंध में थे।

एक डब्ल्यूपीएफ ऐप को एक विनयूआई में कनवर्ट करना एक स्वचालित फैशन में विशेष रूप से व्यवहार्य नहीं है (बिना भारी प्रयास के, लेकिन फिर भी यह बेहद त्रुटि प्रवण होगा)।

मुझे उम्मीद है कि इस अनुरोध को पोस्ट करने के लिए यह सही धागा है।

जंग को अभी एक उचित UI ढांचे की सख्त जरूरत है। यह अच्छा होगा अगर WinUI भविष्य में मूल एसडीके और कुछ टूलिंग के साथ जंग का समर्थन कर सके।

मुझे उम्मीद है कि इस अनुरोध को पोस्ट करने के लिए यह सही धागा है।

जंग को अभी एक उचित UI ढांचे की सख्त जरूरत है। यह अच्छा होगा अगर WinUI भविष्य में मूल एसडीके और कुछ टूलिंग के साथ जंग का समर्थन कर सके।

अच्छी खबर, Rust/WinRT का विकास हो रहा है जो कि रस्ट ऐप्स को WinUI जैसे WinRT API का उपयोग करने में सक्षम बनाएगा! https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/ पर एक नज़र डालें

@jevansaks अरे, प्रतिक्रिया के लिए धन्यवाद! हाँ, मुझे पता है कि केनी Rust/WinRT पर काम करता है, लेकिन मुझे आश्चर्य है कि क्या WinRT एकमात्र API परत है जिसे WinUI समर्थन करेगा? मुझे यकीन नहीं है कि यह इस तथ्य के साथ कैसे फिट होगा कि डेस्कटॉप ऐप्स से WinRT API उपयोग केवल विंडोज 10 1903 में उपलब्ध हो गया, जबकि विनयूआई का लक्ष्य विंडोज 10 के पुराने संस्करणों का समर्थन करना है।

Rust/WinRT (जैसे C++/WinRT) को विंडोज 7 तक सभी तरह से काम करना चाहिए। WinRT ने हमेशा डेस्कटॉप/win32 ऐप्स पर काम किया है। यह केवल कुछ एपीआई हैं जिनके पास स्टोर/यूडब्ल्यूपी/पैकेजिंग आवश्यकताएं थीं (संपूर्ण रूप से WinRT नहीं)। जब तक WinUI के पास वे आवश्यकताएं नहीं हैं, तब तक आप किसी भी समर्थित प्लेटफॉर्म पर C++/WinRT और Rust/WinRT दोनों के माध्यम से डेस्कटॉप ऐप्स से WinUI का उपयोग करने में सक्षम होंगे।

WinUI डेस्कटॉप ऐप्स को लाइव टाइल्स और टाइल अपडेटिंग का समर्थन करना चाहिए - अच्छे सरल नमूनों और SDK टूलिंग के साथ आज UWP ऐप्स की तुलना में टाइलें आसान बनाने के लिए।

मुझे यकीन नहीं है कि यह इस तथ्य के साथ कैसे फिट होगा कि डेस्कटॉप ऐप्स से WinRT API उपयोग केवल विंडोज 10 1903 में उपलब्ध हो गया

WinUI डेस्कटॉप को अभी WinUI 3.0 के लिए डिज़ाइन किया जा रहा है, और इससे सादे Win32 ऐप्स को WinUI डाउनलेवल (वर्तमान योजना 1803 तक नीचे है) का उपयोग करने में सक्षम होना चाहिए।

विंडोज यूआई को कम से कम प्रमुख एमवीवीएम फ्रेमवर्क- एमवीवीएम लाइट, प्रिज्म और कैलीबर्न का समर्थन करना चाहिए। दुर्भाग्य से, INotifyPropertyChanged और INotifyCollectionChanged Breaking ObservableCollection में परिवर्तन के साथ आपकी प्रलेखित समस्यानिश्चित रूप से एमवीवीएम लाइट, और शायद अन्य दो ढांचे को भी तोड़ देता है। सोचा आपको पता होना चाहिए।

दुर्भाग्य से, INotifyPropertyChanged और INotifyCollectionChanged Breaking ObservableCollection में परिवर्तन के साथ आपकी प्रलेखित समस्या निश्चित रूप से MVVM लाइट को तोड़ती है, और शायद अन्य दो फ्रेमवर्क भी। सोचा आपको पता होना चाहिए।

धन्यवाद @terrycox! हम जानते हैं और इसे WinUI 3.0 RTM द्वारा संबोधित किया जाएगा, और आदर्श रूप से इससे पहले एक पूर्वावलोकन बिल्ड में;)

@terrycox विंडोज यूआई को कम से कम प्रमुख एमवीवीएम ढांचे- एमवीवीएम लाइट, प्रिज्म और कैलिबर्न का समर्थन करना चाहिए। ... आपकी प्रलेखित समस्या

हां, इसे प्रलेखित समस्याओं को ठीक करना चाहिए, लेकिन एमवीवीएम ढांचे का समर्थन करने के लिए, WinUI सहित .Net UI लाइब्रेरी की कोई आवश्यकता नहीं है। इसे केवल उन वस्तुओं का समर्थन करने की आवश्यकता है जो UI तत्वों का प्रतिनिधित्व करती हैं। ए.नेट एमवीवीएम या रिएक्टिव फ्रेमवर्क डेटा का प्रतिनिधित्व करने वाली वस्तुओं के आधार पर यूआई का प्रतिनिधित्व करने वाली नेट वस्तुओं को उत्पन्न और बदलने का एक तरीका है। न तो दूसरे के बारे में जानने की जरूरत है। किसी भी फ्रेमवर्क को किसी भी UI लाइब्रेरी के साथ जोड़ा जा सकता है।

लेकिन एमवीवीएम ढांचे का समर्थन करने के लिए, WinUI सहित .Net UI लाइब्रेरी की कोई आवश्यकता नहीं है।

लेकिन घटनाओं और इंटरफेस जैसी चीजें जिन्हें UIElements के बारे में पता है, आवश्यक हैं और यही टूटा हुआ है।

से: चार्ल्स रॉडी नोटिफिकेशन @github.com
भेजा गया: बुधवार, 25 मार्च, 2020 2:28:46 अपराह्न
प्रति: Microsoft/Microsoft-ui-xaml [email protected]
सीसी: द शार्प निंजा [email protected] ; उल्लेख करें @noreply.github.com
विषय: पुन: [माइक्रोसॉफ्ट/माइक्रोसॉफ्ट-यूआई-एक्सएएमएल] विनयूआई 3.0 डेवलपर अनुभव और टूलिंग - इनपुट की आवश्यकता (#1045)

@terrycox https://github.com/terrycox विंडोज यूआई को कम से कम प्रमुख एमवीवीएम फ्रेमवर्क- एमवीवीएम लाइट, प्रिज्म और कैलीबर्न का समर्थन करना चाहिए। ... आपकी प्रलेखित समस्या

हां, इसे प्रलेखित समस्याओं को ठीक करना चाहिए, लेकिन एमवीवीएम ढांचे का समर्थन करने के लिए, WinUI सहित .Net UI लाइब्रेरी की कोई आवश्यकता नहीं है। इसे केवल उन वस्तुओं का समर्थन करने की आवश्यकता है जो UI तत्वों का प्रतिनिधित्व करती हैं। ए.नेट एमवीवीएम या रिएक्टिव फ्रेमवर्क डेटा का प्रतिनिधित्व करने वाली वस्तुओं के आधार पर यूआई का प्रतिनिधित्व करने वाली नेट वस्तुओं को उत्पन्न और बदलने का एक तरीका है। न तो दूसरे के बारे में जानने की जरूरत है। किसी भी फ्रेमवर्क को किसी भी UI लाइब्रेरी के साथ जोड़ा जा सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 पर https://github.com/notifications/unsubscribe-auth/ की सदस्यता समाप्त

डॉटनेट क्ली टूलिंग का उपयोग एक साथ किया जाना चाहिए। नेट कोर एसडीके।
डॉटनेट न्यू और डॉटनेट बिल्ड जैसे कमांड पर्याप्त होने चाहिए, विजुअल स्टूडियो को स्थापित करने की कोई हार्ड निर्भरता नहीं। कृपया, पूरी तरह से .नेट कोर युग में शामिल हों!

• एक्सएएमएल डिजाइनर तेज हो तो अच्छा होगा। वर्तमान एक्सएएमएल डिजाइनर धीमा है और हमेशा कुछ त्रुटि कहता है कि कुछ अपवाद हुआ और यह काम नहीं करेगा। कृपया इसे ठीक करें और मजबूत डिज़ाइनर प्रदान करें।

• वर्तमान में यूडब्ल्यूपी में कोई एपीआई नहीं है जो लॉक स्क्रीन का पता लगा सके। यह अच्छा होगा यदि हमें ऐसे एपीआई प्रदान किए जाएं जो लॉकस्क्रीन का पता लगा सकें और बूलियन को रिटर्न वैल्यू के रूप में दे सकें। हमें लॉक या अनलॉक करने के बाद कुछ एनिमेशन और बैज भी प्रदर्शित करने में सक्षम होना चाहिए।
  - मौजूदा लॉकस्क्रीन एपीआई

• मेरा मुद्दा समझाया

@JensNordenbro की टिप्पणी की तर्ज पर, कोई मौका है कि यह सिर्फ बनाम कोड के साथ काम करेगा?

मैं एक एप्लिकेशन टेम्प्लेट देखना चाहता हूं जो WinUI 3.0 UI के साथ .NET 5 एप्लिकेशन बनाता है जो .NET 5 स्टोर होस्ट एप्लिकेशन को संदर्भित करता है। यह .NET 5.0 की कम अनावश्यक स्थापनाओं की अनुमति देगा

WinUI डेस्कटॉप एप्लिकेशन में, muxc.Window.ThisPtr से hWnd से मूल Win32 विंडो में कैसे जाता है?

मैंने डेस्कटॉप के लिए WinUI 3 प्रीव्यू 1 के लिए मई 2020 के नए टेम्प्लेट आज़माए क्योंकि मुझे यह विचार पसंद आया।

लेकिन मेरा एक सवाल है। विंडोज़ पर विनयूआई के मूल यूआई प्लेटफॉर्म होने के साथ, मैं संचार की कमी पर आश्चर्यचकित हूं कि क्या यह वास्तव में विंडोज 10 का भी हिस्सा है?

मेरा परिणामी हैलो वर्ल्ड ऐप लगभग 120 एमबी बड़ा था। ज़रूर, जगह सस्ती है, लेकिन यहाँ मेरी अपनी कोई निर्भरता नहीं थी। इसमें से, WinUI ने काफी मात्रा में स्थान का उपभोग किया, लगभग उतना ही जितना कि .NET 5 में ही शामिल था। यह अकेले x64 बिल्ड के लिए है। बहु-प्लेटफ़ॉर्म पैकेज में x86 शामिल करें और उस आकार को दोगुना करें। कुछ अन्य निर्भरताएँ जोड़ें और हम वितरण के लिए पैकेज करने के लिए आसानी से 300 एमबी ऐप देख सकते हैं।

क्यों WinUI 3 केवल .NET 5 के विंडोज संस्करण का हिस्सा नहीं है? क्या यह .NET कोर मॉडर्नाइजेशन प्रयास का हिस्सा है? लेकिन अगर नहीं तो इसके लिए जगह कहां है? वास्तव में हर ऐप के फोल्डर के अंदर? आधिकारिक विंडोज 10 यूजर इंटरफेस के रूप में...?

या यह भविष्य में विंडोज 10 का हिस्सा होगा? यदि WinUI को सिस्टम लाइब्रेरी की तरह अधिक व्यवहार किया गया था और .NET 5 बाद में विंडोज के साथ शिप करना शुरू कर देगा, तो हम इसके बजाय तुलनात्मक रूप से छोटे ऐप्स देख रहे होंगे। लेकिन उम्मीद है कि यह कम से कम विंडोज 10X की कहानी है, और शायद बाद में विंडोज 10 नॉन-एक्स की भी? इन दो पुस्तकालयों के साथ-साथ विंडोज 10 एसडीके सी #/विनआरटी ब्रिज डीएलएल को छोड़कर, ऐप का आकार 1-5 एमबी तक गिर जाता है।

@ryandemopoulos ने डिस्कॉर्ड पर कहा है कि WinUI को एक फ्रेमवर्क पैकेज के रूप में वितरित किया जाएगा, इसलिए वितरण के लिए स्टोर या MSIX का उपयोग करने वाले ऐप्स को WinUI का अपना संस्करण नहीं रखना होगा, क्योंकि वे सभी इसकी एक ही प्रति साझा करेंगे।

विनयूआई को विंडोज़ का हिस्सा बनाने से विनयूआई के ओएस से अलग होने की बात खत्म हो जाएगी।

"विश्वसनीय रूप से उपलब्ध है और ऐप के आकार में नहीं" चिंता का विषय है। मुझे आशा है कि .NET 5 समान रूप से वितरित किया जाएगा।

@lmcdougald मैं आपको .NET कोर इंस्टालर पर एक मुद्दा खोलने के लिए आमंत्रित करता हूं और अनुरोध करता हूं कि .NET 5 सर्विसिंग के लिए फ्रेमवर्क पैकेजिंग का भी उपयोग करें।

@jonasnordlund एक और चर्चा #2500 है जहां हम WinRT रनटाइम परिनियोजन के बारे में बात कर रहे हैं। शायद आपको वहां कुछ जवाब मिल जाए। :)

@ marb2000 मैंने एक मुद्दा खोला है, लेकिन मैं ईमानदारी से चकित हूं। क्या इसे विंडोज 10X डिलीवर करने वाले किसी ऐप के लिए जरूरी नहीं माना जाता है?

यहां कई विशेषताओं का संकलन है, जिनमें से कुछ सीधे WinUI नहीं हैं, लेकिन उनकी कमी किसी भी .NET क्लाइंट विकास के अनुभव को सीधे प्रभावित करती है - UWP क्लाइंट शामिल हैं, और विशेष रूप से LoB ऐप क्लाइंट।

• मेरे लिए सबसे पहली और सबसे महत्वपूर्ण सर्वोच्च प्राथमिकता है कि आप ऊनो प्लेटफॉर्म का पोषण करें। मेरे लिए, यह वही है जो यूडब्ल्यूपी को प्रासंगिक बनाता है, अगर यूनो आसपास नहीं होता तो मैं एक्सएफ या किसी अन्य तकनीक से समझौता करता। (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• व्यूमोडेल (https://github.com/microsoft/ProjectReunion/issues/31) से उपयोग किया जाने वाला सार क्लाइंट-साइड पहचान प्रबंधन API
• पूर्ण डेटा-एनोटेशन समर्थन, सत्यापन और UI शीर्षक, स्ट्रिंग लंबाई, आवश्यक-विशेषताएं, केवल-पढ़ने के लिए फ़ील्ड, वॉटरमार्क आदि आदि। (https://bit.ly/3gcMJ3a)
• ओडाटा में सुधार करें ताकि यह आरआईए सेवाओं के लिए एक उचित विकल्प बन जाए। उदाहरण के लिए: समर्थन विशेषता पीढ़ी, इंटरफ़ेस कार्यान्वयन, सामान्य प्रकार, XML दस्तावेज़ (https://github.com/OData/odata.net/issues/1746)
• डब्ल्यूपीएफ से सभी लापता सुविधाओं को लाओ
• x:Bind Binding जैसी सभी सुविधाएं भी होनी चाहिए, जैसे स्कोप या नेस्टेड बाइंडिंग (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• हॉट रीस्टार्ट (https://github.com/microsoft/ProjectReunion/issues/44)
• सरल हैलो वर्ल्ड टेम्प्लेट से अधिक। जैसे कि यूजर-लॉगिन, एमवीवीएम, रूटिंग, एक्स-प्लेट प्रोजेक्ट्स (जैसे यूनो-प्लेटफॉर्म), आदि के लिए समायोजित। दूसरे शब्दों में कृपया डब्ल्यूटीएस को अधिक शक्ति दें।
• XAML WYSIWYG- संपादक लेआउट सुविधाएँ जैसे WinForms में, जैसे डॉकिंग, स्पेसिंग आदि। - ऐसा लगता है कि यह पूरा हो गया है! ❤

आपके संकलन @weitzhandler के लिए धन्यवाद, बहुत सुविधाजनक।

WinUI टीम का Uno उत्पाद टीम (गैर-Microsoft), Xamarin Forms/MAUI टीम और रिएक्ट नेटिव के साथ बहुत अच्छा संबंध है। हम उनके साथ सक्रिय रूप से सहयोग करते हैं और हम उनके सफल भविष्य की कामना करते हैं।

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

अधिक जटिल टेम्पलेट्स के एप्रोपोस। विंडो टेम्प्लेट स्टूडियो का यह मिशन है।

मैंने उन क्षेत्रों को इकट्ठा करने का प्रयास करने के लिए एक मुद्दा बनाया जहां डब्ल्यूपीएफ # 719 @weitzhandler @ marb2000 की तुलना में WinUI की कमी है

अधिक जटिल टेम्पलेट्स के एप्रोपोस। विंडो टेम्प्लेट स्टूडियो का यह मिशन है।

@ marb2000 क्या हम विंडो टेम्प्लेट स्टूडियो को अपने VSIX में ला सकते हैं? या शायद इसके विपरीत? आगे बढ़ने वाले सभी WinUI3 (और प्रोजेक्ट रीयूनियन) टेम्प्लेट की शिपिंग के लिए बस विंडो टेम्प्लेट स्टूडियो का उपयोग वाहन के रूप में करें?

अधिक जटिल टेम्पलेट्स के एप्रोपोस। विंडो टेम्प्लेट स्टूडियो का यह मिशन है।

@ marb2000 क्या हम विंडो टेम्प्लेट स्टूडियो को अपने VSIX में ला सकते हैं? या शायद इसके विपरीत? आगे बढ़ने वाले सभी WinUI3 (और प्रोजेक्ट रीयूनियन) टेम्प्लेट की शिपिंग के लिए बस विंडो टेम्प्लेट स्टूडियो का उपयोग वाहन के रूप में करें?

@crutkas @sibille

मैं सुझाव देता हूं कि सी++ बिल्डर (वीसीएल/एफएमएक्स) और क्यूटी क्रिएटर/डिजाइन स्टूडियो के साथ कुछ समय बिताएं, यह जानने के लिए कि सी++ और आधुनिक टूलिंग के साथ क्या संभव है।

आदर्श रूप से विनयूआई इन उत्पादों के समान टूलिंग की पेशकश करेगा जो सी ++ में लिखे गए क्रॉस प्लेटफॉर्म जीयूआई के लिए पहले से ही आज है।

मुझे जिस चीज की परवाह है वह है .NET विकास अनुभव और उपयोग के मामलों के लिए एक समान अनुभव होने के कारण मुझे सी ++ का उपयोग करने के लिए मजबूर होना पड़ता है, किसी भी कारण से हमें उपलब्ध नहीं कराया जाता है।

C++ Builder और QtCreator इस तरह का अनुभव प्राप्त करते हैं, और इसका स्वागत किया जाएगा यदि .NET डेवलपर्स को C++/WinRT कोड लिखने में कुछ दिन बिताने का सामना करना पड़ रहा हो।

इसे .NET डेवलपर्स के बारे में क्यों बनाएं? C++ XAML का अनुभव बस खराब है, इससे कोई फर्क नहीं पड़ता कि आप C++ या .NET डेवलपर हैं।

मेरा मानना ​​है कि यह बहुत अच्छा होगा यदि वे डेस्कटॉप, वेब (एज), मोबाइल और IoT पर समान XAML रन को सक्षम करने के लिए सड़क खोलते हैं।

हम बिना C#, Xaml या डिज़ाइनर वाले c++ प्रोजेक्ट में WinUI 3 का उपयोग कब कर पाएंगे?
क्या WinUI 3 के c++ कोर के ओपन सोर्सिंग की तारीख के बारे में भी कोई खबर है?

संपादित करें: मुझे लगता है कि मुझे अपने पहले प्रश्न का उत्तर मिल गया है, ऐसा लगता है कि WinUI 3.0 पूर्वावलोकन 1 में c ++ WinUI 3 प्रोजेक्ट टेम्पलेट है :

.vsix एक्सटेंशन को स्थापित करने के बाद आप "WinUI" की खोज करके और उपलब्ध C# या C++ टेम्प्लेट में से एक का चयन करके एक नया WinUI 3.0 प्रोजेक्ट बना सकते हैं।

विनयूआई में सुधार करने के लिए मैं जिस उपयोग के मामले को पसंद करूंगा, वह है फ्रंटलाइन आईटी सपोर्ट स्टाफ के लिए छोटे जीयूआई आधारित उपकरण बनाना जो अक्सर पॉवरशेल में लिखे जाते हैं। विजुअल स्टूडियो कोड में इस प्रकार के उपकरण बनाने में सक्षम होना बहुत अच्छा होगा। यहां तक ​​कि C# आधारित VSCode विकास विकल्प भी एक अच्छा कदम होगा। पूर्ण विकसित विजुअल स्टूडियो इस मामले के लिए बल्कि भारी और जटिल लगता है।

वर्तमान में एंटरप्राइज़ परिवेश इसके बजाय इस तरह के टूल का उपयोग कर रहे हैं:

• https://poshgui.com/ (वेब आधारित XAML विज़ार्ड)
• सेपियन पॉवरशेल स्टूडियो 2020 (मालिकाना)
• एडमिन स्क्रिप्ट एडिटर (एएसई) (अब छोड़ दिया गया प्रोजेक्ट)

अन्य आमतौर पर इस्तेमाल किए जाने वाले "एक्सएएमएल के लिए विजुअल स्टूडियो का उपयोग करें" पैटर्न यहां वर्णित हैं:

• पावरशेल स्क्रिप्ट के लिए एक सरल ग्राफिकल इंटरफेस बनाएं
• अपनी स्क्रिप्ट के लिए पावरशेल जीयूआई कैसे बनाएं

मेरा सवाल @mqudsi के उस सवाल के संदर्भ में है जो उन्होंने मई में पूछा था, लेकिन किसी ने जवाब नहीं दिया।

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

चूंकि यह एक डेस्कटॉप एप्लिकेशन है, इसलिए हम ICoreWindowInterop का उपयोग नहीं कर सकते हैं और मैंने new HandleRef(this, ThisPtr) जैसे यादृच्छिक स्वैग की कोशिश की है, जहां 'यह' Microsoft.UI.Xaml.Window प्रकार का है, लेकिन अमान्य विंडो हैंडल के लिए त्रुटि को देखते रहें। एक बार जब मैं अंततः उस एचडब्ल्यूएनडी को प्राप्त कर लेता हूं, तो मैं विंडो शैली को बदलने और दूसरों के साथ साझा करने के लिए और अधिक COM का उपयोग करने का प्रयास कर सकता हूं ताकि वे उस दर्द को महसूस न करें जो मैं अभी करता हूं :)।

रुचि रखने वाले किसी भी व्यक्ति के लिए, यह मुख्य विंडो के लिए एचडब्ल्यूएनडी को पकड़ने के लिए उपयोग किया जाने वाला त्वरित दृष्टिकोण है ताकि मैं इसे सीमाहीन बना सकूं। WindowStyle = कोई नहीं के डब्ल्यूपीएफ समकक्ष के लिए पूरा समाधान यहां खत्म हो गया

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

इस समय ऐसा प्रतीत नहीं होता है कि जब आपका WinUI एक डेस्कटॉप प्रक्रिया में हो तो hWnd प्राप्त करने का कोई आसान/दस्तावेज तरीका नहीं है, इसलिए मैंने उस दृष्टिकोण की ओर रुख किया जिसका मैंने उपयोग किया था। काफी अच्छा काम करने लगता है।

मुझे लगता है कि शायद यूडब्ल्यूपी और यूनिवर्सल विंडोज़ शर्तों के रूप में दूर हो जाना चाहिए। शर्तें कुछ दुर्भाग्यपूर्ण सामान ले जाती हैं जो देवों को शर्मसार करती हैं।

शायद हम WinUI (Universal Windows) टेम्पलेट को WinUI (Win64) से बदल सकते हैं? फिर डेस्कटॉप या स्टोर का विकल्प है?

Win64 भ्रमित कर रहा है - इसका मतलब यह होगा कि Win32 API केवल 32-बिट्स का समर्थन करता है, और इसके विपरीत UWP केवल 64 बिट्स का समर्थन करता है, जो दोनों झूठे हैं।

Win32 नाम अपने आप में पहले से ही शुरुआती लोगों को भ्रमित करता है, मामलों को बदतर बनाने के लिए हमें Win64 की आवश्यकता नहीं है।

@VagueGit कुछ मैंने सीखा है कि सही नाम चुनना और कहानी को गढ़ना अधिक जटिल चीजों में से एक है। नाम बदलने से बेहतर, हमें (Microsoft) आपको सफल होने में मदद करने के लिए सही उत्पाद (और कहानी) प्रदान करना चाहिए। UWP Win32 के रूप में एक प्रसिद्ध शब्दावली है, इसलिए हमें उनका उपयोग जारी रखना चाहिए।

यह हमारा दृष्टिकोण है (बहुत सरलीकृत):

WinUI का उपयोग दो "प्रकार" ऐप्स में किया जा सकता है जो विभिन्न उपकरणों को लक्षित करते हैं:

• आपका ऐप बहुत सारे इनपुट और फॉर्म-फैक्टर वाले बहुत सारे उपकरणों को लक्षित करता है। फिर यूडब्ल्यूपी का इस्तेमाल करें। उसके लिए UWP बनाया गया था; इसलिए आपको पैकेजिंग मॉडल, स्टोर, एप्लिकेशन मॉडल, सुरक्षा कंटेनर आदि जैसी आवश्यकताओं को पूरा करना होगा।
• आपका ऐप केवल डेस्कटॉप को लक्षित करता है और इसके लिए ओएस तक पूर्ण पहुंच की आवश्यकता होती है। Win32 या डेस्कटॉप का उपयोग करें (इस तरह विजुअल स्टूडियो wpf, WinForms, MFC, ऐप्स को कॉल करता है)।

UWP ऐप में WinUI और डेस्कटॉप ऐप में WinUI (या UWP WinUI ऐप या डेस्कटॉप WinUI ऐप) प्रोजेक्ट टेम्प्लेट के लक्ष्य के साथ बेहतर तरीके से फिट होते हैं।

@ marb2000 नामकरण चीजें कठिन हैं, सहमत हैं। लेकिन कुछ नाम दुर्भाग्य से जहरीले होते हैं और उन्हें पीछे छोड़ देना चाहिए। इसलिए समय-समय पर उत्पादों की रीब्रांडिंग की जाती है। यूडब्ल्यूपी एक है, लेकिन यह केवल मेरा विचार है ... और हर कोई जिससे मैं बात करता हूं। लेकिन वहाँ तुम जाओ।

हमारे पास एक UWP ऐप है जिसे हम WinUI में माइग्रेट करना चाहते हैं। हम Win32 api का उपयोग नहीं करते हैं, हम केवल डेस्कटॉप को लक्षित करते हैं और हम स्टोर का उपयोग नहीं करना चाहते हैं। यह कैसे फिट बैठता है?

@ marb2000 नामकरण चीजें कठिन हैं, सहमत हैं। लेकिन कुछ नाम दुर्भाग्य से जहरीले होते हैं और उन्हें पीछे छोड़ देना चाहिए। इसलिए समय-समय पर उत्पादों की रीब्रांडिंग की जाती है। यूडब्ल्यूपी एक है, लेकिन यह केवल मेरा विचार है ... और हर कोई जिससे मैं बात करता हूं। लेकिन वहाँ तुम जाओ।

हमारे पास एक UWP ऐप है जिसे हम WinUI में माइग्रेट करना चाहते हैं। हम Win32 api का उपयोग नहीं करते हैं, हम केवल डेस्कटॉप को लक्षित करते हैं और हम स्टोर का उपयोग नहीं करना चाहते हैं। यह कैसे फिट बैठता है?

ऐप किसके लिए है, बिल्कुल?

एक उपभोक्ता के रूप में जो यूडब्ल्यूपी ऐप्स का उपयोग करने के लिए अपने रास्ते से हट जाता है, अगर ऐप स्टोर में नहीं है, तो शायद मैं इसे छूने वाला नहीं हूं, इसे देखने की बात तो दूर।

चिंता मत करो @shaheedmalik हम आपको इसे छूने के लिए नहीं

इसलिए हम जानते हैं कि Win64 व्यावसायिक ऐप्स के लिए एक बाज़ार है और हमारा मानना ​​है कि हम उन कुछ व्यावसायिक विकासकर्ताओं में से हैं जिन्होंने Win64 ऐप्स डिलीवर किए हैं जिनके लिए व्यावसायिक ग्राहक भुगतान करेंगे। मुझे पता है कि इस धागे पर कुछ देव हैं जो यूनिवर्सल विंडोज/मल्टी-प्लेटफॉर्म रूट पर जाते हैं, लेकिन वे काफी दुर्लभ हैं। मेरे अनुभव में अधिकांश व्यावसायिक देवता एक विशिष्ट रूप कारक को लक्षित करते हैं।

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

@VagueGit
"हमारे पास एक यूडब्ल्यूपी ऐप है जिसे हम विनयूआई में माइग्रेट करना चाहते हैं। हम Win32 एपीआई का उपयोग नहीं करते हैं, हम केवल डेस्कटॉप को लक्षित करते हैं और हम स्टोर का उपयोग नहीं करना चाहते हैं। यह कैसे फिट बैठता है?"

तो क्या आप UWP को WinUI 3 में माइग्रेट करना चाहते हैं और स्टोर के बाहर तैनात करना चाहते हैं? एक भोला-भाला प्रश्न: क्या आप MSIX की कोशिश की थी sideload ? स्टोर के अलावा कोई कारण जो आपको UWP का उपयोग करने से रोकता है?

@VagueGit
"तो हम जानते हैं कि Win64 व्यावसायिक ऐप्स के लिए एक बाज़ार है।"

एक सवाल, Win64 बहुत सी चीजों के लिए है। उदाहरण के लिए ऐप्स x64 के लिए संकलित हैं। आपके लिए Win64 का क्या अर्थ है?

@marb2000 UWP को व्यावसायिक रिपोर्टिंग के लिए खराब समर्थन प्राप्त है। हमें लगता है कि रीब्रांडिंग से रिपोर्ट राइटर जैसे तीसरे पक्ष के टूल के विकास को किकस्टार्ट करने में मदद मिल सकती है। हमने साइड-लोडिंग के साथ एक नाटक किया है लेकिन यह हमारे लिए 20H1 तक संभव नहीं था क्योंकि डिफ़ॉल्ट रूप से साइडलोडिंग सक्षम नहीं थी।

हमें लगता है कि विन64 विंडोज़ पर आगे बढ़ने का रास्ता है। Micro$ ने अतीत में Win32 को बिना किसी सफलता के विरासत के रूप में पेश करने का प्रयास किया है और अब वह उस स्थिति पर वापस आ रहा है। लेकिन अंततः Win32 को दूर जाना है, हमारे फैसले में (मैं कहता हूं कि Win32 के विकास के 30 साल बाद खुद)। हमने कंपनियों द्वारा खरीदे जाने वाले व्यवसाय ऐप को वितरित करने के लिए UWP की अधिकांश सीमाओं को पार करने में कामयाबी हासिल की है। हम चिंतित हैं कि UWP के एक और पुनरावृत्ति में रीब्रांडिंग के बिना सीमित कर्षण होगा।

जैसा कि @ marb2000 से भ्रम है, Win64 शब्द पहले से ही (खराब) इस्तेमाल किया जा चुका है। मैंने इसे पहले भी इंगित किया है।

मैं मानता हूं कि एक रीब्रांडिंग की आवश्यकता हो सकती है, लेकिन Win64 इसे करने का एक भयानक तरीका है। जब तक कुछ आधिकारिक न हो, तब तक आपको UWP शब्द का उपयोग सभी को समझने के लिए करना चाहिए।

@sylveon UWP को हर कोई फेल समझता है। हम इसे पसंद करते हैं लेकिन कुछ अन्य करते हैं। इसलिए रीब्रांडिंग महत्वपूर्ण है। आप WinUI (डेस्कोप) या WinUI (स्टोर) को प्रोजेक्ट टेम्पलेट के रूप में क्या समझते हैं?

WinUI (स्टोर) अच्छा नहीं है क्योंकि आप स्टोर में Win32 ऐप्स भी शिप कर सकते हैं, या स्टोर के बाहर UWP ऐप्स शिप कर सकते हैं। हालांकि WinUI (डेस्कटॉप) अच्छा है।

@sylveon WinUI (स्टोर) स्टोर को लक्षित करने वाली अन्य परियोजनाओं को रोकता नहीं है। इसका सीधा सा मतलब है कि आप क्षमताओं के सेट से शुरुआत करना चाहते हैं जो स्टोर के माध्यम से रिलीज को सक्षम बनाता है।

शुरुआती लोगों को भ्रमित करना काफी बुरा है।

यह इस धागे में किसी विशेष व्यक्ति को निर्देशित करने के लिए नहीं है, बल्कि डेस्कटॉप एप्लिकेशन डेवलपर/कंपनी के मालिक के रूप में मेरी अपनी राय है।

मैं कभी भी किसी चीज के नाम में नहीं फंसता। मुझे केवल इस बात की परवाह है कि इसमें कौन सी विशेषताएं हैं और यह कितनी अच्छी तरह समर्थित है।

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

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

मुझे लगता है कि कम से कम दो दर्शकों पर विचार करने की आवश्यकता है; डेवलपर्स और अंतिम उत्पाद उपयोगकर्ता। एक डेवलपर/व्यवसाय के स्वामी के रूप में, यदि मेरे पास एक ग्राहक है जिसे एक आवेदन की आवश्यकता है, और उन्हें अंतर्निहित प्रौद्योगिकी नामों से खट्टा कर दिया गया है, तो यह मेरा काम है कि उनमें यह विश्वास पैदा किया जाए कि नाम से दर्शाया गया उत्पाद परिपक्व हो गया है और इससे उनका क्या संबंध है अतीत अद्यतन किया गया है। दूसरी ओर, अगर मैं कहता हूं कि "देखो, यह नई महान चीज है जिसे WinUI या MAUI कहा जाता है" और उनके पास पहले से ही wpf या UWP या Xamarin उत्पाद हैं, जिन्हें हमने उनके लिए विकसित किया है, तो उनसे एक दूरदर्शी प्रतिक्रिया है "ओह बढ़िया, अब हमारे ऐप्स 2,3 या 4 विभिन्न तकनीकों में लिखे गए हैं"। यही वह जगह है जहां मुझे उन्हें बेचना है। सभी ग्राहकों के अलग-अलग होने को ध्यान में रखते हुए, मैं पुशबैक का सामना करने जा रहा हूं, चाहे आप नाम को वैसे ही छोड़ दें, या इसे बदल दें।

अंत में (मेरे लिए) जो महत्वपूर्ण है वह यह है कि हमारे पास ऐसे उपकरण हैं जो हमें आकर्षक लिखने के लिए आवश्यक हैं, जिनमें समृद्ध अनुप्रयोग हैं जिनमें एलटीएस है। जब मैं किसी उत्पाद को हिट डेडलाइन देखता हूं तो मैं पंप हो जाता हूं और उत्पाद जारी होने पर मुझे नई सुविधा और समस्या समाधान सूची पढ़ने को मिलती है। मुझे 2016 से नेटकोर/नेट5 (नाम परिवर्तन एलओएल) के बारे में यह पसंद है। (बीटीडब्ल्यू, अपने ग्राहकों को यह बताने की कोशिश कर रहा है कि नेट 5 वह है जिसे हम एक साल के लिए लक्षित करने की योजना बना रहे हैं, जब मैंने उन्हें नेटकोर में जाने के लिए आश्वस्त किया तो यह आसान नहीं है!)

अभी मैं केवल एक बिंदु पर तेजी से आगे बढ़ना चाहता हूं जब मैं एक्सएएमएल बोली के साथ एक डेस्कटॉप एप्लिकेशन लिख सकता हूं और वही प्रतिपादन प्रदर्शन प्राप्त कर सकता हूं जो यूडब्ल्यूपी/विनयूआई प्रदान करता है (यूडब्ल्यूपी सैंडबॉक्स के बिना)। इस कारण से और सितंबर के पूर्वावलोकन में गिरावट के कारण, मैं एवलोनिया ड्राइविंग का परीक्षण शुरू करने जा रहा हूं। स्कीशर्प के माध्यम से प्रतिपादन प्रदर्शन के बारे में सुनते समय मुझे डब्ल्यूपीएफ समानताएं पसंद हैं।

यह कुछ वर्षों में रोमांचक होने वाला है जब UI विकास के विकल्प स्थिर हो गए हैं। वे जो चाहें प्रोजेक्ट टेम्प्लेट को नाम दे सकते हैं, इससे सुविधाओं की कमी के बारे में मेरी राय नहीं बदलेगी।

मैं आप सभी की सराहना करता हूं।

मुझे वह मिलता है जो jtbrower अपने ईमेल में कहता है। हमारी जैसी उनकी कंपनी उन कुछ लोगों में से एक है जो सफलतापूर्वक xaml पथ पर चले गए। हमें लाभों के बारे में आश्वस्त होने की आवश्यकता नहीं है।

लेकिन यह अच्छा हो सकता है, xaml माइक्रो $ के लिए एक आपदा थी। डेवलपर्स भारी मात्रा में या तो WinForms के साथ रहे, या पूरी तरह से वेब विकास के लिए जहाज कूद गए। UWP के बाद से डेवलपर्स का पलायन बिगड़ गया।

xaml प्रौद्योगिकियों के टिकाऊ होने के लिए, माइक्रो $ को उन लाखों देवों को जीतना होगा, जिन्हें वे ऑनबोर्ड करने में विफल रहे हैं। उन डेवलपर्स के लिए, टूल वेंडर्स और टेक मीडिया के लिए, UWP एक डेड एंड है। UWP का एक और पुनरावृत्ति उन्हें जीत नहीं पाएगा।

@VagueGit लेकिन डेवलपर्स एक समान नाम वाले उत्पाद को जानने के लिए उत्सुक हैं। वे MAUI को एक नाम बदलकर Xamarin फॉर्म के रूप में जानते हैं। वास्तव में वे यह कहने के लिए इतनी दूर जाते प्रतीत होते हैं कि MAUI एक चोरी का नाम था। मुझे नहीं लगता कि आप एक विशिष्ट डेवलपर को नाम परिवर्तन के साथ प्रेरित कर सकते हैं। हम सभी सुविधाएँ चाहते हैं, है ना? क्या आप नहीं देखेंगे कि UWP एकाधिक विंडोज़ की अनुमति देता है, या पूर्ण विश्वास की अनुमति देता है? यदि उन्होंने दोनों किया, तो हम सभी UWP को लक्षित कर सकते हैं और शायद स्टोर ऐप्स के लिए सैंडबॉक्स रख सकते हैं। मैं बस ज़ोर से सपना देख रहा हूँ जो वास्तव में मुझे उत्साहित करेगा! विशेषताएं!!

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

तो हर तरह से जो यूडब्ल्यूपी पथ के साथ जारी रखना चाहते हैं वे यूडब्ल्यूपी स्टोर टेम्पलेट के साथ शुरू कर सकते हैं, लेकिन जो 64 बिट डेस्कटॉप चाहते हैं, सैंडबॉक्स नहीं और पूर्ण विश्वास ... ठीक है, यह यूडब्ल्यूपी नहीं है?

यूडब्ल्यूपी बाजार में अपंग के रूप में देखा जा रहा है। यूडब्ल्यूपी को छोड़कर सभी ने यूडब्ल्यूपी को छोड़ दिया जब माइक्रो $ ने यूडब्ल्यूपी में अपने स्वयं के ऐप बनाने से पीछे हट गए।

यूडब्ल्यूपी में विकास के लिए देव बाजार नहीं देखता है। 64 बिट डेस्कटॉप, सैंडबॉक्स्ड और पूर्ण विश्वास नहीं, नाम परिवर्तन से कहीं अधिक है; यह एक अलग प्रतिमान है। लेकिन अगर इसे अभी भी यूडब्ल्यूपी कहा जाता है तो यह उन लोगों द्वारा ध्यान नहीं दिया जाएगा जिन्होंने यूडब्ल्यूपी को बट्टे खाते में डाल दिया है।

@VagueGit मुझे खुशी है कि आपको UWP के साथ सफलता मिली है। नामकरण कठिन है, और तथ्य यह है कि हम इसे "यूनिवर्सल विंडोज प्लेटफॉर्म" कहते हैं और यह वास्तव में विंडोज डेवलपर्स के विशाल बहुमत द्वारा मान्य नहीं है, ठीक है, बहुत "सार्वभौमिक" नहीं है। प्रोजेक्ट रीयूनियन का एक सटीक सारांश इसे ठीक करना और यूडब्ल्यूपी के हर पहलू को सभी विंडोज डेवलपर्स द्वारा वास्तव में सुलभ बनाना है।

मैं मानता हूँ कि UWP का नाम खराब है, यदि आप किसी खोज इंजन में "UWP is" वाक्यांश टाइप करते हैं, तो पहला स्वतः-सुझाव Bing या Google आपको "UWP is dead" देगा। हालाँकि, मुझे लगता है कि @ marb2000 सही है कि हमें नाम का उपयोग करना जारी रखना चाहिए, इसके बावजूद कि इसमें सामान है।

उस के साथ कहा जा रहा है...

आज, डेस्कटॉप प्रोजेक्ट के कई पहलू हमारे द्वारा "UWP" के रूप में परिभाषित किए जाने वाले विभिन्न भागों का उपयोग करने में सक्षम होंगे:

1. UI स्टैक (उर्फ WinUI3)
2. एमएसआईएक्स पैकेजिंग
3. एमआरटी संसाधन

एक बार CoreApplication को हटा लेने के बाद, UWP और डेस्कटॉप के बीच एकमात्र अंतर वास्तव में सैंडबॉक्स मॉडल होगा जिसे आप अपने एप्लिकेशन के लिए चुनते हैं और आप किन उपकरणों को लक्षित करने में सक्षम हैं।

हमने प्रोजेक्ट टेम्प्लेट में संशोधन करने और एक विज़ार्ड जैसा अनुभव रखने पर चर्चा की है जो इसका अधिक सटीक वर्णन करता है।

@JeanRoca इसे चला रहे प्रधान मंत्री हैं और उनके पास अधिक जानकारी हो सकती है जो वह साझा कर सकते हैं

मुझे WinUI डेस्कटॉप टेम्प्लेट का विचार पसंद है। Win32 से अधिक उपयुक्त और फॉरवर्ड लुकिंग। यह वह टेम्प्लेट है जिसके साथ हम शुरुआत करेंगे जबकि Win32 ने 32 बिट की बाधा का सुझाव दिया था। उम्मीद है कि विनयूआई डेस्कटॉप को मीडिया और डेवलपर्स के बीच कुछ कर्षण मिलेगा।

जब स्टोर के बाहर एक UWP ऐप जारी किया जाता है तो पैकेज .appinstaller होता है। अगर हम उस ऐप को विन यूआई डेस्कटॉप में अपग्रेड करते हैं, तो इंस्टॉलर पैकेज ऐपइंस्टालर से एमएसिक्स में बदल जाता है।

यह मानते हुए कि हम ऐप पैकेज के भीतर विवरण समान रखते हैं और संस्करण को उचित रूप से टक्कर देते हैं, क्या विंडोज यह पहचान लेगा कि यह उसी ऐप का एक नया संस्करण है और स्थानीय डेटा को संरक्षित करता है, या क्या यह इसे एक अलग ऐप के रूप में स्थापित करेगा?

मेरी समझ से, WinUI 3.0 का उपयोग .NET Framework <= 4.8 से कभी नहीं किया जाएगा। तो अगर हम विनयूआई के बारे में बात कर रहे हैं, तो हम या तो .NET नेटिव या .NET 3.1/5+ (या बाइंडिंग का दूसरा सेट) के बारे में बात कर रहे हैं।

.NET 5 के लिए फ्रेमवर्क पैकेजिंग के बारे में आगे बढ़ने/आगे पूछने के बारे में कोई सुझाव (या मुझे इस बिंदु पर ६ का अनुमान है)? मैंने एक मुद्दा खोला और कोई प्रतिक्रिया नहीं मिली। बंडलिंग .NET 5 इन-ऐप एक नॉनस्टार्टर है।

@ स्टीवनब्रिक्स

एक बार CoreApplication को हटा लेने के बाद, UWP और डेस्कटॉप के बीच एकमात्र अंतर वास्तव में सैंडबॉक्स मॉडल होगा जिसे आप अपने एप्लिकेशन के लिए चुनते हैं और आप किन उपकरणों को लक्षित करने में सक्षम हैं।

दुर्भाग्य से एक और बड़ा अंतर यह है कि .NET डेवलपर्स को डायरेक्टएक्स जैसे एपीआई के लिए सी ++ को छोड़ने के लिए मजबूर किया जा रहा है, जिनकी टीम स्पष्ट रूप से COM आधारित होने के बावजूद उन्हें यूडब्ल्यूपी संगत बनाने से इंकार कर देती है।

और इस प्रक्रिया में MIDL को मैन्युअल रूप से लिखने के अनुभव जैसे अच्छे नोटपैड के साथ, और फाइलों की प्रतिलिपि बनाने के उत्पादकता दिनों में वापस छोड़ दें, जाहिर तौर पर विंडोज टीम सी ++ वर्कफ़्लो के लिए नेट जैसा अनुभव प्रदान करने के बजाय एटीएल जैसे देव अनुभव को जाने नहीं दे सकती है। सी ++/सीएक्स सी ++ बिल्डर के लिए बहुत बंद हो रहा था, इसलिए इसे आईएसओ सामान के नाम पर मारना पड़ा, कि भाग्य के साथ हम उन्हें सी ++ 23 में और 2025 में वीएस में प्राप्त कर सकते हैं।

मुझे संदेह है कि तब तक कोई भी यूडब्ल्यूपी की परवाह करेगा, जब तक कि इन सभी गलत कामों को दूर करने के लिए एक उचित विकास अनुभव निर्धारित नहीं किया जाता है।

हमें गिटहब मुद्दे भी फेंक रहे हैं कि किस टीम को फीडबैक देना है, रुचि खोने का एक बहुत तेज़ तरीका है। जाहिर तौर पर मैं बहुत ज्यादा परवाह करता हूं।

डायरेक्टएक्स एपीआई को विनआरटी संगतता के लिए संशोधित नहीं किया जा सकता है क्योंकि यह मौजूदा उपभोक्ताओं के लिए एक महत्वपूर्ण एपीआई ब्रेक होगा, और ऐसा नहीं हो सकता है।

DirectX के लिए कई प्रबंधित रैपर उपलब्ध हैं, जैसे TerraFX जो एक कच्चा 1:1 बाइंडिंग या Vortice है जो एक अधिक C# -स्टाइल API आवरण है।

सीएक्स के लिए, इसे दूर जाना पड़ा। कंपाइलर-विशिष्ट भाषा एक्सटेंशन खराब हैं और उन पर फिदा हैं। यह कोड पोर्टेबिलिटी को महत्वपूर्ण रूप से बाधित करता है, अक्सर सी ++ मानक समर्थन के मामले में पिछड़ जाता है, और मौजूदा पुस्तकालयों से पूर्ण लंबवत एकीकरण की आवश्यकता होती है। विकल्प, WRL, का उपयोग करना बहुत कठिन था और अत्यधिक क्रियात्मक था। इसलिए, यह आश्चर्य की बात नहीं है कि बहुत से लोग (डीएक्स डिवीजन सहित) WinRT API नहीं लिखना चाहते थे।

सी ++/विनआरटी एक बेहतर समाधान है, यह दुर्भाग्यपूर्ण है कि इसे आईडीएल वापस लाना पड़ा (लेकिन वर्तमान में एक आवश्यक बुराई)। C++ टीम पहले की तुलना में मानक समर्थन पर बहुत बेहतर काम कर रही है, इसलिए यह आश्चर्य की बात नहीं होगी यदि हमें C++23 को अंतिम रूप देने से पहले वास्तव में मेटाक्लास मिलते हैं, जिससे डेवलपर UX को मौलिक रूप से सुधारना चाहिए।

@sylveon

आश्चर्यचकित न हों कि विंडोज डेवलपमेंट कम्युनिटी उत्पादकता में गिरावट के औचित्य के साथ रेडमंड से जो कुछ भी निकलता है उसे अनदेखा करता है।

सीएक्स के साथ भी ऐसा ही हो रहा था ... यह काफी हद तक अप्रयुक्त था क्योंकि सी ++ डेवलपर्स को मालिकाना भाषा एक्सटेंशन पसंद नहीं है।

यह मानते हुए कि हम ऐप पैकेज के भीतर विवरण समान रखते हैं और संस्करण को उचित रूप से टक्कर देते हैं, क्या विंडोज यह पहचान लेगा कि यह उसी ऐप का एक नया संस्करण है और स्थानीय डेटा को संरक्षित करता है, या क्या यह इसे एक अलग ऐप के रूप में स्थापित करेगा?

@VagueGit , यह एक अच्छा सवाल है। दिन के अंत में, UWP और डेस्कटॉप ऐप्स इंस्टॉल करने की तकनीक समान है। मुझे ऐसा लगता है कि उत्तर हाँ है? मुझे लगता है कि हाल के एसडीके के रूप में, यहां तक ​​​​कि यूडब्ल्यूपी ऐप्स में भी .msix एक्सटेंशन है (मैं गलत हो सकता हूं, इसलिए मुझे उद्धृत न करें)। मुझे यकीन है कि आप इसे स्थानीय रूप से आजमा सकते हैं और पता लगा सकते हैं? फी के लिए

.NET 5 के लिए फ्रेमवर्क पैकेजिंग के बारे में आगे बढ़ने/आगे पूछने के बारे में कोई सुझाव (या मुझे इस बिंदु पर ६ का अनुमान है)? मैंने एक मुद्दा खोला और कोई प्रतिक्रिया नहीं मिली। बंडलिंग .NET 5 इन-ऐप एक नॉनस्टार्टर है।

@lmcdougald मुझे लगता है कि मुझे पता है कि आप किस मुद्दे का जिक्र कर रहे हैं (लेकिन मुझे यह नहीं मिल रहा है)। एक होगा, लेकिन मुझे लगता है कि यह .net6 समय सीमा में होगा। हर कोई जानता है कि यह कुछ ऐसा है जिसे करने की जरूरत है।

और इस प्रक्रिया में MIDL को मैन्युअल रूप से लिखने के अनुभव जैसे अच्छे नोटपैड के साथ, और फाइलों की प्रतिलिपि बनाने के उत्पादकता दिनों में वापस छोड़ दें, जाहिर तौर पर विंडोज टीम सी ++ वर्कफ़्लो के लिए नेट जैसा अनुभव प्रदान करने के बजाय एटीएल जैसे देव अनुभव को जाने नहीं दे सकती है। सी ++/सीएक्स सी ++ बिल्डर के लिए बहुत बंद हो रहा था, इसलिए इसे आईएसओ सामान के नाम पर मारना पड़ा, कि भाग्य के साथ हम उन्हें सी ++ 23 में और 2025 में वीएस में प्राप्त कर सकते हैं।

हमें गिटहब मुद्दे भी फेंक रहे हैं कि किस टीम को फीडबैक देना है, रुचि खोने का एक बहुत तेज़ तरीका है। जाहिर तौर पर मैं बहुत ज्यादा परवाह करता हूं।

@pjmlp मैं आपकी ईमानदारी और जुनून की सराहना @sylveon ने उल्लेख किया है, वे एक कीमत पर आते हैं। हमने अंततः निर्णय लिया कि यदि हम C++ को महान बनाने के लिए इंजीनियरिंग प्रयास खर्च करना चाहते हैं, तो हमें इसे C++ मानक को आगे बढ़ाने में लगाना चाहिए। यह दुर्भाग्यपूर्ण है कि मेटा क्लास एक रास्ता है, और हम अंतरिम में अनुभव को बेहतर बनाने के तरीकों पर चर्चा कर रहे हैं, क्योंकि मैं आपसे सहमत हूं कि हम इतना लंबा इंतजार नहीं कर सकते।

प्रतिक्रिया के लिए धन्यवाद - मैं "हर कोई जानता है कि यह कुछ ऐसा है जिसे करने की आवश्यकता है" से मैं संतुष्ट हूं और मैं एक या एक साल के लिए फुलाए हुए बाइनरी के साथ रहूंगा।

@stevenbrix और @VagueGit - आपको अभी भी अपने msix पैकेज के लिए एक ऐपइंस्टालर फ़ाइल का उपयोग करने में सक्षम होना चाहिए। एपइंस्टालर फ़ाइल आपके पैकेज में यूरी प्रदान करने वाली एक जेसन फ़ाइल से ज्यादा कुछ नहीं है। चूंकि आपने एंटरप्राइज़ परिदृश्यों का उल्लेख किया है, आप ऐप इंस्टॉलर यूरी को आंतरिक स्थानों के लिए उचित रूप से अनुकूलित कर सकते हैं, या बाहरी पहुंच के लिए भी उन्हें अलग बना सकते हैं - सभी आपके सीडीएन पर निर्भर हैं। वर्जनिंग के संबंध में - हां पैकेज्ड ऐप्स के लिए यदि पैकेज आइडेंटिटी समान है, तो एक नया वर्जन इंस्टॉल करने से मौजूदा एपडाटा तक पहुंच होगी।

@stevenbrix @VagueGit मैं उस जानकारी के साथ उत्तर दूंगा जो मेरे पास वर्तमान में अनुभव जैसे विज़ार्ड पर है। मैं अभी भी इस भूमिका में बहुत नया हूं इसलिए बेझिझक जो कुछ भी मैं कहता हूं उसे नमक के दाने के साथ ले सकता हूं। इसके साथ ही, मेरी टीम वर्तमान में Windows Template Studio में प्रयास चला रही है। यह एप्लिकेशन वर्तमान में आपको हमारे विजार्ड में मौजूदा टेम्प्लेट से एक नया डब्ल्यूपीएफ या यूडब्ल्यूपी ऐप बनाने देता है जिसमें आप चाहते हैं कि पेज और फ्रेमवर्क हों।

भविष्य में इस एप्लिकेशन का लक्ष्य और वर्तमान योजना सभी उपयोगकर्ताओं के लिए विकास के अनुभव को एकीकृत और बेहतर बनाना है। हम वर्तमान में WinUI 3 के साथ डेस्कटॉप ऐप्स के लिए टेम्प्लेट विकसित कर रहे हैं। आप यहां ट्रैकिंग समस्या पा सकते हैं। हम यूडब्ल्यूपी के लिए भी ऐसा करने पर चर्चा कर रहे हैं ताकि समय आने पर हमारे उपयोगकर्ता आसानी से अपनी परियोजनाओं को स्थानांतरित कर सकें। हम अभी भी नहीं जानते कि यह कैसे काम करेगा, लेकिन हमारा लक्ष्य जितना संभव हो सके अनुभव को एकीकृत और सरल बनाना होगा। उम्मीद है की वो मदद करदे!

सीएक्स के साथ भी ऐसा ही हो रहा था ... यह काफी हद तक अप्रयुक्त था क्योंकि सी ++ डेवलपर्स को मालिकाना भाषा एक्सटेंशन पसंद नहीं है।

वे उन्हें क्लैंग, जीसीसी, इंटेल पर प्यार करते हैं। xlCC, PGI, CUDA, C++ Builder और एम्बेडेड प्लेटफॉर्म से भरपूर।

स्पष्ट रूप से सीएक्स को राजनीति के कारण मार दिया गया था जो माइक्रोसॉफ्ट से आने वाले सी ++ आरएडी पर्यावरण को स्वीकार नहीं कर सकता है, और इसके बजाय हम सभी एमडीआईएल/एटीएल को नोटपैड जैसे अनुभव के साथ कर रहे हैं।

मैं हर कीमत पर उनसे बचता हूं, चाहे संकलक कोई भी हो। खासकर जब कहा जाता है कि मालिकाना विस्तार अपने आप में एक पूरी तरह से अलग भाषा है।

मैं हर कीमत पर उनसे बचता हूं, चाहे संकलक कोई भी हो। खासकर जब कहा जाता है कि मालिकाना विस्तार अपने आप में एक पूरी तरह से अलग भाषा है।

फिर WinUI जैसे मालिकाना UI के विरुद्ध कोडिंग क्यों करें, इसके बजाय केवल X Windows जैसे खुले मानकों का उपयोग करें।

... जैसे कि यह विंडोज़ पर प्रयोग योग्य है। मैं कंपाइलर एक्सटेंशन से बचता हूं क्योंकि मैं मानकों के अनुपालन सत्यापन के लिए कंपाइलर्स (क्लैंग और एमएसवीसी) को मल्टीटार्गेट करना चाहता हूं और नए सी ++ मानकों का उपयोग करना चाहता हूं।

मेरा कोड सी ++ 20 का उपयोग करता है। कई भाषा एक्सटेंशन में C++17 समर्थन की कमी होती है या बहुत देर हो चुकी होती है। यह स्थिति सी ++ 20 के साथ दोहराई जाएगी (या खराब हो गई है क्योंकि सी ++ 20 में 17 की तुलना में बहुत अधिक नई चीजें हैं)। उदाहरण के लिए, आप C++20 ( /std:c++latest ) और CX ( /ZW ) को मिश्रित नहीं कर सकते हैं, आपको एक कंपाइलर त्रुटि मिलेगी जिसमें कहा गया है कि दो स्विच असंगत हैं।

NVCC को डिवाइस-साइड C++17 को सपोर्ट करने में इस साल तक का समय लगा। अच्छा लुक नहीं है।

मैं अपने आप को एक ऐसे कोने में नहीं रखना चाहता जहां मैं जिस भाषा विस्तार का उपयोग करता हूं वह एक नए मानक के साथ प्रयोग करने योग्य नहीं है, लेकिन मुझे एक नई मानक सुविधा की भी आवश्यकता है।

उपरोक्त कारणों से, मैं उनसे बचता हूं। यदि हम भाषा एक्सटेंशन के लिए WinUI C++ डेवलपर अनुभव को वापस ले लेते हैं, तो मैं एक वैकल्पिक GUI ढांचे की ओर बढ़ूंगा।

@sylveon आप

क्योंकि C++ डेस्कटॉप उपयोगकर्ताओं के लिए उपयोग करने लायक और कुछ नहीं बचा है।

यह पुष्टि करने के लिए धन्यवाद कि मूर्खतापूर्ण राजनीति ने सीएक्स को मार डाला।

एक दूसरे के अनुकूल रहने का सुझाव। मैं तकनीकी c++ तर्कों पर टिप्पणी नहीं कर सकता और यह न्याय नहीं करूंगा कि कौन सही है।
मुद्दा यह है कि go have fun with X जैसे वाक्यांश यहां मित्रवत और सहयोगात्मक माहौल नहीं बना रहे हैं। @stevenbrix और अन्य कृपया यदि आवश्यक हो तो कदम उठाएं।

धन्यवाद @hansmbakker ️

@pjmm और @sylveon मैं भावुक और ईमानदार बातचीत की सराहना करता हूं, आपके जैसे ग्राहकों की देखभाल करना बहुत अच्छा है।

दोनों बिंदु अत्यंत मान्य हैं, और मुझे लगता है कि आप दोनों के सही होने के लिए दुनिया काफी बड़ी है।

@pjmlp हम सी ++ के वर्तमान अनुभव से संतुष्ट नहीं हैं, और यह मानते हैं कि हमें सी ++ मेटाक्लास से पहले कुछ करने की ज़रूरत है। हमने idl-free c++/winrt के बारे में कुछ चर्चा की है, और @kennykerr और @ Scottj1s ने इसके बारे में एक बिल्ड टॉक की। हमारे पास अधिकांश समस्याएं WinUI के साथ एकीकरण से संबंधित थीं, क्योंकि हमारे कंपाइलर को मेटाडेटा की आवश्यकता होती है। हम यह देखने के लिए इस वर्कफ़्लो को फिर से देखना चाहते हैं कि क्या हमारे पास एक ऐसी कहानी हो सकती है जो समग्र डेवलपर अनुभव को बेहतर बनाए। C++/Cx को वापस लाने के बजाय, क्या c++/winrt का एक idl-मुक्त संस्करण आपको रूचि देगा?

केवल अपेक्षाएं निर्धारित करने के लिए, मुझे 2020 में यहां बहुत अधिक प्रगति देखने की उम्मीद नहीं है।

मुझे एक IDL मुक्त C++/WinRT में बहुत दिलचस्पी होगी।

आईडीई का अनुभव भी सबसे अच्छा नहीं है। उदाहरण के लिए हम एक्सएएमएल संपादक से इवेंट कॉलबैक नहीं बना सकते हैं जैसे हम सी # के साथ कर सकते हैं (नया कॉलबैक ड्रॉप-डाउन कुछ भी नहीं करता है)। XAML संपादक से परिभाषा पर नेविगेट करना भी काम नहीं करता है।

इसके साथ अन्य समस्याएं विभिन्न एक्सएएमएल कंपाइलर बग हैं जिन्हें मैंने इस रेपो में भरा है, जिससे मुझे ऐसे वर्कअराउंड की आवश्यकता होती है जो अन्य समर्थित भाषाओं में आवश्यक नहीं हैं।

@stevenbrix , मैं अपनी आवाज आईडीएल मुक्त सी ++/

@स्टीवनब्रिक्स ,

@pjmlp हम सी ++ के वर्तमान अनुभव से संतुष्ट नहीं हैं, और यह मानते हैं कि हमें सी ++ मेटाक्लास से पहले कुछ करने की ज़रूरत है। हमने idl-free c++/winrt के बारे में कुछ चर्चा की है, और @kennykerr और @ Scottj1s ने इसके बारे में एक बिल्ड टॉक की। हमारे पास अधिकांश समस्याएं WinUI के साथ एकीकरण से संबंधित थीं, क्योंकि हमारे कंपाइलर को मेटाडेटा की आवश्यकता होती है। हम यह देखने के लिए इस वर्कफ़्लो को फिर से देखना चाहते हैं कि क्या हमारे पास एक ऐसी कहानी हो सकती है जो समग्र डेवलपर अनुभव को बेहतर बनाए। C++/Cx को वापस लाने के बजाय, क्या c++/winrt का एक idl-मुक्त संस्करण आपको रूचि देगा?

केवल अपेक्षाएं निर्धारित करने के लिए, मुझे 2020 में यहां बहुत अधिक प्रगति देखने की उम्मीद नहीं है।

जो सिर्फ यह दिखाने के लिए जाता है कि सी ++/विनआरटी के साथ यह पूरा विचार कितना बुरा था, हमारी उत्पादकता ड्रॉप के लिए बिना किसी विचार के इसे हम पर रैंप करना।

इसे परिप्रेक्ष्य में रखने के लिए, लंबे समय तक डेवलपर जिसका विंडोज डेवलपर अनुभव विंडोज 3.0 पर वापस चला जाता है, और आजकल सी ++ ज्यादातर .NET आधारित अनुप्रयोगों के साथ उपयोग करने के लिए प्रासंगिक है, कभी भी अकेले नहीं।

पुराने समय के विंडोज डेवलपर्स के लिए जाने जाने वाले विभिन्न कारणों से बोरलैंड टूल्स मेरी रोटी और मक्खन थे, आगे का रास्ता माइक्रोसॉफ्ट कंपाइलर्स में माइग्रेट करने के लिए समाप्त हो गया।

फ़ॉर्म और एओटी संकलन के साथ एकीकरण की कमी को देखते हुए विज़ुअल सी ++ कभी भी सी ++ बिल्डर के रूप में _Visual_ नहीं था, यहां तक ​​​​कि सी ++/सीएलआई के साथ भी नहीं।

सी ++/सीएक्स ऐसा लग रहा था कि माइक्रोसॉफ्ट ने आखिरकार इसे प्राप्त कर लिया है, हमें 25 साल बाद डेल्फी/सी ++ बिल्डर के साथ-साथ एक ही उत्पादकता वर्कफ़्लो दिया जाएगा।

इसके बजाय हमने सी ++/सीएक्स को मारने के लिए एक राजनीतिक कदम के रूप में प्राप्त किया है, बिना हमारे उत्पादकता ड्रॉप हैंड के लिए आईएसओ सी ++ और डब्लूजी 21 के लापता सुविधाओं की ज़िम्मेदारी लहराते हुए, जैसे कि विजुअल सी ++ टीम हमसे दूर ले जा रही है डब्ल्यूजी 21 द्वारा स्वीकार किया गया।

और यदि आवश्यक सुविधाओं को अंततः ISO C++ द्वारा अपनाया जाएगा, तो क्या यह 2023, 2026,.... होगा? और फिर यह पूरा बिंदु है कि उन सुविधाओं को वास्तव में विंडोज डेवलपर्स के लिए कब उपलब्ध कराया जाएगा, बस मॉड्यूल समर्थन देखें। 2012 में विंडोज 8 के रिलीज होने के बाद से सी ++/सीएक्स हमें जो पेशकश कर रहा है, उसके बराबर पहुंचने में हमें लगभग अंतहीन साल लग रहे हैं।

इसलिए यह देखते हुए कि 2020 तक हम कोई सुधार नहीं देखेंगे, हम यहां पहले से ही 9 साल के बारे में बात कर रहे हैं, इसलिए मुझे क्षमा करें अगर मैं इस सब को कैसे प्रबंधित किया गया है, अन्य मुद्दों के शीर्ष पर जो हमारे पास है UWP विफलता से निपटने के लिए, रीयूनियन, .NET इको-सिस्टम रिबूट, जबकि हमें कोड के लिए कहा जाता है जैसे कि यह 2000 था जिसमें नंगे हड्डियों MIDL नोटपैड अनुभव और ATL जैसे अंतहीन टेम्पलेट सूप थे।

तो हाँ, या तो एक IDL मुक्त C++/WinRT संस्करण, या कम से कम एक पूर्ण Intellisense/Intelicode समर्थन के साथ एक IDL अनुभव और फ़ाइलों को मैन्युअल रूप से कॉपी करने की आवश्यकता नहीं है। हालांकि यह एटीएल जैसे अनुभव को सी ++ कोड से ही नहीं ले जाएगा।

.NET/C++ विकास के दृष्टिकोण से, मुझे Microsoft ढांचे के अतीत में समय यात्रा की परवाह नहीं है, बल्कि यह कैसा दिख सकता है यदि C++ RAD के दृष्टिकोण को अधिक गंभीरता से लिया जाए, दुर्भाग्य से जिस तरह से C++/ WinRT कहानी को प्रबंधित किया गया है, और बाकी सब कुछ जो अब UWP से बैकपेडलिंग के साथ जा रहा है, मुझे आश्चर्य है कि "डेवलपर्स, डेवलपर्स, डेवलपर्स" कहाँ गए हैं।

तो क्षमा करें अगर यह अभी भी थोड़ा सा लगता है, लेकिन जब मुझे कुछ आईएसओ शुद्धता के नाम पर सी ++ में .NET से बाहर निकलने की आवश्यकता होती है, तो मुझे अपनी उत्पादकता ड्रॉप के बारे में ऐसा ही लगता है कि अधिकांश सी ++ कंपाइलर्स वैसे भी नहीं करते हैं।

सी ++ अभी भी बहुत अधिक प्रासंगिक स्टैंडअलोन है। बहुत सारे एप्लिकेशन बिना किसी प्रबंधित कोड के रॉ C++ में लिखे जाते हैं। वास्तव में, संपूर्ण UWP रनटाइम और XAML/WinUI ढांचा मूल C++ है। सी ++ में लिखे गए एक यूडब्ल्यूपी ऐप में (शुक्र है) कोई प्रबंधित भाषा शामिल नहीं है।

मेरा तर्क है कि यदि आप .NET में C++ को छोड़ने की आवश्यकता महसूस करते हैं, तो आपको स्वयं से पूछना चाहिए कि क्यों और उन मुद्दों को सीधे .NET के भीतर हल करने का प्रयास करें। प्रदर्शन? स्पैन प्रकार, स्टैकलॉक और वेक्टर इंट्रिनिक्स का उपयोग करें। डायरेक्टएक्स, देशी एपीआई, या COM? टेराएफएक्स जैसे बाध्यकारी का प्रयोग करें। सी ++ केवल lib के साथ बातचीत करना? .NET में आपको जो चाहिए, उसे फिर से लागू करें।

.NET C++ के बिना बेहतर है, और C++ .NET के बिना बेहतर है।

मुझे नहीं लगता कि cppwinrt में टेम्प्लेटिंग इतना बुरा है। जो चीज मुझे सबसे ज्यादा परेशान करती है, वह है कोड जेन की जरूरत और इससे पैदा होने वाला भयानक संकलन समय।

@sylveon Easy, उन API के कारण जिन्हें Windows टीम UWP के रूप में उपलब्ध कराने से इनकार करती है और किसी तीसरे पक्ष की बाइंडिंग की गिनती नहीं होती है, हर किसी को एक कानूनी विभाग का आशीर्वाद नहीं मिलता है जो लाइसेंस और भविष्य के समर्थन के मुद्दों पर विचार किए बिना कुछ भी जाने देता है।

बोर्लैंड (अब एम्बरकैडेरो), और क्यूटी कंपनी ने दिखाया है कि यह कैसे करना है, यह माइक्रोसॉफ्ट पर निर्भर है कि वे मंच को कितना प्रासंगिक रखना चाहते हैं।

यह देखने की कोशिश करें कि आप macOS, iOS, Android, ChromeOS GUI में ISO C++ के साथ कितनी दूर जाएंगे।

वैसे भी, यहाँ रुकना, यह व्यर्थ है।

@pjmlp हमारे पास आईएसओ सी ++ की लाखों लाइनों के साथ क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन हैं जो आईओएस/मैकोज़/विंडोज पर ठीक काम करते हैं। जब आप प्रदर्शन और/या बैटरी जीवन की परवाह करते हैं तो C++ उपयोग की जाने वाली एकमात्र भाषा है। सी ++ एक्सटेंशन हमारे लिए अच्छा नहीं है क्योंकि हम कई कंपाइलर्स का उपयोग करते हैं (जो स्पष्ट रूप से एक दूसरे के एक्सटेंशन को लागू नहीं करते हैं)।
हमने पहले सी ++/सीएलआई का इस्तेमाल किया है और यह इतना दर्द है। प्रतिबंध जैसे कि वर्ग के सदस्य केवल कच्चे C++ पॉइंटर्स की अनुमति देते हैं, जिससे स्मार्ट पॉइंटर्स को स्टोर करना मुश्किल हो जाता है। संकलन समय लंबा है (एकल वर्ण परिवर्तन के लिए एमडी मर्ज समय के 5 मिनट की आवश्यकता होती है)।
सी ++ में प्रज्ञा प्रबंधित/अप्रबंधित बदलने के लिए रैपिंग की आवश्यकता शामिल है
सी ++ की तुलना में कंपाइलर सी ++/सीएलआई के लिए एक अलग संस्करण है (और मुझे निर्माण पर बताया गया था कि सी ++/सीएलआई कंपाइलर सी ++ 17 से बाद में समर्थन नहीं करेगा, जो एक समस्या है जब सी ++ का उपयोग करने वाले पुस्तकालयों के शीर्षलेख शामिल हैं 20 विशेषताएं)।
मैं जो कहना चाह रहा हूं वह यह है कि कई प्रतिस्पर्धी प्रयास न करें। मानक के साथ रहें और उसी के साथ काम करें। माइक्रोसॉफ्ट सी ++ समिति पर हैं, वे मानक को आगे बढ़ाने में मदद करते हैं, यह फोकस होना चाहिए, मालिकाना नहीं, एक्सटेंशन में बंद होना चाहिए।

क्या हमारे पास xaml कंपाइलर हो सकता है, जैसे xaml.exe, xaml फ़ाइलों को संकलित करने के लिए, midl.exe, cl.exe, या link.exe के समान? विनुई एप्लिकेशन के लिए ऑटो पाइपलाइन बनाना बहुत उपयोगी होगा।

कभी-कभी, हम विकसित करने के लिए विजुअल स्टूडियो का उपयोग नहीं करना चाहते हैं, हो सकता है कि हम किसी भी संपादक का उपयोग कर रहे हों, लेकिन एक बिल्ड पाइपलाइन को अलग रखें। ऐसा लगता है कि विनुई एप्लिकेशन xaml विशेष हिस्सा है और ऐसा लगता है कि अभी तक इसे संकलित करने के लिए कोई कमांड लाइन टूल नहीं है।

यह cmake जैसे परिदृश्यों के लिए आवश्यक है: https://github.com/microsoft/ProjectReunion/issues/58

क्या हमारे पास xaml कंपाइलर हो सकता है, जैसे xaml.exe, xaml फ़ाइलों को संकलित करने के लिए, midl.exe, cl.exe, या link.exe के समान? विनुई एप्लिकेशन के लिए ऑटो पाइपलाइन बनाना बहुत उपयोगी होगा।

@sammi # 1433 आपकी तलाश के लिए एक

क्या हमारे पास xaml कंपाइलर हो सकता है, जैसे xaml.exe, xaml फ़ाइलों को संकलित करने के लिए, midl.exe, cl.exe, या link.exe के समान? विनुई एप्लिकेशन के लिए ऑटो पाइपलाइन बनाना बहुत उपयोगी होगा।

@sammi # 1433 आपकी तलाश के लिए एक

@jtbrower , यह वही विशेषता है

निश्चित रूप से यह एक पूर्वावलोकन है, और इसका मतलब है कि मुझे ज्यादा उम्मीद नहीं करनी चाहिए, लेकिन WinUI 3 पूर्वावलोकन 2 मेरे लिए निराशाजनक था।

मेरी सबसे बड़ी जरूरत एक्सएएमएल डिजाइनिंग के क्षेत्र में है। मैं इस तथ्य से बहुत चकित था कि एक्सएएमएल डिजाइनर बिल्कुल काम नहीं करता था, और अब तक मुझे कोई स्पष्ट जानकारी नहीं मिली है कि यह कब होगा।

हां, मैं मानता हूं कि विजुअल स्टूडियो में वर्तमान एक्सएएमएल डिजाइनर बहुत धीमा है, और जब कोई रीयलटाइम में चीजों को बदलता है तो यह टूट जाता है जो वास्तव में इसे तोड़ना नहीं चाहिए। उदाहरण के लिए, Height="*" को "Auto" या 100 में बदलना। (त्रुटि विंडो लगभग 10 त्रुटियों को बाहर निकालती है - स्क्विगल्स प्रचुर मात्रा में, और आपको परियोजना का पुनर्निर्माण करना होगा)

स्पष्ट होने के लिए - मैं वास्तव में डिज़ाइनर को डिज़ाइन करने के लिए उपयोग नहीं करता - मैं केवल एक विचार रखना चाहता हूं यदि मेरा लेआउट ऐसा दिखता है जैसे मैंने निर्माण प्रक्रिया के माध्यम से जाने से पहले इसकी कल्पना की थी। यदि आसान हो, यदि डिज़ाइनर केवल "केवल देखें" था, और इसे अपडेट किया गया क्योंकि मैंने एक्सएएमएल (क्रैश किए बिना) को ट्वीक किया था, यह मेरे लिए ठीक होगा, क्योंकि मैं एक्सएएमएल को बदलने के लिए जीयूआई का उपयोग नहीं करता .. या बहुत कम ही . वास्तव में, WindowsCommunityToolkit XAML स्रोत के साथ क्या करता है जो उपयोगकर्ता को स्रोत बदलने और रीयलटाइम में आउटपुट देखने देता है जो मेरे उद्देश्यों के लिए पर्याप्त है।

जो कुछ भी कहा गया है, विनयूआई के पास एक अच्छा विचार है - ओएस से इन सभी "आसान" सामान को अलग करें, और डेवलपर के काम को और अधिक तेज़ी से विकसित होने दें, और हम 1 बीएन उपकरणों को अपग्रेड करने से बचने के लिए ऐप के साथ निर्भरताओं को बंडल कर सकते हैं। ताकि वे हमारे नए महान सामान चला सकें।

मुझे उम्मीद है कि प्रोजेक्ट रीयूनियन भी ऐप कंटेनर से जीयूआई को पूरी तरह से अलग कर देगा। बिना सैंडबॉक्स/सीमाओं वाला UWP जैसा UX एक बेहतरीन कदम होगा।

लेकिन हमारे पास एक एक्सएएमएल डिज़ाइनर कब हो सकता है जो फिर से काम करता है ... कृपया?

मुझे लगता है कि हॉट रीलोड ने ज्यादातर एक्सएएमएल डिजाइनर के "केवल-देखने" उद्देश्य को बहिष्कृत कर दिया है।

लेकिन हम यहां WinUI टूलिंग की बात कर रहे हैं। हॉट रीलोड और लाइव विजुअल ट्री WinUI के लिए भी काम नहीं करते हैं।

व्यू ओनली डिज़ाइनर के साथ मेरा मतलब था "मैं इसके लिए समझौता कर सकता था अगर यह कुछ ऐसा होता जिसे हम आगामी पूर्वावलोकन में डाल सकते थे"

मैं गलत हो सकता था (और अगर मैं हूं तो कृपया मुझे बताएं), लेकिन अभी, WinUI में अपना UI देखने का एकमात्र तरीका इसे बनाना और चलाना है।

लेकिन हम यहां WinUI टूलिंग की बात कर रहे हैं। हॉट रीलोड और लाइव विजुअल ट्री WinUI के लिए भी काम नहीं करते हैं।

व्यू ओनली डिज़ाइनर के साथ मेरा मतलब था "मैं इसके लिए समझौता कर सकता था अगर यह कुछ ऐसा होता जिसे हम आगामी पूर्वावलोकन में डाल सकते थे"

मैं गलत हो सकता था (और अगर मैं हूं तो कृपया मुझे बताएं), लेकिन अभी, WinUI में अपना UI देखने का एकमात्र तरीका इसे बनाना और चलाना है।

अरे @ ericleigh007 क्या आपको हमारी नवीनतम रिलीज़ WinUI 3 पूर्वावलोकन 3 देखने का मौका मिला है? हमने हाल ही में कई टूलिंग सुधार जोड़े हैं जैसे कि IntelliSense, Hot Reload, Live Visual Tree और Live Property Explorer। आप यहां रिलीज नोट्स देख सकते यहां नवीनतम पूर्वावलोकन प्राप्त कर सकते हैं । मुझे आपके विचारों में दिलचस्पी है इसलिए कृपया बेझिझक पहुंचें!

@ जीनरोका दुर्भाग्य से सी ++/सीएक्स विकास अनुभव के साथ पकड़ना उन टूलींग सुधारों में से एक नहीं था। WinUI के लिए बहुत अधिक डेवलपर प्यार की अपेक्षा न करें जब प्रस्तावित C++ टूलिंग 2000 में वापस जाने, नोटपैड में IDL फ़ाइलों को लिखने (बिना किसी संपादक समर्थन के) और मैन्युअल रूप से फ़ाइलों की प्रतिलिपि बनाने जैसा लगता है।

यह मुझे जितना हो सके .NET में रहने देता है, या C++/WinRT में जाने की चेतावनियों के बावजूद बस C++/CX का उपयोग करता रहता है।

अद्यतन के लिए धन्यवाद; आज कोशिश करेंगे, और वापस रिपोर्ट करेंगे। मैं

मेल से भेजा गया https://go.microsoft.com/fwlink/?LinkId=550986 Windows 10 के लिए

से: जीनरोका नोटिफिकेशन @github.com
भेजा गया: बुधवार, नवंबर 18, 2020 पूर्वाह्न 4:41
प्रति: Microsoft/Microsoft-ui-xaml [email protected]
सीसी: एरिक [email protected] ; उल्लेख करें @noreply.github.com
विषय: पुन: [माइक्रोसॉफ्ट/माइक्रोसॉफ्ट-यूआई-एक्सएएमएल] विनयूआई 3.0 डेवलपर अनुभव और टूलिंग - इनपुट की आवश्यकता (#1045)

लेकिन हम यहां WinUI टूलिंग की बात कर रहे हैं। हॉट रीलोड और लाइव विजुअल ट्री WinUI के लिए भी काम नहीं करते हैं।

व्यू ओनली डिज़ाइनर के साथ मेरा मतलब था "मैं इसके लिए समझौता कर सकता था अगर यह कुछ ऐसा होता जिसे हम आगामी पूर्वावलोकन में डाल सकते थे"

मैं गलत हो सकता था (और अगर मैं हूं तो कृपया मुझे बताएं), लेकिन अभी, WinUI में अपना UI देखने का एकमात्र तरीका इसे बनाना और चलाना है।

अरे @ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108daaaaaaa%7c470d%7C84df967471% ज्ञात 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% 3 डी% 7C1000 और sdata = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE% 3 डी और सुरक्षित = 0 और यहाँ नवीनतम पूर्वावलोकन प्राप्त https://eur05.safelinks.protection.outlook.com/?url=https% 3 ए% 2F% 2Fdocs.microsoft.com% 2Fen-हमें% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F और डेटा = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3 डी% 7C1000 और sdata = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc%3D&reserved=0 . मुझे आपके विचारों में दिलचस्पी है इसलिए कृपया बेझिझक पहुंचें!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -+७२,९४,०२,०१२ और डेटा = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3 डी% 7C1000 और sdata = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3 डी और सुरक्षित = 0 , या सदस्यता समाप्त https: //eur05.safelinks.protection.outlook .com /? यूआरएल = https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe लेखन% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ और डेटा = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3 डी% 7C1000 और sdata = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&reserved=0 .

- कोई wysiwyg संपादक/विधि नहीं है जो अभी winui3 c++ (डेस्कटॉप) के साथ काम करती है, है ना?

माइक्रोसॉफ्ट सी ++/सीएक्स उपयोगकर्ताओं को भी अलग करने का प्रबंधन कर रहा है? यह सब कुछ ठीक से आकार नहीं ले रहा है। जिस किसी ने भी इस तकनीक को अपनाया है, माइक्रोसॉफ्ट कुछ साल पहले यूडब्ल्यूपी के लिए जोर दे रहा था कि क्या .net या c++ अब माइक्रोसॉफ्ट के समर्थन के बिना मुश्किल में है।

ऐसा लगता है कि विनयूआई 3 केवल डब्ल्यूपीएफ में लिखे गए डेस्कटॉप ऐप्स के लिए खानपान है - लेकिन वे जल्दी से महसूस करेंगे कि यूडब्ल्यूपी में डब्ल्यूपीएफ की सभी सुविधाएं नहीं हैं और विनयूआई कम सुविधाएं अभी भी कम हैं। हर कोई निराश होने वाला है जो कि WinUI 3 शुरू करने के लिए एक बुरी जगह है।

@robloo यूडब्ल्यूपी की वकालत करने वाले किसी व्यक्ति के रूप में उन्होंने मुझे खो दिया, यह

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

जैसा कि उल्लेख किया गया है कि आईडीएल फाइलों को संपादित करना भी कच्चे नोटपैड का उपयोग करने से अलग नहीं है।

कि हमें .NET में माइक्रोसॉफ्ट के साथ सभी यूडब्ल्यूपी घटकों को उपलब्ध नहीं कराना पड़ा, सी ++/सीएक्स के साथ सी ++/सीएलआई जैसे अनुभव की पेशकश के साथ किसी भी तरह से बेकार था। अब C++/WinRT के साथ हम ATL पर वापस आ गए हैं।

फिर रीयूनियन मुद्दों पर चर्चा और अद्यतन रोडमैप को पढ़कर, यह स्पष्ट है कि उन्हें पाठ्यक्रम को सही करने में कई साल लगेंगे।

डब्ल्यूपीएफ और विन 32 पुराने हो सकते हैं, लेकिन वे यहां हैं और काम करते हैं, बिना एक और पुनर्लेखन और सुविधाओं के नुकसान के।

- कोई wysiwyg संपादक/विधि नहीं है जो अभी winui3 c++ (डेस्कटॉप) के साथ काम करती है, है ना?

XAML डिज़ाइनर काम करता है, लेकिन इसे वास्तव में शुरू करने के लिए wysiwyg संपादन के लिए डिज़ाइन नहीं किया गया था। हॉट रीलोड (जो अब पूर्वावलोकन 3 में काम करता है) बेहतर काम करता है।

लाइव विज़ुअल ट्री और लाइव प्रोप व्यू पूर्वावलोकन 3 में बढ़िया काम करते हैं। डिज़ाइनर कब उपलब्ध होना निर्धारित है?

यह भी देखा कि डेस्कटॉप (WPF) (UWP नहीं) डिज़ाइनर 2.4 (या कुछ और) में काम करता था, लेकिन अब मेरे परीक्षण इसे फिर से काम नहीं करते हैं? क्या मुझे डिजाइनर की वर्तमान स्थिति के साथ कुछ याद आ रहा है?

क्षमा करें मुझे पार्टी में देर हो रही है। @wjk ने इसे अपने पहले बिंदु से

1. MSIX सब ठीक है और अच्छा है, लेकिन मैं अभी भी अधिक जटिल अनुप्रयोगों को स्थापित करने के लिए अच्छे पुराने MSI का उपयोग करता हूं जिनके लिए ऐसी सुविधाओं की आवश्यकता होती है जो MSIX का समर्थन नहीं करती हैं। मैं एमएसआईएक्स का उपयोग करने के लिए भी इच्छुक हूं क्योंकि आवश्यक ऑथेंटिकोड प्रमाणपत्र कितने महंगे हैं।

मैं वास्तव में MSIX के आकर्षण की सराहना करता हूं, लेकिन यह प्रमाण पत्र हस्ताक्षर करने वाला मैंडेट मेरे लिए एक डील ब्रेकर है। मुझे एक उचित SCM- अनुकूल इंस्टॉलर विज़ार्ड की आवश्यकता है जिसका उपयोग मैं एक क्लासिक डेस्कटॉप इंस्टालर अनुभव बनाने के लिए कर सकता हूं। क्यों न MSIX में सुधार किए जाएं और अधिक आधुनिक विकास अनुभव के लिए Microsoft Store और प्रमाणन आवश्यकताओं के बिना MSI इंस्टॉलर का एक नया संस्करण बनाया जाए? वर्तमान रोडमैप में सूचीबद्ध "गैर-MSIX परिनियोजन का समर्थन करता है" सुविधा का शायद यही अर्थ है? यदि ऐसा है, तो मुझे लगता है कि मैं 3.x के इंतजार में फंस गया हूं, जब तक कि कुछ चमत्कार न हो, जो इसे पहले की रिलीज में बदल देता है। इसके लिए तत्पर हैं क्योंकि वीएस इंस्टालर प्रोजेक्ट दुखद रूप से पुराने हैं और स्रोत नियंत्रण के अनुकूल नहीं हैं। मैं

@ चिरामिसु मैं भावना से सहमत हूं, लेकिन मैं भी उलझन में हूं -

@Chiramisu आप की कोशिश की है WiX ? मैं इसे अपने सभी एमएसआई-आधारित इंस्टॉलरों के लिए उपयोग करता हूं, और यह बहुत अच्छी तरह से काम करता है। एक विजुअल स्टूडियो एक्सटेंशन भी है, इसलिए आपके पास वाईएक्स परियोजनाएं हो सकती हैं जो विभिन्न संकलन आदेशों को स्वचालित करती हैं।

@robloo यूडब्ल्यूपी की वकालत करने वाले किसी व्यक्ति के रूप में उन्होंने मुझे खो दिया, यह

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

जैसा कि उल्लेख किया गया है कि आईडीएल फाइलों को संपादित करना भी कच्चे नोटपैड का उपयोग करने से अलग नहीं है।

कि हमें .NET में माइक्रोसॉफ्ट के साथ सभी यूडब्ल्यूपी घटकों को उपलब्ध नहीं कराना पड़ा, सी ++/सीएक्स के साथ सी ++/सीएलआई जैसे अनुभव की पेशकश के साथ किसी भी तरह से बेकार था। अब C++/WinRT के साथ हम ATL पर वापस आ गए हैं।

फिर रीयूनियन मुद्दों पर चर्चा और अद्यतन रोडमैप को पढ़कर, यह स्पष्ट है कि उन्हें पाठ्यक्रम को सही करने में कई साल लगेंगे।

डब्ल्यूपीएफ और विन 32 पुराने हो सकते हैं, लेकिन वे यहां हैं और काम करते हैं, बिना एक और पुनर्लेखन और सुविधाओं के नुकसान के।

बस इसलिए मैं जारी रख सकता हूं, क्या आप मुझे सी ++/विनआरटी के साथ किस आईडीएल संपादन के बारे में बात कर रहे हैं, क्या आप मुझे बता सकते हैं? मैंने co_await और अन्य C++ 17 सिंटैक्स के बारे में जो देखा है, उससे लगता है कि जटिलता C++/CX से बड़ी मात्रा में बढ़ी है।

एमएस? क्या यह संभव नहीं है कि, जब तक कि कोई इसके चारों ओर कुछ वाकई अच्छे रैपर नहीं बनाता, सी ++ 17 क्षमताओं के आधार पर सी ++/विनआरटी बहुत जटिल है और वर्तमान डिजाइनों से बहुत अलग है? सी++/सीएक्स को सी++/विनआरटी को उपयोग करने के लिए उचित रूप से सरल बनाने और माइग्रेट करने के लिए सी ++ 17 के लिए कुछ "उत्कृष्ट रैपर" बनाने के लिए पर्याप्त रूप से आसपास नहीं रखा जा सका?

(अब कोई एक लेख से लिंक करने जा रहा है जो दिखाता है कि यह कैसे किया जाता है, और मैं मूर्खता महसूस करने जा रहा हूं)

@lmcdougald मैंने अभी तक कोशिश नहीं की है। यह ध्यान दिया जाना चाहिए कि मेरा विशेष प्रोजेक्ट अभी भी .NET Framework 3.5 पर है। मैं जानता हूँ मुझे पता है। मुझे अभी तक इसे अपडेट करने की अनुमति नहीं दी गई है, इसलिए मैं इस बात पर अड़ा हुआ हूं कि इस प्राचीन ढांचे के साथ इंस्टालर तकनीक क्या काम करेगी। मैं

@wjk मैंने अतीत में उस पर ध्यान दिया है, लेकिन नहीं, मैंने अभी तक इसकी कोशिश नहीं की है। हालांकि उपरोक्त दिया गया है, यह एकमात्र तकनीक है जो मेरे मौजूदा प्रोजेक्ट के लिए काम कर सकती है, जैसा कि है। क्या आपने इसे किसी पुराने ढांचे के आधार पर WinForms ऐप्स के लिए किसी भी मौके से उपयोग किया है? दुर्भाग्य से मैं अकेला डेवलपर हूं, इसलिए मुझे इस बात पर अत्यधिक पूर्वाग्रह का प्रयोग करना पड़ता है कि मैं अपना समय कैसे व्यतीत करता हूं और नई तकनीकों के साथ प्रयोग करने की स्वतंत्रता नहीं है।

सहृदय निवेदन

@चिरामिसु हां, मूल ट्यूटोरियल से शुरुआत करूंगा। मैं यह भी बताना चाहूंगा कि कैसे पता लगाया जाए कि .NET स्थापित है या नहीं , और वाईएक्स का उपयोग करके फ़ाइलों पर एनजीईएन कैसे

@ चिरामिसु मैं जो खोज रहा हूं

यह ध्यान देने योग्य है कि .NET Framework 3.5 को MSIX में पैक किया जा सकता है। आप वीएस 2019 में पैकेज प्रोजेक्ट के साथ अपने मौजूदा ऐप के लिए एक एमएसआईएक्स पैकेज बना सकते हैं, फिर कुछ हद तक एक लंबे संक्रमण के माध्यम से जा सकते हैं, लेकिन यह बहुत काम है:

WinUI 3.0 कभी भी आधिकारिक तौर पर .NET 3.5 का समर्थन नहीं करेगा, और शायद कभी भी किसी भी संस्करण में .NET Framework का समर्थन नहीं करेगा। मैं आपके मौजूदा पैकेजिंग प्रोजेक्ट को बदले बिना .NET 4.6 (या आदर्श रूप से उच्चतर, 4.8 आदर्श होगा) में अपग्रेड करने का लक्ष्य लेकर आपका आधुनिकीकरण शुरू करूंगा। अगर यह सुचारू रूप से चलता है, तो मैं कार्यक्षमता को एक .NET मानक साझा लाइब्रेरी में बदलना शुरू कर दूंगा जिसे आप अपने अपडेट किए गए .NET 4.6+ ऐप से संदर्भित करते हैं।

एक बार .NET 4.6 ऐप के स्थिर और परीक्षण के बाद, आप इसे अपने MSIX पैकेजिंग प्रोजेक्ट के लिए एक ऑटो अपडेट के रूप में स्वैप कर सकते हैं। .NET मानक चरण के बाद, आप एक प्रोजेक्ट हेड बना सकते हैं जो .NET Core 3.1 (या 5 से लगभग समान कोड का उपयोग करता है, लेकिन मुझे लगता है कि LTS स्थिति शायद आपके संगठन के लिए कुछ मायने रखती है)। फिर से, परीक्षण करें और फिर MSIX को इस संस्करण का उपयोग करने के लिए स्विच करें।

उस समय WinForms से WinUI पर स्विच करना WinUI सीखने और इंटरफ़ेस को फिर से लागू करने का मामला है। दोबारा, एक नया प्रोजेक्ट हेड बनाएं, लागू करें + .NET मानक लाइब्रेरी का संदर्भ लें, परीक्षण करें, फिर इस संस्करण का उपयोग करने के लिए पैकेज को स्विच करें।

इस तरह मैं किसी भी बिंदु पर बेतहाशा भिन्न परियोजनाओं को बनाए बिना आधुनिकीकरण के बारे में बताऊंगा। मैं MSIX पैकेजिंग और .NET 4.6 + .NET मानक चरणों को स्थापित करने को प्राथमिकता दूंगा, क्योंकि वे आपको आधुनिक .NET विकास चक्र से अधिक सहायता उपकरण और कनेक्शन प्रदान करेंगे। जल्दी में .NET 5 पर स्विच करना आपके संगठन के लिए अल्पावधि में एक बुरे विचार की तरह लगता है, क्योंकि इसका जीवनचक्र 1/10वां है जब तक कि .NET 3.5 आसपास रहा है।

बस इसलिए मैं जारी रख सकता हूं, क्या आप मुझे सी ++/विनआरटी के साथ किस आईडीएल संपादन के बारे में बात कर रहे हैं, क्या आप मुझे बता सकते हैं? मैंने co_await और अन्य C++ 17 सिंटैक्स के बारे में जो देखा है, उससे लगता है कि जटिलता C++/CX से बड़ी मात्रा में बढ़ी है।

एमएस? क्या यह संभव नहीं है कि, जब तक कि कोई इसके चारों ओर कुछ वाकई अच्छे रैपर नहीं बनाता, सी ++ 17 क्षमताओं के आधार पर सी ++/विनआरटी बहुत जटिल है और वर्तमान डिजाइनों से बहुत अलग है? सी++/सीएक्स को सी++/विनआरटी को उपयोग करने के लिए उचित रूप से सरल बनाने और माइग्रेट करने के लिए सी ++ 17 के लिए कुछ "उत्कृष्ट रैपर" बनाने के लिए पर्याप्त रूप से आसपास नहीं रखा जा सका?

(अब कोई एक लेख से लिंक करने जा रहा है जो दिखाता है कि यह कैसे किया जाता है, और मैं मूर्खता महसूस करने जा रहा हूं)

चूँकि सामान्य C++ में .winmd फ़ाइल बनाने के लिए आवश्यक प्रकार के मेटाडेटा को निकालने की क्षमता नहीं होती है, इसलिए आपको .hpp और .cpp के शीर्ष पर अपनी WinRT कक्षाओं को .idl फ़ाइल में लिखना होगा।

co_await हर जगह .then([=](Foo^ thing) { }) लिखने की तुलना में बहुत कम जटिल है, यह C# के await सिंटैक्स के समान है।

डिफ़ॉल्ट रनटाइम घटक प्रोजेक्ट से यहां एक उदाहरण (आईडीएल + एचपीपी + सीपीपी) दिया गया है:

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();
    }
}

यहाँ एक छोटा co_wait उदाहरण दिया गया है:

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 Designer बाहर था क्योंकि ग्राहकों की प्रतिक्रिया एकत्र करने के बाद, शीर्ष ग्राहक के दर्द बिंदु डेवलपर के आंतरिक लूप को बेहतर बनाने के बारे में थे। हॉट रीलोड और लाइव विजुअल ट्री शीर्ष पर थे। इन-ऐप-टूलबार शीर्ष पर एक और है कि यह पूर्वावलोकन 3 नहीं बना सका। आप सही हैं कि XAML डिज़ाइनर कब होगा; हमें फीचर रोडमैप विचार को अपडेट करने की आवश्यकता है। वर्तमान इंजीनियरिंग योजना के अनुसार, यह 3.0 RTM से बाहर है, इसलिए यह 3.0 के बाद का है।

@pjmlp मुझे सी ++/

@robloo , हम wpf में लिखे गए डेस्कटॉप ऐप्स के लिए कोई खानपान नहीं कर रहे हैं। C++/WinRT, WinUI पारिस्थितिकी तंत्र में प्रथम-नागरिक है। WinUI लिखने के लिए हम इसका उपयोग करते हैं, इसलिए हम अपने उचित टूल और भाषाओं को डॉगफूड कर रहे हैं।

@ चिरामिसु मुझे समझाएं कि "गैर-एमएसआईएक्स परिनियोजन का समर्थन करता है" का अर्थ क्या है। आज आपको MSIX का उपयोग करके एक डेस्कटॉप WinUI 3 ऐप इंस्टॉल और चलाने की आवश्यकता है। यह क्षमता इस जरूरत को दूर करने के बारे में है। एक डेस्कटॉप विनयूआई 3 ऐप चलाने के लिए, आपको केवल एक .EXE पर दोगुना करना होगा, और बस। अपना ऐप इंस्टॉल करने के लिए, आप बस एक एक्सकॉपी कर सकते हैं (कुछ भी हस्ताक्षर करने की आवश्यकता नहीं है)। मूल रूप से, आप वाईएक्स जैसे अन्य पैकेजिंग और इंस्टॉलेशन सिस्टम का उपयोग करने में सक्षम होंगे।

@marb2000 मुद्दे को स्वीकार करने के लिए धन्यवाद। मुझे और कई अन्य विंडोज डेवलपर्स को यह नहीं मिलता है कि आपने (WinDev प्रबंधन के रूप में) यह फैसला किया है कि यह एक अच्छा विचार है कि हम पर अवर टूलिंग के साथ C++/WinRT को बल दें, यहां तक ​​​​कि MFC में वापस जाना बेहतर लगता है, कम से कम हम हैं फ़ाइलों को मैन्युअल रूप से कॉपी नहीं कर रहा है।

अभी मैं ASP.NET, WFP और Win32 पर ध्यान केंद्रित कर रहा हूँ, बस UWP सामग्री का अनुसरण इस उम्मीद के साथ करते रहें कि Microsoft को अंततः पता चलता है कि हम पुनर्लेखन अनुप्रयोगों से तंग आ चुके हैं और UAP => UWP जैसे मैनुअल कॉन्फ़िगरेशन पर घसीटे जा रहे हैं। संक्रमण, .NET फ्रेमवर्क से .NET कोर, या हाँ C++/CX => C++/WinRT।

यह विंडोज देव समुदाय के एक मुखर सदस्य के रूप में एक फीडबैक चीज से अधिक है, जो विंडोज 8 की शुरुआत के बाद से निरंतर पुनर्लेखन के साथ थोड़ा निराश महसूस करता है।

@pjmlp मुझे यकीन नहीं है कि आप सी ++/

@pjmlp मुझे यकीन नहीं है कि आप सी ++/

विजुअल स्टूडियो में सी ++/सीएक्स के विकास अनुभव बनाम शून्य टूलींग समर्थन बिल्कुल यही समस्या है।

IDL फ़ाइलों के लिए कोई संपादन समर्थन नहीं, सिंटैक्स हाइलाइटिंग भी नहीं, इंटेलीजेंस की तो बात ही छोड़िए। और फिर किसी को जेनरेट की गई अनुवाद इकाइयों को मैन्युअल रूप से कॉपी, या मर्ज करने के लिए कहा जाता है!

यह दिन में वापस एटीएल करने जैसा है।

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

मैं यह देखने में विफल रहा कि कोई भी इसे कैसे प्रगति के रूप में देख सकता है, केवल WinDev लोगों के अलावा जो WRL के एकमात्र उपयोगकर्ता थे।

@pjmlp ,

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

हममें से जो बड़े C++ क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन लिखते हैं, उनके लिए मानकों का अनुपालन करना एक बड़ी बात है। सी ++/सीएक्स के प्रतिबंध भयानक थे (कोई सदस्य चर जो कच्चे पॉइंटर्स, टोपी नहीं हैं! ( ^ ) आदि)। वर्तमान में हमारे पास एक बड़ी सी ++/सीएलआई इंटरऑप लाइब्रेरी है, और दर्द बिंदु सूची में बहुत अधिक हैं।

IDL फ़ाइलों के लिए कोई संपादन समर्थन नहीं, सिंटैक्स हाइलाइटिंग भी नहीं, इंटेलीजेंस की तो बात ही छोड़िए। और फिर किसी को जेनरेट की गई अनुवाद इकाइयों को मैन्युअल रूप से कॉपी, या मर्ज करने के लिए कहा जाता है!

फिर से, आप C++/WinRT और टूलिंग का सामना कर रहे हैं। वे 2 अलग चीजें हैं। C++/WinRT, WinRT API के आसपास एक C++ आवरण है। आईडीएल कोड जनरेशन के लिए है, और हाँ, मैं मानता हूँ कि यह भयानक है, यह इतना बुरा है कि मैं इसका उपयोग नहीं करता।

मैं केवल विंडोज़ ऐप लिखता हूं और मुझे अभी भी मानकों के अनुपालन की परवाह है क्योंकि यह मुझे उन मामलों में एक अलग कंपाइलर का उपयोग करने की अनुमति देता है जहां एमएसवीसी विफल रहता है।

@MarkIngramUK

फिर से, आप C++/WinRT और टूलिंग का सामना कर रहे हैं। वे 2 अलग चीजें हैं। C++/WinRT, WinRT API के आसपास एक C++ आवरण है। आईडीएल कोड जनरेशन के लिए है, और हाँ, मैं मानता हूँ कि यह भयानक है, यह इतना बुरा है कि मैं इसका उपयोग नहीं करता।

मैं एमएस-डॉस 3.3 के बाद से माइक्रोसॉफ्ट प्लेटफॉर्म के लिए कोडिंग कर रहा हूं, 1992 में टर्बो सी ++ 1.0 के साथ अपने टूलबॉक्स में सी ++ जोड़ा, अधिकांश बोर्लैंड और माइक्रोसॉफ्ट उत्पादों का उपयोग सी ++ विकास से संबंधित है। C++/WinRT किस बारे में है, इस पर किसी व्याख्यान की आवश्यकता नहीं है।

यह निश्चित रूप से नहीं है, सी ++ बिल्डर और क्यूटी (क्यूटी डिजाइनर के साथ) डेवलपर अनुभव के लिए एक मैच है, कि सी ++/सीएक्स ने अंततः 25 साल बाद पकड़ने का वादा दिखाया।

लेकिन जाहिर तौर पर यहां ज्यादातर लोग केवल एटीएल 3.0 के साथ विजुअल सी ++ 6.0 चाहते हैं, और हममें से बाकी लोगों को सिर्फ .NET 5, डब्ल्यूपीएफ और विन 32 डेस्कटॉप अनुभव के साथ रहना चाहिए, क्योंकि हम अल्पसंख्यक हैं जो विचार के योग्य नहीं हैं, अन्यथा सी ++/विनआरटी कभी नहीं होगा जिस तरह से धकेला गया था।

ईमानदारी से कहूं तो C++/WinRT अब लगभग 4 साल का हो गया है, और Microsoft सिंटैक्स हाइलाइटिंग और इंटेलिजेंस के लिए भी समर्थन प्रदान करने में सक्षम नहीं था?

कुछ ऐसा जो हममें से कुछ लोगों ने Notepad++ (सिंटैक्स हाइलाइटिंग) में तैयार किया है, सच में?

यह निश्चित रूप से दिखाता है कि प्राथमिकताएं कहां हैं, और ऐसा नहीं है कि WinUI को अपनाया जाएगा, विंडोज 8 के बाद से बहुत से पुनर्लेखन।

@pjmlp , फिर से आप गलत चीजों के बारे में बात कर रहे हैं। सी ++/विनआरटी सिर्फ सी ++ है, इसलिए इसमें सिंटैक्स हाइलाइटिंग है और इसमें इंटेलिजेंस सपोर्ट है। आपके पास कोई अन्य सी ++ कोड जैसा ही है।

आईडीई एकीकरण बेहतर हो सकता है, जैसा कि आपने आईडीएल सिंटैक्स हाइलाइटिंग और आईडीएल से .hpp और .cpp में एक डिफ़ॉल्ट कार्यान्वयन बनाने का सुझाव देने जैसी चीजों का उल्लेख किया है (जैसे कि वर्तमान में हेडर में परिभाषा के बिना घोषित फ़ंक्शन आपको हरे रंग की स्क्वीगल्स के साथ कैसे संकेत देता है एक बनाएं), लेकिन सी ++/सीएक्स पर वापस जाना नेट डाउनग्रेड आईएमओ है। सी ++/सीएक्स के साथ मेरे द्वारा उपयोग किए जाने वाले सभी पुस्तकालयों और साझा कोड को एकीकृत करने के लिए बहुत अधिक प्रयास की आवश्यकता होगी, और मुझे अपनी परियोजना को सी ++ 20 से सी ++ 17 तक डाउनग्रेड करने के लिए मजबूर करना होगा (जिसे मैं छोड़ना नहीं चाहता, 20 मुझे बहुत सी अच्छी चीजें देता है)।

सी ++/विनआरटी सी ++/सीएक्स की तुलना में बहुत कम घुसपैठ कर रहा है जब प्रोग्राम केवल WinRT कक्षाओं का उपभोग करना चाहते हैं, उन्हें लेखक नहीं।

क्यूटी और सी ++ बिल्डर ज्यादातर मानकों के अनुरूप सी ++ में अपना अनुभव प्राप्त करते हैं (ध्यान दें कि क्यूटी में आईडीएल के समान कुछ है, जिसे क्यूटी एमओसी कहा जाता है)। यदि ये कर सकते हैं, तो वी.एस. इसके लिए बस देवदिव में किसी से अधिक प्रेम की आवश्यकता है।

और जैसा कि आपने पहले @sylveon का उल्लेख किया है, हम अन्य

@MarkIngramUK और @sylveon

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

अपने मानक अनुपालन C++/WinRT के साथ मज़े करें।

क्या आप 'कोई खानपान नहीं' टाइपो को ठीक करने के लिए इसे संपादित कर सकते हैं .. मुझे लगता है कि यह 'अब...' होना चाहिए

@pjmlp मुझे लगता है कि मैं बिल्कुल समझता हूं कि आपका क्या मतलब है।

एक साल पहले मैंने अपने यूडब्ल्यूपी सी ++/सीएक्स कोड को सी ++/विनआरटी पर पोर्ट करने का विचार छोड़ दिया था। पोर्टिंग के लिए प्रोत्साहन मेरे यूडब्ल्यूपी ऐप को संकलित करने के लिए क्लैंग का उपयोग करने में सक्षम होना था क्योंकि एमएसवीसी ++ में एक बग है जिसे मैंने लगभग 18 महीने पहले रिपोर्ट किया था लेकिन वे बस फिक्सिंग में दिलचस्पी नहीं लेते हैं।

हालांकि, यह तब पता चला कि विजुअल स्टूडियो क्लैंग का उपयोग करके यूडब्ल्यूपी ऐप्स बनाने का समर्थन नहीं करता है। बढ़िया, इसलिए C++/WinRT का "ISO C++ केवल" लाभ खिड़की से बाहर चला गया। इस तथ्य को जोड़ें कि C++/WinRT पर C++/CX कोड बेस को पोर्ट करना 20 साल पहले की यात्रा करने जैसा है।

मैंने अनिवार्य रूप से अपने Android/iOS ऐप्स को विंडोज़ पर पोर्ट करना छोड़ दिया है। हमारे जैसी छोटी दुकान के लिए यह संभव नहीं है कि वह क्लस्टरफक से निपटे जो कि एंड्रॉइड/आईओएस के लिए विकसित करने के अलावा विंडोज ऐप डेवलपमेंट है।

@MarkIngramUK ऐसा लगता है कि आपको बस यह बात

अब, मेरे शेख़ी के बाद, यहाँ मेरा इनपुट है:

सी++/सीएक्स के साथ विनयूआई 3 का उपयोग करके समर्थन। एक बार सी ++/विनआरटी के लिए टूलिंग उन कंपनियों के लिए स्वीकार्य है जिनके पास अपनी टूलिंग बनाने के लिए संसाधन नहीं हैं, तो सी ++/विनआरटी पर स्विच करना ठीक हो सकता है। अब यह निश्चित रूप से नहीं है।

@pjmlp मुझे लगता है कि मैं बिल्कुल समझता हूं कि आपका क्या मतलब है।

एक साल पहले मैंने अपने यूडब्ल्यूपी सी ++/सीएक्स कोड को सी ++/विनआरटी पर पोर्ट करने का विचार छोड़ दिया था। पोर्टिंग के लिए प्रोत्साहन मेरे यूडब्ल्यूपी ऐप को संकलित करने के लिए क्लैंग का उपयोग करने में सक्षम होना था क्योंकि एमएसवीसी ++ में एक बग है जिसे मैंने लगभग 18 महीने पहले रिपोर्ट किया था लेकिन वे बस फिक्सिंग में दिलचस्पी नहीं लेते हैं।

हालांकि, यह तब पता चला कि विजुअल स्टूडियो क्लैंग का उपयोग करके यूडब्ल्यूपी ऐप्स बनाने का समर्थन नहीं करता है। बढ़िया, इसलिए "ISO C++ केवल" C++/WinRT का लाभ खिड़की से बाहर चला गया। इस तथ्य को जोड़ें कि C++/WinRT पर C++/CX कोड बेस को पोर्ट करना 20 साल पहले की यात्रा करने जैसा है।

मैंने अनिवार्य रूप से अपने Android/iOS ऐप्स को विंडोज़ पर पोर्ट करना छोड़ दिया है। हमारे जैसी छोटी दुकान के लिए यह संभव नहीं है कि वह क्लस्टरफक से निपटे जो कि एंड्रॉइड/आईओएस के लिए विकसित करने के अलावा विंडोज ऐप डेवलपमेंट है।

@MarkIngramUK ऐसा लगता है कि आपको बस यह बात

अब, मेरे शेख़ी के बाद, यहाँ मेरा इनपुट है:

सी++/सीएक्स के साथ विनयूआई 3 का उपयोग करके समर्थन। एक बार सी ++/विनआरटी के लिए टूलिंग उन कंपनियों के लिए स्वीकार्य है जिनके पास अपनी टूलिंग बनाने के लिए संसाधन नहीं हैं, तो सी ++/विनआरटी पर स्विच करना ठीक हो सकता है। अब यह निश्चित रूप से नहीं है।

जिज्ञासा से बाहर, 18 महीने पहले किस बग की सूचना दी गई थी? क्या आपके पास इसका कहीं लिंक है?

हाय मिगुएल,
___एंड्रॉइड के लिए आउटलुक से उत्तर देने के बाद चीजों की भयानक स्थिति को ठीक करने के लिए संपादित किया गया___

मेरे पास एक विचार था जो पूर्वावलोकन और रिलीज़ के लिए आपके लक्ष्यों को स्पष्ट कर सकता है क्योंकि आपने कहा था कि Winrt प्लेटफ़ॉर्म वह है जिसका उपयोग आप WINUI को विकसित करने के लिए कर रहे हैं।

यह आलेख लें, जो आईडीएल लिखने और मैन्युअल रूप से फाइलों की प्रतिलिपि बनाने और इसे संशोधित करने पर एक गुच्छा कहता है, इसलिए यह उस स्थिति से मेल खाता है जिस पर आप टूल में काम कर रहे हैं

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

यदि यहाँ नहीं, तो शायद हम उस पर कहीं और चर्चा कर सकते हैं।

जिस तरह से आपने मुझे एक्सएएमएल डिजाइनर पर विशेष रूप से एक्सएएमएल स्टूडियो जैसे अस्तित्व पर उपकरणों के साथ आश्वस्त किया है। (यदि केवल यह कुछ कोड को पीछे लोड करने में सक्षम था, तो यह सफलतापूर्वक एक्सएएमएल लोड कर सकता है जो IValueConverter ...

जैसा कि मेरी पिछली पोस्ट में उल्लेख किया गया है, सी ++/विनआरटी का सी ++ 17 मानक अनुपालन ज्यादातर मामलों में सी ++/सीएक्स कोड बेस को सी ++/विनआरटी में माइग्रेट करने के लिए कोई प्रोत्साहन नहीं है क्योंकि आपको माइक्रोसॉफ्ट के विजुअल सी ++ कंपाइलर के साथ संकलित करने के लिए मजबूर होना पड़ता है वैसे भी। यदि आप उस कंपाइलर को बंद कर सकते हैं जो पूरी तरह से बदल जाएगा।

लेकिन विजुअल स्टूडियो विंडोज रनटाइम घटकों के लिए कंपाइलर को स्विच आउट करने का समर्थन नहीं करता है। यह मेरे लिए एक रहस्य है कि यह समर्थित क्यों नहीं है, खासकर क्योंकि यह डेस्कटॉप ऐप्स के लिए समर्थित है जैसा कि इस ब्लॉग पोस्ट में बताया गया है। विंडोज रनटाइम घटकों के लिए क्लैंग समर्थन को वास्तव में विस्तारित किया जाना चाहिए।

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

आपके पास सी ++ मानक अनुपालन है, आपके पास डेस्कटॉप ऐप्स के लिए विजुअल स्टूडियो में क्लैंग समर्थन है। तो, कृपया अंतिम चरण करें और विंडोज रनटाइम घटकों के लिए क्लैंग समर्थन प्रदान करके सी ++/सीएक्स से दूर माइग्रेट करने का वास्तविक कारण प्रदान करें।

मानकों का अनुपालन उपभोक्ताओं के लिए उपयोगी है - जैसा कि आप उल्लेख करते हैं कि निर्माता एमएसवीसी से चिपके हुए हैं। .vcxproj फ़ाइल में क्लैंग-सीएल के पथ पर संपत्ति CLToolExe सेट करके क्लैंग-सीएल (जो प्रभावी रूप से एलएलवीएम टूलसेट पहले से ही करता है ) को "बल" देने का एक तरीका है। मुझे यकीन नहीं है कि यूडब्ल्यूपी परियोजनाओं में यह कितना अच्छा काम करता है, लेकिन यह एक कोशिश के लायक है।

एक बार डेस्कटॉप प्रोजेक्ट्स में 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 />
• परियोजना को पुनः लोड करें
• निर्माण

हालांकि इसमें कुछ नुकसान हैं:

• अप्रयुक्त तर्कों के बारे में कुछ चेतावनियाँ सामने आती हैं: आप शायद अप्रयुक्त तर्कों को बदलकर/हटाकर उन्हें ठीक कर सकते हैं।
• किसी कारण से क्लैंग 32 बिट्स में 64-बिट्स ऑब्जेक्ट फ़ाइल का उत्सर्जन करता है, सीएलआई में केवल -m32 जोड़ने की आवश्यकता हो सकती है।
• चूंकि क्लैंग ने अभी तक कोरटाइन को पूरी तरह से लागू नहीं किया है, इसलिए आप उनका उपयोग नहीं कर पाएंगे।
• हर बार जब आप वृद्धिशील और/या समानांतर के बजाय ऐप चलाते हैं तो वीएस एक पूर्ण सिंगल-थ्रेडेड पुनर्निर्माण करता है।

मैं इस पर ध्यान आकर्षित करने के लिए https://github.com/microsoft/ProjectReunion पर एक मुद्दा खोलने का सुझाव दूंगा।

@sylveon इन निर्देशों को पोस्ट करने के लिए बहुत बहुत धन्यवाद। मैं इसे किसी बिंदु पर आज़मा दूंगा लेकिन फिर भी उम्मीद है कि विजुअल स्टूडियो किसी बिंदु पर बॉक्स के बाहर इसका समर्थन करेगा।