क्या हम नियंत्रण और डिफ़ॉल्ट मानों में अशक्त डेटा प्रकारों के समर्थन के बारे में बात कर सकते हैं? उदाहरण के तौर पर DatePicker जो डेटटाइम ऑफसेट देता है और CalendarDatePicker जो डेटटाइम ऑफसेट देता है?।

• इनमें से एक अशक्त क्यों है जबकि दूसरा नहीं है? क्या ऐसा इसलिए है क्योंकि डेटपिकर को विंडोज 8 टाइम-फ्रेम में पहले के एपीआई का उपयोग करके विकसित किया गया था?
• क्या हमें नियंत्रण में शून्य की अनुमति/अनुमति देने के लिए कॉन्फ़िगरेशन प्रॉपर्टी जोड़ने पर विचार करना चाहिए?
• क्या नंबरबॉक्स जैसे नए नियंत्रणों के लिए DefaultValue संपत्ति पर विचार किया जाना चाहिए, क्या NaN को डिफ़ॉल्ट के रूप में रखा जाना चाहिए, या क्या हमें डिफ़ॉल्ट नल के साथ एक शून्य डबल पर स्विच करना चाहिए?
• क्या अशक्त मूल्यों को वापस करने और समर्थन करने के साथ WinRT/OS XAML सीमाएं हैं जो नंबरबॉक्स की Value संपत्ति को निरर्थक बनाने से रोकेंगी? यदि हां, तो कैलेंडरडेट पिकर कैसे लागू किया गया था?
• यह सीधे #1721 और #1708 . में NumberBox चर्चाओं से संबंधित है

साथ ही, नंबरबॉक्स पर खुले मुद्दों को ठीक करने के लिए रोडमैप क्या है जो WinUI 3.0 पर निर्भर नहीं है? लंबे समय तक प्रतीक्षा करने के बजाय WinUI 2.4 के आसपास इस नियंत्रण का उपयोग करना शुरू करना बहुत अच्छा होगा। यह मेरी राय में अभी तक पूरी तरह से बेक नहीं हुआ है और मैं इसे प्रोडक्शन ऐप्स में खींचने में असहज हूं।

चर्चा करने के लिए एक और दिलचस्प विचार मैंने इस बारे में सोचा है: माइक्रोसॉफ्ट की नीति अब परिवर्तनों को तोड़ने पर क्या होगी जब WinUI 3.0 ओपन सोर्स जा रहा है?

अतीत में, माइक्रोसॉफ्ट ने वस्तुतः कभी भी ब्रेकिंग परिवर्तन नहीं किए हैं। यह आम तौर पर एक अच्छी बात है जब तक कि कुछ (या 10) वर्षों के बाद सभी अव्यवस्था का निर्माण न हो जाए। यह ओपन सोर्स प्रोजेक्ट्स के लिए भी मानक नहीं है। उदाहरण के लिए, अंततः ListBox को ListView के लिए चरणबद्ध किया जाना चाहिए और MessageDialog को ContentDialog, आदि के लिए चरणबद्ध किया जाना चाहिए। मुझे यकीन है कि API में भी बहुत सारे अच्छे छोटे क्लीन-अप हैं।

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

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

एक बार चर्चा होने के बाद यह दस्तावेज़ के लिए अच्छा हो सकता है।

अंतिम कॉल के बाद हुई प्रगति के आधार पर, टीम को वास्तविक रूप से कब लगता है कि WinUI 3 रिलीज़ के लिए तैयार होगा:

• बिल्ड 2020 (अप्रैल-मई)
• इग्नाइट 2020 (अक्टूबर-नवंबर)
• ~2011

साथ ही, आपका काम .NET टीम पर एक नया AOT समाधान और .NET 5 को एक साथ रखने पर कितना निर्भर है?

अंत में, क्या विंडोज़ पक्ष पर विंडोज़ 10 एक्स रिलीज़ के लिए तैयार होने और/या इससे पहले डेवलपर्स के लिए विशेष ऐप्स बनाने का दबाव है?

क्या WinUI 2.X परियोजनाओं को आसानी से WinUI 3.0 में बदलने के लिए कोई उपकरण होना चाहिए/होना चाहिए (चूंकि इसे मैन्युअल रूप से करना बड़ी परियोजनाओं के लिए बहुत काम हो सकता है)?

कमरे में हाथी - WinRT (#1856)

कमरे में हाथी - WinRT (#1856)

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

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

वाह वाह। वाह वाह!!!!

यह आश्चर्यजनक से परे है! क्या हमारे पास इसके लिए कोई ईटीए है, क्या इस पर कॉल में चर्चा की जाएगी?

यह बहुत बढ़िया है!

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

वाह वाह। वाह वाह!!!!

यह आश्चर्यजनक से परे है! क्या हमारे पास इसके लिए कोई ईटीए है, क्या इस पर कॉल में चर्चा की जाएगी?

यह बहुत बढ़िया है!

यह पहली चीज थी जिसे हमने WinUI के बारे में सीखा। ईटीए इस साल के लिए है, मुझे संदेह है कि //बिल्ड/ पर एक निश्चित तारीख दी जाएगी - लेकिन कॉल के दौरान पूछने के लिए स्वतंत्र महसूस करें।

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo WinUI रोडमैप देखें। अधिक जानकारी के लिए https://github.com/microsoft/microsoft-ui-xaml/issues/1045 भी देखें (जैसे VS प्रोजेक्ट टेम्प्लेट)।

@mdtauk @ फ़ेलिक्स-देव मैं उन दस्तावेज़ों को दोबारा

@jesbis नोब प्रश्न के लिए क्षमा करें - मैं कॉल में कैसे शामिल हो सकता हूं?

हम कल की कॉल के लिए आज बाद में जानकारी सेट कर रहे हैं - मैं कुछ घंटों में दिशा-निर्देश पोस्ट करूंगा।

देरी इसलिए है क्योंकि हम पहली बार एक नई प्रसारण प्रणाली का उपयोग कर रहे हैं - इसके बाद उम्मीद है कि यह आसान हो जाएगा और पहले तैयार हो जाएगा

मेरे पास बस एक दिलचस्प विचार था (वैसे भी मेरे लिए)।

आज के ASP.NET सामुदायिक स्टैंडअप लाइवस्ट्रीम पर नज़र डालते हुए मैंने देखा कि अनिवार्य रूप से 4 MS देव लाइवकोडिंग स्ट्रीम कर रहे हैं, हालाँकि यह एक तकनीकी डेमो से अधिक था। मैं कभी-कभी ट्विच पर @csharpfritz में भी ट्यून करता

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

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

मुझे नहीं पता कि उस प्रकार की चीज़ों पर एमएस नीतियां क्या हैं, खासकर कार्यदिवस के दौरान। आपके विचार सुनना दिलचस्प होगा।

ये रहा कल के लिए YouTube लाइव इवेंट का लिंक!

https://youtu.be/MXTVqgB4rW0

अब तक की सभी टिप्पणियों और प्रश्नों के लिए धन्यवाद! अगर हमारे पास समय नहीं है तो हम सब कुछ पाने की कोशिश करेंगे, या फॉलोअप के लिए ट्रैक रखेंगे।

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

कृपया सीमारहित/पारदर्शी विंडो (एक ला https://github.com/microsoft/microsoft-ui-xaml/issues/1247) की प्राथमिकता बढ़ाने पर विचार करें। यह हमारे जैसे ऐप्स के लिए एक WinUI एडॉप्शन ब्लॉकर है।

cc: @crutkas

कृपया सीमा रहित/पारदर्शी विंडो (एक ला #1247) की प्राथमिकता को बढ़ाने पर विचार करें। यह हमारे जैसे ऐप्स के लिए एक WinUI एडॉप्शन ब्लॉकर है।

cc: @crutkas

इसके लिए संभवतः डब्ल्यूपीएफ के समान गुणों के साथ WinUI Xaml में एक शीर्ष स्तरीय विंडो तत्व जोड़ा जाना आवश्यक होगा। #1323

विनयूआई के लिए 'भविष्य की खिड़की' के बारे में अधिक सीखना अच्छा होगा - बहुत सारे संबंधित अनुरोध हैं जो कम से कम चर्चा/पते के लिए अच्छा होगा।

शायद पहले पूछा गया हो।

मेरे लिए, हमेशा कोड पुन: प्रयोज्यता का मामला रहा है।
इससे दो प्रश्न होते हैं:

1. क्या .NET Core 3 और C# 8.0 सपोर्ट जल्द ही किसी को मिलने वाला है?
2. क्या हम UWP/WinUI टीम की ओर से Uno Platform ऐप्स को विकसित करना आसान बनाने के लिए और कदम उठाने जा रहे हैं?

एक और, हम यूडब्ल्यूपी में समर्थित डब्ल्यूपीएफ से लापता बिट्स कब देखेंगे?

शायद पहले पूछा गया हो।

मेरे लिए, हमेशा कोड पुन: प्रयोज्यता का मामला रहा है।
इससे दो प्रश्न होते हैं:

1. क्या .NET Core 3 और C# 8.0 सपोर्ट जल्द ही किसी को मिलने वाला है?
2. क्या हम UWP/WinUI टीम की ओर से Uno Platform ऐप्स को विकसित करना आसान बनाने के लिए और कदम उठाने जा रहे हैं?

एक और, हम यूडब्ल्यूपी में समर्थित डब्ल्यूपीएफ से लापता बिट्स कब देखेंगे?

.NET कोर कोड दोनों पर काम करना चाहिए, इसलिए एक wpf ऐप को केवल UI Xaml और UI कोड को बदलने की आवश्यकता होगी।

UWP ऐप्स को WinUI 3.0 के लिए नाम स्थान परिवर्तन के साथ ठीक काम करना चाहिए - सैंडबॉक्स से बाहर निकलने के लिए और अधिक काम करने की आवश्यकता हो सकती है, विवरण अभी भी अज्ञात हैं।

डब्ल्यूपीएफ लापता बिट्स की पुष्टि नहीं हुई है, लेकिन मैंने इसके बारे में एक मुद्दा बनाया है। #719

@weitzhandler

हालाँकि यह आधिकारिक तौर पर समर्थित नहीं है और सभी C# 8 सुविधाएँ काम नहीं करेंगी, आप पहले से ही WinUI/UWP के साथ अधिकांश C# 8 का उपयोग कर सकते हैं। यहां देखें।

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

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

धन्यवाद दोस्तों।
अगर मैं अभी भी जोड़ सकता हूं, तो पुराना csproj प्रकार भी थोड़ा परेशान है।

@jesbis

मैंने अभी इस मुद्दे को एक्सएएमएल कंट्रोल गैलरी में खोला है। यदि आप चाहें तो कॉल के दौरान चर्चा करने के लिए यह कुछ हो सकता है।

धन्यवाद, हम सभी सवालों तक पहुंचने की कोशिश करेंगे!

क्या यूआई के प्रदर्शन/एफपीएस के बारे में गाइड में कुछ है?

@ryvanvel हमारे यहां कुछ प्रदर्शन मार्गदर्शन है:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

और कुछ अन्य ब्लॉग पोस्ट और वीडियो जो मदद कर सकते हैं, जैसे:

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

जहां तक ​​मुझे याद है, यह बग विंडोज 10 के साथ रहा है, मुझे आशा है कि इसे जल्द ही संबोधित किया जाएगा: https://github.com/microsoft/microsoft-ui-xaml/issues/597

दुर्भाग्य से मैं समय पर ट्यून नहीं कर पाऊंगा, क्या कोई रिकॉर्डिंग होगी?

संपादित करें: कॉल की रिकॉर्डिंग यहां पाई जा सकती है: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis यहाँ :

ये रहा कल के लिए YouTube लाइव इवेंट का लिंक!
https://youtu.be/MXTVqgB4rW0

YT लिंक के बाद, ऐसा लगता है कि यह केवल इस घंटे के अंत में शुरू होने वाला है, नियमित समय से एक घंटे बाद, क्या यह सच है?

@weitzhandler प्रारंभ समय पोस्ट के शीर्ष पर है। यह भी केवल तीसरी कॉल है, इसलिए "नियमित" एक खिंचाव है।

@weitzhandler मुझे पूरा यकीन है कि अब तक सभी तीन कॉल सुबह 9 बजे प्रशांत समय पर शुरू होने वाली थीं।

आप दोनों को धन्यवाद और परेशानी के लिए खेद है। जल्द ही फिर मिलेंगे।

मैं यह जानने के लिए उत्सुक था कि क्या क्रोमियम-संचालित WebView2 मौजूदा WebView से WebResourceRequested जैसी घटना को भी उजागर करेगा, ताकि डेवलपर्स व्यक्तिगत वेब अनुरोधों को फ़िल्टर कर सकें। मैं अपने ऐप्स में से एक में उस विशिष्ट सुविधा पर बहुत भरोसा करता हूं और मैं सोच रहा था कि क्या वह अभी भी नए नियंत्रण के साथ होगा, और उसी तरह काम कर रहा है।

सभी कड़ी मेहनत के लिए धन्यवाद दोस्तों! मैं

क्या पीडीएफ बनाने के लिए कोई उपकरण होगा? Win2D में पहले से ही बहुत सारे अद्भुत उपकरण हैं, CanvasRenderTarget से PDF उत्पन्न करने की क्षमता एक बढ़िया अतिरिक्त होगी।

समझ में नहीं आया - vsix कैसे स्थापित करें? कहां से डाउनलोड करें?

शायद यह सिर्फ मैं ही हूं, लेकिन मैं आज की कॉल से निराश था। कृपया अधिक तकनीकी लोगों को शामिल करें। प्रधान मंत्री को चर्चा को केंद्रित रखना चाहिए और समय पर आगे बढ़ना चाहिए लेकिन विशेषज्ञों को प्रतिक्रियाएं सौंपें (जैसा कि अंत में और अधिक किया गया था)।

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

@SavoySchuler आपने अनिवार्य रूप से कहा है कि हमें बताएं कि हम नियंत्रणों का उपयोग कैसे कर रहे हैं, इसमें हमारी कंपनी और हमारे ऐप्स शामिल हैं। सामग्री की जरूरतों को अलग करने के लिए आपको इसकी आवश्यकता है बनाम अच्छा है। यह आपको सुविधाओं पर संसाधनों को प्राथमिकता देने में मदद करता है। आपको इसके बारे में दो चीजों के लिए अलग तरह से सोचने की जरूरत है:

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

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

कॉल में, मैं दो बार विंडोिंग लाया और यह उल्लेख किया गया कि:

• यह वास्तव में WinUI 3 के लिए काम किया जा रहा है (समस्या जमने के बावजूद https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• फ़ीचर ट्रैकिंग प्रोजेक्ट (कल अपडेट किया गया) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) केवल WinUI 2 सामान को ट्रैक कर रहा है???

क्या हम यहां कुछ स्पष्टता प्राप्त कर सकते हैं? क्या WinUI 3 बैकलॉग देखने के लिए कोई अन्य स्थान है? नियोजन उद्देश्यों के लिए यह अति महत्वपूर्ण है कि हम जानते हैं कि क्या आ रहा है और क्या नहीं। धन्यवाद!

@SavoySchuler @jesbis और बाकी की प्यारी WinUI टीम, मैं व्यक्तिगत रूप से आपके महान काम और बड़े पैमाने पर प्रयासों के लिए आपको धन्यवाद देना चाहता हूं और आपको बताता हूं कि WinUI को इतना शानदार बनाने और मेरे सभी सवालों के जवाब देने के लिए मैं कितना आभारी हूं।

ट्यून करने में सक्षम सभी को बहुत-बहुत धन्यवाद!

और ऑडियो और टीम के मुद्दों के लिए फिर से खेद है - हमें लगता है कि हमने एक हार्डवेयर समस्या की पहचान की है और उम्मीद है कि अगले महीने सब कुछ ठीक हो जाएगा।

रिकॉर्डिंग अब किसी के लिए भी लाइव है जो इसे नहीं बना सका।

हम प्रश्नों को देख रहे हैं और इस सूत्र में जो कुछ भी छूटा है उसे पाने का प्रयास करेंगे।

कुछ प्रश्न कैच-अप:

क्या पीडीएफ बनाने के लिए कोई उपकरण होगा?

@मुज़ीबुर्रहमान

हमारे पास WinUI 3.0 RTM के लिए इसे प्राप्त करने का समय नहीं होगा, लेकिन हम इसे #672 के साथ बैकलॉग में ट्रैक कर रहे हैं - इस मुद्दे पर एक टिप्पणी जोड़ने के लिए स्वतंत्र महसूस करें कि आप इसका उपयोग कैसे करेंगे!

बनाम कैसे स्थापित करें? कहां से डाउनलोड करें?

@hannespreishuber

उत्पादन ऐप्स के लिए WinUI 2.x उपयोग निर्देश यहां हैं: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

WinUI 3.0 अल्फा निर्देश बनाम स्थापित करने और आज़माने के लिए यहाँ हैं:
https://aka.ms/winui/alpha

शायद यह सिर्फ मैं ही हूं, लेकिन मैं आज की कॉल से निराश था। कृपया अधिक तकनीकी लोगों को शामिल करें। प्रधान मंत्री को चर्चा को केंद्रित रखना चाहिए [...] हम वर्षों/दशकों से एक्सएएमएल का उपयोग कर रहे हैं और आप एक विशेषज्ञ दर्शकों से बात कर रहे हैं (दर्शकों के लिए प्रस्तुतियों को अनुकूलित करना महत्वपूर्ण है)।

@robloo इस पर प्रतिक्रिया के लिए धन्यवाद। हम भविष्य के कॉलों के लिए विशिष्ट विषयों पर अधिक देव शामिल कर सकते हैं और अधिक गहन-गोता लगा सकते हैं यदि यह सभी के लिए रुचिकर है - हम पहली कॉल के लिए कोशिश नहीं करना चाहते थे क्योंकि यह कुछ समय हो गया है और हम एक सामान्य कैच करना चाहते हैं- यूपी।

हमें अतीत में भी फीडबैक मिला है कि कभी-कभी हम बहुत अधिक तकनीकी और बहुत गहन हो जाते हैं क्योंकि बहुत सारे दर्शक अभी तक WinUI से सुपर परिचित नहीं हैं - इसलिए हम उस फीडबैक को भी संतुलित करने का प्रयास कर रहे हैं।

इसके अलावा, अगर यह नोट करने में मदद करता है: डेवलपर प्लेटफॉर्म टीमों पर हमारे कई पीएम सुपर तकनीकी हैं और प्रमुख प्लेटफार्मों और वास्तविक ऐप्स के लिए उत्पादन कोड लिखने का अनुभव रखते हैं। उनमें से कुछ पहले Microsoft और अन्य कंपनियों में पूर्णकालिक डेवलपर थे। हम अभी भी पीएम के रूप में हर समय कोड लिखते हैं, यह हमारा एकमात्र ध्यान नहीं है

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

यदि नियंत्रण अधूरे लगते हैं तो कृपया उनके लिए खुले मुद्दे करें।

कॉल में, मैं दो बार विंडोिंग लाया और यह उल्लेख किया गया कि:
यह वास्तव में WinUI 3 के लिए काम किया जा रहा है (समस्या के स्थिर होने के बावजूद #1247)
फ़ीचर ट्रैकिंग प्रोजेक्ट (कल अपडेट किया गया) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) केवल WinUI 2 सामान को ट्रैक कर रहा है???
क्या हम यहां कुछ स्पष्टता प्राप्त कर सकते हैं? क्या WinUI 3 बैकलॉग देखने के लिए कोई अन्य स्थान है? नियोजन उद्देश्यों के लिए यह अति महत्वपूर्ण है कि हम जानते हैं कि क्या आ रहा है और क्या नहीं। धन्यवाद!

@riverar वह प्रोजेक्ट बोर्ड वर्तमान में WinUI 2 के लिए है क्योंकि वर्तमान में रेपो में यह एकमात्र कोड है।

हम उन मुद्दों के लिए आवश्यकता-विनुई-3 लेबल का उपयोग करते

हम प्रमुख वस्तुओं के लिए फीचर प्रस्ताव पोस्ट करना जारी रखेंगे - जैसे क्रोमियम वेबव्यू स्पेक अलग स्पेक्स रेपो में:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

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

हालांकि मैं कह सकता हूं कि उन टैग किए गए फीचर सुझावों में से अधिकांश को प्रारंभिक 3.0 रिलीज के लिए संबोधित नहीं किया जाएगा - हमारा मुख्य फोकस क्षेत्र हैं:

• WinUI को OS से अलग करना और अलग से भेजना
• Xaml ढांचे की ओपन सोर्सिंग
• एक अच्छा WinUI डेस्कटॉप ऐप डेवलपमेंट अनुभव बनाना (win32 उपयोग, पैकेजिंग, विंडोिंग, आदि)
• विंडोज 10X को सक्षम करना
• .NET Core/5 + WinUI ऐप्स को सक्षम करना

और हम एक ही समय में एक टन अतिरिक्त नई सुविधा विकास करने की कोशिश करके इसमें देरी या अस्थिरता नहीं करना चाहते हैं।

जैसे-जैसे हम डेस्कटॉप/विंडो सपोर्ट जैसे बड़े क्षेत्रों में ठोस प्रगति करेंगे, हम रेपो में प्रस्ताव और अपडेट पोस्ट करेंगे।

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

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

हालांकि मैं कह सकता हूं कि उन टैग किए गए फीचर सुझावों में से अधिकांश को प्रारंभिक 3.0 रिलीज के लिए संबोधित नहीं किया जाएगा - हमारा मुख्य फोकस क्षेत्र हैं:

• WinUI को OS से अलग करना और अलग से भेजना
• Xaml ढांचे की ओपन सोर्सिंग

यह निश्चित रूप से प्रयास का मूल है, लेकिन वर्तमान कार्यान्वयन के साथ विभिन्न समस्याओं या मुद्दों को हल करना संभव हो सकता है, क्योंकि इसे ओएस कोड से निकाला जा रहा है।

• एक अच्छा WinUI डेस्कटॉप ऐप डेवलपमेंट अनुभव बनाना (win32 उपयोग, पैकेजिंग, विंडोिंग, आदि)
• विंडोज 10X को सक्षम करना

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

• .NET Core/5 + WinUI ऐप्स को सक्षम करना

वर्तमान मूल समर्थन C++ कोड और Win32 APIs के रूप में आता है - लेकिन क्या इसका मतलब यह है कि किसी C# डेवलपर को .NET को लक्षित करने की आवश्यकता है? क्या बिना सैंडबॉक्स वाला ऐप मॉडल .NET के बिना C# कोडिंग की अनुमति देगा?

और हम एक ही समय में एक टन अतिरिक्त नई सुविधा विकास करने की कोशिश करके इसमें देरी या अस्थिरता नहीं करना चाहते हैं।

जैसे-जैसे हम डेस्कटॉप/विंडो सपोर्ट जैसे बड़े क्षेत्रों में ठोस प्रगति करेंगे, हम रेपो में प्रस्ताव और अपडेट पोस्ट करेंगे।

CoreWindow के बिना (जो केवल UWP होगा) - विंडिंग उन चीजों में से एक है जिसे पहले दिन से ही लागू करने की आवश्यकता होगी। डब्ल्यूपीएफ में एक्सएएमएल में एक विंडो ऑब्जेक्ट है जो नियंत्रण, दृश्य स्टाइल, पारदर्शिता इत्यादि को संभालता है। यह आकार बदलने, कम करने आदि को संभालता है। पुराने Win32 ढांचे को सतहों की मैन्युअल पेंटिंग की आवश्यकता होती है जो एक्सएएमएल यूआई के लिए कोई चीज नहीं है - तो यह अंतर कैसे पाटता है ?

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

क्या इन आंतरिक कार्य वस्तुओं को सार्वजनिक रूप से सूचीबद्ध करना संभव होगा, भले ही वे कुछ सामान्य नाम जैसे आंतरिक मुद्दे के साथ रिक्त प्रविष्टियों के रूप में दिखाई दें?

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

शुरुआत के रूप में, हमारे पास उच्च-स्तरीय ट्रैकिंग के लिए एक WinUI 3.0 मील का पत्थर है और जैसे ही हम WinUI 3 Xaml कोड को ओपन सोर्स में माइग्रेट करते हैं, हम उस मील के पत्थर में और अधिक "फीचर-स्तरीय" मुद्दे भी खोलेंगे।

हालाँकि, इसमें हमारे सभी WinUI 3.0 दिन-प्रतिदिन के देव कार्य तुरंत शामिल नहीं होंगे - संदर्भ के लिए हम वर्तमान में 2020 के लिए हजारों दिनों के संबंधित देव कार्य को ट्रैक कर रहे हैं और हम अभी तक सभी को स्थानांतरित करने के लिए तैयार नहीं हैं आज GitHub पर हमारी सुपर-ग्रेन्युलर ट्रैकिंग। हम समय के साथ उस तक पहुंच जाएंगे, जैसे हमने WinUI 2 के साथ किया था।

इसलिए, हम फीचर-स्तरीय मुद्दों (जैसे अब तक शुरू हो चुके हैं - जैसे वेबव्यू) से शुरू करेंगे और समय के साथ हमारी प्रक्रियाओं को पूरी तरह से गिटहब में माइग्रेट कर देंगे।

वर्तमान मूल समर्थन C++ कोड और Win32 APIs के रूप में आता है - लेकिन क्या इसका मतलब यह है कि किसी C# डेवलपर को .NET को लक्षित करने की आवश्यकता है? क्या बिना सैंडबॉक्स वाला ऐप मॉडल .NET के बिना C# कोडिंग की अनुमति देगा?

क्या आप .NET नेटिव के बारे में पूछ रहे हैं, या बिल्कुल नहीं .NET के बारे में? तकनीकी रूप से मुझे लगता है कि एक भाषा के रूप में सी # स्पेक .NET पर निर्भर नहीं है, लेकिन वर्तमान में हमारे पास सी ++ या ऐसा कुछ भी ट्रांसपिल करने की कोई योजना नहीं है।

CoreWindow के बिना (जो केवल UWP होगा) - विंडिंग उन चीजों में से एक है जिसे पहले दिन से ही लागू करने की आवश्यकता होगी। डब्ल्यूपीएफ में एक्सएएमएल में एक विंडो ऑब्जेक्ट है जो नियंत्रण, दृश्य स्टाइल, पारदर्शिता इत्यादि को संभालता है। यह आकार बदलने, कम करने आदि को संभालता है। पुराने Win32 ढांचे को सतहों की मैन्युअल पेंटिंग की आवश्यकता होती है जो एक्सएएमएल यूआई के लिए कोई चीज नहीं है - तो यह अंतर कैसे पाटता है ?

@marb2000 उस पर काम कर रहा है और उपलब्ध होने पर अधिक जानकारी साझा करने में सक्षम होगा।

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

स्पष्ट होने के लिए, WinUI 3 सभी Win32 डेस्कटॉप को HoloLens जैसे अन्य प्लेटफार्मों पर नहीं लाएगा: सार्वभौमिक ऐप्स और API अभी भी कई उपकरणों को लक्षित करते समय जाने का रास्ता होगा।

बहुत जल्दी पोस्ट किया गया। पूरी टिप्पणी:

@robloo - मैं आपकी बहुत सारी भावनाओं से सहमत होकर शुरुआत करना चाहता हूं और हमारे बढ़ते दर्द के माध्यम से हमारे साथ रहने के लिए मैं आपकी सराहना करता हूं। मैं अपने सभी तकनीकी मुद्दों के साथ बहुत ज्यादा बिखरा हुआ था और मैंने उस प्रश्न को उतनी अच्छी तरह से नहीं संभाला जितना मैं चाहता था। कृपया मुझे यहां पुन: प्रयास करने की अनुमति दें:

चार्टर और संसाधन

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

1. WinUI 2 को आगे बढ़ाना
2. विनयूआई वितरित करना 3
3. ओपन सोर्सिंग WinUI 3

जैसा कि आप जानते हैं, हम 2 और 3 की ओर मजबूती से डायल कर रहे हैं क्योंकि ए) ये युग्मित उद्देश्य हैं और बी) ओपन सोर्सिंग विनयूआई का मतलब है कि हर कोई हमारी टीम के सीमित संसाधनों द्वारा अवरुद्ध होना बंद कर सकता है क्योंकि विनयूआई अंततः सामुदायिक पुल अनुरोधों को स्वीकार करने के लिए सशक्त होगा।

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

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

एक अतिरिक्त बात जो आपको जाननी चाहिए वह यह है कि जब हम OS से WinUI 3 में कोड माइग्रेट कर रहे होते हैं, तो हम कोड को सरल और साफ करने के लिए कदम उठा रहे होते हैं जहां हम कर सकते हैं। इसका मतलब यह है कि WinUI 3 में हल किए जाने पर कुछ फीचर एडीशन और बग फिक्स को मापने में कम समय और प्रयास की आवश्यकता होगी।

नंबरबॉक्स

विशेषताएं

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

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

कीड़े

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

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

अगला कदम

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

हम ❤️ विनयूआई

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

यह सिर्फ मैं ही हो सकता हूं लेकिन मुझे लगता है कि कोड को जितनी जल्दी हो सके शिप करना महत्वपूर्ण है, कुछ प्रकार के मुद्दे हैं जिन्हें कुछ भी शिपिंग करने से पहले हल किया जाना चाहिए, उदाहरण के लिए # 1846 कुछ ऐसा है जिसे शिपिंग V1 से पहले संबोधित किया जाना चाहिए और वहां कुछ अन्य भी हो सकते हैं।

@yaichenbaum मैं वहां अपने शब्दों को बेहतर तरीके से चुन सकता था। मैं

यदि AD _मस्ट है_ फीचर्स हैं और EH _हैव टू हैव_ फीचर्स हैं, तो मेरी प्राथमिकता AD को दरवाजे से बाहर निकालना और EH को सक्षम रूप से जोड़ना है।

सत्यापन भागीदारों के साथ एक पूर्वावलोकन शाखा पर मंचन करने का कारण यह है कि नियंत्रणों को स्थिर रिलीज पर धकेलने से पहले #1846 जैसे बगों को पकड़ना है। क्षमा करें, हमने इस पर गेंद गिरा दी, मैं @teaP ASAP के साथ काम करके

कॉल में एक बिंदु पर यह उल्लेख किया गया था कि WinUI ऐप्स ऐपडोमेन के माध्यम से सैंडबॉक्सिंग की अनुमति देंगे।

क्या कोई इस बारे में बात कर सकता है कि अनुप्रयोग अलगाव और संसाधन नियंत्रण के लिए WinUI 3.0+ क्षमताओं बनाम AppDomain की स्थिति कैसे तय करेगा?

साथ ही, आखिरी बार मैं नेट कोर के लिए जानता था, ऐपडोमेन के लिए पूर्ण समर्थन नहीं हो रहा था।

हो सकता है कि मैं संपर्क से बाहर हूं, लेकिन क्या आप कह रहे हैं कि नेट 5 में पूर्ण ऐपडोमेन समर्थन होगा?

आज इस कॉल को आयोजित करने के लिए धन्यवाद!

क्या कोई इस बारे में बात कर सकता है कि अनुप्रयोग अलगाव और संसाधन नियंत्रण के लिए WinUI 3.0+ क्षमताओं बनाम AppDomain की स्थिति कैसे तय करेगा?

क्षमा करें यदि यह कॉल में स्पष्ट नहीं था, लेकिन मैं AppContainer के बारे में बात कर रहा था, AppDomain की नहीं।

आह, ठीक है, जेसी स्पष्टीकरण के लिए धन्यवाद।

सबसे पहले धन्यवाद @SavoySchuler और @jesbis (और बाकी सभी WinUI टीम) आज की सामुदायिक कॉल के आयोजन के लिए! हालाँकि कुछ तकनीकी कठिनाइयाँ थीं, यह कॉल बहुत ही व्यावहारिक थी !!!

जैसा कि @jesbis ने उल्लेख किया है कि WinUI 3.0 के लिए अनुरोधित टूल और सुविधाओं को ट्रैक करने में कोई समस्या है। क्या आसान ट्रैकिंग के लिए WinUI 2.x से 3.0 रूपांतरण टूल के अनुरोध को एक अलग मुद्दे में विभाजित करना बेहतर होगा? क्या पहले से ही कोई योजना है? क्या उपकरण को खुला स्रोत बनाने की योजना है ताकि अन्य देव इसे विकसित करने में मदद कर सकें?

एक और अधिक सामान्य प्रश्न (जो अन्य गैर WinUI टीम के सदस्यों के लिए भी होगा), योगदान के बारे में है। क्या वर्तमान में कोई बाधा है जो लोगों को योगदान करने से रोक रही है? क्या योगदानकर्ताओं के लिए एक बेहतर आरंभिक मार्गदर्शिका मदद करेगी?

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

हो सकता है कि उस क्षेत्र में सुधार से लोगों के लिए योगदान करना आसान हो जाए

WinUI 3.0 रेंडरिंग लेयर कैसे किया जाता है? क्या यह सीधे D3D11, D2D, एब्स्ट्रैक्शन लेयर या क्या का उपयोग करता है? क्या इसमें सॉफ्टवेयर रेंडरिंग लेयर है या इसके लिए D3D WARP का उपयोग करें?

@चिंगुकोडिंग

मैं उन बिंदुओं को दोहराऊंगा जो मैंने अभी यहां बनाए

• हमेशा के लिए लैंग का इस्तेमाल नहीं किया
• पता नहीं कितना कोड मंथन पृष्ठभूमि में हो रहा है WinUI 3 रिलीज के लिए जो आज किए गए परिवर्तनों को अधिलेखित कर देगा
• स्रोत कोड के एक समूह तक कोई पहुंच नहीं है जिसकी आवश्यकता होगी और/या मुद्दों के माध्यम से काम करने में काफी मदद मिलेगी

संपादित करें: मैं एक उदाहरण दूंगा। #1555 और #1849 कोर नियंत्रण (टेक्स्टबॉक्स) के साथ प्रमुख मुद्दे प्रतीत होते हैं जो मल्टीटास्किंग के दौरान टेक्स्ट इनपुट और चयन को रोक रहे हैं।

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

@SavoySchuler

अगर हमें उद्देश्य 2 और 3 पर बहुत आगे डायल किया जाता है, जहां WinUI 2 समुदाय के सदस्यों की सेवा कर रहा है, तो हम उस बातचीत को कर सकते हैं और हम पुनर्प्राथमिकता के लिए खुले हैं। बस इतना जान लें कि हमारे बैकलॉग में सभी बगों को हल करने से WinUI 3 के बाजार में रिलीज होने में ~ 6 महीने की देरी होगी।

मैं निश्चित रूप से समझता हूं। हालाँकि, मेरे दिमाग में नंबरबॉक्स यहाँ थोड़ा अलग है और मैं निश्चित रूप से यह नहीं कह रहा हूँ कि हमें सभी बगों पर ध्यान देना चाहिए। अभी मैं केवल NumberBox के सन्दर्भ में ही बात करूँगा। हालांकि निश्चित रूप से कुछ अन्य चकाचौंध वाले मुद्दे हैं जिन्हें संबोधित करने की आवश्यकता है।

नंबरबॉक्स WinUI 2.3 के लिए एक नया विकसित नियंत्रण है, न कि एक विरासत नियंत्रण जिसे इस बिंदु पर सभी को स्वीकार करना है। हम इसे शुरू करने के लिए सही तरीके से क्यों नहीं करेंगे? यह नए विकास मॉडल का एक लिटमस टेस्ट है।

यदि AD में सुविधाएँ होनी चाहिए और EH में सुविधाएँ होना अच्छा है, तो मेरी प्राथमिकता AD को दरवाजे से बाहर निकालना और EH को सक्षम रूप से जोड़ना है।

मैं यहां आपसे पूरी तरह सहमत हूं। लेकिन आप सुविधाओं और बग के बीच अंतर समझना चाहिए। यह मुझे चिंतित करता है कि आप केवल Microsoft के लिए संसाधनों/जनशक्ति के संदर्भ में सोच रहे हैं। हालाँकि, क्या आपने माना है कि ऐप डेवलपर्स नियंत्रण में बग के आसपास काम करने की कोशिश में अनगिनत घंटे बर्बाद करते हैं? इन चीजों को स्रोत पर ठीक करना कहीं अधिक कुशल है और वास्तव में प्लेटफॉर्म/टूलिंग की धारणा में भी मदद करता है।

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

Microsoft के पास अधूरे सॉफ़्टवेयर को जारी करने और फिर अंतिम को पूरा करने का मौका मिलने से पहले अगली नवीनतम और सबसे बड़ी तकनीक पर जाने का वास्तव में खराब ट्रैक रिकॉर्ड है। कृपया मुझे अपने वादे पर संदेह करने के लिए क्षमा करें।

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

सुविधाओं के मामले में आपके साथ एक ही पृष्ठ पर पूरी तरह से। बग अलग हैं। आपको सुविधाओं की तुलना में बग को अलग तरीके से संबोधित करने और उनके लिए अधिक संसाधन देने की आवश्यकता है। नंबरबॉक्स जैसे बिल्कुल नए नियंत्रण को जारी करना बुरा लगता है और फिर कहें कि आप अब से एक साल तक बग फिक्स करने के लिए संसाधन नहीं दे सकते हैं।

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

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

1721 - यूडब्ल्यूपी के साथ एक बड़ा मुद्दा यह था कि यह कुछ नियंत्रणों में डेटा बाइंडिंग के लिए अधूरा समर्थन था। बहुत सारे एप्लिकेशन डेवलपर्स ने वर्षों पहले एमवीवीएम डिज़ाइन में निवेश किया था और फिर यूडब्ल्यूपी नियंत्रणों पर कूदने की कोशिश करते हुए पाया कि डेटा बाइंडिंग केवल आंशिक रूप से समर्थित थी। यह एक बहुत बड़ा दर्द बिंदु है और यह देखते हुए अस्वीकार्य है कि Microsoft की सर्वोत्तम प्रथाओं के लिए MVVM कितना मौलिक है। पुरानी विंडोज़ डेवलपर टूलिंग टीम इसके लिए कभी खड़ी नहीं होगी - यह यहाँ विंडोज़/मूल सोच है।

1839 - यहाँ मूल सामग्री। ये नियंत्रण टेम्पलेट में केवल बुनियादी बग हैं और इन्हें ठीक किया जाना चाहिए। कोई बहाना नहीं।

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

1852, #1853, #1854 - फिर से, ये अत्यधिक जटिल नहीं हैं और पहले कार्यान्वयन में चूक गए थे। हालाँकि, कुछ क्षेत्रों में बेचे जाने वाले या सरकार के लिए विकसित सॉफ़्टवेयर में पहुँच का समर्थन करना एक कानूनी आवश्यकता है। एक मंच के रूप में आपको इसे तुरंत ठीक करना चाहिए ताकि एप्लिकेशन डेवलपर नियंत्रण का उपयोग कर सकें। दोबारा, मुझे आपके साथ इस प्रकार की बात पर बहस नहीं करनी चाहिए, यह बुनियादी चीजें हैं।

एक अतिरिक्त बात जो आपको जाननी चाहिए वह यह है कि जब हम OS से WinUI 3 में कोड माइग्रेट कर रहे होते हैं, तो हम कोड को सरल और साफ करने के लिए कदम उठा रहे होते हैं जहां हम कर सकते हैं। इसका मतलब यह है कि WinUI 3 में हल किए जाने पर कुछ फीचर एडीशन और बग फिक्स को मापने में कम समय और प्रयास की आवश्यकता होगी।

उच्च स्तर पर समझें। हालाँकि, उपरोक्त मुद्दों को ठीक करने से WinUI 3.0 में 6 महीने की देरी नहीं होगी। वे पता करने के लिए WinUI 3.0 पर भी निर्भर नहीं हैं (संभावित रूप से #1721 को छोड़कर)। आप नंबरबॉक्स जारी करके और फिर बग के पहले दौर को बंद करने के लिए उससे चिपके नहीं रहकर एक खतरनाक मिसाल कायम कर रहे हैं। आपको यह पाठ पहले ही UWP से ही सीख लेना चाहिए था।

हो सकता है कि उस क्षेत्र में सुधार से लोगों के लिए योगदान करना आसान हो जाए

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

आरई: योगदान:

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

लोगों को WinUI 2 में योगदान करने से कोई नहीं रोक सकता है, जो वर्तमान में रेपो में कोडबेस है। यदि कोई WinUI 2 समस्या है जिस पर आप काम करना चाहते हैं तो कृपया हमें बताएं और हम इसे आपको सौंप सकते हैं!

हम आइटम के बहुत सारे के साथ टैग है अच्छा पहला मुद्दा और मदद करना चाहता था अगर कोई आइटम है कि (अपेक्षाकृत) आसान के साथ शुरू करने के लिए किया जाना चाहिए के साथ मदद के लिए करना चाहता है 🙂

बग फिक्स के लिए आप सिर्फ एक पीआर खोल सकते हैं। यदि यह एक प्रमुख नई विशेषता है तो हमारे पास पहले इस मुद्दे की समीक्षा करने के लिए कुछ

मैं पूरी तरह से सहमत हूं कि योगदानकर्ता मार्गदर्शिका बेहतर हो सकती है और इसे शुरू करना कठिन है - मैंने हाल ही में एक नई सुविधा ( रेडियलग्रैडिएंटब्रश ) को लागू करने के लिए इसका पालन करने की कोशिश की और पाया कि यह बहुत सारे सुधारों का उपयोग कर सकता है - यह अब मेरे पास है गाइड को बेहतर बनाने के लिए टूडू लिस्ट।

मैं एक उदाहरण दूंगा। #1555 और #1849 कोर नियंत्रण (टेक्स्टबॉक्स) के साथ प्रमुख मुद्दे प्रतीत होते हैं जो मल्टीटास्किंग के दौरान टेक्स्ट इनपुट और चयन को रोक रहे हैं।
वे महत्वपूर्ण मुद्दों की मेरी सूची में उच्च हैं जिन्हें हल किया जाना चाहिए, लेकिन मुझे नहीं पता कि कहां से शुरू करना है। और न ही मुझे यह पता है कि चीजों को डीबग करने के लिए मैं जो कोड चाहता/चाहती हूं, वह उपलब्ध है या नहीं।

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

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

एक बार WinUI 3 ओपन सोर्स हो जाने के बाद कोई भी उन मुद्दों को भी हल करने में मदद कर सकेगा।

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

हम जानते हैं कि C++, C# की तुलना में एक उच्च अवरोध है, लेकिन योजना यह है कि WinUI एक C++ प्लेटफॉर्म बना रहेगा।

योगदान करने के लिए एक और महान परियोजना विंडोज कम्युनिटी टूलकिट है जिसमें योगदान करना आसान है क्योंकि यह सी # है और इसमें कुछ आराम की आवश्यकताएं हैं।

हम अनुरक्षकों के साथ काम करते हैं और अक्सर नए नियंत्रणों को इनक्यूबेट करने के लिए सामुदायिक टूलकिट का उपयोग करते हैं जो अंततः Xaml प्लेटफॉर्म पर माइग्रेट हो जाते हैं (जिसमें C++ में फिर से लागू करना शामिल होता है)।

क्या WinUI को C++/CX की आवश्यकता है? यदि ऐसा लगता है कि यह Win32 और भविष्य के अन्य लक्ष्यों के लिए एक मुद्दा है?

WinUI 3.0 रेंडरिंग लेयर कैसे किया जाता है? क्या यह सीधे D3D11, D2D, एब्स्ट्रैक्शन लेयर या क्या का उपयोग करता है? क्या इसमें सॉफ्टवेयर रेंडरिंग लेयर है या इसके लिए D3D WARP का उपयोग करें?

WinUI Xaml फ्रेमवर्क का प्रतिपादन मुख्य रूप से विंडोज 10 कंपोजिशन इंजन पर लागू किया गया है। कंपोजिशन लेयर एपीआई भी WinUI 3 का हिस्सा होगा।

अंत में इसका मतलब आम तौर पर Direct3D, Direct2D और DirectWrite का उपयोग करके हार्डवेयर-त्वरित प्रतिपादन है, कुछ मामलों में सॉफ़्टवेयर प्रतिपादन के साथ जहां यह समझ में आता है।

आप इंटरऑप एपीआई का उपयोग करके अपनी खुद की कस्टम-रेंडर डायरेक्टएक्स सामग्री भी शामिल कर सकते हैं।

क्या WinUI को C++/CX की आवश्यकता है? यदि ऐसा लगता है कि यह Win32 और भविष्य के अन्य लक्ष्यों के लिए एक मुद्दा है?

नहीं - WinUI प्लेटफ़ॉर्म C++ में लिखा गया है, लेकिन आपके ऐप्स का निश्चित रूप से होना ज़रूरी नहीं है!

WinUI 2 के साथ आज आप .NET (C#, VB.NET) या C++ का उपयोग करके UWP ऐप्स बना सकते हैं।

WinUI 3 के साथ हमारा लक्ष्य यह है कि आप आगामी .NET 5, या C++ का उपयोग करके UWP और/या win32 API का उपयोग करने वाले ऐप्स बनाने में सक्षम होंगे।

@jesbis मुझे लगता है कि आप मेरे सवालों के इरादे को थोड़ा गलत समझ रहे होंगे।

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

2) प्रतिपादन प्रणाली के बारे में। यहाँ युगल बातें।

2.ए) क्या "विजुअल लेयर" एक एब्स्ट्रैक्शन एपीआई को डायरेक्टएक्स एपीआई से काफी दूर हटा दिया गया है जो बाद में उदाहरण के लिए वल्कन बैकएंड का समर्थन कर सकता है? (मुझे यकीन है कि स्रोत जारी होने पर इस प्रश्न का उत्तर दिया जाएगा लेकिन मैं बस सोच रहा हूं)

2.बी) सॉफ्टवेयर रास्टरराइजेशन के बारे में मेरा प्रश्न अधिक था: क्या विनयूआई 3.0 पूर्ण सॉफ्टवेयर प्रतिपादन का समर्थन करेगा (केवल टेक्स्ट प्रतिपादन या क्या नहीं)? कभी-कभी स्क्रीन शेयरिंग सॉफ़्टवेयर में GPU त्वरित ऐप्स (कम से कम D3D9 / wpf के साथ) के साथ समस्याएँ होती हैं और उन स्थितियों में समस्या को हल करने के लिए सॉफ़्टवेयर रेंडरिंग को मजबूर करता है)। या अगर ऐप वीएम में बिना हार्डवेयर जीपीयू के चलाया जाता है।

