+100, यह ऐप के आकार को कम करने में बहुत मददगार होगा।

क्या .asar एक्सटेंशन को बदला जा सकता है? हंगेरियन में यह वास्तव में अजीब लगता है। मूल रूप से इसका मतलब खराब तरीके से the shit होगा ( लिंक )।

.apak? पूरी गंभीरता के साथ, कई भाषाएं हैं, इसलिए उनमें से कुछ में लगभग कोई भी एक्सटेंशन अजीब लग सकता है।

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

इसके लिए +1। मैं एक ऐसे एप्लिकेशन पर काम कर रहा हूं जिसे मुझे मैक और विंडोज़ के लिए डिलीवर करना है, और यह डिलीवरी को काफी आसान बना देगा।

यह कमाल होगा!

कुछ विचार:

• जैसा कि @YuriSolovyov ने कहा, हमें यह घोषित करने का एक तरीका चाहिए कि परमाणु-रनटाइम के कौन से संस्करण एक विशेष असर के साथ संगत हैं। अधिमानतः, इसे एक सटीक संस्करण निर्दिष्ट करने की भी अनुमति देनी चाहिए, क्योंकि इससे असर-आधारित ऐप जारी करते समय क्यूए पर बोझ कम हो जाता है।
  
  
  
  • इसका समर्थन करने के लिए, हमें परमाणु-रनटाइम के कई संस्करणों को साथ-साथ स्थापित करने की अनुमति देनी होगी, संभावित रूप से अदृश्य रूप से उपयोगकर्ता के लिए।
  
  
  • ध्यान दें कि यह कुछ हद तक डाउनलोड आकार को सीमित करने के आदर्शों के विपरीत है। हालांकि, कई असर-आधारित उत्पादों का उत्पादन करने वाली कंपनी आंतरिक रूप से मानकीकरण कर सकती है, इसलिए उनके सभी ऐप्स अभी भी एक ही संस्करण का उपयोग करते हैं।
  
  
• आपने मैक पर एटम-रनटाइम को ऑटो-अपडेट करने के लिए समर्थन का उल्लेख नहीं किया, लेकिन यह _very_ उपयोगी होगा।
• linux पर केवल-स्रोत संस्थापन होने के बजाय, .deb/.rpm संकुल के साथ-साथ कुछ ऐसे तरीकों के माध्यम से बायनेरिज़ को स्थापित / अद्यतन करने का समर्थन करना अच्छा होगा, जिन्हें स्थापित करने के लिए sudo अधिकारों की आवश्यकता नहीं होती है (अर्थात प्रति-उपयोगकर्ता)। प्रति उपयोगकर्ता स्थापित रनटाइम के लिए, ऑटो-अपडेट भी बहुत उपयोगी होगा।
• क्या स्थापित आसार फाइलों को अप-टू-डेट रखने के लिए कोई समर्थन होगा - या ऐसा कुछ है जिसे प्रत्येक ऐप में स्वतंत्र रूप से लागू करना होगा?

अंत में, इस प्रयास की समय-सीमा क्या है? शुरू करने का सबसे अच्छा तरीका क्या होगा, अगर मैं इसके कुछ हिस्सों को लागू करना शुरू करना चाहता हूं? मैं योगदान के लिए तैयार हूं।

@ joshuawarner32 वर्तमान में यह सिर्फ एक मोटा विचार है, मैं परमाणु-खोल के कुछ प्रमुख मुद्दों को हल करने के बाद इस पर काम करने की योजना बना रहा हूं, लेकिन यह महीनों बाद हो सकता है।

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

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

लगभग 5-6 महीने हो गए हैं। इसे लागू करना बहुत अच्छा होगा।

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

यहाँ हमारे डिजाइन की मुख्य विशेषताएं हैं:

• सर्वर पर कई अलग-अलग ऐप्स के लिए .asar.gz फ़ाइलें परिनियोजित करें
• उपयोगकर्ताओं को परमाणु-खोल का एकल निर्माण वितरित करें, जो विशिष्ट ऐप्स के लिए किसी भी कोड को बंडल नहीं करता है
• ऐप स्टार्टअप पर, उपयुक्त .asar.gz फ़ाइल डाउनलोड करें (यदि यह वहां नहीं है, या सर्वर पर हाल ही में कोई फ़ाइल है)। इसे निकालें और निहित ऐप चलाएं।
• हमारा एटम-शेल बिल्ड यह निर्दिष्ट करने के लिए --app तर्क स्वीकार करता है कि कौन सा ऐप डाउनलोड/चलाने के लिए है

क्या उस तरह का परमाणु-खोल लोगों के मन में था? क्या ऐसा कुछ अन्य लोगों के लिए उपयोगी होगा?

जेआरई की तरह यह ईआरई (इलेक्ट्रॉन रनटाइम एनवायरनमेंट) हो सकता है, जिसमें .eapp फाइलें (इलेक्ट्रॉन ऐप) होती हैं।

-1 के लिए .eapp

+1 मुझे इसकी आवश्यकता है!

विंडोज़ पर, हम एटम-रनटाइम के लिए इंस्टॉलर और ऑटो अपडेटर प्रदान कर सकते हैं, और इसके साथ खोले जाने वाले .asar फ़ाइल प्रकार को पंजीकृत कर सकते हैं।

विंडोज़ पर स्टीम स्थापित करें और देखें कि वे गेम शॉर्टकट कैसे बनाते हैं, वे वास्तव में प्रोटोकॉल हैंडलर का उपयोग करते हैं, यह अपेक्षाकृत चालाक है

: +1: स्टीम मॉडल पर।

इसे लागू करने में कोई तकनीकी बाधा नहीं है, पूरी बात सिर्फ एक इलेक्ट्रॉन ऐप ही हो सकती है। लेकिन समस्या यह है कि इसे लागू करना आसान नहीं है, सभी विवरणों को ध्यान में रखते हुए, मुझे लगता है कि इस पर पूर्णकालिक काम करने वाली एक छोटी सी टीम की आवश्यकता है, मुझे यकीन नहीं है कि यह कभी होगा या नहीं।

लेकिन समस्या यह है कि इसे लागू करना आसान नहीं है, सभी विवरणों को ध्यान में रखते हुए, मुझे लगता है कि इस पर पूर्णकालिक काम करने वाली एक छोटी सी टीम की आवश्यकता है, मुझे यकीन नहीं है कि यह कभी होगा या नहीं।

मेरे मन में बहुत सारे प्रश्न हैं, जो निश्चित रूप से दुर्गम नहीं हैं, इस योजना को कठिन बनाते हैं। उदाहरण के लिए, मान लें कि "ऐप 1" को 0.30.x की आवश्यकता है और यह 0.31.x पर नहीं चल सकता है, और "ऐप 2" को इसके विपरीत की आवश्यकता है। इस परिदृश्य में कौन जीतता है?

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

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

@paulcbetts लेकिन हे, इसके लाभ इसके लायक हैं, है ना? ऐप को अपडेट करते समय यूजर्स को ~70mb के बजाय mb से कम डाउनलोड करना होगा। जिसका अर्थ है कि हमें ऑटो-अपडेटिंग फ्रेमवर्क की भी आवश्यकता नहीं होगी और सब कुछ, हमें बस कुछ फाइलों के साथ एक माइक्रो-ज़िप संग्रह को डाउनलोड और निकालना होगा।

मैंने पिछले तीन महीने एक दूरस्थ क्षेत्र में बिताए हैं जहाँ गति 128kbps से कम थी और मेरा विश्वास करो, उन्नयन आकार गधे में एक बड़ा दर्द है, सबसे बुरी बात यह है कि अभी भी इसी तरह की स्थितियों में बहुत से लोग हैं

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

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

बेसिक ऐप्स अब 30 से 50 मेग्स के बीच हैं, जब तक कि आपके पैकेज में ढेर सारे वीडियो न हों। मुझे नहीं लगता कि अधिकांश लोगों के डाउनलोड करने के लिए यह एक खिंचाव है। मेरा मानना ​​है कि औसत यूट्यूब वीडियो 30 से 40 एमबी के बीच है...

मैं यहां सिर्फ एक नोट बनाना चाहता हूं, चीन में, कनेक्शन की गति औसत लगभग 20kB/s (दी है कि मेरे पास मेरे शहर के ~ 92% से धीमी कनेक्शन है।) परमाणु/इलेक्ट्रॉन को अपडेट करने के लिए आमतौर पर पूरे दिन की आवश्यकता होती है wget -c 'आईएनजी। जब तक taobao दर्पण का उपयोग नहीं किया जाता है।

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

20 केबी/एस? आप कैसे जीवित रह सकते हैं? मैं कल्पना नहीं कर सकता कि चीजों को कितना मुश्किल बनाना चाहिए!

@steelbrain मेरा इरादा नहीं है

@RIAEvangelist तेज समय और बहुत धैर्य से आगे बढ़ रहा है। देर रात में गति वास्तव में तेज़ हो जाती है, इसलिए सोते समय डाउनलोड को चालू या शेड्यूल करना छोड़ दें। :3

वैसे भी, मुझे लगता है कि यह एक (मूल) तृतीय-पक्ष रैपर लिखने के लिए बहुत अधिक काम नहीं होगा, कोई भी कोशिश करना चाहता है?

हालाँकि, .asar फ़ाइलें आसानी से अपने इलेक्ट्रॉन संस्करण की घोषणा नहीं कर सकती हैं। शायद किसी अन्य प्रोग्राम डिस्क्रिप्टर सिस्टम की आवश्यकता होगी?

किसी प्रकार के रनटाइम संस्करण डिस्पैचर के बारे में कैसे (यदि आवश्यक हो तो डाउनलोड करें और) लॉन्चर को आपके ऐप के लिए रनटाइम के संस्करण की आवश्यकता है? हम उसके लिए package.json में एक एंट्री जोड़ सकते हैं।

@YuriSolovyov सिवाय इसके कि हम रनटाइम हैंडल .json फ़ाइलों को डिफ़ॉल्ट रूप से नहीं कह सकते। मुझे लगता है कि यह पहले असर फ़ाइल को पढ़ सकता है और package.json देख सकता है, लेकिन यह इसे थोड़ा धीमा कर देगा।

@Tribex हाँ, तर्क प्रवाह इस प्रकार है:

-> associate .asar with runtime
-> user launches .asar app
-> dispatcher reads package.json in .asar
-> (optional) downloads required runtime version if needed
-> launches app

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

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

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

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

सप्ताह में लगभग एक बार एक नया इलेक्ट्रॉन रिलीज़ होता है, इसलिए संभावना है कि 2 ऐप्स में इलेक्ट्रॉन का बिल्कुल समान संस्करण हो।

रन टाइम दृष्टिकोण का समर्थन करने के लिए, हमें संभवतः रिलीज़ को एलटीएस (दीर्घकालिक समर्थन) संस्करणों और ब्लीडिंग एज संस्करणों में अलग करना शुरू करना होगा। एलटीएस उत्पादन के लिए होगा और ब्लीडिंग एज विकास और परीक्षण के लिए होगा। एलटीएस केवल बग फिक्स प्राप्त करेगा और शायद कुछ बदलाव जो प्रमुख io.js और सामग्री खोल संस्करणों को प्रतिस्थापित नहीं करते हैं, इसलिए मूल मॉड्यूल अभी भी काम करना चाहिए।

@etiktin ने जो कहा है, उसे देखते हुए, जब तक कि किसी उपयोगकर्ता के पास अपने सिस्टम पर कई इलेक्ट्रॉन ऐप न हों, डाउनलोड समय में कोई लाभ नहीं होगा क्योंकि उन्हें अभी भी हर बार रन टाइम डाउनलोड करना होगा।

दो हफ्तों में मैं अब इलेक्ट्रॉन को देख रहा हूं, मुझे लगता है कि मैंने 4 रिलीज देखी हैं।

@etiktin आदर्श रूप से, यदि इलेक्ट्रॉन सेवर का अनुसरण करता है, तो एक ऐप संस्करण ^ 0.31 घोषित कर सकता है, और यह नवीनतम 0.31.x रिलीज़ का उपयोग करेगा। इससे चीजों को थोड़ी मदद मिल सकती है।

हमारे पास एक सेवर ऑटो-अपडेट तंत्र के साथ उत्पादन में एक ऐप है जो निम्न कार्य करता है:

1. ऐप के वर्तमान संस्करण (0.3.0, 0.3.1 आदि) और प्लेटफॉर्म (डार्विन-x64, win32-ia32, win32-x64 आदि) देने वाले सर्वर पर एक साधारण HTTP एंड-पॉइंट प्राप्त करें।
2. सर्वर "304 संशोधित नहीं" लौटाता है या यदि कोई नया संस्करण है तो एक JSON प्रकट होता है।
3. JSON मेनिफेस्ट अनिवार्य रूप से नए संस्करण में फ़ोल्डर्स, फ़ाइलों और सिम्लिंक की एक नेस्टेड सूची है।
4. JSON मेनिफेस्ट में एक फ़ोल्डर प्रविष्टि इस तरह दिखती है: [नाम, चाइल्ड प्रविष्टियों की सरणी]।
5. JSON मेनिफेस्ट में एक फ़ाइल प्रविष्टि इस तरह दिखती है: [नाम, सामग्री का हैश, सामग्री के हैश की सरणी 64KB विखंडू में विभाजित, एक पूर्णांक ध्वज यह दर्शाता है कि फ़ाइल निष्पादन योग्य है या नहीं]।
6. JSON मेनिफेस्ट में एक सिमलिंक प्रविष्टि इस तरह दिखती है: [नाम, गंतव्य पथ]।
7. ये JSON मैनिफ़ेस्ट प्रत्येक संस्करण के लिए सर्वर पर बनाए और कैश किए जाते हैं। JSON मेनिफेस्ट में प्रत्येक फ़ाइल के लिए, सर्वर सामग्री-निर्भर चंकिंग का उपयोग करके फ़ाइल को चर लंबाई के टुकड़ों में विभाजित करने के लिए एक साधारण डिडुप्लीकेशन एल्गोरिथ्म चलाता है, और फिर SHA256 का उपयोग करके चंक्स को हैश करता है। यह सुनिश्चित करता है कि एक ही फ़ाइल के विभिन्न संस्करणों के लिए अधिकांश चंक हैश समान रहें, भले ही सामग्री को कुछ बाइट्स द्वारा स्थानांतरित किया गया हो। इष्टतम डिडुप्लीकेशन + संपीड़न दक्षता के लिए औसत चंक लंबाई लगभग 64KB है। यदि टुकड़े बड़े हैं तो वे डुप्लिकेट भी नहीं करेंगे, यदि टुकड़े छोटे हैं तो वे भी संपीड़ित नहीं होंगे। मेटाडेटा में बहुत अधिक चंक हैश होने से बचने के लिए बहुत बड़ी फ़ाइलों के लिए औसत चंक लंबाई भी बढ़ाई जाएगी।
8. जब ऐप को सर्वर से एक नया JSON मेनिफेस्ट प्राप्त होता है, तो यह उपलब्ध खाली डिस्क स्थान की जांच करता है और एक सार्वभौमिक अद्वितीय आईडी के साथ एक नई अस्थायी निर्देशिका बनाता है। अपने पुराने स्थानीय मैनिफेस्ट को शुरुआती बिंदु के रूप में उपयोग करते हुए, यह स्थानीय फाइलों से टुकड़ों की प्रतिलिपि बनाता है या सर्वर से लापता हिस्सों को नए मैनिफेस्ट को फिर से बनाने के लिए डाउनलोड करता है। नया संस्करण बनाने के बाद, यह सभी फ़ाइल सामग्री की निर्देशिका संरचना और हस्ताक्षरों को सत्यापित करता है। अगर डाउनलोड में कुछ भी दूषित हो गया था, तो यह अपडेट को हटा देता है।
9. यदि नया अपडेट मेनिफेस्ट के विरुद्ध सफलतापूर्वक सत्यापित हो जाता है, तो यह ऐप के नए संस्करण को नए अपडेट पथ पर लॉन्च करता है।
10. पुराना संस्करण नोटिस करता है कि दूसरा संस्करण चल रहा है, और खुद को बंद कर देता है।
11. नया ऐप पुराने संस्करण के बंद होने की प्रतीक्षा करता है, फिर खुद को किसी अन्य अस्थायी निर्देशिका में कॉपी करता है, पुराने संस्करण को एक संग्रह निर्देशिका में बदल देता है, और अस्थायी निर्देशिका को पुराने संस्करण (/Applications/Ronomon.app) के स्थान पर बदल देता है। यह फिर खुद को फिर से चलाता है लेकिन अब पुराने संस्करण (/Applicatons/Ronomon.app) के स्थान से और फिर संग्रह निर्देशिका को साफ करता है।
12. यदि संक्रमण के दौरान कुछ भी गलत हो जाता है, तो पुराना संस्करण विहित पथ पर तब तक बना रहता है जब तक कि नाम बदलें कॉल द्वारा स्विच नहीं किया जाता है।

कुल मिलाकर, यह उत्पादन में बहुत अच्छा काम कर रहा है। डुप्लीकेशन और कंप्रेशन का मतलब है कि एक विशिष्ट प्रमुख संस्करण अपडेट के लिए केवल लगभग 33% डाउनलोड करने की आवश्यकता है और ऐप के आधार पर मामूली अपडेट के लिए केवल 1-2 एमबी की आवश्यकता होती है। ऑटो-अपडेट इलेक्ट्रॉन और ऐप कोड को एक परमाणु इकाई के रूप में संभालता है, और इस प्रक्रिया में किसी भी कोड हस्ताक्षर का उल्लंघन नहीं करता है।

+1 विचार करने के लिए
+1 का नाम बदलने के लिए asar

मैं इस संबंध में मुद्दा उठाने आया हूं। पाया कि यह पहले से मौजूद है, इसलिए मैं इसमें अपना + :100: डालूँगा
हमें पूरी तरह से एक JRE या .NET या Adobe Air जैसे समाधान की आवश्यकता है, क्योंकि प्रत्येक ऐप के साथ रनटाइम को पैक करना उन्हें वास्तव में भारी बनाता है।

रनटाइम को ऐप्स से अलग करने पर कोई अपडेट?

क्या यह बंद है क्योंकि एक समाधान विकसित किया गया है?

@PierBover यह मुद्दा खुला है।

यह - https://github.com/KeitIG/museeks/issues/48 - बंद हो गया। किसी और के भंडार में।

ओह धन्यवाद @championswimmer और भ्रम के लिए खेद है।

तो क्या स्वतंत्र रनटाइम पर कोई खबर है? क्या यह कुछ ऐसा है जिस पर काम किया जा रहा है?

@PierBover वर्तमान संस्करण विखंडन के कारण शायद यह जल्द ही किसी भी समय नहीं होने वाला है (एक ही सटीक संस्करण का उपयोग कर रहे 2 इलेक्ट्रॉन ऐप्स ढूंढना मुश्किल है)। शायद v1 जारी होने के बाद।

@jorangreef क्या आप सभी प्लेटफार्मों पर अपने अंतर अद्यतन तंत्र का उपयोग करते हैं? यह बहुत अच्छा होगा यदि आप उस कोड को एक स्टैंडअलोन मॉड्यूल के रूप में जारी कर सकें।

@championswimmer हाँ, मैंने अपने ऐप के लिए एक बिल्ड स्क्रिप्ट बनाने में कामयाबी हासिल की है, इसलिए मैं अब अपना ऐप वितरित कर रहा हूं। लेकिन मैं इस पर नजर रख रहा हूं क्योंकि यह दिलचस्प होगा।

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

उदाहरण के लिए, मान लें कि "ऐप 1" को 0.30.x की आवश्यकता है और यह 0.31.x पर नहीं चल सकता है, और "ऐप 2" को इसके विपरीत की आवश्यकता है। इस परिदृश्य में कौन जीतता है?

फिर उन्हें दो संस्करणों को स्थापित करना चाहिए और दो रनटाइम होंगे, जैसे वीएस सी ++ 2008 2005 के साथ सह-अस्तित्व में हैं। मुझे वास्तव में पसंद है कि वीएस सी ++ रनटाइम कैसे स्थापित होते हैं, इंस्टॉलर एक आवश्यक संस्करण स्थापित करेगा यदि कोई नहीं है, और अन्य इस पर निर्भर हो सकते हैं यह बाद में, और विभिन्न रनटाइम सह-अस्तित्व में हो सकते हैं। संस्करण आवश्यकताओं का प्रवर्तन भी इंस्टॉलर में अधिक आसानी से किया जाता है।

@ louy2 विज़ुअल सी ++ उदाहरण (रिलीज़ के बीच 3 वर्ष), और इलेक्ट्रॉन (प्रति माह कम से कम 3 रिलीज़) के बीच अंतर है।

मैं यहाँ एक 'यह एक टूटी हुई प्रणाली है' उद्धरण के साथ चुटकी लेता हूँ, यदि अधिकांश
इलेक्ट्रॉन पारिस्थितिकी तंत्र में ऐप्स +- 0.0.1 या . के साथ संगत नहीं हैं
0.1.0 संस्करण अंतर

20 फरवरी 2016 को 18:55 बजे, पियरे डे ला मार्टिनियर <
सूचनाएं@github.com> ने लिखा:

@ louy2 https://github.com/louy2 में अंतर है
विज़ुअल C++ उदाहरण (रिलीज़ के बीच 3 वर्ष), और इलेक्ट्रॉन (प्रति रिलीज़ 3 रिलीज़)
महीने कम से कम)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/atom/electron/issues/673#issuecomment -186595285।

+1

मैंने fpm का उपयोग करके .deb पैकेज में इलेक्ट्रॉन पैक किया है। यह लिनक्स पर एक उचित प्रारंभिक बिंदु हो सकता है (डेबियन- या आरपीएम-आधारित, कम से कम)। आप यहां देख सकते हैं: iamale/electron-deb ; एक उदाहरण ऐप भी है । (यह असर के साथ भी काम करेगा, बस रनटाइम पैकेज में एक एमआईएमई प्रविष्टि जोड़ने की जरूरत है।)

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

(मुझे इस सूत्र को इंगित करने के लिए @ louy2 का धन्यवाद!)

वैसे, .asar के लिए MIME प्रकार क्या है? क्या application/x-asar करेंगे?

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

और माइम के बारे में, कैसे के बारे में application/x-electron ?

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

application/x-electron वैसे बहुत अच्छा लगता है, शायद इसके साथ रहेगा।

असर समर्थन जोड़ा गया! अभी तक रिपॉजिटरी में नहीं है, बाद में आज या शायद कल इसका पुनर्निर्माण करेंगे। अभी के लिए, आप transfer.sh पर पैकेज प्राप्त कर सकते हैं (लिंक अगले 2 सप्ताह के लिए मान्य होगा)

आपको .asar के अंदर एक asar.json की आवश्यकता है, यह बताने के लिए:

• अनुशंसित संस्करण
• संगत संस्करण
  एक बार यह हो जाने के बाद, आपको अपने कंप्यूटर में (1) अपडेट (चेकर) और (2) मौजूदा संस्करणों के लिए वेब की जांच करने के लिए इलेक्ट्रॉन (इसका कोई भी संस्करण) का उपयोग करके एक ऐप की आवश्यकता होती है, फिर यदि एक संगत संस्करण मौजूद है तो यह पार्स करता है खुले .asar के लिए उद्घाटन पथ, अन्यथा अनुशंसित संस्करण डाउनलोड करें और फिर से जांचें। ऐप, स्वयं, इलेक्ट्रॉन, या पायथन में लिखा जा सकता है (क्योंकि इसके लिए केवल न्यूनतम या कोई UI की आवश्यकता नहीं होगी)।

विचार यह है: ऐप जो जांचता है कि क्या इलेक्ट्रॉन संस्करण की आवश्यकता है, डाउनलोड किया गया है, इसका आवश्यक इलेक्ट्रॉन संस्करणों से कोई लेना-देना नहीं है।

यदि आवश्यकता होती है, तो आप डिफ़ॉल्ट_एप की सामग्री को अपडेट कर सकते हैं, साथ ही इसे छोड़कर बाकी ऐप भी अपडेट कर सकते हैं।

और वहां, आपके पास app.setPath("userData", __dirname + "/ElectronVersions"); के साथ सहेजे गए संस्करण हो सकते हैं, फिर उन संस्करणों को वहां अकेला छोड़ा जा सकता है, और आवश्यकता पड़ने पर नए स्थापित किए जा सकते हैं।

एफपीएम के बजाय, क्या आपने AppImageKit पर एक नज़र डाली है।

https://bintray.com/probono/AppImages/Atom/_latestVersion#files पर एटम की एक AppImage उपलब्ध है - बस डाउनलोड करें, chmod a+x , और किसी भी पुराने x86_64 Linux वितरण पर चलाएं।

समस्या सिर्फ लिनक्स नहीं है, हमें इसे क्रॉस-ओएस बनाने का एक तरीका चाहिए, जिसका अर्थ है कि हमें इसे लिनक्स, विंडोज और मैक ओएसएक्स पर चलाने में सक्षम होना चाहिए।

किसी प्रकार का ओएस-विशिष्ट लॉन्चर जो यह देखता है कि रनटाइम उपलब्ध है और असर पैकेज के साथ अद्यतित/संगत है

(कई साल बाद) मैं चर्चा को संक्षेप में बताता हूं:

1. @zcbenz एक रनटाइम का प्रस्ताव करता है जो स्थानीय इलेक्ट्रॉन उदाहरणों का प्रबंधन करता है इसलिए .asar पैकेज केवल वितरित किए जाते हैं और इलेक्ट्रॉन बायनेरिज़ को बंडल करने से बचा जाता है। रनटाइम .asar पैकेजों के निष्पादन का भी प्रबंधन करता है।
2. @YurySolovyov अतिरिक्त जानकारी (जैसे आवश्यक इलेक्ट्रॉन संस्करण) के साथ मेनिफेस्ट फ़ाइल को बढ़ाने का सुझाव देता है, इसलिए रनटाइम जानता है कि किस संस्करण का उपयोग किया जाना है जिसके लिए .asar पैकेज। इस दृष्टिकोण का एक सिंहावलोकन यहां दिया गया है।
3. @joshuawarner32 कई रनटाइम संस्करणों, बाइनरी पैकेजिंग (जैसे .deb ) और .asar पैकेज के लिए ऑटोअपडेट के विचार का परिचय देता है। इसके अलावा एक वितरण सर्वर के विचार पर विचार किया जाता है।
4. @paulcbetts स्टीम मॉडल के रूप में देखने और कुछ इसी तरह लागू करने का सुझाव देता है। वह एक स्थानीय रनटाइम के विचार से जुड़ी जटिलताओं को इंगित करता है जो विभिन्न इलेक्ट्रॉन संस्करणों आदि का समर्थन करता है।
5. [लोग चीन में इंटरनेट की गति और उनके बचपन के मामलों पर चर्चा करते हैं]
6. रनटाइम अपग्रेड होने पर @ होकेन जटिलताओं को इंगित करता है। विशेष रूप से रत. मूल मॉड्यूल जिन्हें इलेक्ट्रॉन हेडर के खिलाफ फिर से बनाने की आवश्यकता होती है।
7. @etiktin LTS और ब्लीडिंग एज वर्जन रखना चाहता है, इसलिए प्रोडक्शन-रेडी ऐप्स ब्लीडिंग एज के बजाय LTS का उपयोग करते हैं।
8. @Tribex का कहना है कि अगर हम अर्थपूर्ण संस्करण से चिपके रहते हैं तो हमें _all_ संस्करणों का स्थानीय उदाहरण रखने की आवश्यकता नहीं है, लेकिन केवल वे जो असंगत हैं।
9. @jorangreef अपने स्वयं के अनुप्रयोग के लिए पहले से ही उत्पादन में अंतर ऑटो-अपडेट सिस्टम का एक उदाहरण प्रदान करता है।
10. @iamale ने .asar पैकेजों को निष्पादित करने के लिए इलेक्ट्रॉन का एक fpm पैकेज बनाया है।

