Xterm.js: مشكلة في الأنبوب والشخصية في النوافذ مع الكروم

Windows 7 Prof ، إصدار Chrome 45.0.2454.101

مرحبًا chani ، شكرًا على الإبلاغ! لم أتمكن من إعادة إنتاج مشكلتك بالرغم من ذلك. لقد قمت بكتابة كلا الحرفين في صفحة العرض التوضيحي (http://sourcelair.github.io/xterm.js/demo/) وفي SourceLair (https://www.sourcelair.com) وتمت طباعة كلاهما بشكل طبيعي باستخدام Chrome 46 على Windows.

هل يمكن أن تعطيني مزيدًا من السياق أو بعض الخطوات الأكثر تحديدًا لإعادة إنتاج هذا؟

لقطات

سلام،

تم التحقق منه للتو ، فهو لا يعمل في صفحتك التجريبية ولا مع هذه المجموعة (windows ، chrome). لدينا تخطيط لوحة مفاتيح ألماني ، حرف الأنبوب مصنوع من خلال ALT-GR + <و at-char مصنوع من خلال @ ALT-GR + q

(ALT-GR هو مفتاح alt الموجود على يمين لوحة المفاتيح ، ولست متأكدًا من تسميته بالتساوي على لوحات المفاتيح خارج ألمانيا). هل هذه المعلومات تساعد؟

يبدو أن المشكلة هنا هي تخطيط لوحة المفاتيح الألمانية.
المشكلة هي أنه لا توجد طريقة لمعرفة تخطيط لوحة المفاتيح مسبقًا. وفي أحداث keydown التي وصفتها ، تمت ترجمة Alt-gr إلى Ctrl + Alt .
مع الإصدار الحالي (0.31) ، يؤدي Ctrl + Alt هنا حيث من المفترض أن يتعامل xterm مع key = String.fromCharCode(ev.keyCode - 64); مما ينتج عنه مفتاح Ctrl فقط في حالة AltGr + q.
باستخدام تخطيط لوحة المفاتيح ، يبدو أن @ (shift + 2) ناتجًا عن ضغطة مفتاح فقط وليس نتيجة معالجة الإدخال. في أحدث الالتزامات (وإن لم يكن في أحدث إصدار حتى الآن) ، تم تغيير التدفق الذي أدى إلى التعامل مع Alt-gr بواسطة عبارة Ctrl لذلك قد يعمل من أجلك.
جرب bower install xterm.js#c1701561474cd2aa7389b66f7acb2a1e00c84e24 ولاحظ ما إذا كان هذا سيؤدي إلى إصلاح أي شيء.
إذا لم يكن الأمر كذلك ، فسيتعين علينا إيجاد طريقة للتعامل مع تخطيطات لوحة المفاتيح الأخرى بشكل صحيح

سلام،

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

سلام،

تم التحقق منها للتو. لا يزال لا يعمل في الكروم في النوافذ.

سلام،

هذه المشكلة لا تزال قائمة. ومع ذلك ، هل يمكن لشخص ما أن يرشدني / يعطيني مثالاً ، ما الذي يمكنني فعله لتعيين (بالإضافة إلى ذلك) alt + 7 لطباعة حرف الأنبوب في نافذة المحطة الطرفية؟ شيء مثل:

evt = (e == null؟ event: e) ؛
إذا ((evt.altKey && evt.keyCode == 55)) {
.. اصنع | في نافذة المحطة .. :-)
}

سيكون هذا حلاً جيدًا لمستخدمي Chrome ..

مرحبًا chani ، شكرًا

تحدث جميع وظائف معالجة المفاتيح في Terminal.prototype.write . لذلك هذا هو المكان الذي يمكنك فيه إضافة وظائفك.

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

بالنظر إلى الآن ، تم تسليم الشعلة رسميًا إلى xterm.js بواسطة chjj - لقد

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

مرحبًاexsilium. # 60 يبدو وكأنه علاقات عامة معدة جيدًا ، لكنه يكسر بعض الوظائف على الرغم من الاستخدام السائد.

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

أهلا! شكرا parisk على التحديث. نعم ، يجب أن يعمل التدفق الرئيسي بشكل موثوق به دون سؤال وهذا شرط أساسي لأي نوع أو إصلاحات من المستوى الثالث. لذلك سأفصل المشاكل:

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

هتافات!

أكبر مشكلة في # 60 هي أنه في نظام التشغيل Mac OS ، مفتاح بديل ⌥ Opt هو أيضًا تحول المستوى الثالث. لقد رأيت أن هناك بعض المنطق الذي قام بتعيين مفتاح تعريف Mac الخاص بـ Cmd إلى Alt على منصات أخرى ، ولكن تم كسره بعد بضعة أسطر . # 60 يصلح ذلك (ويسبب عدم اتساق متأصل في الوقت الحالي).

هذا يترك لنا 3 خيارات:

1. اترك رقم 60 كما هو. مفتاح الأمر الخاص بمستخدم Hijack Mac OS ⌘ Cmd ، والذي قد يتسبب في فشل عمليات مثل نسخ ولصق لوحة المفاتيح.
2. أزل المنطق المذكور واترك Alt . سيؤدي ذلك إلى منع مستخدمي نظام التشغيل Mac OS من الدخول في نوبة من المستوى الثالث.
3. قم بإزالة المنطق المذكور ، واترك ⌥ Opt بمثابة تحول من المستوى الثالث. سيؤدي ذلك إلى منع الاختصارات المفيدة مثل Alt + D (حذف كلمة إلى الأمام) ، لكنه يترك Esc D المكافئ يعمل على النحو المنشود.

إذا كنا نسير مع # 60 ، فإنني أوصي بتصحيحه ليتوافق مع الخيار رقم 60. 3. نظرًا لأن هذا هو الوحيد الذي لا يزيل أي وظيفة لمستخدمي Mac OS ، فإن الضغط على Alt سيظل يعمل من خلال مفتاح Esc ، وسيعمل ⌘ Cmd كما يتوقع المستخدمون. هذه أيضًا هي الإعدادات الافتراضية لمحاكيات محطات Mac OS X المحلية الشهيرة مثل _Terminal_ و _iTerm2_.

مرحبًاrunarberg.

حسنًا ، أتفق مع تفضيلك أن يكون الرقم 3 هو الخيار الأفضل بسبب الاستخدام الواسع بالفعل لـ ESC كميتا في iTerm و Terminal. ومع ذلك ، قد يختلف بعض المتعصبين من emacs ؛) لكنني أعتقد أنه حل وسط جيد.

هل يمكنك من فضلك محاولة التحقق من أحدث الالتزام على المستوى الرئيسي وإخبارنا إذا كان الدمج # 60 قد أدى إلى حل هذه المشكلة؟

/ سم مكعبchaniexsiliumrunarberg

يبدو أنه يعمل بشكل جيد! شكرا! (تم اختباره في OSX و Safari)

تم اختباره باستخدام الصفحة التجريبية و xterm.js الجديد من الإصدار الرئيسي ؛ @ و | لا تزال لا تعمل في تركيبة windows + chrome + german-keyboard. أتساءل عما إذا كان بإمكاني تقديم جهاز VM للاختبار. ومع ذلك ، فقد اختبرت زوجتي أنه (نظرًا لعدم وجود أي جهاز يعمل بنظام windows وزملائي يقضون عطلة نهاية الأسبوع) ، سيعودون إليك بمجرد أن أحصل على المزيد من النتائج. في Linux + Firefox / chrome ، لا يزال يعمل بشكل جيد. إصدارات لا تعمل:

إصدار الكروم 51.0.2704.84 م
ويندوز 8

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

chani هل تعتقد أنه من خلال إلقاء نظرة على # 60 ، يمكنك إعداد

pariskchani لا ينبغي أن يكون هناك أي قضايا المتبقية مع لوحات المفاتيح الألمانية على وجه الخصوص. بمجرد السماح بتغييرات مستوى ISO 3 ، يجب أن يكون متاحًا لجميع لوحات مفاتيح ISO. الآن ، ربما لا تزال هناك مشكلات تتعلق بالطقس ، ما زلنا نمنع إدخالات المستوى الثالث على بعض الأنظمة وبعض المتصفحات. لم أختبر مطلقًا على Chrome على Windows على سبيل المثال.

