🦄 😱 🕟 واجهة المستخدم الرسومية باللغة الروسية ، أو محطة VKS تفعل ذلك بنفسك 🤘🏿 🎥 👰🏻

خبرة في تطوير واجهة المستخدم الرسومية C ++ لنظام التداول بالفيديو الروسي (VKS). تركيب التكنولوجيا الحديثة ومتطلبات التصديق. "أشعل" التنمية الرئيسية وسبل الالتفاف عليها. ما هو الشيء المشترك بين واجهة المستخدم الرسومية والباليه الروسي.

أول شيء يراه مستخدم نظام مؤتمر الفيديو هو الواجهة. وفي معظم الحالات ، يتم الحكم على النظام من خلال مظهره ووظيفته. لن تسمح واجهة غير ملائمة أو مترامية الأطراف بتقييم أداء النظام العالي أو الوظائف الواسعة. من الناحية الفنية ، يجب لف النظام "الجميل" في هيكل عمل جذاب ومستقر. لذلك ، في بداية تطوير نظام VKS المحلي ، تم أخذ هذه اللحظة في الاعتبار على الفور.

من سيكون مستخدم نظام التداول بالفيديو الروسي؟

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

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

واجهة المستخدم الرسومية في البداية

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

من وجهة نظر واجهة المستخدم الرسومية ، تمت صياغة المتطلبات التالية:

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

تسمح لك قائمة الوظائف هذه بحل مشكلة تطوير واجهة بطرق مختلفة. علاوة على ذلك ، تأثر اختيار نوع معين من التنفيذ بالقيود المفروضة على نوع لغات البرمجة (على سبيل المثال ، لم تكن جافا بشكل قاطع مناسبة لإصدار الشهادات ، و CSS / HTML - وفقًا للوظائف) ، وتخصص المطورين ، والتوقيت. بشكل عام ، تم الاختيار لصالح C ++ واستخدام إطار Qt5 ، حيث ، على سبيل المثال ، لا تسمح تقنية QML الأكثر حداثة بعرض الفيديو باستخدام سياق OpenGL تعسفي ، وكان ذلك ضروريًا وفقًا لـ ToR لمحطات VKS.

بسرعة وكفاءة

تم إنشاء أول نموذج أولي لواجهة المستخدم الرسومية لهاتف Qt الخاص به واستخدام العديد من المكتبات مفتوحة المصدر. على سبيل المثال ، بالنسبة لبروتوكول SIP ، تم استخدام مكتبات eXosip / oSIP ، لترميز / فك تشفير الفيديو والصوت - ffmpeg ، للعمل مع الأجهزة الصوتية - PortAudio. كان هذا الهاتف يعمل تحت Linux و Windows و MacOS وكان متظاهرًا في مجال التكنولوجيا وليس جهازًا حقيقيًا.

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

الأساسية والجبهة

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

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

العذاب والنصر

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

الاتساق إلى الأبد

تاريخياً ، كانت أول مشكلة مثيرة للاهتمام ظهرت أثناء تطوير واجهة المستخدم الرسومية لأنواع مختلفة من محطات VKS هي مشكلة الاتساق ، أي الحالة المنسقة لجميع الوحدات. أثناء التشغيل ، تتفاعل واجهة المستخدم الرسومية مع العديد من الوحدات الأخرى: وحدة للتفاعل مع الأجهزة ، ونظام فرعي لإدارة المكالمات ، ووحدة معالجة الوسائط (MCU) ، ونظام فرعي لتفاعل المستخدم.

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

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

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

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

الشيء المهم هنا هو أن كل معالجة الانتقال تتم في مؤشر ترابط واجهة المستخدم الرسومية. يتم ضمان ذلك من خلال استخدام آلية فتحة إشارة Qt في متغير QueuedConnection ، حيث يتم إنشاء حدث لكل إشارة ووضعه في EventLoop الرئيسي للتطبيق.

تقديم OpenGL على أجهزة منخفضة الطاقة

هناك صعوبة أخرى كان علينا التعامل معها وهي مشكلة عرض الفيديو. يوفر Qt عرض OpenGL لفئة QOpenGLWidget الخاصة وفئات المساعدة ذات الصلة ، والتي تم استخدامها في الأصل لعرض الفيديو. يتم توفير البيانات لتقديم (إطارات الفيديو التي تم فك تشفيرها) نفسها من خلال وحدة معالجة الوسائط (MCU) ، والتي ، من بين أمور أخرى ، تنفذ فك تشفير الأجهزة لدفق الفيديو (على GPU). في المعالجات منخفضة الطاقة ، تم "إبطاء" عرض فيديو FullHD. كان الحل المباشر هو استبدال المعالج ، ولكن هذا سيتطلب معالجة جادة للمكونات التي تم الانتهاء منها بالفعل من نظام التداول بالفيديو وسيزيد من تكلفة الأجهزة نفسها. لذلك ، تم تحليل عملية العرض بالكامل بعناية للعثور على طرق أكثر جمالا لحل المشكلة.

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

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

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

تم حل هذه المشكلة على النحو التالي: من عنصر واجهة المستخدم الحالي ، يتم الحصول على صورته (يحتوي QWidget على طريقة grab () لهذا) ، ويتم تحويل الصورة الناتجة إلى نسيج OpenGL ويتم تقديم الأخير في أعلى الفيديو باستخدام أدوات OpenGL. من خلال إضافة البيئة المناسبة ، تم تنفيذ آلية عالمية يمكن استخدامها لعرض أي عناصر واجهة مستخدم قياسية أعلى الفيديو بطريقة غير قياسية.

الأكشاك والحاجيات

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

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

جاء الجواب من مكتبة نظام LINUX Xrandr OS ، المسؤولة عن العمل مع شاشات العرض. هناك القليل جدًا من الوثائق عليه على الإنترنت ، لذلك تم التنفيذ باستخدام أمثلة من الإنترنت ، بما في ذلك من هبر. بالإضافة إلى ذلك ، كان من الضروري التوصل إلى خوارزمية لتوزيع أجزاء الواجهة بين الشاشات ، بالإضافة إلى دمج نافذتين مختلفتين في واحدة واحدة. تم تنفيذ هذا الأخير على النحو التالي: ما هي النوافذ في وضع النافذة ، في وضع "الكشك" عبارة عن أدوات داخل نافذة واحدة كبيرة ، والتي تمتد على أكثر من شاشتين (إذا كان هناك 2 منها). في هذه الحالة ، من الضروري تكوين مواضع الشاشات بحيث يتم إنشاء مساحة افتراضية مستمرة (يتم ذلك باستخدام مكتبة XRandr) ، ثم قم بتعيين الشكل الهندسي للأدوات الداخلية داخل نافذة عمومية واحدة حتىحتى يظهر الجميع على الشاشة.

نخلق الروسية

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

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

واجهة المستخدم الرسومية باللغة الروسية ، أو محطة VKS تفعل ذلك بنفسك