مرحبا يا هبر!
بالنسبة لي ، هذه العبارة أشبه بعالم الترحيب ، حيث وصلت أخيرًا إلى أول منشور لي. لقد أجلت هذه اللحظة الرائعة لفترة طويلة ، حيث لم يكن هناك شيء لأكتب عنه ، لكنني أيضًا لا أريد أن أمتص ما تم امتصاصه بالفعل في كومة من المرات. بشكل عام ، في أول مطبعي ، أردت شيئًا أصليًا ومفيدًا للآخرين ويحتوي على نوع من التحدي وحل المشكلات. والآن يمكنني مشاركة هذا. الآن ، أول الأشياء أولاً.
دخول
بدأ كل شيء مع حقيقة أنني منذ فترة طويلة تدحرجت نفسي Linux Mint على جهاز كمبيوتر يعمل. ربما يعلم الكثيرون أن Pidgin مع المكون الإضافي Sipe هو بديل مناسب تمامًا لـ Microsoft Lync (يُسمى الآن Skype for business) لأنظمة Linux. نظرًا لخصائص العمل ، غالبًا ما يتعين علي المشاركة في مؤتمرات sip ، وعندما كان الخباز موجودًا ، كان مدخل المؤتمر أساسيًا: لقد تلقينا دعوة عبر البريد ، وانقر فوق رابط تسجيل الدخول ، ونحن جاهزون بالداخل.
عند التبديل إلى
الجانب المظلم من نظام Linux ، أصبحت الأمور معقدة بعض الشيء: يوجد ، بالطبع ، إدخال Pidgin إلى المؤتمر ، ولكن لهذا عليك تحديد خيار الانضمام إلى المؤتمر من القائمة في خصائص حساب sip وإدراج رابط إلى المؤتمر في النافذة التي تفتح أو تدخل اسم المنظم ومعرف أسيوط. وبعد فترة من الوقت بدأت أفكر: "هل من الممكن تبسيط هذا بطريقة أو بأخرى؟" نعم ، أنت تقول ، لماذا تحتاج إلى الجحيم ، ستجلس على Windows ولن تهب الشارب.
الخطوة 1. البحث
قال نيكراسوف في عمله "من يستطيع أن يعيش بشكل جيد في روسيا" "يا له من نزوة - إنها ستتجه إلى الأمام - فلن تغلب عليها."
لذلك ، منذ أن وصل الفكر إلى الرأس ، بعد بعض الوقت نشأت الفكرة الأولى للتنفيذ. بدا كل شيء بسيطًا - تحتاج إلى اعتراض الدعوة إلى الارتباط بـ
meet.company.com/user/confid - وضع العملية المحلية لتطبيق الويب على 127.0.0.1 على عربة اليد وأدخل الإدخال الثابت لمجال الشركة الذي من خلاله / etc / hosts في مؤتمر يشير إلى مضيف محلي. علاوة على ذلك ، يجب أن يعالج خادم الويب هذا الرابط الذي وصل إليه وأن ينقله بطريقة أو بأخرى إلى Pidgin (سأقول على الفور أنه لم يكن لدي أي فكرة في هذه المرحلة عن كيفية إعطائه إياه على الإطلاق). الحل ، بالطبع ، تنبعث منه رائحة العكازات ، لكننا مبرمجون ، لا تخيفنا العكازات (صرير).
بعد ذلك ، عن طريق الصدفة ، فتحتُ رابطًا لدعوة إلى Google Chrome (وعادةً ما أستخدم دائمًا Mozilla Firefox). وللمفاجأة ، بدت صفحة الويب مختلفة تمامًا - لم يكن هناك نموذج لإدخال بيانات المستخدم ، وبعد طلب الصفحة مباشرةً ، كان هناك طلب لفتح شيء ما عبر
xdg-open . من أجل المتعة ، انقر فوق "نعم" وظهور رسالة خطأ - الرابط lync15: confjoin؟ لا يمكن فتح عنوان url = https: //meet.company.com/user/confid. هم. أي نوع من xdg-open هو هذا وماذا يحتاج من أجل فتح مثل هذه الروابط؟ أوضح
تشريح الجثة الذي قرأ الوثائق أن هذا هو أداة معالجة رسومية تساعد على تشغيل التطبيقات المرتبطة مع بروتوكولات نظام uri أو أنواع معينة من الملفات. يتم تكوين الجمعيات من خلال تعيين نوع mime. لذلك ، نرى أننا نبدأ البحث عن تطبيق معين لنظام uri باسم
lync15 ويتم تمرير الرابط إلى xdg-open ، والذي من الناحية النظرية يجب أن
ينقله إلى بعض التطبيقات المسؤولة عن هذا النوع من الروابط. الذي نحن ، بالطبع ، ليس لدينا في النظام. وإذا لم يكن الأمر كذلك ، كيف يفعلون في عالم مفتوح المصدر؟ هذا صحيح ، وسوف نكتب ذلك بأنفسنا.
مزيد من الانغماس في عالم Linux وخاصة في دراسة كيفية عمل shell الرسومية (بيئة سطح المكتب ، DE) ، بالمناسبة لدي Xfce في Linux Mint ، أظهر أن التطبيقات ونوع mime المرتبط به عادة ما يتم كتابتهما مباشرة في ملفات مختصرة مع الملحق .desktop. حسنًا ، لماذا لا ، أقوم بإنشاء اختصار بسيط للتطبيق ، والذي ينبغي ببساطة تشغيل البرنامج النصي bash وإخراج الوسيطة التي تم تمريرها إليه إلى وحدة التحكم ، وسأقدم فقط ملف الاختصار نفسه:
[Desktop Entry] Name=Lync Exec=/usr/local/bin/lync.sh %u Type=Application Terminal=false Categories=Network;InstantMessaging; MimeType=x-scheme-handler/lync15;
أقوم بتشغيل xdg-open من وحدة التحكم بنفس الرابط الذي يأتي من المتصفح و ... المشكله. مرة أخرى يقول إنه لا يستطيع معالجة الرابط.
كما اتضح فيما بعد ، لم أقوم بتحديث دليل نوع mime المرتبط مع تطبيقي. يتم ذلك باستخدام أمر بسيط:
xdg-mime default lync.desktop x-scheme-handler/lync15
الذي ببساطة تحرير ملف
~ / .config / mimeapps.list .
محاولة رقم 2 مع xdg-open call - وفشل مرة أخرى. لا شيء ، فالصعوبات لا تخيفنا ، بل تثير الاهتمام فقط. ومسلحين بكل قوة باش (أي البحث عن المفقودين) ، ونحن نغوص في تصحيح الأخطاء. من المهم أن نلاحظ هنا أن xdg-open مجرد برنامج نصي.
bash -x xdg-open $url
عند تحليل المخرجات بعد التتبع ، يصبح من الواضح قليلاً أنه يتم نقل المزيد من التحكم إلى
الفتح الخارجي . وهذا ملف ثنائي بالفعل وفهم سبب إرجاع رمز إرجاع غير ناجح عند تمرير رابط إليه في وسيطة أصعب بالفعل.
بعد تشغيله عبر الأجزاء الداخلية من xdg-open ، اكتشفت أنه يحلل مختلف المعلمات البيئية ويمرر التحكم إلى بعض الأدوات لفتح الملفات / الروابط الخاصة بـ DE معين ، أو أنه يحتوي على نسخة احتياطية في شكل وظيفة
open_generic open_xfce() { if exo-open --help 2>/dev/null 1>&2; then exo-open "$1" elif gio help open 2>/dev/null 1>&2; then gio open "$1" elif gvfs-open --help 2>/dev/null 1>&2; then gvfs-open "$1" else open_generic "$1" fi if [ $? -eq 0 ]; then exit_success else exit_failure_operation_failed fi }
لقد قطعت بسرعة
اختراقًا صغيرًا هنا مع تحليل الوسيطة التي تم اجتيازها ، وإذا كان هناك سلسلة فرعية محددة
موجودة لدينا ، فنحن نمرر التحكم على الفور إلى وظيفة
open_generic .
جرب الرقم 3 وتعتقد أنها عملت؟ نعم ، الآن كيف. لكن رسالة الخطأ قد تغيرت بالفعل ، وهذا تقدم بالفعل - الآن أخبرني أنه لم يتم العثور على الملف وفي شكل ملف ، كتب لي الرابط الذي تم تمريره كحجة.
هذه المرة ، تبين أنها الوظيفة
is_file_url_or_path ، التي تحلل الرابط إلى ملف الملف: // أو المسار إلى الملف أو أي شيء آخر. ولم يعمل التحقق بشكل صحيح بسبب حقيقة أن البادئة (مخطط عنوان url) لدينا بها أرقام ، ويتم التحقق من التعبير العادي فقط لمجموعة أحرف تتكون من: alpha: period and dashes. بعد الرجوع إلى معيار rfc3986 لمعرف
مورد موحد ، أصبح من الواضح أن Microsoft هذه المرة لم تنتهك أي شيء (على الرغم من أنني حصلت على مثل هذا الإصدار). مجرد فئة حرف: alpha: يحتوي فقط على أحرف الأبجدية اللاتينية. أنا بسرعة تغيير الاختيار منتظم إلى أبجدية رقمية. تم ، أنت مبهج ، كل شيء يبدأ أخيرًا ، التحكم بعد إعطاء جميع الشيكات إلى تطبيق البرنامج النصي لدينا ، يتم عرض رابطنا على وحدة التحكم ، كل شيء كما يجب. بعد ذلك ، بدأت أشك في أن جميع مشكلات exo-open ترجع أيضًا إلى التحقق من صحة تنسيق الارتباط بسبب الأرقام الموجودة في الرسم التخطيطي. لاختبار الفرضية ، أقوم بتغيير تسجيل نوع mime للتطبيق إلى نظام
lync وفويلا فقط - كل شيء يعمل دون إعادة تحديد وظيفة open_xfce. لكن هذا لن يساعدنا بأي شكل من الأشكال ، لأن صفحة الويب الخاصة بدخول المؤتمر تنشئ الرابط مع lync15 بالضبط.
لذلك ، تم الانتهاء من الجزء الأول من المسار. يمكننا اعتراض مكالمة الارتباط وبعد ذلك نحتاج إلى معالجتها بطريقة ما وتمريرها داخل Pidgin. من أجل فهم كيفية عملها داخليًا عند إدخال البيانات عبر رابط في قائمة "الانضمام إلى المؤتمر" ، قمت باستنساخ مستودع Sipe للمشروع وأعدت الغوص في الكود مرة أخرى. لكن هنا ، لحسن الحظ ، انجذبت إلى البرامج النصية في
المساهم / dbus / directory:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
اتضح أن المكون الإضافي Sipe متاح للتفاعل عبر dbus (ناقل سطح المكتب) وداخل البرامج النصية هناك أمثلة مباشرة للانضمام إلى المؤتمر بالرجوع إليه ، إما من خلال اسم الجهة المنظمة ومعرّفها ، أو يمكنك بدء مكالمة من خلال sip. هذا هو بالضبط ما نفتقر إليه.
الخطوة 2. تطبيق معالج للانضمام التلقائي
نظرًا لوجود أمثلة جاهزة للؤلؤة ، قررت فقط استخدام
sipe-oin-conference-with-uri.pl وتعديله قليلاً لنفسي. يمكنني الكتابة باللؤلؤ ، لذلك لم يسبب ذلك أي صعوبات معينة.
بعد اختبار البرنامج النصي بشكل منفصل ، أدخلت مكالمته في ملف
lync.desktop . وكان انتصارا! عند الدخول إلى صفحة الانضمام إلى المؤتمر والسماح بإطلاق xdg-open ، يتم فتح النافذة المنبثقة للمؤتمر من Pidgin تلقائيًا. كيف فرحت.
بتشجيع من النجاح ، قررت أن أفعل نفس الشيء لمتصفحي الرئيسي ، Mozilla Firefox. عند الدخول عبر الثعلب ، يتم فتح صفحة للترخيص وفي أسفل الصفحة يوجد زر
ربط باستخدام برنامج Office Communicator . كما جذبت انتباهي. عند النقر فوقها في المستعرض ، ينتقل الرابط إلى:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
الذي أخبرني أنه لا يعرف كيفية فتحه ، وربما ليس لدي تطبيق مرتبط بمثل هذا البروتوكول. حسنا لقد مرت علينا بالفعل.
بسرعة تسجيل تطبيق البرنامج النصي الخاص بي أيضا لالاتحاد مخطط uri و ... لا يحدث شيء. يستمر المتصفح في الشكوى من عدم وجود تطبيق يعالج الروابط. في الوقت نفسه ، تعمل مكالمة من وحدة التحكم المفتوحة xdg مع المعلمات بشكل جيد.
"تعيين معالج بروتوكول مخصص في فايرفوكس" - مع هذا السؤال ذهبت عبر الإنترنت. بعد نقاشات قليلة حول stackoverflow (وأين بدونها) ، يبدو أنه تم العثور على الإجابة. تحتاج إلى إنشاء معلمة خاصة في
حوالي: config (بالطبع استبدال foo بـ conf):
network.protocol-handler.expose.foo = false
نخلق ، افتح الرابط و ... لم يكن هناك. المتصفح ، كما لو لم يحدث شيء ، يقول أنه لا يعرف تطبيقنا.
قرأت الوثائق الرسمية حول تسجيل البروتوكول مع Mozilla ، هناك خيار لتسجيل الجمعيات في سطح مكتب gnome نفسه (استبدال بالطبع foo بـ conf):
gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' --type String gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true
أسجل ، افتح المتصفح ... ثم اللحية مرة أخرى.
هنا سطر من الوثائق يلفت انتباهك:
في المرة التالية التي تقوم فيها بالنقر فوق ارتباط من نوع البروتوكول ، سيُطلب منك تحديد التطبيق لفتحه.
- المني Semenych
- اه
نحن لا نضغط على الرابط ، ولكن ببساطة صفحة الويب تتغير نافذة. الموقع من خلال جافا سكريبت. أكتب ملف html بسيط مع رابط لبروتوكول conf ، وافتحه في متصفح ، وانقر على الرابط - Yos! تفتح نافذة بسؤال عن أي تطبيق تحتاج إلى فتح رابطنا وهناك بالفعل لدينا تطبيق Lync في القائمة - لقد سجلناه بصراحة بكل الطرق الممكنة. هناك علامة اختيار في النافذة "تذكر الاختيار وفتح الروابط دائمًا في طلبنا" ، لاحظ ، انقر فوق "موافق". وهذا هو النصر الثاني - يتم فتح نافذة المؤتمر. في الوقت نفسه ، لا يعمل افتتاح المؤتمرات بالفعل عند النقر على الرابط فحسب ، ولكن أيضًا عند التبديل من الصفحة المطلوبة للانضمام إلى المؤتمر.
ثم راجعت أن حذف
معلمات network.protocol-handler.expose.conf لم يؤثر على تشغيل البروتوكول بأي شكل من الأشكال. استمرت الروابط في العمل.
استنتاج
لقد حمّلت جميع إنجازاتي إلى مستودع جيثب ، وستكون روابط جميع الموارد في نهاية المقالة.
سيكون من المثير للاهتمام بالنسبة لي الحصول على تعليقات من أولئك الذين يرغبون في استخدام أفضل الممارسات الخاصة بي. يجب أن أقول على الفور أنني فعلت كل شيء فقط لنظام Linux Mint ، لذلك قد لا تعمل بعض التوزيعات أو أجهزة الكمبيوتر المكتبية الأخرى في هذا الإصدار. بدلاً من ذلك ، أنا متأكد من ذلك تقريبًا ، لأنني قمت بتصحيح وظيفة xdg-open فقط 1 المتعلقة بـ DE الخاص بي فقط. إذا كنت ترغب في إضافة دعم لأنظمة أخرى أو dekstopov ، اكتب لي طلب تجمع في github.
استغرق تنفيذ المشروع بأكمله 1 مساء.
المراجع: