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

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

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

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

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

पुन:: किसी आइटम की स्थिति को बनाए रखना क्योंकि अन्य सामग्री को जोड़ा / हटाया जाता है या आकार में परिवर्तन होता है... पूरी तरह से सहमत हैं कि कुछ भी नहीं करना काफी अच्छा नहीं है। यही कारण है कि स्क्रॉल एंकरिंग सुविधा मौजूद है। :) यह एक अल्पज्ञात क्षमता है कि अतीत में ListView/GridView के वर्चुअलाइजिंग पैनल में अंतर्निहित किया गया है। हाल के रिलीज में हम इस तरह की चीजों को केवल ListView में उपलब्ध होने से अलग करने का एक स्पष्ट प्रयास कर रहे हैं।

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

जैसे ही XAML MR ऐप्स के लिए 3D अभ्यावेदन में आगे बढ़ता है, और जैसे-जैसे गहराई और छाया 2D XAML में आते हैं - स्क्रॉलिंग विभिन्न गहराई मानों की वस्तुओं को कैसे स्थानांतरित करेगी, कैसे छाया स्क्रॉल संकेतकों के ऊपर या पीछे प्रस्तुत हो सकती है, और अन्य मुद्दे जो क्रॉप हो सकते हैं XAML टीम के 3D प्रयोगों में - जो नया डिफ़ॉल्ट बन सकता है, उसमें बनाया जा सकता है, क्योंकि Windows UI लाइब्रेरी धीरे-धीरे नया डिफ़ॉल्ट बन जाता है।

मेरे दिमाग में, स्क्रॉल की जा सकने वाली सामग्री और ज़ूम की जा सकने वाली सामग्री की आवश्यकता बहुत अलग है।

वेब ब्राउज़र, ग्राफ़िक्स डिज़ाइन ऐप्स, ऑफ़िस ऐप्स, PDF व्यूअर को छोड़कर..... कुछ भी जो सामग्री दस्तावेज़ दिखाता है।

@mrlacey से सहमत हैं कि एक विशिष्ट तत्व को ध्यान में

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

ज़ूमिंग की खोज योग्यता को संबोधित करने के लिए एक अलग (व्युत्पन्न) नियंत्रण शुरू करने के बजाय मेरा मानना ​​​​है कि सही दस्तावेज/नमूने अधिक प्रभावी हो सकते हैं।

व्यवहार या संदर्भ एनम जोड़ने के बारे में क्या?

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.Scroll;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.ParallaxScroll;

हालांकि ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; बहुत भ्रमित करने वाला है। मुझे लगता है कि ZoomMode जैसा है वैसा ही रहना चाहिए।

हालांकि ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; बहुत भ्रमित करने वाला है। मुझे लगता है कि ZoomMode जैसा है वैसा ही रहना चाहिए।

मुझे शायद सुझाव को उन टिप्पणियों को संबोधित करने के रूप में प्रस्तुत करना चाहिए था जो सोचते हैं कि स्क्रॉलिंग के बजाय ज़ूमिंग सामग्री के लिए व्युत्पन्न नियंत्रण होना चाहिए

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

@micahl , मैं ज़ूमिंग के साथ मानता हूं और

समर्थन रोटेशन इशारों

इस परिदृश्य को भविष्य में मूल रूप से समर्थित किया जाएगा?

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

यदि ज़ूमिंग और स्क्रॉलिंग पर अधिक नियंत्रण रखने की आवश्यकता है...

ScrollViewer.ScrollBehaviour = ScrollBehaviour.ZoomAndScroll;

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

माइक्रोसॉफ्ट वर्ड यूआई पर नजर डालें तो स्टेटस बार में जूम कंट्रोल होता है। और दस्तावेज़ क्षेत्र के लिए स्क्रॉलबार।

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

@JustinXinLiu सपोर्टिंग रोटेशन जेस्चर को इंटरेक्शनट्रैकर (@likuba) से सपोर्ट की जरूरत होगी।

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

@micahl मुझे समझ में नहीं आता कि स्क्रॉलफ्रॉम को इस तरह क्यों कहा जाता है। क्या यह सिर्फ स्क्रॉलबी की तरह नहीं है बल्कि एक वेग पैरामीटर के साथ है?

@adrientetar क्या आप पूछ रहे हैं कि स्क्रॉल के नामकरण के बजाय पैरामीटर के एक अलग सेट के साथ स्क्रॉलबी का एक और अधिभार क्यों नहीं है?

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

ये सही है। हमारे मन में 3 स्थितियां थीं:

1. मुझे परवाह नहीं है कि मेरी वर्तमान स्थिति क्या है। मैं एक विशिष्ट गंतव्य पर स्क्रॉल/ज़ूम करना चाहता हूं।
2. मुझे परवाह है कि मेरी वर्तमान स्थिति क्या है और मैं उस स्थिति के सापेक्ष एक विशिष्ट राशि से स्क्रॉल/ज़ूम करना चाहता हूं।
3. मुझे परवाह नहीं है कि अंतिम गंतव्य क्या है। मैं बस अपनी वर्तमान स्थिति से स्क्रॉल/ज़ूम करना चाहता हूं।

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

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

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

@lhak , आप उन मूल्यों को

@micahl मुझे पूरा यकीन है कि मैंने उन मूल्यों का उपयोग अतीत में भी कुछ गणनाओं के लिए किया है। यकीन नहीं होता कि मैं उनसे बंधा हूं।

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

मैं वर्तमान में अपने आवेदन में निम्नलिखित के समान कुछ कोड का उपयोग करता हूं:

<ScrollViewer x:Name="outputScrollViewer">
  <Viewbox MaxWidth="{x:Bind outputScrollViewer.ViewportWidth, Mode=OneWay}" MaxHeight="{x:Bind outputScrollViewer.ViewportHeight, Mode=OneWay}">
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

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

@ ल्हाक , अच्छा परिदृश्य! वर्तमान प्रस्ताव में इस परिदृश्य को कैसे समायोजित किया जा सकता है, इस पर ज़ोर से विचार करना... मुझे लगता है कि हम ContentOrientation संपत्ति के लिए एक और विकल्प जोड़ सकते हैं। प्रस्ताव में मौजूदा विकल्प:

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

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

<ScrollViewer ContentOrientation="Viewport">
  <Image Stretch="Uniform" .../>
</ScrollViewer>

अधिक जटिल सामग्री के लिए आप इसे व्यूबॉक्स में लपेट सकते हैं और फिर भी बाइंडिंग को छोड़ सकते हैं।

<ScrollViewer ContentOrientation="Viewport">
  <Viewbox>
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

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

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

यदि वह काम नहीं करता है, तो आप IgnoredInputKind="Mousewheel" सेट करके इसे स्वयं संभालने का प्रयास करने के लिए वापस आ सकते हैं और फिर या तो स्क्रॉलर को उप-वर्गीकरण करके OnPointerWheelChanged को ओवरराइड कर सकते हैं, या स्क्रोलर पर पॉइंटरव्हील चेंज किए गए ईवेंट के लिए ईवेंट हैंडलर जोड़ सकते हैं।

@ माइकल धन्यवाद! मुझे यकीन नहीं है कि आपने किस परिदृश्य के खिलाफ माउस व्हील व्यवहार को कैलिब्रेट किया है, व्यक्तिगत रूप से मुझे जिस तरह से एडोब एक्सडी में पसंद है: ऐसा लगता है कि यह एक त्वरित एनीमेशन है लेकिन यह तेज़ है और इसमें पर्याप्त ज़ूम वृद्धि है। स्क्रॉलर माउस व्हील जूम एनीमेशन थोड़ा सुस्त लगता है और इसमें वास्तव में छोटे जूम इंक्रीमेंट imo हैं।

@adrientetar , अच्छी प्रतिक्रिया। हम इसे समायोजित करने पर विचार कर सकते हैं।

किसी भी प्रकार का चर जो वृद्धि और मूल्यों को नियंत्रित करता है - को अतिरेक गुणों में बनाया जा सकता है

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

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

तो वर्तमान ज़ूमिंग व्यवहार को इंटरेक्शनट्रैकर में बेक किया गया है, इसे ओवरराइड करने का कोई तरीका नहीं है? और मुझे लगता है कि अब इसे बदलने का कोई तरीका नहीं है क्योंकि यह पीछे की ओर-संगतता को तोड़ देगा cc @likuba

मुझे लगता है कि इंटरेक्शनट्रैकर पर कुछ विकल्प हैं जो यहां मदद कर सकते हैं । विशेष रूप से, हमने इस प्रकार के अनुकूलन को सक्षम करने के लिए PointerWheelConfig और DeltaScaleModifier जैसी सुविधाओं का निर्माण किया। हम समन्वयन करने जा रहे हैं और देखेंगे कि क्या नियंत्रण में इनका उपयोग करने से आपके द्वारा ऊपर उल्लिखित समस्याओं/जोखिमों के बिना यहां कुछ हो सकता है।

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

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

हाय @stefangavrilasengage , दिलचस्प परिदृश्य। :) आपके PoC से, जब एक इंककैनवास पर एक उंगली नीचे जाती है और फिर हिलना शुरू हो जाती है, तो अपेक्षित व्यवहार क्या होता है? क्या यह खींचता है या पैन करता है?

हाय वहाँ @micahl - उत्तर देने के लिए धन्यवाद! मुझे लगता है कि अब तक आपने अनुमान लगा लिया होगा कि यह एक डिजिटल व्हाइटबोर्डिंग ऐप जैसा कुछ है।
अब मैं प्रस्तुत करूंगा कि वर्तमान में क्या होता है:

• स्क्रॉलव्यूअर (डिफ़ॉल्ट): एक इंककैनवास पर एक उंगली खींचना ठीक है। दूसरी उंगली पहली इंककैनवास को इनपुट खो देती है।
• स्क्रॉलव्यूअरएक्स (कस्टम नियंत्रण): आकर्षित करने के लिए कई उंगलियों और कई इंक कैनवास का उपयोग करें और यह काम करता है।

क्या यह मदद करता है? :)
शुक्रिया !

@stefangavrilasengage मैं पूछ रहा था कि क्या एक स्पर्श इशारा पैन (स्क्रॉलव्यूअर के लिए डिफ़ॉल्ट व्यवहार) या स्याही खींचता है या नहीं। वहां एक अंतर्निहित संघर्ष है। आप इसे कैसे हल करते हैं? मानचित्र की तरह स्क्रॉल करने के लिए दो अंगुलियों की आवश्यकता है? संपादन मोड में प्रवेश करने/छोड़ने के लिए संपादन बटन का उपयोग करें? आदि...

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

धन्यवाद !

यह विश्वास करना मुश्किल है कि यह पहली बार है कि @micahl और मैं एक

यह विश्वास करना मुश्किल है कि यह पहली बार है कि @micahl और मैं एक

उसके लिए माफ़ करना ! संपादित!

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

@stefangavrilasengage , यह पता लगाना कि यह काम क्यों नहीं करता है, इसमें कुछ समय/जांच लगेगा। आइए इसे इस प्रस्ताव से अलग से ट्रैक करें। क्या आप इसके लिए कोई मुद्दा खोलेंगे?

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

चीजों को आजमाने के लिए धन्यवाद, @adrientetar! आइए इस सूत्र को प्रस्ताव पर केंद्रित रखें। आप जो देख रहे हैं उसके लिए क्या आप एक अलग मुद्दा खोल सकते हैं? इस बात पर निर्भर करते हुए कि हम उस चर्चा पर कहां से निकलते हैं, हम इस विषय पर चर्चा करने के लिए वापस लौट सकते हैं कि क्या यह प्रस्ताव में बदलाव की गारंटी देता है।

@micahl क्यों ExtentChanged/StateChanged/ViewChanged ईवेंट में ऑब्जेक्ट उनके तर्क के रूप में है और उदाहरण के लिए StateChangedEventArgs राज्य के सदस्य के साथ नहीं है? यह देखते हुए कि इंटरेक्शनट्रैकर एक अलग थ्रेड पर चलता है, क्या संदेश पासिंग पैटर्न (तर्क के साथ घटना) ईवेंट हैंडलर में नियंत्रण संपत्ति से पूछताछ करना पसंद नहीं करता है?

https://github.com/XeorgeXeorge/Extended-Image-Viewer

बहुत बड़ी बात नहीं है, लेकिन इस रेपो का पहला भाग दिखाता है कि क्षैतिज/ऊर्ध्वाधर स्क्रॉलबार लॉक (अक्षम) होने पर भी ज़ूमिंग को कैसे कार्यान्वित किया जाए,

सरल शब्दों में:
ज़ूम इन सामग्री पर पैन करने की अनुमति देता है, जबकि अभी भी to . को फ़िट करने के लिए मजबूर करता है
प्रभावी लंबवत/क्षैतिज व्यूपोर्ट।

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

@micahl मैं देखता हूं कि गैर-एनिमेटेड ज़ूम करते समय स्क्रॉलर स्टेट चेंजेड ईवेंट नहीं भेजता है, क्या यह डिज़ाइन द्वारा है?
जब स्क्रॉलर निष्क्रिय हो जाता है, तो मैं अपना कैनवास वर्चुअल कंट्रोल स्केलिंग सेट करता हूं, जैसा कि आपने https://github.com/microsoft/microsoft-ui-xaml/issues/541#issuecomment -488749469 में सुझाव दिया था, जैसे कि नियंत्रण बहुत बड़े रैस्टराइज़िंग को समाप्त नहीं करता है ज़ूम फ़ैक्टर के सापेक्ष कैनवास के भाग। लेकिन एक गैर-एनिमेटेड ज़ूम के साथ, मुझे ऐसा करने की ज़रूरत है जब मैं ज़ूमटो विधि को कॉल करता हूं, भले ही ज़ूम परिवर्तन को महसूस नहीं किया गया हो (afaact)।

@adrientetar , ढांचे और ऐप के बीच आगे और पीछे जाने के लिए ईवेंट

हां, वर्तमान डिजाइन यह है कि एक गैर-एनिमेटेड ज़ूम में आप प्रोग्रामेटिक रूप से आह्वान करते हैं कि StateChanged आग नहीं लगाता है। ज़ूम पूर्ण और स्क्रॉल पूर्ण ईवेंट प्रोग्रामेटिक परिवर्तनों के जवाब में उठाया जाएगा। IIRC वे उपयोगकर्ता के परिवर्तनों से ट्रिगर नहीं होते हैं। आप उनमें से किसी एक का उपयोग कर सकते हैं, शायद StateChanged के संयोजन में। fyi के रूप में, ViewChanged ईवेंट कभी भी दृश्य परिवर्तन (उपयोगकर्ता या प्रोग्रामेटिक) उठाया जाता है जो इसे एक बहुत ही संवेदनशील संवेदनशील कोड पथ बनाता है और वह नहीं है जिसे आप उपयोग करना चाहते हैं।

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

हां, वर्तमान डिजाइन यह है कि एक गैर-एनिमेटेड ज़ूम में आप प्रोग्रामेटिक रूप से आह्वान करते हैं कि StateChanged आग नहीं लगाता है।

आह ठीक है, मैं अब समझता हूँ। हो सकता है कि घटना हमेशा आग लग सकती है और इसमें मूल पैरामीटर हो सकता है, जैसे सेटफोकस, लेकिन हो सकता है कि ऐसा करने के लिए कुछ ओवरहेड हो।

ज़ूम पूर्ण और स्क्रॉल पूर्ण ईवेंट प्रोग्रामेटिक परिवर्तनों के जवाब में उठाया जाएगा। IIRC वे उपयोगकर्ता के परिवर्तनों से ट्रिगर नहीं होते हैं।

ठीक है, तो मेरे उपयोग-मामले के लिए मुझे ज़ूम पूर्ण और स्टेट चेंजेड iff State == Idle को संभालना है, इस पर निर्भर करता है कि परिवर्तन प्रोग्रामेटिक है या नहीं। क्या यह अजीब नहीं है? मेरा मतलब है, एक ही चीज़ के लिए अलग-अलग नामों के साथ अलग-अलग घटनाओं का होना केवल एक अलग तरीके से शुरू होता है

@RBrid और मैंने एक नया राज्य "संक्रमण" शुरू करने और कुछ मामूली नाम

जिस विचार पर चर्चा की गई वह यह था कि जब स्क्रॉल/ज़ूम की स्थिति में बदलाव किया जाने वाला होता है (चाहे उपयोगकर्ता द्वारा शुरू किया गया हो या प्रोग्रामेटिक हो) तो हम StateChanged ईवेंट को बढ़ाएंगे और वर्तमान स्थिति को ट्रांज़िशनिंग के रूप में रिपोर्ट करेंगे। प्रोग्रामेटिक स्क्रॉल (एनिमेटेड और एनिमेटेड नहीं) के लिए अनुक्रम कैसा दिखेगा:

// प्रोग्रामेटिक अनुरोध, एनिमेटेड
myScrollInfo = स्क्रॉलटो (100, चेतन = सत्य);
// कुछ टिक
StateChanged उठाया गया (Scroller.State == Transitioning)
// कुछ टिक
StateChanged उठाया (Scroller.State == एनिमेटिंग)
// कई टिक
StateChanged उठाया (Scroller.State == Idling)

// प्रोग्रामेटिक अनुरोध, कोई एनीमेशन नहीं
myScrollInfo = स्क्रॉलटो (100, चेतन = झूठा);
// कुछ टिक
StateChanged उठाया (Scroller.State == Transitioning)
// कुछ टिक
StateChanged उठाया (Scroller.State == Idling)

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

enum ScrollState
{
    Idling = 0,
    Transitioning = 1,
    Interacting = 2,
    Inertial = 3,
    Animating = 4,
};

@micahl हाँ, यह बहुत कुछ वैसा ही दिखता है जैसा मैं उम्मीद करता हूँ! कोई व्यक्ति जो केवल एनिमेटेड परिवर्तनों को संभालना चाहता है, वह एनिमेटिंग स्थिति को रोक सकता है। नामों के लिए, मैं आइडल नॉट आइडलिंग ("स्क्रॉलर आइडल है"/"स्क्रॉलर एनिमेटिंग है"), ट्रांज़िशनिंग → स्टिरिंग? (संक्रमण बहुत भ्रमित करने वाला है, मैं इसके बजाय यह बताना चाहूंगा कि यह गति की शुरुआत में है इसलिए इमो सरगर्मी बेहतर काम कर सकती है), जड़त्वीय बहती हो सकती है लेकिन मुझे लगता है कि एपीआई समीक्षा भी इसमें शामिल होगी।

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

ठंडा ठंडा। लंबित sgtm, imo अज्ञात संक्रमण से भी अधिक भ्रमित करने वाला है।

@micahl - कार्यात्मक आवश्यकता संख्या 3 में यह बिंदु शामिल है:

प्रभावी व्यूपोर्ट परिवर्तनों में भाग लेता है (जरूरी)

वह उप-बिंदु पहले से मौजूद घटना FrameworkElement.EffectiveViewportChanged को संदर्भित करता है। क्या वह उप - बिंदु यह कहने के लिए पर्याप्त है (अप्रत्यक्ष रूप से) कि

• दस्तावेज़ की जटिलता (वेक्टर तत्वों की मात्रा, प्रभाव, आदि), दस्तावेज़ के आकार और ज़ूम प्रतिशत के आधार पर इस रेंडरिंग कार्य (उच्च ज़ूम प्रतिशत पर) के लिए लगभग 3 .. 20 सेकंड की आवश्यकता होती है। अंतिम उपयोगकर्ताओं को स्वीकार करने के लिए यह देरी बहुत अधिक है।
• संपूर्ण PDF पृष्ठ की एक प्रदान की गई छवि (बिटमैप) ज़ूम प्रतिशत अधिक होने पर सैकड़ों मेगाबाइट RAM की खपत कर सकती है, क्योंकि यह बहुत उच्च DPI पर रेंडर करने के बराबर है।

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

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

क्या जूमिंग से संबंधित एपीआई को एक व्युत्पन्न नियंत्रण (जैसे ज़ूमव्यूअर) में अलग किया जाना चाहिए ताकि स्क्रॉलव्यूअर सख्ती से स्क्रॉल करने के बारे में हो?

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

1. शायद ZoomViewer नामक एक वर्ग जो ScrollViewer उत्तराधिकारी नहीं है, लेकिन ScrollViewer उदाहरण का उपयोग बाल तत्व के रूप में करता है (इसके ControlTemplate )।
2. शायद ZoomableScrollViewer नाम का एक वर्ग जो विरासत में मिला है ScrollViewer ।
3. ScrollViewer भीतर सीधे ज़ूम का समर्थन करना, अगर यह अत्यधिक जटिल या गन्दा नहीं है।

17 माउस मध्य क्लिक और स्क्रॉल का समर्थन करने के लिए एक डिफ़ॉल्ट यूएक्स प्रदान करें। (चाहिए)
18 माउस के माध्यम से क्लिक करने और पैन करने के लिए एक मोड का समर्थन करें (उदाहरण के लिए पीडीएफ व्यूअर के अंदर सामग्री ले जाना)। (चाहिए)

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

4 इनपुट-संचालित एनिमेशन करने में सक्षम

नंबर 4 एक एक्सेसिबिलिटी से संबंधित मुद्दा है। मैं अनुरोध करना चाहता हूं कि स्क्रॉलव्यूअर (और WinUI में अन्य सभी नियंत्रण) एक्सेसिबिलिटी सेटिंग्स का सम्मान करें:

विंडोज 10 -> स्टार्ट -> सेटिंग्स -> एक्सेस में आसानी -> डिस्प्ले -> विंडोज़ में एनिमेशन दिखाएं (चालू या बंद)।

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

हाय @verelpode , @predavid नए चलाएगा , इसलिए मैं उसे टाल दूंगा।

17 माउस मध्य क्लिक और स्क्रॉल का समर्थन करने के लिए एक डिफ़ॉल्ट यूएक्स प्रदान करें। (चाहिए)
18 माउस के माध्यम से क्लिक करने और पैन करने के लिए एक मोड का समर्थन करें (उदाहरण के लिए पीडीएफ व्यूअर के अंदर सामग्री ले जाना)। (चाहिए)

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

@verelpode मुझे लगता है कि आप 17 को सही ढंग से समझते हैं और मैं मानता हूं कि 18 अधिक महत्वपूर्ण है और आमतौर पर 17 से अधिक सहज है। लेकिन ऐसे परिदृश्य हो सकते हैं जहां "बाएं क्लिक और ड्रैग" पहले से ही अन्य उद्देश्यों के लिए उपयोग किया जाता है, जैसे चयन, या ड्रैग + ड्रॉप . ऐसे परिदृश्यों के लिए, यह अच्छा होगा यदि ऐप मध्य क्लिक (17) के माध्यम से स्क्रॉलिंग को सक्षम कर सके।

मैं व्यक्तिगत रूप से समय-समय पर ब्राउज़र में मध्य क्लिक स्क्रॉलिंग का उपयोग करता हूं, जहां बाएं क्लिक + ड्रैग या तो टेक्स्ट चयन या छवियों के ड्रैग + ड्रॉप का कारण बनता है। एक UWP ब्राउज़र में 18 अक्षम और 17 सक्षम होंगे। दोनों को अलग-अलग संपत्तियों के माध्यम से ऑप्ट-इन किया जाना चाहिए।

@lukasf

मैं व्यक्तिगत रूप से समय-समय पर ब्राउज़र में मध्य क्लिक स्क्रॉलिंग का उपयोग करता हूं, जहां बाएं क्लिक + ड्रैग या तो टेक्स्ट चयन या छवियों के ड्रैग + ड्रॉप का कारण बनता है।

