Greasemonkey: बैकअप जोड़ें/पुनर्स्थापित करें

खैर, फ़ायरफ़ॉक्स और इसके मुद्दे। तो, मैं इसे लागू कर रहा था (और निश्चित रूप से एक 'आयात' समारोह)। मैं इसे लगभग पूरा कर चुका हूं, लेकिन एक शो-स्टॉपर है। यह केवल तभी काम करता है जब आप browser toolbox खोलते हैं और "पॉपअप को ऑटोक्लोज न करें" का चयन करते हैं। आयात <input type="file"> (जो एकमात्र तरीका है) के माध्यम से किया जाता है, हालांकि, ब्राउज़ विंडो के फोकस पर पॉपअप सामान्य रूप से बंद हो जाता है, इस प्रकार विंडो नष्ट हो जाती है और कोई फ़ंक्शन निष्पादित नहीं होता है। प्रासंगिक बग:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

काम करने के लिए आधे-अधूरे वातावरण में यह बहुत कष्टप्रद है।

साथ ही, #2612 पर लागू होता है। जिसे एक ही समय में संबोधित किया जा सकता है यह मुद्दा है।

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

मैं वह कर सकता था। इसमें कोड का एक गुच्छा चारों ओर ले जाना शामिल होगा। मैं इसे किसी और बार देख लूंगा।

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

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

ज़रूर, लेकिन फिर हम बहुत सारी शर्तों में भाग लेते हैं। मैं विलय की _exact_ प्रकृति पर किसी प्रकार का प्रवाह आरेख देखना चाहता हूं।

ज्यादातर संघर्ष के मामले में। सामग्री को अधिलेखित करें, कुंजी/मानों को अधिलेखित करें (हाँ वे भी निर्यात किए जाते हैं), सब कुछ के लिए संकेत (जो एक खराब उपयोगकर्ता अनुभव की तरह लगता है), आदि?

मेरा मतलब है: फ़ाइल में प्रत्येक स्क्रिप्ट को आयात करें (और उस स्थिति में पूरी तरह से ओवरराइट करें), लेकिन उन स्क्रिप्ट को स्पर्श/हटाएं नहीं जो फ़ाइल में नहीं हैं।

ओह। यह कहीं ज्यादा आसान है। हाँ, यह अच्छा लगता है।

इसलिए मैंने तीन अलग-अलग आयात विधियों को लागू किया है।

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

सबमिट करने से पहले अन्य पीआर की प्रतीक्षा कर रहा है।

[1] मैं एक स्क्रिप्ट के id द्वारा विशिष्टता निर्धारित करता हूं।

इस बारे में क्या?

1. अद्यतन। केवल पहले से मौजूद स्क्रिप्ट को आयात (ओवरराइट) करें।

यह 1 का पूरक है। मर्ज

1. अधिलेखित करें। मर्ज की तरह लेकिन अगर कोई विरोध पाया जाता है [1] तो आयात की जा रही स्क्रिप्ट को प्राथमिकता दी जाती है।

@Sxderp मुझे लगता है, "विलय की तरह" में बाधा शामिल नहीं है "केवल स्क्रिप्ट जो वर्तमान में मौजूद नहीं हैं" ...
(इस प्रतिबंध का यहां कोई मतलब नहीं है) इसका अर्थ है, अधिलेखित करना = सभी लिपियों को आयात करना, परस्पर विरोधी लिपियों को संग्रह द्वारा अधिलेखित कर दिया जाता है...

इनमें से कौन सा (अपडेट/मर्ज/इत्यादि) विकल्प VM, TM, या अन्यथा ऑफ़र करते हैं?

1. अद्यतन। केवल पहले से मौजूद स्क्रिप्ट को आयात (ओवरराइट) करें।

ज़रूर, यह करने योग्य होना चाहिए।

इसका अर्थ है, अधिलेखित करना = सभी लिपियों को आयात करना, परस्पर विरोधी लिपियों को संग्रह द्वारा अधिलेखित कर दिया जाता है...

सही।

इनमें से कौन सा (अपडेट/मर्ज/इत्यादि) विकल्प VM, TM, या अन्यथा ऑफ़र करते हैं?

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

अद्यतन। केवल पहले से मौजूद स्क्रिप्ट को आयात (ओवरराइट) करें।

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

कुछ त्वरित जांच की, यह 100% पूरी तरह से नहीं है लेकिन एक सामान्य अवलोकन देता है, साथ ही साथ मुझे अपने कार्यान्वयन के संबंध में शायद क्या बदलना चाहिए।

VM और TM दोनों ज़िप फ़ाइलों में निर्यात करते हैं। ज़िप फ़ाइलों के अंदर आप अपनी प्रत्येक स्क्रिप्ट के लिए .user.js फ़ाइलें पा सकते हैं। हालांकि, भंडारण/कार्यान्वयन विशिष्ट विवरण निर्यात करने के लिए, वे दोनों इसे थोड़ा अलग करते हैं। वीएम कार्यान्वयन विशिष्ट विवरण और स्क्रिप्ट डेटा को लपेटता है, जो सभी स्क्रिप्ट की तरह दिखता है, एक फ़ाइल में, violentmonkey । टीएम इसे थोड़ा और समझदारी से करता है। प्रत्येक स्क्रिप्ट के लिए कार्यान्वयन विशिष्ट विवरण, .options.js फ़ाइलों में निर्यात किए जाते हैं, जबकि स्क्रिप्ट डेटा .storage.json में निर्यात किया जाता है।

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

'आयात की विधि' के लिए (ऊपर मेरी पोस्ट में वर्णित):

TM एक 'प्रत्येक स्क्रिप्ट का चयन करें' इंटरफ़ेस प्रदान करता है। जब आप एक संग्रह आयात करते हैं तो आप चुनते हैं कि क्या आप प्रत्येक विशिष्ट स्क्रिप्ट को आयात करना चाहते हैं। यदि आप इसे चेक करते हैं तो यह उस स्क्रिप्ट के सभी डेटा को अधिलेखित कर देगा।

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

अगर कोई परीक्षण करना चाहता है, तो मैंने अपनी शाखा sxderp:import-export-database-merge को अपडेट कर दिया है, जिसमें .zip कार्यक्षमता शामिल है जिसकी मैंने पहले चर्चा की थी। मैंने @Eselce द्वारा सुझाए गए update विकल्प को लागू नहीं किया क्योंकि मैं अभी भी विवरणों के बारे में अनिश्चित हूं।

@Sxderp इस सुविधा को विकसित करने के लिए धन्यवाद। मैंने पैकेज बनाया है और इसे फ़ायरफ़ॉक्स डेवलपर संस्करण में स्थापित किया है (अहस्ताक्षरित एक्सटेंशन स्थापित करने में सक्षम करने के लिए)। मैंने उस ब्राउज़र संस्करण के साथ एक मौजूदा प्रोफ़ाइल को अपग्रेड किया, मौजूदा GreaseMonkey इंस्टॉलेशन को ओवरराइट किया और बिना किसी समस्या के अपने डेटाबेस को निर्यात किया।

इस GreaseMonkey के साथ एक नई फ़ायरफ़ॉक्स प्रोफ़ाइल में आयात करने से हालांकि एक समस्या हुई। ऐसा लगता है कि एक विशिष्ट उपयोगकर्ता स्क्रिप्ट जो बहुत बड़ी है (दोनों user.js और gm_details.js लगभग 230K हैं, आयात के मुद्दे पैदा कर रहे हैं। डेटाबेस को बदलने के बाद GM काम करना बंद कर देता है। GM आइकन पर क्लिक करने से एक खाली ड्रॉपडाउन (लगभग 10x10 वर्ग) खुल जाता है।

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

संपादित करें: जीएम के टूटने के बाद काम करने का एकमात्र तरीका एक्सटेंशन को हटाना, फ़ायरफ़ॉक्स को पुनरारंभ करना और इसे फिर से जोड़ना है।

GMexport_20180 2 17_164139.zip ???

बिना किसी शिकायत के 3.4 एमबी ज़िप फ़ाइल से (आंशिक रूप से) बड़ी स्क्रिप्ट (> 20) का एक पूरा समूह आयात किया। हालांकि विस्तृत जांच नहीं...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() 0 से शुरू होता है... ; लापता...

IIRC, getMonth() 0 से शुरू होता है...; लापता...

फाड़ना

मैंने कुछ समय से इस शाखा में काम नहीं किया है। मैं आज लेने जा रहा हूं और मास्टर पर रिबेस और सफाई का एक गुच्छा करूंगा।

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

7fe8bfe94efbadeb1da1a6491aaf424fc8275f09 में परिवर्तन के साथ विलय। मैंने देखी कुछ समस्याओं को ट्रैक/चर्चा करने के लिए फिर से खोलना।

मैंने देखी कुछ समस्याओं को ट्रैक/चर्चा करने के लिए फिर से खोलना।

क्या मुद्दे थे?

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

मैंने अंत में इस पर थोड़ा गौर किया है।

यह केवल .user.js , और "विवरण" का बैकअप लेता है। जो गलती से आवश्यक सामग्री को शामिल करने के लिए होता है, लेकिन संसाधनों को याद करता है (JSON ब्लॉब को {} क्रमबद्ध करता है)। AFAICT यह खाली/टूटे हुए ब्लॉब्स के साथ .setKnownResources() , और इस प्रकार काम करने में विफल रहता है।

यह बेहतर प्रतीत होगा यदि प्रत्येक स्क्रिप्ट का अपना फ़ोल्डर हो, उस फ़ोल्डर में मुख्य .user.js लिए एक फ़ाइल हो, प्रत्येक @require और @resource , और फिर शायद शेष पार्स/ कस्टम विवरण, और संग्रहीत मान। मुझे लगता है कि यह और भी बेहतर हो सकता है कि मैं किसी भी क्रॉस प्लेटफॉर्म संगतता को छोड़ दूं।

पूरी तरह से सहमत। जैसे किसी दस्तावेज़ को "वेब पेज के रूप में" सहेजना, जो एक htm -दस्तावेज़ और निर्भरता के साथ उसी (आधार) नाम का एक फ़ोल्डर बनाएगा ...

जो गलती से आवश्यक सामग्री को शामिल करने के लिए होता है ...

संयोग से नहीं था। किसी भी स्थानीय परिवर्तन के लिए, जो हो सकता है, इसे उद्देश्य पर शामिल करता है। मैं संसाधनों/आवश्यकताओं को 'कार्यान्वयन विवरण' के रूप में मानता हूं, और इसलिए "विवरण" के रूप में निर्यात किया जाता है। TM संसाधनों/आवश्यकताओं का निर्यात भी नहीं करता है।

लेकिन संसाधनों को याद करता है (JSON ब्लॉब को {} तक क्रमबद्ध करता है)। AFAICT यह .setKnownResources() खाली/टूटे हुए ब्लॉब्स के साथ होगा, और इस प्रकार काम करने में असफल हो जाएगा।

यह पता लगाने के लिए एक TODO है कि क्या बूँदें अच्छी तरह से कठोर हो जाती हैं। मेरे द्वारा इसके लिए पीआर सबमिट करने से पहले इस सुविधा को तकनीकी रूप से मिला दिया गया था।

कुछ समय के लिए, #2937 के साथ ब्लॉब समस्या का समाधान किया जाएगा।

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

यह 4.4 के लिए "बड़ी विशेषता" है, इसलिए मैं वास्तव में इसे जल्द ही समाप्त/सुधार करने की आशा करता हूं।

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