WinUI 3.0 अल्फा निर्देश बनाम स्थापित करने और आज़माने के लिए यहाँ हैं:
https://aka.ms/winui/alpha

क्या एज न्यू के साथ डाउनलोड लिंक दिखाई नहीं दिया, इसे क्रोम के साथ दोहराया- वहां डाउनलोड करें

क्या एज न्यू के साथ डाउनलोड लिंक दिखाई नहीं दिया, इसे क्रोम के साथ दोहराया- वहां डाउनलोड करें

@hannespreishuber डाउनलोड लिंक सर्वेक्षण के अंतिम पृष्ठ पर होना चाहिए। क्या आपका मतलब है कि सर्वेक्षण क्रोमियम एज में काम नहीं करता था लेकिन क्रोम में काम करता था?

डाउनलोड लिंक सर्वेक्षण के अंतिम पृष्ठ पर होना चाहिए। क्या आपका मतलब यह है कि सर्वेक्षण ने क्रोमियम एज में> काम नहीं किया लेकिन क्रोम में काम किया?

दोनों पर सर्वे किया - लेकिन आखिरी पेज अलग था, शायद मेरी गलती थी।

दोनों पर सर्वे किया - लेकिन आखिरी पेज अलग था, शायद मेरी गलती थी।

ठीक है, धन्यवाद - हमने एज के दोनों संस्करणों पर सर्वेक्षण का परीक्षण किया और यह काम करने लगा, इसलिए यदि किसी को डाउनलोड में समस्या है तो कृपया हमें बताएं, और एज में समस्या की रिपोर्ट भी करें यदि पृष्ठ सामग्री क्रोम से अलग प्रस्तुत करती है (सेटिंग्स> सहायता और फ़ीडबैक > फ़ीडबैक भेजें)

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

@ zezba9000 हमने C++/WinRT का उपयोग करके WinUI 2 नियंत्रण और सुविधाओं (वर्तमान में रेपो में नया कोड) लागू किया है जो मानक C++17 है, लेकिन बाकी WinUI 3 एक बहुत बड़ा और पुराना कोडबेस है जो वर्तमान में अभी भी निर्भर करेगा WRL आदि पर। हम इस समय पोर्टेबिलिटी पर ध्यान केंद्रित नहीं कर रहे हैं, लेकिन भविष्य में इस पर चर्चा करने के लिए तैयार हैं।

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

हम इस समय दृश्य परत के लिए भी पोर्टेबिलिटी पर ध्यान केंद्रित नहीं कर रहे हैं। विजुअल लेयर और डायरेक्टएक्स एपीआई (कार्यान्वयन की गिनती नहीं) के बीच कुछ ढीले कपलिंग हैं लेकिन यह ज्यादातर सारगर्भित है। साथ ही, ओपन सोर्स के बारे में स्पष्ट करने के लिए: ओपन सोर्सिंग कोड और हमारी दैनिक विकास प्रक्रियाओं के लिए हमारा प्रारंभिक लक्ष्य Xaml फ्रेमवर्क है, जिसमें इस समय विजुअल लेयर को ओपन सोर्सिंग शामिल नहीं होगा।

सॉफ़्टवेयर रास्टरराइज़ेशन के बारे में मेरा प्रश्न अधिक था: क्या WinUI 3.0 पूर्ण सॉफ़्टवेयर रेंडरिंग का समर्थन करेगा (न कि केवल टेक्स्ट रेंडरिंग या क्या-क्या नहीं)? कभी-कभी स्क्रीन शेयरिंग सॉफ़्टवेयर में GPU त्वरित ऐप्स (कम से कम D3D9 / wpf के साथ) के साथ समस्याएँ होती हैं और उन स्थितियों में समस्या को हल करने के लिए सॉफ़्टवेयर रेंडरिंग को मजबूर करता है)। या अगर ऐप वीएम में बिना हार्डवेयर जीपीयू के चलाया जाता है।

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

मैं यहां आपसे पूरी तरह सहमत हूं। लेकिन आप सुविधाओं और बग के बीच अंतर समझना चाहिए। यह मुझे चिंतित करता है कि आप केवल Microsoft के लिए संसाधनों/जनशक्ति के संदर्भ में सोच रहे हैं। हालाँकि, क्या आपने माना है कि ऐप डेवलपर्स नियंत्रण में बग के आसपास काम करने की कोशिश में अनगिनत घंटे बर्बाद करते हैं? इन चीजों को स्रोत पर ठीक करना कहीं अधिक कुशल है और वास्तव में प्लेटफॉर्म/टूलिंग की धारणा में भी मदद करता है।

