मुझे सच में लगता है कि इस पर फिर से विचार किया जाना चाहिए। VM और TM दोनों इसके विपरीत व्यवहार करते हैं। किसी स्क्रिप्ट पर नेविगेट करते समय आपको एक ऐसा पृष्ठ प्रस्तुत किया जाता है जिसमें स्क्रिप्ट सामग्री/स्रोत और स्थापना बटन दोनों शामिल होते हैं। जब आप तकनीकी रूप से 'पुनर्निर्देशित' होते हैं, तब भी आप संक्षेप में, उपयोगकर्ता स्क्रिप्ट पर 'नेविगेट' कर रहे हैं। शायद इसे -users और -dev मेलिंग सूची में लाया जाना चाहिए और दूसरों की राय देखना चाहिए?

मैं सामुदायिक चर्चा का समर्थन करता हूं।

व्यक्तिगत रूप से मेरी राय है कि ~कोई भी स्रोत की समीक्षा नहीं करता है, इसलिए इसे सभी उपयोगकर्ताओं को दिखाना एक मूर्खतापूर्ण बात है, जिसमें बहुमत भी शामिल है जो इसे समझ भी नहीं सकते हैं।

और: केवल मुख्य स्रोत की समीक्षा करना, जब कोई @require , तो बहुत कम होता है।

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

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

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

जैसा कि उल्लेख किया गया है, मैं समीक्षा-क्षमता को भी महत्व देता हूं। अल्पसंख्यक लोगों के लिए जो इसे चाहते हैं। मैं चाहता हूं कि यह #2567 की तरह काम करे ताकि आप स्रोत के _all_ की समीक्षा कर सकें। आप बस इंस्टॉल करने के बाद संपादित करें पर क्लिक करें, और सभी स्रोत और टेक्स्ट संसाधन दृश्यमान हों। अपनी पसंद के अनुसार सक्षम या अनइंस्टॉल करें।

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

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

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

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

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

अगर कोई अतिरिक्त अनुरोधों के बिना ऐसा करने का एक साफ तरीका लेकर आ सकता है, तो बढ़िया। अन्यथा, मैं _actual_ लाभों के बिना इसके पीछे नहीं जा सकता। [1]

[1] आपने संभावित लाभ के रूप में #2567 के कारण "स्रोत कोड के _all_ की समीक्षा करने में सक्षम होने" का उल्लेख किया है। लेकिन मैं असहमत हूं। मुझे ऐसा लगता है कि #2567 एक विशेषता होनी चाहिए _भले ही_ स्थापित होने पर स्रोत कोड उपलब्ध हो या नहीं।

मुझे नहीं पता। अन्य विषयों पर मैं कुछ चर्चा के बाद आने में सक्षम हुआ हूं। लेकिन यह वह है जिसे मैं सिर्फ "देख नहीं रहा हूं।"

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

मुझे नहीं लगता कि *.user.js नामक चीज़ों को देखना तोड़ना कोई अर्थ नहीं है। यह ब्राउज़र कार्यक्षमता को हटा रहा है।

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

मुझे नहीं लगता कि *.user.js नामक चीज़ों को देखना तोड़ देना उचित है। यह ब्राउज़र कार्यक्षमता को हटा रहा है।

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

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

मैं इस तर्क से असहमत हूं। एक एक्सटेंशन फाइलों का एक संग्रहीत पैकेज है। एक उपयोगकर्ता स्क्रिप्ट नहीं है। आप @requires और @resources बारे में तर्क दे सकते हैं लेकिन मुझे लगता है कि यह कठिन है। उनमें से सभी उनका उपयोग नहीं करते हैं और उनमें से बहुत सारे केवल सादा पाठ हैं। जब आप एक कच्चे टेक्स्ट पेज पर नेविगेट करते हैं तो आप आम तौर पर होते हैं (यह मानते हुए कि अटैचमेंट/डाउनलोड हेडर सेट नहीं है .. जो मुझे भी परेशान लगता है) इसे देखने से पहले इसे डाउनलोड करने की आवश्यकता नहीं है।

यह जीएम के पिछले संस्करणों की तरह ही चीजें भी कर रहा है

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

आप कभी भी किसी एक्सटेंशन को ब्राउज़ नहीं करते हैं। आप इसे डाउनलोड/इंस्टॉल करते हैं, या आप नहीं करते हैं।

टेक्स्ट फ़ाइल होने से फर्क पड़ता है। उदाहरण के लिए जिथब में "कच्चा देखें" विकल्प है जो अब टूटा हुआ है।

अक्षम होने पर नेविगेशन को न छूना शामिल है।

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

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

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