पाठ चयन आदि को काम करना बंद करने से बचने की आवश्यकता अच्छी बात है। आप इस संभावित समाधान के बारे में क्या सोचते हैं: अजीब 17 मोड शुरू करने के बजाय माउस-आधारित पैनिंग मोड (18) को मध्य-क्लिक करें।

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

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

@verelpode
सभी ब्राउज़रों के साथ और अन्य एप्लिकेशन (Word, Adobe Reader, Outlook,...) सपोर्टिंग मोड 17 के साथ, मुझे अभी भी लगता है कि इसे लागू किया जाना चाहिए। सिर्फ इसलिए कि आप व्यक्तिगत रूप से इसे अजीब पाते हैं इसका मतलब यह नहीं है कि यह अन्य लोगों के लिए उपयोगी नहीं है। बेशक दोनों मोड ऑप्ट-इन होने चाहिए, फिर देव तय कर सकते हैं कि उनके ऐप में क्या इस्तेमाल किया जाएगा। यह आपके स्पेसबार + क्लिक व्यवहार को भी अनुमति देगा, अगर यह किसी ऐप के लिए समझ में आता है: स्पेसबार डाउन पर मोड 18 सक्षम करें, इसे स्पेसबार अप पर फिर से अक्षम करें।

@lukasf - ठीक है, अच्छा लगता है। मैंने सोचा था कि आपका मतलब है कि यदि पैनिंग मोड (18) टेक्स्ट चयन या छवियों के ड्रैग + ड्रॉप आदि को नहीं रोकता है, तो आप मोड 17 का उपयोग करना बंद कर देंगे और 18 पर स्विच कर देंगे, लेकिन अब मैं देख रहा हूं कि आपकी वरीयता वास्तव में दोनों मोड के लिए है समर्थित हो।

आपकी प्रतिक्रिया के लिए धन्यवाद @verelpode और @lukasf , मैं

मैंने अभी कुछ खोजी कार्यों को जोड़ने के लिए एक पीआर https://github.com/microsoft/microsoft-ui-xaml/pull/1472 भेजा है। मैं देखना चाहता था कि आज के स्क्रोलर का उपयोग करके मैं 17 और 18 दोनों का समर्थन करने के कितने करीब पहुंच सकता हूं।

18 = माउस-आधारित पैनिंग के लिए चीजें बहुत अच्छी तरह से चली गईं, हालांकि समाधान 100% यूआई-थ्रेड-बाउंड है, स्पर्श-आधारित या माउस-व्हील-आधारित अनुभवों के विपरीत। मैंने माउस के पॉइंटरमोव किए गए ईवेंट को सुनते समय स्क्रॉलटो विधि का उपयोग किया। अंतत: हम चाहते हैं कि अंतर्निहित इंटरेक्शनट्रैकर घटक माउस चालों को संभाले जैसे कि यह उंगली की चाल के साथ करता है।

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

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

@आरबीआरआईडी

18=माउस-आधारित पैनिंग के लिए चीजें बहुत अच्छी रहीं, ……
17 = माउस-आधारित निरंतर-वेग-पैनिंग (एक ऐसा अनुभव जिसे मैं व्यक्तिगत रूप से नापसंद करता हूं) के लिए चीजें बहुत कठिन हैं।

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

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

@verelpode दोनों मोड "चाहिए" के रूप में सेट हैं। इसलिए यदि मोड 17 का एहसास करने के लिए प्रयास बहुत अधिक है, तो इसे छोड़ दिया जा सकता है (और यदि आवश्यक हो तो बाद में जोड़ा जा सकता है)। लेकिन हो सकता है कि किसी को बहुत अधिक बदलावों के बिना इसे महसूस करने का कोई तरीका मिल जाए।

मुझे उम्मीद है कि नए स्क्रॉलव्यूअर में "Ctrl" कुंजी के साथ ज़ूम को अक्षम या अनुकूलित करने की क्षमता है।