सहमत 100% - मैं यह भी याद नहीं करना चाहता कि मैं UWP/WinRT से बग के आसपास काम करने में कितने घंटे बिता रहा हूं।

जेसी,

मैं मुख्य रूप से उद्यम अनुप्रयोगों के विकास के बारे में चिंतित हूं। मैं वर्तमान में WinUI 3.0 Alpha का उपयोग अवधारणा का प्रमाण बनाने के लिए कर रहा हूं ताकि यह प्रदर्शित किया जा सके कि कैसे Xaml, GPRC, एकाधिक विंडो और ट्रू मल्टी-थ्रेडिंग व्यवसाय और व्यावसायिक उपयोगकर्ता को अधिक उत्पादक एप्लिकेशन अनुभव प्रदान कर सकते हैं।

क्यों? क्योंकि हमें ब्राउज़र-आधारित/छोटे स्क्रीन अनुप्रयोगों के विकल्प की आवश्यकता है। मुझे उस विषय पर और भी बहुत कुछ कहना है, लेकिन मैं यहाँ KISS करने जा रहा हूँ।

मैं WinUI टीम से और वास्तव में Microsoft को व्यवसाय के लिए डेस्कटॉप ऐप्स के निर्माण को अपनाना और समर्थन देना चाहता हूं।

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

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

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