_अस्वीकरण: मैंने चर्चा के केवल मुख्य बिंदुओं को शामिल करने का प्रयास किया है। अगर मुझसे कुछ छूट गया हो तो क्षमा करें!_

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

तर्क:

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

एमवीपी:

• पर्यावरण प्रबंधक : स्थानीय रूप से उपलब्ध इलेक्ट्रॉन उदाहरणों का ट्रैक रखता है। इसका उपयोग यह तय करने के लिए किया जा सकता है कि कौन सा पैकेज किस उदाहरण के साथ संगत है (उन्नत package.json [नीचे देखें] का उपयोग करके)। इसे पैकेज चलाने के लिए सही पर्यावरण चर सेट करने का भी ध्यान रखना चाहिए।
• अद्यतन प्रबंधक : स्वचालित अद्यतन (+ अधिसूचना) और अंतर ऑटो-अपडेट की संभावना पर चर्चा की गई है। इसे एक डेमॉन के रूप में रखना अच्छा होगा जो स्थानीय उदाहरणों को नवीनतम संस्करणों में अपडेट करने का ख्याल रखता है।

अच्छा लगा:

• पैकेज/निर्भरता प्रबंधक : एटम के apm की तरह, .asar पैकेज (गिटहब या किसी दिए गए URL, आदि से) को डाउनलोड करने और उन्हें स्थानीय रूप से स्थापित करने के लिए एक पैकेज प्रबंधक की आवश्यकता होती है ( apt-get के साथ तुलनीय) उबंटू में brew )।

आवश्यकताएं:

• एन्हांस्ड मेनिफेस्ट फ़ाइलें : package.json में एक सेवर (या सेवर रेंज) भी होना चाहिए जो यह दर्शाता है कि कौन सा इलेक्ट्रॉन संस्करण आवश्यक है।
• परिभाषित इंस्टालेशन/अनइंस्टॉलिंग प्रक्रिया : एटीएम .asar पैकेज में एप्लिकेशन चलाने के लिए आवश्यक सभी चीजें शामिल हैं। हालांकि, इंस्टॉलेशन के समय केवल सोर्स डिलीवर करना और डिपेंडेंसी मॉड्यूल डाउनलोड करना संभव है। यदि हम बहुत अधिक साहसी हो जाते हैं तो हमारे पास किसी प्रकार की _global_ निर्देशिका हो सकती है जिसमें सभी अनुप्रयोगों के लिए निर्भरता होती है (एनपीएम 3 की फ्लैट संरचना मदद कर सकती है)। हालाँकि, यह वास्तव में जटिल हो सकता है, वास्तव में तेज़ (जैसे किसी ऐप को अनइंस्टॉल करते समय)।
• एकाधिक स्थानीय रनटाइम : यदि सिमेंटिक वर्जनिंग को अब तक लागू किया गया है तो वहां केवल दो असंगत संस्करण हैं 0.x और 1.x । छोटे संस्करण और पैच पश्चगामी संगत होने चाहिए , इसलिए हमें सिस्टम पर केवल 0.x और 1.x के नवीनतम संस्करण की आवश्यकता है।

प्रेरणाएँ:

• पर्यावरण/निर्भरता प्रबंधक: पायथन का virtualenv , रूबी का rbenv , और ruby-build भी देखें।
• पैकेज मैनेजर: पायथन का pip , एटम का apm ।
• अपडेट मैनेजर: क्रोमियम की zygote प्रक्रिया में _silent, background_ अपडेट के लिए एक दिलचस्प तरीका है।
• कोड अनुवादक (नए एपीआई के अनुकूल होने के लिए): पायथन 2to3 ।

epm (इलेक्ट्रॉन पैकेज मैनेजर) पहले से ही नाम के रूप में लिया जा रहा है ...
शायद रनटाइम elec और ऐप्स .tron पर कॉल करें? TRON के साथ शायद कुछ ट्रेडमार्क मुद्दे हैं, लेकिन यह अच्छा लगेगा;)

शायद uepm (सार्वभौमिक इलेक्ट्रॉन पैकेज प्रबंधक), क्योंकि यह इलेक्ट्रॉन द्वारा समर्थित सभी OS-es पर चलने के लिए है... या epmc (इलेक्ट्रॉन पैकेज प्रबंधन केंद्र) और फ़ाइल .epack (इलेक्ट्रॉन पैकेज)। विस्तार, कम से कम, .tron से बेहतर लगता है और इसे एक फिल्म के साथ भ्रमित नहीं किया जा सकता है ("वह ट्रॉन चीज दे दो, यार" _हैंड्स यू मूवी_)।

इलेक्ट्रॉन से संबंधित सैद्धांतिक भौतिकी के क्षेत्र में भी कई शब्द हैं

• फर्मियन
• लेपटोन
• चार्ज
• कूलम्ब
• पाउली

और, सीधे तौर पर संबंधित नहीं है, लेकिन पैकेज मैनेजर के साथ जो हो रहा है, उसके अनुसार कुछ अधिक है,

• बोसॉन
  ;)
  (मेरा मानना ​​​​है कि फोटॉन पहले ही लिया जा चुका है)

@kapouer + क्वार्क? सुनिश्चित नहीं है कि यह हालांकि लिया जाता है

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

Particle(s) ? हालांकि काफी लंबा।
विकि में कणों की सूची

नामकरण महत्वपूर्ण है, फिर भी मुझे लगता है कि हमें पहले रनटाइम/अपडेट/पैकेजिंग/वितरण अर्थशास्त्र की जांच करने की आवश्यकता है।

lepton इसके कणों के परिवार के बाद से सही लगता है जिससे इलेक्ट्रॉन संबंधित है।

थोड़ा आउट-ऑफ-स्कोप विचार: एक अधिक सामान्य रनटाइम मैनेजर और भी अधिक भयानक होगा (और लागू करने के लिए वास्तव में कठिन नहीं है)। उदाहरण के लिए, हम @nwjs बायनेरिज़ को भी शामिल कर सकते हैं और इसे उसी संस्करण-प्रबंधक-चीज़ में भी प्रबंधित कर सकते हैं (जैसे @ asdf-vm, लेकिन GUI रनटाइम के लिए)।

त्वरित और गंदा: https://github.com/iamale/lepton। अभी के लिए केवल निश्चित संस्करण का समर्थन करता है (सेवर अगली बात है), और ऐप्स अनपैक किए गए हैं (यानी अभी तक नहीं।

अच्छा!

+1

यहां तक ​​​​कि अगर नहीं .asar, @iamale , जब तक आपके पास यह जानने का कोई तरीका है कि कौन सी फाइल खोलनी है, मुझे लगता है कि यह ठीक होना चाहिए। जैसे, उदाहरण के लिए, आपके पास file.something हो सकता है जिसमें $#$1 package.json #$ से लिंकिंग json कोड हो, ताकि यह जान सके कि क्या खोलना है...

यह काफी पागल विचार है, लेकिन बनाने के लिए electron फ़ील्ड में package.json का उपयोग करने के बारे में क्या
कोई (ठीक है, किसी की तरह नहीं, लेकिन कोई भी तैयार) npm पैकेज निष्पादन योग्य?
पसंद:

electron: {
  "main": "index.js",
  "runtime": ">= 1.2"
}

यह npm संकुल को संस्थापित करने के लिए electron की क्षमता जोड़कर और उन्हें मेजबान सिस्टम के लिए निष्पादन योग्य और दृश्यमान बनाकर प्राप्त किया जा सकता है।
बस युह्ही

electron install atom

इसके लिए काम करने के लिए, हमें electron कमांड और वास्तविक रनटाइम बंडलों को विभाजित करने की आवश्यकता होगी।

लेकिन package.json का नाम बदलकर package.electron करने के बारे में क्या और क्या इसकी सामग्री कुछ इस तरह है?

run:{
  "name"    : "zDillinger",
  "version" : "0.0.1-1",
  "main"    : "main.js"
},
electron: {
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

इस उदाहरण में, यह इलेक्ट्रॉन 1.2 का उपयोग करने की सिफारिश करेगा, यदि यह नहीं मिला है तो यह भी जांचता है कि 1.2.1 और 1.2.5 के बीच कोई संस्करण है या नहीं, यदि 1.3.1 के लिए चेक नहीं है, तो 1.3.0.1 के लिए, यदि नहीं तो यह जांचता है 1.1 के लिए और यदि नहीं, तो 1.2 डाउनलोड करें।

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

@sapioit एक अलग मैनिफेस्ट होना मेरे लिए एक अच्छा विचार है। एक कस्टम फ़ाइल एक्सटेंशन होने से चीजें काफी सरल हो जाएंगी। (हालांकि .इलेक्ट्रॉन थोड़ा लंबा लगता है।)

हो सकता है कि @iamale's lepton, .lept के अनुसार?

मुझे package.json का उपयोग न करने से कोई लाभ नहीं दिख रहा है, इलेक्ट्रॉन क्षेत्र अलगाव भाग करता है। Babel और ESlint इस तकनीक का उपयोग करते हैं और ठीक काम कर रहे हैं।
इससे npm पर/के माध्यम से ऐप्स को सीधे प्रकाशित करना बहुत आसान हो जाता है।

हाँ, मैं दूसरा @YurySolovyov - मुझे लगता है कि इसे package.json में रखना अधिक उपयुक्त है

@YurySolovyov एक अतिरिक्त फ़ाइल का लाभ यह है कि रनटाइम अतिरिक्त फ़ाइल के एक्सटेंशन के लिए एक हैंडलर पंजीकृत कर सकता है और फ़ाइल के डिफ़ॉल्ट ओपनर के रूप में स्वचालित रूप से चला सकता है। जबकि package.json के साथ ऐसा करने के लिए प्रत्येक JSON फ़ाइल के लिए हैंडलर को पंजीकृत करने की आवश्यकता होगी, जो उपयोगकर्ताओं के लिए एक दर्द होगा।

@ ट्राइबेक्स फेयर पॉइंट।
शायद package.electron किसी प्रकार का लिंक हो सकता है जो रनटाइम को बताता है "Hey, take a look at package.json, it should contain the info on how to launch it" । यह एक "पागल" विचार था, तो हाँ, मैं इसे ठीक करने के साथ ठीक हूँ।

मैं @tribex से सहमत हूं, हमें या तो एक अलग फ़ाइल की आवश्यकता है, या package.json का नाम बदलने के लिए। किसी और चीज को।

@wurysolovoyov आप ऐसा नहीं कर सकते। केवल एक चीज जिसे आप फ़ाइल खोल सकते हैं, उसमें एक एक्सटेंशन संलग्न है, इस स्थिति में प्रत्येक एक्सटेंशन एक ही सॉफ़्टवेयर के साथ खुल जाएगा। इसलिए जब तक आप .json को electron के अलावा किसी और चीज़ के साथ खोलने में असमर्थ होने के साथ ठीक नहीं हैं (जो कि केवल त्रुटि होगी, जब तक कि एक उचित इलेक्ट्रॉन ऐप नहीं खोला जाता है), तब भी आप ऐसा कर सकते हैं, लेकिन आइए, जो .json फाइलें खोलने में सक्षम होना चाहते हैं, उन्हें उस प्रोग्राम के साथ खोलने में सक्षम हों, जिसके साथ हम उन्हें खोलना चाहते हैं।

अन्यथा आप फ़ाइल को संपादित करने में सक्षम नहीं होंगे, या तो पहले संपादक को खोले बिना, या प्रत्येक मिनट के साथ .json खोलने के लिए क्या बदलना है।

मेरा मतलब है @YurySolovyov नहीं @wurysolovoyov

हो सकता है कि मैंने इसे स्पष्ट नहीं बताया: package.electron का उद्देश्य केवल एक मार्कर के रूप में कार्य करना है कि यह निर्देशिका एक ऐप है, ताकि रनटाइम package.json को संदर्भित कर सके जो एक ही फ़ोल्डर में है , और एक ऐप लॉन्च करें। यदि आप सीधे package.json खोलते हैं, तो यह आपके OS में .json के साथ जो कुछ भी संबद्ध है, उसमें खुल जाएगा।

शॉर्टकट सिस्टम की तरह।

@YurySolovyov उस मामले में यह सिर्फ स्वाद की बात है जैसे कि हम उस जानकारी को package.json या package.electron में परिभाषित करते हैं। मैं व्यक्तिगत रूप से इसे केवल इसलिए अलग रखूंगा क्योंकि यह मुझे साफ-सुथरा लगता है। शायद package.json में इंजन की संपत्ति पर्याप्त होगी, हालांकि।

@Tribex यह npm पर ऐप प्रकाशित करने के लिए भी एक आवश्यकता है - वैध package.json

@YurySolovyov राइट। अगर हम package.electron package.json का उपयोग करते हैं तो भी मौजूद रहेगा। .इलेक्ट्रॉन का उपयोग केवल रनटाइम जानकारी को परिभाषित करने के लिए किया जाएगा, या, आपके सुझाव के मामले में, बस एक मार्कर हो।

मूल रूप से, package.electron केवल एक लॉन्च करने योग्य _marker_ के रूप में होगा, इसलिए package.json अभी भी अपने डेटा के साथ मौजूद रहेगा, लेकिन इसलिए एक अलग फ़ाइल की आवश्यकता होगी: _डबल क्लिक ऐप को खोलता है _। मैं अब भी package.electron से my-app.electron या my-app.electron का नाम बदलने में सक्षम होना चाहूंगा।

@sapioit निश्चित रूप से, यह .electron फ़ाइल होने का पूरा बिंदु है, आप इसे जो चाहें नाम दे सकते हैं, जब तक कि इसमें .electron एक्सटेंशन हो।

यह अभी भी मुझे बहुत साफ नहीं लगता है कि रनटाइम हैंडलर को *.electron को देखना होगा, फिर package.json पर यह निर्धारित करने के लिए कि इलेक्ट्रॉन का कौन सा संस्करण चलाना है, जो फिर package.json पढ़ता है।

@Tribex आपको क्यों लगता है package.json दो बार पढ़ा जाएगा?

• अगर हम रनटाइम जानकारी को .electron फ़ाइल में डालते हैं, तो रनटाइम package.json का उपयोग करके ऐप लॉन्च करेगा, यह मानते हुए कि सब कुछ सही है और असफल-तेज़ नहीं है।
• अगर हम रनटाइम को package.json में सीधे या electron सेक्शन में डालते हैं, तो उसे भी केवल 1 पढ़ने की आवश्यकता होगी। इस तरह, मुझे यकीन नहीं है कि .electron फ़ाइल (विचार?) में क्या रखा जाए, मैं इसके खाली होने पर भी ठीक रहूंगा।

@tribex .electron package.json इंगित कर सकता है, बस कुछ कारणों से, package.json का नाम बदल दिया गया है। इस तरह, आपके पास package.json के लिए NPM और इलेक्ट्रॉन के लिए एक अलग package.json (शायद electron.json ) हो सकता है। क्यों? हो सकता है कि आप चाहते हों कि आपके ऐप में package.json यह जानने के लिए कि पैकेज मैनेजर के साथ किन चीजों को आयात करना है, लेकिन एक बार आयात होने के बाद, आप फ़ाइलों को स्थानांतरित या नाम बदलने की आवश्यकता के बिना इसे चलाना चाहते हैं।

_ app.electron _

{
  "package": "package.json",
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

या

_ myapp.electron _

{
  "package": "electron.json",
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

या, यदि हम सब कुछ package.json में डालते हैं, तो हमारे पास .electron केवल .json का लिंक हो सकता है जिसे हम ऐप खोलने के लिए उपयोग करना चाहते हैं, इसलिए:

_ app.electron _

{
  "package": "package.json"
}

या

_ myapp.electron _

{
  "package": "electron.json"
}

साथ ही, हो सकता है कि आप एक ही निर्देशिका में दो लॉन्चर रखना चाहें, एक क्लाइंट के लिए और दूसरा सर्वर के लिए, क्लाइंट के साथ सर्वर की फ़ाइलों का उपयोग करके केवल एक प्लेयर के साथ एक स्थानीय सर्वर लॉन्च करने के लिए। इस तरह, आपको सभी 99% फ़ाइलों की नकल करने की आवश्यकता नहीं होगी (यह मानते हुए कि आपके पास एक गेम है जो 500+ एमबी फाइलों का उपयोग करता है) और 5-6 फाइलें अलग हैं, और उन्हें दो अलग-अलग निर्देशिकाओं में रखें, लेकिन बस एक अतिरिक्त है फ़ाइल को सर्वर को स्वयं लॉन्च करने में सक्षम होने के लिए। सचमुच, एक ही निर्देशिका में एकाधिक निष्पादन योग्य होने के समान।

अलग से package.electron का नाम package.electron.json या कुछ ऐसा होना चाहिए जिसका विस्तार .json हो ताकि संपादकों और IDE को सिंटैक्स ठीक से निर्धारित किया जा सके।

@StreetStrider मैंने IDEs को पढ़ाया होगा कि .electron वास्तव में मान्य है .json ।
और इससे हमें यह भी पता चलता है कि हमने @sapioit के साथ .json संघों के बारे में चर्चा की । मुझे नहीं लगता कि कोई भी लोकप्रिय ओएस डबल एक्सटेंशन एसोसिएशन का समर्थन करता है। ( .foo.bar )

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

@sapioit फेयर पॉइंट, मुझे लगता है कि मैं आपके साथ पैकेज की ओर इशारा करने के बारे में सहमत हूं। जेसन।

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

हाथ में मुद्दा रनटाइम बनाना है। जेआरई और नेट की तरह। खिलाड़ी नहीं।

@baconface शायद आप विस्तृत कर सकते हैं? यह स्पष्ट नहीं है कि आप यहां क्या भेद कर रहे हैं।

@baconface हाँ, लेकिन JRE और .Net दोनों भी इंस्टाल करने योग्य हैं।
JRE के बिना, .jar फाइलें उतनी ही बेकार हैं जितनी electron रनटाइम के बिना पैकेज।

आदर्श रूप से इस उपकरण को इलेक्ट्रॉन स्थापित करने की प्राथमिक विधि के साथ या उसके रूप में वितरित किया जाएगा, आदर्श रूप से प्रसार समस्या को कम किया जाएगा।

इसके लिए आपको एक निष्पादन योग्य बनाने के लिए केवल एक छोटे उपकरण की आवश्यकता होगी जो एक निश्चित फ़ाइल लॉन्च करेगा, अर्थात् .electron आरोपित। इतना ही आसान।

.lept कमाल लग रहा है, धन्यवाद!

मुझे व्यक्तिगत रूप से लगता है कि किसी भी नए कॉन्फ़िगरेशन का आविष्कार करने की कोई आवश्यकता नहीं है, pkg.engines मुझे यहां काफी सीधा दिखता है (हालांकि इसे कुछ जटिल सेवर अभिव्यक्तियों की अनुमति देनी चाहिए, जैसे 1.x || >=2.5.0 || 5.0.0 - 7.2.3 npm के डॉक्स से, इसलिए इसकी कोई आवश्यकता नहीं है { recommended, compatible, etc } -संरचनाएं जैसे @sapioit के उदाहरणों में, मुझे विश्वास है)। (हालांकि, मैंने lepton फ़ील्ड जोड़ा है, क्योंकि scripts.run आमतौर पर npm start द्वारा लागू किया जाता है, और लेप्टन कुछ हद तक अपने स्वयं के $VARIABLES जोड़कर इसके शब्दार्थ को तोड़ता है ।)

या, अगर हम सब कुछ package.json में डालते हैं, तो हमारे पास .इलेक्ट्रॉन केवल उस .json का लिंक हो सकता है जिसका उपयोग हम ऐप खोलने के लिए करना चाहते हैं

मुझे भी यह एक अच्छा विचार नहीं लगता। यदि हमारे पास एकाधिक प्रवेश बिंदुओं वाला एक पैकेज है, तो भी हम उन सभी को एक पैकेज में रख सकते हैं। जेसन, जैसे हमारे पास अभी scripts नक्शा है। मैं ऐसा कुछ सोच रहा हूँ:

// package.json
{
  "engines": {
    "node": "4.x",
    "electron": "1.x"
  },
  "lepton": {
    "run": "$ELECTRON .",
    "server": "$NODE ./server.js",
    "server-debug": "$NODE ./server.js --debug"
  }
}

# lepton-run [DIR OR TARBALL] [CONFIGURATION]
$ lepton-run . # the default configuration is `run`
$ lepton-run . server
$ lepton-run . server-debug

फिर, यदि आप वास्तव में इसे निष्पादन योग्य फ़ाइलों के रूप में चाहते हैं, तो Linux / macOS पर आप साधारण शेल स्क्रिप्ट (#!shebang सहित 3 पंक्तियाँ) और विंडोज़ पर उपयोग कर सकते हैं... _(ツ)_/¯

सबसे पहले, आप इस आलेख पर एक नज़र डालना चाहेंगे, जो सेवर के लिए एक बेहतर विकल्प प्रदान करता है, जबकि अभी भी वहां सब कुछ के साथ संगत है: Release.Breaking.Feature.Fix या अर्थपूर्ण संस्करण को स्पष्ट संस्करण के साथ क्यों बदला जाना चाहिए जल्द से जल्द

दूसरा, सवाल यह है कि वास्तव में उन्हें कैसे अलग किया जाए। मेरा मतलब है, अगर server.js पहले से ही --debug तर्क को स्वीकार करता है, तो उससे परेशान क्यों हों और लोगों को अपनी फ़ाइल कॉन्फ़िगरेशन की अनुमति न दें। हो सकता है कि सर्वर को क्लाइंट से भिन्न कॉन्फ़िगरेशन की आवश्यकता हो, जैसे क्लाइंट 2.2-2.4 पर काम कर रहा हो और सर्वर केवल 1.4-1.9.2.1 पर काम कर रहा हो ...
जैसा आपने सुझाव दिया है, हम केवल और अधिक सीमित होंगे।

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

अगर मैं डिबग पैरामीटर के साथ सर्वर चलाना चाहता था, तो क्या मैं केवल --debug तर्क के साथ .lept लॉन्च नहीं करूंगा? या मैं उस फ़ाइल को --debug तर्क के साथ लॉन्च करने के लिए एक और फ़ाइल बना सकता हूं। क्या यह इतना आसान नहीं है?
मुझे आशा है कि मैं समझ रहा हूँ ...

सबसे पहले, आप इस लेख पर एक नज़र डालना चाहेंगे, जो सेवर के लिए एक बेहतर विकल्प प्रदान करता है

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

हो सकता है कि सर्वर को क्लाइंट से भिन्न कॉन्फ़िगरेशन की आवश्यकता हो

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

अगर मैं सर्वर को डीबग पैरामीटर के साथ चलाना चाहता हूं, तो क्या मैं बस --debug तर्क के साथ .lept को लॉन्च नहीं करूंगा?

हां क्यों नहीं:

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug --myoption=5
# resolves to:
$ path/to/node ./server.js --debug --myoption=5

यह डुअल-कॉन्फ़िगर पैकेज.json उन मामलों के लिए बहुत अच्छा है जब सर्वर a) क्लाइंट के साथ बहुत सारे कोडबेस साझा करता है, और b) अंतिम उपयोगकर्ताओं द्वारा चलाने का इरादा है। अन्य मामलों में यह सभी को दो रेपो/पैकेज में अलग करने के लिए समझ में आता है, प्रत्येक अपने स्वयं के package.json के साथ।

यह इलेक्ट्रॉन के लिए नहीं है, बल्कि आपके द्वारा बनाई गई परियोजनाओं के लिए है। इलेक्ट्रॉन, संभवतः, उनकी अपनी आवश्यकताओं को पूरा करने के लिए सिमेंटिक वर्जनिंग से प्राप्त अपनी प्रणाली है, और यह संभावना नहीं है कि वे इसे बदलने जा रहे हैं, लेकिन लेप्टन और अन्य परियोजनाओं के लिए जो अब तक _ development hell में नहीं हैं _, सिमेंटिक वर्जनिंग को पूरी तरह से छोड़ना एक अच्छा विचार हो सकता है।

अगर मैं सर्वर को डीबग पैरामीटर के साथ चलाना चाहता हूं, तो क्या मैं बस --debug तर्क के साथ .lept को लॉन्च नहीं करूंगा?

हां क्यों नहीं:

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug --myoption=5
# resolves to:
$ path/to/node ./server.js --debug --myoption=5

नहीं, मेरा मतलब कॉन्फ़िगरेशन में नहीं है, बल्कि लॉन्चर के माध्यम से है। तो यह:

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug 

लेकिन .lept को --myoption=5 तर्क के साथ बिना फाइलों को छुए (उन्हें खोलने के अलावा) लॉन्च करें। चूंकि मुझे पूरा यकीन है कि आप लॉन्चर के माध्यम से तर्क "_push_" कर सकते हैं, आप --debug की आवश्यकता को भी हटा सकते हैं, क्योंकि यदि आप चाहें तो इसे कस्टम तर्क के साथ लॉन्च करेंगे।

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

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

यहां समस्याएं हैं:

1. उपयोगकर्ता जानना चाहते हैं कि उन्हें किस संस्करण के लिए समर्थन की पेशकश की जा रही है।
2. वे बहुत सारे _बेकार संख्या_ याद नहीं रखना चाहते हैं, इसलिए यदि वे संस्करण को याद रखना चुनते हैं, तो वे संस्करण 1.7 (उदाहरण के लिए) की तुलना में संस्करण $ 13 को याद रखने की अधिक संभावना रखते हैं।
3. कुछ लोग तब तक अपडेट नहीं करना चाहते हैं जब तक कि कुछ चीजें नहीं हो जातीं, जैसे कि कितने एनवीडिया ड्राइवर्स को अपडेट नहीं किया जा रहा है क्योंकि थंडरबोल्ट संगतता जोड़े जाने के बाद से, उनके ग्राफिक्स कार्ड बेतरतीब ढंग से बाहर निकल जाते हैं (उपयोगकर्ता/मामले के आधार पर) , या तो कंप्यूटर को बूट करने के बाद, गेम खोलने के बाद या गेम खेलने के कुछ मिनट बाद)। यह एक कारण का एक अच्छा उदाहरण है (लेकिन कई अन्य हैं, जैसे KMPlayer के विज्ञापन या locked on स्वचालित अपडेट ) जो उपयोगकर्ताओं को किसी उत्पाद के नवीनतम संस्करण का उपयोग करने से रोकते हैं। इससे चैंज को देखने में आसानी होती है, इससे जटिलता दूर होती है।

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

@sapioit >= 12.1 जैसी सेवर रेंज समर्थन घोषित करने के लिए पर्याप्त लचीला नहीं है?
यदि रनटाइम का कोई नया संस्करण उपलब्ध है, और यह संस्करण श्रेणी को संतुष्ट करता है, तो ऐप के सभी अगले लॉन्च में नवीनतम संभावित रनटाइम का उपयोग करना चाहिए।

चाहिए? लेकिन क्या होगा यदि वे तकनीकी सीमाओं (जैसे KMPlayer के विज्ञापनों और nVidia ड्राइवर्स के साथ चीज़) के कारण नहीं करने का निर्णय लेते हैं?

@sapioit तो बस सुनिश्चित करें कि आपने अपनी रनटाइम रेंज ठीक से बताई है

@sapioit @YurySolovyov क्या यह चर्चा यहाँ प्रासंगिक है? एक रनटाइम मैनेजर को जो भी वर्जनिंग सिस्टम इलेक्ट्रॉन उपयोग कर रहा है उसका पालन करना होगा। मेरा मानना ​​​​है कि किस संस्करण प्रणाली इलेक्ट्रॉन _ should_ का उपयोग किया जा रहा है, इसकी चर्चा किसी अन्य मुद्दे से संबंधित है।

@Tribex कुछ हद तक। मैं यह कहने की कोशिश कर रहा था कि हमें उन चीजों को अधिक जटिल नहीं करना चाहिए जो पहले से ही मूल रूप से हल हो चुकी हैं। लेकिन मैं मानता हूं कि रनटाइम मैनेजर को इस संबंध में सबसे आसान संभव काम करना चाहिए।

@yurysolovyov तो क्यों न केवल संस्करण संख्या में उतने अनुभागों की अनुमति दी जाए जितनी खिलाड़ी चाहता है?

@sapioit

यह इलेक्ट्रॉन के लिए नहीं है, बल्कि आपके द्वारा बनाई गई परियोजनाओं के लिए है।

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

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

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

@championswimmer इसके साथ पैक किए गए इलेक्ट्रॉन के एक संस्करण के साथ रनटाइम मैनेजर का निर्माण करना दिलचस्प होगा, और एक यूआई यह दिखाने के लिए कि अन्य संस्करण कब डाउनलोड किए जा रहे हैं।

@championswimmer iamale/lepton एक प्रकार का फेंकने वाला संदर्भ कार्यान्वयन है: मैंने इसे इस धागे के चारों ओर तैरने वाले विभिन्न विचारों का परीक्षण करने के लिए रखा है, और कुछ नहीं।

@iamale शायद आपको भ्रम से बचने के लिए इसे रीडमी में बताना चाहिए?

@YurySolovyov हो गया!

वास्तविक कार्यान्वयन के लिए, हमारे पास दो विकल्प हैं: या तो हम नोड.जेएस का उपयोग करते हैं, या सी/++ या गो जैसी संकलित भाषा का उपयोग करते हैं; और नोड के लिए, हमें इसके साथ node.js को बंडल करना होगा (या शायद इसे डाउनलोड किए गए इलेक्ट्रॉन उदाहरणों में से एक पर चलाएं? हमें यह सुनिश्चित करने की आवश्यकता होगी कि यह _any_ sane इलेक्ट्रॉन संस्करण पर चलता है, हालांकि)।

@iamale वास्तव में नहीं, हमें बस एक डिफ़ॉल्ट स्थापित संस्करण को चलाना है। उसके बाद अपडेट इसे नए संस्करण में इन-प्लेस पर स्विच कर सकते हैं।

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

लेप्टन अब इतना बड़ा नाम नहीं हो सकता है कि यह एक छवि प्रारूप है ।

तो... अब हम इसे क्या कहते हैं? Hadron ?

क्वार्क? अगर कोई "मून" नाम लेना चाहता है तो मैं अपनी एक परियोजना का नाम बदल सकता हूं।

क्या नामकरण वास्तव में यहाँ सबसे कम महत्वपूर्ण हिस्सा नहीं है?
क्या हम इंस्टाल/अपडेट/रनटाइम सेमेन्टिक्स पर सहमत हुए?

क्यों न सिर्फ electron ...

ऑप 15 जुलाई। 2016 बजे 13:22 हेफ्ट जोशुआ बेमेन्डरफर नोटिफिकेशन@गीथब.कॉम हेट वोल्गेंडे गेश्रेवेन:

क्वार्क? अगर कोई "मून" नाम लेना चाहता है तो मैं अपनी एक परियोजना का नाम बदल सकता हूं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@yurisolovyov मुझे लगता है कि हम सहमत थे ... कमोबेश।
@ जॉब-वी मैं यही सुझाव दे रहा हूं। चलो बस एक को चुनें और उसके साथ रहें।

@zcbenz क्या आप इस सूत्र को देख रहे हैं?
यदि ऐसा है, तो यहां कुछ दिशा-निर्देश प्राप्त करने के लिए यह कैसे काम करना चाहिए, इस पर कुछ दृष्टि रखना अच्छा होगा।

नमस्ते
इस इलेक्ट्रॉन रनटाइम के बारे में कोई अपडेट?
@zcbenz आप सभी चर्चाओं के बारे में क्या सोचते हैं:

• इलेक्ट्रॉन संस्करण का चयन
• उपयुक्त संस्करण स्थापित करना
• इसे win, linux, mac . में काम करने के लिए तैयार करें
• इसके साथ निर्माण करने के लिए किस उपकरण का उपयोग किया जाता है (पायथन, नोड, गो, सी ++)?
  @YurySolovyov @sapioit आपके शानदार विचारों के लिए धन्यवाद
  @iamale डेबियन आधारित विनाश 'उबंटू ...' के लिए आपका समाधान कार्य है

@alnour-altegani
हाँ, यह किसी भी dpkg-आधारित वितरण के लिए काम करेगा क्योंकि हम बाहरी पैकेजों पर निर्भर नहीं हैं। आरपीएम पैकेज इसी तरह से उत्पन्न किए जा सकते हैं, क्यों नहीं?

मैं सभी इलेक्ट्रॉन चीजों के लिए केंद्रीय रेपो शुरू करने की सोच रहा हूं, यानी आप चला सकते हैं:

sudo sh -c "echo 'deb https://epkg.example.org/ /' > /etc/apt/sources.list.d/epkg.list"
sudo apt-get update
sudo apt-get install min-browser  # or whatever

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

अगर कोई इसके लिए किसी चीज़ पर काम करना शुरू करता है, तो शायद उसे यहाँ लिंक करें...

@sapioit मैंने एक Linux (APT/RPM) समाधान पर काम करना शुरू कर दिया है। एक साधारण सेवा जिसे आप .asar पर अपलोड करते हैं और यह संकुल में परिवर्तित हो जाती है और रिपॉजिटरी में जुड़ जाती है। विंडोज और मैकओएस के लिए भी विस्तार योग्य होना चाहिए, लेकिन अभी उस पर कोई वादा नहीं किया गया है।

@iamale कूल! मुझे बताएं कि जब आप इसे विंडोज़ पर काम कर रहे हों।

Linux के लिए फ़्लैटपैक रनटाइम बनाने के बारे में क्या? इस तरह, रनटाइम को कई ऐप्स के बीच साझा किया जा सकता है, और आपको सैंडबॉक्सिंग भी मिलती है।

फ़्लैटपैक के systemd पर अपनी निर्भरता को हटाने के साथ यह संभवतः अपस्ट्रीम पैकेजिंग के लिए लिनक्स पर सार्वभौमिक हो जाएगा।

रनटाइम को कई ऐप्स के बीच साझा किया जा सकता है

मैंने सोचा था कि फ्लैटपैक के साथ यह संभव नहीं होगा?..

@iamale Flatpak को रनटाइम साझा करने के लिए डिज़ाइन किया गया है - ऐप डेवलपर एक रनटाइम चुनते हैं, उस रनटाइम के लिए SDK इंस्टॉल करते हैं, फिर flatpak-builder या इससे मिलते-जुलते ऐप का निर्माण करते हैं। फिर जब उपयोगकर्ता ऐप इंस्टॉल करता है, तो फ़्लैटपैक संबंधित रनटाइम इंस्टॉल करता है।

@ moosingin3space स्पष्टीकरण के लिए धन्यवाद! तब यह निश्चित रूप से विचार करने योग्य है।

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

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

ऐसा प्रतीत होता है कि यहाँ फ़्लैटपैक पर काम हो रहा है: https://github.com/endlessm/electron-installer-flatpak

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

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

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

दोबारा, मैं सोच रहा हूं कि क्या इस पर विचार किया गया है या यदि कोई परियोजना पहले से ही ऐसा कर रही है। यदि नहीं, तो शायद एक परी नेतृत्व करने के लिए जीथब प्रबंधन के कानों में एक शब्द डाल सकती है ????

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

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

उदाहरण के लिए, एक नया ऐप चलाने से एक अस्थायी फ़ोल्डर में इलेक्ट्रॉन के आवश्यक संस्करण की प्रतिलिपि बनाई जाएगी और रनटाइम ( asar फ़ोल्डर की सामग्री) को डिफ़ॉल्ट फ़ाइल स्थान में स्थानांतरित कर दिया जाएगा, जबकि वैकल्पिक enviroment फ़ोल्डर (3 सबफ़ोल्डर के साथ, windows , linux , macosx ) में ऐसी फ़ाइलें होनी चाहिए जो डिफ़ॉल्ट फ़ोल्डर पर चिपकाई जाएंगी, इसकी सामग्री को अधिलेखित कर देंगी।

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

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

सभी को नमस्कार, भले ही मैं JS-केंद्रित दुनिया में नहीं हूं, मुझे हाल ही में _Electron_ के समान एक विचार आया था (जिसे मैं जानता था, लेकिन विकास के लिए उपयोग नहीं करता) लेकिन व्यापक दर्शकों के साथ; इसे बहुत ही सरल तरीके से रखने के लिए: _वेब तकनीकों को GUI तक सीमित करें और API प्रदान करें।_

इसलिए अर्थ-संस्करण वाली साझा लाइब्रेरी / रनटाइम (_Blink_, _Skia_, आदि के शीर्ष पर निर्मित; शायद - "आधुनिक" - _C++_) में चलते रहें और डेवलपर्स को बाइंडिंग का उपयोग करके भाषा चुनने दें ...
उदाहरण के लिए आप _JS_ चाहते हैं, _Node.JS_ का उपयोग करें; आप _C++_ चाहते हैं, कोई बात नहीं; आप चाहते हैं _Python_, मानक _CPython_ के साथ संभव होना चाहिए; और कुछ ? शायद _SWIG_ मदद कर सकता है। (लगभग) किसी भी मामले में, हम जीतते हैं।

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

तो प्रारंभिक बिंदु _Electron_ प्रोजेक्ट का "विभाजन" होना चाहिए (इसमें भौतिकी से संबंधित नाम भी होना चाहिए, इस तथ्य को देखते हुए कि आप वास्तव में इसकी परवाह करते हैं) ... :)

हम इलेक्ट्रॉन के लिए एक ऐडऑन भी नहीं कर सकते हैं, लेकिन मुझे लगता है कि उसे उतनी सफलता नहीं मिलेगी, जब तक कि बहुत सारे विज्ञापन न हों।

@dezzeus इस तर्ज पर एक प्रयास किया गया था जिसके पहले फिजूलखर्ची हुई थी। ब्रीच ब्राउज़र को होस्ट करने के उद्देश्य से थ्रस्ट रनटाइम पर एक नज़र डालें।

मैंने इस लंबे और आकर्षक सूत्र को दो बार पढ़ा, क्योंकि मुझे इस दिशा में और गति देखना अच्छा लगेगा। यहाँ @zcbenz का अंतिम कथन है, मेरा मानना ​​है कि यह अभी भी प्रासंगिक है:

इसे लागू करने में कोई तकनीकी बाधा नहीं है, पूरी बात सिर्फ एक इलेक्ट्रॉन ऐप ही हो सकती है। लेकिन समस्या यह है कि इसे लागू करना आसान नहीं है, सभी विवरणों को ध्यान में रखते हुए, मुझे लगता है कि _इस पर पूर्णकालिक काम करने वाली एक छोटी टीम की आवश्यकता है_, मुझे यकीन नहीं है कि यह कभी होगा या नहीं।

(जोड़ा गया जोर) - मैं इसकी व्याख्या कैसे करता हूं, अगर समाधान कभी बनाया जा रहा है, तो यह सामुदायिक प्रयास और/या गिटहब और अन्य संगठनों की व्यावसायिक जरूरतों पर निर्भर करेगा जिसमें हिस्सेदारी है।

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

ये अन्वेषण और प्रगति के निश्चित चरण हैं, और यह मुझे आशा देता है कि इस प्रक्रिया से उत्पादन-योग्य सामान्य समाधान पैदा होंगे।

यह देखकर अच्छा लगा कि अभी भी इंसानियत में विश्वास रखने वाले लोग हैं।

इसे उत्पाद बनने से रोकने वाली एकमात्र चीज इस उत्पाद (अवधारणा) के निर्माण से तत्काल व्यावसायिक अवसरों की कमी है।

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

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

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

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

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

हमारे पास दो प्रकार की चीजें हैं जिन्हें यहां अपडेट करने की आवश्यकता है:

• इलेक्ट्रॉन स्वयं, जो इलेक्ट्रॉन संस्करण का उपयोग करता है और
• ऐप्स, जिनके लिए हमें वास्तव में SemVer या किसी भी चीज़ की परवाह करने की आवश्यकता नहीं है क्योंकि उनके पास आम तौर पर API नहीं होता है (जब तक कि वे किसी प्रकार के एडऑन सिस्टम का उपयोग नहीं करते हैं)।

हालांकि अगर हमें कई वर्जनिंग सिस्टम का समर्थन करने की आवश्यकता है, तो शायद हमारे पास package.json में कुछ सेटिंग हो सकती है, जैसे सेवर के लिए "breakingVersionComponents": 1 $#$ और स्पष्ट वर्जनिंग या इलेक्ट्रॉन वर्जनिंग के लिए 2 ?

(एक अन्य विकल्प संस्करण में एक और विभाजक जोड़ना होगा, जैसे 1.3:3.7 जो ब्रेकिंग और नॉन-ब्रेकिंग भागों को अलग करेगा। सेवर फिर x:y.z और इलेक्ट्रॉन वर्जनिंग x.y:z बन जाता है। यह होगा वहाँ हर एक उपकरण को तोड़ दो, हालाँकि, मुझे विश्वास है।)

@jorangreef यदि प्रत्येक ऐप में अभी भी अपनी इलेक्ट्रॉन बाइनरी है, तो यह कई इलेक्ट्रॉन ऐप खोलने पर अतिरिक्त रैम उपयोग की समस्या को ठीक नहीं करेगा।

मैंने @ joshuawarner32 द्वारा एक पुरानी टिप्पणी देखी, जिसे मैंने अनदेखा कर दिया था। वह पहले से ही काम कर रहे उदाहरण का उल्लेख करता है, अभी तक एक सामान्य-उद्देश्य समाधान नहीं है, लेकिन सारांश यह है:

- Deploy .asar.gz files for several different apps on a server
- Distribute a single build of atom-shell to users, which doesn't bundle any code for specific apps
- On app startup, download the appropriate .asar.gz file (if it's not there, or there's a more recent one on the server). Extract it and run the contained app.
- Our atom-shell build accepts a --app argument to specify which app to download/run

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

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

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

oss प्रोजेक्ट्स के लिए, हम npm को होस्टिंग के रूप में उपयोग कर सकते हैं, क्लोज्ड सोर्स वाले के लिए, हमें पैकेज मैनेजर को .asar फ़ाइल को डाउनलोड करने के लिए इंगित करने में सक्षम होना चाहिए, और शायद कुछ और मेटाडेटा। सवाल यह है कि इस तरह का प्रबंधक कैसा दिखेगा (और कहा जाता है)

साथ ही, मुझे आश्चर्य है कि क्या हमें ऐप्स इंस्टॉल करने के लिए वास्तव में एक अलग कमांड की आवश्यकता है, शायद बस
electron install atom पर्याप्त होगा?

बस इसे नोड वीकली पर देखा:

इलेक्ट्रिनो लोकप्रिय और शक्तिशाली इलेक्ट्रॉन का प्रायोगिक फेदरवेट विकल्प है। यह इलेक्ट्रॉन में उपलब्ध एपीआई के एक छोटे से हिस्से को लागू करता है, लेकिन आउटपुट ऐप का आकार बहुत छोटा है।

https://medium.com/@pauli/put -your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297

https://github.com/pojala/electrino

@YurySolovyov बंद स्रोत परियोजनाओं को npm में भी प्रकाशित होने में कोई समस्या नहीं होनी चाहिए - वहाँ पहले से ही कुछ Node.js हैं, अर्थात संलग्न करें। (तकनीकी रूप से, यह npm में नहीं है, बस एक लोडर है, लेकिन मैं वैसे भी नहीं देख सकता कि कैसे साइडलोडिंग .asar's मदद करेगा क्योंकि वे अभी भी अनपैक किए जा सकते हैं।)

मैं बस यह सोचने की कोशिश कर रहा था कि हम मौजूदा पारिस्थितिकी तंत्र का यथासंभव पुन: उपयोग कैसे कर सकते हैं।

सुनिश्चित नहीं है कि हम चाहते हैं ...

@jorangreef यदि प्रत्येक ऐप में अभी भी अपनी इलेक्ट्रॉन बाइनरी है, तो यह कई इलेक्ट्रॉन ऐप खोलने पर अतिरिक्त रैम उपयोग की समस्या को ठीक नहीं करेगा।

@ जोप-वी नहीं, ऐसा नहीं होगा। मैं चीजों को उलझाना नहीं चाहता और एक राक्षस के साथ समाप्त होना चाहता हूं। विचार यह है कि एक महान इंस्टॉलर/ऑटो-अपडेटर है जो इस मुद्दे को खोलने वाली टिप्पणी में अधिकांश समस्याओं को हल करता है: https://github.com/electron/electron/issues/673#issue -44580957

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

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

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

वैकल्पिक रूप से, मध्यम अवधि में कम से कम macOS पर, APFS फाइलों को संदर्भ द्वारा कॉपी करेगा, हुड के नीचे पारदर्शी डिडुप्लीकेशन के साथ, डिस्क फुटप्रिंट को कम करेगा। यह हार्डलिंक से बेहतर होगा क्योंकि यह अलगाव को बरकरार रखेगा (कॉपी-ऑन-राइट)।

@jorangreef ऐप्स के लिए अलग इलेक्ट्रॉन बायनेरिज़ का उपयोग करने का क्या मतलब है? आप किस तरह के अलगाव की बात कर रहे हैं? क्षमा करें अगर यह एक बेवकूफ सवाल है, लेकिन मुझे यह समझ में नहीं आया।

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

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

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

@jorangreef धन्यवाद! मुझे लगता है कि यह क्लासिक एपीटी/आरपीएम रिपॉजिटरी की तरह है, बस अधिक "स्मार्ट" (आपकी निर्भरता या जो कुछ भी घोषित करने की आवश्यकता नहीं है)।

सवाल यह है कि इस तरह का प्रबंधक कैसा दिखेगा (और कहा जाता है)

Minifitron (मिनीफाइड इलेक्ट्रॉन) के बारे में क्या?

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

और ऐप्स को इंस्टॉल या छोटा करने का एक विकल्प होना चाहिए, इंस्टालेशन उन्हें इलेक्ट्रॉन के एक नए उदाहरण के रूप में छोड़ देगा, जबकि minified md5 का उपयोग उन फ़ाइलों को हटाने के लिए करेगा जिन्हें .asar के अनारक्षित द्वारा नहीं बदला गया है।

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

(फिर से, ऐप लॉन्च होने तक, मुझे लगता है कि वैसे भी रनटाइम के कई उदाहरण पहले से ही होंगे .. इसलिए तार्किक नहीं हो सकता है ..)

@ इलियट-अकीरा को इस धागे को पढ़ते समय एक समान विचार था।

(फिर से, ऐप लॉन्च होने तक, मुझे लगता है कि वैसे भी रनटाइम के कई उदाहरण पहले से ही होंगे .. इसलिए तार्किक नहीं हो सकता है ..)

खैर, यह इसे जांचने के लिए पर्याप्त लोड कर सकता है, और यह देखने के बाद कि रनटाइम साझा करने के लिए कोई "इलेक्ट्रॉन साथी" उपलब्ध नहीं है, बाकी को लोड करें।

हालांकि यह सुरक्षा संबंधी कई चिंताएं पैदा करेगा। एक दुष्ट ऐप दूसरों को रनटाइम के संशोधित संस्करण की पेशकश कर सकता है, और उनके डेटा तक पहुंच सकता है। हो सकता है कि यह एक साझा मेमोरी सेगमेंट का उपयोग कर सकता है, इसे केवल पढ़ने के लिए बना सकता है, और "उपयोगकर्ता" ऐप्स (जो पहले लॉन्च किए गए ऐप के रनटाइम का उपयोग करते हैं) रनटाइम को चेकसम कर सकते हैं, लेकिन सभी लक्षित ओएस के लिए इन्हें विकसित करना एक दुःस्वप्न हो सकता है ( मुझे यह भी नहीं पता कि यह विंडोज़ में मौजूद है या नहीं; मुझे लगता है कि यह जरूरी है)।

यदि केवल जिज्ञासा के लिए, क्या यह असंवेदनात्मक है? क्या यह उतना ही होगा, या एक अलग साझा रनटाइम से कहीं अधिक काम हो सकता है? क्या यह अन्य अतिरिक्त मुद्दे पैदा करता है?

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

@jorangreef यदि किसी डेवलपर ने इलेक्ट्रॉन बाइनरी को संशोधित किया है, तो क्या उन्हें केवल पुल अनुरोध नहीं बनाना चाहिए?

@ जोप-वी वे कर सकते हैं, लेकिन वे अपना कांटा भी बनाए रख सकते हैं। यदि वे नहीं चाहते हैं तो वे स्रोत प्रकाशित भी नहीं कर सकते हैं - एमआईटी लाइसेंस उन पर कोई दायित्व नहीं डालता है।

@jkurei आगे विचार का पता लगाने के लिए, मैं कुछ तरीकों की कल्पना करता हूं जो काम कर सकते हैं:

1) इलेक्ट्रॉन या ऐप के चारों ओर एक पतला देशी आवरण, जो "लॉन्चर" होगा। यह इलेक्ट्रॉन और उसके संस्करण के पहले से चल रहे इंस्टेंस की जांच करता है: यदि संगत हो, तो बाकी लॉन्च प्रक्रिया को उस इंस्टेंस को सौंप दें और बाहर निकलें; यदि नहीं, तो इलेक्ट्रॉन का अपना उदाहरण लॉन्च करना जारी रखें।

2) एक जावास्क्रिप्ट लाइब्रेरी जो ऐप्स स्वयं लॉन्चर के रूप में मुख्य प्रक्रिया में आयात कर सकती है। यह ऊपर के समान प्रोटोकॉल को लागू कर सकता है: एक इलेक्ट्रॉन इंस्टेंस के अस्तित्व को प्रसारित करें, और अन्य ऐप्स (उसी लाइब्रेरी का उपयोग करके) को खोजने और इसके साथ संवाद करने का एक तरीका - शायद नेटवर्क पोर्ट के माध्यम से ..?

@ इलियट-अकीरा मुझे लगता है, वैसे, पहले से ही किसी प्रकार का आदिम "प्रोटोकॉल" है जिसके बारे में आप बात कर रहे हैं; यह app.makeSingleInstance के पीछे वह चीज है जो किसी भी तरह से पहले से चल रही इलेक्ट्रॉन प्रक्रियाओं का पता लगाती है और यदि वे एक ही ऐप हैं या नहीं (शायद पूर्ण निष्पादन योग्य पथ प्राप्त करके)।

@iamale मैं देखता हूं, वर्तमान ऐप निर्देशिका (एक अद्वितीय पहचानकर्ता के रूप में) पंजीकृत करने के लिए विधि क्रोमियम के मूल ProcessSingleton वर्ग का उपयोग करती है। हां, मैं app.on('ready') से पहले शुरू होने के लिए कुछ इस तरह चित्रित कर रहा था। इसलिए, उस विशेष ऐप के मौजूदा उदाहरण की जाँच करने के बजाय, यह इलेक्ट्रॉन के किसी भी उदाहरण की जाँच कर सकता है - फिर संगत होने पर "लॉन्च प्रक्रिया को सौंप दें"।

दूसरे कोण के लिए, मुझे node-ipc नामक एक मॉड्यूल मिला जो अलग Node.js प्रक्रियाओं के बीच संचार कर सकता है। हो सकता है कि इसका उपयोग विशुद्ध रूप से JS लेयर पर लॉन्च प्रक्रिया को प्रबंधित करने के लिए किया जा सके।

इंटर-प्रोसेस संचार के लिए node-ipc का उपयोग करते हुए, एकाधिक ऐप्स के बीच एकल इलेक्ट्रॉन इंस्टेंस साझा करने का एक मूल उदाहरण यहां दिया गया है: https://github.com/eliot-akira/singletron-example।

IPC हब इसका अपना मॉड्यूल है , जो node-ipc के आसपास एक पतला आवरण है। इसका इनिशियलाइज़ेशन मुख्य प्रक्रिया में है, नीचे main.js ।

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

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

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

इसके अलावा, अच्छा और साफ दिखता है, धन्यवाद!

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

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

मुझे लगता है कि नए आने वाले लोगों के लिए फिर से किसी तरह का सारांश देना मददगार होगा, जैसा कि आधे साल पहले किसी ने किया था।

इसके अलावा, अंतिम उपयोगकर्ता क्या करता है?

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

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

एक डेवलपर के रूप में, मैं एक क्लिक के साथ (सर्वोत्तम रूप से) ऐसा डाउनलोड करने योग्य पैकेज बनाने में सक्षम होना चाहता हूं। यह एक क्लिक मेरे कोड को कुछ भंडार (प्ले/वेब/ऐप स्टोर के समान) में अपलोड करना चाहिए और मेरे लिए एक .exe/.app/.deb पैकेज बनाना चाहिए जिसे मैं दुनिया के साथ साझा कर सकता हूं।

मैं अभी तक इलेक्ट्रॉन के साथ शामिल नहीं हूं, क्योंकि मैं सी # के लिए इलेक्ट्रॉन और इलेक्ट्रॉन-एज का उपयोग करके एक छोटा मॉड इंस्टॉलर बना रहा हूं।

मैं भोला हो सकता हूं, लेकिन afaik, एकमात्र "वास्तविक" कारण है, चीजें संगत क्यों नहीं हैं + -0.1 संस्करण यह है कि इलेक्ट्रॉन के हर संस्करण के लिए .node फ़ाइलों को फिर से बनाया जाना है। क्या ये .node फ़ाइलें किसी प्रकार के क्लाउड समाधान का उपयोग करके सेटअप के दौरान नहीं बनाई जा सकतीं?

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

इमो, एकमात्र समस्या यह है कि इलेक्ट्रॉन का एलटीएस संस्करण हर किसी पर भरोसा करने के लिए तैयार नहीं है।

उस एलटीएस संस्करण के साथ, ऑटोअपडेटिंग, डिडुप्लिकेटिंग, संस्करण प्रबंधन और अन्य सभी चीजों का निर्माण केक का एक टुकड़ा होना चाहिए।

मेरे द्वारा प्रस्तावित इंस्टॉलर समाधान में अतिरिक्त लाभ भी है, कि उपयोगकर्ता वास्तव में सॉफ़्टवेयर के फ़ोल्डर को नहीं देखता है, इसलिए हमें इसे पैकेज करने की आवश्यकता नहीं है। जो भी हो और उसे कहीं सुरक्षित स्थानांतरित करने के लिए कहें। इसके अलावा, स्थापना के दौरान कई "सबएक्ज़ीक्यूटेबल्स" जोड़े जा सकते हैं (उदाहरण के लिए मल्टीप्लेयर गेम, मल्टीपल "प्रोफाइल" आदि)। इन एक्जिक्यूटिव को केवल somelaunchername.electron कहा जाना चाहिए, लेकिन Json प्रारूप में सॉफ़्टवेयर को लॉन्च करने के तरीके के बारे में जानकारी के साथ (जैसे index.html को लोड करने के लिए और उस तरह की सामग्री)। नोड_मॉड्यूल्स को निष्पादन योग्य के बीच साझा किया जाना चाहिए (जब तक कि देव को प्रत्येक निष्पादन योग्य के लिए मॉड्यूल के विभिन्न संस्करणों का उपयोग करने की आवश्यकता न हो)। यह तीन नोड_मॉड्यूल फ़ोल्डर होने से प्राप्त किया जा सकता है। प्रत्येक निष्पादन योग्य के लिए एक और दोनों के लिए एक। package.json में केवल सामान्य जानकारी होगी। प्रत्येक .electron फ़ाइल को (imo) package.json में मानों को अधिलेखित करने में सक्षम होना चाहिए।

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

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

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

आप लोग क्या सोचते हैं?

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

@zcbenz @paulcbetts क्या आपने साझा डीएल का उपयोग करने पर विचार किया है? क्या exe के आकार को कम करना और सभी इलेक्ट्रॉन कोड को dll में स्थानांतरित करना संभव है (इसलिए, exe में केवल न्यूनतम कोड रखें)? यह अच्छा है कि चूंकि इलेक्ट्रॉन 1.7.5 साझा सी रनटाइम को node.dll और exe से हटा दिया जाता है। अब, 30 एमबी कोड पहले से ही डीएलएल फाइलों में है (लेकिन एक्सई अभी भी बड़ा है - 80 एमबी), इसलिए, मैं इसके साथ प्रयोग करना शुरू कर सकता हूं।

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

क्या क्रोमियम पुराने संस्करणों के लिए सुरक्षा सुधार भी करता है? मुझे एक मजबूत भावना है कि उनकी नीति "सुरक्षित होने के लिए नवीनतम संस्करण में अपग्रेड करें" है। क्रोमियम से सुरक्षा अपडेट के बिना, इलेक्ट्रॉन का एक एलटीएस एक लंबा रास्ता तय करता है।

@ sedwards2009 लेकिन क्या वाकई इतने सारे खतरे हैं? निश्चित रूप से, मैं यहां भोला हो सकता हूं, लेकिन हम उपयोगकर्ताओं को खुले इंटरनेट से नहीं, बल्कि (ज्यादातर) स्थानीय ऐप्स से बचा रहे हैं। किसी भी .exe फ़ाइल को चलाना 10000 गुना अधिक खतरनाक है और .exe वायरस लिखना भी 10000 गुना आसान है जब मेरे वैध इलेक्ट्रॉन ऐप के इंस्टॉलर को भी AVG द्वारा वायरस कहा जाता था।

तो मेरे लिए, उस सुरक्षा को हर 6 महीने में "नवीनीकरण" करना पर्याप्त है। इसके अलावा, हर डेवलपर को क्रोमियम के अपने स्वयं के पैकेज्ड संस्करण का उपयोग करने देने के लिए यह अधिक असुरक्षित है, वे वैसे भी इसके साथ और अधिक बुराई कर सकते हैं जिसे हम रोक नहीं सकते (साझा रनटाइम के साथ या अन्यथा)

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

ठीक है, तो एलटीएस संस्करण प्राप्त करना कितना आसान है? क्या हम वर्तमान संस्करण को चुनकर इसे एलटीएस संस्करण घोषित नहीं कर सकते?

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

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

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

या क्या आपका मतलब है कि हमारे पास अधिकांश रनटाइम साझा किया गया है और आवश्यकतानुसार अलग-अलग हिस्सों को स्विच कर दिया गया है? यह समझ में आता है, लेकिन मुझे लगता है कि इसे लागू करना मुश्किल है

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

मुझे लगता है कि नोड के पास ऐसा कुछ था:

• कुछ डेवलपर्स नवीनतम v8 चाहते थे, और टूटने को सहन करने के लिए ठीक थे
• बड़ी कंपनियां स्थिरता और दीर्घकालिक समर्थन चाहती थीं।

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

ठीक है अगर हर इलेक्ट्रॉन ऐप एक ही रनटाइम का उपयोग करता है और सिर्फ उस रनटाइम के लिए विशेष रूप से बनाए गए .asar पैकेज के साथ जहाज करता है, तो चीजें काम करेंगी, है ना?

हाँ, लेकिन आप कभी-कभी नया क्रोम और नोड चाहते हैं, है ना?

हाँ, लेकिन मैं 6 महीने एनपी के लिए एक ही नोड/क्रोम रखने के साथ रह सकता था। नोड के पास वैसे भी एक एलटीएस संस्करण है और मैंने जो देखा है उससे क्रोम उतना नहीं बदलता है। इमो, हर ऐप इंस्टाल पर 100 एमबी की बचत करने का लाभ थोड़ी गति को बढ़ाता है और एक बार क्रोमियम / इलेक्ट्रॉन का एक नया संस्करण बाहर हो जाता है। इसके अलावा, एक बार जब हम डेवलपर्स को बोर्ड पर ले लेते हैं, तो रनटाइम के नए संस्करणों के बीच के समय को कम करना बहुत कठिन नहीं होना चाहिए। फिर हम रनटाइम के नवीनतम संस्करण और एक या दो पुराने संस्करण का समर्थन कर सकते हैं।

हर 6 महीने में .node फ़ाइलों का पुनर्निर्माण करना बहुत कठिन नहीं होना चाहिए जैसा कि मुझे लगता है

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

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

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

कई ऐप्स स्वयं को खुले वेब पर प्रदर्शित नहीं करते हैं, और वे पुराने इलेक्ट्रॉन पर ठीक चलेंगे। लेकिन दूसरा चरम बहादुर जैसा कुछ है जो एक वेब ब्राउज़र के रूप में खुद को उजागर करने के अलावा और कुछ नहीं करता है। :-)

@sedwards2009 तुम, लेकिन अगर हम सबकी और उनकी माँ की देखभाल करना शुरू कर दें, तो हम कोई प्रगति नहीं करेंगे। कुछ न करने के हमेशा कारण होंगे। 100% देवों को बोर्ड पर नहीं लाना केवल एक बलिदान है जो हमें करना है। अगर उन्हें वास्तव में सुरक्षा चाहिए/चाहते हैं, तो वे इसे मैन्युअल रूप से प्राप्त कर सकते हैं।

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

@CxRes लेकिन हम इलेक्ट्रॉन के किस संस्करण का समर्थन करते हैं? मेरी परियोजना में, मुख्य समस्या इलेक्ट्रॉन के विशिष्ट संस्करण (नोड नहीं) के खिलाफ .node फ़ाइलों का पुनर्निर्माण करना था।

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

क्या मुझसे कोई चूक हो रही है? इमो, समस्या इलेक्ट्रॉन है, नोड नहीं

ठीक है, मैं इसे एक उदाहरण के साथ फिर से समझाने की कोशिश करता हूं:

• नोड एलटीएस वर्तमान में 6.11.1 . पर है
• इसलिए हम इलेक्ट्रॉन के उच्चतम संस्करण का उपयोग करना चाहते हैं जो आधिकारिक तौर पर नोड के उच्चतम संस्करण के साथ बनाया गया था जो कि स्थिति को संतुष्ट करता है <=6.11.1>=6.0.0
• नोड 6 का उपयोग करके निर्मित इलेक्ट्रॉन का उच्चतम संस्करण इलेक्ट्रॉन 1.4.15 है जो नोड 6.5.0 . के साथ बनाया गया है
• तो इलेक्ट्रॉन 1.4.15 वह जगह है जहां हम इलेक्ट्रॉन एलटीएस के लिए कांटा करते हैं और हम इसे 6.11.1 के साथ पुनर्निर्माण करते हैं (और इसी तरह जब तक नए नोड v6 रिलीज नहीं होते हैं)

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

उन देवों के बारे में जो नवीनतम और महानतम चाहते हैं?

@CxRes @CiriousJoker आइए यहां विषय से दूर रहें। कोई भी तकनीकी कारण विभिन्न इलेक्ट्रॉन संस्करणों के उपयोग को रोकता नहीं है। विखंडन किसी भी स्थिति में होगा (डेवलपर ने एक वर्ष पहले जारी किया गया ऐप और भूल गया, हाल ही में जारी किए गए किसी अन्य डेवलपर का अन्य ऐप और दूसरे संस्करण का उपयोग करता है)।

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

ऊपर @CiriousJoker कमेंट भी देखें:

हाँ, लेकिन अगर हम सबकी और उनकी माँ की देखभाल करना शुरू कर दें, तो हम कोई प्रगति नहीं करेंगे।

@develar ठीक है। लेकिन जैसा कि आप बताते हैं कि यह एक तकनीकी समस्या नहीं है, यह राजनीतिक है (एक ऐसे निर्माण पर सहमत होना जो ज्यादातर लोगों के लिए लगातार काम करता है जैसे कि बोझ साझा हो जाता है)।

तो अब हम क्या करें? क्या हम एक एलटीएस संस्करण चुनते हैं और शुरू करते हैं या मॉड्यूलर डीएलएस के साथ एक-फिट-सभी रनटाइम बनाने की कोशिश करके इसे सभी के लिए काम करने के लिए समाधान खोजने का प्रयास करते हैं (जैसा कि @ डेवेलर सुझाव देता है कि मैं सही ढंग से समझता हूं)

@CiriousJoker विशेष इलेक्ट्रॉन संस्करण के लिए साइड-बाय-साइड असेंबली। जैसे ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 ।

@develar मुझे Google पर वह इलेक्ट्रॉनरंटाइन असेंबली चीज़ नहीं मिल रही है, क्या आप एक लिंक या smth प्रदान कर सकते हैं?

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

हम (या वास्तव में आप लोग) इस बारे में वर्षों से बात कर रहे हैं, लेकिन अगर कोई शुरू नहीं होता है, तो कुछ भी नहीं बदलने वाला है और हम विचारों पर चर्चा करने और शुरू न करने के तरीके खोजने के लिए यहां और 3 साल बैठेंगे।

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

जो मुझे वर्षों जैसा लगता है, उसके लिए उन्होंने इसे हल नहीं किया, इसलिए मैं इसके बारे में निराशावादी हूं। ज़रूर, यह बहुत बढ़िया होगा, लेकिन क्या वे सक्रिय रूप से इस पर काम कर रहे हैं?

@CiriousJoker जैसा कि ऊपर बताया गया है, मैं इलेक्ट्रॉन-बिल्डर में विंडोज़ के लिए साझा इलेक्ट्रॉन रनटाइम समर्थन पर काम कर रहा हूं। मैंने प्रगति को ट्रैक करने के लिए https://github.com/electron-userland/electron-builder/issues/1942 दायर किया है। मुझे उम्मीद है कि यह 1 महीने में उपयोग के लिए तैयार हो जाएगा।

@develar मेरा बुरा, इसे अनदेखा कर दिया होगा .. उस स्थिति में, शुभकामनाएं, अगर आप इसे बना सकते हैं तो बहुत बढ़िया होगा!

अगर किसी को सबफाइल कंटेंट-डिफाइंड-चंकिंग डिडुप्लीकेशन में दिलचस्पी है, जिसे पहले https://github.com/electron/electron/issues/673#issuecomment -157980607 में थ्रेड में संदर्भित किया गया है, तो मैंने इसे ओपन सोर्स किया है: https:// github.com/ronomon/deduplication

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

मैं हाल ही में इस समस्या के बारे में सोच रहा था। तब मैंने अपने स्मार्टफोन पर एक नज़र डाली: फेसबुक ऐप 600 एमबी बड़ा है। क्रोम 325एमबी बड़ा है, मेसेंजर 300एमबी बड़ा है... तो डेस्कटॉप पर 120एमबी ऐप, मुझे वास्तव में परवाह नहीं है...

आकार आज कोई समस्या नहीं है। रैम और बिजली की खपत है।

_संपादित करें: यदि आप असहमत हैं, तो बेझिझक साझा करें क्यों_

