फैब्रिक द्वारा उपयोग किए जाने वाले बटन आदि पर गोलाकार कोनों की तुलना में यह एक व्यापक परियोजना होनी चाहिए।

• बटन
• स्पिनर्स/प्रोग्रेस रिंग
• अनिश्चित प्रगतिबार
• चेकबॉक्स और रेडियो बटन
• ComboBoxes और TextFields
  और इसी तरह।

Xbox की अलग-अलग आवश्यकताएं बनी रहेंगी, लेकिन रास्ते में Xbox कंसोल के एक नए सेट के साथ, शायद Microsoft डिज़ाइन टीमें WinUI 3.0 और Xbox Next के लिए समय पर सब कुछ संरेखित करने के लिए एक साथ काम कर सकती हैं।

ऐसा लगता है कि फैब्रिक पर इस समय बहुत अधिक ध्यान दिया जा रहा है, इसके क्रॉस प्लेटफॉर्म और PWA के उपयोग के मामले क्या हैं। तो शायद फैब्रिक ब्लूप्रिंट बन जाता है - कम से कम कॉम्पैक्ट डेंसिटी के लिए, और न्यूनतम माप के रूप में 2px से 4px तक ले जाएं - और फिर आप टच अफोर्डेंस को एक्सट्रपलेशन करें और लापता कंट्रोल स्टेट्स को भरें।

थीमशैडो को गोलाकार कोनों के लिए खाते की आवश्यकता होगी। और ऐक्रेलिक सतहों में संभवतः आंतरिक और बाहरी सीमाएं शामिल होनी चाहिए ताकि यह सुनिश्चित किया जा सके कि वे पृष्ठभूमि से ऊपर की ओर दिखाई दें।

@mdtauk आवश्यकता संख्या 4 राज्यों के अनुसार, Xbox के साथ इस परिवर्तन को युक्तिसंगत बनाने की योजना है। उस ने कहा, यह विशिष्ट विशेषता केवल कार्य को स्पष्ट रूप से दायरे में रखने के लिए गोल कोने तक सीमित है। कृपया अपने पास मौजूद अन्य डिज़ाइन सुझावों के लिए अलग-अलग अनुरोध खोलने के लिए स्वतंत्र महसूस करें।

बीटीडब्ल्यू, मैं ऐक्रेलिक सतहों के लिए आंतरिक और बाहरी सीमाओं पर आपकी प्रतिक्रिया को समझ नहीं पा रहा हूं? क्या यह Xbox डिज़ाइन है जिसका आप उल्लेख कर रहे हैं क्योंकि वर्तमान में हम आपके द्वारा निर्दिष्ट दो सीमाओं का उपयोग नहीं करते हैं।

@chigy निश्चित रूप से Xbox के साथ, यह अपनी बात है। लेकिन बात यह है कि गोल कोनों को सभी प्रासंगिक नियंत्रणों पर काम करने की आवश्यकता है।

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

Fluent Web अपने गोल कोनों के लिए 2px कोने वाले त्रिज्या का उपयोग करता है, लेकिन Fluent XAML ने आधार माप के रूप में 4px का उपयोग करने की प्रवृत्ति रखी है। फिर कॉम्पैक्ट डेंसिटी टेम्पलेट्स हैं जो शायद उसी मेट्रिक्स का उपयोग फ्लुएंटवेब के रूप में करेंगे?

मैंने Xbox फ़्लुएंट और फ़ैब्रिक साझा नियंत्रणों की एक तुलना छवि बनाई, और वे कितने अलग दिखते हैं। तो इन नियंत्रण टेम्पलेट्स को देखे जाने के दौरान गोलाकार कोनों से कहीं अधिक किया जाना चाहिए।

Xbox सामान पर ध्यान न दें

@mdtauk , आपको यह आभास दिलाने के लिए कि यह केवल बटन के बारे में है, मुझे स्पष्ट रूप से निर्दिष्ट नहीं करना चाहिए ... निश्चिंत रहें, ऐसा नहीं है। आवश्यकताएं संख्या 1 और उनके उप आइटम देखें। यह सभी नियंत्रणों के बारे में है।

मुझे डिज़ाइन फ़ाइल प्रकाशित करने का मौका नहीं मिला है, लेकिन हम जिस कोने की त्रिज्या की योजना बना रहे हैं वह वास्तव में 2px (ओवरले UI के लिए 4px) है। मैं वास्तव में फैब्रिक टीम (यानी फ्लुएंट वेब) के साथ मिलकर काम करता हूं और हम इन परिवर्तनों का एक साथ मूल्यांकन कर रहे हैं। उस ने कहा, उन्हें बिल्कुल एक जैसा बनाना हमारा लक्ष्य नहीं है, लेकिन जब उपयोगकर्ता उन्हें साथ-साथ देखते हैं तो हमें सुसंगत होने और परिवार का हिस्सा महसूस करने की आवश्यकता होती है। आवश्यकता संख्या 4 देखें।

तो इन नियंत्रण टेम्पलेट्स को देखे जाने के दौरान गोलाकार कोनों से कहीं अधिक किया जाना चाहिए।

यह काम में है लेकिन हम इसे एक-एक करके/मामले के आधार पर कर रहे हैं। हम ऐसे बदलाव करने में सावधानी बरतते हैं जो बदलाव के लिए चीजों को नहीं बदलने के लिए समझ में आता है।

@chigy धन्यवाद, धन्यवाद, धन्यवाद!

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

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

@chigy @mdtauk मेरी प्रतिक्रिया यहां देखें। केवल UI अवधारणाओं को देखना "यह जानने के लिए कि फ़्लुएंट डिज़ाइन कहाँ जा रहा है" या मेरी राय में विसंगतियों को इंगित करने के लिए पर्याप्त नहीं है। मैं ऊपर दिए गए लिंक किए गए मुद्दे में इस बिंदु पर आगे विस्तार करता हूं, लेकिन लंबी कहानी छोटी मैं चाहता हूं कि डिज़ाइन प्रस्तावों की बात आने पर भी उपयोगकर्ताओं और फ़्लुएंट डिज़ाइन (FD) टीम के बीच एक सक्रिय आगे-पीछे हो।

@mdtauk मैं देख रहा हूं कि आप FD से मिलान करने के लिए wpf/WinForms नियंत्रणों को अपडेट करने का मुद्दा उठाते हैं। मैं इसका विरोध कर रहा हूं क्योंकि आपके पास WinUI होगा यदि आप Win10 देशी लुक और फील के साथ एक गैर-UWP ऐप शिप करना चाहते हैं और MS की टीम के पास केवल सीमित संसाधन हैं जो UWP/WinUI को निश्चित बनाने पर सबसे अच्छा खर्च किया जाता है। विंडोज प्रेजेंटेशन प्लेटफॉर्म।
तो, @YuliKl @chigy @pag3 : क्या आप इस पर टिप्पणी कर सकते हैं? क्या डिफ़ॉल्ट WinForms/WPF नियंत्रणों को एक नया FD रूप देने के लिए अपडेट किया जाएगा या WinUI नियंत्रण नवीनतम और सबसे बड़ी डिज़ाइन सुविधाओं के लिए जाने का तरीका होगा जैसा कि मैं इसे समझता हूँ?

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

द बॉर्डर थिकनेस , फोकस रिवील ऑन फोकस्ड स्टेट, बॉर्डर ऑन डिसेबल्ड स्टेट।

"स्पिन बटन" शैली खोज बटन, पासवर्ड प्रकट बटन, स्पष्ट पाठ बटन पर लागू हो सकती है।

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

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

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

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

@mdtauk , क्रमशः, क्या आप कृपया इस मुद्दे पर बातचीत को गोल कोने तक सीमित कर सकते हैं? मैं वास्तव में विशेष रूप से गोल कोने पर प्रतिक्रिया प्राप्त करना चाहता हूं और मुझे डर है कि यह बातचीत उन लोगों के लिए बहुत भ्रमित हो रही है जो शायद उस उद्देश्य के लिए यहां आए हैं।

उस ने कहा, आप जो दिखा रहे हैं वह मुझे एक प्रकट फोकस व्यवहार जैसा दिखता है। हमने फोकस स्थिति को मजबूत बनाने पर ध्यान दिया और कुछ उपयोगकर्ता शोध किए और हमने पुष्टि की कि वे वैसे ही बहुत मजबूत हैं जैसे @ फ़ेलिक्स-देव ने अपनी प्रतिक्रिया में उल्लेख किया है।
https://docs.microsoft.com/en-us/windows/uwp/design/style/reveal-focus

@chigy अगर शोध से पता चलता है कि टेक्स्ट कंट्रोल फोकस पर फोकस फोकस बहुत ज्यादा है, तो मैं इसे स्वीकार करूंगा। मेरे उदाहरणों में गोल कोनों को शामिल किया गया है, यह सीमा में कुछ मामूली बदलावों के साथ हो, जो प्रस्ताव के "... वेब और ऐप शैली दिशा के अनुरूप" भाग के साथ फिट बैठता है।

@mdtauk और @ फ़ेलिक्स-देव, अब मैंने प्रस्तावित परिवर्तनों के विज़ुअल

@chigy टेक्स्ट नियंत्रण, कॉम्बो बॉक्स, चेक और रेडियो नियंत्रण की सीमा मोटाई पर पुनर्विचार करने की कोई संभावना है।

फैब्रिक वेब ने 1 एपेक्स मोटाई का विकल्प चुना और मुझे लगता है कि यह नियंत्रणों को और अधिक सुरुचिपूर्ण बनाता है, खासकर नए गोल कोनों के साथ। फिलहाल वे थोड़ा भारीपन महसूस कर रहे हैं।

कॉम्पैक्ट मोड में टेक्स्ट बॉक्स से बहुत फायदा होगा। लेकिन जब ध्यान केंद्रित किया जाता है तो सीमा मोटी हो सकती है

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

स्पिन बटन प्रस्ताव के साथ नंबरबॉक्स बटन और टेक्स्ट फ़ील्ड के इस संयोजन को दिखाता है

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

@Chigy द्वारा बनाई दृश्य comps देखने में सहायता के लिए मेरे द्वारा बनाए गए इस

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

@chigy द्वारा बनाए गए विज़ुअल

@mrlacey , बहुत बहुत धन्यवाद !!

@chigy टेक्स्ट नियंत्रण, कॉम्बो बॉक्स, चेक और रेडियो नियंत्रण की सीमा मोटाई पर पुनर्विचार करने की कोई संभावना है।

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

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