http://stackoverflow.com/questions/10657346/detect-alt-gr-alt-graph-modifier-on-key-press

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

@ parisk تحاول.

@ parisk الق نظرة:

إخراج الكروم على النوافذ ، بالضغط على @ -char

e.keyCode: 64
e.altKey: true
e.ctrlKey: true
e.keyCode || e.which: 64
e.shiftKey: false
e.metaKey: false
e.charCode: 64

نفس الشيء بالنسبة لي لينكس

Linux x86_64
e.keyCode: 64
e.altKey: false
e.ctrlKey: false
e.keyCode || e.which: 64
e.shiftKey: false
e.metaKey: false
e.charCode: 64

هل لاحظت أن النوافذ يبدو أنها ترسل altKey و ctrlKey صحيحًا حيث لا يبدو أن هذا يحدث كما هو الحال في لينكس؟ هل يمكن أن يكون ذلك مرتبطا؟ الآن | -char ، لينكس:

e.keyCode: 124
e.altKey: false
e.ctrlKey: false
e.keyCode || e.which: 124
e.shiftKey: false
e.metaKey: false
e.charCode: 124

شبابيك:

e.keyCode: 124
e.altKey: true
e.ctrlKey: true
e.keyCode || e.which: 124
e.shiftKey: false
e.metaKey: false
e.charCode: 124

مرة أخرى ، هذا التناقض الذي يرسله windows altKey و ctrlKey صحيح حيث لا يفعل لينكس. سألقي نظرة فاحصة هذا المساء.

شكرا جزيلا. العلاقات العامة لهذا سيكون رائعًا.

متأكد تمامًا من أن الإصلاح سيستغرق وقتًا أطول. runarberg ، هل يمكنك عمل شيء ما باستخدام المعلومات المقدمة؟ إذا لم يكن الأمر كذلك ، فسأحاول ، على الرغم من أن JS الخاص بي محدود .. ولست متأكدًا من أين أبدأ. :)

chani نحن بالفعل نأخذ هذا في الاعتبار . يتعامل Linux (على الأقل ubuntu) مع تحول المستوى الثالث أصلاً مع مفتاح خاص معين له (عادةً AltGr ) ، لذلك تعمل أجهزة ubuntu خارج الصندوق (ولديها دائمًا). تنشأ المشكلة مع نظام التشغيل Windows وخاصة نظام التشغيل Mac ، لأنهم لا يمتلكون هذه الفكرة ، ويعتمدون على أحرف التحكم التي يتم الضغط عليها. يعمل # 60 على إصلاح هذا التناقض من خلال استمرار إرسال حدث رئيسي إلى المحطة عند وجود event.ctrlKey و event.altKey في حدث لوحة المفاتيح على windows أو عندما يكون event.altKey موجودًا في نظام التشغيل Mac OS.

لقد جربت هذا مؤخرًا على كل من Edge و Chrome 51 على جهاز يعمل بنظام Windows 10 ، وتمكنت من إدخال هذه الأحرف على لوحة مفاتيح ISO باستخدام إما Ctrl + Alt + Q ⇒ @ أو AltGr + + ``.

ملاحظة: على عكس Ubuntu ، عادةً ما يقوم MS Windows بتعيين AltGr على Ctrl + Alt .

pariskrunarberg شكرا لكما . باستخدام CTRL + ALT + Q و CTRL + ALT + <يعمل كما هو متوقع. ومع ذلك ، فإن ضغط المفتاح "المعتاد" والذي سيكون ALTGR + Q و ALTGR + <لا يعمل في Windows. أعتقد أن هذا جيد بما فيه الكفاية.

تصحيح .. آسف. يبدو أن strg + alt + q لا يعمل مع الكروم في الويندوز.

أعتقد أن هذا تم إصلاحه في 3.2.0 https://github.com/xtermjs/xterm.js/releases/tag/3.2.0