Vscode: Onglets appropriés pour les fichiers ouverts

Créé le 19 nov. 2015  ·  411Commentaires  ·  Source: microsoft/vscode

Je manque _ vraiment_ les onglets appropriés pour les fichiers ouverts (comme VS proprement dit), et la possibilité d'extraire un onglet dans sa propre fenêtre.

feature-request workbench-tabs

Commentaire le plus utile

Merci à tous ceux qui ont pris le temps de se joindre à l'appel aujourd'hui et de fournir des commentaires, nous l'apprécions vraiment. @anyong a déjà fait un excellent travail en résumant ce que nous avons présenté mais j'ajouterai quelques détails supplémentaires ci-dessous et quelques captures d'écran.

Aspect visuel

Tout d'abord, cette image indique à quoi nous pensons que les onglets pourraient ressembler dans VS Code:
image2

Nous visons un look léger et non distrayant, quelque chose qui s'intègre bien avec le reste de VS Code. Nous n'avons pas encore défini à quoi cela ressemblerait dans un thème clair.

Comme vous pouvez le voir dans l'image ci-dessus, les onglets contiennent un bouton de fermeture à gauche du nom. Lorsque le fichier contient des modifications non enregistrées, nous affichons un indicateur sale à l'emplacement du bouton de fermeture.

Le survol d'un onglet affichera une info-bulle avec le chemin complet du fichier dans l'onglet.

Onglets d'aperçu

Pour distinguer clairement les onglets d'aperçu des onglets ouverts, nous mettons en italique le titre dans l'onglet comme dans le filaire suivant.
image1

Nous avons discuté des actions permettant de promouvoir un onglet d'aperçu en un onglet complètement ouvert:

  • Modifier le contenu dans l'onglet
  • Double-cliquez sur un fichier dans l'explorateur
  • Double-cliquez sur l'onglet d'aperçu dans le groupe d'onglets

Débordement

Les onglets s'ouvrent à droite de l'onglet actif. S'il n'y a pas assez de place pour afficher tous les onglets d'un groupe d'onglets, nous débordons les onglets. Nous ne tronquons pas le nom du fichier à l'intérieur de l'onglet pour faire plus de place pour plus d'onglets.

Nous montrons un chevron chaque fois qu'il y a un débordement. Cliquez sur ce chevron pour afficher une boîte de dialogue d'ouverture rapide qui répertorie tous les onglets du groupe d'onglets, permettant à l'utilisateur de trouver l'onglet qu'il souhaite afficher.

Cliquez sur un onglet actuellement en débordement pour afficher cet onglet.

Navigation dans les onglets

Les commandes suivantes permettent aux utilisateurs de naviguer entre les onglets:

  • Ctrl-Tab affiche une liste de tous les onglets à l'intérieur du groupe d'onglets actif:
    image3
  • Ctrl Alt Tab affiche une liste de tous les onglets dans tous les groupes d'onglets
    image4
  • L'ouverture rapide montre l'historique linéaire de tous les onglets
    image5

Fichiers de travail

Nous avons renommé les fichiers de travail pour ouvrir les éditeurs afin de mieux refléter ce que c'est vraiment.

La liste des éditeurs ouverts fonctionne de la même manière que les onglets. Nous les listons simplement dans l'explorateur plutôt que de les visualiser sous forme d'onglets.

Si un fichier est ouvert dans deux ou plusieurs groupes d'éditeurs, nous le montrons dans la liste des éditeurs ouverts:
image6

Tout éditeur ouvert par l'utilisateur apparaît dans la liste des éditeurs ouverts. Ainsi, par exemple, l'éditeur de différences apparaît comme ceci:
image7

Chaque groupe ne contient qu'un seul onglet d'aperçu.

Le chevron en haut à droite du groupe d'éditeurs actif indique s'il existe ou non une pile d'éditeurs.
image8

Dans ce cas, la fermeture d'un éditeur révélera l'éditeur en dessous dans la pile, plutôt que de fermer complètement l'éditeur.

La fermeture d'un éditeur (par exemple avec Ctrl-W) supprime également l'éditeur de la liste des éditeurs ouverts.

Tous les 411 commentaires

+1

Serait-il possible d'ajouter des onglets via une extension personnalisée? J'ai rapidement regardé la documentation mais je n'ai pas semblé possible d'ajouter ce type de fonctionnalité avec l'API actuelle

Serait-il possible d'ajouter des onglets via une extension personnalisée?

Non, ce n'est actuellement pas possible depuis une extension (voir aussi http://code.visualstudio.com/docs/extensions/our-approach)

+1

: +1:

: +1:

+1

Les onglets sont le moyen par défaut de travailler même dans Visual Studio, sans parler des autres éditeurs de texte tels que sublime.

Pour ceux qui manquent d'onglets, avez-vous essayé d'utiliser Ctrl+Tab pour naviguer dans l'historique des fichiers ouverts?

Oui. Mais le fichier reste dans le contexte Ctrl+tab même après la fermeture du fichier. L'expérience n'est pas la même que celle de Sublime / Atom.

@snehilmodani à droite, cela aiderait-il si la liste ne montrait que ce que vous avez dans la section des fichiers de travail de l'explorateur? pouvez-vous au moins travailler avec la liste des fichiers de travail?

Ce serait génial!

Sur une note latérale: N'est-ce pas une mise en page avec des noms de fichiers sous forme d'onglets plus conviviaux. Il est extensible d'avoir une ou plusieurs sections d'onglets, chacune avec son propre ensemble de fichiers ouverts. (Encore une fois, je prends Sublime Text comme référence ici)

Je pense qu'avoir des onglets ou non est indépendant des sections. Aujourd'hui, vous pouvez ouvrir jusqu'à 3 éditeurs côte à côte dans VS Code et nous avons donc des sections. Comme nous n'avons pas d'onglets, nous n'ajoutons pas plusieurs fichiers dans ces sections et vous ne pouvez pas non plus avoir de sections vides (ce qui est une discussion UX séparée).

Revenant à Ctrl + Tab: Nous, dans l'équipe, avons toujours travaillé sans onglets depuis le premier jour et en fait, nous n'avons même pas eu la vue des fichiers de travail pendant longtemps et en fait, peu de personnes dans l'équipe l'utilisent. Nous avons constaté que pour nous, le fichier que vous aviez ouvert ou fermé importait peu. Nos esprits réfléchissent plutôt à l'ordre chronologique du fichier que nous avons édité en dernier. Ainsi, lorsque j'appelle Ctrl + Tab, il me montre généralement les fichiers dans lesquels j'étais en dernier. Je ne regarde pas vraiment le nombre de fichiers là-dedans, je ne suis intéressé que par les 5 meilleurs au max. L'avantage de ce modèle est que vous n'avez pas du tout à gérer les mises en page et les onglets. La gestion se fait naturellement pendant que vous naviguez entre les fichiers.

Nous pouvons ajouter un sélecteur de fichiers pour les fichiers de travail, mais il serait intéressant de savoir si les gens peuvent être convaincus d'utiliser Ctrl + Tab comme c'est le cas aujourd'hui et découvrir quels sont les problèmes.

@bpasero Je vais donner ctrl+tab un coup, je viens de réaliser qu'il peut être utilisé pour passer au fichier précédent qui est quelque chose que je voulais et que je n'avais pas encore étudié jusqu'à présent. Alors c'est bien.

Soit dit en passant, que l'on puisse s'habituer / s'habituer à ctrl+tab comme alternative aux onglets, les nouveaux utilisateurs de code VS seront probablement découragés par le manque d'onglets, donc si ce n'est que pour des raisons de part de marché, je recommande d'avoir une option d'onglets. Tous les autres éditeurs utilisent des onglets (pour le meilleur ou pour le pire), et ne pas les avoir introduit une barrière d'entrée plutôt inutile au code VS. J'utilise du code VS quel que soit le support des onglets en raison de son support génial de typographie, mais si ce n'était pas pour cela, je ne sais pas si je l'aurais continué les premières fois que je l'ai essayé.

Oui, Ctrl+Tab consiste à remonter dans l'historique des fichiers en cours de traitement. Vous pouvez maintenir enfoncée la touche Ctrl et appuyer plusieurs fois sur Tab pour revenir au-delà d'un fichier.

Ctrl+tab est une chose merveilleuse à avoir et j'en suis totalement fan. C'est quelque chose que même Atom manque.

En ce qui concerne les onglets et plusieurs fichiers dans chaque section: Même dans Sublime Text, nous pouvons ouvrir 3 éditeurs côte à côte, mais ils offrent toujours une mise en page en onglets. Je suis d'accord avec vous sur le désordre et la gestion de la mise en page de l'éditeur serait une tâche difficile, mais les gens y sont de toute façon habitués.
J'aimerais faire partie d'une expérience sociale où vous essayez de nous convaincre de nous débarrasser de nos interactions encombrées basées sur la mise en page avec nos éditeurs.

Je suis d'accord avec vous sur le désordre et la gestion de la mise en page de l'éditeur serait une tâche difficile, mais les gens y sont de toute façon habitués.

Eh bien, je suis sûr que nous pouvons trouver plus d'exemples UX où nous étions habitués à quelque chose, puis nous nous sommes habitués à quelque chose de beaucoup mieux :). Pensez au clavier du téléphone mobile et à l'interaction tactile du smartphone.

J'aimerais faire partie d'une expérience sociale où vous essayez de nous convaincre de nous débarrasser de nos interactions encombrées basées sur la mise en page avec nos éditeurs.

Oui, je pense que nous devrons faire quelque chose comme ça 2016. @stevencl fyi

En ce qui concerne les onglets et plusieurs fichiers dans chaque section: Même dans Sublime Text, nous pouvons ouvrir 3 éditeurs côte à côte, mais ils offrent toujours une mise en page en onglets.

Je suis d'accord sur une option pour permettre des sections plus stables afin que nous puissions avoir des sections vides, mais le fait de pouvoir voir les onglets dans cette section n'est qu'une représentation visuelle des fichiers qui, dans la plupart des cas, se développent tellement que vous finissez par ne pas rien voir. Je ne pense pas que les onglets soient un bon moyen d'afficher la liste des fichiers ouverts à moins que vous ne gériez ces choses activement et ne les fermez.

Je ne pense pas que les onglets soient un bon moyen d'afficher la liste des fichiers ouverts à moins que vous ne gériez ces choses activement et ne les fermez.

Certaines personnes les gèrent et pour d'autres, il y a des onglets proches à droite.

Merci beaucoup pour les commentaires.

Nous avons un problème sur notre backlog UX (# 1133) pour améliorer la gestion de l'espace de travail (gestion des fichiers ouverts, de l'historique, etc.) dont cela ferait partie. Notre intention est d'améliorer l'expérience de manière à ce que la gestion de la liste des fichiers ouverts et récents soit simple et facile et permette à l'utilisateur de se concentrer sur son code, sans avoir à prêter une attention excessive à l'interface utilisateur de VS Code.

Notre hypothèse est que le système actuel a des aspérités (par exemple, la fermeture d'un éditeur ferme en fait l'éditeur, mais nous pensons qu'il devrait peut-être montrer à la place le fichier qui était précédemment ouvert dans ce même éditeur) et que lisser ces arêtes aider à créer une bien meilleure expérience.

Nous réalisons des études UX sur le produit de manière très régulière. En fait, c'est ainsi que nous concevons une grande partie de l'UX dans le produit. Nous parcourons nos conceptions en nous basant sur de vrais commentaires en nous assurant que nous utilisons une grande compréhension de ce que les gens font et veulent faire avec le produit pour éclairer nos conceptions.

Si vous souhaitez participer à ces études à l'avenir (nous n'en organiserons plus avant la mi-janvier au plus tôt), faites-le moi savoir et j'ajouterai votre nom à la liste.

Si vous souhaitez participer à ces études à l'avenir (nous n'en organiserons plus avant la mi-janvier au plus tôt), faites-le moi savoir et j'ajouterai votre nom à la liste.

Enregistre-moi!

Je ne pense pas que les onglets soient un bon moyen d'afficher la liste des fichiers ouverts à moins que vous ne gériez ces choses activement et ne les fermez.

La gestion des onglets est une partie inconsciente et décomplexante de mon développement. VS-proper a de petits onglets discrets, qui ne sont pas intrusifs (vscode a déjà le nom de fichier occupant de l'espace là où l'onglet serait autrement). Je suis d'accord pour dire que le spam d'onglets emballés est un problème, il serait peut-être bien d'innover et de résoudre ce problème, mais je dirais que c'est moins prioritaire que d'avoir des onglets. VSCode doit atteindre un état de fonctionnement minimum. En ce moment, je trouve que ça se rapproche beaucoup, mais je ne peux pas encore travailler de manière productive. Commencer avec des modèles établis nous permettrait probablement de travailler plus tôt.

Il convient de garder à l'esprit que tout le monde n'est pas développeur Web, je trouve que les modèles et le flux de travail ont tendance à être légèrement différents selon les langues et les styles d'application. En tant que développeur natif, il est courant d'avoir un ensemble de fichiers associés visibles; cpp + h , peut-être aussi un inl , et vous ne travaillez généralement pas sur un seul fichier isolé. J'ai souvent une vue de démontage visible à côté du code. Mon environnement d'éditeur s'étend sur 2 moniteurs, avec 4 fichiers visibles à tout moment, et j'aurais du mal à travailler dans un environnement plus restrictif que cela.
Je manque également de pouvoir saisir un onglet et le déchirer dans une petite fenêtre flottante, que je définis souvent sur `` toujours au-dessus '', qui est généralement utilisé comme point de référence, ou quelque chose que je fais beaucoup de copie / pasing to / from.

À l'heure actuelle, par exemple, j'essaie de refactoriser et de simplifier un certain code hérité; mon jeu de fichiers de travail actuel est ... component.cpp, component.h, component.inl, componentimpl.cpp, componentimpl.h, icomponent.h. Cela fait 6 fichiers! Et je ne peux pas échapper aux modifications occasionnelles de certains autres fichiers à la périphérie. J'utilise généreusement ctrl-tab lorsque je travaille sur ce style de projet (basculement entre 2 fichiers), mais dans ce contexte / base de code, je ne peux tout simplement pas travailler sans onglets.

Refactoriser et maintenir le code hérité a un flux de travail très différent de l'écriture de nouveau code (ce que j'imagine que vous faites, et que vous utilisez principalement comme guide pour la conception UX).

Mon point ici est; il y a un désir moderne de tout réinventer, et nous avons vu d'énormes progrès dans la conception UX ces dernières années; vscode en présente déjà certains, mais soyez prudent et faites preuve de discernement lorsque vous décidez de changer la façon dont les gens travaillent depuis des décennies. De nombreux modèles établis sont établis parce qu'ils sont bons et efficaces, pas parce qu'ils sont vieux et ont besoin d'être mis à jour pour être plus à la mode :)

J'apprécierais l'opportunité de faire partie de ces études ciblées!

Mon point ici est; il y a un désir moderne de tout réinventer, et nous avons vu d'énormes progrès dans la conception UX ces dernières années; vscode en présente déjà certains, mais soyez prudent et faites preuve de discernement lorsque vous décidez de changer la façon dont les gens travaillent depuis des décennies.

C'est le cas pour moi. En fait, je ne peux pas travailler sans onglets. Je travaille avec le système d'onglets depuis des années, et sans eux, je suis vraiment perdu. C'est l'une des raisons pour lesquelles je n'utilise pas de code en fait.

De nombreux modèles établis sont établis parce qu'ils sont bons et efficaces, pas parce qu'ils sont vieux et ont besoin d'être mis à jour pour être plus à la mode :)

: +1:

Jusqu'à présent, je n'ai pas encore entendu une bonne raison pour les onglets par rapport au fait d'avoir juste une liste de "fichiers de travail" quelque part. Pouvoir prendre un fichier et le faire glisser dans une nouvelle fenêtre n'est clairement pas un avantage d'un système d'onglets, c'est une fonctionnalité que vous pouvez avoir sans onglets.

Est-ce que les gens veulent vraiment ouvrir des fichiers dans des onglets, les déplacer et les fermer éventuellement? Est-ce parce que vous y êtes tellement habitué ou y a-t-il vraiment une valeur à le faire? La valeur peut-elle définir un ensemble de fichiers de travail actif que vous rejetterez ultérieurement pour démarrer quelque chose de nouveau? Je me demande ce qu'il y a de si bon à avoir des onglets que vous ne pouvez pas obtenir avec un autre mode de représentation. Et je n'accepte pas l'argument selon lequel tout le monde est habitué aux onglets :). Beaucoup de gens sont habitués à enregistrer des fichiers et il existe encore des éditeurs avec une capacité de sauvegarde automatique et les gens semblent l'apprécier.

Même si ce n'est pas le cas par défaut, donner à l'utilisateur le choix d'activer la fonctionnalité des onglets via une option serait presque aussi bon pour moi.

Par exemple, que diriez-vous de laisser l'utilisateur déplacer / faire glisser la section "Fichiers de travail" vers le haut (les convertir en onglets, disons). Encore une fois, l'utilisateur peut choisir comment il veut travailler et je pense que c'est génial!

Pour moi, ce n'est pas tant l'apparence des onglets que leur comportement qui me manque. (Par exemple, vous pouvez faire en sorte que Sublime Text ressemble à VS Code en ce sens que vous pouvez masquer la barre d'onglets et afficher les fichiers ouverts dans la barre latérale à la place ... mais ils se comportent toujours exactement comme les onglets.)

La première chose que je fais avec VS Code est d'échanger son fichier de fermeture et de fermer les raccourcis clavier de l'éditeur actif, de sorte que ctrl + W ferme réellement un fichier lorsque j'appuie dessus, plutôt que de le laisser dans des fichiers de travail et d'encombrer ctrl + tab.

Mais même dans ce cas, chaque fois que je ferme un fichier, je suis accueilli avec un écran vide et je dois ctrl + tab juste pour afficher le fichier de travail le plus récent encore ouvert (diable, quand c'est le dernier, il me semble que je dois aussi appuyez sur Entrée après ctrl + tab; je ne sais pas de quoi il s'agit). Dans n'importe quel autre éditeur, je serais immédiatement accueilli par le fichier ouvert (onglet) le plus récent ou adjacent lors de la fermeture de celui en cours.

De plus, ctrl + tab entre les fichiers de travail semble fonctionner dans l'ordre le plus récent, contrairement aux onglets qui fonctionnent généralement dans l'ordre dans lequel ils apparaissent ou sont organisés. (J'ai vu certains éditeurs prendre en charge les deux.)

Je n'utilise pas de fenêtres séparées, donc si l'une de ces différences de comportement a quelque chose à voir avec cela, c'est perdu pour moi. Peut-être que je comprendrais mieux si je le comprenais sous cet angle, mais la non-division ne serait-elle pas encore le cas d'utilisation le plus courant?

Quoi qu'il en soit, ce sont des frictions petites mais fréquentes comme celles-ci qui m'éloignent de VS Code et de revenir à d'autres éditeurs. Oui, vous pourriez dire que VS Code fonctionne différemment de ce à quoi je suis habitué. Mais quand ce que j'ai l'habitude de _works_ et que VS Code fonctionne différemment provoque des frictions avec lesquelles j'utiliserais plus tôt un éditeur différent pour éviter d'avoir à gérer, c'est un gros problème.

Oui, je peux voir un modèle dans lequel la zone de l'éditeur se comporte comme des onglets sans afficher d'onglets. Nous voulons explorer cela l'année prochaine.

Btw il y a une extension qui - une fois que vous fermez un éditeur - ouvre le suivant à partir des fichiers de travail. Si vous combinez cela avec la modification de la combinaison de touches comme le suggère

Jusqu'à présent, je n'ai pas encore entendu une bonne raison pour les onglets par rapport au fait d'avoir juste une liste de "fichiers de travail" quelque part. Pouvoir prendre un fichier et le faire glisser dans une nouvelle fenêtre n'est clairement pas un avantage d'un système d'onglets, c'est une fonctionnalité que vous pouvez avoir sans onglets.

Bien sûr, il peut être possible de le faire d'une manière différente ... mais pourquoi? Sauf si vous avez une amélioration ou une innovation significative à offrir.

Est-ce que les gens veulent vraiment ouvrir des fichiers dans des onglets, les déplacer et les fermer éventuellement?

Oui

Est-ce parce que vous y êtes tellement habitué ou y a-t-il vraiment une valeur à le faire?

En partie par habitude, mais aussi parce que personne n'a encore présenté quelque chose de significativement supérieur. L'innovation devrait présenter un avantage significatif si elle veut insister pour que les gens se battent et se recyclent contre leurs habitudes vieilles de plusieurs décennies.

La valeur peut-elle définir un ensemble de fichiers de travail actif que vous rejetterez ultérieurement pour démarrer quelque chose de nouveau?

Je ne suis pas sûr de comprendre exactement cette phrase; essayez-vous de décrire une alternative où vous travaillez sur les termes de plusieurs ensembles de «fichiers de travail»? Difficile à imaginer. Je ne suis pas sûr que ce serait universellement utile. Pour les tâches héritées, de maintenance et de re-factorisation, je pense que ce serait un grave inconvénient de travailler de cette façon, car votre ensemble de travail n'est généralement pas connu à l'avance, mais plutôt émergent lorsque vous travaillez. Le modèle traditionnel fonctionne déjà très bien dans ces flux de travail.

Je me demande ce qu'il y a de si bon à avoir des onglets que vous ne pouvez pas obtenir avec un autre mode de représentation.

D'un point de vue différent; considérez l'utilisation de l'espace. Il y a _déjà_ un onglet en haut de la fenêtre de code, c'est là que se trouve le nom du fichier, il n'a tout simplement pas le rectangle de tabulation autour du nom (il se comporte même comme un onglet; si vous cliquez avec le bouton central, il se ferme!). À droite du nom de fichier au-dessus de la fenêtre de code se trouve actuellement un espace perdu vide (où les onglets devraient être).
En haut à gauche de l'espace de travail se trouve la liste des «fichiers de travail»; il s'agit d'un espace doublement gaspillé car il n'a tout simplement pas besoin d'exister, son espace pourrait être déplacé vers l'espace où se trouvent généralement les onglets, remplissant cet espace perdu.

Je trouve également une autre différence pratique que l'utilisation de l'espace et la tendance habituelle; J'aime avoir les onglets associés à la fenêtre de l'éditeur à laquelle ils sont liés. J'ai généralement au moins 2, 3, souvent 4 fenêtres de code ouvertes (en vs-bon), et chacune a quelques onglets associés. Peut-être que dans une fenêtre j'ai widget.cpp/.h , et dans l'autre j'ai gizmo.cpp/.h/.inl . Ces onglets sont logiquement associés à la fenêtre de code à laquelle ils sont attachés, et je trouve cela agréable.

Et je n'accepte pas l'argument selon lequel tout le monde est habitué aux onglets :). Beaucoup de gens sont habitués à enregistrer des fichiers et il existe encore des éditeurs avec une capacité de sauvegarde automatique et les gens semblent l'apprécier.

Eh bien, acceptez-le ou non, les gens trouvent que c'est un argument raisonnable et fort. Mais je réserverai mon jugement si vous avez quelque chose de bien meilleur en tête. Bien sûr, si vous pensez que vous pouvez améliorer de manière significative les onglets, essayez-le, mais ne le forcez pas obstinément à cause de l'innovation «à la mode» seule;) .. Il doit être nettement supérieur pour éjecter le statut quot .

Je peux seulement dire que la liste actuelle des «fichiers de travail» n'est certainement pas supérieure. Ce sont essentiellement des onglets, juste disposés verticalement, sauf avec les inconvénients que les onglets sont détachés de la fenêtre de l'éditeur, ils sont liés, et la liste vit dans un espace perdu alors que l'emplacement habituel des onglets est vide.
Je n'aime pas non plus que la liste des `` fichiers de travail '' ait une hauteur dynamique, ce qui signifie que l'arborescence du projet se déplace verticalement, et je suppose que je l'aimerais encore moins si les `` fichiers de travail '' avaient une hauteur fixe et une barre de défilement verticale au lieu.

Ce n'est tout simplement pas supérieur aux onglets réguliers, et n'offre donc aucune raison impérieuse de s'adapter ... à mon avis :)

+1 @TurkeyMan

Dans l'équipe VS Code, nous travaillons sans onglets et sans fichiers de travail depuis le début (4 ans) et il ne nous manque rien. Donc, personnellement, je suis d'accord que la section des fichiers de travail est un espace perdu et je garde cette section réduite. Cependant, nous travaillons également avec l'enregistrement automatique activé et ne nous soucions généralement pas des fichiers sales. Les fichiers de travail ont été introduits principalement pour donner aux fichiers sales et sans titre un endroit où apparaître. Plus tard, nous avons décidé que c'était aussi un endroit utile pour aider les personnes qui manquent d'onglets traditionnels car il s'agit d'une représentation similaire, juste d'une autre manière de l'interface utilisateur.

Nous réservons de l'espace au-dessus de l'éditeur pour afficher les informations sur les fichiers et les actions. On pourrait dire que cet espace est le même que celui requis pour les onglets. Mais mon argument contre les onglets est que, généralement, l'espace horizontal n'est pas suffisant pour afficher la liste des fichiers de travail, car vous vous retrouvez rapidement avec ceci:

screen shot 2015-12-24 at 09 28 30

C'est le cauchemar que nous essayons d'éviter: vous devez faire défiler la liste des onglets à gauche et à droite pour trouver les fichiers que vous voulez. Les onglets ne fonctionnent bien que tant que vous n'avez pas plus d'onglets ouverts que ce qui peut être affiché horizontalement. Une fois qu'un onglet devient suffisamment petit pour que le nom du fichier soit masqué, vous devez commencer à fermer les autres onglets uniquement pour voir ce qui se passe.

Maintenant, évidemment, les fichiers de travail ont un problème similaire, juste dans une autre dimension. C'est pourquoi nous, dans l'équipe, utilisons généralement Ctrl+Tab pour tout et ne nous soucions pas de ce qui est ouvert ou non.

Pour résumer: les fichiers de travail ne sont pas notre réponse pour remplacer les onglets, c'est plutôt la combinaison de fichiers de travail et de Ctrl+Tab . Et notre équipe est plus ou moins à 100% en utilisant simplement Ctrl+Tab et rien d'autre.

Votre image semble exagérer inutilement le problème; fenêtre irréaliste étroite, bords de tabulation en diagonale, beaucoup trop de texte dans l'onglet, point à droite;)
vs-proper cloue magnifiquement les onglets, et il n'y a aucune raison de ne pas rouler avec de petits onglets discrets comme il le fait.

Je suis un utilisateur très libéral de Ctrl-Tab lorsque cela est applicable, mais vous ne pouvez pas utiliser Ctrl-Tab à moins que vous ne modifiiez activement pas plus de 2 ou 3 fichiers.
Je soupçonne que votre opinion sur cette question peut être assez biaisée en faveur de votre projet particulier, et cela pourrait inclure un biais linguistique. En C / C ++, le nombre typique de fichiers de travail est doublé ou triplé lorsque vous acceptez qu'il y ait un .h , et dans mon cas, souvent un .inl complétant chaque .cpp . Ctrl-Tab est moins efficace dans ce scénario, et vous avez tendance à utiliser Ctrl- ~ à la place (basculer cpp / h; pour lequel j'ai également publié une demande de fonctionnalité), en conjonction avec la gestion des onglets.
Ou considérez Java, où chaque classe - aussi petite soit-elle - doit vivre dans son propre fichier.

Dans mon quotidien actuel, j'ai souvent un ensemble de 10 fichiers de travail, Ctrl-Tab ne me sert à rien lorsque je travaille de cette façon. Le flux de travail le plus pratique est constitué de 2 à 4 fenêtres d'édition et de quelques onglets par fenêtre. Je n'ai pas choisi cette mise en page parce que je l'aime; il est simplement apparu, car c'est la disposition de l'espace de travail la plus efficace pour ce travail particulier.

+ 1
J'ai généralement l'éditeur divisé et la fermeture d'un onglet est un peu plus intuitive que d'avoir plus de 10 fichiers de travail.

Je ne travaille généralement que sur un sous-ensemble de fichiers et j'aime les garder à portée de main. 5/5 est plus facile à gérer qu'une liste de 10 pour moi personnellement. Je me déplace également activement entre eux en permanence. Les onglets aident également dans la mesure où il y a une indication visuelle que vous avez trop ouvert - le «tab hell» montré par @bpasero.

J'accepte que les onglets ne soient pas nécessairement le Saint Graal de la gestion des fenêtres. Cependant, pour les langages ou les projets sur lesquels plusieurs ensembles de fichiers doivent être utilisés, les onglets seraient moins difficiles à gérer.

Un exemple simple serait .cpp et '.h' avec des onglets, ce serait deux clics tous deux centrés sur le dessus de la fenêtre, tandis qu'avec des fichiers de travail, ce serait 3-4 clics avec des fichiers de travail qui vous obligent à sélectionner le éditeur en question, puis sélectionnez le nouveau fichier à éditer.

Les onglets et les onglets personnalisés permettraient également d'ajouter plus facilement certaines extensions intéressantes. Un exemple est une console ou un onglet de tracé. Celles-ci nécessiteraient des entrées spéciales dans la section du sélecteur de fichiers ou devraient être supprimées à la fermeture avec le système actuel. Je reviens très régulièrement sur mes parcelles donc la fermeture de la fenêtre nécessiterait alors qu'elle soit re-tracée. Ou la console serait fermée et les données à l'intérieur perdues.

Cependant, si une alternative appropriée est disponible, je serais heureux de la tester. Je pense juste que l'immobilier horizontal sur les écrans actuels est plus grand que l'immobilier vertical dont la conception actuelle de la gestion des fenêtres ne tire pas parti. Bien que je n'aimerais pas que les onglets soient plus grands verticalement que les noms actuels dans chaque fenêtre.

Je suis curieux de savoir pourquoi la mise en œuvre des onglets est si négative. Techniquement, ce n'est pas difficile et des fichiers de travail sont déjà implémentés; pourquoi pas les deux et laisser les utilisateurs décider?

Cela ressemble presque à des espaces v. Tabs, 2.0

Je suis curieux de savoir pourquoi la mise en œuvre des onglets est si négative. Techniquement, ce n'est pas difficile et des fichiers de travail sont déjà implémentés; pourquoi pas les deux et laisser les utilisateurs décider?

Cela ressemble presque à des espaces v. Tabs, 2.0

Tout à fait d'accord, il est probablement beaucoup plus facile de pousser la fonctionnalité en option (désactivée par défaut si cela rend les personnes anti-tabulation heureuses) et de suivre l'utilisation via des statistiques / commentaires que de théoriser sans fin si cela a du sens ou non.

Je me rends compte qu'il semble que nous ayons théorisé sans fin à ce sujet au lieu de faire quelque chose et de nous en excuser. Cependant, nous avons un élément pour résoudre ce problème dans notre arriéré (mentionné ci-dessus - # 1133). Nous n'avons tout simplement pas été en mesure de consacrer beaucoup de temps à ce sujet récemment, car nous avons travaillé dur sur la localisation et l'accessibilité.

Comme je l'ai mentionné ci-dessus, nous sommes conscients des problèmes liés à l'expérience actuelle de gestion des fichiers et nous avons un certain nombre de modifications que nous souhaitons apporter pour améliorer l'expérience.

L'un de nos objectifs avec VS Code est que lorsque nous apportons des modifications à l'interface utilisateur et à l'UX, nous nous assurons que VS Code reste un éditeur léger et puissant qui permet aux utilisateurs de se concentrer sur leur code. L'une des façons dont nous essayons d'y parvenir est de faire très attention à toute nouvelle interface utilisateur que nous ajoutons au produit.

Notre souci avec l'ajout d'onglets est qu'il introduit un autre ensemble de problèmes qui finissent par obliger l'utilisateur à se concentrer sur l'interface utilisateur au lieu du code. Notre expérience avec Visual Studio par exemple nous a montré que de nombreux utilisateurs se retrouvent souvent avec de nombreux onglets ouverts contenant des fichiers dont ils n'ont plus besoin et qui finissent par encombrer leur espace de travail. Cela provoque certains problèmes lorsque les utilisateurs recherchent des fichiers et d'autres ressources de code. Pour résoudre ces problèmes, une interface utilisateur supplémentaire est nécessaire pour permettre aux utilisateurs de fermer tous les onglets, de fermer tous les onglets sauf cet onglet, les contrôles de débordement d'onglets, etc. Nous voulons éviter cette situation et espérons que les conceptions sur lesquelles nous travaillons nous aideront à y parvenir.

Ce n'est pas un débat idéologique - nous essayons vraiment de maintenir l'esthétique minimale qui, selon nous, offre une expérience légère et puissante. Nous faisons simplement très attention à l'introduction de nouvelles interfaces utilisateur et UX dans le produit.

Il est tout à fait possible qu'après quelques cycles de conception et de recherche à ce sujet, nous finissions par introduire des onglets. Mais nous ne le ferions qu'en sachant que c'est le meilleur moyen d'améliorer la façon dont les utilisateurs gèrent les fichiers et les actifs avec lesquels ils travaillent, mais cela ne finit pas par encombrer l'interface utilisateur.

J'espère que cela aidera à expliquer notre point de vue à ce sujet. Et je m'excuse encore d'avoir fait croire que nous regardons le nombril et que nous ne faisons rien à ce sujet.

Merci @stevencl , c'est bien que ce soit au moins sur le radar et qu'il y ait un brainstorming en cours.

Notre souci avec l'ajout d'onglets est qu'il introduit un autre ensemble de problèmes qui finissent par obliger l'utilisateur à se concentrer sur l'interface utilisateur au lieu du code.

Je sens que je dois me concentrer sur l'interface utilisateur au lieu du code pour le moment, donc cet argument va dans les deux sens. :)

de nombreux utilisateurs se retrouvent souvent avec de nombreux onglets ouverts contenant des fichiers dont ils n'ont plus besoin

C'est intéressant que vous disiez cela, car j'ai en quelque sorte l'impression qu'une partie de l'intérêt des fichiers de travail était d'encourager à garder plus de fichiers ouverts à la fois. Ce que vous décrivez ici est susceptible de se produire également avec des fichiers de travail, au moins avec les raccourcis clavier par défaut (et c'est pourquoi j'ai joué avec le changement des raccourcis clavier pour fermer l'éditeur actif et fermer complètement le fichier de travail).

En fin de compte, si VS réussissait à répliquer facultativement le comportement des onglets (auquel il semble qu'au moins une des choses de # 1133 se rapporte) tout en le gardant de côté, cela pourrait être un bon début . Ctrl + ordre de tabulation étant MRU vs ordre d'apparition est une autre chose (Sublime permet les deux via différentes commandes pouvant être liées).

@stevencl , merci pour votre réponse. Je voudrais commenter certains de vos points:

[...] nous sommes conscients des problèmes liés à l'expérience actuelle de gestion des fichiers et nous souhaitons apporter un certain nombre de modifications pour améliorer l'expérience.

J'attends certainement avec impatience ce qui semble être un très bel avenir pour VS Code. J'étais ravi d'apprendre que Microsoft apportait un IDE aussi puissant que Visual Studio dans des mondes au-delà de Windows, et pour adopter de nouveaux paradigmes de développement d'applications avec Electron. Félicitations pour votre travail à ce jour!

L'un de nos objectifs avec VS Code est que lorsque nous apportons des modifications à l'interface utilisateur et à l'UX, nous nous assurons que VS Code reste un éditeur léger et puissant qui permet aux utilisateurs de se concentrer sur leur code.

Je ne pense pas que quiconque puisse apporter un argument convaincant en faveur des onglets rendant les interfaces faibles, lentes ou distrayantes. En fait, il y a beaucoup plus d'espace horizontal pour les onglets que d'espace vertical au-dessus de l'arborescence du projet. Le fait d'avoir les fichiers de travail là-bas, pour moi, rend la gauche de la fenêtre beaucoup plus encombrée qu'elle ne devrait l'être.

Notre souci avec l'ajout d'onglets est qu'il introduit un autre ensemble de problèmes qui finissent par obliger l'utilisateur à se concentrer sur l'interface utilisateur au lieu du code.

Y aurait-il une raison d'utiliser autre chose que TextEdit ou Notepad s'il s'agissait uniquement de se concentrer sur le code? Stipuler que la fonctionnalité, à toutes fins utiles, est la même dans la plupart des éditeurs, l'interface utilisateur / X utilisée pour atteindre cette fonctionnalité et la qualité de celle-ci est vraiment là où un produit se distingue.

Notre expérience avec Visual Studio par exemple nous a montré que de nombreux utilisateurs se retrouvent souvent avec de nombreux onglets ouverts contenant des fichiers dont ils n'ont plus besoin et qui finissent par encombrer leur espace de travail. Cela provoque certains problèmes lorsque les utilisateurs recherchent des fichiers et d'autres ressources de code.

Voici un argument que je ne pense pas important pour ou contre les onglets ou une liste de fichiers de travail; lorsque vous travaillez avec plusieurs fichiers, vous devrez toujours interrompre votre concentration pour rechercher des ressources de code.

Même ainsi, la liste des fichiers de travail ne résout toujours pas le problème. Trop de fichiers de travail font défiler la liste et la liste ne peut pas être développée. Donc, au lieu de faire défiler les onglets, vous allez plus rapidement faire défiler la liste des fichiers de travail.

[...] nous essayons vraiment de maintenir l'esthétique minimale qui, selon nous, offre une expérience légère et puissante. Nous faisons simplement très attention à l'introduction de nouvelles interfaces utilisateur et UX dans le produit.

Je peux apprécier et soutenir cette position dans une certaine mesure. Lorsque la communauté fait entendre sa voix, vous devez commencer à parler de l'adoption par les utilisateurs. N'est-ce pas pourquoi vous avez placé le manque de pliage de VS Code comme un problème d'adoption par les utilisateurs dans votre feuille de route pour mars? Certaines choses sont telles qu'elles sont et pour une bonne raison. Le menu Démarrer sur Windows et le dock sur OSX viennent à l'esprit.

[...] Je m'excuse encore d'avoir fait croire que nous regardons le nombril et que nous ne faisons rien à ce sujet.

Ce n'est certainement pas mon point de vue, donc pas de soucis là-dessus. Pour les raisons que j'ai déjà énoncées, une conversation saine à ce sujet ne peut certainement qu'améliorer le but principal qu'est l'interface utilisateur / X de VS Code.

Je veux aussi intervenir et dire simplement que je pense que je ne sens pas du tout le «nombril». Le timing de ce problème est en partie responsable - le 19 novembre ne donne pas le temps de le mettre n'importe où en décembre et peut-être en janvier, en fonction de la mesure dans laquelle les choses sont prévues. De plus, cette conversation qui a recommencé est plus importante que la simple implémentation aléatoire d'onglets parce que les utilisateurs le veulent.

Je suis d'accord avec ianwesterfield en ce que l'interface des fichiers de travail n'est pas idéale et qu'il y a plus d'espace horizontal que d'espace vertical. Des listes de fichiers massives et de nombreux fichiers commutés sont les faiblesses actuelles de vscode en termes de gestion des fichiers de travail.
Lorsque vous commencez à parcourir 16 fichiers différents, être capable de gérer à quel éditeur divisé ils appartiennent est quelque chose que les fichiers de travail seraient difficiles à battre. Cela étant dit, diviser la liste des fichiers de travail en deux sections différentes serait une solution raisonnable.

Cependant, stevencl a fait un argument qui me rend très heureux. "Il est tout à fait possible qu'après quelques cycles de conception et de recherche à ce sujet, nous finissions par introduire des onglets. Mais nous ne le ferions qu'en sachant qu'il s'agit de la meilleure façon d'améliorer la façon dont les utilisateurs gèrent les fichiers et les actifs sur lesquels ils travaillent. avec, mais ne finit pas par encombrer l'interface utilisateur. " En essayant réellement de nouvelles choses, des améliorations peuvent être apportées.

Un moyen plus simple de gérer les fenêtres fractionnées serait déjà une amélioration. Je peux faire un argument pour les fichiers de travail en ce que la gestion des fenêtres peut TOUJOURS être au même endroit. La gestion des onglets demande plus d'effort lorsque vous souhaitez réorganiser 2-4 divisions (écran haute résolution + atome = division horizontale et verticale si nécessaire). Il existe donc une solution possible qui conserve l'interface des fichiers de travail mais l'étend plutôt pour qu'elle soit un peu plus complexe.

Merci, j'apprécie l'opportunité d'avoir cette conversation.

@ianwesterfield , vous avez raison sur les fichiers de travail et vous avez mis en évidence l'un des problèmes que nous voulons résoudre. Il y a aussi d'autres problèmes, dont beaucoup ont mis en évidence

Ayant travaillé sur la conception de Visual Studio pendant un certain nombre d'années, j'ai cependant vu les problèmes UX que les onglets peuvent causer. J'ai passé 18 mois à travailler sur l'expérience des onglets d'aperçu dans Visual Studio, ce qui tente de réduire le problème de `` l'enfer des onglets '' décrit ci-dessus par @bpasero .

Nous voulons éviter de nous retrouver dans une position où cela devient nécessaire. Nous voulons donc continuer sur notre conception approfondie pour découvrir les options qui s'offrent à nous, puis en choisir une. Comme je l'ai dit plus tôt, il se pourrait bien que nous nous retrouvions avec des onglets. Si nous le faisons, nous saurons que c'est la meilleure approche que nous pourrions créer qui fournira une excellente expérience pour la gestion des fichiers et d'autres actifs de code.

Merci pour toutes les informations et descriptions des problèmes que vous rencontrez actuellement avec la façon dont nous gérons les fichiers dans VS Code.

@stevencl , c'est drôle que vous mentionniez l'onglet d'aperçu - j'adore. C'est formidable de voir comment VS Code, Sublime, Atom, Brackets (via l'extension), etc. ont une fonction de prévisualisation comme celle-ci par défaut.

Je suis très heureux que Microsoft nous ait donné l'opportunité de participer à des discussions de conception en cours en gardant ce projet ouvert. Si les utilisateurs n'avaient cette voix que lors de la refonte du menu Démarrer, Windows n'aurait peut-être pas eu besoin d'un autre cycle de publication pour enfin obtenir une intégration massive après Windows 7.

Il est tout à fait possible qu'après quelques cycles de conception et de recherche à ce sujet, nous finissions par introduire des onglets. Mais nous ne le ferions qu'en sachant que c'est le meilleur moyen d'améliorer la façon dont les utilisateurs gèrent les fichiers et les actifs avec lesquels ils travaillent, mais cela ne finit pas par encombrer l'interface utilisateur.

Depuis que j'ai ouvert ce numéro, qui semble avoir refait surface, je voudrais juste ajouter que je pense que ce commentaire est assez satisfaisant. Je soupçonne plutôt que des onglets vont apparaître, mais je soutiens totalement l'exploration de nouvelles idées, et le code est une excellente plateforme pour ce faire. J'adore le travail que vous avez accompli jusqu'à présent.
Cela dit, gardez à l'esprit que nous voulons _utiliser_ ceci, et plus tôt je pourrai l'utiliser comme mon éditeur principal, mieux ce sera, donc j'apprécierais si vous pouviez nous donner une expérience familière (encore légère) qui nous pouvons utiliser de manière productive et nous sentir chez nous en ce moment, et nous pouvons continuer notre travail. Ensuite, vous pouvez prendre tout le temps du monde pour explorer de nouveaux horizons :)
C'est juste que nous attendons avec impatience le code pour atteindre la ligne magique où nous pouvons l'adopter à plein temps. Pour moi, les onglets sont mon seul problème d'utilisation, la compilation et le débogage natifs sont mon seul problème technique.

Je ne pense pas que je sois le seul utilisateur de Windows fatigué et souffrant qui soit désespérément accro au studio visuel. Le salut n'est que quelques petits problèmes et fonctionnalités hors de notre portée, il progresse rapidement, et je suis reconnaissant d'avoir l'opportunité de participer et de regarder avec une telle visibilité.

Malheureusement, Windows reste la pire plate-forme / écosystème de développement, avec le meilleur environnement de développement, et il en est ainsi depuis 15 ans. Vraiment bizarre.
Je ne sais pas pourquoi, mais il semble que pour moi, l'environnement de développement (productivité) l'emporte sur l'écosystème dans mon équilibre, mais c'est un équilibre douloureux et je serai aussi heureux qu'un cochon dans la boue quand je pourrai utiliser VS sous Linux pleinement -temps! Nous sommes si proches!
Je sais que vous voyez cela comme un véhicule pour explorer de nouveaux territoires, et c'est totalement cool, mais à court terme, nous voulons vraiment juste VS sur linux, (ou osx, si vous balancez de cette façon), comme nous avons rêvé pour un une dizaine d'années, et nous pouvons enfin, après toutes ces années, mettre fin à nos souffrances! ;)
</dramatic_commentary>

TL; DR, l'exploration est tout à fait géniale et je suis convaincu que vous êtes déterminé à offrir le meilleur produit final que vous puissiez créer, mais des solutions sûres et familières en attendant peut-être?

+1 pour les onglets. La question: pourquoi ne pas le supprimer de Visual Studio Bundle alors? Voyez ce qui se passe alors ...

+1 pour les onglets! Veuillez l'implémenter dans une future mise à jour.

L'hypothèse courante semble être que "[les onglets] dans la plupart des cas grandissent tellement que vous finissez par ne rien voir". Je voudrais contester cette hypothèse. J'utilise les onglets comme index visible des fichiers qui m'intéressent actuellement et je gère activement cet index à mesure que mon intérêt évolue au fil du temps. La visibilité est importante: je me réfère constamment aux onglets physiques pour me réorienter. Avec Working Files, je suis privé de ma capacité à afficher et à manipuler cet index. Par exemple, il ne semble pas y avoir de moyen de supprimer un fichier des fichiers de travail via le clavier. J'ai l'impression de me battre contre l'éditeur. Veuillez ajouter des onglets de style Sublime Text.

Bien que je convienne que VS Code fonctionne correctement sans onglets maintenant (je l'utilise depuis le début de manière assez productive), je suis également d'accord avec certains commentaires ci-dessus qui suggèrent d'avoir des onglets en option (peut-être désactivés par défaut) et de laisser les utilisateurs décider s'ils les veulent ou ne pas.

Tout le monde est différent, donc avoir une option là-bas serait génial. Même si je peux bien travailler sans eux, cela ne me dérangerait pas de les avoir ajoutés et je les utiliserais probablement pendant - trop d'années d'utilisation de VS full. On dirait qu'ils sont déjà dans l'arriéré - merci!

+1 pour les onglets. Presque 1 an de travail avec VSCode et je l'aime beaucoup. Mais il manque toujours des onglets, en particulier lorsque vous travaillez avec le débogage ou la recherche, ou la section de gauche git. Les onglets aident à ne pas penser à quel fichier contient du code, vous avez déjà travaillé. Je pense que les utilisateurs gèrent les onglets et leur ordre pour garder à l'esprit également une position d'onglet, qui peut être associée au code source sur lequel ils travaillent. Les onglets de l'éditeur fractionnés peuvent également conserver cette intention.

Ctrl + tab est une action clé et les tabulations sont une action visuelle, qui est beaucoup plus rapide.

Je pourrais probablement vivre sans onglets ... si VS n'était pas si mal dans la gestion des "fichiers de travail". J'ouvre très souvent des fichiers simplement pour me référer à l'intérieur d'eux, sans les modifier, mais VS ne place pas ces fichiers dans ma liste de fichiers de travail, alors que j'aurais certainement un onglet ouvert dans un environnement à onglets.

Ceci combiné avec le fait que lorsque vous fermez un fichier / concentrez-vous sur un nouveau fichier "fonctionnel", l'explorateur de fichiers SE DÉPLACE vers le fichier ouvert au lieu de rester sur votre dernier emplacement crée une expérience très déroutante.

Je comprends que ce ne sont pas des soucis pour vous puisque "vous l'avez utilisé sans onglets pendant 4 ans", donc tout ce qui sort de la portée Ctrl + Tab est considéré comme une manière étrange d'utiliser le programme.

Cela doit être une fonctionnalité et si elle est activée ou désactivée par défaut n'a pas d'importance. Pratiquement tous les éditeurs de texte / IDE utilisent des onglets pour la navigation. Peut-être que certains pensent qu'il existe un meilleur moyen, mais pour la plupart d'entre nous, les onglets sont efficaces, faciles à utiliser et familiers ... et évidemment nous les adorons! Sortez-les de Visual Studio pour une version pour voir à quel point ils sont importants ... (cue la fusion épique des développeurs de style Metro) Veuillez considérer les onglets pour une version à court terme. c'est la seule chose qui retient beaucoup d'entre nous de l'adoption à plein temps de VSCode.

: +1:

Je suis beaucoup plus productif avec les onglets! J'utilise Atom comme j'utilise Google Chrome (Ctrl + 1 pour le premier onglet, Ctrl + 5 etc. Ctrl + Tab, Ctrl + Shift + tab).

Les fichiers de travail me rendent moins productif et je me sens toujours un peu frustré après l'avoir utilisé.

Alors s'il vous plaît, implémentez des onglets.

Les onglets seront très utiles, +1

: +1:

@MadSpindel "Les fichiers de travail me rendent moins productif et je me sens toujours un peu frustré après l'avoir utilisé." 1000% d'accord ... c'est comme si nous étions obligés de ne pas utiliser d'onglets pour que quelqu'un fasse valoir un point ou quelque chose. Nous ne l'aimons pas, si vous l'aimez, alors rendez-le facultatif pour nous s'il vous plaît.

Visual Studio Power Tools a une option pour afficher les onglets verticalement, ce que j'adore.

: +1: et je suis d'accord avec @sitefinitysteve. Si l'équipe insiste pour ne pas avoir d'onglets, améliorez au moins l'API d'extension afin qu'elle puisse être ajoutée par un tiers.

Voici où les onglets sont importants - nous devons revenir un instant sur une autre fonctionnalité manquante:

VSCode doit vider l'implémentation non informative des fichiers de travail, puis ajouter la fonctionnalité permettant d'ouvrir plusieurs projets. Je fais mon travail en séparant mon code côté client en un projet et mon code côté serveur en un autre projet. Sur un grand écran, je veux ouvrir deux fenêtres de codage, avec une arborescence de projet à l'extrême gauche. Code client dans la fenêtre de gauche, code serveur dans la fenêtre de droite. Maintenant, dans l'un ou l'autre projet, je travaillerai sur plusieurs fichiers source. Dans ces cas, je veux les référencer comme des onglets au-dessus de la fenêtre de projet respective dans laquelle ils ont été ouverts. Je peux avoir 3 ou 4 onglets sur le projet côté client et 3 onglets ou plus sur le projet côté serveur.

L'organisation est organique. L'ensemble de l'arborescence du travail, plusieurs projets, est affiché sur la gauche. J'ai une séparation de projet par fenêtres de code et j'ai également des fichiers open source en cours de travail, ou référencés, par des onglets au-dessus de leurs fenêtres de projet respectives.

C'est un workflow essentiel pour moi. Je fais actuellement exactement cela dans Atom mais j'aime VSCode et j'aimerais voir ce flux répliqué dans VSCode. Pour ce faire, VSCode doit implémenter la prise en charge de plusieurs projets et des onglets au-dessus des fenêtres respectives. Sinon, c'est juste un autre rédacteur en chef, et je ne le crois pas. S'il vous plaît.

@riclf l' a bien

J'ai généralement 3 colonnes verticales ouvertes, HTML, JS et CSS de gauche à droite.

Dans Sublime j'avais tous mes onglets html au-dessus de la première colonne, tous les fichiers JS sous forme d'onglets au-dessus de la deuxième colonne, etc. Les onglets ont un contexte et je sais que je ne vais pas ouvrir le mauvais fichier dans la mauvaise colonne.

C'est presque impossible dans VS Code, je ne peux ouvrir 3 colonnes qu'en utilisant deux fois "ouvrir sur le côté", et une colonne peut disparaître totalement si un fichier est fermé, à quel point je peux en ouvrir un nouveau mais je dois le réorganiser leur. Si j'ouvre un fichier, il s'ouvre à nouveau dans la colonne dans laquelle se trouve actuellement le curseur, donc si j'ouvre un fichier css, je dois m'assurer que mon curseur est dans la troisième colonne. C'est absolument exaspérant.

Sans oublier que la section Fichiers de travail prend un certain espace vertical dans mon arborescence de dossiers, ce qui est un réel problème sur mon ordinateur portable.

Une question pour l'équipe Microsoft. Si vous avez une vue fractionnée, comment êtes-vous censé savoir à quelle colonne un fichier dans "fichiers de travail" est associé? C'est simple lorsque les onglets sont au-dessus de leurs colonnes respectives.

Juste mon 2c.

Je n'avais aucun malaise cognitif pour m'habituer aux fichiers de travail. Je les aime beaucoup plus que les onglets. L'interface utilisateur de VSCode est sur la bonne voie. Je ne suis pas contre les onglets opt-in, mais jetterait un coup d'œil aux onglets opt-out.

Les fichiers de travail sont des onglets dans une meilleure mise en page (plus d'espace de défilement). Il leur manque des fonctionnalités "déchirer" et glisser, qui pourront être ajoutées ultérieurement.

En tant qu'utilisateur mvim, j'ai plusieurs ensembles de fichiers TDD ouverts et tabulés entre eux. Par exemple, j'ai angular + tests, serveur + tests, concombre ou behave + scripts. Je ne veux pas tabuler pour accéder à un seul fichier, mais à une combinaison de fichiers ouverts. Je suis passé à VSCode pendant 3 mois pour un projet Typescript, car il avait vraiment le meilleur support de Typescript / incroyable. Cependant, dès que je suis passé à un projet non-Typescript, j'ai trouvé que j'avais comparé ses capacités de recherche, de navigation et de substitution à usage général directement à mvim et je suis désolé de dire que je suis rapidement (c'est-à-dire instantanément) revenu à mon ancien éditeur. J'ai un écran Apple Cinema de 27 pouces et j'aurais un écran plus grand si possible. J'ai beaucoup de place pour beaucoup d'onglets et de paires de fichiers, et je n'ai pas de raison impérieuse d'être limité dans l'utilisation de cet espace par mon éditeur Je ne veux pas traiter un seul fichier à la fois - je veux en ouvrir plusieurs et suivre le flux d'un onglet à l'autre.

J'ai donné à Visual Studio Code un autre essai il y a deux semaines. En fait, j'ai été agréablement surpris quand je me suis contenté de quelques fichiers. Mais quand j'ai commencé à travailler sur un (gros) projet réel avec plus d'une poignée de fichiers ouverts, le manque d'onglets est devenu très ennuyeux. _Working Files_ ne me convenait tout simplement pas et cela m'a ralenti. Après 3 jours, j'étais tellement ennuyé que je suis retourné à Sublime Text. J'ai deux écrans de 24 "au travail (Windows), un Mac de 27" à la maison et je peux facilement ouvrir 20 onglets et distinguer quel fichier est lequel. Beaucoup de biens d'écran pour les onglets dans mon cas. _Vous_ affichez déjà le nom de fichier du fichier qui est ouvert dans l'éditeur. Tout l'espace à droite du nom du fichier est inutilisé (à l'exception des icônes à droite de la fenêtre) et pourrait être rempli d'onglets (ce que fait aussi Sublime Text). Je dis donner aux utilisateurs la possibilité de travailler avec _Working Files_ et / ou onglets de fichiers. Pour l'instant, je reviens à un combo de Sublime Text et Visual Studio Enterprise. Lorsque les onglets seront ajoutés, je reconsidérerai.

Pour l'option Working Files , je dois basculer la barre latérale (car je la garde cachée pour une vue étendue du code) pour sélectionner le fichier. Et les options Ctrl+P et Ctrl+tab ne sont pas non plus conviviales.

Je sais que vous essayez quelque chose de différent pour cela, mais les options que vous avez déjà fournies ne sont pas conviviales. Désolé.

veuillez fournir une extension pour cela, afin que les utilisateurs aient la possibilité d'utiliser des onglets au lieu d'être forcés d'utiliser la liste de travail. Je déteste vraiment la fonctionnalité des fichiers de travail, cela me fait changer de fichier lentement et me volé ma productivité

Quand j'étais nouveau dans VS Code, j'ai vraiment manqué des onglets. Puis j'ai découvert ctrl + tab et je n'en ai plus besoin.

J'essaie de faire de vscode (ce qui est génial dans la plupart des cas) mon éditeur principal depuis plusieurs mois, mais le manque d'onglets continue de m'ennuyer et de nuire à ma productivité (je fais partie de ceux qui gèrent activement l'ensemble des onglets ouverts dans d'autres éditeurs). Ctrl + tab ne remplace pas les onglets.

Il est évident que l'équipe vscode est biaisée contre cela, et vise actuellement à «convaincre» les utilisateurs qu'ils n'ont pas vraiment besoin d'onglets. Mais c'est le même type de réflexion qui a conduit à la suppression du menu Démarrer de Windows 8 (nous savons tous comment cela s'est terminé).

@pesho Exactement!

Maintenant que le pliage du code est terminé, c'est le principal problème de User Voice. Nous évaluons un certain nombre d'options en interne alors que nous continuons à évaluer les commentaires de la communauté, les tests d'expérience utilisateur, etc. Merci à tous pour la discussion ici. Très utile.

C'est probablement la seule raison pour laquelle j'ai ouvert pour la première fois vscode il y a presque un an et l'ai fermé juste après quelques minutes de jeu. et vous n'avez toujours pas d'onglets. J'espère qu'il apparaîtra bientôt, pour que je puisse l'utiliser. Son Open Source, et les gens de Microsoft doivent changer d'avis (c'est ce qu'ils tentent de faire maintenant, n'est-ce pas?) Et écouter la communauté, pas simplement "nous utilisons cet outil en interne et nous n'avons pas besoin d'onglets bla bla"

@pleerock Vous n'allez même pas essayer un IDE car il n'a pas d'onglets?! (Oo) weeeweweweweeeww. Ils ne veulent pas ajouter d'onglets car les onglets sont inutiles, verbeux, ils n'ajoutent généralement aucune valeur tout en ajoutant le poids supérieur sur l'espace des fenêtres. Les alternatives offrent plus de métadonnées, une facilité d'utilisation et une navigation plus rapide.

Avec les onglets, je choisis les fichiers qui restent ouverts. Qu'il s'agisse de l'onglet CTRL + ou de "Fichiers de travail", si j'ouvre un fichier pour y rechercher du code, que j'en passe à un autre pour utiliser ledit code, je n'ai aucun moyen de revenir à mon premier fichier sans avoir à re- accédez au fichier dans l'explorateur.

Je sais que j'ai 3 éditeurs, mais parfois je ne veux pas remplacer les 2 autres avec mon fichier de code de recherche uniquement.

Si lorsque j'ouvre un fichier, il reste dans les différents historiques de fichiers, alors je vais bien sans onglet. Peut-être que si un fichier a été ouvert plus de 5s, il mérite une entrée en CTRL + Tab.

@ 4tron oui c'est pour moi, car je veux utiliser l'IDE qui me convient. pour quelqu'un, perdre des onglets est inutile et sûr de leur espace (ils utilisent probablement des netbooks et n'ont pas assez d'espace pour vraiment quelques pixels supplémentaires =)), pour d'autres, c'est pratique et augmente leur productivité. Tout bon logiciel doit être personnalisable et avoir la capacité de masquer / afficher des panneaux. "économiser un espace" n'est pas argumenté. Introduire les onglets + ajouter la possibilité de les afficher / masquer (si c'est vraiment nécessaire pour quelqu'un =)) c'est la meilleure façon de procéder. Pas besoin d'ouvrir une nouvelle Amérique ou d'utiliser de mauvaises innovations, besoin d'apprendre des meilleurs IDE ici qui ont fait de l'UX de mieux en mieux pendant des années, comme intellij, visual studio et autres

C'est vraiment simple - faites-en une préférence - onglets ou pas d'onglets. Lorsque les onglets sont activés, pas de fichiers de travail, lorsque les onglets sont désactivés, les fichiers de travail. C'était Genius! ;)

Moi, je suis un gars des onglets. Je trouve que les fichiers de travail sont très limités et peu intuitifs, ainsi que prennent de l'espace vertical dans l'arborescence du projet. Mais peu importe si nous ne pouvons pas ouvrir plus d'un projet. :(

Je pense qu'une préférence devrait également convenir.

J'ai également pensé à un moyen d'améliorer le système de fichiers de travail. Vous devez utiliser la ligne de tabulation comme historique.
Par exemple, si vous ouvrez 4 fichiers dans la fenêtre de gauche, puis en ouvrez un cinquième en faisant sortir le fichier modifié le plus ancien de la ligne de tabulation, il devrait disparaître et revenir en tant que "fichier modifié" dans les fichiers de travail.

Vous pouvez également le rendre intelligent, le système peut également donner la priorité à la disparition des premiers fichiers enregistrés et donc non modifiés.

Le fait est que les onglets sont tellement pratiques, même si les ballonnements sont un problème. Vous devriez réfléchir à un moyen d'utiliser les onglets mais en limitant le nombre d'entre eux.

Habituellement, je garde des onglets ouverts que je n'ai pas modifiés depuis des jours. c'est généralement celui qui le fait gonfler.

+1

J'ai un écran 4K et ne pas avoir d'onglets à l'horizontale me désactive vraiment de VsCode

BTW, je tiens à préciser que je ne veux pas seulement des onglets, je voudrais des ensembles d'onglets. En tant que développeur full stack mvim TDD sur Mac, je pense en termes de contextes. html + css, tests angulaires +, nœuds + tests, concombre + étapes de test. Je travaille normalement dans un seul contexte pendant quelques lignes de code avant de passer au contexte suivant, le style TDD. Lorsque j'utilise mvim, non seulement je bascule très rapidement entre ces contextes (en utilisant la même séquence de touches que j'utilise pour Mac Terminal, Mac Finder et Safari ou Chrome), mais je bénéficie de macros qui ouvrent automatiquement le fichier apparié, de sorte que d'un fichier source angulaire, je peux ouvrir automatiquement le test correspondant. C'est une façon incroyablement productive de travailler et de garder mes doigts sur le clavier.

Si je trouvais un IDE qui me permettrait d'ouvrir des fichiers "associés" dans des cadres les uns à côté des autres, juste en changeant un onglet, par exemple lorsque j'ouvre button.html, il ouvrirait button.js à côté et button.scss dans le troisième image, je n'utiliserais plus jamais un autre IDE.

Je sais que ça n'arrivera jamais, mais dis juste.

Eh bien, vous devriez utiliser mvim! http://www.vim.org/scripts/script.php?script_id=1567 Commande: AV ouvre les fichiers associés (A pour associé).

Ce dont @jtosey parle, c'est exactement ce que je suis venu dire ici. J'utilise des volets pour organiser un ensemble de fichiers associés. La plupart de la gestion des onglets consiste à placer ces fichiers associés les uns à côté des autres lorsque je change de contexte.

+1

Même chose ici, j'adorerais les onglets.

Je viens de passer à VSCode d'Atom et j'ai remarqué à quel point il est incroyablement organisé et propre après avoir travaillé avec lui pendant un certain temps. La raison? Pas de surpopulation d'onglets! Le manque réel d'onglets est ce qui rend cette expérience si fluide. Ma navigation principale dans les fichiers est le menu commande-P qui me permet de passer rapidement à n'importe quel fichier.

Les onglets VS sont parfaits, veuillez apporter des onglets, le désancrage des onglets dans une fenêtre séparée serait également génial!
Merci pour vscode :)

Je suis en fait assez curieux de savoir si vous voulez faire de VSC un éditeur de fichiers à usage général, ou simplement un éditeur de code source.

Il y a quelques situations où une barre d'onglets est absolument requise.

  1. Basculez rapidement entre de nombreux onglets.
    Une situation courante pour moi est que je dois comparer 2 fichiers ou plus par leur forme, par exemple pour comparer entre le chinois simplifié et son équivalent traditionnel. Un diff ne résoudra pas le problème car ce sont des personnages différents. Le seul moyen est de basculer rapidement entre les onglets pour voir s'il manque un mot dans vos globes oculaires. En utilisant ST et je peux changer d'onglet en utilisant Alt-NUM, mais dans VSC, le seul moyen possible est d'utiliser plusieurs Ctrl-Tab, ou la souris se déplaçant rapidement et en cliquant.
  2. Noms de fichiers longs et difficiles à saisir.
    Utiliser Ctrl-P pour basculer entre les fichiers n'est pas mal. Mais qu'en est-il de certains noms de fichiers qui partagent un long correctif commun? Et certains noms qui ne sont pas en anglais? Considérez combien de temps passeriez-vous sur Ctrl-P pour basculer entre 青年急着买房的原因(上).md et 青年急着买房的原因(下).md ?

Je dirais qu'aucune des situations ne vous touchera lors de l'écriture de code, mais en tant qu'éditeur polyvalent, c'est un problème sérieux.

@ msg7086 Je ne suis pas sûr de un point , mais pour le point deux pourriez - vous pas ctrl + p et puis tapez .md vous laissant avec les deux options, puis seulement ctrl + tab pour choisir celui que vous vouloir? Je ne suis pas sûr de bien comprendre le problème

@ 4tron Merci pour la réponse. Cependant, votre méthode ne fonctionne que si je n'ai que 2 fichiers de ce type. En réalité, les gens travailleront probablement avec plusieurs de ces fichiers dans un seul répertoire. Imagerie J'écris un blog qui contient 50 articles au format markdown, avec différents caractères en chinois, coréen ou arabe, etc. comme noms de fichiers. Le vrai scénario auquel je faisais face était en fait des fichiers de sous-titres avec des noms CJK, où tous sont *.ass , donc Ctrl + P par extension ne fonctionne pas très bien.

J'apprécie vraiment si cela peut être mis en œuvre

Les développeurs y sont habitués, veuillez en faire une priorité .

+1 pour les onglets. Veuillez implémenter des onglets.

+1 pour les onglets!

Je vote aussi pour l'ajout d'onglets.

+1

+1

+1

Nous avons besoin d'onglets dès que possible.

Les onglets me manquent. Je continue à les chercher, ce serait bien de renvoyer rapidement deux ou trois documents ouverts différents.

Quel est le problème?

  • La zone des fichiers de travail est verrouillée en hauteur, même problème que trop d'onglets, sauf que c'est fastidieux à gérer (pas de souris ni de molette de défilement ici). Les onglets peuvent être bannis facilement, donnant à l'utilisateur le document suivant dans la pile de fichiers ouverte.
  • La colonne Explorer dans Code est beaucoup plus large que Sublimes, parfois on veut la minimiser lors de l'exécution de deux applications côte à côte pour gagner de la place (Unity à gauche, Code à droite par exemple). Les onglets n'ont besoin d'aucun gain de place pour fonctionner, Code a déjà une belle zone vide où ils peuvent aller.
  • Les onglets gagnent pour la facilité d'utilisation et l'économie d'espace, aucune recherche UX n'est nécessaire. Ils sont rapides à utiliser et nous les aimons tous.

Veuillez nous donner la gestion des documents par onglets :)

+1, moi.

+1

+1

VSCode est un excellent éditeur et possède de jolis points d'intégration avec Git et Nodejs. La principale raison pour laquelle je ne l'utilise pas comme IDE de développement principal est qu'il ne prend pas en charge les onglets.

Pareil ici. C'est la seule chose qui me retient de l'utiliser.
Op faire 10 mrt. 2016 à 15:18 schreef Konrad Piascik < [email protected]

VSCode est un excellent éditeur et possède de jolis points d'intégration avec Git et
Nodejs. La principale raison pour laquelle je ne l'utilise pas comme IDE de développement principal
est parce qu'il ne prend pas en charge les onglets.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036.

C'est un peu surprenant de voir autant de repoussements sur ce problème étant donné qu'il devrait être si facile à mettre en œuvre. À tout le moins, faites-en une option ou disponible via une extension (comme le fait Brackets).

Si cela est ajouté, veuillez ajouter ce qui suit:

  1. Fermez des fonctionnalités telles que Google Chrome. (J'ai toujours été ennuyé que la version standard de VS n'ait pas cela.)
    - " Fermer les autres onglets "
    - " Fermer les onglets à droite ".
  2. Une option pour ouvrir l'onglet à droite ou à gauche. (VS a changé la valeur par défaut à un moment donné, mais a ensuite ajouté une option pour changer)

Les onglets fonctionnent. Ils sont partout, les gens y sont habitués. La liste actuelle des fichiers n'est pas intuitive. Après 2 mois d'utilisation quotidienne de VS Code, je me retrouve toujours à aller chercher un onglet presque chaque fois que j'ai besoin de changer de fichier. Le fait que tous les autres éditeurs continueront à utiliser des onglets crée un énorme obstacle pour que quelque chose de différent devienne intuitif.

Dans mon équipe, les gens se plaignent tout le temps à ce sujet, au point que certaines personnes préfèrent utiliser sublime sans aucun support dactylographié puis utiliser VS Code.

Je ne suis pas contre la recherche UX pour trouver une «meilleure» façon de gérer les fichiers ouverts, mais s'il vous plaît ne faites pas de nouveau le fiasco du ruban Office, qui a pris une demi-décennie et plusieurs versions pour inventer une autre façon de faire exactement le même chose.

-1

Quelques notes expliquant pourquoi je suis contre les onglets:

  • Tout temps passé sur les onglets sera perdu pour apporter d'autres améliorations à l'éditeur.
  • Je me suis forcé à devenir davantage un commando clavier et ne pas avoir d'onglets a été utile. Donc, je discute du point de vue c'est-pour-votre-bien même si je n'y suis même pas encore moi-même.
  • Lié au précédent, cela me rappelle quand Gmail est sorti et que j'ai dû convaincre les gens que les libellés étaient supérieurs aux dossiers. Certaines personnes ne pouvaient tout simplement pas le traiter et continuent de balancer leurs comptes de messagerie AOL / FAI. Je pense que MS devrait prendre position ici en disant "nous pensons simplement que c'est une meilleure façon de faire les choses".
  • Si je suggérais quelque chose, ce serait une explication directe de la raison pour laquelle les onglets ne sont pas là, ainsi que des exemples de navigation dans l'éditeur sans eux.

Eh bien, il y a un compromis: rendre les onglets visibles ou non dans Préférences / Options.

Je ne pense pas que cela prenne du temps pour d'autres améliorations car je suis sûr qu'ils ont plus d'un programmeur sur ce développement. J'adore aussi être un commando clavier. S'ils ont été implémentés, ne les utilisez pas, mais pourquoi empêcher ceux qui préfèrent les onglets dans leur flux de travail de les avoir.

Quoi qu'il en soit, pas de problème. Je suis retourné à Atom en attendant que VSC décide de ce qu'il va faire. Je trouve les onglets essentiels pour le flux de travail dans un grand projet, en plus de pouvoir ouvrir plus d'un dossier de projet.

Je me suis forcé à devenir davantage un commando clavier et ne pas avoir d'onglets a été utile. Donc, je discute du point de vue c'est-pour-votre-bien même si je n'y suis même pas encore moi-même.

Comme je l'ai suggéré plus tôt dans ce fil , c'est le comportement manquant qui est tout aussi important, sinon plus, que le composant visuel. Je suis tout à fait favorable à l'utilisation de raccourcis clavier comme ctrl + [shift +] tab ou même ctrl + P pour naviguer vers les fichiers (y compris les fichiers ouverts), mais le comportement de Working Files et la façon dont il gère les fenêtres de l'éditeur (et le fait qu'il ctrl + tabs dans l'ordre MRU) Je trouve terriblement discordant.

Tiens le téléphone! J'ai la réponse! C'est parfait! Prêt? Nous n'avons pas besoin d'onglets. Étendons simplement les fichiers de travail avec une option simple pour les afficher dans des onglets horizontalement en haut de l'éditeur! Woo hoo! Problème résolu sans créer d'onglets!

Je préfère en fait la façon dont il est maintenant - des panneaux pour les fichiers ouverts et un sélecteur de fichiers de type liste avec des "fichiers de travail" sur le côté. À l'époque où j'utilisais Atom, je détestais que chaque fois que je regardais rapidement un fichier, il ouvrait un nouvel onglet, et en quelques minutes, ma barre d'onglets était pleine d'onglets inutiles.

Donc je suis -1 sur ce point. Mais j'aimerais quand même voir le détachement des fenêtres.

Je viens de passer à VSCode d'Atom et j'ai remarqué à quel point il est incroyablement organisé et propre après avoir travaillé avec lui pendant un certain temps. La raison? Pas de surpopulation d'onglets! Le manque réel d'onglets est ce qui rend cette expérience si fluide

ce. 100% d'accord.

Je préfère en fait la façon dont il est maintenant - des panneaux pour les fichiers ouverts et un sélecteur de fichiers de type liste avec des "fichiers de travail" sur le côté. À l'époque où j'utilisais Atom, je détestais que chaque fois que je regardais rapidement un fichier, il ouvrait un nouvel onglet, et en quelques minutes, ma barre d'onglets était pleine d'onglets inutiles.

Je comprends cela et c'est pourquoi nous demandons une fonctionnalité supplémentaire et non un remplacement pour les fichiers de travail. Je ne peux pas pour la vie de moi comprendre pourquoi les deux n'ont pas pu être inclus dans l'éditeur. Je veux dire sérieusement. Regardez combien d'onglets veulent dans ce fil! Ce n'est pas un scénario _Hey, j'aimerais que les boutons soient bleus_. Il s'agit d'une entrave à la productivité pour la grande majorité des personnes souhaitant des onglets dans cet éditeur de texte (qui est d'ailleurs en passe d'être supérieur à Atom et Sublime). J'obtiens les arguments valides des deux côtés.Je ne comprends tout simplement pas pourquoi les onglets et les fichiers de travail ne peuvent pas être inclus avec des options à désactiver. Tout le monde y gagne alors.

@ jayrosen1576 Peut-être que le problème est que personne n'a vraiment fait de proposition approfondie sur ce à quoi cela devrait ressembler

  • la barre d'onglets doit-elle être placée au-dessus de toutes les fenêtres?
  • Comment le fait de cliquer sur un onglet fonctionnerait-il lorsque plusieurs fichiers seraient ouverts côte à côte ou, dans une version ultérieure, même fractionnés horizontalement?
  • L'onglet du fichier actif serait-il toujours mis en surbrillance? Que faire si la console de débogage est focalisée?
  • Si vous activez le paramètre de l'onglet, la section des fichiers de travail sera-t-elle supprimée car elle est redondante?
  • Qu'en est-il des noms de fichiers en double dans différents dossiers?
  • Qu'en est-il du bouton de fermeture en double d'un onglet et d'un panneau?
  • La fermeture du panneau fermera-t-elle l'onglet?
  • Un onglet apparaîtra-t-il dès que vous ouvrez un fichier comme dans Atom (urgh) ou seulement lorsque vous éditez comme avec des fichiers de travail?

Ce sont toutes des questions sur lesquelles l'équipe de développement devrait passer du temps. Et aussi dur que j'essaye, je ne peux pas penser à une implémentation plus élégante que la liste des fichiers de travail et qui ne prête pas à confusion.

Voici la proposition à quoi cela devrait ressembler:

1) Télécharger Atom
2) Ouvrir Atom
3) Regardez les onglets
4) Implémenter en VSCode

@ jayrosen1576 sérieusement? J'ai nommé quelques problèmes valables avec l'implémentation d'Atom et aussi des problèmes qu'Atom n'a tout simplement pas parce qu'il n'a pas de concept de fichiers de travail.

Là encore, votre photo de profil dit tout.

  • la barre d'onglets doit-elle être placée au-dessus de toutes les fenêtres?
    R: Oui. Essayez les onglets dans Atom
  • Comment le fait de cliquer sur un onglet fonctionnerait-il lorsque plusieurs fichiers seraient ouverts côte à côte ou, dans une version ultérieure, même fractionnés horizontalement?
    R: Des onglets apparaissent en haut de chaque volet. Essayez les onglets dans Atom.
  • L'onglet du fichier actif serait-il toujours mis en surbrillance?
    R: Oui. Essayez les onglets dans Atom.
  • Que faire si la console de débogage est focalisée?
    R: Même résultat que lorsque la console de débogage est désormais focalisée avec deux fichiers ouverts côte à côte.
  • Si vous activez le paramètre de l'onglet, la section des fichiers de travail sera-t-elle supprimée car elle est redondante?
    R: Seulement si vous désactivez les fichiers de travail (en option)
  • Qu'en est-il des noms de fichiers en double dans différents dossiers?
    R: L' onglet comprend un chemin partiel. Essayez les onglets dans Atom.
  • Qu'en est-il du bouton de fermeture en double d'un onglet et d'un panneau?
    R: Le panneau n'a pas de bouton de fermeture. Essayez les onglets dans Atom.
  • La fermeture du panneau fermera-t-elle l'onglet?
    R: Oui. Essayez les onglets dans Atom.
  • Un onglet apparaîtra-t-il dès que vous ouvrez un fichier comme dans Atom (urgh) ou seulement lorsque vous éditez comme avec des fichiers de travail?
    R: Seulement si vous activez l'option pour le faire (usePreviewTabs = false dans Atom le désactive). Sinon, un double-clic les ouvre dans un onglet. Essayez les onglets dans Atom.

@felixfbecker Étant

Cela en dit long sur votre personnage lorsque vous évoquez quelque chose d'aussi pudique qu'une photo de profil en réponse à une réponse valide à vos préoccupations.

Tiens le téléphone! J'ai la réponse! C'est parfait! Prêt? Nous n'avons pas besoin d'onglets. Étendons simplement les fichiers de travail avec une option simple pour les afficher dans des onglets horizontalement en haut de l'éditeur! Woo hoo! Problème résolu sans créer d'onglets!

@ jayrosen1576 Cela ne résout pas vraiment le problème, car comme je l'ai déjà dit (et évoqué à nouveau littéralement dans le commentaire précédant le vôtre), ce n'est pas seulement l'apparence visuelle des onglets qui est différente - c'est le comportement. Comme je l'ai dit dans mon premier commentaire ici, vous pouvez obtenir des "onglets dans la barre latérale" à la place dans Sublime Text aussi, mais ce n'est toujours pas la même chose que les fichiers de travail. (OMI c'est mieux.)

@kfranqueiro Je suis totalement d'accord. J'étais juste sarcastique. Cet onglet est un argument vraiment idiot. Si VSCode avait simplement la capacité d'onglets des onglets d'Atom avec l'option de les masquer (même par défaut), ce serait parfait. Je pense que nous demandons tous la même chose. Je ne peux tout simplement pas comprendre pourquoi les deux ne peuvent pas être inclus avec une option pour désactiver l'un ou l'autre.

Honnêtement, discuter si les onglets sont un bon choix pour un éditeur de texte est tout simplement stupide. Ce n'est pas un nouveau concept. Mettez-les simplement en œuvre et laissez-les facultatifs. Faites-en une extension et laissez-le être le non. 1 extension de loin jusqu'à ce que les gens se rendent compte qu'il s'agit d'une fonctionnalité de base et que cela n'a aucun sens de ne pas l'avoir, tout comme le choix du menu VS majuscule.

@nvivo Je

tout comme le choix de menu en majuscules VS.

@nvivo Avez-vous essayé cette extension? Aucune option de menu mais vous pouvez configurer certains raccourcis clavier. fonctionne plutôt bien.

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

Si vous n'aimez pas cette discussion, passez à autre chose. La lecture de ce fil est complètement facultative!

Bien sûr, sa lecture est facultative, mais son existence même semble soutenir l'idée que l'ajout d'onglets dans VS Code est facultatif et que nous devrions en débattre. Un simple sondage avec la question suivante.

Continuerez-vous à utiliser VS Code si les onglets ne sont pas ajoutés bientôt? Oui Non

Cela montrerait que Microsoft perdrait une grande partie de sa base d'utilisateurs potentiels s'il ne l'ajoutait pas. Ce qui signifie que d'un point de vue commercial, même s'ils n'ont pas besoin de la fonctionnalité eux-mêmes, ce serait un suicide commercial pour eux de ne pas le faire. Ergo, cette conversation est distrayante et inutile.

Cela dit, nous parlons de la même entreprise qui n'a toujours pas mis d'extensions dans son navigateur. Donc je suppose que tout est possible.

En toute sincérité, la seule conversation devrait maintenant porter sur la meilleure façon d'implémenter les onglets. Il n'y a plus de point d'interrogation pour savoir si les gens veulent la fonctionnalité, alors passons la conversation à quelque chose de plus constructif.

Extensions de navigateur? Actif ... NVM.

Honnêteté, je ne vois aucune raison pour les onglets. L'amour pour les onglets est tout simplement trop fort. En termes de travail réel, les raccourcis font tout ce qui est nécessaire, avec une recherche par regex, plus de métadonnées et un processus de travail bien meilleur. Ils fournissent un besoin ésotérique de base pour, je ne sais pas, quelque chose de familier. J'ai l'impression que c'est juste une poussée pour voir si les ms vont servir la communauté, pour voir si elles changent vraiment. Bien que pas aussi inutile que tout le texte en majuscules dans vs issue.

En termes de ce qui a été dit plus tôt.

"Je ne pense pas que d'autres améliorations prennent du temps"

Personnellement, je pense que c'est le cas, comme par exemple la création de la capacité d'extensibilité sur la fenêtre de l'éditeur de texte, afin que des extensions puissent être faites pour quiconque souhaite des onglets. Je suis presque sûr que l'idée même de vscode est de le garder aussi minimal et léger que possible, l'utilisateur final ajoutant ou étendant des extensions.

@ 4tron , bien sûr, il y a conspiration de la communauté perverse pour tester microsoft ici! N'y en a-t-il pas toujours un?

Si les onglets avaient un sens, nous verrions d'autres éditeurs les utiliser. Et si c'était un très bon moyen d'organiser plusieurs contenus ouverts, peut-être que d'autres types de logiciels qui ont ce besoin d'organiser plusieurs contenus ouverts, comme par exemple les navigateurs, les utiliseraient également. Mais bien sûr, ils ne le font pas, car ils n'ont aucun sens! Pouvez-vous imaginer quelque chose que les gens utilisent tout le temps comme un navigateur utilisant des onglets? Absurdité!

Je dis: jouons prudemment. Attendons d'abord et voyons si un autre bon éditeur prend en charge cette nouvelle fonctionnalité afin de ne pas perdre de temps et d'efforts sur quelque chose qui ne fonctionne pas réellement. Vérifions Visual Studio, Intellij, Eclipse, Atom, Sublime, Monodevelop, Notepad ++ ou tout autre qui a une base d'utilisateurs considérable. Une fois qu'au moins certains de ces éditeurs prennent en charge cette fonctionnalité pendant quelques années sans la remplacer par autre chose, alors il y aura une indication que c'est une fonctionnalité utile.

Mais n'allons pas trop vite. Nous devons avoir quelque chose comme un suivi des problèmes où les gens peuvent exprimer ce désir directement et peut-être laisser d'autres personnes voter, afin que nous puissions vraiment nous assurer que nous ne faisons pas cela pour rien! Nous ne pouvons agir que si cela devient l'une des fonctionnalités les plus demandées du référentiel. Ensuite, nous saurons que ce n'est pas seulement une tendance, mais que les gens l'ont trouvé utile pour leur travail quotidien et veulent cette fonctionnalité ici aussi.

Mais jusqu'à ce jour, attendons patiemment. Les éditeurs de texte sont une nouveauté et personne ne sait vraiment quel type de fonctionnalités est nécessaire.

Ghehehe, hilarant!

Op za 12 mrt. 2016 à 11:57 schreef Natan Vivo [email protected]

@ 4tron https://github.com/4tron , bien sûr, il y a conspiration de la
communauté maléfique pour tester Microsoft ici! N'y en a-t-il pas toujours un?

Si les onglets avaient un sens, nous verrions d'autres éditeurs les utiliser. Et si ça
était un très bon moyen d'organiser plusieurs contenus ouverts, peut-être d'autres types
des logiciels qui ont ce besoin d'organiser plusieurs contenus ouverts, comme
disons que les navigateurs, par exemple, les utiliseraient aussi. Mais bien sûr qu'ils ne le font pas,
parce qu'ils n'ont pas de sens! Pouvez-vous imaginer quelque chose que les gens utilisent
temps comme un navigateur utilisant des onglets? Absurdité!

Je dis: jouons prudemment. Attendons d'abord et voyons si un autre bon éditeur
prend en charge cette nouvelle fonctionnalité afin de ne pas perdre de temps et d'efforts sur quelque chose
cela ne fonctionne pas réellement. Vérifions Visual Studio, Intellij, Eclipse,
atome, sublime, monodevelop, notepad ++ ou tout autre qui a un
base d'utilisateurs considérable. Une fois au moins _ certains_ de ces éditeurs prennent en charge
cette fonctionnalité pendant quelques années sans la remplacer par autre chose,
alors il y aura une indication que c'est une fonction utile.

Mais n'allons pas trop vite. Nous devons avoir quelque chose comme un
problème tracker où les gens peuvent exprimer ce désir directement et peut-être laisser
d'autres votent, donc nous pouvons vraiment nous assurer que nous ne le faisons pas pour
rien! Nous ne pouvons agir que si cela devient l'un des plus demandés
fonctionnalités dans le référentiel. Alors on saura que ce n'est pas seulement une tendance,
mais les gens l'ont trouvé utile pour leur travail quotidien et veulent cette fonctionnalité ici
aussi.

Mais jusqu'à ce jour, attendons patiemment. Les éditeurs de texte sont une toute nouvelle chose
et personne ne sait vraiment quel type de fonctionnalités sont nécessaires.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795.

@nvivo Comparez -vous vraiment un navigateur à un éditeur de texte en ce moment? Je comprends votre utilisation excessive du sarcasme ici, et c'est génial. Le point que j'essaie de faire n'est pas de savoir si les onglets sont utiles ou non. J'aime l'idée d'un éditeur léger / minimal. Ce n'est que mon avis, j'aime l'idée que l'éditeur soit extensible pour l'utilisateur en fonction de ses préférences utilisateur. C'est ce sur quoi je veux que vscode travaille. Ensuite, nous pouvons déplacer cette discussion sur "Pourquoi aucun développeur n'a encore créé d'extension pour cela ... oh peut-être que je devrais le faire parce que j'aime les onglets et que je voudrais cela, et vscode peut le faire alors oui, maintenant j'ai un éditeur de texte qui est similaire à mon navigateur "

@ 4tron Il m'a semblé qu'il comparait également des éditeurs de texte à des éditeurs de texte.
Je pense qu'ils font un excellent travail pour rendre le vscode extensible, mais je suis fermement dans le camp qui considère que les onglets devraient être une fonctionnalité prête à l'emploi. Cette notion "Oh, vous aimez les onglets comme tous les autres logiciels que vous utilisez? Recherchez le problème sur Google, trouvez des recommandations expliquant comment installer l'extension appropriée fournie par l'utilisateur, et vous êtes prêt à partir!" ne vole pas. J'imagine que la plupart des utilisateurs s'attendent simplement à ce que les onglets existent, et je doute fortement qu'il y ait beaucoup de gens qui penseraient que vous trouverez une barre d'onglets en installant une extension. Je suis presque sûr que cela n'a jamais été précédé par aucun autre logiciel. Pourquoi les gens penseraient-ils à faire cela?

@TurkeyMan
Sa rhétorique a commencé par une comparaison avec les navigateurs.

Nous parlons de développeurs ici. Je pense qu'ils auraient l'initiative s'ils voulaient des onglets. Je suis désolé d'être contre cette idée, mais je ne vois aucun onglet de raison valable, je alt + q en vs tout le temps.Je ne vois tout simplement aucune valeur ajoutée. c'est mon opinion personnelle, et peut-être que je suis un développeur de merde pour ne pas comprendre à quel point les onglets sont censés être utiles. Je pense que cette conversation est verbeuse et personnellement j'aimerais voir vscode être ouvert comme un shell isolé pour une personnalisation presque complète et même des modèles basés sur les affaires, c'est-à-dire. où quelqu'un pourrait améliorer la personnalisation à un degré ciblé pour, par exemple, le développement drupal ou le développement wordpress où les éditeurs construisent est basé sur l'écosystème de la base de code des utilisateurs. Cela aussi me semble être un meilleur problème à résoudre.

L'inconvénient de tout ce qui est une extension est que vous vous retrouvez avec d'étranges interactions indésirables entre eux. Dans vs code, l'utilisation de GitHistory en plus de Smart File Reopener provoque des problèmes de fermeture de fichiers étranges.

Quelque chose d'aussi basique que les onglets devrait être prêt à l'emploi. Maintenant, comme d'autres l'ont demandé dans ce fil, l'ouverture de groupes ou la création de relations entre les onglets est l'endroit où les extensions devraient entrer dans la discussion.

@ 4tron , c'était drôle, mais je suis tout à fait sérieux sur ce point.

Les services de compilation externes sont quelque chose que vous pouvez décider ou non de prendre en charge dans un éditeur de texte. Les coureurs de tâches intégrés sont une fonctionnalité intéressante.

Les onglets ne font pas partie de cette classe. Les onglets sont comme des fenêtres, des boutons et des fichiers d'ouverture et d'enregistrement. Il n'y a pas de décision à prendre ici, il suffit de les avoir là-bas et de passer à autre chose, les gens s'y attendent. Ce n'est pas une chose personnalisée avancée que peu de gens veulent être prise en charge par des plugins, c'est une interface utilisateur standard dans _tout OS partout_. Les gens y sont habitués, et il y a une raison pour laquelle tous les autres éditeurs possibles n'ont pas besoin d'une pétition pour les ajouter.

Et c'est pourquoi discuter si les onglets sont bons ou non est stupide. VS Code n'est pas une expérience UX, c'est une tentative d'avoir un bon éditeur .NET pour toutes les plateformes. Rendez cette fichue chose utile à 90% des gens et vous réussirez.

Je comprends honnêtement votre point de vue sur les alternatives, mais il vous suffit de comprendre que vous êtes une très petite minorité. Croire que la plupart des gens qui le demandent ne sont que des trolls qui veulent tester Microsoft est tout simplement illusoire.

Le fait que ce soit un appel pour voir si ms changerait sa position sur les onglets était sans enthousiasme, principalement à cause de la passion pour les onglets à inclure. Au point que quelqu'un n'essaierait même pas l'éditeur car il n'y avait pas d'onglets. J'ai du mal à comprendre cela. N'oublions pas qu'il est toujours en version bêta. J'espère donc qu'ils ajouteront des onglets (en option, s'il vous plaît).

@ 4tron Je l'ai essayé plusieurs fois et je n'utilise pas régulièrement vscode car il ne semble pas bien s'adapter aux grands projets, et les onglets manquants sont l'une des principales raisons pratiques qui me semblent être vraies.
Je l'utilise principalement comme un éditeur de texte léger lorsque j'édite un petit nombre de fichiers, mais dès que je veux travailler sur l'un de nos grands projets, vscode ne fonctionne tout simplement pas. Les onglets manquants et le fait qu'il n'y ait pas de notion de sous-projets (ou de «solutions» comme le dit VS) sont les seuls bloqueurs dont je suis actuellement au courant.

Je veux juste commenter cette idée d'ajouter tout avec des plugins. C'est un bel objectif; avoir un bon cadre d'extension est important, mais je pense qu'ils doivent être prudents et ne pas trop s'engager dans cette idée.
J'utilise VS, et même si cela me rend dingue, je trouve que j'y suis attaché car il a un très haut niveau de qualité de produit, ce que j'attends d'un produit MS. J'ai essayé toutes les alternatives OSS (et d'autres outils propriétaires), et elles semblent toutes ne pas répondre aux besoins de base de l'utilisabilité (en particulier en ce qui concerne l'expérience de débogage).
J'espère vraiment que l'intention de vscode n'est pas d'être une coquille légère dans laquelle tout le monde pirate des fonctionnalités au hasard via des extensions ... il existe déjà de nombreux autres outils qui correspondent à cette description, je n'en trouve pas encore un qui soit convaincant. Ce que je veux de vscode, c'est ce que j'ai toujours souhaité de VS; être bien conçu du point de vue de la convivialité par des designers UX professionnels et être CROSS PLATFORM.

Je pense que ceux qui sont contre les onglets peuvent manquer le point. Je (nous) ne voulons pas d'une solution tout ou rien. Tout ce que nous demandons, c'est une option simple pour activer les onglets (ils peuvent être masqués par défaut) qui ressemblent et se comportent comme ceux du célèbre éditeur Atom. Si vous ne les aimez pas, vous ne saurez même jamais qu'ils existent. Si vous le faites, ils peuvent être activés. Et pour ceux qui n'ont jamais utilisé Atom et l'expérience multi-volets + onglets, je vous suggère de l'essayer avant d'écarter complètement l'argument pour eux. Vous ne pouvez pas les aimer, mais vous devez admettre qu'ils sont utiles pour beaucoup d'entre nous. Sinon pour l'excellente capacité de débogage node.js de VS Code, j'utiliserais Atom exclusivement. Les fichiers de travail ne me dérangent pas. Je pense qu'ils peuvent être utiles, cependant, ils ne remplacent pas bien les onglets et ils ne sont pas vraiment une autre façon de faire la même chose. C'est comme si vous disiez _Vous avez une Honda Civic, pourquoi voulez-vous une camionnette? _ Eh bien, essayez de charger 1 200 lb de parquet à rainures et languettes en bambou à l'arrière de votre Civic et vous verrez pourquoi. Les deux sont des véhicules mais servent des objectifs différents.

Comme je l'ai déjà dit, supprimez les onglets de Visual Studio, Edge ou de tout autre produit Microsoft pour une version et voyez la réaction. Ce ne sera pas joli. Nous _pouvons_ tous avoir les deux. Nous demandons que les onglets soient un _optionnel_ et non un composant d'édition obligatoire. Peut-on mieux consacrer du temps au développement d'autres éditeurs? Sûr. Les corrections de bogues critiques et les améliorations qui bloquent l'utilisation de l'éditeur doivent toujours venir en premier. Cependant, je suis sûr qu'il y a eu un tas de fonctionnalités ajoutées qui ne s'élèvent pas au niveau d'une amélioration ou d'un correctif critique. Donc, si du temps est consacré à ceux-ci, il devrait y avoir du temps réservé pour une fonctionnalité que la grande majorité de ce fil demande.

Nous adorons ce que VSCode est devenu ces derniers mois et nous sommes engagés dans ce sujet parce que nous voulons que ce soit le meilleur éditeur disponible. Il n'y a pas de place pour la négativité ici. Nous sommes tous passionnés par ce que nous voulons / ne voulons pas en tant que développeurs. Personne n'a une mauvaise opinion, mais les opinions opposées doivent être honorées en tant que telles et pas simplement écartées parce que vous estimez qu'elles sont invalides.

Je ne pense pas qu'il y ait beaucoup de "passion pour les onglets". Ce qui se passe, c'est qu'après que @bpasero ait déclaré " Je ne pense pas que les onglets soient un bon moyen d'afficher la liste des fichiers ouverts " et " Jusqu'à présent, je n'ai pas encore entendu de bonne raison pour les onglets ", les gens se feront entendre plus en essayant de justifier la demande au commetteur principal du projet.

Je suis amusement frustré de voir toute cette discussion, et je suis un peu offensé parce que j'utilise quotidiennement VS Code dans mon travail et je veux avoir un bon éditeur .NET sur mac et linux, et les onglets me manquent beaucoup, et je n'ai pas eu ce moment "_wow! c'est en fait plus utile_", mais la réponse ici semble être "_vous n'aviez simplement pas réalisé que nous avons créé quelque chose d'extraordinaire! laissez-lui le temps et habituez-vous! _".

Voici quelques problèmes réels que je vois en utilisant VS Code quotidiennement pendant quelques mois:

  • cela n'a aucun sens pour moi de cliquer sur l'icône de fermeture dans la fenêtre mais de garder le fichier dans cette liste - je dois constamment nettoyer cette liste manuellement pour avoir une liste où je ne vois que les fichiers avec lesquels je suis en train de me réveiller - et les fichiers Je travaille avec ce ne sont pas les derniers que j'ouvre ou ceux que je change, ce sont ceux que je veux garder ouverts en même temps
  • cela n'a aucun sens pour moi de fermer un fichier non enregistré et de l'avoir sur cette liste avec un marqueur - plusieurs fois par jour, je fais quelque chose, et le changement n'est pas reflété dans l'application car j'ai fermé le fichier et le code VS n'a pas demandé moi pour le sauver, ce qui me fait perdre du temps
  • un clic ouvre le fichier, mais seulement double-cliquez pour placer le fichier dans la section récemment utilisée - donc, j'ouvre constamment des fichiers qui n'y apparaissent pas - et ma mémoire musculaire trouve plus facile d'ajouter ou de supprimer un espace dans le fichier puis faites défiler jusqu'au fichier que je regarde à nouveau et double-cliquez dessus
  • Je trouve ennuyeux que vous ne puissiez pas voir la barre de défilement une fois que la liste est remplie à moins que vous ne la survoliez. Maintenant, c'est compliqué car c'est ainsi que fonctionne l'interface utilisateur dans l'éditeur. Mais voyez, je connais le projet et je sais qu'il doit y avoir plus de fichiers dans la vue des dossiers. Je connais aussi la structure du code, donc je sais qu'il doit y avoir quelque chose de plus dans le volet de l'éditeur. Mais avec la liste récente, je n'en ai aucune idée. «Est-il plein ou ai-je oublié d'ouvrir ce fichier? N'ai-je pas ouvert ce fichier il y a 1 minute? Permettez-moi de l'ouvrir à nouveau ...

Maintenant, je vois que la plupart de ces problèmes seraient résolus avec un argument comme "_oh, mais vous manquez le point, c'est une liste de fichiers récemment utilisés, pas une liste de fichiers ouverts. Vous la comparez à des onglets, et il y a mieux façons de gérer les fichiers ouverts. Après un certain temps, vous commencez à ..._ "

Ce à quoi je répondrais volontiers: "_Cette chose n'a aucun sens pour moi et me rend en fait improductive. Il existe déjà une solution qui fonctionne partout depuis des décennies. Je ne veux pas réparer quelque chose qui n'a jamais été problème, et honnêtement, je ne vois pas cette nouvelle solution comme une meilleure alternative. Pouvons-nous simplement avoir quelque chose de familier qui fonctionne et auquel nous sommes tous habitués? Merci_ "

Je sais que tout cela semble arrogant. Mais je parie que c'est ce que la plupart des gens pensent, mais ils sont soit trop timides, soit trop polis pour le dire.

Les interfaces utilisateur expérimentales sont d'excellentes alternatives et je suis tout à fait d'accord pour avoir la possibilité de basculer entre les deux. Mais il s'agit actuellement d'une expérience forcée qui empêche l'autre option, qui est la plus courante et attendue. Et tout comme le menu Démarrer de Windows 8, cela ne se termine pas correctement.

Ce à quoi je répondrais volontiers: "Tout cela n'a aucun sens pour moi et me rend en fait improductif. Il existe déjà une solution qui fonctionne partout depuis des décennies. Je ne veux pas réparer quelque chose qui n'a jamais été problème, et honnêtement je ne vois pas cette nouvelle solution comme une meilleure alternative. Pouvons-nous simplement avoir quelque chose de familier qui fonctionne et auquel nous sommes tous habitués? Merci "
...
Et tout comme le menu Démarrer de Windows 8, cela ne se termine pas correctement.

Je ne pourrais pas être plus d'accord.

Comme le pliage de code était autrefois la fonctionnalité la plus votée, les onglets le sont maintenant . L'équipe vscode nous a donné le pliage.

Je serai surpris et déçu si les onglets ne se concrétisent jamais compte tenu de l'excellent bilan de l'inclusion par l'équipe vscode des principales demandes des utilisateurs à la lumière de la participation rafraîchissante de Microsoft à la communauté open source.

@ianwesterfield Exactement, c'est la fonctionnalité la plus demandée avec des milliers de votes. Ça va arriver. Cette conversation est inutile et doit passer à "Comment exactement les onglets devraient-ils fonctionner?"

J'ai déjà commenté l'existence d'une implémentation presque parfaite des onglets: Atom. Ils sont faciles à organiser, ont un affichage correct des chemins de fichiers partiels si deux onglets ont le même nom de fichier et fonctionnent extrêmement bien dans une fenêtre avec plusieurs volets horizontaux et / ou verticaux (ce qui, je pense, est une autre fonctionnalité nécessaire de VSCode). Si VSCode avait les mêmes fonctionnalités d'onglet que Atom, je pense que cela couvrirait 99% de ce que tout le monde demande. Et comme Atom est également basé sur les électrons, la mise en œuvre peut également fonctionner aussi bien dans VSCode. Je ne suis pas pour une solution de copie-cat de quoi que ce soit, mais ils (Atom) ont fait un excellent travail d'implémentation des onglets et ce qu'ils ont est une excellente solution à cet égard.

@ jon64digital C'est

Améliorer la gestion des documents, le comportement d'empilement des éditeurs

Cela donne l'impression que nous devons encore justifier à plusieurs reprises l'existence des onglets, sans parler de leur comportement. À tout le moins, je suppose, cette référence est l'une des trois références à Eliminate Adoption Roadblockers , mais c'est maintenant le 12 mars ...

Dans cet esprit, je pense que s'ils devaient au moins l'attribuer à quelqu'un, nous pourrions nous reposer tranquillement dans ce que

EDIT Peut-être que ce manque d'engagement de la part de l'équipe VS Code est un malentendu - après tout, le plan d'itération de mars n'a pas été mis à jour depuis le 7 janvier.

@ jayrosen1576 Je suis d'accord - et je pense que le 1% des demandes des utilisateurs qui ne seraient pas couvertes pourrait alors être traité par des extensions (par exemple l'ouverture de fichiers avec des relations dans des groupes d'onglets, etc.).

@ jayrosen1576 Atom vous permet-il de lier des fichiers afin de pouvoir avoir une vue fractionnée qui (par exemple) ouvre toolbar.html dans le premier cadre, toolbar.js dans le second et toolbar.css dans le troisième?

Ce n'est qu'un exemple, mais ce serait absolument idéal. Quelqu'un ci-dessus a dit que Vim pouvait le faire, mais j'ai vérifié vim et je n'y étais pas intéressé pour un certain nombre de raisons, mais le truc de l'onglet semble superbe.

@ jon64digital Atom ne le fait pas par défaut, et je ne connais aucune extension à ce jour (même les extensions inspirées de vim), mais c'est le cas d'utilisation d'extension auquel je faisais référence dans mon dernier message.

EDIT se référer au commentaire de @jtosey ci-dessus (environ 9 jours avant ce post).

Personnellement, je pouvais voir que c'était une gêne. La moitié du temps, je ne me soucie pas de la vue - juste le contrôleur, le modèle et le JS côté client. Je finirais probablement par devenir fou si la vue s'ouvrait à chaque fois que j'ouvrais le JS.

Mais là encore, c'est la beauté d'une extension - si je ne l'aime pas, je peux la désactiver.

Lorsque nous travaillons sur des demandes de fonctionnalités comme celle-ci qui ont un impact très fort sur l'UX, nous passons généralement un certain temps dans les réunions UX pour discuter de la façon dont la mise en œuvre réelle devrait ressembler. Nous avions une gestion améliorée des documents à notre ordre du jour depuis un certain temps, mais d'autres éléments de notre liste GA avaient tout simplement une priorité plus élevée (accessibilité par exemple).

Nous choisirons cet élément après la sortie de notre version GA à la fin du mois et commencerons la discussion sur la manière dont la gestion des documents devrait fonctionner à l'avenir. Nous voyons quelques défauts dans la façon dont les choses fonctionnent actuellement et nous savons que nous devons l'améliorer. Nous pensons que même sans onglets, il y a des choses qui ne sont tout simplement pas très intuitives dans la façon dont l'UX se comporte aujourd'hui (Fermer l'éditeur vs Fermer le fichier, le fait que les éditeurs secondaires se comportent différemment des autres éditeurs, les fichiers de travail et ouvert, etc.).

Bien que le concept d'onglets soit bien compris, nous ne pensons pas que nous pourrions simplement ajouter des onglets en plus de notre gestion documentaire existante sans y revenir sur nos concepts.

Je pense que nous aurons pas mal de discussions sur la manière dont la gestion des documents devrait fonctionner à l'avenir et je pense que nous sommes prêts à revoir les concepts comme nous le jugeons nécessaire.

@bpasero après avoir examiné le code pour un autre problème, je ne comprends pas pourquoi il n'est pas possible d'ajouter simplement des onglets ou quels concepts vous auriez à changer en le faisant. Cela pourrait aller très loin si vous pouviez nous éclairer, ou est-ce une référence à la ligne de pensée dans vos messages originaux?

@bpasero C'était bien si vous développiez davantage sur ce qui est discuté et quelles sont certaines des approches que vous voyez comme des solutions possibles aux problèmes que nous avons publiés.

PS Je ne sais pas si c'est possible avec VSCode mais certaines équipes comme Roslyn, TypeScript et quelques autres partagent leurs notes de conception, cela donne beaucoup de contexte à leur fonctionnement et à ce qui va suivre, cela ouvre également la communauté à de nouvelles discussions, est-ce que quelque chose comme ça est possible?

@bpasero voudrait que l'équipe envisage sérieusement les tentatives de la communauté d'ajouter des onglets. Cela ne me dérange pas d'essayer, mais je ne pense pas que quiconque veuille perdre son temps si un effort était bloqué

Je pense que votre équipe est en phase de vaporisation après avoir fait de cette taupinière dans la montagne.

Signification: Les onglets sont constitutifs, et non synonymes, du concept plus large de gestion de documents. Il existe déjà d'autres problèmes liés à d'autres domaines de la gestion de documents de vscode.

Nous discutons déjà de nos idées UX via des problèmes à l'air libre (voir https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux), je suppose que nous ferions de même pour la gestion des documents et les onglets.

Je pense également que nous ne voudrions pas que ces améliorations soient apportées via des extensions, mais plutôt les avoir comme concept de base dans l'atelier VS Code.

Une fois que nous avons commencé la discussion UX dans l'équipe, nous aimerions également impliquer la communauté et nous discuterions également des défauts que nous voyons dans notre conception actuelle et de ce que nous prévoyons d'améliorer.

@bpasero merci beaucoup, c'est tout ce que je voulais savoir. :)

@bpasero Génial. Je sais que vous investissez énormément dans le produit et nous l'apprécions tous vraiment. Je pense que beaucoup d'entre nous ressentent une certaine frustration face au manque d'onglets dans l'interface utilisateur, car nous comptons beaucoup sur eux et changer complètement notre façon de travailler n'est pas vraiment une option. Nous voulons que ce soit le meilleur éditeur sur le marché et c'est vraiment près d'y parvenir.

Sans lire tout ce fil, je donne un gros: +1: à ce sujet.

J'utilise Sublime depuis des années et j'adore les onglets. Je vois que les fichiers de travail comblent une partie du vide, mais pas complètement. Je ne peux pas expliquer complètement pourquoi, mais veuillez me donner mes onglets!

+1

Extrêmement nécessaire.

+1

Je travaille sur de nombreux types de fichiers différents pendant le développement, donc j'aime souvent créer un groupe d'onglets sur le côté droit pour un type de fichier et un autre groupe d'onglets sur la gauche pour les autres types de fichiers. Par exemple, lorsque je travaille sur du code rapporteur / webdriverjs, j'aime garder tous les "objets de page" à droite et toutes les "spécifications" à gauche, groupées séparément et logiquement. De même lorsque je travaille sur des éléments frontaux, je vais garder un groupe d'onglets à droite pour tous les fichiers js / ts et un autre à gauche pour html et css.

Ce ne sont que deux exemples, mais je le fais TOUT le temps sur presque tous les projets dans une certaine mesure et cette stratégie m'a bien servi pendant de nombreuses années de développement et je la trouve extrêmement utile.

Bien que Code me permette certainement d'avoir plusieurs volets, l'approche de la liste de fichiers globale rend plus difficile la distinction entre les types de fichiers et je me retrouve donc à perdre beaucoup de temps à parcourir la liste du fichier que je voulais afficher. De plus, lorsque j'essaie (instinctivement) de fermer un seul fichier dans le volet droit, le volet entier disparaît, ce qui est extrêmement frustrant, en particulier après avoir utilisé des VS classiques pendant plus de 16 ans, ce qui m'a appris à m'attendre à ce que le volet reste ouvert avec le reste de les fichiers visibles.

Le manque de groupes d'onglets dans Code est extrêmement décevant et je ne pense pas que les gens devraient être forcés ou convaincus de travailler d'une certaine manière parce que «c'est mieux» ou «il n'y a pas de bonne raison pour les onglets» à votre avis. Oui il y a. Peut-être que vous ne les utilisez pas de la meilleure façon ou que vous ne pensez pas qu'ils sont utiles, mais nous sommes des tonnes à apprécier et à apprécier quelque chose d'aussi basique que les groupes d'onglets.

Je crois comprendre que le code est basé sur Atom qui prend déjà en charge les groupes d'onglets. Il semblerait qu'il aurait fallu beaucoup de travail supplémentaire pour supprimer cette fonctionnalité, ce qui n'a tout simplement pas beaucoup de sens pour moi. À tout le moins, permettez à l'utilisateur de choisir l'expérience qu'il souhaite afin de pouvoir utiliser le code de la manière qui lui convient le mieux.

Veuillez ramener les groupes d'onglets dans VS Code.

Peut-être que si vous dessinez des boîtes autour des noms de fichiers dans la liste des fichiers de travail, les gens verront que c'est fonctionnellement équivalent aux onglets de gauche ... :-)

@ChrisMiami : sauf que ce n'est pas le cas . (Je serais potentiellement prêt à vivre avec si c'était le cas.)

LOL

Le jeu 17 mars 2016 à 04 h 59 Kenneth G. Franqueiro <
[email protected]> a écrit:

@ChrisMiami https://github.com/ChrisMiami : sauf que ce n'est pas le cas
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

@kfranqueiro en attendant une solution d'onglets appropriée, vous pourriez être intéressé par l'adoption des raccourcis clavier que j'utilise qui rapprochent ctrl + w et ctrl + shift + w d'une implémentation d'onglets classiques.

@ nub340 VSCode n'est pas basé sur Atom mais Electron qui a été créé par le même groupe qui travaille sur Atom.

+1 Veuillez ajouter !!!

Je pense aussi que c'est une fonctionnalité qui manque cruellement dans un éditeur par ailleurs génial.

Veuillez ajouter des onglets en option ou autoriser le plugin tiers pour la fonctionnalité des onglets.

La première chose qui m'a frappé à propos de VSC (après le nom idiot) était à quel point c'était génial de ne pas avoir d'onglets.

J'ai actuellement 8 fichiers ouverts - les onglets sont inutiles pour moi, car les noms de fichiers ne s'afficheront pas sur les onglets.

Je _adore_ CTRL + TAB, et la liste des «fichiers de travail».

Si vous devez ajouter des onglets, veuillez les rendre facultatifs.

@leegee Ils ne sont pas "inutiles", vous n'en avez tout simplement pas besoin. Avez-vous pensé que les personnes qui travaillent sur différents types de projets pourraient avoir un cas d'utilisation différent de vous?

Donnez aux milliers de personnes qui ont voté pour les onglets, je pense que la seule chose "inutile" ici est votre commentaire :)

@ jon64digital : J'ai vu que le projet avait demandé des commentaires généraux aux utilisateurs sur la perspective des onglets - j'ai compris que nous devions exprimer nos propres opinions. Je me rends compte maintenant que j'aurais dû d'abord vous envoyer un e-mail, afin de pouvoir exprimer votre opinion et éviter votre impolie ad-hominem invective. Mes excuses.

@ jon64digital @leegee a dit qu'ils étaient inutiles _pour lui_, pas en général. Je soutiens entièrement les onglets, mais je suis d'accord qu'ils devraient être une option qui peut être désactivée pour ceux qui ne les utilisent pas. Gardons la discussion civile et ne recourons pas à des attaques personnelles. Personne n'a une opinion erronée. Ce ne sont que ça ... des opinions.

@ jayrosen1576 Il a édité son commentaire. S'il avait dit à l'origine «inutile pour moi», alors bien sûr, je n'aurais pas dit ce que j'ai fait. Je présume également que les deux autres personnes qui ont rejeté son commentaire l'ont fait avant qu'il ne l'édite.

Je suis tout à fait d'accord que tout le monde a droit à une opinion, mais il semble y avoir plusieurs personnes ici qui n'ont pas besoin d'onglets dans leur flux de travail et qui cherchent à refuser à ceux qui le veulent en mettant -1 ou en disant à MS que la fonctionnalité est n'est pas nécessaire ou détournerait en quelque sorte des ressources de fonctionnalités plus importantes. Étant donné qu'ils peuvent voir combien de personnes veulent des onglets, je trouve cela égoïste et un peu immature.

Quoi qu'il en soit, je m'excuse si quelqu'un a vu cela comme une attaque personnelle. J'ai mis un smiley après.

Si quoi que ce soit, je pense que cette discussion illustre simplement qu'il existe de nombreuses façons pour un développeur d'utiliser un IDE et qu'elles sont toutes parfaitement valables pour leur cas d'utilisation. Il n'y a pas une seule «bonne» façon et en fin de compte c'est juste un outil pour faire le travail. Certains développeurs aiment les onglets afin de pouvoir regrouper arbitrairement des fichiers similaires et d'autres trouvent qu'une seule liste MRU est parfaitement adéquate. Ensuite, vous avez ceux qui utilisent simplement le bloc-notes pour tout et nous sommes tous un tas de pensées ha-ha.

Sérieusement, je pense simplement que, puisque les onglets ont été une partie essentielle de Visual Studio depuis à peu près jamais, de nombreux développeurs se sont habitués à leur utilité et rendent donc la liste MRU unique facultative (opt-in ou out) rendrait l'outil déjà génial que VS Code est encore plus polyvalent, pour tous.

@ nub340 exactement! certains d'entre nous aiment les onglets parce qu'ils ont toujours fait partie de notre expérience en tant que développeurs / utilisateurs, personnellement, j'aime voir les fichiers sur lesquels je travaille en haut, il n'y a aucun avantage inhérent aux onglets par rapport aux fichiers de travail, mais c'est ainsi que certains nous l'aimons.

D'accord, je voudrais que ce soit une option, pas la forcer.
Le mar 22 mars 2016 à 06:22 Eyal Solnik [email protected]
a écrit:

@ nub340 https://github.com/nub340 exactement! certains d'entre nous aiment les onglets parce que
ils ont toujours fait partie de notre expérience en tant que développeurs / utilisateurs, personnellement j'aime
pour voir les fichiers sur lesquels je travaille en haut, il n'y a pas de
avantage des onglets par rapport aux fichiers de travail, mais c'est comme cela que certains d'entre nous l'aiment.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

Nous n'avions pas d'onglet sur le Vic-20 ...

Une chose qui ressort de cette discussion est que tout ce qui est (fait)
disponible, il doit être personnalisable.

@glennblock , @leegee ouais cela devrait certainement être une option, mais le fichier de travail ne devrait-il pas recevoir le même traitement pour ceux qui ne le veulent pas? cependant, il est probablement préférable d'en discuter dans une autre demande de fonctionnalité. :)

J'ai posté ce texte ici: https://github.com/Microsoft/vscode/issues/101

C'est également valable pour cette discussion. Je serais heureux de voir la réponse de @bpasero .

Je veux cette fonctionnalité. Fin de la conversation. Fuck your opinions @bpasero Je me fiche de ce que vous pensez être juste ou non. Il en va de même pour les onglets # 224. Vous essayez de nous convaincre que votre solution est meilleure. Encore une fois, baise ta solution. Nous faisons tous les choses différemment et personne ne se soucie de ce que vous pensez. J'utilise vscode juste en raison d'un excellent support de typescript et angular2. Sinon, je déteste car il manque des fonctionnalités que les éditeurs normaux ont, par exemple SublimeText, Atom, Brackets

Haha @PeterMtj , merci d'avoir dit ce que nous pensons tous :)

@bpasero semble avoir l'habitude de rejeter et de discréditer toute fonctionnalité qu'il n'utiliserait pas personnellement et ne correspond pas à son flux de travail personnel.

Les gens utilisent les logiciels Microsoft principalement parce qu'ils le doivent, rarement parce qu'ils l'aiment, et quand vous voyez que le personnel de Microsoft a des attitudes comme la sienne, cela montre simplement pourquoi ils ne peuvent pas concevoir un logiciel décent comme Sublime Text. J'ai essayé de mon mieux avec VS Code mais je suis très proche de le désinstaller.

@PeterMtj Sérieusement? c'est comme ça que tu abordes les choses? maudire les gens? si vous n'avez pas de respect pour lui, ayez du respect pour vous-même!

@ jon64digital Il peut voter contre ou dire son opinion personnelle et c'est très bien! nous n'avons pas besoin d'être personnels et certainement pas de maudire les gens pour leurs opinions!

Je ne suis pas d'accord avec sa réponse initiale aussi, dire «non» n'est pas professionnel et assez grossier à mon avis, mais je pense que la communauté peut faire mieux et rester civilisée indépendamment de l'opinion des gens.

Les gens utilisent les logiciels Microsoft principalement parce qu'ils le doivent, rarement parce qu'ils l'aiment, et quand vous voyez que le personnel de Microsoft a des attitudes comme la sienne, cela montre simplement pourquoi ils ne peuvent pas concevoir un logiciel décent comme Sublime Text. J'ai essayé de mon mieux avec VS Code mais je suis très proche de le désinstaller.

Edit: Les gens n'ont pas besoin d'utiliser les produits Microsoft! Je n'ai certainement pas à faire ça et dire que les gens le font rarement parce qu'ils aiment ça, c'est juste du trash! Microsoft fabrique d'excellents produits et de grandes technologies et je suis loin d'être fan de tout ce qu'ils font, mais ils font certainement certaines choses correctement! personne n'oblige quiconque à utiliser VSCode et si quelqu'un vous oblige à utiliser VSCode, il / elle devrait être renvoyé car vous devez choisir vos propres outils! la seule chose dont un employeur devrait se soucier, c'est votre travail et non la façon dont il est fait!

Ne transformons pas cela en une guerre des flammes et gardons-le constructif, s'il vous plaît!

@eyalsk

Je n'essayais pas de lancer une guerre des flammes ou de parler de déchets, mais je maintiens à 100% ce que j'ai dit. Les États membres ont historiquement lié leurs propres produits à leur système d'exploitation et les uns aux autres pour forcer les gens à utiliser leur logiciel parce qu'ils savent que ce n'est pas assez bon pour être autonome. Je connais beaucoup de gens qui doivent utiliser MS Office au travail, j'ai dû utiliser Visual Studio auparavant car je n'avais pas d'autre choix et je pouvais compter le nombre de personnes qui utiliseraient volontairement Internet Explorer sur les doigts d'une main. Ils ont même fait l'objet de poursuites anti-trust à cause de ces pratiques, donc dire que personne ne fait utiliser un logiciel MS est naïf.

Les choses ont récemment évolué dans la bonne direction et ils sont de plus en plus indépendants des plates-formes et tentent d'améliorer l'interopérabilité de leur logiciel avec les autres. Je suis sûr qu'il y a de bonnes personnes chez MS qui essaient de créer de bons logiciels et de donner aux gens ce qu'ils veulent, mais bpasero n'en fait clairement pas partie. Son attitude fermée d'esprit ne leur fait pas honneur et j'ai trouvé drôle que @PeterMtj l'ait appelé de cette façon. Nous sommes tous des adultes ici et personne ne devrait être offensé par un juron étrange. C'est juste un mot.

Vous avez un long fil de discussion ici avec des centaines de personnes qui disent exactement à MS ce qu'elles veulent d'un éditeur de code. Ce n'est pas comme s'ils ne savaient pas ce que nous voulons. Ensuite, nous avons un employé de la SP ici qui dit "non, vous avez tout faux". Cela ne donne-t-il pas le portrait d'une entreprise qui n'est pas exactement en phase avec son public?

Juste mon 2c.

@ jon64digital

Je n'essayais pas de lancer une guerre des flammes ou de parler de déchets, mais je maintiens à 100% ce que j'ai dit. Les États membres ont historiquement lié leurs propres produits à leur système d'exploitation et les uns aux autres pour forcer les gens à utiliser leur logiciel parce qu'ils savent que ce n'est pas assez bon pour être autonome.

Ce n'est que votre hypothèse de partialité et je respecte cela, mais nous pouvons dire exactement la même chose à propos de toute autre société dans le monde pour n'en nommer que quelques-uns Apple, Oracle et Google ...

Je connais beaucoup de gens qui doivent utiliser MS Office au travail,

Les gens ne sont pas obligés d'utiliser MS Office, c'est la décision de l'employeur, Libre office est un excellent produit et c'est une très bonne alternative.

J'ai dû utiliser Visual Studio avant car je n'avais pas d'autre choix

Je ne sais pas pourquoi vous n'aviez pas le choix mais vous avez certainement des choix aujourd'hui! J'ai toujours eu le choix même quand les gens utilisaient beaucoup Visual Studio pour le développement .NET J'utilisais SharpDevelop, Vim et Notepad ++, je n'ai jamais eu de problèmes avec plusieurs éditeurs, je ne suis pas fan des designers de toute façon ...

Pour C / ++, vous avez encore plus de support de la part des éditeurs et des IDE, sauf si vous utilisez VC ++ :)

De plus, je n'ai jamais compris pourquoi certaines personnes se bloquent sur une pile spécifique de technologies fabriquées par X, il existe de nombreuses technologies au-delà de Microsoft, par exemple.

Je pourrais compter le nombre de personnes qui utiliseraient volontairement Internet Explorer sur les doigts d'une main.

Vous avez raison, Internet Explorer était très mauvais jusqu'à la version 9 mais ils se sont beaucoup améliorés depuis et même si je suis un utilisateur de FireFox, je ne juge pas Microsoft pour son passé, je les juge pour qui ils sont le cadeau et ça a l'air bien!

Ils ont même fait l'objet de poursuites anti-trust à cause de ces pratiques, donc dire que personne ne fait utiliser un logiciel MS est naïf.

Personne ne fait utiliser quoi que ce soit et je ne sais pas pour la plupart des gens mais je suis loin d'être naïf, je suis juste raisonnable.

Si votre employeur fait le choix d'utiliser les technologies MS, alors vous êtes certainement forcé mais encore une fois ce n'est pas la faute de Microsoft, si vous avez fait le choix d'utiliser les technologies MS alors vous l'avez choisi et vous en plaindre est un peu idiot, il existe des technologies équivalentes qui sont aussi bons que ceux de Microsoft, donc les gens ont certainement le choix.

Les choses ont récemment évolué dans la bonne direction et ils sont de plus en plus indépendants des plates-formes et tentent d'améliorer l'interopérabilité de leur logiciel avec les autres. Je suis sûr qu'il y a de bonnes personnes chez MS qui essaient de créer de bons logiciels et de donner aux gens ce qu'ils veulent,

Exactement! même si je ne pense pas que donner aux gens ce qu'ils veulent soit bon du point de vue du design. :)

mais bpasero n'en fait clairement pas partie. Son attitude fermée d'esprit ne leur fait pas honneur et j'ai trouvé drôle que @PeterMtj l'ait appelé de cette façon. Nous sommes tous des adultes ici et personne ne devrait être offensé par un juron étrange. C'est juste un mot.

Je ne pense pas que nous devons définir les gens en fonction de leurs opinions, certainement pas ce genre d'opinions et être un adulte ne rend pas les gens vulnérables à des attaques personnelles de toute nature, jurer qu'une personne n'est pas agréable et devrait être découragée, agir en tant qu'adulte signifie que vous pouvez contrôler votre rage et écrire votre opinion sur quelqu'un ou quelque chose sans être offensant.

Vous avez un long fil de discussion ici avec des centaines de personnes qui disent exactement à MS ce qu'elles veulent d'un éditeur de code. Ce n'est pas comme s'ils ne savaient pas ce que nous voulons. Ensuite, nous avons un employé de la SP ici qui dit "non, vous avez tout faux". Cela ne donne-t-il pas le portrait d'une entreprise qui n'est pas exactement en phase avec son public?

C'est un bon point et une plainte, je ne dis pas le contraire! mais @bpasero a déjà déclaré qu'une fois qu'ils travailleront sur l'UX, ils s'attaqueront également à ce problème. et ce que nous prévoyons d'améliorer._ "

@eyalsk Oui, c'est exactement comme ça que

@ jon64digital a raison sur l'attitude @bpasero . Je ne sais pas quoi penser de lui. Peut-être qu'il veut juste se débarrasser du travail en disant que vous vous trompez et que ce n'est pas nécessaire. Dans les deux cas, @bpasero ne devrait probablement pas communiquer avec la communauté avec son attitude. C'est mon avis.

Essayez de réaliser que Microsoft ne nous aide pas. Nous aidons Microsoft en utilisant ses produits et en donnant des commentaires afin qu'ils puissent créer des produits décents. Cela ne devrait pas être une discussion sur la défense des onglets, mais sur la façon dont les onglets devraient fonctionner pour que cela soit dans la nature avec vscode. Vscode est pour la communauté, c'est nous et dans les cas extrêmes, si nous voulons tous un dinosaure rouge au milieu de l'écran, ils devraient le faire sans remettre en question les raisons. Nous avons tous nos propres raisons. Sinon, vscode est inutile pour la communauté. Voilà comment je le vois.

@PeterMtj Je suppose que nous devrons accepter de ne pas être d'accord. :)

Je voulais intervenir et fournir des informations supplémentaires sur ce problème. Nous sommes sur le point de conclure une étape majeure du Code. Un objectif clé pour nous au cours des 6 derniers mois a été le soutien à l'accessibilité et à la localisation. Cela ne nous a laissé aucun cycle dans la zone de l'interface utilisateur pour travailler activement sur les commentaires des onglets. Maintenant que la plupart des cases à cocher du plan de mars (# 3555) sont cochées, nous commençons lentement à chercher à nouveau. En avril, nous allons accélérer sur ce sujet. @bpasero a joué un rôle clé dans le développement de notre UX et ce sera la prochaine évolution majeure.

Merci à tous pour votre passion et vos commentaires, qui nous aident à faire de VS Code le meilleur produit possible.

TIA pour les ajouts d'accessibilité - fera une grande différence pour nous
à moitié aveugle

Le samedi 26 mars 2016, 01:38 Erich Gamma, [email protected] a écrit:

Je voulais intervenir et fournir des informations supplémentaires sur ce problème.
Nous sommes sur le point de conclure une étape majeure du Code. Un objectif clé pour nous
au cours des 6 derniers mois, il s'agissait d'un soutien pour l'accessibilité et la localisation. Ce
ne nous a laissé aucun cycle dans la zone de l'interface utilisateur pour travailler activement sur les commentaires des onglets.
Maintenant que la plupart des cases à cocher du plan de mars (# 3555
https://github.com/Microsoft/vscode/issues/3555) sont vérifiés, nous sommes
recommençant lentement à lever les yeux. En avril, nous allons accélérer sur ce sujet.
@bpasero https://github.com/bpasero a joué un rôle clé dans la
développement de notre UX et ce sera la prochaine évolution majeure.

Merci à tous pour votre passion et vos commentaires, qui nous aident à faire de VS Code le
meilleur produit possible.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

@egamma Je vous remercie vraiment vous et votre équipe pour tout, je pense que vous faites un excellent travail! mais j'ai l'impression que la première réponse de @bpasero a irrité les gens et cela aurait pu être évité s'il avait expliqué pourquoi il pensait que les onglets ne devraient pas être une option au lieu de simplement dire "Non".

Quoi qu'il en soit, concentrons-nous sur le présent, y a-t-il une nouvelle construction avant l'événement // build /? :RÉ

@eyalsk Je crois que le commentaire "Non" faisait en fait référence à la première réponse de @inakianduaga , en ce sens qu'il n'est pas possible d'implémenter des onglets en utilisant l'API d'extension actuelle. Je pense que cela a été mal interprété comme disant que les onglets ne se produiront jamais, mais le problème aurait probablement été clos si c'était le cas.

@Tyriar , merci! :)

Quoi qu'il en soit, concentrons-nous sur le présent, y a-t-il une nouvelle construction avant l'événement // build /? :RÉ

Les bits de la nouvelle version vous attendent déjà sur le canal d'initiés ( notes de publication ), veuillez l'utiliser et nous faire part de vos commentaires.

@egamma merci! ;)

Nous commençons le travail de conception sur cette expérience et aimerions impliquer la communauté autant que possible. J'organiserai des discussions de conception régulières au fur et à mesure que nous progressons pour obtenir vos commentaires. Le plus souvent, il s'agira de sessions individuelles où nous partagerons ce sur quoi nous travaillons et en discuterons avec vous.

Les premières sessions auront lieu ce mercredi. Veuillez vous inscrire ici si vous êtes intéressé: https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

Impressionnant!
Le lun 4 avril 2016 à 3 h 54 Steven Clarke [email protected]
a écrit:

Nous commençons le travail de conception sur cette expérience et aimerions
impliquer la communauté autant que possible. Je vais exécuter un design régulier
discussions au fur et à mesure que nous progressons pour obtenir vos commentaires. Le plus souvent, ces
être des sessions individuelles où nous partageons ce sur quoi nous travaillons et discutons
les avec vous.

Les premières sessions auront lieu ce mercredi. Veuillez vous inscrire ici si
tu es intéressé:
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

Dans l'attente de vos commentaires sur les nouvelles conceptions que nous explorons liées à ce problème. Si vous êtes intéressé, veuillez vous inscrire via le lien sur le commentaire de @stevencl ci-dessus!

3 et 4 heures du matin seulement? Pas d'autre fois? Je ne peux pas faire 3/4 du matin PST un mercredi.

Le lun 4 avril 2016 à 8 h 14, Brad Gashler [email protected]
a écrit:

Dans l'attente de vos commentaires sur les nouveaux designs que nous explorons
liés à ce problème. Si vous êtes intéressé, veuillez vous inscrire via le lien sur
Commentaire de Steven ci-dessus!

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

Ce serait bien si vous avez un timing selon PST, beaucoup (moi y compris) peuvent participer

{Mobile}

Le lundi 4 avril 2016 à 8h50 -0700, "Glenn Block" [email protected] a écrit:

3 et 4 heures du matin seulement? Pas d'autre fois? Je ne peux pas faire 3/4 du matin PST un mercredi.

Le lun 4 avril 2016 à 8 h 14, Brad Gashler [email protected]

a écrit:

Dans l'attente de vos commentaires sur les nouveaux designs que nous explorons

liés à ce problème. Si vous êtes intéressé, veuillez vous inscrire via le lien sur

Commentaire de Steven ci-dessus!

-

Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub

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

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub

Oui s'il vous plaît. J'aimerais vraiment participer à la conversation.

Désolé, je sais que ces horaires ne conviennent pas à tout le monde. À l'avenir, nous examinerons les moyens de planifier des sessions dans différents fuseaux horaires, car nous prévoyons de les organiser régulièrement.

Pourquoi ne pas simplement en programmer un supplémentaire cette semaine à un moment différent? C'est un
sujet brûlant avec beaucoup d'intérêt.

Le lun 4 avril 2016 à 9 h 44 Steven Clarke [email protected]
a écrit:

Désolé, je sais que ces horaires ne conviennent pas à tout le monde. Dans le futur nous
examinera comment nous pouvons planifier des sessions dans différents fuseaux horaires pendant que nous
prévoyez de les organiser régulièrement.

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

Juste pour que vous le sachiez, les plages horaires que vous voyez ne sont que celles qui sont encore disponibles. J'avais des créneaux ouverts plus tard dans la journée, mais ceux-ci ont été pris assez rapidement.

Comme je l'ai dit, nous essaierons de planifier des sessions dans différents fuseaux horaires à l'avenir.

Merci pour tout l'intérêt porté.

Je vois, eh bien je suppose qu'ils se sont remplis instantanément (ce qui est bien)
Le lun.4 avril 2016 à 11h30 Steven Clarke [email protected]
a écrit:

Juste pour que vous le sachiez, les plages horaires que vous voyez ne sont que celles qui sont
toujours disponible. J'avais des créneaux ouverts plus tard dans la journée mais ceux-ci ont été pris
assez rapidement.

Comme je l'ai dit, nous allons essayer de planifier des sessions dans différents fuseaux horaires
l'avenir.

Merci pour tout l'intérêt porté.

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

Pouvez-vous / enregistrez-vous les sessions?

Le lun 4 avril 2016 à 11:32 Glenn Block glenn. [email protected] a écrit:

Je vois, eh bien je suppose qu'ils se sont remplis instantanément (ce qui est bien)
Le lun.4 avril 2016 à 11h30 Steven Clarke [email protected]
a écrit:

Juste pour que vous le sachiez, les plages horaires que vous voyez ne sont que celles qui sont
toujours disponible. J'avais des créneaux ouverts plus tard dans la journée mais ceux-ci ont été pris
assez rapidement.

Comme je l'ai dit, nous allons essayer de planifier des sessions dans différents fuseaux horaires
l'avenir.

Merci pour tout l'intérêt porté.

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

J'aurais aimé l'avoir vu plus tôt afin que j'aie pu m'inscrire. Pour ce que ça vaut, j'espère que vous n'implémentez jamais d'onglets. J'ai progressé de vim à TextMate à Sublime à Atom et maintenant à VS Code (avec beaucoup d'IDE en cours de route), j'ai donc beaucoup d'expérience avec les onglets. Pour moi, ils sont une béquille que les gens utilisent et ne passent jamais. Gérer de nombreux onglets ouverts sur un grand projet est un exercice de frustration qui ajoute une tâche supplémentaire dont je n'ai pas besoin. Oubliez d'en fermer quelques-uns et cela devient vite désespéré. À ces quelques-uns d'entre vous qui ont la discipline de ne jamais rencontrer cela, bravo. Mais pourquoi dépenser l'énergie mentale sur une tâche inutile?

Plus important encore, je pense que les onglets amènent les gens à penser en termes de FICHIERS, alors que (pour la plupart du développement de code) ils devraient se concentrer sur les fonctions, les classes, les espaces de noms - symboles. Les fichiers sont un détail d'implémentation dans la plupart des cas qui ne devrait pas dominer votre navigation. Je pense que VS Code a une réelle opportunité de fournir quelque chose de nouveau et de meilleur.

Je me rends compte que ce n'est que MA préférence, et je comprends pourquoi beaucoup de gens demandent que les onglets soient facultatifs. Cela peut sembler un compromis raisonnable, mais il serait difficile de bien prendre en charge deux flux de travail de navigation différents. Essayez simplement de désactiver le plugin des onglets dans Atom et voyez combien de choses ne fonctionnent pas ou fonctionnent mal parce que les développeurs s'attendent à ce que les onglets soient là. Donc, pour mes propres raisons égoïstes, je veux que les développeurs de VS Code se concentrent sur la navigation qui n'est pas basée sur des onglets (ou même des fichiers).

Idem @indiejames

Si vous implémentez des onglets, veuillez prendre en charge plusieurs lignes pour de nombreux fichiers. Je déteste avoir une barre de défilement sur ma barre d'onglets. Ma mise en œuvre d'onglets préférée est Tabs Studio . Découvrez également comment les fichiers portant le même nom de base peuvent être automatiquement regroupés.

Mon flux de travail J'ouvre des onglets pendant que je travaille dans Sublime selon mes besoins. Je ne laisse pas des tonnes d'onglets ouverts et j'utilise souvent "tout fermer" pour ramener les choses à une table rase.

J'ai développé plus de 30 ans sur plusieurs IDE et éditeurs de texte. Je ne vois pas les onglets comme une béquille, ils sont un outil d'organisation utile. Oui, ils peuvent devenir incontrôlables si vous avez des millions d'onglets, mais pas moi ...

En termes d'onglets orientés vers les fichiers et autres, le code vit dans des fichiers et les fichiers SONT utilisés pour l'organisation, et le code VS est construit autour de la gestion des dossiers et des fichiers de code.

Je comprends totalement que certains préfèrent peut-être ne pas avoir d'onglets et je ne dis pas de se débarrasser de ce qui est là, mais avoir un flux de travail d'onglets pris en charge serait bien.
Le mar 5 avril 2016 à 7 h 32, l'erreur [email protected] a écrit:

Si vous implémentez des onglets, veuillez prendre en charge plusieurs lignes pour de nombreux fichiers. je déteste
avoir une barre de défilement sur ma barre d'onglets. Ma mise en œuvre d'onglets préférée est Tabs
Studio https://tabsstudio.com/.

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

«Il est plus facile pour les utilisateurs de mal utiliser le produit» est une terrible raison pour ne pas prendre en charge une fonctionnalité. L'outil est là pour _faciliter_ les workflows, pas pour les _dicter_. Si un utilisateur ne peut pas trouver un flux de travail confortable, il est plus susceptible de choisir un autre outil là où il le peut, plutôt que de s'adapter à un paradigme inconnu.

Je travaille actuellement sur quelques fichiers étroitement liés, faisant des va-et-vient entre eux. Chaque fois que j'ai besoin de changer, je dois choisir dans la barre latérale ou dans une liste déroulante, ce qui prend 3 à 4 fois plus longtemps qu'un onglet.

@indiejames

mais il serait difficile de bien prendre en charge deux flux de travail de navigation différents. Essayez simplement de désactiver le plugin des onglets dans Atom et voyez comment les choses peuvent ne pas fonctionner ou mal parce que les développeurs s'attendent à ce que les onglets soient là. Donc, pour mes propres raisons égoïstes, je veux que les développeurs de VS Code se concentrent sur la navigation qui n'est pas basée sur des onglets (ou même des fichiers).

Il n'est pas trop difficile de prendre en charge deux flux de travail de navigation différents ou même plus de deux, ce qui est vraiment difficile, c'est de bien concevoir!

Si vous voulez vraiment prendre en charge les onglets et les fichiers de travail ou un autre flux de travail, vous devez revenir en arrière de quelques pas, effectuer un zoom arrière et repenser la navigation à partir de zéro, faisant des flux de travail une stratégie parmi laquelle les gens peuvent choisir.

Créer une extension juste pour avoir des onglets dans l'éditeur sans tenir compte des cas d'utilisation et de la façon dont les gens travaillent avec les onglets ou un autre flux de travail manque simplement la cause qui n'ajoute aucun avantage réel et donc très probablement un échec.

Il y a une différence entre la navigation de code et la navigation de fichier, lorsque vous codez, vous devez sûrement
pensez aux symboles plutôt qu'aux fichiers, mais le code vit dans des fichiers et parfois vous devez également le gérer, par exemple, je n'ouvre pas beaucoup d'onglets mais lorsque je travaille sur plusieurs projets, j'ai généralement un fichier par projet ouvert qui est lié, je utilisez beaucoup de raccourcis clavier mais parce que les onglets sont toujours en haut, et quand je regarde l'éditeur, ils sont toujours là, c'est probablement psychologique mais cela m'aide simplement à me concentrer.

Votre expérience avec les onglets est malheureuse et je ne sous-estime pas du tout votre expérience, je ne sais pas comment vous travaillez mais beaucoup d'entre nous l'aiment et l'utilisons avec beaucoup de succès.

Je ne pense pas qu'une expérience soit meilleure que l'autre, mais avoir des expériences différentes ou même hybrides peut être utile et les éditeurs devraient honorer mon expérience et ne pas aller à l'encontre.

Il serait très utile pour nous, qui ne pouvons pas participer aux réunions en raison d'autres engagements, de pouvoir donner leur avis.
Peut-être, une fois les réunions terminées le premier jour, publier une vidéo d'une réunion (avec la permission de toutes les personnes impliquées) que les autres peuvent voir et commenter dans le temps restant pour les réunions?

Évidemment, cela ne peut pas être une longue période, mais plus de commentaires ne peuvent pas nuire avec, espérons-le, quelques points de vue différents ajoutés.

J'espère vraiment que certains développeurs Python et c / c ++ seront présents à la réunion car leur flux de travail est différent de celui d'un développeur JavaScript

Merci Steven d'avoir pris le temps de parler avec moi!
Cet engagement avec la communauté est vraiment encourageant et j'apprécie
suite au développement de vscode!

Le 6 avril 2016 à 19h41, Michael Wallace Louwrens < [email protected]

a écrit:

Ce serait très utile pour nous qui ne pouvons pas faire les réunions en raison d'autres
engagements pour pouvoir donner un feedback.
Peut-être, une fois les réunions terminées le 1er jour, publier une vidéo d'un
réunion (avec la permission de toutes les personnes impliquées) que d'autres peuvent voir et commenter
dans le temps restant pour les réunions?

Évidemment, cela ne peut pas être une longue période, mais plus de commentaires ne peuvent pas nuire avec
j'espère que certains points de vue différents ont été ajoutés.

J'espère vraiment que certains développeurs Python et c / c ++ seront présents à la réunion comme
leur flux de travail est différent de celui d'un développeur JavaScript

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

Merci @TurkeyMan , bonne conversation avec vous plus tôt dans la

Pour tous ceux qui n'ont pas pu participer, nous les organiserons régulièrement, de sorte qu'il y aura des occasions de participer à une date ultérieure.

Les conversations que nous avons cette semaine sont toutes des conversations 1: 1 au cours desquelles nous discutons des détails des problèmes que chaque individu a rencontrés. Cela nous permet de mieux comprendre les problèmes que nous devons résoudre.

Dans les semaines suivantes, lorsque nous examinerons les maquettes de conception, nous chercherons des moyens d'organiser des discussions de groupe ainsi que des discussions 1: 1. Nous examinerons également comment enregistrer et publier des vidéos de réunions par la suite.

@stevencl est-il possible de publier un résumé des sessions (ou encore mieux, des enregistrements) pour ceux d'entre nous qui ne sont pas en mesure de participer, mais qui sont toujours intéressés à fournir des commentaires.

+1
Le mercredi 6 avril 2016 à 07:36 Peter Petrov [email protected]
a écrit:

@stevencl https://github.com/stevencl est-il possible de poster un résumé
des sessions (ou encore mieux, des enregistrements) pour ceux d'entre nous qui ne
participer, mais sont toujours intéressés à fournir des commentaires.

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

Je voudrais partager mes attentes en matière de navigation dans les fichiers dans un éditeur de code. J'essaie de m'habituer à VScode depuis des semaines maintenant et de revenir à Sublime. Voici ce que j'attends:

  1. navigation sans souris
  2. possibilité de naviguer en avant et en arrière dans l'ensemble des fichiers ouverts
  3. fermez facilement les fichiers

Jusqu'à présent, j'ai trouvé que VScode échouait malheureusement pour moi sur les trois. L'espace de travail n'est pas intuitif car lorsque je ferme un fichier, il ne se ferme pas vraiment, il n'est tout simplement plus modifiable. La fermeture du fichier est une activité mentale consistant à le supprimer de l'ensemble de fichiers avec lequel je travaille.

Dans VScode, lorsque je navigue dans les fichiers qui sont ouverts _dans ma tête_, je continue à rencontrer des «déchets» que je pensais avoir été jeté auparavant. C'est extrêmement distrayant et je finis par avoir des fichiers 20-ish ouverts dans l'espace de travail et je ne peux finalement plus en garder une trace et les fermer tous.

Je ne peux pas utiliser le clavier pour basculer rapidement entre les fichiers ouverts, qui forment dans ma tête une liste liée. L'ordre dans lequel je les ouvre est tout aussi important que l'ordre dans lequel je les ferme. Je trouve que Ctrl + Tab est inutile car je dois lire les noms de fichiers un par un dans cette liste et ensuite déterminer lequel tabuler. Je peux beaucoup plus rapidement parcourir 5 à 8 fichiers ouverts vers le bon en reconnaissant simplement le contenu pendant qu'il clignote ou en sachant simplement où se trouve dans «la liste» le fichier souhaité.

J'espère que cela a du sens. J'essaie d'optimiser au maximum mon flux de travail, d'utiliser le clavier et d'éviter la souris car cela ralentit énormément tout. Je lutte avec cela dans VScode plus que je ne l'ai fait auparavant dans n'importe quel autre éditeur (textmate, vim, sublime, flash, eclipse, etc ...)

Juste pour répéter, les enregistrements des réunions qui ont lieu cette semaine ne seront pas disponibles car chaque réunion est une conversation 1: 1 où chaque personne discute des détails de leur fonctionnement et des problèmes spécifiques qu'ils ont avec VS Code. Au cours de ces conversations, nous n'entrerons pas dans les détails sur les designs.

Dans les semaines à venir, nous chercherons des opportunités pour enregistrer et rendre disponibles des réunions où nous discuterons des conceptions pour améliorer la gestion des documents dans VS Code. Recherchez une autre invitation de ma part la semaine prochaine pour participer à la prochaine série de discussions sur la conception.

Merci pour tous les commentaires et les détails sur la façon dont VS Code fonctionne ou ne fonctionne pas pour vous.

Tout simplement parce que personne ne semble l'avoir mentionné et que je soupçonne que je ne suis pas seul à ce sujet: pour moi, les onglets dans un éditeur sont une question de mémoire spatiale - c'est-à-dire où suis-je, et où sont les choses autour de moi?

Nous vivons dans un monde physique. Nous avons évolué pour comprendre et faire des intuitions sur l'espace qui nous entoure et nous le faisons sans réfléchir. C'est pourquoi nous pouvons taper sans regarder le clavier - nous «savons simplement» où se trouvent les touches et pouvons taper rapidement. Avec les onglets, notre wetware par défaut avec lequel nous sommes nés peut entrer en jeu et nous savons "où" se trouve un fichier à l'écran et nous pouvons l'affiner sans réfléchir parce que c'est son instinct que nous utilisons tous les jours. Je «dépose un fichier» pour ainsi dire via un onglet dans l'éditeur, et je peux me souvenir de «où je l'ai laissé» exactement de la même manière que je peux me souvenir où j'ai posé ma télécommande TV la prochaine fois que j'ai besoin de changer de chaîne ( en supposant que je n'avais plus une télé)

Pour moi, un historique de fichiers ordonné dans le temps va totalement à l'encontre de cette compréhension intuitive de l'espace. Si je sais que "main.java" ou la touche T de mon clavier est dans une certaine position, je ne veux pas qu'il bouge à moins que je ne le déplace physiquement et délibérément. S'il bouge tout seul, je dois m'arrêter, réfléchir et le trouver. Imaginez une télécommande de téléviseur avec des roues qui se déplaçait toute seule dans votre maison ou un clavier qui réorganisait les touches en fonction de la dernière utilisation de chaque lettre! Ce serait le chaos! :-)

J'aime vraiment VSCode, mais je suis personnellement frustré et ralenti par le manque d'onglets. Continuez votre bon travail - j'ai hâte de voir ce que vous proposez!

@ matt1
Ce que vous décrivez est exactement ce qui rend les onglets si limitatifs (pour moi). Les onglets sont une métaphore des onglets physiques placés sur des fichiers dans un classeur physique et ont tous les mêmes limitations. Je préfère avoir un classeur automatisé dans lequel je peux taper quelques clés et accéder à mes informations plutôt qu'un classeur physique où je dois trier les choses moi-même et gérer l'espace limité pour les onglets visibles.

Je suis curieux - naviguez-vous dans les onglets à l'aide de la souris / du trackpad ou en utilisant des combinaisons de touches sur d'autres éditeurs?
Si vous utilisez exclusivement des raccourcis clavier, vous avez peut-être un flux de travail d'onglets que je ne connais pas
de et j'aimerais le voir. Je soupçonne, cependant, que beaucoup de gens utilisent la souris / trackpad - sans se rendre compte à quel point ce changement de contexte est improductif et à quel point il les ralentit pour retirer leurs mains des touches. Il est facile à apprendre et à comprendre, mais moins puissant / productif que l'utilisation de combinaisons de touches. Si vous vous retrouvez à "atteindre un onglet" avec la souris, cela peut être intuitif et tirer parti de votre sens spatial, mais cela vous ralentit. Pas tellement dans le temps perdu pour le mouvement physique, mais dans le changement de contexte lui-même.

Je me rends compte que ce ne sont que mes opinions et que la plupart des gens ne sont pas d'accord avec elles, mais c'est le _Code_ de Visual Studio. Pour les codeurs / développeurs. Et les développeurs ont réalisé il y a longtemps que le shell> gui pour la plupart des choses (pas toutes), et que les métaphores de bureau, bien que faciles à apprendre, sont assez limitatives.

Alors est-il juste possible que certains d'entre vous qui disent "Je ne peux pas vivre sans onglets" n'aient pas exploré d'autres flux de travail? Si tel est le cas, ne vaut-il pas la peine de l'essayer si le gain est d'augmenter votre productivité?

À ceux d'entre vous qui ont essayé de travailler sans onglets et qui ne peuvent pas s'adapter ou estiment honnêtement que les onglets vous rendent plus productif, je peux accepter qu'il ne s'agisse que d'un désaccord honnête. Mais à ceux qui plaident pour des métaphores physiques parce que "ils travaillent depuis 30 ans!" Je demanderais si nous avons vraiment besoin d'un autre TextMate / Sublime / Atom? Ne devrions-nous pas essayer de déplacer l'enveloppe?

Je n'ai aucun doute que je suis en minorité ici (mais cela ne me trompe pas), c'est donc le dernier commentaire que je vais faire. N'hésitez pas à empiler :)

Décidé de vérifier VS Code pour voir si cela pourrait être un remplacement gratuit pour Sublime, mais sans documents à onglets, c'est un non-démarreur. Être capable de définir VS Code en une seule instance, d'ouvrir plusieurs documents et de basculer facilement entre eux est une exigence de base de tout éditeur de texte. Garder l'Explorateur ouvert est une solution de contournement, mais ce n'est pas contre nature d'avoir des onglets de gauche au lieu des onglets supérieurs comme dans VS, les navigateurs, Sublime, etc. Ctrl-Tab a plusieurs problèmes, il faut regarder le clavier et bouger la main (pour autre chose que la souris), l'autre est que ce n'est pas intuitif. Quiconque suggère qu'un éditeur sans onglets est autre chose que BloatedNotepad n'a clairement jamais fait d'édition sérieuse de plusieurs documents, comme cela est nécessaire lorsque le débogueur parcoure quelque chose qui avait plus d'un fichier en entrée du compilateur.

@indiejames
Les onglets ne sont pas pour moi une question de productivité. C'est une question de cognition.

Personnellement, je n'ai jamais trouvé que la vitesse de frappe brute ait jamais été le facteur limitant de ma productivité. La programmation nécessite de la réflexion et de la considération - quelques clics ne sont pas un problème dans le grand schéma des choses pour moi compte tenu du temps que nous passons à «réfléchir».

@indiejames J'utilise ctrl + (shift +) tab pour naviguer entre les onglets, pas nécessairement la souris. Un de mes plus gros reproches avec les fichiers de travail est le même que celui de @ matt1 - le fait que ctrl + tab fonctionne dans l'ordre le plus récemment utilisé. Je ne me souviens pas nécessairement du fichier que j'ai regardé en dernier et avant-dernier, mais il m'est très facile de voir / de me souvenir dans quel ordre je les ai ouverts / arrangés. Sublime Text utilise également par défaut ctrl + (shift +) tab sur MRU ordre; Je le change toujours, car il a des commandes pour MRU et l'ordre visible.

Je me souviens à l'époque où un navigateur Web (était-ce Opera pré-clignotant peut-être?) Utilisait également MRU pour ctrl + tab par défaut, supposant vraisemblablement que puisque les systèmes d'exploitation le font pour les applications, un navigateur pourrait aussi bien le faire; J'ai trouvé cela terriblement peu intuitif et j'ai dû faire très attention pour trouver ce à quoi je voulais vraiment revenir ... ce qui, devinez quoi, rend le processus plus lent.

L'argument de l'utilisation exclusive de l'ouverture rapide fonctionne aussi bien dans Sublime Text avec des onglets que dans VS Code avec des fichiers de travail. Les onglets n'interdisent pas du tout ce flux de travail.

Pour ceux qui préfèrent l'approche actuelle des fichiers de travail dans VS Code, combien d'entre vous préfèrent réellement cliquer sur les fichiers dans la liste des fichiers de travail par opposition aux flux de travail suivants?

  • en utilisant Ctrl + E / + E pour ouvrir rapidement les fichiers récents.
  • utiliser Ctrl + Tab pour changer de fichier récent

Soit dit en passant, pour ceux qui préfèrent les onglets , vos commentaires nous ont été très utiles alors que nous cherchons à les ajouter au produit. Merci beaucoup de continuer à partager!

@ bgashler1
Je préfère les raccourcis clavier. Pas pour que je puisse être le dactylo le plus rapide, mais parce que je les trouve moins gênants que de déplacer la souris / le trackpad.

Je pense que ce qui manque à beaucoup de "Fichiers de travail et aucun onglet JAMAIS", c'est qu'ils _way_ dans lesquels beaucoup d'entre nous utilisent des onglets. Par exemple, lorsque je travaille sur une application MVC (Web, mobile ou bureau), j'ai tendance à avoir des onglets dans un ou plusieurs volets verticaux (dont VSCode a également besoin) dans un ordre spécifique: fichier modèle, fichier de vue, fichier de contrôleur . Donc, une configuration que j'ai fréquemment ouverte ressemble à ceci:

Volet gauche

Fichier modèle 1 (onglet) | Afficher 1 fichier (onglet) | Fichier Controller 1 (onglet)

Volet droit

Fichier modèle 2 (onglet) | Afficher 2 Fichier (onglet) | Fichier Controller 2 (onglet)

Cette configuration me permet de sélectionner rapidement les fichiers de modèle pour les deux composants sur lesquels je travaille à des fins de comparaison ou Afficher les fichiers lorsque j'ai mon chapeau UI / UX. Cela NE PEUT absolument PAS être accompli efficacement avec des fichiers de travail, surtout si vous avez également d'autres fichiers ouverts (par exemple CSS, scripts db, etc.). Je fais une tonne d'UI / UX et c'est de loin une pratique courante. Si j'étais strictement un développeur backend Java ou un DBA, alors non, ce ne serait pas une exigence. Mais pour la grande majorité d'entre nous, développeurs Web et mobiles full stack, ne pas avoir d'onglets (et de volets verticaux / horizontaux à onglets) est un obstacle extrême. Bien que je respecte VSCode à court terme, j'ai de sérieuses réserves à m'en tenir à cause de cette capacité manquante. Personne ne peut nous convaincre que les onglets sont inutiles et qu'une liste de fichiers de travail n'est pas une innovation (Adobe Brackets a également une liste de fichiers de travail et elle existe depuis 2012).

Encore une fois, ce n'est pas un problème du tout ou rien. Nous demandons simplement la même capacité qui existe dans d'autres éditeurs en option même si cette capacité est désactivée par défaut. Si VSCode implémentait les onglets / volets de fenêtre exactement comme le fait Atom, cela résoudrait 99,99% de nos prises liées aux onglets. Je sais que ce n'est pas une tâche triviale à mettre en œuvre, mais je pense que beaucoup d'entre nous seraient satisfaits d'attendre un peu plus longtemps (des mois, pas des années) pour que cette fonctionnalité soit effectuée correctement plutôt que de rester dans le backlog.

Juste mes 2 ¢ ...

Bien que j'aie déjà communiqué la plupart de cela à @ bgashler1 , je vais faire un petit article ici pour expliquer le comportement idéal pour moi.

  1. Les raccourcis clavier doivent fermer les fichiers de travail, les supprimant de la liste des fichiers de travail et de la pile MRU (la plus récemment utilisée). J'ai les raccourcis clavier suivants pour accomplir ceci:

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

  1. Les fichiers dans l'éditeur doivent être "empilés", de sorte que lorsque vous fermez un fichier, le dernier fichier de la pile MRU s'affiche.
  2. ctrl + shift + t devrait restaurer l'onglet le plus récemment fermé. Cette liaison de touches est en conflit avec workbench.action.tasks.test dans vscode mais c'est une touche de raccourci très standard dans les environnements à onglets. J'ai créé une demande de fonctionnalité pour la commande ici https://github.com/Microsoft/vscode/issues/3989
  3. ctrl + tab et ctrl + shift + tab ne doivent tourner que dans les fichiers de la liste des "fichiers de travail", et non dans les fichiers qui ont été "prévisualisés" (un simple clic dans l'explorateur, puis la navigation).
  4. Je veux que mes fichiers de travail soient disposés en haut de l'éditeur. Les raisons en sont:

    • Je veux pouvoir voir mes fichiers de travail visuellement, quelle que soit la barre latérale que j'ai ouverte. En relation: https://github.com/Microsoft/vscode/issues/3360

    • Au cours des près de 2 décennies que j'ai programmées, j'ai cherché au-dessus de l'éditeur pour mes fichiers de travail. C'est une habitude difficile à briser.

@bpasero

Soit dit en passant, pour ceux qui préfèrent les onglets, vos commentaires nous ont été très utiles alors que nous cherchons à les ajouter au produit. Merci beaucoup de continuer à partager!

J'utilise beaucoup Ctrl + Tab dans VSCode mais je pense que l'expérience dans Visual Studio est tellement meilleure car en plus des fichiers, je peux aussi naviguer vers d'autres parties de l'interface utilisateur, je l'utilise pour naviguer vers le gestionnaire de console de package, Explorateur de solutions, etc.

@Tyriar Grands points!

[Avertissement de philosophie!]

Pourquoi ctrl+tab il tellement plus utile que le concept de «fichiers de travail» tel qu'il est? C'est la question cruciale. Personnellement, je pense qu'il y a deux problèmes en jeu.

Premièrement, ctrl+tab est un raccourci clavier et les raccourcis clavier sont inconsciemment associés au curseur - l'utilisateur s'attend à ce que ctrl+tab modifie le fichier dans l'éditeur actuel, où le curseur est actuellement placé, et c'est précisément ce qu'il fait. Ceci est différent des 'fichiers de travail' ou du navigateur qui ne sont pas associés à un éditeur particulier - ils sont horizontalement distants de tous les éditeurs sauf un et associés à l'éditeur _ le plus récent_ - et sont généralement utilisés avec la souris. Même si vous les utilisez avec le clavier, vous avez quitté votre curseur au moment où vous sélectionnez un fichier.

Deuxièmement, ctrl+tab vous montre _tous_ les fichiers que vous avez vus récemment, dans l'ordre chronologique inverse. «Fichiers de travail» ne vous montre que ceux sur lesquels vous avez double-cliqué ou modifié et dans l'ordre dans lequel vous avez pris la peine de les ouvrir. Les critères et l'ordre sont arbitraires et n'ont rien à voir avec la façon dont les programmeurs pensent - aller et venir entre l'appelant et la fonction, la classe et le consommateur.

(Opinions. Le kilométrage peut varier.)

EDIT: Mon point est le suivant: comprendre pourquoi une fonctionnalité fonctionne et une autre ne aidera pas à corriger la fonctionnalité ou à en concevoir une meilleure. En l'état, les fichiers de travail ne le font pas.

@Tyriar : Personnellement, je déteste vraiment le fait que les fichiers en un seul clic n'apparaissent pas dans les fichiers de travail. Je veux TOUS les fichiers que j'ai vus dans ma pile récemment utilisée - même les fichiers externes en lecture seule. Je les ai ouverts pour une raison. Si j'en ai fini avec eux, ils disparaîtront de la liste assez tôt. Au mieux, il devrait y avoir une option pour que le simple clic et le double-clic se comportent de la même manière.

J'ai compris comment tirer le meilleur parti de ce qui me manquait de sublime dans le contexte de ce numéro:

[
  { "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 Je ne sais pas si quelqu'un a déjà fait une demande de fonctionnalité pour désactiver les «fichiers de prévisualisation».

@stephenmartindale, nous cherchons un moyen d'épingler des "fichiers de prévisualisation" pour qu'ils restent ouverts, y compris les fichiers en lecture seule.

Nous aimerions conserver les "fichiers de prévisualisation", car souvent, les gens ne savent pas quel fichier ils recherchent jusqu'à ce qu'ils en aient ouvert plusieurs (ce qui peut entraîner un nombre indésirable de fichiers ouverts qui ne sont pas pertinents).

J'aime vraiment le flow de Sublime ici. Un simple clic vous sautez au fichier,
double-cliquez pour qu'il reste ouvert.
Le sam 9 avril 2016 à 11 h 49 Brad Gashler [email protected]
a écrit:

@stephenmartindale https://github.com/stephenmartindale nous recherchons
dans un moyen d'épingler des "fichiers de prévisualisation" pour rester ouverts.

Nous souhaitons conserver les "fichiers de prévisualisation", car souvent les gens ne le savent pas
quel fichier ils recherchent jusqu'à ce qu'ils en aient ouvert plusieurs (ce qui peut
entraîner une quantité indésirable de fouillis de fichiers ouverts).

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

@Tyriar , @ bgashler1 , @stevencl Je pense qu'il vaut mieux avoir deux nouveaux messages pour les onglets et les fichiers de travail pour recueillir des commentaires.

Juste mon avis mais j'ai l'impression que ce serait bien mieux que de discuter des deux fonctionnalités ici, celle-ci est assez longue. :)

👎 Veuillez ne pas le faire, ou du moins le rendre facultatif. L'interface utilisateur propre et sans onglets est l'une de mes choses les plus appréciées à propos du code VS.

@tobico Il n'est pas nécessaire que ce soit tout ou rien ... vous savez, en ce qui me concerne, je veux que les fichiers de travail et les onglets soient optionnels et pourtant intégrés aux personnes qui veulent vivre cette expérience.

Je voudrais en second lieu que Ctrl + W devrait fermer non seulement l'éditeur actuel, mais le fichier de travail ouvert correspondant. Pour moi, c'est le plus gros inconvénient de l'implémentation actuelle. Cela et le fait que Ctrl + Tab répertorie tous les fichiers récents, pas seulement ceux des fichiers de travail. À la réflexion, une troisième mise en garde serait qu'un simple clic n'ouvre pas un fichier en tant que fichier de travail, mais le modifie.

+1

@csholmq, vous pouvez le faire maintenant, consultez les raccourcis clavier personnalisés dans https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479

@Tyriar Cela répond à presque toutes mes mises en garde. Merci!

En 3 minutes, j'ai arrêté d'utiliser VS Code et je suis retourné à Atom. Pas d'onglets, pas de go. Désolé, mon flux de travail a été foré en moi. Je parierais qu'un sondage rapide il y a 4 ans aurait obtenu votre réponse d'interface utilisateur beaucoup plus rapidement. Mais laissez aussi l'arrogance de Microsoft à réparer quelque chose qui n'est pas cassé.

@zunama nous n'avons pas oublié les utilisateurs qui veulent des onglets et une gestion améliorée des documents. Maintenant que nous sommes 1.0, c'est l'une de nos plus grandes priorités pour répondre à ces préoccupations. Des choses géniales arrivent bientôt dans VS Code.

En tant que développeur Web, les onglets sont importants pour moi. Contrairement aux programmeurs de bureau (qui se concentrent principalement sur un seul fichier à la fois), nous basculons toujours entre les fenêtres et en utilisant la souris en même temps (par exemple, découpage d'une image à partir de Photoshop, puis retour immédiat à l'éditeur. Ou débogage dans les navigateurs, et c'est parti) retour à un autre fichier pour faire la correction). Avec les onglets, nous pouvons accéder rapidement au fichier cible. Avec les raccourcis, c'est encore 2 étapes. Avec la barre latérale "fichiers de travail", il y a moins d'espace dans la zone de code principale (car nous mettons Photoshop & Editor ou les navigateurs côte à côte). Height dans l'éditeur sont moins nécessaires. Vous êtes toujours capable de mémoriser quelques lignes de plus, n'est-ce pas?

En outre, les onglets supérieurs sont meilleurs pour les yeux humains. Vous pouvez scanner le titre de l'onglet supérieur et l'indicatif régional principal en même temps. Mais vous ne pouvez pas lire à gauche working files avec le code principal ensemble. Essayez-le vous-même. De plus, les onglets sont plus larges, mieux adaptés aux mouvements de la souris. (Même si vous ne vous concentrez pas dessus, c'est plus prévisible)

+1/0

+1

Juste mon opinion personnelle mais s'il vous plaît, arrêtez de faire -1, +1 messages ... Je veux dire en plus de suggérer que vous aimez ou n'aimez pas cette fonctionnalité, quelque chose que la réaction / émoticône peut être utilisée car cela ne dit rien sur votre expérience et donc si vous écrivez déjà un article, assurez-vous qu'il est utile! Je suis sûr que vous avez votre propre conservateur sur les choses et comment vous aimeriez qu'elles fonctionnent! sinon, utilisez simplement des émoticônes.

Méta:
@eyalsk Dans ce cas, la discussion est en cours de sorte qu'elle semble effectivement redondante. Mais pour les questions sur lesquelles vous souhaitez gagner du terrain, est-ce vraiment l'équivalent du "Ajoutez votre réaction"? Cela ne fait-il pas qu'alerter le commentaire plutôt que d'indiquer que le problème est un sujet brûlant? Ie alerte-t-il les développeurs qui sont balisés sur le problème ou définit-il le problème comme modifié?

@csholmq Je ne sais pas si je vous

@zunama Ce n'est pas de l'arrogance d'essayer de chercher une meilleure alternative. "Non cassé" n'est pas un argument valable contre la recherche de nouvelles choses. C'est à peu près un argument pour cela (peut-être qu'il y a quelque chose de mieux?). Bien que j'ai remarqué dans cette discussion que si VS Code veut être pleinement utilisé aujourd'hui, il devrait viser à plaire à la base d'utilisateurs actuelle de «l'ancien état d'esprit» et à innover plus tard. Parce que les gens ne sont pas très doués pour attendre et que cela vous fait gagner du temps en essayant d'expliquer pourquoi ceci ou cela est mieux.

Revenons à votre commentaire: Si vous voulez faire quelque chose de bien, ne passez pas 3 minutes à arrêter. Vous énumérez votre point de vue sur les critiques utiles et recherchez des améliorations possibles. Un point de vue de 3 minutes est inutile - et dangereux - pour votre conception car il est biaisé.

Un sondage ne fonctionne pas lorsque vous souhaitez innover. Exemple:


Lequel de ces styles de nagivation serait le plus productif pour vous?

  • Quelque chose. (Essayez quelque chose de nouveau qui pourrait être mieux)
  • Onglets. (Bon vieux style de travail que vous avez appris à aimer).

Bien sûr, les onglets gagneraient. Mais peut-être l'autre idée pourrait ouvrir la voie à une nouvelle interface utilisateur de navigation standard.

Pour être honnête, l'une des caractéristiques déterminantes de VS Code pour moi était l'absence d'onglets. Je n'avais même pas réalisé (au début) qu'ils manquaient! C'était un point de vue très intéressant.

Chaque fois que j'utilise des onglets, ils sont toujours cliquetis et impossibles à trouver. Lorsque je ne peux pas voir un certain fichier immédiatement dans la liste des onglets, ma première réaction est de le rouvrir. . . et puis je découvrirais qu'il était déjà ouvert. Bien sûr, l'ordre des onglets est sérieusement perturbé dans le processus. C'est ce qui m'arrive dans Visual Studio 2015.

Dans le monde où tout est pareil, c'est rafraîchissant d'avoir une identité.

PS. Je ne suis cependant pas très impressionné par la section des fichiers de travail. Je l'utilise principalement pour visualiser rapidement les fichiers à enregistrer.

PSS. Une idée - s'il y a des onglets dans vs code un jour, alors peut-être sera-t-il préférable de limiter le nombre maximum d'onglets ouverts, c'est-à-dire de fermer automatiquement les onglets les plus anciens lorsque de nouveaux sont ouverts?

@RussBaz Je ne pense pas que limiter le nombre d'onglets soit une bonne idée car ce nombre peut changer d'un utilisateur à l'autre, mais peut-être que cela peut être une option comme celle-ci:

tabs.autoClose = "non visible", "off", "time", x où x est un nombre

C'est une idée bizarre. Si j'aime 16 onglets et que vous en aimez 4, c'est simple. VOUS utilisez 4 onglets et j'en utiliserai 16! Pourquoi dire que votre chemin est meilleur que le mien, ou vice versa. Qu'est-ce que c'est que ça? Même la conversation sur les onglets est un peu inutile tant que les onglets sont activés / désactivés dans Options / Préférences. Ceux qui ne veulent pas d'onglets, super! Ceux qui les veulent, cochez la petite case! Vraiment, il n'est pas nécessaire que votre chemin soit meilleur que le mien, ou que je sache mieux que vous.
+1
;)

Exemple de cas d'utilisation: je passe actuellement entre 6 onglets en permanence dans atom.

Cela passe à environ 10 lorsque j'ai besoin de travailler sur des sections plus profondes. Je les utilise tous! Donc, fermer et rouvrir serait une douleur. Je pourrais avoir des fichiers volumineux à sa place, mais ce serait beaucoup plus pénible à gérer, car il atteindrait 6 000 lignes dans un fichier si j'incluais chaque partie d'un module dans un seul fichier.

@Measuring Je suis d'accord et en désaccord avec vous. Il y a des choses qui doivent être innovées, mais il faut d'abord se demander, qu'en est-il du flux de travail pouvons-nous améliorer en supprimant les onglets. Eh bien, pour moi, chaque éditeur que j'utilise pour le développement a une interface à onglets car il est courant pour un developpement de fonctionner entre 5 à 10 fichiers à la fois sans se souvenir du nom exact des fichiers ni de l'ordre dans lequel ils les ont ouverts. Donc Je dois demander, comment cette nouvelle interface l'a-t-elle améliorée? En quoi est-ce innovant? Demandez d'abord, comment l'utilisent-ils, puis demandez-vous comment puis-je l'améliorer.

En ce qui concerne le problème de trois minutes, je vais supposer que Code n'est pas si différent que Sublime (mon choix préféré) ou Atom (ce que j'essaie), mais si dès le début, j'ai du mal à travailler avec ou à montrer quelqu'un efficacement ce qu'il doit faire entre les fichiers pour faire fonctionner quelque chose, alors je vais utiliser quelque chose qui fonctionne mieux pour mes besoins maintenant et examiner le code dans quelques versions plus tard quand il sera prêt. Ce n'est pas un état d'esprit «à l'ancienne», mais plutôt une efficacité dans mon travail.

Demander à ceux d'entre nous qui préfèrent les onglets de passer à aucun onglet est tout aussi bon que
demander à ceux qui ne préfèrent aucun onglet de passer aux onglets. Nous ne voulons pas tous les deux
passez à l'autre méthode.

Pouvons-nous nous arrêter maintenant avec le type de 'Mac vs Windows', 'Android vs IPhone'
débats sur la meilleure façon de procéder: «Tabs vs No Tabs»? Ils sont tous les deux bons
et différentes personnes ont leur propre préférence.

Je pense que la meilleure solution est d'ajouter des onglets comme préférence qui peuvent être
activé en option. Ensuite, les deux foules sont ravies.

Quelqu'un est-il contre les deux méthodes que vous pouvez activer ou
en fonction de vos préférences?

Je pense que cela se résume à ces deux options:

1) Ajoutez des onglets comme préférence. On pour ceux qui l'aiment et hors pour ceux qui
pas.

2) N'ajoutez pas du tout d'onglets, même si j'ai la possibilité de les désactiver.

Pourquoi voteriez-vous même pour l'option 2 lorsque vous avez la possibilité de les activer
de?
Le 15 avril 2016 à 19 h 32, "James McLaughlin" [email protected]
a écrit:

@Measuring https://github.com/Measuring Je suis d'accord et en désaccord avec vous.
Il y a des choses qui doivent innover, mais il faut d'abord se demander
sur le flux de travail pouvons-nous améliorer en supprimant les onglets. Eh bien pour moi, chaque
l'éditeur unique que j'utilise pour le développement a une interface à onglets car il est
courant pour un développe de fonctionner entre 5 à 10 fichiers à la fois sans
se souvenir du nom exact des fichiers ni de l'ordre dans lequel ils les ont ouverts
Je dois donc demander, comment cette nouvelle interface l'a-t-elle amélioré? Comment est
c'est innovant? Demandez d'abord comment l'utilisent-ils, puis demandez-vous comment puis-je faire
cest mieux. Quant à la question des trois minutes, je vais supposer que le Code est
pas si différent que Sublime ou Atom et si dès le début je
avoir du mal à travailler avec ou montrer à quelqu'un de manière efficace ce qu'il doit faire
entre les fichiers pour faire fonctionner quelque chose, alors j'utiliserai quelque chose qui fonctionne
mieux pour mes besoins maintenant et regardez dans Code quelques versions plus tard
quand il est prêt.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@ tones411 Certaines personnes

_Je ne peux pas insister assez dessus_ mais à mon avis, la discussion ne devrait pas se limiter à ajouter des onglets et à l'appeler un jour, mais à obtenir le bon flux de travail et je l'ai dit plusieurs fois, ce qui signifie qu'il a besoin des bonnes options de personnalisation se sentir intégré et non aliéné et toujours optionnel! il en va de même pour les fichiers de travail.

Certaines personnes peuvent vouloir avoir quelque chose comme des tampons Vim et ne voudraient pas du tout avoir ni onglets ni fichiers de travail.

Peut-être que quelque chose comme les tampons Vim peut être utilisé comme surface pour VSCode où nous pouvons utiliser des commandes pour gérer les fichiers, puis jeter les bases de chaque flux de travail, qu'il s'agisse d'onglets, de fichiers de travail ou autre chose demain.

Bien dit. Cela s'est transformé en débat religieux. C'est évident de cela
long fil conducteur qu'il y a beaucoup de gens ici qui sont passionnés par le fait d'avoir
onglets et pensent qu'ils sont nécessaires / facilitent leur flux de travail. Il y a
d'autres qui ne croient pas que les onglets sont nécessaires et qu'ils constituent un obstacle.

Acceptons simplement de ne pas être d'accord, c'est bien. Tant que les onglets sont facultatifs
que ceux qui n'en veulent pas ne doivent pas les utiliser.

Je pense personnellement qu'ils sont utiles, mais je ne vais pas arrêter quelqu'un
d'utiliser des fichiers de travail si cela fonctionne pour eux. Ça ne marche pas pour moi.
Le vendredi 15 avril 2016 à 22 h 07, tones411 [email protected] a écrit:

Demander à ceux d'entre nous qui préfèrent les onglets de passer à aucun onglet est tout aussi bon que
demander à ceux qui ne préfèrent aucun onglet de passer aux onglets. Nous ne voulons pas tous les deux
passez à l'autre méthode.

Pouvons-nous nous arrêter maintenant avec le type de 'Mac vs Windows', 'Android vs IPhone'
débats sur la meilleure façon de procéder: «Tabs vs No Tabs»? Ils sont tous les deux bons
et différentes personnes ont leur propre préférence.

Je pense que la meilleure solution est d'ajouter des onglets comme préférence qui peuvent être
activé en option. Ensuite, les deux foules sont ravies.

Quelqu'un est-il contre les deux méthodes que vous pouvez activer ou
en fonction de vos préférences?

Je pense que cela se résume à ces deux options:

1) Ajoutez des onglets comme préférence. On pour ceux qui l'aiment et hors pour ceux qui
pas.

2) N'ajoutez pas du tout d'onglets, même si j'ai la possibilité de les désactiver.

Pourquoi voteriez-vous même pour l'option 2 lorsque vous avez la possibilité de les activer
de?
Le 15 avril 2016 à 19 h 32, "James McLaughlin" [email protected]
a écrit:

@Measuring https://github.com/Measuring Je suis d'accord et en désaccord avec vous.
Il y a des choses qui doivent innover, mais il faut d'abord se demander
sur le flux de travail pouvons-nous améliorer en supprimant les onglets. Eh bien pour moi,
chaque
l'éditeur unique que j'utilise pour le développement a une interface à onglets car il est
courant pour un développe de fonctionner entre 5 à 10 fichiers à la fois sans
se souvenir du nom exact des fichiers ni de l'ordre dans lequel ils sont ouverts
leur
Je dois donc demander, comment cette nouvelle interface l'a-t-elle amélioré? Comment
est
c'est innovant? Demandez d'abord comment l'utilisent-ils, puis demandez-vous comment puis-je
faire
cest mieux. Quant à la question des trois minutes, je vais supposer que le Code
est
pas si différent que Sublime ou Atom et si dès le début
je
avoir du mal à travailler avec ou montrer à quelqu'un de manière efficace ce qu'il doit faire
entre les fichiers pour faire fonctionner quelque chose, alors j'utiliserai quelque chose qui
travaux
mieux pour mes besoins maintenant et regardez dans Code quelques versions plus tard
quand il est prêt.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

Je suis ce fil depuis environ ~ mois depuis que je suis passé à Code en tant qu'éditeur principal et je suis continuellement ennuyé par le comportement de navigation dans les fichiers. J'ai passé du temps à essayer de m'habituer à la section Fichiers de travail, que vous admettez est plus ou moins une réflexion après coup de toute façon, et Ctrl + Tab et Ctrl + P. Je suis super content de Code et c'est facilement mon éditeur préféré, mais ces options de navigation dans les fichiers sont si mal conçues qu'il est difficile de comprendre comment elles ont été conçues en premier lieu.

La plupart d'entre eux ont été mentionnés, mais voici mes reproches:

La liste WF est essentiellement inutile, car la fermeture d'une fenêtre d'éditeur ne ferme pas réellement le fichier de WF. Je dois fermer un fichier _twice_, et utiliser la souris pour le faire (Ctrl + W _et_ fermer le fichier à partir du panneau WF). Si je voulais laisser le fichier ouvert, je n'aurais pas appuyé sur Ctrl + W - comment cela a-t-il un sens d'appuyer sur Ctrl + W et de laisser un fichier «ouvert» (visible dans WF). Oui, cela peut être réaffecté, mais je parle du comportement par défaut de WF).

Cliquer sur un fichier dans WF ou dans l'arborescence ouvre un fichier dans une fenêtre d'édition indésirable au moins la moitié du temps. Si vous avez un éditeur à deux panneaux avec un panneau de gauche actif, «ouvrir sur le côté» l'ouvre dans le panneau _droite_, pas dans un panneau _nouveau_, et avec 3 colonnes, il s'ouvrira toujours dans un panneau existant. Le problème ici est que «les choses ne restent pas là où je les ai placées». Je m'attends à dire à mon éditeur où je veux que les choses soient, pas à mon éditeur de décider où les choses doivent être basées sur l'état actuel de l'interface utilisateur, puis de les modifier à mesure que l'état de l'interface utilisateur change dans d'autres parties de l'application. Obtenir _back_ à un fichier précédemment ouvert est un tel PITA .

Un simple clic et un double-clic sur les fichiers ont un comportement _complètement différent_ avec _exactement la même_ interface utilisateur. Un simple clic ouvre temporairement l'aperçu du fichier (lorsque je ne veux pas le charger dans WF car il faudra alors deux fermetures pour s'en débarrasser plus tard), mais charger un éditeur de «prévisualisation» avec un autre fichier (inévitable avec l'implémentation actuelle comme mentionné ci-dessus) fera sauter l'arborescence des dossiers vers un nouvel emplacement, et le chargement du fichier "aperçu" précédent signifie que je dois à nouveau naviguer vers le dossier dans l'arborescence. Je ne veux même pas admettre combien de temps j'ai passé à naviguer vers le _exact même dossier_ 6 fois de suite à cause de ce comportement.

À mon avis, un simple ou double clic sur un fichier devrait me donner le _exact même comportement_, mais si vous voulez vraiment un simple clic "aperçu" qui n'apparaît pas dans WF / Ctrl + Tab, il devrait y avoir un _ marqueur d'interface utilisateur_ évident_ qui la fenêtre de l'éditeur active est un aperçu et disparaîtra lorsque vous la remplacerez.

L'arborescence de dossiers ne doit _pas_ accéder à l'emplacement de chaque fichier sur lequel je clique ou, lorsque je débogue, parcourir chaque dossier de mon dossier de bibliothèque. Si je voulais accéder à un dossier particulier, je voudrais y accéder, et une fois que j'aurai fait cela, je m'attends à ce qu'il le reste. Cela peut sembler peu pertinent dans le fil des onglets, mais c'est effectivement le cas.,

La seule raison pour laquelle ces comportements de panneau d'édition, de WF et de vue de dossier absolument ridicules existent est _parce qu'il n'y a pas d'onglets_. Si vous ajoutez des onglets (ancrés à un panneau particulier si les panneaux de l'éditeur sont divisés) et que vous utilisez par défaut le comportement normal de l'éditeur qui consiste à _toujours tout ouvrir dans un nouvel onglet_, aucun de ce comportement n'est nécessaire. Laissez-moi simplement décider comment je veux naviguer dans mon arbre et comment je veux empiler mes onglets, et arrêtez d'essayer de me montrer une «meilleure façon» (à moins que vous n'ayez en fait une meilleure façon - après environ 6 mois de travail quotidien, je peux dire avec une certitude absolue que la manière actuelle n'est pas meilleure pour moi).

Et pendant que vous y êtes, pour l'amour de Dieu, SVP laissez-moi voir les fichiers du même répertoire dans plus d'une fenêtre! Il existe une solution simple et élégante, que tous les autres logiciels basés sur des onglets ont depuis des années - faites glisser les onglets dans une nouvelle fenêtre - sérieusement, ce n'est pas révolutionnaire. Si vous voulez conserver le comportement «un dossier ne reçoit qu'une seule instance», alors faites flotter les panneaux dans une nouvelle fenêtre (qui est toujours contrôlée par / attachée à la fenêtre principale).

Vous avez fait un travail formidable avec cet éditeur et je continuerai à l'utiliser. Si nous pouvons voir:

  1. Onglets
  2. Désactiver WF
  3. Arrêter la navigation automatique dans l'arborescence des dossiers
  4. Ripoff des onglets dans le panneau d'édition flottant (qui partage le même comportement que les autres panneaux d'édition dans l'interface principale)

Ensuite, je pense que VS Code ira loin, loin, loin. Excellent éditeur, et je suis prêt à supporter les inconvénients pour profiter du reste, mais beaucoup, beaucoup d'autres n'attendent que ces quelques fonctionnalités de base.

J'aimerais aider avec les tests UI / UX ou tout ce que vous faites pour les commentaires / contributions des utilisateurs. Faites-moi savoir si je peux être utile.

Je vous remercie!

@anyong merci pour vos idées!

Pour le point 3, je ne sais pas si vous le savez, mais vous pouvez également le personnaliser actuellement avec:

"explorer.autoReveal": false

Je lie également workbench.files.action.showActiveFileInExplorer afin que je puisse accéder à un fichier aléatoire dans l'explorateur si nécessaire.

@Tyriar Je ne sais pas à quelle version vous faites référence, mais je suis à jour sur Insider et cette option ne fait encore rien.

: +1:

: +1:

@bpasero J'ai lu les premiers messages sur ce forum concernant les avantages / inconvénients des onglets. Je comprends également la position de l'équipe MSFT à ce sujet: l'équipe est unie sous le même style de codage et a développé le même ensemble de réflexes concernant ctrl+tab et / ou la section des fichiers de travail. C'est une bonne chose. Tous les membres de l'équipe ont un flux uniforme de faire les choses, en général. Cependant, nous ne faisons pas partie de cette équipe et nous ne souhaitons pas développer le même ensemble de réflexes. Nos réflexes existants devraient, idéalement, être accomplis, non forcés et remplacés. L'éditeur devrait aider l'utilisateur.

Nous devrons soit nous adapter à votre définition de l'UX, soit arrêter d'utiliser VSCode. Certains s'adapteront, d'autres non. Il s'agit de l'équilibre entre les bonnes et les mauvaises choses mises sur la table. Cela étant dit, je pense que l'équipe MSFT sous-estime grandement l'importance des onglets et surestime grandement les réflexes développés en interne.

L'équipe et les personnes en charge doivent vraiment prendre une décision simple: VS Code est-il une expérience d'interaction homme- machine

@Tyriar : J'ai essayé votre paramètre autoReveal dans v.1.0.0-insider et cela n'a rien fait pour moi non plus. L'explorateur saute toujours quand je ne le veux pas - le plus irritant, quand il défile complètement vers un endroit différent lorsque j'utilise go-to-definition et que cela ouvre un autre fichier.

C'est ce que j'ai mis dans mon fichier de préférences: "explorer.autoReveal": false,

@anyong @stephenmartindale vous avez raison, je ne savais pas à quel point ce paramètre était nouveau. Il devrait être disponible sur la prochaine version d'Insiders.

Bien dit @stephenmartindale. Sans onglets, tout ce que nous avons est notepad.exe avec sa propre version de Alt-Tab (qui, comme indiqué à plusieurs reprises ci-dessus, est cassée). J'ai essayé d'utiliser "Working Files" comme s'il s'agissait d'onglets latéraux, mais après une semaine, je suis à peu près prêt à revenir à Sublime et ce sont des problèmes, en particulier qu'il n'y a aucun moyen de faire en sorte que cette barre latérale soit toujours là non importe ce qui se passe dans l'application. Avec le nom «Visual Studio ...», je m'attendais au moins aux fonctionnalités de base de l'éditeur Visual Studio (onglets et possibilité de faire glisser ces onglets dans leurs propres fenêtres). Pourquoi ils auraient supprimé cette fonctionnalité est inexplicable. Peut-être que je reviendrai dans quelques mois pour voir s'ils sont assez loin pour mettre une balise pré-alpha sur une construction. Pour le moment, ce n'est rien de plus qu'une expérience d'interface utilisateur, la seule question est qu'elle a déjà échoué ou est-elle au bord de l'échec?

Comme la plupart des 259 commentaires précédents l'ont indiqué, j'aimerais beaucoup voir des onglets dans VS Code, similaires à leur fonctionnement dans Sublime Text. Moi aussi, je changerais volontiers s'il n'y avait pas cette fonctionnalité manquante. Aussi étrange que cela puisse paraître, j'ai besoin de la possibilité d'ouvrir au moins quatre documents dans la même fenêtre pour pouvoir basculer rapidement entre eux.

Oh, et si Microsoft ne veut pas que VS Code soit autant comparé à Sublime Text, alors ils n'auraient pas dû créer un produit qui lui ressemble et se comporte si similaire. Garder les onglets loin de l'interface graphique n'est pas un moyen de décourager les comparaisons avec Sublime Text; c'est un moyen de rendre ces comparaisons moins favorables pour Microsoft.

@SturmB Sublime n'est pas le seul éditeur qui existe et je ne pense pas qu'ils aient fait de VSCode un autre copieur Sublime, tout comme Atom n'est pas Sublime, mais tous les éditeurs partagent des fonctionnalités, ce qui est une bonne chose, c'est ainsi que vous avez le choix. !

VSCode n'agit pas du tout comme Sublime car ils sont très différents, VSCode vise à être le juste milieu entre un éditeur de code et un IDE alors que Sublime ne fait pas cette affirmation, par conséquent, VSCode a un public plus large de personnes, allant des personnes qui utilisent Vim pour Visual Studio.

L'ajout d'onglets n'est pas du tout le problème, les gens continuent à dire qu'ils doivent ajouter des onglets et je suis sûr qu'à présent ils comprennent que les onglets sont importants, mais le vrai problème est d'obtenir le bon design et de s'assurer que l'expérience est agréable pour tout le monde, ceux qui aiment les onglets et ceux qui les détestent.

Désormais, lorsque vous concevez une fonctionnalité, en particulier une fonctionnalité qui est au cœur de l'expérience de l'éditeur, vous ne pouvez pas simplement pirater quelques éléments et les assembler, puis revenir avec une annonce qui, après quelques jours, fera décevoir de nombreuses personnes! les bonnes choses prennent du temps! et ce n'est pas différent. :)

J'aime le concept des fichiers de travail. Les onglets ne s'adaptent pas bien lorsque de nombreux fichiers sont ouverts. Quoi qu'il arrive, gardez le contrôle des fichiers de travail!

@helmbold Je suis vraiment curieux - comment les utilisez-vous efficacement? J'ai essayé et je n'arrive pas à comprendre comment donner un sens au désordre qu'est WF. (De plus, quelque part dans ce numéro, l'équipe a déclaré que les fichiers de travail n'étaient vraiment qu'une réflexion après coup, pas une fonctionnalité prévue.)

@eyalsk :

le vrai problème est d'avoir le bon design et de s'assurer que l'expérience est agréable pour tout le monde, ceux qui aiment les onglets et ceux qui les détestent.

Presque tout le monde ici a dit espérer que les onglets seront contrôlés par un paramètre exactement pour cette raison. Cela étant dit, alors que certains logiciels lors des premières itérations d'onglets il y a des années n'étaient pas très agréables à utiliser, ces jours-ci, ils sont généralement assez bons. Code a Sublime, Atom et les non-éditeurs comme les navigateurs à rechercher pour créer des onglets «à droite».

Une fonctionnalité que j'aimerais voir que je n'ai vue dans aucun logiciel à onglets et qui, je pense, atténuerait certains problèmes avec "trop ​​d'onglets" est un moyen de sélectionner et de faire glisser plusieurs onglets dans une nouvelle fenêtre.

En fin de compte, les interfaces homme-ordinateur pour gérer des centaines de fichiers avec de longs noms similaires feront toujours défaut - ce n'est pas ainsi que nous sommes conçus pour fonctionner, c'est simplement comment nous sommes obligés de travailler à cause du état actuel du génie logiciel.

@anyong sure! l'ajout d'options n'est pas du tout un problème, je veux dire que le problème commence lorsque vous vous demandez quelles options sont redondantes et quelles options sont réellement utiles, les programmes qui ont été conçus avec des onglets à l'esprit dès le départ l'ont vraiment facile pour plusieurs raisons mais principalement parce que les onglets ne sont pas une réflexion après coup, aussi, il n'est pas possible de comparer un éditeur à un autre ou même à un autre programme qui a des onglets principalement parce que l'histoire de navigation est généralement différente d'un programme à l'autre, différents programmes visent à se concentrer sur différents des choses.

Ce n'est pas parce que Sublime / Atom ou un autre programme a des onglets et que cela fonctionne bien que cela ne signifie pas que vous pouvez prendre toutes les choses qui fonctionnent là-bas et les intégrer dans votre programme, ce n'est pas comme ça que les choses fonctionnent, en fait c'est comme ça que les choses peuvent échouer! c'est réussi là-bas parce que l'ensemble du paquet le fait réussir.

Désormais, l'ajout d'un nouveau type d'expérience utilisateur à l'éditeur vous oblige à réévaluer toute l'histoire de navigation, y compris les fonctionnalités existantes telles que les "fichiers de travail", en particulier lorsque vous avez des consommateurs existants où chaque personne s'attend à ce que cela fonctionne comme l'éditeur de son choix. et vous pouvez dire d'après les messages que beaucoup d'entre eux ont des normes élevées sur la façon dont cela devrait fonctionner. :)

: +1:

@bpasero , @ bgashler1 et moi avons commencé à travailler sur les conceptions UX pour améliorer la gestion des documents. Nous surveillons attentivement tous les commentaires sur ce problème et avons déjà parlé à une poignée d'entre vous pour obtenir plus de détails sur vos propres expériences et perspectives uniques.

Nous aimerions maintenant partager nos premières conceptions avec vous pour obtenir vos commentaires. Nous organiserons un hangout Google le jeudi 21 avril à 16h BST. Si vous souhaitez nous rejoindre, veuillez cliquer sur ce lien à ce moment-là: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

Ce sera notre première réunion publique de conception et nous avons hâte d'y être.

J'utilise exclusivement VSCode (provenant de WebStorm) et je n'ai pas manqué d'onglets. Au départ, je pensais que je le ferais, mais j'ai commencé à aimer davantage les fichiers de travail car je pouvais en voir plus dans moins d'espace et sans avoir à réfléchir à la façon d'organiser ou de regrouper les choses à l'écran. Maintenant, j'utilise principalement CTRL + TAB.

Je pense que si quelque chose d'onglets traditionnels devrait être une _extension_ officielle ou une _option_ opt-in. Personnellement, j'espère autre chose que des onglets pour améliorer l'expérience actuelle.

Ce que je trouve que CTRL + TAB manque, c'est le contexte du volet de l'éditeur actif. Si j'ai 2 volets d'éditeur ouverts côte à côte, je voudrais voir CTRL + TAB afficher l'historique des fichiers filtré vers les fichiers qui ont été ouverts dans le volet de l'éditeur actif plutôt que tous les fichiers ouverts dans l'application dans son ensemble ( bien que cela devrait encore exister). En outre, peut-être que cliquer quelque part sur / près du nom de fichier en haut d'un volet de l'éditeur pourrait afficher une liste déroulante des fichiers ouverts dans ce volet de l'éditeur (identique à CTRL + TAB).

Continuez votre bon travail.

Une autre suggestion ... Ce serait bien d'avoir une meilleure combinaison de touches par défaut pour afficher la liste des fichiers de travail lorsque la barre latérale est masquée. Je viens de découvrir que CTRL + K CTRL + P montre ce que je veux mais il est plus difficile de remonter que CTRL + TAB. Comme je l'ai suggéré avec CTRL + TAB, la fenêtre contextuelle des fichiers de travail pourrait bénéficier d'un contexte basé sur le volet de l'éditeur actif. Peut-être pourrait-il être trié de sorte que la liste des fichiers de travail qui ont été ouverts dans le volet de l'éditeur actif soit au-dessus du reste.

@RyanEwen Je suppose que vous n'êtes pas un utilisateur de raccourci avant? Parce que la plate-forme Intellij Idea a les mêmes raccourcis et est capable de placer les onglets n'importe où (haut, bas, gauche, droite, aucun). Lorsqu'il est placé à gauche / droite, il fonctionne de la même manière que les fichiers de travail dans VSCode. Ce serait formidable de faire des expériences. Revenez à WebStorm en utilisant la combinaison CTRL + TAB avec les onglets supérieurs pour voir si vous n'en avez pas besoin ou si vous êtes obligé de l'accepter comme seule solution de contournement. CTRL + E dans WebStorm également un fichier récent avec des fonctionnalités de filtrage (tapez pour rechercher).

Quiconque a dit non aux onglets, veuillez également mentionner si vous utilisiez la souris dans votre flux de travail.

: +1:

@KayLeung J'ai utilisé CTRL + E dans WebStorm, mais comme il y avait des onglets, je me permettrais de les chercher en utilisant la souris le plus souvent. J'ai récemment utilisé un éditeur à onglets (Koding.io) alors que je n'avais pas accès à VSCode et que je peux dire en toute confidentialité que je ne manque pas de configurer / organiser les onglets. Cela semble fastidieux comparé au simple fait d'avoir une histoire. Je me suis toujours retrouvé pris au piège de la façon dont je veux que les choses soient présentées et de prédire quels fichiers ouvrir plutôt que d'utiliser simplement l'éditeur et de passer d'un fichier à l'autre. C'est probablement en partie un problème "moi" plus qu'un problème d'onglet, je le sais. Un peu de TOC, je suppose.

J'étais un mouser quand j'utilisais WebStorm. J'ai utilisé des raccourcis clavier pour rechercher des fichiers récents et non ouverts ici et là, mais je me suis dirigé vers des onglets pour ce qui était déjà ouvert. Je ne sentais pas que je pouvais utiliser le clavier sur des onglets spécifiques facilement / intuitivement, et il y avait ce désir d'organiser les onglets qui m'a également amené à prendre ma souris à la fin. Le manque d'onglets m'a inconsciemment (et sans douleur - dans mon cas) m'a aidé à me glisser dans un flux de travail axé sur le clavier.

Je viens d'essayer Adobe Brackets et leur liste de fichiers de travail est divisée par volet. Si vous avez un volet gauche et un volet droit, il y a 2 listes de fichiers de travail («gauche» et «droite») dans la barre latérale au lieu d'une comme dans VSCode. Pas une mauvaise solution. Cela ne me dérangerait pas quelque chose comme ça (en plus de mon autre suggestion d'ajouter un contexte à CTRL + TAB basé sur le volet de l'éditeur actif).

@RyanEwen vous avez fait un très bon point. Je travaille toujours avec 2 volets pour toute instance ouverte de mon IDE. Je peux avoir 2 instances ouvertes sur 2 écrans, pour 4 volets ouverts. Je ne pouvais pas vraiment mettre le doigt dessus, mais vous l'avez fait. Avoir une seule liste quand il y a deux (ou plus?) Volets ouverts, est le problème avec l'implémentation actuelle des fichiers de travail qui l'a rendue inutilisable pour moi. Merci d'être précis ici.

Un rappel amical que nous (moi-même, @bpasero et @ bgashler1) partagerons nos dernières conceptions d'onglets et de fichiers de travail plus tard dans la journée à 16 heures, heure d'été britannique.

Rejoignez-nous sur ce lien à 16h BST: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme. Nous aimerions avoir vos commentaires.

Rappel pour tous ceux qui prévoyaient de rejoindre les hangouts - il est activé maintenant, alors cliquez sur le lien ci-dessus. Seulement ~ 5 personnes jusqu'à présent.

J'aurais vraiment aimé y être mais il est 11h et je suis au travail incapable de me joindre. Je suppose que quelqu'un aura des choses à partager par écrit par la suite? :RÉ

Bref aperçu:

  1. Les onglets et les fichiers de travail (renommés "éditeurs ouverts") se comportent exactement de la même manière, cela dépend simplement si vous voulez les visuels en haut (onglets) ou à gauche (éditeurs ouverts)
  2. Les onglets sont regroupés par panneau visuellement en haut, les éditeurs ouverts sont regroupés sous les en-têtes "Gauche", "Droite"
  3. Cliquez une fois sur un fichier pour ouvrir un onglet d'aperçu (ou "ouvrir l'éditeur"); double-cliquez sur le fichier, modifiez le fichier ou double-cliquez sur l'onglet lui-même pour persister
  4. Le débogueur ouvre tous les fichiers en tant que fichiers de prévisualisation à moins que vous ne persistiez le fichier en cours de débogage en prenant l'une des options ci-dessus
  5. Les onglets / éditeurs ouverts peuvent être déplacés entre les panneaux
  6. Les panneaux peuvent être déplacés pour déplacer tout le groupe d'onglets

Ça a l'air vraiment bien, et personnellement (du groupe très pro-tab si vous lisez mon message ci-dessus), je pense que je serai heureux de donner une chance aux nouveaux "Open Editors".

Réflexions de suivi pour les développeurs:

  1. Puisque le flux des onglets / éditeurs ouverts est exactement le même, il devrait être possible de faire quelque chose comme ceci: afficher les éditeurs ouverts lorsque l'explorateur est ouvert et afficher les onglets lorsque l'explorateur est fermé. Nous pouvons augmenter l'immobilier horizontal pour le code et maintenir l'accès aux onglets. En supposant qu'il existe un raccourci masquer / afficher les onglets, ce serait l'équivalent d'appuyer sur cela et CTRL + B en même temps - si cela fonctionne, cela devrait être une option dans les paramètres: autoShowTabsWhenExplorerClosed ou quelque chose. Si nous avons besoin de voir plus d'onglets, nous pouvons soit cliquer sur le chevron, soit simplement CTRL + B pour voir les onglets dans le panneau de gauche. Je ne sais pas si ce serait "déroutant" du tout, mais tant que les éditeurs ouverts et les onglets sont toujours exactement les mêmes et dans le même ordre, je peux imaginer que cela fonctionnerait très bien.
  2. Je pense que vous avez mentionné que les onglets précédemment fermés étaient disponibles dans l'une des vues CTRL + Tab + quelque chose, mais avez-vous pensé à un raccourci CTRL + SHIFT + T (annuler fermer l'onglet) qui rouvrirait simplement les onglets précédemment fermés (dans l'ordre dans lesquels ils ont été fermés)?

Je n'ai pu me joindre que pendant les 15 dernières minutes environ. Cela a-t-il été enregistré?

J'ai été déçu (mais pas surpris) de voir que les onglets sont susceptibles de
devenir la valeur par défaut. Un espoir que vous continuerez à préserver la légèreté
environnement de VS Code et pour explorer les flux de travail progressifs.

Merci,

James

Le jeudi 21 avril 2016 à 11h07, anyong [email protected] a écrit:

Rappel pour tous ceux qui prévoyaient de rejoindre les hangouts - c'est maintenant activé.
cliquez sur le lien ci-dessus. Seulement ~ 5 personnes jusqu'à présent.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

On dirait qu'il y avait de bonnes idées. J'ai hâte de voir cela en action.

FWIW (et si c'est toujours pertinent), je pense toujours qu'il vaut mieux ne pas avoir d'onglets dans l'interface utilisateur _par défaut_. Un bel en-tête d'éditeur propre sur lequel on peut cliquer pour voir une liste de fichiers si je n'ai pas la barre latérale visible, ou CTRL + TAB, c'est ce que j'espère vraiment :)

Merci à tous ceux qui ont pu y assister et nous faire part de leurs commentaires aujourd'hui. Nous avons pris des notes et suivons continuellement le problème de GitHub ici. Nous écoutons tout le monde.

@indiejames et @RyanEwen oui nous avons pris des notes, et nous publierons bientôt. Nous n'avons pas encore décidé avec certitude du comportement par défaut. Cependant, nous proposons une solution qui permettrait de choisir facilement si vous souhaitez ou non utiliser des fichiers de travail, des onglets ou les deux.

@ bgashler1 vous mentionnez que vous cherchez une solution qui permettra aux gens de choisir s'ils veulent les fichiers de travail, les onglets ou les deux, qu'en est-il de rien? est-ce une option? dépend du projet et de la langue sur lesquels je travaille, aucun ne peut être idéal pour les scripts comme PowerShell. :)

Merci à tous ceux qui ont pris le temps de se joindre à l'appel aujourd'hui et de fournir des commentaires, nous l'apprécions vraiment. @anyong a déjà fait un excellent travail en résumant ce que nous avons présenté mais j'ajouterai quelques détails supplémentaires ci-dessous et quelques captures d'écran.

Aspect visuel

Tout d'abord, cette image indique à quoi nous pensons que les onglets pourraient ressembler dans VS Code:
image2

Nous visons un look léger et non distrayant, quelque chose qui s'intègre bien avec le reste de VS Code. Nous n'avons pas encore défini à quoi cela ressemblerait dans un thème clair.

Comme vous pouvez le voir dans l'image ci-dessus, les onglets contiennent un bouton de fermeture à gauche du nom. Lorsque le fichier contient des modifications non enregistrées, nous affichons un indicateur sale à l'emplacement du bouton de fermeture.

Le survol d'un onglet affichera une info-bulle avec le chemin complet du fichier dans l'onglet.

Onglets d'aperçu

Pour distinguer clairement les onglets d'aperçu des onglets ouverts, nous mettons en italique le titre dans l'onglet comme dans le filaire suivant.
image1

Nous avons discuté des actions permettant de promouvoir un onglet d'aperçu en un onglet complètement ouvert:

  • Modifier le contenu dans l'onglet
  • Double-cliquez sur un fichier dans l'explorateur
  • Double-cliquez sur l'onglet d'aperçu dans le groupe d'onglets

Débordement

Les onglets s'ouvrent à droite de l'onglet actif. S'il n'y a pas assez de place pour afficher tous les onglets d'un groupe d'onglets, nous débordons les onglets. Nous ne tronquons pas le nom du fichier à l'intérieur de l'onglet pour faire plus de place pour plus d'onglets.

Nous montrons un chevron chaque fois qu'il y a un débordement. Cliquez sur ce chevron pour afficher une boîte de dialogue d'ouverture rapide qui répertorie tous les onglets du groupe d'onglets, permettant à l'utilisateur de trouver l'onglet qu'il souhaite afficher.

Cliquez sur un onglet actuellement en débordement pour afficher cet onglet.

Navigation dans les onglets

Les commandes suivantes permettent aux utilisateurs de naviguer entre les onglets:

  • Ctrl-Tab affiche une liste de tous les onglets à l'intérieur du groupe d'onglets actif:
    image3
  • Ctrl Alt Tab affiche une liste de tous les onglets dans tous les groupes d'onglets
    image4
  • L'ouverture rapide montre l'historique linéaire de tous les onglets
    image5

Fichiers de travail

Nous avons renommé les fichiers de travail pour ouvrir les éditeurs afin de mieux refléter ce que c'est vraiment.

La liste des éditeurs ouverts fonctionne de la même manière que les onglets. Nous les listons simplement dans l'explorateur plutôt que de les visualiser sous forme d'onglets.

Si un fichier est ouvert dans deux ou plusieurs groupes d'éditeurs, nous le montrons dans la liste des éditeurs ouverts:
image6

Tout éditeur ouvert par l'utilisateur apparaît dans la liste des éditeurs ouverts. Ainsi, par exemple, l'éditeur de différences apparaît comme ceci:
image7

Chaque groupe ne contient qu'un seul onglet d'aperçu.

Le chevron en haut à droite du groupe d'éditeurs actif indique s'il existe ou non une pile d'éditeurs.
image8

Dans ce cas, la fermeture d'un éditeur révélera l'éditeur en dessous dans la pile, plutôt que de fermer complètement l'éditeur.

La fermeture d'un éditeur (par exemple avec Ctrl-W) supprime également l'éditeur de la liste des éditeurs ouverts.

@stevencl

Pour distinguer clairement les onglets d'aperçu des onglets ouverts, nous mettons en italique le titre dans l'onglet comme dans le filaire suivant.

En plus de le mettre en italique, cela peut être génial s'il y avait une option pour atténuer les couleurs des onglets pour le rendre _ vraiment_ clair.

Comme je l'ai écrit auparavant, je voudrais également savoir s'il existe une option pour ne pas avoir d'onglets ou d'ouvrir des éditeurs, cela peut être un scénario utile pour les personnes qui font des scripts, par exemple PowerShell.

@eyalsk, il a été mentionné dans la discussion que les onglets et les éditeurs ouverts devraient être activés ou désactivés indépendamment pour l'un / l'autre / aucun.

@anyong merci! :)

Ctrl-Tab affiche une liste de tous les onglets à l'intérieur du groupe d'onglets actif:

Finalement! Onglets ou pas, c'est le comportement que j'attendais! Plus besoin de se perdre dans mon historique de fichiers.

La fermeture d'un éditeur (par exemple avec Ctrl-W) supprime également l'éditeur de la liste des éditeurs ouverts.

Génial! Nous espérons que cela semblera plus intuitif et aidera à nettoyer le désordre dans les fichiers de travail.

Maintenant, j'attendrai simplement que https://github.com/Microsoft/vscode/issues/5554 se ferme.

Hmm je ne sais pas si cela a été envisagé mais j'y ai pensé tout à l'heure, plusieurs moniteurs supposent! dans Visual Studio, je peux faire glisser un onglet vers un autre moniteur et créer une nouvelle fenêtre / vue d'onglet, est-ce que quelque chose comme cela est envisagé? J'imagine qu'il est possible d'y parvenir en créant un nouveau processus VSCode et en faisant glisser des onglets entre les processus via une communication inter-processus, il en va de même pour les éditeurs ouverts, juste une idée, :)

S'il vous plaît, s'il vous plaît, pouvez-vous rendre les "onglets de prévisualisation" facultatifs - c'est-à-dire avoir une option pour que quoi que ce soit soit auto-promu vers un onglet permanent et ne jamais faire disparaître des éléments. Je sais que vous discutez des moyens de distinguer visuellement les onglets qui sont temporaires, mais, franchement, cela ne fonctionnera pas pour les gens comme moi qui naviguent entre les fichiers si rapidement (en particulier avec Go-To-Definition et al.) Qu'ils n'ont pas le temps de inspectez visuellement l'onglet pour deviner comment il pourrait se comporter, je ne me souviens pas comment j'ai ouvert un fichier ou si je l'ai édité et je trouve vraiment déconcertant lorsque des fichiers disparaissent apparemment au hasard. (Je sais que ce n'est pas aléatoire, mais ça pourrait aussi bien l'être.)

Je m'enterre généralement dans des onglets ouverts jusqu'à ce que j'aie terminé une unité de travail, puis je les ferme tous en même temps que je m'engage.

Merci @eyalsk , oui, nous l'avons considéré. En fin de compte, nous aimerions pouvoir prendre en charge cela, mais le travail nécessaire pour partager le contexte entre plusieurs processus est assez important et il est donc peu probable que cela se produise pendant que nous travaillons sur le reste de l'UX de gestion de documents. C'est certainement quelque chose que nous voulons faire.

@stevencl Je serais heureux si le glissement ouvrait juste une nouvelle fenêtre vscode avec ce fichier ouvert (peut-être avec le même dossier ouvert aussi).

Merci @Tyriar , nous continuerons à étudier cela. S'il existe un moyen de le faire fonctionner correctement, nous serions ravis de pouvoir le faire.

@stevencl Je crains juste que cela demande encore plus de travail pour l'ajouter à l'avenir, alors _lorsque_ vous améliorerez l'infrastructure, assurez-vous de la conserver dans vos backlogs! ;)

onglets s'il vous plaît

Super de voir ça. J'adore la proposition légère et que vous trouvez un moyen de ne pas briser l'expérience des fichiers de travail.

Au plaisir de lui donner un tour. Merci pour l'écoute.

@stevencl Cela semble être le meilleur des deux mondes. Ça a l'air merveilleux! Les onglets apparaissent comme je l'aurais attendu afin de s'intégrer au reste de l'interface utilisateur, et il semble que j'obtiendrais exactement ce que je veux avec les modifications des fichiers de travail :)

Les éditeurs ouverts prendront-ils en charge plus de 2 groupes d'éditeurs? Je me demande simplement comment vous les nommez si c'est plus compliqué que Gauche et Droite.

Oui, cela serait toujours pris en charge.


De: Maxime Quandallemailto: [email protected]
Envoyé le 22/04/2016 23:09
À: Microsoft / vscodemailto: [email protected]
Cc: Steven Clarkemailto: [email protected]; Mentionmailto: [email protected]
Objet: Re: [Microsoft / vscode] Onglets appropriés pour les fichiers ouverts (# 224)

Le repositionnement des volets par glisser-déposer serait-il toujours possible avec la proposition @stevencl ?


Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

@stevencl Je pense que ce que vous avez décrit lors de la discussion il y a quelques jours est génial. C'est exactement ce que nous attendions tous en ce qui concerne les onglets. Quelques-uns des autres éditeurs que j'ai utilisés implémentent également des configurations de panneaux horizontales et verticales. Cela vous permet d'avoir deux fichiers ouverts côte à côte en haut et un ou deux ouverts en dessous. Bien que ce ne soit pas une fonctionnalité critique, je me retrouve souvent à manquer lors du développement d'applications Web frontales et d'applications mobiles. La raison en est que la plupart de ce sur quoi je travaille est MVC ou ses dérivations, donc avoir un modèle, une vue, un contrôleur et un fichier d'interface utilisateur (css, Js, etc.) ouverts en même temps est un énorme avantage. Est-il prévu d'inclure cela également? Atom le fait très bien, c'est le dernier éditeur que j'ai utilisé avant VSCode. Malheureusement, il manquait gravement dans d'autres domaines dans lesquels VSCode excelle, d'où ma seule utilisation de VSCode. Si ce n'est pas dans la version prévue avec les changements d'onglets et de gestion des documents, ce serait une grande amélioration future.

@ jayrosen1576 le fractionnement horizontal est capturé dans ce numéro https://github.com/Microsoft/vscode/issues/1749 , assurez-vous de: +1: pour montrer votre intérêt.

Bon travail les gars, les cadres en fil de fer semblent fonctionner très bien.

Salut @stevencl
Merci pour l'excellent travail et voici mes 2 centimes sur le bouton de fermeture à gauche.
Lorsqu'il y a beaucoup de fichiers ouverts et que les onglets sont réduits, le petit espace pour chaque onglet sera suffisant pour afficher le bouton de fermeture, ce qui facilitera la fermeture accidentelle de l'onglet au lieu de le sélectionner.

L'icône d'indicateur sale peut toujours rester à gauche car elle n'indique que l'état du fichier, mais déplacer le bouton de fermeture vers la droite nous permettra de reconnaître facilement le nom du fichier et empêchera toute action de fermeture accidentelle.

Les maquettes

@hsyn , j'ai

Les onglets s'ouvrent à droite de l'onglet actif. S'il n'y a pas assez de place pour afficher tous les onglets d'un groupe d'onglets, nous débordons les onglets. Nous ne tronquons pas le nom du fichier à l'intérieur de l'onglet pour faire plus de place pour plus d'onglets.

Je ne suis pas d'accord avec ça. Si l'écran est divisé en 2-3 colonnes, vous afficherez alors au maximum 1 à 2 onglets et déborderez le reste. S'il vous plaît, faites ce que font les navigateurs, nous les utilisons tous les jours et c'est intuitif et nous y sommes habitués. Je vous encourage à utiliser des modèles établis, dont certains évoluent depuis plus d'une décennie maintenant. N'allez pas à contre-courant.

Je ne suis pas d'accord avec ça. Si l'écran est divisé en 2-3 colonnes, vous afficherez alors au maximum 1 à 2 onglets et déborderez le reste. S'il vous plaît, faites ce que font les navigateurs, nous les utilisons tous les jours et c'est intuitif et nous y sommes habitués. Je vous encourage à utiliser des modèles établis, dont certains évoluent depuis plus d'une décennie maintenant. N'allez pas à contre-courant.

Certains navigateurs combinent des onglets réducteurs, puis les débordent au-delà d'un certain seuil. Firefox le fait; à peu près sûr que iOS Safari le fait (ou l'a fait) aussi.

Quand suffisamment d'onglets sont ouverts pour que vous puissiez à peine voir quelques lettres dans chacun d'eux (bien qu'en pratique je n'en ai normalement pas beaucoup ouvert), ce n'est pas particulièrement plus utilisable que le débordement.

@alexgorbatchev Je

Mais vous m'avez donné une idée pour les développeurs - je pense que le vrai problème ici est que, bien que nous sachions que nous ne pouvons pas utiliser 20 onglets lorsque tous les noms de fichiers sont cachés, au moins nous _ savons_ qu'il y a 20 onglets ouverts et cela nous fournit un certain sentiment de "je sais où sont mes fichiers si j'en ai besoin, ils n'ont pas simplement disparu." Tout ce qu'il faudrait pour résoudre ce problème est un indicateur montrant le _nombre_ des onglets actuellement masqués, l'indicateur pourrait simplement être un petit cercle au-dessus du chevron de débordement afin de ne pas prendre d'espace horizontal supplémentaire.

Merci tout le monde. Nous ne l'avons pas montré dans les maquettes, mais notre intention est que, lorsque cela est nécessaire, nous réduisons les onglets afin que seuls le nom du fichier et le bouton de fermeture soient visibles. Pour les raisons mentionnées par @anyong , nous ne pensons pas que nous voulons réduire au point que les noms de fichiers ne se distinguent pas les uns des autres. Nous pensons qu'il est probablement plus courant pour plusieurs onglets dans un éditeur de code d'avoir des noms similaires que pour les onglets de navigateur d'avoir des noms similaires (par exemple, il pourrait y avoir plusieurs noms de fichiers avec le même préfixe). Ainsi, nous pensons que la réduction des onglets dans un éditeur de code a des conséquences différentes de celles d'un navigateur.

Nous avons l'intention de montrer quand les onglets sont dans le contrôle de débordement avec le double chevron, mais placer un badge avec le nombre d'onglets débordants est également une idée intéressante. L'intention est-elle que le nombre indique simplement qu'il y a des onglets de débordement ou le nombre réel d'onglets de débordement est-il important?

Merci d'avoir clarifié @stevencl.

Un cas particulier à garder à l'esprit avec les noms de fichiers dans les onglets est plusieurs fichiers avec le même nom ouverts à partir de différents dossiers (index.js, README, LICENSE, package.json, etc.).

Je n'utiliserai probablement pas du tout d'onglets, mais je pense que cela vaut également la peine de pointer
que les navigateurs affichent généralement le favicon d'un site dans l'onglet qui
facilite l'identification même lorsque l'onglet rétrécit au-delà du point
c'est lisible. Les fichiers sources n'auraient pas de favicon pour les dissiper,
et, comme le souligne Steven, les noms de fichiers sont souvent similaires dans le code source.

Le jeu 28 avril 2016 à 12 h 16, Steven Clarke [email protected]
a écrit:

Merci tout le monde. Nous ne l'avons pas montré dans les maquettes mais notre intention est
qu'en cas de besoin, nous réduirons les onglets afin que seul le nom du
le fichier et le bouton de fermeture sont visibles. Pour les raisons @anyong
https://github.com/anyong mentionne, nous ne pensons pas que nous voulons réduire
le point où les noms de fichiers ne peuvent pas être distingués les uns des autres. Nous pensons
qu'il est probablement plus courant pour plusieurs onglets dans un éditeur de code d'avoir
des noms similaires à ceux des onglets du navigateur qui ont des noms similaires (par exemple,
il peut y avoir plusieurs noms de fichiers avec le même préfixe). Ainsi nous pensons que
la réduction des onglets dans un éditeur de code a des conséquences différentes de celles
navigateur.

Nous avons l'intention de montrer quand les onglets sont dans le contrôle de débordement avec le double
chevron mais placer un badge avec le nombre d'onglets débordants est un
idée intéressante aussi. L'intention est-elle que le nombre indique simplement que
il y a des onglets de débordement ou le nombre réel d'onglets de débordement est-il important?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

Merci @alexgorbatchev. Nous avons quelques idées pour montrer le chemin d'accès à un fichier pour pouvoir lever l'ambiguïté dans ces cas. Dans la maquette haute fidélité illustrée ci-dessus, par exemple, nous montrons le chemin d'accès au fichier sous le nom du fichier. Ce n'est qu'une idée cependant et peut ne pas fonctionner lorsque le chemin est long. Un autre serait de mettre le chemin dans la barre d'état. Beaucoup de choses à explorer ...

@stevencl

L'intention est-elle que le nombre indique simplement qu'il y a des onglets de débordement ou le nombre réel d'onglets de débordement est-il important?

Je pense que montrer le nombre réel d'onglets ouverts (mais cachés de la vue) résoudrait le problème. Essentiellement, les gens ont l'habitude de voir cela (enfin, pour moi au moins):

image

ils ont donc intuitivement une idée de "J'ai beaucoup d'onglets ouverts" ou "J'ai 2 ou 3 onglets ouverts"

Un badge indiquant "20" est beaucoup plus petit (pas de biens immobiliers supplémentaires, essentiellement) que de montrer 20 onglets rétrécis minuscules / inutiles, mais cela me permet quand même de savoir immédiatement que (a) les onglets cachés sont là et (b) exactement comment il y en a beaucoup.

Je ne suis que nouveau dans ce fil, mais mon 2p en tant qu'utilisateur complet de VS2015:

Au plaisir d'avoir des onglets dans vscode, car les fichiers de travail ne me conviennent jamais (bien que je vois maintenant que le fait d'appuyer sur ctrl-f4 ne supprime pas de cet ensemble comme je l'avais supposé).

Grand fan de l'onglet d'aperçu, heureux de le voir entrer.

Curieux de savoir pourquoi de nouveaux onglets s'ouvriront à droite de l'onglet actif. J'attends «parce que les navigateurs web» ou «parce que sublime» est la réponse, mais cela me semble contre-intuitif, surtout si les onglets débordent en se cachant par la gauche (dans le chevron à droite).

J'espère voir les menus du clic droit pour les onglets selon VS ... «Fermer tout» (pour le groupe) le plus important, pas de problème sur «Tout fermer sauf cela». Une boîte de sauvegarde de style VS pour tous les fichiers modifiés serait utile ici.

Le bouton de fermeture sur la gauche m'est étrange - je suppose que c'est une convention mac / linux - mais tant que le «clic du bouton du milieu» sur l'onglet ferme un éditeur (invite à enregistrer le cas échéant), alors pas de problème. Je peux voir pourquoi il est à gauche de fermer rapidement un tas de fichiers en succession, mais un clic du milieu est préférable pour cela de toute façon (mais peut-être pas pour les macs ou les ordinateurs portables sans molette de défilement?).

Le sélecteur de fichiers Chevron devrait permettre de taper pour accéder rapidement à un fichier. Non pas que je prévois personnellement d'ouvrir suffisamment de fichiers pour afficher le chevron, (et quand je le ferai, j'utiliserai sans aucun doute ctrl-p), mais cela arrive.

Numéro de chevron - est-ce un nombre d'onglets / fichiers / éditeurs _ cachés_ dans ce groupe, ou un nombre de _tous_ y compris les fichiers visibles? Je ne discuterais que des éléments cachés, surtout si vous affichez uniquement le chevron (et donc le nombre) lorsque quelque chose déborde de la ligne d'onglets.

Sur une note légèrement liée, si je ctrl-f4 (ou ctrl-w? Cela semble être la version non Windows de ctrl-f4 sauf si je me trompe), je m'attends à ce que si l'onglet disparaît, il ferme le éditeur et devrait demander à enregistrer / supprimer et le supprimer de ctrl-tab / ctrl-alt-tab / fichiers de travail ... Je peux voir qu'il y a un changement de raccourci clavier que je peux faire pour le moment pour activer cette fonctionnalité, mais j'ai du mal à voyez pourquoi dans une interface basée sur des onglets, l'existence d'un onglet n'est pas directement liée à l'ouverture - / actuelle du fichier / éditeur.

J'adore ce que vous faites tous sur vscode, ça a l'air incroyable ☺

J'ai essayé d'utiliser l'historique des fichiers comme suggéré, et après un mois, je n'ai plus besoin d'onglets. Dans VS, avoir un tas d'onglets ouverts est vraiment ennuyeux. Je déteste quand il y en a trop et être déplacé dans le petit menu déroulant des onglets cachés. Je pense que j'aimerais vraiment utiliser l'historique des fichiers dans VS maintenant aussi.

En ce qui concerne les fichiers de travail, je trouve vraiment ennuyeux que tout soit là-dedans. C'est ennuyeux au point de ne jamais l'ouvrir et de le garder fermé. La seule chose pour laquelle je trouve cela utile est de voir de nouveaux fichiers qui n'ont pas été enregistrés, ou tout fichier qui n'a pas été enregistré, je suppose. Cela devient rapidement trop grand pour que je m'en soucie même. Je ne sais pas comment cela pourrait être résolu. Peut-être n'afficher que les fichiers non enregistrés, mais cela aurait des effets secondaires étranges.

Quoi qu'il en soit, je suis un partisan de l'historique des fichiers maintenant. :)

Je pense que ce serait vraiment cool si nous pouvions ajouter la possibilité de faire des allers-retours dans l'historique en utilisant shift+cmd+[ et shift+cmd+] . ce sont les raccourcis par défaut pour naviguer dans les onglets dans d'autres applications et pouvoir les utiliser pour naviguer dans l'historique à la place, je pense que cela contribuerait grandement à faire de moi un croyant au moins

Edit: essentiellement réalisé cela en mettant en œuvre

  { "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" }

en tant que raccourcis clavier personnalisés

Pouvoir déchirer une section de code dans une nouvelle fenêtre serait également utile, je pense. Je ne sais pas si cette chose est même possible.

@JoshClose c'est tout à fait possible mais ils n'ont pas l'infrastructure de communication inter-processus pour l'éditeur lui-même, donc pour que deux instances communiquent et fassent tout ce dont elles ont besoin, elles ont d'abord un protocole.

... les onglets contiennent un bouton de fermeture à gauche du nom

Y a-t-il une raison spécifique pour enfreindre la convention? Lors de la lecture de LTR, l'information la plus importante est le nom du fichier, pas un bouton de fermeture. Le déplacer vers la droite faciliterait également le masquage par défaut des boutons de fermeture (et affichés au survol). À un stade ultérieur, les utilisateurs peuvent également souhaiter avoir des icônes de fichier à gauche du nom de fichier.

Nous avons discuté des actions pour promouvoir un onglet d'aperçu en un onglet complètement ouvert ...

Je pense que les deux premières options seraient probablement suffisantes. Un double-clic sur un onglet peut être utile pour d'autres choses à l'avenir.

Nous avons quelques idées pour montrer le chemin d'accès à un fichier pour pouvoir lever l'ambiguïté dans ces cas.

Qu'en est-il simplement d'afficher une info-bulle (avec le chemin relatif) lors du survol d'un onglet? Cela rendrait le design moins encombré et les onglets n'auraient pas besoin d'être aussi hauts.

Nous montrons un chevron chaque fois qu'il y a un débordement ...

Firefox gère bien le débordement d'onglets - il a une largeur d'onglet maximale, des boutons de défilement gauche / droite, un menu déroulant répertoriant tous les onglets (avec les onglets actuellement visibles marqués), etc.

Ce serait vraiment bien si les boutons de fermeture des onglets correspondaient aux conventions de la plate-forme: à gauche sous OS X, à droite sous Windows.

Après avoir utilisé VSCode pendant un certain temps maintenant, je pense que le mode _Working Files_ a beaucoup évolué sur moi!

Voici quelques raisons:

  1. Bien que cela semble contre-intuitif, la fermeture d'un fichier que je n'utilise pas (ctrl-w) ne le supprime pas des fichiers de travail. C'est très bien car je me retrouve souvent à rouvrir des fichiers récemment fermés (dans un projet React) lorsque je travaille avec des fichiers associés (ou des classes enfants). Ainsi, quand je sens que je devrais fermer un fichier, cela ne correspond pas un à un au moment où je devrais l'avoir fermé.
  2. J'aime le Force-Close explicite, qui est offert par le workbench.files.action.closeFile .
  3. J'ai remappé workbench.files.action.closeFile en Ctrl + k Ctrl + w car cela nécessite (légèrement) moins d'effort que Ctrl + kw ,
  4. Je peux voir le nom complet du fichier et le chemin dans la barre supérieure de l'éditeur -> Ceci est très important dans les projets profondément imbriqués (comme moi) qui ont des fichiers avec des noms similaires ou identiques ( index.js ?) Et seulement La façon de se différencier est par le chemin.
  5. Moins de bruit d'onglets = Zen!

Donc, d'une certaine manière, j'essaie de dire que s'il vous plaît, ne supprimez pas le flux actuel si vous introduisez le truc des onglets.

@kumarharsh pourquoi auraient-ils supprimer cela? si quoi que ce soit, ils l'amélioreront probablement pour vous! :)

Si l'indicateur sale remplace l'icône CLOSE, comment pourrons-nous fermer le fichier si nous ne voulons pas enregistrer nos modifications? Est-ce que ctrl-w sera toujours disponible?

L'indicateur sale ne pourrait-il pas simplement se transformer en bouton de fermeture en survol?
C'est une solution assez courante ...

Le mercredi 4 mai 2016 à 23 h 28, rojorojo [email protected] a écrit:

Si l'indicateur sale remplace l'icône CLOSE, comment pourrons-nous
fermer le fichier si nous ne voulons pas enregistrer nos modifications? Est-ce que ctrl-w sera toujours
disponible?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

@rojorojo nous faisons ce que @anyong a également suggéré, donc vous n'aurez aucun problème. Et oui, Ctrl + W sera toujours disponible.

Merci pour tous les commentaires.

Nous menons une étude UX sur nos dernières créations à la fin de ce mois. Si vous avez une heure le 25 ou 26 mai et souhaitez participer à l'étude, veuillez vous inscrire ici: https://calendly.com/stevencl/vs-code-docmgmt/

Malheureusement, je ne peux proposer que des heures pendant la journée (heure d'été britannique) et je ne peux pas organiser de sessions le soir.

Nous espérons avoir des éléments fonctionnels que vous pourrez essayer, ainsi que des wireframes de conception que nous n'avons pas encore montrés.

Attendez, j'adore le comportement actuel de l'interface utilisateur, y aura-t-il une configuration?

Il y a trois semaines, je voulais vraiment des onglets. J'ai même retardé le passage à VSC pendant un certain temps car il n'avait pas d'onglets. Maintenant que j'ai passé quelques semaines à utiliser VSC, je ne veux même plus d'onglets. À ce stade, je pense qu'ils me gêneraient.

J'espère que lorsque cela sera construit, il sera facultatif afin que ceux d'entre nous qui le souhaitent puissent continuer dans l'environnement actuel.

En tant que personne qui aime vraiment les onglets verticaux (ils s'adaptent beaucoup mieux et fonctionnent mieux sur les écrans larges), je me demande: pourquoi avez-vous besoin à la fois d'onglets et d '«éditeurs ouverts». Si ce dernier est essentiellement des «fichiers de travail» avec un comportement d'onglet, alors c'est tout ce dont j'ai besoin / envie.

Je souhaite ajouter mon vote pour m'assurer que les onglets sont facultatifs. Je n'aime vraiment pas les onglets de l'éditeur et préfère de loin le panneau sur le côté gauche de la fenêtre. Je comprends les ajouter pour les personnes qui les veulent, mais s'il vous plaît, ne nous les forcez pas. Ne pas les avoir est l'une des choses que j'aime dans cet éditeur.

Mes deux cents: je ne veux jamais fermer les boutons; pour moi, ils sont un gaspillage de biens immobiliers qui provoquent parfois de la frustration (clic accidentel). Il est beaucoup plus difficile de faire un clic central accidentellement que de cliquer accidentellement 1px trop à gauche.

Je pense aussi que les indicateurs sales sont un gaspillage de biens immobiliers. Dans Sublime Text, je configure "dirty" pour simplement changer la couleur de police de l'onglet. Dans le passé, je l'ai également mis en italique, mais il semble que vous ayez prévu de mettre en italique les aperçus.

Le côté gauche de la bordure est trop large

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

Les gens, je comprends que c'est un long fil de discussion, donc vous n'avez probablement pas tout lu, mais veuillez lire les messages ici . Les onglets seront facultatifs, les développeurs sont déjà très, très conscients des points que vous soulevez.

Affiches potentielles: veuillez parcourir le fil de discussion pour voir si vos problèmes sont déjà résolus - chaque fois que vous postez, une centaine de personnes reçoivent des e-mails avec votre: +1: Merci

@anyong Cependant, "Ouvrir l'éditeur" sépare la liste de fichiers de travail existante en deux si vous ouvrez deux colonnes. J'adore l'idée qu'il n'y a qu'un seul «fichiers de travail» pour toutes les colonnes de l'éditeur.
Veuillez le rendre facultatif non plus.

@ be5invis La seule différence est qu'il existe un séparateur visuel. Vous pouvez toujours faire glisser les fichiers et les ouvrir dans n'importe quel éditeur de votre choix.

@anyong Puis-je le cacher? Et si je choisis de masquer le "séparateur" et Ctrl-Tab dans une colonne de l'éditeur, puis-je basculer vers un fichier ouvert dans l'autre colonne? Ce que les escrocs veulent, c'est maintenir complètement le comportement existant.

@ be5invis du commentaire

Ctrl Alt Tab affiche une liste de tous les onglets dans tous les groupes d'onglets

Donc, oui, vous pouvez toujours définir la liaison de touches pour conserver le comportement actuel Ctrl + Tab si vous le souhaitez.

@anyong C'est bien.
Mais quand même, puis-je masquer l'indicateur «gauche / droite» et faire en sorte que la liste ressemble à une unité?

Ce serait une question pour @stevencl

Yay! J'espère que nous aurons bientôt des onglets!

Bonnes nouvelles .. nous obtenons des onglets .. Mais nous ne voulons pas perdre le dossier «Working Files». Le garder avec les onglets?

Impressionnant! Groupes d'onglets

@ be5invis Vous avez raison, nous avons l'intention d'afficher plusieurs groupes d'éditeurs dans la liste des éditeurs ouverts une fois que vous avez scindé l'éditeur. Mais vous n'avez pas besoin de le faire pour pouvoir travailler avec plusieurs fichiers. Vous diviseriez l'éditeur pour afficher plusieurs fichiers à la fois. Si vous ne gardez qu'un seul éditeur visible à tout moment, vous pouvez toujours ouvrir plusieurs fichiers. Par exemple, dans cette capture d'écran
image
J'ai deux fichiers ouverts, mais je n'en vois qu'un car je n'ai pas divisé l'éditeur. La liste des éditeurs ouverts montre à la fois les fichiers et je peux interagir avec eux là-bas ou via le contrôle de débordement en haut à droite. (Et notez qu'il n'y a pas d'onglets affichés ici - c'est l'option sans onglets.)

La raison pour laquelle nous avons fait cela est qu'il existe un risque de confusion lors de la gestion d'un fichier ouvert dans deux éditeurs dans la configuration actuelle des fichiers de travail. Par exemple, dans la capture d'écran ci-dessous à partir du produit actuel, que doit-il se passer lorsque je ferme le fichier app.js dans la liste des fichiers de travail. Les deux éditeurs devraient-ils fermer ou juste l'un d'entre eux? Et si juste l'un d'entre eux, lequel?

image

Nous voulons éviter toute ambiguïté et incertitude, c'est pourquoi nous avons choisi d'être plus explicites sur les fichiers ouverts dans chaque groupe d'éditeurs.

C'est aussi pourquoi nous avons renommé les fichiers de travail pour ouvrir les éditeurs car nous pensons que cela reflète mieux le nouveau comportement.

L'option Aller à la définition (F12) doit être améliorée (même la définition est dans une autre page avec dans le projet)) comme du texte sublime? Je suis confronté à ce problème depuis longtemps depuis que j'installe le code VS? Une aide à ce sujet?

@ vinod-a-ext - veuillez ouvrir un nouveau numéro décrivant le problème que vous rencontrez avec Go To Definition.

@stevencl
Aller au problème de définition dans VS Code
https://github.com/Microsoft/vscode/issues/6238

@stevencl Mon avis est que vous pouvez masquer les étiquettes dans «l'éditeur ouvert», et simplement tracer une ligne pour représenter différents panneaux. Une fois qu'un panneau est fermé, deux listes peuvent être fusionnées naturellement.

Merci pour la suggestion, nous explorerons certainement différents traitements visuels pour cela.

Date: mar 10 mai 2016 04:06:34 -0700
De: [email protected]
À: [email protected]
CC: [email protected]; [email protected]
Objet: Re: [Microsoft / vscode] Onglets appropriés pour les fichiers ouverts (# 224)

@stevencl Mon avis est que vous pouvez masquer les étiquettes dans «l'éditeur ouvert», et simplement tracer une ligne pour représenter différents panneaux. Une fois qu'un panneau est fermé, deux listes peuvent être fusionnées naturellement.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

Je suis curieux de savoir quel programme avez-vous utilisé pour générer les maquettes, comme celle-ci

Nous avons utilisé PowerPoint pour ces maquettes. Notre intention était de nous concentrer sur le flux d'interaction, pas sur la conception visuelle, de sorte que les outils de PowerPoint fonctionnent correctement pour ce niveau de détail. Faire des choses dans PowerPoint nous permet également d'enchaîner facilement une séquence d'écrans pour avoir une meilleure idée du flux.

Date: mar 10 mai 2016 05:03:55 -0700
De: [email protected]
À: [email protected]
CC: [email protected]; [email protected]
Objet: Re: [Microsoft / vscode] Onglets appropriés pour les fichiers ouverts (# 224)

Je suis curieux de savoir quel programme avez-vous utilisé pour générer les maquettes, comme celle-ci

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

Je suis juste venu ici après avoir vu les notes de publication d'avril. Fil ouvert depuis longtemps - mais je suis +1 pour le design original - c'est à dire pas d'onglets. Au début, cela me dérangeait - mais ensuite j'ai appris à apprécier et à comprendre la philosophie derrière cela ... Maintenant, quand je pense à Atom et à l'onglet spam ... je frissonne. Tout cela mis à part - j'adore l'engagement et les commentaires réfléchis et les commentaires des développeurs.

J'ai hâte d'essayer ça. Une chose que j'aimerais voir est la combinaison de plusieurs fichiers liés dans un seul onglet (similaire à ce plugin VS )

Ce serait vraiment utile pour rester organisé dans le développement Angular 2, où vous avez généralement des fichiers associés:

  • widget.component.css
  • widget.component.html
  • widget.component.ts
  • widget.component.spec.ts

D'accord avec @lucidtech, nous avons utilisé le dossier «Working Files».

Je suis d'accord avec @coreh pour

Mes deux cents: Une des raisons pour lesquelles j'aime le code sur Atom, Sublime, ou n'importe lequel des autres éditeurs hipster, c'est qu'il n'essaie pas de klaxonner dans le concept d '«onglet» du navigateur Web. Les IDE traditionnels tels que Visual Studio, IDEA et Eclipse le font tous également. Le code, d'un autre côté, a une approche "frames and buffers", semblable à ce que vous trouverez dans Emacs (et Vim aussi, je crois).

Inévitablement, dans n'importe quel éditeur basé sur des onglets, je me trouve obligé de travailler avec des résultats dans les cadres de mon éditeur qui sont horriblement spammés avec des onglets pour lesquels les porte-documents sont si petits qu'ils sont illisibles. De plus, lorsque j'utilise l'équivalent d'un tel éditeur pour Ctrl / ⌘-PI, je finis par me déformer vers une autre image comme un artefact de l'image que je regardais lorsque j'ai navigué pour la première fois vers le fichier. Afin d'afficher le même fichier dans une autre image, vous devez effectuer une opération maladroite de «tabulation fractionnée» qui a également souvent tendance à être associée à la division des images dans beaucoup de ces éditeurs. _Tabs couplent étroitement l'état de la mémoire tampon du fichier avec une image donnée sur l'écran.

Si vous voulez excuser l'attrait émotionnel, veuillez _s'il vous plaît_ ne pas transformer VS Code en un autre éditeur à onglets.

Je pense que, d'un point de vue UX, plutôt que d'implémenter aveuglément des onglets pour correspondre au comportement d'Atom ou de tout autre éditeur, il serait instructif de comprendre _pourquoi_ les gens veulent des onglets (autre qu'une simple familiarité confortable) et de voir si une solution plus innovante pour leurs besoins sont possibles. Je suis tout à fait d'accord que le régime actuel de l'espace de travail peut continuer d'évoluer: comme quelqu'un d'autre l'a mentionné, l'ouverture d'une fenêtre séparée dans le même projet (équivalent à «ripout» basé sur des onglets) afin de mieux tirer parti des écrans multi-têtes me vient à l'esprit!

edit: très triste d'avoir manqué l'appel il y a 19 jours. J'aurais rejoint si je l'avais su. Seulement découvert dans les notes de version de 1.1.0. :(

Les onglets sont un must pour moi et une autre suggestion pour, par exemple, les onglets groupés angular 2.0 pour les fichiers associés est également une excellente idée. Si la fonctionnalité est configurable, ceux dont les préférences diffèrent seront également satisfaits. Quand pouvons-nous essayer !!! ???

@orospakr , vous pouvez désactiver les onglets dans Sublime via une option de menu. Juste FYI.

@orospakr

il serait instructif de comprendre pourquoi les gens veulent des onglets (autres que juste une familiarité confortable) et de voir si une solution plus innovante à leurs besoins est possible.

Il y a une tonne de commentaires sur les raisons pour lesquelles les gens veulent des onglets en plus de la familiarité, sans oublier que si c'est familier et que les gens sont à l'aise avec cela, cela n'a pas de sens de faire preuve de créativité et d'innover quelque chose là où il y a déjà quelque chose qui fonctionne.

Ils ont essayé d'innover avec les "fichiers de travail" et un groupe a aimé, l'autre n'a pas aimé et nous voilà aujourd'hui en train de demander des onglets! Je ne pense pas que vous souhaitiez que le même syndrome se reproduise ...

La bonne façon de le faire est d'obtenir d'abord l'expérience que les gens recherchent, puis de disposer de fonctionnalités supplémentaires, d'innovation ou d'expériences lors des versions alpha et / ou en option.

Dans ce cas d'onglets / "éditeurs ouverts" ou demain autre chose, ils l'ont rendu facultatif et c'est ainsi que les gens devraient avoir la possibilité d'accepter l'expérience ou de s'en désabonner.

Je sais que je suis un peu en retard au jeu ici, mais en ce qui concerne cette section:

Nous avons discuté des actions permettant de promouvoir un onglet d'aperçu en un onglet complètement ouvert:

Modifier le contenu dans l'onglet
Double-cliquez sur un fichier dans l'explorateur
Double-cliquez sur l'onglet d'aperçu dans le groupe d'onglets

Je souhaite que "Ajouter un signet" soit inclus dans la liste ci-dessus.
Je trouve extrêmement frustrant d'ajouter un signet à un gros fichier, puis de cliquer par inadvertance sur un autre fichier, fermant le fichier de travail.

Il est très peu probable que j'aie ajouté un signet à un fichier que j'ai l'intention de fermer immédiatement.

J'ai regardé autant de commentaires que possible, à la recherche de mots-clés et je n'ai pas trouvé cela mentionné.

en ce qui concerne les onglets, premièrement, _merci! _ leur absence est l'une des seules choses que je n'aime pas dans VS Code.

J'aimerais que la navigation entre les onglets soit personnalisable; par exemple, j'aime la façon dont iTerm bascule entre les onglets en appuyant sur cmd + left , et j'aimerais beaucoup le faire aussi dans mon éditeur.

merci pour un super éditeur <3

Les onglets sont un must pour moi ... Revenir à Sublime jusqu'à ce que vous ayez des onglets. PS Je suis très déçu de votre attitude; Vous semblez n'avoir aucun sens de l'UX, mais prétendez que cela a été fait pour améliorer l'UX. Quels sont vos personnages? Où sont vos entretiens utilisateurs? Prouve le.

@asadighi avez-vous même lu les commentaires avant de poster? L'équipe a réalisé des entretiens approfondis et en mène d'autres pour obtenir les bons onglets. Ils sont incroyablement réactifs à la communauté et produisent un excellent éditeur (gratuit). Bonne chance en attendant la prochaine version de Sublime.

Vos commentaires précédents révèlent votre partialité. Mon objection porte sur l'attitude qu'ils ont eue dès le départ. Les entretiens avec les utilisateurs doivent avoir lieu AVANT que les gens commencent à dénigrer le produit pour une telle faille. Assez intéressant, vous pouvez voir l'hésitation à investir pour corriger cette faille au nom d'une meilleure UX. Ce numéro est ouvert depuis novembre et pendant une bonne partie de ce temps, la plupart des réponses correspondent au fait que nous savons mieux que vous comment vous devez faire votre travail.

@asadighi Tout est dans votre tête et vos absurdités apparaissent dans vos commentaires, arrêtez.

@muellerkyle : +1: vous devez créer un problème avec l'extension de signet que vous utilisez.

J'attends avec impatience cette fonctionnalité

+1!

Tous les jours, je bascule entre Eclipse, PhpStorm, Notepad ++ et VSCode. Devinez quoi, CTRL+W me rend fou.

Je suis en retard à cette fête, mais les onglets seront-ils facultatifs? J'avais l'habitude de penser que je les ai manqués, mais maintenant je ne le fais pas. Juste curieux de savoir s'il y aura un moyen de les cacher. Pas de haine envers les onglets et les personnes qui souhaitent les utiliser, pensez simplement que je préférerais une bascule pour afficher / masquer. Tout cela continue votre excellent travail. J'adore vscode.

@jamesmenera oui, ça va être optionnel mais aussi les fichiers de travail (éditeurs ouverts).

En passant, pourriez-vous divulguer quel programme vous avez utilisé pour créer ces maquettes?

@ciel , @stevencl a écrit qu'ils utilisaient PowerPoint pour cela.

Personnellement, j'adore WireframeSketcher pour le faire, mais PowerPoint peut aussi fonctionner. :)

Tout comme @jamesmenera l'a mentionné, les onglets et la barre latérale me manquent vraiment, mais je peux voir que beaucoup de gens aiment l'approche Working Files, elle devrait donc être facultative.

@ kadza93 les onglets et les fichiers de travail seront facultatifs ... Je me demande combien de fois je vais l'écrire.

Il est vraiment facile de faire une recherche et de chercher le mot "facultatif", ça va vous prendre moins de temps pour le trouver que pour écrire un article à ce sujet!

@eyalsk je me demande pourquoi la flamme! Je suis ici pour exprimer mon besoin et pour autant que je puisse voir le besoin de beaucoup d'onglets, donc en soutenant ce que les autres ont dit et en acceptant, je fais quelque chose de mal? Au fait, merci pour le conseil sur la fonctionnalité de recherche, je devrais l'utiliser davantage sur de longs fils où je veux exprimer mon opinion et si quelqu'un a déjà exprimé un message similaire au mien, je l'ignorerai simplement.

C'était seulement 3 de votre post ...

Suite à ce fil, il me semble qu'il y a déjà des décisions prises sur les onglets pour une prochaine version (les onglets étant facultatifs, où les icônes s'afficheront, les combinaisons de touches, etc.). Si je ne me trompe pas, existe-t-il une liste de ces décisions auxquelles les gens peuvent être renvoyés?

@jtlowe, il n'y a pas de moyen facile de le rendre évident comme des commentaires épinglés sur GitHub. Les gens font de nouveaux commentaires et cela enterre les choses importantes. GitHub effectue également le pliage des commentaires lorsqu'il y a trop de commentaires, ce qui rend la recherche dans la page plus difficile.

Peut-être que les administrateurs peuvent mettre une bannière "ÉTAT ACTUEL: EN DÉVELOPPEMENT" en haut de la page du problème (sous le corps du problème du PO)?

Cela devrait être une fonctionnalité appropriée dans github --- quelque chose comme le texte alternatif suggère ici: https://xkcd.com/979/

@ kadza93 Je ne t'ai pas

Je suis ici pour exprimer mon besoin et pour autant que je puisse voir le besoin de beaucoup d'onglets, donc en soutenant ce que les autres ont dit et en acceptant, je fais quelque chose de mal?

Non, vous n'avez rien fait de mal mais vous n'avez rien écrit d'utile non plus, la fonction émoticônes / réaction existe spécifiquement pour cette raison.

Au fait, merci pour le conseil sur la fonctionnalité de recherche, je devrais l'utiliser davantage sur de longs fils où je veux exprimer mon opinion et si quelqu'un a déjà exprimé un message similaire au mien, je l'ignorerai simplement.

Ouais ... tu as beaucoup de sens, je veux dire exprimer une opinion sur quelque chose qui a été confirmé! et tu n'as même pas eu besoin de le chercher parce que j'ai répondu à la même personne que tu avais abandonné.

En général, il est logique de rechercher des mots communs probables dans un long article.

Les développeurs devraient simplement ouvrir un nouveau problème avec la FAQ et les détails tirés de
les points les plus courants de ce fil et fermez ce problème. Personnes
abonnés à ce problème reçoivent des dizaines d'e-mails chaque jour pour le
mêmes commentaires "thumbs up" / "thumbs down".
Le 18 mai 2016 à 01h51, "Kumar Harsh" [email protected] a écrit:

Les administrateurs peuvent peut-être mettre une bannière "ÉTAT ACTUEL: EN DÉVELOPPEMENT" sur
en haut de la page des problèmes (sous le corps de la question du PO)?

Cela devrait être une fonctionnalité appropriée dans github --- quelque chose comme le texte alternatif
suggère ici: https://xkcd.com/979/

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

@anyong ouais je suis complètement d'accord! il n'y a rien à discuter et une fois que tabs et open editors sont en ligne, ils devraient créer deux problèmes distincts pour obtenir des commentaires sur ces fonctionnalités.

@eyalsk, nous essayons toujours de gérer les mises à jour sur les problèmes créés par la communauté. Il existe de nombreuses façons de le faire, mais elles sont toutes mauvaises sans une fonction de commentaire épinglé sur GitHub. Le problème du terminal intégré https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854 a fonctionné jusqu'à présent avec une grosse mise à jour au milieu du fil, je suppose que cela a à voir avec moins de besoin de discussion donc il n'a pas été enterré.

@Tyriar Eh bien, vous pouvez référencer des articles, alors ne pouvez-vous pas simplement créer de nouveaux articles et faire référence aux anciens en les fermant? Je pense que c'est ainsi que les gars qui travaillent sur Roslyn le font, puis ils ont un article qui résume toutes les fonctionnalités pour les versions à venir, mais néanmoins je suis d'accord avec vous, les commentaires épinglés peuvent être extrêmement utiles.

Nous avons travaillé sur la mise en œuvre des conceptions pour les onglets et les groupes d'éditeurs dans ce jalon et continuerons de le faire au prochain jalon.

Merci à tous ceux qui ont participé à l'étude UX ces derniers jours. Nous avons reçu d'excellents commentaires de votre part qui nous ont aidés à améliorer l'expérience:

  • Refonte de l'icône de débordement
  • Fournit un paramètre pour choisir si les fichiers à ouverture rapide sont épinglés ou prévisualisés
  • Ajouter une commande pour transformer un fichier prévisualisé en fichier épinglé

Désolé, si j'ai manqué cela, mais comment activer les onglets? Sont-ils disponibles dans la dernière version d'initié, comme je l'ai, mais aucune trace d'onglets là-bas. Je vois aussi toujours des 'fichiers de travail' dans l'explorateur, alors qu'il semble qu'il devrait être remplacé par 'Opened Editors' comme indiqué dans # 6536.

@lllopo ils ne sont pas encore disponibles. Les piles / éditeurs ouverts ont été fusionnés pour la v1.3.0 et seront disponibles dans Insiders la semaine prochaine lorsque les versions quotidiennes seront disponibles.

+1

+1

👎

Que se passe-t-il ici, pourquoi refusez-vous de nous donner la possibilité d'utiliser les onglets? 😕
Tant de gens aiment les onglets dont moi, donnez-nous la putain d'option PERIOD!

@aminroosta Sérieusement ... tu ne peux pas lire? es-tu aveugle?

Ce qui est drôle, c'est que vous demandez ce qui se passe ici ... et puis continuez et supposez qu'ils le refusent ou, selon vos propres mots, "résistent" alors qu'en fait, ils ont confirmé que des onglets arrivent et travaillent à sa mise en œuvre!

Certaines personnes dans ce monde! incroyable!

@eyalsk
J'ai passé 25 minutes à lire les 20 à 30 premiers commentaires.
Je me suis fatigué et j'ai laissé un commentaire qui semble maintenant être une erreur de ma part.

Désolé pour ça.

On ne peut pas reprocher à Microsoft R&D d'essayer d'innover. Le système d'onglets a des inconvénients.

La conception de l'interface utilisateur est comme toute forme de conception. 90% font ce que l'utilisateur attend, 10% font de nouvelles choses, essayent de créer un nouveau système révolutionnaire et convivial.

tout système convivial considéré comme indispensable dans le nouvel éditeur de texte d'aujourd'hui a été expérimenté et controversé auparavant.

@aminroosta Je vais vous donner un conseil, lorsque vous lisez un long article, lisez le message original, puis pour obtenir les dernières mises à jour, passez environ une minute à faire défiler de bas en haut.

C'est une bonne suggestion car c'est un flux TRÈS long.

Le dim 5 juin 2016 à 10 h 42 Eyal Solnik [email protected]
a écrit:

@aminroosta https://github.com/aminroosta Je vous donnerai un conseil, quand
vous lisez un long article, lisez le message original, puis obtenez le
les dernières mises à jour passent environ une minute à faire défiler de bas en haut.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495,
ou couper le fil
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

Personnellement, j'aime l'approche Ctrl + Tab. D'après mon expérience personnelle, les onglets peuvent devenir rapidement désordonnés si vous en avez plus de 10 ouverts en même temps. Je dirais supprimer les "fichiers de travail" ou au moins le laisser comme une option. Je ne l'utilise pas et cela ajoute de la confusion pour moi. J'utiliserai Ctrl + Tab à partir d'ici merci!

@adred Les deux Working files (maintenant appelé Open editors ) et Tabs seront facultatifs pour autant que je sache.

@bpasero

Pouvez-vous _please_ verrouiller ce fil et en ouvrir un nouveau avec les éléments importants de celui-ci copiés? Il y a encore des commentaires qui arrivent quotidiennement de personnes qui ne peuvent pas tout lire (cela devrait vous dire que c'est trop long), et qui posent la même question encore et encore, et une fois que la publication des onglets aura atteint les versions publiques, nous allons voir encore plus de spam dans ce fil.

Je veux rester au courant des événements liés aux onglets, et ce fil est actuellement le lieu idéal pour le faire, mais il est très ennuyeux de recevoir des courriers indésirables plusieurs fois par jour pour les mêmes commentaires encore et encore.

Toutes mes excuses pour le ton et merci.

Il y a tellement de +1 que c'est un peu trop.

Le lundi 6 juin 2016 à 02:16 -0700, "anyong" [email protected] a écrit:

@bpasero

Pouvez-vous _please_ verrouiller ce fil et en ouvrir un nouveau avec les éléments importants de celui-ci copiés? Il y a encore des commentaires qui arrivent quotidiennement de personnes qui ne peuvent pas tout lire (cela devrait vous dire que c'est trop long), et qui posent la même question encore et encore, et une fois que la publication des onglets aura atteint les versions publiques, nous allons voir encore plus de spam dans ce fil.

Je veux rester au courant des événements liés aux onglets, et ce fil est actuellement le lieu idéal pour le faire, mais il est très ennuyeux de recevoir des courriers indésirables plusieurs fois par jour pour les mêmes commentaires encore et encore.

Toutes mes excuses pour le ton et merci.


Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

Juste un commentaire sur le texte de mise à jour @ https://code.visualstudio.com/updates#_workbench

Le texte n'était pas clair pour moi et je pensais en fait que les piles mises à jour étaient déjà là (et que les onglets viendraient plus tard). Après la mise à jour, je n'ai pas vu les piles mises à jour et j'ai dû relire le texte plusieurs fois.

Pour moi, cela dit que les onglets prendront plus d'itérations (donc pas d'onglets dans _cette_ mise à jour), mais qu'en mai, vous avez fait de grands progrès sur la façon de gérer les piles d'éditeurs (donc, malgré l'absence d'onglets, des piles mises à jour _ sont_ dans cette mise à jour?) et qu'il y a plus de travail à faire pour la branche de version de juin (pour améliorer encore plus les piles?).

Donc, à tous ceux qui ont pu être confus comme moi ... on dirait que les piles mises à jour ne sont pas réellement dans cette mise à jour. Je suppose que ce n'est qu'un aperçu des onglets et des piles à venir.

Je suis d'accord avec @RyanEwen. J'apprécie vraiment le développement ouvert et la quantité de communication, mais ces annonces faisant partie des "Notes de publication" officielles sont vraiment déroutantes.

Peut-être que cela peut être divisé en notes de version réelles, et «sur quoi nous travaillons actuellement» ou quelque chose comme ça.

Lier ce problème dans la feuille de route n'a pas été une bonne idée car si vous le lisez dès la première fois, vous n'aurez pas une idée claire de l'état actuel (plus que le jalon). Il y a encore du travail à faire mais l'état actuel est correct: +1:

Oui, ils devraient résumer les problèmes et ensuite avoir des liens vers ces résumés afin que les gens connaissent le plan actuel après qu'il en ait été discuté.

Les liens avec les discussions sont mauvais car ils ont tendance à être longs et les gens ne peuvent pas avoir l'idée sans lire presque tout, mais je ne sais peut-être pas qu'il leur est impossible de le faire autrement.

Quand j'ai commencé à lire les notes de version de la version 1.2, la première chose que j'ai recherchée était _la fonctionnalité de l'onglet_. J'apprécie qu'ils y mettent la situation actuelle. Mais j'ai aussi été confus. Au début, je pensais qu'il avait atterri, mais je ne m'en suis pas rendu compte, mais beaucoup de progrès ont été réalisés. Dans ce cas, il semble vraiment que cet élément devrait être au bas des notes de publication avec un lien vers la discussion ou un jalon (ils prouvent tous les deux la progression de la fonctionnalité) avec une petite note disant quelque chose comme _ "Consultez le progrès vers l'implémentation des onglets "_.

Indépendamment de cette chose mineure. Excellent travail sur la sortie. VS Code est un excellent produit avec un cycle de développement incroyable.

VSCode vient d'être mis à jour vers 1.3.0-insider. Les fichiers récents semblent avoir disparu. Y a-t-il un moyen de le faire maintenant?

Merci pour les commentaires sur les notes de publication et désolé pour la confusion. J'ai apporté des modifications au document pour indiquer clairement que le travail n'est pas stable, mais que vous pouvez prévisualiser le travail de l'onglet dans la version Insiders .

Avoir une section vers la fin où nous parlons du travail accompli mais pas dans la version stable est une bonne idée et nous le ferons le mois prochain si nous avons plus de travail qui rentre dans ce seau.

@JoshClose veuillez ouvrir un nouveau problème pour cela car je verrouillerai ce problème sous peu en faveur de problèmes individuels au lieu de ce fil de discussion unique. THX.

Tout d'abord, permettez-moi de remercier tout le monde une fois de plus pour vos opinions, vos goûts et vos aversions concernant les onglets. Les commentaires que nous avons vus dans ce fil (à la fois positifs et négatifs) montrent vraiment à quel point les gens sont passionnés par l'avenir de VS Code.

Je pense que tout le monde peut convenir que nous avons épuisé l'utilité de ce problème et par conséquent, je vais verrouiller la conversation. Nous laisserons ce problème ouvert jusqu'à ce que nous expédions avec une option pour les onglets / pas d'onglets, ce que nous prévoyons de faire d'ici la fin de l' itération de juin 2016 .

Bien que l'équipe VS Code puisse publier des mises à jour dans ce numéro, vous devez vous attendre à ce que nous créions de nouveaux problèmes pour des conceptions d'onglets ou des discussions supplémentaires. Nous marquerons les problèmes avec le libellé tabs pour faciliter les requêtes. Vous aussi, vous pouvez ouvrir de nouveaux onglets sur des problèmes spécifiques et nous attendons avec impatience vos commentaires sur les problèmes spécifiques, car ensemble, nous construisons les meilleures expériences possibles.

Merci encore, installez maintenant la version Insiders !

https://github.com/Microsoft/vscode/issues/6605 documente tous les identificateurs de commande ajoutés ou modifiés à utiliser avec les raccourcis clavier. Étant donné que le modèle de piles représente une modification importante de l'interface utilisateur de VS Code, nous avons décidé de revoir toutes les commandes liées aux éditeurs ou aux groupes.

Nous sommes heureux d'annoncer que vous pouvez désormais activer les onglets dans nos versions nocturnes d'initiés (http://code.visualstudio.com/Download#insiders). Le paramètre associé est workbench.editor.showTabs . Veuillez consulter nos notes de publication pour plus de détails sur le concept des piles d'éditeurs, des éditeurs de prévisualisation et des onglets.

image

Il y a encore du travail prévu dans ce domaine jusqu'à la fin du mois (et probablement au-delà), nous sommes donc heureux de recueillir les commentaires d'initiés. N'hésitez pas à ouvrir les problèmes au fur et à mesure que vous les trouvez en utilisant les onglets.

Merci!

Comme @bpasero l' a mentionné, vous pouvez désormais activer les onglets dans nos versions nocturnes d'initiés.

Si vous avez essayé cela et que vous pouvez consacrer 30 minutes à partager vos commentaires, veuillez vous inscrire à un chat ici: https://calendly.com/stevencl/vs-code-tabs/

Malheureusement, je ne peux offrir des créneaux horaires que pendant la journée (je suis à Edimbourg, en Écosse) le lundi et le mardi de la semaine prochaine.

tl; dr; activer les onglets dans les initiés VS Code workbench.editor.showTabs: true

Nous clôturons pour le jalon de juin au cours de cette semaine avec nos tests de fin de partie habituels. Les onglets sont sur le plan de test (https://github.com/Microsoft/vscode/issues/7854) et bénéficieront d'une couverture au cours de la semaine. Nous prévoyons toujours de corriger les onglets pour juin et éventuellement des améliorations basées sur les commentaires après juin. Cependant, la majorité du travail est terminée, je vais donc clore ce numéro.

À partir de la description de cet élément de travail, @TurkeyMan demande d'avoir des onglets et un moyen de déplacer un onglet hors de l'atelier pour l'ouvrir dans une nouvelle fenêtre. J'ai extrait ce dernier dans https://github.com/Microsoft/vscode/issues/8171 car il n'est pas lié au travail des onglets que nous avons effectué.

Veuillez continuer à signaler les problèmes sur les onglets tels que vous les voyez lorsque vous les essayez. Merci d'avoir aidé à tester la construction des initiés!

Cette page vous a été utile?
0 / 5 - 0 notes