@ Zucce05 , हाँ #684

@चिगी
मैं गोल कोनों के डिज़ाइन परिवर्तन का भी प्रशंसक नहीं हूं, इसलिए मुझे यह सुनकर खुशी हुई कि आसानी से वापस स्विच करने का एक विकल्प है। मुझे नहीं लगता कि कोई सिस्टम-वाइड कॉर्नर रेडियस विकल्प होगा, क्या वहां होगा (सिस्टम-वाइड एक्सेंट कलर सेट करने के समान)?

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

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

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

@chigy मैंने अपने द्वारा बताए गए परिवर्तनों को स्पष्ट करने के लिए कुछ विज़ुअल मॉक अप किए हैं, और नियंत्रणों को फ़ैब्रिक वेब के नियंत्रणों के करीब लाता है - लेकिन फिर भी फ़्लुएंट कंट्रोल मेट्रिक्स का उपयोग कर रहा है।

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

उपरोक्त @mdtauk द्वारा कुछ डिज़ाइन प्रस्तावों को

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

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

मुझे यकीन नहीं है कि माइक्रोसॉफ्ट के नियंत्रण डिजाइनों को वेब से विंडोज़ में इतना अलग करने की आवश्यकता क्यों है। यह सिर्फ अलग-अलग टीमों की तरह लगता है, एक साथ बात नहीं कर रहा है। और डेवलपर्स के पास अभी भी ओवरराइड करने का विकल्प है। और ये नए डिफ़ॉल्ट तब तक प्रभावित नहीं होते जब तक कि ऐप को WinUI 3.0 में पुन: संकलित नहीं किया जाता है

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

@ फ़ेलिक्स-देव, इस विशेष मुद्दे के लिए, मुझे लगता है कि यह कुछ अजीब पैमाने के साथ फिग्मा निर्यात दृश्य का कुछ अजीब बग है। मैंने वास्तविक निर्माण और वास्तविक Figma फ़ाइल की दोबारा जाँच की, जिससे मैंने PNG निर्यात किया, वे ठीक दिखते हैं।

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

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

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

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

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

@चिगी

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

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

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

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

@ फ़ेलिक्स-देव फैब्रिक वेब नियंत्रण अन्य ढांचे और डिफ़ॉल्ट वेब नियंत्रणों से अद्वितीय हैं। पुराने लुक की तुलना में उन्हें हाल ही में फ़्लुएंट डिज़ाइन का उपयोग करने के लिए अपडेट किया गया था, जो कि विंडोज 10 एमडीएल 2 नियंत्रणों और विंडोज 8 / विनजेएस नियंत्रणों की तरह था।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नया डिफ़ॉल्ट CornerRadius मान ThemeResources हो सकता है, कुछ इस तरह
<Thickness x:Name="ControlCornerRadius" Value="2,2,2,2"/>
<Thickness x:Name="FlyoutCornerRadius" Value="4,4,4,4"/>

फिर एक देव इन्हें App.xaml में ओवरराइड कर सकता है - या CornerRadius="0" को उन नियंत्रणों पर लागू कर सकता है

इसके बाद, मैं यह भी सुझाव दूंगा कि BorderThickness का डिफ़ॉल्ट 2epx के बजाय 1epx पर सेट है - लेकिन सभी नियंत्रण ThemeResources का उपयोग करेंगे, कुछ इस तरह:
<Thickness x:Name="ControlBorderThickness" Value="1,1,1,1"
<Thickness x:Name="ControlFocusedBorderThickness" Value="2,2,2,2"
<Thickness x:Name="FlyoutInnerBorderThickness" Value="1,1,1,1"
<Thickness x:Name="FlyoutOuterBorderThickness" Value="1,1,1,1"

इसलिए इन्हें App.xaml में विश्व स्तर पर ओवरराइड किया जा सकता है, या केवल कुछ नियंत्रणों पर लागू शैली में।

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

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

@mdtauk , यह सही है और जैसा कि मैंने उल्लेख किया है, इसे # 684 के साथ प्रस्तावित परिवर्तन द्वारा ट्रैक किया गया है। @kikisaints को इस सूत्र में जोड़ना ताकि वह आपके द्वारा दी गई अच्छी प्रतिक्रिया को देख सके (लेकिन पूरी बात को उद्धृत नहीं करना क्योंकि यह बहुत बड़ा होगा। :)

@chigy जैसा कि मैं आखिरी प्रतिक्रिया पोस्ट कर रहा था, अन्य चीजें जोड़ दी गईं, इसलिए मुझे उद्धरण शामिल करना पड़ा :)

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

मैं इन परिवर्तनों को विकसित होते देखकर उत्साहित हूं, और यहां चल रही चर्चाओं में शामिल होकर मुझे खुशी हो रही है!

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

मैं निश्चित रूप से एक परिवर्तन के लिए पूरे नियंत्रण को फिर से टेम्पलेट करने के बजाय एक संपत्ति को सेट करने के रूप में अनुकूलन नियंत्रण को सरल बनाने के निर्णय की सराहना करता हूं।

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

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

मुझे विंडोज यूआई टीमों के बीच होने वाली चर्चाओं के बारे में और अधिक सुनना अच्छा लगेगा।

@mdtauk ,

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

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

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

@chigy जैसा कि आप GitHub में प्रत्येक नए नियंत्रण डिज़ाइन के लिए डिज़ाइन

@mdtauk

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

मैं इस बारे में बात नहीं कर रहा हूं कि बाहरी देव उस उपयोगकर्ता सेटिंग का सम्मान कैसे करेंगे - वे पहले से ही किसी भी तरह से नियंत्रणों को स्टाइल कर सकते हैं - लेकिन विंडोज घटकों के रूप के बारे में। इसका मतलब है कि सेटिंग्स ऐप, क्लिपबोर्ड, स्निप और स्केच, टास्क बार फ्लाईआउट्स में यूआई तत्व (जैसे नेटवर्क पैनल में बटन), आदि ...

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

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

एक आखिरी बात: विन 10 के 800 मिलियन उपयोगकर्ता और गिनती है। प्रस्तावित परिवर्तनों के बारे में मार्टिन के रूप में हर कोई इतना उत्साहित नहीं है और यह अच्छा होगा यदि विंडोज भी उन उपयोगकर्ताओं को समायोजित करने का प्रयास करेगा। जैसा कि आपने कहा, यूआई अत्यधिक व्यक्तिपरक है और यदि यूआई सिस्टम में लचीलापन जोड़ने की कोई संभावना है, तो एमएस को कम से कम उस पर विचार करना चाहिए।
इंटरनेट ब्राउज़रों के लिए, उदाहरण के लिए, थीमिंग का एक पूरा उद्योग है, जहां न केवल रंग बदले जाते हैं बल्कि टैब या खोज बार जैसे UI तत्वों का रूप भी बदला जाता है: https://github.com/muckSponge/MaterialFox (काफी मजेदार , वह विशेष प्रोजेक्ट फ़ायरफ़ॉक्स में गोलाकार कोनों को जोड़ता है - और मैं गोलाकार कोनों का प्रशंसक नहीं हूं।)
विंडोज सिस्टम के लिए, हालांकि, उपयोगकर्ता केवल एक थीम नहीं बना सकते हैं, इसलिए यह अच्छा होगा यदि एमएस यूआई अनुकूलन विकल्प प्रदान कर सके।

@mdtauk @chigy
कृपया इस रेडिट पोस्ट को देखें कि यह सिर्फ मैं ही नहीं हूं जो गोल कोनों का प्रशंसक नहीं है। हमारे पास ऐसे लोग हैं जो पूरे कदम को नापसंद करते हैं और कई लोगों को अपने विंडोज लुक के लिए उपयोगकर्ताओं को विकल्प देने के लिए भी कहते हैं ताकि वे वर्तमान रूप में वापस आ सकें।

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

विलाप के संदर्भ में: बस उन्हें वर्गाकार रखें या उपयोगकर्ता स्तर पर इसे वैकल्पिक बनाएं।

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

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

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

बहुत से लोग गोल कोनों के प्रस्ताव को भी बहुत नापसंद करते हैं और कई इसे एक कदम पीछे की ओर मानते हैं, यहां तक ​​कि आने वाले होलोलेंस यूआई के कई वीडियो में टिप्पणियों की जांच भी करते हैं, अधिकांश टिप्पणियां एक बार फिर सभी गोल कोनों को नापसंद करने के बारे में हैं और यहां तक ​​​​कि यहां तक ​​​​कि टिप्पणियों में कहा गया है कि "Microsoft UI विभाग में तौलिया में फेंक रहा है और Apple या Google की नकल कर रहा है", भले ही Microsoft ने पहली बार गोल कोनों का उपयोग नहीं किया है, लोग अब इसे एक नकारात्मक चीज़ के रूप में देखते हैं।

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

मैंने इस प्रस्ताव से लिंक करते हुए एक reddit पोस्ट बनाया है ताकि हम अधिक प्रतिक्रिया एकत्र कर सकें। अब तक की टिप्पणियों को देखते हुए, मैं कह सकता हूं कि बहुत से लोग गोल कोनों के साथ सूक्ष्म दृष्टिकोण की सराहना करते हैं।

लोग UI विसंगतियों को भी बुला रहे हैं - यहां तक ​​कि आधिकारिक विन 10 एमएस ऐप्स में भी, सेटिंग ऐप और सुरक्षा ऐप (नेविगेशन व्यू टाइटलबार में विस्तारित) देखें - और Win32 सिस्टम घटकों और नए यूडब्ल्यूपी तत्वों के बीच अंतर भी देखें। जैसा कि @SavoySchuler ने उल्लेख किया है, उम्मीद है कि इसे WinUI 3.0 के साथ संबोधित किया जाएगा। यह इस प्रस्ताव के बारे में एक विशिष्ट बिंदु नहीं है, बल्कि हम में से कई विंडोज उपयोगकर्ताओं के बीच एक "अत्यधिक" इच्छा है। कोनों के गोल होने या न होने के बारे में इतना नहीं बल्कि विंडोज सिस्टम में स्थिरता है।

संगति यहाँ कुंजी है, और मेरी मुख्य चिंता रही है।

WinUI 3.0 XAML नियंत्रणों में उन परिवर्तनों के बारे में है जो इनबॉक्स ऐप्स और Windows UI को प्रभावित करते हैं।

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

