+100 ، سيكون ذلك مفيدًا جدًا لتقليل حجم التطبيق.

هل يمكن تغيير الامتداد .asar ؟ يبدو الأمر غريبًا حقًا في اللغة الهنغارية. يعني في الأساس the shit بطريقة سيئة ( رابط ).

.apak? بكل جدية ، هناك الكثير من اللغات ، لذا فإن أي امتداد تقريبًا يمكن أن يبدو غريبًا في بعضها.

يجب أن يكون تثبيت وقت تشغيل IMO وتحديثه سهلاً قدر الإمكان. تحتوي العديد من أوقات التشغيل على إشعارات مزعجة للغاية. أيضًا ، إذا كنت ستفعل ذلك ، فيجب تقديم بعض البيانات الوصفية الإضافية للبيان ، لأن إصدارات التطبيق الأحدث قد لا تعمل في وقت التشغيل القديم ، لذلك تحتاج إلى مقارنة إصدار وقت التشغيل الحالي بالإصدار الموجود في بيان التطبيق (ربما حتى نطاق الإصدارات كما في العقدة الحزم) ، ثم إذا احتاج وقت التشغيل إلى التحديث ، فاجعل هذه العملية سهلة قدر الإمكان. لا أعرف ما هو الأمر السهل بالنسبة لمعظم الأشخاص ، ولكن بالنسبة لي ، إنها مجرد نافذة بها شريط تقدم أو رسائل حالة ("جارٍ التنزيل ... 57٪" ، "جارٍ التحديث ...")
لست متأكدًا ولكن يمكن أيضًا النظر في تحديثات الخلفية. قد تكون بعض خدمات التحديث أو مجرد تنزيل وقت التشغيل أثناء تشغيل التطبيق والتحديث عند إغلاق التطبيق.

+1 لهذا. أنا أعمل على تطبيق لا بد لي من تقديمه لنظام التشغيل mac و windows ، وهذا من شأنه أن يبسط عملية التسليم إلى حد كبير.

سيكون هذا رائعا!

بعض الأفكار:

• كما قال YuriSolovyov ، نحن بحاجة إلى طريقة للإعلان عن إصدارات وقت تشغيل الذرة التي يتوافق معها asar معين. على نحو مفضل ، يجب أن يسمح هذا أيضًا بتحديد إصدار دقيق ، لأن هذا يخفف العبء على ضمان الجودة عند إصدار تطبيق يستند إلى asar.
  
  
  
  • لدعم ذلك ، نحتاج إلى السماح بتثبيت إصدارات متعددة من وقت تشغيل الذرة جنبًا إلى جنب ، من المحتمل أن تكون غير مرئية للمستخدم.
  
  
  • لاحظ أن هذا يتعارض إلى حد ما مع المثل العليا للحد من أحجام التنزيل. ومع ذلك ، يمكن للشركة التي تنتج العديد من المنتجات المستندة إلى أسار توحيد المعايير داخليًا بحيث لا تزال جميع تطبيقاتها تستخدم الإصدار نفسه.
  
  
• لم تذكر دعم التحديث التلقائي لوقت تشغيل atom على نظام التشغيل Mac ، ولكن هذا سيكون مفيدًا جدًا.
• بدلاً من تثبيتات المصدر فقط على نظام التشغيل Linux ، سيكون من الجيد دعم تثبيت / تحديث الثنائيات ، سواء من خلال حزم .deb / .rpm بالإضافة إلى بعض الطرق التي لا تتطلب حقوق sudo للتثبيت (أي لكل مستخدم). بالنسبة لأوقات التشغيل المثبتة لكل مستخدم ، سيكون التحديث التلقائي مفيدًا جدًا أيضًا.
• هل سيكون هناك أي دعم للحفاظ على تحديث ملفات asar المثبتة - أم أن هذا شيء يجب تنفيذه بشكل مستقل في كل تطبيق؟

أخيرًا ، ما هو الجدول الزمني لهذا الجهد؟ ما هي أفضل طريقة للبدء ، إذا أردت البدء في تنفيذ أجزاء من هذا؟ أنا منفتح على المساهمة.

@ joshuawarner32 حاليًا هذه مجرد فكرة تقريبية ، أخطط للعمل عليها بعد حل بعض المشكلات الرئيسية في غلاف الذرة ، ولكن قد يستغرق ذلك شهورًا.

أعتقد أنه من المفيد أيضًا النظر في أوقات التشغيل الحالية وكيفية عملها / تحديثها ، ومدى إزعاجها وما هي الإيجابيات والسلبيات الأخرى.

هذه مجرد فكرة تقريبية حاليًا ، أخطط للعمل عليها بعد حل بعض المشكلات الرئيسية المتعلقة بالصدفة الذرية ، ولكن قد يستغرق ذلك شهورًا.

لقد مرت حوالي 5-6 أشهر. سيكون من الرائع أن يتم تنفيذ هذا.

لقد أنشأنا تطبيقًا داخليًا لهذا يناسب حالة الاستخدام الخاصة بنا جيدًا ، وقد نتمكن من نشرها. يكمن الخطر في أنها في الواقع محددة للغاية لحالة الاستخدام الخاصة بنا ، ولن يهتم أي شخص آخر بالتعقيد الإضافي.

فيما يلي أهم ميزات تصميمنا:

• انشر ملفات .asar.gz للعديد من التطبيقات المختلفة على الخادم
• وزع بنية واحدة من atom-shell على المستخدمين ، والتي لا تجمع أي كود لتطبيقات معينة
• عند بدء تشغيل التطبيق ، قم بتنزيل ملف .asar.gz المناسب (إذا لم يكن موجودًا ، أو كان هناك ملف أحدث على الخادم). قم باستخراجها وتشغيل التطبيق المتضمن.
• يقبل إصدار atom-shell الخاص بنا وسيطة --app لتحديد التطبيق المراد تنزيله / تشغيله

هل هذا نوع من ما كان يدور في خلد قوم قذيفة الذرة؟ هل سيكون شيء من هذا القبيل مفيدًا للآخرين؟

مثل JRE ، يمكن أن يكون ERE (بيئة وقت تشغيل الإلكترون) ، مع ملفات .eapp (تطبيق الإلكترون)

-1 لـ

+1 أحتاجه!

في نظام Windows ، يمكننا توفير برنامج التثبيت والمُحدِّث التلقائي لوقت تشغيل atom ، وتسجيل نوع ملف .asar ليتم فتحه به.

قم بتثبيت Steam على Windows وتحقق من كيفية إنشاء اختصارات للعبة ، فهم يستخدمون بالفعل معالج بروتوكول ، إنه ذكي نسبيًا

: +1: على طراز Steam.

لا توجد عقبة فنية في تنفيذ ذلك ، كل شيء يمكن أن يكون مجرد تطبيق Electron نفسه. لكن المشكلة أنه ليس من السهل تنفيذ أي منهما ، مع الأخذ في الاعتبار جميع التفاصيل ، أعتقد أنه يتطلب فريقًا صغيرًا يعمل بدوام كامل على ذلك ، ولست متأكدًا مما إذا كان سيحدث على الإطلاق.

لكن المشكلة أنه ليس من السهل تنفيذ أي منهما ، مع الأخذ في الاعتبار جميع التفاصيل ، أعتقد أنه يتطلب فريقًا صغيرًا يعمل بدوام كامل على ذلك ، ولست متأكدًا مما إذا كان سيحدث على الإطلاق.

هناك الكثير من الأسئلة في ذهني والتي ، على الرغم من أنها ليست مستعصية بالتأكيد ، تجعل هذه الخطة صعبة. على سبيل المثال ، لنفترض أن "التطبيق 1" يتطلب 0.30.x ولا يمكن تشغيله على 0.31.x ، و "التطبيق 2" يتطلب العكس. من يفوز في هذا السيناريو؟

يبدو أن هناك الكثير من الجهد والبنية التحتية / الحيلة للتحسين لشيء ليس أكبر مشكلة لدينا - مساحة القرص وعرض النطاق الترددي ، على حساب تعقيد المطور (على سبيل المثال ، يتعين على المطورين الآن إنشاء هذا المثبت الجنوني للتثبيت / تحقق من Electron ، ثم قم بتثبيت التطبيق الخاص بهم)

لا أقصد أن أكره فكرة! أعتقد أنه مع الوقت الذي سنستغرقه للقيام بذلك ، يمكننا بدلاً من ذلك إنفاقه على مشكلتنا الكبيرة - مما يجعل الأمر سهلاً للغاية على المطورين الجدد لإنشاء ونشر تطبيقات Electron ، بدءًا من السطر الأول من التعليمات البرمجية وصولاً إلى شحنه للمستخدمين

paulcbetts ولكن مهلا ، الفوائد تستحق العناء ، أليس كذلك؟ عند تحديث أحد التطبيقات ، سيتعين على المستخدمين تنزيل أقل من ميغابايت بدلاً من 70 ميغابايت تقريبًا. مما يعني أننا لن نحتاج حتى إلى إطارات عمل للتحديث التلقائي وكل ذلك ، سيتعين علينا فقط تنزيل واستخراج أرشيف مضغوط يحتوي على ملفين.

لقد أمضيت الأشهر الثلاثة الماضية في منطقة نائية حيث كانت السرعة أقل من 128 كيلو بت في الثانية وصدقني ، حجم الترقية يمثل ألمًا كبيرًا في المؤخرة ، وأسوأ جزء هو أنه لا يزال هناك الكثير من الأشخاص لا يزالون في مواقف مماثلة

مما يعني أننا لن نحتاج حتى إلى إطارات عمل للتحديث التلقائي وكل ذلك ، سيتعين علينا فقط تنزيل واستخراج ملف مضغوط صغير يحتوي على ملفين.

لا أعتقد أن هذا صحيح ، لأنه من شبه المؤكد في مرحلة ما أنك سترغب في الانتقال في تحديث إلى إصدار أحدث من Electron ثم kerplowie ، فأنت في نفس الوضع (أو على الأقل واحد قبيح بالمثل )

تتراوح التطبيقات الأساسية الآن بين 30 و 50 ميغا ما لم يكن لديك الكثير من مقاطع الفيديو داخل الحزمة الخاصة بك. لا أعتقد أن هذا يمثل امتدادًا لمعظم الأشخاص لتنزيله. أعتقد أن متوسط ​​فيديو يوتيوب يتراوح بين 30 و 40 ميغا بايت ...

أود فقط تدوين ملاحظة هنا ، في الصين ، حيث يبلغ متوسط ​​سرعة الاتصال حوالي 20 كيلو بايت / ثانية (من المؤكد أنني حصلت على اتصال أبطأ من ~ 92٪ من مدينتي.) يتطلب تحديث Atom / الإلكترون عادةً يومًا كاملاً من wget -c 'جي. ما لم يتم استخدام مرايا تاوباو.

من أجل التوافق مع الإصدار ، يتحرك تطوير الإلكترون بسرعة كبيرة بحيث لا يكون لديه إصدار شامل أيضًا ، ربما يمكن استخدام نوع من الغلاف / المساعد لاستخدام / تنزيل الإصدار الرئيسي المطلوب عند بدء تشغيل التطبيق؟

20 كيلو بايت / ثانية؟ كيف تستطيع النجاة لا أستطيع أن أتخيل مدى صعوبة هذا الأمر!

steelbrain لا نيتي

RIAEvangelist الحصول على أوقات سريعة والكثير من الصبر. تصبح السرعة عالية جدًا في وقت متأخر من الليل ، لذلك فقط اترك التنزيلات قيد التشغيل أو مجدولة أثناء نومك. : 3

على أي حال ، أعتقد أنه لن يكون هناك الكثير من العمل لكتابة غلاف (أساسي) لجهة خارجية ، هل يريد أي شخص المحاولة؟

ومع ذلك ، لا تستطيع ملفات .asar التصريح بسهولة عن نسختها الإلكترونية. ربما ستكون هناك حاجة إلى نظام واصف برنامج آخر؟

ماذا عن نوع من مرسل إصدار وقت التشغيل الذي (يتم تنزيله إذا لزم الأمر و) قاذفات تتطلب إصدارًا من وقت التشغيل لتطبيقك؟ يمكننا إضافة إدخال إلى package.json لذلك.

YuriSolovyov إلا أننا لا نستطيع أن نقول أن وقت التشغيل يعالج ملفات .json افتراضيًا. أفترض أنه يمكنه قراءة ملف asar أولاً وعرض 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

من الناحية المثالية ، يجب أن يعمل وضع وقت التشغيل مثل طريقة Steam أو Chrome App Launcher . تكمن المشكلة الرئيسية في كيفية تعاملنا مع التطبيقات عند ترقية وقت التشغيل إلى الإصدار الجديد.

تعاني تطبيقات Electron من ترقية Electron ، وخاصة الوحدات النمطية للعقد الأصلية. الوحدات الأصلية مطلوبة لإعادة البناء لكل ترقية للإلكترون بسبب مشكلة C ++ ABI (هناك العديد من مشكلات التعطل التي تم نسيانها والتي أبلغ عنها المستخدمون).

لا يعاني Steam من الألم لأن كل لعبة على Steam هي برنامج مستقل ، في الواقع يمكنك تشغيل اللعبة بدون Steam Client. لا يتم تشغيل تطبيق Chrome أيضًا ، نظرًا لأن تطبيقات Chrome مكتوبة بلغة HTML / JS / CSS وهي أنواع من اللغات المفسرة ، فلا توجد فجوة تعمل في الإصدارات المختلفة من Chrome.

hokein كيف يكون لدينا "عميل" خفيف الوزن بلغة أصلية ، يقوم بتنزيل لغات متعددة ، عندما يواجه تطبيقًا يعتمد على إصدار غير مثبت من الإلكترون ، يقوم بتنزيل نسخة منه ، ثم يقوم بتشغيل كل تطبيق بإلكترون محدد.

هناك إصدار جديد من Electron حوالي مرة واحدة في الأسبوع ، لذا فإن فرصة أن يكون لدى تطبيقين نفس الإصدار من Electron تكون ضئيلة.

لدعم نهج وقت التشغيل ، سنحتاج على الأرجح إلى البدء في فصل الإصدارات إلى إصدارات LTS (دعم طويل الأجل) وإصدارات حافة النزيف. سيكون LTS للإنتاج وستكون ميزة النزيف للتطوير والاختبار. سيحصل LTS على إصلاحات للأخطاء فقط وربما بعض التغييرات التي لا تحل محل إصدارات io.js الرئيسية وإصدارات غلاف المحتوى ، لذلك يجب أن تستمر الوحدات الأصلية في العمل.

بالنظر إلى ما قاله tiktin ، ما لم يكن لدى المستخدم العديد من تطبيقات الإلكترون على نظامه ، فمن المحتمل ألا تكون هناك فائدة في وقت التنزيل حيث سيظل عليهم تنزيل وقت التشغيل في كل مرة.

في الأسبوعين الماضيين كنت أبحث في الإلكترون الآن أعتقد أنني رأيت 4 إصدارات.

etiktin من الناحية المثالية ، إذا اتبع الإلكترون semver ، فيمكن للتطبيق إعلان الإصدار ^ 0.31 ، وسيستخدم أحدث إصدار 0.31.x. هذا قد يساعد الأشياء قليلا.

لدينا تطبيق قيد الإنتاج بآلية التحديث التلقائي من semver والتي تقوم بما يلي:

1. احصل على نقطة نهاية HTTP بسيطة على الخادم تعطي الإصدار الحالي (0.3.0 ، 0.3.1 وما إلى ذلك) والنظام الأساسي (darwin-x64 و win32-ia32 و win32-x64 وما إلى ذلك) من التطبيق.
2. يعرض الخادم "304 Not Modified" أو بيان JSON إذا كان هناك إصدار أحدث.
3. بيان JSON هو في الأساس قائمة متداخلة من المجلدات والملفات والروابط الرمزية في الإصدار الأحدث.
4. يبدو إدخال المجلد في بيان JSON على النحو التالي: [الاسم ، مجموعة الإدخالات الفرعية].
5. يبدو إدخال ملف في بيان JSON كما يلي: [الاسم ، تجزئة المحتوى ، مصفوفة من تجزئات المحتوى مقسمة إلى أجزاء 64 كيلوبايت ، علامة عدد صحيح تشير إلى ما إذا كان الملف قابلاً للتنفيذ أم لا].
6. يبدو إدخال الارتباط الرمزي في بيان JSON على النحو التالي: [الاسم ، مسار الوجهة].
7. يتم إنشاء بيانات JSON هذه وتخزينها مؤقتًا على الخادم لكل إصدار. لكل ملف في بيان JSON ، يقوم الخادم بتشغيل خوارزمية بسيطة لإزالة البيانات المكررة لتقسيم الملف إلى أجزاء متغيرة الطول باستخدام تقسيم يعتمد على المحتوى ، ثم يقوم بتجزئة الأجزاء باستخدام SHA256. يضمن ذلك أن تظل معظم تجزئة الأجزاء لإصدارات مختلفة من نفس الملف كما هي ، حتى إذا تم نقل المحتوى بمقدار بضع بايتات. يبلغ متوسط ​​طول المجموعة 64 كيلو بايت تقريبًا لإلغاء البيانات المكررة + كفاءة الضغط المثلى. إذا كانت القطع أكبر ، فلن يتم إلغاء تكرارها أيضًا ، وإذا كانت الأجزاء أصغر حجمًا فلن يتم ضغطها أيضًا. سيتم أيضًا زيادة متوسط ​​طول المجموعة للملفات الكبيرة جدًا لتجنب وجود عدد كبير جدًا من التجزئة في البيانات الوصفية.
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 من المحتمل ألا يحدث في أي وقت قريب بسبب تجزئة الإصدار الحالي (من الصعب العثور على تطبيقين للإلكترون يستخدمان نفس الإصدار بالضبط). ربما بعد إصدار v1.

jorangreef هل تستخدم آلية التحديث التفاضلي الخاصة بك على جميع المنصات؟ سيكون رائعًا إذا كان بإمكانك إصدار هذا الرمز كوحدة قائمة بذاتها.

championswimmer نعم ، لقد تمكنت من إنشاء نص برمجي لتطبيقي ، لذا فأنا على ما يرام في توزيع تطبيقي الآن. لكني أراقب هذا لأنه سيكون ممتعًا.

etiktin نعم ، يعمل التحديث التلقائي التفاضلي حاليًا على جميع الأنظمة الأساسية. إذا تضمن أيضًا الحد الأدنى من المثبت الذي يقوم بالتنزيل ، فيمكن مشاركة المثبت بواسطة العديد من التطبيقات ، واستخدام نسخة مخبأة من Electron إذا كانت متوفرة بالفعل. هذا من شأنه أن يجعل التثبيت أسرع بكثير. أود فتح مصدره إذا كان الناس مهتمين ، وسأحاول إصدار الكود في الأشهر القليلة القادمة.

على سبيل المثال ، لنفترض أن "التطبيق 1" يتطلب 0.30.x ولا يمكن تشغيله على 0.31.x ، و "التطبيق 2" يتطلب العكس. من يفوز في هذا السيناريو؟

ثم يجب عليهم تثبيت الإصدارين وسيكون هناك وقتان للتشغيل ، تمامًا مثل VS C ++ 2008 مع 2005. أحب حقًا كيفية تثبيت أوقات تشغيل VS C ++ ، حيث يقوم المثبت بتثبيت الإصدار المطلوب إذا لم يكن هناك أي إصدار ، ويمكن للآخرين الاعتماد عليه لاحقًا ، ويمكن أن تتعايش أوقات تشغيل مختلفة. يبدو أيضًا أن تنفيذ متطلبات الإصدار يتم بسهولة أكبر في المثبت.

@ louy2 يوجد فرق بين مثال Visual C ++ (3 سنوات بين الإصدارات) والإلكترون (3 إصدارات شهريًا على الأقل)

سوف أقوم باقتباس عبارة "هذا نظام مكسور" هنا ، إذا كانت الأغلبية
التطبيقات في نظام Electron البيئي غير متوافقة مع + - 0.0.1 أو
0.1.0 نسخة الاختلافات

في 20 فبراير 2016 الساعة 18:55 ، بيير دي لا مارتينيير <
[email protected]> كتب:

@ louy2 https://github.com/louy2 هناك فرق بين
مثال مرئي C ++ (3 سنوات بين الإصدارات) و Electron (3 إصدارات لكل
شهر على الأقل)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/atom/electron/issues/673#issuecomment -186595285.

+1

لقد قمت بتعبئة الإلكترون في حزمة .deb باستخدام fpm . قد تكون هذه نقطة انطلاق عادلة لنظام Linux (على الأقل يعتمد على Debian أو RPM). يمكنك إلقاء نظرة هنا: iamale / electron-deb ؛ يوجد أيضًا مثال على التطبيق . (ستعمل مع asar أيضًا ، تحتاج فقط إلى إضافة إدخال MIME في حزمة وقت التشغيل.)

سيكون رائعًا حقًا إذا كان لدينا شيء من هذا القبيل على المنصات الأخرى أيضًا! ربما يمكنني محاولة حزمه لنظام التشغيل Windows ، لكنني لم أعد أستخدمه بنشاط بعد الآن ، ولم يكن لدي الكثير من الخبرة به.

(شكرًا لـ @ louy2 للإشارة إلى هذا الموضوع لي!)

بالمناسبة ، ما هو نوع MIME لـ .asar؟ هل سيفعل application/x-asar ؟

iamale بدلاً من fpm ، هل ألقيت نظرة على AppImageKit . الفائدة الرئيسية التي تحصل عليها هي أنه بدلاً من إنشاء مكتبات متعددة وكلها ، يمكنك استهداف جميع توزيعات Linux باستخدام ملف تنفيذي واحد. لم تعد مضطرًا أيضًا إلى مطالبة المستخدم بتثبيت أي تبعيات لأنها مجمعة مع الملف القابل للتنفيذ. إنه مشروع جميل ، يرجى إلقاء نظرة.

وحول التمثيل الصامت ، ماذا عن application/x-electron ؟

steelbrain هذه فكرة جميلة. ومع ذلك ، فإن هذا لن يحل المشكلة الأصلية: يجب أن يتم حزم وقت تشغيل Electron مع كل تطبيق (لأن الصور يجب أن تكون قائمة بذاتها) ، وهو بالضبط ما تدور حوله هذه المشكلة. على الرغم من أنني أعتقد أنه يجب أن يكون من السهل نسبيًا إنشاء AppImages من تطبيقات Electron ، وأعتقد أن هذا سيكون رائعًا عندما لا يمكن استخدام إدارة الحزم التقليدية (توزيعات نادرة أو مستخدمون غير مفوضين). لذا ، شكرا للإشارة إلى ذلك!

بالمناسبة ، يبدو application/x-electron رائعًا ، ومن المحتمل أن يظل كذلك.

تمت إضافة دعم asar! ليس في المستودع بعد ، وسنعيد بنائه في وقت لاحق اليوم أو ربما غدًا. في الوقت الحالي ، يمكنك الحصول على الحزمة على transfer.sh (سيكون الرابط صالحًا لمدة أسبوعين مقبلين)

أنت بحاجة إلى asar.json داخل .asar لتقول:

• نسخة موصى بها
• إصدارات متوافقة
  بمجرد الانتهاء من ذلك ، ستحتاج إلى تطبيق واحد يستخدم الإلكترون (أي إصدار منه) للتحقق من الويب بحثًا عن (1) تحديثات لنفسه (المدقق) و (2) الإصدارات الموجودة في جهاز الكمبيوتر الخاص بك ، ثم إذا كان هناك إصدار متوافق ، فإنه يوزع المسار الافتتاحي إلى .asar المفتوح ، وإلا فقم بتنزيل الإصدار الموصى به وتحقق مرة أخرى. يمكن كتابة التطبيق نفسه بلغة Electron أو python (حيث سيتطلب حدًا أدنى من واجهة المستخدم أو لا يتطلبها).

الفكرة هي: إن التطبيق الذي يتحقق مما إذا كان قد تم تنزيل إصدار الإلكترون المطلوب ليس له علاقة بإصدارات الإلكترون المطلوبة.

إذا دعت الحاجة ، يمكنك تحديث محتوى التطبيق الافتراضي ، وكذلك باقي التطبيق ، باستثناءه.

وهناك ، يمكنك حفظ الإصدارات app.setPath("userData", __dirname + "/ElectronVersions"); ثم يمكن ترك هذه الإصدارات هناك بمفردها ، وتثبيت الإصدارات الجديدة حسب الحاجة.

بدلاً من fpm ، هل ألقيت نظرة على AppImageKit .

هناك AppImage لـ Atom متاح على https://bintray.com/probono/AppImages/Atom/_latestVersion#files - فقط قم بتنزيل chmod a+x وتشغيله على أي توزيعة Linux x86_64 ليست قديمة جدًا.

لا تكمن المشكلة في نظام Linux فقط ، فنحن بحاجة إلى طريقة لجعله يعمل عبر نظام التشغيل ، مما يعني أننا بحاجة إلى أن نكون قادرين على تشغيله على Linux و Windows و Mac OSx.

نوع من المشغلات الخاصة بنظام التشغيل الذي يبحث عما إذا كان وقت التشغيل متاحًا ومحدّثًا / متوافقًا مع حزمة asar

(بعد عدة سنوات) اسمحوا لي أن ألخص المناقشة:

1. يقترح zcbenz وقت تشغيل يدير مثيلات الإلكترون المحلية بحيث يتم توزيع الحزم .asar فقط ويتم تجنب تجميع ثنائيات الإلكترون. يدير وقت التشغيل أيضًا تنفيذ حزم .asar .
2. يقترح YurySolovyov تحسين ملف البيان بمعلومات إضافية (مثل إصدار الإلكترون المطلوب) حتى يعرف وقت التشغيل الإصدار الذي سيتم استخدامه لحزمة .asar . يتم إعطاء لمحة عامة عن هذا النهج هنا .
3. يقدم @ joshuawarner32 فكرة إصدارات متعددة لوقت التشغيل ، والتعبئة الثنائية (مثل .deb ) ، والتحديث التلقائي لحزم .asar . علاوة على ذلك ، يتم النظر في فكرة خادم التوزيع.
4. يقترح paulcbetts إلقاء نظرة على نموذج Steam وتنفيذ شيء مشابه. ويشير إلى التعقيدات المرتبطة بفكرة وقت التشغيل المحلي الذي يدعم إصدارات مختلفة من الإلكترون ، إلخ.
5. [يناقش الأشخاص سرعة الإنترنت في الصين وشؤون طفولتهم]
6. يشير hokein إلى التعقيدات التي تحدث عند ترقية وقت التشغيل. Wrt خصيصا. الوحدات الأصلية المطلوب بناؤها مرة أخرى ضد رؤوس الإلكترون.
7. يريد etiktin الحصول على LTS وإصدارات متطورة ، لذا فإن التطبيقات الجاهزة للإنتاج تستخدم LTS بدلاً من ميزة النزيف.
8. يقول Tribex أنه إذا تمسكنا بالإصدار الدلالي ، فلن نحتاج إلى أن يكون لدينا مثيل محلي من جميع الإصدارات ، ولكن فقط تلك غير المتوافقة.
9. يوفر jorangreef مثالاً على نظام التحديث التلقائي التفاضلي قيد الإنتاج بالفعل لتطبيقه الخاص.
10. أنشأ iamale حزمة fpm من Electron لتنفيذ حزم .asar .

_disclaimer: حاولت تضمين نقاط المناقشة الرئيسية فقط. أرجو المعذرة إذا فاتني شيء! _

قرأت المناقشة حتى هنا ، وحاولت تلخيص النقاط الرئيسية وأردت معالجة بعضها. تتجاوز فكرة وقت التشغيل مع "تكامل النظام الأساسي العميق" مجرد مثال محلي بسيط. يجب تحديد الحد الأدنى من المنتج القابل للتطبيق ، والذي يعمل بمثابة وقت تشغيل على مستوى النظام. لقد أضفت أيضًا ميزة لطيفة قد تكون مفيدة. يصف القسم الأخير التغييرات / الميزات التي يجب تنفيذها.

الأساس المنطقي:

ما يفعله معظم المطورين (أي تجميع ثنائيات الإلكترون) يشبه ربط جميع المكتبات المشتركة بشكل ثابت! إنه مثل توصيل فرن مع كل بيتزا نبيعها.

أفضل لاعب:

• مدير البيئة : يتتبع مثيلات الإلكترون المتاحة محليًا. يمكن استخدامه لتحديد الحزمة المتوافقة مع أي مثيل (باستخدام package.json [انظر أدناه]). يجب أن تهتم أيضًا بتعيين متغيرات البيئة الصحيحة للحزم للتشغيل.
• مدير التحديث : تمت مناقشة إمكانية التحديث التلقائي (+ الإخطار) والتحديث التلقائي التفاضلي. سيكون من الجيد أن يكون ذلك بمثابة برنامج خفي يهتم بتحديث النسخ المحلية إلى أحدث الإصدارات.

من الجميل أن يكون لديك:

• مدير الحزمة / التبعية : تمامًا مثل Atom apm ، هناك حاجة إلى مدير الحزم لتنزيل حزم .asar (من GitHub أو عنوان URL معين ، وما إلى ذلك) وتثبيتها محليًا (يمكن مقارنتها بـ apt-get في Ubuntu أو brew في Mac).

متطلبات:

• ملفات البيان المحسّنة : يجب أن يحتوي package.json أيضًا على semver (أو نطاق semver) للإشارة إلى إصدار Electron المطلوب.
• إجراء التثبيت / إلغاء التثبيت المحدد : ATM تحتوي الحزمة .asar على كل ما يلزم لتشغيل التطبيق. ومع ذلك ، من الممكن تقديم وحدات التبعية للمصدر وتنزيلها فقط عند التثبيت. إذا أصبحنا شجاعين للغاية ، فيمكننا الحصول على نوع من الدليل _العالمي_ الذي يحتوي على تبعيات لجميع التطبيقات (قد يساعد الهيكل المسطح لـ npm 3). ومع ذلك ، يمكن أن يصبح هذا الأمر معقدًا وسريعًا حقًا (على سبيل المثال عند إلغاء تثبيت أحد التطبيقات).
• أوقات تشغيل محلية متعددة : إذا تم تطبيق الإصدار الدلالي حتى الآن ، فلا يوجد سوى نسختين غير متوافقتين هناك 0.x و 1.x . يجب أن تكون الإصدارات الثانوية والتصحيحات متوافقة مع الإصدارات السابقة ، لذلك نحتاج فقط إلى أحدث إصدار من 0.x و 1.x على النظام.

الإلهام:

• مدير البيئة / التبعية: Python virtualenv ، Ruby's rbenv ، وانظر أيضًا ruby-build .
• مدير الحزم: Python pip ، Atom apm .
• مدير التحديث: تتميز عملية Chromium zygote بأسلوب مثير للاهتمام لتحديثات الخلفية الصامتة.
• مترجمي الأكواد (للتكيف مع واجهات برمجة التطبيقات الجديدة): Pythons 2to3 .

يبدو أن epm (مدير حزمة الإلكترون) مأخوذ بالفعل كاسم ...
ربما استدعاء وقت التشغيل elec والتطبيقات .tron ؟ ربما تكون هناك بعض مشكلات العلامات التجارية مع TRON ولكنها تبدو رائعة ؛)

ربما uepm (مدير حزم الإلكترون العالمي) ، لأنه من المفترض أن يتم تشغيله على جميع أنظمة التشغيل التي تدعمها Electron ... أو epmc (مركز إدارة حزم الإلكترون) والملف .epack (حزمة إلكترونية). الامتداد ، على الأقل ، يبدو أفضل من .tron ولا يمكن الخلط بينه وبين فيلم ("gimme that tron ​​thing، dude" _hands you the movie_).

هناك أيضًا مجموعة من الكلمات في مجال الفيزياء النظرية المتعلقة بالإلكترون

• فيرميون
• ليبتون
• تكلفة
• كولوم
• باولي

وليس مرتبطًا بشكل مباشر ، ولكنه متوافق إلى حد ما مع ما يحدث مع مدير الحزم ،

• بوزون
  ؛)
  (أعتقد أن الفوتون قد تم أخذه بالفعل)

@ kapouer + كوارك؟ لست متأكدًا مما إذا كان قد تم أخذه على الرغم من ذلك

كوارك مأخوذ ، والباقي لا أعرف. ولكن لماذا يجب أن نحافظ على الوضع الراهن ، في حين أن قائمة الاقتراحات هذه تقترح عدم الإبقاء على الوضع الراهن؟ ولكن بما أننا في ذلك ، فلماذا لا نطلق عليه اسم Hauldron؟ مأخوذة من LHC. المصادم ليس فكرة جيدة ، فهو يعطي المنتج ظلًا سلبيًا ، لأن معناه مرتبط ارتباطًا وثيقًا بالحرب ...

Particle(s) ؟ طويل جدا رغم ذلك.
قائمة الجسيمات في الويكي

في حين أن التسمية مهمة ، ما زلت أعتقد أننا بحاجة إلى التحقق من دلالات وقت التشغيل / التحديث / التغليف / التوزيع أولاً.

يبدو lepton مثاليًا لأنه عائلة الجسيمات التي ينتمي إليها الإلكترون.

فكرة خارج النطاق قليلاً: سيكون مدير وقت التشغيل الأكثر عمومية أكثر روعة (وليس أصعب في التنفيذ). على سبيل المثال ، يمكننا تضمين nwjs ثنائيات أيضًا وإدارتها في نفس الإصدار-manager-thingy أيضًا (تمامًا مثل @ asdf-vm ، ولكن لأوقات تشغيل واجهة المستخدم الرسومية).

سريع وقذر: https://github.com/iamale/lepton. يدعم الإصدار الثابت فقط في الوقت الحالي (semver هو الشيء التالي الذي يجب القيام به) ، ويتم فك حزم التطبيقات (على سبيل المثال لا يوجد .asar-s حتى الآن).

لطيف - جيد!

+1

حتى لو لم يكن كذلك .asar ، iamale ، طالما أن لديك أي طريقة لمعرفة الملف الذي تريد فتحه ، أعتقد أنه يجب أن يكون على ما يرام. مثل ، على سبيل المثال ، يمكن أن يكون لديك file.something به كود json مرتبط بـ package.json حتى يعرف ما يجب فتحه ...

هذه فكرة مجنونة تمامًا ، ولكن ماذا عن استخدام حقل electron في package.json لصنع
أي حزمة npm قابلة للتنفيذ (حسنًا ، ليس مثل أي ، ولكن معدة)؟
يحب:

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

يمكن تحقيق ذلك عن طريق إضافة قدرة electron لتثبيت حزم npm وجعلها قابلة للتنفيذ ومرئية للنظام المضيف.
تماما مثل

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"
  ]
}

في هذا المثال ، يوصى باستخدام Electron 1.2 ، إذا لم يتم العثور عليه ، يتحقق أيضًا مما إذا كان هناك أي إصدار بين 1.2.1 و 1.2.5 ، وإذا لم يكن يتحقق من 1.3.1 ، فعندئذٍ بالنسبة لـ 1.3.0.1 ، إن لم يكن يتحقق لـ 1.1 وإذا لم يكن الأمر كذلك ، فسيتم تنزيل 1.2.

ربما يكون هناك شيء من هذا القبيل يقوم بتنزيل الإصدار الموصى به تلقائيًا ، ولا يمكنه ذلك ، ثم يتحقق من الإصدارات المتوافقة. وخذ كل واحد من المتوافقين وتحقق منها ، وإذا لم يعمل أي منها ، اسأل المستخدم عما إذا كان يريد عدم استخدام إصدار غير متوافق ، وإذا ضغط no ، فسيتم تشغيله بإصدار غير متوافق الموجودة على جهاز الكمبيوتر ، وإذا لم يتم العثور على أي منها ، فبدلاً من طلب استخدام إصدار غير متوافق ، أظهر نافذة منبثقة للخطأ تفيد بأنه لم يتم اكتشاف تثبيت إلكتروني.

sapioit يبدو أن وجود ملف بيان منفصل فكرة جيدة بالنسبة لي. سيؤدي وجود امتداد ملف مخصص إلى تبسيط الأمور قليلاً. (على الرغم من أن .electron يبدو طويلاً بعض الشيء).

ربما وفقًا لـ 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 مباشرةً ، فسيتم فتحه في كل ما يرتبط بـ .json في نظام التشغيل الخاص بك.

نوع من مثل نظام الاختصار.

YurySolovyov في هذه الحالة ، إنها مسألة ذوق فقط إذا حددنا هذه المعلومات في package.json أو package.electron. أنا شخصياً سأبقيها منفصلة لمجرد أنها تبدو أنظف بالنسبة لي. ربما تكفي خاصية المحركات في package.json.

Tribex هو أيضًا مطلب لنشر التطبيق إلى npm - وجود package.json صالح

تضمين التغريدة إذا استخدمنا package.electron package.json لا يزال موجودًا. سيتم استخدام .electron فقط لتحديد معلومات وقت التشغيل ، أو ، في حالة اقتراحك ، يكون مجرد علامة.

بشكل أساسي ، سيكون 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 ، فسيتطلب ذلك أيضًا قراءة واحدة فقط. بهذه الطريقة ، لست متأكدًا مما سأضعه في ملف .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 عند تحريره. أو انقر بزر الماوس الأيمن وافتحه باستخدام محرر ، ولكن تمامًا مثل Adobe Air ، التي تفتح الملف افتراضيًا باستخدام المشغل الخاص بها ، مما يسمح للمستخدم بفتح الملف باستخدام محرر ، ولن يتسبب ذلك في أي مشاكل.

sapioit نقطة عادلة ، أعتقد أنني أتفق معك في ذلك الوقت حول الإشارة إلى package.json.

بالنسبة لي ، فإن وقت التشغيل واللاعب هما شيئان منفصلان. هذا يأتي أكثر كلاعب الآن. ولا يبدو أنه سيحصل على أي استخدام واسع النطاق خارج المجتمع المائل تقنيًا والمعتاد على مفاهيم مديري الحزم.

القضية المطروحة هي إنشاء وقت تشغيل. نوع من مثل JRE و. لا لاعب.

baconface ربما يمكنك التفصيل؟ ليس من الواضح ما هو الفرق الذي تقوم به هنا.

baconface نعم ، ولكن يمكن تثبيت كل من JRE و .Net أيضًا.
بدون JRE ، تكون ملفات .jar عديمة الفائدة مثل الحزم بدون electron وقت التشغيل.

من الناحية المثالية ، سيتم توزيع هذه الأداة مع أو كطريقة أساسية لتثبيت الإلكترون ، مما يؤدي بشكل مثالي إلى التخفيف من مشكلة الانتشار.

لهذا ، ستحتاج فقط إلى أداة صغيرة لإنشاء ملف تنفيذي من شأنه تشغيل ملف معين ، أي .electron المحسوب. سهل هكذا.

.lept يبدو رائعًا ، شكرًا!

أنا شخصياً أعتقد أنه ليست هناك حاجة لاختراع أي تكوين جديد ، فإن pkg.engines يبدو واضحًا جدًا بالنسبة لي هنا (يجب أن يسمح ببعض التعبيرات semver المعقدة ، مثل 1.x || >=2.5.0 || 5.0.0 - 7.2.3 من مستندات npm ، لذلك لا داعي لـ { recommended, compatible, etc } -بنى كما في أمثلة sapioit ، على ما أعتقد). (لقد أضفت حقلاً lepton على الرغم من ذلك ، لأن scripts.run يتم استدعاؤه عادةً بواسطة npm start ، ويقوم ليبتون إلى حد ما بتقسيم دلالاته عن طريق إضافة $VARIABLES الخاص به .)

أو ، إذا وضعنا كل شيء في package.json ، فيمكننا الحصول على رابط .electron فقط إلى ملف .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 ، يمكنك استخدام نصوص برمجية بسيطة (3 أسطر بما في ذلك #! shebang) ، وعلى Windows ... حسنًا ... ¯_ (ツ) _ / ¯

أولاً ، قد ترغب في إلقاء نظرة على هذه المقالة ، التي تقدم بديلاً أفضل لـ semver ، بينما تظل متوافقة مع كل شيء تقريبًا: Release.Breaking.Feature.Fix أو لماذا يجب استبدال الإصدار الدلالي بـ Explicit Versioning مثل فى اسرع وقت ممكن

ثانيًا ، السؤال هو كيف نفرق بينهما. أعني ، إذا كان server.js يقبل بالفعل الوسيطة --debug ، فلماذا تهتم بذلك ولا تسمح للأشخاص بتكوين ملفاتهم الخاصة. ربما يتطلب الخادم تكوينات مختلفة عن العميل ، مثل العميل الذي يعمل على 2.2-2.4 والخادم يعمل فقط على 1.4-1.9.2.1 ...
بالقيام بما اقترحته ، سنكون أكثر محدودية.

أيضًا ، ماذا عن استخدام المزيد من المتغيرات ، وليس فقط --debug ؟ كيف سأقوم بتشغيله بمزيد من المتغيرات مثله؟ هل من الآمن القيام بذلك؟ بعد كل شيء ، إذا أردت ملفًا واحدًا للقيام بذلك ، كان بإمكاني فعل ذلك حتى مع وجود ملفات منفصلة ، ولكن بهذه الطريقة يفسد الأمر مع النتائج المحتملة لتشغيل ملف .lept مع المعلمات.

إذا كنت أرغب في تشغيل الخادم بمعامل التصحيح ، ألا يمكنني ببساطة تشغيل .lept باستخدام الوسيطة --debug ؟ أو يمكنني إنشاء ملف آخر لتشغيل هذا الملف باستخدام الوسيطة --debug . أليس بهذه البساطة؟
آمل أن أكون منطقية ...

أولاً ، قد ترغب في إلقاء نظرة على هذه المقالة ، والتي تقدم بديلاً أفضل لـ semver

أعتقد أن هذه فكرة رائعة! لا أعتقد أن Electron ستتحول إلى نظام النسخ هذا ، رغم ذلك. أعتقد أيضًا أنه على الرغم من كونه رائعًا لمنتجات المستخدم النهائي ، إلا أننا لا نحتاج إليه حقًا للمكتبات والمحركات وأوقات التشغيل والأشياء. من الناحية المثالية ، يجب ألا يعرف المستخدم حتى إصدار Electron الذي يتم تشغيله (ما لم يرغب في ذلك).

ربما يتطلب الخادم تكوينات مختلفة عن العميل

قد تكون هذه مشكلة ، لكن لا يمكنني تخيل مشروع يحتاج إلى أكثر من إصدار واحد من وقت التشغيل.

إذا كنت أرغب في تشغيل الخادم بمعامل التصحيح ، ألن أقوم ببساطة بتشغيل .lept باستخدام وسيطة --debug؟

نعم ، لما لا:

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

تعد حزمة config.json ثنائية التكوين هذه رائعة للحالات التي يكون فيها الخادم أ) يشارك الكثير من التعليمات البرمجية مع العميل ، و ب) معدة ليتم تشغيلها بواسطة المستخدمين النهائيين. في حالات أخرى ، سيكون من المنطقي فصلها جميعًا إلى مجموعتين من حزم المستودعات / الحزم ، ولكل منها package.json الخاص بها.

إنه ليس من أجل Electron ، ولكن للمشاريع التي تبنيها. من المحتمل أن يكون لدى Electron نظام خاص به مشتق من الإصدار الدلالي ليناسب احتياجاتهم ، ومن غير المحتمل أنهم سوف يغيرونه ، ولكن بالنسبة إلى Lepton والمشاريع الأخرى التي ليست الآن في _ development hell _ ، قد يكون من الجيد تخطي الإصدار الدلالي تمامًا.

إذا كنت أرغب في تشغيل الخادم بمعامل التصحيح ، ألن أقوم ببساطة بتشغيل .lept باستخدام وسيطة --debug؟

نعم ، لما لا:

# 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 بدون لمس الملفات (إلى جانب فتحها). نظرًا لأنني متأكد تمامًا من أنه يمكنك "دفع_" الوسيطة من خلال المشغل ، يمكنك أيضًا إزالة الحاجة إلى --debug أيضًا ، نظرًا لأنك ستطلقها باستخدام الوسيطة المخصصة إذا كنت تريد ذلك.

لكن في شيء واحد أعتقد أنه يمكننا الاتفاق: المستخدمون يريدون أن يكونوا على نسخة مستقرة يحصلون على الدعم لها. لهذا السبب صنعت " الإصدار " هو رقم خاص به ، لأنه من غير المرجح أن يتذكر الناس العديد من الأرقام ، لكنهم عادة ما يتذكرون الرقم الأول.

sapioit إذا كان الحقل "Release" مخصصًا للمستخدمين النهائيين ، فما الغرض من الحقول الأخرى؟ بالنسبة للمستخدم النهائي ، لا يجب أن يكون هذا مهمًا على الإطلاق ، إذا كان الإصدار الجديد متاحًا ويتطلب وقت تشغيل محدثًا (عبر bump in package.json) ، فيجب تحديث وقت التشغيل أيضًا.

فيما يلي المشاكل:

1. يريد المستخدمون معرفة الإصدار الذي يتم دعمهم له.
2. إنهم لا يريدون تذكر الكثير من _الأرقام عديمة الفائدة_ ، لذلك إذا اختاروا تذكر الإصدار ، فمن المرجح أن يتذكروا الإصدار 13 من الإصدار 1.7 (على سبيل المثال).
3. لا يرغب بعض الأشخاص في التحديث حتى حدوث أشياء معينة ، مثل عدم تحديث قدر كبير من برامج تشغيل nVidia لأنه منذ إضافة توافق Thunderbolt ، يتم إخراج بطاقة (بطاقات) الرسومات الخاصة بهم بشكل عشوائي (اعتمادًا على المستخدم / الحالة) ، إما بعد تمهيد الكمبيوتر ، أو بعد فتح لعبة أو بعد دقائق قليلة من لعبها). هذا مثال جيد لسبب (ولكن هناك العديد من الأسباب الأخرى ، مثل إعلانات KMPlayer أو التحديثات التلقائية locked on ) التي تمنع المستخدمين من استخدام أحدث إصدار من المنتج. هذا يجعل من السهل النظر إلى التغيير ، عن طريق إزالة التعقيد منه.

هذه فقط بعض الأسباب ... إذا كان بإمكانك الخوض في مزيد من التفاصيل ، فيمكنني أيضًا الخوض في مزيد من التفاصيل وشرح لك بشكل أفضل سبب اتخاذ هذه الخيارات.

sapioit أليست نطاقات semver مثل >= 12.1 مرنة بما يكفي لإعلان الدعم؟
إذا كان هناك إصدار جديد متاح من وقت التشغيل ، وكان يفي بنطاق الإصدار ، فيجب أن تستخدم جميع عمليات التشغيل التالية للتطبيق أحدث وقت تشغيل ممكن.

هل يجب عليهم ذلك؟ ولكن ماذا لو قرروا عدم القيام بذلك ، بسبب القيود التقنية (مثل الشيء مع إعلانات KMPlayer وبرامج تشغيل nVidia)؟

sapioit ثم تأكد من تحديد نطاق وقت التشغيل بشكل صحيح

sapioitYurySolovyov هل هذه المناقشة ذات صلة هنا؟ سيتعين على مدير وقت التشغيل اتباع أي نظام إصدار يستخدمه إلكترون. أعتقد أن مناقشة ماهية نظام إصدار الإلكترون الذي يجب أن يستخدمه تنتمي إلى قضية أخرى.

تضمين التغريدة كنت أحاول أن أقول إننا لا ينبغي أن نبالغ في تعقيد الأشياء التي تم حلها بالفعل. لكنني أوافق على أن مدير وقت التشغيل يجب أن يفعل أبسط شيء ممكن في هذا الصدد.

yurysolovyov فلماذا لا تسمح ببساطة بعدد الأقسام في رقم الإصدار كما يريد اللاعب؟

تضمين التغريدة

إنه ليس من أجل Electron ، ولكن للمشاريع التي تبنيها.

ليس لدى Lepton نظام إصدارات معين (حتى الآن) ، ويمكن للحزم (التطبيقات) استخدام أي نظام إصدار تريده. نحتاج إلى التعامل مع هذا (على سبيل المثال ، إذا أردنا دعم تحديث التطبيقات من خلال Lepton نفسه).

من الناحية المثالية ، يجب أن تستخدم أوقات التشغيل semver ، لأنها ليست منتجات ، ولكن مرة أخرى ، يتم دعم أي إصدار من 3 أرقام الآن (على المطورين توخي الحذر عند تحديد النطاقات ، على الرغم من ذلك). إذا احتجنا في أي وقت إلى دعم أكثر من 3 أرقام (كما هو الحال مع اقتراح الإصدار الصريح الخاص بك) ، فسنحتاج إلى تمديد المحلل اللغوي (بالنسبة إلى Python ، أقترح تفرع k-bx / python-semver أو podhmo / python-semver - السابق تم تحديثه مؤخرًا ، في حين أن السابق يتبع واجهة برمجة تطبيقات node-semver بشكل أكثر إحكامًا وهو ما أستخدمه حاليًا).

هل يمكنني القول أن وجود مدير حزم وقت تشغيل مكتوب بلغة python لمشروع nodejs هو مجرد فكرة سيئة.
فقط دعنا لا نفعلها أيا كان اسمه ، ليبتون ، أو أيا كان. دعنا نكتبها في العقدة ، أو نستخدم شيئًا آخر. ودعنا لا نرسل هذه المشكلة بالبريد الإلكتروني الذي لا داعي له حول كيفية اعتقادك أنك تعرف أفضل من مخطط النسخ الدلالية المدروس جيدًا

championswimmer سيكون من المثير للاهتمام بناء مدير وقت التشغيل بإصدار من الإلكترون مُعبأ معه وواجهة مستخدم لإظهارها عند تنزيل إصدارات أخرى.

championswimmer iamale / lepton هو نوع من التنفيذ المرجعي المهمل: لقد وضعته للتو لاختبار الأفكار المختلفة التي تدور حول هذا الموضوع ، لا شيء أكثر من ذلك.

iamale ربما يجب عليك ذكرها في الملف التمهيدي لتجنب الالتباس بعد ذلك؟

تضمين التغريدة

بالنسبة للتنفيذ الحقيقي ، لدينا خياران: إما أن نستخدم node.js ، أو لغة مجمعة مثل C / ++ أو Go ؛ وبالنسبة للعقدة ، سيتعين علينا تجميع node.js معها (أو ربما فقط تشغيلها على إحدى مثيلات الإلكترون التي تم تنزيلها؟ سنحتاج إلى التأكد من أنها تعمل على أي إصدار إلكتروني عاقل ، رغم ذلك).

iamale ليس حقًا ، علينا فقط تشغيل إصدار افتراضي مثبت. بعد ذلك يمكن للتحديثات تبديله إلى إصدار أحدث في نفس المكان.

أفضل استخدام إصدار واحد معين ، لأنه إذا لزم الأمر ، يمكن تحديث كل شيء ...

قد لا يكون Lepton اسمًا رائعًا الآن لأنه تنسيق صورة .

إذن ... ماذا نسميها الآن؟ Hadron ؟

كوارك؟ إذا أراد شخص ما أخذ اسم "Muon" يمكنني إعادة تسمية أحد مشاريعي.

أليست التسمية في الواقع هي الجزء الأقل أهمية هنا؟
هل اتفقنا على دلالات التثبيت / التحديث / وقت التشغيل؟

لماذا ليس فقط electron ...

أب 15 يوليو. 2016 om 13:22 heeft Joshua Bemenderfer [email protected] Het volgende geschreven:

كوارك؟ إذا أراد شخص ما أخذ اسم "Muon" يمكنني إعادة تسمية أحد مشاريعي.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

yurisolovyov أعتقد أننا اتفقنا ... أكثر أو أقل.
@ job-v هذا ما كنت أقترحه طوال الوقت. فقط دعنا نختار واحدة ونلتزم بها.

zcbenz هل تراقب هذا الموضوع؟
إذا كان الأمر كذلك ، فسيكون من الجيد أن يكون لديك بعض الرؤية حول كيفية عمل ذلك للحصول على بعض التوجيهات هنا.

أهلا
أي تحديثات حول وقت تشغيل الإلكترون هذا؟
zcbenz ما رأيك في كل النقاش حول:

• اختيار الإصدار الإلكتروني
• تثبيت الإصدار المناسب
• جهزه للعمل في win و linux و mac
• ما الأداة التي تستخدمها للبناء معها (python ، node ، go ، c ++)؟
  YurySolovyovsapioit شكرا لأفكارك الرائعة
  iamale هو الحل الخاص بك لداستروس دبيان المستندة إلى 'ubuntu ...'

@ alnour- التجاني
نعم ، ستعمل مع أي توزيعات قائمة على dpkg لأننا لا نعتمد على الحزم الخارجية. يمكن إنشاء حزم RPM بطريقة مماثلة ، فلماذا لا؟

أفكر في بدء ريبو مركزي لجميع الأشياء الإلكترونية ، لذا يمكنك تشغيل:

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 ، أعتقد أن الإلكترون كحزمة deb واستخدمه كاعتمادات في التطبيق ليتم تثبيتها يدويًا أو من المستودع المركزي للعديد من حزم deb للإصدار الإلكتروني.
ثم استخدم هذه الحزمة بعد التثبيت لتشغيل تطبيق المستخدم

إذا بدأ أي شخص في العمل على شيء من أجل هذا ، فربما يرتبط به هنا ...

sapioit لقد بدأت العمل على حل Linux (APT / RPM). خدمة بسيطة تقوم بتحميل .asar إليها ويتم تحويلها إلى حزم وإضافتها إلى المستودعات. يجب أن يكون قابلاً للتمديد لنظامي التشغيل Windows و macOS أيضًا ، لكن لا توجد وعود بذلك في الوقت الحالي.

iamale رائع! اسمحوا لي أن أعرف عندما تحصل على العمل على النوافذ.

ماذا عن إنشاء وقت تشغيل Flatpak لنظام التشغيل Linux؟ بهذه الطريقة ، يمكن مشاركة وقت التشغيل بين تطبيقات متعددة ، وستحصل أيضًا على وضع الحماية.

مع إزالة Flatpak لاعتماده على systemd ، فمن المحتمل أن يصبح عالميًا على Linux للتعبئة الأولية.

يمكن مشاركة وقت التشغيل بين تطبيقات متعددة

اعتقدت أنه مع Flatpak لن يكون ذلك ممكنًا؟ ..

تم تصميم iamale Flatpak لمشاركة أوقات التشغيل - يختار مطورو التطبيقات وقت التشغيل ، ويثبتون SDK لوقت التشغيل هذا ، ثم ينشئون تطبيقًا flatpak-builder أو ما شابه ذلك. ثم عندما يقوم المستخدم بتثبيت التطبيق ، يقوم Flatpak بتثبيت وقت التشغيل المرتبط.

@ moosingin3space شكرا على التوضيح! إنه بالتأكيد يستحق النظر في ذلك الوقت.

الشيء الآخر الذي يعجبني في Flatpak هو أنه تم تصميمه حول حالة الاستخدام حيث يضيف المستخدم ريبو يتم تشغيله بواسطة مطور وقت التشغيل ومطور التطبيق (بشفافية) وهذا يجعل التحديثات تلقائية.

الأشياء الوحيدة التي يمكنني رؤيتها هي مشكلات تتعلق بالأمان - الحاجة إلى تعديل مكتبات النظام لاستخدام واجهة "البوابات" في Flatpak للسماح بالخروج الآمن من وضع الحماية.

يبدو أن هناك عملًا على Flatpak هنا: https://github.com/endlessm/electron-installer-flatpak

كملاحظة جانبية ، تستند Flatpak على مشروع OSTree ، الذي يقوم بمعالجة المحتوى لأشجار نظام الملفات. هذا يعني أنه يتم إلغاء تكرار الملفات ذات المجاميع الاختبارية المتطابقة تلقائيًا على القرص ، ويتم إجراء التحديثات باستخدام دلتا ثابتة. هذا يعني أنه ليس بإمكان Electron فقط توفير وقت تشغيل مشاركة يمكن تحديثه ومشاركته بشكل مستقل عبر التطبيقات ، ولكن أيضًا أن التطبيقات المبنية على ملفات متطابقة ستشاركها تلقائيًا على القرص ، وبمجرد تثبيت تطبيق و / أو وقت تشغيل ، يتم تحديث التحديثات لن يتطلب تنزيلًا كاملاً.

سامحني إذا كان هذا ساذجًا بعض الشيء ، فأنا أتساءل عما إذا كان قد تم النظر في إمكانية بناء بيئة سطح مكتب كتقدم منطقي طبيعي لبيئة وقت التشغيل. الفكرة هي أن هناك تطبيق تشغيل يتم تحميل الإلكترون عند بدء التشغيل (بدلاً من atom مثلاً) مع القدرة على تشغيل تطبيقات إلكترونية أخرى (نظرًا للمكتبة الكبيرة المتنامية) عن طريق إنتاج حالات جديدة من العارض أو ربما إعادة استخدامه والحصول على يتم فتح التطبيقات في علامة تبويب جديدة.

يبدو أن Chrome كما هو الحال في نظام التشغيل في فهمي هو هذا بالضبط (لكنه يقتصر على تطبيقات الويب). سيكون وجود تطبيقات سطح المكتب مع وصول كامل إلى fs من خلال nodejs (على عكس قيود chromeAPIs) مع الإلكترون كبيئة تشغيل أعلى Linux (أو حتى استبدال أو على الأقل زيادته في بداية explorer.exe في Windows) سيكون مثيراً للغاية. أعتقد أن هذا حل أنظف من ChromeOS الذي يقوم بتحميل ما هو فعال وقت تشغيل ثم محرك متصفح ثم استضافة تطبيق - هنا سيقوم أحدهم بتحميل التطبيقات مباشرة في وقت التشغيل وسيكون المتصفح نفسه مجرد تطبيق آخر (وهناك كذلك العديد من مشاريع متصفح الإلكترون المبتكرة في البرية).

مرة أخرى ، أتساءل عما إذا كان قد تم النظر في ذلك أم أن هناك مشروعًا ما يقوم بذلك بالفعل. إذا لم يكن الأمر كذلك ، فربما تستطيع الجنية أن تضع كلمة في أذن إدارة جيثب لتأخذ زمام المبادرة ؟؟؟؟

ملاحظة: هناك شيء واحد لا أقترحه هنا وهو نقل OS.js (وهو مشروع صغير لطيف في حد ذاته) إلى الإلكترون ولكنه يخلق بيئة لتطبيقات الإلكترون (على الرغم من أنني لن أعارض إعادة استخدام الكود من OS.js).
PPS: سأقوم بإنشاء مشكلة منفصلة إذا كانت تعتبر جديرة بالقدر الكافي أو إذا كانت تشتيت الانتباه عن مشكلة بيئة وقت التشغيل.

أعتقد أن بيئة وقت التشغيل المدمجة ستجعل تطبيقات Electron أفضل بكثير. أعتقد أن حزمها يجب أن يكون مجرد ضغط الملفات وإعادة تسمية الامتداد إلى asar ، ولكن يجب أن يحتوي هذا الأرشيف على مجلدين ، أحدهما يسمى asar ، مع محتوى مجلد وقت التشغيل الافتراضي ، والآخر يسمى enviroment مع الملفات التي يجب أن تحل محل التكوين الافتراضي.

على سبيل المثال ، سيؤدي تشغيل تطبيق جديد إلى نسخ الإصدار المطلوب من Electron في مجلد مؤقت ونقل وقت التشغيل (محتويات المجلد asar ) إلى موقع الملفات الافتراضي ، بينما المجلد الاختياري enviroment (مع 3 مجلدات فرعية ، windows ، linux ، macosx ) يجب أن تحتوي على الملفات التي يمكن لصقها فوق المجلد الافتراضي ، والكتابة فوق محتوياته.

بهذه الطريقة ، نحتاج فقط إلى تطبيق أو شيء ما لتقييم الامتداد .asar لأحد التطبيقات ، ولجعل هذا التطبيق يصل إلى المجلد الذي يحتوي على الإصدارات التي تم تنزيلها من Electron (المؤرشفة) ، ونسخها (استخراجها) في مجلد مؤقت ، واستخدم محتويات .asar لتعديل ما هو مطلوب ، ثم قم بتشغيل مثيل Electron من مجلد temp وانتظر حتى يموت من أجل فرض حذف المجلد temp. بالنسبة للمبتدئين ، حتى مجرد الحصول على التكوين الافتراضي للعمل مع أرشيف بامتداد مخصص على جميع أنظمة التشغيل المدعومة سيكون قفزات فائقة مما لدينا بالفعل. بعد ذلك ، يمكننا القلق بشأن وجود مجلد ثالث ، config ، حيث يتم الاحتفاظ بإعدادات التكوين الحالية ، وربما مجلد _config بداخله ، لإعدادات التكوين الافتراضية (إذا احتجنا إليها ).

مع التخلص التدريجي من تطبيقات Chrome المجمعة قريبًا ، سيبحث الناس عن بدائل. سيكون وقت التشغيل رائعًا لتلك المشاريع الصغيرة التي لن تتوفر دائمًا على إصدارات / إصدارات. نظرًا لأن التطبيقات مصنوعة باستخدام تقنية الويب تمامًا مثل تطبيقات Chrome ، فسيكون من المفيد للمستخدم تشغيل التطبيق ببساطة من المصدر. لا يمكنني تبرير نقل عدد لا يحصى من المشاريع الصغيرة إلى Electron إذا كانت الطريقة الوحيدة التي يمكن للمستخدم من خلالها تشغيلها هي تنزيل إصدار ثنائي كبير لكل برنامج نصي أو تطبيق فردي ، ولا يمكن للمستخدمين الاستفادة من تشغيل أحدث التزام دون إنشائه أو تنزيل Electron's IDE أنفسهم.

مرحبًا بالجميع ، حتى لو لم أكن في عالم تتمحور حول JS ، فقد كانت لدي مؤخرًا فكرة مشابهة تمامًا لـ _Electron_ (والتي تصادف أنني أعرفها ، ولكن لا أستخدمها من أجل التطوير) ولكن مع جمهور أوسع ؛ لوضعها بطريقة بسيطة للغاية: _ ما عليك سوى قصر تقنيات الويب على واجهة المستخدم الرسومية وتوفير واجهات برمجة التطبيقات.

لذا استمر في استخدام مكتبة / وقت تشغيل مشتركة ذات إصدارات دلالية (مبنية على رابط _Blink_ ، _Skia_ ، إلخ ؛ ربما في - "حديثة" - _C ++ _) ودع المطورين يختارون اللغة باستخدام الروابط ...
على سبيل المثال ، إذا كنت تريد _JS_ ، فاستخدم _Node.JS_ ؛ تريد _C ++ _ ، لا مشكلة ؛ تريد _Python_ ، مع _CPython_ القياسي يجب أن يكون ممكنًا ؛ هل من شيء آخر ؟ ربما _SWIG_ يمكن أن تساعد. في (تقريبًا) على أي حال ، نحن نفوز.

بمجرد حصولنا على المكتبة / وقت التشغيل المشترك (المعتمد على نظام التشغيل) ، يمكنك حل المشكلة الرئيسية ويمكنك توضيح الطريقة التي تعتقد أنه من الأفضل توصيل الباقي بها (بخلاف إحداث ثورة في نهج برمجة واجهة المستخدم الرسومية / تحديثها لبقيتنا ؛ أ خطوة كبيرة إلى الأمام!).

لذا يجب أن تكون نقطة البداية هي "الانقسام" (يجب أن يكون لها اسم متعلق بالفيزياء ، بالنظر إلى حقيقة أنك تهتم به حقًا) لمشروع _Electron_ ... :)

لا يمكننا حتى القيام بعمل إضافي لـ Electron ، لكنني أعتقد أن ذلك لن يحقق هذا القدر من النجاح ، ما لم يكن هناك الكثير من الإعلانات.

dezzeus كان هناك جهد في هذه السطور قبل أن تلاشى. ألق نظرة على وقت التشغيل الدافع المخصص لاستضافة متصفح الاختراق .

قرأت من خلال هذا الخيط الطويل والرائع مرتين ، حيث أرغب في رؤية المزيد من الزخم في هذا الاتجاه. إليكم آخر بيان صادر عن zcbenz ، أعتقد أنه لا يزال ذا صلة:

لا توجد عقبة فنية في تنفيذ ذلك ، كل شيء يمكن أن يكون مجرد تطبيق Electron نفسه. لكن المشكلة تكمن في أنه ليس من السهل تنفيذ أيٍّ منهما ، مع أخذ جميع التفاصيل في الاعتبار ، أعتقد أنه يتطلب فريقًا صغيرًا يعمل بدوام كامل عليه ، ولست متأكدًا مما إذا كان سيحدث على الإطلاق.

(تأكيد إضافي) - كيف أفسر هذا ، إذا كان الحل سيتم بناؤه في أي وقت ، فسوف يعتمد على جهد المجتمع و / أو احتياجات العمل لـ GitHub والمنظمات الأخرى التي لها حصة فيه.

نظرة عامة موجزة بواسطة @ yan-foto تبدو وكأنها خطة مقاربة معقولة ، مع أهداف / متطلبات واضحة. هناك تطبيق مرجعي / نموذج أولي يسمى lepton بواسطة iamale ، يقترح "مدير إصدار وقت تشغيل عالمي" يستهدف Electron. كان تعليق jorangreef مثيرًا للفضول ، حيث وصف "تطبيقًا قيد الإنتاج بآلية التحديث التلقائي semver" ، مع التحديث التفاضلي ، وإلغاء المضاعفات (لست متأكدًا مما إذا كان هذان العنصران متماثلان) والضغط. بدت العديد من الميزات التي وصفها مثالية للتكيف / التبني.

هذه خطوات محددة للاستكشاف والتقدم ، وتعطيني الأمل في أن الحل (الحلول) العامة الجديرة بالإنتاج ستولد من هذه العملية.

من الجميل أن نرى أنه لا يزال هناك أناس يؤمنون بالإنسانية.

الشيء الوحيد الذي يمنع هذا من أن يصبح منتجًا هو عدم وجود فرص عمل فورية يتم فتحها من خلال صنع هذا المنتج (المفهوم).

@ eliot-akira نعم ، هذا ما هو عليه. الكود الذي كتبته يقوم بإلغاء التكرار المستند إلى المحتوى لكل ملف (أجزاء متغيرة الحجم) داخل ملف لتقليل التنزيلات عند تغيير بضع وحدات بايت فقط داخل الملف. كما أنه يقوم فقط بتحديث تلك الملفات التي تتغير بين الإصدارات والتحديثات للتطبيق ككل وهي ذرية في مواجهة أي أخطاء. إما أن الإصدار الجديد سيبدأ أو سيبقى الإصدار القديم في مكانه.

أرغب في فتح مصدر الشفرة ، وهناك بعض الأشياء التي ما زلت بحاجة إليها لترميز الفكرة العامة. سيكون من الرائع أن تشترك العديد من تطبيقات Electron في عملية مشرف محدث تلقائي واحدة (مع ذاكرة تخزين مؤقت مشتركة محلية غير قابلة للتغيير لإلغاء البيانات المكررة عبر العديد من تطبيقات Electron المستقلة).

سيكون الهدف من هذا النهج بأكمله هو تقليل النطاق الترددي للتنزيل الكلي المطلوب لتثبيت وتحديث تطبيقات Electron ، مع الحفاظ على تطبيقات Electron معزولة تمامًا عن بعضها البعض (سيكون للتطبيقات المتعددة ثنائيات Electron الخاصة بها). سيكون الهدف غير المقصود لتقليل بصمة القرص.

يجب تنزيل أول تثبيت لتطبيق Electron بالكامل ، لكن عمليات تثبيت تطبيق Electron اللاحقة ستستفيد من ذاكرة التخزين المؤقت المشتركة المحلية غير القابلة للتغيير.

نظرًا لأنه يتعلق بالتحديث التلقائي ، يجب أن أجلب مشكلة تعيين الإصدار ، وحقيقة أن أنظمة إصدارات متعددة تستخدم أعدادًا مختلفة من الأرقام للإصدار. أنا ، على سبيل المثال ، أستخدم إصدارًا صريحًا .

لدينا نوعان من الأشياء التي يجب تحديثها هنا:

• الإلكترون نفسه ، الذي يستخدم إصدار الإلكترون و
• التطبيقات ، التي لا نحتاج حقًا إلى الاهتمام بها حول SemVer أو أي شيء لأنها لا تحتوي عمومًا على واجهة برمجة تطبيقات (ما لم تكن تستخدم نوعًا من النظام الإضافي ربما).

على الرغم من أننا إذا احتجنا إلى دعم العديد من أنظمة الإصدار ، فربما يكون لدينا بعض الإعدادات في package.json ، مثل "breakingVersionComponents": 1 لـ semver و 2 للإصدار الصريح أو إصدار الإلكترون؟

(قد يكون الخيار الآخر هو إضافة فاصل آخر في الإصدار ، مثل 1.3:3.7 والذي سيفصل بين الأجزاء المكسورة وغير القابلة للكسر. ثم يصبح Semver x:y.z و Electron Versioning x.y:z . هذا من شأنه كسر كل أداة هناك ، رغم ذلك ، على ما أعتقد.)

jorangreef إذا كان كل تطبيق لا يزال لديه ثنائي إلكترون خاص به ، فلن يؤدي ذلك إلى حل مشكلة الاستخدام الزائد لذاكرة الوصول العشوائي عند فتح العديد من تطبيقات Electron.

لقد لاحظت تعليقًا أقدم من @ 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 ، شكرًا لعملك على Lepton ، في نظري هذا تنفيذ ملموس في اتجاه الحل.

فكرة أخرى: مجرد نشر التطبيقات في npm ، وإنشاء غلاف npm خاص يمكنه تثبيتها وتشغيلها. سيكون من السهل حقًا نشره في ذلك الوقت وربما سهل الاستخدام (يعتمد ذلك على جودة الغلاف) أيضًا. ما هو رأيكم أيها الأصدقاء؟

بالنسبة لمشاريع أنظمة التشغيل ، يمكننا استخدام npm كاستضافة ، وبالنسبة للمشاريع المغلقة ، نحتاج إلى أن نكون قادرين على توجيه مدير الحزم إلى ملف .asar لتنزيله ، وربما بعض البيانات الوصفية الأخرى. السؤال هو كيف سيبدو هذا المدير اللطيف (ويسمى)

أيضًا ، أتساءل عما إذا كنا نحتاج حقًا إلى أمر منفصل لتثبيت التطبيقات ، ربما فقط
electron install atom سيكون كافيا؟

رأيت هذا للتو على Node Weekly:

Electrino هو بديل تجريبي لوزن الريشة للإلكترون الشهير والقوي. ينفذ جزءًا صغيرًا من واجهات برمجة التطبيقات المتاحة في Electron ، لكن حجم تطبيق الإخراج أصغر بكثير.

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

https://github.com/pojala/electrino

YurySolovyov لا يجب أن تواجه مشاريعYurySolovyov مشكلة في النشر في npm أيضًا - هناك عدد قليل من مشاريع Node.js موجودة بالفعل ، على سبيل المثال أرفقها. (من الناحية الفنية ، ليس في npm ، مجرد أداة تحميل ، لكنني على أي حال لا أستطيع أن أرى كيف سيساعد التحميل الجانبي لـ .asar حيث لا يزال من الممكن تفريغها.)

كنت أحاول فقط التفكير في كيفية إعادة استخدام أكبر قدر ممكن من النظام البيئي الحالي.

لست متأكدًا من رغبتنا في ...

jorangreef إذا كان كل تطبيق لا يزال لديه ثنائي إلكترون خاص به ، فلن يؤدي ذلك إلى حل مشكلة الاستخدام الزائد لذاكرة الوصول العشوائي عند فتح العديد من تطبيقات Electron.

@ Jop-V لا ، لن يحدث ذلك. لا أريد أن أخلط الأشياء وينتهي بي الأمر مع وحش. الفكرة هي أن يكون لديك مُثبِّت / مُحدِّث تلقائي رائع يحل معظم المشاكل الواردة في التعليق الذي فتح هذه المشكلة: https://github.com/electron/electron/issues/673#issue -44580957

لا تكمن المشكلة في وجود العديد من الثنائيات على القرص ، ولكن تأثير الشبكة على المستخدم الذي يتعين عليه تنزيل نسخ متعددة من البرنامج الثنائي وتحديثها تلقائيًا.

ومع ذلك ، فإن حل استخدام الذاكرة يستحق بالتأكيد القيام به. أعتقد أن هناك مجموعة متنوعة من الطرق للقيام بذلك ولكنها لا تحتاج بالضرورة إلى أن تكون مجمعة مع مُثبِّت / مُحدِّث تلقائي لإلغاء البيانات المكررة.

إذا كانت بصمة القرص تمثل مشكلة أيضًا ، فيمكن معالجتها من خلال الروابط الثابتة على الأنظمة التي تدعمها ، على الرغم من أن ذلك سيبدأ في انتهاك فكرة العزل بين التطبيقات (على سبيل المثال ، إذا قرر أحد التطبيقات الكتابة إلى ارتباط ثابت مشترك مع شيء آخر).

بدلاً من ذلك ، على الأقل في نظام التشغيل macOS على المدى المتوسط ​​، سيقوم APFS بنسخ الملفات بالرجوع إليها ، مع إزالة التكرار الشفافة تحت الغطاء ، مما يقلل من مساحة القرص. سيكون هذا أفضل من الروابط الصلبة لأنه سيبقي العزلة سليمة (نسخ عند الكتابة).

jorangreef ما الهدف من استخدام ثنائيات إلكترونية منفصلة للتطبيقات؟ ما نوع العزلة التي تتحدث عنها؟ آسف إذا كان هذا سؤال غبي ، لكنني لم أفهمه.

iamale قد تستهدف بعض التطبيقات إصدارات رسمية مختلفة من Electron ، أو قد توزع إلكترونًا مبنيًا مسبقًا تم تجميعه من مصادر معدلة. هذا النهج سيعمل معهم جميعًا. حتى مع وجود اختلافات كبيرة في الثنائيات (على عكس JS وتغييرات الأصول) ، فإن إلغاء البيانات المكررة سيؤدي إلى التخلص من 70٪ أو أكثر من متطلبات التنزيل ، لذلك ستستفيد التطبيقات التي تستهدف ثنائيات مختلفة.

باستخدام هذا النهج ، من الممكن شحن أي نوع من الحزم (أي مجموعة من الملفات والأدلة المحددة بواسطة بيان JSON) ، وليس بالضرورة تطبيقات Electron فقط. قد يكون أيضًا تطبيق Python. إنه غير مألوف لأي خيارات يريد المطور القيام بها تجاه كيفية هيكلة أو حزم تطبيقاته (الملفات مقابل asar ، إلخ).

الفكرة الرئيسية هي أن النظام البيئي يستفيد من دلتا التثبيت / التحديث الصغيرة جدًا حيث أن المزيد والمزيد من التطبيقات تستخدم نفس المثبت / التحديث التلقائي. في هذه الأيام ، يقوم كل تطبيق بتشغيل التحديث التلقائي الإشرافي الخاص به وهو غير ضروري.

jorangreef شكرا لك! أعتقد أنه يشبه إلى حد كبير مستودعات APT / RPM الكلاسيكية ، ولكنه أكثر "ذكاءً" (لا داعي للإعلان عن تبعياتك أو أي شيء آخر).

السؤال هو كيف سيبدو هذا المدير اللطيف (ويسمى)

ماذا عن Minifitron (الإلكترون المصغر)؟

أعتقد أن ملف الأرشيف (على سبيل المثال .asar ) يجب أن يحتوي على محتويات المجلد حيث يوجد ثنائي الإلكترون ، حتى نتمكن من إضافة أو استبدال الملفات التي تخرج عن المعيار. سيكون لدينا كل إصدار في مجلد أو أرشيف ونسخه إلى مجلد مؤقت جديد لوقت تشغيله.

ويجب أن يكون هناك خيار لتثبيت التطبيقات أو تصغيرها ، فالتثبيت سيتركها كمثيل جديد للإلكترون ، بينما سيستخدم المصغر md5 لحذف الملفات التي لم يتم تغييرها عن طريق إلغاء أرشفة .asar (أو ما سنستخدمه) وأرشفة ذلك واستبدال الملف الأصلي ، كحالة محدثة للتطبيق الذي استخدمناه.

فقط لإلقاء فكرة أخرى: ماذا لو احتوى كل تطبيق Electron على نسخه الخاصة من أوقات التشغيل ، ولكن عند التشغيل ، يمكنهم التحقق مما إذا كان هناك مثيل قيد التشغيل بالفعل من Electron (وإصداره) - إذا كان متوافقًا (ضمن نطاق semver ، وما إلى ذلك) ، يمكن للتطبيق التواصل معها واستخدام نفس الحالة ؛ إذا لم يكن متوافقًا ، فيمكن للتطبيق بدء مثيله الخاص من Electron. يبدو أن هذا يعالج مشكلة تقليل أثر الذاكرة.

(ثم ​​مرة أخرى ، بحلول الوقت الذي يتم فيه تشغيل التطبيق ، أعتقد أنه سيكون هناك بالفعل عدة حالات من وقت التشغيل على أي حال .. لذلك قد لا يكون منطقيًا ..)

@ eliot-akira كانت لديه فكرة مشابهة جدًا أثناء قراءة هذا الموضوع.

(ثم ​​مرة أخرى ، بحلول الوقت الذي يتم فيه تشغيل التطبيق ، أعتقد أنه سيكون هناك بالفعل عدة حالات من وقت التشغيل على أي حال .. لذلك قد لا يكون منطقيًا ..)

حسنًا ، يمكن أن يتم تحميله بما يكفي للتحقق من ذلك ، وبعد أن يرى أنه لا يوجد "شريك إلكتروني" متاح لمشاركة وقت التشغيل معه ، قم بتحميل الباقي.

هذا من شأنه أن يخلق الكثير من المخاوف الأمنية. يمكن أن يقدم تطبيق شرير نسخة معدلة من وقت التشغيل للآخرين ، والوصول إلى بياناتهم. قد يكون من الممكن استخدام شريحة ذاكرة مشتركة ، وجعلها للقراءة فقط ، ويمكن لتطبيقات "المستخدم" (التي تستخدم وقت تشغيل تطبيق تم إطلاقه مسبقًا) أن تحقق وقت التشغيل ، ولكن تطويرها لجميع أنظمة التشغيل المستهدفة قد يكون كابوسًا ( لا أعرف حتى ما إذا كان هذا موجودًا في Windows ؛ أفترض أنه يجب ذلك).

إذا كان ذلك من باب الفضول فقط ، فهل هذا غير منطقي؟ هل سيكون بنفس القدر ، أو قد يكون عملًا أكثر بكثير من وقت تشغيل مشترك منفصل؟ هل تخلق مشاكل إضافية أخرى؟

تمت الإضافة لاحقًا: قد يكون هذا بعيد المنال ، ولكن توجد تقنيات لإزالة تكرار الصفحات المتطابقة على ذاكرة الوصول العشوائي ؛ يتم استخدامها في الغالب في بيئات المحاكاة الافتراضية وبرامج Hypervisor. هذا هو أول شيء فكرت فيه وركضت للتحقق مما إذا كانت أنظمة تشغيل اليوم تستخدم هذا ، ومن ثم قد تكون هناك طريقة لضبط الإلكترون بطريقة يمكن الاستفادة من هذه الميزة ، ولكن لا يبدو ذلك كذلك.

jorangreef إذا قام مطور بتعديل ثنائي الإلكترون ، ألا يجب عليهم فقط إنشاء طلب سحب؟

@ Jop-V يمكنهم ذلك ، لكن يمكنهم أيضًا الاحتفاظ بالشوكة الخاصة بهم. حتى أنهم قد لا ينشرون المصادر إذا كانوا لا يريدون ذلك - لا يفرض ترخيص معهد ماساتشوستس للتكنولوجيا أي التزامات عليهم.

jkurei لاستكشاف الفكرة بشكل أكبر ، أتخيل طريقتين قد تعملان:

1) غلاف أصلي رفيع حول Electron أو التطبيق نفسه ، سيكون "المشغل". يتحقق من وجود مثيل قيد التشغيل بالفعل من Electron وإصداره: إذا كان متوافقًا ، فقم بتسليم بقية عملية الإطلاق إلى هذا المثال واخرج ؛ إذا لم يكن كذلك ، فاستمر في إطلاق مثيله الخاص من Electron.

2) مكتبة JavaScript يمكن للتطبيقات نفسها استيرادها إلى العملية الرئيسية ، كمشغل. يمكنه تنفيذ بروتوكول مشابه لما ورد أعلاه: بث وجود مثيل إلكتروني ، وطريقة لتطبيقات أخرى (باستخدام نفس المكتبة) للعثور عليه والتواصل معه - ربما عبر منفذ الشبكة ..؟

@ eliot-akira أعتقد ، بالمناسبة ، أن هناك بالفعل نوعًا من "البروتوكول" البدائي الذي تتحدث عنه ؛ هذا الشيء وراء app.makeSingleInstance الذي يكتشف بطريقة ما عمليات Electron قيد التشغيل بالفعل وما إذا كانت هي نفس التطبيق أم لا (ربما عن طريق الحصول على المسار الكامل القابل للتنفيذ).

iamale أرى أن الطريقة تستخدم فئة Chromium الأصلية ProcessSingleton لتسجيل دليل التطبيق الحالي (كمعرف فريد؟). نعم ، كنت أتخيل شيئًا كهذا ، ليتم تهيئته قبل app.on('ready') . لذلك ، بدلاً من مجرد التحقق من وجود مثيل موجود لهذا التطبيق المحدد ، يمكنه التحقق من وجود أي مثيل للإلكترون - ثم "تسليم عملية التشغيل" إذا كان متوافقًا.

لزاوية أخرى ، وجدت وحدة تسمى node-ipc يمكنها التواصل بين عمليات Node.js المنفصلة. ربما يمكن استخدام ذلك لإدارة عملية الإطلاق على طبقة JS فقط.

فيما يلي مثال أساسي لمشاركة مثيل Electron واحد بين تطبيقات متعددة ، باستخدام node-ipc للتواصل بين العمليات: https://github.com/eliot-akira/singletron-example.

محور IPC هو الوحدة النمطية الخاصة به ، وهو غلاف رقيق يبلغ حوالي node-ipc . تتم التهيئة في العملية الرئيسية ، main.js في الأسفل .

عند البدء ، سيحاول التطبيق أولاً الاتصال بمثيل إلكتروني موجود. إذا لم يكن هناك أي شيء ، فسيبدأ "خادمًا" يستمع إلى الطلبات بين العمليات. ستتصل أي حالات لاحقة من التطبيق بالمثيل الأول ، وتتلقى "التكوين" (إصدارات Chrome ، و Node ، و Electron) ، وتكون قادرة على تبادل الرسائل ، على سبيل المثال ، لطلب نافذة جديدة لنفسها.

إنه تطبيق بسيط لتبدأ به ، ولكن ما يعجبني في هذا الأسلوب هو أن الأمر متروك للتطبيق للتعامل مع كيفية تفاوض الخادم / العملاء: التحقق من التوافق ، وما إذا كان سيتم فتح نوافذ جديدة ، أو تمرير إعدادات أخرى ، وما إلى ذلك.

@ eliot-akira أعتقد أن تحديد معرف الخادم الافتراضي هو فكرة _ حقًا-سيئة للغاية_ في هذه المرحلة: إذا بدأ أي شخص في استخدام هذا لأغراضهم الخاصة ، فمن المحتمل أن يقوموا فقط بتعديل رمز المثال الخاص بك لاحتياجاتهم الخاصة وكسر البروتوكول ( وبالتالي كسر التطبيقات الأخرى التي تعتمد على هذا).

بصرف النظر عن ذلك ، تبدو جيدة ونظيفة ، شكرا لك!

إعادة: مخاوف أمنية: تطبيقات Electron تعمل بالفعل بامتيازات المستخدم ، وإذا وضعناها في شجرة عملية واحدة ، فسيكون لديهم بالفعل (أو سيكونون قادرين على الوصول) إلى مثيلات Electron الأخرى. ومع ذلك ، أعتقد أنه إذا كنا سنخفف من ذلك ، فإن قدرة الجميع على توفير نسخة إلكترونية مصححة لن تساعد بالتأكيد.

iamale شكرا لك على ردود الفعل. لقد كشفت عن خيار تعيين معرف الخادم ، في حالة رغبة بعض التطبيقات في تنفيذ بروتوكول خاص بها ، بدلاً من بروتوكول مشترك لجميع تطبيقات Electron. في الواقع ، لا يوجد مثل هذا البروتوكول المشترك حتى الآن - لذلك ، في هذه المرحلة ، ليس من العملي لهذا الغرض ، أن تتصل التطبيقات غير المعروفة وتسليم عملية التشغيل. كان من المفترض أن يكون إثباتًا للمفهوم ، لذلك سأقوم بتحديث المستند لذكر ذلك. سأستمر في استكشاف كيفية جعله أكثر عملية.

أعتقد أنه سيكون من المفيد للأشخاص القادمين حديثًا الحصول على نوع من الملخص مرة أخرى ، على غرار ما فعله شخص ما قبل نصف عام.

أيضا ، ماذا يفعل المستخدم النهائي؟

إذا كنت المستخدم النهائي (وأنا جزئيًا) ، فأنا أريد حزمة واحدة .exe / .app / .deb تعمل نوعًا ما مثل برنامج التثبيت portableapps.net. يجب أن يكون ملف exe صغيرًا ويجب تنزيل أحدث إصدار محدث من البرنامج تلقائيًا مع وقت التشغيل إذا لم يكن مثبتًا. في عملية الإعداد البسيطة ، يجب أن أكون قادرًا على تعيين "موقع وقت التشغيل" (باستخدام مربع اختيار الخيارات المتقدمة) يدويًا مع مربعات الاختيار لإنشاء روابط النظام (سطح المكتب ، قائمة البدء ، إلخ).

عندما أقوم بتنزيل البرنامج التالي ، يجب إعادة استخدام وقت التشغيل السابق (مهما كان شكله ، idc) إن أمكن.

بصفتي مطورًا ، أود أن أكون قادرًا على إنشاء مثل هذه الحزمة القابلة للتنزيل بنقرة واحدة (في أفضل الأحوال). يجب أن تقوم هذه النقرة الواحدة بتحميل الكود الخاص بي إلى بعض المستودعات (على غرار متجر play / web / app store) وإنشاء حزمة .exe / .app / .deb بالنسبة لي يمكنني مشاركتها مع العالم.

أنا لست منخرطًا مع Electron حتى الآن ، لأنني أقوم فقط بإنشاء مُثبِّت تعديل صغير باستخدام Electron و Electron-Edge لـ C #.

قد أكون ساذجًا ، لكن afaik ، السبب الوحيد "الحقيقي" ، لماذا لا تتوافق الأشياء + إصدارات -0.1 هو أنه يجب إعادة بناء ملفات .node لكل إصدار من إصدارات Electron. ألا يمكن إنشاء ملفات .node هذه أثناء الإعداد باستخدام نوع من الحلول السحابية؟

أيضًا ، هل ستكون صفقة كبيرة حقًا لإنشاء إلكترون LTS واحد كبير كل نصف عام أو نحو ذلك؟ أشك في أن المطورين يستخدمون في الواقع جميع الميزات المتطورة لكل إصدار جديد من Electron ، لذلك إذا أجبرناهم (نوعًا ما) على الالتزام بإصدار واحد لفترة أطول ، فإن ذلك سيجعل الأمور أسهل كثيرًا.

Imo ، المشكلة الوحيدة هي عدم وجود نسخة LTS من Electron جاهزة للجميع للاعتماد عليها.

باستخدام هذا الإصدار lts ، يجب أن يكون إنشاء التحديث التلقائي وإلغاء البيانات المكررة وإدارة الإصدار وكل هذه الأشياء الأخرى بمثابة قطعة من الكعكة.

يحتوي حل المثبت الذي اقترحته أيضًا على فائدة إضافية ، وهي أن المستخدم لا يرى مجلد البرنامج حقًا ، لذلك لا يتعين علينا حزمه على هذا النحو. أيضًا ، يمكن إضافة "ملفات تنفيذية فرعية" متعددة أثناء التثبيت (على سبيل المثال للألعاب متعددة اللاعبين ، و "ملفات تعريف" متعددة وما إلى ذلك). يجب تسمية هذه الملفات التنفيذية فقط باسم somelaunchername.electron ، ولكن بتنسيق Json مع معلومات حول كيفية تشغيل البرنامج (مثل index.html للتحميل وأشياء من هذا القبيل). يجب مشاركة node_modules بين الملفات التنفيذية (إلا إذا احتاج المطور إلى استخدام إصدارات مختلفة من وحدة نمطية لكل ملف تنفيذي). يمكن تحقيق ذلك من خلال وجود ثلاثة مجلدات node_modules. واحد لكل ملف قابل للتنفيذ وواحد لكليهما. في package.json سيكون هناك فقط معلومات عامة. يجب أن يكون كل ملف إلكتروني (imo) قادرًا على الكتابة فوق القيم الموجودة في package.json.

يمكن بعد ذلك إضافة ملفات .electron هذه إلى قائمة البدء والمواقع الأخرى باستخدام إما "runtime --appname" أو بروتوكول مخصص مثل Steam. لست متأكدًا من أيهما أفضل ، لكن البخار الذي أثار استيائي عدة مرات في الماضي.

الآن ، إذا أراد المطور حقًا شحن وقت تشغيل معدل ، فلا يزال بإمكانه حزمه بالطريقة التي يتم بها حاليًا.

ليستنتج:
في رأيي ، تتمثل الخطوة التالية في إنشاء إصدار lts ثابت وإشراك المطورين من خلال تزويدهم بحل تغليف سهل. يمكن تحسين عملية التثبيت لاحقًا ، ويكفي حاليًا تنزيل وقت تشغيل وقاذفة لملفات الإلكترون هذه.

ماذا تظنون يا جماعة؟

يمكن لـCiriousJoker منشئ الإلكترون إنشاء تطبيق محمول ومثبت ويب. بقدر ما أرى ، على windows المشتركة DLL هو الحل. تدعم DLL المشتركة أيضًا حساب المرجع ، لإزالة وقت تشغيل الإلكترون غير المستخدم تلقائيًا. حاليًا ، وقت تشغيل الإلكترون على النوافذ في ملف exe كبير واحد (باستثناء node.dll). إذا كان من الممكن تقسيمها إلى dll ، فمن السهل جدًا تنفيذ الحل على جانب منشئ الإلكترون. سيوفر أيضًا الذاكرة ، وليس مساحة القرص فقط.

zcbenzpaulcbetts هل فكرت في استخدام dll المشترك؟ هل من الممكن تقليل حجم exe ونقل كل كود الإلكترون إلى dll (لذلك ، احتفظ بالحد الأدنى فقط من الشفرة في exe)؟ إنه لأمر رائع أنه منذ الإلكترون 1.7.5 تمت إزالة وقت تشغيل C المشترك من node.dll و exe. الآن ، 30 ميغابايت من التعليمات البرمجية موجودة بالفعل في ملفات DLL (لكن exe لا يزال كبيرًا - 80 ميغابايت) ، لذلك ، يمكنني البدء في تجربته.

develar imo ، المشكلة الحقيقية ليست كيف يمكننا مشاركة ملفات dll ، بل بالأحرى كيف يمكننا الحصول على نسخة من الإلكترون

هل يقوم Chromium بإجراء إصلاحات أمنية للإصدارات الأقدم؟ لدي شعور قوي بأن سياستهم هي "الترقية إلى أحدث إصدار لتكون آمنة". بدون تحديثات الأمان من Chromium ، يبدو أن LTS of Electron بعيد المنال.

@ sedwards2009 لكن هل هناك بالفعل العديد من التهديدات؟ بالتأكيد ، قد أكون ساذجًا هنا ، لكننا لا نحمي المستخدمين من الإنترنت المفتوح ، ولكن من التطبيقات المحلية (في الغالب). يعد تشغيل أي ملف exe. أكثر خطورة بمقدار 10000 مرة ، كما أن كتابة فيروسات exe. أسهل أيضًا 10000 مرة حتى عندما كان برنامج تثبيت تطبيق الإلكترون الشرعي الخاص بي يسمى فيروسًا بواسطة AVG.

بالنسبة لي ، فإن "تجديد" هذا الأمن كل 6 أشهر أو نحو ذلك يكفي. أيضًا ، من غير الآمن السماح لكل مطور باستخدام نسخته المعبأة من الكروم ، فيمكنهم فعل المزيد من الشر باستخدام ذلك على أي حال لا يمكننا منعه (مع وقت تشغيل مشترك أو غير ذلك)

نعم ، ينتهي الأمان حيث يحصل التطبيق على وصول أولي إلى الخدمات والشبكات.
إما أن تثق في بائع التطبيق أو تبتعد عنه. <- هذا لتطبيقات مغلقة المصدر.
بالنسبة إلى برامج OSS ، من الأفضل ، أن معظمهم على الأقل ليس لديهم نوايا سيئة ، ولكن قد يحتويون على أخطاء.

حسنًا ، ما مدى سهولة الحصول على إصدار lts؟ ألا يمكن أن نختار الإصدار الحالي فقط ونعلن أنه إصدار lts؟

من المحتمل أن تظهر المشكلة الأكبر لاحقًا ، عندما نحاول إقناع المطورين بإنشاء تطبيقاتهم لهذا الإصدار المحدد ، ولكن هذه هي الخطوة الأخيرة على أي حال. لإنشاء وقت تشغيل مشترك ، نحتاج فقط إلى اختيار وقت التشغيل أولاً

أود أن أقول إن هذا يجب أن يكون قرار المطور - لمعرفة أي إصدارات وقت التشغيل يجب أن يعمل التطبيق عليها.
نوع مثل npm مجال محركات .
مهمة Runtime هنا هي جلب dll المطلوب أو أي شيء والسماح بتشغيل التطبيق.

ولكن إذا سمحنا لهم باختيار واحد من العشرات من نفس وقت التشغيل تقريبًا غير المتوافق ، فسنفتقد النقطة تمامًا ، أليس كذلك؟ نحن نحاول تجنب وجود عدة أوقات تشغيل ، وليس فقط إزالة تكرارها. كما ذكر أحدهم في مكان ما في البداية ، فإن إلغاء تكرار أوقات التشغيل لا يكون له معنى كبير عندما تكون هناك فرصة واحدة في مثل 20 لاستخدام نفس وقت التشغيل مرة أخرى على نفس النظام.

أو هل تقصد أن لدينا معظم وقت التشغيل ونقوم بتبديل الأجزاء المختلفة حسب الحاجة؟ سيكون هذا منطقيًا ، لكني أتخيل أنه من الصعب تنفيذه

لا أرى كيف يمكن مشاركة وقت التشغيل ، فالمستهلكون الرئيسيون هم Chromium و Node ، وهما متكاملان بإحكام وأشك في أنه يمكن جعلهما يعملان مع أكثر من إصدار واحد من بعضهما البعض.

أعتقد أن العقدة لديها شيء من هذا القبيل:

• أراد بعض المطورين أحدث إصدار من الإصدار 8 ، وكانوا على ما يرام لتحمل الكسر
• أرادت الشركات الكبرى الاستقرار والدعم طويل الأمد.

لست متأكدًا من أن فريق الإلكترون لديه موارد كافية لدعم كليهما ، لكن قد أكون مخطئًا.
على أي حال ، لا يتعارض هذا مع نطاقات تعيين الإصدار ، ما عليك سوى الإشارة إلى الإصدارات "LTS"

حسنًا ، إذا كان كل تطبيق إلكتروني يستخدم نفس وقت التشغيل ويشحن فقط مع حزمة .asar المصممة خصيصًا لوقت التشغيل هذا ، فستنجح الأمور ، أليس كذلك؟

نعم ، لكنك تريد إصدارًا أحدث من Chrome و Node من حين لآخر ، أليس كذلك؟

نعم ، لكن يمكنني العيش مع وجود نفس العقدة / الكروم لمدة 6 أشهر np. يحتوي Node على إصدار LTS على أي حال ولا يتغير الكروم كثيرًا عما لاحظته. Imo ، ميزة توفير 100 ميغابايت على كل تثبيت للتطبيق تعوض عن السرعة الصغيرة التي تعزز بين الحين والآخر إصدار جديد من Chromium / Electron. أيضًا ، بمجرد انضمام المطورين إلى اللوحة ، لا ينبغي أن يكون من الصعب جدًا تقليل الوقت بين الإصدارات الجديدة من وقت التشغيل. يمكننا بعد ذلك دعم أحدث إصدار من وقت التشغيل وإصدار واحد أو ربما اثنين أقدم.

لا ينبغي أن تكون إعادة إنشاء ملفات .node كل 6 أشهر صعبة للغاية كما أعتقد

سوف يدعم منشئ الإلكترون الخيار الجديد لجميع أهداف nsis - useSharedElectronRuntime. في الوقت الحالي ، ستكون جميع ملفات dll الحالية ، أعتقد أنه من الممكن تقليل حجم exe ونقل الكود إلى dll ، ولكن يمكن القيام بذلك لاحقًا ، حيث يعد توفير 30 ميغابايت بالفعل هدفًا جيدًا.

1. أنشئ تجميعًا موقّعًا لجميع إلكترون dll وانشره في إصدارات GitHub (bintray ليس خيارًا ، لأنه غير موثوق).
2. سيقوم برنامج التثبيت Nsis بتنزيل وتثبيت التجميع إذا لم يكن مثبتًا بعد. الأمان - تم التوقيع على التجميع. كما يدعم منشئ الإلكترون التثبيت لكل جهاز. ويوفر Windows مستوى إضافيًا من الأمان إذا تم تثبيت التجميع لكل جهاز ، لذلك ، إذا لزم الأمر ، يمكنك تمكينه. سيتم إضافة خيار Additionall لتثبيت التجميع لكل جهاز في أي حال. لم يتضح بعد - هل يجب أن يكون بشكل افتراضي صواب أم خطأ. أعتقد أنه خطأ ، للتأكد من أنه يمكن تثبيت تطبيق الإلكترون افتراضيًا بدون مشرف.
3. لا داعي للقلق بشأن وقت تشغيل الإلكترون غير المستخدم - يدعم dll المشترك العد المرجعي. عند إلغاء تثبيت التطبيق ، ستتم إزالة التجميع وسيقوم Windows بإزالته إذا لم تستخدمه تطبيقات أخرى.

CiriousJoker Re: الأمن. لم أكن أفكر في مشكلات الأمان لأن التطبيق نفسه ضار. كنت أفكر في التطبيقات الإلكترونية التي تمتص المحتوى غير الموثوق به وتستخدمها. على سبيل المثال ، في أي وقت يعرض تطبيق الإلكترون صفحة ويب من الويب المفتوح بـ webview أو ما شابه ذلك.

لا تعرض العديد من التطبيقات نفسها للويب المفتوح ، وسيكون من الجيد تشغيلها على إلكترون قديم. لكن الطرف الآخر هو شيء مثل Brave الذي لا يفعله كمتصفح ويب سوى الكشف عن نفسه. :-)

@ sedwards2009 أنتم ، ولكن إذا بدأنا في الاهتمام بالجميع وبأمهاتهم ، فلن نحرز أي تقدم. ستكون هناك دائمًا أسباب لعدم القيام بشيء ما. عدم الحصول على 100٪ من المطورين على متن الطائرة هو مجرد تضحية يجب أن نقدمها. إذا كانوا يحتاجون / يريدون الأمان حقًا ، فيمكنهم الحصول عليه يدويًا.

فيما يتعلق باختيار LTS ، فإن الخيار الأكثر منطقية imho هو ربط أنفسنا بـ Nodejs LTS ، أي أن أي إصدار من الإلكترون يتوافق مع العقدة LTS هو الإلكترون LTS بشكل فعال. يمكن أن يؤدي ذلك إلى بعض الانسجام والاتفاق حتى نتمكن من المضي قدمًا بشكل جماعي والحصول على بعض الضمانات بدلاً من تركها كخيار حر (مما ينفي هذا المجتمع) أو الجدال (الذي لا يقودنا إلى أي مكان).

CxRes لكن ما هو إصدار الإلكترون الذي ندعمه؟ في مشروعي ، كانت المشكلة الرئيسية هي إعادة إنشاء ملفات .node مقابل الإصدار المحدد من Electron (وليس Node).

يمكننا فقط تعيين أحدث إصدار من Electron باعتباره lts أو استخدام الإصدار الأكثر استخدامًا.

نسيت شيئا ما هنا؟ إيمو ، المشكلة هي الإلكترون ، وليس العقدة

حسنًا ، دعني أحاول شرح هذا مرة أخرى بمثال:

• Node LTS موجود حاليًا في 6.11.1
• ومن ثم فإننا نريد استخدام أعلى إصدار من الإلكترون تم إنشاؤه رسميًا بأعلى إصدار من العقدة التي تفي بالشرط <= 6.11.1> = 6.0.0
• أعلى إصدار من الإلكترون الذي تم إنشاؤه باستخدام Node 6 هو الإلكترون 1.4.15 والذي تم إنشاؤه باستخدام Node 6.5.0
• لذا فإن الإلكترون 1.4.15 هو المكان الذي نتفرع منه للإلكترون LTS ونعيد بنائه بـ 6.11.1 (وهكذا حتى يتم إصدار إصدارات Node v6 جديدة)

عندما ينتقل Node LTS إلى الإصدار 8 (LTS عبارة عن أرقام زوجية فقط) ، سننتقل معًا إلى إلكترون لم يتم إصداره بعد والذي سيتم بناؤه باستخدام Node v8 أو البقاء على مفترق LTS الحالي حتى يتم إصدار مثل هذا الإصدار الإلكتروني.

ماذا عن المطورين الذين يريدون الأحدث والأعظم؟

تضمين التغريدة لا توجد أي أسباب فنية تمنع استخدام إصدارات مختلفة من الإلكترون. سيكون التجزئة على أي حال (أصدر المطور التطبيق قبل عام واحد ونسي ، تم إصدار تطبيق آخر من مطور آخر مؤخرًا ويستخدم إصدارًا آخر).

YurySolovyov الفكرة الكاملة لـ LTS هي أنها ليست الأحدث والأكبر - إنها مستقرة. وإذا لم نتمكن من الاتفاق على التركيز على حل واحد - فنحن محكوم علينا أن نعاني من أمثلية باريتو الفرعية لعدم وجود أي وقت تشغيل لأنه لا توجد مجموعة واحدة لديها الوقت والقدرة على إعادة بناء كل إصدار وفحصها بحثًا عن الأخطاء.

انظر أيضًا تعليق CiriousJoker أعلاه:

أنتم ، ولكن إذا بدأنا في الاهتمام بالجميع وبأمهاتهم ، فلن نحرز أي تقدم.

