समुदाय प्रतिक्रिया सुनने के लिए धन्यवाद। मैं वास्तव में WinUI 3.0 (Win32 + WinUI + C++) के लिए उत्साहित हूं। ऐसा लगता है कि हम जिस ढांचे की प्रतीक्षा कर रहे हैं! आरआईपी जीडीआई

(Win32 ऐप मॉडल) + (WinUI 3.0 UI) + (.NET या C++ भाषा)

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

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

ओह और डेस्कटॉप में WinUI कैसे काम करेगा, इसके बारे में दस्तावेज़ीकरण, और UWP, WPF, और Win32 से अलग, आने वाले कई प्रश्नों को पूर्व-खाली करने के लिए बहुत उपयोगी होगा।

शायद ढांचे और एपीआई के संयोजन के साथ क्या शामिल है, इसका एक अच्छा मैट्रिक्स, आर्किटेक्चर आरेखों के साथ जो हमें बिल्ड में मिला है!

आप लोग अविश्वसनीय हैं, हर चीज के लिए धन्यवाद!
एक्सप्लेट सेक्शन ने मेरा दिन बना दिया, खासकर कि यूनो रडार पर है।

हमारा ध्यान अभी भी विंडोज 10 और 8.1 पर है, लेकिन हम फीडबैक सुनते हैं कि आप में से कुछ के पास अभी भी विन 7 पर उपयोगकर्ता और ग्राहक हैं और हम समय के साथ बाजार और विकल्पों का मूल्यांकन करेंगे।

यह मानते हुए कि UI फ्रेमवर्क के इस इम्प्लांटेशन को पोर्टेबिलिटी को ध्यान में रखते हुए डिज़ाइन किया गया है, कम से कम इतना पर्याप्त है कि इसका UI कोर (रेंडरिंग / इनपुट) किसी भी विंडोज ओएस के तहत काम कर सकता है जो .NET कोर 3+ का समर्थन करता है। विंडोज 7 पर क्या सीमाएं होंगी यहां तक ​​कि होना? ऐसा लगता है कि डेस्कटॉप पर लोगों द्वारा उपयोग की जाने वाली अधिकांश सुविधाएं केवल काम करेंगी और विशेष/प्लेटफ़ॉर्म विशिष्ट लोगों के लिए जो नहीं करते हैं, शायद उन्हें कोर यूआई सिस्टम का हिस्सा बनने से दूर रखें और उन्हें प्लेटफ़ॉर्म विशिष्ट पैकेजों में रखें जैसे (Win10, Win8.1, Win7 Nugets आदि)।

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

यह भी खुशी है कि आप लोग इसे "मैराथन (महान बंगी गेम भी)" मानते हैं। एक्सएएमएल स्पेस में कम विखंडन सभी के लिए बेहतर है और कई शॉर्ट कट लेने से आप वापस वहीं समाप्त हो जाएंगे जहां आपने शुरू किया था;)

डेस्कटॉप में WinUI कैसे काम करेगा, और UWP, WPF, और Win32 से अलग कैसे काम करेगा, इसके बारे में दस्तावेज़ीकरण बहुत उपयोगी होगा

हम इस पर काम कर रहे हैं और जैसे-जैसे यह विकसित होगा, हम इसे और साझा करेंगे!

यह मानते हुए कि UI फ्रेमवर्क के इस इम्प्लांटेशन को पोर्टेबिलिटी को ध्यान में रखते हुए डिज़ाइन किया गया है, कम से कम इतना पर्याप्त है कि इसका UI कोर (रेंडरिंग / इनपुट) किसी भी विंडोज ओएस के तहत काम कर सकता है जो .NET कोर 3+ का समर्थन करता है। विंडोज 7 पर क्या सीमाएं होंगी यहां तक ​​कि होना?

@ zezba9000 WinUI .NET का उपयोग नहीं करता है, और आपको WinUI के साथ .NET Core का उपयोग करने की आवश्यकता नहीं है: यह OS API पर निर्मित एक मूल ढांचा है, और यह Win8/Win10 में नई कार्यक्षमता पर निर्भर करता है जो इसमें मौजूद नहीं था Win7 - कुछ मामलों में मुख्य विशेषताओं के लिए, न केवल विशिष्ट नियंत्रण जैसी उच्च-स्तरीय ऐड-ऑन सुविधाएँ।

डेस्कटॉप में WinUI कैसे काम करेगा, और UWP, WPF, और Win32 से अलग कैसे काम करेगा, इसके बारे में दस्तावेज़ीकरण बहुत उपयोगी होगा

हम इस पर काम कर रहे हैं और जैसे-जैसे यह विकसित होगा, हम इसे और साझा करेंगे!

यह मानते हुए कि UI फ्रेमवर्क के इस इम्प्लांटेशन को पोर्टेबिलिटी को ध्यान में रखते हुए डिज़ाइन किया गया है, कम से कम इतना पर्याप्त है कि इसका UI कोर (रेंडरिंग / इनपुट) किसी भी विंडोज ओएस के तहत काम कर सकता है जो .NET कोर 3+ का समर्थन करता है। विंडोज 7 पर क्या सीमाएं होंगी यहां तक ​​कि होना?

@ zezba9000 WinUI .NET का उपयोग नहीं करता है, और आपको WinUI के साथ .NET Core का उपयोग करने की आवश्यकता नहीं है: यह OS API पर निर्मित एक मूल ढांचा है, और यह Win8/Win10 में नई कार्यक्षमता पर निर्भर करता है जो इसमें मौजूद नहीं था Win7 - कुछ मामलों में मुख्य विशेषताओं के लिए, न केवल विशिष्ट नियंत्रण जैसी उच्च-स्तरीय ऐड-ऑन सुविधाएँ।

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

अभी यह संभव नहीं है कि क्या यह संभव है - आशा यह है कि जब OS से WinUI बिट्स को हटा दिया जाता है, तो उन्हें एक तरह से ओपन सोर्स प्रोजेक्ट में डाल दिया जाता है, जो अन्य प्लेटफार्मों को किसी प्रकार का संगतता घटक प्रदान करने में सक्षम बनाता है। एक कस्टम रेंडरर के साथ Xamarin, Uno, या .Net Core सोचें।

यह ओएस एपीआई पर बनाया गया एक मूल ढांचा है, और यह Win8/Win10 में नई कार्यक्षमता पर निर्भर करता है जो कि Win7 में मौजूद नहीं था - कुछ मामलों में मुख्य सुविधाओं के लिए

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

ट्रे-आइकन सपोर्ट आदि जैसी चीजें "WinUI विंडोज बेसिक फीचर्स (Win7-Win10)" पैकेज में हो सकती हैं। पुश नोटिफिकेशन जैसी चीजें "WinUI विंडोज एक्सटेंडेड फीचर्स (Win8-Win10)" पैकेज में हो सकती हैं।

आशा है कि यह समझ में आता है।

@mdtauk , @ zezba9000 यह सब सैद्धांतिक रूप से संभव है, और हमारे पास टीम पर बहुत सारी प्लेटफ़ॉर्म एब्स्ट्रैक्शन विशेषज्ञता है। किसी भी चीज़ की तरह, यह केवल लागत, समय-सारणी और अपेक्षित लाभ पर निर्भर करता है

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

क्या आपको 2020+ में Win7 पर नए ग्राहक मिलने की उम्मीद है? प्रतिक्रिया और निश्चित उपयोग के मामले हमें प्राथमिकता देने में मदद करते हैं।

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

क्या आपको 2020+ में Win7 पर नए ग्राहक मिलने की उम्मीद है? प्रतिक्रिया और निश्चित उपयोग के मामले हमें प्राथमिकता देने में मदद करते हैं।

@jesbis मुझे WinUI 3.0 - Linux, Android, iOS, iPadOS और MacOS के लिए Win7 में संगतता जोड़ने में अधिक लाभ नहीं दिखता है, हालांकि, क्रॉस प्लेटफॉर्म समाधान प्रदान करने के लिए फायदेमंद हो सकता है, जो देशी UI ढांचे पर निर्भर नहीं करता है।

@mdtauk
@jesbis मुझे WinUI 3.0 - Linux, Android, iOS, iPadOS और MacOS के लिए Win7 में संगतता जोड़ने में अधिक लाभ नहीं दिखता है, हालांकि, क्रॉस प्लेटफॉर्म समाधान प्रदान करने के लिए फायदेमंद हो सकता है।

इसके लिए सहमत हैं। मैं सिर्फ वेब-असेंबली जोड़ूंगा, मेरे लिए यह लिनक्स से भी ज्यादा जरूरी है।

क्या आपको 2020+ में Win7 पर नए ग्राहक मिलने की उम्मीद है? प्रतिक्रिया और निश्चित उपयोग के मामले हमें प्राथमिकता देने में मदद करते हैं।

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

मेरी कंपनी क्या देखना पसंद करेगी, इस पर स्पष्ट होने के लिए एंड्रॉइड और डब्ल्यूएएसएम समर्थन यूएनओ (और 3 साल पहले) की तुलना में थोड़ा अधिक आधिकारिक होना चाहिए। हम प्रबंधन सॉफ्टवेयर बनाते हैं जो स्थानीय कंप्यूटरों के संग्रह की स्थिति को नियंत्रित करता है और सिस्टम सेटअप में आमतौर पर Win32 API की बड़ी आवश्यकता शामिल होती है (UWP हमारे लिए कभी काम नहीं करेगा लेकिन हम HTML बिल्ड सिस्टम के विपरीत संकलन-समय त्रुटियों के कारण UI को पसंद करते हैं) और हमारे क्लाइंट्स + हमें Win32 + Android + Browser UI अनुभव चाहिए, जिनका अनुभव और अनुभव एक समान हो। एचटीएमएल सिर्फ एक बड़ा दर्द बिंदु है क्योंकि यह अनावश्यक अमूर्तता और जटिलता जोड़ता है जो अन्यथा वहां नहीं होना चाहिए क्योंकि हमारा प्राथमिक कोड आधार सी # में है।

आशा है कि यह आपके लिए बेहतर प्रतिक्रिया है।

इसके अलावा हाँ WASM सबसे बड़ा लक्ष्य है जिसे हम किसी भी अन्य प्लेटफॉर्म के विरुद्ध चाहते हैं। से दूर!!
चूंकि यह हमारे एंड्रॉइड/आईओएस/मोबाइल मुद्दे के साथ-साथ वेब पोर्टल सामग्री को हल करता है।

प्रतिक्रिया सुनने के लिए धन्यवाद!

डेस्कटॉप + WASM सोना होगा!

वाह, चिल्लाने के लिए धन्यवाद, @jesbis! पूरी तरह से अप्रत्याशित और बहुत सराहना और सम्मानित। मैं

विंडोज 7 के आसपास की चर्चा थोड़ी विचलित करने वाली है, क्योंकि प्रयास की मात्रा (लागत का उल्लेख नहीं करने के लिए) WinUI 3.0 में महत्वपूर्ण देरी का कारण बनेगी। जनवरी में विंडोज 7 का जीवन समाप्त हो गया है, और हम सभी ग्राहकों को विंडोज 10 में अपग्रेड करने के लिए प्रोत्साहित कर रहे हैं। मेरे ग्राहक यहां दूसरों के साथ संरेखित नहीं हो सकते हैं, लेकिन विंडोज 8.1 भी हमारे लिए रुचि का मंच नहीं है।

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

पारदर्शिता के लिए टीम के लिए धन्यवाद।

मैं विभिन्न समस्याओं के समाधान में लोगों की मदद करने के लिए लाइन-ऑफ-बिजनेस सॉफ्टवेयर के महत्व का उल्लेख करना चाहूंगा।

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

हम जानते हैं कि हमारे पास अगली डिलीवरी के लिए INotifyDataErrorInfo है। लेकिन यह बहुत अच्छा होगा यदि WinUI के पास भविष्य की डिलीवरी जैसे 3.x आगे के लिए RAD संसाधन हो।

धन्यवाद टीम, उस दिन का इंतजार नहीं कर सकती जब आप वेब असेंबली में पेंसिल करेंगे। यह मेरा दिन, वर्ष और दशक बना देगा और एमएस को प्रौद्योगिकी स्टैक के शीर्ष पर रखेगा। WinUI + Xamarin + WASM + .NET => शुद्ध अजीबता !!

@jesbis इस अद्यतन के लिए धन्यवाद। अच्छी काम टीम: +1:। यह समझना अभी भी जल्दी है, आपको क्या लगता है कि हम कब WinUI 3.0 मील का पत्थर निर्मित और इसके खिलाफ टैग किए गए मुद्दों को देखेंगे?

आपको क्या लगता है कि हम कब WinUI 3.0 मील का पत्थर निर्मित और इसके खिलाफ टैग किए गए मुद्दों को देखेंगे?

@shaggygi अच्छा सवाल! मैंने अभी इसे बनाया है:

विनयूआई 3.0 मील का पत्थर

यह कमाल है दोस्तों!

त्वरित प्रश्न: Windows.UI.Composition को Microsoft.UI.Composition में ले जाना, क्या यह 2.2 या 3.0 के करीब है?
और यह उम्मीद करने के लिए समय सीमा में, क्या यह मेरे लिए २-३ महीने या उससे अधिक की तरह होगा, जब ३.० उपलब्ध हो जाएगा?

भविष्य में, जब आप वर्षों के बारे में बात करते हैं (जैसे कि "वर्ष के अंत तक") तो क्या आप कैलेंडर वर्ष और [Microsoft] वित्तीय वर्षों के बारे में स्पष्ट हो सकते हैं।
जब यह स्पष्ट रूप से नहीं कहा जाता है तो भ्रम करना आसान होता है और मुझे ऐसे मौकों का पता चला है जब लोगों को यह विश्वास हो गया है कि चीजें 6 महीने पहले आ रही थीं।

Windows.UI.Composition को Microsoft.UI.Composition में ले जाना, क्या यह 2.2 या 3.0 के करीब है?

@jtorjo यह 3.0 (न्यूनतम) होगा। हम 3.0 के पहले पूर्वावलोकन में एक प्रारंभिक बिल्ड शामिल करने की उम्मीद कर रहे हैं, लेकिन अभी तक 100% गारंटी नहीं है।

भविष्य में, जब आप वर्षों के बारे में बात करते हैं (जैसे कि "वर्ष के अंत तक") तो क्या आप कैलेंडर वर्ष और [Microsoft] वित्तीय वर्षों के बारे में स्पष्ट हो सकते हैं।

@mrlacey धन्यवाद, मैं इसे ध्यान में

@jesbis यह दुख की बात है। तो आप कह रहे हैं कि यह संभव है कि हमारे पास 3.0 में Microsoft.UI.Composition नहीं होगा?

@jtorjo

हम 3.0 के

अक्सर कई पूर्वावलोकन रिलीज़ होते हैं। उदाहरण के लिए, .NET कोर 3 पूर्वावलोकन 6 पर है।

हमारी योजना 3.0 में कंपोजिशन एपीआई को शामिल करने की है।

हालांकि रचना भाग से पहले Xaml ढांचा हिस्सा खुला स्रोत होगा।

@jesbis धन्यवाद, अच्छा लगता है!

शानदार रोडमैप, बढ़िया काम!

यहां हर किसी के रूप में, मुझे पारदर्शिता पसंद है और मैं वास्तव में WinUI 3.0 की प्रतीक्षा कर रहा हूं। मेरे लिए WinUI 3.0 सबसे रोमांचक चीज है क्योंकि 2006 में wpf को पेश किया गया था।

मेरे पास अभी भी विंडोज 7 चलाने वाले ग्राहक हैं, लेकिन मुझे लगता है कि विंडोज 10 समर्थन सबसे महत्वपूर्ण है और मैं Win7 समर्थन के लिए समय और संसाधन खर्च नहीं करूंगा। मैं जिन कंपनियों में काम करता हूं, वे 10 पर स्विच कर रही हैं। और मुझे लगता है कि 2020 के अंत में मुझे पता चलेगा कि एकमात्र कंपनी जो अभी भी विंडोज 7 का उपयोग करती है, वह शायद मेरा दंत चिकित्सक होगा। और अगर वह मुझसे उसके लिए एक विंडोज ऐप लिखने के लिए कह सकता है, तो मैं उसके पीसी को विंडोज 10 में माइग्रेट कर दूंगा। :-)

भविष्य में WASM समर्थन अद्भुत होगा।

कल एक सम्मेलन में:

@jesbis और टीम को दिखाने के लिए एक छोटी सी कहानी, जो हम यहां लिखते और भाग लेते हैं, उत्साहित हिमशैल का सिरा मात्र हैं। :-)

कल ही मैंने जर्मनी में एक डेवलपर सम्मेलन में कुछ .NET डेवलपर्स के साथ बातचीत की और मैंने उन्हें WinUI 3.0 के बारे में बताया, और वे इसके बारे में नहीं जानते थे। मैंने उन्हें रोडमैप के बारे में बताया और उन्होंने कहा:

"वाह यह शानदार है"।

समूह की एक लड़की ने मुझसे पूछा:

"लेकिन क्या आपको हमें यह सब बताने की अनुमति है?"

मैंने उसकी और अन्य लोगों की ओर देखा, और फिर मैंने अवसर का एक मौखिक विराम के लिए लिया

await Task.Delay(3000);

मेरे कहने से पहले

"नर्क हाँ! आप यह सब GitHub पर पढ़ सकते हैं"।

धन्यवाद @jesbis और इसमें शामिल सभी लोग। विंडोज़ डेवलपर बनने का अच्छा समय ❤️

मुझे उम्मीद है कि प्रथम-पक्ष एप्लिकेशन (जैसे वर्ड?) WinUI की परतों का उपयोग कर सकते हैं, और डेवलपर्स को यह देखकर खुशी होगी कि, "अरे, WinUI एक वास्तविक चीज़ है जो एक खिलौने के बजाय व्यवसाय चला सकती है"।
अगर वे पहले से ही इसका इस्तेमाल कर रहे हैं, तो इसे ज़ोर से बोलें।

WPF, Win32 और WinUI डेस्कटॉप के लिए ऐक्रेलिक।

ओह और शायद केवल सक्रिय विंडोज़ नीति पर ऐक्रेलिक पर पुनर्विचार करें।

हां, यदि आपके पास 1 से अधिक मॉनिटर हैं, तो यह सिर्फ एक विंडो में रेंडर करता है। कम से कम एकाधिक मॉनीटरों में इसे ठीक से काम करना चाहिए ....

मैं यूडब्ल्यूपी ऐप्स में यूआई नियंत्रण के दो सेट उपलब्ध होने के विकास अनुभव प्रभावों के बारे में सोच रहा था - जब हमारे पास WinUI नियंत्रण और विरासत UI नियंत्रण दोनों तक पहुंच होगी, जब सी # कोड-बैक में, IntelliSense क्योंकि इसे हमेशा हमें सही ढंग से करने की आवश्यकता होगी केवल using जोड़ने और जारी रखने के लिए Alt + Enter जाने के बजाय नियंत्रण किस नामस्थान से आना चाहिए चुनें। क्या इससे किसी तरह बचना संभव होगा?

एक बार WinUI3 डेवलपर्स के लिए उपलब्ध हो जाने के बाद, Windows 10 SDK को उन प्रोजेक्ट्स के लिए नाम स्थान के परिवर्तन का सुझाव देने पर विचार करना चाहिए जो एक समर्थित SDK स्थापित के साथ खोले गए हैं। लोगों को OS नेमस्पेस से दूर ले जाने का प्रयास करें।

WPF, Win32 और WinUI डेस्कटॉप के लिए ऐक्रेलिक।

मैं सबसे पहले जो देखना चाहता हूं वह है एमएस परिपक्व Xaml द्वीप समूह ताकि, एक उदाहरण के रूप में, टाइटलबार में ऐक्रेलिक का उपयोग गैर-यूडब्ल्यूपी परियोजनाओं के लिए किया जा सकता है जो उनके यूआई को WinUI पर आधारित करते हैं ( इस पोस्ट का अंतिम पैराग्राफ देखें)। @ marb2000 शायद इस बारे में पूछने वाला व्यक्ति है।

@MartinZikmund हम इस परिदृश्य से बचना चाहते हैं। WinUI 3 का उपयोग करते समय आपके पास केवल पैकेज से नियंत्रणों तक पहुंच होनी चाहिए। विचार यह है कि हमारे पास नवीनतम और सबसे बड़े बदलावों के साथ आपकी जरूरत की हर चीज है।

@MartinZikmund
@LucasHaines

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

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

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

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

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

लाभ:

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

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

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

क्रॉस प्लेटफॉर्म नेटिव ऐप में लिपटे ब्लेज़र + (नॉन एचटीएमएल) यूआई पर स्टीव सैंडर्सन द्वारा बस एक शानदार प्रस्तुति देखी गई। वीडियो में लगभग 52 मिनट। UWP, WinUI और c# प्रशंसकों के लिए अवश्य देखें। मैं ब्लेज़र से गंभीर रूप से प्रभावित हूँ !!!

https://youtu.be/uW-Kk7Qpv5U

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

कुछ नियंत्रण प्रदर्शन, और RAM उपयोग, बहुत बेहतर हो सकते हैं, जैसे ListView/GridView = ItemsControl.

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

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

प्रदर्शन निश्चित रूप से कुछ ऐसा है जिसमें हम निवेश करना चाहते हैं, लेकिन मुझे 3.0 के लिए किसी भी सुधार की उम्मीद नहीं है। प्रारंभिक 3.0 प्रयास ज्यादातर Xaml को NuGet पैकेज और ओपन-सोर्सिंग के रूप में शिप करने पर केंद्रित है।

WinUI 3.0 (आज UWP Xaml की तरह) कंपोजीशन लेयर पर बनाया गया है और DWM के माध्यम से इसके अधिकांश रेंडरिंग और एनीमेशन ऑफ-थ्रेड को चलाता है।

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

इन परिदृश्यों पर विचार करते समय अक्सर प्रदर्शन बनाम लचीलापन/समृद्धि ट्रेडऑफ़ होता है। Xaml- आधारित प्लेटफ़ॉर्म (UWP और wpf सहित) में प्रत्येक नियंत्रण के लिए बड़े, समृद्ध UI ऑब्जेक्ट ट्री होते हैं: जो किसी भी नियंत्रण की शैली और UX को बदलने के लिए बहुत अधिक लचीलापन प्रदान करता है, जबकि कुछ अन्य प्लेटफ़ॉर्म में अधिक चापलूसी वाले ऑब्जेक्ट ट्री होते हैं। जो उतने लचीले नहीं हैं लेकिन कभी-कभी तेजी से लोड किए जा सकते हैं।

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

मुझे आशा है कि माइक्रोसॉफ्ट एक नया comctl32.dll और comdlg32.dll प्रदान कर सकता है जो कि WinUI 3.0 पर आधारित है।

क्योंकि अधिकांश Win32 ऐप्स में आधुनिक UI अनुभव होगा और यह डेवलपर्स को अपने ऐप्स को आधुनिक UI के अनुकूल बनाने में मदद करेगा।

कई Win32 डेवलपर्स को कई विंडोज़ संस्करणों को अनुकूलित करने की आवश्यकता होती है। इसलिए वे आज सीधे WinUI का उपयोग नहीं कर सकते हैं। यह बहुत अच्छा है यदि Microsoft उन्हें अपने ऐप्स के UI को आधुनिक बनाने के कार्यभार को कम करने में मदद करने के लिए एक विधि प्रदान कर सकता है।

साथ ही, मुझे आशा है कि Microsoft C++ Win32 ऐप्स के लिए XAML डिज़ाइनर प्रदान कर सकता है जो WinUI का उपयोग कर रहा है।

केंजी मौरीक

@MouriNaruto आप आज (Win32 से) FileOpenPicker का उपयोग कर सकते हैं।

@MouriNaruto आप आज (Win32 से) FileOpenPicker का उपयोग कर सकते हैं।

मुझे पता है, लेकिन मुझे उम्मीद है कि सभी आधुनिक सामान्य नियंत्रण और संवाद Win32 में लाएंगे।

@MouriNaruto

तकनीकी रूप से यह संभव है। लेकिन विंडोज डेवलपर्स को न केवल COMCTL और COMDLG कार्यान्वयन के सटीक व्यवहारों को फिर से बनाना होगा बल्कि कोडबेस में मौजूद ज्ञात और अज्ञात बग्स को भी बनाना होगा।

संगतता हमारा उन्मादी है !

यहां तक ​​कि अगर वे ऐसा करते हैं, तब तक वे इसे पूरा करते हैं, उन कामों का उपयोग करने वाले प्रत्येक सॉफ़्टवेयर के पास WinUI में माइग्रेट करने के लिए पर्याप्त समय होगा! व्यंग्य!! मैं

@MarkIngramUK

एफवाईआई : FileOpenPicker मूल WinRT संवाद/नियंत्रण नहीं है। यह अनिवार्य रूप से ExplorerFrame का एक आवरण है जो स्वयं DirectUI (एटीजी टीम द्वारा विकसित और DirectX पर आधारित) और COM में लिखा गया है!

तकनीकी रूप से यह संभव है। लेकिन विंडोज डेवलपर्स को न केवल COMCTL और COMDLG कार्यान्वयन के सटीक व्यवहारों को फिर से बनाना होगा, बल्कि कोडबेस में मौजूद ज्ञात और अज्ञात बग्स को भी बनाना होगा।
संगतता हमारा उन्मादी है!
यहां तक ​​कि अगर वे ऐसा करते हैं, तब तक वे इसे पूरा करते हैं, उन कामों का उपयोग करने वाले प्रत्येक सॉफ़्टवेयर के पास WinUI में माइग्रेट करने के लिए पर्याप्त समय होगा! व्यंग्य!! मैं

मुझे नहीं लगता कि वास्तविकता के कारण इसके बिना कई परियोजनाओं के लिए WinUI में माइग्रेट करना आसान है।

आपने कहा है "संगतता हमारी उन्मादी है!"। हाँ, यह भी मेरे सुझावों का एक कारण है। व्यंग्य!! मैं

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

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

1. क्या प्रत्येक ऐप को इसके साथ अपनी WinUI लाइब्रेरी लाने की आवश्यकता है या संभव ऐप्स के बीच साझा कर रहा है, शायद स्वचालित रूप से विंडोज मैकेनिम्स के माध्यम से भी
2. क्या WinUI को स्थिर रूप से लिंक करना संभव होगा?
3. मान लें कि मुझे इसे पुनर्वितरित करना है, WinUI मोटे तौर पर MB में कितना बड़ा होगा?

क्या प्रत्येक ऐप को इसके साथ अपनी WinUI लाइब्रेरी लाने की आवश्यकता है या संभव ऐप्स के बीच साझा कर रहा है, शायद स्वचालित रूप से विंडोज मैकेनिम्स के माध्यम से भी

हम मुख्य रूप से WinUI 3 को NuGet के माध्यम से वितरित करने की योजना बना रहे हैं, जिसमें स्वचालित रूप से कैश और पैकेज साझा करने के लिए तंत्र हैं - यहां अधिक जानकारी उपलब्ध है:

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

क्या WinUI को स्थिर रूप से लिंक करना संभव होगा?

यह ऐसा कुछ नहीं है जिसकी हम वर्तमान में योजना बना रहे थे - क्या आपके मन में कोई ऐसा परिदृश्य है जहां यह एक लाभ होगा?

मान लें कि मुझे इसे पुनर्वितरित करना है, WinUI मोटे तौर पर MB में कितना बड़ा होगा?

हम अभी भी काम कर रहे हैं कि अंतिम निर्भरता ग्राफ कैसा दिखेगा, लेकिन यूआई टुकड़ों के लिए यह प्रासंगिक मौजूदा सिस्टम 32 डीएल आकार (एमबी के 10) के समान होगा।

हम मुख्य रूप से WinUI 3 को NuGet के माध्यम से वितरित करने की योजना बना रहे हैं, जिसमें स्वचालित रूप से संकुल को कैश और साझा करने के लिए तंत्र है

मुझे लगा कि नगेट सिर्फ विकास के लिए है या मुझे कुछ याद आ रहा है? जहां तक ​​​​मुझे पता है कि प्रत्येक ऐप द्वारा व्यक्तिगत रूप से नगेट आधारित पैकेजों को तैनात किया जाना है और इसे साझा नहीं किया जा सकता है। यही कारण है कि एक साझा डॉटनेट कोर रनटाइम के लिए समर्पित इंस्टॉलर हैं, अन्यथा यह आवश्यक नहीं होगा कि डॉटनेट कोर पैकेज पहले से ही नगेट पर हैं ...

आपको केवल UI फ्रेमवर्क पैकेज साझा करने के लिए कोई विकास उपकरण या SDK इंस्टॉल करने की आवश्यकता नहीं है। .NET कोर के लिए डब्ल्यूपीएफ और विनफॉर्म में एक ही समस्या थी और एक साझा बंडल बनाने में निवेश किया गया था ताकि लोगों को अंतिम उपयोगकर्ता मशीनों पर एसडीके स्थापित करने की आवश्यकता न हो , जो संभवतः WinUI के लिए भी करने योग्य है (शायद यहां तक ​​​​कि यहां तक ​​​​कि अपने आप को WindowsDesktop बंडल में शामिल करें)

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

Microsoft Store द्वारा डिलीवर किए गए ऐप्स के लिए, रिलीज़ पैकेज सामग्री को परिनियोजन के समय भी स्वचालित रूप से साझा किया जाना चाहिए।

अन्य माध्यमों से परिनियोजित किए गए win32 ऐप्स के लिए, यह हमारी टूडू सूची में विकल्पों की जांच करने के लिए है जैसे कि आपने क्या उल्लेख किया है 😊

क्या WinUI को स्थिर रूप से लिंक करना संभव होगा?

यह ऐसा कुछ नहीं है जिसकी हम वर्तमान में योजना बना रहे थे - क्या आपके मन में कोई ऐसा परिदृश्य है जहां यह एक लाभ होगा?

मुझे लगता है कि मुझे स्पष्ट करने की आवश्यकता है: क्या एक स्थिर रूप से जुड़े EXE में WinUI का उपयोग करना संभव होगा (जो स्थिर रूप से वीसी-रनटाइम को जोड़ता है)? मुझे लगता है कि सी ++/विनआरटी की वजह से कोई समस्या नहीं होनी चाहिए, लेकिन मैं सिर्फ यह सुनिश्चित करना चाहता था ...

मान लें कि मुझे इसे पुनर्वितरित करना है, WinUI मोटे तौर पर MB में कितना बड़ा होगा?

हम अभी भी काम कर रहे हैं कि अंतिम निर्भरता ग्राफ कैसा दिखेगा, लेकिन यूआई टुकड़ों के लिए यह प्रासंगिक मौजूदा सिस्टम 32 डीएल आकार (एमबी के 10) के समान होगा।

जानकारी के लिए धन्यवाद।

इतने बड़े उपक्रम के लिए बहुत बढ़िया पारदर्शिता बीटीडब्ल्यू, मुझे यह बहुत पसंद है।

मुझे लगता है कि मुझे स्पष्ट करने की आवश्यकता है: क्या एक स्थिर रूप से जुड़े EXE में WinUI का उपयोग करना संभव होगा (जो स्थिर रूप से वीसी-रनटाइम को जोड़ता है)? मुझे लगता है कि सी ++/विनआरटी की वजह से कोई समस्या नहीं होनी चाहिए, लेकिन मैं सिर्फ यह सुनिश्चित करना चाहता था

यह संभव होना चाहिए (सिद्धांत रूप में) लेकिन जैसा कि @jesbis ने कहा, हम अभी भी इस कहानी पर काम कर रहे हैं कि साझा ढांचे पर अनपैक किए गए ऐप्स कैसे प्राप्त होंगे। हमारे पास एक रेडिस्ट इंस्टॉलर होना चाहिए, जैसे कि .NET कोर इसे कैसे कर रहा है।

विंडोज 7 के आसपास की चर्चा थोड़ी विचलित करने वाली है, क्योंकि प्रयास की मात्रा (लागत का उल्लेख नहीं करने के लिए) WinUI 3.0 में महत्वपूर्ण देरी का कारण बनेगी। जनवरी में विंडोज 7 का जीवन समाप्त हो गया है, और हम सभी ग्राहकों को विंडोज 10 में अपग्रेड करने के लिए प्रोत्साहित कर रहे हैं। मेरे ग्राहक यहां दूसरों के साथ संरेखित नहीं हो सकते हैं, लेकिन विंडोज 8.1 भी हमारे लिए रुचि का मंच नहीं है।

तुम सही हो। लेकिन हम अपने ग्राहक को नियंत्रित नहीं कर सकते हैं और चीन में 60% से अधिक सिस्टम win7 है। और हम इस बाजार को नहीं छोड़ सकते हैं, इसलिए हम ऐसी किसी भी तकनीक का उपयोग नहीं कर सकते हैं जो win7 का समर्थन नहीं करती है।

डेटा Baidu से है, देखें https://tongji.baidu.com/data/os

लेकिन हम अपने ग्राहक को नियंत्रित नहीं कर सकते हैं और चीन में 60% से अधिक सिस्टम win7 है

टीबीएच मैं सिर्फ .NET फ्रेमवर्क 4.8 + डब्ल्यूपीएफ के साथ रहूंगा यदि आप Win7 पर फंस गए हैं।

लेकिन हम अपने ग्राहक को नियंत्रित नहीं कर सकते हैं और चीन में 60% से अधिक सिस्टम win7 है

टीबीएच मैं सिर्फ .NET फ्रेमवर्क 4.8 + डब्ल्यूपीएफ के साथ रहूंगा यदि आप Win7 पर फंस गए हैं।

लेकिन Win7 Sp1 .NET Framework 4.8 स्थापित कर सकता है और win7 बिना sp1 स्थापित नहीं कर सकता।

.NET फ्रेमवर्क सिस्टम आवश्यकताएँ |

यदि आपके पास SP1 भी नहीं है, तो आप जीवन के अंत से पहले ही ६ वर्ष बीत चुके हैं।

सर्विस पैक के बिना विंडोज 7 आरटीएम के लिए समर्थन 9 अप्रैल, 2013 को समाप्त हो गया।

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

यदि आप Windows 7 का समर्थन चाहते हैं तो आपको ऐसी तकनीक का उपयोग करना चाहिए जो पहले से ही Windows 7 का समर्थन करती हो, और Microsoft से आपके लिए इस समस्या को हल करने की अपेक्षा नहीं करनी चाहिए।

@MarkIngramUK ऐसा नहीं है कि Microsoft ने मेरे लिए इस समस्या का समाधान किया है, लेकिन मैं अपने ग्राहकों का समर्थन नहीं कर सकता जो बिना sp1 के win7 का उपयोग कर रहे हैं। मैं अपने ग्राहकों को किसी भी प्रणाली का उपयोग करने के लिए नियंत्रित नहीं कर सकता, लेकिन वे जो बिना SP1 के win7 का उपयोग करते हैं, वे हमारे आवेदन को छोड़ देंगे और इसका मतलब है कि हमने यह बाजार खो दिया है। लेकिन मेरे प्रतियोगी जो नई तकनीक का उपयोग नहीं करते हैं, वे बिना SP1 के win7 का समर्थन कर सकते हैं और मेरे प्रतियोगी इस बाजार को जीतेंगे।

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