उद्यम अनुप्रयोगों में अन्य आयाम हैं जिन पर अधिक चर्चा नहीं होती है - दीर्घायु और कौशल। फिर से, यहाँ कहने के लिए बहुत कुछ है, लेकिन मैं संक्षेप में बताने जा रहा हूँ। व्यवसाय एप्लिकेशन बनाने में पैसा लगाते हैं और वे "लंबे" समय के लिए उन ऐप्स का उपयोग करने की योजना बनाते हैं। इसका मतलब है कि अंतर्निहित तकनीक को दशकों तक समर्थन देने की आवश्यकता है। मैं WinUI को Win32/MFC और WinForms को बदलने के लिए अगली लंबे समय तक चलने वाली तकनीक देखना चाहता हूं।

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

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

हमें एक मजबूत (मुक्त) डेटाग्रिड नियंत्रण की आवश्यकता है। उस पर पर्याप्त जोर नहीं दे सकता।

यदि आप रुचि रखते हैं तो मेरे पास साझा करने के लिए और विचार हैं, लेकिन मैं यहां रुकूंगा और संक्षेप में बताऊंगा:

• Microsoft को एक व्यापक डेस्कटॉप अनुप्रयोग विकास समाधान प्रदान करने की आवश्यकता है।
• WinUI/Fluent को व्यावसायिक उपयोगकर्ता की आवश्यकताओं जैसे कि फ़ंक्शन/फॉर्म, डेस्कटॉप के लिए UX, कई विंडो प्रदर्शित करने वाले कोड नमूने/प्रोजेक्ट टेम्प्लेट, ट्रू मल्टी-थ्रेडिंग, डेटा सत्यापन, “फॉर्म-लाइक” पेजों की आवश्यकताओं को पूरा करने की आवश्यकता है।
• Microsoft को यह स्पष्ट करने की आवश्यकता है कि वे अत्यधिक उत्पादक, लंबे समय तक चलने वाले व्यावसायिक LOB अनुप्रयोगों के निर्माण के लिए WinUI की पेशकश कर रहे हैं। इसके अलावा, क्यों .Net 5 + WinUI एक और DLL नरक नहीं होगा।
• यह स्पष्ट करें कि WinUI, Win32/MFC और WinForms का प्रतिस्थापन है।
• आईटी के लिए एक कौशल के रूप में C#XS को पुश करें।
• (फ्री) डाटाग्रिड

आशा है कि आपको यह मददगार लगा।

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

यह बताया है कि विशेष रूप से NumberBox एक अपराधी है और इन अप stacking रहे हैं हमें हमारे समय के साथ रणनीतिक हो, तो मदद करने के लिए हमें यह देखने के लिए धन्यवाद मदद करता है कि राशि के लिए। मैंने अपने नंबरबॉक्स देव @teaP और हमारे (नए शीर्षक वाले) इंजीनियरिंग प्रबंधक @ranjesh के साथ हमारी बकाया नंबरबॉक्स बग सूची की समीक्षा करने के लिए अगले सप्ताह की शुरुआत में समय निर्धारित किया है ताकि हम उन्हें सामूहिक रूप से ASAP हल कर सकें।

@SavoySchuler धन्यवाद!

@SavoySchuler , ऐसा लगता है कि आप बीच में चुनने की कठिन स्थिति में फंस गए हैं:

a) WinUI 2.x में बग्स को ठीक करें, और WinUI 3.0 के रिलीज में देरी करें
या
b) WinUI 2.x को समुदाय पर छोड़ दें, और जल्द से जल्द रिलीज़ की तारीख प्राप्त करने के लिए WinUI 3.0 के लिए आंतरिक संसाधनों को समर्पित करें

मुझे लगता है कि बहुत से मौजूदा WinUI 2.x उपयोगकर्ता चाहते हैं कि आप पहले बग्स को ठीक करें, क्योंकि वे वर्तमान में प्रभावित हैं, लेकिन शायद इसे पर्याप्त संसाधनों के साथ WinUI 3.0 _could_ उपलब्ध होने की यथार्थवादी अपेक्षा की पेशकश करके कम किया जा सकता है ( और यह मानते हुए कि WinUI 3.0 2.x पर अतिरिक्त सुधार पेश करेगा)।

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

@jesbis , WinUI 3.0 के संबंध में विजुअल लेयर के बारे में यह दिलचस्प सुनवाई है। क्या आप कह रहे हैं कि प्रारंभिक रिलीज़ के लिए, WinUI 3.0 की Windows.UI.Composition कक्षाओं पर निर्भरता होगी? क्या WinUI 3.0 में निष्कर्षण से पहले दृश्य परत का समर्थन करने के लिए OS में और अधिक सुविधाएँ जोड़ने की संभावना है?

संदर्भ के लिए, जिन चीजों में मैं दिलचस्प हूं:

• Win32 "AppContainer" मॉडल। हम अन्य ओएस पर पूरी तरह से सैंडबॉक्स संगत हैं, लेकिन हम "आधुनिक" एपीआई तक पहुंच चाहते हैं
• दृश्य परत ( Windows|Microsoft.UI.Composition )
• दृश्य परत में DXGI स्वैप चेन / SwapChainPanel
• विंडो प्रबंधन API (AppWindow आदि)

@infoequipt गहन नोट्स के लिए धन्यवाद! निश्चित रूप से मददगार। @marb2000 दृश्यता के लिए

WinUI 3.0 के संबंध में विजुअल लेयर के बारे में यह दिलचस्प सुनवाई है। क्या आप कह रहे हैं कि प्रारंभिक रिलीज़ के लिए, WinUI 3.0 की Windows.UI.Composition क्लासेस पर निर्भरता होगी?

@MarkIngramUK नहीं, किसी भी भ्रम के लिए खेद है - मेरा पहला बिंदु केवल ओपन सोर्सिंग के बारे में था।

Microsoft.UI.Composition WinUI 3 का हिस्सा होगा और Microsoft.UI.Xaml इस पर निर्भर करेगा। WinUI 3 Alpha के मामले में पहले से ही ऐसा है।

हम ओपन सोर्सिंग Xaml की दिशा में काम कर रहे हैं, जिसका अर्थ है कि Xaml फ्रेमवर्क कोड इस रेपो में रहेगा और हमारी इंजीनियरिंग टीम आगे जाकर GitHub पर Xaml पर हमारे दिन-प्रतिदिन का काम करेगी। हालाँकि Microsoft.UI.Composition पैकेज जिस पर Xaml निर्भर करता है वह अभी भी आंतरिक रूप से विकसित होगा और केवल बाइनरी रूप में अपडेट किया जाएगा।

स्पष्टीकरण के लिए धन्यवाद @jesbis बहुत सराहना की। इसके लिए आप किन वितरण विधियों का प्रयोग करेंगे? हम एक क्रॉस-प्लेटफ़ॉर्म ऐप हैं, इसलिए सीएमके का उपयोग कर रहे हैं, और Windows.UI.Composition पर निर्भरता रखते हैं, इसलिए आसानी से नए dll, lib, हेडर इत्यादि लाने का एक तरीका पसंद करेंगे।

क्या ओएस से विजुअल लेयर निकालने के लिए कोई प्रदर्शन प्रभाव है? यानी यदि आप केवल विज़ुअल लेयर पर निर्भर हैं, तो क्या नई लाइब्रेरी में अपडेट करने में कोई कमी होगी?

क्या अंततः Microsoft.UI.Composition को स्रोत खोलने की कोई योजना है?

