Vscode: علامات التبويب المناسبة للملفات المفتوحة

تم إنشاؤها على ١٩ نوفمبر ٢٠١٥  ·  411تعليقات  ·  مصدر: microsoft/vscode

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

feature-request workbench-tabs

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

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

التصميم المرئي

أولاً ، توضح هذه الصورة كيف نعتقد أن علامات التبويب قد تبدو في VS Code:
image2

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

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

سيؤدي التمرير فوق علامة التبويب إلى إظهار تلميح أداة بالمسار الكامل للملف في علامة التبويب.

معاينة علامات التبويب

للتمييز بوضوح بين علامات تبويب المعاينة وعلامات التبويب المفتوحة ، نقوم بوضع العنوان المائل في علامة التبويب كما في الإطار السلكي التالي.
image1

ناقشنا إجراءات ترقية علامة تبويب المعاينة إلى علامة تبويب مفتوحة بالكامل:

  • تحرير المحتوى داخل علامة التبويب
  • النقر المزدوج على ملف في المستكشف
  • النقر المزدوج فوق علامة تبويب المعاينة في مجموعة علامات التبويب

تجاوز

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

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

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

التنقل بين علامات التبويب

تسمح الأوامر التالية للمستخدمين بالتنقل بين علامات التبويب:

  • يظهر Ctrl-Tab قائمة بجميع علامات التبويب داخل مجموعة علامات التبويب النشطة:
    image3
  • يظهر Ctrl Alt Tab قائمة بجميع علامات التبويب داخل كل مجموعات علامات التبويب
    image4
  • يُظهر Quick Open التاريخ الخطي لجميع علامات التبويب
    image5

ملفات العمل

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

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

إذا كان الملف مفتوحًا في مجموعتين أو أكثر من مجموعات التحرير ، فإننا نعرض هذا في قائمة المحررين المفتوحة:
image6

يظهر أي محرر يفتحه المستخدم في قائمة المحررين المفتوحة. على سبيل المثال ، يظهر محرر الفرق كما يلي:
image7

تحتوي كل مجموعة على علامة تبويب معاينة واحدة فقط.

تشير شارة الرتبة في أعلى يمين مجموعة المحرر النشط إلى وجود مجموعة من المحررين أم لا.
image8

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

يؤدي إغلاق محرر (على سبيل المثال باستخدام Ctrl-W) إلى إزالة المحرر من قائمة المحررين المفتوحة.

ال 411 كومينتر

+1

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

هل من الممكن إضافة علامات تبويب من خلال ملحق مخصص؟

لا ، هذا غير ممكن حاليًا من امتداد (انظر أيضًا http://code.visualstudio.com/docs/extensions/our-approach)

+1

: +1:

: +1:

+1

علامات التبويب هي الطريقة الافتراضية للعمل حتى في Visual Studio ، ناهيك عن برامج تحرير النصوص الأخرى مثل sublime.

بالنسبة لأولئك الذين يفتقدون علامات التبويب ، هل حاولت استخدام Ctrl+Tab للتنقل في محفوظات الملفات المفتوحة؟

نعم. لكن الملف يظل في سياق Ctrl+tab حتى بعد إغلاق الملف. التجربة ليست هي نفسها تجربة Sublime / Atom.

snehilmodani صحيح ، هل سيكون من المفيد أن تعرض القائمة فقط ما لديك في قسم ملفات العمل في المستكشف؟ هل يمكنك العمل مع قائمة ملفات العمل على الأقل؟

هذا سيكون رائع!

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

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

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

يمكننا إضافة منتقي ملفات لملفات العمل ، ولكن سيكون من المثير للاهتمام معرفة ما إذا كان يمكن إقناع الأشخاص باستخدام Ctrl + Tab كما هو الحال اليوم ومعرفة المشكلات.

bpasero سأعطي لقطة ctrl+tab ، لقد أدركت للتو أنه يمكن استخدامها للانتقال إلى الملف السابق وهو شيء

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

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

Ctrl+tab شيء رائع أن أمتلكه وأنا معجب به تمامًا. إنه شيء يفتقده أتوم.

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

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

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

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

نعم أعتقد أننا سنحتاج إلى القيام بشيء مثل هذا 2016.stevencl fyi

فيما يتعلق بعلامات التبويب والملفات المتعددة في كل قسم: حتى في Sublime Text ، يمكننا فتح 3 برامج تحرير جنبًا إلى جنب لكنها لا تزال تقدم تخطيطًا مقطعيًا مبوبًا.

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

لا أعتقد أن علامات التبويب هي طريقة جيدة لإظهار قائمة الملفات المفتوحة إلا إذا كنت تدير هذه الأشياء بنشاط وتغلقها.

يقوم بعض الأشخاص بإدارتها بالفعل ، وبالنسبة للآخرين ، توجد علامات تبويب قريبة على اليمين.

شكرا جزيلا لردود الفعل.

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

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

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

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

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

أشركني!

لا أعتقد أن علامات التبويب هي طريقة جيدة لإظهار قائمة الملفات المفتوحة إلا إذا كنت تدير هذه الأشياء بنشاط وتغلقها.

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

تجدر الإشارة إلى أنه ليس كل شخص مطور ويب ، أجد أن الأنماط وسير العمل يميلان إلى الاختلاف قليلاً باختلاف اللغات وأنماط التطبيق. كمطور أصلي ، من الشائع أن يكون لديك مجموعة من الملفات المرتبطة مرئية ؛ cpp + h ، وربما أيضًا inl ، وعادة لا تعمل على ملف واحد فقط بشكل منفصل. غالبًا ما يكون لدي عرض تفكيك مرئي بجوار الكود. تمتد بيئة المحرر الخاصة بي على شاشتين ، مع 4 ملفات مرئية في أي وقت ، وسأكافح للعمل في بيئة أكثر تقييدًا من ذلك.
أفتقد أيضًا القدرة على الاستيلاء على علامة تبويب ونسخها في نافذة صغيرة عائمة ، والتي غالبًا ما أضعها على "دائمًا في المقدمة" ، والتي تُستخدم عمومًا كنقطة مرجعية ، أو شيء أقوم بنسخه كثيرًا العبور إلى / من.

الآن على سبيل المثال ، أحاول إعادة بناء وتبسيط بعض التعليمات البرمجية القديمة ؛ مجموعة ملفات عملي الحالية هي ... component.cpp، component.h، component.inl، componentimpl.cpp، elementimpl.h، icomponent.h. هذا 6 ملفات! ولا يمكنني الهروب من القرص العرضي لبعض الملفات الأخرى على الأطراف. أستخدم ctrl-tab بشكل متحرر عندما أعمل على هذا النمط من المشروع (التقليب بين ملفين) ، لكن في هذا السياق / قاعدة التعليمات البرمجية ، لا يمكنني ببساطة العمل بدون علامات تبويب.

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

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

سأكون ممتنًا لفرصة أن أكون جزءًا من هذه الدراسات المركزة!

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

هذا هو الحال بالنسبة لي. في الواقع لا يمكنني العمل بدون علامات التبويب. أنا أعمل مع نظام علامات التبويب منذ سنوات ، وبدونها ، أنا ضائع حقًا. هذا هو أحد أسباب عدم استخدامي لـ Code في الواقع.

تم إنشاء العديد من التصميمات الراسخة لأنها جيدة وفعالة ، وليس لأنها قديمة وتحتاج إلى التحديث لتكون أكثر عصرية :)

: +1:

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

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

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

على سبيل المثال ، ماذا عن السماح للمستخدم بنقل / سحب قسم "ملفات العمل" إلى الأعلى (تحويلها إلى علامات تبويب ، دعنا نقول). مرة أخرى ، قد يختار المستخدم الطريقة التي يريد أن يعمل بها وأعتقد أن هذا رائع!

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

أول شيء أفعله على الإطلاق باستخدام VS Code هو تبديل ملفه القريب وإغلاق اختصارات لوحة مفاتيح المحرر النشط ، بحيث يقوم ctrl + W بالفعل بإغلاق الملف عند الضغط عليه ، بدلاً من تركه في ملفات العمل والتكدس في ctrl + tab.

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

بالإضافة إلى ذلك ، يبدو أن ctrl + tab بين ملفات العمل تعمل بالترتيب الأحدث ، على عكس علامات التبويب التي تعمل عادةً بالترتيب الذي تظهر به أو يتم ترتيبها. (لقد رأيت بعض المحررين يدعمون كليهما).

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

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

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

راجع للشغل هناك امتداد - بمجرد إغلاق محرر - يفتح التالي من ملفات العمل. إذا قمت بدمج ذلك مع تغيير رابط المفاتيح كما يقترح فستكون قريبًا جدًا من imho.

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

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

هل يريد الأشخاص حقًا فتح الملفات في علامات التبويب ونقلها وإغلاقها في النهاية؟

نعم

هل هذا لأنك معتاد على ذلك أم أن هناك قيمة في فعل ذلك؟

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

هل قيمة القدرة على تعيين مجموعة ملف عمل نشط قمت برفضها لاحقًا لبدء شيء جديد؟

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

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

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

أجد أيضًا فرقًا عمليًا آخر غير استخدام الفضاء والميل المعتاد ؛ أحب أن تكون علامات التبويب مرتبطة بنافذة المحرر التي يلتزمون بها. عادةً ما يكون لدي ما لا يقل عن 2 ، 3 ، غالبًا 4 نوافذ مفتوحة (في مقابل مناسب) ، ولكل منها بضع علامات تبويب مرتبطة. ربما في إحدى النوافذ لدي widget.cpp/.h ، وفي النافذة الأخرى لدي gizmo.cpp/.h/.inl . ترتبط علامات التبويب هذه منطقيًا بنافذة التعليمات البرمجية المرفقة بها ، وأجد ذلك ممتعًا.

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

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

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

إنه ليس متفوقًا على علامات التبويب العادية ، وبالتالي لا يقدم أي سبب مقنع للتكيف ... في رأيي :)

+ 1TurkeyMan

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

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

screen shot 2015-12-24 at 09 28 30

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

الآن ، من الواضح أن ملفات العمل بها مشكلة مماثلة ، فقط في بعد آخر. هذا هو السبب في أننا في الفريق عادةً ما نستخدم فقط Ctrl+Tab لكل شيء ولا نهتم بما تم فتحه أم لا.

للتلخيص: ملفات العمل ليست إجابتنا لاستبدال علامات التبويب ، بل هي مزيج من ملفات العمل و Ctrl+Tab . وفريقنا أكثر أو أقل بنسبة 100٪ عند استخدام Ctrl+Tab ولا شيء آخر.

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

أنا مستخدم Ctrl-Tab ليبرالي للغاية عندما يكون ذلك ممكنًا ، ولكن لا يمكنك استخدام Ctrl-Tab إلا إذا كنت تقوم بتحرير ما لا يزيد عن 2 أو 3 ملفات.
لدي شك في أن رأيك في هذا الأمر قد يكون متحيزًا تمامًا تجاه مشروعك المحدد ، وقد يتضمن ذلك تحيزًا لغويًا. في C / C ++ ، يتضاعف العدد المعتاد لملفات العمل أو يتضاعف ثلاث مرات عندما تقبل أن هناك .h ، وفي حالتي ، غالبًا .inl يكمل كل .cpp . Ctrl-Tab أقل فاعلية في هذا السيناريو ، وأنت تميل إلى استخدام Ctrl- ~ بدلاً من ذلك (تبديل cpp / h ؛ الذي قمت أيضًا بنشر طلب ميزة له) ، بالتزامن مع إدارة علامات التبويب.
أو ضع في اعتبارك Java ، حيث يلزم أن تعيش كل فئة - مهما كانت صغيرة - في ملفها الخاص.

في يومي الحالي ، غالبًا ما يكون لدي مجموعة عمل من 10s من الملفات ، Ctrl-Tab لا فائدة لي عندما أعمل بهذه الطريقة. سير العمل الأكثر عملية هو 2-4 نوافذ محرر ، وبضع علامات تبويب في كل نافذة. لم أختر هذا التصميم لأنني أحبه ؛ لقد ظهر ببساطة ، لأنه تخطيط مساحة العمل الأكثر كفاءة لهذه الوظيفة بالذات.

+ 1
عادةً ما أقوم بتقسيم المحرر ويكون إغلاق علامة تبويب أكثر سهولة من وجود أكثر من 10 ملفات عمل.

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

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

مثال بسيط على ذلك هو .cpp و ".h" مع علامات التبويب ، ستكون نقرتان مركّزة على أعلى النافذة بينما في ملفات العمل سيكون من 3 إلى 4 نقرات مع ملفات العمل التي تتطلب منك تحديد المحرر المعني ثم حدد الملف الجديد لتحريره.

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

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

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

هذا يبدو تقريبًا مثل المسافات مقابل علامات التبويب ، 2.0

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

هذا يبدو تقريبًا مثل المسافات مقابل علامات التبويب ، 2.0

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

أدرك أنه يبدو كما لو كنا ننظّر إلى ما لا نهاية حول هذا بدلاً من فعل شيء فعليًا ونعتذر عن ذلك. ومع ذلك ، لدينا عنصر لمعالجة هذا الأمر في التراكم لدينا (المشار إليه أعلاه - # 1133). لم نتمكن من قضاء قدر كبير من الوقت في هذا مؤخرًا لأننا نعمل بجد على الأقلمة وإمكانية الوصول.

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

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

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

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

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

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

شكرًا stevencl ، من الجيد أنه على الأقل على الرادار وهناك بعض العصف الذهني يجري.

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

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

غالبًا ما ينتهي الأمر بالعديد من المستخدمين بفتح العديد من علامات التبويب التي تحتوي على ملفات لم تعد بحاجة إليها

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

عندما يتعلق الأمر بذلك ، إذا تمكنت VS من تكرار _ سلوك _ علامات التبويب اختياريًا (والتي يبدو أنها على الأقل واحدة من الأشياء في # 1133 تتعلق) مع الاحتفاظ بها على الجانب بدلاً من ذلك ، فقد يكون ذلك بداية جيدة بما فيه الكفاية . إن ترتيب Ctrl + tab يجري MRU مقابل ترتيب الظهور شيء آخر (Sublime يسمح لكليهما عبر أوامر مختلفة قابلة للربط).

stevencl ، شكرا لاستجابتك. أود التعليق على بعض نقاطك:

[...] نحن على دراية بالمشكلات المتعلقة بالتجربة الحالية لإدارة الملفات ولدينا عدد من التغييرات التي نريد إجراؤها لتحسين التجربة.

أنا بالتأكيد أتطلع إلى ما يبدو أنه مستقبل مشرق للغاية لـ VS Code. لقد كنت متحمسًا عندما سمعت أن Microsoft تقدم بيئة تطوير متكاملة قوية مثل Visual Studio إلى عوالم خارج Windows ، ولاعتمادها نماذج جديدة لتطوير التطبيقات باستخدام Electron. مجد لعملك حتى الآن!

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

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

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

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

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

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

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

[...] نحاول حقًا الحفاظ على الحد الأدنى من الجمالية التي نعتقد أنها توفر تجربة خفيفة الوزن وقوية. نحن ببساطة حريصون للغاية على إدخال واجهة مستخدم جديدة وتجربة مستخدم جديدة في المنتج.

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

[...] أعتذر مرة أخرى لجعل الأمر يبدو وكأننا نحدق في السرة ولا نفعل أي شيء حيال هذا.

هذا بالتأكيد ليس رأيي في ذلك ، لذلك لا تقلق هناك. للأسباب التي ذكرتها بالفعل ، يمكن للمحادثة الصحية حول هذا بالتأكيد أن تعزز الهدف الأكبر وهو UI / X الخاص بـ VS Code.

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

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

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

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

شكرًا ، أقدر الفرصة لإجراء هذه المحادثة.

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

بعد أن عملت على تصميم Visual Studio لعدد من السنوات على الرغم من أنني رأيت مشاكل UX التي يمكن أن تسببها علامات التبويب. لقد أمضيت 18 شهرًا في العمل على تجربة علامة تبويب المعاينة في Visual Studio وهي محاولة لتقليل مشكلة "علامة التبويب" التي يصفها bpasero أعلاه.

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

نشكرك على كل الأفكار والأوصاف المتعلقة بالمشكلات التي تواجهها حاليًا بشأن كيفية إدارتنا للملفات في VS Code.

stevencl ، من المضحك أن تذكر علامة تبويب المعاينة - أحبها. إنه لأمر رائع أن يكون لدى VS Code و Sublime و Atom و Brackets (عبر الامتداد) وما إلى ذلك ميزة معاينة مثل هذه افتراضيًا.

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

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

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

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

للأسف ، يظل Windows أسوأ نظام أساسي / نظام بيئي مطور ، مع أفضل بيئة تطوير ، وقد كان الأمر كذلك لمدة 15 عامًا. غريب حقا.
لا أعرف السبب ، ولكن يبدو أنه بالنسبة لي ، فإن بيئة التطوير (الإنتاجية) تتفوق على النظام البيئي في ميزاني ، لكنه توازن مؤلم وسأكون سعيدًا مثل خنزير في الوحل عندما يمكنني استخدام VS في لينوكس بالكامل -زمن! نحن قريبون جدا!
أعلم أنكم تنظرون إلى هذا على أنه وسيلة لاستكشاف مناطق جديدة ، وهذا أمر رائع تمامًا ، ولكن على المدى القصير ، نريد حقًا فقط VS على نظام Linux ، (أو OSX ، إذا كنت تتأرجح بهذه الطريقة) ، كما حلمنا عقد أو نحو ذلك ، ويمكننا أخيرًا ، بعد كل هذه السنوات ، إنهاء معاناتنا! ؛)
</dramatic_commentary>

TL ؛ DR ، الاستكشاف رائع تمامًا وأنا واثق من أنك ملتزم بأفضل منتج نهائي يمكنك صنعه ، لكن الحلول المألوفة الآمنة في الوقت الحالي ربما؟

+1 لعلامات التبويب. السؤال- لماذا لا تقوم بإزالته من Visual Studio Bundle بعد ذلك؟ انظر ماذا سيحدث بعد ذلك ...

+1 لعلامات التبويب! يرجى تنفيذ هذا في تحديث مستقبلي.

يبدو أن الافتراض الجاري هو أن "[علامات التبويب] تنمو كثيرًا في معظم الحالات بحيث ينتهي بك الأمر بعدم رؤية أي شيء". أود تحدي هذا الافتراض. أنا أستخدم علامات التبويب كفهرس مرئي للملفات التي أهتم بها حاليًا ، وأدير هذا الفهرس بنشاط مع تغير اهتماماتي بمرور الوقت. الرؤية مهمة: أشير إلى علامات التبويب المادية باستمرار لإعادة توجيه نفسي. مع ملفات العمل ، جردت من قدرتي على عرض هذا الفهرس ومعالجته. على سبيل المثال ، لا يبدو أن هناك طريقة لإزالة ملف من ملفات العمل عبر لوحة المفاتيح. أشعر وكأنني أحارب المحرر. الرجاء إضافة علامات تبويب Sublime Text-style.

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

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

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

Ctrl + tab هو إجراء رئيسي ، وعلامات التبويب هي إجراء مرئي ، وهو أسرع بكثير.

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

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

أتفهم أن هذه ليست مخاوف بالنسبة لك لأنك "استخدمتها بدون علامات تبويب لمدة 4 سنوات" ، لذا فإن أي شيء خارج نطاق Ctrl + Tab يُنظر إليه على أنه طريقة غريبة لاستخدام البرنامج.

يجب أن يكون هذا ميزة وما إذا كان يتم تشغيله أو إيقاف تشغيله افتراضيًا لا يهم. تقريبًا يستخدم كل محرر نصوص / IDE علامات تبويب للتنقل. ربما يشعر البعض أن هناك طريقة أفضل ولكن بالنسبة لمعظمنا ، فإن علامات التبويب فعالة وسهلة الاستخدام ومألوفة ... ومن الواضح أننا نحبها! أخرجهم من Visual Studio لإصدار واحد لترى مدى أهميتهم ... (cue-style انصهار مطور ملحمي) يرجى النظر في علامات التبويب لإصدار قريب المدى. إنه الشيء الوحيد الذي يمنع الكثير منا من اعتماد VSCode بدوام كامل.

: +1:

أنا أكثر إنتاجية مع علامات التبويب! أستخدم Atom أثناء استخدامي Google Chrome (Ctrl + 1 لعلامة التبويب الأولى ، Ctrl + 5 إلخ. Ctrl + Tab ، Ctrl + Shift + علامة التبويب).

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

لذا من فضلك ، قم بتنفيذ علامات التبويب.

ستكون علامات التبويب مفيدة جدًا ، +1

: +1:

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

يحتوي Visual Studio Power Tools على خيار لعرض علامات التبويب عموديًا ، وهو ما أحبه تمامًا.

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

هنا حيث تكون علامات التبويب مهمة - علينا الرجوع للحظة إلى ميزة أخرى مفقودة:

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

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

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

riclf لديه بقعة على.

عادةً ما يكون لدي 3 أعمدة عمودية مفتوحة ، HTML و JS و CSS من اليسار إلى اليمين.

في Sublime ، كان لدي جميع علامات تبويب html أعلى العمود الأول ، وجميع ملفات JS كعلامات تبويب أعلى العمود الثاني وما إلى ذلك. تحتوي علامات التبويب على سياق وأنا أعلم أنني لن أقوم بفتح الملف الخطأ في العمود الخطأ.

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

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

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

فقط بلدي 2c.

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

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

كمستخدم mvim ، لدي مجموعات متعددة من ملفات TDD مفتوحة ، وعلامة تبويب بينها. على سبيل المثال ، أنا اختبارات + الزاوية ، اختبارات الخادم + ، الخيار أو التصرف + البرامج النصية. لا أريد استخدام علامة التبويب للوصول إلى ملف واحد ، بل مجموعة من الملفات المفتوحة. لقد قمت بالتبديل إلى VSCode لمدة 3 أشهر لمشروع إنشسكريبت ، لأنه كان يتمتع بالفعل بدعم Typecript الأفضل في فئته / المذهل. ومع ذلك ، بمجرد أن انتقلت إلى مشروع لا يحتوي على أنواع ، وجدت أنني قارنت إمكانات البحث والتنقل والاستبدال للأغراض العامة مباشرةً مع mvim ، ويؤسفني أن أقول إنني عادت بسرعة (أي على الفور) إلى محرري السابق. لدي شاشة Apple Cinema مقاس 27 بوصة وسأحصل على شاشة أكبر إن أمكن. لدي مساحة كبيرة للكثير من علامات التبويب وأزواج الملفات ، وليس لدي سبب مقنع لكي أكون محدودًا في استخدام هذه المساحة بواسطة المحرر . لا أريد التعامل مع ملف واحد فقط في كل مرة - أريد فتح العديد من الملفات وتتبع التدفق من علامة تبويب إلى أخرى.

لقد قمت بتجربة Visual Studio Code مرة أخرى قبل أسبوعين. لقد فوجئت في الواقع بسرور عندما كنت مجرد عبث ببعض الملفات. لكن عندما بدأت العمل في مشروع فعلي (كبير) مع فتح أكثر من حفنة من الملفات ، أصبح عدم وجود علامات تبويب مزعجًا للغاية. _Working Files_ فقط لم يناسبني وأبطأني. بعد 3 أيام شعرت بالانزعاج الشديد من ذلك لدرجة أنني عدت إلى Sublime Text. لدي شاشتان مقاس 24 بوصة في العمل (Windows) ، وجهاز Mac في المنزل مقاس 27 بوصة ، ويمكنني بسهولة فتح 20 علامة تبويب مع الاستمرار في التمييز بين الملفين. الكثير من العقارات المعروضة على الشاشة لعلامات التبويب في حالتي. _You_ تظهر بالفعل اسم الملف للملف الذي تم فتحه في المحرر. كل المساحة الموجودة على يمين اسم الملف غير مستخدمة (باستثناء الرموز الموجودة على يمين النافذة) ويمكن ملؤها بعلامات تبويب (وهو ما يفعله Sublime Text أيضًا). أقول منح المستخدمين خيار العمل مع _Working Files_ و / أو علامات تبويب الملفات. في الوقت الحالي ، أعود إلى مجموعة من Sublime Text و Visual Studio Enterprise. سأعيد النظر عند إضافة علامات التبويب.

بالنسبة لخيار Working Files ، يجب أن أقوم بتبديل الشريط الجانبي (حيث أبقيه مخفيًا لعرض الرمز الموسع) لتحديد الملف. كما أن خيارات Ctrl+P و Ctrl+tab ليست سهلة الاستخدام.

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

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

عندما كنت جديدًا على VS Code فاتني حقًا علامات التبويب. ثم اكتشفت ctrl + tab ولم أعد بحاجة إليها.

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

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

pesho بالضبط!

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

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

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

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

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

إذا كنت أقوم بفتح ملف ، فإنه يظل في سجلات الملفات المختلفة ، فأنا بخير بدون علامة تبويب. ربما إذا كان الملف مفتوحًا لأكثر من 5 ثوانٍ ، فإنه يستحق إدخالًا في CTRL + Tab.

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

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

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

أعتقد أن التفضيل يجب أن يكون جيدًا أيضًا.

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

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

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

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

+1

لدي شاشة بدقة 4K وليس لدي أي علامات تبويب أفقيًا يؤدي إلى إطفائي من VsCode

راجع للشغل ، أريد أن أوضح أنني لا أريد فقط علامات التبويب ، بل أرغب في مجموعات من علامات التبويب. بصفتي مطورًا مكدسًا كاملًا لـ mvim TDD على جهاز Mac ، أعتقد أنه من حيث السياقات. html + css ، الزاوي + الاختبارات ، العقدة + الاختبارات ، الخيار + خطوات الاختبار. عادةً ما أعمل في سياق واحد لبضعة أسطر من التعليمات البرمجية قبل الانتقال إلى السياق التالي ، نمط TDD. عند استخدام mvim ، لا أقوم فقط بالتبديل بين هذه السياقات بسرعة كبيرة (باستخدام نفس تسلسل المفاتيح الذي أستخدمه في Mac Terminal و Mac Finder و Safari أو Chrome) ، لكنني أستفيد من وحدات الماكرو التي تفتح الملف المقترن تلقائيًا ، بحيث يتم ذلك من ملف المصدر الزاوي ، يمكنني فتح الاختبار المقابل تلقائيًا. هذه طريقة عمل مثمرة بشكل لا يصدق ، وتبقي أصابعي على لوحة المفاتيح.

إذا وجدت بيئة تطوير متكاملة من شأنها أن تسمح لي لفتح "المرتبطة" ملفات في إطارات بجانب بعضها البعض، فقط عن طريق التحول علامة تبويب واحدة، على سبيل المثال عندما button.html فتحه سيفتح button.js بجانبه وbutton.scss في الإطار الثالث ، لن أستخدم IDE آخر مرة أخرى.

أعلم أن هذا لن يحدث أبدًا ، لكن فقط قل.

حسنًا ، إذن ، يجب أن تستخدم mvim! http://www.vim.org/scripts/script.php؟script_id=1567 الأمر: يفتح AV الملفات المرتبطة (A للملفات المرتبطة).

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

+1

بالمثل هنا ، أحب علامات التبويب.

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

تعد علامات التبويب VS مثالية ، يرجى إحضار علامات التبويب ، وسيكون فك علامات التبويب في نافذة منفصلة أمرًا رائعًا أيضًا!
شكرا على vscode :)

أنا في الواقع أشعر بالفضول بشأن ما إذا كنت تريد أن تجعل VSC محرر ملفات للأغراض العامة ، أو مجرد محرر شفرة مصدر.

هناك بعض المواقف التي يكون فيها شريط علامات التبويب مطلوبًا تمامًا .

  1. التبديل بسرعة بين العديد من علامات التبويب.
    الوضع الشائع بالنسبة لي هو أنني بحاجة إلى مقارنة ملفين أو أكثر من خلال شكله ، مثل المقارنة بين الصينية المبسطة وما يعادلها التقليدية. الفرق لن يحل المشكلة لأنهم شخصيات مختلفة. الطريقة الوحيدة هي التبديل بسرعة بين علامات التبويب لمعرفة ما إذا كانت هناك أي كلمة مفقودة من مقل العيون. باستخدام ST وأنا يمكنني تبديل علامات التبويب باستخدام Alt-NUM ، ولكن في VSC ، الطريقة الوحيدة الممكنة هي استخدام Ctrl-Tab متعدد ، أو تحريك الماوس والنقر بسرعة.
  2. أسماء ملفات طويلة ويصعب كتابتها.
    استخدام Ctrl-P للتبديل بين الملفات ليس بالأمر السيئ. ولكن ماذا عن بعض أسماء الملفات التي تشترك في إصلاح مشترك طويل؟ ماذا عن بعض الأسماء التي ليست باللغة الإنجليزية؟ ضع في اعتبارك مقدار الوقت الذي تقضيه على Ctrl-P للتبديل بين 青年急着买房的原因(上).md و 青年急着买房的原因(下).md ؟

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

@ msg7086 لست متأكدًا من النقطة الأولى ولكن بالنسبة للنقطة الثانية ، لا يمكنك ctrl + p ثم اكتب .md مما يترك لك الخيارين ثم فقط ctrl + tab لاختيار الخيار الذي تريده تريد؟ لست متأكدًا من أنني أفهم المشكلة بشكل صحيح

@ 4tron شكرا على الرد. ومع ذلك ، فإن طريقتك لا تعمل إلا إذا كان لدي ملفان فقط من هذا النوع. في الواقع ، من المحتمل أن يعمل الأشخاص مع مجموعة من هذه الملفات في دليل واحد. Imaging أنا أكتب مدونة بها 50 منشورًا بتنسيق markdown ، بأحرف مختلفة باللغة الصينية أو الكورية أو العربية وما إلى ذلك كأسماء الملفات. كان السيناريو الحقيقي الذي كنت أواجهه هو في الواقع بعض ملفات الترجمة بأسماء CJK ، حيث تكون جميعها *.ass ، وبالتالي فإن Ctrl + P بالامتداد لا يعمل بشكل جيد.

نقدر حقًا ما إذا كان يمكن تنفيذ ذلك

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

+1 لعلامات التبويب. الرجاء تنفيذ علامات التبويب.

+1 لعلامات التبويب!

أنا أصوت لإضافة علامات التبويب أيضا.

+1

+1

+1

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

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

ما هي الصفقة الكبيرة؟

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

يرجى إعطائنا إدارة المستندات المبوبة :)

+1 أنا.

+1

+1

يعد VSCode محررًا رائعًا ولديه نقاط تكامل جيدة مع كل من Git و Nodejs. السبب الرئيسي في عدم استخدامه باعتباره IDE الأساسي للتطوير هو أنه لا يدعم علامات التبويب.

كذلك هنا. إنه الشيء الوحيد الذي يجعلني أستخدمه.
Op do 10 mrt. 2016 om 15:18 schreef Konrad Piascik < [email protected]

يعد VSCode محررًا رائعًا ولديه نقاط تكامل جيدة مع كل من Git و
Nodejs. السبب الرئيسي في أنني لا أستخدمه باعتباره IDE الأساسي للتطوير
لأنه لا يدعم علامات التبويب.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036.

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

إذا تمت إضافة هذا ، يرجى إضافة ما يلي:

  1. أغلق الوظائف مثل Google Chrome. (كان منزعجًا دائمًا أن الإصدار القياسي من VS لم يكن لديه هذا.)
    - " أغلق علامات التبويب الأخرى "
    - " إغلاق علامات التبويب على اليمين ".
  2. خيار لفتح علامة التبويب إلى اليمين أو اليسار. (غيرت VS الافتراضي في وقت ما ، لكنها أضافت بعد ذلك خيارًا للتغيير)

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

في فريقي ، يشتكي الأشخاص طوال الوقت من ذلك ، لدرجة أن بعض الأشخاص يفضلون استخدام sublime دون أي دعم مطبوع ثم استخدام VS Code.

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

-1

بعض الملاحظات حول سبب معارضتي لعلامات التبويب:

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

حسنًا ، هناك حل وسط - اجعل علامات التبويب مرئية أم لا في التفضيلات / الخيارات.

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

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

لقد أجبرت نفسي على أن أصبح أكثر من كوماندوز لوحة المفاتيح وعدم وجود علامات تبويب كان مفيدًا. لذلك أنا أتجادل من منظور الأمر لصالحك على الرغم من أنني لست موجودًا حتى الآن.

كما اقترحت سابقًا في هذا الموضوع ، فإن _السلوك_ المفقود هو نفس الأهمية ، إن لم يكن أكثر ، من المكون المرئي. أنا جميعًا أستخدم اختصارات لوحة المفاتيح مثل ctrl + [shift +] علامة التبويب أو حتى ctrl + P للتنقل إلى الملفات (بما في ذلك الملفات المفتوحة) ، ولكن سلوك ملفات العمل وكيف تدير نوافذ المحرر (وحقيقة أنها ctrl + tabs بترتيب MRU) أجد صراخًا رهيبًا.

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

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

لذلك أنا -1 في هذا. لكني ما زلت أرغب في رؤية فك النوافذ.

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

هذه. أتفق بنسبة 100.

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

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

@ jayrosen1576 ربما يقم أحد حقًا بتقديم اقتراح متعمق حول الشكل الذي يجب أن يبدو عليه

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

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

إليك اقتراح كيف يجب أن يبدو:

1) قم بتنزيل Atom
2) افتح Atom
3) انظر إلى علامات التبويب
4) تنفيذ في VSCode

@ jayrosen1576 على محمل الجد؟ لقد قمت بتسمية بعض المخاوف الصحيحة المتعلقة بتنفيذ Atom وأيضًا المشكلات التي لا يواجهها Atom ببساطة لأنه لا يحتوي على مفهوم ملفات العمل.

ثم مرة أخرى ، صورة ملفك الشخصي تقول كل شيء.

  • هل يجب وضع شريط علامات التبويب أعلى جميع النوافذ؟
    ج: نعم. جرب علامات التبويب في Atom
  • كيف سيعمل النقر فوق علامة تبويب عندما يكون لديك ملفات متعددة مفتوحة جنبًا إلى جنب ، أو في إصدار مستقبلي ، حتى يتم تقسيمها أفقيًا؟
    ج: تظهر علامات التبويب أعلى كل جزء. جرب علامات التبويب في Atom.
  • هل سيتم تمييز علامة تبويب الملف النشط دائمًا؟
    ج: نعم. جرب علامات التبويب في Atom.
  • ماذا لو كانت وحدة التحكم في التصحيح مركزة؟
    ج: نفس النتيجة عندما تكون وحدة تصحيح الأخطاء مركزة الآن مع ملفين مفتوحين جنبًا إلى جنب.
  • إذا قمت بتمكين إعداد علامة التبويب ، فهل ستتم إزالة قسم ملفات العمل لأنها زائدة عن الحاجة؟
    ج: فقط إذا قمت بتعطيل ملفات العمل (كخيار)
  • ماذا عن أسماء الملفات المكررة في مجلدات مختلفة؟
    ج: تتضمن علامة التبويب مسارًا جزئيًا. جرب علامات التبويب في Atom.
  • ماذا عن زر الإغلاق المكرر لعلامة تبويب ولوحة؟
    ج: لا تحتوي اللوحة على زر إغلاق. جرب علامات التبويب في Atom.
  • هل سيؤدي إغلاق اللوحة إلى إغلاق علامة التبويب؟
    ج: نعم. جرب علامات التبويب في Atom.
  • هل ستظهر علامة تبويب بمجرد فتح ملف مثل Atom (urgh) أم فقط عند تحرير مثل ملفات العمل؟
    ج: فقط إذا قمت بتمكين الخيار للقيام بذلك (usePreviewTabs = false في Atom يوقف هذا الخيار). خلاف ذلك ، انقر نقرًا مزدوجًا لفتحها في علامة تبويب. جرب علامات التبويب في Atom.

felixfbecker نظرًا لأن هذا المنتج يحمل لقب Visual Studio ، يجب أن تكون هناك علامات تبويب اختيارية ، ويجب أن تتصرف كما تفعل في أي منتج Visual Studio آخر.

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

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

@ jayrosen1576 هذا لا يحل المشكلة بالكامل في الواقع ، لأنه كما قلت من قبل (

kfranqueiro أتفق

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

nvivo لا يمكن أن

تمامًا مثل اختيار القائمة بالأحرف الكبيرة VS.

nvivo هل جربت هذا التمديد؟ لا يوجد خيار قائمة ولكن يمكنك إعداد بعض اختصارات لوحة المفاتيح. يعمل بشكل جيد.

https://marketplace.visualstudio.com/items؟itemName=wmaurer.change-case

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

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

هل ستستمر في استخدام VS Code إذا لم تتم إضافة علامات التبويب قريبًا؟ نعم / لا

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

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

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

ملحقات المستعرض؟ نشط ... NVM.

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

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

"لا أعتقد أنه يستغرق وقتًا بعيدًا عن التحسينات الأخرى"

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

@ 4tron ، بالطبع هناك مؤامرة من المجتمع الشرير لاختبار مايكروسوفت هنا! ألا يوجد دائما واحد؟

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

أقول لنلعب بأمان. دعنا ننتظر أولاً ونرى ما إذا كان محرر جيد آخر يدعم هذه الميزة الجديدة حتى لا نضيع الوقت والجهد في شيء لا يعمل بالفعل. دعنا نتحقق من الاستوديو المرئي أو intellij أو eclipse أو atom أو sublime أو monodevelop أو notepad ++ أو أي واحد آخر لديه قاعدة مستخدمين كبيرة. بمجرد دعم _ بعض هؤلاء المحررين على الأقل لهذه الميزة لمدة عامين دون استبدالها بشيء آخر ، سيكون هناك بعض المؤشرات على أن هذه ميزة مفيدة.

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

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

Ghehehe ، فرحان!

أب زا 12 متر. 2016 om 11:57 schreef Natan Vivo [email protected]

@ 4tron https://github.com/4tron ، بالطبع هناك مؤامرة من
المجتمع الشر لاختبار مايكروسوفت هنا! ألا يوجد دائما واحد؟

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

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

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

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

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795.

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

@ 4tron بدا لي أنه كان يقارن أيضًا محرري النصوص
أعتقد أنهم يقومون بعمل رائع في جعل vscode قابل للتوسيع ، لكنني أقيم بثبات في المعسكر الذي يعتبر أن علامات التبويب يجب أن تكون ميزة خارج الصندوق. هذه الفكرة "أوه ، هل تعجبك علامات التبويب مثل جميع البرامج الأخرى التي تستخدمها؟ ابحث في Google عن المشكلة ، واعثر على توصيات تشرح كيفية تثبيت الامتداد المناسب الذي يساهم به المستخدم ، وأنت على ما يرام!" لا تطير. أتخيل أن معظم المستخدمين يتوقعون فقط وجود علامات تبويب ، وأشك بشدة في وجود الكثير من الأشخاص الذين يعتقدون أنك ستجد شريط علامات تبويب من خلال تثبيت ملحق. أنا متأكد من أن هذا لم يسبقه أي برنامج آخر على الإطلاق. لماذا يعتقد الناس أن يفعلوا ذلك؟

تضمين التغريدة
لقد بدأ خطابه بمقارنة مع المتصفحات.

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

الجانب السلبي لكون كل شيء امتدادًا هو أنك ستنتهي بتفاعلات غريبة غير مرغوب فيها بينهما. في مقابل الكود الذي يستخدم بالفعل GitHistory أعلى Smart File Reopener يتسبب في حدوث مشكلات غريبة في إغلاق الملف.

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

@ 4tron ، كان الأمر مضحكًا ، لكنني جاد للغاية بشأن هذه النقطة.

خدمات المترجم الخارجي شيء قد تقرره أو لا تدعمه في محرر نصوص. تعد ميزة تشغيل المهام المتكاملة ميزة جيدة.

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

وهذا هو السبب وراء غباء مناقشة ما إذا كانت علامات التبويب جيدة أم لا. VS Code ليس تجربة UX ، إنها محاولة للحصول على محرر .NET جيد لجميع الأنظمة الأساسية. اجعل هذا الشيء مفيدًا لـ 90٪ من الناس وستنجح.

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

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

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

أريد فقط التعليق على فكرة إضافة كل شيء مع المكونات الإضافية. هذا هدف جميل. من المهم وجود إطار عمل ممتد رائع ، لكنني أعتقد أنهم بحاجة إلى توخي الحذر بشأن الإفراط في الالتزام بهذه الفكرة.
أستخدم VS ، وبينما يدفعني إلى الجنون ، أجد أنني مرتبط به لأنه يتمتع بمستوى عالٍ جدًا من جودة المنتج وهو ما أتوقعه من منتج MS. لقد جربت كل بدائل OSS (وغيرها من الأدوات الاحتكارية) ، ويبدو أنهم جميعًا يقصرون في واجهة الاستخدام الأساسية (خاصة عندما يتعلق الأمر بتجربة تصحيح الأخطاء).
آمل حقًا ألا يكون القصد من vscode أن يكون غلافًا خفيفًا يخترق كل شخص الميزات فيه بشكل عشوائي عبر الامتدادات ... هناك بالفعل العديد من الأدوات الأخرى التي تناسب هذا الوصف ، ولا أجد أداة أخرى مقنعة. ما أريده من vscode هو ما كنت أتمناه دائمًا من VS ؛ لتكون مصممة جيدًا من منظور قابلية الاستخدام من قبل مصممي UX المحترفين ، وأن تكون CROSS PLATFORM.

أعتقد أن أولئك الذين يعارضون علامات التبويب ربما يفتقدون المقصد. أنا (نحن) لا أريد حلاً كليًا أو لا شيء. كل ما نطلبه هو خيار بسيط لتشغيل علامات التبويب (يمكن إخفاؤها افتراضيًا) التي تبدو وتتصرف مثل تلك الموجودة في محرر Atom الشهير. إذا كنت لا تحبهم فلن تعرف أبدًا بوجودهم. إذا قمت بذلك ، فيمكن تمكينهم. وبالنسبة لأولئك الذين لم يستخدموا Atom مطلقًا وتجربة علامات التبويب متعددة الأجزاء ، أقترح أن تجربها قبل استبعاد الحجة تمامًا بالنسبة لهم. قد لا تعجبك ، لكن عليك أن تعترف بأنها مفيدة للكثير منا. إذا لم يكن الأمر يتعلق بقدرة تصحيح أخطاء node.js الممتازة الخاصة بـ VS Code ، فسأستخدم Atom حصريًا. أنا لا أمانع ملفات العمل. أعتقد أنها يمكن أن تكون مفيدة ، ومع ذلك ، فهي لا تشكل بديلاً جيدًا لعلامات التبويب وليست حقًا طريقة بديلة للقيام بنفس الشيء. إنه مثل قول "لديك هوندا سيفيك ، لماذا تريد شاحنة بيك أب؟ _ حسنًا حاول تحميل 1200 رطل من لسان الخيزران وأرضية الأخدود في الجزء الخلفي من سيفيك وسترى السبب. كلاهما مركبات لكنهما يخدمان أغراضًا مختلفة.

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

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

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

أشعر بالإحباط الشديد لرؤية كل هذه المناقشة ، وأشعر بالإهانة قليلاً لأنني أستخدم VS Code يوميًا في عملي وأريد الحصول على محرر .NET جيد على نظامي Mac و Linux ، وأفتقد علامات التبويب كثيرًا ، ولم أفهم لحظة "_Wow! هذه في الواقع أكثر فائدة_" ، ولكن يبدو أن الرد هنا هو "_ أنت فقط لم تدرك أننا صنعنا شيئًا رائعًا! امنحه الوقت واعتاد عليه! _".

فيما يلي بعض المشكلات الفعلية التي أراها باستخدام VS Code يوميًا لمدة شهرين:

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

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

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

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

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

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

لا يمكن اقبل المزيد.

نظرًا لأن طي الكود كان في يوم من الأيام الأكثر تصويتًا للميزة ، فإن علامات التبويب الآن . أعطانا فريق vscode الطي.

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

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

لقد علقت من قبل على وجود تنفيذ شبه مثالي لعلامات التبويب: Atom. من السهل تنظيمها ، ولديها عرض مناسب لمسارات الملفات الجزئية إذا كانت علامتا تبويب لهما نفس اسم الملف وتعملان بشكل جيد للغاية في نافذة بها عدة أجزاء أفقية و / أو رأسية (أعتقد أنها ميزة أخرى مطلوبة لـ VSCode). إذا كان VSCode يحتوي على نفس ميزات علامة التبويب مثل Atom ، أعتقد أن ذلك سيغطي 99٪ مما يطلبه الجميع. ونظرًا لأن Atom يعتمد أيضًا على الإلكترون ، يمكن أن يعمل التنفيذ بشكل متساوٍ في VSCode. أنا لا أؤيد حل نسخة القط لأي شيء ، لكنهم (Atom) قاموا بعمل رائع في تنفيذ علامات التبويب وما لديهم هو حل ممتاز في هذا الصدد.

@ jon64digital ربما أنا فقط ، لكن أعتقد أن ما يمنع تطور هذه المحادثة هو الشعور بالإحباط. لا يزال هذا الطلب غير محدد في التراكم ، حتى مع 6k + تصويت وإشارة غامضة الصياغة في تكرار 31 مارس:

تحسين إدارة المستندات وتكديس سلوك المحررين

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

مع أخذ ذلك في الاعتبار ، أعتقد أنه إذا كان عليهم على الأقل تخصيصه لشخص ما ، فيمكننا أن نهدأ فيما قاله

تحرير ربما يكون هذا النقص في الالتزام من فريق VS Code هو سوء فهم - بعد كل شيء لم يتم تحديث خطة التكرار لشهر مارس منذ 7 يناير.

@ jayrosen1576 أوافق - وأعتقد أن 1٪ من طلبات المستخدم التي لن تتم تغطيتها يمكن معالجتها بعد ذلك من خلال الامتدادات (على سبيل المثال ، فتح الملفات بعلاقات في مجموعات علامات التبويب ، وما إلى ذلك).

@ jayrosen1576 هل يسمح لك atom بربط الملفات بحيث يمكنك الحصول على عرض مقسم (على سبيل المثال) يفتح toolbar.html في الإطار الأول ، toolbar.js في الإطار الثاني و toolbar.css في الإطار الثالث؟

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

@ jon64digital Atom لا يفعل ذلك افتراضيًا ، ولست على علم بأي امتدادات حتى الآن (حتى ملحقات مستوحاة من vim) ، ولكن هذه هي حالة استخدام الامتداد التي كنت أشير إليها في آخر مشاركة لي.

يشير EDIT إلى التعليق الذي كتبهjtosey أعلاه (حوالي 9 أيام قبل هذا

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

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

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

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

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

أعتقد أنه سيكون لدينا بعض المناقشات حول كيفية عمل إدارة المستندات في المستقبل وأعتقد أننا مستعدون لإصلاح المفاهيم كما نراها ضرورية.

bpasero بعد مراجعة الكود الخاص

bpasero كان من الرائع أن تشرح بالتفصيل ما تمت مناقشته وما هي بعض الأساليب التي تراها كحلول ممكنة للمشكلات التي نشرناها.

ملاحظة: لست متأكدًا مما إذا كان ذلك ممكنًا مع VSCode ولكن بعض الفرق مثل Roslyn و TypeScript وعدد قليل آخر يشاركون ملاحظات التصميم الخاصة بهم ، فهو يعطي الكثير من السياق لكيفية عملهم وما سيأتي بعد ذلك ، كما أنه يفتح المجتمع أمام مناقشات جديدة ، هل أمر مثل هذا ممكن؟

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

أعتقد أن فريقك في حالة حبس بخار بعد أن جعل هذا الخلد في الجبل.

المعنى: تعتبر علامات التبويب مكونة للمفهوم الأوسع لإدارة المستندات ، وليست مرادفة له. توجد مشكلات أخرى تم تقديمها بالفعل للتعامل مع مجالات أخرى لإدارة مستندات vscode.

لقد ناقشنا بالفعل أفكار UX الخاصة بنا عبر المشكلات المفتوحة (راجع https://github.com/Microsoft/vscode/issues؟q=is٪3Aopen+is٪3Aissue+label٪3Aux) ، أفترض أننا سنفعل نفس الشيء لإدارة المستندات وعلامات التبويب.

أعتقد أيضًا أننا لا نرغب في إجراء هذه التحسينات عبر الامتدادات بل نرغب في جعلها مفهومًا أساسيًا في منضدة عمل VS Code.

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

bpasero شكرًا جزيلاً لك ، هذا كل ما أردت معرفته. :)

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

بدون قراءة هذا الموضوع بالكامل ، أعطي فكرة كبيرة: +1: حول هذا الموضوع.

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

+1

ضروري للغاية.

+1

أعمل على العديد من أنواع الملفات المختلفة أثناء التطوير ، لذلك أرغب غالبًا في إنشاء مجموعة علامات تبويب على الجانب الأيمن لنوع واحد من الملفات ومجموعة علامات تبويب أخرى على اليسار لأنواع أخرى من الملفات. على سبيل المثال ، عند العمل على كود منقلة / webdriverjs ، أود الاحتفاظ بجميع "كائنات الصفحة" على اليمين وجميع "المواصفات" على اليسار ، مجمعة بشكل منفصل ومنطقي. وبالمثل عند العمل على عناصر الواجهة الأمامية ، سأحتفظ بمجموعة علامات تبويب على اليمين لجميع ملفات js / ts ومجموعة أخرى على اليسار لـ html و css.

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

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

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

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

يرجى إعادة مجموعات علامات التبويب إلى رمز VS.

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

ChrisMiami: إلا انها ليست . (من المحتمل أن أكون راغبًا في التعايش معه إذا كان كذلك).

هههه

يوم الخميس ، 17 مارس 2016 الساعة 4:59 صباحًا Kenneth G. Franqueiro <
[email protected]> كتب:

ChrisMiami https://github.com/ChrisMiami : ما عدا أنه ليس كذلك
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

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

@ nub340 لا يعتمد VSCode على Atom ولكن Electron الذي تم تصنيعه بواسطة نفس المجموعة التي تعمل على Atom.

+1 الرجاء إضافة !!!

أعتقد أيضًا أن هذه ميزة مفقودة تمامًا في محرر رائع.

يرجى إضافة علامات تبويب كخيار ، أو السماح بمكوِّن إضافي لجهة خارجية لوظيفة علامة التبويب.

أول ما أدهشني بشأن VSC (بعد الاسم السخيف) هو كيف _عظيم_ عدم وجود علامات تبويب.

لدي حاليًا 8 ملفات مفتوحة - علامات التبويب غير مجدية بالنسبة لي ، لأن أسماء الملفات لن تظهر في علامات التبويب.

I _adore_ CTRL + TAB وقائمة "ملفات العمل".

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

leegee إنهم ليسوا "

أعط الآلاف من الأشخاص الذين صوتوا لعلامات التبويب ، أعتقد أن الشيء الوحيد "غير المجدي" هنا هو تعليقك :)

@ jon64digital : رأيت أن المشروع قد طلب تعليقات عامة من المستخدمين حول احتمال وجود علامات تبويب - لقد

@ jon64digital قال leegee إنهم لا طائل منهم _ بالنسبة له _ وليس بشكل عام. أؤيد علامات التبويب تمامًا ولكني أوافق على أنها يجب أن تكون خيارًا يمكن إيقاف تشغيله لمن لا يستخدمها. دعونا نجعل المناقشة حضارية ولا نلجأ إلى الهجمات الشخصية. لا أحد لديه رأي خاطئ. هم فقط ... الآراء.

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

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

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

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

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

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

متفق عليه ، أود ذلك كخيار ، وليس إجباره.
يوم الثلاثاء ، 22 آذار (مارس) 2016 ، الساعة 6:22 صباحًا إيال سولنيك [email protected]
كتب:

@ nub340 https://github.com/nub340 بالضبط! البعض منا يحب علامات التبويب لأن
لقد كانوا دائمًا جزءًا من تجربتنا كمطورين / مستخدمين ، وأنا شخصياً أحب
لرؤية الملفات التي أعمل عليها في الأعلى ، ليس هناك ملازم
ميزة لعلامات التبويب على ملفات العمل ولكن هذا هو بالضبط ما يحبها البعض منا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

لم يكن لدينا علامات تبويب على Vic-20 ...

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

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

لقد قمت بنشر هذا النص هنا: https://github.com/Microsoft/vscode/issues/101

كما أنه صالح لهذه المناقشة. سأكون سعيدًا برؤية رد @ bpasero .

اريد هذه الميزة. نهاية المناقشة. اللعنة على آرائك @ bpasero لا يهمني ما تعتقد أنه صحيح وما هو غير صحيح. الأمر نفسه يتعلق بعلامات التبويب رقم 224. إنك تحاول إقناعنا بأن حلك أفضل. مرة أخرى يمارس الجنس مع الحل الخاص بك. كلنا نقوم بالأشياء بشكل مختلف ولا أحد يهتم بما تعتقده. أنا أستخدم vscode فقط بسبب الدعم الكبير للطباعة والزاوية 2. وإلا فإنني أكرهه لأنه يفتقر إلى الميزات التي يمتلكها المحررون العاديون مثل SublimeText و Atom و Brackets

HahaPeterMtj ، شكرًا

يبدو أن bpasero لديه عادة التصويت ضد وتشويه سمعة أي ميزة لن يستخدمها بنفسه شخصيًا ولا تناسب سير عمله الشخصي.

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

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

@ jon64digital يمكنه التصويت

أنا لا أتفق مع رده الأولي أيضًا ، فقال "لا" ليس مهنيًا وقحًا تمامًا في رأيي ولكني أعتقد أن المجتمع يمكنه أن يعمل بشكل أفضل وأن يظل متحضرًا بغض النظر عن رأي الناس.

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

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

دعونا لا نحول هذا إلى حرب نار ونبقيها بناءة ، من فضلك!

eyalsk

لم أكن أحاول بدء حرب مشتعلة ، أو التحدث عن القمامة ، لكنني 100٪ متمسكة بما قلته. ربطت شركة MS منتجاتها من الناحية التاريخية بنظام التشغيل الخاص بها ومع بعضها البعض لإجبار الناس على استخدام برامجهم لأنهم يعرفون أنه ليس من الجيد الوقوف بمفردها. أعرف الكثير من الأشخاص الذين يتعين عليهم استخدام MS Office في العمل ، وكان علي استخدام Visual Studio من قبل لأنه لم يكن لدي خيار آخر ويمكنني إحصاء عدد الأشخاص الذين سيستخدمون Internet Explorer طوعًا بأصابع يد واحدة. لقد كانوا حتى موضوع دعاوى مكافحة الاحتكار بسبب هذه الممارسات ، لذا فإن القول بأنه لا أحد يجعل أي شخص يستخدم برنامج MS هو أمر ساذج.

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

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

فقط بلدي 2c.

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

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

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

أعرف الكثير من الأشخاص الذين يتعين عليهم استخدام MS Office في العمل ،

الناس ليسوا مجبرين على استخدام MS Office ، هذا هو قرار صاحب العمل ، Libre office هو منتج رائع وهو بديل جيد تمامًا.

كان علي استخدام Visual Studio من قبل لأنه لم يكن لدي خيار آخر

لا أعلم _لماذا_ لم يكن لديك خيار ولكن بالتأكيد لديك خيارات اليوم! لطالما كان لدي خيار حتى عندما استخدم الأشخاص Visual Studio بكثافة لتطوير .NET ، استخدمت SharpDevelop و Vim و Notepad ++ ، ولم أواجه مشكلات مطلقًا في استخدام برامج تحرير متعددة ، ولست من محبي المصممين على أي حال ...

بالنسبة إلى C / ++ لديك المزيد من الدعم من المحررين و IDEs إلا إذا كنت تستخدم VC ++ :)

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

يمكنني إحصاء عدد الأشخاص الذين قد يستخدمون Internet Explorer طوعًا بأصابع يد واحدة.

أنت محق في أن Internet Explorer كان سيئًا للغاية حتى الإصدار 9 ، لكنه تحسن كثيرًا منذ ذلك الحين ، وعلى الرغم من أنني مستخدم FireFox ، فأنا لا أحكم على Microsoft على ماضيهم ، بل أحكم عليهم بناءً على من هم الحاضر ويبدو جيدا!

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

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

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

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

بالضبط! على الرغم من أنني لا أعتقد أن إعطاء الناس ما يريدون أمر جيد من وجهة نظر التصميم. :)

لكن من الواضح أن bpasero ليس واحدًا منهم. موقفه المنغلق لا يُنسب إليهم ، واعتقدت أنه من المضحك أن

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

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

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

eyalsk نعم ، هذا بالضبط ما

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

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

PeterMtj أعتقد أنه سيتعين علينا الموافقة على عدم الموافقة. :)

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

شكرًا للجميع على شغفكم وتعليقاتكم ، مما يساعدنا على جعل VS Code أفضل منتج يمكن أن يكون.

TIA لإضافات إمكانية الوصول - ستحدث فرقًا كبيرًا بالنسبة لنا
نصف أعمى

في السبت ، 26 مارس 2016 ، 01:38 كتب إريك جاما ، [email protected] :

أردت القفز وتقديم بعض المعلومات الأساسية الإضافية لهذه المشكلة.
نحن على وشك الانتهاء ، وهو معلم رئيسي في البرمجة. التركيز الرئيسي بالنسبة لنا
في الأشهر الستة الماضية كان دعم الوصول والترجمة. هذه
لم يترك لنا أي دورات في منطقة واجهة المستخدم للعمل بنشاط على تعليقات علامات التبويب.
الآن بعد أن أصبحت معظم خانات الاختيار في خطة مارس (# 3555
https://github.com/Microsoft/vscode/issues/3555) يتم فحصها ، نحن
بدأت ببطء في البحث مرة أخرى. في أبريل ، سنقوم بتكثيف هذا الموضوع.
لعب bpasero https://github.com/bpasero دورًا رئيسيًا في
تطوير تجربة المستخدم الخاصة بنا وسيكون هذا هو التطور الرئيسي التالي.

شكرًا للجميع على شغفكم وتعليقاتكم ، مما يساعدنا في جعل VS Code هو
أفضل منتج يمكن أن يكون.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

egamma أشكرك حقًا أنت bpasero أثار غضب الناس وكان من الممكن تجنب ذلك إذا قدم أفكارًا عن سبب اعتقاده أن علامات التبويب لا ينبغي أن تكون خيارًا بدلاً من مجرد قول "لا".

على أي حال ، دعنا نركز على الحاضر ، هل هناك أي بناء جديد قبل // البناء / الحدث؟ :د

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

Tyriar ، مسكتك شكرا! :)

على أي حال ، دعنا نركز على الحاضر ، هل هناك أي بناء جديد قبل // البناء / الحدث؟ :د

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

egamma شكرا! ؛)

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

وتعقد الجلسات الأولى يوم الأربعاء. يرجى التسجيل هنا إذا كنت مهتمًا: https ://

رائع!
يوم الاثنين 4 أبريل 2016 الساعة 3:54 صباحًا Steven Clarke [email protected]
كتب:

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

وتعقد الجلسات الأولى يوم الأربعاء. الرجاء التسجيل هنا إذا
انت مهتم:
https://cal friendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

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

3 و 4 صباحا فقط؟ لا أوقات أخرى؟ لا أستطيع أن أجعل 3/4 صباحًا بتوقيت المحيط الهادي يوم الأربعاء.

يوم الإثنين 4 أبريل 2016 الساعة 8:14 صباحًا براد جاشلر [email protected]
كتب:

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

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

سيكون من الجيد إذا كان لديك توقيت وفقًا لـ PST ، يمكن للكثيرين (بمن فيهم أنا) المشاركة

{التليفون المحمول}

في يوم الاثنين ، 4 أبريل 2016 الساعة 8:50 صباحًا -0700 ، كتب "Glenn Block" [email protected] :

3 و 4 صباحا فقط؟ لا أوقات أخرى؟ لا أستطيع أن أجعل 3/4 صباحًا بتوقيت المحيط الهادي يوم الأربعاء.

يوم الإثنين 4 أبريل 2016 الساعة 8:14 صباحًا براد جاشلر [email protected]

كتب:

نتطلع إلى سماع ملاحظاتك حول التصميمات الجديدة التي نستكشفها

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

تعليق ستيفن أعلاه!

-

أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

نعم من فضلك. أنا مواطن أود أن أكون جزءًا من المحادثة.

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

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

يوم الإثنين 4 أبريل 2016 الساعة 9:44 صباحًا Steven Clarke [email protected]
كتب:

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

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

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

كما قلت ، سنحاول جدولة الجلسات في مناطق زمنية مختلفة في المستقبل.

شكرا على كل الاهتمام.

أرى ، حسنًا ، أعتقد أنهم ملأوا على الفور (وهو أمر جيد)
يوم الإثنين 4 أبريل 2016 الساعة 11:30 صباحًا Steven Clarke [email protected]
كتب:

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

كما قلت ، سنحاول جدولة الجلسات في مناطق زمنية مختلفة في
المستقبل.

شكرا على كل الاهتمام.

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

هل يمكنك / هل تقوم بتسجيل الجلسات؟

يوم الإثنين 4 أبريل 2016 الساعة 11:32 صباحًا جلين بلوك جلين. كتب [email protected] :

أرى ، حسنًا ، أعتقد أنهم ملأوا على الفور (وهو أمر جيد)
يوم الإثنين 4 أبريل 2016 الساعة 11:30 صباحًا Steven Clarke [email protected]
كتب:

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

كما قلت ، سنحاول جدولة الجلسات في مناطق زمنية مختلفة في
المستقبل.

شكرا على كل الاهتمام.

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

أتمنى لو رأيت هذا في وقت سابق حتى أتمكن من التسجيل. لما يستحق ، أتمنى ألا تطبق علامات التبويب أبدًا. لقد تقدمت من vim إلى TextMate إلى Sublime إلى Atom والآن إلى VS Code (مع الكثير من IDEs على طول الطريق) ، لذلك كان لدي الكثير من الخبرة مع علامات التبويب. بالنسبة لي ، هم عكاز يستخدمه الناس ولا يتخطونه أبدًا. تعد إدارة العديد من علامات التبويب المفتوحة في مشروع كبير بمثابة تمرين في الإحباط يضيف مهمة روتينية أخرى لست بحاجة إليها. ننسى إغلاق القليل وسرعان ما يصبح ميؤوسًا منه. إلى أولئك القلائل منكم الذين لديهم الانضباط لعدم مواجهة هذا أبدًا ، مجد. لكن لماذا تنفق الطاقة الذهنية في مهمة غير ضرورية؟

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

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

كما سبق indiejames

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

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

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

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

أحصل على البعض تمامًا قد يفضل عدم وجود علامات تبويب وأنا لا أقول للتخلص مما هو موجود ولكن وجود سير عمل مدعوم لعلامة التبويب سيكون أمرًا رائعًا.
في الثلاثاء ، 5 أبريل 2016 في تمام الساعة 7:32 صباحًا ، كتب خطأ [email protected] :

إذا قمت بتنفيذ علامات التبويب ، فيرجى دعم صفوف متعددة للعديد من الملفات. انا اكره
وجود شريط تمرير على شريط علامات التبويب الخاص بي. تطبيق علامات التبويب المفضل لدي هو Tabs
الاستوديو https://tabsstudio.com/.

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

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

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

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

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

ليس من الصعب جدًا دعم عمليتي سير عمل مختلفتين للتنقل أو حتى أكثر من عمليتين ، ما يصعب حقًا هو الحصول على التصميم الصحيح!

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

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

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

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

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

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

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

آمل حقًا أن يكون بعض مطوري Python و c / c ++ في الاجتماع لأن سير عملهم يختلف عن سير عمل مطوري JavaScript

شكرا ستيفن لأخذ الوقت للتحدث معي!
هذا التفاعل مع المجتمع أمر مشجع حقًا ، وأنا أستمتع به
بعد تطوير vscode!

في 6 أبريل 2016 ، الساعة 19:41 ، مايكل والاس لورينز < [email protected]

كتب:

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

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

آمل حقًا أن يكون بعض مطوري Python و c / c ++ في الاجتماع كـ
سير عملهم يختلف عن سير عمل مطور JavaScript

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

شكرًا TurkeyMan ، تمت الدردشة معك في وقت سابق اليوم.

بالنسبة لأي شخص آخر لم يتمكن من المشاركة ، سنقوم بتشغيلها بشكل منتظم حتى تكون هناك فرص للمشاركة في تاريخ لاحق.

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

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

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

+1
يوم الأربعاء ، 6 أبريل 2016 ، الساعة 7:36 صباحًا ، Peter Petrov [email protected]
كتب:

stevencl https://github.com/stevencl هل من الممكن نشر ملخص
من الجلسات (أو حتى أفضل ، التسجيلات) لأولئك منا غير القادرين
للمشاركة ، لكنك لا تزال مهتمًا بتقديم التعليقات.

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

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

  1. التنقل بدون الماوس
  2. القدرة على التنقل للأمام والخلف ضمن مجموعة الملفات المفتوحة
  3. إغلاق الملفات بسهولة

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

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

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

وآمل أن يجعل بعض معانيها. أحاول تحسين سير العمل الخاص بي قدر الإمكان ، واستخدام لوحة المفاتيح وتجنب الماوس لأنه يبطئ كل شيء بشكل كبير. أعاني من هذا في VScode أكثر مما كنت أواجهه سابقًا في أي محرر آخر (textmate ، vim ، sublime ، flash ، eclipse ، إلخ ...)

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

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

نشكرك على جميع التعليقات والتفاصيل الخاصة بكيفية عمل VS Code أو عدم عمله من أجلك.

فقط لأنه لا يبدو أن أحدًا قد ذكرها وأعتقد أنني لست وحدي في هذا الأمر: بالنسبة لي ، فإن علامات التبويب في المحرر تدور حول الذاكرة المكانية - أي أين أنا ، وأين الأشياء من حولي؟

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

بالنسبة لي ، فإن سجل الملفات المرتب زمنيًا يتعارض تمامًا مع هذا الفهم الحدسي للفضاء. إذا علمت أن "main.java" أو المفتاح T على لوحة المفاتيح الخاصة بي في وضع معين ، فلا أريد أن يتحرك إلا إذا قمت بتحريكه فعليًا ومتعمدًا. إذا تحركت من تلقاء نفسها ، فأنا بحاجة إلى التوقف والتفكير والعثور عليها. تخيل جهاز تحكم عن بعد في التلفزيون به عجلات تحركت بنفسها حول منزلك بمفردها ، أو لوحة مفاتيح أعادت ترتيب المفاتيح بناءً على مدى استخدامك لكل حرف مؤخرًا! ستكون الفوضى! :-)

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

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

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

أدرك أن هذه مجرد آرائي ومعظم الناس يختلفون معها ، لكنها Visual Studio _Code_. للمبرمجين / المطورين. وقد أدرك المطورون منذ وقت طويل أن shell> gui لمعظم (وليس كل) الأشياء ، وأن الاستعارات المكتبية ، رغم سهولة تعلمها ، محدودة للغاية.

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

لأولئك منكم الذين حاولوا العمل بدون علامات تبويب ولا يمكنهم التكيف أو الشعور بصدق بعلامات التبويب تجعلك أكثر إنتاجية ، يمكنني قبول أن هذا مجرد خلاف صادق. ولكن لأولئك الذين يجادلون في الاستعارات الجسدية لأنهم "عملوا لمدة 30 عامًا!" أود أن أسأل هل نحتاج حقًا إلى _another_ TextMate / Sublime / Atom؟ ألا يجب أن نحاول تحريك الظرف؟

ليس لدي أدنى شك في أنني من الأقليات هنا (لكن هذا لا يخطئني) ، لذلك هذا هو آخر تعليق سأدلي به. لا تتردد في التراكم :)

قررت التحقق من VS Code لمعرفة ما إذا كان يمكن أن يكون بديلاً مجانيًا لـ Sublime ، ولكن بدون المستندات المبوبة ، فهو ليس بداية. تعد القدرة على تعيين VS Code في حالة واحدة ، وفتح مستندات متعددة ، والتبديل بسهولة بينها شرطًا أساسيًا لأي محرر نصوص. يعد الاحتفاظ ببرنامج Explorer مفتوحًا بمثابة حل بديل ، ولكن ليس من غير الطبيعي وجود علامات تبويب يسرى بدلاً من علامات التبويب العليا كما هو الحال في VS والمتصفحات و Sublime وما إلى ذلك. Ctrl-Tab به العديد من المشكلات ، يتعين على المرء أن ينظر إلى لوحة المفاتيح ويحرك يده (لشيء آخر غير الماوس) ، والآخر أنه غير بديهي. من الواضح أن أي شخص يقترح أن محررًا بدون علامات تبويب هو أي شيء أكثر من BloatedNotepad لم يقم مطلقًا بأي تحرير جاد لمستندات متعددة ، كما هو مطلوب عند قيام مصحح الأخطاء بالتصفح عبر شيء يحتوي على أكثر من ملف واحد كمدخل للمترجم.

تضمين التغريدة
لا تتعلق علامات التبويب بالإنتاجية بالنسبة لي. حول الإدراك.

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

indiejames @ أستخدم ctrl + (shift +) علامة التبويب للتنقل بين علامات التبويب كثيرًا ، وليس بالضرورة الماوس. واحدة من أكبر نقاط قبضتي على ملفات العمل هي نفس ملفات

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

تعمل حجة استخدام الفتح السريع حصريًا أيضًا في Sublime Text مع علامات التبويب كما هو الحال في VS Code مع ملفات العمل. علامات التبويب لا تمنع سير العمل هذا على الإطلاق.

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

  • باستخدام Ctrl + E / + E لفتح الملفات الحديثة بسرعة.
  • باستخدام Ctrl + Tab لتبديل الملفات الحديثة

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

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

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

الجزء الأيسر

نموذج 1 ملف (علامة تبويب) | عرض ملف واحد (علامة تبويب) | ملف تحكم 1 (علامة تبويب)

الجزء الأيمن

نموذج 2 ملف (علامة تبويب) | عرض ملف 2 (علامة تبويب) | ملف وحدة التحكم 2 (علامة تبويب)

يتيح لي هذا الإعداد تحديد ملفات النموذج بسرعة لكلا المكونين اللذين أعمل عليهما للمقارنة أو عرض الملفات عندما يكون لدي قبعة UI / UX الخاصة بي. لا يمكن تحقيق ذلك على الإطلاق بكفاءة مع ملفات العمل ، خاصة إذا كان لديك ملفات أخرى مفتوحة أيضًا (مثل CSS ، نصوص db ، إلخ). أقوم بالكثير من UI / UX وهذه ممارسة شائعة إلى حد بعيد. إذا كنت مطورًا لواجهة Java الخلفية أو DBA ، فلا ، لن يكون هذا مطلبًا. ولكن بالنسبة للغالبية العظمى منا ، فإن عدم وجود علامات تبويب (وألواح رأسية / أفقية مبوبة) يعد عائقًا كبيرًا. بينما أستحق VSCode على المدى القصير ، لدي تحفظات جدية تلتزم به بسبب هذه القدرة المفقودة. لا يمكن لأحد أن يقنعنا بأن علامات التبويب غير مجدية وأن قائمة ملفات العمل ليست ابتكارًا (يحتوي Adobe Brackets أيضًا على قائمة ملفات العمل وهي موجودة منذ عام 2012).

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

فقط بلدي 2 ¢ ...

بينما قمت بتوصيل معظم هذا إلى @ bgashler1 بالفعل ، سأكتب القليل هنا لشرح السلوك المثالي بالنسبة لي.

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

json { "key": "ctrl+shift+w", "command": "workbench.files.action.closeAllFiles" }, { "key": "ctrl+w", "command": "workbench.files.action.closeFile" },

  1. يجب أن تكون الملفات الموجودة في المحرر "مكدسة" ، بحيث يتم عرض الملف الأخير في مكدس MRU عند إغلاق ملف واحد.
  2. يجب أن يستعيد ctrl + shift + t آخر علامة تبويب تم إغلاقها. يتعارض رابط المفاتيح هذا مع workbench.action.tasks.test في vscode ولكنه مفتاح اختصار قياسي جدًا في البيئات المبوبة. لقد قمت بإنشاء طلب ميزة للأمر هنا https://github.com/Microsoft/vscode/issues/3989
  3. يجب أن يتم تدوير ctrl + tab و ctrl + shift + tab فقط خلال الملفات الموجودة في قائمة "ملفات العمل" ، وليس الملفات التي تمت معاينتها (نقرة واحدة في المستكشف ثم انتقل بعيدًا).
  4. أريد وضع ملفات العمل الخاصة بي على طول الجزء العلوي من المحرر. أسباب ذلك هي:

    • أريد أن أتمكن من رؤية ملفات العمل الخاصة بي بصريًا ، بغض النظر عن الشريط الجانبي الذي فتحته. ذات صلة: https://github.com/Microsoft/vscode/issues/3360

    • على مدار ما يقرب من عقدين من الزمن كنت أبرمج ، كنت أبحث عن محرر ملفات العمل الخاصة بي. إنها عادة يصعب التخلص منها.

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

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

أستخدم Ctrl + Tab كثيرًا في VSCode لكنني أعتقد أن التجربة في Visual Studio أفضل بكثير لأنه بالإضافة إلى الملفات يمكنني أيضًا الانتقال إلى أجزاء أخرى من واجهة المستخدم ، وأستخدمها للانتقال إلى Package Console Manager ، مستكشف الحلول الخ ...

Tyriar نقاط عظيمة!

[تحذير من الفلسفة!]

لماذا يعتبر ctrl+tab أكثر إفادة من مفهوم "ملفات العمل" كما هو؟ هذا هو السؤال الجوهري. أنا شخصياً أعتقد أن هناك مشكلتين في اللعبة.

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

ثانيًا ، يعرض لك ctrl+tab _ جميع_ الملفات التي رأيتها مؤخرًا بترتيب زمني عكسي. تُظهر لك "ملفات العمل" فقط الملفات التي نقرت عليها نقرًا مزدوجًا أو أجريت تغييرات عليها وبالترتيب الذي أزعجته لفتحها. المعايير والأوامر تعسفية ولا علاقة لها بالطريقة التي يفكر بها المبرمجون - القفز ذهابًا وإيابًا بين المتصل والوظيفة والطبقة والمستهلك.

(الآراء. قد تختلف المسافة المقطوعة.)

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

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

لقد اكتشفت كيفية الحصول على معظم ما كنت أفتقده من السامي في سياق هذه المشكلة:

[
  { "key": "cmd+w", "command": "workbench.files.action.closeFile" },
  { "key": "cmd+shift+]", "command": "workbench.files.action.openNextWorkingFile" },
  { "key": "cmd+shift+[", "command": "workbench.files.action.openPreviousWorkingFile" }
]

stephenmartindale لست متأكدًا مما إذا كان أي شخص قد قام بطلب ميزة لتعطيل "ملفات المعاينة" حتى الآن.

stephenmartindale نحن نبحث عن طريقة لتثبيت "ملفات المعاينة" لتظل مفتوحة - بما في ذلك ملفات للقراءة فقط.

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

أنا حقًا أحب تدفق Sublime هنا. نقرة واحدة تنتقل إلى الملف ،
انقر نقرًا مزدوجًا عليه يظل مفتوحًا.
يوم السبت ، 9 أبريل 2016 الساعة 11:49 صباحًا Brad Gashler [email protected]
كتب:

stephenmartindale https://github.com/stephenmartindale نحن نبحث
في طريقة لتثبيت "ملفات المعاينة" لتظل مفتوحة.

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

Tyriar ، @ bgashler1 ، stevencl أعتقد أنه من الأفضل أن يكون لديك منشورتان جديدتان لعلامات التبويب وملفات العمل لجمع التعليقات.

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

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

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

أود أن أؤكد أن Ctrl + W يجب أن يغلق ليس فقط المحرر الحالي ، ولكن ملف العمل المفتوح المقابل. بالنسبة لي ، هذا هو أكبر عيب في التنفيذ الحالي. هذا وحقيقة أن Ctrl + Tab يسرد جميع الملفات الحديثة ، وليس فقط الملفات الموجودة في ملفات العمل. عند التفكير الثاني ، قد يكون التحذير الثالث هو أن النقرة الواحدة لا تفتح ملفًا كملف عامل ، ولكن تحريره يؤدي إلى ذلك.

+1

csholmq يمكنك فعل ذلك الآن ، راجع روابط المفاتيح المخصصة في https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479

Tyriar هذا يعالج تقريبًا جميع

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

zunama لم ننسى المستخدمين الذين يريدون علامات تبويب وإدارة محسنة للمستندات. الآن وقد أصبحنا 1.0 ، فمن أهم أولوياتنا معالجة هذه المخاوف. ستأتي أشياء رائعة إلى VS Code قريبًا.

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

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

+1/0

+1

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

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

csholmq لا أعرف ما إذا كنت المنشورات التي لا تحتوي على شيء سوى +1 ، -1 فيها ، لا تضيف أي قيمة ، يمكن لإدخال أكثر فائدة تمت كتابتها بدلاً من كتابة منشور بـ +1 ، -1 ... فقط رأيي ، سأقوم بتعديله والتأكيد عليه في رسالتي.

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

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

لا يعمل الاستطلاع عندما تريد الابتكار. مثال:


أي من أساليب التنبيه هذه ستكون الأكثر إنتاجية بالنسبة لك؟

  • شيئا ما. (جرب شيئًا جديدًا قد يكون أفضل)
  • نوافذ التبويب. (أسلوب العمل القديم الجيد الذي تعلمت أن تحبه).

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

لأكون صادقًا ، كانت إحدى السمات المميزة لـ VS Code بالنسبة لي هي عدم وجود علامات تبويب. لم أدرك (في البداية) أنهم مفقودون! كانت وجهة نظر مثيرة للاهتمام.

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

في عالم كل شيء هو نفسه ، من المنعش أن يكون لديك هوية.

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

PSS. فكرة - إذا كانت هناك علامات تبويب في مقابل رمز يومًا ما ، فربما يكون من الأفضل تحديد الحد الأقصى لعدد علامات التبويب المفتوحة ، أي إغلاق علامات التبويب القديمة تلقائيًا عند فتح علامات تبويب جديدة؟

RussBaz لا أعتقد أن تحديد عدد علامات التبويب فكرة جيدة لأن هذا الرقم يمكن أن يتغير من مستخدم لآخر ولكن ربما يكون هذا خيارًا كالتالي:

tabs.autoClose = "غير مرئية" ، "إيقاف" ، "الوقت" ، x حيث x هي رقم

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

مثال حالة الاستخدام: أقوم حاليًا بالتبديل بين 6 علامات تبويب باستمرار في الذرة.

ينمو هذا إلى حوالي 10 عندما أحتاج إلى العمل على أقسام أعمق. أنا استخدمهم جميعًا! لذا فإن الإغلاق وإعادة الفتح سيكونان بمثابة ألم. يمكن أن يكون لدي ملفات ضخمة في مكانها ولكن هذا سيكون أكثر إيلامًا بكثير للتعامل معها حيث أنه سيتضخم إلى 6k سطر في ملف إذا قمت بتضمين كل جزء من وحدة في ملف واحد.

@ قياس أنا أتفق

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

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

هل يمكننا التوقف الآن عن نوع "Mac vs Windows" ، "Android vs IPhone"
المناقشات حول أي طريقة أفضل: "علامات التبويب مقابل عدم علامات التبويب"؟ كلاهما جيد
والأشخاص المختلفون لديهم ما يفضلونه.

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

هل يعارض أي شخص وجود كلا الطريقتين كخيارات يمكنك تشغيلها أو
قبالة اعتمادا على تفضيلاتك؟

أعتقد أن الأمر يتعلق بهذين الخيارين:

1) إضافة علامات التبويب كتفضيل. على لمن يحبونها ومن أجل أولئك الذين
لا تفعل.

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

لماذا قد تصوت حتى للخيار 2 عندما يكون لديك خيار تحويلها
إيقاف؟
في 15 أبريل 2016 ، الساعة 7:32 مساءً ، "جيمس ماكلولين" [email protected]
كتب:

Measuring https://github.com/Measuring أنا أتفق معك وأختلف معك.
هناك أشياء تحتاج إلى الابتكار ولكن على المرء أولاً أن يسأل ماذا
حول سير العمل ، هل يمكننا تحسينه عن طريق إزالة علامات التبويب. حسنا بالنسبة لي ، كل
محرر واحد أستخدمه للتطوير له واجهة علامة تبويب لأنه كذلك
من الشائع أن يعمل على تطوير ما بين 5-10 ملفات في وقت واحد بدون
تذكر الاسم الدقيق للملفات ولا ترتيب فتحها
في. لذلك علي أن أسأل ، كيف جعلتها هذه الواجهة الجديدة أفضل؟ كيف هو
انها مبتكرة؟ اسأل أولاً ، كيف يستخدمونها ، ثم اسأل ، كيف يمكنني صنعها
من الأفضل. بالنسبة لمسألة الثلاث دقائق ، سأفترض أن Code هو
لا يختلف كثيرًا عن Sublime أو Atom وإذا كان ذلك صحيحًا منذ البداية
تكافح للعمل معها أو تظهر لشخص ما بكفاءة ما يحتاج إلى القيام به
بين الملفات لإنجاز شيء ما ، سأستخدم شيئًا يعمل
أفضل لاحتياجاتي الآن وألقِ نظرة على Code بعض الإصدارات القادمة
عندما يكون جاهزا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@ tones411 سيختار بعض الأشخاص الخيار 2 لمجرد اعتقادهم أن إضافة علامات التبويب

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

قد يرغب بعض الأشخاص في الحصول على شيء مثل المخازن المؤقتة لـ Vim ولا يرغبون في عدم وجود علامات تبويب أو ملفات عمل على الإطلاق.

ربما يمكن استخدام شيء مثل Vim buffers كسطح لـ VSCode حيث يمكننا استخدام الأوامر لإدارة الملفات ثم فوق ذلك وضع الأسس لكل سير عمل سواء كانت علامات تبويب أو ملفات عمل أو أي شيء آخر غدًا.

احسنت القول. لقد تحول هذا إلى نقاش ديني. من الواضح من هذا
سلسلة طويلة من الناس هنا متحمسون لامتلاكها
علامات التبويب وتعتقد أنها مطلوبة / تسهل سير عملها. هناك
الآخرين الذين لا يعتقدون أن علامات التبويب ضرورية وأنهم يمثلون عائقًا.

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

أنا شخصياً أعتقد أنها مفيدة ، لكنني لن أوقف أحدًا
من استخدام ملفات العمل إذا كان ذلك يناسبهم. انها لا تعمل بالنسبة لي.
يوم الجمعة ، 15 أبريل 2016 الساعة 10:07 مساءً ، كتب tones411 [email protected] :

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

هل يمكننا التوقف الآن عن نوع "Mac vs Windows" ، "Android vs IPhone"
المناقشات حول أي طريقة أفضل: "علامات التبويب مقابل عدم علامات التبويب"؟ كلاهما جيد
والأشخاص المختلفون لديهم ما يفضلونه.

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

هل يعارض أي شخص وجود كلا الطريقتين كخيارات يمكنك تشغيلها أو
قبالة اعتمادا على تفضيلاتك؟

أعتقد أن الأمر يتعلق بهذين الخيارين:

1) إضافة علامات التبويب كتفضيل. على لمن يحبونها ومن أجل أولئك الذين
لا تفعل.

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

لماذا قد تصوت حتى للخيار 2 عندما يكون لديك خيار تحويلها
إيقاف؟
في 15 أبريل 2016 ، الساعة 7:32 مساءً ، "جيمس ماكلولين" [email protected]
كتب:

Measuring https://github.com/Measuring أنا أتفق معك وأختلف معك.
هناك أشياء تحتاج إلى الابتكار ولكن على المرء أولاً أن يسأل ماذا
حول سير العمل ، هل يمكننا تحسينه عن طريق إزالة علامات التبويب. حسنًا بالنسبة لي ،
كل
محرر واحد أستخدمه للتطوير له واجهة علامة تبويب لأنه كذلك
من الشائع أن يعمل على تطوير ما بين 5-10 ملفات في وقت واحد بدون
تذكر الاسم الدقيق للملفات ولا ترتيب فتحها
معهم
في. لذلك علي أن أسأل ، كيف جعلتها هذه الواجهة الجديدة أفضل؟ كيف
يكون
انها مبتكرة؟ اسأل أولاً ، كيف يستخدمونه ، ثم اسأل ، كيف يمكنني ذلك
يصنع
من الأفضل. بالنسبة لمسألة الثلاث دقائق ، سأفترض أن المدونة
يكون
لا يختلف كثيرًا عن Sublime أو Atom وإذا كان ذلك صحيحًا من البداية
أنا
تكافح للعمل معها أو تظهر لشخص ما بكفاءة ما يحتاج إلى القيام به
بين الملفات لإنجاح شيء ما ، سأستخدم شيئًا ما
يعمل
أفضل لاحتياجاتي الآن وألقِ نظرة على Code بعض الإصدارات القادمة
عندما يكون جاهزا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

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

تم ذكر معظم هذه الأشياء ، ولكن ها هي مشاعري:

قائمة WF غير مجدية بشكل أساسي ، لأن إغلاق نافذة محرر لا يغلق الملف من WF. أحتاج بالفعل إلى إغلاق ملف _twice_ ، واستخدام الماوس للقيام بذلك (Ctrl + W _ و_ إغلاق الملف من لوحة WF). إذا أردت ترك الملف مفتوحًا ، فلن أضغط على Ctrl + W - كيف يكون من المنطقي الضغط على Ctrl + W وترك الملف "مفتوحًا" (مرئي في WF). نعم يمكن إعادة تعيين هذا ، لكنني أتحدث عن السلوك الافتراضي لـ WF).

يؤدي النقر فوق ملف في WF أو طريقة عرض الشجرة إلى فتح الملف في نافذة محرر غير مرغوب فيها نصف الوقت على الأقل. إذا كان لديك محرر من لوحتين مع اللوحة اليسرى النشطة ، يفتح "فتح على الجانب" في اللوحة _ right_ ، وليس اللوحة _ new_ ، وبوجود 3 أعمدة سيتم فتحه دائمًا في لوحة موجودة. المشكلة هنا هي أن "الأشياء لا تبقى حيث أضعها". أتوقع أن أخبر المحرر الخاص بي بالمكان الذي أريد أن تكون فيه الأشياء ، وليس للمحرر الخاص بي ليقرر أين يجب أن تستند الأشياء إلى حالة واجهة المستخدم الحالية ثم تغييرها مع تغير حالة واجهة المستخدم في أجزاء أخرى من التطبيق. إحضار _back_ إلى ملف مفتوح سابقًا هو مثل PITA .

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

في رأيي ، يجب أن يعطيني النقر الفردي أو المزدوج على ملف _التصرف نفسه تمامًا _ ، ولكن إذا كنت تريد حقًا "معاينة" بنقرة واحدة لا تظهر في WF / Ctrl + Tab ، فيجب أن يكون هناك _ علامة واجهة مستخدم واضحة_ ذلك نافذة المحرر النشط عبارة عن معاينة وستختفي عند استبدالها.

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

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

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

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

  1. نوافذ التبويب
  2. تعطيل WF
  3. إيقاف التنقل التلقائي شجرة المجلد
  4. علامات تبويب Ripoff في لوحة المحرر العائم (التي تشترك في نفس سلوك لوحة محرر أخرى في الواجهة الرئيسية)

ثم أعتقد أن VS Code ستذهب بعيدًا بعيدًا. محرر رائع ، وأنا على استعداد لتحمل الجوانب السلبية للاستفادة من الباقي ، لكن العديد والعديد من الآخرين ينتظرون هذه الميزات الأساسية القليلة.

أرغب في المساعدة في اختبار UI / UX أو كل ما تفعله لتعليقات / مدخلات المستخدم. اسمحوا لي أن أعرف إذا كان بإمكاني أن أكون في الخدمة.

شكرا لك!

anyong شكرا

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

"explorer.autoReveal": false

أقوم بربط workbench.files.action.showActiveFileInExplorer أيضًا حتى أتمكن من الوصول إلى ملف عشوائي في المستكشف إذا احتجت إلى ذلك.

Tyriar لست متأكدًا من الإصدار الذي تشير إليه ولكني محدث على Insider وهذا الخيار لا يفعل أي شيء حتى الآن.

: +1:

: +1:

bpasero لقد قرأت الرسائل القليلة الأولى في هذا المنتدى فيما يتعلق بمزايا / عيوب علامات التبويب. أفهم أيضًا موقف فريق MSFT من هذا: يتحد الفريق وفقًا لنفس أسلوب الترميز وطور نفس مجموعة ردود الفعل فيما يتعلق بـ ctrl+tab و / أو قسم ملفات العمل. هذا أمر جيد. يتمتع جميع أعضاء الفريق بتدفق موحد للقيام بالأشياء بشكل عام. ومع ذلك ، نحن لسنا جزءًا من هذا الفريق ، ولا نرغب في تطوير نفس مجموعة ردود الفعل. من الناحية المثالية ، ينبغي تحقيق ردود أفعالنا الحالية ، وليس إجبارها على الخروج واستبدالها. يجب أن يساعد المحرر المستخدم.

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

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

Tyriar : لقد جربت إعداد autoReveal الخاص بك في v.1.0.0-insider ولم يفعل شيئًا بالنسبة لي أيضًا. لا يزال المستكشف يقفز عندما لا أريده - وهو أمر مزعج للغاية ، عندما ينتقل تمامًا إلى مكان مختلف عندما أستخدم go-to-definition ويفتح ملفًا آخر.

هذا ما وضعته في ملف التفضيلات الخاص بي: "explorer.autoReveal": false,

anyongstephenmartindale أنت على حق، لم أكن أدرك كيف الجديد كان هذا الإعداد. يجب أن يكون متاحًا في إصدار Insider التالي.

قال حسناstephenmartindale. بدون علامات التبويب ، كل ما لدينا هو notepad.exe بإصداره الخاص من Alt-Tab (والذي تم كسره كما لوحظ عدة مرات أعلاه). كنت أحاول استخدام "ملفات العمل" كما لو كانت علامات تبويب جانبية ، ولكن بعد أسبوع ، أصبحت مستعدًا تمامًا للعودة إلى Sublime وهي مشكلات ، خاصة أنه لا توجد طريقة لجعل هذا الشريط الجانبي دائمًا غير موجود بغض النظر عما يجري في التطبيق. باسم "Visual Studio ..." توقعت على الأقل الميزات الأساسية لمحرر Visual Studio (علامات التبويب ، والقدرة على سحب علامات التبويب هذه إلى النوافذ الخاصة بهم). لا يمكن تفسير سبب إزالة هذه الوظيفة. ربما سأتحقق مرة أخرى في غضون بضعة أشهر وأرى ما إذا كانوا قد قطعوا مسافة كافية لوضع علامة ما قبل ألفا على بناء. في الوقت الحالي ، هذه ليست أكثر من تجربة لواجهة المستخدم ، والسؤال الوحيد هو هل فشلت بالفعل أم أنها تتأرجح على شفا الفشل؟

كما ذكرت معظم التعليقات الـ 259 السابقة ، أود بشدة أن أرى علامات تبويب في VS Code ، على غرار الطريقة التي تعمل بها في Sublime Text. أنا أيضًا ، سأقوم بالتبديل بكل سرور إذا لم تكن هذه الميزة المفقودة. بقدر ما يبدو الأمر غريبًا ، فأنا بحاجة إلى القدرة على فتح أربعة مستندات على الأقل في نفس النافذة حتى أتمكن من التبديل بينها بسرعة.

أوه ، وإذا كانت Microsoft لا تريد مقارنة VS Code بالنص السامي كثيرًا ، فلا ينبغي أن يصنعوا منتجًا يشبهه ويتصرف بشكل مشابه له. إن إبقاء علامات التبويب بعيدًا عن واجهة المستخدم الرسومية ليس طريقة لتثبيط المقارنات مع Sublime Text ؛ إنها طريقة لجعل هذه المقارنات أقل ملاءمة لشركة Microsoft.

SturmB Sublime ليس هو المحرر الوحيد الموجود ولا أعتقد أنهم صنعوا VSCode ليكون نسخة Sublime أخرى ، مثل Atom ليس Sublime ولكن جميع المحررين يشاركون ميزات وهو أمر جيد ، هكذا تحصل على الخيارات !

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

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

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

أنا أحب مفهوم ملفات العمل. لا يتم قياس علامات التبويب بشكل جيد عند فتح العديد من الملفات. مهما حدث ، يرجى التحكم في ملفات العمل!

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

eyalsk :

المشكلة الحقيقية هي الحصول على التصميم الصحيح والتأكد من أن التجربة تبدو رائعة للجميع ، أولئك الذين يحبون علامات التبويب والذين يكرهونها.

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

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

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

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

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

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

: +1:

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

نود الآن مشاركة تصميماتنا المبكرة معك للحصول على ملاحظاتك. سنستضيف جلسة Hangout على Google يوم الخميس 21 أبريل الساعة 4 مساءً بتوقيت جرينتش. إذا كنت ترغب في الانضمام إلينا ، يرجى النقر فوق هذا الرابط في ذلك الوقت: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

سيكون هذا أول اجتماع عام للتصميم ونحن نتطلع إليه.

لقد كنت أستخدم VSCode حصريًا (جاء من WebStorm) ولم أفقد علامات التبويب. في البداية اعتقدت أنني سأفعل ذلك ، لكنني بدأت أحب ملفات العمل أكثر لأنني تمكنت من رؤية المزيد في مساحة أقل ودون الحاجة إلى التفكير في كيفية ترتيب الأشياء أو تجميعها على الشاشة. الآن أستخدم CTRL + TAB بشكل أساسي.

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

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

ثابر على العمل الجيد.

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

RyanEwen أعتقد أنك لست مستخدم اختصار من قبل؟ لأن منصة Intellij Idea لها نفس الاختصارات وقادرة على وضع علامات التبويب في أي مكان (أعلى ، أسفل ، يسار ، يمين ، لا شيء). عند وضعها على اليسار / اليمين ، فإنها تعمل بشكل مشابه لملفات العمل في VSCode. سيكون من الرائع القيام ببعض التجارب. العودة إلى WebStorm باستخدام التحرير والسرد CTRL + TAB مع أعلى علامات التبويب لمعرفة ما إذا كنت لا تحتاج إليها أو أنك مجبر على قبولها كحل بديل. CTRL + E في WebStorm هي أيضًا ملفات حديثة مع ميزات التصفية (اكتب للبحث).

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

: +1:

KayLeung لقد استخدمت CTRL + E في WebStorm ، ولكن نظرًا لوجود علامات تبويب سأسمح لنفسي بالبحث عنها باستخدام الماوس أكثر من مرة. لقد استخدمت مؤخرًا محررًا مبوبًا (Koding.io) عندما لم يكن بإمكاني الوصول إلى VSCode ويمكنني القول بسرية أنني لا أفوت إعداد / ترتيب علامات التبويب. يبدو الأمر مملًا مقارنة بمجرد وجود تاريخ. لقد وجدت نفسي دائمًا منخرطًا في الطريقة التي أريد بها وضع الأشياء والتنبؤ بالملفات التي يجب فتحها بدلاً من مجرد استخدام المحرر والتقليب بين الملفات. من المحتمل أن تكون هذه مشكلة "أنا" جزئيًا أكثر من مشكلة علامة تبويب ، أعرف. قليلا الوسواس القهري ، على ما أعتقد.

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

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

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

تذكير ودود بأننا (أنا و @ bpasero و @ bgashler1) سنشارك أحدث تصميماتنا لعلامات التبويب وملفات العمل في وقت لاحق اليوم في الساعة 4 مساءً بالتوقيت الصيفي البريطاني.

انضم إلينا على هذا الرابط الساعة 4 مساءً بتوقيت جرينتش: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme. نود أن نسمع ملاحظاتك.

تذكير لأي شخص كان يخطط للانضمام إلى جلسات Hangout - إنه قيد التشغيل الآن ، لذا انقر على الرابط أعلاه. فقط ~ 5 أشخاص حتى الآن.

كنت أود حقًا أن أكون هناك ولكن الساعة 11 صباحًا وأنا في العمل غير قادر على الانضمام. أفترض أن شخصًا ما سيكون لديه بعض الأشياء لمشاركتها كتابيًا بعد ذلك؟ :د

لمحة موجزة:

  1. تتصرف علامات التبويب وملفات العمل (التي أعيدت تسميتها بـ "المحررين المفتوحين") بالطريقة نفسها تمامًا ، ويعتمد ذلك فقط على ما إذا كنت تريد العناصر المرئية في الأعلى (علامات التبويب) أو إلى اليسار (المحررون المفتوحون)
  2. يتم تجميع علامات التبويب حسب اللوحة بشكل مرئي في الجزء العلوي ، ويتم تجميع المحررين المفتوحين معًا تحت عناوين "يسار" و "يمين"
  3. نقرة واحدة على ملف لفتح علامة تبويب معاينة (أو "محرر مفتوح") ؛ انقر نقرًا مزدوجًا فوق الملف أو قم بتحريره أو انقر نقرًا مزدوجًا فوق علامة التبويب نفسها للاستمرار
  4. يفتح المصحح جميع الملفات كملفات معاينة ما لم تستمر في تصحيح أخطاء الملف عن طريق اتخاذ أحد الخيارات المذكورة أعلاه
  5. يمكن سحب علامات التبويب / المحررات المفتوحة بين اللوحات
  6. يمكن سحب اللوحات لتحريك مجموعة علامات التبويب بأكملها

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

أفكار المتابعة للمطورين:

  1. نظرًا لأن تدفق علامات التبويب / المحررات المفتوحة هو نفسه تمامًا ، فمن الممكن القيام بشيء مثل هذا: إظهار المحررين المفتوحين عندما يكون المستكشف مفتوحًا ، وإظهار علامات التبويب عند إغلاق المستكشف. يمكننا زيادة العقارات الأفقية للرمز والحفاظ على الوصول إلى علامة التبويب. بافتراض وجود اختصار لإخفاء / إظهار علامات التبويب ، فسيكون هذا مكافئًا للضغط على ذلك و CTRL + B في نفس الوقت - إذا كان يعمل ، فيجب أن يكون خيارًا في الإعدادات: autoShowTabsWhenExplorerClosed أو شيء ما. إذا احتجنا إلى رؤية المزيد من علامات التبويب ، فيمكننا إما النقر فوق شيفرون ، أو ببساطة CTRL + B لرؤية علامات التبويب في اللوحة اليمنى. لست متأكدًا مما إذا كان ذلك سيكون "مربكًا" على الإطلاق ، ولكن طالما أن المحررين وعلامات التبويب المفتوحة هي نفسها دائمًا وبنفس الترتيب ، يمكنني أن أتخيل أنها ستعمل بشكل جيد جدًا.
  2. أعتقد أنك ذكرت أن علامات التبويب المغلقة سابقًا كانت متاحة في إحدى طرق عرض شيء CTRL + Tab + ، ولكن هل فكرت في اختصار CTRL + SHIFT + T (تراجع عن علامة التبويب) التي ستعيد فتح علامات التبويب المغلقة سابقًا (بالترتيب التي تم إغلاقها)؟

تمكنت فقط من الانضمام خلال آخر 15 دقيقة أو نحو ذلك. هل تم تسجيله؟

شعرت بخيبة أمل (ولكن لم أتفاجأ) لرؤية علامات التبويب على الأرجح
تصبح الافتراضي. نأمل أن تستمر في الحفاظ على الوزن الخفيف
بيئة VS Code واستكشاف سير العمل التدريجي.

شكر،

جوامع

في الخميس 21 أبريل 2016 الساعة 11:07 صباحًا ، كتب anyong [email protected] :

تذكير لأي شخص كان يخطط للانضمام إلى جلسة Hangout - تم تشغيله الآن
انقر فوق الارتباط أعلاه. فقط ~ 5 أشخاص حتى الآن.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

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

FWIW (وإذا كانت لا تزال ذات صلة) ما زلت أعتقد أنه من الأفضل عدم وجود علامات تبويب في واجهة المستخدم _ افتراضيًا. رأس محرر نظيف لطيف يمكن النقر فوقه لرؤية قائمة بالملفات إذا لم يكن الشريط الجانبي مرئيًا ، أو CTRL + TAB ، هو ما أتمناه حقًا :)

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

indiejames و RyanEwen نعم ، لقد أخذنا الملاحظات ، وسنقوم بالنشر قريبًا. لم نقرر بالتأكيد السلوك الافتراضي حتى الآن. ومع ذلك ، فإننا نقترح حلاً من شأنه أن يسهل اختيار ما إذا كنت تريد استخدام ملفات العمل أو علامات التبويب أو كليهما أم لا.

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

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

التصميم المرئي

أولاً ، توضح هذه الصورة كيف نعتقد أن علامات التبويب قد تبدو في VS Code:
image2

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

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

سيؤدي التمرير فوق علامة التبويب إلى إظهار تلميح أداة بالمسار الكامل للملف في علامة التبويب.

معاينة علامات التبويب

للتمييز بوضوح بين علامات تبويب المعاينة وعلامات التبويب المفتوحة ، نقوم بوضع العنوان المائل في علامة التبويب كما في الإطار السلكي التالي.
image1

ناقشنا إجراءات ترقية علامة تبويب المعاينة إلى علامة تبويب مفتوحة بالكامل:

  • تحرير المحتوى داخل علامة التبويب
  • النقر المزدوج على ملف في المستكشف
  • النقر المزدوج فوق علامة تبويب المعاينة في مجموعة علامات التبويب

تجاوز

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

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

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

التنقل بين علامات التبويب

تسمح الأوامر التالية للمستخدمين بالتنقل بين علامات التبويب:

  • يظهر Ctrl-Tab قائمة بجميع علامات التبويب داخل مجموعة علامات التبويب النشطة:
    image3
  • يظهر Ctrl Alt Tab قائمة بجميع علامات التبويب داخل كل مجموعات علامات التبويب
    image4
  • يُظهر Quick Open التاريخ الخطي لجميع علامات التبويب
    image5

ملفات العمل

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

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

إذا كان الملف مفتوحًا في مجموعتين أو أكثر من مجموعات التحرير ، فإننا نعرض هذا في قائمة المحررين المفتوحة:
image6

يظهر أي محرر يفتحه المستخدم في قائمة المحررين المفتوحة. على سبيل المثال ، يظهر محرر الفرق كما يلي:
image7

تحتوي كل مجموعة على علامة تبويب معاينة واحدة فقط.

تشير شارة الرتبة في أعلى يمين مجموعة المحرر النشط إلى وجود مجموعة من المحررين أم لا.
image8

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

يؤدي إغلاق محرر (على سبيل المثال باستخدام Ctrl-W) إلى إزالة المحرر من قائمة المحررين المفتوحة.

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

للتمييز بوضوح بين علامات تبويب المعاينة وعلامات التبويب المفتوحة ، نقوم بوضع العنوان المائل في علامة التبويب كما في الإطار السلكي التالي.

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

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

eyalsk تم ذكره في المناقشة أنه يجب تمكين علامات التبويب والمحررين

anyong شكرا! :)

يظهر Ctrl-Tab قائمة بجميع علامات التبويب داخل مجموعة علامات التبويب النشطة:

أخيرا! علامات تبويب أم لا ، هذا هو السلوك الذي كنت أنتظره! لا مزيد من الضياع في محفوظات الملفات الخاصة بي.

يؤدي إغلاق محرر (على سبيل المثال باستخدام Ctrl-W) إلى إزالة المحرر من قائمة المحررين المفتوحة.

عظيم! نأمل أن يكون هذا الأمر أكثر سهولة ويساعد في تنظيف الفوضى في ملفات العمل.

الآن سأنتظر فقط https://github.com/Microsoft/vscode/issues/5554 للإغلاق.

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

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

عادةً ما أقوم بدفن نفسي في علامات تبويب مفتوحة حتى أنتهي من وحدة العمل ثم أغلقها جميعًا في نفس الوقت الذي أذهب فيه للالتزام.

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

stevencl سأكون سعيدًا إذا قمت بالسحب للتو بفتح نافذة vscode جديدة مع فتح هذا الملف (ربما مع فتح نفس المجلد أيضًا).

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

stevencl ، أنا قلق من أن الأمر سيتطلب المزيد من العمل لإضافته في المستقبل ، لذا عندما تقوم بتحسين البنية التحتية ، تأكد من الاحتفاظ بها في الأعمال المتراكمة الخاصة بك! ؛)

علامات التبويب من فضلك

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

نتطلع إلى إعطائها تدور. شكرا على الإنصات.

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

هل ستدعم Open Editors أكثر من مجموعتين من المحررين؟ فقط أتساءل كيف تسميهم إذا كان الأمر أكثر تعقيدًا من اليسار واليمين.

نعم ، هذا لا يزال مدعومًا.


من: Maxime Quandallemailto: [email protected]
تاريخ الإرسال: 22/04/2016 23:09
إلى: Microsoft / vscodemailto: [email protected]
نسخة إلى: ستيفن كلاركيميلتو: [email protected] ؛ Mentionmailto: [email protected]
الموضوع: Re: [Microsoft / vscode] علامات التبويب المناسبة للملفات المفتوحة (# 224)

هل سيظل تغيير موضع الأجزاء عن طريق السحب والإفلات ممكنًا بموجب اقتراح


أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

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

تم التقاط @ jayrosen1576 التقسيم الأفقي في هذه المشكلة https://github.com/Microsoft/vscode/issues/1749 ، تأكد من: +1: لإظهار اهتمامك.

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

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

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

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

hsyn لقد فهمت أن علامات التبويب لن تتقلص ، وستتوفر علامات التبويب الفائضة من زر تجاوز الشيفرون. لا ينبغي أن يكون زر الإغلاق مشكلة.

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

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

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

تقوم بعض المتصفحات بمزيج من تقليص علامات التبويب ولكن بعد ذلك تتخطى حدًا معينًا. فايرفوكس يفعل ذلك ؛ متأكد تمامًا من أن iOS Safari يقوم بذلك (أو فعل) أيضًا.

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

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

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

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

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

شكرا لتوضيح الأمرstevencl.

حالة حافة واحدة يجب وضعها في الاعتبار مع أسماء الملفات في علامات التبويب هي ملفات متعددة بنفس الاسم تم فتحها من مجلدات مختلفة (index.js ، README ، LICENSE ، package.json ، إلخ).

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

يوم الخميس ، 28 أبريل 2016 الساعة 12:16 مساءً ، Steven Clarke [email protected]
كتب:

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

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

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

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

هل القصد من أن الرقم يشير ببساطة إلى وجود علامات تبويب تجاوز أو أن العدد الفعلي لعلامات التبويب الفائضة مهم؟

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

image

لذلك لديهم فكرة بديهية عن "لدي الكثير من علامات التبويب المفتوحة" مقابل "لدي 2 أو 3 علامات تبويب مفتوحة"

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

أنا جديد فقط في هذا الموضوع ولكن 2p كمستخدم VS2015 كامل:

أتطلع إلى وجود علامات تبويب في vscode ، لأن ملفات العمل لا تناسبني أبدًا (على الرغم من أنني أرى الآن أن الضغط على ctrl-f4 لا يزيل من تلك المجموعة كما افترضت).

معجب كبير بعلامة تبويب المعاينة ، يسعدني رؤيتها قادمة.

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

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

زر الإغلاق الموجود على اليسار غريب بالنسبة لي - أفترض أنه بعض اصطلاحات mac / linux - ولكن طالما أن "النقر على الزر الأوسط" في علامة التبويب يغلق محررًا (موجه للحفظ إن أمكن) ، فلا داعي للقلق. يمكنني معرفة سبب إغلاق مجموعة من الملفات بسرعة متتالية على اليسار ، ولكن النقر الأوسط أفضل لذلك على أي حال (على الرغم من أنه ربما لا يكون لأجهزة Mac أو أجهزة الكمبيوتر المحمولة التي لا تحتوي على عجلة تمرير؟).

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

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

في ملاحظة ذات صلة قليلاً ، إذا كنت ctrl-f4 (أو ctrl-w؟ يبدو أنه الإصدار بخلاف Windows من ctrl-f4 إلا إذا كنت مخطئًا) ، أتوقع أنه إذا كانت علامة التبويب تختفي ، فإنها تغلق محرر ويجب أن يطالب بحفظ / تجاهل وإزالته من ctrl-tab / ctrl-alt-tab / ملفات العمل ... أستطيع أن أرى أن هناك بعض التغييرات في رابط المفاتيح التي يمكنني القيام بها في الوقت الحالي لتمكين هذه الوظيفة ، لكنني أجاهد من أجل انظر لماذا في الواجهة المبنية على علامة التبويب لا يرتبط وجود علامة تبويب مباشرة بـ "الحالي" - / فتح الملف / المحرر.

أحب ما تفعلونه جميعًا على vscode ، إنه يبدو رائعًا ☺

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

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

على أي حال ، أنا مؤمن بتاريخ الملفات الآن. :)

أعتقد أنه سيكون من الرائع حقًا إضافة القدرة على الانتقال ذهابًا وإيابًا في السجل باستخدام shift+cmd+[ و shift+cmd+] . هذه هي الاختصارات الافتراضية للتنقل حول علامات التبويب في التطبيقات الأخرى والقدرة على استخدامها لتصفح التاريخ بدلاً من ذلك أعتقد أنها ستقطع شوطًا طويلاً نحو جعلني مؤمنًا على الأقل

تحرير: تحقق هذا بشكل أساسي من خلال التنفيذ

  { "key": "shift+cmd+[", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+]", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+[", "command": "workbench.action.quickOpenNavigateNext", "when": "inQuickOpen" },
  { "key": "shift+cmd+]", "command": "workbench.action.quickOpenNavigatePrevious", "when": "inQuickOpen" }

كروابط مفاتيح مخصصة

أعتقد أن القدرة على تمزيق قسم الكود في نافذة جديدة سيكون مفيدًا أيضًا. لست متأكدًا مما إذا كان هذا الشيء ممكنًا.

JoshClose من الممكن تمامًا ولكنهم يفتقرون إلى البنية التحتية للتواصل بين العمليات للمحرر نفسه ، لذلك بالنسبة

... تحتوي علامات التبويب على زر إغلاق على يسار الاسم

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

ناقشنا إجراءات ترقية علامة تبويب المعاينة إلى علامة تبويب مفتوحة بالكامل ...

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

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

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

نعرض شيفرون كلما حدث تجاوز ...

يتعامل Firefox مع تجاوز علامة التبويب بشكل جيد - يحتوي على أقصى عرض لعلامة التبويب ، وأزرار تمرير يسار / يمين ، وقائمة منسدلة تسرد جميع علامات التبويب (مع علامات التبويب المرئية حاليًا) ، إلخ

سيكون من الرائع حقًا إذا كانت أزرار إغلاق علامة التبويب مطابقة لاتفاقيات النظام الأساسي: على اليسار في OS X ، على اليمين في Windows.

بعد استخدام VSCode لبعض الوقت الآن ، أعتقد أن وضع _Working Files_ قد نما لي كثيرًا!

لدينا هنا بعض الأسباب:

  1. على الرغم من أنه يبدو غير بديهي ، إلا أن إغلاق ملف لا أستخدمه (ctrl-w) لا يخرجه من ملفات العمل. هذا جيد جدًا لأنني في كثير من الأحيان أجد نفسي أعيد فتح الملفات المغلقة مؤخرًا (في مشروع React) عند العمل مع الملفات ذات الصلة (أو فصول الأطفال). لذلك ، عندما أشعر بأنني يجب أن أغلق ملفًا ، لا يتم تعيين واحد لواحد للوقت الذي يجب أن أقوم فيه بإغلاقه.
  2. يعجبني فرض الإغلاق الصريح ، والذي يقدمه workbench.files.action.closeFile .
  3. لقد قمت بإعادة تعيين workbench.files.action.closeFile إلى Ctrl + k Ctrl + w لأنه يتطلب جهدًا أقل (قليلاً) من Ctrl + kw ،
  4. يمكنني رؤية اسم الملف الكامل والمسار في الشريط العلوي للمحرر -> هذا مهم جدًا في المشاريع المتداخلة بعمق (مثل لدي) والتي تحتوي على ملفات بأسماء متشابهة أو متشابهة ( index.js ؟) وفقط طريقة التفريق هي طريق.
  5. ضجيج أقل لعلامات التبويب = Zen!

لذا ، بطريقة ما أحاول أن أقول ذلك من فضلك _لا تزيل_ التدفق الحالي إذا قمت بتقديم شيء علامات التبويب.

kumarharsh لماذا يزيلون ذلك؟ إذا كان هناك أي شيء ، فمن المحتمل أن يقوموا بتحسينه لك! :)

إذا حل المؤشر المتسخ محل رمز CLOSE ، فكيف سنتمكن من إغلاق الملف إذا لم نرغب في حفظ التغييرات؟ هل سيظل ctrl-w متاحًا؟

ألا يمكن أن يتغير المؤشر القذر إلى زر الإغلاق عند التحويم؟
هذا حل شائع جدًا ...

في الأربعاء 4 مايو 2016 الساعة 11:28 مساءً ، كتب rojorojo [email protected] :

إذا حل المؤشر المتسخ محل رمز CLOSE ، فكيف سنتمكن من ذلك
أغلق الملف إذا كنا لا نريد حفظ تغييراتنا؟ سوف ctrl-w لا يزال
متاح؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

rojorojo نحن نقوم بما اقترح anyong أيضًا ، لذلك لن تواجه أي مشكلة. ونعم ، سيظل Ctrl + W متاحًا.

شكرا لكل الردود.

نجري دراسة UX على أحدث تصميماتنا في نهاية هذا الشهر. إذا كان بإمكانك توفير ساعة في 25 أو 26 مايو وترغب في المشاركة في الدراسة ، فيرجى الاشتراك هنا: https ://

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

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

انتظر ، أحب سلوك واجهة المستخدم الحالية ، هل سيكون هناك تكوين؟

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

آمل أنه عندما يتم بناؤه سيكون اختياريًا حتى يتمكن من يريده منا من الاستمرار في البيئة الحالية.

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

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

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

أعتقد أيضًا أن المؤشرات القذرة هي إهدار للعقارات. في Sublime Text ، أقوم بتكوين "dirty" لتغيير لون خط علامة التبويب فقط. في الماضي ، قمت أيضًا بجعلها مائلة ولكن يبدو أن لديك خططًا لإدخال معاينات مائلة.

الجانب الأيسر من الحد عريض جدًا

@ be5invisMrTravisBrauschmamarcusruggerjpaaso

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

الملصقات المحتملة: يرجى الاطلاع على سلسلة الرسائل لمعرفة ما إذا كانت مشاكلك قد تمت معالجتها بالفعل - في كل مرة تنشر فيها هناك مائة شخص يتلقون رسائل بريد إلكتروني تتضمن: +1: شكرًا

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

@ be5invis الاختلاف الوحيد هو وجود فاصل مرئي. لا يزال بإمكانك سحب الملفات وفتحها في أي محرر تريده.

anyong يمكنني إخفاء ذلك؟ وإذا اخترت إخفاء "الفاصل" و Ctrl-Tab في عمود محرر واحد ، فهل يمكنني التبديل إلى ملف مفتوح في العمود الآخر؟ ما يريده المحتالون هو الحفاظ تمامًا على السلوك الحالي.

@ be5invis من التعليق الذي ربطته أعلاه:

يظهر Ctrl Alt Tab قائمة بجميع علامات التبويب داخل كل مجموعات علامات التبويب

لذا ، نعم ، لا يزال بإمكانك تعيين ارتباط المفتاح للحفاظ على سلوك Ctrl + Tab الحالي إذا كنت تريد ذلك.

anyong هذا جيد.
ولكن مع ذلك ، هل يمكنني إخفاء مؤشر "اليسار / اليمين" وجعل القائمة تبدو كوحدة؟

سيكون هذا سؤالاً لـstevencl

ياي! آمل أن نحصل على علامات التبويب قريبًا!

أخبار رائعة .. نحصل على علامات التبويب .. لكننا لا نريد فقد مجلد "ملفات العمل". هل تريد الاحتفاظ به مع علامات التبويب؟

رائع! مجموعات علامات التبويب

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

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

image

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

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

يجب تحسين خيار الانتقال إلى التعريف (F12) (حتى التعريف موجود في صفحة أخرى في المشروع)) مثل النص السامي؟ أواجه هذه المشكلة منذ فترة طويلة منذ أن قمت بتثبيت كود VS؟ أي مساعدة في هذا؟

@ vinod-a-ext - يُرجى فتح عدد جديد يصف المشكلة التي تواجهها مع Go To Definition.

تضمين التغريدة
انتقل إلى مشكلة التعريف في رمز VS
https://github.com/Microsoft/vscode/issues/6238

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

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

التاريخ: الثلاثاء ، 10 مايو 2016 04:06:34 -0700
من: [email protected]
إلى: [email protected]
نسخة إلى: [email protected] ؛ أذكرnoreply.github.com
الموضوع: Re: [Microsoft / vscode] علامات التبويب المناسبة للملفات المفتوحة (# 224)

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

لدي فضول ، ما هو البرنامج الذي استخدمته لإنشاء النماذج ، مثل هذا

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

التاريخ: الثلاثاء ، 10 مايو 2016 05:03:55 -0700
من: [email protected]
إلى: [email protected]
نسخة إلى: [email protected] ؛ أذكرnoreply.github.com
الموضوع: Re: [Microsoft / vscode] علامات التبويب المناسبة للملفات المفتوحة (# 224)

لدي فضول ، ما هو البرنامج الذي استخدمته لإنشاء النماذج ، مثل هذا

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

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

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

سيكون هذا مفيدًا حقًا للحفاظ على التنظيم في تطوير Angular 2 ، حيث يكون لديك عادةً ملفات ذات صلة:

  • widget.component.css
  • widget.component.html
  • widget.component.ts
  • widget.component.spec.ts

بالاتفاق مع

أتفق مع coreh على أن موقع زر إغلاق علامة التبويب يجب أن يتطابق مع اصطلاحات النظام الأساسي. قد يكون تبديل السياق محبطًا إلى حد ما أن يتم تغيير موقع زر الإغلاق عندما أنتقل من Visual Studio إلى Visual Studio Code.

سنتان: أحد الأسباب التي تجعلني أحب البرمجة عبر Atom ، Sublime ، أو أي محررين آخرين ، ahem ، hipster هو أنه لا يحاول استخدام مفهوم "علامة تبويب" متصفح الويب. IDEs التقليدية مثل Visual Studio و IDEA و Eclipse كلها تفعل ذلك أيضًا. من ناحية أخرى ، يحتوي الكود على نهج "الإطارات والمخازن المؤقتة" ، على غرار ما تجده في Emacs (وأعتقد أيضًا فيم Vim).

حتمًا ، في أي محرر مستند إلى علامة التبويب أجد نفسي مضطرًا للعمل مع النتائج في إطارات المحرر الخاصة بي التي يتم إرسال رسائل غير مرغوب فيها بشكل مرعب مع علامات التبويب التي تكون مجلدات المجلدات صغيرة جدًا بحيث لا يمكن قراءتها. علاوة على ذلك ، عندما أستخدم ما يعادل هذا المحرر لـ Ctrl / ⌘-PI ينتهي الأمر بالالتفاف إلى إطار آخر كقطعة أثرية لأي إطار كنت أنظر إليه عندما انتقلت لأول مرة إلى الملف. من أجل عرض نفس الملف في إطار آخر ، عليك القيام بعملية "تقسيم علامة التبويب" التي غالبًا ما تميل أيضًا إلى أن تقترن بتقسيم الإطارات في العديد من برامج التحرير هذه. _تقرن علامات التبويب بإحكام حالة المخزن المؤقت للملف بإطار معين على الشاشة.

إذا كنت ستعذر الاستئناف العاطفي ، فالرجاء _الرجاء_ عدم تحويل VS Code إلى محرر مبوب آخر.

أعتقد ، من منظور UX ، بدلاً من التنفيذ الأعمى لعلامات التبويب لمطابقة سلوك Atom أو أي محرر آخر ، سيكون من المفيد معرفة _لماذا_ يريد الأشخاص علامات التبويب (بخلاف مجرد الإلمام المريح) ومعرفة ما إذا كان هناك حل أكثر ابتكارًا احتياجاتهم ممكنة. أنا أوافق بالتأكيد على أن نظام مساحة العمل الحالي يمكن أن يستمر في التطور: كما ذكر شخص آخر فتح نافذة منفصلة في نفس المشروع (أي ما يعادل "ripout" المستند إلى علامة التبويب) من أجل الاستفادة بشكل أفضل من شاشات العرض متعددة الرؤوس التي تتبادر إلى الذهن!

عدل: حزين جدًا لأنني فاتني المكالمة منذ 19 يومًا. كنت سألتحق إذا كنت قد علمت بذلك. اكتشفت فقط من ملاحظات إصدار 1.1.0. :(

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

orospakr ، يمكنك إيقاف تشغيل علامات التبويب في Sublime من خلال خيار القائمة. لمعلوماتك فقط.

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

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

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

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

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

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

أعلم أنني قد تأخرت قليلاً عن اللعبة هنا ، لكن فيما يتعلق بهذا القسم:

ناقشنا إجراءات ترقية علامة تبويب المعاينة إلى علامة تبويب مفتوحة بالكامل:

تحرير المحتوى داخل علامة التبويب
النقر المزدوج على ملف في المستكشف
النقر المزدوج فوق علامة تبويب المعاينة في مجموعة علامات التبويب

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

من غير المحتمل جدًا أنني أضفت إشارة مرجعية إلى ملف أنوي إغلاقه على الفور.

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

بقدر ما تذهب علامات التبويب ، أولاً ، _ شكرًا لك! _ غيابهم هو أحد الأشياء الوحيدة التي لا أحبها في VS Code.

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

شكرا للمحرر الرائع <3

علامات التبويب ضرورية بالنسبة لي ... العودة إلى Sublime حتى يكون لديك علامات تبويب. ملاحظة: أشعر بخيبة أمل كبيرة من موقفك ؛ يبدو أنه ليس لديك أي إحساس بتجربة المستخدم حتى الآن تدعي أن هذا قد تم لتحسين تجربة المستخدم. ما هي شخصياتك؟ أين هي مقابلات المستخدم الخاصة بك؟ اثبت ذلك.

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

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

asadighi كل شيء في رأسك ويظهر

muellerkyle : +1: يجب إنشاء مشكلة مقابل امتداد الإشارة المرجعية الذي تستخدمه.

إنني أتطلع إلى هذه الميزة

+1!

يوميًا ، أقوم بالتبديل بين Eclipse و PhpStorm و Notepad ++ و VSCode. خمن ماذا ، CTRL+W يدفعني للجنون.

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

jamesmenera نعم ، سيكون اختياريًا وكذلك ملفات العمل (المحررين

جانبا ، هل يمكنك الكشف عن البرنامج الذي استخدمته لعمل تلك الصور بالحجم الطبيعي؟

ciel ، كتب stevencl أنهم استخدموا PowerPoint لذلك.

أنا شخصياً أحب WireframeSketcher للقيام بذلك ولكن PowerPoint يمكن أن يعمل أيضًا. :)

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

@ kadza93 ستكون كل من علامات التبويب وملفات العمل اختيارية ... أتساءل كم مرة

من السهل حقًا إجراء بحث والبحث عن كلمة "اختياري" ، وسيستغرق العثور عليها وقتًا أقل من كتابة منشور حول هذا الموضوع!

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

لقد كانت 3 فقط من مشاركتك ...

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

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

ربما يمكن للمسؤولين وضع لافتة "الحالة الحالية: قيد التطوير" في الجزء العلوي من صفحة المشكلة (ضمن نص إصدار OP)؟

يجب أن تكون هذه ميزة مناسبة في جيثب - شيء مثل النص البديل هنا يقترح: https://xkcd.com/979/

@ kadza93 لم

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

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

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

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

بشكل عام ، من المنطقي البحث عن كلمات شائعة محتملة في منشور طويل.

حقًا يجب على المطورين فتح مشكلة جديدة مع الأسئلة الشائعة والتفاصيل المأخوذة من
أكثر النقاط شيوعًا في هذا الموضوع وإغلاق هذه المشكلة. اشخاص
المشتركين في هذه المشكلة يتلقون العشرات من رسائل البريد الإلكتروني يوميًا لـ
نفس التعليقات "رائعة" / "رفض".
في 18 أيار (مايو) 2016 ، الساعة 1:51 صباحًا ، كتب "كومار هارش" [email protected] :

ربما يمكن للمسؤولين وضع لافتة "الحالة الحالية: قيد التطوير" على
أعلى صفحة الإصدار (ضمن هيئة إصدار OP)؟

يجب أن تكون هذه ميزة مناسبة في github --- شيء مثل النص البديل
يقترح هنا: https://xkcd.com/979/

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

anyong نعم أتفق تماما! لا يوجد شيء للمناقشة ، وبمجرد أن يتم عرض tabs و open editors ، يجب عليهم إنشاء مشكلتين منفصلتين للتعليق على هذه الميزات.

eyalsk ما زلنا نجرب كيفية التعامل مع التحديثات على المشكلات التي أنشأها المجتمع. هناك مجموعة من الطرق للقيام بذلك ولكنها كلها سيئة نوعًا ما بدون ميزة تعليق مثبتة على GitHub. كانت المشكلة الطرفية المتكاملة https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854 جيدة حتى الآن مع تحديث كبير في منتصف سلسلة الرسائل ، أعتقد أن الأمر يتعلق بحاجة أقل للمناقشة لذلك لم يتم دفنها.

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

لقد عملنا على تنفيذ تصميمات علامات التبويب ومجموعات المحررين في هذا الإنجاز وسنواصل القيام بذلك في المرحلة التالية

شكرًا لكل من شارك في دراسة UX في اليومين الماضيين. لقد تلقينا بعض التعليقات الرائعة منك والتي ساعدتنا في إجراء بعض التحسينات على التجربة:

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

عذرًا ، إذا فاتني ذلك ، ولكن كيف يمكننا تمكين علامات التبويب؟ هل هي متوفرة في أحدث إصدار داخلي ، كما أملك ، ولكن لا يوجد أي أثر لعلامات التبويب هناك. ما زلت أرى أيضًا "ملفات العمل" في المستكشف ، بينما يبدو أنه يجب استبدالها بـ "Opened Editors" كما هو مذكور في # 6536.

lllopo هم غير متاحين بعد. تم دمج مكدسات / برامج التحرير المفتوحة في الإصدار 1.3.0 وستتوفر في Insider الأسبوع المقبل عندما تصبح الإصدارات اليومية متاحة.

+1

+1

👎

ماذا يحدث هنا ، لماذا تقاوم منحنا خيارًا لاستخدام علامات التبويب؟ 😕
الكثير من الأشخاص يحبون علامات التبويب بمن فيهم أنا ، يمنحونا الخيار اللعين PERIOD!

aminroosta بجدية ... ألا يمكنك القراءة؟ هل انت اعمى؟

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

بعض الناس في هذا العالم! لا يصدق!

eyalsk
قضيت 25 دقيقة في قراءة أول 20 إلى 30 تعليقًا.
لقد تعبت وتركت تعليقًا يبدو الآن أنه خطأ من ناحيتي.

اسف بشأن ذلك.

لا يمكننا إلقاء اللوم على Microsoft R&D لمحاولة الإبداع. نظام علامات التبويب له سلبيات.

تصميم واجهة المستخدم يشبه كل أشكال التصميم. 90٪ يصنعون ما ينتظره المستخدم و 10٪ يصنعون أشياء جديدة ويحاولون إنشاء نظام ثوري جديد وسهل الاستخدام.

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

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

هذا اقتراح جيد لأن هذا موجز طويل جدًا.

يوم الأحد ، 5 حزيران (يونيو) 2016 الساعة 10:42 صباحًا إيال سولنيك [email protected]
كتب:

aminroosta https://github.com/aminroosta سأعطيك نصيحة ، متى
تقرأ منشورًا طويلاً ، اقرأ المنشور الأصلي ثم تحصل على ملف
آخر التحديثات تقضي دقيقة أو نحو ذلك في التمرير من الأسفل إلى الأعلى.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

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

adred كلاهما Working files (يُسمى الآن Open editors ) و Tabs سيكونان اختياريًا بقدر ما أستطيع أن أقول.

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

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

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

الاعتذار عن النغمة والشكر.

هناك عدد كبير جدًا من إجراءات 1+ وهذا كثير جدًا.

في يوم الإثنين 6 حزيران (يونيو) 2016 الساعة 2:16 صباحًا -0700 ، كتب "anyong" [email protected] :

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

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

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

الاعتذار عن النغمة والشكر.


أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

مجرد تعليق على نص التحديث @ https://code.visualstudio.com/updates#_workbench

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

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

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

أتفق معRyanEwen. إنني أقدر حقًا التطور المفتوح وكمية الاتصالات ، ولكن كون هذه الإعلانات جزءًا من "ملاحظات الإصدار" الرسمية أمر محير حقًا.

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

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

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

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

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

بغض النظر عن هذا الشيء البسيط. عمل رائع في الإصدار. يعتبر VS Code منتجًا رائعًا مع دورة تطوير مذهلة.

تم تحديث VSCode للتو إلى 1.3.0-insider. يبدو أن الملفات الأخيرة قد ولت. هل هناك طريقة لفعل ذلك الآن؟

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

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

JoshClose ، يرجى فتح مشكلة جديدة لهذا لأنني

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

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

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

شكرًا مرة أخرى ، انتقل الآن وقم بتثبيت إصدار Insiders !

https://github.com/Microsoft/vscode/issues/6605 يوثق جميع معرفات الأوامر المضافة أو التي تم تغييرها لاستخدامها مع روابط المفاتيح. نظرًا لأن نموذج المكدس يمثل تغييرًا كبيرًا في واجهة المستخدم الخاصة بـ VS Code ، فقد قررنا إعادة النظر في جميع الأوامر التي تتعلق بالمحررين أو المجموعات.

يسعدنا أن نعلن أنه يمكنك الآن تمكين علامات التبويب في تصميمات المطلعين الليلية الخاصة بنا (http://code.visualstudio.com/Download#insiders). الإعداد المرتبط هو workbench.editor.showTabs . يرجى الرجوع إلى ملاحظات الإصدار الخاصة بنا للحصول على مزيد من التفاصيل حول مفهوم مجموعات المحرر ومحرري المعاينة وعلامات التبويب.

image

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

شكر!

كما ذكر bpasero ، يمكنك الآن تمكين علامات التبويب في

إذا كنت قد جربت هذا وكان بإمكانك توفير 30 دقيقة لمشاركة ملاحظاتك ، فالرجاء الاشتراك للدردشة هنا: https ://

لسوء الحظ ، لا يمكنني تقديم خانات زمنية إلا خلال اليوم (أنا في إدنبرة ، اسكتلندا) يومي الاثنين والثلاثاء من الأسبوع المقبل.

TL ؛ د. تمكين علامات التبويب في المطلعين على VS Code مع workbench.editor.showTabs: true

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

من وصف عنصر العمل هذا ، يسأل TurkeyMan عن وجود علامات تبويب وطريقة لنقل علامة تبويب من طاولة العمل لفتحها داخل نافذة جديدة. لقد استخرجت الأخير في https://github.com/Microsoft/vscode/issues/8171 لأنه لا يتعلق بعمل علامات التبويب الذي قمنا به.

يرجى الاستمرار في تقديم المشكلات في علامات التبويب كما تراها أثناء تجربتها. شكرا للمساعدة في اختبار بناء المطلعين!

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