Maui: .NET 5 के लिए क्रॉस प्लेटफॉर्म UX

मुझे यह विचार पसंद है। हालांकि, व्यावहारिक रूप से, यह कुछ ऐसा है जिसे Xamarin.Forms टीम द्वारा नियंत्रित किए जाने की अधिक संभावना है।
हो सकता है, कोर टीम UX ढांचे को "बेहतर" बनाने के लिए कुछ निम्न-स्तरीय निर्माणों में योगदान करे (जैसे CoreFxLab क्या करता है)।

संपादित करें: क्या WebAssembly भी एक समर्थित मंच बन सकता है?

मुझे यह विचार पसंद आया। मैंने लोगों (स्वयं सहित) को कई वातावरणों के लिए कई UI तकनीकों से पीड़ित देखा है।

मुझे पूरा यकीन है कि भविष्य में हम देख सकते हैं कि corehost के प्रतिस्थापन के रूप में हम मूल एप्लिकेशन का उपयोग करके एंड्रॉइड और आईओएस डिवाइस पर .net कोर पोर्ट किए गए हैं। कहा जा रहा है कि, UI क्षमताओं की आवश्यकता होगी।

2D xplat ड्रॉइंग लाइब्रेरी (त्वरित आरेखण सहित) के लिए, हमारे पास उदाहरण के लिए स्कीया है।

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

हालांकि, मुझे संदेह है कि नेट टीम की ओर से कुछ एक्सप्लेट System.Drawing.X प्राइमेटिव वापस लाने के अलावा उस पर समय निवेश करने की कोई योजना है ...

@4creators शायद यह चर्चा आपके लिए रुचिकर है

@ vibeeshan025 WebAssembly जावास्क्रिप्ट का प्रतिस्थापन नहीं है, इसलिए आपकी अधिकांश टिप्पणी का वास्तव में कोई मतलब नहीं है। WebAssembly को DOM से जोड़ने के लिए आपको अभी भी जावास्क्रिप्ट की आवश्यकता होगी। तो, नहीं, आप बस कुछ को wasm में संकलित नहीं कर सकते हैं और उम्मीद करते हैं कि यह जावास्क्रिप्ट के साथ जो कुछ भी आपने पहले किया था उसे प्रतिस्थापित कर देगा। ऐसा नहीं है कि यह कैसे काम करता है। यह UI तकनीक नहीं होगी।

हे दोस्तों, बस अपना 5c यहाँ रखना चाहता हूँ।
System.Drawing.X .NET कोर विकास के लिए आवश्यक है। (बस यहां https://github.com/dotnet/corefx/issues/20325 से आया हूं)

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

FWIW, मोनो WebAssembly को अपना रहा है , इसलिए यदि यह मोनो में काम करता है, तो यह WebAssembly में काम करता है (या काम करेगा)। यही वर्तमान विचार/समझ है, कम से कम।

साथ ही, मुझे इस कार्य को पूरा करने वाले .NET/MSFT की संभावना पर भावना को प्रतिध्वनित करना होगा। उनका सारा फोकस/आईक्यू कोर/इंटर्नल/फ्रेमवर्क/जस्ट-गेट-इट-वर्किंग में रखा गया है और मुझे लगता है कि यह एक या दो साल के लिए इसी तरह रहेगा। लेकिन कौन जानता है, मुझे (सुखद) आश्चर्य हो सकता है।

इस पर मेरा विचार यह है कि कुछ बाहरी प्रयास गति प्राप्त करने जा रहे हैं और शायद MSFT, ala Xamarin द्वारा खरीदे जा सकते हैं, लेकिन अधिक UI-केंद्रित (ढांचे/टूलिंग-केंद्रित के विपरीत, जो कि Xamarin की मुख्य ताकत IMO है)। तो, एवलोनिया या नोएसिस जैसा कुछ, जो क्रमशः ओपन सोर्स और पेड चैनलों के माध्यम से अपने मूल्य प्रस्ताव की पेशकश करते हैं। संयोग से, ये दोनों मोनो बिल्ट-ऑन/सपोर्ट हैं।

Xamarin.Forms के लिए XAML मानक (पूर्वावलोकन) जारी करने और परियोजना की प्रगति पर लंबे समय से अतिदेय अद्यतन के साथ Xaml मानक थोड़ा आगे बढ़ गया है। पीआर डॉटनेट/डिजाइन#111 में परियोजना लक्ष्यों के बारे में एक बहुत ही रोचक चर्चा है जो इस प्रस्ताव को लाभान्वित करने की दिशा में जा रही है।

सिल्वरलाइट एक अच्छा समाधान है जो कोड पहले से मौजूद है

1. ओपन सोर्स सिल्वरलाइट कोड
2. इसे डॉटनेट कोर रनटाइम के शीर्ष पर चलाएं
3. लिनक्स वितरण के लिए चांदनी का प्रयोग करें
4. "इलेक्ट्रॉन" के लिए डॉटनेट कोर विकल्प बनाएं, यह दुनिया को खाएगा (कम मेमोरी उपयोग + विशाल पूर्ण सुधार + xaml अच्छाई)
5. मूल अनुपालन (यदि एक दिन कोरर्ट परियोजना प्रकाश देखें)

इसे प्रासंगिक पाया- http://platform.uno

@गुलशन दिलचस्प, महान परियोजना, क्या यह अधिकांश यूडब्ल्यूपी सुविधा का समर्थन कर रहा है, कैसे वे केवल 4 योगदानकर्ताओं के साथ बहुत कम समय में इतने समृद्ध करतबों को लागू करने में सक्षम थे।

@ vibeeshan025 उनके पास आईआईआरसी को फंड करने वाली एक कंपनी है ...

एक और भविष्य तलाशने लायक है- HTML/CSS + .net (JS/TS के बजाय)। यहां पहले से ही कोशिश की जा रही है-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

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

उपयोग करने के लिए संभावित जीयूआई libs:

• TclBridge (मुक्त या खुला स्रोत नहीं लगता)
• मोनो वन (शायद सबसे अच्छा शायद)
• ईगल (सुनिश्चित नहीं है कि यह कितना अच्छा है)
• शायद अन्य भी।

मुझे cpython के tkinner मॉड्यूल से tcl/tk का उपयोग करने का विचार मिला।

यह भी सुनिश्चित नहीं है कि .NET कोर *.resources (संकलित resx) से या यहां तक ​​कि *.resx से अभी तक संसाधनों को लोड करने का समर्थन करता है। अगर ऐसा होता है तो बहुत अच्छा होगा।

Microsoft.DesktopUI.App वर्तमान में v3.0.0-alpha-26921-3 विंडोज .NET कोर एसडीके के दैनिक बिल्ड के साथ उपलब्ध है। मैं उत्सुक हूं कि जीडीसी और डायरेक्टएक्स के लिए कुछ अनुवाद परतों के तहत इसे लिनक्स पर चलाने और चलाने के लिए क्या आवश्यक होगा।

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

यह वही है जो आवश्यक है, कुछ भी कम स्वीकार्य नहीं है:
एक सर्वव्यापी .NET क्लाइंट अनुप्रयोग विकास मॉडल बनाएँ

विजुअल बेसिक 6 को जारी हुए अब 20 साल हो गए हैं, और हम उस उत्पादकता के करीब कहीं नहीं हैं जो 1998 में हमारे पास थी।Microsoft को अपना दृष्टिकोण प्रस्तुत करने की आवश्यकता है कि "Microsoft दुनिया" में एक बड़ा कस्टम सिस्टम कैसे किया जाना चाहिए, और वे उस उत्पादकता को कैसे वापस लाएंगे जो हमारे पास 20 साल पहले थी।

Microsoft को अपनी गंदगी को एक साथ लाने और कदम बढ़ाने और अपनी जिम्मेदारी को स्वीकार करने की आवश्यकता है। Microsoft को यह महसूस करने की आवश्यकता है कि उनके सभी ग्राहक, भागीदार और डेवलपर्स जिन्होंने दशकों से MS तकनीक में भारी निवेश किया है, वे बहुत निराश हैं और MS में उनका विश्वास बहुत कम है। MS को अपने ग्राहकों, भागीदारों और डेवलपर्स का सम्मान करना शुरू करने और अपनी प्रतिष्ठा और सम्मान का पुनर्निर्माण करने की आवश्यकता है, लेकिन यह देखते हुए कि वे अब Skype के साथ क्या कर रहे हैं और वे अपने Skype ग्राहकों और उपयोगकर्ताओं के साथ कैसा व्यवहार करते हैं, मुझे बहुत कम उम्मीद है कि ऐसा होगा।

और Xamarin के बारे में भूल जाओ, Microsoft स्वयं भी इसका उपयोग नहीं करता है , और Xamarin का उपयोग करने के बजाय, ElectronJS फ्रेमवर्क (क्रोमियम, Node.js, जावास्क्रिप्ट और CSS पर आधारित) जैसे एकल थ्रेडेड मेमोरी-हॉगिंग फ्रेमवर्क के लिए जाता है, जो उनके पास है और पर पूर्ण नियंत्रण है, और जो प्रत्येक प्लेटफॉर्म के लिए वास्तविक मूल कोड उत्पन्न करेगा।

@ बार्टोलोमस-649

विजुअल बेसिक 6 को जारी हुए अब 20 साल हो चुके हैं, और हम उस उत्पादकता के करीब कहीं नहीं हैं जो 1998 में हमारे पास थी।

और कंप्यूटर और इंटरनेट के उपयोग के साथ-साथ प्लेटफार्मों की विविधता (ओएस / मोबिलिटी / फॉर्म फैक्टर) का प्रसार कहीं भी 1998 जितना कम नहीं है।

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

अन्य बिंदुओं पर आप जो कह रहे हैं, मुझे लगता है कि वे ज्यादातर व्यक्तिगत राय या अवलोकन हैं जो आपके विशिष्ट कार्य पर लागू होते हैं और आम तौर पर लागू बयान नहीं होते हैं।

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

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

@richlander @karelz @AdamYoblick @llongley @kmahone

मेरा प्रश्न यह है कि क्या हम-समुदाय मौजूदा रेपो के भीतर लिनक्स और मैकओएस पोर्ट पर काम कर सकते हैं यानी अलग-अलग शाखाओं में या क्या हमें ऐसी परियोजनाओं का समर्थन करने के लिए अलग रेपो बनाना चाहिए? यह बहुत महत्वपूर्ण निर्णय है क्योंकि मौजूदा रेपो का उपयोग करने से हम बंदरगाहों को एमएसएफटी सीआई बुनियादी ढांचे के साथ एकीकृत कर सकेंगे जो अन्यथा समुदाय द्वारा खरोंच से स्थापित करना होगा।

क्या कोई कारण है कि Xamarin.Forms/Avalonia/Platform.Uno आपकी आवश्यकताओं के अनुरूप नहीं है? ऐसा लगता है कि क्रॉस-प्लेटफ़ॉर्म एक्सएएमएल लाने का एक नया प्रयास पूरे समुदाय के लिए बहुत कम मूल्य लाता है।

4क्रिएटर्स नहीं, बल्कि मेरे 2¢/इंप्रेशन:

• Xamarin.Forms ज्यादातर मोबाइल परिदृश्यों पर ध्यान केंद्रित करते हैं।
• Platform.Uno . के लिए समान
• अवलोनिया अभी प्राइम टाइम के लिए तैयार नहीं है। मेरे लिए इस पर भरोसा करने के लिए बहुत छोटी गाड़ी है। (पिछली बार जब मैं इसकी जांच करने गया था, तो डेमो ऐप वर्तमान स्थिर रिलीज में भी नहीं बनेगा, आत्मविश्वास को बिल्कुल प्रेरित नहीं करता है।)

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

अच्छे तर्क। फिर भी, हमें एक और समाधान बनाने के बजाय मौजूदा समाधानों में सुधार करने पर ध्यान देना चाहिए, जिसकी लागत पहले की तुलना में बहुत अधिक है।

वैसे, कोई दर्द NoesisGUI के बारे में बताता है?

समुदाय Linux और macOS पोर्ट पर काम कर सकता है

@4creators ऐसे कांटे बनाएं जो आपके पास हों और जिन पर आपका पूरा नियंत्रण हो।

सीआई इंफ्रास्ट्रक्चर

.NET Core CI अवसंरचना वर्तमान कस्टम जेनकिंस-आधारित समाधान के बजाय एक नियमित Azure DevOps का उपयोग करने की ओर बढ़ रही है। Azure DevOps के पास ओपन सोर्स प्रोजेक्ट्स के लिए मुफ़्त ऑफ़र हैं जिनका आप लाभ उठा सकते हैं।

केवल डॉटनेट/विनफॉर्म के लिए बोलना:

Winforms पहले से ही AzureDevOps का उपयोग कर रहा है, और मास्टर में कोई भी PR PR CI बिल्ड को स्वचालित रूप से चलाएगा।

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

वैसे, कोई दर्द NoesisGUI के बारे में बताता है?

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

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

@4creators मुझे लगता है कि दो मुद्दों के भ्रम के कारण इस मुद्दे का शीर्षक गलत है।

सबसे पहले, .Net UI फ्रेमवर्क को अन्य .Net रनटाइम के बजाय .Net Core का उपयोग करने की अनुमति देना । डब्ल्यूपीएफ अब नेट कोर पर चल सकता है, और वे Xamarin.iOS/Android/Mac/GTK को .Net Core पर भी चला सकते हैं। इसमें मोनो या .Net फ्रेमवर्क का उपयोग करने की तुलना में प्रदर्शन और रखरखाव के लाभ हैं।

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

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

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

मुझे लगता है कि दो मुद्दों के भ्रम के कारण इस मुद्दे का शीर्षक गलत है।

@charlesroddie IMO, वास्तव में नहीं। मुद्दा यह नहीं है कि .NET कोर प्लेटफॉर्म पर कुछ UX फ्रेमवर्क उपलब्ध है, बल्कि UX जो कि DotNet पारिस्थितिकी तंत्र का एक हिस्सा है, जिसे अन्य भागों के साथ संयुक्त रूप से बनाया और बनाए रखा गया है। .NET पारिस्थितिकी तंत्र के लिए MSFT भविष्य की योजनाएँ .NET कोर आधारित हैं। वर्तमान में Xamarin.Forms को .NET कोर में पोर्ट करने की कोई योजना नहीं है, कुछ कारणों से @Happypig375 द्वारा ऊपर बताया गया है और दूसरा कारण मोबाइल पर xplat समर्थन के साथ आगे बढ़ने के निर्णय की कमी है। हालाँकि, मुझे लगता है कि .NET कोर में निवेश किए गए विकास प्रयासों के कारण MSFT द्वारा उपयोग किया जाने वाला भविष्य का xplat प्लेटफॉर्म .NET कोर आधारित होगा।

मोनो को लिनक्स पर भी कई वर्कलोड के लिए पर्याप्त रूप से अनुकूलित नहीं किया गया है और उस रनटाइम के शीर्ष पर अब कोई बड़ी नई सुविधाएँ विकसित नहीं हुई हैं। बीसीएल वर्तमान में मोनो और .NET कोर के बीच साझा किया गया है। यह भविष्य में मोनो पदावनति की उच्च संभावना की ओर इशारा करता है।

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

.Net Standard यह सुनिश्चित करता है कि UI विभिन्न रनटाइम बिना किसी समस्या के एक ही पारिस्थितिकी तंत्र का हिस्सा हो सकते हैं। हालांकि नेट कोर के अन्य रनटाइम पर फायदे हैं, जो अंततः मूल्यह्रास हो सकते हैं, क्रॉस-प्लेटफ़ॉर्म यूआई के लिए सही दृष्टिकोण खोजने के साथ रनटाइम को लिंक करना आवश्यक नहीं है। यह सिर्फ प्रश्न को जटिल करता है।

यह कहना बहुत दूर जा रहा है कि एक यूएक्स प्लेटफॉर्म एक विशेष रनटाइम पर "आधारित" है। @ हैप्पीपिग375 यह वर्तमान में ज़ामरीन की .नेट कोर पर स्विच करने की योजना में नहीं है (इसके बजाय मोनो को कोड साझा करके नेट कोर के समान बनने की योजना है)। लेकिन यह डब्ल्यूपीएफ को नेट कोर पर ले जाने से ज्यादा कठिन नहीं होना चाहिए।

(बीटीडब्लू, यह सच नहीं है कि मोनो में कोई नई सुविधाएं नहीं हैं क्योंकि इसे नेट स्टैंडर्ड 2.1 का समर्थन करने के लिए अद्यतन किया जा रहा है, और वेबसैम्प पर वर्तमान काम नेट कोर के बजाय मोनो में किया जा रहा है। लेकिन यह एक तरफ है क्योंकि इस काम को पोर्ट किया जा सकता है से .नेट कोर।)

विनयूआई 3.0 रोडमैप - हमें आपके इनपुट की जरूरत है!

ऐसा लगता है कि सभी आवश्यक घटकों के खुले स्रोत होने के बाद यह विकास प्रस्ताव नई xplat संभावनाओं को खोल सकता है।

अगर ऐसा है, तो उन्हें इसे MicrosoftUI 1.0 कहने पर विचार करना चाहिए, @4creators। मैं

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

मेरा मानना ​​है कि इस रेपो द्वारा इस मुद्दे को संबोधित किया गया है।