विंडोज प्लेटफॉर्म के लिए, @develar का इलेक्ट्रॉन-बिल्डर (इलेक्ट्रॉन-यूजरलैंड/इलेक्ट्रॉन-बिल्डर#1942) के साथ प्रयास साझा रनटाइम हासिल करने के करीब है।

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

प्रगतिशील वेब अनुप्रयोग (PWA) इस समस्या का आंशिक समाधान हैं। Android पर आप PWA को होम स्क्रीन पर जोड़ सकते हैं और यह असली एपीके की तरह काम करेगा। Chrome टीम अब डेस्कटॉप पर PWA को स्थापित करने में सक्षम बनाने के लिए काम कर रही है (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/), Microsoft पीडब्लूए (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) का समर्थन करने में भी रुचि दिखाता है और मुझे आशा है कि फ़ायरफ़ॉक्स और सफारी जल्द ही पकड़ लेंगे। यदि डेवलपर रुचि दिखाते हैं तो अनुपलब्ध API (उदा. मूल फ़ाइल सिस्टम एक्सेस) जोड़ दिए जाएंगे.
अधिकांश वेब आधारित इलेक्ट्रॉन अनुप्रयोगों को आसानी से पीडब्ल्यूए में परिवर्तित किया जा सकता है, लेकिन मैं एटम, वीएससीओडी जैसे लोगों के बारे में निश्चित नहीं हूं - मूल कोड को शायद वेबएसेप्ली में फिर से लिखना होगा।

@develar के पास इस विचार के बारे में कोई प्रगति है?

रिलीज होने पर मैं उपयोग करूंगा!

हाल ही में इस बारे में जानने के बाद, मैं बस अपनी राय देना चाहता था। हालांकि मैंने पूरे मुद्दे को नहीं पढ़ा है, इसलिए मैं अनजाने में कुछ चीजें दोहरा सकता हूं।

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

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

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

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

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

@octacian मुझे लगने लगा है कि PWA एक बेहतर विकल्प है। सार्वभौमिक नहीं, हालांकि - आप PWA का उपयोग करके _सब कुछ_ नहीं कर सकते हैं - लेकिन निश्चित रूप से कस्टम कैलकुलेटर जैसी चीजों के लिए वे पर्याप्त से अधिक होने चाहिए।

अब हमें डेस्कटॉप पर PWA सपोर्ट के उभरने का इंतजार करना होगा।

मुझे यह भी लगता है कि इस तरह की प्रणाली के साथ, 1- एम्बेडेड/छोटे सिस्टम में शिप करना आसान होगा, और 2- भविष्य में मोबाइल उपकरणों के लिए इलेक्ट्रॉन जैसा ऑपरेटिंग सिस्टम बेस बनाया जा सकता है।

@yasinaydin पहले से ही LG WebOS है। (फ़ायरफ़ॉक्स ओएस भी हुआ करता था, लेकिन वह बंद हो गया है)

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

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

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

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

@jacobq यदि आप नहीं जानते हैं, तो Microsoft इलेक्ट्रॉन का स्वामी है।

यदि आप नहीं जानते हैं, तो Microsoft इलेक्ट्रॉन का स्वामी है।

@Jop-V कृपया इसके लिए एक उद्धरण जोड़ें; मुझे नहीं लगता कि यह सही है। Electrojs.com फ्रंट पेज कहता है:

इलेक्ट्रॉन एक ओपन सोर्स प्रोजेक्ट है जिसे GitHub और योगदानकर्ताओं के एक सक्रिय समुदाय द्वारा बनाए रखा गया है।

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

@jacobq Microsoft GitHub का अधिग्रहण करने जा रहा है, इसलिए यदि वर्तमान में GitHub द्वारा इलेक्ट्रॉन का रखरखाव किया जाता है, तो इसे जल्द ही Microsoft द्वारा बनाए रखा जाएगा जहाँ तक मैं बता सकता हूँ।

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

https://blog.github.com/2018-06-04-github-microsoft/

Microsoft द्वारा Github का अधिग्रहण इलेक्ट्रॉन के लिए कोई मायने नहीं रखता है। Github अभी भी अपने उत्पादों और परियोजनाओं के साथ एक अलग कंपनी है/होगी। मैं Microsoft को इलेक्ट्रॉन का स्वामित्व लेते हुए नहीं देखता, जितना कि मैं Microsoft को एटम का स्वामित्व लेते नहीं देखता।

मुझे लगता है कि यह बहस वास्तव में इस मुद्दे के शुरुआती बिंदु की मदद नहीं कर रही है।

https://github.com/GoogleChromeLabs/carlo

कार्लो काफी दिलचस्प लग रहा है। मैंने इसे एक स्पिन के लिए लिया और यह बहुत सहज है। क्या किसी ने अभी तक pkg आईएनजी के साथ प्रयोग किया है?

अंतिम उपयोगकर्ता हार्ड ड्राइव और मेमोरी के ब्लोट को कम करने के सभी प्रस्तावों पर कभी काम क्यों नहीं किया गया? यह एक शानदार विचार है जो 4 साल पुराना है और अभी भी सिर्फ एक विचार है। मुझे समझ नहीं आ रहा है कि इस तरह की चीजें परियोजना की प्राथमिकताओं में सबसे ऊपर क्यों नहीं हैं

@ danielo515 क्योंकि एक और मेहनती प्रोजेक्ट बनाने के बजाय, https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app है

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

मुझे समझ नहीं आ रहा है कि इस तरह की चीजें परियोजना की प्राथमिकताओं में सबसे ऊपर क्यों नहीं हैं

क्योंकि इसे वास्तविकता बनाना कठिन है (जैसे "वास्तव में" कठिन)।

यदि आप खुश नहीं हैं (जो पूरी तरह से समझ में आता है), इलेक्ट्रॉन को फोर्क करने और पीआर जमा करने के लिए स्वतंत्र महसूस करें।

मुझे गलत मत समझो, अगर इस समस्या का आसान समाधान होता, तो मुझे यकीन है कि इसे पहले ही लागू कर दिया गया होता।

@ डेनियल515

... लोगों को किसी ऐसी सुविधा के लिए किसी भिन्न प्रोजेक्ट की ओर इशारा करना जो इसका हिस्सा होना चाहिए, मुझे सही नहीं लगता।

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

@jacobq हाँ, आप सही हैं - विभिन्न उपकरणों के लिए अलग-अलग उपयोग के मामले कॉल करते हैं।

अगर किसी और को दिलचस्पी है, तो मैंने डेस्कटॉप पर जेएस ऐप्स विकसित करने के लिए समान टूल की एक सूची बनाई है।

https://github.com/styfle/awesome-desktop-js

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

@kapouer ... स्थापित ब्राउज़र का उपयोग करें ...

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

डेल्टा अपडेट पर स्विच करके या पैकेज मैनेजर केवल .asar फ़ाइल या संसाधन फ़ोल्डर को अपडेट करके कई उपयोगकर्ताओं को लगभग 50 एमबी अपडेट प्राप्त हुए हैं। और जरूरत पड़ने पर ही एक बड़ा इलेक्ट्रॉन अपडेट करें। हम अपनी कंपनी में यही करते हैं और इसने बहुत अच्छा काम किया है।

एक भोले उपयोगकर्ता के दृष्टिकोण से, साझा रनटाइम के रूप में इलेक्ट्रॉन ऐप-शेल का उपयोग करना इसे वितरित करना और उपयोग करना वास्तव में आसान बना देगा। उदाहरण के लिए एक ही सिस्टम में 5 इलेक्ट्रॉन ऐप के साथ, आपके पास ऐप-शेल के 5 इंस्टेंस हैं और यह लगभग 300MB है, है ना?

मेरा दृढ़ विश्वास है कि इलेक्ट्रॉन डेस्कटॉप यूएक्स का भविष्य है और वेब-तकनीक को और अधिक शक्तिशाली बनाने के लिए यह एक बड़ा कदम होगा (.NET रनटाइम देखें - एक खराब तुलना हो सकती है, लेकिन, यह सही है?)

विकास के उपयोग के लिए इलेक्ट्रॉन के पास पहले से ही एक रनटाइम है, है ना? "इलेक्ट्रॉन।" आदेश, मेरा मतलब है। उपयोगकर्ता पक्ष के लिए इसका पुन: उपयोग क्यों न करें?

इलेक्ट्रॉन के विभिन्न संस्करण के आधार पर कई ऐप्स से निपटने के लिए, आप उस दृष्टिकोण का उपयोग कर सकते हैं जो .NET कोर उपयोग करता है। बस रनटाइम के कई संस्करण साथ-साथ स्थापित करें, और ऐप्स को उनके लिए आवश्यक न्यूनतम (या अधिकतम) संस्करण घोषित करें।

मैंने एक प्रूफ-ऑफ-कॉन्सेप्ट लॉन्चर बनाया है: https://github.com/ProPuke/electron-shared

एकल निष्पादन योग्य, आकार में 1MB से कम। इसे एक ऐप डायरेक्टरी या असर पैकेज पास करें और यह आपके पैकेज में आपकी इलेक्ट्रॉन संस्करण आवश्यकताओं की जांच करेगा।

इलेक्ट्रॉन रनटाइम AppData\Local\Local\electron-shared (विंडोज़) .cache/electron-shared (लिनक्स) Library/Application Support/electron-shared (मैक) में संग्रहीत हो जाते हैं ताकि उन्हें ऐप्स के बीच साझा किया जा सके।

निर्दिष्ट पथ के बिना यह स्वचालित रूप से app निर्देशिका या app.asar यदि कोई मौजूद है तो चलाएगा; तो आप अपने ऐप को केवल इस फ़ाइल और app.asar के साथ वितरित कर सकते हैं। या इसे .asar फाइलों से जोड़ा जा सकता है और सिर्फ असर को वितरित किया जा सकता है।

इसमें कुछ कमांडलाइन पैराम्स भी हैं, जिनमें --downloadOnly और --silent शामिल हैं, इसलिए इसे सेटअप प्रक्रिया के दौरान इंस्टॉलर के भीतर से बुलाया जा सकता है।

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

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

वैसे भी, अवधारणा/प्रस्ताव का प्रमाण। क्या ऐसा कुछ समस्याओं का समाधान करता है? क्या मैंने कुछ भी स्पष्ट और स्पष्ट याद किया है?

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

मेरे पास एक विचार है। इलेक्ट्रॉन क्योंकि वर्तमान में "इलेक्ट्रॉन.एक्सई पथ" कमांड का समर्थन करता है। मुझे लगता है कि आप इसे कमांड लाइन से कई असारों को कॉल करके खोल सकते हैं। वर्तमान में, मैं सिर्फ एक विचार हूं। मुझे उम्मीद है कि कोई इसे कर सकता है, क्योंकि मैंने अभी इस सॉफ्टवेयर को छुआ है।
_____________ चीनी अनुवाद संस्करण__________
मेरे पास विचार है। क्योंकि वर्तमान में इलेक्ट्रॉन "electron.exe पथ" कमांड का समर्थन करता है। मुझे लगता है कि इसे कई असारों को कॉल करने के लिए कमांड लाइन का उपयोग करके खोला जा सकता है। मैं इस समय सिर्फ एक विचार हूं, मुझे आशा है कि कोई इसे देख सकता है, क्योंकि मैं अभी इस सॉफ्टवेयर में शामिल हुआ हूं।

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

सबसे खराब स्थिति में, आपको गैर-विंडोज ओएस के लिए एक .bat फ़ाइल या समकक्ष बनाना होगा, और इसे इलेक्ट्रॉन से चलाना होगा।

संभवतः उपयोगी लिंक:

https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
https://www.freecodecamp.org/news/node-js-child-processes-everything-you-need-to-know-e69498fe970a/

9718

https://stackoverflow.com/questions/50491092/execute-a-cmd-line-with-electron-angular
https://github.com/martinjackson/electron-run-shell-example

ऐसा लगता है कि केवल जब कोई ऐप.आसार या ऐप फ़ोल्डर नहीं होता है तो कमांड इलेक्ट्रॉन होता है। exe पथ मान्य

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

या मैंने कुछ गलत समझा।

यह विचार शायद वही है: चूंकि बल्ले वर्तमान में कहना आसान है, उदाहरण के लिए इसे लें, सामग्री है Electron.exe app1.asar, निष्पादन के बाद, इलेक्ट्रॉन app1.asar की सामग्री को खोलता है। शायद यही तरीका काम करता है, लेकिन जब आप अगला वाक्य, इलेक्ट्रॉन.exe app2.asar, बल्ले में लिखते हैं, तो आप इसे तभी कर सकते हैं जब app1.asar का इलेक्ट्रॉन समाप्त हो जाता है। और जब बल्ले को बंद किया जाता है, तो इलेक्ट्रॉन बंद हो जाता है। लेकिन मैं Electron.exe app3.asar|electron.exe-v याelectron.exe app3.asar|start, इत्यादि लिखता हूँ। जब मैं बल्ला बंद करता हूं, तो इलेक्ट्रॉन जीवित रह सकता है, लेकिन मैं अन्य असर खोलना जारी नहीं रख सकता। मुझे लगता है कि यह स्टैंड-अलोन कार्यक्रम इससे बेहतर हो सकता है, क्योंकि बल्ला अभी भी कुछ हद तक सीमित है।

यदि आप अस्थायी फ़ोल्डर का उपयोग नहीं करते हैं।

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

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

एसएसडी？

???

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

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

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

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

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

आप "कर्ल, wget, aria2c" डाउनलोड फ़ाइल का उपयोग कर सकते हैं, और उपयोगकर्ता को git，oh स्थापित करने की आवश्यकता नहीं हो सकती है, आपको "gzip,7z" अनपैक ज़िप का उपयोग करने की आवश्यकता है。

मैं एक टूल बना रहा हूं electron-runtime जो इसी तरह काम करता है electron-builder । यह केवल app.asar फ़ाइल को एक साधारण sh स्क्रिप्ट के साथ बंडल करता है (बाद में यह इलेक्ट्रॉन डाउनलोड की प्रगति को दिखाने के लिए एक UI होगा)। वर्तमान में यह केवल macOS के लिए काम करता है।

electron-runtime के साथ पैक किया गया ऐप चलाते समय यह मूल रूप से इलेक्ट्रॉन के संबंधित प्रमुख संस्करण को डाउनलोड करता है, लेकिन मामूली और पैच के मामले में नवीनतम, क्योंकि इलेक्ट्रॉन के ब्रेकिंग परिवर्तन केवल प्रमुख संस्करण वृद्धि में होते हैं।

electron-quick-start ऐप केवल 62 KB का है, स्क्रीनशॉट:

यदि आप इसमें रुचि रखते हैं, तो एक स्टार, पीआर या एक मुद्दा छोड़ दें।

मैंने पैकेज को थोड़ा अपडेट किया है, कि यह electron-builder का उपयोग करके निर्माण कर सकता है ( यहां बताया गया है कि यह कैसे काम करता है )। तो अब आप इसके साथ विजुअल स्टूडियो कोड भी बना सकते हैं! (लेकिन अभी भी केवल macOS पर)।

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

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

@nwdxlgzs यह विंडोज, मैकओएस और लिनक्स को सपोर्ट करता है...

मैंने सोचा कि यह परियोजना केवल मैक का समर्थन करती है।
मैं इस महान परियोजना को आजमाने के लिए समय निकालने जा रहा हूं।

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

खैर, electron-global अपस्ट्रीम को एकीकृत करने और इसे नया डिफ़ॉल्ट बनाने के बारे में कैसे?