واجهة المستخدم الرسومية العالمية ~ = نهاية البؤس

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

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

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

يرسل الخادم بيانات Json ، والتي بموجبها يجب على واجهة المستخدم الرسومية لتطبيقنا تصميم صورة تفي بمواصفات واجهة المستخدم الرسومية الجميلة. جوجل مع تصميمها المادي هو المعيار اليوم ، لذلك خذها.

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

• زر بدون حالة {"name": "Push me"}. إذا كان العنصر يحتوي على اسم فقط ، فهو زر.
• حقل الإدخال هو {'name': 'Edit me'، 'value': ''} لأن قيمة النوع هي سلسلة.
• زر المحول {'name': 'My state'، 'value': false} لأن النوع false منطقي.
• اختر من القائمة {'name': 'Switch شيء' ، القيمة: 'Choice1' ، options = ['Choice1' ، 'Choice2' ، 'Choice3']}
• الصورة {'name': 'Image،' url '': '..'، 'width': ..، 'height': ...}
• الجدول {'name': 'My table'، 'headers' = ['Name'، 'Synonym']، rows = [
  ['young'، 'youngful']،
  ['small'، 'meager']،
  .. .]
  }
  

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

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

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

• إذا لم يتم عرض الاسم على الشاشة ، فيجب أن يبدأ بـ _ ؛
• - , ‘icon’: ‘ Material Design ’; push - {‘name’: ‘_Check’, ‘icon’: ‘check’}
• , Viewers, , ‘colors’, ‘params’,… // . — , .

للتجميع المنطقي للعناصر ، نقدم مفهوم الكتلة الذي يجمع العناصر ذات الصلة المنطقية في كتلة مرئية واحدة.

{'name': 'Block 1'، 'elems': [{'name': '_Check'، 'icon': 'check'}، ...]}
داخل الكتلة ، يجب أن تحتوي جميع العناصر على أسماء فريدة لأنها معرّفة .

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

أعلى مستوى من الوصف هو الشاشة. يبدو أن {'name': 'Screan'، block: [..]، menu: [{'name': 'Screen'، 'icon': ..،}، ..]، 'toolbar': [JSON set - العناصر (الأزرار ، الحقول ، أيا كان)]}

أضف تفاصيل التنفيذ لـ uniGUI الشرطي الذي يدعم بروتوكول JSON الخاص بنا. إنها عملية منفصلة تتواصل مع خادم بيانات Websocket وتوفر عرض بياناتها مع التقارير اللاحقة لجميع تحديثات هذه البيانات المهمة للخادم.

عند الاتصال بالخادم ، يتوقع uniGUI استلام الشاشة. بعد أن استلمها ، قام بتصميم ورسم المعلومات الناتجة بطريقة مثالية للشاشة الحالية للمستخدم ، ثم ينتظر رد فعل من المستخدم والخادم. من صورة البيانات المُنشأة ، يتلقى الخادم دفقًا من رسائل JSON التي تصف بشكل كامل ما فعله المستخدم. لديهم شكل ["Block" و "Elem" و "type of action" و "value"] ، حيث تمثل "Block" و "Elem" أسماء الكتلة والعنصر ، والقيمة هي قيمة الحدث.

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

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

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

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

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



واجهة المستخدم الرسومية لتطبيق تدفق الرسائل -> يبدو الخادم مثل هذا:

الرفرفة: [مسرد المصطلحات ، = ، 658]
رفرفة: [_Details، Links، @،Folliculitis]
رفرفة: [_Details، Links، @،Adolescent]
رفرفة: [toolbar، _Back، =، _Back]
رفرفة: [toolbar، _Forward، =، _Forward]
رفرفة: [toolbar، _Back، =، _Back]
رفرفة: [_Details، _Status، =، Virtual]
رفرفة: [_Details، _Status ، =، Stable]
رفرفة: [_Details، Links، @،التهاب]
رفرفة: [_Details، _Status، =، Virtual]
رفرفة: [_Details، _Status، =، Stable]
رفرفة: [toolbar، _Back، =، _Back]
رفرفة: [_Details، Links، @،Folliculitis]

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

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