अंक सामग्री में आपके द्वारा पूछे गए प्रश्नों पर ये मेरे प्रारंभिक विचार हैं।

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

कौन से टेम्प्लेट में आपकी सबसे अधिक रुचि होगी?

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

इन ऐप्स के "सिल्हूट" की जांच करें और सामान्य UX परिदृश्यों का पता लगाएं।

मेरे सिर के ऊपर से, वहाँ है:

• मुख्य मेनू (सभी ढांचे)
• एमडीआई (एक खिड़की में कई दस्तावेज) (ज्यादातर एमएफसी)
• टैब और डेटाग्रिड (WPF, WinForms, MFC)
• रिबन (Win32 ऐप्स ऑफिस, 3ds मैक्स, पेंट, वर्डपैड, फाइल एक्सप्लोरर आदि)
• सिस्टम ट्रे यूटिलिटीज (एमएफसी, विनफॉर्म)
• ब्राउज़र्स
• विजार्ड्स (डब्ल्यूपीएफ, एमएफसी)
• कॉम्प्लेक्स एमडीआई ऐप्स (एडोब सॉफ्टवेयर, विजुअल स्टूडियो)
• मीडिया प्लेयर
• डेटा विज़ुअलाइज़ेशन एलओबी (डब्ल्यूपीएफ और वेब)
• सामाजिक ऐप्स (रिएक्ट नेटिव, पीडब्ल्यूए - स्काइप, फेसबुक, ट्विटर)

इन सभी या इनमें से कुछ को नोटिफिकेशन/एक्शन सेंटर के साथ WinRT/UWP सिस्टम इंटीग्रेशन से फायदा हो सकता है।

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

मौजूदा wpf और WinForms ऐप्स वाले डेवलपर्स के लिए WinUI 3.0 निर्भरता जोड़ने का एक आसान तरीका भी होना चाहिए जो उन्हें एक सरल स्टेटमेंट या मेनिफेस्ट एंट्री के साथ नए कंट्रोल डिज़ाइन देता है।

एक्सएएमएल द्वीप समूह

जैसे-जैसे Xaml द्वीप संभव बनाना आसान हो जाता है - पुराने वेबव्यू नियंत्रणों, रंग बीनने वालों, XAML आधारित संवादों को बदलना एक नया जोड़ें जितना आसान हो सकता है

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

इनमें से कोई भी परिदृश्य जो वर्तमान में UWP XAML में संभव नहीं है, इन्हें आसान बनाने के लिए नियंत्रण और टेम्प्लेट के साथ होना चाहिए।

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

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

नई परियोजनाओं पर यह डिफ़ॉल्ट होना चाहिए, और विंडोज एसडीके के भविष्य के संस्करणों के साथ स्थापित नगेट पैकेज होना चाहिए।

WinUI 3 के साथ UWP घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

स्वचालित अद्यतन उत्तर के साथ, नए पृष्ठों और परियोजनाओं में इसे डिफ़ॉल्ट रूप से शामिल करना चाहिए, और एक संदेश यह पूछना चाहिए कि क्या वे स्वचालित रूप से WinUI पर जाना चाहते हैं | नाम स्थान अपडेट करने के लिए टूडू टिप्पणियां जोड़ें | विनयूआई पर न जाएं ।

आप किस प्रकार के ऐप्स के लिए WinUI 3.0 का उपयोग करने के लिए सबसे अधिक उत्साहित होंगे?

एक उपयोगकर्ता के रूप में मैं चाहता हूं कि विंडोज़ पर चलने वाले सभी ऐप्स एक सामान्य यूआई और यूएक्स साझा करें, इससे कोई फर्क नहीं पड़ता कि किस ढांचे का उपयोग किया गया था।

मैं चाहता हूं कि रजिस्ट्री के साथ खिलवाड़ किए बिना और कबाड़ को पीछे छोड़े बिना ऐप्स इंस्टॉल किए जाएं। (इसलिए शताब्दी)

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

Fluent UI के साथ C++ MFC ऐप का आधुनिकीकरण?

ऐक्रेलिक WPF, WinForms और MFC ऐप्स के लिए उपलब्ध होना चाहिए, और WinUI 3.0 निर्भरता या मेनिफेस्ट के माध्यम से डिफ़ॉल्ट नए टेम्प्लेट में शामिल होना चाहिए। CommonControls और विंडो शैलियों को ऐक्रेलिक और विस्तारित टाइटलबार का उपयोग करना चाहिए (जिसे वर्तमान डिफ़ॉल्ट पर वापस जाने के लिए ओवरराइड किया जा सकता है)

Microsoft के Win32 गैर UWP ऐप्स को सभी को WinUI 3.0 के साथ पुन: संकलित करने की आवश्यकता है ताकि वे सभी ऐक्रेलिक विंडो फ़्रेम, मुख्य मेनू, थीमशैडो, प्रसंग मेनू , टेक्स्ट फ़ील्ड, प्रगति बार आदि का उपयोग करें।

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

पुन: नामस्थान, मैं उनसे लक्ष्य के आधार पर केवल परिवर्तन की अपेक्षा करता हूं, यहां तक ​​​​कि इसके लिए सशर्त नामस्थान की आवश्यकता होती है।

यहाँ मेरे उत्तर हैं:

एक नया ऐप बनाना

कौन से टेम्प्लेट में आपकी सबसे अधिक रुचि होगी?

• मुझे पहले वहां c++/winRT win32+xaml और .net core+xaml देखना अच्छा लगेगा, UWP टेम्प्लेट दूसरे स्थान पर आ रहे हैं, पैकेज्ड win32 ऐप को टेम्प्लेट के रूप में नहीं आना चाहिए, क्योंकि वर्तमान ऐप पैकेज टेम्प्लेट को वैसे ही काम करना चाहिए जैसे वे पहले से ही करते हैं। win32/.Net ऐप्स।
• अतिरिक्त, मुझे मौजूदा Win32 या .net कोर ऐप एप्लिकेशन में दिखाने के लिए बॉयलर-प्लेट कोड के साथ "नई एक्सएएमएल विंडो" जैसे आइटम टेम्पलेट्स देखना अच्छा लगेगा (उदाहरण: मौजूदा सिस्ट्रे ऐप ए ला डॉकर डेस्कटॉप बनाना, एक दिखाने में सक्षम नई शीर्ष स्तरीय Xaml विंडो)

मौजूदा Win32 ऐप्स में WinUI 3.0 जोड़ना

• गैर-पिछड़े संगतता सटीक कारण है कि मैंने वास्तविक परियोजना पर कभी भी xaml द्वीपों का उपयोग नहीं किया (हालांकि इसे व्यक्तिगत सामग्री पर मनोरंजन के लिए उपयोग किया जाता है)। विंडोज एपीआई से यूआई ढांचे को डिकूप करना, विनयूआई 3.0 रोडमैप के साथ घोषित सबसे बड़ी चीजों में से एक है (गैर-पैकेज्ड/गैर-यूडब्ल्यूपी लक्ष्यीकरण ऐप्स को इसका लाभ उठाने की क्षमता के साथ)

अपने मौजूदा UWP Xaml ऐप को WinUI 3.0 में अपडेट करना

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

इसके अलावा, केवल यह उल्लेख करना चाहते हैं कि यह एक बहुत ही स्वागत योग्य कदम है, और Github पर संपूर्ण UI फ्रेमवर्क का खुला स्रोत होना बहुत बढ़िया है! ऐसा करने के लिए बहुत-बहुत धन्यवाद!

सबसे पहले, यह एक अच्छा कदम है! दुर्भाग्य से मैं इस तथ्य की उपेक्षा नहीं कर सकता कि जिस तरह से Microsoft ने अपने प्लेटफॉर्म पर कुछ अंतिम डेवलपर्स के साथ व्यवहार किया है, उससे मैं थोड़ा आहत महसूस करता हूं। फिलहाल मैं केवल उपभोक्ता-सामना करने वाले ऐप्स के लिए यूडब्ल्यूपी का उपयोग करता हूं क्योंकि:

1. डब्ल्यूपीएफ विनयूआई (सत्यापन, मौजूदा नियंत्रण, आदि) की तुलना में अधिक परिपक्व है, इसलिए उद्यम के लिए डब्ल्यूपीएफ बेहतर फिट है
2. UWP कई डिवाइस श्रेणियों (मोबाइल, टैबलेट, डेस्कटॉप, आदि) के लिए बहुत अच्छा है, यहीं पर उपभोक्ता हैं

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

मुझे लगता है कि उपभोक्ता सामान अब समीकरण का हिस्सा नहीं है, वह जहाज छंटनी "रणनीति" के साथ रवाना हुआ है। तो एंटरप्राइज़ ऐप्स के लिए केवल एक चीज अच्छी हो सकती है।

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

सवालों के जवाब

एक नया ऐप बनाना

कौन से टेम्प्लेट में आपकी सबसे अधिक रुचि होगी?

मुझे यहां .net core/xaml/C# देखना अच्छा लगेगा, क्योंकि मुझे लगता है कि यह सबसे अधिक इस्तेमाल किया जाने वाला भाषा संयोजन उपलब्ध है। लेकिन शायद यहां एक माइग्रेशन टेम्प्लेट बेहतर होगा (जितनी जल्दी हो सके सभी को बोर्ड पर लाने का प्रयास करें, जितना अधिक समय लगेगा, उतना ही दर्दनाक होगा)।

मौजूदा Win32 ऐप्स में WinUI 3.0 जोड़ना

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

क्या आप डेस्कटॉप ऐप्स के आधुनिकीकरण के लिए Xaml द्वीप समूह के बारे में जानते थे?

हां, लेकिन विंडोज 7 पर बहुत सारे ग्राहक हैं (या थे), इसलिए यह एंटरप्राइज़ देवों के लिए एक विकल्प नहीं था। और उपभोक्ताओं के लिए आप वैसे भी यूडब्ल्यूपी का उपयोग कर सकते हैं।

क्या यह विंडोज़ 10 पर विस्तारित पश्च-संगतता Xaml द्वीप समूह को आपके लिए अधिक उपयोगी बनाता है?

यह एक अच्छी शुरुआत है क्योंकि जिस समय यह सामान शिप होता है, यह एंटरप्राइज़ में विंडोज 10 के सभी समर्थित संस्करणों पर काम करेगा।

अपने मौजूदा UWP Xaml ऐप को WinUI 3.0 में अपडेट करना

एमएस के लिए उपभोक्ता ऐप्स खत्म हो गए हैं, एमएस द्वारा किए गए विकल्पों के कारण, इसके लिए और कोई जगह नहीं है। मैं बस इस पूरे विकल्प को छोड़ दूंगा और इसके बारे में भूल जाऊंगा। यह दुखद है क्योंकि मैंने यूडब्ल्यूपी ऐप्स में हजारों घंटे लगाए हैं, लेकिन मुझे लगता है कि हमें इस मौत को कम दर्दनाक बनाने के लिए जल्दी करने की जरूरत है।

पूरी वादा की गई कहानी हमेशा अप-टू-डेट थी, सभी उपकरणों का समर्थन करती है। मुझे लगता है कि हम सभी जानते हैं कि वह वादा किस दिशा में गया।

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

यदि यह सिर्फ नामस्थान है, तो एक खोज/प्रतिस्थापन भी चाल चलनी चाहिए।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

अब महत्वपूर्ण नहीं है, मैं विकास के हजारों घंटे का नुकसान उठाने को तैयार हूं, वैसे भी कोई उपयोगकर्ता नहीं बचा है।

क्या आप UWP Xaml कंट्रोल लाइब्रेरी या WinRT घटकों का निर्माण या उपयोग करते हैं जिन्हें आप ऐप कोड के साथ आसानी से पुन: संकलित और अपडेट नहीं कर सकते हैं?

नहीं।

WinUI 3 के साथ UWP घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

UWP द्वीप समूह (होस्टेड घटकों की तरह)

आम

ऊपर और रोडमैप में उल्लिखित समग्र 3.0 योजना के बारे में आप क्या सोचते हैं? क्या यह आपको अपने नए और मौजूदा विंडोज़ ऐप्स के लिए WinUI का उपयोग करने में सक्षम करेगा?

इसे शायद कुछ परिपक्व होने की आवश्यकता है, लेकिन मैं खुद को उद्यम विकास के लिए 1 - 2 वर्षों में इस सामान का उपयोग करते हुए देखता हूं। माइग्रेट करना कितना कठिन है, इस पर निर्भर करते हुए, हम या तो WinUI या वेब चुनेंगे (यह इस पर निर्भर करता है कि Windows स्वयं "विकसित कैसे होता है")।

आप किस प्रकार के ऐप्स के लिए WinUI 3.0 का उपयोग करने के लिए सबसे अधिक उत्साहित होंगे? एक नया Win32 ऐप बनाना और उसे MSIX के साथ पैक करना? एक डब्ल्यूपीएफ ऐप में नए विचार जोड़ना? Fluent UI के साथ C++ MFC ऐप का आधुनिकीकरण?

शायद सिर्फ एक डब्ल्यूपीएफ ऐप में नए विचार जोड़ना और धीरे-धीरे माइग्रेट करना शुरू करें।

मुझे यह रोडमैप बहुत पसंद है। यूडब्ल्यूपी को इसके बंधनों से मुक्त करने की जरूरत है, और यह ऐसा करने का एक शानदार तरीका है।

अपने मौजूदा UWP Xaml ऐप को WinUI 3.0 में अपडेट करना

यह मेरे नियोक्ता के लिए बहुत महत्वपूर्ण है। हमारे पास स्टोर में एक जटिल UWP डेस्कटॉप ऐप है। Win32 API तक पहुंच प्राप्त करने के लिए हमें अब डेस्कटॉप ब्रिज की आवश्यकता है जो .NET नेटिव द्वारा समर्थित नहीं हैं।

मैं चाहूँगा

• सभी win32 API तक सीधी पहुंच;
• एक सादे पुराने win32 निष्पादन मॉडल का उपयोग करना। मैं कुछ डेस्कटॉप ब्रिज-जैसे सैंडबॉक्सिंग के साथ ठीक हूं (उदाहरण के लिए रजिस्ट्री का वर्चुअलाइजेशन);
• हमारे ऐप को स्टोर (msix) में रखने के लिए जैसा कि अभी है;
• अभी भी WNS (पुश नोटिफिकेशन) का उपयोग करने के लिए;
• UWP से कुछ नए Xaml डेस्कटॉप ऐप प्रकार के लिए एक दर्द रहित अपडेट अनुभव। मुझे कुछ शारीरिक श्रम करने में कोई आपत्ति नहीं है। हो सकता है कि मैं यहां टूलींग पर अच्छे दस्तावेज़ीकरण को प्राथमिकता दूं।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

मौजूदा शैलियों को अभी भी काम करना चाहिए। मैं कुछ मामूली दृश्य परिवर्तनों के साथ रह सकता हूं। लेकिन व्यवहार में बदलाव के साथ नहीं।

क्या आप UWP Xaml कंट्रोल लाइब्रेरी या WinRT घटकों का निर्माण या उपयोग करते हैं जिन्हें आप ऐप कोड के साथ आसानी से पुन: संकलित और अपडेट नहीं कर सकते हैं?

नहीं।

WinUI 3 के साथ UWP घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

यदि उन्हें पुन: संकलित नहीं किया जा सकता है (तृतीय पक्ष): Xaml द्वीप-जैसा दृष्टिकोण। अन्यथा उन्हें आसानी से WinUI 3 में पोर्ट करना संभव होना चाहिए।

आम

आप किस प्रकार के ऐप्स के लिए WinUI 3.0 का उपयोग करने के लिए सबसे अधिक उत्साहित होंगे? एक नया Win32 ऐप बनाना और उसे MSIX के साथ पैक करना? एक डब्ल्यूपीएफ ऐप में नए विचार जोड़ना? Fluent UI के साथ C++ MFC ऐप का आधुनिकीकरण?

• डेस्कटॉप win32 ऐप्स, MSIX के साथ पैक किया गया।
• यूनो क्रॉस प्लेटफॉर्म ऐप्स;)

कृपया _INOTifyDataErrorInfo_ जैसी सामग्री के लिए नए नामस्थानों का परिचय न दें - इसका उपयोग उन मॉडलों को देखने में किया जाना चाहिए जो आमतौर पर क्रॉस-प्लेटफ़ॉर्म होते हैं और WinUI पर निर्भरता नहीं होनी चाहिए। यह परिभाषित किया जाना चाहिए कि इस तरह की अन्य चीजें कहां स्थित हैं (यानी _INOTifyPropertyChanged_ या _INOTifyCollectionChanged)_

मैं सिर्फ यह जानना चाहूंगा कि क्या अंतिम लक्ष्य क्रॉस-प्लेट यूआई स्टैक बनाना है। इसे समझना शायद पूरी तरह से नहीं समझा जा सकता है कि हम वहां कैसे पहुंचते हैं। हालांकि, अगर यह इरादा है ... इस प्रयास की शुरुआत में विन संदर्भों के बिना इसे ब्रांड करना बेहतर होगा। यदि आपने किया तो लंबे समय में यह कम सिरदर्द होगा।

क्या XamlUI या समान के रूप में लेबल करना बेहतर होगा? Microsoft.UI.* नाम स्थान ठीक हैं, बस रेपो को ब्रांड करें और जैसे XamlUI 3.0 या समान।

खोज लेने के लिए धन्यवाद। आगे देखें कि इस स्पेस में क्या आने वाला है :मुस्कान:

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

टीबीएच ने मुझे पिछले बिल्ड पर निराश किया था कि एमएस की यूडब्ल्यूपी या एक्सएएमएल क्रॉस-प्लेटफॉर्म बनाने की कोई योजना नहीं है। ऊनो को भाषण के अलावा कोई आधिकारिक मान्यता नहीं मिली। इससे भी अधिक निराशा, मैं कहूंगा कि दुख हुआ, यह पता लगाना था कि एमएस रिएक्ट नेटिव और एचटीएमएल/जेएस संचालित ढांचे को फिर से (WinJS) को इतना प्यार दे रहा है, जबकि उत्तरदायी .NET स्टैक देवों की उपेक्षा कर रहा है।
मैं MS को आधिकारिक तौर पर Uno की तरह एक क्रॉस-प्लेटफ़ॉर्म UI स्टैक बनाते हुए और सही टूलिंग, टेम्प्लेट और एकीकृत समर्थन प्रदान करते हुए देखना चाहता हूँ।

और बीटीडब्ल्यू, मैं एक्सएफ के साथ एमएस द्वारा इसके अधिग्रहण के बाद से काम कर रहा हूं, और काश इसके पास निम्नलिखित कारणों से एक विकल्प होता: ए। कोई वेब समर्थन नहीं, b. बहुत मोबाइल पक्षपाती, डेस्कटॉप के लिए कोई प्यार नहीं c. डब्ल्यूपीएफ/यूडब्ल्यूपी कंट्रोल-लाइब्रेरी की तुलना में निश्चित रूप से इसकी लाइब्रेरी पदानुक्रम मैला महसूस करती है। एमएस एक्सएएमएल का उपयोग नहीं कर रहा है।
यहाँ सुविधा अनुरोध है जिसे मैंने Microsoft डेवलपर समुदाय पर पोस्ट किया है: .NET UI मानक ।

धन्यवाद आप सब!

हमें एक एक्सएएमएल यूआई की आवश्यकता है जो वेब (असेंबली) पर भी चलता है। कम से कम UWP का एक सबसेट।
क्यों न यूएनओ प्लेटफॉर्म को अपनाया जाए और स्कीयाशर्प का उपयोग करके वेब रेंडरिंग की जाए?
WinUI का वेब समकक्ष सिल्वरलाइट 6 हो सकता है

प्रश्नों के त्वरित उत्तर

कौन से टेम्प्लेट में आपकी सबसे अधिक रुचि होगी?

.NET कोर SDK-शैली प्रोजेक्ट, या कुछ सरल MSVC प्रोजेक्ट स्वरूप।
पुरानी प्रोजेक्ट फ़ाइलें मैन्युअल रूप से संपादित करने के लिए बहुत जटिल हैं, और पुराने और नए प्रोजेक्ट सिस्टम के बीच कई इंटरैक्शन समस्याएं हैं। हमें नई परियोजनाओं के लिए पुरानी परियोजना प्रणाली को पूरी तरह से छोड़ देना चाहिए।

क्या आप डेस्कटॉप ऐप्स के आधुनिकीकरण के लिए Xaml द्वीप समूह के बारे में जानते थे?

नहीं, मैं एक पूर्ण डेटा मॉडल परिवर्तन के साथ अपने आवेदन को फिर से लिख रहा हूं, इसलिए कोई प्रगतिशील माइग्रेशन नहीं है।

क्या यह विंडोज़ 10 पर विस्तारित पश्च-संगतता Xaml द्वीप समूह को आपके लिए अधिक उपयोगी बनाता है?

विंडोज 7 पर अभी भी कई उपयोगकर्ता हैं और Xaml द्वीप मदद नहीं कर सकते हैं।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

नहीं। मेरे सभी घटक स्व-लिखित हैं, या एमयूएक्स और डब्ल्यूसीटीके से हैं, इसलिए मैं एक त्वरित मैनुअल माइग्रेट कर सकता हूं।

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

इतना नहीं, क्योंकि मेरी परियोजना बड़ी नहीं है (~ 20 पृष्ठ और ~ 10 कस्टम नियंत्रण अभी के लिए)।

WinUI 3 के साथ UWP घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

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

आप किस प्रकार के ऐप्स के लिए WinUI 3.0 का उपयोग करने के लिए सबसे अधिक उत्साहित होंगे? एक नया Win32 ऐप बनाना और उसे MSIX के साथ पैक करना? एक डब्ल्यूपीएफ ऐप में नए विचार जोड़ना? Fluent UI के साथ C++ MFC ऐप का आधुनिकीकरण?

एक नया विंडोज 10-ओनली ऐप बनाना और स्टोर के बिना शिप करना।
व्यक्तिगत डेवलपर्स के लिए विश्वसनीय हस्ताक्षर महंगा है, और स्टोर पर अपलोड करना डोमेन-विशिष्ट के लिए लागू नहीं है, न कि दीर्घकालिक अनुप्रयोगों के लिए।

UI प्लेटफ़ॉर्म के लिए मेरा व्यक्तिगत रूप

Xaml टूलचेन

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

x:Bind साथ आने से चीजें और भी खराब हो जाती हैं। सरल परिदृश्यों का उपयोग करना आसान है, लेकिन संपत्ति की पहुंच से अधिक चीजों को करना बहुत जटिल है। उदाहरण के लिए, यह विधि ओवरलोडिंग का समर्थन नहीं करता है, इसलिए मुझे यह जांचने के लिए संकलित करना होगा कि इस बाध्यकारी अभिव्यक्ति के लिए कौन सा अधिभार चुना गया है। मैं एक साधारण स्विच, या "कुछ संपत्ति झूठी होने पर दृश्यमान" रूपांतरण भी नहीं कर सकता, और एक सहायक विधि की आवश्यकता होती है। प्रलेखन इन विस्तृत परिदृश्यों के बारे में कुछ नहीं कहता है, इसलिए मुझे लगता है कि xaml-भाषा-डिज़ाइन चर्चा के लिए एक स्थिति होनी चाहिए, और xaml को गंभीरता से डिज़ाइन की गई भाषा जैसे सी # बनाना चाहिए।

Xaml संपादक का उपयोग करना भी कठिन है। डिज़ाइनर के लिए वास्तविक प्रभाव दिखाने के लिए कुछ कोड निष्पादित करने का प्रयास करना उचित है, लेकिन टेक्स्ट एडिटर को केवल मेटाडेटा के बारे में पता होना चाहिए। स्रोत दृश्य में xaml फ़ाइल खोलना धीमा है क्योंकि यह डिज़ाइनर को सक्रिय कर रहा है, और पूरी तरह से चलने वाले xaml के लिए कुछ इंटरैक्शन अपवादों को फेंक रहा है, जैसे NullReferenceException और Cannot convert __ComObject to some type । यह निर्मित पुस्तकालयों के माध्यम से ProjectReference को छूता है, और निर्भरता पुस्तकालय में गैर-सार्वजनिक-एपीआई क्षेत्र में एक साधारण संपादन, आमतौर पर डेटा मॉडल के कार्यान्वयन के दौरान भी जटिल त्रुटि का परिणाम होता है। तो मुझे लगता है कि एक मेटाडेटा और स्रोत कोड जागरूक होना चाहिए, पूरी तरह से रोसलिन एकीकृत xaml कंपाइलर।

एक बेहतर विंडोिंग मॉडल

सूचना-पूर्ण, राज्य-पूर्ण एप्लिकेशन के लिए नेविगेटिंग मॉडल के बजाय मल्टी-विंडो मॉडल का उपयोग करना नियमित है। वर्तमान में UWP में, ApplicationView का उपयोग करके नई विंडो बनाना दर्दनाक है क्योंकि थ्रेडिंग समस्याएं हैं। नया AppWindow UI थ्रेड साझा करता है, और मैं इसके UI प्रदर्शन के बारे में निश्चित नहीं हूं।

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

डेटा बाइंडिंग इंटरफेस

हम INotifyPropertyChanged लागू करने वाले मॉडल बनाने के लिए बहुत थक गए हैं। मैंने एक एक्सएमएल को विस्तारित संपत्ति एक्सेसर्स में कनवर्ट करने के लिए एक कस्टम एमएसबिल्ड कार्य लिखा है, लेकिन जब संपत्ति बदलती है तो मैं सेटर में कुछ कस्टम करना चाहता हूं तो यह मदद नहीं करता है।

और थ्रेडिंग मुद्दे हैं। मेरा डेटा पूरी तरह से एक पृष्ठभूमि नेटवर्क सर्वर से आता है, इसलिए await लिए संदर्भ कैप्चरिंग मेरी मदद नहीं कर सकता। डब्ल्यूपीएफ और Binding , यह ऐसा ही है क्योंकि Binding थ्रेडिंग को स्वयं हल करता है। x:Bind बदलते समय, मुझे इसे ईवेंट रेज़र के अंदर हल करना होगा, क्योंकि x:Bind सिर्फ कॉलिंग थ्रेड पर काम करता है। चीजें और भी बदतर हो जाती हैं जब मेरे पास एक ही डेटा को छूने वाले कई एप्लिकेशन दृश्य होते हैं, जिसका अर्थ है कि वैश्विक यूआई डिस्पैचर उपलब्ध नहीं है, और एकमात्र समाधान घटना पंजीकरण पर SynchronizationContext.Current कैप्चर कर रहा है। संग्रह के लिए, ItemsSource न तो थ्रेड सुरक्षित है और न ही समान समाधान की आवश्यकता है।

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

IObservableVector<T> एक नकली जेनेरिक प्रकार है जो केवल object का उपयोग कर सकता है, INotifyCollectionChanged गैर सामान्य है। बस इसे अंतर्निहित संग्रह के लिए लागू करें जैसे ObservableCollection<T> पर्याप्त नहीं है, विशेष रूप से जटिल, ISupportIncrementalLoading / IItemsRangeInfo उन्मुख परिदृश्यों के लिए। प्लेटफ़ॉर्म को सर्वोत्तम प्रथाओं के साथ एक डिफ़ॉल्ट अमूर्त कार्यान्वयन प्रदान करना चाहिए, जिससे उपयोगकर्ता केवल एक सार डेटा-भरने की विधि को लागू कर सके।

@shaggygi @weitzhandler @TonyHenrique

यदि UWP/XamlUI3.0 के लिए Windows Renderer से XAML सिंटैक्स को सारगर्भित करने के लिए क्रॉस प्लेटफ़ॉर्म भविष्य होना है, और शेष Windows रनटाइम इसे संभालने का एक तरीका होगा।

यदि परियोजना के साथ लगभग प्लग-इन मानसिकता हो सकती है, तो एआरटी एपीआई को सी # और वीबी, साथ ही मौजूदा सी ++, सी भाषा में पास करने के लिए एंड्रॉइड या आईओएस/ऐपकिट रेंडरर और एंड्रॉइड/आईओएस ऐपकिट शिम हो सकता है। सहयोग।
Xamarin यहाँ मदद कर सकता है।

Microsoft को उन ऑल्ट प्लेटफ़ॉर्म रेंडरर्स पर काम करने वाले होने की आवश्यकता नहीं है।

लेकिन अभी के लिए विंडोज़ पर ध्यान केंद्रित कर रहा है ... विनयूआई 3.0 में फैब्रिक वेब / रिएक्ट नेटिव / डब्ल्यूपीएफ / विनफॉर्म / एमएफसी शामिल हो सकता है। पीडब्लूए ऐप विकास के लिए प्रथम श्रेणी के नागरिक भी होंगे, इसलिए विंडोज़/.नेट/यूडब्ल्यूपी के लिए सीधे नहीं बने ऐप्स के लिए क्रॉस प्लेटफॉर्म कहानियां हैं।

अब जरूरत इस बात की है कि सी#/.नेट/यूडब्ल्यूपी डेवलपर्स को उनके ऐप्स और निवेश को प्लेटफॉर्म के व्यापक परिदृश्य में लाने के लिए एक कहानी प्रदान की जाए।

मेरे 2 सेंट: मैं एक Xamarin हूं। फॉर्म देव, और (कई अन्य लोगों की तरह) सभी एक्सएएमएल बोलियों को मोबाइल स्पेस सहित हर जगह काम करने वाले एक में विलय करने में दिलचस्पी है। निश्चित नहीं है कि यह कैसे घटेगा, लेकिन इस मामले में कम से कम मेरी यही इच्छा है।

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

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

@mdtauk मुझे लगता है कि एक बार जब Xaml प्लेटफॉर्म को वास्तव में ओपन-सोर्स बना दिया जाता है, तो हमें इस बारे में स्पष्ट समझ होगी कि यह स्टैक के नीचे क्या निर्भर करता है (हम पहले से ही जानते हैं कि मुख्य प्लेटफॉर्म-विशिष्ट निर्भरताएं हैं DirectX11, Direct2D और Windows मीडिया फाउंडेशन, लेकिन कौन जानता है कि विंडोज एसडीके का कौन सा हिस्सा वहां उपयोग किया जाता है), और इसे कैसे स्तरित किया जाता है (ताकि हम किसी भी पोर्टिंग की व्यवहार्यता के बारे में वास्तविक महसूस कर सकें)।
साथ ही हमें अभी यह देखना है कि किस तरह के लाइसेंस के तहत सोर्स कोड वितरित किया जाएगा। मुझे यकीन नहीं है कि यह अभी तक तय किया गया है।

एंड्रॉइड वल्कन का उपयोग करता है और मुझे लगता है कि ओपनजीएल का समर्थन करता है
iOS और macOS मेटल का इस्तेमाल करते हैं

मीडिया कोडेक्स के लिए, स्थानापन्न करने के लिए देशी सी आधारित एपीआई का उपयोग करना संभव हो सकता है।

@simonferquel यह तब स्पष्ट हो जाएगा जब कोड को रिफैक्टर किया जाएगा और चेक इन किया जाएगा। और उन प्रयासों का नेतृत्व करने के लिए कुछ आईओएस और एंड्रॉइड विशेषज्ञों की आवश्यकता हो सकती है।

मुझे लगता है कि जब विनुई नियंत्रण का संग्रह था तो नामस्थान बदलना एक उचित दृष्टिकोण था। हालाँकि, अब जब यह मूल रूप से प्लेटफ़ॉर्म को बदल देता है, तो मुझे लगता है कि यह अब उचित नहीं है। यह पहले से ही wpf/Winforms के लिए उसी तरह काम करता है, जहां कोड में नामस्थान बदले बिना कोड को .net Framework से .net कोर में स्थानांतरित किया जा सकता है। सक्षम होने पर प्लेटफ़ॉर्म स्वचालित रूप से आवश्यक dll के winui संस्करणों को लोड करने में सक्षम होना चाहिए। इस तरह, स्रोत और बाइनरी संगतता (मैंने .net कोर ऐप्स में .net फ्रेमवर्क लाइब्रेरी का सफलतापूर्वक उपयोग किया है) को संरक्षित किया जा सकता है।

बस अब तक की टिप्पणियों के लिए सभी को धन्यवाद कहना चाहता था! WinUI टीम सभी प्रतिक्रियाओं और बिंदुओं को ध्यान से देख रही है।
एक बार जब हम अपने विचारों को व्यवस्थित कर लेते हैं, तो हम उन विशिष्ट बिंदुओं के बारे में बात करने के लिए कुछ केंद्रित मुद्दों को अलग कर देंगे (उदाहरण के लिए मौजूदा यूडब्ल्यूपी ढांचे और घटकों के साथ संगतता)।

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

मैं स्पष्ट कर दूं कि मैं देशी यूडब्ल्यूपी और ज़ामरीन फॉर्म्स (एंड्रॉइड, आईओएस) में भारी निवेश कर रहा हूं और मैं प्लेटफॉर्म को पसंद करता हूं, लेकिन एमएस द्वारा रिएक्ट के लिए मूल समर्थन की घोषणा के बाद, मैं जहाज कूदने वाला हूं।

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

उपरोक्त सोच का कारण यह है कि यूडब्ल्यूपी मुझे एस्केप हैच प्रदान नहीं करता है क्योंकि अगर जल्द ही कोई क्रॉस-प्लेटफ़ॉर्म क्षमता नहीं है तो यह आसानी से अगला सिल्वरलाइट शिकार बन सकता है। MS यह सुनिश्चित करने के लिए अपने दांव को हेजिंग कर रहा है कि वे PWA प्रवृत्ति से न चूकें या उनका हाथ विंडोज पर रिएक्ट नेटिव सपोर्ट के लिए दिया जा रहा है। समस्या यह है कि मैंने इस उम्मीद में एक शर्त लगाई थी कि इस समय तक ब्राउज़र या क्रॉस प्लेटफॉर्म में UWP/c#/.net के लिए एक "पथ" होगा और मैं अपने अधिकांश निवेश को उन प्लेटफार्मों में पुन: उपयोग कर सकता हूं।

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

आप कह सकते हैं कि ब्लेज़र है, लेकिन स्पष्ट रूप से इससे पहले कि मैं एक नए प्लेटफॉर्म में अधिक समय लगाऊं, मैं इसके बजाय रिएक्ट सीखूंगा या आप कह सकते हैं कि हमारे पास इस सब के लिए सीमित संसाधन हैं। निश्चित रूप से जब आप Github के लिए $7.5 बिलियन का भुगतान करते हैं तो यह सब सापेक्ष हो जाता है।

मुझे लगता है कि यह महत्वपूर्ण है कि एमएस प्रतिष्ठित नुकसान को समझें कि मौजूदा यूडब्ल्यूपी/विन32 निवेश के लिए प्लेटफॉर्म क्षमता को पार करने के लिए एक असफल माइग्रेशन पथ। क्रॉस प्लेटफॉर्म क्षमता .NET 5 का पर्याय होनी चाहिए और ऐसा नहीं है। मुझे यकीन नहीं है कि इस उदाहरण में मंच पार करने के लिए बेबी कदम एमएस के लिए काम करने जा रहा है और मेरा विश्वास है कि मैं हमेशा xaml/.net/c# का बहुत बड़ा प्रशंसक रहा हूं

कौन से टेम्प्लेट में आपकी सबसे अधिक रुचि होगी?

क्या आपका मतलब प्रोजेक्ट टेम्प्लेट या आइटम टेम्प्लेट से भी है?

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

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

पुन: नई सुविधाओं के लिए पिछड़ा संगतता

क्या क्रिएटर्स अपडेट (15063) के लिए बैकवर्ड संगत होना एक निश्चित संदर्भ बिंदु होगा या क्या आगे की योजना वर्तमान संस्करण और उससे पहले के संस्करणों की एक्स संख्या का समर्थन करने के लिए होगी?

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

पुन:: नामस्थान माइग्रेट करना

क्या मौजूदा यूडब्ल्यूपी को चरणों में माइग्रेट करना संभव होगा (मैं पेज सोच रहा हूं) या क्या पूरे ऐप को एक बार में अपडेट करना आवश्यक होगा? यदि यह एक ही बार में संपूर्ण ऐप है जो गोद लेने को धीमा कर देगा।

डब्ल्यूपीएफ ऐप्स माइग्रेट करने के बारे में क्या? - क्या एक्सएएमएल द्वीप समूह का उपयोग करने के लिए माइग्रेशन रणनीति है जो WinUI 2.x या 3.x का उपयोग कर सकती है? क्या दोनों को एक ही ऐप में इस्तेमाल किया जा सकता है?

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

कृपया UWP के सभी उदाहरणों को उपयुक्त नामों से बदलें, क्योंकि यह स्पष्ट नहीं है कि आप क्या कह रहे हैं।

@mrlacey :

क्या आपका मतलब प्रोजेक्ट टेम्प्लेट या आइटम टेम्प्लेट से भी है?

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

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

अच्छा प्रश्न - किस प्रकार के निर्भरता अद्यतन इसे और अधिक मूल्यवान बना देंगे? उदाहरण के लिए नए संगत NuGet पैकेज संस्करण ढूँढना?

क्या क्रिएटर्स अपडेट (15063) के लिए बैकवर्ड संगत होना एक निश्चित संदर्भ बिंदु होगा या क्या आगे की योजना वर्तमान संस्करण और उससे पहले के संस्करणों की एक्स संख्या का समर्थन करने के लिए होगी?

हम उपयोग के आधार पर समय के साथ बदलने के लिए समर्थन संस्करण श्रेणी की कल्पना करते हैं। विशिष्ट संस्करणों तक सीमित होने के बजाय, हम संभवतः उपयोग डेटा को देखना जारी रखेंगे और सबसे सक्रिय इन-मार्केट विंडोज 10 संस्करणों का समर्थन करेंगे।

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

वर्तमान में हम कस्टम नियंत्रणों के लिए कोई अतिरिक्त आवश्यकता या "प्रमाणन" लागू करने की कल्पना नहीं करते हैं। वर्जनिंग आपके ऊपर होगी। मई 2019 अपडेट, विनयूआई 3.0 और विनयूआई के भविष्य के संस्करणों की समग्र संस्करण कहानी निश्चित रूप से एक ऐसा विषय है जिसे हम जल्द ही और अधिक गहराई में जाना चाहते हैं।

क्या मौजूदा यूडब्ल्यूपी को चरणों में माइग्रेट करना संभव होगा (मैं पेज सोच रहा हूं) या क्या पूरे ऐप को एक बार में अपडेट करना आवश्यक होगा? यदि यह एक ही बार में संपूर्ण ऐप है जो गोद लेने को धीमा कर देगा।

महान प्रश्न - यह ध्यान देने के लिए धन्यवाद। यह भी एक ऐसा विषय है जिस पर हम जल्द ही और गहराई में जाना चाहते हैं।

कृपया UWP के सभी उदाहरणों को उपयुक्त नामों से बदलें, क्योंकि यह स्पष्ट नहीं है कि आप क्या कह रहे हैं।

@riverar : क्या कोई विशिष्ट उपयोग या अनुभाग है जो स्पष्ट नहीं है?

हम " UWP Xaml " शब्द का उपयोग Xaml प्लेटफॉर्म को संदर्भित करने के लिए करते हैं जिसे विंडोज 10 और UWP SDK के हिस्से के रूप में शिप किया जाता है, ताकि इसे अन्य Xaml-आधारित प्लेटफॉर्म (जैसे wpf) से अलग किया जा सके।

हम Win32 ऐप मॉडल से अलग " UWP ऐप मॉडल " (पैकेजिंग और इंस्टालेशन, डेटा और स्टेट मैनेजमेंट, रनटाइम लाइफसाइकिल, आदि) का भी उल्लेख करते हैं।

यहां तक ​​कि विंडोज डेस्कटॉप पर भी यूजर्स वेब ब्राउजिंग में काफी समय लगाते हैं।
मुझे लगता है कि हमें (के सबसेट) UWP vNext XAML + .NET (C#/F#/VB.NET) का उपयोग करके सभ्य वेब ऐप्स विकसित करने का एक तरीका चाहिए

मैंने कई वर्षों तक डब्ल्यूपीएफ + क्लिकऑन में विकसित किया, फिर यूडब्ल्यूपी को देखना शुरू कर दिया। मुझे यूडब्ल्यूपी पसंद है, लेकिन इसे (या अगली क्रिया।) स्टैंडअलोन EXE, बेहतर विंडो एपीआई चलाने में सक्षम होना चाहिए (अगर हम चाहते हैं तो एक कस्टम विनैम्प विंडो स्टाइल ऐप बनाने की अनुमति दें), अधिक प्रिंटिंग एपीआई, सी डीएल के साथ आसान इंटरऑप , OCX, कम से कम घटकों का एक सबसेट वेब पर चलना चाहिए।

जब मैंने UNO को देखा, तो मैंने सोचा: Microsoft इस कंपनी को खरीद सकता है, और इन डेवलपर्स को UWP और Xamarin की टीमों के साथ जोड़ सकता है। मुझे खुशी होगी यदि अगला संस्करण UWP एक Azure चीज़ बन जाए, जो वेब, विंडोज, मोबाइल और IoT पर चलता है। IMO भी Azure पोर्टल UWP vNext में लिखा जा सकता है।

माइक्रोसॉफ्ट कर सकता है। आपने इसे सिल्वरलाइट के साथ किया, आपने डब्ल्यूपीएफ किया, आपने यूडब्ल्यूपी किया, आपने ज़ामरीन किया। अब अंतिम GUI XAML ढांचे का समय है। और, मेरी राय में, वेब को समर्थित होना चाहिए, कम से कम कार्यक्षमता का एक सबसेट।

_INOTifyDataErrorInfo_

कृपया _INOTifyDataErrorInfo_ जैसी सामग्री के लिए नए नामस्थानों का परिचय न दें - इसका उपयोग उन मॉडलों को देखने में किया जाना चाहिए जो आमतौर पर क्रॉस-प्लेटफ़ॉर्म होते हैं और WinUI पर निर्भरता नहीं होनी चाहिए। यह परिभाषित किया जाना चाहिए कि इस तरह की अन्य चीजें कहां स्थित हैं (यानी _INOTifyPropertyChanged_ या _INOTifyCollectionChanged)_

इस विषय के बारे में। Windows.UI.Xaml.Interop में पहले से ही एक INotifyCollectionChanged इंटरफ़ेस है और Windows.UI.Xaml.Data में INotifyPropertyChanged है। इन दोनों को माइक्रोसॉफ्ट नेमस्पेस में ले जाया जाएगा। शायद System.Runtime.WindowsRuntime असेंबली WinUI से .Net पर कुछ मैपिंग कर सकती है

मेरी केवल एक चीज जो मैं जोड़ना चाहता हूं अगर इसे पहले से नहीं जोड़ा गया है, तो मैं 100% MSIX/Appx पैकेज मॉडल का समर्थन करता हूं और Win10 ने उस गंदगी को ठीक करने का शानदार काम किया है जो विंडोज़ के जीवनकाल में स्थापना और हटाने की थी। हालांकि, ऐपकॉन्टेनर सैंडबॉक्स में उपलब्ध एपीआई विकल्पों के अजीब उपसमुच्चय के कारण मुझे हमेशा "यूडब्ल्यूपी" एप्लिकेशन बनाने के लिए संघर्ष करना पड़ा। एक सी ++ डेवलपर के रूप में, यह निराशाजनक था और हर साल आपको पूर्ण Win32 एपीआई सेट की अनुमति देने के लिए सैंडबॉक्स को और अधिक खोलने से राहत मिली है।

तो अगर WinUI 3.0 मुझे Win32 स्टैक के 100% तक पहुंच के साथ एक ऐप बनाने देता है, तो यह सुनहरा होगा! मैंने अभी XamlIslands का उपयोग करने की कोशिश की है, और यह एक शानदार एस्केप हैच है, लेकिन यह मेरे लिए अस्थिर रहा है और इसे वास्तव में फिनिश लाइन के पार करने से पहले कुछ काम बचा है।

प्रोजेक्ट टेम्प्लेट प्राप्त करना जो मुझे ऐपकंटेनर प्रक्रिया के अंदर भरे बिना Win32 ऐप बनाने देता है, और मुझे आपके द्वारा UI के साथ की गई सभी प्रगति तक पहुंचने देता है, तो WinUI 3 मेरे लिए एकदम फिट होगा।

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

हैलो माइक्रोसॉफ्ट,

मुझे नहीं पता कि यह पोस्ट Font Rendering , ClearType , DirectWrite और Windows UI के भविष्य के विषय को कितना प्रभावित करेगी, लेकिन मैं उन छोटे लेकिन मुखर और भावुक लोगों में से एक हूं, जिन्हें फॉन्ट रेंडरिंग सबसिस्टम के साथ कुछ गंभीर शिकायतें हैं। खिड़कियाँ।

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

मैं यहां इस बात पर चर्चा करने के लिए नहीं हूं कि एक दूसरे से बेहतर है या नहीं। न ही मैं यहां रजिस्ट्री हैक्स, 'फ़ॉन्ट ट्यूनर', या फोंट को बेहतर बनाने के लिए ओएस सेटिंग्स को कैसे बदल सकता हूं, इस पर चर्चा करने के लिए हूं। मेरा विश्वास करो, मैंने यह सब किया है; यहां तक ​​​​कि कर्नेल मोड में DirectWrite फ़ंक्शन को पैच करने के लिए कर्नेल मोड ड्राइवर लिखने के लिए अनुसंधान करने के लिए भी जा रहा है।

मैं यहां इसलिए हूं क्योंकि मेरे पास एक बहुत ही सामान्य ऑप्टिक चिकित्सा स्थिति है जिसे मायोपिया / निकट दृष्टिदोष कहा जाता है। मैं चीजों को करीब से साफ देख सकता हूं। लेकिन सिर्फ हथियारों की दूरी पर, मेरी दृष्टि मेरी दृश्य तीक्ष्णता के किनारे पर है और जहां पाठ धुंधला होने लगता है।

हथियारों की दूरी से परे, मुझे सुधारात्मक लेंस पहनने की जरूरत है। :चश्मा: मुझे यकीन है कि हम सभी जानते हैं, डेस्कटॉप कंप्यूटर स्क्रीन लगभग हथियारों की दूरी पर हैं। इसलिए समस्या है।

• फ़ॉन्ट जो चिकने दिखते हैं, मुझे धुंधले लगते हैं।
• नुकीले किनारों वाले (स्नैप्ड-टू-पिक्सेल) फ़ॉन्ट मुझे अधिक स्पष्ट दिखाई देते हैं।

जब फोंट स्नैप-टू-पिक्सेल होते हैं, तो तेज किनारे मेरे मस्तिष्क के लिए एक दृश्य संकेत होते हैं कि मेरी दृष्टि स्पष्ट और फोकस में है । हालाँकि, जब मेरा सामना फ़ॉन्ट-चिकना पाठ से होता है, तो वह दृश्य संकेत मेरे मस्तिष्क को यह सोचने के लिए चकरा देता है कि मेरी दृष्टि फ़ोकस से बाहर है।

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

इस फ़ॉन्ट-चिकनाई समस्या को स्पष्ट करने के लिए, आइए विंडोज 7 पर services.msc MMC स्नैप-इन देखें:

क्या आपको कोई धुंधला टेक्स्ट दिखाई देता है जो फोकस से बाहर दिखता है? यहां। आइए थोड़ा और करीब से देखें...

अच्छाई, कृपालु ऐसा लगता है कि मैं ऑटोस्टेरियोग्राम में क्रॉस-आइड टेक्स्ट को देख रहा हूं।

यह पता चला है, इस विशिष्ट मामले में, इस विंडो के नियंत्रण पदानुक्रम के माध्यम से खुदाई करते हुए, MMC स्नैप-इन एक इंटरनेट एक्सप्लोरर DHTML/ActiveX नियंत्रण को होस्ट करता है जो "इसका विवरण देखने के लिए एक आइटम का चयन करें" पैनल में अस्पष्ट पाठ प्रदान कर रहा है। शार्प (स्नैप्ड-टू-पिक्सेल), "सहायता" मेनू और सेवाओं की सूची सामान्य USER32 और GDI32 आदिम के साथ प्रदान की जाती है।

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

मेरे जैसे उपयोगकर्ताओं के लिए समस्या और भी बदतर हो जाती है क्योंकि जैसे-जैसे समय बीतता है, विंडोज 8 और विंडोज 10 का जन्म, मेट्रो ऐप, डब्ल्यूपीएफ और यूडब्ल्यूपी सभी ने IE9+ के समान दृष्टिकोण अपनाया है। हुड के तहत ये सभी UI प्रौद्योगिकियां वैश्विक ऑपरेटिंग-सिस्टम व्यापक सेटिंग्स को अनदेखा करती हैं जिनका हमारी मशीनों पर सम्मान किया जाना चाहिए। यदि हम ऑपरेटिंग सिस्टम-व्यापी स्तर पर ClearType और फ़ॉन्ट-स्मूथिंग को अक्षम करते हैं, तो हम उम्मीद करते हैं कि ClearType और DirectWrite API (और फलस्वरूप, मेट्रो, WPF और UWP ऐप्स) किसी भी फ़ॉन्ट-स्मूथिंग के साथ आकर्षित न हों।

मुझे पता है कि इस समस्या से मैं अकेला नहीं हूं।

कुछ समय पहले, Google Chrome ने अपने v31 रिलीज़ के साथ भी ऐसा ही किया था और IE9+ दृष्टिकोण का अनुसरण करने का प्रयास किया था और वैश्विक सिस्टम-व्यापी सेटिंग्स को अनदेखा करते हुए सभी फ़ॉन्ट रेंडरिंग को DirectWrite पर स्विच कर दिया था। इस बदलाव ने इंटरनेट को गुस्से में डाल दिया है। क्रोमियम अंक 319429 देखें। अंत में, दांतों को बहुत मसलने के बाद, Google ने पाठ्यक्रम को उलट दिया और क्रोम 37 में उन उपयोगकर्ताओं के लिए समस्या को ठीक कर दिया, जो मायोपिक दृश्य हानि के साथ थे और अब ऑपरेटिंग सिस्टम-वाइड सेटिंग का सम्मान करते हैं जो फ़ॉन्ट-स्मूथिंग को अक्षम करता है।

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

मैं यहां केवल इस बात की वकालत करने के लिए हूं कि Microsoft को एक वैश्विक सेटिंग की आवश्यकता है , जिसे ऑपरेटिंग सिस्टम पर सभी ऐप्स के लिए, सभी UI स्टैक में , दृश्य तीक्ष्णता के मुद्दों वाले लोगों के लिए सम्मान की आवश्यकता है ।

और एक अनुकूल अनुस्मारक के रूप में, यह सामान्य रूप से विंडोज यूआई के लिए एक एक्सेसिबिलिटी समस्या है , न कि दृश्य वरीयता में से एक।

मायोपिया के विश्वव्यापी प्रसार के आधार पर, यह अनुमान लगाया जा सकता है कि वर्तमान विश्व जनसंख्या का 22% से अधिक, यानी 1.5 बिलियन लोग मायोपिक हैं। https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

धन्यवाद,
ब्रायन

:walking_man: :walking_woman: लापता व्यक्ति - LA में घूमना

इसका मतलब है कि पूरा Xaml ढांचा GitHub पर विकसित किया जाएगा और NuGet पैकेज के रूप में बैंड से बाहर भेज दिया जाएगा।

NuGet बहुत अच्छा है, लेकिन vcpkg (और CMake ) का समर्थन करने की भी सराहना की जाएगी (हममें से उन लोगों के लिए जिनके पास बड़े, मौजूदा क्रॉस प्लेटफॉर्म लाइब्रेरी हैं)।

कौन से टेम्प्लेट में आपको सबसे अधिक रुचि होगी?

वरीयता क्रम में:
Win32 + Xaml डेस्कटॉप + विनयूआई
Win32 + Xaml द्वीप + WinUI
यूडब्ल्यूपी + विनयूआई

क्या आप डेस्कटॉप ऐप्स के आधुनिकीकरण के लिए Xaml द्वीप समूह के बारे में जानते थे?क्या यह विंडोज़ 10 पर विस्तारित पश्च-संगतता Xaml द्वीप समूह को आपके लिए अधिक उपयोगी बनाता है?

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

WinUI में Xaml, कंपोजिशन और इनपुट एपीआई के लिए रूट नेमस्पेस विंडोज यूडब्ल्यूपी एसडीके रूट नेमस्पेस से अलग होगा:

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

यह मुझे प्रभावित नहीं करता है, क्योंकि हमारे पास यूडब्ल्यूपी ऐप नहीं है (वर्तमान में प्रत्यक्ष बिक्री के लिए डब्ल्यूपीएफ और स्टोर के लिए डब्ल्यूपीएफ + डेस्कटॉप ब्रिज का उपयोग करें), लेकिन नामस्थान बदलना एक बार की बात है, और यहां तक ​​​​कि सबसे बड़े कोड बेस में भी, Windows::UI::Xaml लिए एक वैश्विक खोज और प्रतिस्थापन यह कठिन नहीं है (हम सभी संस्करण नियंत्रण का सही उपयोग कर रहे हैं ..?)।

WinUI 3.0 जारी करने का सबसे तेज़ तरीका मिश्रण का समर्थन नहीं करना होगा:

यह मेरे साथ ठीक है, उन्हें अलग असंगत पुस्तकालयों के रूप में माना जाना चाहिए। आप या तो UWP Xaml, या WinUI Xaml को लक्षित करते हैं। जैसा कि ऊपर उल्लेख किया गया है, एक बार का रूपांतरण उतना कठिन नहीं होना चाहिए।

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

माइक्रोसॉफ्ट को एक तकनीक चुनने और उसके साथ रहने की जरूरत है। वर्षों से हमें नवीनतम और महानतम डेस्कटॉप UI फ्रेमवर्क (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml, और अब WinUI Xaml) का वादा किया गया है। जबकि चुनाव बढ़िया है, यह कार्यक्षमता और डेवलपर ज्ञान के विखंडन की ओर जाता है। विंडोज़ में एक सुविधा को लागू करने पर एक सत्र/एक वेबपृष्ठ/एक स्टैक ओवरफ्लो उत्तर देना बहुत आसान है, तकनीक के आधार पर 7 अलग-अलग बनाम। यदि WinUI Xaml भविष्य है, तो इसका लाभ उठाने के लिए समुदाय टूलकिट को अद्यतन करने की आवश्यकता है।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

मैं यूडब्ल्यूपी एक्सएएमएल के साथ कुछ भी करना बंद कर रहा हूं क्योंकि कार्यक्षमता वहां नहीं है (Win32/WPF की तुलना में), और मुझे लगता है कि मैं उस संबंध में अकेला नहीं हूं। जैसे, पूर्ण संगतता कोई समस्या नहीं है।

क्या आप UWP Xaml कंट्रोल लाइब्रेरी या WinRT घटकों का निर्माण या उपयोग करते हैं जिन्हें आप ऐप कोड के साथ आसानी से पुन: संकलित और अपडेट नहीं कर सकते हैं?

नहीं।

WinUI 3 के साथ UWP Xaml घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

एन/ए

1. ऊपर और रोडमैप में उल्लिखित समग्र 3.0 योजना के बारे में आप क्या सोचते हैं? क्या यह आपको अपने नए और मौजूदा विंडोज़ ऐप्स के लिए WinUI का उपयोग करने में सक्षम करेगा?

रोडमैप में Xaml Desktop का कोई उल्लेख नहीं है। क्या यह विनयूआई के दायरे में आता है?
मैंने पहले//बिल्ड/ पर लोगों से इसका उल्लेख किया है, लेकिन पहले यूडब्ल्यूपी एक्सएएमएल को अपनाने का कारण यह नहीं है कि मौजूदा सी ++ पुस्तकालयों का उपयोग करने वाले एप्लिकेशन को बनाना असंभव था। उदाहरण के लिए, जब कोई उपयोगकर्ता FileOpenPicker के साथ एक फ़ाइल चुनता है, तो परिणाम IStorageFile के रूप में वितरित किया जाता है, और इसे खोलने के लिए मौजूदा तृतीय पक्ष लाइब्रेरी में पास करने का कोई तरीका नहीं है (उदाहरण के लिए libpng , libjpeg , आदि)। यही कारण है कि हमें wpf के साथ रहना पड़ा है, इसलिए यदि Xaml Desktop या Win32 + Xaml Islands हमें इन प्रतिबंधों के बिना जीने की अनुमति देता है, तो हाँ, यह हमें नए एप्लिकेशन के लिए WinUI का उपयोग करने में सक्षम करेगा।

1. आप किस प्रकार के ऐप्स के लिए WinUI 3.0 का उपयोग करने के लिए सबसे अधिक उत्साहित होंगे? एक नया Win32 ऐप बनाना और उसे MSIX के साथ

WinUI (और MSIX के साथ पैकेजिंग) के साथ एक नया Win32 ऐप बनाना।

यदि आपके कोई प्रश्न हैं, तो कृपया मुझे बताएं, मुझे आगे चर्चा करने में प्रसन्नता हो रही है।

असल में उम्मीद है कि डब्ल्यूपीएफ/विनफॉर्म से कॉम्पैक्ट ओवरले को कॉल करने का कोई तरीका है।
हमें एंड्रॉइड में "अन्य ऐप्स अनुमति पर ड्रा करें" जैसी व्यवस्थापक अनुमति प्रणाली की आवश्यकता है।

आशा है कि यह ऐप मॉडल + पैकेजिंग (UWP + AppX, Win32 + MSIX) इसकी अनुमति देता है (सैंडबॉक्स के अंदर पूर्ण अमूर्तता)

क्या विंडोज़ को सर्वोत्तम सुरक्षा के साथ सबसे उन्नत और असीमित संभावनाएं नहीं माना जाता है?
सुरक्षा के लिए अपंग सुविधा द्वारा नहीं।

रोडमैप के संबंध में इनपुट के लिए समुदाय को खोलने के लिए धन्यवाद।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

वर्तमान में, हमारे पास अभी एंटरप्राइज़ क्लाइंट्स के लिए काफी संख्या में UWP ऐप्स उपयोग में हैं, और मुझे आशा है कि माइग्रेशन पथ इतना कठिन नहीं होगा। यदि परिवर्तनकारी परिवर्तन हो रहे हैं तो .Net Framework से .Net Core समान माइग्रेशन टूल का होना बहुत अच्छा होगा जो यह उत्पन्न करता है कि हमारा माइग्रेशन पथ कितना अनुकूल होगा, इसे किसी भी चीज़ की रिपोर्ट करनी चाहिए जिसे बदलने की आवश्यकता हो सकती है ( उदाहरण के लिए एपीआई जिन्हें बहिष्कृत किया जा सकता है या अलग तरह से व्यवहार किया जा सकता है) और यदि संभव हो तो नामस्थान को स्वचालित रूप से बदलने का विकल्प। इस तरह UWP के लिए WInUI के लिए माइग्रेशन पथ हमारे लिए उद्यम देवों के लिए उतना अस्थिर नहीं होगा।

क्या आप डेस्कटॉप ऐप्स के आधुनिकीकरण के लिए Xaml द्वीप समूह के बारे में जानते थे?
क्या यह विंडोज़ 10 पर विस्तारित पश्च-संगतता Xaml द्वीप समूह को आपके लिए अधिक उपयोगी बनाता है?

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

ऊपर और रोडमैप में उल्लिखित समग्र 3.0 योजना के बारे में आप क्या सोचते हैं? क्या यह आपको अपने नए और मौजूदा विंडोज़ ऐप्स के लिए WinUI का उपयोग करने में सक्षम करेगा?

डेस्कटॉप टीम पहले से ही WinUI 3 की खबर के लिए उत्साहित है, लेकिन जैसा कि ऊपर कहा गया है कि अगर रास्ता इतना आसान नहीं है तो हमारे सभी UWP ऐप्स के माइग्रेशन को इसमें डर लगता है।

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

यह भी जोड़ें कि WinUI 3 के साथ XAML बोली में भी सुधार होना चाहिए, हो सकता है कि पुराने ऐप्स के लिए पश्च संगतता बनाए रखने के लिए XAML के किस संस्करण का उपयोग किया जा रहा है, यह निर्दिष्ट करने के लिए एक संस्करण नामस्थान / Doctype पेश करें। एक्सएएमएल को कम वर्बोज़ बनाने या कुछ बॉयलरप्लेट को बाहर निकालने के लिए बहुत कुछ किया जाना है, जैसे कि एक साधारण संपत्ति विशेषता होने के बजाय निजी सेटर्स का समर्थन करने के साथ INotifyPropertyChanged लिखना है और NotifyPropertyChangedAttribute कहें और घटकों को बनाने को आसान बनाने के लिए कस्टम नियंत्रणों के लिए रनटाइम ओवरहेड या DependencyProperties से बचने के लिए चरण का निर्माण करें। हो सकता है कि रेजर टीम में उनके कुछ अच्छे हिस्सों के लिए कुछ सुधार भी हों।

ये अनुरोध व्यवहार्य हो सकते हैं या नहीं भी हो सकते हैं, लेकिन मैं एक्सएएमएल से प्यार करता हूं और इसमें सुधार जारी रखना पसंद करूंगा, इसलिए मैं कुछ दर्द बिंदुओं (लेकिन अभी भी सेवा योग्य) बताऊंगा जो मैंने और हमारी टीम के कुछ लोगों ने उनके लिए विकसित किए थे।

@mdtauk मैं फ़ाइल सुरक्षा का विरोध नहीं कर रहा हूं, लेकिन अंतर्निहित कर्नेल को आपको उन जगहों पर लिखने से रोकना चाहिए

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

@MarkIngramUK आपकी टिप्पणियों के लिए धन्यवाद, बस एक स्पष्टीकरण। Xaml डेस्कटॉप कॉन्सेप्ट जिसे // Build 2019 में एक स्नीक पीक में प्रस्तुत किया गया था, उसका नाम बदलकर WinUI डेस्कटॉप कर दिया गया है। यह नया विजुअल स्टूडियो प्रोजेक्ट एक Win32 ऐप मॉडल का उपयोग करेगा, जिसमें WinUI प्रस्तुति ढांचे के रूप में होगा, और यह मूल या प्रबंधित हो सकता है (.NET Core 3 का उपयोग करके)।

धन्यवाद @ marb2000 - क्या यह WinUI 3.0 समय सीमा के भीतर है?

WinUI डेस्कटॉप द्वारा @ marb2000 , आपका मतलब Xaml द्वीप वाले Win32 ऐप्स से है? यह किस निर्माण सत्र में दिखाया गया था?

WinUI टीम को एक बात पर ध्यान देना चाहिए कि WinUI 3.0 का नाम बदलें: यदि आप .NET में प्रक्षेपित किसी भी प्रकार का नाम बदलते हैं, तो अनुमान काम नहीं करेंगे (और हम इसे और जोड़ने की योजना नहीं बना रहे हैं क्योंकि यह नहीं है एक रखरखाव योग्य एक्स्टेंसिबल सिस्टम)। यहां उन प्रकारों की सूची दी गई है जिन्हें हम प्रोजेक्ट करते हैं: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

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

INotifyDataErrorInfo

कृपया INotifyDataErrorInfo जैसी सामग्री के लिए नए नामस्थानों का परिचय न दें - इसका उपयोग उन मॉडलों को देखने में किया जाना चाहिए जो आमतौर पर क्रॉस-प्लेटफ़ॉर्म होते हैं और WinUI पर निर्भरता नहीं होनी चाहिए। यह परिभाषित किया जाना चाहिए कि इस तरह की अन्य चीजें कहां स्थित हैं (यानी INotifyPropertyChanged या INotifyCollectionChanged)

इस विषय के बारे में। Windows.UI.Xaml.Interop में पहले से ही एक INotifyCollectionChanged इंटरफ़ेस है और Windows.UI.Xaml.Data में INotifyPropertyChanged है। इन दोनों को माइक्रोसॉफ्ट नेमस्पेस में ले जाया जाएगा। शायद System.Runtime.WindowsRuntime असेंबली WinUI से .Net पर कुछ मैपिंग कर सकती है

उत्तर के लिए धन्यवाद, लेकिन आपको माइक्रोसॉफ्ट नेमस्पेस में इसकी आवश्यकता क्यों है यदि .NET मानक में यह System.ComponentModel पहले से है? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@ मीर-प्लेटिंस्की। NET केवल एक ढांचा है जिसका उपयोग आप UWP XAML के साथ ऐप्स बनाने के लिए कर सकते हैं। वे चाहते हैं कि टेक्स्ट फ़ील्ड सत्यापन देवों के लिए उपलब्ध हो, चाहे वे किसी भी ढांचे का उपयोग करें

@mdtauk , नहीं, WinUI डेस्कटॉप (पहले Xaml डेस्कटॉप) आपको द्वीप के उपयोग के बिना सीधे Win32 के साथ Xaml का उपयोग करने की अनुमति देता है।

@ marb2000 यह बहुत अच्छा होगा यदि एप्लिकेशन पैकेजिंग प्रोजेक्ट ने आपको Win32 विंडो के साथ एक AppX बनाने की अनुमति दी और WinRT घटकों को उसी आसान तरीके से शामिल किया जैसे UWP प्रोजेक्ट करता है। ऐसी बहुत सी चीजें हैं जो vcxproj फ़ाइलों को मैन्युअल रूप से संपादित किए बिना काम नहीं करती हैं जैसे संसाधन जोड़ना और cppwinrt कंपाइलर शामिल किए गए WinRT घटकों से हेडर उत्पन्न करना।

एक अन्य परियोजना जो इस नए UI के लिए महत्वपूर्ण है, वह है साइमन क्रॉप द्वारा _PropertyChanged.Fody_ जो स्वचालित कार्यान्वयन INotifyPropertyChanged (मैंने C# / F# के साथ प्रयास किया) की अनुमति देता है। देखें https://github.com/Fody/PropertyChanged

यह इस तरह एक साधारण कोड की अनुमति देता है:

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

    public event PropertyChangedEventHandler PropertyChanged;
}

जिसका उपयोग हम UI से बाइंड करने के लिए कर सकते हैं।

एक चीज जो मैं WinUI 3.0 में देखना चाहता हूं: वर्तमान में, UWP XAML कंपाइलर ( genxbf.dll ) केवल MSBuild द्वारा सीधे लागू किया जा सकता है जब एक csproj, vbproj, या vcxproj फ़ाइल से संदर्भित किया जाता है। ऐसा इसलिए है क्योंकि कोई कमांड-लाइन टूल नहीं है जिसका उपयोग इस कार्यक्षमता को लागू करने के लिए किया जा सकता है। यह मुझे एक बहुत ही अजीब निर्णय के रूप में प्रभावित करता है, क्योंकि विंडोज 10 एसडीके डाउनलोड में विजुअल स्टूडियो की आवश्यकता नहीं है। (डब्लूडीके ऐड-ऑन में विजुअल स्टूडियो लक्ष्य भी शामिल हैं, लेकिन वे लक्ष्य सभी कमांड-लाइन टूल्स का आह्वान करते हैं जो वीएस से स्वतंत्र रूप से प्रयोग योग्य हैं।) मैं इसके अतिरिक्त की सराहना करता हूं उदाहरण के लिए XbfCompiler.exe और XbfCodeGen.exe एसडीके की बिन निर्देशिका में। (पूर्व EXE एक्सएएमएल फाइलों को एक्सबीएफ फाइलों में संकलित करेगा, और बाद वाला कोड-बैक फाइलें उत्पन्न करेगा जो कोड से एक्सएएमएल प्रकारों को संदर्भित करने के लिए आवश्यक हैं।) यह मुख्य रूप से सी ++ परियोजनाओं में उपयोगी होगा जो सीएमके या अन्य, गैर-विजुअल का उपयोग करते हैं स्टूडियो बिल्ड टूल, लेकिन यदि आवश्यक हो तो C# और VB.NET प्रोजेक्ट्स के लिए भी इस्तेमाल किया जा सकता है। धन्यवाद!

@MarkIngramUK क्या आपको पता है कि मैं WinUI डेस्कटॉप के बारे में और कहां से जान सकता हूं। वे बिल्ड 2019 सत्र ऑनलाइन देखने के लिए उपलब्ध नहीं हैं। महत्वपूर्ण जानकारी की तरह लगता है जिसे इस रेपो में जोड़ा जाना चाहिए

@mdtauk एक तथाकथित चुपके पीक में इसका उल्लेख किया गया था, जो केवल बिल्ड अटेंडीज़ के लिए है। अफैक कोई रिकॉर्डिंग नहीं है। मैं भी वहां नहीं था, लेकिन एक स्लाइड है - शायद सबसे अच्छी स्लाइड :-) - ट्विटर पर उपलब्ध: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk WinUI 3 रोडमैप में नवीनतम जानकारी और आरेख हैं जो बिल्ड स्नीक पीक में दिखाए गए से भी अधिक अद्यतित हैं। "एक्सएएमएल डेस्कटॉप" और न ही "विनयूआई डेस्कटॉप" जैसी कोई चीज नहीं है ... संप्रेषित की जा रही अवधारणा (और रोडमैप इसे और अधिक स्पष्ट रूप से समझाने की कोशिश करता है) यह है कि WinUI 3 के लिए हम इसे बनाने के लिए काम कर रहे हैं ताकि आपके पास एक प्रोजेक्ट टेम्प्लेट हो जो अपने UI के लिए WinUI 3 का उपयोग करके एक नया पारंपरिक डेस्कटॉप/Win32-मॉडल ऐप बनाता है। (जैसे आज पारंपरिक डेस्कटॉप/Win32-मॉडल के शीर्ष पर WinForms, wpf, MFC, आदि जैसे UI ढांचे के लिए टेम्पलेट हैं) एक अद्यतन UWP/WinRT- मॉडल ऐप प्रोजेक्ट टेम्पलेट के अलावा जो WinUI 3 का उपयोग करता है। स्पष्ट करने में मदद करें?

3.0 रोडमैप निम्नलिखित रणनीति के लिए काफी उचित लगता है: किसी भी विंडोज क्लाइंट ऐप को एक्सएएमएल और "आधुनिक" विनयूआई नियंत्रणों का उपयोग करने में सक्षम करें।

हालाँकि, यह रणनीति अदूरदर्शी लगती है यदि कोई आज के बाजार की वास्तविकता पर विचार करता है: बहुत सारे ऐप विकास के लिए, एंड्रॉइड और आईओएस प्राथमिक लक्ष्य हैं, और विंडोज एक अच्छा है। .NET डेवलपर के लिए, Xamarin को आपको अच्छा Android और iOS समर्थन मिलता है, लेकिन उनका Windows समर्थन सब-बराबर है। तो देशी मोबाइल/डेस्कटॉप ऐप्स के लिए, विन यूआई 3.0 .NET डेवलपर्स के लिए क्रॉस-प्लेटफ़ॉर्म विकास को आसान बनाने के लिए कुछ भी नहीं करता है।

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

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

वैकल्पिक रूप से अक्षम करें या लीगेसी-मोबाइल एप्लिकेशन जीवनचक्र व्यवहारों से ऑप्ट आउट करें, जैसे सस्पेंड + टॉम्बस्टोन।

हकीकत यह है कि यूडब्ल्यूपी एक डेस्कटॉप वातावरण है और कम से कम गेम के लिए, उपयोगकर्ता अक्सर ऐप को कम कर सकता है जो आमतौर पर ऐप को निलंबित/टॉम्बस्टोनिंग की ओर ले जाता है। यह एक झकझोर देने वाला अनुभव है और यह किसी भी win32 डेस्कटॉप ऐप या गेम से बहुत अलग है। एक विस्तारित आस्थगन का अनुरोध करना, जो अभी भी समाप्त होने की संभावना है, इससे निर्बाध रूप से निपटने के लिए पर्याप्त नहीं है।

जबकि यह जीवनचक्र कुछ ऐप्स के लिए आसान है, यह दूसरों के लिए हानिकारक है। आदर्श रूप से एक डेस्कटॉप ऐप या गेम एक ऐसी क्षमता की घोषणा करने में सक्षम होना चाहिए जो ऐप को सस्पेंड + टॉम्बस्टोन जीवनचक्र मॉडल से ऑप्ट-आउट करने की अनुमति देता है, जो इसे कम से कम होने पर अंततः निलंबित होने से रोकेगा।

@natemonster

प्रति: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

डेस्कटॉप उपकरणों पर, ExtendedExecutionReason.Unनिर्दिष्ट के साथ बनाए गए विस्तारित निष्पादन सत्रों में बैटरी-जागरूक समय सीमा होती है। यदि डिवाइस दीवार की शक्ति से जुड़ा है, तो विस्तारित निष्पादन समय अवधि की लंबाई की कोई सीमा नहीं है। यदि डिवाइस बैटरी पावर पर है, तो विस्तारित निष्पादन समयावधि पृष्ठभूमि में दस मिनट तक चल सकती है।

एक टैबलेट या लैपटॉप उपयोगकर्ता को वही लंबे समय तक चलने वाला व्यवहार मिल सकता है - बैटरी जीवन की कीमत पर - जब ऐप सेटिंग्स द्वारा बैटरी उपयोग में ऐप को पृष्ठभूमि कार्यों को चलाने की अनुमति दें विकल्प का चयन किया जाता है।

@TonyHenrique जब आप Fody का उल्लेख करते

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

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

किस प्रकार के निर्भरता अद्यतन इसे और अधिक मूल्यवान बना देंगे? उदाहरण के लिए नए संगत NuGet पैकेज संस्करण ढूँढना?

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

@mrlacey मैंने फोडी का उल्लेख किया क्योंकि मुझे लगता है कि यह एक दिलचस्प समाधान है और हमें _INOTifyPropertyChanged_ बॉयलरप्लेट कोड से बचने के लिए एक बेहतर तरीका चाहिए। एक प्रतिक्रियाशील वस्तु की इस अवधारणा के लिए एक एमएस समर्थित समाधान होना अच्छा होगा जो कुछ संपत्ति में परिवर्तन होने पर स्वचालित रूप से एक घटना उठाता है।
यह सी # कक्षाओं और यहां तक ​​​​कि एफ # रिकॉर्ड्स पर भी काम करता है (लेकिन कुछ कठिनाइयां थीं)।
तो WinUI रोडमैप पर यह भी होना चाहिए।

नोट: यह अच्छा होगा यदि हम अपनी डेटा संस्थाओं को परिभाषित करने के लिए F# रिकॉर्ड का उपयोग कर सकें और फिर सीधे XAML UI से बाइंड कर सकें। यह अच्छा होगा अगर हम बिना किसी समस्या के एफ # रिकॉर्ड्स + फोडी + डेटा बाइंडिंग का उपयोग कर सकें।

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

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

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

@tonyhenrique / @mrlacey मुझे लगता है कि फोडी स्टफ (OAP) दायरे से बाहर होना चाहिए। WinUI टीम के पास पहले से ही उनकी प्लेट पर पर्याप्त है, और मुझे लगता है कि अलग-अलग परियोजनाओं में बुनाई करना बेहतर है (सुधार के मामले में बहुत तेजी से रिलीज चक्र)।

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

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

उस दिशा में जाने का एक लंबे समय से प्रस्ताव है: .NET 5 के लिए क्रॉस प्लेटफॉर्म UX - मूल शीर्षक Cross platform UX for .NET Core 3.0 । इसके लिए समुदाय का भारी समर्थन स्पष्ट है और हम आशा कर सकते हैं कि MSFT को यह एहसास होगा कि .NET पर काम करने वाले किसी भी UI ढांचे को विकसित करने के लिए यह सबसे अच्छी दिशा है। अलग-अलग प्लेटफ़ॉर्म समूहों के लिए अलग-अलग कोडबेस रखने और .NET द्वारा समर्थित विभिन्न UX फ्रेमवर्क के आधार पर जबरन अलग-अलग डेवलपर कौशल सेट बनाने का कोई कारण नहीं है।

सभी प्लेटफार्मों के लिए एकल यूएक्स बनाकर हम ढांचा विकास में सभी अक्षमताओं को रद्द कर देते हैं और डेवलपर को अपनाने के लिए बाधाओं को कम करते हैं।

@mfeingol / @4creators , मैं इसके लिए समझौता करूंगा

ऐप वास्तव में प्रत्येक प्लेटफॉर्म पर प्रथम श्रेणी का होना चाहिए

विंडोज़ पर शुरू करने के लिए ...

यह 2019 है, मुझे एक तेज़, मूल UI चाहिए, और मैं CreateWindowExW , GDI, आदि के साथ उपयोगकर्ता इंटरफ़ेस बनाने पर गंभीरता से विचार नहीं करना चाहता।

अब जबकि WinUI3.0 और उससे ऊपर के कोड को Windows 10 से अलग कर दिया गया है, क्या भविष्य में WinUI के लिए Linux और Mac पर काम करने की कोई योजना है?

@jesbis टच इंटरैक्शन को WinUI 3.0 में रखा जाएगा?

स्पष्टीकरण के लिए धन्यवाद, मैंने मान लिया था कि 3.0 जिस तरह से काम करेगा, वह सामुदायिक टूलकिट का उपयोग करने के बजाय, WinUI में Xaml द्वीप को शामिल करना था।

एक्सएएमएल प्लस विन 32 बनने के साथ, यह अधिक समझ में आता है, खासकर विंडोज कोर ओएस के साथ एक्सएएमएल में इसके खोल को फिर से लिखना।

जैसा कि मैं अब इसे समझता हूं, यह समृद्ध Win32 API एक्सेस C और C++ में है | सी # में कुछ भी .NET पर निर्भर है (सब अब यह .NET कोर हो)।

शायद इन Win32 API तक पहुंचने का एक सुरक्षित और आसान तरीका होना चाहिए, साथ ही ऐप्स UI प्रदर्शित करने के लिए अधिक प्रवेश बिंदु भी होने चाहिए?

• WinUI 3 ऐप्स के लिए सिस्टम ट्रे XAML फ्लाईआउट

• Hololens/Xbox/Surface हब/IoT, आदि के लिए सरल पिकर UI

• अद्यतन किए गए XAML अनुकूलन योग्य सामान्य फ़ाइल संवाद, और फ़ोल्डर पिकर

• Win32 APIs के लिए सरल C# .NET एक्सेस

• सभी एक्सएएमएल तत्वों के लिए कॉम्पैक्ट सेटिंग, जो Win32 और wpf नियंत्रण आकार से मेल खाते हैं (इससे फ्रेमवर्क को एक साथ आराम से बैठने में मदद मिलेगी)

• WinUI का उपयोग करते समय मिलान नियंत्रण शैली/फोंट/उच्चारण ब्रश/एक्रिलिक

• स्पष्ट परिभाषा कि किन उपकरणों को WinRT/मोबाइल जीवनचक्र की आवश्यकता है

• एक्सबॉक्स ऐप डेवलपमेंट और विंडोज़ पर परीक्षण के लिए निर्मित एक्सबॉक्स नेक्स्ट कंट्रोल स्टाइल

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

• WinForms WinUI 3.0 - सरल UI, केवल MFC, माउस और कीबोर्ड तक पहुंच

• डब्ल्यूपीएफ विनयूआई 3.0 - सघन यूआई, 3डी रेंडरिंग, डीपीआई जागरूक, सिम्युलेटेड टच और बेसिक इंक सपोर्ट

• Xaml WinUI 3.0 - फुल टच, MR, गेमपैड, इनकिंग, वॉयस, माउस, कीबोर्ड। घने और सरल यूआई। नई विंडोिंग समर्थन। एमआर 3डी रेंडरिंग। वैकल्पिक प्रबंधित जीवनचक्र, या डेस्कटॉप जीवनचक्र। नोटपैड, चार्मैप, पेंट, फ़ाइल एक्सप्लोरर जैसे इनबॉक्स ऐप्स के Win32 संस्करणों के साथ शेल और रीवर्क किए गए इनबॉक्स ऐप्स के लिए सभी दुनिया के सर्वश्रेष्ठ डिफ़ॉल्ट - ओपन सोर्स और स्टोर से उपलब्ध।

टच इंटरैक्शन को WinUI 3.0 में रखा जाएगा?

@ r7dev हाँ, योजना समान स्तर के स्पर्श समर्थन को बनाए रखने की है।

WinUI 3.0 रोडमैप पर F# को अनदेखा कर दिया गया है। Microsoft अपने एक उत्पाद को एक बार फिर नज़रअंदाज़ कर रहा है।

Win32 एपीआई विचार

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

ओएस एक्स पर, ऐपकिट तक पहुंचने के लिए आपको बस objc_msgSend C API को पाटने और संपूर्ण obj-c इन्फ्रास्ट्रक्चर तक पहुंच प्राप्त करने की आवश्यकता है। उपरोक्त सभी भाषाओं ने इसे पाटने का वास्तव में अच्छा काम किया है और इससे आपकी पसंद की भाषा में लिखना और कुछ सम्मोहक बनाना आसान हो गया है।

इसलिए यदि आप WinUI 3.x को निम्न-विलंबता, कम-मेमोरी, उच्च गुणवत्ता वाले Win32 UI तक पहुँचने के लिए सही मार्ग बनाना चाहते हैं, तो आपको उस सहजता पर विचार करने की आवश्यकता है जिस पर अन्य भाषा अनुरक्षक बुनियादी ढांचे में टैप कर सकते हैं।

यूआई संगति

यदि आप वास्तव में सिस्टम से UI को अलग करने की योजना बना रहे हैं, तो UI के लिए प्रत्येक OS अपग्रेड के अनुरूप रहने की क्या योजना है? जब ऐप्पल ऐपकिट या आईओएस में छाया और ग्रेडियेंट में बदलाव करता है, तो सिस्टम फ्रेमवर्क पर भरोसा करने वाले ऐप्स उन सभी बदलावों को प्राप्त करते हैं और लगातार बने रहते हैं। यह आपके लिए सिस्टम-व्यापी अनुभवों को जोड़ना भी कठिन बना देगा क्योंकि 3 साल पहले UI इन्फ्रास्ट्रक्चर में लॉक किए गए ऐप्स कुछ नई सिस्टम सेवा के साथ अच्छी तरह से काम नहीं कर सकते हैं, इसलिए समय के साथ उनके पास एक और संगतता परत होगी।

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

बाइनरी आकार

इन सभी UI.dll को हमारी परियोजनाओं के साथ वितरित करने के लिए नियोजित कहानी क्या है? क्या ये चीजें 40mb रनटाइम की होंगी जिन्हें हमारी परियोजनाओं के साथ शिप करने की आवश्यकता है? यदि कोई प्रोजेक्ट छोड़ दिया जाता है तो क्या होगा, क्या वे पुराने दिखने लगेंगे क्योंकि वे पुराने UI फ्रेमवर्क का उपयोग करते हैं?

सी ++ के लाभों में से एक यह है कि इसमें कोडबेस के आधार पर लाइब्रेरी ओवरहेड की न्यूनतम मात्रा होती है। निश्चित रूप से अगर यहां से हर एक ऐप को WinUI 3.x की आवश्यकता होती है, तो यह 40mb x संख्या में ऐप्स होने वाला है।

बाइनरी आकार

WinUI पहले से ही एक निर्भरता है, ठीक वैसे ही जैसे .NET है। यह पहले से ही एक सिस्टम-वाइड लाइब्रेरी है। :)
आपके पास डुप्लिकेट डीएलएस नहीं हैं, और आपके पास यह नहीं होगा।
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

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

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

संभवतः सबसे बड़ी समस्या यह है कि निम्न-स्तरीय WinRT ABI विवरण के लिए दस्तावेज़ीकरण एक प्रकार से अव्यवस्थित है, और दुनिया/समुदाय में उनके बारे में बहुत कम समझ या जागरूकता है, मुझे उम्मीद है कि हालांकि xlang परियोजना के साथ इस स्थिति में सुधार होगा।

आप किस टेम्पलेट में सबसे अधिक रुचि रखते हैं?

वर्तमान में मैं एक ब्लैंक ऐप (यूनिवर्सल विंडोज) प्रोजेक्ट से शुरुआत करना पसंद करता हूं। मुझे पूर्व-कॉन्फ़िगर किए गए ढांचे वाले टेम्प्लेट भी पसंद हैं, लेकिन केवल तभी जब मैं कुछ जल्दी से आज़माना चाहता हूँ। UWP के लिए "मेन मेन्यू" टेम्प्लेट और MDI टेम्प्लेट भी अच्छा होगा (क्योंकि वे टेम्प्लेट WinForms के लिए भी मौजूद हैं)

क्या आप डेस्कटॉप ऐप्स के आधुनिकीकरण के लिए Xaml द्वीप समूह के बारे में जानते थे?
क्या यह Windows 10 पर विस्तारित पश्च-संगतता Xaml द्वीप समूह को आपके लिए अधिक उपयोगी बनाता है

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

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

हाँ, सुनिश्चित करें कि यह विश्वसनीय काम करता है! मैं उन कई टिप्पणियों से हैरान हूं जो इतनी अच्छी सुविधा की सराहना नहीं करती हैं। साथ ही यह सुविधा जांच सकती है कि क्या WinUI 3.0 का अपडेट संभव है, XAML कोड अपनाएं, नाम स्थान समायोजित करें और आवश्यक WinUI nugets स्थापित करें।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

मैं WinUI 3.0 के साथ पूर्ण कार्य करने के लिए नियंत्रण के केवल नामस्थान बदलने की अपेक्षा करता हूं। मैं WinUI 3.0 में अपग्रेड करने में ज्यादा समय नहीं लगाना चाहता हूं

क्या आप UWP Xaml कंट्रोल लाइब्रेरी या WinRT घटकों का निर्माण या उपयोग करते हैं जिन्हें आप ऐप कोड के साथ आसानी से पुन: संकलित और अपडेट नहीं कर सकते हैं?

मैं तृतीय पक्ष UWP Xaml नियंत्रण पुस्तकालयों (जैसे Windows समुदाय टूलकिट, https://github.com/kakone/VLC.MediaElement) का उपयोग कर रहा हूं। मुझे लगता है कि मैं डॉकपैनल जैसे तीसरे पक्ष के पुस्तकालयों से सरल नियंत्रणों को WinUI 3.0 में अपग्रेड करने में सक्षम हूं।

WinUI 3 के साथ UWP Xaml घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

• UWP के लिए विजुअल स्टूडियो में "WinUI 3.0 के साथ ब्लैंक ऐप" प्रोजेक्ट टेम्प्लेट बनाएं। WinUI 3.0 निर्भरता को nuget के रूप में स्थापित किया जाएगा (जैसे WinUI 2.0 में)।

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] । जब तक मुझे सभी बुनियादी नियंत्रण मिलते हैं, तब तक मैं इस तरह के समाधान को बिल्कुल पसंद करूंगा। मुझे उम्मीद है कि Windows.UI के सभी वर्गों में Microsoft.UI नेमस्पेस में एक समान वर्ग होगा।

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