تضمين التغريدة لكن كما أوضحت أن هذه ليست مشكلة فنية ، إنها مشكلة سياسية (التوصل إلى اتفاق على بناء يعمل مع معظم الناس باستمرار بحيث يتم تقاسم العبء).

اذا ماذا نفعل الان؟ هل نختار إصدار lts ونبدأ أو نحاول إيجاد حل لجعله يعمل للجميع من خلال محاولة إنشاء وقت تشغيل يناسب الجميع مع dlls معياري (كما يقترح develar إذا فهمت بشكل صحيح)

CiriousJoker تجميع جنبًا إلى جنب لإصدار إلكتروني معين. على سبيل المثال ، ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

develar لا يمكنني العثور على شيء التجميع الإلكتروني هذا على Google ، هل يمكنك توفير رابط أو شيء ما؟

Imo ، لتسريع الأمور ، يجب علينا فقط اختيار إصدار Electron عشوائي كإصدار lts والبدء. يمكننا تغيير الإصدار على أي حال في أي وقت لاحقًا.
develar ما زلت لا أعرف ما تعنيه بهذا التجميع جنبًا إلى جنب ، لكن يجب أن يعمل عبر النظام الأساسي وأتصور ، يمكننا تنفيذه لاحقًا أيضًا.

لقد كنا (أو في الواقع يا رفاق) نتحدث عن هذا لسنوات ، ولكن إذا لم يبدأ أحد ، فلن يتغير شيء وسنجلس هنا لمدة 3 سنوات أخرى نناقش الأفكار ونجد طرقًا لعدم البدء.

آمل أن يتمكن مطورو الإلكترون من حل فصل بيئة التشغيل والتطبيق في أقرب وقت ممكن ، مما سيعزز بشكل كبير تطبيقات الإلكترون ، وسأرى مستقبلًا مشرقًا.

لم يحلوها لما يبدو لي سنوات ، لذلك أنا متشائم حيال ذلك. بالتأكيد ، سيكون رائعًا ، لكن هل يعملون بنشاط على ذلك؟

CiriousJoker كما هو مذكور أعلاه ، أنا أعمل على دعم وقت تشغيل الإلكترون المشترك للنوافذ في منشئ الإلكترون. لقد قدمت https://github.com/electron-userland/electron-builder/issues/1942 لتتبع التقدم. آمل أن يكون جاهزًا للاستخدام في غضون شهر واحد.

develar بلدي السيئ ، يجب أن يكون قد أغفلته .. في هذه الحالة ، الحظ الجيد ، سيكون رائعًا إذا تمكنت من تحقيقه!

إذا كان أي شخص مهتمًا بإلغاء تكرار تقسيم المحتوى المحدد بالملف الفرعي المشار إليه سابقًا في السلسلة في https://github.com/electron/electron/issues/673#issuecomment -157980607 ، فقد قمت بفتحه: https: // github.com/ronomon/deduplication

ظل هذا الخيط الطويل نائمًا خلال الأشهر الماضية ، لكنني أعتقد أن المشكلة التي يعالجها لا تزال تستحق التحقيق. خلال عطلة نهاية الأسبوع ، قمت بعمل أداة مساعدة صغيرة من صفحة واحدة لإعادة تسمية الملفات بشكل جماعي. معبأ بمُنشئ الإلكترون ، ملف Mac. النهائي هو 121 ميجابايت ...

كنت أفكر في هذه المشكلة في الآونة الأخيرة. ثم ألقيت نظرة على هاتفي الذكي: يبلغ حجم تطبيق Facebook 600 ميغا بايت. يبلغ حجم Chrome 325 ميغا بايت ، بينما يبلغ حجم Mesenger 300 ميغا بايت ... لذا ، فإن التطبيق بحجم 120 ميغا بايت على سطح المكتب ، لا يهمني حقًا ...

الحجم ليس مشكلة اليوم. ذاكرة الوصول العشوائي واستهلاك الطاقة.

_تعديل: إذا كنت لا توافق ، فلا تتردد في مشاركة لماذا_

بالنسبة لمنصة Windows ، تبدو جهود develar مع منشئ الإلكترون (electron-userland / electron-builder # 1942) قريبة من تحقيق وقت التشغيل المشترك.

لاحظ أيضًا أن كتالوج الويب الخاص بالتطبيق ، الذي يحزم تطبيقات الويب كتطبيقات Electron المستقلة ، قد حل مشكلة استخدام وقت التشغيل المشترك لتقليل حجم التطبيق بشكل كبير: كتالوج الويب / كتالوج الويب / المشكلات / 171. تم إجراء ذلك في أداة التجميع الخاصة بهم ، عن طريق ربط الموارد المشتركة بين التطبيقات .

تعد تطبيقات الويب التقدمية (PWAs) حلاً جزئيًا لهذه المشكلة. على نظام Android ، يمكنك إضافة PWA إلى الشاشة الرئيسية وسوف يعمل مثل apk حقيقي. يعمل فريق Chrome الآن على تمكين تثبيت PWAs على سطح المكتب (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/) ، Microsoft يُظهر أيضًا اهتمامًا بدعم PWAs (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) وآمل أن يلحق Firefox و Safari بالمواكبة قريبًا. ستتم إضافة واجهات برمجة التطبيقات (API) المفقودة (مثل الوصول إلى نظام الملفات الأصلي) إذا أبدى المطورون اهتمامًا.
يمكن بسهولة تحويل معظم تطبيقات Electron المستندة إلى الويب إلى PWAs ، لكنني لست متأكدًا من تطبيقات مثل Atom و VSCode - ربما يلزم إعادة كتابة التعليمات البرمجية الأصلية في WebAssembly.

develar لديه أي تقدم حول هذه الفكرة؟

سأستخدمه عند إطلاق سراحه!

بعد أن صادفت هذا مؤخرًا ، أردت فقط أن أطرح رأيي. لم أقرأ القضية بأكملها رغم ذلك ، لذلك قد أكرر بعض الأشياء دون علمي.

أعتقد أن شيئًا كهذا مهم جدًا ، فعلى الرغم من أن حجم برنامج Electron قد لا يبدو بهذه الأهمية الآن ، فإنك تبدأ حقًا في رؤيته عند توزيع برنامج بسيط جدًا وصغير - على سبيل المثال ، آلة حاسبة مخصصة. في حالة حدوث ذلك ، سيكون شيء مثل 5-10 ميغا بايت معقولاً. 60 ميغا بايت أو أكثر سيكون أمرًا سخيفًا على الرغم من ذلك. بالنسبة لبرنامج أكبر ، يصبح حجم الإلكترون نفسه أكثر قابلية للتجاهل ، لكنه لا يزال مزعجًا.

الآن ، سيتطلب وضع وقت التشغيل هذا نوعًا من نظام إصدار LTS مع الأخذ في الاعتبار المعدل الحالي للإصدارات. يمكن بعد ذلك تشجيع المطورين على الاعتماد على إصدار LTS ، ويمكن أيضًا عرض قائمة بالإصدارات الأكثر استخدامًا في دليل التطبيقات ، مما يشجعهم على استخدام أكثرها شيوعًا ما لم تكن تفتقر إلى الميزة المطلوبة.

يجب أن يحتوي وضع وقت التشغيل نفسه ، IMO ، على نظام مدمج لتثبيت إصدارات أخرى من مكتبة Electron أيضًا ، بحيث إذا طلب المستخدم تثبيت تطبيق يتطلب إصدارًا مختلفًا ، يمكن لبرنامج وقت التشغيل تنزيله تلقائيًا على أنه أمر بسيط. خطوة في عملية التثبيت.

أعتقد أنه يجب الإشارة أيضًا إلى أنه يمكن أيضًا تحسين استخدام ذاكرة الوصول العشوائي لتطبيقات Electron بمساعدة هذا ، على الرغم من أن التغييرات المطلوبة لوضعها موضع التنفيذ ستكون أكثر أهمية. مع وقت التشغيل المشترك ، يمكن لتطبيقات Electron التي تستخدم نفس الإصدار مشاركة بعض الموارد داخل الذاكرة.

على أي حال ، أنا جديد جدًا على المصدر الكامل لمشروع Electron على أي حال ، لذا آسف إذا كان هناك أي شيء غير واضح ، أو إذا كررت شيئًا ما دون داع. آمل حقًا أن يتم تنفيذ هذا ، مع ذلك ، لأنه سيجعل من Electron بالفعل منصة واعدة أكثر لأنواع أكثر من البرامج. : +1:

octacian بدأت أعتقد أن PWAs هي خيار أفضل. ليس عالميًا ، على الرغم من أنه لا يمكنك فعل _ كل شيء_ باستخدام PWA - ولكن بالتأكيد بالنسبة لأشياء مثل الآلات الحاسبة المخصصة ، يجب أن تكون أكثر من كافية.

الآن علينا فقط انتظار ظهور دعم PWA على سطح المكتب .

أعتقد أيضًا أنه مع مثل هذا النظام ، 1- سيكون من الأسهل الشحن إلى أنظمة مدمجة / أصغر ، و 2- في المستقبل يمكن إنشاء قاعدة نظام تشغيل شبيه بالإلكترون للأجهزة المحمولة.

yasinaydin هناك بالفعل LG WebOS. (كان هناك نظام Firefox OS أيضًا ، ولكن تم إيقاف ذلك)

KeitIG ​​يا سيدي ، ستكون حجتك مناسبة تمامًا إذا كانت المشكلة الوحيدة مع Electron هي الحجم. إن امتلاك برنامج أكبر قليلاً ولكن تبسيط التعقيد وإمكانية الفشل للمطورين (لا يمكننا إنكار أن Electron يعد أمرًا رائعًا في منح المطورين طريقة موحدة لبناء التطبيقات دون مساحة كبيرة للفشل) سيكون أمرًا رائعًا. للأسف ، فإن استخدام إصدار منفصل من المكتبات لكل تطبيق يعني أيضًا زيادة استخدام ذاكرة الوصول العشوائي (RAM) ، ومشكلات أمنية موزعة (ويصعب إصلاحها). لقد أوضحت هذا بشكل أفضل في مشكلتي المكررة ، ولكن باختصار أعتقد حقًا أن مكتبة وقت التشغيل المشتركة يمكنك تحديثها بمفردها ومشاركتها بين تطبيقات Electron المختلفة (والتي سيتم شحنها في إصدار "خفيف" أيضًا ، نوعًا ما عندما اعتاد بعض المطورين على توزيع ملفات Java لاستخدامها على JVM والمجمعة .exe s) سيكون حقًا قاطع الصفقة بالنسبة إلى Electron ، وبينما أفهم أنه من المحتمل أن يكون قدرًا هائلاً من العمل ، فإنه يحزنني أنه ليس في خطط المطورين بعد. دعونا نأمل أن يفعلوا ذلك في المستقبل.

@ dre-hh بينما أقر بالنية الحسنة لاقتراحك ، إلا أنه مفرط في التقييد ، من بين أمور أخرى. على سبيل المثال ، لقد قمت بتطوير تطبيق إلكتروني تجاري لصاحب عملي ، ويتم استخدامه في بيئات شديدة التنظيم (لا يوجد اتصال بالإنترنت ، ومتطلبات لإمكانية التتبع / التدقيق ، وما إلى ذلك). لا يمكن لعملائنا السماح لنا بالقيام بأشياء مثل تحديث البرنامج تلقائيًا. إنه عالم مختلف تمامًا عن تطبيقات الويب النموذجية للجماهير. تعتبر المتصفحات دائمة الخضرة والتثبيت التلقائي لتحديثات أمان نظام التشغيل ، في رأيي ، فكرة رائعة لمعظم الناس في معظم الحالات ، لكن وجهة نظري هي أنها لا تناسب كل مكان. في بعض الأحيان ، يكون خطر الانقطاع الناجم عن تغيير البرامج أكبر بكثير من المخاطر المرتبطة بتشغيل إصدار قديم من البرنامج ، لا سيما في البيئات الخاضعة للرقابة حيث توجد تقنيات التخفيف الأمني ​​الأخرى. ومن ثم فإن اتخاذ إجراء متطرف مثل منع تنفيذ التطبيقات التي تستخدم إصدارات قديمة من الإلكترون (أو في الحقيقة ، أي مكتبة) ليس حلاً مثاليًا ، إذا كان حلاً على الإطلاق. (إلى جانب ذلك ، يمتلك المسؤولون بالفعل العديد من عناصر التحكم لتقييد البرامج التي يمكن تنفيذها ، حتى يتمكنوا من تنفيذ ذلك بدون أي ميزات نظام تشغيل جديدة.)

بالإضافة إلى ذلك ، كما هو الحال مع معظم المخاوف الأمنية ، ينبع الكثير من المشكلة من المطورين الذين إما غير مدركين للمخاطر أو اختاروا ، لأي سبب كان (مثل ضيق الوقت) ، عدم اتباع إرشادات الأمان للأدوات التي يستخدمونها. (على سبيل المثال ، الأمان والقدرات الأصلية ومسؤوليتك) نحن كمطورين نحتاج جميعًا إلى القيام بدورنا في تحمل المسؤولية عن الجودة (التي تشمل الأمان) لعملنا.

أخيرًا ، أعتقد أنه من الخطأ النظر إلى كيان برمجيات تجاري ، مثل Microsoft ، لمعالجة هذه المخاوف. هذا جزئيًا لأنه ، كما تمت الإشارة إليه للتو ، لا يمكننا توقع إنتاج تطبيقات آمنة عبر مطورين لا يهتمون بالأمن. الأهم من ذلك ، في رأيي على الأقل ، هو أن أحد الأشياء الجميلة في Electron هو طبيعتها مفتوحة المصدر ومتعددة المنصات ، والتي لا تمثل عادةً أولويات عالية لبائعي البرمجيات التجارية. من المرجح أن يتطلب التقدم الناجح والمدروس جيدًا مستوى معينًا من الإجماع والجهد من مجتمع المطورين بأكمله. بالطبع ، مساهمات الكيانات التجارية موضع تقدير.

jacobq في حالة عدم معرفتك ، فإن Microsoft هي المالكة لشركة Electron.

في حالة عدم معرفتك ، فإن Microsoft هي المالكة لشركة Electron.

@ Jop-V الرجاء إضافة اقتباس لهذا ؛ لا أعتقد أن هذا صحيح. الصفحة الأولى لموقع electronjs.com تقول:

Electron هو مشروع مفتوح المصدر تتم إدارته بواسطة GitHub ومجتمع نشط من المساهمين.

Microsoft هي مستهلك لـ Electron (يستخدمها في منتجات مثل Visual Studio Code) و (أفترض) أيضًا مساهم ، لكن ليس لديهم ملكية. لا يذكر ملف الترخيص Microsoft ولا تشير مقالة Wikipedia إلى أن لديهم موقع ملكية.

jacobq سوف تستحوذ Microsoft على GitHub ، لذلك إذا كان Electron تحتفظ به 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 لا يعني شيئًا بالنسبة إلى Electron. جيثب هي شركة منفصلة / ستظل كذلك ، مع منتجاتها ومشاريعها الخاصة. لا أرى ملكية Microsoft لشركة Electron ، بقدر ما لا أرى ملكية Microsoft لشركة Atom.

أعتقد أن هذا النقاش لا يساعد حقًا في النقطة الأولية للقضية.

https://github.com/GoogleChromeLabs/carlo

يبدو كارلو مثيرًا للفضول. لقد أخذته في جولة وهو أمر بديهي للغاية. هل جرب أي شخص مع pkg ing حتى الآن؟

لماذا لا يتم العمل على جميع المقترحات الخاصة بالحد من سخام محرك الأقراص الثابتة والذاكرة للمستخدمين النهائيين؟ هذه فكرة رائعة عمرها 4 سنوات وما زالت مجرد فكرة. لا أستطيع أن أفهم سبب عدم احتلال هذا النوع من الأشياء على رأس أولويات المشروع

@ danielo515 لأنه بدلاً من إنشاء مشروع كادح آخر ، هناك https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

عن ماذا تتحدث؟ هذا بالفعل مشروع ضخم. إنه أيضًا الأكثر انتشارًا واستخدامًا ، لذا فإن توجيه الأشخاص إلى مشروع مختلف لميزة يجب أن تكون جزءًا من هذا لا يبدو صحيحًا بالنسبة لي.
أيضًا ، كارلو هو نهج مختلف ، فهم يستخدمون Chrome المثبت لديك ، لذلك فهو ليس مثل إصدار خفي من Electron.

لا أستطيع أن أفهم سبب عدم احتلال هذا النوع من الأشياء على رأس أولويات المشروع

لأن تحويلها إلى حقيقة أمر صعب (مثل صعب "حقًا").

إذا لم تكن سعيدًا (وهذا أمر مفهوم تمامًا) ، فلا تتردد في تفرع Electron وإرسال PR.

لا تفهموني خطأ ، إذا كان هناك حل سهل لهذه المشكلة ، فأنا متأكد من أنه تم تنفيذه بالفعل.

@ danielo515

... توجيه الأشخاص إلى مشروع مختلف لميزة يجب أن تكون جزءًا من هذا لا يبدو صحيحًا بالنسبة لي.

أعتقد أن النقطة المهمة هي أن لكل مشروع نقاط قوته وضعفه ، وأن كارلو مناسب تمامًا للحالات ذات المساحة المحدودة. بالنسبة لحالات الاستخدام الخاصة بي ، فإن حجم التطبيق 100 ميغا بايت جيد تمامًا ، لذلك على الرغم من أنني أرغب في رؤية هذه الميزة ، إلا أن ميزات الإلكترون الأخرى أكثر أهمية بالنسبة لي.

jacobq نعم ، أنت على حق — تتطلب حالات الاستخدام المختلفة أدوات مختلفة.

إذا كان أي شخص آخر مهتمًا ، فقد قمت بإنشاء قائمة بالأدوات المماثلة لتطوير تطبيقات js على سطح المكتب.

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

أنا فقط لا أستخدم Electron لأنني لا أستطيع تحمل تكاليف تحديث العشرات من تطبيقات 100 ميجابايت - وأنت تعرف كيف تحتاج التطبيقات إلى التحديث (لدي آراء أخرى حول هذا الموضوع ولكن مشاركتها لن تساعد).
ما أحبه حقًا في نهج carlo هو فكرة استخدام المتصفح المثبت.
والأفضل من ذلك ، أنه من المؤكد أن كارلو يمكنه استخدام أي متصفح متاح ، وليس فقط الكروم ، حيث يمكن لمحرك الدمى إدارة المتصفحات الأخرى أيضًا. في OSX ، يمكنك نشر Safari أو على linux epiphany (webkitgtk) أو Firefox ، إلخ ...
لذلك حقًا للحصول على تطبيق ما عليك سوى تثبيت nodejs وتطبيقك.
الآن سيكون السؤال هو: ما مدى جودة pkg في استخدام libs المثبتة بالنظام والوظائف الإضافية الأصلية؟
على سبيل المثال ، إذا اضطررت إلى حزم التطبيق الذي أقوم بتطويره حاليًا ، فسأحتاج إلى postgresql و sharp (و vips) و webkitgtk و exiftool. أرغب في أن أكون قادرًا على توزيع التطبيق على مستخدمي لينكس ديبيان أو فيدورا أو أوبونتو فقط. أود التخلص من "الحزم المجنونة" والاستفادة بدلاً من ذلك من العمل الشاق الذي تقوم به تلك التوزيعات مجانًا.

kapouer ... استخدم المتصفح المثبت ...

على الرغم من أنها فكرة جيدة من الناحية النظرية ، إلا أنها تؤدي إلى زيادة صعوبة ترميز التطبيقات على جانب الويب نظرًا لأنه سيتعين عليك الآن التركيز على دعم المتصفحات المتعددة وقد تكون المتصفحات التي تعود إليها محدودة فيما ترغب في القيام به لأنها ليس لديك دعم كامل لأشياء مثل التي تجدها في Chromium. أنت تعتمد أيضًا على المستخدم للتأكد من أن متصفحه محدث وأن بائعي المستعرضات المتعددين لا يكسرون تطبيقك بالتحديث.

لقد تمكن العديد من المستخدمين من الحصول على تحديثات ضخمة تبلغ 50 ميجا بايت عن طريق التبديل إلى تحديثات دلتا أو جعل مديري الحزم يقومون فقط بتحديث ملف .asar أو مجلدات الموارد. وقم بإجراء تحديث كبير للإلكترون فقط عند الحاجة. هذا ما نقوم به في شركتنا وقد نجح بشكل رائع.

من منظور المستخدم الساذج ، فإن استخدام غلاف تطبيق Electron مثل وقت التشغيل المشترك سيجعل من السهل حقًا التوزيع والاستخدام. على سبيل المثال. مع 5 تطبيقات إلكترونية في نظام واحد ، لديك 5 مثيلات لقذيفة التطبيق وتبلغ حوالي 300 ميجابايت ، أليس كذلك؟

أعتقد بشدة أن الإلكترون هو مستقبل UX لسطح المكتب وستكون هذه خطوة كبيرة (انظر إلى .NET Runtime - قد تكون مقارنة سيئة ، ولكن ، أليس هذا رائعًا؟) لجعل تقنية الويب أكثر قوة.

لدى الإلكترون بالفعل وقت تشغيل للاستخدام في التطوير ، أليس كذلك؟ "الإلكترون". أمر يعني. لماذا لا تعيد استخدام ذلك من جانب المستخدم؟

للتعامل مع تطبيقات متعددة اعتمادًا على إصدار مختلف من Electron ، يمكنك استخدام النهج الذي يستخدمه .NET core. ما عليك سوى تثبيت إصدارات متعددة من وقت التشغيل جنبًا إلى جنب ، وجعل التطبيقات تعلن عن الحد الأدنى (أو الحد الأقصى) للإصدار الذي تتطلبه.

لقد صنعت مشغل إثبات المفهوم: https://github.com/ProPuke/electron-shared

ملف واحد قابل للتنفيذ ، حجمه أقل من 1 ميغا بايت. قم بتمريره إلى دليل التطبيق أو حزمة asar وسيقوم بفحص متطلبات إصدار الإلكترون في package.json devDependencies وتنزيل / تشغيل بالإصدار الصحيح.

يتم تخزين أوقات تشغيل الإلكترون في AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac) بحيث يمكن مشاركتها بين التطبيقات.

بدون تحديد المسار ، سيتم تشغيل الدليل app تلقائيًا أو app.asar إذا كان موجودًا ؛ لذا يمكنك توزيع تطبيقك باستخدام هذا الملف فقط و app.asar . أو يمكن أن يرتبط هذا بملفات .asar ويمكن توزيع ملفات asars فقط.

يحتوي أيضًا على عدد قليل من معلمات سطر الأوامر ، بما في ذلك --downloadOnly و --silent لذلك يمكن استدعاؤه من داخل المثبتات أثناء عملية الإعداد.

لا يتعامل مع التحديث التلقائي (يتم تنزيله فقط إذا لم يكن إصدار متوافق من Electron متاحًا بالفعل على جهازك) ، ولكن يمكن القيام بذلك بشكل دوري عند التشغيل ، أو من خلال خدمة في الخلفية (طالما يتم وضع أوقات التشغيل في المكان المناسب الذي سيجده ويستخدمه عند تشغيل التطبيقات).

قد تكون معرفة وقت حذف النسخ القديمة من أوقات التشغيل أمرًا صعبًا. قد تتراكم مع مرور الوقت. سنحتاج إما إلى تتبع التطبيقات المثبتة التي استخدمت الإصدارات (وبالتالي التي لم تعد ضرورية) أو ربما مجرد تخزين تاريخ آخر استخدام لكل إصدار من إصدارات وقت التشغيل وحذفها تلقائيًا إذا لم يتم استخدامها فى لحظة.

على أي حال ، إثبات المفهوم / الاقتراح. هل شيء كهذا يحل المشاكل؟ هل فاتني شيء صارخ وواضح؟

لقد جربت مشاركة الإلكترون الخاصة بـProPuke وتمكنت من تشغيل عرض إلكترون سريع البدء . لكنني لم أتمكن من تشغيل أي من التطبيقات الموضحة في موقع electronjs (لأن معظم التطبيقات تستخدم بعض البرامج النصية من shell لبدء تشغيل التطبيق وليس فقط package.json ، كما أفهم). لكنني أعتقد أن هذا _ إثبات المفهوم / الاقتراح_ يمكن أن يكون مؤشرًا على الترقية الكبيرة التالية.

لدي فكرة. لأن الإلكترون يدعم حاليًا الأمر "مسار electron.exe". أعتقد أنه يمكنك فتحه عن طريق استدعاء عدة asars من سطر الأوامر. في الوقت الحالي ، أنا مجرد فكرة. أتمنى أن يتمكن أحد من القيام بذلك ، لأنني تطرقت للتو إلى هذا البرنامج.
_____________ نسخة الترجمة الصينية ___________
لدي فكرة. لأن الإلكترون حاليًا يدعم الأمر "مسار electron.exe". أعتقد أنه يمكن فتحه باستخدام سطر الأوامر لاستدعاء asars متعددة. أنا مجرد فكرة في الوقت الحالي ، وآمل أن يتمكن أحدهم من إلقاء نظرة عليها ، لأنني شاركت للتو في هذا البرنامج.

بعد إلقاء نظرة خاطفة على المحادثة بأكملها (ومناقشات أخرى مثل "تطبيقات" متعددة) ، سألخص - استدعاء عدة asars محليًا بدلاً من البدء بثنائيات متعددة له تاريخ طويل ، ولكنه غير مدعوم. ولكن يتم تنفيذ التطبيق الافتراضي للإلكترون باستخدام سطر الأوامر (ربما لا أعرف في الوقت الحالي). أعتقد أن استدعاء cmd من خلال الإلكترون (يبدو أنه ممكن) يجب أن يكون قادرًا على تحقيق توافق الوظيفة.
بإلقاء نظرة خاطفة على جميع المحادثات (والمناقشات الأخرى ، مثل "تطبيقات" متعددة) ، أستنتج أن المكالمات الأصلية إلى Asar المتعددة بدلاً من عدة ثنائيات تبدأ ، والتي لها تاريخ طويل ، ولكنها غير مدعومة. لكن تطبيق Electron الافتراضي هو تطبيق يستفيد من سطر الأوامر (وربما لا أعرف لفترة من الوقت) .أريد استدعاء cmd عبر الإلكترون (كما لو كنت أستطيع) يجب أن يكون قادرًا على تحقيق شريط توافق الميزة هذا.

في أسوأ السيناريوهات ، سيكون عليك إنشاء ملف .bat أو ما يعادله لأنظمة تشغيل بخلاف Windows ، وتشغيله من Electron.

ربما روابط مفيدة:

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

يبدو أنه فقط في حالة عدم وجود app.asar أو مجلد التطبيق ، يكون الأمر إلكترونيًا. مسار exe صالح

أوه ، لذلك أنت بحاجة إلى إلكترون لتشغيل مسار exe داخل الإلكترون المستخدم لإعداد كل ذلك. لا يزال أفضل من التثبيت الإلكتروني لكل تطبيق مستخدم. ستحتاج فقط إلى تثبيت إلكترون واحد لكل إصدار من الإلكترون يحتاجه تطبيقك. ربما تحتاج إلى إنشاء ملحق منفصل وهو أرشيف مضغوط تمت إعادة تسميته والذي يحتوي على كل من التطبيق الذي نحاول تشغيله وملف بالإصدار الموصى به (سيتم تشغيله على الفور) ، والإصدارات المتوافقة (قد تسأل عما إذا كان سيتم تشغيله أو قم بتثبيت الإصدار الموصى به ، وقم أيضًا بتنزيل إصدار Electron الموصى به في الخلفية) ، أو قد يعرض شريط تقدم التنزيل فقط ، لتنزيل الإصدار الموصى به.

أو أنني أسأت فهم شيء ما.

ربما تكون هذه الفكرة هي نفسها: نظرًا لأنه من السهل حاليًا قول الخفافيش ، خذها على سبيل المثال ، المحتوى هو electron.exe app1.asar ، بعد التنفيذ ، يفتح الإلكترون محتوى app1.asar. ربما تكون هذه هي الطريقة التي تعمل بها ، ولكن عندما تكتب الجملة التالية ، electron.exe app2.asar ، في bat ، لا يمكنك فعل ذلك إلا عندما ينتهي إلكترون app1.asar. وعندما يتم إيقاف تشغيل الخفاش ، يتم إيقاف تشغيل الإلكترون. لكني أكتب app3.asar من electron.exe | electron.exe-v أو app3.asar | إلكترون | ابدأ ، وهكذا. عندما أغلق الخفاش ، يمكن للإلكترون البقاء ، لكن لا يمكنني الاستمرار في فتح asars أخرى. أعتقد أن هذا البرنامج المستقل قد يكون أفضل من هذا البرنامج ، لأن الخفافيش لا تزال محدودة إلى حد ما.

ليس إذا كنت تستخدم المجلدات المؤقتة.

لديك الإصدارات (المؤرشفة أو غير المؤرشفة) في مجلد electron_versions ، والذي تستخدم منه إما الإصدار الموصى به أو أحدث إصدار متوافق قمت بتنزيله عن طريق نسخ الإصدار الذي تستخدمه إلى مجلد مؤقت ، وبعد الانتهاء منه ، احذف المجلد.

سيكون مسار الملفات المحفوظة محليًا إما في مجلد الإلكترون أو بجوار الملف الذي تستخدمه. إذا كنت تستخدمه من أرشيف يحتوي على الأشياء التي ذكرتها خلال آخر 24 ساعة ، فسيتعين عليك إعادة ملفات البيانات المحفوظة إلى الأرشيف ، أو عدم نقلها على الإطلاق قبل حذف مجلد مثيل الإلكترون المؤقت.

SSD？

؟؟؟

يعود سبب حذف مجلد الإلكترون المؤقت إلى أن التطبيق يمكنه نظريًا تغيير ملفات تثبيت الإلكترون الذي يعمل عليه ، وبحسب التصميم. أعني ، يمكن للأرشيف أن يحتوي على الملفات والمجلدات التي تحتاج إلى الكتابة أو الكتابة فوقها داخل تركيب الإلكترون المؤقت.

لذلك بعد استخدام التثبيت ، يمكن التعامل معه على أنه تالف من خلال التطبيق الذي تم تشغيله ، لذلك لا يمكن إعادة تدويره ، وبالتالي يجب حذفه. ومع ذلك ، فإن الإصدار الذي استخدم منه التثبيت التالف كقاعدة لا يزال سليماً ، في مجلد electron_versions لتطبيق وقت التشغيل الإلكتروني الذي نحاول صنعه.

في الواقع ، إذا كان الأرشيف بامتداد مميز ، والذي ذكرته من قبل ، للقراءة فقط ، فيمكن من الناحية النظرية نقل البيانات التي يستخدمها إلى٪ appdata٪. لذا فإن التطبيق الذي يتم تشغيله داخل وضع وقت التشغيل الإلكتروني الذي نحاول صنعه سيكون في الواقع محمولًا (قائم بذاته) ، وبالتالي فإن نسخ هذا الملف سيكون كافيًا لأخذ تكوين هذا التطبيق معك.

ولكن ربما نحتاج أيضًا إلى إضافة وظيفة تحديث لهذا النوع من الملفات ، والتي ستكون بمثابة تثبيت إلكتروني آخر يقوم بنسخ الملفات من ملف التثبيت الجديد والكتابة فوقها إلى نسخة من ملف التثبيت القديم ، وإرجاع ملف التثبيت الجديد بالملف البيانات التي كان لديها. يمكن القيام بكل شيء تلقائيًا ، إذا كان هناك رابط تنزيل في الملفات التي يستخدمها وقت التشغيل-الوضع-الإلكترون الذي نحاول صنعه.

بمجرد أن يصبح ذلك جاهزًا ، إذا كنت ترغب في بذل جهد إضافي ، يمكنك حتى إضافة عميل git لتحديث التطبيقات منه ، على الرغم من أن ذلك قد يتطلب استخدام github و bitbucket لاستضافة ملفات الأرشيفات المجمعة.

يمكنك استخدام ملف تنزيل "curl، wget، aria2c" ، ولا يمكن للمستخدم أن يحتاج إلى تثبيت git ， أوه ， تحتاج إلى استخدام "gzip، 7z" unpack zip。

أنا أصنع أداة electron-runtime والتي تعمل بشكل مشابه لـ electron-builder . إنه يجمع فقط الملف app.asar مع برنامج نصي بسيط sh (لاحقًا ستكون هذه واجهة مستخدم لإظهار تقدم تنزيل الإلكترون). يعمل حاليًا فقط مع macOS.

عند تشغيل تطبيق مُعبأ بـ electron-runtime يقوم بتنزيل إصدار رئيسي مطابق من Electron ، ولكنه الأحدث في حالة الإصدار الثانوي والتصحيح ، نظرًا لأن التغييرات الفاصلة للإلكترون تحدث فقط بزيادات كبيرة في الإصدار.

يبلغ حجم التطبيق electron-quick-start 62 كيلوبايت فقط ، لقطة الشاشة:

إذا كنت مهتمًا بها ، فاترك نجمًا أو علاقات عامة أو مشكلة.

لقد قمت بتحديث الحزمة قليلاً ، بحيث يمكن إنشاؤها باستخدام electron-builder ( فيما يلي وصف لكيفية عملها ). حتى الآن يمكنك بناء حتى Visual Studio Code معها! (ولكن لا يزال على نظام macOS فقط).

لقد أصدرت بنجاح الإصدار الأول من electron-global ! (لقد غيرتها ، حيث تم أخذ electron-runtime ). يمكنك إنشاء تطبيقك باستخدام حزمة npm الخاصة بي مع electron-builder . لقد أضفت أيضًا واجهة مستخدم مع شريط تقدم لإظهار تقدم تنزيل Electron. آمل أن يصبح جعل إلكترون أفضل.

أنا آسف ، أنا أستخدم نظام Windows ، وليس لدي المال لاستخدام MacOS ، لكنني أعتقد أن مشروعك سيكون ناجحًا للغاية.

nwdxlgzs يدعم أنظمة تشغيل Windows و macOS و Linux ...

اعتقدت أن هذا المشروع يدعم فقط شركة المطوع والقاضي.
سأستغرق بعض الوقت لتجربة هذا المشروع الرائع.

نشكرك على صنعه وإبقائنا على اطلاع دائم!
أنا أستخدم Windows أيضًا.
سوف ألقي نظرة على الكود عندما أحصل على التغيير.

حسنًا ، ماذا عن دمج electron-global upstream وجعله الافتراضي الجديد 😏