@MarkIngramUK आप जो कह रहे हैं @SavoySchuler 'बिग-पिक्चर' दृश्य में क्या कह रहा है। जैसा कि आपने बताया, हमारे लिए WinUI 2.0 उपयोगकर्ताओं के लिए बग स्वीकार करना कठिन है क्योंकि हमारे पास अभी उत्पादन ऐप्स हैं। हमें कुछ बगों को ठीक करने के बीच एक समझौता खोजने की जरूरत है जो WinUI 3.0 में देरी नहीं करेंगे और WinUI 3.0 को भी ट्रैक पर रखेंगे। एक अतिरिक्त निराशा थी कि नंबरबॉक्स एक नया नियंत्रण था जिसे तुरंत उपेक्षित किया गया था - एक टिप्पणी के साथ कि माइक्रोसॉफ्ट एक साल से अधिक समय तक इसे वापस नहीं करेगा। भले ही, मैं निश्चित रूप से सहमत हूं कि WinUI 3.0 प्राथमिकता है और मैं नहीं चाहता कि इसमें किसी भी महत्वपूर्ण क्षमता में देरी हो।

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

इसके लिए आप किन वितरण विधियों का प्रयोग करेंगे? हम एक क्रॉस-प्लेटफ़ॉर्म ऐप हैं, इसलिए सीएमके का उपयोग कर रहे हैं, और Windows.UI.Composition पर निर्भरता रखते हैं, इसलिए आसानी से नए dll, lib, हेडर इत्यादि लाने का एक तरीका पसंद करेंगे।

@MarkIngramUK आपके लिए NuGet पैकेज का उपभोग करेगा? यानी हम WinUI 2.x और WinUI 3 Alpha के साथ क्या कर रहे हैं। हम अभी भी विजुअल स्टूडियो टीम के साथ कुछ वितरण विवरणों पर काम कर रहे हैं। अभी WinUI 3 Alpha में 1 पैकेज में Xaml और कंपोज़िशन बायनेरिज़ दोनों शामिल हैं, लेकिन हम उन्हें ओपन सोर्सिंग Xaml का समर्थन करने और Xaml को अलग से बनाने में सक्षम होने के लिए अलग करेंगे।

क्या ओएस से विजुअल लेयर निकालने के लिए कोई प्रदर्शन प्रभाव है? यानी यदि आप केवल विज़ुअल लेयर पर निर्भर हैं, तो क्या नई लाइब्रेरी में अपडेट करने में कोई कमी होगी?

बने रहें परफ़ बेंचमार्किंग और काम इस साल के अंत में हमारे रोडमैप पर है, इसलिए किसी भी संख्या के लिए यह थोड़ा जल्दी है।

क्या अंततः Microsoft.UI.Composition को स्रोत खोलने की कोई योजना है?

संभावित रूप से विचार करने के लिए यह हमारे बैकलॉग पर है लेकिन हमारे पास इसके लिए कोई योजना नहीं है।

@MarkIngramUK अगर मैं पूछ सकता हूं: ओपन सोर्स होने से आप क्या लाभ प्राप्त करने की उम्मीद करेंगे?

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

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

@robloo धन्यवाद! हम वास्तव में पारदर्शी होने की कोशिश कर रहे हैं और यह जानना अच्छा है कि यह मूल्यवान है

Savoy ने जो उल्लेख किया है उसे दोहराने के लिए हमारे पास WinUI 2.x पर काम करने वाले देव हैं (जैसा कि उम्मीद है कि PR लॉग से भी देखा जा सकता है) इसलिए हम निश्चित रूप से अभी भी WinUI 2 और 3 दोनों में समानांतर में निवेश कर रहे हैं - यह सिर्फ इतना है कि हमारे अधिकांश संसाधन WinUI 3 पर हैं। मैं विशेष रूप से कुछ ध्यान देने की आवश्यकता वाले नंबरबॉक्स के बारे में सहमत हूं और हमारे एक्सएएमएल नियंत्रण देव लीड अब इसे देख रहे हैं।

@robloo आप सबसे अच्छे हैं! भ्रम के लिए फिर से क्षमा करें - केवल एक चीज जो उल्लेखित ~ 1 वर्ष की देरी के अधीन थी, वह थी नंबरबॉक्स के अतिरिक्त इनपुट सत्यापन मोड क्योंकि वे 3.0 के लिए हमारे सभी-अप इनपुट सत्यापन कार्य पर अवरुद्ध हैं। अन्यथा @teaP , @ranjeshj , और मैं अगले सप्ताह से शुरू होने वाली नंबरबॉक्स बग सूची में रहूंगा। मैं

मुझे लगता है कि @jesbis को बाकी सब कुछ मिल गया है!

@jesbis ,

@MarkIngramUK आपके लिए NuGet पैकेज का उपभोग करेगा? यानी हम WinUI 2.x और WinUI 3 Alpha के साथ क्या कर रहे हैं। हम अभी भी विजुअल स्टूडियो टीम के साथ कुछ वितरण विवरणों पर काम कर रहे हैं। अभी WinUI 3 Alpha में 1 पैकेज में Xaml और कंपोज़िशन बायनेरिज़ दोनों शामिल हैं, लेकिन हम उन्हें ओपन सोर्सिंग Xaml का समर्थन करने और Xaml को अलग से बनाने में सक्षम होने के लिए अलग करेंगे।

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

क्या अंततः Microsoft.UI.Composition को स्रोत खोलने की कोई योजना है?

संभावित रूप से विचार करने के लिए यह हमारे बैकलॉग पर है लेकिन हमारे पास इसके लिए कोई योजना नहीं है।

मुझे इसमें दिलचस्पी है, इसलिए अगर ऐसा होता है तो मुझे चर्चा में शामिल होना अच्छा लगेगा।

@MarkIngramUK अगर मैं पूछ सकता हूं: ओपन सोर्स होने से आप क्या लाभ प्राप्त करने की उम्मीद करेंगे?

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

प्रारंभिक विचार योगदान/विस्तार कर रहे हैं (जैसा कि मैंने पहले उल्लेख किया है, हमारी Windows.UI.Composition पर निर्भरता है, लेकिन Xaml Framework/UWP पर नहीं), हालांकि ज़ोर से सोचते हुए, विज़ुअल लेयर को Vulkan या मेटल बैकएंड में क्रॉस- मंच रोमांचक हो सकता है, लेकिन मैंने केवल 30 सेकंड का विचार दिया है। इसके अलावा, ओपन सोर्सिंग एक और ढांचे को अपनाने की चिंता को कम करेगा जिसे अंततः कुछ वर्षों में माइक्रोसॉफ्ट द्वारा छोड़ दिया जाएगा (हमारे वर्तमान ऐप्स डब्ल्यूपीएफ पर बनाए गए हैं, हमारे पिछले ऐप्स एमएफसी पर बनाए गए थे, हमारे पास सिल्वरलाइट का उपयोग कर वेब घटक थे, इसलिए , आप देख सकते हैं कि मैं यहाँ से कहाँ आ रहा हूँ...)

नंबरबॉक्स

हेलो सब लोग! @teaP , @ranjeshj , और मैंने आज हमारे सभी खुले नंबरबॉक्स आइटम के माध्यम से काम किया।

• हमने कुछ पहले ही बंद कर दिए हैं।
• @teaP ने कई और ( लेबल फ़िल्टरिंग यहाँ ) के लिए एक संयुक्त पीआर प्रस्तुत किया।
• हमारे पास बाकी के लिए तय की गई कार्रवाई का एक कोर्स है (#1721 के अपवाद के साथ) और फिक्स ASAP के साथ जवाब देंगे। #1721 को आगे के सर्वोत्तम मार्ग का निदान करने के लिए हमारे ऊपर और अधिक काम करने की आवश्यकता है। हम इसे हल करने के लिए काम करना जारी रखेंगे।

हमारे साथ काम करने के लिए सभी को धन्यवाद। हम ❤️ विनयूआई!

क्या WinUI समुदाय कॉल के लिए कोई "कैलेंडर" है? उदाहरण: एक सार्वजनिक कैलेंडर के रूप में जिसे हम कॉल विवरण के स्वचालित अपडेट के लिए अपने लाइव/गूगल/* कैलेंडर में जोड़/एकीकृत कर सकते हैं।

YouTube ईवेंट समय से पहले शेड्यूल किए गए हैं ताकि आप यहां "आगामी लाइव स्ट्रीम" के अंतर्गत एक Google रिमाइंडर जोड़ सकें:

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

हमारे पास .ics कैलेंडर आमंत्रण भी था लेकिन यह कुछ लोगों के लिए समस्या पैदा कर रहा था और इसे अपडेट करने का कोई तरीका नहीं था इसलिए हमने अभी के लिए इसे छोड़ दिया।