• स्टाइल ट्रिगर गायब
• स्टाइल `बेस्डऑन = {स्टेटिक रिसोर्स {x: टाइप टेक्स्टब्लॉक}} गायब है
• डेटाटाइप के साथ परिभाषित डेटा टेम्पलेट स्वचालित रूप से wpf में लागू नहीं होते हैं (केवल कुंजी के माध्यम से)
• हर सेकेंड Windows.UI.Xaml.Controls कंट्रोल (टेक्स्टब्लॉक, बॉर्डर,...) को सील क्यों घोषित किया जाता है? कृपया इसे UWP के साथ WinUI 3.0 में न करें।
• डब्ल्यूपीएफ समता के लिए मार्कअप एक्सटेंशन
• यह पहले ही उल्लेख किया गया था, लेकिन मैं इसका एक बार और उल्लेख करने जा रहा हूं। यह दुख की बात है कि UWP System.ComponentModel.IDataErrorInfo का उपयोग नहीं करता है। इस तरह मैं अपने मॉडल प्रोजेक्ट को UWP समाधान के साथ साझा नहीं कर सकता।
• रिपोर्ट नियंत्रण (एंटरप्राइज़ अनुप्रयोगों के लिए)

मैं वास्तव में WinUI 3.0 और इसकी पिछड़ी संगतता की प्रतीक्षा कर रहा हूं!

WinUI 3.0 रोडमैप पर F# को अनदेखा किया गया है

क्या कोई संभावना है कि यूडब्ल्यूपी एक्सएएमएल मार्कअप को किसी तरह अतिरिक्त सुविधाएं मिलें?

@Happypig375 , @mfe-:

रोडमैप केवल प्रारंभिक 3.0 रिलीज़ को कवर करता है, और प्रारंभिक रिलीज़ के लिए हम मुख्य रूप से नई सुविधाओं की एक छोटी संख्या के साथ मौजूदा सुविधाओं के लिए समता और पश्चगामी संगतता पर ध्यान केंद्रित कर रहे हैं।

यदि आपको लगता है कि अन्य नई सुविधाएँ जैसे बेहतर F# समर्थन या नई मार्कअप क्षमताएँ महत्वपूर्ण हैं तो कृपया एक नया सुविधा अनुरोध खोलें ताकि हम उन्हें अलग से ट्रैक कर सकें!

हर दूसरा Windows.UI.Xaml.Controls control (TextBlock, Border,...) को सील क्यों घोषित किया जाता है?! कृपया इसे UWP के साथ WinUI 3.0 में न करें।

नियंत्रण हटाना वास्तव में उन छोटी संख्या में नई सुविधाओं में से एक है जिन्हें हम 3.0 . में शामिल करने की उम्मीद कर रहे हैं

जब भाषाओं की बात आती है, तो यह मिश्रण और मिलान करने के लिए साफ-सुथरा होगा (जो पैकेजिंग से पहले सब कुछ संकलित होने पर ठीक होना चाहिए)

एफ # कुछ बैक एंड लॉजिक के लिए उपयोग किया जाता है - सी # डाटाबेसिंग और यूआई कोड के लिए - सी ++ नियंत्रण के लिए और शायद कुछ कम अंत Win32 हुक या यहां तक ​​​​कि WinForms संवाद लॉन्च करने के लिए भी।

सभी कोड भाषाएं समान, विनिमेय हैं, जिसमें WinUI 3.0 सभी UI को संभालता है

वह xlang है

वह xlang है

@MarkIngramUK हम्म, मैंने सोचा कि यह भाषाओं के बीच एक पुल था, जो एक ही परियोजना में कई भाषाओं से कोड फ़ाइलों को अनुमति देने के बजाय प्रत्येक भाषा को

मैंने xlang के उद्देश्य को समझने के लिए बहुत संघर्ष किया है - रेपो में होने वाले अपडेट पर चमकते हुए (लेकिन अभी भी यह मेरी देखने की सूची में है)

क्या xlang संकलन से पहले या बाद में काम करता है? क्या यह इसकी अपनी सारगर्भित भाषा है जिसे प्रक्षेपित किया जा सकता है, या यह मौजूदा कोड फ़ाइलों के बीच बस बैठती है?

हां, आप किसी एक प्रोजेक्ट में भाषाओं का मिश्रण नहीं कर सकते। यह एक पुल है, लेकिन फिर भी उन उद्देश्यों के लिए उपयोगी है।

@MarkIngramUK मुझे लगता है कि यदि इसका कोड संकलित किया जा सकता है तो इसमें शामिल है।

PInvokes और अन्य .NET ट्रिक्स के बिना, देशी Win32 सुविधाओं तक पहुँचने के लिए C# का उपयोग करने में सक्षम होना अच्छा होगा

@jesbis मैं इस परियोजना के क्रॉस-प्लेटफ़ॉर्म पहलुओं में ईमानदारी से अधिक दिलचस्पी

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

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

यदि .Net 5 पर लक्ष्य "वन .नेट एवरीवेयर" होना है, जो मूल रूप से .Net 1.0 के बाद से हर किसी की हमेशा अपेक्षा की जाती है, तो "एनीथिंग बट विन यूआई" फ्रेमवर्क की नींव क्रॉस-प्लेट शुरू होनी चाहिए।

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

वह सिर्फ मेरा 2c है। मुझे Xaml पर काम पर वापस जाना अच्छा लगेगा लेकिन अगर यह यूडब्ल्यूपी के समान लाइन पर रहता है, तो मुझे डर है कि इसे सही कर्षण नहीं मिलेगा और डब्ल्यूपीएफ को फिर से लिखने का एक और प्रयास होगा जिसे अंततः एक और प्रयास की आवश्यकता होगी भविष्य और इतने आगे।

कृपया मुझे पागल मत समझो और मेरी टिप्पणी को एक बुरी आलोचना के रूप में मत लो। मैं बस यही चाहता हूं कि .Net दुनिया पर UI के प्रयासों को Flutter, .Net Core 3.0/.Net 5, और यहां तक ​​कि Blazor जैसा कुछ मिले।

रिकॉर्ड के लिए, मैंने नेट वर्ल्ड पर विकल्पों की कमी के कारण पूरी तरह से सी # और नेट कोर पर स्पंदन इंजन को फिर से लिखने/बंद करने के लिए एक परियोजना शुरू की ...

बीटीडब्ल्यू, CoreUI एक अच्छा नाम है ...

उस सुझाव के लिए कुडोस टू जेक हेलफर्ट

मैं

बीटीडब्ल्यू, CoreUI एक अच्छा नाम है ...

उस सुझाव के लिए कुडोस टू जेक हेलफर्ट

मैं

CoreUI .NET Core के साथ भ्रमित हो सकता है

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

अगर टीम कभी भी प्रेजेंटेशन प्लेटफॉर्म को लाने का विकल्प चुनती है, और Xland या Xamarin क्रॉस प्लेटफॉर्म ऐप्स के लिए रनटाइम को हैंडल कर सकता है।

इनबॉक्स UWP UI से WinUI 3.0 में माइग्रेशन के बारे में, मैं @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ) से एक हालिया ब्लॉग पोस्ट उद्धृत

फन बॉटम नोट: UWP के साथ जो हो रहा है, वह यह नहीं है कि इसे मारा जा रहा है: Microsoft सर्वोत्तम भागों को उस स्थान पर लाने की ओर अग्रसर है जहाँ हमें उनकी आवश्यकता है। यह वास्तव में पहले हुआ था, लेकिन दुर्भाग्य से इसे एक धुरी प्रदर्शन करने के अवसर के रूप में उपयोग नहीं किया गया था। सिल्वरलाइट याद है? अनुमान लगाएं कि .NET Core का क्रॉस-प्लेटफ़ॉर्म CLR कहाँ से आया है। और बहुत सारे सिल्वरलाइट का कोड भी UWP में समाप्त हो गया। अगर वे केवल पिवोट करते और कहते "हाँ, हम सहमत हैं कि सिल्वरलाइट का उपभोक्ता अतिरिक्त में कोई मतलब नहीं है, लेकिन यह एंटरप्राइज स्पेस में फल-फूल रहा है, तो चलिए उस पर निर्माण करते हैं, और हम इसे .NET कोर और विंडोज स्टोर में विकसित करेंगे"। दुर्भाग्य से यह इतना आसान नहीं था, और बहुत से लोग अभी भी PTSD से पीड़ित हैं और माइक्रोसॉफ्ट जो कुछ भी करता है उससे सावधान रहता है जो किसी भी तकनीक को मार रहा है।

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

@weitzhandler WinUI 3.0 विभिन्न Win32, .NET Core और UWP फ्रेमवर्क को एक XAML फ्रेमवर्क के साथ संयोजित करने और wpf, WinForms और MFC++ के साथ इंटरऑपरेट करने के बारे में है।

विंडोज़ पर एक्सएएमएल डायरेक्ट एक्स में प्रस्तुत किया गया है।

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

Microsoft स्वयं ऐसा नहीं करना चाहेगा क्योंकि यह उनके लिए कोई अर्थ नहीं रखता है। लेकिन WinUI 3.0 ओपन सोर्स होगा - इसलिए अन्य लोग इसे क्रॉस प्लेटफॉर्म पर लाने का प्रयास करना चुन सकते हैं

@mdtauk

इसे स्पष्ट करने के लिए धन्यवाद। स्पंदन शायद मेरे लिए भविष्य है।

यह सिर्फ मेरी समझ है, मुझसे गलती हो सकती है।

माना जाता है कि स्पंदन को भविष्य में विंडोज का समर्थन मिल रहा है। और विंडोज पर भी रिएक्ट नेटिव सपोर्ट आ रहा है। साथ ही यदि आप उस वेब HTML और Javascript दुनिया में निवेशित हैं तो PWA भी हैं।

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

एक्सएएमएल को पर्यावरण अज्ञेयवादी होने की जरूरत है जैसे एचटीएमएल 100 एमबी + ले रहा है, यहां तक ​​​​कि सबसे बुनियादी टूल ऐप्स के लिए भी एचटीएमएल ऐप्स करते हैं। इसका मतलब है कि एक XAML फ्रेमवर्क जो शुद्ध C/C++ या C# में लिखा गया है और पोर्टिंग के मामले में न्यूनतम प्रयास के साथ WASM, Win32, UWP, iOS, Android, macOS, Linux आदि में होस्ट किया जा सकता है। आपको एक अज्ञेय प्रतिपादन बैकएंड की आवश्यकता है जैसे गेम इंजन शुरू करने के लिए उपयोग करते हैं।

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

मेरी राय में एक्सएएमएल को बचाने का एकमात्र तरीका है:

• .NET Core और C/C++ के लिए एक नया अज्ञेयवादी/पोर्टेबल ढांचा आधार बनाएं।
• एक अज्ञेय प्रतिपादन अमूर्त परत बनाएं जिसे कोई भी पुल-अनुरोधों के माध्यम से बढ़ा सकता है।
• जैसे एचटीएमएल एक्सएएमएल को सिंगल विंडो वाले ऐप कॉन्सेप्ट पर केंद्रित रखता है (जैसा कि गेम में भी किया जाता है) लेकिन मल्टी विंडो आदि के लिए विस्तारित डेस्कटॉप फीचर्स की अनुमति देता है। (यह ऐप को लगभग किसी भी संदर्भ में चलाने की अनुमति देता है जैसे कि गेम यूआई कर सकता है)

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

1 MS को XAML प्रोजेक्ट का समर्थन करने की आवश्यकता है या लोगों को इसके गिरने का डर है।

2 इसे क्रॉस-प्लेटफ़ॉर्म होने की आवश्यकता है या हर कोई पागल फूला हुआ HTML रनटाइम के साथ फंसने वाला है।

वैसे भी मेरे दो सेंट हैं और अगर WinUI 3.0 को सही तरीके से डिज़ाइन किया गया है तो शायद पोर्टिंग संभव होगी। इस बिंदु पर हालांकि idk क्या महसूस करना है।

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

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

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

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

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

यह कुछ ऐसा है जिसे Microsoft डिज़ाइन टीम द्वारा पहले ही संबोधित किया जा चुका है। फ्लुएंट वेबसाइट स्पष्ट रूप से कहती है "कस्टम ऐप्स डिज़ाइन और निर्माण करें जो मूल रूप से आईओएस हैं जबकि अभी भी विशिष्ट रूप से फ्लुएंट हैं"। धाराप्रवाह दस्तावेज़ दिखाते हैं कि देशी नियंत्रण शैली का उपयोग किया जाना चाहिए।
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

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

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

@KyleNanakdewa ठीक है अगर वे इसे ओपन सोर्सिंग कर रहे हैं, तो कुछ Xaml प्रशंसकों को जाने दें और अंतर्निहित प्लेटफॉर्म बिट्स बनाएं। मुझे लगता है कि यह शायद वास्तुशिल्प रूप से काफी जटिल है और Win32 का पर्याप्त लाभ उठाता है कि मुझे संदेह है कि बंदरगाह एक बड़ा उपक्रम होगा।

मुझे लगता है कि इस परियोजना को मूल विंडोज सॉफ्टवेयर बनाने के लिए कक्षा में सर्वश्रेष्ठ पेशकश करने पर ध्यान देना चाहिए

यह तर्क सम्मोहक हो सकता है यदि Microsoft के पास पहले से ही एक मौजूदा क्रॉस-प्लेटफ़ॉर्म XAML टूलकिट नहीं है जो कि WinUI की तुलना में XAML की एक बहुत ही अलग बोली पेश करने के लिए होता है।

साथ ही यदि आप उस वेब HTML और Javascript दुनिया में निवेशित हैं तो PWA भी हैं।

हां ... "वह दुनिया" जो देशी ओएस/स्टोर/होस्टेड विकास के बारे में हम जो कुछ भी जानते हैं उसे जल्दी से बदल रही है। मैं

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

विचार करें कि "वह दुनिया" HTML5 रेंडरर वाले _all_ आधुनिक उपकरणों पर मौजूद है:

• 1.4 अरब . के साथ ऐप्पल
• 2.5 अरब . के साथ Droid
• विंडोज 10 800 मिलियन के साथ

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

फ़्लटर के साथ इसकी तुलना करें, जो _one_ कोडबेस के साथ वेब के साथ-साथ उपरोक्त मार्केटप्लेस के _all_ तक पहुंचता है, जैसा कि उल्लेख किया गया है कि तीनों के कुल में बना है - इसलिए बिल्डिंग की आवश्यक लागत को कम करते हुए एप्लिकेशन डेवलपर्स के लिए बाजार पहुंच और संभावित राजस्व को अधिकतम करना ऐसा करने के लिए आवेदन।

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

आधिकारिक नेट कोर 3 (सितंबर 2019) और अंत में जल्द ही किसी भी डेटा संचालित आधुनिक डेस्कटॉप अनुभव में आरेख नियंत्रण आवश्यक है। नेट 5 (नवंबर 2020)

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

हम 2 इन 1 उपयोग के मामले देखते हैं जहां हमारे ऐप को भविष्य के विंडोज कोर ओएस में टैबलेट मोड का समर्थन करने की आवश्यकता है। हमें संदेह है कि Winform in. NET Core 3 मदद नहीं करेगा।

यदि आपको लगता है कि अन्य नई सुविधाएँ जैसे बेहतर F# समर्थन या नई मार्कअप क्षमताएँ महत्वपूर्ण हैं तो कृपया एक नया सुविधा अनुरोध खोलें ताकि हम उन्हें अलग से ट्रैक कर सकें!

लगता है @migueldeicaza मामलों को अपने हाथों में ले रहा है: https://github.com/microsoft/microsoft-ui-xaml/pull/736

मैं क्रॉस-प्लेटफ़ॉर्म पर @eklipse2k8 के विचारों को प्रतिध्वनित करना चाहता हूं। क्रॉस-प्लेटफ़ॉर्म UI लाइब्रेरी बनाते समय आपको हमेशा समझौता करना होगा। WinUI को समझौता नहीं करना चाहिए - इसे Win32 UI का आधुनिक प्रतिस्थापन होना चाहिए (मैं अब CreateWindowExW कॉल नहीं करना चाहता!) और इसे विंडोज़ पर आप क्या कर सकते हैं इसका एक प्रदर्शन होना चाहिए। मैकोज़ या एंड्रॉइड पर विनयूआई हमेशा एक ऐसा अनुभव प्रदान करेगा जो मूल अनुभव से मेल नहीं खा सकता है। हम क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन लिखते हैं, और हम प्रत्येक प्लेटफ़ॉर्म पर मूल UI लिखते हैं। इस तरह ग्राहकों को उनकी पसंद के प्लेटफॉर्म पर बेहतरीन अनुभव मिलता है। यदि लोग एक क्रॉस प्लेटफॉर्म समाधान चाहते हैं, तो यह ठीक है, उन्हें उस उद्देश्य के लिए किसी अन्य पुस्तकालय को देखना चाहिए - शायद वह जो विंडोज प्लेटफॉर्म पर विनयूआई को लपेटता है।

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

अनिवार्य एक्सकेसीडी:
https://xkcd.com/927/

@MarkIngramUK मुझे लगता है कि क्रॉस प्लेटफार्म की बात यूआई घोषित करने के लिए .NET और XAML को कोड करने में सक्षम होने के बारे में अधिक है - फिर उस ऐप को एंड्रॉइड, आईओएस, मैकोज़, लिनक्स पर चलाने के लिए ?! - एक्सएएमएल के पीछे कोड बदलने या छोड़ने के बिना।

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

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

वास्तव में इसकी आवश्यकता होगी (उच्च स्तर की सोच पर) यह सुनिश्चित करना है कि विंडोज़ में स्क्रीन पर एक्सएएमएल प्रस्तुत करने वाला कोड निहित है, इसलिए अन्य रेंडरर्स क्रॉस प्लेटफॉर्म परिदृश्यों के लिए कदम उठा सकते हैं।

विनआरटी/यूडब्ल्यूपी/एक्सएएमएल को विंडोज 10 ओएस से निकालने के लिए कुछ रिफैक्टरिंग की आवश्यकता होगी - तो भविष्य में विस्तार की अनुमति देने के लिए यह रिफैक्टरिंग कैसे किया जाता है, यह ध्यान में रखना है। क्रॉस प्लेटफॉर्म एक वास्तविकता बन जाता है या नहीं।

@MarkIngramUK मैं हूं

कोई कारण नहीं होना चाहिए कि हम प्रतिक्रिया सहित अन्य पुस्तकालयों में UI घटकों का वर्णन करने के लिए xaml का उपयोग क्यों नहीं कर सकते हैं। यदि आप http://www.cshtml5.com जैसे प्रोजेक्ट को देखते हैं, तो वे xaml का उपयोग करते हैं जो html में परिवर्तित हो जाता है।
मुझे नहीं लगता कि कोई भी इस तथ्य के बारे में बताता है कि अंतिम लक्ष्य यूआई के लिए अन्य प्लेटफार्मों पर समान दिखना है, लेकिन मैं व्यक्तिगत रूप से यूआई पक्ष पर कुछ ऐसा चाहता हूं जिसका उपयोग मैं अपने मौजूदा निवेश का लाभ उठाने के लिए कर सकता हूं जैसे यूडब्ल्यूपी

बात बस इतनी सी है। अगर मैं एक उद्यम ग्राहक को एक प्रस्ताव देता हूं और एक भयानक यूडब्ल्यूपी ऐप पेश करता हूं जो हर तरह से शानदार है। यदि उस एंटरप्राइज़ ग्राहक के पास 1 उपयोगकर्ता है जो उदाहरण के लिए मैकबुक प्रो का उपयोग कर रहा है, तो मुझे तुरंत एक समस्या है क्योंकि एंटरप्राइज़ ग्राहक मेरे "मूल ऐप" की तुलना में हर जगह काम करता है (सबसे कम denominator => वेबसाइट) भले ही वे चलते हों विंडोज 10 पर।

तो अभिगम्यता महत्वपूर्ण है। तथ्य यह है कि एमएस अभी भी 2019 में "मूल ऐप्स" में निवेश करने की उम्मीद कर रहा है, बिना किसी रोडमैप को पार करने की क्षमता के लिए पागल है।

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

तो फिर हम अब से 2-3 साल बाद तेजी से आगे बढ़ते हैं, कंपनियों से UWP/win32 में कोई नया निवेश नहीं होता है और आप एक और "सिल्वरलाइट" के साथ बैठे हैं जिसकी किसी को परवाह नहीं है।

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

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

और PWA के संबंध में, ये Windows UI सिस्टम के पूर्ण उपयोग का प्रतिनिधित्व नहीं करते हैं

काफी उचित, और मैं सहमत हूं। पीडब्ल्यूए के साथ मेरा प्राथमिक बिंदु यह प्रदर्शित करना था कि इसकी बाजार हिस्सेदारी किसी एक विशेष बाजार से बौनी है, क्योंकि यह सभी बाजारों में शामिल है।

उस ने कहा, मुझे लगता है कि मेरे हिस्से पर भ्रम का हिस्सा Microsoft.* को प्रतिबिंबित करने के लिए नेमस्पेसिंग है, जब वास्तव में ऐसा लगता है कि यह अभी भी Windows.* (या यहां तक ​​​​कि Microsoft.Windows.* ) होना चाहिए। .

PWA और क्रॉस-प्लेटफ़ॉर्म के लिए पहले से ही समाधान हैं - हमें दूसरे की आवश्यकता नहीं है।

दुर्भाग्य से, यह .NET विकास के मामले में नहीं है, जो इस घोषणा और बाद की चर्चा के आसपास भ्रम और क्रॉस-प्लेटफ़ॉर्म गुस्से का हिस्सा है।

इसलिए ऐसा करने के लिए एप्लिकेशन बनाने की आवश्यक लागत को कम करते हुए एप्लिकेशन डेवलपर्स के लिए बाजार पहुंच और संभावित राजस्व को अधिकतम करना।

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

क्रॉस-प्लेटफ़ॉर्म (xplat) समाधान के संबंध में।
Xplat समाधान कई मूल अंतर्निहित प्रणालियों पर एक अमूर्त है। विनयूआई के बारे में मेरी समझ यह है कि यह विंडोज़ के लिए मूल प्रणाली होगी।

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

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

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

उस ने कहा, यदि आप एक xplat समाधान बनाना चाहते हैं (और ऐसे बहुत से लोग हैं जो ऐसा करते हैं और इसके कारण हैं) क्योंकि आप या तो अभी कई ऑपरेटिंग सिस्टम को लक्षित करना चाहते हैं, या भविष्य में करना चाहते हैं, तो यह एक उचित और समझने योग्य है परिदृश्य।
उसके लिए Microsoft के पास Xamarin. या, यदि आप यूडब्ल्यूपी की तरह एक्सएएमएल के साथ कुछ पसंद करते हैं, तो यूनो है। (बहुत सारे अन्य विकल्प भी हैं।)
यदि, मेरी तरह, आप देखना चाहते हैं कि Xamarin के पास Windows ऐप्स बनाने के लिए बेहतर मूल समर्थन है, तो मुझे नहीं लगता कि WinUI का प्रयास करना और कई चीजें करना इसका उत्तर है।

WinUI केवल XAML और विशिष्ट नियंत्रणों से कहीं अधिक है। इसमें इस बात का विवरण शामिल है कि कैसे वे नियंत्रण और उनके साथ बनाए गए ऐप्स अंतर्निहित ऑपरेटिंग सिस्टम के साथ एकीकृत होते हैं।
यदि विनयूआई योजना विंडोज़ पर विंडोज़ विकास को सर्वश्रेष्ठ बनाने पर ध्यान केंद्रित करती है तो यह नवाचार और अच्छे भविष्य के समर्थन के लिए एक अच्छा मामला है। यह उन संभावनाओं को बढ़ाने की भी संभावना है जो लोग विंडोज का उपयोग जारी रखना चाहते हैं और इसलिए यह महत्वपूर्ण हो जाता है कि इसे कई xplat समाधानों से ठोस समर्थन प्राप्त हो।

क्रॉस-प्लेटफ़ॉर्म (xplat) समाधान के संबंध में।
Xplat समाधान कई मूल अंतर्निहित प्रणालियों पर एक अमूर्त है। विनयूआई के बारे में मेरी समझ यह है कि यह विंडोज़ के लिए मूल प्रणाली होगी।

क्षमा करें, लेकिन मुझे ऐसा नहीं लगता ...

स्पंदन को देखें ... इसमें एक कोर इंजन है जो किसी भी प्लेटफॉर्म पर कुछ भी प्रस्तुत कर सकता है जो इसका समर्थन करता है।

इसके शीर्ष पर, इसमें ऐसे घटक हैं जो इंजन प्रबंधित परत का उपयोग करके डार्ट पर पूरी तरह से लागू होते हैं और जो पिक्सेल निष्ठा में उस प्लेटफ़ॉर्म और डिज़ाइन भाषा का प्रतिनिधित्व (ड्रा/रेंडर) करते हैं, जिसका आप उदाहरण के लिए उपयोग करना चाहते हैं, Material.io और Apple's Cupertino।

तो, वह IMHO, जो कुछ क्रॉस प्लेटफॉर्म बनाने के लिए सबसे अच्छा तरीका होगा और साथ ही अंतर्निहित प्लेटफॉर्म क्षमताओं का प्रतिनिधित्व करता है।

मुझे नहीं लगता कि यह मान लेना उचित है कि यदि आप देशी विंडोज प्रौद्योगिकियों के साथ कुछ बनाते हैं और फिर इसे एक प्रतिस्पर्धी ऑपरेटिंग सिस्टम पर चलाना चाहते हैं तो यह आसान बनाने के लिए माइक्रोसॉफ्ट/विंडोज पर निर्भर है

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

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

मैं ठीक यही कह रहा हूं...

उदाहरण के लिए, Win10 (WPF और UWP) और साथ ही OSX दोनों पर डेस्कटॉप के लिए स्पंदन एम्बेडर्स आ रहे हैं।

वे 100% स्पंदन रनटाइम द्वारा प्रबंधित होते हैं, लेकिन वे विंडोिंग प्रबंधन और Graphics पॉइंटर प्राप्त करने के लिए केवल (उदाहरण के लिए) wpf/UWP का उपयोग कर रहे हैं। बाकी सब इंजन द्वारा प्रबंधित किया जाता है ...

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

इसलिए मैं कह रहा हूं कि WinUI माध्यम से UWP: The empire strikes back लंबे समय तक काम नहीं करने वाला है।

MSFT को कुछ क्रॉस-प्लेटफ़ॉर्म, ओपन और पोर्टेबल के साथ आना चाहिए। ठीक वैसे ही जैसे उन्होंने .Net Core के साथ किया था, Blazor के साथ, आदि... Reinvent UWP/XAML कहीं नहीं जाएगा।

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

जैसे MSFT ने हाल ही में क्रोमियम के साथ एज के लिए कोर के रूप में किया था, मेरा मानना ​​​​है कि WinUI (या जो भी नाम बन गया) स्की का लाभ उठा सकता है क्योंकि इसमें GL, DX, Vulkan, सॉफ़्टवेयर रेंडरिंग, FB, आदि के लिए बैकएंड हैं ... बस के साथ शुरू करके कि आपके पास बाद में अन्य प्लेटफ़ॉर्म जोड़ने की बहुत बड़ी संभावना है...

@galvesribeiro ,

स्पंदन को देखें ... इसमें एक कोर इंजन है जो किसी भी प्लेटफॉर्म पर कुछ भी प्रस्तुत कर सकता है जो इसका समर्थन करता है।

इसके शीर्ष पर, इसमें ऐसे घटक हैं जो इंजन प्रबंधित परत का उपयोग करके डार्ट पर पूरी तरह से लागू होते हैं और जो पिक्सेल निष्ठा में उस प्लेटफ़ॉर्म और डिज़ाइन भाषा का प्रतिनिधित्व (ड्रा/रेंडर) करते हैं, जिसका आप उदाहरण के लिए उपयोग करना चाहते हैं, Material.io और Apple's Cupertino।

बढ़िया, इसलिए जैसे ही Apple macOS के लिए एक अपडेट जारी करता है, और UI अपडेट (शायद बटन कॉर्नर रेडियस बदल जाता है, या बैकग्राउंड ग्रेडिएंट बदल जाता है, आदि) आपका फ़्लटर एप्लिकेशन अपडेट नहीं होता है और पिछले OS की तरह दिखता रहता है - एक देशी के विपरीत नियंत्रण जो मुफ्त में लाभ प्राप्त करेगा।

@MarkIngramUK अपडेट का समर्थन करने के लिए टीम पर काम है।

जैसे Xamarin टीम 0+1 दिन से अपडेट प्रदान करती है, यह टीम भी ऐसा ही कर सकती है। Google टीम भी यही करती है...

"मूल" नियंत्रण का उपयोग करके, आप ज़ामरीन दुनिया पर फिर से वापस आ गए हैं, क्या आप केवल रैपर (उर्फ रेंडर) थे ...

हम देशी नियंत्रणों के लिए C# बाइंडिंग पर चर्चा नहीं कर रहे हैं (जैसे Xamarin करता है)... हम एक पूर्ण UI ढांचे के बारे में बात कर रहे हैं जैसे आप Flutter के साथ करते हैं...

रिकॉर्ड के लिए, कोई भी किसी भी प्लेटफॉर्म के लिए "डिफ़ॉल्ट" थीम का उपयोग नहीं करता है। वे सभी प्रत्येक प्लेटफ़ॉर्म की डिज़ाइन भाषाओं के शीर्ष पर अपना विशिष्ट UX बनाते हैं।

यदि आप हमेशा मूल घटक के रूप में दिखने के बारे में चिंतित हैं, तो आपके ऐप के पास शायद कभी भी अच्छे दर्शक नहीं होंगे जैसा कि वे देखेंगे ... मेह...

मेरा मानना ​​है कि हम यहां दो अलग-अलग परियोजनाओं के बारे में बात कर रहे हैं। WinUI को Win32 प्रतिस्थापन की आवश्यकता है। लोगों को एक पार मंच समाधान है, जो उचित है के लिए पूछ रहे हैं, लेकिन मुझे नहीं लगता कि यह इस परियोजना होना चाहिए।

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

@MarkIngramUK

मैं सिर्फ स्पष्ट कर रहा हूं कि क्यों WinUI सिर्फ Win32 प्रतिस्थापन नहीं होना चाहिए, बस।

अगर ऐसा है, तो मुझे पूरा यकीन है कि यह यूडब्ल्यूपी की तरह ही निकट भविष्य में गिरेगा ...

मैं सहमत हूं कि @MarkIngramUK WinUI को स्वयं Windows के लिए एक एकीकृत UI प्रदान करने पर ध्यान केंद्रित करना चाहिए, चाहे आप C#, WinRT APIs, Win32 ABI, C++, F#, VB, .NET Core का उपयोग करें या नहीं।

विनयूआई 3.0 में सभी कोड को उठाना और विंडोज ओएस से एक्सएएमएल का प्रतिपादन, और इसे ओएस अपडेट चक्र से स्वतंत्र एक ढांचा बनाना, और इसे ओपन सोर्स बनाना शामिल है।

इसे कैसे उठाया जाता है और फिर से पैक किया जाता है यह अभी भी हवा में है। केवल Microsoft के आंतरिक लोग ही जानते हैं कि वे इसे कैसे करेंगे। एक्सएएमएल के लिए भविष्य के क्रॉस प्लेटफॉर्म समर्थन का समर्थन करने के लिए, मुझे उम्मीद है कि भविष्य में इसे कैसे प्राप्त किया जा सकता है, क्योंकि वे इसे विंडोज़ से निकाल रहे हैं।

.NET कोर पहले से ही अन्य प्लेटफॉर्म पर उपलब्ध है। तो यह पहले से हस्तांतरणीय के पीछे सी # कोड है। यह अब केवल एक्सएएमएल और यूआई और नियंत्रण है, जिसे आईओएस/मैकोज़/एंड्रॉइड/लिनक्स (और भविष्य में जो कुछ भी आ सकता है) के लिए पथ की आवश्यकता है।

शायद WinUI 3.0 के दायरे से बाहर, लेकिन निश्चित रूप से इस परियोजना और प्रयास से जुड़ा हुआ है।

@jesbis @terrajobst @jevansaks

डेस्कटॉप, मोबाइल (Droid, iOS) और वेब पर रेंडर होने वाले .NET Core में UI फ्रेमवर्क लाने के लिए Microsoft की क्या योजनाएं हैं?
इसको लेकर काफी समय से अनिश्चितता बनी हुई है।

@weitzhandler , उनके पास निम्नलिखित पैराग्राफ के साथ पहले से ही एक रोडमैप है :

वेब और क्रॉस-प्लेटफ़ॉर्म ढांचे के लिए एक मूल विंडोज़ लक्ष्य
WinUI 3 को पुस्तकालयों और ढांचे के निर्माण के लिए बेहतर रूप से अनुकूलित किया
उदाहरण के लिए, हम WinUI 3 पर नए उच्च-प्रदर्शन C++ रिएक्ट नेटिव विंडोज कार्यान्वयन को आधार बनाने की योजना बना रहे हैं।

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

तो ठीक है...

/me keep working on FluSharp

जो उचित है, लेकिन मुझे नहीं लगता कि यह परियोजना होनी चाहिए।

यह वहाँ प्यासा है @MarkIngramUK , हमारे अनुमानों को क्षमा करें। मैं

निम्नलिखित पैराग्राफ के साथ

ज्यादा नहीं कहता। यह C# और .NET विकास xplat बनाने के लिए MS के स्पष्ट इरादे को प्रकट नहीं करता है। यह शायद कहता है कि यदि आप पोर्टेबल होना चाहते हैं तो HTML JS और CSS shi{ आपके लिए C# से बेहतर उपकरण हैं।

फिलहाल, Xamarin और Xamarin Forms Windows के बाहर C# और .NET कोर विकास के लिए Microsoft की कहानी है।

विंडोज के लिए रिएक्ट नेटिव जावास्क्रिप्ट कोड और नेटिव यूआई के लिए आ रहा है (जो WinUI 3.0 XAML का उपयोग करेगा)

फिलहाल माइक्रोसॉफ्ट के पास अन्य प्लेटफॉर्म पर विनयूआई 3.0 के एक्सएएमएल लाने की कोई योजना नहीं है।

WinUI परियोजना Win32, WPF, MFC, UWP, .NET Core dev चौखटे को एक आधुनिक XAML प्रस्तुति ढांचे के तहत एकीकृत करने का प्रयास कर रही है।

मुझे लगता है कि उसके बाद, विनयूआई 3.0 के लिए लिखे गए एक्सएएमएल को प्रस्तुत करने के तरीकों को खोजने के लिए काम करना चाहिए - मैकओएस, आईओएस, एंड्रॉइड इत्यादि जैसे प्लेटफॉर्म पर - लेकिन यह अब तक एजेंडा पर नहीं है।

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

F#, .NET के रेडहेड सौतेले बच्चे को प्रथम श्रेणी का नागरिक बनाने की कोई योजना? और फिर लोगों को आश्चर्य होता है कि .NET डेवलपर्स के विशाल बहुमत F# को दस फुट के पोल के साथ क्यों नहीं छूएंगे।

फिलहाल, Xamarin और Xamarin Forms Windows के बाहर C# और .NET कोर विकास के लिए Microsoft की कहानी है।

हाँ, Xamarin.Forms को macOS, GTK, UWP और WPF में पोर्ट किया जा रहा है, साथ ही काम में हर जगह सामग्री डिज़ाइन है, जो इसे वास्तविक .NET UI फ्रेमवर्क बनाता है, लेकिन यह इतना धीमा और छोटा है मुझे आश्चर्य है कि Microsoft क्या सोच रहा है इसके डेवलपर्स के बारे में। बस समस्या सूची को देखें! एक बार गंभीर विकास शुरू होने के बाद, बग बाएं और दाएं हिट होते हैं। मुझे उम्मीद है कि विनयूआई के साथ हम अंततः एक बेहतर विकास अनुभव प्राप्त कर सकते हैं।

संदर्भ#

यदि आपको लगता है कि अन्य नई सुविधाएँ जैसे बेहतर F# समर्थन या नई मार्कअप क्षमताएँ महत्वपूर्ण हैं तो कृपया एक नया सुविधा अनुरोध खोलें ताकि हम उन्हें अलग से ट्रैक कर सकें!

हां, यह हमेशा एफ # होता है जिसे अलग से ट्रैक किया जाता है और फिर से अनदेखा किया जाता है। UWP और .NET नेटिव को ही देखें - दोनों के दिमाग में F# नहीं था और बड़े पैमाने पर समुदाय को सब कुछ पता लगाना था। 4 साल बाद, F# अभी भी .NET नेटिव पर समर्थित नहीं है।

एफ # सुझावों/प्रश्नों के लिए मैंने एक समर्पित मुद्दा बनाया है:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

कृपया बेझिझक एफ # चर्चाओं को वहां निर्देशित करें।

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

आरई: क्रॉस-प्लेटफ़ॉर्म यूआई:

अब तक उठाए गए बिंदुओं के लिए और .NET और Xaml के जुनून के लिए सभी को धन्यवाद।
मैं बस फिर से कहना चाहता हूं कि हम सभी फीडबैक को करीब से सुन रहे हैं, और जैसे-जैसे हम आगे बढ़ेंगे हम अपने विचार और अपडेट साझा करेंगे।

वर्तमान रोडमैप और सामने आए कुछ बिंदुओं की पुष्टि करने के लिए:

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

हमारे अन्य वर्तमान अल्पकालिक लक्ष्यों में से एक विनयूआई को विंडोज़ पर उपयोग करने के लिए अन्य प्लेटफार्मों के लिए एक मूल लक्ष्य के रूप में सेवा करने के लिए सक्षम करना है: उदाहरण के लिए हम react-native-windows सुनिश्चित करने पर भी काम कर रहे हैं - एक उच्च प्रदर्शन सी ++ प्रतिक्रिया मूल कार्यान्वयन विंडोज़ के लिए - WinUI का उपयोग करता है , और यह कि WinUI नियंत्रणों का उपयोग रिएक्ट नेटिव ऐप्स में मूल UI दृश्य बनाने के लिए किया जा सकता है।

मैं पूरी तरह से ईमानदार रहूंगा। मेरे पास एक देशी विंडोज डेस्कटॉप ऐप है जिसे मैंने 2006 में WinForms पर लिखा था कि मैं आज भी ऑनलाइन बेच रहा हूं।

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

वर्तमान में, यह संभवतः Blazor + .NET Core + Electron जैसा दिखेगा।

मुझे लगता है कि @ माइक-ईईई कुछ बेहतरीन बिंदु बनाता है। UX/प्लेटफ़ॉर्म जो मुझे दर्शकों की सबसे बड़ी संख्या तक पहुँचने के लिए अपने C# कौशल का लाभ उठाने की अनुमति देता है, वह अधिक संभावना वाली तकनीक है जिसे मैं चुनूंगा।

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

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

अर्थशास्त्र में, एक वस्तु एक आर्थिक अच्छा या सेवा है जिसमें पूर्ण या पर्याप्त प्रतिरूपता है: अर्थात, बाजार अच्छे के उदाहरणों को समकक्ष या लगभग इतना ही मानता है कि उन्हें किसने उत्पादित किया है। https://en.wikipedia.org/wiki/Commodity

माइक्रोसॉफ्ट को तय करना है, क्या वह डेवलपर टूलिंग स्टोरी का हिस्सा बनना चाहता है? या माइक्रोसॉफ्ट एक नए विंडोज़-ओनली यूएक्स स्टैक में लाखों डॉलर का निवेश करता है जो यूएक्स स्टैक्स के कब्रिस्तान में शामिल हो जाएगा जो कम और कम लोग उपयोग करते हैं?

यह प्रोजेक्ट एक टीम के स्वामित्व में है जिसके पास इस बारे में ज्ञान का खजाना है कि विंडोज इंटर्नल कैसे काम करता है, और यह उनके लिए एक व्याकुलता होगी और यह पता लगाना होगा कि मैक या लिनक्स पर समान डिग्री पर वास्तव में कुछ कैसे काम करना है।

यह सुनिश्चित करने के लिए एक कठिन स्थिति है। लेकिन समय बदल गया है। आज की दुनिया उस दुनिया से बहुत अलग है जो १९९५ में थी। जिस तरह से मैं इसे देखता हूं, वहां कुछ विकल्प हैं:

आप उस ज्ञान को विंडोज़ से आगे बढ़ाने के लिए और लोगों को काम पर रख सकते हैं।

या, विंडोज़ के अंदर यूएक्स प्लंबिंग बनाने के लिए उस टीम के ज्ञान का उपयोग करें जो विंडोज़ पर बेहतर चलने के लिए क्रॉस-प्लेटफ़ॉर्म यूआई एप्लिकेशन फ्रेमवर्क के लिए संगतता को बढ़ाता है।

ठीक वैसे ही जैसे WSL ने विंडोज़ पर लिनक्स चलाने के लिए किया था।

• जीटीके को 200 गुना तेज चलाने के लिए टीम के ज्ञान का उपयोग करें।
• क्यूटी ऐप्स को 200 गुना तेज चलाने के लिए टीम के ज्ञान का उपयोग करें।
• किसी भी अन्य OS की तुलना में इलेक्ट्रॉन ऐप्स को तेज़ी से रेंडर करने के लिए टीम के ज्ञान का उपयोग करें।

विंडोज क्रॉस-प्लेटफॉर्म यूएक्स संगतता कहानी को बढ़ाने के लिए बहुत सारे काम किए जा सकते हैं। लेकिन एक बिल्कुल नए UX स्टैक में निवेश करना और आशा करना कि हम सभी स्विच करें (बिना किसी क्रॉस-प्लेटफ़ॉर्म कहानी के) एक बहुत बड़ा दांव है। केवल विंडोज़ के लिए नए यूएक्स ढांचे बनाने की इस आदत को तोड़ना होगा।

केवल मेरे दो सेंट्स। :पैसे का बैग:

:horse_racing: :cowboy_hat_face: लिल नास एक्स - ओल्ड टाउन रोड (आधिकारिक मूवी) फीट। बिली रे साइरस

@bchavez

केवल विंडोज़ के लिए नए यूएक्स ढांचे बनाने की इस आदत को तोड़ना होगा।

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

आरई: क्रॉस-प्लेटफ़ॉर्म यूआई:

... विनयूआई विंडोज के लिए नेटिव यूआई प्लेटफॉर्म है (_ देशी ऐप्स सहित _, न कि सिर्फ .NET) और शुरुआती 3.0 वर्जन के लिए हम मुख्य रूप से इसे ओएस से स्वतंत्र बनाने और इसे ओपन सोर्स के लिए तैयार करने की दिशा में काम कर रहे हैं। तेजी से रिलीज चक्र पर विकास। हम यह सुनिश्चित करना चाहते हैं कि इस वर्ष एक पूर्वावलोकन प्राप्त करने के लिए गुंजाइश पर्याप्त है।

फ्लुएंट/फैब्रिकवेब नियंत्रण शैलियों से बेहतर मिलान करने के लिए WinUI 3.0 के साथ चल रहे WinForms, MFC, WPF नियंत्रणों के विज़ुअल लुक को अपडेट करने के विचार के लिए +1 जोड़ें।

निश्चित रूप से अलग-अलग नियंत्रण आकार (कुछ भी नहीं जो WinRT XAML को अपने मेट्रिक्स से UWP नियंत्रणों के कॉम्पैक्ट संस्करण से मेल खाना चाहिए) लेकिन एक सुसंगत और सुसंगत पॉलिश लुक।

WinForms में WinUI 3.0 निर्भरता जोड़ें और नियंत्रण बदल जाते हैं।

WinUI 3.0 wpf ऐप्स Fluent.Light.xaml या Fluent.Dark.xaml कंट्रोल थीम्स का पता लगाते हैं और उनका उपयोग करते हैं।

@weitzhandler मैं आपकी भावना को समझता हूं। मुझे आशा है कि कभी भी जावास्क्रिप्ट को स्पर्श नहीं करना पड़ेगा, और इस क्रॉस-प्लेटफ़ॉर्म जीयूआई को करने के लिए समान है। मैं इलेक्ट्रॉन, कोणीय, डार्ट, स्पंदन का उपयोग करके एक परियोजना शुरू करने के बारे में सोचना भी नापसंद करता हूं।
मुझे उम्मीद है कि हमारे पास जल्द ही .NET 5 के साथ एक समाधान हो सकता है, जो यूनिवर्सल एक्सएएमएल सपना लाएगा। Microsoft XAML जीत सकता है, वेब, मोबाइल, डेस्कटॉप और IoT।
कई उपयोग के मामलों के लिए सिल्वरलाइट ने लगभग ऐसा ही किया ।

केवल विंडोज़ के लिए नए यूएक्स ढांचे बनाने की इस आदत को तोड़ना होगा।

यदि हमें क्रॉस-प्लेटफ़ॉर्म समर्थन (सभी प्लेटफ़ॉर्म पर अनिवार्य रूप से समझौता) के लिए प्रतीक्षा करनी पड़े, तो WinUI 3.0 कभी रिलीज़ नहीं होगा। विनयूआई विंडोज़ पर निम्नतम स्तर का यूआई फ्रेमवर्क होना चाहिए, और यदि आप क्रॉस-प्लेटफ़ॉर्म क्षमता चाहते हैं, तो उसके ऊपर निर्माण करें (या रिएक्ट नेटिव, ज़ामरीन, आदि का उपयोग करें)।

केवल विंडोज़ के लिए नए यूएक्स ढांचे बनाने की इस आदत को तोड़ना होगा।

मैं केवल यह स्पष्ट करना चाहता हूं कि हम WinUI 3.0 के साथ एक नया UI ढांचा बनाने की कोशिश नहीं कर रहे हैं।

हमारा प्रारंभिक लक्ष्य है:

• मौजूदा आधुनिक देशी तकनीकों (Windows 10 Xaml UI और कंपोज़िटर) को OS से अलग करके और मौजूदा ऐप मॉडल (win32 और UWP), भाषाओं, अन्य फ्रेमवर्क (द्वीपों के माध्यम से) और विंडोज संस्करणों में काम करने के लिए सक्षम करने के लिए बाधाओं को दूर करें।

• ओपन सोर्स होने के लिए हमारी इंजीनियरिंग प्रक्रिया को अपडेट करें

यदि हमें क्रॉस-प्लेटफ़ॉर्म समर्थन (सभी प्लेटफ़ॉर्म पर अनिवार्य रूप से समझौता) के लिए प्रतीक्षा करनी पड़े, तो WinUI 3.0 कभी रिलीज़ नहीं होगा।

यार... यदि आप वास्तव में उस पर विश्वास करते हैं, तो आपका मतलब है कि फ़्लटर जैसे सफल ढांचे काम नहीं करते हैं...

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

मैं निराश हूं कि विनयूआई केवल विंडोज़ चीजें बन जाएगा ...

.Net को एक UI फ्रेमवर्क की आवश्यकता होती है जो .Net कोर क्रॉस प्लेटफॉर्म क्षमताओं की उत्कृष्टता से मेल खाता हो, जैसे हमें अभी-अभी वेब के लिए Blazor (क्लाइंट और सर्वर-साइड) के साथ मिला है।

मुझे लगता है कि अभी के लिए, हमें अभी भी समुदाय संचालित प्रयासों पर निर्भर रहना है।

मैं समझता हूं कि आपकी टीम क्या करने की कोशिश कर रही है @jesbis... यह सिर्फ इतना है कि हम में से बहुत से लोग .Net/C++/UWP/MFC/Windows पर UI देखकर थक गए हैं, एक _silo_'ed चीज़ जो केवल विंडोज़ पर चलती है जबकि पूरी दुनिया (Apple और OSX को छोड़कर) विपरीत दिशा में जा रहे हैं जो डेवलपर्स को बेहतर और बेहतर क्रॉस प्लेटफॉर्म समाधान प्रदान करते हैं। जैसा कि आपने रिएक्ट और रेक्ट-नेटिव का उल्लेख किया है (रिकॉर्ड के लिए मुझे या तो पसंद नहीं है, केवल यह उल्लेख करते हुए कि वे विकसित हो रहे हैं)।

तो अब हमारे पास केवल समुदाय संचालित पहल जैसे अवलोनिया या यहां तक ​​​​कि यूनो और अन्य ढांचे (जैसे फ्लूशर्प जो मैं उल्लेख के अनुसार काम कर रहा हूं) जो स्पष्ट कारणों से बहुत धीमी गति से विकसित होते हैं ...

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

(सभी प्लेटफार्मों पर अनिवार्य रूप से समझौता) क्रॉस-प्लेटफ़ॉर्म समर्थन

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

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

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

मुझे लगता है कि बड़ी चिंता यह है कि दीर्घकालिक योजनाएं वास्तव में क्या हैं। @jesbis की प्रतिक्रियाओं के आधार पर ऐसा लगता है कि वे अभी केवल अल्पकालिक पर ध्यान केंद्रित कर रहे हैं, और दीर्घकालिक योजनाएँ अभी भी चर्चा के लिए खुली हैं।

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

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

मुद्दा यह है ... जैसा कि material.io और क्यूपर्टिनो के साथ है, हम (और मुझे आश्चर्य नहीं है अगर Google पहले से ऐसा नहीं कर रहा है!) धाराप्रवाह डिजाइन भाषा के लिए स्पंदन पर "थीम" है ...

और यह मेरी बात है जब मैंने कहा कि वास्तव में क्रॉस-प्लेट यूआई फ्रेमवर्क इसकी परवाह नहीं करेगा और बस काम करेगा, जैसे फ़्लटर करता है ... मुझे नहीं लगता कि हमने उस पर समझौता किया है ...

@weitzhandler मुझे देशी ऐप्स के लिए HTML पसंद नहीं है। अन्यथा मैं प्रतिक्रिया . के साथ इलेक्ट्रॉन का उपयोग कर रहा होता

मैं यहाँ सिर्फ भावुक नहीं हो रहा हूँ, और इसके बजाय सिर्फ तर्कसंगत हूँ।

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

मेरा सुझाव है कि यहां के उपयोगकर्ताओं को बिल्ड 2019 के बाद स्कॉट हंटर को सुनने के लिए समय दें कि कैसे विन यूआई, ज़ामरीन फॉर्म, यूएनओ, वेब असेंबली एक साथ आ सकते हैं।

.NET कोर 3 और स्कॉट हंटर के साथ परे @.NET रॉक

Xamarin फॉर्म (XAML) और UNO (XAML) दोनों को क्रॉस प्लेटफॉर्म के विजन के साथ बनाया गया था। यूएनओ के मामले में (वेब ​​असेंबली के माध्यम से वेब के लिए आईओएस, एंड्रॉइड, एक्सएएमएल के अलावा)।

UWP को Microsoft पारिस्थितिकी तंत्र जैसे वेब, Android, iOS से परे किसी भी दृष्टि के साथ नहीं बनाया गया था। UWP को धीरे-धीरे अपनाने के कारण सभी प्रभावशाली फ़्लुएंट डिज़ाइन प्रयासों में बहुत कम समय लगता है

जैसा कि @ माइक-ईई ने बताया, Droid और iOS में 2 ~ और 1.5 ~ बिलियन हैं जबकि Win10 में 0.9 बिलियन हैं। जिनमें से अधिकांश डेवलपर्स अभी भी WinForm और wpf से UWP में कूदने के लिए अनिच्छुक हैं।

क्यों? UWP नियंत्रण, वाणिज्यिक और Microsoft से, अपूर्ण हैं !!!!! विनफॉर्म और डब्ल्यूपीएफ में उन लोगों की तुलना में। उस संक्रमण में मदद करने के लिए Microsoft द्वारा कोई प्रयास नहीं किया गया है। XAML द्वीप इसे तब तक संबोधित नहीं करेगा जब तक कि Microsoft में BLIND SPOT नहीं है क्योंकि डेवलपर्स को WinForm और wpf से UWP में संक्रमण की आवश्यकता है।

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

ऐसा ही एक कंट्रोल है डायग्राम कंट्रोल । सभी डेटा गहन व्यवसाय ऐप को UWP के लिए आरेख नियंत्रण की आवश्यकता होती है।

==> मैं UWP UI को अलग करने की आवश्यकता को समझता हूं। यह केवल फ़्लुएंट डिज़ाइन ब्रांडिंग को अन्य प्लेटफ़ॉर्म जैसे आईओएस, एंड्रॉइड, वेब पर फैलाने के लिए समझ में आता है।
==> कृपया बेहतर 3D मॉडल नियंत्रण और आरेख नियंत्रण (2D/3D दोनों) प्रदान करने पर ध्यान दें

यह केवल NET5 के लिए रुकने और प्रतीक्षा करने के लिए समझ में आता है जब सभी बीसीएल (मोनो को विंडोज़ के मूल के साथ विलय कर दिया जाता है, वेब असेंबली आदि के लिए), क्योंकि मुझे होलोलेंस रचनात्मक 3D UI का भविष्य दिखाई देता है।

उसके लिए हमें UWP और 3D मॉडल नियंत्रण के लिए

@jesbis मैं आपसे UWP के लिए Win UI के इन यूएसपी (अद्वितीय विक्रय बिंदु) में अधिक लोगों को शामिल करने का आग्रह करता हूं।

@weitzhandler

यह समस्या WinUI 3.0 रोडमैप पर चर्चा करने के लिए बनाई गई थी।

@jesbis ने एक स्पष्ट बयान दिया :

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

आपकी पहली दो टिप्पणियाँ विषय पर थीं।

निम्नलिखित छह अनुत्पादक और अपमानजनक के संयोजन थे, और आप Microsoft ओपन सोर्स आचार संहिता को तोड़ने के करीब हैं।

यह Microsoft के साथ एक उत्पादक, पेशेवर बातचीत बनी रहनी चाहिए।

// मैं पूरे दिन किसी न किसी लड़के को सुनने के लिए इस बातचीत का अनुसरण नहीं कर रहा हूं।

मुझे लगता है कि यहां कुछ बेहतरीन टिप्पणियां हैं, हालांकि ऐसा लगता है कि दो अलग-अलग चर्चाएं हो सकती हैं। मैं इसे छोटा रखूंगा क्योंकि इसमें से अधिकांश पहले ही कहा जा चुका है।

क्रॉस प्लेटफॉर्म और वेब

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

सुनिश्चित नहीं है कि Xamarin वह प्लेटफ़ॉर्म हो सकता है, लेकिन यदि ऐसा है - सुनिश्चित करें कि Xaml को WinUI और Xamarin में जितना संभव हो सके संरेखित किया गया है।

विनयूआई

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

HoloLens और परे

लाइट के आने के साथ, और HoloLens जैसे नए सुपर रोमांचक फॉर्म कारक यह तर्क दे सकते हैं कि UI के संदर्भ में UWP इसके लिए तैयार नहीं है। हां, हम उन्हें HoloLens पर चला सकते हैं जो कि अच्छा है, लेकिन मैं पूर्ण एकता के बिना 3D के लिए ऐप्स को वास्तव में अनुकूलित करने का एक तरीका देखना चाहता हूं।

WinUI Xamarin से काफी आगे है। लेकिन Microsoft टीम ने Xamarin 4.0 को बाहर कर दिया...
मैं व्यक्तिगत रूप से ज़ामरीन की तरह हूं क्योंकि यह क्रॉस प्लेटफॉर्म के लिए सबसे कम मूल्यवर्ग है, भविष्य में सास के लिए मूल ऐप्स की संख्या बढ़ने वाली है।

Xamarin के अलावा, कुछ विकल्प है।
1) क्यों न यूएनओ प्लेटफॉर्म को अपनाया जाए और स्कीयाशर्प का उपयोग करके वेब रेंडरिंग की जाए?
2) @ zezba9000 आपको एक अज्ञेयवादी प्रतिपादन बैकएंड की आवश्यकता है जैसे गेम इंजन शुरू करने के लिए उपयोग करते हैं। असल में मैं इसे स्वीकार करता हूं ....

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

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

@jkoritzinsky , एक बात WinUI टीम को WinUI 3.0 नाम बदलने के साथ देखना चाहिए: यदि आप .NET में प्रक्षेपित किसी भी प्रकार का नाम बदलते हैं, तो अनुमान काम नहीं करेंगे (और हम और जोड़ने की योजना नहीं बना रहे हैं चूंकि यह एक रखरखाव योग्य एक्स्टेंसिबल सिस्टम नहीं है)। यहां उन प्रकारों की सूची दी गई है जिन्हें हम प्रोजेक्ट करते हैं: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

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

मैं सहमत हूं और मुझे खुशी है कि आपने इस मुद्दे को उठाया, हालांकि मैं यह जोड़ना चाहता हूं कि मुझे लगता है कि ये अनुमान एक दुर्भाग्यपूर्ण बुराई हैं। हम हर एक एपीआई को प्रोजेक्ट नहीं करते हैं जो शायद होना चाहिए (System.IO APIs के बारे में सोचते हुए), इसलिए हमें या तो इसका समाधान करना चाहिए, या अलग तरीके से सोचना चाहिए। एक बात जो दिमाग में आती है, वह है किसी भिन्न नामस्थान में .NET प्रकारों में समान, लेकिन भिन्न प्रकारों को नहीं जोड़ना। इसके बजाय, हमें अपने C++ डेवलपर्स को System.ComponentModel.INotifyDataErrorInfo का भी उपयोग करने में सक्षम बनाना चाहिए। हमने सी ++/सीएलआई के साथ ऐसा किया है, लेकिन इसके लिए शुद्ध सी ++ एप्लिकेशन के लिए सीएलआर लोड करने की आवश्यकता नहीं होगी। मुझे नहीं पता कि यह अधिक भ्रमित करने वाला होगा, लेकिन ऐसा लगता है कि हम एपीआई परत पर .NET और WinRT तकनीकों में मूलभूत और अंतर्निहित अंतरों को लीक कर रहे हैं, जिससे चीजें असंगत महसूस होती हैं।

@ मीर-प्लेटिंस्की। NET केवल एक ढांचा है जिसका उपयोग आप UWP XAML के साथ ऐप्स बनाने के लिए कर सकते हैं। वे चाहते हैं कि टेक्स्ट फ़ील्ड सत्यापन देवों के लिए उपलब्ध हो, चाहे वे किसी भी ढांचे का उपयोग करें

यह पैसे पर सही है, हमारे पास सी ++ डेवलपर्स हैं जिनकी हम परवाह करते हैं। हालांकि जैसा कि मैंने ऊपर उल्लेख किया है, मुझे अच्छा लगेगा कि हम .NET समुदाय में भ्रम पैदा न करें ताकि ऐसा हो सके।

@mdtauk , नहीं, WinUI डेस्कटॉप (पहले Xaml डेस्कटॉप) आपको द्वीप के उपयोग के बिना सीधे Win32 के साथ Xaml का उपयोग करने की अनुमति देता है।

मुझे लगता है कि @ meir-pletinsky .NET/C++ का जिक्र कर रहा था, जब तक कि मुझे कुछ याद नहीं आ रहा है?

@MarkIngramUK मेरा मानना ​​​​है कि हम यहां दो अलग-अलग परियोजनाओं के बारे में बात कर रहे हैं। WinUI को Win32 प्रतिस्थापन की आवश्यकता है। लोग एक क्रॉस-प्लेटफ़ॉर्म समाधान मांग रहे हैं, जो उचित है, लेकिन मुझे नहीं लगता कि यह _this_ प्रोजेक्ट होना चाहिए।

हाँ, मैं पूरी तरह सहमत हूँ! मेरे लिए, विनयूआई विंडोज के लिए सबसे आधुनिक, प्रदर्शनकारी, बस सर्वश्रेष्ठ यूआई को परिभाषित करने के बारे में है। Xamarin Microsoft से क्रॉस-प्लेटफ़ॉर्म कहानी होनी चाहिए और इसे WinUI के शीर्ष पर विकसित होना चाहिए।

@mdtauk

फ्लुएंट/फैब्रिकवेब नियंत्रण शैलियों से बेहतर मिलान करने के लिए WinUI 3.0 के साथ चल रहे WinForms, MFC, WPF नियंत्रणों के विज़ुअल लुक को अपडेट करने के विचार के लिए +1 जोड़ें।

निश्चित रूप से अलग-अलग नियंत्रण आकार (कुछ भी नहीं जो WinRT XAML को अपने मेट्रिक्स से UWP नियंत्रणों के कॉम्पैक्ट संस्करण से मेल खाना चाहिए) लेकिन एक सुसंगत और सुसंगत पॉलिश लुक।

WinForms में WinUI 3.0 निर्भरता जोड़ें और नियंत्रण बदल जाते हैं।

WinUI 3.0 wpf ऐप्स Fluent.Light.xaml या Fluent.Dark.xaml कंट्रोल थीम्स का पता लगाते हैं और उनका उपयोग करते हैं।

मैं वास्तव में उन ढांचे में एमएस निवेश समय और संसाधनों को मूल विंडोज 10 ऐप्स की तरह दिखने के लिए नहीं देखना चाहता हूं। इसलिए इसमें WinUI 3.0 होगा। आप चाहते हैं कि विंडोज 10 WPF/WinForms ऐप्स में दिखे और महसूस करें? विनयूआई 3.0 का प्रयोग करें।
एमएस को अपने संसाधनों को यूडब्ल्यूपी/विनयूआई और उनके Win32 समकक्षों के बीच मौजूदा (और अवरुद्ध) अंतराल को बंद करने के बजाय अपने पुराने ढांचे पर फिर से जाने के बजाय निवेश करना चाहिए। विशेष रूप से यह देखते हुए कि विनयूआई विंडोज़ के लिए _the_ प्रेजेंटेशन फ्रेमवर्क बनने के लिए है ...

मैं विनयूआई और यूआई/यूएक्स पर माइक्रोसॉफ्ट के इरादों पर स्पष्टीकरण मांगना चाहता हूं:

1. क्या WinUI निम्नलिखित में से सभी को प्रतिस्थापित करता है (काल्पनिक रूप से?): Win32, ATL, MFC, WinForms, Silverlight (मुझे पता है), WPF, UWP और/या XAML द्वीप समूह? मैं मानता हूं कि ये प्रौद्योगिकियां मौजूद रहेंगी, और कुछ अनिश्चित समय के लिए समर्थित होती रहेंगी ; मैं केवल यह स्पष्ट रूप से समझना चाहता हूं कि माइक्रोसॉफ्ट जो कह रहा है वह "आगे बढ़ने का रास्ता" है, और वह (उदाहरण के लिए), हमें WinForms और wpf पर उसी तरह विचार करना चाहिए जैसा हम Win32 या MFC मानते हैं।

2. क्या WinUI UWP से प्राप्त होता है? (या, दोनों कितने समान हैं?) यूडब्ल्यूपी, एक्सएएमएल द्वीप समूह, या डब्ल्यूपीएफ की तुलना में विनयूआई कितना समान (या अलग) है?

एक पेशेवर C# और C++ डेवलपर के रूप में, मैंने WinForms के साथ काम करना शुरू किया, और फिर wpf में चला गया, और फिर WinForms में वापस चला गया, क्योंकि मैं WinForms में व्यावसायिक उद्देश्यों के लिए UI/UX को लगभग दोगुना तेजी से डिजाइन कर सकता था जितना कि मैं wpf में कर सकता था। डब्ल्यूपीएफ ने बहुत अधिक लचीलापन, प्रदर्शन दिया, और बहुत बेहतर दिख रहा था- लेकिन जैसे ही किसी ने एक्सएएमएल को हाथ से संपादित करने के बजाय डिज़ाइनर के माध्यम से इंटरफ़ेस को छुआ, एक्सएएमएल मैंगलिंग भयानक थी। कुछ मामलों में, मुझे लगता है कि WinForms (डिजाइनर का उपयोग करके) एक एक्सएएमएल फॉर्म या नियंत्रण जो समान था, को हाथ से बनाने की तुलना में तेजी से परिमाण के आदेश थे।

व्यक्तिगत रूप से, मुझे एक ऐसा UI पसंद आएगा जो उपलब्ध हो और Microsoft के सभी उत्पादों में समान हो। एक फ्रेमवर्क जिसका समान रूप से Win32 या .NET द्वारा लाभ उठाया जा सकता है, का अर्थ होगा सभी Microsoft डेवलपर्स के लिए सुसंगत, आधुनिक दिखने वाले एप्लिकेशन, और इसका अर्थ यह भी होगा कि सामान्य प्रश्नों और समस्याओं को उन सत्रों में हल किया जा सकता है जो एकल तकनीक को लक्षित करते हैं—उदाहरण के लिए, जब एक नियंत्रण के बारे में कोई प्रश्न पूछा जाता है, तो Win32 डेवलपर या .NET डेवलपर के लिए उत्तर समान (यदि लगभग समान नहीं है) होगा। यह सीखने को "WinUI" को किसी भी दिए गए डेवलपर के लिए स्टैक के लिए उपयोगी बना देगा, और ऑनलाइन जानकारी तक पहुंच (StackOverflow, आदि) को और अधिक मूल्यवान बना देगा, चाहे आप कहीं भी विकास कर रहे हों। हालांकि मैं Xamarin का उपयोग नहीं करता, अगर Xamarin को इन चरणों में पालन करने के लिए बनाया जा सकता है (WinUI के विस्तार के रूप में?), तो उपरोक्त कथन न केवल विंडोज डेवलपर्स पर लागू किया जा सकता है, बल्कि एंड्रॉइड, आईओएस आदि को लक्षित करने वालों पर भी लागू किया जा सकता है।

मैं किस प्रकार के अनुप्रयोगों के लिए WinUI का उपयोग करने के लिए उत्साहित होऊंगा?

यदि WinUI के बारे में मेरी समझ सही है, और यह "आगे बढ़ने का रास्ता" है, तो Win32, MFC, Forms, WPF, आदि की जगह ले रहा है, और वही ढांचा मूल या .NET विकास के लिए उपलब्ध है, तो मैं उत्सुकता से रचना को बदल दूंगा मेरे द्वारा समर्थित एप्लिकेशन के _ ALL _ में। आधुनिक, सुसंगत UI, प्लेटफ़ॉर्म या स्टैक की परवाह किए बिना वही काम (और व्यवहार) करते हैं? क्या हम सब यही नहीं चाहते? मुझे नहीं लगता कि कोई भी यह याद रखना चाहता है कि कैसे दोनों CreateWindowEx() और Win32 में ईवेंट भेजने के लिए एक संदेश लूप चलाएं, जबकि WinForms या wpf में घटनाओं को पूरी तरह से अलग तरीके से प्रबंधित करें। यह कुछ "आधुनिक" का समय है। मैं वास्तव में आशा करता हूं कि WinUI (3.0) यही है।

ओएस संगतता और डाउनलेवल समर्थन

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

क्या WinUI को स्टैटिकली-लिंक करने योग्य या एम्बेड करने योग्य (जैसे .NET Core/5) एक विकल्प बना रहा है? हमें विंडोज 8.1, विंडोज 8, विंडोज 7—यहां तक ​​कि विंडोज पीई को भी लक्षित करना होगा। हम उन आवश्यकताओं के साथ WinUI का उपयोग कैसे कर सकते हैं?

@शिडेल :

क्या WinUI UWP से प्राप्त होता है? (या, दोनों कितने समान हैं?) यूडब्ल्यूपी, एक्सएएमएल द्वीप समूह, या डब्ल्यूपीएफ की तुलना में विनयूआई कितना समान (या अलग) है?

WinUI 3.0 एक तरह से विंडोज 10/UWP के UI प्लेटफॉर्म घटकों का अगला संस्करण होगा, जिसमें Xaml प्लेटफॉर्म, कंपोजिशन और इनपुट शामिल हैं। यह उस कोडबेस से आता है।

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

क्या WinUI निम्नलिखित में से सभी को प्रतिस्थापित करता है (काल्पनिक रूप से?): Win32, ATL, MFC, WinForms, Silverlight (मुझे पता है), WPF, UWP और/या XAML द्वीप समूह? मैं मानता हूं कि ये प्रौद्योगिकियां मौजूद रहेंगी, और कुछ अनिश्चित समय के लिए समर्थित होती रहेंगी; मैं केवल यह स्पष्ट रूप से समझना चाहता हूं कि माइक्रोसॉफ्ट जो कह रहा है वह "आगे बढ़ने का रास्ता" है, और वह (उदाहरण के लिए), हमें WinForms और wpf पर उसी तरह विचार करना चाहिए जैसा हम Win32 या MFC मानते हैं।

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

Xaml द्वीप WinUI का हिस्सा होंगे, और मौजूदा ऐप्स (जैसे WPF, WinForms) में नए दृश्य बनाने के लिए आपको WinUI का उपयोग करने में सक्षम बनाएंगे।

1703 से अधिक पुराने प्लेटफॉर्म पर WinUI उपलब्ध कराने के बारे में क्या चर्चा हो रही है, जो मुझे लगता है कि वर्तमान में लक्षित सबसे बड़ा प्लेटफॉर्म है?
क्या WinUI को स्टैटिकली-लिंक करने योग्य या एम्बेड करने योग्य (जैसे .NET Core/5) एक विकल्प बना रहा है? हमें विंडोज 8.1, विंडोज 8, विंडोज 7—यहां तक ​​कि विंडोज पीई को भी लक्षित करना होगा। हम उन आवश्यकताओं के साथ WinUI का उपयोग कैसे कर सकते हैं?

इस पर प्रतिक्रिया साझा करने के लिए धन्यवाद। 3.0 के लिए हम रोडमैप (1703+, 8.1 पर कुछ समर्थन के साथ) में प्लेटफॉर्म पर ध्यान केंद्रित कर रहे हैं। हम निश्चित रूप से समझते हैं कि डेवलपर्स के पास अन्य संस्करणों पर भी ग्राहक हैं, और यह कुछ ऐसा है जिसका हम आगे मूल्यांकन करने की योजना बना रहे हैं।

बहुत बढ़िया—ऐसा लगता है कि WinUI "आगे बढ़ने का रास्ता" है, और इसकी इस समझ को देखते हुए, यह कहना कि मैं उत्साहित हूं, एक अल्पमत होगा।

विशेष रूप से, मुझे लगता है कि यह शानदार है कि XAML द्वीपसमूह डेवलपर्स को WinUI को पुरानी तकनीक, जैसे wpf और WinForms में विस्तारित करने की अनुमति देगा। पुरानी (एर) परियोजनाओं पर काम/विस्तार करते समय यह एक महान पुल "आगे" है।

बहुत बढ़िया—ऐसा लगता है कि WinUI "आगे बढ़ने का रास्ता" है, और इसकी इस समझ को देखते हुए, यह कहना कि मैं उत्साहित हूं, एक अल्पमत होगा।

विशेष रूप से, मुझे लगता है कि यह शानदार है कि XAML द्वीपसमूह डेवलपर्स को WinUI को पुरानी तकनीक, जैसे wpf और WinForms में विस्तारित करने की अनुमति देगा। पुरानी (एर) परियोजनाओं पर काम/विस्तार करते समय यह एक महान पुल "आगे" है।

मैं यह सोचना चाहता हूं कि WinUI 3.0 के साथ WinForms, MFC, या wpf प्रोजेक्ट बनाया गया था या नहीं - वे एक फॉर्म/डब्ल्यूपीएफ विंडो/एचडब्ल्यूएनडी विंडो में एक्सएएमएल द्वीप का उपयोग किए बिना एक्सएएमएल पेज/सामग्री/विंडो प्रस्तुत कर सकते हैं।

केवल शुद्ध एक्सएएमएल का उपयोग करने की क्षमता, या एक्सएएमएल को प्रदान की गई सतहों में एक्सएएमएल रखने के लिए एक द्वीप का उपयोग करने की क्षमता - वास्तव में WinUI 3.0 को "उन सभी पर शासन करने के लिए एक यूआई" बना देगा।

वास्तव में WinUI 3.0 "उन सभी पर शासन करने वाला एक UI" बना देगा

... विंडोज़ पर। मैं

WinUI 3.0 एक तरह से विंडोज 10/UWP के UI प्लेटफॉर्म घटकों का अगला संस्करण होगा, जिसमें Xaml प्लेटफॉर्म, कंपोजिशन और इनपुट शामिल हैं। यह उस कोडबेस से आता है।

उस नोट पर, @jesbis , मैं सोच रहा हूं कि क्या आप बोल सकते हैं कि

निश्चित रूप से एक प्रयास किया गया था , लेकिन विकसित होने में पूरे दो साल लगने के बावजूद

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

वास्तव में WinUI 3.0 "उन सभी पर शासन करने वाला एक UI" बना देगा

... विंडोज़ पर। मैं

कम से कम WinUI 3.0 की रिलीज़ विंडो के लिए। मुझे उम्मीद है कि यह एक्सएएमएल प्रतिपादन को अन्य प्लेटफॉर्म पर लाने की प्रक्रिया की शुरुआत हो सकती है ...

मैं सोच रहा हूं कि क्या आप बोल सकते हैं कि डब्ल्यूपीएफ और यूडब्ल्यूपी के बीच एकीकरण कैसे होगा। विशेष रूप से, मार्कअप एक्सटेंशन जैसी अवधारणाओं के साथ, जो हम यूडब्ल्यूपी में वर्षों से मांग रहे हैं, बहुत कम सफलता के साथ। [...] क्या यह सुनिश्चित करने का प्रयास है कि नए यूडब्ल्यूपी-आधारित विनयूआई 3.0 मार्कअप में डब्ल्यूपीएफ के साथ पूर्ण निष्ठा होगी?

@ माइक-ईईई डब्ल्यूपीएफ के साथ पूर्ण निष्ठा 3.0 के लिए लक्ष्य नहीं है। हालांकि हम समय के साथ अंतराल को बंद करने के लिए कई कार्य आइटम ट्रैक कर रहे हैं (उदाहरण के लिए #741 मार्कअप एक्सटेंशन सुधार - कृपया एक नज़र डालें और इस पर एक टिप्पणी छोड़ दें कि क्या यह आपकी आवश्यकताओं को पूरा करेगा!) और डब्ल्यूपीएफ से परे विनयूआई का विस्तार करना जारी रखें (उदाहरण के लिए # 686 3डी मॉडल सपोर्ट)।

यदि डब्ल्यूपीएफ में अन्य विशिष्ट विशेषताएं हैं जो आप चाहते हैं/विनयूआई में उपयोग करने की आवश्यकता है तो कृपया उनके लिए नए फीचर प्रस्ताव मुद्दों को खोलने के लिए स्वतंत्र महसूस करें, या हाल ही में " WPF सुविधाओं जो WinRT XAML में होनी चाहिए " अंक # 719 में टिप्पणी करें। हमारे पास अनंत संसाधन नहीं हैं लेकिन हम निश्चित रूप से अपनी योजना में सामुदायिक इनपुट का हिसाब रखने की कोशिश कर रहे हैं। एक बार जब सब कुछ खुला स्रोत हो जाता है तो किसी के लिए भी संभावित योगदान सुविधाओं में मदद करने का अवसर होगा।

यह उत्साहजनक है, @jesbis इसे साझा करने के लिए धन्यवाद। मैंने उस मुद्दे पर ग्राहकों को इंगित करने के लिए UserVoice पर प्रासंगिक वोट अपडेट किए हैं।

मुझे लगता है कि मेरी उत्कृष्ट चिंता यह है कि यदि पूर्ण wpf निष्ठा एक लक्ष्य नहीं है, जबकि WinUI को wpf _is_ लक्ष्य के भीतर उपयोग किया जाता है, तो आपको wpf अपनाने के साथ घर्षण का सामना करना पड़ेगा, क्योंकि इसमें बेहतर (और मूल) Xaml मॉडल है।

यही है, WinUI3.0 को wpf में शामिल करने के लिए एक स्पष्ट मूल्य प्रस्ताव प्रतीत नहीं होता है, वैसे ही Xaml द्वीप में स्पष्ट मूल्य प्रस्ताव नहीं है। दिन के अंत में, ऐसा लगता है कि आप एक स्थापित/अवर/अविकसित Xaml मॉडल को स्थापित और बेहतर Xaml मॉडल में लाने का प्रयास कर रहे हैं, जिसका कोई मतलब नहीं है।

WinForms, MFC, आदि में उपयोग के मामलों के लिए, हाँ यह दृष्टिकोण WinUI3.0 के लिए समझ में आता है। हालांकि, डब्ल्यूपीएफ के साथ, इसका एक बेहतर प्रस्तुति मॉडल और डेवलपर/डिजाइनर प्रतिमान है जो एमएसएफटी या बाहरी विक्रेताओं द्वारा किसी अन्य पहल से मेल नहीं खाता है।

@ माइक-ईईई स्कॉट हंटर की बात पर आधारित है, यह मुझे लगता है, जो गलत हो सकता है, कि "वन बीसीएल टू रूल इन ऑल" का लक्ष्य "उन सभी पर शासन करने के लिए एक यूआई" की तुलना में उच्च प्राथमिकता पर आता है।

मोनो अंतर्निहित Xamarin प्रपत्र XAML और UNO XAML को वेब में प्रतिस्थापित करके, हालांकि वेब असेंबली में AoC वाले एक सामान्य BCL के साथ, Xamarin प्रपत्र XAML पर आधारित ऐप्स, वेब पर Uno XAML गति प्रदर्शन से सभी लाभान्वित होंगे।

यह गति प्रदर्शन उन सभी के लिए महत्वपूर्ण है जो अपने करियर के भविष्य की परवाह करते हैं, अन्य तकनीकों जैसे स्पंदन, प्रतिक्रिया आदि से आने वाली तीव्र प्रतिस्पर्धा के मद्देनजर क्रॉस प्लेटफॉर्म के लिए C# में निवेश करते हैं।

उम्मीद है, .NET5 = उन सभी पर शासन करने के लिए एक सामान्य बीसीएल की ओर इस यात्रा में, XAML मानकीकरण को प्रक्रिया के साथ, आंशिक रूप से या पूरी तरह से ध्यान रखा जाता है, लेकिन .NET5 का मुख्य लक्ष्य नहीं है।

एक्सएएमएल मानकीकरण की आवश्यकता के शीर्ष पर एक और प्राथमिकता सभी प्लेटफार्मों (मोबाइल, डेस्कटॉप और वेब) के लिए धाराप्रवाह डिजाइन के माध्यम से माइक्रोसॉफ्ट ब्रांडिंग का प्रसार है। [तकनीकी शब्द में, विन यूआई 3.0 के माध्यम से डिकूपिंग, जिसे हमें बार-बार विनयूआई 3.0 रोडमैप के उद्देश्य पर ध्यान केंद्रित करने के लिए कहा जाता है]

अंत में, कितना UWP, जो Win UI उत्पन्न करता है, वास्तव में इस ONE BCL में एक भूमिका निभाता है, जब .NET5 जारी किया जाता है, तो यह भी मेरे विचार में एक उच्च प्राथमिकता वाला लक्ष्य नहीं है।

विपणन के दृष्टिकोण से, दुर्भाग्य से उस तकनीक में अनुवादित नहीं किया गया है जिसका हम गहराई से ध्यान रखते हैं, यह है कि धाराप्रवाह डिजाइन के माध्यम से Microsoft ब्रांडिंग सर्वव्यापी है और उस डिज़ाइन को बढ़ावा देने वाला ऐप

मोबाइल उपस्थिति की कमी के कारण मैं "बाजार हिस्सेदारी को पकड़ने" के लिए माइक्रोसॉफ्ट की दीर्घकालिक रणनीति को इस तरह देखता हूं।

यह स्पष्ट है सिवाय इसके कि मुझे Hololens 2 और उसके बाद में एक बहुत बड़ी क्षमता दिखाई देती है। उसके लिए, हमें यह सुनिश्चित करने की आवश्यकता है कि WinUI 3.0 के साथ UWP APPS 3D आरेख नियंत्रण और उन्नत 3D मॉडल व्यूअर के साथ आते हैं।

क्षमा करें दोस्तों, मैं इस पर जोर देता रहता हूं क्योंकि मैं अपने पास सीमित समय का सर्वोत्तम प्रौद्योगिकी पर उपयोग करना चाहता हूं। :-)

WinUI 3.0 संक्रमण अवधि के संबंध में

मेरा सुझाव है कि माइक्रोसॉफ्ट विंडोज कम्युनिटी टूलकिट मेंटेनर्स (जिनमें से कुछ एमएस के लिए काम करते हैं) के साथ सीधे काम करें ताकि:

1. यह देखने के लिए परीक्षण करें कि क्या टूलकिट को WinUI 3.0 (नमूना ऐप सहित) पर पुन: लक्षित करते समय कोई अप्रत्याशित बाधाएं हैं।
2. यह देखने के लिए कि यह कितना आसान है, विजुअल स्टूडियो या "अन्य टूल" के माध्यम से स्वचालित नामस्थान का नाम बदलने का परीक्षण करें।
3. सार्वजनिक रूप से रिपोर्ट करें कि प्रक्रिया कैसे हुई (ब्लॉग पोस्ट/गिटहब मुद्दा/जो भी आपको पसंद हो)।
4. WinUI 3.0 के बारे में टेक्स्ट का एक कॉपी + पेस्ट हिस्सा प्रदान करें और प्रोजेक्ट मेंटेनर्स अपने GitHub/Nuget/अन्य रीडमी के लिए संलग्न कर सकते हैं, या इसके बारे में संक्षिप्त जानकारी के साथ कम से कम एक URL प्रदान कर सकते हैं। यह उन परियोजनाओं के किसी भी उपयोगकर्ता को WinUI 3.0 पर तेजी से लाने में मदद करेगा, और यह समझाएगा कि संक्रमण को पूरा करने के लिए उन्हें क्या करने की आवश्यकता होगी।
5. एक सुझाई गई संक्रमण प्रक्रिया और समयरेखा की रूपरेखा तैयार करें जिसे परियोजना/पुस्तकालय अनुरक्षक अपनाना चुन सकते हैं।

अंतिम मद के संबंध में, इसमें इस तरह के सुझाव शामिल होने चाहिए:

• एक नया प्रमुख रिलीज़ नंबर बनाएँ जो यह दर्शाता हो कि इसका उपयोग WinUI 3.0 ऐप्स (जैसे WCT v6.0) के साथ किया जाना है।
• वैकल्पिक रूप से (?) लीगेसी कोड को शामिल करने के लिए एक शाखा बनाएं जो उन परियोजनाओं का समर्थन करेगी जो अभी तक WinUI 3.0 में अपडेट नहीं हुई हैं।
• समय की अवधि प्रदान करें (उदाहरण के लिए 3/6/12 महीने) जिस पर विरासत परियोजनाओं के लिए समर्थन प्रदान किया जाएगा (यानी मुख्य शाखा से बग फिक्स और ऐसे विलय)। इसमें संभावित रूप से सामुदायिक परियोजनाओं/पुस्तकालयों में समर्थन अवधि को 'सिंक्रनाइज़' करने के लिए विशिष्ट तिथियां हो सकती हैं।

अंत में, मुझे लगता है कि यह पहचानना महत्वपूर्ण होगा कि यदि आपको विंडोज 10 संस्करण 1507 और 1607 एलटीएसबी का समर्थन करने की आवश्यकता है तो क्या किया जा सकता है। ये W10 के केवल 2 समर्थित संस्करण हैं जो जंगली में होंगे और WinUI 3.0 रिलीज़ के समय संगत नहीं होगा।

मूल रूप से मैं विंडोज 10 कैलकुलेटर के साथ प्रक्रिया का परीक्षण करने का सुझाव देने जा रहा था, क्योंकि यह एक उत्पादन गुणवत्ता वाला ओपन सोर्स ऐप है। हालाँकि, मुझे तब एहसास हुआ कि इस ऐप को अगले 6-7 वर्षों के लिए 1507 और 1607 LTSB पर चलाने की आवश्यकता है। इस प्रकार के ऐप्स का समर्थन करने के बारे में स्पष्ट रूप से कुछ विवाद होगा, खासकर जब छोटी सामुदायिक परियोजनाओं की बात आती है। यदि उन्हें वास्तव में इस समर्थन की आवश्यकता है, तो ऐसा करने के लिए एक स्पष्ट दीर्घकालिक रणनीति प्रदान की जानी चाहिए।

WinUI 4.0/3.x/vNext के संबंध में

जैसा कि यहाँ टिप्पणियाँ इंगित करती हैं, समुदाय के पास WinUI की भावी रिलीज़ के लिए काफी लंबी इच्छा सूची है। हमें वास्तव में कुछ अधिक दीर्घकालिक योजनाओं का सार्वजनिक रूप से दस्तावेजीकरण करके यहां बनाए जा रहे गति और उत्साह को भुनाना चाहिए।

चूंकि इनमें से अधिकतर आइटम v3.0 के दायरे से बाहर हैं, मुझे लगता है कि WinUI 4.0/3.x/vNext पर सामुदायिक प्रतिक्रिया एकत्र करना शुरू करने के बजाय जल्द ही एक नया मुद्दा बनाया जाना चाहिए। यदि कुछ भी हो, तो यह दोनों प्रकार के कार्यों की पहचान करने में मदद करेगा जिन पर WinUI टीम विचार कर रही है, और WinUI और/या अन्य MS टीमों की जिम्मेदारी के लिए क्या दायरे से बाहर है।

अंतिम बिंदु का एक उदाहरण - मैं वास्तव में इन चीजों को देखना चाहूंगा:

• UWP परियोजनाओं के लिए .NET Core 3.0 समर्थन (.NET टीम की जिम्मेदारी, जैसा कि मैं इसे समझता हूं)
• विजुअल स्टूडियो ऐप सेंटर से विंडोज़ ऐप्स (यूडब्ल्यूपी और विन32) के लिए पूर्ण समर्थन (जाहिर है ऐसा कुछ नहीं जिसके लिए विनयूआई टीम जिम्मेदार है)
• मटीरियल डिज़ाइन डॉक्स (फिर से, अलग टीम की जिम्मेदारी) में आप जो पा सकते हैं, उसके समान अधिक ठोस फ्लुएंट डिज़ाइन दिशानिर्देश
• इन-बॉक्स W10 ऐप्स में WinUI 3.0 और फ़्लुएंट डिज़ाइन का उपयोग (अलग टीमों और उनमें से कुछ ऐप्स को LTSB संस्करणों का समर्थन करने की आवश्यकता है)

इन आउट-ऑफ-स्कोप आइटमों की पहचान करके हम समुदाय को फीडबैक के उचित बिंदुओं की ओर पुनर्निर्देशित कर सकते हैं, और/या अन्यथा समझा सकते हैं कि उन क्षेत्रों में क्या हो रहा है।

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

यह बहुत अच्छा होगा यदि एफ # के पास सी # के साथ सममूल्य समर्थन होगा, उदाहरण के लिए सी # के समान प्रोजेक्ट टेम्पलेट्स।

मैं चाहता हूं कि WinUI (UWP vNext) में एक उचित विंडो ऑब्जेक्ट हो जैसे wpf के पास टॉप, लेफ्ट, चौड़ाई, ऊंचाई, स्टार्टअपपोजिशन, IsTopMost, AllowTransparency, और Show () / ShowDialog () विधियों के साथ था।

(_मैं इस बारे में निश्चित नहीं हूं कि यह विंडो मोबाइल फोन और IoT_ जैसे छोटे स्क्रीन उपकरणों पर कैसे काम करेगी (या अनुमति दी जाएगी))

@TonyHenrique 1903 में UWP के लिए एक नई विंडोिंग API है, लेकिन यह समाप्त होने से बहुत दूर है।

WinUI 3.0 के दायरे में XAML के प्रतिपादन पर फिर से विचार कर रहा है।

मुझे लगता है कि चीजें डब्ल्यूपीएफ के प्रतिपादन से एक कदम नीचे हैं:

• पाठ ClearType का उपयोग नहीं कर रहा है, इसके बजाय ग्रेस्केल एंटी-अलियासिंग का पक्ष ले रहा है;
• बॉर्डर स्ट्रोक जैसी चीज़ों के लिए पिक्सेल प्रेसिजन की कमी;

मैं समझ सकता हूं कि जब विंडोज फोन 7 और विंडोज फोन 8 को एक रेंडरिंग सिस्टम साझा करना था - स्क्रीन तकनीक का प्रकार, और रेंडरिंग की गति अधिक प्रदर्शन करने की ओर जोर दे रही थी। लेकिन WinUI के साथ पहले डेस्कटॉप पर, और बड़े डिस्प्ले के साथ - शायद इन गुणों को XAML रेंडर इंजन में पुनर्स्थापित करने का समय है।

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

एफ # टेम्पलेट के बारे में क्या?

जब तक यह मानक विंडोज फॉर्म और डब्ल्यूपीएफ प्रोजेक्ट टेम्पलेट्स में बॉक्स से बाहर काम नहीं करता है, जो .NET फ्रेमवर्क 4.5 या नए को लक्षित करता है, हम WinUI लाइब्रेरी को नहीं अपना सकते हैं।

केवल नवीनतम विंडोज 10 रिलीज और / या यूडब्ल्यूपी एप्लिकेशन की आवश्यकता फ्लुएंट डिज़ाइन को अपनाने के लिए शोस्टॉपर है।

मैं सुझाव दूंगा कि माइक्रोसॉफ्ट सीधे विंडोज कम्युनिटी टूलकिट अनुरक्षकों के साथ काम करे (जिनमें से कुछ एमएस के लिए काम करते हैं)

@kmgallahan
बढ़िया सुझाव! यह निश्चित रूप से योजना में है। हमारी टीम अक्सर विंडोज कम्युनिटी टूलकिट अनुरक्षकों के साथ मिलकर काम करती है और यह उन चीजों में से एक है जिसे हम परीक्षण परियोजना के रूप में उपयोग करना चाहते हैं।

WinUI 3.0 के दायरे में XAML के प्रतिपादन पर फिर से विचार कर रहा है।

@mdtauk
किसी भी प्रतिपादन परिवर्तन की संभावना 3.0 के दायरे से बाहर है, लेकिन कृपया इसके लिए एक मुद्दा खोलें ताकि हम संभावित रूप से बाद के रिलीज के लिए विचार पर फिर से विचार कर सकें। एक बड़ा फोकस निश्चित रूप से सार्वभौमिक प्रदर्शन रहा है, जैसा कि आपने नोट किया है कि विंडोज 8+ में कुछ प्रतिपादन परिवर्तन हुए हैं। प्रदर्शन मोड स्विच एक दिलचस्प विचार है।

एफ # टेम्पलेट के बारे में क्या?

@edgarsanchez , @khoshroomahdi
ऐसा लगता है कि हम F# में बहुत रुचि ले रहे हैं! हम इस बारे में अधिक जानना चाहेंगे कि आप F# क्यों चाहते हैं: कृपया F# अंक में बेझिझक टिप्पणी करें कि आप इसे क्यों चाहते हैं और आप इसके लिए क्या उपयोग करेंगे: #740

जब तक यह मानक विंडोज फॉर्म और डब्ल्यूपीएफ प्रोजेक्ट टेम्पलेट्स में बॉक्स से बाहर काम नहीं करता है, जो .NET फ्रेमवर्क 4.5 या नए को लक्षित करता है, हम WinUI लाइब्रेरी को नहीं अपना सकते हैं।

@jozefizso
क्या आपने Xaml द्वीप समूह में देखा है? यह सुविधा आपको डब्ल्यूपीएफ और विंडोज़ फॉर्म अनुप्रयोगों में WinRT Xaml का उपयोग करने देती है ताकि आप उन्हें आधुनिक Xaml दृश्यों/पृष्ठों के साथ बढ़ाना शुरू कर सकें:
https://docs.microsoft.com/windows/apps/desktop/आधुनिकीकरण/xaml-islands

हम WinUI 3.0 के लिए योजना बना रहे हैं ताकि द्वीपों को शामिल किया जा सके और क्रिएटर्स अपडेट और नए के लिए पिछड़े-संगत होने के लिए, जो कि विंडोज के कम से कम पिछले 5 संस्करण हैं।

क्या WinUI 3.0 के साथ क्रिएटर्स अपडेट और नए पर काम कर रहे Xaml द्वीप आपकी ज़रूरतों को पूरा कर सकते हैं?

किसी भी प्रतिपादन परिवर्तन की संभावना 3.0 के दायरे से बाहर है, लेकिन कृपया इसके लिए एक मुद्दा खोलें ताकि हम संभावित रूप से बाद के रिलीज के लिए विचार पर फिर से विचार कर सकें। एक बड़ा फोकस निश्चित रूप से सार्वभौमिक प्रदर्शन रहा है, जैसा कि आपने नोट किया है कि विंडोज 8+ में कुछ प्रतिपादन परिवर्तन हुए हैं। प्रदर्शन मोड स्विच एक दिलचस्प विचार है।

हो गया #768

XAML द्वीपसमूह को Windows 10, संस्करण 1903 की आवश्यकता है और Windows समुदाय टूलकिट लाइब्रेरी के लिए प्रोजेक्ट UWP होना आवश्यक है। यह एक नहीं जाना है।

XAML द्वीपसमूह को Windows 10, संस्करण 1903 की आवश्यकता है और Windows समुदाय टूलकिट लाइब्रेरी के लिए प्रोजेक्ट UWP होना आवश्यक है। यह एक नहीं जाना है।

विनयूआई 3.0 विंडोज 7/8/8.1 पर नहीं जाएगा - लेकिन वे ओएस बहुत जल्द जीवन के अंत तक पहुंच जाएंगे। और आप अभी भी उनके लिए wpf और WinForms का उपयोग कर सकते हैं। यह तब के लिए है जब आपके उपयोगकर्ता विंडोज 10 में चले गए हैं

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

@jozefizso यह कहना अधिक सटीक है कि यूडब्ल्यूपी इसे विनफॉर्म की तरह बनने की अनुमति देने के लिए बदल रहा है, और विनफॉर्म प्लेटफॉर्म के करीब आ रहा है।

आधुनिक एक्सएएमएल यूआई के साथ यूडब्ल्यूपी ऐप्स प्रतिबंधात्मक सैंडबॉक्स से बाहर निकल रहे हैं, और डब्ल्यूपीएफ और विनफॉर्म प्लेटफॉर्म से जुड़ने में सक्षम हैं।

मैं इसे ऐसे ही समझता हूं।

XAML द्वीपसमूह को Windows 10, संस्करण 1903 की आवश्यकता है

इस मामले में परियोजना विंडोज 10 के लिए यूडब्ल्यूपी होगी

WinUI 3.0 के साथ, हम 1703 और उसके बाद के संस्करण (बहुत आगे पीछे) द्वीपों को उपलब्ध कराने की योजना बना रहे हैं।

हम WinUI को UWP (अनौपचारिक रूप से "WinUI डेस्कटॉप" कहा जा रहा है) के बजाय Win32 ऐप मॉडल के साथ प्रयोग करने योग्य होने की दिशा में भी काम कर रहे हैं, इसलिए जरूरी नहीं कि यह एक UWP ऐप हो।

हम WinUI को UWP (अनौपचारिक रूप से "WinUI डेस्कटॉप" कहा जा रहा है) के बजाय Win32 ऐप मॉडल के साथ प्रयोग करने योग्य होने की दिशा में भी काम कर रहे हैं, इसलिए जरूरी नहीं कि यह एक UWP ऐप हो।

यही वह चीज है जिसे लेकर मैं सबसे ज्यादा उत्साहित हूं। विंडोज के पूर्ण एपीआई के साथ एक मूल एप्लिकेशन उपलब्ध है, चाहे वह Win32 हो या विंडोज रनटाइम, Xaml के माध्यम से प्रदर्शन करने वाला UI रखने में सक्षम हो।

हम WinUI को UWP (अनौपचारिक रूप से "WinUI डेस्कटॉप" कहा जा रहा है) के बजाय Win32 ऐप मॉडल के साथ प्रयोग करने योग्य होने की दिशा में भी काम कर रहे हैं, इसलिए जरूरी नहीं कि यह एक UWP ऐप हो।

यही वह चीज है जिसे लेकर मैं सबसे ज्यादा उत्साहित हूं। विंडोज के पूर्ण एपीआई के साथ एक मूल एप्लिकेशन उपलब्ध है, चाहे वह Win32 हो या विंडोज रनटाइम, Xaml के माध्यम से प्रदर्शन करने वाला UI रखने में सक्षम हो।

WinForms ऐप लें, कोड को पीछे रखें, लेकिन फॉर्म को XAML विंडो से बदलें, और सभी ब्रश और XAML नियंत्रणों तक पहुंच प्राप्त करें।

डब्ल्यूपीएफ केवल विनयूआई एक्सएएमएल का उपयोग करने के लिए थोड़ा और जटिल होगा - लेकिन कम से कम डब्ल्यूपीएफ नियंत्रणों को विनयूआई से मेल खाने के लिए स्टाइल किया जा सकता है

1. नामस्थान का नाम बदला जाना चाहिए। "Xaml" उपयुक्त नहीं है क्योंकि Xaml एक मार्कअप भाषा को संदर्भित करता है, जिसे गलत तरीके से मूल UWP घटकों के लिए मार्केटिंग भाषा (जो अक्सर बदलती रहती है) के रूप में उपयोग किया जा रहा है। "Xaml" को "WinUI" से बदला जाना चाहिए। आप देख सकते हैं कि इस थ्रेड में भी कितना भ्रम है, जहां यह अक्सर स्पष्ट नहीं होता है कि "Xaml" .xaml भाषा या ui घटकों को संदर्भित करता है या नहीं।
2. जहां तक ​​यह डब्ल्यूपीएफ और यूडब्ल्यूपी को एक साथ ले जाता है, यह अच्छा है। उनमें से प्रत्येक में ऐसी विशेषताएं हैं जो दूसरे में मौजूद नहीं हैं, और यह समझ में आता है कि "विंडोज यूआई" दोनों को जोड़ती है। सुविधाओं का कुछ दोहराव हो सकता है लेकिन यह एक संक्रमण पथ भी हो सकता है wpf -> UWP।
3. विंडोज़ संस्करणों से डिकूपलिंग करना समझ में आता है, लेकिन अपेक्षाकृत अपडेट किए गए Win10 को मान लेना भी ठीक है, यह देखते हुए कि जब यह काम समाप्त हो जाएगा तो Win7 EOL से काफी आगे हो जाएगा।

Xaml UI फ्रेमवर्क का नाम है। इसलिए Windows.UI.Xaml...

Xaml UI फ्रेमवर्क का नाम है

Xaml wpf में एक तकनीक थी जिसने डेवलपर्स को न केवल अपने अनुप्रयोगों के भीतर प्रस्तुति के दृश्यों का शक्तिशाली रूप से वर्णन और निर्माण करने में सक्षम बनाया, बल्कि स्वयं एप्लिकेशन भी। यानी, आप UI तत्वों _साथ ही POCOs_ का वर्णन कर सकते हैं। यदि यह .NET था, तो इसे Xaml के साथ बड़े पैमाने पर वर्णित किया जा सकता है और इसे एप्लिकेशन संदर्भ में लोड किया जा सकता है।

ऐसा न हो कि हम भूल जाएं (और ऐसा लगता है कि हमारे पास है) कि Xaml का अर्थ है विस्तारित एप्लिकेशन मार्कअप लैंग्वेज, जिसका अर्थ है कि यह एक मार्कअप भाषा है जो आपको .NET _application_ घटकों का सुरुचिपूर्ण ढंग से और कुशलता से वर्णन करने में सक्षम बनाती है। हालांकि यह मुख्य रूप से यूजर इंटरफेस तत्वों का वर्णन करने के लिए इस्तेमाल किया गया था, लेकिन यह व्यवहार में इस तरह से निर्वासित या विवश नहीं था।

मैंने व्यक्तिगत रूप से Xaml का उपयोग करके अपने संपूर्ण एप्लिकेशन कॉन्फ़िगरेशन का वर्णन करने, App.config को हटाने और बदलने के लिए समाप्त किया - और हाँ, यहां तक ​​​​कि Web.config - जटिलता उन बाहरी एपीआई के मामलों को छोड़कर जो बिल्कुल आवश्यक थे।

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

@charlesroddie मैं सहमत हूँ कि नामकरण वास्तव में मनमाना है। बस एक स्पर्शरेखा, यदि आप कभी भी WUXaml नेमस्पेस में उत्पन्न होने वाली चीजों के ढेर के निशान का निरीक्षण करते हैं, तो यह वास्तव में नामस्थान DirectUI में आंतरिक रूप से होता है। मुझे Win8 की कहानी जानना अच्छा लगेगा अगर उन दिनों यहां कोई भी आसपास होता, क्योंकि मुझे लगता है कि एक अलग कहानी थी। परतों को संयोजित करने के लिए DirectComp, चिकनी स्क्रॉलिंग और रबर बैंडिंग के लिए DirectManipulation, और फिर Direct2D/DirectWrite को वेक्टर ग्राफिक्स इंजन के रूप में DirectUI के साथ शीर्ष पर सभी को एक साथ खींचने के लिए। फिर किसी कारण से, इसमें से कुछ को वापस Win7 में पोर्ट किया गया था, केवल Xaml बिट्स WinRT सिस्टम के माध्यम से उजागर हो गए थे, जबकि अन्य सभी एपीआई अजीब कारखानों और पैटर्न के साथ क्रिप्टिक कॉम इंटरफेस के रूप में छोड़े गए थे जिन्हें आपको नमूने देखने की आवश्यकता थी, यह बताएं कि कैसे आह्वान।

दरअसल, अब जब मैं इसके बारे में सोचता हूं, तो यह वास्तव में अच्छा होगा यदि WUComposition ने WinRT के माध्यम से DirectComp और DirectManipulation का खुलासा किया (या यह एक पुनर्लेखन है), Direct2D/DirectWrite का यहां औपचारिक घर भी था। यदि आप इसकी तलाश कर रहे हैं तो वे सभी एस्केप हैच के विभिन्न स्तरों और निष्ठा के स्पर्श बिंदुओं को सक्षम करने के लिए एक साथ काम करते हैं। Win2D वास्तव में आधा बेक किया हुआ है और एक अच्छा API भी नहीं है।

Windows.UI.Composition मेरा मानना ​​​​है कि DirectComposition का फिर से लिखना है। एपीआई समान हैं लेकिन समान नहीं हैं।

यह मान लेना बंद कर दें कि सभी मॉनिटर अब sRGB हैं।
सभी पुराने ऐप्स के रंगों को sRGB के रूप में मानें और रचना के दौरान प्रत्येक मॉनिटर के लिए रूपांतरण करें।

यह थोड़ा ऑफ-टॉपिक हो सकता है, लेकिन मान लें कि आपके पास पहले से ही C++ में लिखा हुआ एक बड़ा Win32 एप्लायंस है, आप UI सिस्टम को आधुनिक बनाना चाहते हैं, इसलिए आप न्यूनतम निर्भरता के साथ WinUI या Comp का उपयोग करना चाह सकते हैं, जैसे कि Comp का उपयोग केवल बिना इन- बॉक्स नियंत्रण सेट, या यहां तक ​​​​कि XAML के बिना भी।

हालांकि अब यह पहले से ही संभव है, इसके लिए हमें WinUI 3.0 की प्रतीक्षा करने की आवश्यकता नहीं है।

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

मौजूदा एप्लिकेशन (जैसे फोटोशॉप) को आधुनिक बनाने के लिए बिना XAML के C++ Win32 एप्लिकेशन में Windows.UI.Composition का उपयोग करें। उनके पास पहले से ही UI आर्किटेक्चर है।

यह थोड़ा ऑफ-टॉपिक हो सकता है, लेकिन मान लें कि आपके पास पहले से ही C++ में लिखा हुआ एक बड़ा Win32 एप्लायंस है, आप UI सिस्टम को आधुनिक बनाना चाहते हैं, इसलिए आप न्यूनतम निर्भरता के साथ WinUI या Comp का उपयोग करना चाह सकते हैं, जैसे कि Comp का उपयोग केवल बिना इन- बॉक्स नियंत्रण सेट, या एक्सएएमएल के बिना भी।

इस पर प्रतिक्रिया के लिए धन्यवाद - मुझे लगता है कि विनयूआई 3 के साथ अंत में यह संभव होना चाहिए, विंडोज़ का उपयोग करने वाले "फ्रेमवर्कलेस" ऐप के समान। UI.Composition जो आप पहले से ही आज कर सकते हैं। हम इसे ध्यान में रखेंगे क्योंकि हम यह निर्धारित करते हैं कि WinUI NuGet पैकेज (पैकेजों) और निर्भरताओं की संरचना कैसे करें।

यह मान लेना बंद कर दें कि सभी मॉनिटर अब sRGB हैं।
सभी पुराने ऐप्स के रंगों को sRGB के रूप में मानें और रचना के दौरान प्रत्येक मॉनिटर के लिए रूपांतरण करें।

@ reli-msft क्या आप इसे ट्रैक करने के लिए एक अलग मुद्दा खोल सकते हैं?

@jesbis # 67

ऐप्पल ने आज स्विफ्टयूआई की घोषणा की ...

क्या होगा अगर Xaml Direct को विजुअल स्टूडियो टेम्प्लेट दिए जाएं ताकि डेवलपर्स को XAML और कोड के बजाय कोड का उपयोग करके ऐप बनाने में सक्षम बनाया जा सके।

मुझे नहीं लगता कि कार्ड में कोई बड़ी रीब्रांडिंग है लेकिन हम निश्चित रूप से नामकरण और नामस्थान पर चर्चा कर रहे हैं।

धन्यवाद @jesbis मैं इस सूत्र में शामिल होने के लिए आपकी सराहना

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

इन सभी ने कहा कि मैं कम से कम इन दो क्षेत्रों को बेहतर ढंग से वर्गीकृत करने के लिए ब्रांडिंग प्रयासों पर विचार करने के लिए (भीख माँगता हूँ, यहाँ तक कि ) भी कहूँगा। मुझे लगता है कि "एक्सएएमएल डायरेक्ट" यहां भ्रम का शिखर है, क्योंकि इसका नाम "मार्कअप लैंग्वेज" है - यह नाम में सही है! - लेकिन इसके वास्तविक उपयोग में ऐसा कुछ नहीं है। बहुत भ्रामक और भ्रामक, और ब्रांड का सीमावर्ती दुरुपयोग, मैं पेश करूंगा।

और Xaml डायरेक्ट की बात करें तो @mdtauk :

क्या होगा अगर Xaml Direct को Visual Studio टेम्प्लेट दिए जाने चाहिए ताकि डेवलपर्स XAML और कोड के बजाय कोड का उपयोग करके ऐप बनाने का विकल्प चुन सकें।

जैसा कि CSharpForMarkup जैसा कुछ है?

Xaml Direct की तुलना में एक बेहतर और उपयुक्त नाम, मैं सुझाव दूंगा। बेशक, _any_ नाम होगा। मैं

और Xaml डायरेक्ट की बात करें तो @mdtauk :

क्या होगा अगर Xaml Direct को Visual Studio टेम्प्लेट दिए जाने चाहिए ताकि डेवलपर्स XAML और कोड के बजाय कोड का उपयोग करके ऐप बनाने का विकल्प चुन सकें।

जैसा कि CSharpForMarkup जैसा कुछ है?

Xaml Direct की तुलना में एक बेहतर और उपयुक्त नाम, मैं सुझाव दूंगा। बेशक, _any_ नाम होगा। मैं

@ माइक-ईईई https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

इसे कोड से XAML UI लिखने के लिए मिडल-वेयर के लिए डिज़ाइन किया गया है, लेकिन क्या होगा यदि XAML फ़ाइलों के बजाय इसका उपयोग करने के लिए टेम्प्लेट हों? वहाँ बाहर रखने के लिए बस एक विचार ...

@mdtauk हाँ! स्विफ्टयूआई एक्सएएमएल की तरह दिखता है लेकिन कोड में किया जाता है। मैं वास्तव में कोड में हर चीज के विचार से प्यार करता हूं जिस तरह से रिएक्ट करता है। यह आपकी डिज़ाइन फ़ाइलों को तोड़ने और फिर किसी प्रकार के कोड-बैक से लिंक करने के लिए पुराना स्कूल है, और मुझे लगता है कि इसे बनाए रखना मुश्किल हो जाता है।

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

मैंने एक नया अंक #804 बनाया जहां स्विफ्टयूआई प्रेरित परिवर्तनों के बारे में चर्चा @ eklipse2k8 . हो सकती है

कृपया Visual Basic के लिए टेम्पलेट जोड़ना न भूलें।😀

WPF को _on_ WinUI 3 की निचली परतों का निर्माण करने दें!

@ रेली-एमएसएफटी डब्ल्यूपीएफ को अपडेट करने से आप क्या लाभ प्राप्त करना चाहेंगे?

यदि ऐसी विशिष्ट डब्ल्यूपीएफ विशेषताएं हैं जिन पर आप भरोसा करते हैं जिन पर आप विनयूआई में देखना चाहते हैं तो हमें "डब्ल्यूपीएफ फीचर्स जो कि विनआरटी [विनयूआई] में होनी चाहिए" थ्रेड में और अधिक सुनना अच्छा लगेगा: https://github.com/microsoft /माइक्रोसॉफ्ट-यूआई-एक्सएएमएल/मुद्दे/719

नए पिन किए गए अंक #888 . के पक्ष में समापन

वास्तव में इसकी प्रतीक्षा है। विशेष रूप से संस्करण से संबंधित कई मुद्दों को हल करेगा।

@weitzhandler [ 16 मई 2019 को

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

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

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

शुक्रिया!

बहुत अधिक अंतर्निर्मित कन्वर्टर्स

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

पूरे कन्वर्टर्स व्यवसाय को बेवजह डंप कर दिया जाना चाहिए।

बूलियन कनवर्टर पर आपत्ति

बूलियन बूलियन हैं। अन्य वस्तुएं बूलियन नहीं हैं। और वस्तुओं से बूलियन में कोई प्राकृतिक रूपांतरण नहीं होता है। .Net में प्रकार महत्वपूर्ण हैं और आगे की टाइप न की गई प्रणालियों को उपयोगकर्ताओं के सामने प्रकट नहीं किया जाना चाहिए।

हां और मौजूदा अनटाइप्ड सिस्टम जैसे बाइंडिंग को भी डंप किया जाना चाहिए।

पूरे कन्वर्टर्स व्यवसाय को बेवजह डंप कर दिया जाना चाहिए।

मेरा मतलब है कि आपके विकल्प क्या हैं?
कन्वर्टर्स के साथ मेरा दर्द बिंदु केवल यह है कि आपको उन्हें स्वयं फिर से लिखना होगा / NuGet से चुनना होगा, और वे बहुत वर्बोज़ हैं। कि उनके अलावा गैर-लचीला होने के कारण अंकगणित या नकार आदि जैसे किसी भी अभिव्यक्ति की अनुमति नहीं है।

बूलियन बूलियन हैं। अन्य वस्तुएं बूलियन नहीं हैं।

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

बाइंडिंग जैसे मौजूदा अनटाइप्ड सिस्टम को भी डंप किया जाना चाहिए।

हुह? मुझे वास्तव में लगता है कि इसका एक फायदा है। वी और वीएम के बीच लूज-कपलिंग अच्छी हो सकती है।

बाइंडिंग जैसे मौजूदा अनटाइप्ड सिस्टम को भी डंप किया जाना चाहिए।

वी और वीएम के बीच लूज-कपलिंग अच्छी हो सकती है।

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

संकलित बाइंडिंग उसके लिए बहुत मदद करती हैं।

@weitzhandler मेरा मतलब है कि आपके विकल्प क्या हैं?
... हर चीज में एक समर्पित दृश्यता संपत्ति नहीं होनी चाहिए।
हुह? मुझे वास्तव में लगता है कि [बाइंडिंग] का एक फायदा है। वी और वीएम के बीच लूज-कपलिंग अच्छी हो सकती है।

एक अच्छे प्रतिक्रियाशील ढांचे में आप name:Mutable<string> जैसे अवलोकन योग्य चर (कोड में) को परिभाषित कर सकते हैं और फिर उन्हें let visibility = name.map(fun s -> s <> "") मैप कर सकते हैं और फिर उन्हें visibility.bind someView.set_IsVisible या name.bind(fun s -> someView.IsVisible <- s <> "") साथ गुणों को देखने के लिए बाध्य कर सकते हैं।

मैं https://github.com/ReedCopsey/Gjallarhorn का उपयोग करता हूं लेकिन आसपास विभिन्न प्रतिक्रियाशील ढांचे हैं।

ध्यान दें कि: 1. बाइंडिंग के विपरीत, सब कुछ टाइप किया गया है। 2. चीजें (फ़ंक्शन, गुण, विचार) को ऑब्जेक्ट के रूप में संदर्भित किया जाता है, न कि स्ट्रिंग नामों को पास करके, 3. फ़ंक्शन केवल फ़ंक्शन हैं, कन्वर्टर्स की तुलना में बहुत कम क्लंकी, 4. बाइंडिंग बॉयलरप्लेट, जहां साधारण ऑब्जेक्ट गुणों को अतिरिक्त देने की आवश्यकता होती है "बाध्यकारी गुण" आदि को हटाया जा सकता है।

दृश्य अभी भी Xaml में लिखे जा सकते हैं, खासकर यदि वे साधारण ज्यादातर स्थिर लेआउट हैं, हर जगह जादू के तार के नुकसान के साथ, लेकिन एक लाइव दृश्य देने के लिए एक डिजाइनर होने का लाभ। बेहतर होगा कि कोड हो जो लाइव व्यू देता हो। दुभाषिया के साथ बहुत संभव है।

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

नमस्ते, क्या एमएस टीम यूजरवॉयस पर सभी बग्स/फीचर्स को हल कर सकती है?
यदि ऐसा किया जाता है, तो यह एक बढ़िया कदम होगा, जो कि WinUI 3.0 से भी अधिक है।

@ hupo376787 मुझे लगता है कि आपको

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

@charlesroddie हाँ, ऐसा लगता है कि उपयोगकर्ता की आवाज़ छोड़ दी गई है। मैं फीडबैक हब को अपनी आवाज भेजूंगा। शायद एमएस उन्हें अनदेखा कर दें, लेकिन मैं अपना काम करूंगी।

UserVoice इस महीने पूरी तरह से सेवानिवृत्त हो रहा है।

विशिष्ट उत्पादों के लिए, GitHub रेपो (जैसे यह एक) प्रतिक्रिया के लिए सबसे अच्छी जगह है क्योंकि संबंधित इंजीनियरिंग टीमें सक्रिय रूप से उनका उपयोग कर रही हैं।

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

मुझे पता है कि UserVoice पर वर्तमान में बहुत सारे इतिहास और पिछली प्रतिक्रिया है (जिसे हम अभी भी ट्रैक करेंगे), लेकिन GitHub और Feedback हब दोनों ही UserVoice की तुलना में हमारी इंजीनियरिंग टीमों और वर्कआइटम ट्रैकिंग के लिए एक अधिक सीधा रास्ता प्रदान करते हैं, इसलिए उम्मीद है कि यह सकारात्मक बदलाव होना चाहिए। हम विभिन्न समर्थन और प्रतिक्रिया लिंक अपडेट करने की प्रक्रिया में हैं।

हम वह सब कुछ देखते हैं जो किसी भी चैनल से आता है और वास्तव में प्रतिक्रिया और बग रिपोर्ट की सराहना करते हैं!

@jesbis ठीक है, मिल गया।

WinForms के लिए, नए WinUI प्रोजेक्ट टेम्प्लेट का उपयोग करते समय, क्या गुण विंडो अभी भी काम करेगी और WinUI नियंत्रणों के गुणों को सेट करने में सक्षम होगी? मैं पूरे दिन एचटीएमएल को कोड कर सकता हूं (आमतौर पर एएसपीनेट एमवीसी), लेकिन जब नियंत्रण के लिए बहुत सारी सेटिंग्स उपलब्ध हैं, तो मैंने पिछले 20 वर्षों से गुण विंडो का उपयोग करने का आनंद लिया है।

@ डीन-एनसी मुझे लगता है कि आप एक्सएएमएल डिजाइनर के बारे में पूछ रहे हैं, कोई विनफॉम्स/विंडोज फॉर्म नहीं, है ना? यदि हां, तो गुण पैनल तब भी WinUI नियंत्रणों के लिए कार्य करेगा जब आप XAML डिज़ाइनर पर किसी आइटम का चयन करेंगे।

@ marb2000 मुझे लगता है कि मैंने भोलेपन से सोचा था कि WinUI 3 नए नियंत्रणों को WinForms में इस अर्थ में लाएगा कि यह अधिकतर निर्बाध होगा, और मेरे पास विरासत और WinUI दोनों नियंत्रणों के साथ एक फॉर्म हो सकता है, और गुण विंडो काम करेगी विरासत और WinUI नियंत्रण दोनों के लिए।

मैंने उपरोक्त पूरी पोस्टिंग पढ़ी है, और मैं बहुत उत्साह के साथ इसका अनुसरण कर रहा हूं (WinForms डेवलपर के रूप में), लेकिन मुझे लगता है कि मैंने उच्च-स्तरीय वर्कफ़्लो को गलत समझा है कि यह कैसे काम करेगा (फिर से, WinForms के दृष्टिकोण से) )

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

@ marb2000 मुझे लगता है कि मैंने भोलेपन से सोचा था कि WinUI 3 नए नियंत्रणों को WinForms में इस अर्थ में लाएगा कि यह अधिकतर निर्बाध होगा, और मेरे पास विरासत और WinUI दोनों नियंत्रणों के साथ एक फॉर्म हो सकता है, और गुण विंडो काम करेगी विरासत और WinUI नियंत्रण दोनों के लिए।

मैंने उपरोक्त पूरी पोस्टिंग पढ़ी है, और मैं बहुत उत्साह के साथ इसका अनुसरण कर रहा हूं (WinForms डेवलपर के रूप में), लेकिन मुझे लगता है कि मैंने उच्च-स्तरीय वर्कफ़्लो को गलत समझा है कि यह कैसे काम करेगा (फिर से, WinForms के दृष्टिकोण से) )

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

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

और मौजूदा विनफॉर्म और डब्ल्यूपीएफ यूआई में एक्सएएमएल डालने के लिए एक्सएएमएल द्वीप हैं

आप ब्लेज़र टीम को यूनो (विशेष रूप से सर्वर साइड) में शामिल अपने कुछ होस्टिंग मॉडल प्राप्त करने के लिए यूनो के साथ काम करना चाहिए, और/या यूनो यूआई (और इस प्रकार विनयूआई 3) ब्लेज़र द्वारा उपयोग योग्य प्रतिपादन/दृश्य परत प्राप्त करने के लिए .... और/या शायद Blazor के लिए Xaml द्वीप समूह?

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

मेरी टीम ने केवल 1 UWP ऐप विकसित किया है। हम और विकास नहीं करेंगे।

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

हम अपने UWP उत्पाद में Stimulsoft Reports का उपयोग करते हैं। यह बहुत छोटी है और उन्होंने हमें बताया है कि वे बग्स को ठीक नहीं करेंगे क्योंकि उनका UWP उठाव इतना कम है।

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

इसलिए यदि WinUI का उद्देश्य अंततः डेटा डेवलपर्स पर प्रपत्रों को आकर्षित करना है, तो हमें एक अंतर्निहित सारणीबद्ध रिपोर्ट लेखक की आवश्यकता है।

मुझे आशा है कि यह दृश्य लोगों को ठेस नहीं पहुंचाएगा :-)

मैं पूरी तरह सहमत हूं। हम बिना किसी रिपोर्टिंग सिस्टम के आधुनिक व्यावसायिक ऐप कैसे विकसित कर सकते हैं जिसे ऐप के साथ आसानी से एकीकृत किया जा सकता है? यह एक विशाल घाटी है जो डेवलपर्स को आगे बढ़ने से रोकेगी।

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

यह मेरी समझ है कि व्यवसाय/उद्यम अभी भी विंडोज़ का सबसे बड़ा उपभोक्ता है। UWP के लिए Windows पारिस्थितिकी तंत्र के लिए कुछ इतना मौलिक क्यों नहीं विकसित किया जा रहा है?

प्रतिक्रिया के लिए धन्यवाद @VagueGit और @Elmarcotoro ! एंटरप्राइज़ नियंत्रण अभी हमारे लिए एक अंतर है। लेकिन आपका समय अच्छा है, हम डेटाग्रिड नियंत्रण के डिज़ाइन के लिए प्रतिक्रिया एकत्र कर रहे हैं। कृपया यहां पढ़ें और प्रतिक्रिया दें: #1500।

इसी तरह, वर्गाकार सारणीबद्ध डेटा नियंत्रण के अलावा, हमें एक ओपनसोर्स UWP ग्राफ नियंत्रण की आवश्यकता है जो रचनात्मक तरीके से लोकतांत्रिक तरीके से आरेख नियंत्रण के माध्यम से जटिल संबंधों को साझा करता है।

एक रिपोर्टिंग सिस्टम के लिए, मुझे लगता है कि टेलीरिक यूआई वर्तमान में सबसे अच्छा विकल्प है। एक चीनी कहावत है "कुछ लोग कुछ व्यवसायों में विशेषज्ञ होते हैं जबकि अन्य अन्य व्यवसायों में"। Telerik, या DevExpress या कोई अन्य, रिपोर्टिंग में अच्छे हैं।

विभिन्न नियंत्रणों की कमी के लिए, हमें इस टीम को नहीं, बल्कि पूरी एमएस रणनीति के लिए दोष देना चाहिए। सत्या की शुरुआत से ही मोबाइल छोड़ दिया, वे ios और android को बेहतर पसंद करते हैं, उनके जैसे बॉस का कारण बनते हैं। पूरा UWP पारिस्थितिकी तंत्र कमजोर और कमजोर हो जाता है।

अभी के लिए, ट्विटर पर "UWP is dead" नाम से एक बहस चल रही है, मुझे लगता है कि MS को इसे स्पष्ट करना चाहिए और अपना uwp रोड घोषित करना चाहिए।

अभी के लिए, ट्विटर पर "UWP is dead" नाम से एक बहस चल रही है, मुझे लगता है कि MS को इसे स्पष्ट करना चाहिए और अपना uwp रोड घोषित करना चाहिए।

आपने अभी इसे रोडमैप थ्रेड पर पोस्ट किया है...

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

@ हूपो376787
"एक रिपोर्टिंग सिस्टम के लिए, मुझे लगता है कि टेलीरिक यूआई वर्तमान में सबसे अच्छा विकल्प है।"

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

एक रिपोर्टिंग सिस्टम के लिए, मुझे लगता है कि टेलीरिक यूआई वर्तमान में सबसे अच्छा विकल्प है। एक चीनी कहावत है "कुछ लोग कुछ व्यवसायों में विशेषज्ञ होते हैं जबकि अन्य अन्य व्यवसायों में"। Telerik, या DevExpress या कोई अन्य, रिपोर्टिंग में अच्छे हैं।

@hupo376787 कृपया पोस्टिंग को गलत टेलीरिक रिपोर्टिंग में

DevExpress में WinForms और WPF के लिए एक रिपोर्ट डिज़ाइनर भी है, लेकिन UWP नहीं

तो कृपया अपने आप को एक त्रुटि करने से पहले अपने तथ्यों की जांच करें जो हमेशा के लिए संरक्षित और व्यापक रूप से प्रसारित की जाएगी। अरे ऐसा लगता है कि यह एक दिन पुरानी कहावत हो सकती है 😉

@hupo376787 कृपया पोस्टिंग को गलत टेलीरिक रिपोर्टिंग में

DevExpress में WinForms और WPF के लिए एक रिपोर्ट डिज़ाइनर भी है, लेकिन UWP नहीं

तो कृपया अपने आप को एक त्रुटि करने से पहले अपने तथ्यों की जांच करें जो हमेशा के लिए संरक्षित और व्यापक रूप से प्रसारित की जाएगी। अरे ऐसा लगता है कि यह एक दिन पुरानी कहावत हो सकती है 😉

ठीक है, मुझे लगता है कि हमें रिपोर्टिंग की अलग समझ है। मेरा मतलब है https://www.telerik.com/universal-windows-platform-ui और https://www.devexpress.com/products/net/controls/win10apps/।

मैं गलत था, देव एक्सप्रेस UWP के लिए रिपोर्टिंग प्रदान नहीं करती है। ऐसा प्रतीत होता है कि कोई तृतीय पक्ष टूलिंग डेवलपर नहीं करता है! मैंने देव एक्सप्रेस से उनकी चैट के माध्यम से संपर्क किया, इस बारे में कि क्या उनके पास यूडब्ल्यूपी के लिए रिपोर्टिंग प्रदान करने के लिए कोई रोड मैप है।
उन्होंने कहा,
"XtraReports Suite System.Drawing असेंबली द्वारा प्रदान की गई कार्यक्षमता का उपयोग करता है और जो चीज हमें यूनिवर्सल विंडो एप्लिकेशन के लिए टूल के समान सेट को लागू करने से रोकती है, वह यह है कि यह असेंबली वहां उपलब्ध नहीं है (https://stackoverflow.com/questions /31545389/windows-universal-app-with-system-drawing-and-possible-alternative)। इसलिए, हमने अभी तक इस क्षेत्र में अपनी भविष्य की योजनाओं को स्थापित नहीं किया है।"

@jevansaks , ऐसा लगता है कि Microsoft UI टीम और इन तृतीय पक्ष टूल प्रदाताओं के बीच संचार की कमी है। हमें थर्ड पार्टी टूलिंग का उपयोग करने में खुशी होगी, लेकिन ऐसा लगता है कि यूडब्ल्यूपी प्लेटफॉर्म इन कंपनियों के लिए यूडब्ल्यूपी में अन्य प्लेटफॉर्म के लिए टूलिंग को एकीकृत करना मुश्किल बना देता है।

उन्होंने मुझे हमारी रिपोर्टिंग आवश्यकताओं के साथ उनकी [email protected] से संपर्क करने के लिए कहा, यह विन UI 3.0 टीम के लिए उनके साथ संपर्क करने और यह देखने में मददगार हो सकता है कि क्या यह कार्यान्वयन में उनकी सहायता करने का एक तरीका है। मैं यह नहीं देखता कि उचित रिपोर्टिंग टूल के बिना आप यूनिवर्सल प्लेटफॉर्म पर बिजनेस डेव्स कैसे प्राप्त करेंगे।

https://www.devexpress.com/subscriptions/reporting/

रिपोर्टिंग: सिर्फ WinForms के नजरिए से, मैंने Telerik और DevExpress (यहां तक ​​कि उनके नवीनतम संस्करण) दोनों का उपयोग किया है, और जबकि Telerik अच्छा था, मुझे लगता है कि DevExpress के पास न केवल एक बेहतर समग्र डिज़ाइनर और अनुभव है, बल्कि इसमें बहुत अधिक सूक्ष्म विशेषताएं हैं मुझे टेलीरिक की तुलना में अधिक जटिल लेआउट करने की अनुमति दी। मुझे लगता है कि DevExpress रेंडरिंग तकनीक अधिक उन्नत है।

विन यूआई 3.0 टीम के लिए उनसे संपर्क करना और यह देखना उपयोगी हो सकता है कि क्या वे कार्यान्वयन में उनकी सहायता करने का एक तरीका है।

कॉल-आउट के लिए धन्यवाद। हम उन तक भी पहुंचेंगे।

कॉल-आउट के लिए धन्यवाद। हम उन तक भी पहुंचेंगे।

उन सभी के साथ बात करना और देखना होगा कि ब्लॉक क्या हैं? टेलीरिक, ग्रेपसिटी, देवएक्सप्रेस आदि।

कॉल-आउट के लिए धन्यवाद। हम उन तक भी पहुंचेंगे।

उन सभी के साथ बात करना और देखना होगा कि ब्लॉक क्या हैं? टेलीरिक, ग्रेपसिटी, देवएक्सप्रेस आदि।

निश्चित रूप से, यह हमारी योजना है।

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

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

मोटे तौर पर हम जो भी ऐप लिखते हैं, वह किसी न किसी तरह के वेब-आधारित बैकएंड को हार्डवेयर के कुछ टुकड़े (जैसे एक प्रिंटर, एक बारकोड स्कैनर, एक मैग स्ट्राइप रीडर, एक आरएफआईडी स्कैनर, एक कैमरा, कार्ड भुगतान हार्डवेयर, वेंडिंग-स्टाइल नकद भुगतान) के साथ एकीकृत करता है। घटकों, आदि), और उन घटकों में से अधिकांश ऐतिहासिक रूप से Win32 SDKs के साथ आए हैं, न कि UWP वाले।

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

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

अपने विशिष्ट प्रश्नों का उत्तर देने के लिए:

कौन से टेम्प्लेट में आपकी सबसे अधिक रुचि होगी?

सी # .NET कोर के साथ, Win32 WinUI 3.0 ओवरलैड के साथ अच्छा होगा।

क्या आप डेस्कटॉप ऐप्स के आधुनिकीकरण के लिए Xaml द्वीप समूह के बारे में जानते थे?

हां, और जब मैंने उनके साथ खेला तो मैं उनके साथ अपेक्षाकृत खुश था, हालांकि हम _single_ नियंत्रण का उपयोग करने की संभावना नहीं रखते हैं, जितना कि पूरे कस्टम UI के लिए निर्णय लेना।

मुझे इसकी जानकारी होने का मुख्य कारण यह था कि हमें Win32 ऐप्स के लिए Lottie सपोर्ट मिलेगा।

क्या यह विंडोज़ 10 पर विस्तारित पश्च-संगतता Xaml द्वीप समूह को आपके लिए अधिक उपयोगी बनाता है?

ज़रुरी नहीं; हम लगभग हमेशा लक्ष्य पीसी को नियंत्रित करते हैं और यह सुनिश्चित कर सकते हैं कि हमें हमेशा नवीनतम संगत रिलीज मिल रही है।

यदि विजुअल स्टूडियो या कोई अन्य उपकरण स्वचालित रूप से आपके लिए नामस्थान अपडेट करता है तो क्या यह मदद करेगा?

हां।

मौजूदा UWP Xaml घटकों और WinUI 3.0 ऐप्स के बीच पूर्ण संगतता आपके लिए कितनी महत्वपूर्ण है?

बहुत कम। मुख्य संगतता सिरदर्द जो हमारे पास होता, वह मूल तत्वों को स्टाइल करने के लिए StaticResource कुंजियाँ बदल देता।

क्या आप UWP Xaml कंट्रोल लाइब्रेरी या WinRT घटकों का निर्माण या उपयोग करते हैं जिन्हें आप ऐप कोड के साथ आसानी से पुन: संकलित और अपडेट नहीं कर सकते हैं?

हां, हमने अतीत में सिंकफ्यूजन यूडब्ल्यूपी कंट्रोल लाइब्रेरी का इस्तेमाल किया

WinUI 3 के साथ UWP Xaml घटकों का उपयोग करने के लिए आपका पसंदीदा समाधान क्या होगा?

पसंदीदा समाधान यह होगा कि बाहरी स्रोतों (उदाहरण के लिए दस्तावेज़ दर्शकों) पर झुकाव के बजाय WinUI में ही अधिक मानक नियंत्रण उपलब्ध हों, लेकिन मुझे उम्मीद है कि वे बाहरी घटक पुस्तकालय आमतौर पर अपने पुस्तकालयों को अपडेट करने के बारे में अधिक प्रगतिशील होंगे, जितना कि हम स्विच करने पर होंगे। अधिकांश भाग के लिए वैसे भी WinUI 3।

ऊपर और रोडमैप में उल्लिखित समग्र 3.0 योजना के बारे में आप क्या सोचते हैं? क्या यह आपको अपने नए और मौजूदा विंडोज़ ऐप्स के लिए WinUI का उपयोग करने में सक्षम करेगा?

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

इस तरह के स्पष्ट मार्गदर्शन के साथ कि Microsoft हमें ऐप UI बनाने की कैसे अनुशंसा करता है, मैं उम्मीद करता हूँ कि हमारे सभी ऐप WinUI फ़्रंटएंड के साथ समाप्त होंगे, चाहे हम किसी भी बैकएंड का समर्थन कर सकें।

आप किस प्रकार के ऐप्स के लिए WinUI 3.0 का उपयोग करने के लिए सबसे अधिक उत्साहित होंगे? एक नया Win32 ऐप बनाना और उसे MSIX के साथ पैक करना? एक डब्ल्यूपीएफ ऐप में नए विचार जोड़ना? Fluent UI के साथ C++ MFC ऐप का आधुनिकीकरण?

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

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

मैं देख रहा हूं कि इसे बंद कर दिया गया है, लेकिन कुछ ऐसे मुद्दे हैं जो हमारे उपयोगकर्ताओं द्वारा उठाए जाते हैं, हालांकि मैं इसे उठाने लायक हूं। वे उन उपयोगकर्ताओं के लिए उत्पादकता सुधार हैं जो बड़ी मात्रा में डेटा के साथ काम करते हैं।

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

ग्रिडव्यू/सूची दृश्य:
ग्रिडव्यू और लिस्ट व्यू उपयोगकर्ता को संग्रह के माध्यम से प्रभावी रूप से टैब करने की अनुमति नहीं देते हैं।
ListView टैब को उसी पंक्ति पर नियंत्रण में ले जाने की अनुमति देता है, लेकिन यह नियंत्रण की अगली पंक्ति पर टैब नहीं करेगा। इसके बजाय सूची दृश्य फोकस खो देता है और टैब दृश्य पेड़ में अगले नियंत्रण पर चला जाता है।

ये दो मुद्दे हमारे उपयोगकर्ताओं द्वारा बहुत कष्टप्रद के रूप में उठाए गए हैं।

@Elmarcotoro

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

यह मुद्दा मुख्य रूप से पोस्ट के शीर्ष पर 2 "सामान्य प्रश्न" के संबंध में प्रतिक्रिया प्राप्त करने के लिए मौजूद था।

WinUI में मूल निवासी Blazor होस्टिंग मॉडल का समर्थन करें। यह ब्लेज़र नियंत्रण को सीधे क्लाइंट/सर्वर वेब में उपयोग करने या सीधे WinUI में उपयोग करने की अनुमति देगा। वेबव्यू नियंत्रण का उपयोग किए बिना ब्लेज़र रोडमैप में यह भविष्य की अवधारणा है। इस तरह नियंत्रण का UI मूल रूप से चलता है और कोड का .Net मानक भाग भी मूल रूप से चल रहा है।

WinUI में मूल निवासी Blazor होस्टिंग मॉडल का समर्थन करें

ब्लेज़र पक्ष पर चर्चा की, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

निश्चित रूप से, यह हमारी योजना है।

@jevansaks भी लूप में

मैं WinUI 3.0 के साथ ट्रे मेनू/आइकन मेनू की बेहतर संगति चाहता हूं। प्रत्येक ऐप में एक अलग रिक्ति होती है, और Win32 ऐप्स लगातार फ़ॉन्ट रेंडरिंग/स्पेसिंग/थीम का पालन नहीं करते हैं। कृपया इसे पहले ही ठीक कर लें!

किसी भी विंडोज़ प्रबंधन संभावना की कमी के कारण डेस्कटॉप में WinUi मेरे लिए पूरी तरह से बेकार है: विंडोज़, विंडोज़ स्थिति, विंडोज़ आकार, डॉक/अनडॉक दिखाएं/छुपाएं ...

@alexandrevk यह अभी भी एक पूर्वावलोकन है। क्या आपने विंडोिंग एपीआई डिज़ाइन देखा? https://github.com/microsoft/ProjectReunion/issues/157

विंडोिंग अनाउंसमेंट पोस्ट से लिंक करने के लिए

@alexandrevk - हम रीयूनियन के लिए एपीआई को एक साथ रख रहे हैं जो आपको Win32 और UWP दोनों से WinUI सामग्री के साथ-साथ आपकी विंडो में अन्य ढांचे/स्वैपचैन सामग्री का उपयोग करते समय इस प्रकार के विंडोिंग संचालन करने की अनुमति देगा। इन विंडोिंग सुविधाओं में से कुछ को आसान पहुंच के लिए WinUI विंडो क्लास में भी सारगर्भित किया जा सकता है, लेकिन यह आगे सड़क से नीचे है। विंडोिंग क्षेत्र के लिए फ़ीचर स्पेक्स पाइप में हैं, देखते रहें।

एक व्यक्तिगत उपयोगकर्ता (यानी: गैर-कॉर्पोरेट/कंपनी) और सी ++ के रूप में सख्ती से बोलते हुए, भले ही मैं शून्य में चिल्लाने वाली अकेली आवाज हूं, मुझे यह कहने की आवश्यकता महसूस होती है कि जब तक इनमें से कोई भी नया यूआई सिस्टम नहीं है UWP और उस भयानक पैकेजिंग सिस्टम से बंधा हुआ है जिसमें वे निर्माण करते हैं, तो मुझे डर है कि आप जो कुछ भी करते हैं वह हमेशा अंधेरे में रहेगा। (WinRT अनुभव से बोलते हुए, अभी तक WinUI की कोशिश नहीं की है, लेकिन यह मेरे लिए काफी समान दिखता है)।
निश्चित रूप से यह ज्ञात होना चाहिए कि कम से कम कोई भी वास्तव में यूडब्ल्यूपी ऐप्स का उपयोग नहीं करता है? (वास्तव में अधिकांश afaik से नफरत है) तो अगर इसे 'मूल' कहा जा रहा है तो यह वास्तव में 'मूल' क्यों नहीं है, यानी: कुछ # शामिल हैं, एक .lib या दो लिंक करें और मानक सी ++ में अपना ऐप बनाएं।
क्यूटी जैसी चीजों का सहारा लेना जब क्रॉस-प्लेट कोई चिंता का विषय नहीं है, तो 1000 वीं बार Win32 को लपेटने से बचने के लिए निष्पक्ष होना थोड़ा पुराना हो रहा है।
वैसे भी सिर्फ मेरे 2 सेंट, किसी ऐसे व्यक्ति से जो हर दिन भाषा का उपयोग करता है, लेकिन शायद यहां टिप्पणी करने के लिए कोई जगह नहीं है।

@ nl-n आपको यह जानकर प्रसन्नता होनी चाहिए कि WinUI के साथ एक बड़ा सौदा यह है कि इसे UWP ऐप के रूप में चलाने की आवश्यकता नहीं है। वास्तव में यह प्रीव्यू 2 के बाद से ही संभव हो पाया है।
_Currently_ इसे msix के रूप में पैकेजिंग की आवश्यकता होती है, लेकिन msix वास्तव में आपके ऐप्स को वितरित (और अपडेट) करने का एक बहुत अच्छा तरीका है।

@dotMorten यह बड़े मुद्दों में से एक है: स्टोर के माध्यम से साइड-लोडिंग/इंस्टॉल करने की आवश्यकता है। मैं एक भी व्यक्ति को नहीं जानता जो विंडोज़ स्थापित करने से पहले (या उसके बाद) स्टोर को अक्षम/स्ट्रिप नहीं करता है, तो हम उन्हें कैसे वितरित करना चाहते हैं?
मुझे पता है कि यह कुछ हद तक अलंकारिक है, लेकिन यह बात परोसता है। मुझे केवल बिल्ड निर्देशिका को ज़िप करने और इसे वितरित करने में सक्षम होना चाहिए (या यदि आवश्यक हो तो इंस्टॉलर)।
फिर संगतता समस्या है, बहुत से लोग अभी भी W10 को स्थापित करने से इनकार करते हैं, इसलिए वह भी है ...
हालांकि यह सुनना अच्छा है कि 3.0 दिशा की ओर बढ़ रहा है, जितना मुझे xaml से नफरत है, यह एक स्वागत योग्य अतिरिक्त होगा।
हो सकता है कि हम इसे वीएस में भी पूरे 50 जीबी यूडब्ल्यूपी वर्कलोड को स्थापित करने की आवश्यकता के बिना प्राप्त कर सकें? 🙏 (अतिरंजना मुझे पता है, लेकिन फिर भी)

इस सूत्र की शुरुआत में @MarkIngramUK को उद्धृत करने के लिए:

यह 2019 है, मुझे एक तेज़, मूल UI चाहिए, और मैं CreateWindowExW , GDI, आदि के साथ उपयोगकर्ता इंटरफ़ेस बनाने पर गंभीरता से विचार नहीं करना चाहता।

जो (मजेदार रूप से पर्याप्त) मुझे सचमुच अभी करना है, और हाँ यह उतना ही दर्दनाक है जितना लगता है :)

@ एनएल-एन स्टोर के बारे में कुछ भी किसने कहा? MSIX वास्तव में MSI से स्थापित करने से अलग नहीं है। यह सिर्फ एक ऐप इंस्टॉलर है। इंस्टॉल करने के लिए इसे डबल क्लिक करें। दुकान की जरूरत नहीं। 100% क्लीन अनइंस्टॉल की भी गारंटी देता है (MSI के विपरीत जो एक बड़ी गड़बड़ी करता है)

मैं एक भी व्यक्ति को नहीं जानता जो स्टोर को अक्षम/स्ट्रिप नहीं करता है

हालांकि यह आम नहीं है।

हम उन्हें कैसे वितरित करने वाले हैं

सबसे पहले, आपको उपयोगकर्ताओं को स्टोर को अक्षम न करने के लिए सूचित करना होगा)

मुझे बस बिल्ड निर्देशिका को ज़िप करने और इसे वितरित करने में सक्षम होना चाहिए

MSIX को बिना स्टोर के इंस्टॉल किया जा सकता है। नवीनतम विंडोज संस्करणों के साथ उपयोगकर्ता को उसके लिए कुछ भी सक्षम करने की आवश्यकता नहीं है। बेशक अगर विश्वसनीय प्रमाण पत्र के साथ पैकेज पर हस्ताक्षर किए गए थे। लेकिन हाँ, यदि उपयोगकर्ता ने पीसी से स्टोर हटा दिया है, तो वह इसमें से MSIX/APPX AppInstaller को भी हटा सकता है। उस स्थिति में वे शायद अनुप्रयोगों की सभी परिवर्तनशीलता नहीं चाहते हैं।

बहुत से लोग अभी भी W10 को स्थापित करने से इनकार करते हैं,

यह उनकी पसंद है। निफ ने कहा।

वीएस में भी पूरे 50 जीबी यूडब्ल्यूपी वर्कलोड

सिंगल एसडीके लगभग 3 जीबी है। 10240 से शुरू होने वाले प्रत्येक को डाउनलोड करने की आवश्यकता नहीं है।

@ एनएल-एन स्टोर के बारे में कुछ भी किसने कहा? MSIX वास्तव में MSI से स्थापित करने से अलग नहीं है। यह सिर्फ एक ऐप इंस्टॉलर है। इंस्टॉल करने के लिए इसे डबल क्लिक करें। दुकान की जरूरत नहीं। 100% क्लीन अनइंस्टॉल की भी गारंटी देता है (MSI के विपरीत जो एक बड़ी गड़बड़ी करता है)

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

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

हालांकि यह आम नहीं है।

आपके विचार से अधिक सामान्य, और कारण के साथ

वैसे भी, मेरा इरादा पटरी से उतरने का नहीं था, इसलिए मैं अभी के लिए अपनी CreateWindowExW सामग्री लिखने के लिए वापस जाऊंगा