Xterm.js: التمرير السلس

تم إنشاؤها على ١١ ديسمبر ٢٠١٧  ·  16تعليقات  ·  مصدر: xtermjs/xterm.js

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

هل من الممكن (ومن المرغوب فيه) أن يعمل xterm.js على حل هذه المشكلة ودمج خيار التمرير السلس المستند إلى البكسل؟

سألت في الأصل albinekb نفس الشيء عن Hyper (https://github.com/zeit/hyper) وأحالني إلى هذا المشروع لأن Hyper يستخدم xterm.js.

aremouse-support typenhancement

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

شيء لا يستخدمه سوى عدد قليل جدًا من الأشخاص

كل من يقوم بالتمرير باستخدام لوحة اللمس يستخدمها في VTE ، سواء أعجبهم ذلك أم لا: د

ال 16 كومينتر

من المؤكد أنه من الممكن القيام به ولكن سيكون هناك الكثير من العمل (+ تعقيد إضافي) لشيء يستخدمه عدد قليل جدًا من الناس. أفضل عدم إضافة هذا شخصيًا.

هذا مفهوم وعادل. شكرا لعملكم!

لمعلوماتك: VTE (محطة جنوم والأصدقاء) تفعل ذلك منذ الإصدار 0.44. (بالطبع لا يعمل إلا في التمرير للخلف لمحاكي المحطة الطرفية ، وليس عند تمرير الملف في محرر نصوص على سبيل المثال.)

شيء لا يستخدمه سوى عدد قليل جدًا من الأشخاص

كل من يقوم بالتمرير باستخدام لوحة اللمس يستخدمها في VTE ، سواء أعجبهم ذلك أم لا: د

egmontkob لدي محطة جنوم

screen shot 2017-12-18 at 6 57 19 am

من المرجح أن تشير gt 3.18.3 إلى أن لديك vte 0.42 ، في حين أن هذه الميزة جديدة في 0.44.

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

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

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


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


أنا جديد على xtermjs والأصدقاء ولم أجرب ذلك بعد ، فقط انظر إلى أن الأشياء الرائعة تحدث هنا. لست متأكدًا من أنني أمتلك الهندسة المعمارية الصحيحة في ذهني ، ولكن إذا فعلت ذلك ، فإن GNOME Terminal هي VTE ما هو hterm بالنسبة لـ xtermjs. VTE عبارة عن عنصر واجهة مستخدم GTK + يقوم بمحاكاة المحطة الطرفية. هناك ما يقرب من اثني عشر تطبيقًا أكثر أو أقل من تطبيقات المحاكاة الطرفية الشائعة التي تستخدم VTE ، بما في ذلك GNOME Terminal و Xfce4 Terminal و Terminator و Tilix ...


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

  • احصل من بوابة أو تاربال
  • ./autogen.sh (git) أو ./configure (tarball)
  • make
  • ./src/app/vte-2.91 (من 0.51) أو ./src/testvte (حتى 0.50) أو ./bindings/vala/vte-2.91 أو ./src/vte-2.91 (حتى 0.50 ، تم نقلها إلى دليل آخر في وقت ما)

كنت أستخدم عجلة الفأرة ، هذه مشكلتي: sweat_smile:

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

IMO من الآمن أن نقول إنه متوقع من قبل المستخدمين في هذه المرحلة. أعني ، حتى أنه يمتلكها.

ليس من الممكن حقًا باستخدام عارض اللوحة ، ولكن سيكون من السهل جدًا تحقيقه باستخدام عارض webgl https://github.com/xtermjs/xterm.js/pull/1790 الذي يجب أن يحل محل عارض اللوحة القماشية. بالنسبة إلى عارض DOM ، يمكننا تحقيق ذلك من خلال وجود خطوط مرئية جزئيًا في الأعلى والأسفل. على هذا النحو ، أنا أعتبر هذا محظورًا في # 1790

شيء آخر يجب مراعاته: وجود ydisp ليس عددًا صحيحًا ووجود أكثر من صفوف من Terminal.rows مرئي يكسر بعض الافتراضات الموضوعة في الكود ، على سبيل المثال كيف يؤثر ذلك على دعم قارئ الشاشة؟

إنه غير ممكن حقًا مع عارض اللوحة القماشية

ولم لا؟ يجب أن يكون الأمر بسيطًا مثل رسم viewportHeight + 2 من الصفوف ، والتعويض في مكان ما بين الصف الأول والثاني بناءً على إزاحة البكسل لموضع التمرير الحالي.

من المؤكد أنه من الممكن القيام به ولكن سيكون هناك الكثير من العمل (+ تعقيد إضافي) لشيء يستخدمه عدد قليل جدًا من الناس. أفضل عدم إضافة هذا شخصيًا.

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

ولم لا؟

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

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

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

في كل مرة أقوم فيها بتمرير الجهاز في Visual Studio Code أفقد المكان الذي كنت فيه. التمرير السلس ميزة أساسية ونحن بحاجة إليها.

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