यह मेरे उद्योग की यथास्थिति है, और उपरोक्त निष्कर्ष अन्य उद्योगों के लिए उपयुक्त नहीं हो सकते हैं।

@lindexi जैसा कि मैं कहता हूं, आप उम्मीद नहीं कर सकते कि नई तकनीक को ऐसे OS में पोर्ट किया जाएगा जो पहले से ही जीवन के 6 साल पहले का है। अगर आप पुराने OS को टारगेट करना चाहते हैं तो आपको पुरानी तकनीक की जरूरत है।

@lindexi मुझे लगता है कि यदि ग्राहक समर्थित तकनीक का उपयोग नहीं करना चाहता है और कुछ पुराना पसंद करता है, तो वे आधुनिक यूआई होने की उचित उम्मीद नहीं कर सकते हैं। वे दो आवश्यकताएं विशुद्ध रूप से परस्पर अनन्य हैं ...

@MarkIngramUK उदास। मुझे लगता है कि जब मैं आज की नई तकनीक का उपयोग कर सकता हूं, तो यह नई तकनीक पुरानी तकनीक बन गई है।

@lindexi जो सचमुच हो रहा है उसके विपरीत है। आप नई तकनीक को "पुरानी तकनीक" सिर्फ इसलिए नहीं कह सकते क्योंकि इसे किसी प्राचीन OS में पोर्ट नहीं किया जा रहा है। यदि आप Win7 (कोई SP1) समर्थन चाहते हैं, तो WinForms या MFC या कुछ और का उपयोग करें।

@MartinZikmund आप सही कह रहे हैं। वास्तव में, लगभग कोई भी हमारे उपयोगकर्ता कंप्यूटर तकनीक को नहीं समझते हैं, यहां तक ​​कि win7 और win10 भी नहीं बता सकते हैं। वे परवाह नहीं करते कि हम किस तकनीक का उपयोग करते हैं।

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

अपने ग्राहकों पर मैंने विंडोज 10 मीडिया के साथ एक यूएसबी स्टिक (पेनड्राइव) का इस्तेमाल किया, और इसे विंडोज 7 से नवीनतम विंडोज 10 में मुफ्त में अपग्रेड किया। उन्हें एंटीवायरस, विंडोज अपडेट, एज वेबब्राउज़र के साथ एक आधुनिक ओएस का लाभ मिला है और पुराने जैसे WinForms, wpf से GUI तकनीकों का समर्थन करता है, जिसमें UWP और उससे आगे (WinUI) शामिल हैं। इसके अलावा, शटडाउन के बजाय, मैंने विंडोज को हाइबरनेट पर सेट किया, और उपयोगकर्ताओं को पीसी के साथ काम करना शुरू करने के लिए बस पावर बटन को पुश करने और पीसी का उपयोग करने के बाद पावर बटन को दबाने के लिए सिखाया।
इसके अलावा, मैं आसानी से मशीनों को स्थापित/अपग्रेड करने के लिए, नेटवर्क पर एक आईएसओ डालता हूं।

और उन्हें अपने कंप्यूटर पर भी Candy Crush प्रीइंस्टॉल्ड होने का फायदा है!

राय

मैंने सोचा था कि पुराने संस्करण विंडोज़ समर्थन के लिए डब्ल्यूपीएफ के नियंत्रण कार्यान्वयन को विनयूआई में विलय किया जा सकता है। (उदाहरण के लिए, विंडोज 7.) लेकिन ऑफिस की राजनीति के कारण माइक्रोसॉफ्ट के लिए इसे सच करना बहुत कठिन है, योग्य।

जवाब

@ लिंडेक्सी
मुझे पता है कि आज चीन में बहुत सारे पुराने विंडोज संस्करण उपयोगकर्ता हैं। लेकिन मुझे लगता है कि आज विंडोज एनटी 5.x उपयोगकर्ताओं को छोड़ना जरूरी है और मुझे पता है कि यह मुश्किल है।

@MartinZikmund

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

यदि आप नहीं चाहते कि आपका काम अल्पसंख्यकों के लिए हो, तो आधुनिक UI और पुराने प्लेटफ़ॉर्म समर्थन दोनों ही चीन में आवश्यक हैं। तो मेरे एक मित्र, एक चीनी डेवलपर, पोर्ट ब्लिंक और V8 से Windows XP बिना किसी अपडेट के इंस्टॉल किए गए हैं , बहुत सारे डेवलपर अपने आधुनिक ऐप अनुभवों को लागू करने के लिए इसका उपयोग करते हैं। चीन में, न्यूनतम ऑपरेटिंग सिस्टम संस्करण आवश्यकता बिना किसी अद्यतन के स्थापित संस्करण के बराबर है। उदाहरण के लिए, यदि आप जानते हैं कि चीन से किसी ऐप के ऑपरेटिंग सिस्टम संस्करण की आवश्यकता विंडोज 7 है, तो यह बताता है कि आप "विंडोज 7 आरटीएम" या "6.1.760.16385 (win7_rtm.090713-1255)" के तहत ऐप का उपयोग कर सकते हैं। Android की दुनिया में भी, कई ऐप आज भी Android 4.4 को सपोर्ट करते हैं।

यही कारण है कि गैर-चीनी डेवलपर्स द्वारा बनाए गए अधिकांश ऐप चीन में बहुसंख्यक पसंद नहीं हो सकते हैं।

पीएस हम नवीनतम विजुअल स्टूडियो 2019 का उपयोग बिना किसी अपडेट के विंडोज एक्सपी आरटीएम के लिए ऐप बनाने के लिए कर सकते हैं, नवीनतम विंडोज 10 एसडीके और नवीनतम सी ++ 17 मानक या अभी सी ++ 20 की कोशिश कर रहे हैं। VC-LTL (https://github.com/Chuyu-Team/VC-LTL) और YY-Thunks (https://github.com/Chuyu-Team/YY-Thunks) के कारण।

अपने बारे में ध्यान दें

अपने अधिकांश समय में, मैं नवीनतम स्थिर विंडोज बिल्ड का उपयोग करता हूं। (मैं आज 10.0.18362 का उपयोग करता हूं। मैं 19H1 और 19H2 का उपयोग कर रहा हूं।) लेकिन मेरे Win32 प्रोजेक्ट्स को बिना किसी अपडेट के विंडोज विस्टा आरटीएम के लिए डिज़ाइन किया गया बिना किसी अपडेट के या बाद में

केंजी मौरीक

कृपया, कृपया, सभी WinUI 3.0 नियंत्रण वर्गों को अन-सीलिंग करने पर विचार करें!

मेरी समझ के अनुसार, माइक्रोसॉफ्ट ने सभी यूडब्ल्यूपी नियंत्रण वर्गों को सील करने का फैसला किया, क्योंकि जावास्क्रिप्ट (जो विरासत को नहीं जानता) विरासत में मिली कक्षाओं के साथ उपयोग किए जाने पर समस्याएं पैदा करता है। अब जबकि JS/HTML को पदावनत कर दिया गया है, नए UI ढांचे को अभी भी सभी वर्गों को सील करने की कोई आवश्यकता नहीं है। अन-सेलिंग से यूडब्ल्यूपी नियंत्रणों को अनुकूलित करना बहुत आसान हो जाएगा, जैसे डब्ल्यूपीएफ में यह हमेशा संभव था। यह कस्टम वर्चुअलाइजिंग सूची नियंत्रण या पैनल लिखते समय भी बहुत मदद करेगा, ताकि एक गैर-मुहरबंद वर्चुअलाइजिंग बेस क्लास इनहेरिट किया जा सके। न तो C#, न ही C++/CX या C++/WinRT को इनहेरिटेंस की समस्या है। यह केवल जेएस/एचटीएमएल नामक विफलता थी जिसने इसे हम पर मजबूर कर दिया।

तो कृपया WinUI 3.0 बनाते समय इस अनावश्यक प्रतिबंध को हटा दें।

@gisfromscratch प्रतिक्रिया के लिए धन्यवाद! हम निश्चित रूप से सी ++ विकास (विशेष रूप से सी ++/विनआरटी के साथ) का समर्थन करना चाहते हैं।

सी ++ का उपयोग करना क्या आसान बना देगा? क्या आपने सीएक्स के बजाय सी ++/विनआरटी की कोशिश की

क्या अधिक नमूना ऐप्स मदद करेंगे?

आपने उल्लेख किया है कि बाध्यकारी पर दस्तावेज़ ढूंढना कठिन था: क्या कोई अन्य विशिष्ट विशेषताएं थीं जिन्हें बेहतर दस्तावेज़ीकरण की आवश्यकता थी?

कृपया, कृपया, सभी WinUI 3.0 नियंत्रण वर्गों को अन-सीलिंग करने पर विचार करें!

@lukasf यह कुछ ऐसा है जो हम करने जा रहे हैं #780 में कुछ संबंधित चर्चा चल रही है

@jesbis मुझे C++/WinRT का उपयोग करके अपने हाथों को गंदा करना है। मैंने अभी फोटो संपादक सी++/विनआरटी नमूना आवेदन का पालन किया है । लेकिन जब आप प्रदान किए गए लिंक जैसे डेटा बाइंडिंग को गहराई से पढ़ते हैं तो आप बहुत सारे सी # स्निपेट में समाप्त होते हैं और केवल कुछ साइड नोट्स जैसे "सी ++/विनआरटी के लिए, किसी भी रनटाइम क्लास जिसे आप अपने एप्लिकेशन में घोषित करते हैं जो बेस क्लास से प्राप्त होता है, है एक कंपोज़ेबल क्लास के रूप में जाना जाता है। और कंपोज़ेबल क्लासेस के आसपास बाधाएँ हैं ..."। यह पृष्ठ ९५% C# और केवल ५% C++ को लक्षित कर रहा है।

@gisfromscratch धन्यवाद! हम इसे ध्यान में रखेंगे क्योंकि हम WinUI 3 के लिए डॉक्स को अपडेट करने पर काम कर रहे हैं।

यदि यह मदद करता है, तो आपके द्वारा उल्लिखित डेटाबाइंडिंग पृष्ठ विशेष रूप से C++/WinRT के साथ डेटाबाइंडिंग के बारे में कुछ अलग-अलग पृष्ठों से लिंक करता है, उदाहरण के लिए:

एक्सएएमएल नियंत्रण;

एक्सएएमएल आइटम नियंत्रण;

उस खंड में कई अन्य C++/WinRT- विशिष्ट विषय भी हैं।

आपकी महान नौकरियों के लिए धन्यवाद! Xaml द्वीप को WinUi 3.0 से हटाते हुए देखकर बहुत खुशी हुई।
बीटीडब्ल्यू: मुझे आश्चर्य है कि WinUi 3.0 में भाषा प्रक्षेपण का निम्न-स्तरीय कार्यान्वयन WinRT घटक से अलग होगा। WinRT घटक के भाषा प्रक्षेपण के कार्यान्वयन से .NET UWP प्रोजेक्ट में संकलन समय और रन टाइम दोनों में भारी प्रदर्शन प्रभावित हुआ है। चूंकि WinUi 3.0 को UWP से पूरी तरह से अलग कर दिया गया है, मुझे उम्मीद है कि भाषा इंटरऑप कार्यान्वयन में कुछ सुधार हो सकता है।

@zenjia XAML द्वीप को WinUI 3 से नहीं हटाया गया है। WinUI 3 में वे API होंगे जो WPF/WinForms/MFC ऐप्स को WinUI 3 नियंत्रणों को होस्ट करने की अनुमति देते हैं।

मैं WinUI में प्रगति को जारी रखने की कोशिश कर रहा हूं। मैंने अतीत में सी # के साथ यूडब्ल्यूपी ऐप्स लिखने की कोशिश की है लेकिन पाया कि यह एक कठिन लड़ाई थी। लेकिन मैं winui ३.० के बाद फिर से प्रयास करने के लिए उत्सुक हूँ।

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

• क्या देशी नियंत्रणों के लिए .net रैपर भी खुले स्रोत वाले होंगे? यह स्पष्ट नहीं है कि यह जीथब रेप्रो है जो विनुई के नेट पक्ष के लिए ज़िम्मेदार है, क्योंकि मुझे लगता है कि केवल सी # कोड स्वचालित परीक्षणों के लिए है। मैं Microsoft.UI.Xaml.UIElement जैसी चीज़ों की तलाश में हूं लेकिन वह कोड कहीं भी नहीं मिल रहा है।

• जब हम winui 3.0 की रिलीज़ पर पहुँचते हैं, तो क्या UWP ऐपमॉडल और win32 ऐपमॉडल एक ही .Net Core रनटाइम पर चल रहे होंगे? मैंने कभी यह पता नहीं लगाया है कि यूडब्ल्यूपी अनुप्रयोगों द्वारा नेट कोर का कौन सा संस्करण उपयोग किया जाता है। मुझे लगता है कि यह कुछ ऐसा है जो विंडोज़ में ही बनाया गया है, और विंडोज़ 10 एसडीके वीएस 2019 को यूडब्ल्यूपी में उपलब्ध नेट कोर के सही संस्करण को लक्षित करने की इजाजत दे रहा है।

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

• कोई भी मौका है कि एक्सएमएल द्वीपों के साथ एक डब्ल्यूपीएफ ऐप (50% डब्ल्यूपीएफ और 50% डब्ल्यूआईएनयूआई कहें) किसी दिन एआरएम 64 में मूल रूप से संकलित किया जा सकता है? एआरएम को लक्षित करना उन अनुप्रयोगों के साथ संभव है जो 100% यूडब्ल्यूपी हैं, और यह अच्छा होगा यदि डब्ल्यूपीएफ निर्भरता हमें अपने मूल एआरएम 64 लक्ष्यीकरण को छोड़ने के लिए मजबूर नहीं करेगी। (विकल्प ऐप को x86 एमुलेशन में चलाना होगा - लेकिन यह धीमा है और उपलब्ध मेमोरी को सीमित करता है जिसका उपयोग किया जा सकता है)।

उम्मीद है कि ये सभी प्रश्न विनुई के रोडमैप के लिए प्रासंगिक हैं। किसी भी सलाह की सराहना की जाएगी।

क्या देशी नियंत्रणों के लिए .net रैपर भी खुले स्रोत वाले होंगे? यह स्पष्ट नहीं है कि यह गीथब रेप्रो है जो विनुई के नेट पक्ष के लिए ज़िम्मेदार है, क्योंकि मुझे लगता है कि केवल सी # कोड स्वचालित परीक्षणों के लिए है। मैं Microsoft.UI.Xaml.UIElement जैसी चीज़ों की तलाश में हूं लेकिन वह कोड कहीं भी नहीं मिल रहा है।

UIElement WinUI 2 में नहीं है इसलिए यह वर्तमान में रेपो में नहीं है। यह WinUI 3 में होगा जो अभी तक रिलीज़ या ओपन सोर्स नहीं किया गया है, लेकिन हम इस पर काम कर रहे हैं!

आप WinRT अनुमानों के माध्यम से .NET के संपर्क में आने वाले अन्य मूल नियंत्रणों के रेपो में उदाहरण देख सकते हैं, उदाहरण के लिए WinUI 2.2 नियंत्रण यहां प्रलेखित

@ marb2000 द्वीपों/डेस्कटॉप प्रश्नों पर सर्वोत्तम टिप्पणी कर सकता है।

प्रश्न: _क्या WinUI 3 UWP और डेस्कटॉप समान .NET रनटाइम का उपयोग करेंगे?_
ए: हाँ, यह योजना है। UWP और डेस्कटॉप .NET Core 3 का उपयोग करेंगे। प्रबंधित WinRT पुस्तकालय .NET मूल के बजाय .NET Core 3 का उपयोग करेंगे।

प्रश्न: _क्या डब्ल्यूपीएफ और यूडब्ल्यूपी एक ही हवाई क्षेत्र साझा करेंगे?_
ए: हालांकि डब्ल्यूपीएफ और विनयूआई (और एक्सएएमएल यूडब्ल्यूपी) समान लगते हैं, वे नहीं हैं। WPF DirectX9 का उपयोग करता है, और WinUI/XAML UWP Windows.UI.Composition का उपयोग XAML की संरचना, रेंडरिंग और एनिमेशन आवश्यकताओं (DirectX11 के आधुनिक संस्करण के अलावा) के लिए करता है। अफसोस की बात है कि इसका कारण इंटरऑप बहुत जटिल है। डब्ल्यूपीएफ एडोर्नर्स के बारे में आपका प्रस्ताव दिलचस्प है। सिद्धांत रूप में, अपनाने वाला wpf सामग्री पर WinUI/XAML सामग्री को रखने के लिए पॉपअप बना सकता है। या यह डब्ल्यूपीएफ विजुअल ट्री को सूचित कर सकता है कि एक पुन: लेआउट की आवश्यकता है, लेकिन सब कुछ एचडब्ल्यूएनडी पर आधारित है।
@dbeavon यह एक अच्छा प्रस्ताव है, क्या आप इसके लिए एक फीचर अनुरोध बना सकते हैं?

प्रश्न: _क्या Xaml द्वीप के साथ एक wpf ऐप ARM64 में संकलित होगा?_
ए: यदि विंडोज़ के लिए .NET कोर 3 निश्चित रूप से एआरएम 64 का समर्थन करता है। आज यह विंडोज़ में ARM32 को सपोर्ट करता है। हालाँकि, लिनक्स में ARM64 का समर्थन करता है। मुझे लगता है कि यह विंडोज़ में भी एआरएम 64 का समर्थन करने के लिए .NET कोर रोडमैप पर है। हालांकि AFAIN, अभी कोई तारीख नहीं है। @richlander , कोई खबर?

@marb2000

प्रश्न: क्या डब्ल्यूपीएफ और यूडब्ल्यूपी एक ही हवाई क्षेत्र साझा करेंगे?

क्या UWP एक परत बनाने के लिए Windows.UI.Composition का उपयोग कर सकता है जो DirectX बिटमैप से रेंडर प्राप्त कर सकता है? और फिर डब्ल्यूपीएफ विंडोज़ को इस परत में win2d की तरह प्रस्तुत करता है। हो सकता है कि यह उसी हवाई क्षेत्र को साझा कर सके। लेकिन डब्ल्यूपीएफ को एक परत में प्रस्तुत करना मुश्किल है।

@lindexi मुझे लगता है कि स्वर्ग हो सकता है: डी

क्या UWP एक परत बनाने के लिए Windows.UI.Composition का उपयोग कर सकता है जो DirectX बिटमैप से रेंडर प्राप्त कर सकता है?

UWP Xaml के पास Xaml में DirectX बिटमैप्स या स्वैप चेन को रेंडर करने और उन्हें Windows.UI.Composition के साथ संयोजित करने के कई तरीके हैं, ताकि वे SurfaceImageSource , VirtualSurfaceImageSource और SwapChainPanel सहित समान एयरस्पेस साझा कर सकें।

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

आप UWP Xaml UI ट्री में Windows.UI.Composition विज़ुअल भी सम्मिलित कर सकते हैं और इसमें DirectX सामग्री बना सकते हैं, उदाहरण के लिए ICompositorInterop , ICompositionDrawingSurfaceInterop और ICompositionGraphicsDeviceInterop जैसा कि यहां बताया गया है:

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

उन दृष्टिकोणों को WinUI के साथ समान रूप से काम करना चाहिए।

एक यूडब्ल्यूपी डेस्कटॉप ऐप एक डब्ल्यूपीएफ/विनफॉर्म डीएलएल को संदर्भित करने और एक डब्ल्यूपीएफ/विनफ्रॉम विंडो खोलने में सक्षम होगा? यह मुझे धीरे-धीरे माइग्रेट करने की अनुमति देगा।

@marb2000 -- .NET Core Windows ARM64 के लिए हमारे रोडमैप पर है। मैं अभी इसके लिए एक योजना पर काम कर रहा हूं।

WinUI 3.0 के साथ, क्या इसके ऊपर win2d को संकलित करना संभव होगा?
(इस प्रकार, इसे UWP से अलग करना)
अगर ऐसा है तो यह बहुत ही शानदार होगा!

हम अभी भी DirectX एकीकरण पर विवरण पर काम कर रहे हैं, लेकिन उम्मीद है कि UWP Xaml बेस क्लास के बजाय WinUI बेस क्लास का उपयोग करने के लिए Win2D को अपडेट करना संभव होगा।

उँगलियाँ पार :D

क्षमा करें यदि यह विषय से हटकर है: UWP पर बग रिपोर्ट - क्या मैं https://github.com/microsoft/microsoft-ui-xaml/ या अन्य जगहों पर कोई समस्या जोड़ता हूं?

क्षमा करें यदि यह विषय से हटकर है: UWP पर बग रिपोर्ट - क्या मैं https://github.com/microsoft/microsoft-ui-xaml/ या अन्य जगहों पर कोई समस्या जोड़ता हूं?

@jtorjo महान सवाल! यह रेपो संबंधित किसी भी मुद्दे को दर्ज करने के लिए सबसे अच्छा स्थान है:

• UWP UI फ्रेमवर्क API (उदा. Windows.UI.Xaml)
• धाराप्रवाह डिजाइन
• विनयूआई

सामान्य तौर पर docs.microsoft.com पर अधिकांश दस्तावेज़ीकरण पृष्ठों के नीचे "इस उत्पाद के बारे में फ़ीडबैक भेजें" लिंक होना चाहिए जो आपको किसी विशिष्ट सुविधा या API पर फ़ीडबैक प्रदान करने का सबसे अच्छा तरीका बताएगा।

उपरोक्त के अलावा UWP के अधिकांश पहलुओं के लिए, फीडबैक हब में डेवलपर प्लेटफ़ॉर्म श्रेणी के अंतर्गत बग फ़ाइल करना होगा, जिसमें कई प्रासंगिक उपश्रेणियाँ हैं।

क्या WinUI 3 में UWP SemanticZoom नियंत्रण शामिल होगा? मुझे लगता है कि यह उन सभी का सबसे अच्छा नियंत्रण है।

@jesbis धन्यवाद! System.IO के बारे में अभी एक चर्चा पोस्ट की है

Microsoft भी Office के लिए Windows 7 का समर्थन नहीं छोड़ता, WinUI 3 ऐसा क्यों करेगा? मेरा मतलब है, लगभग सभी गंभीर सॉफ्टवेयर्स में विंडोज 7 सपोर्ट होता है (फ़ोटोशॉप, ऑफिस, विजुअल स्टूडियो 2019, वीएससीओडी, ...) अगर विनयूआई विंडोज 7 का समर्थन नहीं करता है ...

Microsoft भी Office के लिए Windows 7 का समर्थन नहीं छोड़ता, WinUI 3 ऐसा क्यों करेगा? मेरा मतलब है, लगभग सभी गंभीर सॉफ्टवेयर्स में विंडोज 7 सपोर्ट होता है (फ़ोटोशॉप, ऑफिस, विजुअल स्टूडियो 2019, वीएससीओडी, ...) अगर विनयूआई विंडोज 7 का समर्थन नहीं करता है ...

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

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

प्रश्न: क्या WinUI 3 UWP और डेस्कटॉप समान .NET रनटाइम का उपयोग करेंगे?
ए: हाँ, यह योजना है। UWP और डेस्कटॉप .NET Core 3 का उपयोग करेंगे। प्रबंधित WinRT पुस्तकालय .NET मूल के बजाय .NET Core 3 का उपयोग करेंगे।
प्रश्न: क्या डब्ल्यूपीएफ और यूडब्ल्यूपी एक ही हवाई क्षेत्र साझा करेंगे?
ए: हालांकि डब्ल्यूपीएफ और विनयूआई (और एक्सएएमएल यूडब्ल्यूपी) समान लगते हैं, वे नहीं हैं। WPF DirectX9 का उपयोग करता है, और WinUI/XAML UWP Windows.UI.Composition का उपयोग XAML की संरचना, रेंडरिंग और एनिमेशन आवश्यकताओं (DirectX11 के आधुनिक संस्करण के अलावा) के लिए करता है। अफसोस की बात है कि इसका कारण इंटरऑप बहुत जटिल है। डब्ल्यूपीएफ एडोर्नर्स के बारे में आपका प्रस्ताव दिलचस्प है। सिद्धांत रूप में, अपनाने वाला wpf सामग्री पर WinUI/XAML सामग्री को रखने के लिए पॉपअप बना सकता है। या यह डब्ल्यूपीएफ विजुअल ट्री को सूचित कर सकता है कि एक पुन: लेआउट की आवश्यकता है, लेकिन सब कुछ एचडब्ल्यूएनडी पर आधारित है।
@dbeavon यह एक अच्छा प्रस्ताव है, क्या आप इसके लिए एक फीचर अनुरोध बना सकते हैं?
प्रश्न: क्या एक्सएमएल द्वीप समूह के साथ एक डब्ल्यूपीएफ ऐप एआरएम 64 में संकलित होगा?
ए: यदि विंडोज़ के लिए .NET कोर 3 निश्चित रूप से एआरएम 64 का समर्थन करता है। आज यह विंडोज़ में ARM32 को सपोर्ट करता है। हालाँकि, लिनक्स में ARM64 का समर्थन करता है। मुझे लगता है कि यह विंडोज़ में भी एआरएम 64 का समर्थन करने के लिए .NET कोर रोडमैप पर है। हालांकि AFAIN, अभी कोई तारीख नहीं है। @richlander , कोई खबर?

तो क्या हम UWP सैंडबॉक्स से छुटकारा पा रहे हैं? जो बदले में यूडब्ल्यूपी का वर्तमान स्वरूप में भी दूर जा रहा है, और इसके साथ ऐप स्टोर का संरक्षित सैंडबॉक्स जैसा कि हम जानते हैं?

तो क्या हम UWP सैंडबॉक्स से छुटकारा पा रहे हैं? जो बदले में यूडब्ल्यूपी का वर्तमान स्वरूप में भी दूर जा रहा है, और इसके साथ ऐप स्टोर का संरक्षित सैंडबॉक्स जैसा कि हम जानते हैं?

UWP सैंडबॉक्स से छुटकारा पाना बहुत ही बढ़िया होगा!

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

मुख्य परिवर्तन हैं:

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

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

तो क्या हम UWP सैंडबॉक्स से छुटकारा पा रहे हैं? जो बदले में यूडब्ल्यूपी का वर्तमान स्वरूप में भी दूर जा रहा है, और इसके साथ ऐप स्टोर का संरक्षित सैंडबॉक्स जैसा कि हम जानते हैं?

UWP WinUI 3.0 ऐप बनाने के विकल्पों में से एक होगा। UWP का उपयोग करने से आपका ऐप Xbox, Hololens, आदि पर चलने देगा।

लेकिन आप WinUI 3.0 के साथ एक Win32 ऐप भी बना सकते हैं और UWP API तक पहुंच सकते हैं - लेकिन जहां आपका ऐप चल सकता है वह अधिक सीमित होगा।

@mdtauk @jesbis मैं पूरी तरह से UWP के लिए हूं, लेकिन इस समय:

1. संकलन समय बहुत धीमा है! (बहुत ज्यादा, 6 गुना धीमी है कि डब्ल्यूपीएफ - मैं लक्ष्य संस्करण का निर्माण 180 9 का उपयोग कर रहा हूं - 17783 का निर्माण)
2. मुझे पता है कि स्टोरेजफोल्डर फ़ाइल एन्यूमरेशन एपीआई यूडब्ल्यूपी का हिस्सा नहीं है, लेकिन यह बेहद धीमा है। UWP सैंडबॉक्स (कम से कम विंडोज डेस्कटॉप पर) मदद करने से ज्यादा नुकसान पहुंचा रहा है।
3. निश्चित रूप से, एसिंक प्रोग्रामिंग मजेदार है, लेकिन यूडब्ल्यूपी में, जब कोई अपवाद होता है, तो इसे किसी भी तरह यूडब्ल्यूपी कोड द्वारा खाया जाता है, और फिर बाद में डीबगर में तोड़ दिया जाता है, जिसमें सभी स्टैक संदर्भ खो जाते हैं। कभी-कभी, मेरे पास फेंके गए अपवाद के अंदर ही स्टैक संदर्भ होता है, लेकिन हमेशा नहीं।
4. UWP कोड की रूपरेखा बनाना लगभग असंभव है। इवेंट डॉटट्रेस इसे करने का प्रयास करते समय तुरंत टूट जाता है।

(मुझे अपना कोड wpf से UWP में पोर्ट करने में एक महीने से अधिक का समय लगा, क्योंकि मुझे win2d की अत्यधिक आवश्यकता है, इसलिए मेरे लिए UWP से बचने का कोई तरीका नहीं है।)

@mdtauk @jesbis मैं पूरी तरह से UWP के लिए हूं, लेकिन इस समय:

1. संकलन समय बहुत धीमा है! (बहुत ज्यादा, 6 गुना धीमी है कि डब्ल्यूपीएफ - मैं लक्ष्य संस्करण का निर्माण 180 9 का उपयोग कर रहा हूं - 17783 का निर्माण)
2. मुझे पता है कि स्टोरेजफोल्डर फ़ाइल एन्यूमरेशन एपीआई यूडब्ल्यूपी का हिस्सा नहीं है, लेकिन यह बेहद धीमा है। UWP सैंडबॉक्स (कम से कम विंडोज डेस्कटॉप पर) मदद करने से ज्यादा नुकसान पहुंचा रहा है।
3. निश्चित रूप से, एसिंक प्रोग्रामिंग मजेदार है, लेकिन यूडब्ल्यूपी में, जब कोई अपवाद होता है, तो इसे किसी भी तरह यूडब्ल्यूपी कोड द्वारा खाया जाता है, और फिर बाद में डीबगर में तोड़ दिया जाता है, जिसमें सभी स्टैक संदर्भ खो जाते हैं। कभी-कभी, मेरे पास फेंके गए अपवाद के अंदर ही स्टैक संदर्भ होता है, लेकिन हमेशा नहीं।
4. UWP कोड की रूपरेखा बनाना लगभग असंभव है। इवेंट डॉटट्रेस इसे करने का प्रयास करते समय तुरंत टूट जाता है।

(मुझे अपना कोड wpf से UWP में पोर्ट करने में एक महीने से अधिक का समय लगा, क्योंकि मुझे win2d की अत्यधिक आवश्यकता है, इसलिए मेरे लिए UWP से बचने का कोई तरीका नहीं है।)

इसके लिए इस थ्रेड #1517 में पोस्ट करना उपयोगी होगा और उम्मीद है कि आप एसडीके टीम के किसी व्यक्ति के नाम में शामिल कर सकते हैं

@jtorjo

संकलन समय बहुत धीमा है! (बहुत ज्यादा, 6 गुना धीमी है कि डब्ल्यूपीएफ

क्या आप सी ++/विनआरटी का उपयोग कर रहे हैं? यदि हां, तो क्या आप पूर्व-संकलित शीर्षलेखों का उपयोग कर रहे हैं?

@mdtauk ने अभी वहीं पोस्ट किया है

@MarkIngramUK यह सी # कोड है

समापन - कृपया रोडमैप और अल्फा फीडबैक को इस पर निर्देशित करें: #1531

अभी यह संभव नहीं है कि क्या यह संभव है - आशा यह है कि जब OS से WinUI बिट्स को हटा दिया जाता है, तो उन्हें एक तरह से ओपन सोर्स प्रोजेक्ट में डाल दिया जाता है, जो अन्य प्लेटफार्मों को किसी प्रकार का संगतता घटक प्रदान करने में सक्षम बनाता है। एक कस्टम रेंडरर के साथ Xamarin, Uno, या .Net Core सोचें।

क्या यह वास्तव में रोडमैप पर कुछ है या सिर्फ एक धारणा थी?

@mdtauk , @ zezba9000 यह सब सैद्धांतिक रूप से संभव है, और हमारे पास टीम पर बहुत सारी प्लेटफ़ॉर्म एब्स्ट्रैक्शन विशेषज्ञता है। किसी भी चीज़ की तरह, यह केवल लागत, समय-सारणी और अपेक्षित लाभ पर निर्भर करता है

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

@andreinitescu शेख़ी और शिकायतों के लिए क्षमा करें, लेकिन जो मैं समझता हूं उससे केवल मेरे विचार: जबकि मैं विंडोज़/Win32 केवल सामान के लिए wpf को प्रतिस्थापित करने के लिए WinUI 3 का उपयोग करूंगा ... क्योंकि विंडोज़ पर WinUI विंडोज़ केवल प्रतिपादन एपीआई का उपयोग करता है, न कि अज्ञेयवादी एक, ऐसा लगता है कि विनयूआई अन्य प्लेटफार्मों पर विनयूआई को फिर से लागू करने/फ्रैगमेंट (यूजीजी) करने के लिए तीसरे पक्ष पर भरोसा कर रहा है (जैसे यूएनओ प्रोज, जो अच्छा है लेकिन मोनो से .NET की तरह यह एक अनावश्यक और समय बर्बाद करने वाला विखंडन है यदि चीजें केवल थीं शुरू करने के लिए सही बनाया गया है)। स्कीया जैसे पोर्टेबल का उपयोग करने या एमएस बनाने के बजाय। उन 1% लोगों का समर्थन करने की आवश्यकता को भी नहीं समझते हैं जो WinUI के साथ C# का उपयोग नहीं कर रहे हैं, C# को एक अर्थ में द्वितीय श्रेणी का लक्ष्य बनाते हैं और अधिक महत्वपूर्ण रूप से देव समय को बहुत अधिक समय लेते हैं। जैसे एंड्रॉइड कई कोर ऐप्स के लिए जावा + पोस्ट-एओटी का उपयोग करता है, वैसे ही विंडोज़ को सी # + प्री-एओटी का उपयोग करना चाहिए। क्योंकि इससे समय की बचत होती है। C++ का उपयोग करने वाले 70% बग्स डिलोकेटेड ptrs का उपयोग कर रहे हैं।

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

खराब करने के लिए MS वह नहीं कर सकता/नहीं कर सकता जो Apple ने लगभग 20 साल पहले OS9 से OSX की ओर बढ़ने के साथ किया था। इसमें आप UNIX/LINUX कर्नेल में जाकर बैंड-सहायता को चीर देते हैं, लेकिन अगले 5-10 वर्षों के लिए विरासत सॉफ़्टवेयर के लिए OS में निर्मित एक एमुलेटर/सिम्युलेटर है, जबकि लोग मूल रूप से चलाने के लिए सॉफ़्टवेयर और देव टूल को माइग्रेट करते हैं। (सोचें कि आप इसका क्या करेंगे लेकिन मैं सपना देख सकता हूं)