एक्सबॉक्स नेक्स्ट, विंडोज लाइट और विंडोज कोर ओएस नए शेल्स के साथ आएंगे, इसलिए यह टीमों के लिए भी एक विचार होना चाहिए - लीगेसी सपोर्ट के लिए विंडोज 10 के साथ

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

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

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

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

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

मेरा मानना ​​​​है कि एज की योजना अंततः ऐक्रेलिक को वापस लाने की है, और UI को विंडोज/फ्लुएंट डिज़ाइन शैली की ओर ले जाना है।

लेकिन विंडोज भी उम्मीद से विभाजन को पाटने के लिए थोड़ा आगे बढ़ रहा है।

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

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

निश्चित रूप से एक ऐप देव के रूप में, आपके पास अपने नियंत्रणों पर CornerRadius मान को 0 पर सेट करने का विकल्प है ताकि चुकता नियंत्रण वापस लाया जा सके।

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

क्या कोई कारण है कि MediaTransport Scrub Bar Thumb एक रूपरेखा के साथ गोल है, जबकि प्रस्तावित नया स्लाइडर Thumb एक भरे हुए घेरे के रूप में है?

मुझे लगता है कि सर्कल का अंगूठा अजीब लोजेंज/गोली के आकार की तुलना में बहुत अधिक मनभावन है जो किसी भी अन्य नियंत्रण में फिट नहीं होता है।

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

टेक्स्टबॉक्स और नंबरबॉक्स डिज़ाइन अवधारणाओं के साथ मैंने किया है - यहां कॉम्बोबॉक्स और संपादन योग्य कॉम्बोबॉक्स के लिए कुछ हैं

अच्छी नौकरी!
मेरे पास फ़्लायआउट मेनू के बारे में कुछ सुझाव हैं। मेनू को सीमांकित करने वाली छाया के साथ, क्या हमें वास्तव में सीमा की आवश्यकता है? और आईएमओ चयन हाइलाइट बिना अंतराल छोड़े फ्लाईआउट सतह की पूरी चौड़ाई को कवर कर सकता है।

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

अच्छी नौकरी!
मेरे पास फ़्लायआउट मेनू के बारे में कुछ सुझाव हैं। मेनू को सीमांकित करने वाली छाया के साथ, क्या हमें वास्तव में सीमा की आवश्यकता है? और आईएमओ चयन हाइलाइट बिना अंतराल छोड़े फ्लाईआउट सतह की पूरी चौड़ाई को कवर कर सकता है।

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

@mdtauk

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

इसलिए मैंने इसे देवों के लिए

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

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

उपयोगकर्ता के नजरिए से यहां रेडिट से अपनी प्रतिक्रिया छोड़ते हुए: “मुझे प्रस्ताव से साफ गोल कोने वाला लुक पसंद है। हालांकि (रेडिट पर) बाकी सभी लोगों की तरह, पूरे ओएस के आसपास निरंतरता को अभी भी बहुत प्यार की जरूरत है। ”

क्या कोई कारण है कि MediaTransport Scrub Bar Thumb एक रूपरेखा के साथ गोल है, जबकि प्रस्तावित नया स्लाइडर Thumb एक भरे हुए घेरे के रूप में है?

@mdtauk , वास्तव में, यह कुछ ऐसा है जिसे हम देख रहे हैं, लेकिन इसका मतलब यह नहीं है कि हम बदलाव करेंगे, इसलिए मैं अपेक्षाएं निर्धारित नहीं कर रहा हूं ...

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

@quantumfrost , हाँ, वास्तव में, हम करते हैं। छाया स्मार्ट है। इसलिए जब सिस्टम लो पावर मोड या किसी अन्य स्थिति में होता है जहां हम छाया को बंद कर देते हैं, तो सीमा खेल में आ जाएगी। हमने सीमा को इस तरह से डिजाइन किया है कि यह सूक्ष्म है। हमने कई अलग-अलग विकल्पों का मूल्यांकन किया लेकिन यह सबसे मजबूत था।

@nepxune , @mdtauk
आपकी प्रतिक्रिया के लिए आपका धन्यवाद।
मुझे आपके द्वारा ऊपर दिए गए कुछ बिंदुओं का उत्तर देने दें।

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

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

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

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

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

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

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

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

हमारे रेपो में आपका स्वागत है, @zag2me! हम आपको यहां चर्चाओं में शामिल होने के लिए उत्साहित हैं। मैं सहमत हूं और आपके लिए महत्वपूर्ण मुद्दों पर ध्यान आकर्षित करने के लिए यह सही जगह है! आप हमारा फ़ीचर अनुरोध फ़ॉर्म यहाँ पा सकते हैं: https://github.com/microsoft/microsoft-ui-xaml/issues/new/choose

@चिगी

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

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

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

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

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

जो हमें प्रस्ताव की ओर ले जाता है, हम में से कुछ तैर रहे हैं: विंडोज़ में अधिक यूआई अनुकूलन विकल्प जोड़ना।

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

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

@चिगी
अधिकांश लोग इस बात से सहमत होंगे कि 2px एक अच्छा दायरा होगा। बाकी को इसे बंद करने का विकल्प देना एक अच्छा आदर्श होगा।

अधिकांश उपयोगकर्ता चाहते हैं कि विंडोज यूआई के अत्याधुनिक हो और अन्य पुराने उपयोगकर्ता बदलना नहीं चाहते।

कुछ के लिए परिवर्तन का त्याग न करें, बस उन्हें इसे बंद करने का विकल्प दें।

@शहीदमालिक
यहां कोई "विरासत" उपयोगकर्ता नहीं हैं और मैं यह भी नहीं देखता कि आप " अधिकांश उपयोगकर्ता चाहते हैं [गोल कोनों]" पर कैसे पहुंचते हैं या वर्तमान विंडोज लुक "अत्याधुनिक" नहीं है।

यूआई अत्यधिक व्यक्तिपरक है, लेकिन इसका मतलब यह नहीं है कि हम अलग-अलग विचारों को "विरासत", "बदलने के लिए तैयार नहीं", आदि के रूप में देख सकते हैं ...

आइए अन्य उपयोगकर्ताओं की राय को "अतीत से जागना नहीं चाहते" की राय के रूप में केवल त्यागने का प्रयास न करें और वर्तमान चर्चा को भावुक लेकिन सम्मानजनक भी रखें क्योंकि यह अब तक रहा है।

@ फ़ेलिक्स-देव लीगेसी उपयोगकर्ता वे हैं जो विंडोज 7 पर बने रहेंगे, मौका दिया जाएगा, जो विंडोज 8 में किए गए परिवर्तनों के प्रतिरोधी थे, जो ओएस यूआई परिवर्तनों के प्रतिरोधी हैं, आगे बढ़ रहे हैं।

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

इस विशेष मामले में, बहुसंख्यक गोलाकार कोनों को लिंक के रूप में चाहते हैं (https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/)

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

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

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

@ फ़ेलिक्स-देव आइए इन अप/डाउन वोटों और उत्तरों में किसी भी व्यक्तिगत राय को पढ़ने की कोशिश न करें।

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

हमें चर्चाओं को रचनात्मक रखने की कोशिश करनी चाहिए, ताकि बदलाव किए जाने चाहिए या नहीं, बल्कि उन्हें किस तरह से किया जाना चाहिए, इस बारे में नहीं।

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

मैं सहमत हूं, हमें प्रस्ताव पर वापस आना चाहिए और इन अंतिम पोस्टों को भूल जाना चाहिए।

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

अभी डेवलपर्स के लिए प्रत्येक नियंत्रण (#684) पर अपना स्वयं का CornerRadius सेट करना आसान बनाने का एक प्रस्ताव है, जो टीम को डिफ़ॉल्ट रूप से नियंत्रण में CornerRadii जोड़ने में सक्षम बनाता है।

इसे OS स्तर पर करना एक जटिल कार्य है, और अनुसंधान इसे लागू करने में शामिल इंजीनियरिंग समय और प्रयास की काफी गारंटी नहीं देता है।

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

मैंने "AppBarSeparator" को गोलाई से हटाने के लिए युक्ति को अद्यतन किया है क्योंकि मैंने पुष्टि की है कि यह 1px लाइन है।

मैंने "AppBarSeparator" को गोलाई से हटाने के लिए युक्ति को अद्यतन किया है क्योंकि मैंने पुष्टि की है कि यह 1px लाइन है।

@chigy 100% स्केलिंग पर यह 1 एपेक्स होगा - लेकिन 200%, 300%, 400% स्केलिंग पर, इस पर कुछ ध्यान देने की आवश्यकता हो सकती है।

यदि यह वास्तव में एक रेखा है, और एक आयत नहीं है - शायद स्ट्रोकस्टार्टलाइनकैप और स्ट्रोकएंडलाइनकैप को पेनलाइनकैप पर

@mdtauk

इसे OS स्तर पर करना एक जटिल कार्य है, और अनुसंधान इसे लागू करने में शामिल इंजीनियरिंग समय और प्रयास की काफी गारंटी नहीं देता है।

ऐसा लगता है कि यह प्रस्ताव पहले से ही अधिकांश काम कर रहा है, नियंत्रण के लिए CornerRadius संपत्ति जोड़ रहा है। इसके बाद केवल एक चीज बची है जो संसाधन SystemCornerRadius का निर्माण होगा, वे नियंत्रण उनके वास्तविक कोने के दायरे के लिए बाध्य हो सकते हैं (इसी तरह आज आप अपने UI के तत्वों को रंग देने के लिए SystemAccentColor संसाधन का उपयोग उस उच्चारण रंग में करते हैं जो उपयोगकर्ता सेटिंग ऐप में सेट करता है।

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

@mdtauk

इसे OS स्तर पर करना एक जटिल कार्य है, और अनुसंधान इसे लागू करने में शामिल इंजीनियरिंग समय और प्रयास की काफी गारंटी नहीं देता है।

ऐसा लगता है कि यह प्रस्ताव पहले से ही अधिकांश काम कर रहा है, नियंत्रण के लिए CornerRadius संपत्ति जोड़ रहा है। इसके बाद केवल एक चीज बची है जो संसाधन SystemCornerRadius का निर्माण होगा, वे नियंत्रण उनके वास्तविक कोने के दायरे के लिए बाध्य हो सकते हैं (इसी तरह आज आप अपने UI के तत्वों को रंग देने के लिए SystemAccentColor संसाधन का उपयोग उस उच्चारण रंग में करते हैं जो उपयोगकर्ता सेटिंग ऐप में सेट करता है।

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

क्या यह स्लाइडर या टॉगल होगा?

[X] नियंत्रणों पर गोल कोने

बीटीडब्ल्यू सेट करने के लिए केवल एक कॉर्नर त्रिज्या मान नहीं होगा। कुछ तत्वों में केवल एक तरफ गोलाई होगी, या केवल शीर्ष कोनों को गोल किया जाएगा। फ्लाईआउट्स और पॉप ओवर नियंत्रणों को 4 ईपीएस त्रिज्या मिलेगी, जबकि अन्य नियंत्रणों में केवल 2 एपेक्स होंगे।

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

अंत में, यह एक ऐसा बदलाव हो सकता है जिसका बिना किसी उपद्रव के स्वागत किया जाता है, और इसलिए इसे ओएस में एक और विकल्प जोड़ने के लिए एक अति-प्रतिक्रिया माना जा सकता है।

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

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

विंडोज और डिजाइन टीम रोजाना (ट्विटर पर) बात करती है कि वह कैसे उपयोगकर्ताओं को शामिल करना चाहती है और उन्हें बाहर नहीं करना चाहती। यहां एक मौका है जहां मुझे लगता है कि एमएस के लिए अपने उपयोगकर्ताओं की राय में व्यापक विविधता का सम्मान करने के लिए एक विकल्प जोड़ना अपेक्षाकृत आसान है।

उपयोगकर्ता उन ऐप्स पर कैसे प्रतिक्रिया देंगे जो वे उपयोगकर्ता की वरीयता को अनदेखा करने का निर्णय लेते हैं?

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

@mdtauk @chigy
मेरा मानना ​​​​है कि @ फ़ेलिक्स-देव इस पर सही है, एक साधारण टॉगल वाला बूलियन स्विच उपयोगकर्ता स्तर पर अनुकूलन के लिए जाने का तरीका हो सकता है, मुझे लगता है कि उपयोगकर्ता स्तर पर इसके अनुकूलन के लिए एक स्लाइडर जटिल चीजों पर होगा, हालांकि अगर यह 3 निश्चित प्रीसेट पोजीशन वाला स्लाइडर है तो चीजें बदल सकती हैं।

3 निश्चित विकल्पों वाला एक स्लाइडर एक अतिरिक्त सेटिंग की अनुमति देगा जिसमें मूल रूप से प्रस्तावित एक की तरह एक अधिक कठोर कोने त्रिज्या परिवर्तन हो सकता है, ताकि आपके पास हो:

नुकीले - नुकीले कोने जैसे वे अभी हैं
मध्य विकल्प - नई छोटी त्रिज्या
गोलाकार - मूल प्रस्तावित त्रिज्या परिवर्तन या कुछ और अधिक गोलाकार

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

उपयोगकर्ता उन ऐप्स पर कैसे प्रतिक्रिया देंगे जो उपयोगकर्ता की वरीयता को अनदेखा करने का निर्णय लेते हैं?

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

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

इसे OS स्तर पर करना एक जटिल कार्य है, और अनुसंधान इसे लागू करने में शामिल इंजीनियरिंग समय और प्रयास की काफी गारंटी नहीं देता है।

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

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

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

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

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

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

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

मेरा एक्सएएमएल थोड़ा जंगली है लेकिन एक कम्बोबॉक्स टेम्पलेट है जैसे:

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

इसके अलावा अगर कोने का दायरा स्टाइल करने योग्य हो जाएगा तो क्या इसे सिर्फ पैरेंट कंट्रोल द्वारा सेट नहीं किया जा सकता है।

मेरा एक्सएएमएल थोड़ा जंगली है लेकिन एक कम्बोबॉक्स टेम्पलेट है जैसे:

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

यह उसी तरह है जैसे आप स्टाइल को ओवरराइड कर सकते हैं, लेकिन टेम्प्लेट में उपयोग के लिए आपको प्रत्येक ओरिएंटेशन के लिए अलग स्टाइल की आवश्यकता होगी।

<Thickness x:Name="FlyoutLooseCornerRadius" Value="4,4,4,4"/>

अभिविन्यास:

• नीचे
• बॉटमएजअलाइन्डलेफ्ट
• बॉटमएज अलाइन्ड राइट
• भरा हुआ
• बाएं
• लेफ्टएजअलाइन्डबॉटम
• लेफ्टएजअलाइन्डटॉप
• सही
• राइटएजअलाइन्डबॉटम
• राइटएजअलाइन्डटॉप
• शीर्ष
• TopEdgeAlignedLeft
• TopEdgeAlignedRight

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

<ComboBox CornerRadius="2,2,2,2">  
      <x:String>Blue</x:String>
      <x:String>Green</x:String>
      <x:String>Red</x:String>
      <x:String>Yellow</x:String>
</ComboBox>  

फ्लाईआउट पर CornerRadius प्रॉपर्टी को एडजस्ट करने के बाद जब इसे कॉम्बोबॉक्स (और अन्य नियंत्रण) से जोड़ा और संलग्न किया जाता है, तो वांछित परिणाम प्राप्त करने के लिए इसे फ्लाईआउटप्लेसमेंटमोड एनम में TopEdgeAligned और bottomEdgeAligned को जोड़ने की आवश्यकता हो सकती है।

_(अपडेटेड इमेज)_

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

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

वैसे मैंने अभी देखा है कि यह "संलग्न रूप" है कि मैकोज़ टॉप मेनू बार कैसे काम करता है, इसलिए यह रूप असामान्य रूप से असामान्य प्रतीत नहीं होता है;)

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

वैसे मैंने अभी देखा है कि यह "संलग्न रूप" है कि मैकोज़ टॉप मेनू बार कैसे काम करता है, इसलिए यह रूप असामान्य रूप से असामान्य प्रतीत नहीं होता है;)

मैं गोलाई भूल गया था, इसलिए मैंने इसे ठीक करने के लिए छवि को अद्यतन किया, और ज़ूम किए गए उदाहरण के साथ थोड़ा और विवरण भी जोड़ा - ओह और इसमें होवर राज्य शामिल है

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

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

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

और कुछ संदर्भ मेनू में ऐसे नियंत्रण होंगे जो फ़्लाईआउट की पूरी चौड़ाई तक नहीं फैले हैं, इसलिए गोल चयन उनके लिए काम करेगा

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

मैं भी यही महसूस करता हूँ। यदि कॉम्बो सूची कॉम्बो बॉक्स के समान आकार की है, तो उन्हें मूल बिंदु पर सीधे रहना चाहिए, अन्यथा जो पक्ष पंक्तिबद्ध नहीं है वह गोल होना चाहिए।

@mdtauk @Qowy @shaheedmalik यह आप comboboxes के लिए एक स्वयं के मुद्दे विशिष्ट बनाने के लिए संभव हो सकता है? यह धागा सामान्य रूप से कोने के दायरे के बारे में है और कुछ विशिष्ट मामलों के बारे में नहीं है जो आसानी से एक पूरी नई बातचीत को जन्म दे सकता है जैसा कि यहां देखा गया है, और इस प्रकार सामान्य दृष्टिकोण के बारे में बात करने वाले बिंदुओं को ढंकता है।

कृपया इसे गलत न समझें, लेकिन अगर हमारे पास कई नियंत्रणों के लिए ऐसी विशिष्ट चर्चाएं हैं, तो यह धागा आसानी से अपना सामान्य फोकस खो देगा।

बहुत सराहना की!

पीएस: गैर-सीमा हाइलाइट किए गए तत्वों के बारे में: तत्व हाइलाइट निश्चित रूप से एक आयताकार होना चाहिए। इसे गोल रंग बनाना अजीब है।

मैं शायद अपनी राय के साथ यहां अल्पमत में हूं, लेकिन सामान्य नियंत्रणों के कोने की त्रिज्या को बदलना ईमानदारी से एक भयानक विचार है। @mdtauk से ऊपर दिए गए मेनू उदाहरण को

@mdtauk

इसे OS स्तर पर करना एक जटिल कार्य है, और अनुसंधान इसे लागू करने में शामिल इंजीनियरिंग समय और प्रयास की काफी गारंटी नहीं देता है।

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

क्या यह स्लाइडर या टॉगल होगा?
[X] नियंत्रणों पर गोल कोने
बीटीडब्ल्यू सेट करने के लिए केवल एक कॉर्नर त्रिज्या मान नहीं होगा। कुछ तत्वों में केवल एक तरफ गोलाई होगी, या केवल शीर्ष कोनों को गोल किया जाएगा। फ्लाईआउट्स और पॉप ओवर नियंत्रणों को 4 ईपीएस त्रिज्या मिलेगी, जबकि अन्य नियंत्रणों में केवल 2 एपेक्स होंगे।
जैसे ही यह सेटिंग OS में बदलती है, आप कई चर सेट कर रहे होंगे। फिर परीक्षण के बारे में क्या? साथ ही उम्मीदें भी होंगी। उपयोगकर्ता उन ऐप्स पर कैसे प्रतिक्रिया देंगे जो वे उपयोगकर्ता की वरीयता को अनदेखा करने का निर्णय लेते हैं?
आप उन उपयोगकर्ताओं के साथ कैसे संवाद करते हैं जिनके नियंत्रण गोल हो जाते हैं, और कौन से नहीं? कुछ नियंत्रणों में आंतरिक सीमा या बाहरी सीमा तत्व होंगे। आकृतियों के किनारों को ठीक से गले लगाना सुनिश्चित करने के लिए इन्हें अपने CornerRadius मानों को समायोजित करने की आवश्यकता होगी।
अंत में, यह एक ऐसा बदलाव हो सकता है जिसका बिना किसी उपद्रव के स्वागत किया जाता है, और इसलिए इसे ओएस में एक और विकल्प जोड़ने के लिए एक अति-प्रतिक्रिया माना जा सकता है।

यहां 2epx कोने का दायरा, 4epx कोना का दायरा, और दूसरी जगह पर अलग होना क्योंकि 2 या 4 बिल्कुल सही नहीं दिखता है, भयानक UX है। सामान्य नियंत्रणों को वैसे ही छोड़ दें जैसे वे हैं - काम हो गया ... कुछ और महान बनाने के लिए आगे बढ़ें।

@चिगी
इसलिए मैंने कुछ दिनों पहले शुरू किए गए रेडिट थ्रेड में प्रतिक्रियाओं से गिनती की और यहां यह है (दुर्भाग्य से, भाग लेने वाले उपयोगकर्ताओं की कुल संख्या को आसानी से देखने का कोई स्पष्ट तरीका नहीं है):

राय व्यक्त कोने-कोने के दायरे (वर्तमान UI के विपरीत): 18
राय ने प्रो-करंट यूआई (और कॉन्ट्रा कॉर्नर रेडियस) को व्यक्त किया: 12 (+1 अगर मैं मुझे रेडिट पोस्टर के रूप में शामिल करता हूं, तो प्रो-कॉर्नर-रेडियस काउंट में

बाकी का:

• MS से UI विकल्प प्रदान करने के लिए कहना
• दोनों के साथ ठीक
• प्रस्ताव पर कोई राय नहीं दी
• विंडोज सिस्टम में विसंगतियों के साथ एक सामान्य निराशा व्यक्त की (यानी Win32 प्रोग्राम बनाम UWP ऐप्स)

विशेष रूप से अंतिम समूह (निराशा) धागे में भाग लेने वाले लोगों का एक अच्छा हिस्सा था।

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

@चिगी
Microsoft डिज़ाइन टीम द्वारा उपयोगकर्ताओं को "बहिष्कृत" करने के बजाय "शामिल" करने के लिए सभी बातों के साथ, मुझे लगता है कि यह थ्रेड और उपरोक्त रेडिट थ्रेड दिखाता है कि प्रस्तावित गोल कोने के बीच स्विच करने के लिए UI में एक सरल विकल्प प्रदान करने के अच्छे कारण हैं। UI और वर्तमान UI (तेज कोने)।

@ फ़ेलिक्स-देव तकनीकी रूप से मैंने जो पोस्ट बनाया वह फ्लाईआउट नियंत्रण के बारे में था, कॉम्बोबॉक्स केवल उन नियंत्रणों में से एक है जिसमें फ्लाईआउट घटक होता है।

मुझे लगता है कि सभी परिस्थितियों में सभी कोनों पर चक्कर लगाना समझ में आता है। और टीम ने फ़ैसला किया कि फ़्लायआउट्स और डायलॉग्स में 4 एपीएक्स कॉर्नर का उपयोग किया जाएगा, और अन्य नियंत्रणों में 2 एपेक्स का उपयोग किया जाएगा।

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

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

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

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

यदि आप पदों की गिनती करने जा रहे हैं, तो आपको अपवोट भी गिनने चाहिए।

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

FWIW, "2px सबसे प्यारा स्थान लगता है।" 54 अंकों के साथ सबसे अधिक वोट प्राप्त किया।

"अंतिम उपयोगकर्ता थीमिंग समर्थन" के लिए कॉल करने वाला एक उच्च-रेटेड पोस्ट (+21 - चौथा स्थान) भी है, हालांकि मैं यह निर्धारित नहीं कर सकता कि क्या वे सभी अपवोट कॉल-फॉर-कस्टमाइजेशन भाग के लिए हैं या उस हिस्से के लिए जहां लेखक आलोचना करता है लापता प्रणाली में निरंतरता।

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

पूछने के लिए धन्यवाद। मैं इस मुद्दे के "महत्वपूर्ण नोट" खंड में डिज़ाइन कंप्स से जुड़ा हुआ हूं, इसलिए कृपया इसे जांचना सुनिश्चित करें।

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

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

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

पूछने के लिए धन्यवाद। मैं इस मुद्दे के "महत्वपूर्ण नोट" खंड में डिज़ाइन कंप्स से जुड़ा हुआ हूं, इसलिए कृपया इसे जांचना सुनिश्चित करें।

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

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

मुझे लगता है कि मुझे इसका उत्तर पता है, लेकिन मैं वैसे भी पूछूंगा - क्या इन विंडोज यूआई डिज़ाइनों को साझा करने की योजना है जिस पर टीम ने फैसला किया है?

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

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

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

मुझे लगता है कि यह फीडबैक हब में तब दिखाई देगा जब डिजाइन में बदलाव लाइव होंगे - यह विंडोज टीम तक पहुंचने की सबसे अधिक संभावना है।

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

मुझे लगता है कि मुझे इसका उत्तर पता है, लेकिन मैं वैसे भी पूछूंगा - क्या इन विंडोज यूआई डिज़ाइनों को साझा करने की योजना है जिस पर टीम ने फैसला किया है?

@mdtauk
हां, और यहां बहुत पारदर्शी होने के लिए ... वास्तविकता यह है कि, इस विशेष मुद्दे की बातचीत जितनी जल्दी धीमी हो जाती है, उतनी ही जल्दी मैं उस पर काम कर सकता हूं... :)

@chigy अगर मैंने बातचीत को पटरी से उतारने और प्रगति को धीमा करने में योगदान दिया है तो मैं क्षमा चाहता हूं। मैं केवल हमेशा मदद करना चाहता था, और सुनिश्चित करना चाहता था कि WinUI 3.0 जितना अच्छा हो सके उतना अच्छा लगे!

@चिगी
अब मैं उलझन में हूँ। आप विंडोज फ्लुएंट डिज़ाइन टीम पर काम करने वाले व्यक्ति हैं, विनयूआई को "[...] अत्यधिक अनुकूलित देशी यूआई प्लेटफॉर्म कहा जाता है जिसका उपयोग विंडोज़ बनाने के लिए किया जाता है" ( यहां से उद्धृत, अनुभाग "विनयूआई 3 के लाभ"। तो, अगर यह विंडोज 10 डिजाइन लैंग्वेज को प्रभावित करने की जगह नहीं है, तो यह क्या है?

मुझे नहीं पता कि आपके उत्तर के बारे में कैसा महसूस करना है। आप मूल रूप से हमसे प्रतिक्रिया मांग रहे हैं, लेकिन यह पता चला है कि हमें कभी भी प्रस्ताव को प्रभावित करने का अधिक मौका नहीं मिला? यदि इस पद पर वास्तविक अधिकार वाला कोई नहीं है, तो हम यहां केवल मूल रूप से गर्म हवा करते हैं। यहां तक ​​​​कि मार्टिन जैसे मामलों में जहां वह अपनी डिजाइन अवधारणाओं को इस उम्मीद में पोस्ट कर रहा है कि वे desgin टीम द्वारा लागू किए जाएंगे। WinUI नियंत्रणों को अलग-अलग शैली में नहीं रख सकता है जहाँ से "विंडोज़ डिज़ाइन प्राधिकरण" इसे जाना चाहता है, क्योंकि जैसा कि WinUI टीम ने स्वयं कहा था: "WinUI 3.0+ विंडोज UI होगा"।

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

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

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

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

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

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

UI अनुकूलन के लिए हमारा आह्वान अब वास्तव में कहां खड़ा है? क्या यह रेपो वास्तव में अब विंडोज यूआई चर्चाओं के लिए मायने रखता है?

मैं इसके साथ छोड़ दूँगा:

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

@ फेलिक्स-देव मुझे प्रभावित करने की उम्मीद थी, न कि मेरे डिजाइन वास्तविक डिजाइन बनने पर जोर दें। मैं एक डिज़ाइनर हूँ जो Windows Vista/7/Zune/Windows Phone के दिनों से ही Windows उत्साही रहा है।

@mdtauk
वास्तव में, हालांकि आपके पास निश्चित रूप से एमएस के खिलाफ आपके विचारों को अपनाने के खिलाफ कुछ भी नहीं होगा, है ना? आखिर आप उनके कायल हैं!

क्षमा करें यदि यह आपके आस-पास आया क्योंकि आप धक्का दे रहे थे (और मेरे लिए निष्पक्ष होने के लिए आपने भी कहा था कि आपके प्रस्ताव इस तरह आ सकते हैं), लेकिन @chigy का जवाब मेरे लिए काफी

विनयूआई टीम! = विंडोज देव टीम।

विंडोज 10 वर्तमान ओएस है, लेकिन विंडोज लाइट और विंडोज कोर ओएस भविष्य की दिशाएं हैं।

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

Microsoft की फ़्लुएंट डिज़ाइन टीम नियम (रंग, फ़ॉन्ट शैली और आकार, सामग्री, आदि) बनाती है जिसका अनुसरण अन्य Microsoft टीमें अपने UI डिज़ाइन कार्य के साथ WinUI, Windows, Xbox, Office, Bing, Teams, Fabric, Fluent Web जैसी करती हैं।

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

मेरे विचार जो मैं इस रेपो में योगदान दे रहा हूं - फैब्रिक वेब और विनयूआई 3.0 के बीच की खाई को पाटने की कोशिश कर रहा हूं - मैंने उन विचारों को भी शामिल किया है जिन पर मैं Win8 दिनों से विचार कर रहा हूं।

स्पष्टीकरण वास्तव में अच्छा होगा, क्योंकि यहां मैंने इसे समझा है:

@chigy विंडोज़ फ़्लुएंट डिज़ाइन टीम की सदस्य हैं और FD (फ्लुएंट डिज़ाइन) Windows 10 की डिज़ाइन भाषा होने के कारण, वह इस प्रकार Windows डिज़ाइन टीम की सदस्य होंगी।

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

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

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

वैसे यह मेरे लिए एक बड़ी निराशा है, जैसा कि दूसरों ने कहा कि यह हम में से कई लोगों के लिए एक बहुत बड़ा मुद्दा है, इसलिए यदि आपके पास इसका कोई लाभ नहीं है तो क्या मैं विनम्रता से पूछ सकता हूं @chigy : वह व्यक्ति कौन है जिसके साथ हमें बात करनी चाहिए? यदि नहीं, तो हम इस स्पष्ट रूप से विवादास्पद UI परिवर्तन पर अपनी आवाज़ कैसे सुना सकते हैं, जिसे बहुत से लोग नापसंद करते हैं?

यह विंडोज 10 के विकास के वर्षों पहले हुए प्रवचन के समान है, जब स्क्वायर प्रोफाइल पिक्चर्स को सर्कुलर में बनाने का प्रस्ताव था, कई लोगों ने इसे फिर से नापसंद किया और फीडबैक हब में चले गए। फीडबैक हब में 1000000+ से अधिक समर्थन के साथ कई पोस्ट थे, जो ऐसा नहीं करने के लिए कह रहे थे।

प्रतिक्रिया अनिवार्य रूप से लोगों को फिर से बता रही थी कि उनकी राय की परवाह किए बिना परिवर्तन किया जा रहा है ...

मैं उस पोस्ट को कम कृपालु और अपमानजनक @ फ़ेलिक्स-देव . के रूप में फिर से लिखूंगा

@mdtauk
मेरी पोस्ट अपमानजनक कहाँ है?

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

@mdtauk
मेरी पोस्ट अपमानजनक कहाँ है?

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

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

@mdtauk
"चिगुसा सानसेन एक्सएएमएल यूआई प्लेटफॉर्म टीम में एक प्रधान कार्यक्रम प्रबंधक है और फ्लुएंट डिजाइन सिस्टम के मुख्य सदस्यों का हिस्सा है " (स्रोत: https://mybuild.techcommunity.microsoft.com/speaker/545575?source=sessions)

उन्होंने उस सत्र में विंडोज से संबंधित FD पार्ट भी अपने पास रखा था।

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

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

वैसे मैं इसे अपमानजनक मानता हूं। विशेष रूप से ऐसा लगता है कि आपको "भ्रमित" होने के विरोध में चर्चा के उद्देश्य को गलत समझा गया है

@mdtauk
हम यहां एक अलग तरंग लंबाई पर हैं और मेरे लिए यह अनुमान लगाने की कोशिश करने का कोई मतलब नहीं है कि ऐसा क्यों हो सकता है ...

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

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

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

@mdtauk
हम यहां एक अलग तरंग लंबाई पर हैं और मेरे लिए यह अनुमान लगाने की कोशिश करने का कोई मतलब नहीं है कि ऐसा क्यों हो सकता है ...

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

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

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

यह समस्या वेब और ऐप शैली दिशा के अनुरूप कॉमन कंट्रोल पर कॉर्नर रेडियस को अपडेट करने से संबंधित है।

मेरे द्वारा पोस्ट किए गए विचार फैब्रिक वेब द्वारा उपयोग की जाने वाली शैलियों को ले रहे थे, और उन्हें एक्सएएमएल नियंत्रण में ला रहे थे - और इसलिए मुझे लगता है कि वे इस चर्चा के दायरे में हैं। OS सुविधाएँ जो XAML नियंत्रण को नियंत्रित करती हैं, ThemeResource विषय से थोड़ा हटकर है, लेकिन संबंधित है।

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

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

कृपया आचार संहिता देखें और सम्मानजनक बनने का प्रयास करें। @chigy धोखा देने या गुमराह करने की कोशिश नहीं कर रहा था।

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

धन्यवाद, @ फ़ेलिक्स-देव, @Nepxune , और @mdtauk , कुछ इंगित करने के लिए जब मैंने इस गिटहब आइटम को संभाला तो शायद मैं बहुत स्पष्ट नहीं था। जैसा कि आप जानते हैं, यह हमारा पहला डिज़ाइन से संबंधित मुद्दा है जिस पर हम खुले समुदाय में चर्चा कर रहे हैं इसलिए हम सीख रहे हैं जैसे हम जाते हैं …

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

डिजाइन के संबंध में विनयूआई की भूमिका को संक्षेप में प्रस्तुत करने के लिए @jevansaks धन्यवाद।

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

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

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

हर कोई, मेरा मतलब इस मुद्दे को बंद करना नहीं था। मैं टिप्पणी को बंद करने की कोशिश कर रहा था और गलती से ऐसा हो गया !!

@mdtauk @jevansaks @chigy
मैं आपसे पूरी तरह सहमत हूं कि यह चर्चा पेशेवर बनी रहनी चाहिए। हम सभी विंडोज़ के लिए अपने जुनून में और विंडोज़ को यथासंभव सर्वश्रेष्ठ बनते देखने की इच्छा में एकजुट हैं।

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

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

आम तौर पर, मैं पहले से ही वर्तमान स्थिति से काफी प्रभावित हूं। फीडबैक जारी किया जाता है और WinUI टीम द्वारा गंभीरता से व्यवहार किया जाता है, भले ही वास्तविक WinUI उत्पाद से संबंधित फीडबैक न हो। मैं इसकी सराहना करता हूं और इसके लिए आपके मन में सम्मान है!

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

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

जैसा कि आप में से कुछ ने बताया, मैं स्पष्ट नहीं था कि विनयूआई टीम क्या कर सकती है और मैं क्या नहीं कर सकता, इसलिए मैं उन महान बिंदुओं को संक्षेप में बताने का प्रयास करता हूं जो आप सभी ने उठाए और उसके निष्कर्ष। और अगर आपको लगता है कि मुद्दे अभी भी खुले हैं, तो कृपया आगे बढ़ें!

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

• सुनिश्चित करें कि Xbox पर विचार किया जा रहा है (@mdtauk)
  o Xbox डिज़ाइन का स्वामित्व Xbox टीम के पास है।
  o लेकिन हाँ, हम उनके साथ मिलकर काम करते हैं। मैं पुष्टि कर रहा हूँ कि एक मीटिंग हुई है जहाँ हमने Xbox डिज़ाइन टीम के साथ इसकी और आगामी डिज़ाइन प्रस्तावों की समीक्षा की।
• संरेखण के लिए नियंत्रण संबंधी अन्य परिवर्तन करने पर विचार करें जैसे कि सीमा रेखाओं को पतला बनाना (@mdtauk)
  o विंडोज़ डिज़ाइन टीम, फ़्लुएंट डिज़ाइन सिस्टम कलेक्टिव के साथ समन्वय करते हुए विंडोज़ के लिए अंतिम कॉल करती है ताकि Microsoft डिज़ाइन टीमों में संरेखित करने का प्रयास किया जा सके।
  o WinUI टीम इसे डेवलपर्स के लिए बेहतर काम करेगी और स्विच करने (या वापस स्विच करने) के लिए एक अच्छी डेवलपर कहानी होगी।
  o इसे आगामी GitHub मुद्दों में ट्रैक किया जाएगा।
• समुदाय फ़्लुएंट डिज़ाइन टीम ( @mdtauk , @ फ़ेलिक्स-देव, @Nepxune) को सीधे अपनी राय देने के लिए एक जगह चाहता है।
  o FYI करें, Fluent टीम का एक LinkedIn समूह है।
  o यह WinUI टीम या स्वयं के स्वामित्व में नहीं है।
  यह उनके ध्यान में लाया जा रहा है, लेकिन अगर कुछ होगा तो हम खुद को प्रतिबद्ध नहीं कर सकते।
  o अगर कुछ होता है तो मैं इस समूह के साथ वापस संवाद करना सुनिश्चित करूंगा।
• क्या हम डब्ल्यूपीएफ/विनफॉर्म के लिए फ्लुएंट थीम जारी करते हैं? (@ फ़ेलिक्स-देव, @mdtauk)
  ओ यह कुछ ऐसा है जिसे हमने अभी तक नहीं समझा है।
  ओ यह थोड़ा जटिल है। मैं एक ऐसा व्यक्ति हूं जो विंडोज़ के लिए समग्र रूप से डेवलपर्स के लिए डिज़ाइन मार्गदर्शन और डिज़ाइन समर्थन देख रहा है, इसलिए यह मेरी चिंता का क्षेत्र फिट बैठता है। हालाँकि, स्पष्ट रूप से, यह इस समय प्राथमिकता नहीं है क्योंकि यह WinUI कार्य नहीं है।
• उपयोगकर्ता सेटिंग जहां उपयोगकर्ता गोलाकार कोने को चालू/बंद कर सकता है और/या कुछ बिंदु तक दानेदार मान परिवर्तन कर सकता है (@ फ़ेलिक्स-देव) / गोलाकार कोने पसंद नहीं है, इसे गोलाकार न रखें और उपयोगकर्ता को एक विकल्प दें ( @Nepxune और लोग रेडिट)
  o दुर्भाग्य से, यह WinUI निर्णय नहीं है।
  o सबसे अच्छा मैं अभी अनुशंसा कर सकता हूं कि एक बार जब यह परिवर्तन विंडोज ओएस पर लागू हो जाए तो फीडबैक हब मुद्दों को खोलें और आपको अभी भी यह नहीं लगता कि डिजाइन आपकी आवश्यकताओं को पूरा करता है?
  o यदि कोई सांत्वना मिलती है, तो मैंने विंडोज टीम को सूचित करने की पूरी कोशिश की, लेकिन उनकी टीम द्वारा कोई योजना नहीं है।

यह हमारी वर्तमान योजना को सारांशित करता है:

• WinUI 2.x का उपयोग करके आपको जो नियंत्रण मिलते हैं, वे गोल कोनों का उपयोग करने के लिए डिफ़ॉल्ट दृश्यों को अपडेट करेंगे।
  o दूसरे शब्दों में, यदि आप WinUI 2.x का उपयोग नहीं करते हैं, तो आपको यह परिवर्तन नहीं मिलेगा।
• अधिकांश नियंत्रणों के लिए गोल कोनों का मान 2px है, फ़्लायआउट प्रकार UI के लिए 4px है। जब UI अन्य UI तत्वों के साथ प्रतिच्छेद करता है तो कोई गोलाई नहीं होती है
  यहां विजुअल कॉम्प: https://github.com/mrlacey/microsoft-ui-xaml-specs/blob/RoundedCornerVisualizations/active/RoundedCorner/ImageFiles/index.md
  ओ लघु टिप्पणी @mdtauk, @Qowy, @shaheedmalik ने इस बारे में बातचीत की थी करने के लिए। हम आंतरिक रेखाओं को गोल नहीं करेंगे। यह उस दृश्य COMP में परिलक्षित होता है जो जगह में है। विंडोज डिजाइन टीम ने विभिन्न विकल्पों और पेशेवरों और विपक्षों को देखा और उनका मूल्यांकन किया है।
• डेवलपर्स के पास इसे आसानी से वापस टॉगल करने का एक तरीका है (#684)।
• कोई उपयोगकर्ता सेटिंग नहीं होगी जो उपयोगकर्ताओं को इसे आगे/पीछे टॉगल करने देती है, या बारीक परिवर्तन करती है।

@chigy आपके द्वारा पोस्ट किए गए सारांश के लिए धन्यवाद।

आगे क्या होगा इसके बारे में मेरे कुछ प्रश्न हैं...

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

• आप कैसे सुझाव देते हैं कि हम एक समुदाय के रूप में WinUI में आने वाले इन डिज़ाइन विकल्पों में से कुछ को प्रभावित करने या सुझाव देने का प्रयास करते हैं?

• हम विंडोज यूआई के लिए विंडोज डिजाइन टीम के दृष्टिकोण को कब देख पाएंगे, इसलिए हमारे पास नियंत्रण डिजाइनों पर काम करने के लिए एक संदर्भ हो सकता है?

• क्या एक्सएएमएल का उपयोग करके इनबॉक्स ऐप्स और शेल तत्वों के बीच निरंतरता को मनाने/काजोल/लागू करने का प्रयास किया जाएगा, इसलिए सब कुछ डिजाइन में मेल खाता है?

• क्या Xbox संशोधित नियंत्रण डिज़ाइनों को WinUI में शामिल किया जाएगा, या वे केवल अगले Xbox उपकरणों पर आएंगे (विंडोज़ पर विकसित होने के दौरान इन नियंत्रण टेम्पलेट्स का परीक्षण करने का कोई तरीका नहीं है?

@mdtauk , ओह, मैंने बहुत कुछ लिखा लेकिन मैं यह सुनिश्चित करना चाहता था कि मैंने खुद को अच्छी तरह समझाया ...

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

COMP में आप जो देख रहे हैं वह उतना ही अंतिम है जितना हम इस समय प्राप्त कर सकते हैं। उस ने कहा, जैसा कि हम वास्तविक नियंत्रणों में परिवर्तन को लागू करते हैं, कुछ मामूली परिवर्तन हो सकते हैं जो डिज़ाइन को थोड़ा सा स्थानांतरित करने का कारण बनता है। जैसा कि आप देख सकते हैं, COMP प्रत्येक UI घटनाओं को कवर नहीं करता है। हालांकि, इस विशेष प्रयास से मुझे इसकी उम्मीद नहीं है...

• आप कैसे सुझाव देते हैं कि हम एक समुदाय के रूप में WinUI में आने वाले इन डिज़ाइन विकल्पों में से कुछ को प्रभावित करने या सुझाव देने का प्रयास करते हैं?

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

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

• हम विंडोज यूआई के लिए विंडोज डिजाइन टीम के दृष्टिकोण को कब देख पाएंगे, इसलिए हमारे पास नियंत्रण डिजाइनों पर काम करने के लिए एक संदर्भ हो सकता है?

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

• क्या एक्सएएमएल का उपयोग करके इनबॉक्स ऐप्स और शेल तत्वों के बीच निरंतरता को मनाने/काजोल/लागू करने का प्रयास किया जाएगा, इसलिए सब कुछ डिजाइन में मेल खाता है?

मैं जो जानता हूं उसके आधार पर नीचे पूरी तरह से मेरी अपनी राय है। केवल स्पष्ट करने के लिए... :)
मेरे विचार से समस्या दुगनी है।

पहली समस्या यह है कि वर्तमान में हमारे पास नए UI के लिए वितरण प्रणाली है जो OS रिलीज़ पर निर्भर है। उसके कारण, बहुत से इनबॉक्स ऐप्स नई शैलियों को नहीं अपना सके जिनका शेल उपयोग कर रहा था, आदि क्योंकि उन्हें अभी भी पुराने OS संस्करण का समर्थन करने की आवश्यकता थी। हम WinUI में नया UI डिलीवर करके इसे हल करने का प्रयास कर रहे हैं ताकि आप OS संस्करण की परवाह किए बिना इन परिवर्तनों को अपना सकें।

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

• क्या Xbox संशोधित नियंत्रण डिज़ाइनों को WinUI में शामिल किया जाएगा, या वे केवल अगले Xbox उपकरणों पर आएंगे (विंडोज़ पर विकसित होने के दौरान इन नियंत्रण टेम्पलेट्स का परीक्षण करने का कोई तरीका नहीं है?

हमारे पास विशेष रूप से Xbox के लिए नियंत्रणों को संशोधित करने की कोई योजना नहीं है। हमने अतीत में ऐसा नहीं किया है (हमने एक दस्तावेज जारी किया है) और Xbox टीम के साथ-साथ समुदाय (यह प्री-ओपन सोर्स है) दोनों से कोई मजबूत अनुरोध प्राप्त नहीं हुआ है।

@chigy इतनी स्पष्टवादी और प्रतिक्रिया देने के लिए फिर से धन्यवाद।

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

दृष्टि के लिए - मेरा मतलब है "यहां भविष्य में विंडोज शैल और इनबॉक्स ऐप्स कैसा दिखेंगे।" और "हम अपने विंडोज़ डिज़ाइन को अपडेट करने का अवसर ले रहे हैं, यहां कुछ बदलाव हैं जो हम कर रहे हैं ..."

क्यू चित्र और या वीडियो

मुझे यह भी लगता है कि Xbox और Windows को एक दूसरे से मेल खाना चाहिए। हमारे पास Xbox पर ऐप्स हैं जो विंडोज़ पर बंद कर दिए गए हैं लेकिन अभी भी Xbox (सीबीएस, फॉक्स स्पोर्ट्स) पर मौजूद हैं या विंडोज 10 (यूट्यूब) पर कभी मौजूद नहीं हैं।

यदि आप किसी भी प्रकार के UI परिवर्तन करने से बचते हैं, तो यह इन ऐप्स को प्लेटफ़ॉर्म पर रखेगा।

बस मेरे विचार।

मुझे यह भी लगता है कि Xbox और Windows को एक दूसरे से मेल खाना चाहिए। हमारे पास Xbox पर ऐप्स हैं जो विंडोज़ पर बंद कर दिए गए हैं लेकिन अभी भी Xbox (सीबीएस, फॉक्स स्पोर्ट्स) पर मौजूद हैं या विंडोज 10 (यूट्यूब) पर कभी मौजूद नहीं हैं।

यदि आप किसी भी प्रकार के UI परिवर्तन करने से बचते हैं, तो यह इन ऐप्स को प्लेटफ़ॉर्म पर रखेगा।

बस मेरे विचार।

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

@shaheedmalik और @mdtauk, मैं थोड़ा एक्सबॉक्स और Windows के बारे में चर्चा के बारे में उलझन में से मेल खाना चाहिए और एप्लिकेशन एक दूसरे पर चलाना चाहिए हूँ।

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

UWP ऐप जो ठीक से बनाया गया है वह विंडोज और एक्सबॉक्स दोनों पर चलेगा। @shaheedmalik सूचियों जैसे ऐप्स के लिए, वे बहुत अधिक ब्रांडेड हैं कि हमने अक्सर एक ही ब्रांड को Xbox और Windows पर आने के लिए देखा है। इसलिए एक ऐप डिज़ाइन अक्सर उन डिवाइसों पर चल रहा होता है।

फिर से, यह गोल कोने वाला विषय है, इसलिए इसे वापस ला रहे हैं...
यहां बताया गया है कि एक बार राउंड कॉर्नर रिलीज़ होने के बाद डेवलपर को Xbox पर क्या करना होगा। यदि कोई डेवलपर WinUI 2.x को अपनाता है जिसमें गोल कोने की सुविधा है, तो देव को गोल कोने की शैली को बंद करने की आवश्यकता होगी यदि वे शेल की शैली से मेल खाना चाहते हैं। ध्यान रहे, Xbox पर बहुत सारे ऐप्स नहीं हैं... इसलिए हम परवाह करने वालों के लिए मार्गदर्शन दस्तावेज़ जारी करते हैं। जब हम रिलीज़ करेंगे तो मैं सुनिश्चित करूँगा कि 10FT मार्गदर्शन दस्तावेज़ में गोल कोने के बारे में उल्लेख किया गया हो।

दृष्टि के लिए - मेरा मतलब है "यहां भविष्य में विंडोज शैल और इनबॉक्स ऐप्स कैसा दिखेंगे।" और "हम अपने विंडोज़ डिज़ाइन को अपडेट करने का अवसर ले रहे हैं, यहां कुछ बदलाव हैं जो हम कर रहे हैं ..."

क्यू चित्र और या वीडियो

@mdtauk , यह कुछ ऐसा है जो मैंने अतीत में डिज़ाइन टीम से पूछा है, इसलिए हम एक प्लेटफ़ॉर्म टीम के रूप में, इसका उपयोग डेवलपर दर्शकों के लिए डिज़ाइन विजन को संप्रेषित करने के लिए कर सकते हैं। जहां तक ​​मुझे पता है, तत्काल कोई योजना नहीं है लेकिन मैं फिर से जांच कर सकता हूं।

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

@mdtauk , यह कुछ ऐसा है जो मैंने अतीत में डिज़ाइन टीम से पूछा है, इसलिए हम एक प्लेटफ़ॉर्म टीम के रूप में, इसका उपयोग डेवलपर दर्शकों के लिए डिज़ाइन विजन को संप्रेषित करने के लिए कर सकते हैं। जहां तक ​​मुझे पता है, तत्काल कोई योजना नहीं है लेकिन मैं फिर से जांच कर सकता हूं।

धन्यवाद। // बिल्ड / उन परिवर्तनों को साझा करने का सही अवसर होता, जिनकी योजना बनाई जा रही थी, खासकर यदि योजना इन नियंत्रण टेम्प्लेट को गर्मियों के अंत में WinUI 3.0 की प्रारंभिक रिलीज़ के साथ अपडेट करने की है।

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

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

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

@mdtauk , मुझे लगता है कि Xbox के बारे में यह बातचीत # 698 के साथ बेहतर अनुकूल लगती है? मैंने Xbox में किसी को यह देखने के लिए पिंग किया है कि क्या वे दूसरी बातचीत पर टिप्पणी कर सकते हैं (कोई वादा नहीं :))। वह फिर से, यह एक खुला स्रोत समुदाय है, शायद आप उक्त संसाधन बना सकते हैं और हमें किसी तरह से उपभोग करने का प्रस्ताव दे सकते हैं? सिर्फ यह कहते हुए...

@chigy वह एक मुद्दा था जिसे मैंने सबमिट किया था, और यह सुनिश्चित करने के बारे में था कि समुदाय द्वारा WinUI में जोड़े जाने वाले किसी भी नियंत्रण में भविष्य के Xbox कंसोल पर चलने के लिए टेम्पलेट शामिल होना चाहिए। यदि डेवलपर्स अपने Xbox ऐप के लिए WinUI 3.0+ का उपयोग करना चाहते हैं - तो टीवी पर चलते समय सभी नियंत्रण सही दिखने के लिए अनुकूलित होने चाहिए।

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

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

यदि डेवलपर्स अपने Xbox ऐप के लिए WinUI 3.0+ का उपयोग करना चाहते हैं - तो टीवी पर चलते समय सभी नियंत्रण सही दिखने के लिए अनुकूलित होने चाहिए।

@mdtauk , जैसा कि मैंने पहले उल्लेख किया था, यह एक अच्छा सुझाव है लेकिन यह हमारी प्राथमिकता नहीं है क्योंकि Xbox टीम या स्वयं के अलावा समुदाय दोनों से कोई अनुरोध नहीं आया है।

इस तथ्य को अपडेट किया गया है कि WebView के स्क्रॉलइंडिकेटर को XAML के माध्यम से अपडेट नहीं किया जाएगा, लेकिन हम वेब का जैसा है वैसा ही उपयोग करते हैं।

MUXControlsTestApp में वर्तमान प्रोग्रेस बार को देखते हुए - क्या प्रोग्रेस वैल्यू बार का दाहिना सिरा भी गोल होगा, या यह अपने फ्लैट किनारे को बनाए रखेगा?

क्या वॉल्यूम फ़्लायआउट के भीतर स्लाइडर को भी स्टाइल किया जाएगा

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

क्या ColourPicker में उपयोग किए गए स्लाइडर को MediaPlayer के समान आउटलाइन शैली से लाभ होगा - ताकि यह बार के गहरे रंगों के बीच खो न जाए?

MUXControlsTestApp में वर्तमान प्रोग्रेस बार को देखते हुए - क्या प्रोग्रेस वैल्यू बार का दाहिना सिरा भी गोल होगा, या यह अपने फ्लैट किनारे को बनाए रखेगा?

डिजाइन परिभाषा के अनुसार, यह होना चाहिए। कृपया MUXControlsTestApp के विरुद्ध कोई समस्या खोलें।

क्या वॉल्यूम फ़्लायआउट के भीतर स्लाइडर को भी स्टाइल किया जाएगा

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

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

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

क्या ColourPicker में उपयोग किए गए स्लाइडर को MediaPlayer के समान आउटलाइन शैली से लाभ होगा - ताकि यह बार के गहरे रंगों के बीच खो न जाए?

MediaPlayer को नए स्लाइडर (#841) के डिज़ाइन का अनुसरण करने की योजना बनाई जा रही है। तो आप जो प्रस्ताव दे रहे हैं वह योजना में नहीं है। अगर आपको लगता है कि यह एक उपयोगिता समस्या है, तो कृपया एक अलग मुद्दा खोलें।

वाह! यहां बहुत सारी टिप्पणियां हैं।

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

@Poopooracoocoo नए कार्यालय चिह्न/लोगो गोलाकार कोनों का उपयोग करते हैं, जैसा कि नया टर्मिनल आइकन और नया दृश्य स्टूडियो आइकन/लोगो करता है।

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

@Poopooracoocoo , @mdtauk ,
आपकी प्रतिक्रिया के लिए आपका धन्यवाद। आप दोनों सही हैं कि परिवर्तन पूरे मंडल में लागू होना चाहिए। इस प्रकार यह प्रयास फैब्रिक और एज जैसे अन्य दृश्यमान UI के साथ संरेखण शुरू कर रहा है। हम चाहते हैं कि निरंतरता रातोंरात बनी रहे, लेकिन यह एक यात्रा है। और यह यहाँ खेलने पर UI प्लेटफ़ॉर्म के डिफ़ॉल्ट मान से शुरू होता है (यानी WinUI)।

स्थिति अपडेट:

कॉर्नर रेडियस (उर्फ राउंडेड कॉर्नर) हाउ-टू डॉक्यूमेंट पीआर बनाया जाता है।

इसे दस्तावेज़ के रूप में docs.microsoft.com में जोड़ा जाएगा।
यह https://docs.microsoft.com/en-us/windows/uwp/design/style/ के अंतर्गत एक नया पेज होगा

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

क्या वे अतिरिक्त जानकारी उपयोगी/सहायक हैं, प्रासंगिक नहीं हैं, अन्य जानकारी गायब हैं, आदि?

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

@mdtauk , अच्छी पकड़। मेरे पास "टूडू" खंड (सिद्धांत) था जो इसे पकड़ता है, लेकिन किसी तरह संपादन के दौरान, संदर्भ खो गया। मैं अभी भी उस सेक्शन को भरने के लिए काम कर रहा हूं।

स्थिति अपडेट

सूची और ग्रिड व्यू (# 1096) के अंदर चेकबॉक्स के कोने को गोल करने के लिए काम को ट्रैक करने के लिए एक अलग मुद्दा बनाया गया

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

@mdtauk

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

केवल अभी उत्तर देने के लिए खेद है। वे वास्तव में टाइल्स से छुटकारा पा रहे हैं! :(

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

Office चिह्न स्वयं Word या PowerPoint के चिह्नों की तरह नहीं दिखता है। इन परिवर्तनों के साथ, मुझे लगता है कि Microsoft अपनी पहचान खो रहा है

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

@Poopooracoocoo और @mdtauk , कृपया टाइल चर्चा के लिए फीडबैक हब पर फीडबैक सबमिट करें क्योंकि WinUI टीम की टाइल्स में कोई भागीदारी नहीं है और न ही योजनाओं का कोई ज्ञान है।

@Poopooracoocoo और @mdtauk , कृपया टाइल चर्चा के लिए फीडबैक हब पर फीडबैक सबमिट करें क्योंकि WinUI टीम की टाइल्स में कोई भागीदारी नहीं है और न ही योजनाओं का कोई ज्ञान है।

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

हैलो, राउंडिंग को कैसे निष्क्रिय करें? गोल बटन में गोल टूलटिप होने पर यह बदसूरत लग रहा है।

@kikisaints @chigy क्या गोल कोने को अक्षम करने का कोई तरीका है कि @mklemarczyk जैसे विशिष्ट तत्व के लिए पूछ रहा है?

हैलो, राउंडिंग को कैसे निष्क्रिय करें? गोल बटन में गोल टूलटिप होने पर यह बदसूरत लग रहा है।

@mklemarczyk क्या आपने नियंत्रण शैली में CornerRadius मान को 0 पर सेट करने का प्रयास किया है? सभी टूलटिप नियंत्रणों को प्रभावित करने के लिए आपको इसे App.xaml में करना पड़ सकता है।

@kikisaints @chigy क्या गोल कोने को अक्षम करने का कोई तरीका है कि @mklemarczyk जैसे विशिष्ट तत्व के लिए पूछ रहा है?

@mklemarczyk , क्या आपने हमारा मार्गदर्शन डॉक्टर देखा है?
https://docs.microsoft.com/en-us/windows/uwp/design/style/rounded-corner#page -or-app-wide-cornerradius-changes

@mklemarczyk टूलटिप नियंत्रण के कोने त्रिज्या को बदलने के लिए आप दो विकल्पों के रूप में ToolTip.CornerRadius संपत्ति या

Control.CornerRadius संपत्ति विंडोज 1809 से उपलब्ध है और आप इसे इस तरह उपयोग कर सकते हैं:

<Application.Resources>
    <Style TargetType="ToolTip">
        <Setter Property="CornerRadius" Value="0" />
    </Style>
</Application.Resources>

यह ऐप में हर टूलटिप के लिए कॉर्नर रेडियस को 0 पर सेट करता है।

वैकल्पिक रूप से, आप उपयोग कर सकते हैं

<Application.Resources>
    <CornerRadius x:Key="OverlayCornerRadius">0</CornerRadius>
</Application.Resources>

सावधान रहें कि यह न केवल टूलटिप नियंत्रणों के कोने के दायरे को ऐप-वाइड बल्कि अन्य सभी नियंत्रणों को भी सेट करता है जो इस संसाधन का उपयोग करते हैं (जैसे ContentDialog और कॉम्बोबॉक्स जैसे उपभोग करने वाले पॉपअप को नियंत्रित करता है)। यानी ... सिद्धांत रूप में संसाधन को ओवरराइड करने से इन नियंत्रणों को प्रभावित नहीं होता है, भले ही इसे (टूलटिप काम करता है)।

आगे-पीछे इतना कुछ है कि यह जानना मुश्किल है कि अन्य इनपुट और कॉर्नर रेडियस के संबंध में क्या निर्णय लिया गया था, लेकिन बहुत जल्दी, WinUI 3 का उपयोग करने के लिए UWP प्रोजेक्ट को माइग्रेट करने के बाद विशेष रूप से मैंने देखा कि केवल बटनों में एक कॉर्नर रेडियस लगाया गया था। (अन्य परिवर्तनों जैसे एन्हांस्ड रिवील इत्यादि के साथ) लेकिन मेरे अन्य इनपुट नियंत्रण (जैसे कम्बोबॉक्स) मेट्रो लुक (गहरा/मोटा सीमा और 90 डिग्री कोण) के साथ छोड़े गए थे। क्या यह जानबूझकर, एक WIP, या एक बग है? साथ ही, बटनों से मिलान करने के लिए कम्बोबॉक्स प्राप्त करने के लिए मुझे 3epx के कोने त्रिज्या का उपयोग करने की आवश्यकता है, हालांकि जो कुछ भी मैं ऑनलाइन देख रहा हूं वह कहता है कि नया डिफ़ॉल्ट कोने त्रिज्या 4epx है?

आगे-पीछे इतना कुछ है कि यह जानना मुश्किल है कि अन्य इनपुट और कॉर्नर रेडियस के संबंध में क्या निर्णय लिया गया था, लेकिन बहुत जल्दी, WinUI 3 का उपयोग करने के लिए UWP प्रोजेक्ट को माइग्रेट करने के बाद विशेष रूप से मैंने देखा कि केवल बटनों में एक कॉर्नर रेडियस लगाया गया था। (अन्य परिवर्तनों जैसे एन्हांस्ड रिवील इत्यादि के साथ) लेकिन मेरे अन्य इनपुट नियंत्रण (जैसे कम्बोबॉक्स) मेट्रो लुक (गहरा/मोटा सीमा और 90 डिग्री कोण) के साथ छोड़े गए थे। क्या यह जानबूझकर, एक WIP, या एक बग है? साथ ही, बटनों से मिलान करने के लिए कम्बोबॉक्स प्राप्त करने के लिए मुझे 3epx के कोने त्रिज्या का उपयोग करने की आवश्यकता है, हालांकि मैं जो कुछ भी ऑनलाइन देख रहा हूं _says_ कि नया डिफ़ॉल्ट कोने त्रिज्या 4epx है?

यदि आप शैलियों के संबंध में WinUI2 और WinUI3 के बीच अंतर देख रहे हैं, तो क्या आप कृपया एक नया मुद्दा खोल सकते हैं? WinUI2 से WinUI3 में शैलियों के विलय के संबंध में यह एक बग हो सकता है।