WebExt से पहले, हमें किसी भी उपयोगकर्ता-स्क्रिप्ट-दिखने वाले अनुरोध को जल्द से जल्द निलंबित करने के लिए http-on-modify-request का उपयोग करके यह प्राप्त हुआ था। हम इंस्टॉल डायलॉग को ट्रिगर करेंगे, और सभी भागों को डाउनलोड करने के लिए रिमोटस्क्रिप्ट ऑपरेशन शुरू रद्द कर देगा, और ... कुछ नेविगेशन को पुनरारंभ करेगा (मुझे लगता है कि चैनल को ठीक से फिर से शुरू करके, लेकिन मुझे वह नहीं मिल रहा है)।

धीमी स्क्रिप्ट के साथ , पहले कुछ भी नहीं होता है -- एक बार ==UserScript== भाग लोड हो जाने के बाद, इंस्टॉल डायलॉग प्रकट होता है, फिर इसकी प्रगति पट्टी भर जाती है क्योंकि बाकी डाउनलोड हो जाती है - शेष स्क्रिप्ट, संसाधन की आवश्यकता होती है , आदि।

यह सर्वर से केवल एक कनेक्शन के साथ स्क्रिप्ट डाउनलोड करने का प्रबंधन करता है।

WebExt के अंतर्गत, सभी API निश्चित रूप से भिन्न हैं, लेकिन onHeadersReceived ईवेंट को पहले से ही HEAD _seems_ पर ब्लॉक/फ़िल्टर करना सबसे अच्छी बात है। मुझे अभी भी शोध करना है।

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

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

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

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

मेरे पास कुछ भी स्थापित करने से पहले .. इसका निरीक्षण करने का विकल्प था ...

2567

क्या होगा यदि यह एक उपयोगकर्ता स्क्रिप्ट की तरह दिखता है, लेकिन ऐसा नहीं है? उदाहरण के लिए, यदि आप अपना धीमा लोड उदाहरण लेते हैं और प्रारंभिक // ==UserScript== हटा दें। इसे 3.x में खोलें, इंस्टॉल डायलॉग कभी नहीं खुलता (सही) और फिर टेक्स्ट कंटेंट टैब / पेज पर लिखा जाता है। WebEx के साथ यदि आप पृष्ठभूमि में एक नया कनेक्शन बनाते हैं तो मैं नहीं देखता कि आप पृष्ठ पर सामग्री कैसे लिख सकते हैं। जहां तक ​​​​मुझे पता है कि पृष्ठभूमि में किसी पृष्ठ पर कुछ सामग्री लिखने का एकमात्र सीधा तरीका स्ट्रीम फ़िल्टर के माध्यम से होता है।

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

शायद मुझे कुछ याद आ रहा है..

इसे 3.x में खोलें, इंस्टॉल डायलॉग कभी नहीं खुलता (सही) और फिर टेक्स्ट कंटेंट टैब / पेज पर लिखा जाता है।

एह, मैं इस बिंदु को ठीक करना चाहूंगा। मैं गलत था, जब मैंने शुरू में परीक्षण किया तो मेरे पास user में एक टाइपो था।

@Sxderp मुझे दोहराना चाहिए कि आपके द्वारा आज तक किए गए योगदानों को मैं बहुत महत्व देता हूं और आशा करता हूं कि आप इसे जारी रखेंगे।

लेकिन ऊपर उल्लिखित मेरे निर्णय के बारे में थोड़ी और स्पष्टता के लिए: मैंने अपना काम प्रगति पर साफ कर लिया है; पहले मैंने कुछ असंबंधित काम को अलग करने के लिए स्थानांतरित किया। जो बचा था वह एक फ़ाइल का नाम बदलना है और फिर यह बड़ी प्रतिबद्धता है , जो केवल + 425 -491 है।

Downloader वर्ग स्रोत की परवाह किए बिना किसी स्क्रिप्ट को स्थापित करने (डाउनलोड करने और) के बारे में सभी तर्कों को समाहित करता है। आपको बस इनपुट सेट अप करने की आवश्यकता है - केवल एक इंस्टॉल के लिए यूआरएल, लेकिन मुख्य स्क्रिप्ट स्रोत और शायद पहले से ज्ञात होने पर सामग्री की आवश्यकता/संसाधन सामग्री हो सकती है (केस संपादित करने के लिए), यह कुछ और लापता डाउनलोड करता है (यानी एक नई आवश्यकता में संपादित करें /संसाधन) और हमेशा एक ही प्रारूप को user-script-regstry पर भेजता है जो इसे केवल एक ही तरीके से जारी रखता है। संपूर्ण downloader.js 250 लाइनों के नीचे है। परिणामस्वरूप पृष्ठभूमि/सामग्री के बीच कम संदेश पारित होते हैं और कोई नया पोर्ट नहीं होता है।

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

क्या यह parsedDetails की पुनरावर्ती संरचना को भी हल करता है (कहीं कोई समस्या है, इसे देखने के लिए समय नहीं है)?

मुझे नहीं पता। मुझे शक है?

क्या यह पार्स किए गए विवरण की पुनरावर्ती संरचना को भी हल करता है (कहीं कोई समस्या है, इसे देखने का समय नहीं है)?

आपका मतलब #2806 है?