Toolbox: تكامل ملفات سطح المكتب

تم إنشاؤها على ٢١ أبريل ٢٠٢٠  ·  18تعليقات  ·  مصدر: containers/toolbox

إذا قمت بتثبيت تطبيق GUI (على سبيل المثال VS Code و GNOME Builder وما إلى ذلك) ، فسيتم إنشاء ملف سطح المكتب في / usr / share / applications. لكن صندوق الأدوات يحتوي على نظام معزول (باستثناء homedir) ولن يتم ربطه.
إذا كان هناك خيار لإنشاء ملف سطح المكتب منه مثل:
$ toolbox desktop code.desktop سيفعل:

  1. انسخ /usr/share/applications/code.desktop إلى .local / share / applications / toolbox_code.desktop
  2. قم بتغيير جميع المراجع القابلة للتنفيذ (/ usr / bin / code أو code) إلى conainers (/ usr / bin / code -> toolbox run / usr / bin / code et cetera)
  3. رمز النسخ إلى تخزين الرموز المحلي

أضف أيضًا خيارًا للإزالة:
$ toolbox desktop code.desktop -r
لإزالة ~ / .local / share / applications / toolbox_code.desktop والرمز

1. Feature request 5. Good First Issue 5. Help Wanted

التعليق الأكثر فائدة

أنا ذاهب لذلك!

ال 18 كومينتر

مرحبًا @ oksoft-git! هذا يبدو مثيرا للاهتمام. كنت أفكر في تقديم شيء مشابه لهذا. هل تريد إجراء علاقات عامة مع هذه الميزة (ولكن ليس في Shell ولكن في Go للإصدار الجديد من Toolbox ؟

debarshiray ، ما رأيك؟

أنا ذاهب لذلك!

ستفيد هذه الميزة بشكل كبير مستخدمي silverblue لأنه يمكنك بسهولة استخدام التطبيقات من الحاوية

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

كأغلفة أوامر ، أعني غلافًا مثل هذا لـ nano على سبيل المثال (قد يكون أكثر تعقيدًا من هذا بالنسبة لبعض البرامج)

!/bin/bash
toolbox nano "$@"

(تقوم flatpak بعمل شيء من هذا القبيل ، ويمكن أن تبحث فيه أكثر)

مرحبا sandorex ! الميزة التي تتحدث عنها يتم تتبعها بالفعل هنا: # 145. إنها إحدى الأولويات بعد طرح Toolbox المحدّث. في حين أن هاتين الميزتين متشابهتان ، فإن الحل لهما مختلف تمامًا.

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

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

إذا كنت مخطئًا بشأن التعقيد ، فعندئذ ، من فضلك ، أثبت أنني مخطئ.

قد أكون مخطئًا ولكن يتم البحث في ملفات سطح المكتب بشكل متكرر في ~/.local/share/applications لذلك الدليل الذي يحتوي فقط على ملفات سطح المكتب من مربع الأدوات (لكل حاوية) ثم قم فقط بإزالة ملفات سطح المكتب غير الموجودة في الحاوية ولكن التعديل لا يمكنني فعلاً تبسيط

تتمثل الطريقة الثانية في إعطاء هذه المسؤولية إلى تطبيق آخر ( toolbox-desktop-integration ) مما يسمح باختيار ملفات سطح المكتب لإحضارها إلى المضيف (سيكون وضعها في مجلداتها أمرًا ذكيًا ، مثل ~/.local/share/applications/_toolbox_XXX حيث XXX هو اسم الحاوية)

مهتم برأيك HarryMichal

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

_ تحرير_: سيكون إنشاء أداة مخصصة لذلك أفضل. سأعيد إنشائه.

حسنًا ، لدي. github.com/ondra05/toolbox-desktop

@ ondra05 عمل عظيم!

هناك شيء واحد كنت سأقوم بتحسينه شخصيًا (رغم أنه ليس ضروريًا) وهو استخدام cat لقراءة الملف من الحاوية ، سيعمل بشكل جيد ولكن الاختراق نوعًا ما يتسبب في مشاركة الصور podman باستخدام toolbox يمكنك استخدام podman cp لنسخ الملفات بين الحاوية والمضيف

كنت أتلاعب بهذه الفكرة في نص بيثون هذا . يقوم حاليًا بتثبيت ملفات سطح المكتب والرموز و mime و metainfo. لا يزال يتعين علي إضافة ميزة إلغاء التثبيت ، ولكن لا يبدو الأمر صعبًا للغاية.

للأسف ، ليس لدي الوقت الكافي لعمل تطبيق مناسب ، لقد صنعت واجهة المستخدم ولكن GTK مجرد ألم في المؤخرة ، ربما سأفعل تطبيق CLI فقط يومًا ما (آمل)

للأسف ليس لدي الوقت الكافي لعمل تطبيق مناسب

أعتقد أن واجهة المستخدم الرسومية لهذا مبالغة. يجب التعامل مع هذا مع أوامر في اتجاه toolbox export مع الأعلام مثل --remove و --list .

سأحاول النظر في الأمر. أتساءل عما إذا كان من الممكن إضافة أمر toolbox export APP يستدعي ، على سبيل المثال ، نص Python هذا داخل صندوق الأدوات بطريقة مشابهة لـ toolbox run export.py ARGS . على الرغم من أنه من الأفضل القيام بذلك أثناء التنقل ، إلا أن هذا يتضمن فقط نسخ الملفات من مربع الأدوات /usr إلى $XDG_DATA_DIR وقد يكون من الأسهل استخدام برنامج نصي له. لا أعرف ما المشرف على هذا الاحتمال.

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

هذا مشابه للمناقشة حول إضافة أمر التشغيل ، بما في ذلك محادثة IRC هذه من #silverblue على Freenode:

From #silverblue on Freenode:

15:56 <rishi> otaylor: alexlarsson: Hey! Do you have any thoughts on            
      https://github.com/debarshiray/toolbox/pull/76 ?
15:57 <rishi> In short, people want to be able to do "toolbox run emacs".
15:57 <rishi> And I am worried about encroaching on Flatpak territory.
15:58 <alexlarsson> I don't think its a huge problem.
15:58 <otaylor> rishi: I suspect we need such functionality if we want the      
      toolbox to be a serious tool that people rely on
15:58 <alexlarsson> No 2 tools will be 100% non-overlapping
15:59 <alexlarsson> and i can imagine using this in non-flatpak like way
15:59 <alexlarsson> toolbox run some-service
15:59 <otaylor> rishi: I'd be more worried about adding, say, menu item         
      management so that it looks like 'toolbox run emacs' is a real app
16:00 <alexlarsson> I mean, some people use flatpak for cli stuff
16:00 <rishi> otaylor: alexlarsson: Okay!
16:00 <alexlarsson> which is not quite the point
16:00 <alexlarsson> Still, it works
16:01 <alexlarsson> The main thing is that the design decisions that drive      
      toolbox and flatpak are driven by a particular usecase
16:01 <alexlarsson> Not that they can't be used other ways
16:03 <rishi> Yeah, toolbox is very clearly: "use jhbuild on Silverblue".
16:04 <rishi> walters would say "separate development prefix", but that's       
      about it, I think.

من الممكن بالفعل إضافة toolbox run emacs في ملف .desktop للتطبيق المثبت داخل الحاوية. إن وجود أمر يقوم بتحليل وإنشاء ملفات .desktop هو خطوة أخرى في نفس الاتجاه ، ولست متأكدًا مما إذا كان بعيدًا جدًا.

debarshiray ما رأيك في برنامج نصي بيثون ينسخ ملفات سطح المكتب و icondata والبيانات الوصفية؟ لقد صنعت بالفعل واحدة وهي تعمل بشكل جيد.

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

أنا مهتم بالعمل على هذه القضية!

...
لا يستخدم الجميع شل جنوم
...
إذا كنت مخطئًا بشأن التعقيد ، فعندئذ ، من فضلك ، أثبت أنني مخطئ.

HarryMichal أعتقد أن مخاوفك غير ضرورية.
في الوقت الحاضر ، تم تصميم ملفات سطح المكتب وموضوعات ملفات الرموز لتكون محايدة لسطح المكتب وتخضع لمواصفات XDG :
https://specifications.freedesktop.org/
https://specifications.freedesktop.org/desktop-entry-spec/latest/index.html
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

للجميع:
هل يمكننا تصميم الوظائف المطلوبة مثل DNF plugin ربما؟

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

لا يزال يتعين علي إضافة ميزة إلغاء التثبيت ، ولكن لا يبدو الأمر صعبًا للغاية.

شكرا @ A6GibKm ، من فضلك! :)

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات