Vscode: علامات تبويب للمحطة المتكاملة

تم إنشاؤها على ١٥ أغسطس ٢٠١٦  ·  191تعليقات  ·  مصدر: microsoft/vscode

طلب المواصفات.

المحطة الافتراضية

image

ولكن يمكن أن يكون أكثر قابلية للاستخدام ...

terminals2
terminals1

feature-request integrated-terminal layout ux

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

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

ال 191 كومينتر

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

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

stevencl @ bgashler1 يرجى تقييم علامات التبويب مرة أخرى مع الأخذ في الاعتبار أنني لم أجد روابط مفاتيح افتراضية معقولة لإجراءات المحطة focusNext و focusPrevious (أقوم بربط ctrl + shift + j / k).

نحتاج إلى النظر في هذا في سياق هذه المشكلة على الرغم من: https://github.com/Microsoft/vscode/issues/9659

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

مجرد التفكير بصوت عالٍ هنا ، هل نحتاج حقًا إلى إظهار علامات التبويب إذا سمحنا بتقسيم الجهاز؟ هل سيكون كافيًا إذا كشفنا للتو إجراءات لتقسيم الجهاز الطرفي وطيّه ولكن لم يكن علينا إظهار علامة التبويب الفعلية؟

ربما يمكنني أن أرى نفسي أستخدم 2-3 محطات مقسمة عبر علامات تبويب / محطات طرفية متعددة. قد تصبح إدارة المحطات الطرفية المنقسمة ومحطات علامات التبويب مربكة للغاية وربما بالكاد تحصل على أي فائدة بسبب نقص روابط المفاتيح.

إذا فتحنا الباب لتقسيم المحطات ، فماذا يعني ذلك للتقسيم ، على سبيل المثال ، أحد طرفي واحد واستبدال تصحيح واحد؟ هل هو نفس تفاعل UX؟

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

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

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

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

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

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

ماذا عن خيار محاذاة الجهاز مع علامة تبويب المحرر ، بحيث يعكس الجهاز تلقائيًا لغة ملف المحرر؟

سيؤدي فتح محطة طرفية تلقائيًا إلى تحميل غلاف تم تكوينه مسبقًا للغة المحرر النشط (المحدد حاليًا). يجب دعم عدة قذائف طرفية في ملف settings.json.

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

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

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

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

عندما تقوم بتحويل التركيز من المحرر الحالي إلى محرر بلغة أخرى (على سبيل المثال ، Ruby) ، فإن الجهاز سيقدم مثيل IRB في الجهاز. إذا أراد المستخدم فتح مثيل آخر من الصدفة الحالية ، فقد يضطر فقط إلى التمرير فوق النص التشعبي لتلك shell والنقر فوق + الذي سيظهر. إذا كانت سلاسل النص التشعبي قصيرة - مثل العقدة ، irb ، cmd ، ps - يمكن إنشاء سلسلة أخرى بجوار السلسلة المستخدمة لإنشاء مثيل جديد. ستتحرك الأوتار بشكل منفصل لإفساح المجال لكنها لن تشوش لأنه يمكن تعيين حد (من سيفتح أكثر من ثلاث قذائف ضد المحرر؟).

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

إذا كنت ترغب في منح المستخدم خيار إضافة صدفة غير مرتبطة بالمحرر ، مثل git shell ، فإن النقر فوق + يمكن أن يعرض قائمة بالقذائف المسجلة في ملف settings.json. لا تظهر علامة - التي تظهر عند المرور بجانب كل سلسلة نص تشعبي ، بالطبع ، أي خيارات. سيغلق مثيل shell الحالي.

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

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

من المحتمل أن يطلب ملف settings.json من المستخدم إدخال امتداد اللغة المحدد (.js ، .cs ، .rb) مقابل كل terminal.internal.shell. الدخول بحيث يكون هناك تطابق منطقي مع ملف. يمكن تكوين قذيفة افتراضية لأي نوع ملف غير محدد في settings.json.

يستمر مثيل shell الذي تم تحميله لكل محرر طالما أن المحرر مفتوح. بمجرد إغلاق محرر (ملف) ، يتم أيضًا إغلاق غلاف (ق) الطرفي المرتبط.

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

@ nick-walt بينما قد يكون الأمر أكثر سهولة للبعض ، إلا أنه ليس بديهيًا على الإطلاق للآخرين. من المحتمل أن يتسبب ذلك في إرباك الناس إلى حد ما والتساؤل أين ذهبت قوقعتهم. كما أن متطلباتي هي عرض قذائف 2 مرة واحدة ؛ واحد لمهمة الساعة التي أتتبع الأخطاء فيها والآخر لمهمة التشغيل ، git ، البناء ، إلخ.

ظهرت تكوينات طرفية متعددة من قبل ، لست متأكدًا من أنها تستحق التعقيد الإضافي على الرغم من أنه في معظم الوقت يمكنك فقط تشغيل الصدفة في غلافك الآخر (يفتح powerhell ، ruby ​​، ​​node ، إلخ داخل cmd).

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

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

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

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

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

أعتقد أنه يمكن معالجة مخاوفك بالكامل.

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

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

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

هناك حاجة أيضًا إلى العرض المقسم لأنه على الشاشة العريضة يوجد مكان متاح على الأقل لأكثر من محطة واحدة.

سؤال آخر هو الاستخدام التعاوني مع عداء المهام. والتي تستخدم حاليًا لتشغيل مهمة واحدة فقط في كل مرة. لكن https://github.com/Microsoft/vscode/issues/981 يفترض أنه سيدعم مهام خلفية متعددة - لذا فهو يشبه (لن أقول متضاربًا) الغرض كما هو الحال بالنسبة لمحطات متعددة.

تمتلك Jetbrains Webstorm currenlty مثل هذه الإمكانيات - يمكنها تشغيل مهام متعددة (محددة عبر grunt / gulp / npm) ومحطات متعددة (مع علامات تبويب مسماة). ويمكنك أيضًا استخدام طريقة عرض مقسمة حيث يرى أحد الجانبين تشغيل المهام ، وعلى الجانب الآخر - الطرفية. (إرفاق الشاشة)

image

@لون أبيض

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

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

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

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

أو ، يمكن للمستخدم إنشاء مثيل shell إضافي من shell المبدئي 'cmd' ربما باستخدام أمر يفهمه الجزء الطرفي على أنه إنشاء "جديد".

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

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

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

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

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

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

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

cescoferraro تعجبني هذه الفكرة. ولكن بعد ذلك ، يجب أن يدعم VS Code أيضًا طرق عرض علامات التبويب المنقسمة الرأسية وليس أفقيًا فقط. وإلا فلن تستوفي الشرط حقًا لرؤية محطات متعددة دون إضاعة المساحة.

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

لقد كتبت ملحقًا يمكنك من خلاله تحديد مهمة npm / gulp ، وستقوم بتشغيل المحطة الطرفية (مع اسم المهمة) وتشغيلها هناك ، كما ستضع عنصرًا على شريط الحالة يمكنك النقر فوقه في أي وقت ، يقوم بالتتبع الأساسي لحالة العملية الجارية.
image

فقط لإظهار موقع "علامات التبويب" المحتمل ، يمكن أن يكونوا في الجزء السفلي من المؤقت.

whitecolor : open_mouth: هذا يستخدم API المحطة الجديدة؟ هذا رائع!

Tyriar نعم ، ذلك الشخص الذي تعمل عليه: غمزة:

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

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

whitecolor بعد التفكير في الأمر قليلاً ، هناك بعض المشكلات التي

  • عند إعادة تشغيل vscode ، سيتم إنشاء محطة طرفية قياسية ، ولا يمكنك إرفاق عنصر شريط الحالة بهذا
  • الامتداد غير مدرك عندما يتم التخلص من الجهاز بواسطة المستخدم ، لذلك سيظل عنصر شريط الحالة ثابتًا على الأقل حتى يتم النقر فوقه مرة أخرى # 10925
  • (خطأ) التخلص من المحطة سيظهر اللوحة رقم 11275
  • من المحتمل أيضًا أن تكون المحطة الطرفية مخفية افتراضيًا في الإصدار 1.6.0 ، لذلك ستحتاج إلى الاتصال بـ Terminal.show مباشرة بعد إنشائه # 11384

Tyriar شكرا للمشاركة ، سوف يجيب على قائمتك:

1) نعم ، هذا ليس مهمًا جدًا ، فالإضافات الخاصة بي تضيف أمرًا "فتح محطة جديدة" وتسمح بفتح محطة طرفية جديدة مسماة ، وعادة ما أغلق المعيار فقط ، وأستخدم واحدة تم إنشاؤها ، ولكن سيكون من الجيد أن يكون هناك وصول إلى جميع المحطات الموجودة في اللوحة.
2) نعم ، الامتداد ليس على دراية بالحالة الطرفية لكني أتتبع العمليات الفرعية لـ terminal._id بواسطة PID ، لذلك أعرف متى يتم التخلص من الجهاز بواسطة المستخدم (العمليات الفرعية تذهب إلى 0). إذن ما سأطلبه عدم _remove_ معرف العملية هذا في المستقبل ، لست متأكدًا مما إذا كان يجب أن يكون عامًا). لذا فأنا أتتبع مقدار العمليات التي يتم تشغيلها ، وإذا تم تقليل العدد ، فقد يعني ذلك أن شيئًا خاطئًا أو المهام قد انتهت ، ثم أعرض هذه المحطة ، وهي مفيدة جدًا.
3) لذلك أنا لا أستخدم التخلص حاليًا.

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

التمديد جاهز بالفعل للنشر ، ومن المحتمل أن يتم ذلك في أيام.

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

نظرة خاطفة متستر على terminal._id : wink: ربما لن يتم تغييره في أي وقت قريب ، ولكن بمجرد إضافة حدث يمكنك الاستماع إليه ، يجب عليك بالتأكيد الاستفادة من ذلك لأنه سيكون واجهة برمجة التطبيقات الرسمية المستقرة. يجب استكشاف تتبع العمليات الفرعية والإخراج في # 11422 (يمكنك متابعة المشكلات المرتبطة من ذلك لبعض المناقشات حول هذا الموضوع).

باستخدام الأمر الطرفي المسمى ، فإنك تقدم أيضًا حلاً بديلاً لـ # 10023: مبتسم:

عمل جيد ، أتطلع إلى تجربته!

whitecolor FYI ، لذلك كذبت ومن المحتمل أن يتغير terminal._id في الإصدار 1.6 ليكون بعض المعرف العشوائي ، وليس معرف PID. أنا في منتصف معمل إعادة بناء ضخم لفصل اللوحة الطرفية عن العمليات أكثر (بحيث يمكن أن توجد بدون اللوحة الموجودة # 11275) ولا أعتقد أنه يمكنني الاحتفاظ بها هناك لسوء الحظ.

whitecolor يمكنك تجربة window.onDidCloseTerminal (# 10925) في المطلعين على الغد. يجب أن يكون أسهل من تتبع PID.

أود أن أراها مثل InteliJ. حتى ذلك ، أضيفها هذه المفاتيح الشخصية:

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

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

سيكون العرض المقسم على علامات تبويب المحطة مفيدًا للغاية ؛

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

أي تقدم في هذا؟

تضمين التغريدة
يمكن أن يكون tmux حلاً ولكنه يعمل بشكل غير مرتب داخل المحطة الطرفية المتكاملة VSCode (أخيرًا في windows).

MeirionHughes إليك مشكلة هذه الميزة https://github.com/Microsoft/vscode/issues/7504. لا يوجد تقدم حتى الآن ، في المرة الأخيرة التي ضغطت فيها من أجل ذلك ، تم إبعادي من الفريق. المزيد: +1: بخصوص هذه المسألة كان ذلك أفضل.

Tyriar ، يمكنك القول أن هذه المشكلة تتطلب أيضًا تظهرها بوضوح. بالإضافة إلى أن هذا العدد به 112 👍 :)

MeirionHughes يقول التعليق الأول (لي):

دعونا نتتبع تقسيم المحطة في # 7504

والسبب في ذلك هو أن المناقشات الخاصة بميزتين مختلفتين لا تخلق ضوضاء لبعضها البعض.

يا رفاق ، الرجاء المساعدة لأنها ميزة مهمة حقًا لواجهة المستخدم ، وأحيانًا تجعل crz مقبض القائمة المنسدلة لتبديل وحدة التحكم ، شكرًا جزيلاً ؛)

+1 لـ cycle terminal keybindings.

whitecolor _darn! _ اعتقدت أن tmux داخل الجهاز الطرفي المتكامل هو الحل الذكي الخاص بي ، لكنك تغلبت عليه. يعمل بشكل جيد بالنسبة لي (لا يوجد mouse mode ) لكن الأجزاء تعمل بشكل جيد:

screen shot 2017-02-06 at 2 12 51 pm

وضع الماوس يعمل بشكل جيد بالنسبة لي مع tmux.

على أي حال ، أعتقد أن هذه إضافة رائعة

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

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

أعطني رابطًا للمفاتيح للتنقل بين المحطات وأعتقد أنه يمكنني الاستغناء عن التقسيم / علامات التبويب

@ psimoneau22 هذا هو رابط المفاتيح الذي أستخدمه لذلك:

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

سنبحث في الانقسام قريبًا.

لا أصدق مدى جودة وقوة هذا المحرر. ستكون هذه إضافة قوية للغاية لمجرد فتح vscode ولا شيء آخر أثناء جلسة الترميز.

TL ؛ DR ؛ استخدم بضع ساعات لالتقاط tmux.

أنا سعيد مع tmux في طرفي (يعمل وضع الماوس مثل السحر). استغرق الأمر مني يومًا للتعلم. لقد لعبت بها من قبل عدة مرات ، لكنني أمضيت البارحة في إعدادها مثل الرئيس. أنا فقط أقوم بعمل tmux -CC في iTerm - والذي يفتح نافذة طرفية. ثم قم بعمل tmux a في محطة vscode للتواصل مع تلك الجلسة - كان هذا هو أنني أحصل على جلسات طرفية مستمرة حتى أتمكن دائمًا من العودة بالجلسة عند إعادة تشغيل vscode (تحديث Vscode ، تثبيت الامتدادات). هذه ميزة أفضل بكثير بالنسبة لي من وجود علامات تبويب أو تقسيمات في الجهاز. حافظ على ضوء Vscode من فضلك. Atom هو درس نتعلم منه (جئت منه). TMUX FTW :)

لقد نجح هذا النهج نفسه أيضًا بالنسبة لي في Mac / cygwin / windows ويجب أن يعمل إلى حد كبير في كل مكان يعمل فيه Vscode.

TL ؛ DR ؛

سيكون من الجيد أن يكون لديك علامات تبويب للوحدة الطرفية المتكاملة بدلاً من القائمة المنسدلة. هل من فرصة لرؤية هذه الميزة في المستقبل؟

بالنظر إلى الاختصار ctrl + shift + ` و ctrl + ` ` أعتقد أن هذه الإعدادات أكثر منطقية.

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

leocaseiroTyriar @ psimoneau22 إلا إذا كنت تستخدم جهاز ماكنتوش، ومن الجدير مضيفا أن 'عندما' الخيار لتلك كما ctrl + shift + left و ctrl + shift + right لتحديد أجزاء النص في المحرر.

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

أو

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

هنا 2 قيراط خاصتي لهذه الميزة المرغوبة للغاية (آسف إذا تم ذكر بعض النقاط بالفعل)

استخدم حالات
عادةً ما يكون سبب استخدامي محطات طرفية متعددة في الحالة الأولى إما:

  • أحتاج إلى العمل في دليلين بالتوازي ولا أرغب في تقديم cd للأمام والخلف طوال الوقت
  • أحتاج إلى العمل مع محطتين مختلفتين (مثل bash vsowershel vs cmd أو local vs remote / ssh)
  • أرغب في مراقبة إخراج برنامجين مختلفين في نفس الوقت

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

واجهة المستخدم
لماذا لا تمدد علامات التبويب الحالية (مثل التصحيح ، Ouput ، Terminal ...) والسماح بـ "Terminal1 ، Terminal2 ، Terminal3 ....)

علامات التبويب مقابل القائمة المنسدلة

  • ترى كل علامات التبويب المتاحة
  • من الأسهل (بالنسبة لي) تذكر المحطة التي تخدم أي غرض إذا تم تمثيلها من خلال مواقع مرئية مميزة (مثل علامة التبويب الثالثة)

TL ؛ د

أتفق بشدة مع MikeGitb ، فأنا دائمًا أستخدم أكثر من محطة طرفية في وقت واحد. يصعب رؤية علامات التبويب المفتوحة في القائمة المنسدلة للأجهزة في رمز VS الحالي. سيكون من الرائع حقًا أن يكون لديك علامات تبويب لمحطة متكاملة. شكر.

فكرة واحدة مجنونة: لماذا لا تعطي المحطة نفس حالة علامات تبويب المحرر العادي؟ سيكون مفيدًا بشكل خاص إذا أراد المرء رؤية أكثر من سطرين في نفس الوقت.

فكرة واحدة مجنونة

إنه ليس جنونًا ، هكذا يعمل vim / neovim.

إنه ليس جنونًا ، هكذا يعمل vim / neovim.

كما تفعل الكثير من IDEs الأخرى ؛).

عذرًا ، كان المقصود من هذه المقدمة بشكل مثير للسخرية.

Tyriar ، هل هناك ميزة للسماح بالتحريك الرأسي للمحطة جنبًا إلى جنب مع الكود الخاص بك أم أن هذا غير مسموح به؟

ajrator الذي تمت تغطيته في https://github.com/Microsoft/vscode/issues/2806

سأكون سعيدًا تمامًا بمنح الأجهزة الطرفية نفس حالة علامات تبويب المحرر - يواجه كل من ComEmu و HyperTerminal مشكلات خطيرة تمنع استخدامهما الحالي (لدى ConEmu مشكلات تباين لا يمكن إصلاحها حيث يريد المشرف الحفاظ على دعم XP ، ولا يمكن لـ HyperTerminal القيام بذلك Ctrl + C في بوويرشيل وأساسيات أخرى). سيكون وجود vscode كمحطة عمل مبوبة أمرًا رائعًا.

أنا أتابع أيضًا متى سينشر عرضًا مبوبًا للمحطة المدمجة بدلاً من القائمة المنسدلة.

القائمة المنسدلة غير مريحة بعض الشيء للاستخدام. كما أن وجود أكثر من محطة طرفية مفتوحة سيكون أمرًا رائعًا.

بالنسبة للأشخاص الذين يرغبون في تجربة tmux أثناء انتظار دعم علامة التبويب ، فقد أنشأت جوهرًا لبدء الإعداد. يتم تمكين دعم الماوس بشكل افتراضي ويستخدم روابط بسيطة لتقسيم الجهاز.
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

شكرا cybertim ، ملف رائع! لقد استخدمت tmux بالفعل ولكن هذا الملف سهل الاستخدام.

السبب في أنني شخصياً سأكون حريصًا تمامًا على العديد من المحطات الطرفية في مواقع مختلفة داخل النافذة هو أنه من المأمول أن يؤدي ذلك إلى تنفيذ RStudio / Jupyter Lab مثل بيئة VSCode.

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

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

بعد ذلك ، ما زلت تريد علامات التبويب؟ أجزاء؟ انشقاقات؟

أعتقد أن العديد من الأشخاص هنا يطلبون ميزة مبالغة في استخدام VScode. إذا كانوا يريدون فقط تجربة tmux ، فلن يطلبوا ذلك. المحطة تعطى لنا. باستخدام tmux ، فإنه يدعم علامات التبويب. سوف تستغرق بضع ساعات كحد أقصى لتعلم tmux. هناك علامات تبويب ونوافذ وانشقاقات وغير ذلك ، إذا كنت بحاجة إلى إعادة تشغيل VSCode ، يمكنك فقط كتابة tmux -a بعد إعادة تشغيله للعودة مباشرة إلى جلسة tmux الخاصة بك. بعد تشغيل وضع الماوس (سطر واحد فقط في التكوين) ، يمكنك حتى تغيير حجم الأجزاء ، والنقر فوق علامات التبويب للانتقال إلى علامة التبويب تلك. أنا ضد هذه الميزة في VSCode. سيؤدي فقط إلى إبطاء الأداء. حافظ على VSCode خفيف الوزن قدر الإمكان - لا نريد ذرة أخرى. دع tmux يقوم برفع الأحمال الثقيلة! كما ترى أدناه ، لدي انقسامات وأيضًا إذا نظرت عن كثب إلى الأسفل ، لدي علامتا تبويب - python & fish . ونعم ، في أسفل اليسار ، أستخدم googler في سطر الأوامر لـ Google: D

screen shot 2017-05-02 at 5 26 33 pm

piggyslasher لا أرى كيف يمكن لهذه الميزة أن تجعل vscode أبطأ.
يدعم Vscode بالفعل وجود أكثر من مثيل طرفي واحد. هذه الميزة تتعلق فقط بتغيير منتقي القائمة المنسدلة إلى ميزة أفضل لاستخدام علامة التبويب.

باستخدام هذه الميزة ، ستظل قادرًا على الاستمرار في استخدام مثيل / علامة تبويب طرفية واحدة مع tmux ، ولن تتوقع حدوث تغيير في الأداء مقارنةً الآن.

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

اقتراحpiggyslasher مثير للاهتمام على الرغم من أنك إذا فكرت في الأمر بدلاً من ذلك مثل طريقة "do it the tmux".

هذا شيء كنت أفكر فيه لفترة طويلة. يحتوي Tmux على tabs ويمكن تقسيم كل tab إلى أي عدد تريده من panes . في المقابل ، يمتلك المحررون panes وبعد ذلك يمكن أن يحصل كل pane على tabs .

أفضل طريقة tmux لأنها مثل "تخطيط المحطات هذا مرتبط ، ثم ننتقل إلى علامة تبويب أخرى للأجهزة الطرفية ذات الصلة"

لشيء مثل تطوير التفاعل / الزاوي ، يمكنني أن أرى أن هذا مفيد إذا كان لديك جزء "JS / HTML / CSS / Test" مفتوح لكل مكون ، و "علامة تبويب" لكل مكون تعمل عليه.

سأكون مهتمًا بمعرفة ما إذا كان من الممكن القيام بشيء من هذا القبيل في مكون إضافي. إن لعبة Origami for Sublime قريبة ، لكنها لا تزال "أجزاء مليئة بعلامات التبويب" وليس "علامات تبويب مليئة بالأجزاء".

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

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

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

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

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

إذا لم يكن هذا منطقيًا ، أو إذا كنت أذكر ما هو واضح ، فأخبرني بذلك.

@ نيك والت عندما تقول:

توفير خيار للمستخدم لإرفاق وحدات التحكم بمحرر أو مجموعة من المحررين.

هل تقترح قدرة الجهاز الطرفي على ربط مثيلات shell بملفات مفتوحة معينة؟

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

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

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

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

منذ أكثر من عام ، قال @ bgashler1 :

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

لذلك ربما يكون من الأفضل في هذا الوقت التفكير في علامات التبويب التي تختلف بشكل مرئي عن علامات تبويب المحرر ، مما يشير إلى أنها _ غير قابلة للتبديل مع علامات تبويب المحرر ، لتجنب أي ارتباك؟

أوافق ، تعد علامات التبويب حلاً جيدًا لاختيار وحدات التحكم المختلفة.

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

من المرجح أن تكون واجهة المستخدم هي أنه عند تحديد محرر (ملف) جديد في الجزء العلوي من التطبيق ، تتغير علامة (علامات) تبويب وحدة التحكم في الجزء السفلي مع تغير المحرر. انها بسيطة جدا وبديهية.

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

  • موقع الدليل
  • مشروع
  • نوع الملف (ربما عندما تكون الملفات في نفس الموقع)
  • مجموعة المحرر (من تحديد المستخدم)
  • بعض التجريد الآخر

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

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

لتعزيز ارتباط علامة تبويب وحدة التحكم بالمحرر ، سيتم تسمية الجزء الذي يحتوي على علامات تبويب وحدة التحكم بوضوح باسم المحرر.

ويمكن أن تعرض كل علامة تبويب تلقائيًا نوع وحدة التحكم التي تم تحميلها ، مثل Git و Node و CMD و Powershell ... بدلاً من عرض Terminal 1 و Terminal 2 وما إلى ذلك (كما هو موضح بواسطة

سيسمح ذلك للمستخدم بتحديد وحدة التحكم التي يريدها مباشرةً دون البحث عبر علامات التبويب بحثًا عن موجه git أو powerhell.

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

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

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

قد يرغب البعض في المزج بين الاثنين ، اعتمادًا على ما يفعلونه ووحدة التحكم التي يستخدمونها. هذا مجرد تحسين لمشكلة UI / UX التي يجب على المبدعين حلها. كما هو الحال مع أي تحدي UI / UX.

ستكون حالة استخدام المحرر السياقي / وحدة التحكم UX هي:

  • لا يوجد سياق (لا توجد وحدات تحكم مرتبطة بأي محرر معين)
  • سياق مختلط (بعض وحدات التحكم مرتبطة ، وبعضها لا)
  • كل السياق (جميع وحدات التحكم المرتبطة بمحرر)

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

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

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

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

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

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

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

سيكون إنشاء محرك وحدة تحكم في VScode ليبني عليه الجميع تجربة ممتعة.

إليك مقطع يوضح كيفية عمل Cloud9 IDE :

ezgif-1-a2ab27787f

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

plmrry هذا رائع! شيء في هذا الاتجاه سيكون لطيفًا حقًا.

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

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

هل يمكن للأوامر الطرفية أن تستهدف فقط الأمر الذي تم التركيز عليه مؤخرًا؟ بنفس الطريقة التي يستهدف بها cmd + shift + t علامة التبويب التي تم إغلاقها مؤخرًا

btoo ربما هذا ما سيفعله في مثل هذا العالم. هذا تغيير جذري للغاية في كيفية عمل VS Code.

لقد جئت من PHPstorm ونقص علامات التبويب الطرفية أمر محبط حقًا ، فجميع منتجات Brainstorm بها علامات تبويب طرفية ، إنها ميزة مفيدة للغاية.

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

+1
تعد علامات التبويب في الجهاز أكثر ملاءمة لتجربة المستخدم من التحديد ولا تشغل مساحة كبيرة

+1

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

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

تحديث صغير على هذا: أنا مستهلك حاليًا لجعل الوصول إلى المحطة الطرفية (https://github.com/Microsoft/vscode/issues/8339) ، بعد ذلك من المحتمل أن تكون القطعة الرئيسية التالية التي سأعمل عليها تقسيم المحطة الطرفية (https://github.com/Microsoft/vscode/issues/7504) الذي تم استبعاده من هذه المشكلة (ومن المحتمل أن العديد من الأشخاص الذين يؤيدون هذا الأمر يريدونه حقًا). هذا في خارطة الطريق https://github.com/Microsoft/vscode/wiki/Roadmap#terminal

AnthonyMichaelc ليس هناك قلق من الأداء مع إظهار متعددة ، التحسينات الأخيرة .

(التقسيم) هو على الأرجح ما يريده كثير من الأشخاص الذين يؤيدون هذا حقًا

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

... لقد قرأت للتو كل هؤلاء ، ولا أصدق أنني فاتني هذه الفكرة:

لماذا لا تضيف علامات تبويب إضافية إلى شريط علامات التبويب الموجود ، عند فتح محطات جديدة؟
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... أيضًا ، وحدة التحكم في تصحيح الأخطاء ليست مفيدة بشكل رهيب إذا لم تكن تستخدم مصحح الأخطاء بالفعل ..

(وهو على الأرجح ما يريده كثير من الأشخاص الذين يؤيدون هذا حقًا)

سوف ألصق هذا فقط .... (أول مشاركة في هذا الموضوع)

بالإضافة إلى تعليق ericblade ، من فضلك دعني أرى لوحتين على الأقل (مشاكل ، مخرجات ، وحدات تحكم ، محطات طرفية ، ...) في نفس الوقت!
على سبيل المثال ، أثناء تصحيح أخطاء الخادم ، أود ملاحظة إخراج بعض الخدمات الأخرى أو قيام مراقب الملفات ببناء عميلي دون تبديل طرق العرض طوال الوقت ، ولا حتى عبر اختصارات لوحة المفاتيح.
يسعدني أن أرحب بالمطاريف المنقسمة (أيضًا على Windows ؛) كبداية ، لكن علامات التبويب المرنة التي يمكن وضعها في اللوحة اليسرى / الوسطى / اليمنى من شأنها تحسين "سطح المراقبة" لـ vscode إلى حد كبير دون تشويش واجهة المستخدم.

PixelT الصورة الأولى في

mikemaccana يرجى قراءة منشوري مرة أخرى ، لأنني أرى أنك لا تفهمها + لم أزل أي شيء:]

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

هل يمكن أن يكون لدينا خيار وجود علامات تبويب مع إيقاف تشغيلها افتراضيًا؟

وقد سقط معاينة تقسيم في المطلعين ، تحقق من https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609 عن التحديث الكامل.

kapture 2018-02-14 at 9 12 17

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

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

ملاحظة جانبية: لقد لاحظت فقط من الاستخدام لبضع دقائق إذا حاولت التبديل ذهابًا وإيابًا opt / alt + cmd / ctrl بسرعة ، بدا أن التركيز كان متأخرًا قليلاً. (قد أكون أنا فقط)

تضمين التغريدة

أنا متأكد من أن شخصًا ما سيشتكي لماذا لا يمكنني وضع 15 محطة طرفية ولكن بالنسبة لي ، سيكون هذا رائعًا.

الخطة في الواقع هي السماح لأكبر عدد تريده ، لقد قمت بحل مشكلة n = 2 حتى الآن.

تخطيط الشبكة

نحن نناقش هذا الأمر الآن بنشاط ، بل إنه حصل على مكان في خطة التكرار لشهر فبراير https://github.com/Microsoft/vscode/issues/43361

ملاحظة جانبية: لقد لاحظت فقط من الاستخدام لبضع دقائق إذا حاولت التبديل ذهابًا وإيابًا opt / alt + cmd / ctrl بسرعة ، بدا أن التركيز كان متأخرًا قليلاً. (قد أكون أنا فقط)

لم أر هذا بعد ، لكنني سأظل أبحث عن البطء.

تضمين التغريدة

إذا كنت أعمل على شيء مثل مكدس متوسط ​​، فيمكنني الحصول على محطة مزدوجة واحدة فقط لـ nodemon و mongos وما إلى ذلك ، ثم افتح زوجًا طرفيًا آخر لتشغيل خدمة ng وتوليد الأوامر.

إن وجود محطات ومحرر متعدد الأطراف في نفس الوقت أمر مريح للغاية. في حياتي اليومية ، لدي أول محطة لخادم التطوير ، والثانية بالنسبة لاختبارات الوحدة ، وأحيانًا الثالثة في git.

هناك طريقة مخترقة لتحقيق ذلك في cmder الطرفية لنظام التشغيل Windows عن طريق فتح VSC كواحدة من علامة تبويب المحطة الطرفية (هنا) لا يمكنني الانتظار للحصول على حل أصلي لـ Visual Studio Code ، لأن هناك بعض المشاكل مع الاختصارات أثناء استخدام VSC و Cmder في من هنا.

Visual Studio Code + cmder multiple tabs

Tyriar كما أستطيع أن أرى ، هذا الموضوع يدور حول علامات التبويب في المحطة ، لا تقسيم ...؟

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

لا يمكنني أن أتفق معك - هذا الموضوع يراقب ويناقش الأشخاص الذين يريدون علامات تبويب في الجهاز الطرفي ، بالنسبة لتقسيم المحطة ، هناك موضوع آخر: https://github.com/Microsoft/vscode/issues/7504 الذي أنشأته :)

علامات التبويب الطرفية والتقسيم هي معايير اليوم في كل بيئة تطوير متكاملة حديثة تقريبًا.

تم التبديل إلى إصدار Insider لاختبار ذلك ، ويعمل بشكل مذهل ، شكرًا

لا يزال لا شيء يحدث بشأن علامات التبويب في المحطة الطرفية ... 😕

PixelT هل جربت الإصدار الداخلي الذي يحتوي على المحطة المزدوجة؟ مما قالوا إنهم يخططون لجعله حتى تتمكن من فتح العديد من المحطات الطرفية في هذا التصميم كما تريد ولكني أعتقد أن الإصدار الداخلي يسمح حاليًا بـ 2 باستخدام الأمر: cmd / ctrl + d أعتقد

Morkowski أرى ما فعلته ، نعم لديّ نظام تشغيل windows وجهاز كمبيوتر محمول يعمل بنظام التشغيل OSX ، لذا عندما أكون على كمبيوتر يعمل بنظام windows ، أستخدم cmder مثل هذا ، عندما أستخدم iterm على كمبيوتر osx وأنشئ ما لا يقل عن 2 إلى 3 داخل شبكة التخطيط و 4 عند العمل في تطبيق متوسط ​​المكدس.

مرحبًا Tyriar بت من التعليقات - عند تغيير حجم وحدة التحكم باستخدام الأزرار Maximize Panel Size أو Restore Panel Size (أو اختصار لوحة المفاتيح) ، يتم نسيان عرض أجزاء وحدة التحكم ، وعرض كل جزء هو إعادة التعيين إلى مبلغ مساوٍ.

عند تغيير حجم وحدة التحكم لأعلى / لأسفل باستخدام الماوس ، يتم تذكر العروض.

وبالمثل ، يتم تجاهل العروض عند إخفاء أو إظهار شريط الجانب الأيسر.

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

أتمنى أن يساعدك هذا!

jamesjryan ، كانت هناك مشكلة تم إصلاحها في أحدث معلومات داخلية لأول 2 https://github.com/Microsoft/vscode/issues/45074

وبالمثل ، يتم تجاهل العروض عند إخفاء أو إظهار شريط الجانب الأيسر.

لا يمكنني إعادة إصدار أحدث ، يرجى إنشاء مشكلة إذا كنت تراها.

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

نعم هذا كما هو مصمم 🙂

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

7504

تحديث Tyriar - يعمل كما هو موضح ، شكرًا!

KillyMXI إنه تقدم نحو الهدف النهائي ، وتنفيذ مفيد للغاية حتى في شكله الحالي.

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

screen shot 2018-03-06 at 12 22 50 pm

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

أعتقد أن اللعبة النهائية تمنح المستخدم المرونة لوضع المحطات في أي مكان يريده ، ولكن ربما يكون هذا حلًا مؤقتًا جيدًا؟

jamesjryan لا يمكنني رؤية حل Tyriar باعتباره تقدمًا نحو علامات التبويب. يبدو متعامدًا تمامًا بالنسبة لي.

هناك الكثير من الأشياء المفيدة حولها ، لكن لديهم أماكن مناسبة. المكان المناسب لمحطة الانقسام هو تذكرة مختلفة.

أخيرا نعود إلى علامات التبويب.

تم اقتراح شيء مماثل أعلاه ، في الواقع: https://github.com/Microsoft/vscode/issues/10546#issuecomment -359632932
هذا هو الشيء الأكثر وضوحًا عند استبدال القائمة المنسدلة بقائمة المحطات.

كنت سأحاول

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

أفضل تجنب وضع كلمة "Terminal" في كل علامة تبويب. سيكون واضحا بما فيه الكفاية ما هو عليه.
أو ربما تستخدم كلمة "Terminals:" كنوع من الفاصل المرئي.

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

إذن هذه هي النتيجة النهائية التي أتمنى الحصول عليها هنا:
68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f6a736d656368616d2f61746f6d2d7465726d696e616c2d7461622f6d61737465722f64656d6f2e676966

مأخوذة من https://atom.io/packages/terminal-tab

إنه بسيط وسهل الفهم ويعطي المرونة للمستخدم النهائي فيما يتعلق بكيفية تقسيم / هيكل IDE الخاص بهم.

انا مرتبك. يمكننا بالفعل أن يكون لدينا محطة طرفية واحدة في الجزء السفلي أو الأيمن أو الأيسر أو ملء الشاشة.

يمكننا بالفعل أن يكون لدينا محطة طرفية واحدة في الجزء السفلي أو الأيمن أو الأيسر أو ملء الشاشة.

نحن نفعل؟ كيف أقوم بإنشاء Terminal على الجانب الأيسر؟ في الوقت الحالي ، يمكنني رؤية الجانب السفلي أو الجانب الأيمن فقط.

لا يمكنك ترك اليسار ولكن لا يزال ، أنا في حيرة من أمري بهذه الصورة المتحركة. هههه

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

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

ربما أسيء فهم هذا القلق ، لكن مصممي UX قلقون بشكل أساسي من الخلط بين أنواع مختلفة من علامات التبويب.

سأخفي شريط علامات التبويب افتراضيًا وتظهر علامة تبويب واحدة. حافظ على الشيء المنسدل.

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

هل فاتني شيء؟

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

هذا ما تحاول الصورة المتحركة "المربكة" أعلاه إظهاره.

نعم ، آسف إذا جعلته الصورة المتحركة أكثر إرباكًا ولكن هذا هو الأساس الذي كنت أحاول الوصول إليه.

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

كنوع من الحل البديل ، قمت بإعداد اختصارات لوحة المفاتيح التالية:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

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

vedmant يمكنك تحسين ذلك للعمل فقط عندما تكون المحطة مركزة إذا كان ذلك مفضلًا أيضًا:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

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

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

لا يبدو أن Tyriar workbench.action.terminal.focusPrevious يعمل

لقد جربت أيضًا workbench.action.terminal.focusPreviousPane نظرًا لأنها طريقة استخدام Defaults Kebindings ، لكنها لا تعمل ( workbench.action.terminal.focuNextPane لا تعمل أيضًا)

باختصار: فقط workbench.action.terminal.focusNext يعمل

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

إصدارات VSCode

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

نظام التشغيل: lubuntu 18.04

تم اختباره بدون ملحقات

تعديل

شكرًا Tyriar ، لقد كتبت cmd بدلاً من ctrl أعلاه

caub ، يجب عليك إنشاء مشكلة جديدة إذا كنت تريد المساعدة (لقد عملت دائمًا بشكل جيد بالنسبة لي على Ubuntu 18).

أدركت مؤخرًا مشكلة في وجود الجهاز في مكانه: يجعل من المستحيل رؤية علامة تبويب المشاكل في نفس الوقت.

أعتقد أن لديك مساحة عمل بها مشاريع متعددة. ما يمكنك القيام به ، هو أن يكون لديك محطة واحدة لكل مشروع ، وأن يكون لديك امتداد يركز على المحطة المقابلة بناءً على الملف المركّز في المحرر (وعلى المشروع الذي تنتمي إليه)

إنه لا يحل مشكلتك الخاصة ، ولكنه يجعل من السهل التبديل وملاحظة المشكلات

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

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

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

mrmckeb موافق . لست متأكدًا من كيفية تعاملهم مع كل من علامات التبويب والانقسامات ، لكن هذا ممكن. Tmux يفعل ذلك.

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

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

ماذا

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

لا يلزم أن تكون علامات التبويب الطرفية قابلة للتبديل مع أطراف التوصيل في اللوحة للبدء ؛ يمكن إنشاؤها ككيانات منفصلة تمامًا في البداية لجمع التعليقات.

لماذا ا

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

  • شاهد واستخدم أكثر من محطتين في وقت واحد. يتم القيام به بسهولة عن طريق ترتيب ثلاثة أو أكثر من المحطات الطرفية ولكني أحب ذلك على شبكة المحرر.
  • استخدم VSCode كمحاكي طرفي الوحيد ، عن طريق فتح نافذة VSCode مع علامة تبويب طرفية فقط.
  • لديك العديد من المحطات المفتوحة في نفس الوقت ، لكنني لا أريد النظر إليها الآن.

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

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

  1. اسمح بوضع اللوحة بشكل أكثر مرونة https://github.com/Microsoft/vscode/issues/57029 ، https://github.com/Microsoft/vscode/issues/50984 ، https://github.com/Microsoft/ vscode / القضايا / 37877 ، https://github.com/Microsoft/vscode/issues/10121
  2. تحقق من السماح للأجهزة الطرفية الفردية بـ "الانفصال" عن اللوحة ووضعها في شبكة المحرر كما تتحدث عنه (نوع من التتبع في هذه المشكلة). هذا يحتاج إلى القليل من العمل لمعرفة التأثيرات على UX والأوامر و keybindings وواجهة برمجة التطبيقات.

أيضًا ، sagebind ، لست متأكدًا مما إذا كنت قد سمعت من قبل عن ConEmu ، لكنه يفعل ما وصفته.

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

أعتقد أن هذا الامتداد يوضح كيفية عمل علامات التبويب بطريقة نظيفة.

https://marketplace.visualstudio.com/items؟itemName=Tyriar.terminal-tabs

PauloDanielCarneiro تم إنشاء هذا الامتداد بالفعل بواسطة أحد كبار مطوري VSCode نفسه (Tyriar)

أعلم أن هذه المشكلة قديمة ، لكن هذا سيكون رائعًا

هذه بالضبط الميزة المفقودة التي تمنع جميع مسؤولي النظام من القفز تمامًا من ISE إلى VSCode.

بصفتي مسؤولاً مسؤولاً ، أقضي معظم وقتي في العمل في وقت واحد على عدة أجهزة كمبيوتر.

أقوم بالاتصال بجهاز كمبيوتر بعيد باستخدام CTRL + SHIFT + R.
يؤدي هذا إلى فتح علامة تبويب طرفية جديدة تحمل اسم الكمبيوتر الذي تتصل به.
وترتبط كل علامة تبويب طرفية بواحدة أو عدة علامات تبويب للبرنامج النصي أدناه.
أقوم بالتبديل من علامات تبويب البرنامج النصي إلى علامة تبويب المحطة الطرفية والعكس بالعكس باستخدام CTRL + R.

هذا سهل ومفيد وقوي في نفس الوقت ...

tabs

هل هذه الميزة قيد النظر؟

ليس بديلاً ، ولكن يمكنك استخدام cmd-\ لتقسيم جهازك الطرفي

شكرا @ Hum4n01d هذا أفضل ، لم أكن أعرف عن ذلك.

@ Hum4n01d في حالتي ، يمكنني تقسيم الجهاز باستخدام Ctrl+] ، أو فقط النقر فوق الرمز لتقسيم الجهاز في الزاوية العلوية اليمنى من نافذة الجهاز ، بجوار الخيار Kill Terminal .

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

فقط في الحالة التي أحتاج فيها إلى عدة محطات طرفية ، قد لا يكون هذا حلاً ، على الرغم من أن علامات التبويب أيضًا قد لا تكون (في حد ذاتها) ، بدلاً من ذلك ستحتاج إلى شيء مثل علامات التبويب + النوافذ العائمة (https://github.com/Microsoft/vscode / قضايا / 10121).

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

قد تكون علامات التبويب في منطقة المحطة رائعة ، ولكن لماذا تستثمر في القيام بذلك بينما يمكن قضاء الوقت في السماح لعلامات تبويب الشفرة بالتفاف مثيلاتها؟

مرحبا. ذهبت للبحث عن مشكلة أواجهها وانتهى بي الأمر هنا.

الشيء الوحيد الذي أريد القيام به هو استخدام Terminal كعلامة تبويب محرر عادي

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

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

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

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

Zyrsha - في هذه الحالة ، لماذا تستخدم VS Code؟ يبدو أنك ستحصل على قيمة أكبر من الاستخدام المباشر للمحطة الفعلية التي تأتي مع نظام التشغيل الخاص بك ، مع علامات تبويب متعددة. سؤال صادق / قارئ مرتبك جدا.

BTW vscode هو IDE الأول والوحيد حيث أستخدم المحطة الطرفية فيه. على جهاز الكمبيوتر المحمول مقاس 13 بوصة ، يعمل بشكل جيد بالنسبة لي. بالنسبة إلى IDEs الأخرى مثل eclipse أو webstorm ، يسعدني جدًا استخدام برنامج Awesome WM للتبديل السريع وطلب النوافذ.

أعتقد أن فكرة استخدام المحطة الطرفية (أو أي "نافذة" أخرى) كعلامة تبويب عادية جيدة وتعمل في الكسوف. لكن المحطة لديها سير عمل مختلف قليلاً ، على الأقل بالنسبة لي. أحتاج إلى إمكانية التبديل السريع إلى المحطة الطرفية "الصحيحة". مثل الآخرين ، أستخدم علامات تبويب المحطة الطرفية لذلك:
image
وهو ، للأسف ، ليس مثاليًا بسبب مشكلات مثل هذه. علاوة على ذلك ، لا أفهم سبب عدم احتواء vsc على محطة طرفية مدمجة.

@ shane-smith

الجهاز الفعلي الذي يأتي مع نظام التشغيل الخاص بك ، مع علامات تبويب متعددة.

حسنًا ، لا يحتوي تطبيق Console الذي يأتي مع Windows على علامة تبويب تدعم AFAIK. هذا خارج. ولينكس لا "يأتي مع" محاكي طرفي في حد ذاته (ربما توزيعة) ، عليك اختيار واحد تريده. في هذه الحالة ، يبدو أن الشيء الذي يعجبZyrsha هو VS Code ، إذا كان من الممكن تحسينه قليلاً.

تضمين التغريدة

في هذه الحالة ، يبدو أن الشيء الذي يعجبZyrsha هو VS Code ، إذا كان من الممكن تحسينه قليلاً.

أوه ، أوافق - الجهاز في VS Code رائع. وأنا أعلق على هذه المسألة لأنني أوافق على أن لديها مجال للتحسين.

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

مرحبا.

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

لا ، إنهم يريدون فقط أن يكون لديهم علامة تبويب طرفية مثل علامات تبويب المحرر ، بالضبط ما لدينا في Cloud9 و Atom وبعض المحررين الآخرين (حتى Vim و Emacs). بالنسبة للأشخاص الذين يستخدمون نظام التشغيل Mac أو Linux ، من الطبيعي أن يكون لديهم محررين في أعلى النافذة وبعض علامات تبويب المحطة الطرفية في الأسفل.

حتى Theia-IDE يمكن أن تحتوي على عدة علامات تبويب طرفية وهي تعتمد على بعض أجزاء VSCode.

ألق نظرة على لقطات الشاشة هذه وستفهم:

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

حسنًا ، دعنا نتجاهل السبب للحظة ونركز على الكيفية:

كيف سيتم تنفيذ هذا؟ هل هناك سبب معماري لوجود المحطات الطرفية في موقعها الحالي؟

هل سيكون من الممكن بطريقة فعالة أن يكون هناك مكون إضافي يوفر محطات طرفية في علامات تبويب؟

      Ok, let's ignore the why for a moment and focus on the how:

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

على الجانب المعماري:

  • يحتوي VSCode على العديد من علامات تبويب البرمجة النصية المرتبطة بوحدة تحكم واحدة (وحدة تحكم PowerShell متكاملة) وهو أمر جيد جدًا لاختبار العديد من البرامج النصية على جهاز واحد . ومع ذلك ، حتى عند إضافة المزيد من المحطات الطرفية ، تظل جميع علامات تبويب البرمجة النصية مرتبطة بوحدة تحكم PowerShell المدمجة نفسها.
    في البداية ، تم كتابة VSCode بواسطة مطورين للمطورين.

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

Fortunatelly ، طريقة ISE (علامات تبويب البرمجة المرتبطة بعلامات تبويب وحدة التحكم) تعمل للمطورين أيضًا.
لكن طريقة VSCode الحالية (علامات تبويب وحدة التحكم المرتبطة بعلامة تبويب برمجة نصية "واحدة") لا تناسب SysAdmins.
إذا كنت لا تريد أو لا يمكنك عكس الطريق (من البرامج النصية المرتبطة بوحدات التحكم إلى وحدات التحكم المرتبطة بالنصوص البرمجية) على الأقل يجب أن نكون قادرين على اختيار علامة تبويب وحدة التحكم التي نريد ربط كل علامة تبويب برمجة نصية ...

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

أيضًا ، في حين أن علامات التبويب الطرفية _ تفعل _ تحل مشكلة الرغبة في أكثر من محطة طرفية نشطة ، من وجهة نظر UX ، سيكون من الأفضل أن يكون لديك محطات طرفية في نفس علامات التبويب المستخدمة للملفات. هذا يضمن أن لديك رابطان قياسيان للتبديل بين علامات التبويب ، بدلاً من اثنين قياسيين ، واثنان لعلامات تبويب المحطة الطرفية (لا يشمل ذلك روابط المفاتيح الرقمية للتبديل إلى علامة تبويب طرفية معينة). سيكون سير العمل لتقسيم المحرر باستخدام علامات التبويب هذه ، أو نقل علامات التبويب إلى نوافذ VS Code الأخرى ، أو أي شيء آخر يمكنك القيام به باستخدام علامات التبويب ، هو نفسه ، وسيؤدي إلى إنشاء UX قياسي. كما هو الحال الآن ، لديك مساران مختلفان لسير عمل UX ، ولا تربح كثيرًا من وجود الاثنين.

أتفهم سبب عدم تنفيذ ذلك حتى هذه النقطة ، أو لماذا لدينا علامات تبويب طرفية كحل بديل ، لكن المحطات الطرفية في علامات تبويب المحرر / المخازن المؤقتة / كل ما يتم إجراؤه في جميع المجالات في Emacs و Atom وما شابه ، كمعيار تجربة UX ، التي أحب أن أراها أيضًا في VS Code.

الآن بعد أن تم إهمال Nuclide ، أود التبديل إلى VS Code ، لكنني أحب حقًا أن أكون قادرًا على قراءة كل مخرجات الإنشاء على الجهاز - وهو أمر صعب للغاية باستخدام VS Code. لماذا يجب أن يتم إجبار الجهاز على مكان معين ، ولا يتم التعامل معه مثل كل علامة تبويب / نافذة أخرى؟

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

كيف سيتم تنفيذ هذا؟

بالنسبة لنظام Linux ، يمكننا تنفيذه كحالة خاصة لمنهج أكثر عمومية: تشغيل أوامر محددة من قبل المستخدم وتزويدها بمعرف نافذة X لعلامة التبويب الجديدة. يمكننا بعد ذلك تشغيل xterm … -into $VSCODE_TAB … للمحطة ، لكن يمكننا أيضًا دمج أشياء أخرى بسهولة بالغة. سيكون من الجيد أيضًا إذا كان هناك أمر CLI للبحث عن مثيل VSCode من خلال دليل المشروع (افتراضيًا إلى دليل العمل الخاص بمكان تشغيل الأمر) ، وافتح علامة تبويب في تلك الحالة ، واطبع X win id على stdoutو VSCode $DISPLAY إذا كان مختلفًا لذلك يمكن لأي أدوات خارجية الانضمام إلى واجهة المستخدم الرسومية الخاصة بـ VSCode.

تحرير 2: سأفتح تذكرة جديدة لهذه الفكرة لأنها لا تتعلق حقًا بالمحطات.

لا !!! علامة التبويب تجعل واجهة المستخدم تبدو سيئة ....

تضمين التغريدة

لا !!! علامة التبويب تجعل واجهة المستخدم تبدو سيئة ....

أنا متفائل جدًا أنه سيكون من السهل إلغاء تنشيطها و / أو إخفاؤها.

ما عليك سوى تحويل القائمة المنسدلة إلى أزرار وتصميمها مثل علامات تبويب المحرر الرئيسي.

فقط لأكون واضحًا ، أود أن تكون علامات التبويب قابلة للتبديل مع جميع علامات التبويب الأخرى (على سبيل المثال ، علامات تبويب التعليمات البرمجية المصدر). تمامًا كما هو الحال في Atom.

فقط لأكون واضحًا ، سأقبل حلول floydnoel نظرًا لأن طلب OPs لم يلاحظه أحد منذ عام 2016

kitsirota لقد تمت ملاحظته ، وهو Tyriar مزيد من المعلومات حول ذلك.

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

في انتظار هذا والنوافذ العائمة من اليوم الأول بدأت باستخدام VSCode. أنا أستخدم حاليًا ConEmu. إنه ليس في متناول اليد المحطة الحالية المرفقة والمنسدلة.

مجرد ملاحظة (بينما يجب بالتأكيد إضافة علامات التبويب إلى vscode) إذا كنت لا تزال تستخدم ConEmu ، فقد ترغب في تجربة Windows Terminal.

ما زلت انتظر هذا :)

أود فقط رؤية "الإخراج" و "وحدة التحكم في التصحيح" في نفس الوقت.

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

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

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

jaxspadesTyriar هي 1754: +1: 187: القلب: لا يكفي؟ و 34: صاروخ :؟ كم يجب أن يكون؟

هذا لا يزال مفتوحا ؟!

هل سيساعد هذا التمويل الجماعي؟ أين أضع أموالي؟

Bessonov أريد علامات تبويب المحطة الطرفية ولكني لست في Microsoft لذلك ليس لدي رأي. لكنني أريدهم كمحرر ، ليس في تلك النافذة الصغيرة في أسفل الشاشة. لذا فإن الإصدار 1.43 قد تم شحنه للتو مع Search Editors ، لذلك آمل أن تتبع Terminals قريبًا. Tyriar ، هل تساعدنا محررات البحث في الاقتراب من علامات تبويب المحطة الطرفية / المحررين؟

تحرير: إضافة رابط إلى قضية محرري البحث.

23931

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

  • ابحث في اللوحة
  • ابحث في المحرر
  • جميع عروض اللوحة والمنظر قابلة للتبديل

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

لكنني أريدهم كمحرر ، ليس في تلك النافذة الصغيرة في أسفل الشاشة.

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

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

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

حاليًا ، إذا كنت أرغب في إخراج تشغيل المحررين في محطة أخرى ، يجب أن أفتح وحدة تحكم VS Code جديدة.

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

Tyriar ،
إلى جانب ملاحظاتك ، أود أيضًا أن أتمكن من رؤية "المشكلات" ونافذة "طرفية" في نفس الوقت جنبًا إلى جنب. آمل أن يكون ذلك ممكنًا أيضًا.
شكر

@ fullenw1 فكرة مثيرة للاهتمام لم أسمع بها بعد ، شكرا!

ggedde نحن نناقش بنشاط كيف سيعمل هذا في اجتماعات UX.

مع حل المشكلة رقم 10121 ، ستكون هذه ميزة جيدة أكثر من أي وقت مضى.

تحتاج اللوحات الطرفية إلى عنوان من نوع ما ..

76528795-bdeb6e00-6447-11ea-9861-65f444e5d867

من المستحيل معرفة أي لوحة هي المسار عندما يكون لديك عدة مشاهدين

IceSentry لدي مشكلة لكن Tyriar قال إنها نسخة مكررة من هذه. افترضت أنه مرتبط لأن Tyriar أغلقت لي لصالح هذا .. لا لم أقرأ 6 سنوات من الحوار :)

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

الشيء الجميل الآخر حول Terminals في Cloud9 هو أنها تعلق على مثيلات (IIRC) tmux بدلاً من محطات مباشرة. سمح ذلك للواجهة الأمامية بإعادة التخصيص (أي الإغلاق) دون فقدان العمليات الطرفية ، والإرفاق بسلاسة مع عميل جديد (وهي ميزة ستكون مفيدة جدًا لمستخدمي Cloud VS Code) ، وحتى مشاركة مثيلات العميل الطرفية مع الآخرين (برنامج Hypervisor) -level) المستخدمين.

هناك امتدادات للقيام بذلك لمحطة VS Code المدمجة ، ولكن إذا كنت تبحث عن تجريد للأجهزة الطرفية ، فسيكون من الرائع تجميعها في abduco .

علامات تبويب المحطة الطرفية القابلة للتبديل في واجهة المستخدم بعلامات تبويب المحرر

هذا مجرد رائع.

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

كمرجع ، يتم بالفعل التعامل مع صفحات معلومات الامتداد و Settings UI و Keyboard Shorcuts ، وربما أشياء أخرى بهذه الطريقة ، مثل علامات تبويب محرر عادية برمز مخصص.

سيسمح ذلك للأشخاص بتقسيم وترتيب المحطات الطرفية كما يحلو لهم ، باستخدام الميزات الحالية لتقسيم علامات تبويب المحرر وترتيبها.

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

image

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

ومع ذلك ، هناك فائدة لجعله مجرد "علامة تبويب" للمحرر ، لأن علامة تبويب المحرر يمكن أن تحتوي على معالجات Serialize / Deserialize.
وبالتالي من الممكن إعطاء Terminal سلوك الحفظ والاستعادة. (مثل ، احفظ معرف جلسة tmux وأعد التوصيل عند الاستعادة)

POC: https://github.com/mmis1000/Vscode-terminal-tab

@ mmis1000 من الممكن بالتأكيد ستفقد جميع عمليات التكامل والأوامر والميزات مثل التعامل مع الارتباط والوصول إلى واجهة برمجة التطبيقات (api) وستكون بمثابة شيء منفصل بشكل عام.

يتم تعقب ميزة الحفظ والاستعادة في https://github.com/microsoft/vscode/issues/20013

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

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

POC: https://github.com/mmis1000/Vscode-terminal-tab

مرحبًا @ mmis1000 ، هل يمكنك إضافة بعض إرشادات التثبيت ، سيكون ذلك رائعًا. هل حقا ترغب في الحصول على هذا.

@ mmis1000 إنه window.onDidWriteTerminalData وهذا هو سبب تعليقه في المقترح. في حين أن هذا النوع من الامتداد قد يكون مفيدًا كحل مؤقت ، إلا أنني أشعر بالقلق بشأن الذيل الطويل المحتمل للمستخدمين بمجرد أن نجعل المحطات تعمل داخل منطقة المحرر. هناك مشكلة أخرى قد ينتهي بها الأمر وهي الاعتماد على node-pty التي يتم شحنها كجزء من vscode ، هذه ليست واجهة برمجة تطبيقات عامة مخصصة للاستهلاك ومن المحتمل أن تكسر امتدادك في المستقبل.

Tyriar كمستخدم cloud9 (وما زلت مستخدم cloud9 الآن).

من المفيد نوعًا ما استخدام أي منطقة شاشة كمحطة طرفية مع استمرار الجلسة المدعومة بواسطة tmux.

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

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

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

(أيضًا لأن cloud9 فعلت ذلك منذ سنوات ، لذلك لا أشعر حقًا أن هذه مشكلة فنية)

لا تبدو تجربة vscode الطرفية المقدمة حقًا أحدث منتج عام بالنسبة لي لأكون صادقًا.

@ mmis1000 هل يمكنك إضافة بعض إرشادات التثبيت من فضلك؟

يحتوي https://github.com/mmis1000/Vscode-terminal-tab repo على أداة تعقب المشكلات الخاصة به. أي شخص يشعر بالحاجة إلى السؤال عن هذا المشروع ، من فضلك اسأل هناك.

ezgif-2-8012d10efb96

لعرض توضيحي حول الجهاز الذي أتوقع رؤيته على بيئة تطوير متكاملة / مستعرض بعيد.
أتوقع أن تقوم فقط باستعادة موضع علامة التبويب / الجلسة النهائية حيث أغلقتها أمس.
بدلاً من It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD .

يبدو أن xgdgsc محتمل ولكنه ليس كذلك.

ما أتوقعه هو أن المحطة الثابتة متاحة عالميًا حتى على مثيل vscode المحلي. (على الأقل إلى النقطة التي يفعلها iterm2)
لماذا يجب أن تقتصر هذه الوظيفة المفيدة على الاتصال عن بُعد؟

ولم أواصل اتصال ssh أيضًا ، لقد قمت فقط بتوصيل بعض معدد الإرسال الطرفي وتشغيل الأشياء هناك.

@ mmis1000 مرة أخرى يتم تعقبها في https://github.com/microsoft/vscode/issues/20013 ، انظر هناك لمعرفة الأحدث. حاول الاستمرار في الموضوع حيث يوجد الكثير من الأشخاص الذين يتم إعلامهم عند التعليق على هذه المشكلة.

هل هناك أي فرصة للحصول على هذا في التكرارات التالية؟

يعد فتح Terminal كعلامة تبويب صفحة محرر عادية فكرة رائعة بالنسبة لي ، وأنا بحاجة إلى ذلك كثيرًا.

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