Salut,
Je suggère l'option de fenêtres flottantes pour:
Finalement:
De cette façon, nous pourrions profiter d'un grand espace d'écran et / ou de plusieurs moniteurs.
Le fait de devoir constamment basculer entre les différentes fenêtres n'est pas un flux de travail optimal.
J'ajoute simplement mon soutien à cela. Très souvent, avec Visual Studio complet, je faisais glisser un onglet sur mon autre moniteur afin de pouvoir afficher deux fichiers de code à la fois. La fonctionnalité du volet divisé est agréable mais pas la même.
Je considère que les onglets de l'éditeur sont plus importants que les autres. Vraiment difficile d'utiliser deux moniteurs lorsque vous ne pouvez pas casser un onglet. Ceci est important lors du référencement du code, mais aussi pour des choses comme l'aperçu Markdown.
Comment ça marche ...? Je ne peux pas le faire fonctionner (sur 1.11.0-Insider). Lorsque vous faites glisser un onglet en dehors de la fenêtre, il affiche un 🛇 et ne me laisse pas déposer, ou, lorsqu'il est déposé au-dessus d'une fenêtre de l'Explorateur Windows, il copie le fichier ...
@CherryDT Ce problème est toujours ouvert et marqué comme Backlog . Avez-vous une référence qui dit qu'il est censé être mis en œuvre dans la version 1.11?
@ vossad01 Vous avez raison J'ai été confus pendant une seconde, parce que je venais du numéro fermé # 10147 où il disait «Déjà adressé par # 10121» et j'ai pris «adressé» comme «résolu». Mon erreur.
Je dirais que le désancrage des onglets (les éditeurs en particulier) est un type de tâche _doit avoir_ plutôt que _ventuellement_. J'adorerais l'avoir mis en œuvre.
@bpasero @aeschli est-ce une fonctionnalité que vous aimeriez obtenir et examiner en tant que pull request? Cela semble être une tâche plus importante, il est donc logique de demander avant de procéder à la mise en œuvre.
@mlewand ce n'est pas un domaine où nous nous attendons à un PR en raison de limitations techniques. Si vous avez une idée, faites-le nous savoir.
@bpasero par limitation technique dites-vous que c'est une limitation Electron? Ou s'agit-il plus de VSCode one project <-> one window design?
@mlewand dépend, si je pouvais ouvrir une fenêtre légère qui partage le même contexte JavaScript et y créer une interface utilisateur, cela aiderait certainement. Sinon, nous finirions par ouvrir une fenêtre de navigateur lourde avec son propre contexte qui ne contient que les éléments d'interface utilisateur que nous voulons afficher, ce qui semble être la mauvaise direction.
Vous voulez faire sonner "moi-à".
Plus précisément les onglets de l'éditeur. Il est malheureux que l'auteur du problème ait les priorités à l'envers, mais je ne peux pas croire que personne chez Microsoft n'ait vu ce ticket à un moment donné au cours de l'année dernière, a reconnu l'immense valeur de pouvoir faire glisser un onglet d'éditeur d'un fenêtre à une autre (votre public Visual Studio le fait depuis des décennies) et l'a fait maintenant.
Il s'agit d'une grave lacune avec VSCode en tant qu'éditeur.
J'ai utilisé Visual Studio comme éditeur principal pendant environ 9 ans, puis je suis passé à VS Code après être passé à une équipe de projet frontale uniquement. Il y a beaucoup à aimer à propos de VS Code, mais la seule caractéristique manquante importante pour moi est le manque de fenêtres flottantes à onglets d'éditeur uniquement (comme je me suis habitué à en avoir dans Visual Studio).
FWIW, j'utilise 4 moniteurs côte à côte. Cela semble insensé d'être bloqué sur un seul moniteur pour l'édition de code, surtout lorsque je travaille sur plusieurs fichiers simultanément.
Je devrai être d'accord avec les commentaires ci-dessus. L'absence de cette fonctionnalité est un énorme problème pour ceux qui ont plusieurs moniteurs (essentiellement tous ceux qui travaillent avec du code). Évidemment, vous pouvez contourner ce problème en ouvrant des fichiers spécifiques dans une instance de Visual Studio Code distincte (ctrl + shift + N), mais c'est certainement quelque chose qui doit être résolu dès que possible.
Je veux pouvoir ouvrir des fichiers dans une nouvelle fenêtre (par exemple pour mettre sur un autre moniteur ou un autre espace de travail virtuel).
Si je ne peux pas ouvrir directement dans une nouvelle fenêtre, je dois pouvoir déchirer un onglet dans une nouvelle fenêtre ou pouvoir faire glisser un onglet vers une fenêtre VSCode séparée (comme créé avec Fichier → Nouvelle fenêtre)
J'utilise un plugin de visualisation WYSIWYG pour éditer AsciiDocs. La séparation des fenêtres sur différents moniteurs est une exigence de base dans ce cas. Espérons que cette fonctionnalité sera bientôt priorisée
Ce serait vraiment bien si nous pouvions déchirer des onglets pour afficher le fichier / l'onglet dans une fenêtre séparée 😪
J'essaie de quitter JetBeans et ce n'est pas une fonctionnalité facultative ou agréable à avoir. C'est fondamental pour le codage multi-moniteurs. Ne pas l'avoir est un facteur décisif.
+
Vous recherchez cette fonctionnalité. Je vous remercie :)
Ce n'est pas le moyen le plus propre de prendre en charge plusieurs moniteurs / fenêtres, mais vous pouvez effectuer les opérations suivantes:
Fichier> Nouvelle fenêtre
Faites maintenant glisser un onglet dans votre fenêtre Visual Studio Code déjà existante dans la nouvelle fenêtre que vous venez d'ouvrir.
Je conviens que ce serait vraiment bien de pouvoir simplement faire glisser un onglet existant sur un deuxième moniteur, mais c'est au moins une solution de contournement assez indolore jusqu'à ce qu'ils prennent en charge le glissement des onglets vers un autre moniteur.
Ajout de ma demande pour cette fonctionnalité également. Ravi de voir d'autres en vouloir.
J'adore cet IDE, sinon. 😄
Bonne chance.
Fonctionnalité hautement nécessaire.
Merci
+1
(BTW .: Le Backlog-Link (https://github.com/Microsoft/vscode/milestone/8) ici dans le panneau de droite ne fonctionne pas?)
Avez-vous l'intention de l'ajouter à un cercle de publication? Merci!
Je ne sais pas si quelqu'un a vu ce projet pour l'électron, mais je vais juste laisser ça ici. Peut-être que MS pourrait aider, dans leur abondance de temps :). Je n'ai pas vu de commits depuis un certain temps, je ne sais pas s'il a rencontré un problème ou s'il s'est simplement occupé.
Je dois admettre que je suis choqué qu'un éditeur aussi établi que VSCode ne me permette pas de faire glisser un onglet vers un deuxième moniteur.
Ajout de mon +1 à cela.
J'adorerais également avoir cette fonctionnalité. +1
@bpasero Je ne pense pas que ce serait un si gros problème de permettre l'ouverture d'une autre instance de VSCode si nous faisions glisser un onglet. Au moins, ce serait un début.
Je pense passer de Sublime Text à VSC et cette limitation est la seule chose qui me permet de les utiliser tous les deux, je serai certainement plus enclin à VSC une fois que vous l'aurez ajouté!
+1
même si je n'ai besoin que de l'explorateur et du débogage
onglets
Explorateur / recherche / debug / git / extensions
Tant de demandes pour cela, et elles arrivent également régulièrement. Je suis content de ne pas être seul. En réalité, c'est mon seul problème avec le code VS pour le moment.
+1
Je répondrai avec le commentaire ci-dessus - c'est vraiment mon seul problème / fonctionnalité pour VSCode. Sinon, c'est un plaisir absolu de travailler avec, et bien supérieur à Sublime et autres (à mon avis).
@RoyTinker pareil ici. C'est la dernière chose qui m'empêche de passer complètement à VSCode.
En accord avec tout ce qui précède, c'est la seule mouche dans la pommade pour moi après le passage de Sublime.
Je pense qu'une autre raison importante pour cela est que vous pouvez interrompre les fenêtres "Sortie" et "Terminal". Si vous allez exécuter le débogage dans VS Code, vous voulez probablement que la fenêtre de sortie soit sur un moniteur et le code sur un autre plutôt que de tout entasser sur un seul moniteur.
@laserbeak Je pense que les complications
J'ai du mal à déboguer un grand projet malgré le travail sur trois écrans - je ne peux avoir que la console de débogage et le code que je parcours sur un seul écran. Je ne peux même pas les avoir côte à côte sur le même écran car la console de débogage prend tout le bas de la fenêtre séparément de l'éditeur de code.
J'espère que cette fonctionnalité pourra recevoir une priorité plus élevée, d'autant plus qu'elle est ouverte depuis plus d'un an maintenant.
Non pertinent https://www.npmjs.com/package/electron-window-manager
Op 5 okt. 2017 02h38 schreef Luc Shelton [email protected] :
@laserbeak https://github.com/laserbeak Je pense que les complications viennent du fait de devoir gérer la gestion des fenêtres sur plusieurs systèmes d'exploitation. Il n'y a peut-être pas de moyen clair ou clair de le faire sur toutes les plates-formes.
-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/Microsoft/vscode/issues/10121#issuecomment-334327742 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AD90FFy4E1Ra3EKfLfwh026vckOf4p9kfjcf .
Apparemment, les gars de JetBrains connaissent la meilleure façon de le faire.
Dans chaque produit IntelliJ, chaque vue a une icône de roue dentée qui a les options suivantes:
Sans cette fonctionnalité, les développeurs entrent dans le cycle suivant qui prend au moins 20% du temps du développeur!
while (developing){
swithToIDE() // because you were checking browser before this.
findTheFileYouAreInterested() // because you can't see more then one file unless you split the view which brings another problem(limits visible area)
findTheCodeYouAreWorkingOn() // since the coding window is too small because of the space taken by other views (terminal, output etc.)
changeLogicCode()
// checking output
if (output.NotVisibleEnough){ // TODO: change to if(true) becuase it's never visible enough
output.resizeToVisibleSize()
}
findTheProblemInOutput()
if (output.takesTooMuchSpace){ // TODO: change to if(true)
output.resizeToMinimalSizes()
}
changeLogicCode()
changeUICode()
swithToBrowser();
}
J'appelle ce que le cycle C réativité K iller de U de SERS de F.
Il est dommage que cela n’ait apparemment pas de priorité élevée. C'est vraiment un showstopper pour cet éditeur autrement génial.
C'était la dernière chose qu'ils m'ont dit à ce sujet @Hypernut
Bizarre qu'ils ignorent la demande apparemment élevée pour cette fonctionnalité.
@Hypernut J'ai pensé la même chose. Il me semble que cela devrait être une fonctionnalité de base de tout IDE moderne.
@LoveDuckie @Hypernut Vous pouvez contourner ce problème en faisant glisser un fichier de l'explorateur dans une nouvelle fenêtre; mais ce n'est vraiment pas une solution acceptable. Ils semblent esquiver la question selon laquelle il s'agit d'une limitation de l'électron et si oui ou non ils seront réellement capables de le faire malheureusement.
ou peut-être qu'ils ne veulent tout simplement pas faire une concurrence trop forte pour Visual Studio; -}
@ benm-eras J'en suis conscient, mais il semble que cette fonctionnalité soit déjà prise en charge. C'est simplement un cas de MS souhaitant l'intégrer à VS Code.
+1. Obligatoire, ce n'est pas très pratique pour les personnes disposant de plusieurs moniteurs (onglets). Plus de 14 mois et toujours un silence de mort? Mais bon, le support de macOS Touch Bar est là. 👎 Triste ...
Je suis d'accord avec le commentaire «ne faisons pas concurrence à Visual Studio». Eh bien, si je pouvais travailler efficacement sur mon SPA et mon backend API Web dans Visual Studio, je n'aurais pas non plus besoin de VS Code.
+1 besoin de cette fonctionnalité
Cette fonctionnalité est dans le backlog, mais elle est classée n ° 14 lors du tri des demandes de fonctionnalités par nombre de votes positifs:
https://github.com/Microsoft/vscode/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Areactions-%2B1-desc%20label%3Afeature-request
Il a besoin de 104 voix supplémentaires pour faire partie du top 10.
Ce problème recevrait probablement beaucoup plus de votes positifs si la demande initiale était mieux formulée.
Titre: VSCode Add Multi-Monitor / Multi Workspace Support.
La description:
Prise en charge du glissement des onglets de document VSCode, des fenêtres d'outils et d'extension hors d'une instance IDE sur plusieurs espaces de travail / moniteurs. Windows éclaté de cette manière devrait fonctionner dans le même contexte que lorsqu'il est généralement attaché à l'EDI.
Comportement actuel:
https://cloud.githubusercontent.com/assets/2397125/26831065/5b8f145c-4acb-11e7-8f81-fe25512708cd.gif
Comportement désiré:
https://user-images.githubusercontent.com/3527695/31317649-71a530b2-ac4d-11e7-9531-6fe2d4a2e967.gif
Soutien:
https://www.npmjs.com/package/electron-window-manager
Alors pourquoi n'utilisez-vous pas simplement Visual Studio?
@ s952163
J'utilise, mais je suis limité à Windows uniquement ;-) alors que vscode j'utilise sous linux, macos, windows
@ s952163 De nombreuses raisons potentielles:
Je suis maintenant un développeur frontal sur macOS et je ne reviendrais pas vers Windows et Visual Studio uniquement pour la prise en charge de plusieurs fenêtres. Je suis actuellement à la recherche d'éditeurs similaires pour voir si des fenêtres flottantes prennent en charge: Brackets, Atom, Sublime, JetBrains ...
Je souhaite également apporter mon soutien à cette fonctionnalité. À ce stade, c'est la fonctionnalité manquante qui m'empêche d'utiliser VS Code à plein temps.
Un développeur typique commentant ce problème: "Tous les autres IDE avec une mauvaise interface utilisateur conçue dans les années 90 m'ont forcé à acheter plusieurs écrans pour être productif du tout, donc ce nouvel IDE ne devrait pas essayer de résoudre le problème différemment mais reproduire la même mauvaise interface utilisateur et prendre en charge mes multiples écrans ".
J'espère vraiment que cela ne sera pas mis en œuvre, se concentrer sur une fenêtre unique, rationalisée et axée sur l'édition UX est un avantage important de VSCode, pas un inconvénient.
@ Krzysztof-Cieslak De la même manière, Chrome ne devrait pas prendre en charge l'ouverture d'un onglet dans une nouvelle fenêtre. Je ne pouvais pas imaginer que quiconque soutienne cela. Plusieurs moniteurs sont toujours _ vraiment utiles_ car ils augmentent la surface d'écran disponible. Les applications qui prennent en charge plusieurs moniteurs ne sont pas du tout maladroites pour le faire.
Voir l' illustration de @ D1no ci-dessus ( cliquez pour faire défiler vers le haut ). C'est ce que je voudrais - tout comme faire apparaître un onglet Chrome. [EDIT: Je ne dis pas que la fenêtre du nouvel onglet doit dupliquer l'interface utilisateur de la fenêtre principale. Je pense que tout ce dont il aurait besoin est une barre d'onglets (pour plusieurs onglets d'éditeur de code) et le contenu de l'onglet.]
@ Krzysztof-Cieslak vous plaisantez, non? Croyez-le ou non, il existe une grande communauté de développeurs qui valorisent la productivité plutôt que la localité dans un café, ou au sommet d'un arbre, ou tout ce qui est actuellement en vogue.
Les espaces de travail multi-écrans ne sont pas une relique des années 90. Ils sont un outil de productivité incroyable qui ne doit pas être sacrifié au changement de mobilité ou de modes de vie hipster.
@ Krzysztof-Cieslak c'est probablement la déclaration la plus factice que j'ai lue depuis longtemps. Pour info: la moitié du mouvement VR du 21e siècle est inspirée par les limitations du parc d'écran pour un nombre infini de "fenêtres / interfaces" 🙄
Revenons donc au sujet: que pouvons-nous faire?
Je me demande comment la réalité virtuelle est liée à l'édition de texte et aux activités de lecture lourdes comme la programmation ... C'est la partie facile.
@ Krzysztof-Cieslak, vous dites que les anciens IDE avaient un problème de conception qui nous a obligés à avoir plusieurs moniteurs, OK, je vais prendre ça, je n'en sais pas assez sur ce sujet pour dire que c'est vrai ou faux (et je suis né en 1991 donc je n'ai pas vraiment eu de chance), mais peu importe comment vous le voyez, il est plus productif de voir 2 fichiers ou plus en même temps que de cliquer sur des onglets ou d'utiliser des combinaisons de touches pour changer la vue, ceci est particulièrement vrai lorsque ces fichiers ont une forte dépendance. Je ne pense pas avoir besoin d'expliquer ce besoin, vous devriez savoir de quoi je parle. Désolé pour le mauvais anglais, btw.
Kiddo, habitez-vous derrière la lune ou êtes-vous juste à la traîne
https://gearburn.com/2016/06/space-vr-app-turns-the-htc-vive-oculus-rift-into-a-productivity-hub/
https://www.bloomberg.com/news/articles/2016-11-16/how-working-in-vr-could-make-you-more-productive
https://www.theguardian.com/technology/2015/mar/24/andreessen-horowitz-london-virtual-reality-startup-improbable
(...)
La maximisation de l'exposition aux informations est ce qui motive tout, du multi-threading à la densité de pixels et même des applications multi-écrans et multi-appareils. IDE inclus.
Il est donc approprié de _ask_ pour qu'un éditeur enrichi rejoigne ce flux de travail établi. Si vous avez des contributions à partager en plus de la pêche à la traîne, nous sommes tous heureux de vous entendre. Mais à ce stade, l'activité de plus d'un an de cette question parle d'elle-même.
Nous sommes au-delà de _if_, plutôt à _when_ et _how_ cette amélioration atteint vscode.
Ce problème devient assez brûlant, je pense que ceux d'entre nous qui le soutiennent devraient le sensibiliser (tweeter, recommander, discuter), afin qu'il puisse figurer parmi les 10 premières demandes. La pêche à la traîne / les insultes / les disputes ne nous mène nulle part.
Et merci @ D1no , maintenant je veux un Oculus Rift pour pouvoir avoir 17 moniteurs virtuels :).
@ Krzysztof-Cieslak
Il s'agit d'une fonctionnalité et non d'un choix de conception. Si cette fonctionnalité est mise en œuvre, vous n'avez pas besoin de plusieurs moniteurs pour utiliser VS Code. En fait, vous n'avez rien à faire, vous utilisez simplement VSCode tel quel. Je ne comprends toujours pas pourquoi vous êtes contre.
Quoi qu'il en soit, j'ai 2 moniteurs et j'envisage toujours d'acheter le troisième. Pourquoi? Il faut vraiment du temps pour cliquer et redimensionner une fenêtre pour voir le contenu. Machine virtuelle, le code que vous écrivez, la page HTML que vous concevez, la fenêtre du navigateur que vous vérifiez, la sortie de débogage, le terminal et ainsi de suite. J'ai besoin de tous les voir à la fois.
BTW en utilisant MacOS ou Linux n'est pas la seule raison de ne pas utiliser VS.Si vous avez déjà utilisé VS, vous savez à quel point il est gonflé. La dernière fois que je l'ai téléchargé, c'était il y a quelques mois et sa taille était d'environ 7 ou 8 Go à l'époque. Pourtant, vous n'avez pas de programme de désinstallation hors ligne pour un programme d'installation de 8 Go! Il existe des solutions de contournement pour créer un programme d'installation hors ligne à partir d'un programme d'installation en ligne sur le net!
@tavuntu
il est plus productif de voir 2 fichiers ou plus en même temps
Vous pouvez actuellement voir 3 fichiers, un panneau vertical (débogueur, git, recherche, explorateur) et un panneau horizontal en même temps
@ D1no ,
Bien joué, relier certains liens sans rapport avec les IDE (ou l'édition de texte en général) vers les articles hype VR dans des médias informatiques / génie logiciel respectables tels que Guardian et Bloomberg montre totalement votre point de vue. Cependant, je ne vois toujours pas dans tout ce fil un lien vers la recherche, l'étude, l'article montrant le gain de productivité lié à l'utilisation de plusieurs écrans pour l'édition de texte. Je ne vois aucune discussion raisonnable sur les implications possibles des différentes manières d'implémenter une telle fonctionnalité. Je parie que je ne verrai aucune implémentation de preuve de concept. Tout ce que je peux voir, c'est un groupe de gens heureux de +1 une fonctionnalité aléatoire avec d'énormes implications de conception (et beaucoup de haine pour quiconque a une opinion différente)
Bref, je suis sorti. Ouais, m'appeler gamin vivant derrière la lune vous a valu cette discussion! Vous m'avez également démystifié en tant que troll Internet aléatoire, bien joué, monsieur!
@ Krzysztof-Cieslak,
Non non, ne vous enfuyez pas quand vous avez tort!
Veuillez d'abord pointer une étude montrant que le fait de ne pas avoir de prise en charge de plusieurs moniteurs améliore la productivité ou plutôt constitue un meilleur choix. Tout ce que vous avez donné aux gens était votre demande, et ils ont donné la leur.
"Vous pouvez actuellement voir 3 fichiers, un panneau vertical (débogueur, git, recherche, explorateur) et un panneau horizontal en même temps", bel essai, mais vous savez ce que je veux dire, je veux dire une fenêtre agrandie avec un fichier CSS en un moniteur et une fenêtre agrandie avec HTML dans un autre ... c'est bien mieux que d'avoir beaucoup de panneaux inconfortables dans le même moniteur. Je dirais que c'est une préférence personnelle, mais bon, cette chose a 237 votes positifs contre 7 votes négatifs, alors oui.
@tavuntu @ Krzysztof-Cieslak Je garde l'un de mes moniteurs de 22 "orienté verticalement. C'est parfois très agréable d'éditer un fichier widget JS là-bas, avec les fichiers HTML et CSS correspondants dans un volet divisé maximisé sur un moniteur adjacent.
Disposition:
+---------+
| |
| JS File |
| |
+-------------+ +--------------+ | |
| Chrome tabs:| | CSS | HTML | | |
| App, docs, | | File | File | | |
| inspector | | | | | |
| | | | | | |
+-------------+ +--------------+ | |
+--------------+ +---------+
| Terminal, |
| Email, |
| Slack |
| |
+--------------+
Idéalement, les moniteurs en haut au milieu et à droite exécuteraient une seule instance de VS Code, le fichier JS apparaissant comme une fenêtre séparée et agrandie.
Veuillez ne pas faire cette erreur ...
Vous ne pouvez pas lire plusieurs fichiers à la fois et rester concentré. Diviser le code en un seul écran suffit déjà et ce type de décision implique beaucoup d'implication de conception pour l'expérience utilisateur.
Il y a déjà beaucoup à faire sur VSCode, pour améliorer l'expérience utilisateur actuelle sans ajouter plus de complexité. Parce qu'une nouvelle fenêtre signifie probablement que le fournisseur VSCode doit la prendre en charge car le contexte n'est pas aussi simple avec une seule fenêtre, etc.
Meilleure mise au point possible IMO, correction de la sélection du modèle de mot et changement de nom de la sélection, ajout de la prise en charge du glisser-déposer dans les panneaux, etc.
De plus, la plupart des systèmes d'exploitation ne prennent pas en charge un système de tuilage approprié pour vos fenêtres, alors amusez-vous à gérer chacune d'elles ...
@MangelMaxime Vous réalisez que de nouvelles fenêtres seraient facultatives?
@ jez9999 Oui, je comprends cela, car je comprends également que ce n'est pas une fonctionnalité simple à ajouter et à maintenir à l'avenir. :) Juste donner mon avis après semble que la plupart des gens ont déjà donné avec un +1 :)
@MangelMaxime
"Vous ne pouvez pas lire plusieurs fichiers à la fois et rester concentré"
Si vous pouvez cliquer-redimensionner-lire plusieurs fichiers, vous pouvez sûrement lire plusieurs fichiers sans cliquer et redimensionner d'abord.
De plus, ce n'est pas toujours le code que vous continuez à regarder. Parfois, vous regardez la sortie ou entrez des commandes dans le terminal. C'est pourquoi je m'en tiendrai à IntelliJ jusqu'à ce que cette fonctionnalité arrive au code VS.
@ramazanpolat
C'est un bon point en effet mais pour la console ou la commande, nous avons déjà l'application console par exemple qui devrait faire un meilleur travail en général IMO.
J'abandonne.
La prise en charge de plusieurs moniteurs est une mauvaise idée.
C'est cher, cela rendra la maintenance des applications plus difficile, cela empêchera les utilisateurs de concentrer le code. De plus, un moniteur est nettement moins cher que deux. Vous n'avez pas besoin de bouger les yeux de gauche à droite et de haut en bas, il vous suffit de regarder directement le milieu de l'écran et d'utiliser la souris pour déplacer le contenu pertinent vers le milieu de l'écran. De cette façon, vous pouvez également trouver des moniteurs de plus petite taille plus attrayants, en raison de leur taille compacte et de leur prix moins cher.
EDIT: Apparemment, quelqu'un n'a pas eu le sarcasme.
Depuis sa sortie, Code n'a pas eu de support multi-moniteurs, et j'ai supposé que ce choix avait été fait intentionnellement. Cela dit, je ne sais pas si je le trouverais utile. J'utilise Code dans un moniteur et mes navigateurs et émulateurs dans l'autre écran. -1.
Pourquoi le rejeter simplement parce que vous ne l'utiliseriez pas?
J'ai refusé de fournir des commentaires sur un niveau de priorité. Je pense que la fonctionnalité devrait être donnée dans le backlog. Ce n'est pas une fonctionnalité que je prioriserais, et en fait, je pense que cela va à l'encontre de la conception et de l'intention (voir "Depuis sa sortie, le code n'a pas pris en charge plusieurs moniteurs, et j'ai supposé que ce choix avait été fait intentionnellement." ) Merci pour la question!
C'est cher, cela rendra la maintenance des applications plus difficile, cela empêchera les utilisateurs de concentrer le code.
De plus, un moniteur est nettement moins cher que deux.
Ouais! Si je n'aime pas le pain, personne ne devrait le manger! Ne fait qu'encombrer les magasins, les rend plus difficiles à entretenir. Empêche les gens de se concentrer sur d'autres aliments plus importants.
De plus, vous n'avez plus besoin de beurre, ce qui rend la vie définitivement moins chère.
Quelle discussion absurde ...
dites-moi si j'ai raison. Si la fonctionnalité est intégrée maintenant. contre si la fonctionnalité est intégrée plus tard, lorsque le code serait devenu plus complexe en raison des «fonctionnalités requises». Ne serait-il pas préférable de l'intégrer maintenant, alors que le système global est relativement plus simple?
Vous avez de bonnes nouvelles pour tous ceux qui (comme moi) ne le savaient pas: il semble que cette fonctionnalité soit déjà (principalement) implémentée. Déchirer les onglets dans des fenêtres séparées est __déjà possible__ 🎉, avec quelques mises en garde / solutions de contournement requises.
Étapes de préparation:
Maintenant, faites glisser et déposez un onglet d'éditeur de la fenêtre de votre projet vers la nouvelle fenêtre.
==> Boom: Workspace est maintenant multi-moniteur.
(vous devrez également fermer l'onglet depuis lequel vous avez glissé)
Ainsi, une implémentation minimale viable de cette fonctionnalité ne serait pas insoluble si l'on pouvait automatiser les étapes 2 à 5 (+ fermeture de l'onglet d'origine) et déclencher l'automatisation lorsque quelqu'un fait glisser / dépose un onglet sur une partie de l'écran n'appartenant pas à vscode.
Hé, oui, c'est une solution de contournement connue (comme ouvrir le projet plusieurs fois) et est indiquée ci-dessus quelque part dans les commentaires. Cependant, c'est fastidieux et - parfois - peut entraîner des problèmes d'ouverture de plusieurs instances du projet en même temps (ces instances ne communiquent pas directement entre elles).
@RoyTinker "Je garde l'un de mes moniteurs 22" orienté verticalement. ", c'est un argument valable!
Vous ne pouvez pas non plus déboguer dans l'autre éditeur. La raison la plus utile d'avoir plusieurs fenêtres est de déboguer sur le serveur (nœud) et le client (Angular). Avoir tout cela dans un seul espace est vraiment irritant. Je veux avoir mes fichiers angulaires dans une fenêtre, mes fichiers de nœuds dans une autre et le terminal dans un autre plein écran afin que je puisse voir la sortie de ce qui se passe. Tout est possible dans quelque chose comme Web Storm, mais pas VS Code. Cela aide vraiment la productivité et pour cette seule raison, j'utilise toujours WS au lieu de VSC.
Bonne nouvelle - cela est passé au n ° 13 des demandes de fonctionnalités triées par votes positifs. Nous n'avons besoin que de 88 votes supplémentaires pour faire partie du top 10.
un vote de plus de ma part!
Voté, c'est la seule chose qui manque en passant de Sublime
Un vote de plus, une fonctionnalité indispensable.
Et un vote de plus!
un vote de plus!
J'adorerais avoir cette fonctionnalité. Vote positif.
Un vote de plus.
Les commentaires en tant que votes aident-ils? Ou juste assez de pouces vers le haut du post principal? Sinon, ce fil deviendra un peu inondé.
Bravo sur le message principal.
Nous avons besoin d'un coup d'œil sur le message principal ... N'ajoutons pas à ce fil à moins que nous ayons quelque chose à ajouter à la discussion. Merci pour les votes !! 😃
+1 Vote de moi
Je commence à en avoir davantage besoin à mesure que les projets prennent de l'ampleur. Ce serait une excellente fonctionnalité, si les performances ne diminuent pas à cause de cela.
Il serait également idéal de l'avoir pour certaines modifications de texte. Par exemple, j'écris des articles de recherche dans VS-Code. J'écris également beaucoup de documentation basée sur Markdown dans VS Code. Ce serait très utile si j'écris le code / texte sur un seul écran et que j'obtienne l'aperçu (toujours dans VSCode) sur un moniteur externe (ou, un deuxième écran). J'ai totalement besoin et supporte cette fonctionnalité!
+1 vote de ma part! Vscode est génial et ce sera encore plus génial avec cette fonctionnalité!
@ amadare42
Les pouces vers le haut sont toujours préférés à la méthode populaire du +1. Wish GitHub le rendrait plus évident avec un bouton +1 à chaque message que le + [Emoji].
J'ai toujours aimé le style reddit aussi
Hourra, nous sommes arrivés dans le top 10 (c'est en fait le # 9 maintenant). Seulement 68 votes de plus et ce sera dans le top 5 des demandes de fonctionnalités. (Pour voter, ajoutez une réaction "thumbs up" au commentaire supérieur.)
Un coup de pouce pour cela. ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP
Votez de moi
+1 pour moi. La première chose que j'ai remarquée manquait lors du changement.
Ma configuration actuelle de VS Community Edition:
Écran gauche:
Écran droit:
En ce moment, le "mode zen" est étroitement lié à cela ... mais ce n'est pas presque la même expérience.
Alors s'il vous plaît ... "faites flotter toutes les choses!" 🙏
Mais je pense aussi que ce n'est peut-être pas un travail facile pour les développeurs de vscode.
Cette fonctionnalité nécessiterait peut-être que les développeurs d'extensions implémentent une interface s'ils veulent que leurs fenêtres d'extension flottent. Le pire des cas serait que toutes les anciennes extensions devraient être réécrites pour prendre en charge le flottant.
Mais de toute façon, si la fonctionnalité est bien faite, cela n'oblige pas les développeurs d'extensions à se soucier de quoi que ce soit de plus ,,,,,, ce serait gleit.
J'attends toujours cela après avoir basculé vers le code à partir de Visual Studio: (Pour l'instant, ma seule solution est de minimiser l'application et de l'étirer manuellement pour l'adapter à mes moniteurs.
@nguyenlamlll Je vous suggère de lire https://github.com/Microsoft/vscode/issues/2686#issuecomment -344808761
C'est une application géniale, et je suis récemment passé de Webstorm à vscode.
Je veux vraiment cette fonctionnalité !!
@bpasero "retiré du backlog" - un commentaire? Je serais triste d'apprendre que la réponse de l'équipe est un «non».
@RoyTinker non, cela n'a pas de signification spécifique, je préfère simplement que les problèmes qui me tiennent à soient attribués à aucune étape à moins que le travail ne commence. Veuillez consulter notre feuille de route pour savoir sur quoi nous prévoyons de travailler dans les 6 à 12 prochains mois: https://github.com/Microsoft/vscode/wiki/Roadmap
Veuillez consulter notre feuille de route pour savoir ce sur quoi nous prévoyons de travailler dans les 6 à 12 prochains mois
Je ne le vois pas là-bas, donc il semble que vous continuez à ignorer la forte demande pour cette fonctionnalité.
Pourquoi?
Ouais, je dirais que cette fonctionnalité tombe fermement dans la catégorie "Happy coding". Plus de 400 votes positifs. Devrait être sur la feuille de route.
Je suis tout à fait d'accord que ce serait une excellente fonctionnalité, mais vraiment les gars donnent du repos aux gentils gens de vscode. Je suis presque sûr qu'il y a de bonnes raisons pour lesquelles ce n'est pas encore commencé. Nous devons nous rappeler qu'il s'agit d'un logiciel libre;)
Merci @bpasero, bon à savoir.
@ zewa666 oui c'est gratuit et génial, j'en suis reconnaissant. Le problème est que ces gars-là ne donnent pas de réponse et même s'ils ont une bonne raison de ne pas mettre en œuvre cela, leur silence nous dit qu'ils ne se soucient tout simplement pas de cette demande. Nous sommes des développeurs, beaucoup d'entre nous comprendraient une raison technique. Parfois, le silence est pire qu'une réponse négative.
Oui c'est gratuit. Mais - et je peux me tromper - il est développé uniquement par des développeurs Microsoft et Microsoft. Si c'est correct, je suis presque sûr qu'ils sont payés pour travailler là-dessus. C'est donc au moins légèrement différent de tout projet communautaire que les gens font pour s'amuser et pendant leur temps libre. Parce que dans tout autre projet open source comme celui-ci, nous aurions déjà une réponse si et quand cela sera mis en œuvre et sinon, pourquoi.
C'est tout ce que je demande.
Le silence est étrange pour un projet open source, mais malheureusement typique pour une entreprise comme Microsoft.
Il y a une raison technique pour laquelle cette fonctionnalité ne fait pas beaucoup de progrès: nous utilisons le framework Electron comme cadre d'interface utilisateur multiplateforme basé sur Chrome en dessous. Chrome a un modèle où chaque fenêtre obtient son propre contexte isolé, par exemple, chaque fenêtre a son propre processus et son propre contexte JavaScript. Je ne serais pas possible de partager le même contexte entre plusieurs fenêtres.
Imaginez maintenant que vous avez un éditeur dans lequel vous tapez et que vous souhaitez le faire glisser pour produire une nouvelle fenêtre, vous vous attendez à ce que cette opération soit très rapide et légère. Mais au lieu de cela, cela nous obligerait à créer une toute nouvelle instance de VS Code avec un hôte d'extension séparé, même pour avoir l'éditeur dans une fenêtre autonome (ce serait comparable à faire Fichier> Nouvelle fenêtre et à ouvrir ce fichier dans la fenêtre) .
Je ne vois cette fonctionnalité possible que lorsque nous trouvons un moyen de créer des fenêtres qui partagent la même mémoire avec la fenêtre "principale" afin que cette opération soit légère. A mon avis, cela ne fonctionnerait pas pour que chacune des fenêtres flottantes soit complètement isolée comme elles le sont maintenant.
@bpasero - être léger pour cette fonctionnalité n'est pas si essentiel - ce serait déjà très utile si deux instances de vscode sont synchronisées et je peux simplement modifier un fichier sur l'écran principal et voir le panneau de problèmes ou les terminaux sur le deuxième écran se mettre à jour immédiatement. J'ouvrirais typiquement par exemple un panneau sur un deuxième écran et aurais cette configuration d'écran juste assise ouverte pendant des heures.
Idéalement, je voudrais avoir un écran partagé avec 1-4 fenêtres sur le deuxième écran ouvert côte à côte pour pouvoir jeter un coup d'œil sur le panneau des problèmes et les terminaux ouverts (par exemple, montrant les tests unitaires et la sortie client et serveur) - afin que je puisse utiliser le premier écran plein écran sans avoir à ouvrir et fermer le panneau latéral tout le temps.
Je me trouve assez souvent dans la situation où vous ouvrez et fermez le terminal tout le temps avec cmd + j ou devez fermer tous les onglets séparés parce que vous voulez différer les changements côte à côte bien que j'ai un deuxième écran où ceux-ci pourraient simplement rester ouverts .
Merci pour la réponse.
Je m'en fous non plus si c'est léger. Je veux juste pouvoir déplacer le terminal et la console de débogage là où cela me dérange le moins.
@bpasero
euh, on ne peut pas garder le contexte?
// STEP 1: open a new browser window and store a reference to it
this.externalWindow = window.open('', '', 'width=600,height=400,left=200,top=200');
// STEP 2: append the container <div> (that has props.children appended to it) to the body of the new window
this.externalWindow.document.body.appendChild(this.containerEl);
Je le sais, car c'est l'une des principales raisons pour lesquelles les portails React v16 sont si utiles.
https://hackernoon.com/using-a-react-16-portal-to-do-something-cool-2a2d627b0202
Merci pour les suggestions et la discussion. Il existe certainement des moyens de communiquer entre les fenêtres, même si elles vivent dans des processus séparés. Il y a toujours le défi que l'une des fenêtres n'est pas vraiment consciente de l'autre fenêtre. Des bibliothèques comme electron-window-manager
semblent rendre cela un peu plus facile, mais après tout, il y a une tonne de travail à faire, pour en décrire quelques-uns:
Je ne dirais pas que c'est techniquement impossible, mais ce que je peux dire, c'est que cette demande de fonctionnalité est à la fois très difficile en raison de l'impact sur l'interface utilisateur et en raison du changement fondamental qu'elle nécessite pour chaque aspect de ce que nous avons aujourd'hui. J'espère que cela à du sens.
J'espère que vous viserez à publier cette fonctionnalité étape par étape et que vous ne serez pas assis sur des plans
+1 aimerait ça
@bpasero Désolé pour la question n00b: nativeWindowOpen peut-
+1 de moi et
@ Blackbaud-DustinLunsford merci pour une solution de contournement simple
@ n9 Je pense que la communication entre les deux fenêtres peut être résolue mais les autres problèmes restent que j'ai mentionnés, en particulier le fait que chaque fenêtre a son propre DOM et que tous nos services doivent parler au même backend depuis chaque fenêtre
C'est une fonctionnalité intéressante dont j'ai besoin!
@bpasero merci pour la réponse!
Un doit avoir sur écran partagé 1 portrait, 1 paysage.
L'une des raisons pour lesquelles j'utilise toujours Eclipse sur du code VS. Code de fenêtre en mode portrait - Outils sur paysage
+1
J'adorerais voir cette fonctionnalité bientôt disponible 🙂
Bon travail; J'adore l'éditeur
Jésus
+1 ...! 😃
@bpasero Je soupçonne qu'il existe une cible intermédiaire possible de 80/20 (% bénéfice / effort) qui n'impliquerait pas plusieurs des complexités que vous avez mentionnées.
Et si les fonctionnalités suivantes pouvaient être ajoutées:
@RoyTinker Je pense que cela peut être encore plus simple.
Comme première solution, il n'est pas nécessaire que ce soit des fenêtres 100% "détachables". L'APP réelle pourrait simplement être un "conteneur" pour plusieurs canevas qui peuvent être réorganisés à l'intérieur.
Avec un peu de chance, cela pourrait être un changement très simple dans la fenêtre principale de VSCode.
@Rouche VSCode est implémenté dans Electron, ce qui signifie que chaque fenêtre est un processus de chrome distinct, accompagné de certains processus back-end. L '"application" est un conteneur spécifique au système d'exploitation qui instancie / orchestre ces processus. Changer ce modèle serait plutôt fondamental (important) à ce stade.
Je suis un peu déçu que cela n'ait jamais été une considération de conception de la part du
le tout début.
Le vendredi 1er décembre 2017 à 21h39, Roy Tinker [email protected] a écrit:
@Rouche https://github.com/rouche VSCode est implémenté dans Electron,
ce qui signifie que chaque fenêtre est un processus de chrome distinct, accompagné de quelques
les processus back-end également. L '"application" est un conteneur spécifique au système d'exploitation qui
instancie / orchestre ces processus. Changer ce modèle serait
plutôt fondamentale (grande) à ce stade.-
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/10121#issuecomment-348621220 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAqQmoLrUY4l5H5xwroWCytBbgT2LIL_ks5s8HIqgaJpZM4JckZO
.
-
Programmeur de jeux
+1
En tant qu'utilisateur de Visual Studio dans le passé, c'est une fonctionnalité qui me manque cruellement dans VS Code.
+1
@bpasero Le fait que chaque fenêtre soit dans son propre processus ne peut-il pas être traité comme un problème d'électrons? N'est-ce pas une surcharge inutile d'avoir le multi-traitement pour chaque fenêtre pour un cadre tel que l'électron?
Eh bien, je pense que l'équipe d'électrons peut simplement dire que le problème est dans le chrome. Depuis, chrome crée un nouveau processus pour chaque onglet. La seule solution serait de déplacer l'électron pour travailler sur un autre cadre entièrement.
@vvavrychuk Ce n'est pas tant un problème d'électrons qu'une limitation fondamentale de la technologie Web. (électron = chrome + API pour accéder aux fonctionnalités sous-jacentes du système d'exploitation)
Et si vous pouviez lancer vscode dans certains modes, par exemple "mode extension",
et passez par certains paramètres. par exemple. vscode --extended-window --socket-id
((guid-socket)) --root-window ((root-window-guid))
De cette façon, vous pouvez créer une prise ou un bus de communication entre Windows
ou des applications indépendantes.
Chaque fenêtre étendue créée se voit attribuer un identifiant de fenêtre racine et le
a créé un identifiant de socket UNIX avec lequel communiquer.
Je pense qu'il y a une possibilité de mettre en œuvre quelque chose comme ça.
Si l'électron a un moyen d'ouvrir, de lire et d'écrire des sockets, cette approche pourrait
avoir du succès.
@RoyTinker chrome a l'option "single-process" mais electron ne la prend pas en charge https://github.com/electron/electron/issues/11398. Ils disent que nous ne pouvons pas avoir plusieurs instances node.js dans un même processus. Ça c'est sûr. Mais je ne comprends pas pourquoi nous avons besoin de plusieurs instances node.js pour plusieurs fenêtres? Ne pouvons-nous pas avoir Electron = plusieurs fenêtres + un seul node.js en un seul processus?
@ Jesus-Gonzalez On dirait une variante de ce que @bpasero a dit qu'il faudrait pour mettre en œuvre ceci, bien que votre suggestion semble plus facile (pour moi au moins) que l'élément (3) de sa liste, parce que l'arbre de processus d'électrons "parent" hébergerait la fonctionnalité principale, telle que le débogueur.
Cependant, les éléments (1) et (2) de la liste des défis de @bpasero resteraient. De plus, ajouter une communication de socket aux onglets de l'éditeur / panneau prendrait beaucoup de travail - si je ne me trompe pas, de nombreuses API internes devraient être mises à jour pour être asynchrones / basées sur la promesse au lieu d'être synchrones, ce qui serait un effort considérable. .
@vvavrychuk par "single-process" Je me réfère uniquement au contexte web (sans workers). Par "processus électronique", je voulais dire davantage un arbre de processus, qui inclurait un seul contexte Web accompagné d'un nombre quelconque de processus Node.js et de certains processus de chrome de fond. Sinon, je ne suis probablement pas la meilleure personne à qui demander.
+1
Des progrès à ce sujet? J'adorerais pouvoir utiliser VScode sur les deux moniteurs et partager des fichiers entre eux.
+1
Je pensais que tout le monde serait heureux de savoir - cette demande de fonctionnalité vient d'être classée # 4 par des votes positifs. Seulement 150 de plus et il sera dans le top 3!
+1
Je soutiens fermement la demande de cette fonctionnalité.
+1 Sera très utile pour les moniteurs plus grands ou multiples.
+1
J'utilise un moniteur 4k plus grand dans mon bureau à domicile, mais au bureau de mon travail où j'utilise 4 moniteurs plus petits, c'est un ralentissement. C'est le dernier morceau qui nous manque, comme d'autres l'ont dit d'un mouvement complet d'autres éditeurs.
@RoyTinker où est-ce que nous le votons?
@pantonis Veuillez cliquer sur l'icône "thumbs up" en bas du premier commentaire.
L'ajout d'un commentaire qui ne dit que "+1" n'aide pas et ne fait qu'encombrer la zone de discussion.
+1. Ici, nous travaillons avec back-end et front-end en même temps. Dans le moniteur principal, back-end; dans le 2ème, le front-end. C'est le même projet et le même espace de travail. Cela devrait nous permettre d'ouvrir plusieurs fenêtres avec le même espace de travail / projet.
Cela sera-t-il mis en œuvre prochainement? Je pense que les onglets doivent être libres de se déplacer n'importe où, tout comme les onglets Google Chrome. Se déplacer entre les fenêtres ouvertes ou lorsqu'il est glissé sur le bureau ouvrira une nouvelle fenêtre pour cet onglet. C'est très important.
+1
Pour l'amour de Dieu, veuillez faire en sorte que cela se produise!
Chaque fois que je mets à jour mon joli vscode, j'essaye de détacher un onglet et ça ne marche pas! allez les gars, cela a déjà été demandé dès le premier jour.
Pas de feuille de route pas de jalon pas de promesses, que se passe-t-il!
800 votes positifs maintenant! Ceci est 3e par pouces vers le haut et est 2e en nombre de commentaires
J'adorerais également avoir cette fonctionnalité.
+1 D'accord, j'aimerais pouvoir faire glisser mes onglets dans leurs propres fenêtres. Ne pas pouvoir le faire va en quelque sorte à l'encontre de l'objectif d'avoir plusieurs moniteurs.
Seulement 42 33 22 17 8 2 0 votes de plus et ce numéro sera n ° 1.
+1
@tavuntu Le problème de commenter simplement avec +1
rend inutile l'encombrement et spams les personnes qui regardent ce problème avec une notification inutile.
Vous voulez voir cette fonctionnalité mise en œuvre? Ajoutez une réaction 👍 au message original et cela suffira, inutile de commenter le commentaire redouté +1
.
Même mon commentaire est méta car il fait la même chose (plus de fouillis) et ne devrait pas être requis. Cela a déjà été discuté dans ce fil .
Néanmoins , venant de Sublime Text, cette fonctionnalité était quelque chose que j'ai vraiment apprécié et que j'aimerais voir un jour dans VSCode.
@ V-ed
Cela signifie que nous réalisons une faille dans le système de réaction de GitHub. Il doit y avoir une interface utilisateur supplémentaire pour "+1 à cette fonctionnalité" si le fil de discussion est considéré comme une demande de fonctionnalité . Mais j'espère que quelqu'un avec plus d'influence pourra prendre cela sur GitHub.
@ketozhang
En effet, et je me souviens avoir vu quelqu'un parler d'une idée pour que GitHub implémente un système automatique de « +1
to top-post 👍 conversion», ce serait formidable pour ceux qui sont encore dans l'esprit de +1 ajouter leur vote. Votre idée d'une interface utilisateur appropriée pour +1 une demande de fonctionnalité / "J'ai ce problème!" pour les problèmes serait génial! La chose est ...
Cette discussion sort du cadre de ce fil et pourrait être discutée ici (hé, en fait, c'est déjà tout ce que nous avons dit jusqu'à présent! _Cependant, les espoirs diminuent de plus en plus avec le temps ..._ _ ou est-ce? _ ) - j'espère que quelque chose se passera en ce qui concerne ce problème. En en parlant ici, nous ne faisons qu'empirer les choses - rendez-vous de l'autre côté de la force et passez une bonne journée!
J'utilise vscode pour travailler sur une grande solution c #, en particulier, des fichiers 19644
c #. Visual Studio 2017
meurt avec une exception de mémoire insuffisante. Les onglets / éditeurs flottants sont indispensables, en particulier lorsque vous travaillez avec une configuration à deux moniteurs.
Cette demande de fonctionnalité est désormais n ° 1 par les votes positifs. On l'a fait! 🥇
Je pense que Xcode fait très bien cela si vous cherchez de l'inspiration.
Cela devrait être fait au début, lorsque vous commencez à écrire cet éditeur. Des onglets / panneaux mobiles en dehors de la fenêtre principale (avec la possibilité de coller à la fenêtre principale) sont la fonction principale de chaque éditeur réel, en particulier avec les grands écrans 4k actuels et les ensembles multi-moniteurs (dans le cas des programmeurs professionnels).
C'est juste une base, cela nécessite la conception de l'API appropriée pour la communication entre Windows et leur gestion, et après cela, vous devez construire le reste en plus de cela. Vous êtes actuellement dans une situation difficile pour le résoudre d'une manière ou d'une autre, sans corrompre tout ce qui a été créé jusqu'à présent, mais plus tôt vous relevez ce défi, mieux ce sera pour tout le monde, après avoir passé plus de temps et l'écriture de plus de code peut être trop tard pour un tel changement.
Dans le monde réel, nous devons voir beaucoup plus que le panneau gauche / droit / inférieur, cette solution https://github.com/Microsoft/vscode/issues/10121#issuecomment -335013296 est excellente.
Le ton condescendant ne résout pas les bogues. Veuillez utiliser 👍pour voter.
Cette fonctionnalité est demandée depuis des années maintenant ... Veuillez l'implémenter.
Pour ceux qui veulent simplement ouvrir des fichiers dans de nouvelles fenêtres et qui ont été dirigés vers cette page par Google, utilisez le raccourci clavier pour "Ouvrir les fichiers actifs dans une nouvelle fenêtre";
Ctrl + K, O
C'est une fonctionnalité tellement basique, j'ai d'abord pensé que l'absence de la fenêtre flottante était un bug: ')
Veuillez l'équipe VS Code, nous en avons besoin!
Support multi-écran complet !!
Ce fil était ouvert il y a 1 an 6 mois et 4 jours ....
Edit: Par mal, bpasero a répondu au fil de discussion il y a un an, espérons simplement que l'équipe prendra ce problème comme problème de référence pour l'élément de plan de mise en page Explore UX for flexible workbench sur le plan d'itération de février 2018 !
@Aetherall et autres, veuillez lire plus loin le fil. Benjamin Pasero a répondu à plusieurs reprises. C'est un membre de l'équipe VSCode.
N'oubliez pas non plus qu'il s'agit d'un projet open source. Certains commentaires semblent supposer que MS nous doit quelque chose ici ... pas vrai.
Peut-être que VSCode est tellement génial que les gens supposent parfois que c'est commercial :-)
@patrys c'est le problème le plus voté et je suis sûr que vous le savez, mais oui, vous avez raison, cela ne sera pas résolu par magie, il faut du temps et des efforts, et les gens (comme @Aetherall l'a dit) semblent penser c'est un logiciel commercial (cela a commencé comme une belle demande mais maintenant cela semble être une forte exigence)
Déchirer l'onglet est le comportement que je souhaite (de la même manière que cela fonctionne dans le navigateur Chrome). Cependant, je me contenterais de toute possibilité de déplacer / ouvrir rapidement quelque chose dans une nouvelle fenêtre, comme une option de menu contextuelle. À l'heure actuelle, je dois ouvrir un nouveau VSCode et rouvrir manuellement le fichier. Dans les deux cas, je ne souhaite pas une fenêtre flottante comme dans Visual Studio. Je veux qu'il génère une nouvelle copie de VSCode. Les fenêtres flottantes se perdent, je veux juste une nouvelle fenêtre ...
Agréable
@inarius voir le commentaire de @ christopher-howard ci-dessus.
Merci @RoyTinker. Je ne trouve pas du tout d'option de menu pour cela et je suis assuré d'oublier le raccourci, mais cela fonctionne! Je pense que ce serait une bonne option d'exposer dans le menu contextuel de l'onglet actif et / ou des éléments dans l'explorateur de documents Open Editors.
Je viens également de trouver que le numéro 8171 semble être exactement ce que je veux . Peut-être que les gens qui votent là-dessus devraient aller vérifier celui-là!
TIL, faire glisser des onglets sur une autre fenêtre vscode ouvre également le fichier sur cette fenêtre. Malheureusement, il ne ferme pas l'ancien onglet qui est attendu pour l'idée de fenêtre flottante.
Ce comportement me déroute. Ceci est similaire à l'ouverture des onglets d'aperçu Markdown qui se duplique également parfois.
Salut @ketozhang ,
Malheureusement, il ne ferme pas l'ancien onglet qui est attendu pour l'idée de fenêtre flottante. Ce comportement me déroute.
Curieusement, j'ai vraiment apprécié ce comportement - utile pour faire référence à partir du même document, comme lors de la création d'une nouvelle vignette. Je suis convaincu que c'est la décision de conception derrière cela, mais je serais intéressant de savoir le contraire.
Cordialement
Sonnerie avec un mouvement pour se détacher, en particulier la fenêtre de surveillance
+1
J'ai récemment étudié les moniteurs ultra larges et avec le nouvel écran, je voudrais l'utiliser pour une productivité maximale. Visual Studio 2017 gère cela assez bien pour faire glisser des onglets pour devenir de nouvelles fenêtres, donc j'espère que nous verrons quelque chose comme ça dans un proche avenir.
+1. Ce serait vraiment génial d'avoir la possibilité de faire glisser des onglets sur différents moniteurs pour en faire une nouvelle fenêtre.
++
Vraiment, il y a beaucoup de gens qui travaillent avec deux moniteurs. Donc je n'aime pas voir les informations de sortie sur mon code.
Je ne dois voir que du code. Donc, je serai miracle si l'utilisateur peut déplacer le terminal / la sortie / l'onglet vers un autre moniteur, ou faire cette fenêtre flottante. Et plus tard, sélectionnez la fenêtre nécessaire par Cmd + ~ par exemple ou voyez les résultats sur un autre écran.
@bpasero pourquoi pas une nouvelle instance complète avec tout le contexte du navigateur, je
Cette fonctionnalité ancrable dans la fenêtre est déjà VSCode. Mais, je ne sais pas récemment pourquoi cela ne fonctionne pas ...
+1. Faire glisser un onglet en dehors de la fenêtre devrait se diviser en une nouvelle fenêtre comme pratiquement toutes les autres applications à onglets.
Les onglets ne sont pas ma priorité. Mais le débogage détachable serait vraiment bon.
Ce numéro est désormais ouvert depuis près d'un an et demi. Veuillez donner quelques réponses sur l'état actuel de cette fonctionnalité.
Faire glisser des onglets en dehors de la fenêtre VS Code copie actuellement le fichier (ou un raccourci vers celui-ci?) Vers la cible de glissement. Ceci est assez peu intuitif par rapport aux autres IDE.
À bien y penser, l'absence de fenêtres flottantes (comme VS proprement dit) est mon seul vrai problème avec VS Code. Il doit être mis en œuvre.
@belst et d'autres voient ce commentaire , étant donné la conception actuelle, il est assez difficile d'implémenter cette fonctionnalité
@Jorilx savez-vous s'il y a un problème lié à l'électron quelque part?
Ce serait vraiment bien de voir la prise en charge de plusieurs écrans ou fenêtres flottantes. Pour l'instant, je dois redimensionner manuellement la fenêtre pour l'adapter à mes deux moniteurs (la ligne rouge est le bord du moniteur), ce qui n'est pas confortable.
Pour moi, en ce moment, c'est la fonctionnalité la plus nécessaire en matière d'UI / UX.
+1! <3
@kodipe Pas idéal, mais il existe une solution de contournement pour votre situation en ce moment. Enregistrez votre projet en tant qu '"espace de travail", puis ouvrez un fichier, utilisez le raccourci clavier Ctrl + KO (comme je vois que vous êtes sous Windows) qui est d'afficher le fichier actif dans une nouvelle fenêtre / instance. Ajoutez maintenant le dossier racine du référentiel dans cette nouvelle fenêtre / instance (car il s'agit maintenant d'un nouvel espace de travail) ... Vous avez maintenant deux fenêtres utilisant le même espace de travail sur deux moniteurs. Comme je l'ai dit, ce n'est en aucun cas idéal, mais c'est ce que j'ai utilisé comme solution de contournement en utilisant la fonction d'espaces de travail.
C'est un must pour avoir une fonctionnalité d'interface utilisateur. Cela paralyse l'expérience et la productivité du travail quotidien.
Bump, c'est la seule chose qui m'empêche de passer complètement à VS Code.
Je comprends le fait qu'il existe des complexités techniques pour implémenter cette fonctionnalité.
Cependant, le fait qu'il n'y ait aucune indication d'activité sur cette demande est tout simplement ridicule à ce stade. Cela doit être l'une des fonctionnalités les plus demandées, et il n'y a littéralement aucune communication de la part de l'équipe vscode reconnaissant quand ou si elle prévoit de faire quoi que ce soit.
C'est un produit gratuit et Microsoft ne nous doit rien. Cela ne veut pas dire que je ne suis pas extrêmement irrité que cette fonctionnalité ne soit même pas sur le radar. Il existe plusieurs pages de problèmes Github demandant cette fonctionnalité. VsCode est un excellent IDE, mais l'absence de cette fonctionnalité en 2018 lorsque nous avons tous plusieurs moniteurs est juste embarrassante.
À tous ceux qui essaient d'excuser cela en raison de limitations techniques: rappelez-vous que quelqu'un a eu l'occasion d'évaluer une plate-forme / un langage sur lequel construire vscode, et ils ont décidé d'un cadre qui a un défaut très évident. Je suis honnêtement fatigué d'essayer d'obtenir une communication de l'équipe vscode.
Si cela n'est pas ajouté bientôt à la feuille de route de vscode, je pense que je vais trouver un nouvel IDE.
@BentOnCoding Je conviens que l'absence de cette fonctionnalité est incompréhensible, mais comme vous l'avez dit, ils ont choisi un cadre qui n'est pas tout à fait adapté à la création d'EDI, donc l'ajout de cette fonctionnalité serait un effort majeur et il semble qu'ils ne soient pas prêts à le faire .
Question honnête, Atom n'est-il pas également implémenté dans Electron, et ne supportent-ils pas correctement les onglets détachables? Leur implémentation n'est pas adaptée à l'architecture de VScode, n'est-ce pas?
@ruippeixotog Je ne pense pas
@belst Il
Si Code autorisait plusieurs fenêtres du même espace de travail, même sans le glissement-tab-pour-nouvelle-fenêtre, ce serait mieux que d'avoir à créer un nouvel espace de travail pour autoriser plusieurs fenêtres.
Cette confusion entre le mouvement des onglets et les fenêtres détachables est exactement la raison pour laquelle je ne supporte PAS les onglets détachables. Le mouvement des onglets devrait engendrer un nouveau processus dans une nouvelle fenêtre. Je veux qu'il fonctionne exactement comme le navigateur Chrome.
L'équipe VScode a répondu à ce sujet pour discuter de la difficulté. Puisqu'il existe plusieurs approches à cela qui pourraient être adoptées, et plusieurs problèmes en suspens qui ont été combinés dans celui-ci, j'espère qu'ils fourniront au moins des conseils sur l'approche qu'ils préfèrent ici afin que cette demande de fonctionnalité ne s'enlève pas. discussion improductive.
Ce problème n'a vraiment pris de l'importance qu'au cours des 3 derniers mois environ. J'imagine qu'il y a encore des discussions internes en cours.
J'aimais aussi extraire les onglets et les fenêtres de Visual Studio; Je suis sur un Mac maintenant et j'utilise VSCode. Très déçu de constater que cette fonctionnalité n'est pas prise en charge. L'expérience a été proche de Visual Studio et de l'extension Python Tools pour Visual Studio, mais il manque encore certains des avantages.
Je vais vous abonner à ce problème pour obtenir un ping lorsque cette excellente fonctionnalité est présente.
Je vais simplement laisser mes deux morceaux ici aussi. Suivre ce fil pendant longtemps et ne toujours pas l'avoir fin mars 2018 (presque 2 ans) est tellement dommage. Croiser mes doigts pour l'avoir disponible bientôt.
C'est une fonctionnalité tellement basique, j'ai d'abord pensé que l'absence de la fenêtre flottante était un bug: ')
@Aetherall 👍 J'ai pensé la même chose! Puis je suis venu et j'ai trouvé ce fil ... :-(
C'est un logiciel gratuit. Vous n'avez rien payé pour cela. Si le fait de ne pas avoir cette fonctionnalité vous empêche vraiment d'utiliser VS Code, vous êtes libre de contribuer à une pull request qui implémente au moins certaines des modifications requises pour que cela fonctionne. Sinon, vous pouvez prendre votre zéro dollar et le dépenser ailleurs.
Ce que vous ne devriez pas faire, c'est pleurnicher et essayer de culpabiliser la formidable équipe derrière VS Code pour qu'elle se sente mal.
S'il y avait une meilleure alternative, vous l'utiliseriez au lieu de perdre votre temps dans ce fil, alors la prochaine fois, dites "merci" au lieu de "comment cela n'est pas encore fait".
@Nepoxx Vous pouvez toujours ouvrir un nouveau problème avec un titre comme «Discussion technique pour les fenêtres flottantes en cours» et un lien vers ce problème.
@Nepoxx Vous êtes ici juste pour donner votre avis sur les opinions et les commentaires des gens. Commencez par la discussion technique et digne alors. Nous connaissons tous les limites de la plate-forme, nous essayons de donner de la pertinence au sujet afin que l'équipe Microsoft accorde de l'importance au problème. Nous avons tous des besoins différents et vous ne devriez pas dire que les opinions des autres ne valent rien. Pourquoi suivez-vous ce fil de toute façon.
@patrys "vous êtes libre de contribuer à une pull request qui implémente au moins certaines des modifications requises pour que cela fonctionne"
Cela exigerait que l'équipe VSCode discute publiquement d'un plan de mise en œuvre de cette fonctionnalité très demandée. C'est un problème trop énorme pour quiconque de créer des relations publiques massives mettant en œuvre les _fonctionnalités les plus basiques_ — après tout, chaque fichier traitant des références à la fenêtre ou à l'espace de processus nécessiterait des mises à jour s'il n'est pas jeté et réécrit. Pensez-vous honnêtement que l'équipe vscode fusionnerait quelque chose qui change son produit à un niveau aussi fondamental quand elle ne le dirige pas? Je ne le ferais pas. La communauté ne peut pas contribuer tant qu'un tel plan n'est pas ouvertement discuté.
_ (La plupart) _ des personnes dans ce fil ne se plaignent pas "Je veux ça". ou "Faites-le parce que je suis trop paresseux pour le faire moi-même." La communauté est préoccupée car c'est une caractéristique si importante et il n'y a eu que peu ou pas de réponse de la part des principaux contributeurs - essentiellement, "c'est une question difficile".
Imaginez: vous montez dans un taxi et dites au chauffeur votre destination. Il gare ensuite la voiture. Vous attendez une minute, confus pourquoi vous ne bougez pas et demandez, "pouvons-nous y aller?" Pas de réponse. Une heure, vous posez la même question, et il répond, "il y a beaucoup de virages à faire pour y arriver", et n'en dira pas plus. Ne seriez-vous pas ... confus? frustré? c'est ce que nous ressentons. Mais nous ne sommes pas sur le point de simplement prendre le volant et de conduire nous-mêmes, ce n'est pas notre taxi.
Voici une suggestion pour tous ceux qui en font la demande, si les onglets non verrouillables ont une si grande valeur pour vous et votre entreprise. Pourquoi ne pas mettre en place un crowdfunding pour cela?
Si vous pouvez vous permettre 4 moniteurs juste pour augmenter la productivité, je suppose que vous pouvez également vous permettre de dépenser de l'argent pour le développement d'une telle fonctionnalité.
Désolé
@bpasero peut-être
Désolé si je me trompe, mais il existe une sorte de support pour plusieurs fenêtres: https://www.npmjs.com/package/electron-window-manager
Si l'UX du code VS fonctionnait comme celui de l'atome, je ferais le changement. Tel quel, je continue d'installer du code VS, aimant presque tout et finalement désinstallant quand je réalise que l'UX n'a toujours pas été mis à jour. Regardera ce problème, veuillez le corriger.
Je dirais que la plupart des gens ici manquent le point: le code VS n'est pas un IDE, c'est un éditeur de code. Avec quelques fonctionnalités intéressantes ajoutées dans (débogage), un support brillant pour plusieurs langues via des plugins, des plates-formes croisées, etc. Une chose n'est pas, c'est l'IDE.
C'est pourquoi c'est ma valeur par défaut pour un petit écran (c'est-à-dire un ordinateur portable, car il gère l'immobilier de manière brillante) et des plateformes autres que Windows. Sur un poste de travail approprié, j'utilise Visual Studio. C'est ça.
Les bons IDE sont des outils assez coûteux. Regardez JetBrains - ils ont réussi à construire ces choses;)
@mdmnk Non. C'est un IDE.
notepad.exe
est un éditeur de texte, notepad++
est un éditeur de texte, vscode
avant le terminal intégré, les exécuteurs de tâches, scm et debug _ était _ un éditeur de texte. _Quelles sont les fonctionnalités des autres IDE que vscode
n'ont pas? _ Il y a certaines choses dont je suis sûr, mais pas beaucoup.
C'est certainement léger lorsque vous n'installez pas 1000 plugins. Cela ne me dérange pas d'ouvrir vscode
pour modifier ~/.bash_profile
car je n'ai pas à attendre 4 minutes comme je le ferais avec Visual Studio ou WebStorm.
@rozzzly Visual Studio, au moins, a un grand ensemble de fonctionnalités que vscode n'a pas. Profil d'exécution pour .NET, outils SQL Server, un système de gestion de test massif, des outils Azure (cloud MS), un suivi intégré des tâches / PR / problèmes - pour en rappeler quelques-uns. C'est un produit vraiment massif. Par cette mesure, VSCode n'est qu'un éditeur, malgré le débogage intégré / etc. - il n'est pas livré avec tout ce dont vous avez besoin pour développer et expédier des logiciels à grande échelle ... pas même de près.
@rozzzly -même le team building, il se réfère à lui comme éditeur plutôt que IDE donc clairement il n'y a pas de lecteur pour le faire exploser complètement IDE.
Ces choses coûtent de l'argent.
Regardez ce que @RoyTinker a mentionné. Ajoutez une couverture de code, des services d'équipe, des outils de fusion de conflits, une personnalisation complète de la mise en page, un gestionnaire de packages intégré, un explorateur de cloud, un explorateur SQL, un explorateur de serveur, des informations sur les applications, une vue de classe, un navigateur d'objets, etc.
VS Code est un outil assez étonnant. Pourtant, il est gratuit, ce qui signifie dès le départ qu'il aura des limites.
Vous ne l'aimez pas, allez payer JetBrains ou Microsoft pour quelque chose qui a toutes les fonctionnalités dont vous avez besoin.
J'espère que nous pourrons arrêter de discuter des obligations de cet outil pour implémenter certaines fonctionnalités. Cela semble être un moyen rapide de verrouiller ce sujet. Je continuerai à partager le support de cette fonctionnalité avec des pouces vers le haut et de rares commentaires constructifs.
Il y a plusieurs façons d'aborder cela, je pense toujours que nous avons besoin de conseils généraux de la part de l'équipe VSCode avant que quiconque puisse diriger son soutien vers d'autres formes d'aide constructive. Comme d'autres l'ont mentionné, personne ne peut vraiment commencer à travailler sur une fonctionnalité aussi importante que celle-ci jusqu'à ce qu'il y ait une certaine assurance que le travail sera accepté.
@ michaljaros84 Le fait que VS Code ne soit pas destiné à être un IDE comme Visual Studio n'empêche pas du tout les améliorations UX telles que les fenêtres flottantes en cours de processus.
@RoyTinker Peut-être pouvons-nous discuter des
Le fait que Code soit un IDE ne signifie pas que nous devons porter tous les choix UX terribles pour les VS comme les panneaux flottants.
Je ne vois pas l'intérêt d'augmenter considérablement la complexité si la même fonctionnalité peut être obtenue en engendrant un nouveau processus.
La même fonctionnalité ne peut pas être obtenue en engendrant un nouveau processus, car, AIUI, pour les langages qui ont des outils basés sur LSP, les deux processus ne pourraient pas tous les deux parler au même serveur de langue, vous n'auriez donc que le serveur basé sur LSP. fonctionnalités dans l'un d'eux.
@inarius Bien sûr, bien que cela ait déjà été discuté ci-dessus (voir mon commentaire "20% d'effort / 80% d'avantages" ). Si je comprends bien, le cas d'utilisation est de mieux prendre en charge plusieurs moniteurs.
Pour diverses raisons (comme celle mentionnée par @HighCommander) VS Code ne démarre qu'un seul espace de travail par dossier (et actuellement un seul espace de travail ne peut pas s'étendre sur plusieurs instances).
Merci pour les réponses. Je suppose que je peux comprendre cela. Pour être honnête, j'utilise souvent VS Code en ouvrant des fichiers et non des dossiers. Si je travaillais sur un projet git, je pouvais voir comment mon flux de travail actuel consistant à ouvrir une nouvelle fenêtre et à y faire glisser des fichiers me permettrait uniquement d'effectuer des actions de dossier / git à partir de la fenêtre d'origine.
Quand j'essaye cela maintenant, le nouvel espace de travail ne rouvre certainement pas le dossier, mais les actions git restent même si je travaille avec des fichiers sous le répertoire du référentiel.
@ Krzysztof-Cieslak Les panneaux flottants sont conçus pour être entièrement facultatifs dans Visual Studio (c'est-à-dire qu'aucune fonctionnalité ou flux de travail ne nécessite que vous les utilisiez), donc je ne vois pas en quoi c'est un mauvais choix UX, même du point de vue des gens qui ne le font pas. Je ne veux pas les utiliser.
C'est dommage que ce ne soit toujours pas possible, les personnes avec une configuration multi-écrans en profiteraient beaucoup.
Alors votez pour la fonctionnalité 💃
Un moyen acceptable d'autoriser l'utilisation de plusieurs fenêtres pour stocker ces fenêtres dans la configuration de l'espace de travail? Je pourrais imaginer avoir un moyen de suivre les fenêtres une fois qu'elles sont ouvertes. Je pourrais faire quelques recherches plus tard dans le code pour voir si je pourrais trouver un moyen d'avoir au moins un espace de travail sur plusieurs fenêtres.
Au moins, supprimez la restriction très arbitraire sur l'ouverture du même dossier dans plusieurs fenêtres.
@TedYav Cette restriction a des raisons techniques - voir # 2686 pour plus d'informations et discussion.
Donc, la référence dans le plan d'itération n ° 47369 n'est qu'une blague sur l'obtention d'un moniteur 4k plutôt qu'un plan pour soutenir cela?
@hosaka Correct, même si je n'avais pas l'intention de sarcasme dans mon commentaire. J'espère que ça ne s'est pas passé de cette façon.
@RoyTinker Pas du tout, mais je clarifierais pour que les autres qui lisent n'espèrent pas :)
Bosse. Je voudrais moi aussi faire glisser les onglets de code sur le bureau pour les modifier dans une nouvelle fenêtre
Étant un utilisateur de longue date de Visual Studio, notepad ++, travaillant pendant des années avec 3 moniteurs (21-25 pouces), c'est en fait la seule fonctionnalité qui, après quelques heures d'utilisation de Visual Studio Code, m'arrête de l'utiliser. Je l'ai essayé plusieurs fois. Mais pour moi ergonomiquement très inconfortable et fatiguant à un degré qui me fait repartir. Ce serait vraiment génial d'avoir ça.
Wow, c'est de loin la fonctionnalité la plus recherchée! : sweat_smile:
^^ https://github.com/Microsoft/vscode/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
Et étonnamment, les fonctionnalités suivantes les plus recherchées sont très liées: +1:
En ce moment, j'utilise vscode 1.22.0 avec plusieurs moniteurs et le raccourci CTRL+k o
pour ouvrir un onglet dans une nouvelle fenêtre. Cela fonctionne plutôt bien pour moi: sweat_smile:
Ce qui veut dire quoi exactement? Existe-t-il une estimation du moment où les 3 principales fonctionnalités auront été mises en œuvre?
Op 9 janv. 2018 03:15 am schreef Roy Tinker [email protected] :
Je pensais que tout le monde serait heureux de savoir - cette demande de fonctionnalité vient d'être classée # 4 par des votes positifs. Seulement 150 de plus et il sera dans le top 3!
-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/Microsoft/vscode/issues/10121#issuecomment-356148693 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AD90FPGlliOcLwiQbPIMFB5fITE42- 5Tks5tIr3GgaJpZM4JckZO .
Les gens votent contre parce que vous n'ajoutez rien à la discussion, mais tous les abonnés à ce problème reçoivent votre commentaire par e-mail.
Existe-t-il une estimation du moment où les 3 principales fonctionnalités auront été mises en œuvre?
Certaines fonctionnalités ont pris 2 ans entre le moment où elles ont atteint leur importance et le moment où elles ont été expédiées.
C'est maintenant en forte demande depuis 2 (DEUX!) Ans. Je dois dire, surtout compte tenu du fait que Microsoft considère que c'est son «éditeur de code officiel», c'est très décevant. Je n'arrête pas de m'en servir, car à chaque fois que j'essaye, cela (et quelques autres fonctionnalités manquantes) me ralentit énormément.
Je pense qu'il est grand temps, au moins pour une déclaration définitive:
@Hypernut En fait, les votes pour cette question n'ont vraiment commencé à décoller qu'en décembre de l'année dernière. Regardez dans l'historique des commentaires et vous verrez un message de (IIRC) il y a moins de 8 mois disant "Seulement X votes de plus et ce sera dans le top 10."
EDIT: Lien de commentaire ici: https://github.com/Microsoft/vscode/issues/10121#issuecomment -339404507
«104 votes de plus pour faire partie du top 10» au 25 octobre 2017.
Je veux vraiment cette fonctionnalité aussi - principalement pour avoir juste la fenêtre de débogage sur un moniteur différent.
Une solution plus simple à implémenter (?) Pourrait être d'autoriser une nouvelle fenêtre (CTRL + SHIFT + N) pour ouvrir le même projet (ce n'est actuellement pas autorisé). Vous pouvez alors ouvrir tous les onglets dont vous avez besoin dans cette nouvelle fenêtre, ou si vous voulez simplement avoir la console de débogage ici, vous pouvez l'agrandir pour remplir la fenêtre. Cela fonctionnerait tant que les fenêtres restent synchronisées et que tous les changements de code / messages de débogage, etc. sont immédiatement mis à jour dans toutes les instances de fenêtre.
Veuillez ajouter cette fonctionnalité. Je dois ouvrir les deux codes VS pour imiter ce comportement ... Ce qui serait génial si cela était intégré.
Pourquoi les votes négatifs @minajevs , @ djm158 et @JustinAddams? J'ai déclaré la même chose que tout le monde a fait pour soutenir cette fonctionnalité.
@faustinoaq Oui. OUI! Merci merci merci!
Pour l'instant, au moins, Cmd-K o est assez bon pour moi - ouvrir un fichier source dans une fenêtre détachée. J'ai vu quelqu'un demander la même chose pour les fenêtres de démarque ... ne pas utiliser cela, mais ne devrait pas être trop difficile à réaliser avec la même solution, non? Ou peut-être est-ce déjà possible d'utiliser Cmd-K o?
Merci @steinhh pour la combinaison de clavier Cmd
- K
O
. Je n'étais pas encore au courant de cela et je vais l'utiliser la semaine prochaine sur un système multi-écrans pour voir à quel point cela fonctionne.
Votre astuce m'a amené à trouver les PDF ci-dessous et à faire les listes / captures d'écran ci-dessous également.
Terrifiant! Merci merci!
Les liaisons (sur Mac) que j'ai trouvées avec leurs captures d'écran:
Cmd
- Shift
- P
: afficher toutes les commandesCmd
- K
O
: ouvrir le fichier actuel dans une nouvelle fenêtreCmd
- Shift
- N
: ouvre une nouvelle fenêtreCmd
- K
Cmd
- R
: ouvrir le PDF de référence des raccourcis clavier pour le système d'exploitation actuel dans le navigateur Web par défautCmd
- K
Cmd
- S
: ouvrir l'éditeur de raccourcis clavierL'éditeur de raccourcis clavier a une recherche qui peut trouver des liaisons sur le nom de la combinaison de touches lui-même ou le nom de la commande:
Quand je suis passé à VSCode, j'en suis tombé amoureux. C'est tellement facile à utiliser et rapide sur mon ordinateur lent!
Mais après l'avoir utilisé pendant les 15 premières minutes, j'ai manqué cette fonction. J'ai 3 moniteurs et je travaille généralement avec 2 fichiers en même temps ...
@steinhh C'est bien, mais ce n'est pas du tout ce qui est décrit dans l'OP.
"_... option de fenêtres flottantes pour:
TerminalConsole de débogageProblèmesSortie _
"
Toute nouvelle fenêtre ouverte avec le raccourci, a toujours toutes ces sous-fenêtres attachées.
@RoyTinker
Excusez-moi d'être si insouciant. Je suis sûr que la demande est soudainement apparue "en décembre dernier". Avant cela, personne ne voulait ou même ne savait à propos des fenêtres flottantes. :)
Quoi qu'il en soit, le fait est que la demande est élevée MAINTENANT et elle est absolument ignorée.
@Hypernut Je ne suis pas un membre de l'équipe VSCode, et je ne parle pas non plus pour eux. J'essaie simplement d'aider à définir les attentes en fonction de mes observations de leur comportement passé et du moment où cette fonctionnalité serait apparue pour la première fois sur leur radar «La demande des utilisateurs est élevée».
@algiuxass Même chose ici. Je suis surpris de voir que cela n'a toujours pas été ajouté. C'est mon plus grand désir de voir ajouté avec vscode. Je ne suis pas un développeur d'électrons, alors idk s'il s'agit d'une limitation des applications d'électrons ou si cela peut être fait.
@RoyTinker
Je sais que vous ne parlez pas au nom de l'équipe VSC. Mais pourquoi ressentez-vous le besoin de «fixer des attentes»?
Je pense que 8 mois sont plus que suffisants pour au moins nous donner une idée de ce à quoi nous attendre. Surtout compte tenu de la spéculation dans ce fil, que cela pourrait ne pas être possible du tout.
@Hypernut Puisque l'équipe VSCode n'a donné aucune indication sur son calendrier ou ses projets concernant cette fonctionnalité, il existe un réel vide d'informations, ce qui laisse les gens très frustrés. J'essaie d'aider avec cela en utilisant des données du passé.
Je ne défends pas l'équipe VSCode ou quoi que ce soit, agissant simplement sur ma conviction que les plaintes / etc. dans les commentaires n'aidera pas beaucoup. Comme je l'ai déjà dit, la meilleure façon d'attirer leur attention est qu'un _lot_ de personnes ajoute leur vote à la question.
Si vous souhaitez passer du temps à aider sur ce problème, je suggère d'aller dans d'autres endroits en ligne où les personnes qui souhaitent cette fonctionnalité pourraient se retrouver (Stack Overflow, reddit, etc.) et de créer un lien vers ce problème.
Bonjour l'équipe VS, VEUILLEZ implémenter cette fonctionnalité. Ce n'est pas vraiment "beaucoup", mais c'est une fonctionnalité disponible dans d'autres éditeurs qui manque cruellement. En fait, c'est la seule fonctionnalité qui m'empêche d'utiliser exclusivement VS Code.
J'ai fait des recherches sur le problème des fenêtres flottantes (mes connaissances avec l'électron sont presque inexistantes). Il semble qu'électron prend en charge les fenêtres sans cadre, cela ne pourrait-il pas résoudre le problème en créant simplement une fenêtre sans cadre lorsqu'un utilisateur fait glisser le fichier vers l'extérieur comme sur Visual Studio?
https://github.com/electron/electron/blob/master/docs/api/frameless-window.md
@ Trevinlc1997
Oui, à petite échelle d'une application, cela peut être aussi simple que cela
VSCode est un programme complexe, ils ne peuvent pas patcher les fonctionnalités sur le noyau, ou cela deviendrait un cauchemar à maintenir et à améliorer (il suffit de cloner le dépôt pour voir ce qui se passe à l'intérieur de la bête)
Mes suppositions (je me trompe peut-être):
S'ils veulent ajouter cette fonctionnalité, ils voudront la mettre en œuvre de manière à permettre son plein potentiel
L'équipe VSCode a pris connaissance de la demande pour cette fonctionnalité, et le problème sera plus facile à gérer lorsque d'autres fonctionnalités seront implémentées, donc afin d'éviter un défilement de 500m d'explications / discussions, ils préfèrent ne rien dire du tout
Comment n'est-ce pas encore une fonctionnalité, c'est la seule fonctionnalité qui m'empêche d'utiliser exclusivement VS Code.
C'est le protocole Language Server qui m'a attiré vers VSCode en premier lieu.
À la suite de ce problème, j'ai plutôt contribué à la prise en charge du protocole Language Server dans Eclipse.
j'adore VSCode. c'est la seule chose que je n'aime vraiment pas. cela semble si évident en tant que fonctionnalité, même dans l'éditeur le plus minimaliste. toute personne avec une configuration multi-moniteurs qui essaie de faire glisser un onglet d'éditeur hors de la fenêtre a ressenti la douleur de la déception en le voyant revenir d'où il venait. L'équipe VSCode, veuillez s'il vous plaît mettre cela plus haut sur votre liste!
+1. Ce serait bien d'avoir similaire à PyCharm / CLion.
Semble qu'une nouvelle fonctionnalité a été ajoutée pour servir de contournement pour cela.
"Dupliquer l'espace de travail dans une nouvelle fenêtre".
Cela semble partager le contexte / l'espace de travail entre les fenêtres et résout le problème de base du multi-moniteur.
Merci à l'équipe VSCode (et à tous ceux qui y ont travaillé).
Ils proposent également une nouvelle fonctionnalité de grille. https://twitter.com/joaomoreno/status/1004303587755855872?s=19
Oui, ça l'est!
Yehya Abouelnaga [email protected] schrieb am Fr., 8. juin 2018 um
12:22 Uhr:
@Deltatiger https://github.com/Deltatiger Est-ce déjà expédié?
-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/10121#issuecomment-395718792 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEVMyNsBaeorg-rczkcZsifgpi-jtPR7ks5t6lB7gaJpZM4JckZO
.
@Deltatiger
Si votre objectif est de pouvoir redimensionner et se déplacer librement, par exemple le terminal ou la sortie (comme décrit dans l'OP), cela ne résout rien.
La prise en charge de plusieurs écrans n'est de loin pas la seule raison de vouloir cette fonctionnalité.
@Hypernut Je suis totalement d'accord.
J'ai utilisé cette fonctionnalité comme solution de contournement dans le sens où je peux maintenant avoir une fenêtre (la fenêtre d'origine) pour tous les Output / Git / Terminal et créer une nouvelle fenêtre pour le code réel.
De cette façon, j'obtiens plus de biens immobiliers tout en gardant un œil sur le terminal / la sortie, ce qui, je crois, est l'une des principales raisons des fenêtres flottantes. Mais c'est mon point de vue.
Il y a eu également des discussions sur le codage multi-fenêtres (suggestion originale de Ctrl + K, O pour ouvrir une nouvelle fenêtre), alors j'ai pensé que je clarifierais simplement cette partie ici pour toutes les personnes à la recherche de cette fonctionnalité.
Mais cela ne donnera jamais la même liberté que de faire glisser librement des mini fenêtres spécialisées (disons une pour Terminal, une pour git et une pour, disons, un deuxième terminal).
Si cette fonctionnalité peut être mise en œuvre, ce serait génial.
Par curiosité, pourquoi voudriez-vous séparer le terminal dans une nouvelle fenêtre? Ne serait-il pas préférable d'ouvrir simplement un nouveau processus de terminal en dehors de VSCode?
@ iansan5653 Alors pourquoi mettre un terminal en VSCode en premier lieu? Pourquoi pas une application git séparée? Un explorateur de fichiers? Supprimer tous les plugins et ne donner qu'une fenêtre de code?
@ iansan5653 c'est mon cas:
J'utilise souvent WebStorm (qui a une telle fonctionnalité). Mon poste de travail est composé d'un ordinateur portable et d'un moniteur supplémentaire, qui est tourné verticalement pour une meilleure lecture. Ainsi, je configure l'IDE pour qu'il apparaisse comme suit:
Pourrais-je vivre sans cela? Ouais, bien sûr. Mais je trouve toujours cela agréable.
Je préfère que l'équipe de Visual Studio (appropriée) devienne meilleure pour prendre en charge le développement / le débogage d'applications côté client. Cela dit, c'est l'une des principales raisons pour lesquelles je ne peux pas utiliser VSCode pour le débogage.
Lorsque vous utilisez la fonction "Comparer le fichier avec la révision précédente", il peut être presque impossible de voir certains diffs sans avoir à aller en fin de ligne, car l'éditeur est divisé en deux sur un seul écran. Avoir la possibilité d'ouvrir les deux versions dans deux fenêtres serait un véritable économiseur.
Je pense qu'il a besoin de cette fonction.
Notepad++
a cette fonction pour faire flotter la fenêtre, mais je ne trouve pas que vs code
a.
Donc, si je veux faire flotter la fenêtre sur mon autre écran, je dois encore ouvrir une nouvelle fenêtre puis ouvrir mon fichier, je pense que c'est trop laborieux à utiliser.
Veuillez donc ajouter cette fonction.
Et quelqu'un qui a un bon moyen de le résoudre?
Merci!
PS Il y a quelqu'un qui ne donne que des emojis, mais pas pour essayer d'écouter une autre idée ou de donner des moyens de la résoudre. Je pense que je mépriserai ces personnes
Certaines personnes n'aiment tout simplement pas les mauvaises critiques et les lacunes, elles savent comment laver le sol, elles soufflent et les ignorent, elles ...
Je pense que ces personnes ne peuvent probablement pas communiquer avec nous.
Je voudrais les fenêtres flottantes / dockables et les positions enregistrées pour le prochain chargement. Actuellement, je peux étirer les fenêtres sur plusieurs moniteurs, mais la position est réinitialisée à la valeur par défaut lors de la prochaine ouverture. La plupart du temps, je n'aime pas les positions par défaut des volets et je veux les déplacer.
@ CHN-STUDENT Je pense que les gens donnent: -1: votes parce qu'ils conviennent que nous en avons besoin (ce fil a 270 commentaires et est le plus: +1: question votée). Le sujet ne concerne plus ce que nous voulons ou pourquoi , mais comment nous pouvons l'implémenter, alors essayons de garder la conversation positive et concentrée sur la façon d'aider à mettre en œuvre cette fonctionnalité. :)
Cette fonctionnalité manquante est la principale raison pour laquelle je ne peux pas utiliser le code VS.
Faire écho à ce que les autres ont dit - Ne pas pouvoir ancrer les différents panneaux est un peu un facteur décisif pour moi aussi. - C'était la troisième chose que j'ai essayé de faire dans VS Code (juste après avoir changé le thème en lumière, pour que je puisse voir les menus et installer les extensions mssql).
Pour être utile - ce qui me serait utile, ce n'est pas seulement de pouvoir ouvrir des fichiers sur plusieurs écrans, mais également de pouvoir ancrer n'importe quel type de panneau n'importe où dans l'EDI (y compris les faire apparaître dans de nouvelles fenêtres qui peuvent être déplacées vers de nouvelles écrans). - Ma configuration typique me permet d'ouvrir des fichiers de code sur les deux premiers de mes écrans, et d'avoir un panneau de contrôle de tous les panneaux «d'état» utiles ancrés sur le troisième écran.
J'ai joint ci-dessous un exemple typique de ce à quoi ressemble mon troisième écran (dans l'espoir que cela aide) - excuses pour le texte obscurci:
Au fait, j'avais l'impression que la plupart des éléments d'ancrage du panneau que Visual Studio fait était intégré à .NET, est-ce vraiment si difficile à implémenter? - Quoi qu'il en soit, Visual Studio le fait incroyablement bien, peut-être pourriez-vous contacter l'équipe Visual Studio Prime et demander à simplement emprunter leur code pour cette partie. ;-)
Edit: hein, il semble que VS Code soit une application d'électrons ... eh bien, c'est une décision _intéressante_ ... hrmm ...
C'est la seule raison pour laquelle personne dans mon équipe n'utilise réellement VS Code comme plate-forme de développement principale. Nous continuons à utiliser VS 2017 - même avec toute sa fagilité évidente.
Je n'ai aucun doute sur le fait que l'équipe de VS Code doit se rendre compte qu'il s'agit d'un - des problèmes de niveau nucléaire - donc, de toute évidence, ils ont un défaut architectural majeur qu'ils ne peuvent tout simplement pas résoudre.
Il s'agit de l'une des trois principales fonctionnalités d'un environnement de développement pris en charge par Visual Studio (et tous les autres environnements de développement depuis la présence de Bill Cliniton). Donc, ce n'est pas quelque chose qui est dans la catégorie de; "Oh, je n'y ai jamais pensé!"
VS Code ne peut tout simplement pas le retirer.
Je suis fatigué d'ajuster les problèmes / la sortie / la fenêtre du terminal de haut en bas. Ce serait une excellente première étape pour rendre cela détachable.
Pour les personnes souhaitant une solution de contournement, si vous créez un lien symbolique vers le dossier de votre projet et ouvrez ce dossier en tant que nouvelle fenêtre. Vous obtenez votre projet sur les deux fenêtres. À l'équipe de code VS, veuillez ne jamais «corriger» ce bogue (sauf si vous ajoutez le support multi-fenêtre ofc)
La commande "Dupliquer l'espace de travail dans une nouvelle fenêtre" ajoutée à la palette de commandes il y a quelques versions n'est-elle pas une meilleure option?
@JustinAddams
C'est correct comme solution de contournement. Essayez d'accéder à des projets avec plusieurs configurations de plusieurs langages, outils et frameworks (tels que .NET (plus outils et bibliothèques) pour la logique backend et buisness + abstractions DB et Angular / VueJS / React pour front-end ou d'autres frameworks)
La duplication d'un espace de travail présente un très gros inconvénient en termes d'utilisation de la mémoire et du lecteur de stockage.
Il s'agit essentiellement d'une nouvelle instance de VSCode dans le même espace de travail.
L'exécution de services linguistiques et de serveurs linguistiques en double peut créer des conditions de course et une utilisation intensive du disque dur / SSD en accédant aux mêmes fichiers, en particulier avec des outils qui utilisent une analyse à l'échelle du projet.
Bien sûr, vous pouvez désactiver ces outils et choses, mais lorsque vous travaillez dans une grande équipe, il arrive toujours que quelqu'un valide le dossier des paramètres de vscode (même s'il est ignoré - ne me demandez pas comment cela se passe). Puis vient le chaos.
La mise en cache peut également être un problème.
La fenêtre sans cadre d' Electron peut être une solution cool implémentée, mais dans le noyau. Cela prendra aussi du temps. Puisqu'il est essentiel de changer le code de base à ce niveau.
Ils veulent probablement implémenter une fonctionnalité pour un rapport performances / utilisation de RAM maximum, mais c'est très complexe en raison de leur construction personnalisée d'Electron et de leur noyau complexe. Son implémentation au cœur peut rendre toutes les fenêtres capables d'une `` existence '' sans cadre comme dans Visual Studio 2015, 2017, WebStorm, etc.
C'est une fonctionnalité critique, en particulier pour la configuration multi-moniteurs. Partage de processus d'espace de travail unique sur des fichiers ouverts à plusieurs fenêtres.
_Solution probable: ouvrez une nouvelle instance de VSCode au lieu de l'implémentation de fenêtres sans cadre, mais ajoutez une option de ligne de commande pour lui permettre d'utiliser les extensions partagées de la première instance (problème: l'hôte d'extension peut être partagé ou est lié à l'instance?) ._
@JustinAddams C'est ce que je fais en ce moment,
Ce serait également bien d'avoir ajusté la configuration de la vue pour la vue de l'espace de travail dupliquée ...
Par exemple,
Etc
Également à partir de la fenêtre principale de l'espace de travail, nous, en tant que développeurs, pouvons créer un service de pont, qui écouterait les événements des espaces de travail dupliqués enfants, et la fenêtre principale de l'espace de travail pourrait interagir avec cela.
Cas d'utilisation, par exemple:
Créer un sous-espace de travail par modèle préconfiguré
comme un espace de travail en double, mais créez un processus enfant à partir de la fenêtre principale de l'espace de travail.
Un modèle pourrait être nommé, par exemple, "Panel uniquement" (il n'aurait que Problèmes, Sortie, Console de débogage, Terminal)
Dans l'onglet du terminal de l'espace de travail enfant, je peux démarrer yarn test --watch
,
Command+Click
sur la session vscode du sous-espace de travailMais je vois cela juste un chargement d'une session enfant de Visual Studio Code mais pas de vscode complètement chargé, mais une variante de chargement simplifiée et plus légère ... J'espère que cela ne devrait pas prendre beaucoup de ressources
Les modules sur le VSCode doivent également communiquer via un middleware, qui peut facilement connecter de nombreuses instances entre elles, donc dans la fenêtre de l'espace de travail enfant, nous pouvons voir le problème d'ESLint par exemple …………
Peut-être que ce "brainstorming" sera utile pour quelqu'un, je l'espère :)
À votre santé! & merci pour votre attention…
Pour les personnes qui suggèrent d'ouvrir une autre fenêtre.
Le principal avantage de cette fonctionnalité est d'ouvrir le terminal / la sortie / les problèmes sur un autre moniteur, vous pouvez donc avoir une liste d'erreurs séparément de la fenêtre de code. Vous pouvez donc Ctrl-clic sur un moniteur et voir le code correspondant sur un autre.
J'aimerais voir cette fonctionnalité ajoutée. Webstorm / Phpstorm ont tous deux cette fonctionnalité, et c'est vraiment la principale chose que j'aime dans ces applications. J'utilise un moniteur d'orientation portrait comme éditeur principal, et avoir mon panneau d'arborescence de fichiers / explorateur sur un moniteur différent fait une grande différence pour moi. J'aime aussi avoir mon terminal sur un moniteur différent, mais je peux toujours simplement utiliser un terminal qui n'est pas intégré avec vs code, mais avoir des fenêtres détachables dans vs code pour ces panneaux serait génial.
Alors? 2 ans et rien?
Je ne supporte pas le panneau de "recherche" intégré, car il est toujours énorme et large.
Je trouve étrange que, bien que cela ait maintenant deux ans et que la fonctionnalité la plus souhaitée et la plus discutée ici, cela soit encore complètement ignoré par les développeurs.
J'ai peur, ils ont déjà jugé cela trop compliqué / trop de travail il y a longtemps, ont décidé que cela n'en valait pas la peine et gardez le silence pour retarder les retombées le plus longtemps possible ...
Et je dois dire que je suis un peu énervé par cette non-communication. Peut-être que je me trompe, mais cela sent beaucoup la politique de Microsoft ...
J'ai peur, ils ont déjà jugé cela trop compliqué / trop de travail il y a longtemps, ont décidé que cela n'en valait pas la peine et gardez le silence pour retarder les retombées le plus longtemps possible ...
Je n'ai aucune idée de comment cela peut être si compliqué. D'innombrables autres logiciels l'ont fait, le font et continueront de le faire, je ne suis donc pas tout à fait sûr de ce qui les empêche réellement d'implémenter l'une des fonctionnalités les plus demandées.
Est-ce parce qu'aucun développeur n'est actuellement recruté pour travailler sur VSCode? N'est-il pas jugé assez digne car VSCode ne peut pas être monétisé?
Je ne suis pas tout à fait sûr que l'argument "cela peut s'avérer trop pénible pour les ordinateurs" soit valable ces derniers temps, étant donné que les ordinateurs les plus récents ont beaucoup plus de ressources système qu'auparavant. De plus, si cela s'avère avoir cet effet sur les postes de travail, ayez la possibilité de désactiver complètement cette fonctionnalité.
Avoir la possibilité de l'utiliser ou non serait bien mieux que de ne pas avoir le choix du tout, très franchement.
VSCode est utilisé par les personnes qui CODE. Si les codeurs ne savent pas comment activer ou désactiver une fonctionnalité, ils utilisent peut-être le mauvais logiciel.
En outre, des mesures seront prises pour réduire l'épuisement des ressources système, mais en s'abstenant d'ajouter de nouvelles fonctionnalités telles que celle-ci sur la base de la croyance séculaire que «la plupart des utilisateurs ne sauront pas comment l'éteindre, donc il est activé par défaut lors de l'installation, le logiciel pourrait être vraiment lent sur divers ordinateurs et cela nous fera paraître mauvais »est le pire argument possible pour le manque de mise en œuvre, car cela impliquerait que votre base d'utilisateurs cible est moins encline technologiquement que la plupart.
La dernière fois que j'ai vérifié, ce n'était pas le cas.
Ma meilleure hypothèse est qu'il est difficile pour eux de créer une nouvelle fenêtre avec l'onglet et de garder l'onglet à cause de l'électron. Ils doivent créer une nouvelle fenêtre chaque fois que vous faites glisser un onglet dans sa propre fenêtre, et ce n'est évidemment pas une chose facile à faire. Surtout pour des choses comme le terminal, la barre latérale, etc.
Je veux toujours désespérément cette fonctionnalité.
@Penagwin De même, mais étant donné que je ne sais pas quel est le raisonnement technique pour ne pas être en mesure de le mettre en œuvre, je vais également être poli et réserver mon jugement et attendre patiemment comme tout le monde. 😄
Une solution de contournement dans le temps moyen consiste à ouvrir deux fenêtres, ouvrir un dossier parent et un dossier enfant du même projet. Par exemple, ouvrez le répertoire de votre application dans une fenêtre et le dossier «public» dans l'autre fenêtre. L'inconvénient est qu'il n'y a pas d'onglets glisser-déposer entre eux, mais sinon cela fonctionne.
A toutes les personnes qui proposent la solution de contournement avec 2 fenêtres. Cela n'aide pas du tout avec le problème réel de ne pas pouvoir avoir des éléments comme l'inspecteur de débogage ou le terminal / sortie et ainsi de suite sur un deuxième écran.
Utilisez "Ctrl K, O" pour ouvrir le fichier actuel dans une autre fenêtre vscode pour l'édition. Vous devrez redéfinir le répertoire par défaut du terminal pour que la fenêtre nouvellement ouverte soit créée. Fonctionne uniquement avec les fichiers; pas sur les fenêtres de terminal. Je sais que ce n'est pas la même chose que le glisser-déposer, mais cela devrait être utile si vous avez juste besoin de déplacer quelques fichiers vers une autre fenêtre pour utiliser le deuxième ou le troisième moniteur. Rien de mal à un travail autour car nous n'avons pas de solution. Le monde n'est pas parfait, tirez le meilleur parti de ce que nous avons et faites le travail. J'espère que cela aidera jusqu'à ce que quelque chose de mieux arrive. Bon codage!
Il est difficile de croire que cela fait 2 ans et il y a eu si peu de progrès à ce sujet. Je commençais sérieusement à craquer pour le code VS car, dans l'ensemble, c'est un IDE génial. Je ne peux cependant pas le considérer comme un concurrent sérieux pour le développement professionnel sans le support multi-écrans. En parcourant ces commentaires, il semble que je ne suis pas le seul à avoir cette opinion.
Retour à Webstorm pour l'instant = (
J'observe cette fonctionnalité depuis un moment, ajoutant simplement une autre voix disant que je souhaite vraiment que cela se produise! Si le code VS pouvait implémenter cela, ce serait l'éditeur parfait !!
Pourquoi est-ce toujours pas une chose! Quel est le retard sur cette fonctionnalité ... VS code est un excellent éditeur, mais c'est une fonctionnalité majeure manquante ...
Cela doit vraiment arriver! Gros oubli sur le compte de Microsoft.
S'il vous plaît les gars, faites-le! C'est la fonctionnalité la plus recherchée: danseur:
Je travaille avec 3 moniteurs et j'ai besoin de cette fonctionnalité, car parfois dans le code, j'ai besoin de voir quelles fonctions je dois implémenter à partir d'un fichier, et je dois ouvrir ceci dans une fenêtre séparée pour copier coller quoi Je veux au lieu de diviser la fenêtre à l'intérieur d'un moniteur qui peut limiter la zone d'espace de travail.
Veuillez implémenter cette fonctionnalité pour faire flotter les fenêtres (détachement de la fenêtre).
+1. Ce serait vraiment très utile pour la productivité multi-écrans.
Cette demande de fonctionnalité a récemment célébré son deuxième anniversaire. Je doute que cela soit jamais implémenté :(
+1 Des mises à jour sur cette fonctionnalité?
Il semble que le fait de vouloir cette fonctionnalité soit en corrélation avec le fait de ne pas pouvoir utiliser GH correctement ni de bien se comporter dans la discussion sur Internet. Le spam Mindless +1 aidera certainement votre cause.
@ Krzysztof-Cieslak Il devrait y avoir une option pour désactiver les commentaires sur un problème et n'autoriser que les réactions à l'OP
@ Krzysztof-Cieslak Je pense que +1 est lié à un vote plutôt qu'à une discussion.
Un +1 est souvent utilisé pour HAUT la conversation afin que les gars de Microsoft ne perdent pas le problème;)
@SkyzohKey , c'est déjà ouvert, ils ne perdront rien.
Y at-il une chance puisque MS possède github et essentiellement le projet d'électrons, cela verra-t-il réellement le jour? Je suis d'accord que c'est un problème fondamental avec l'éditeur sinon c'est plutôt génial.
@ napalm684 Bon point, néanmoins je pense que ce n'est pas un problème dans Electron (https://github.com/Microsoft/vscode/issues/10121#issuecomment-346088717), mais avec l'architecture VSCode elle-même (https://github.com / Microsoft / vscode / issues / 10121 # issuecomment-346290180).
Ah, j'ai lu à l'origine @ n9 que c'était un problème d'électrons. Quoi qu'il en soit, je pense que c'est la demande de fonctionnalité numéro 1 pour le moment.
Aura-t-il cette fonctionnalité dans la prochaine version majeure?
Je sais que tout le monde n'aimait pas être pressé mais,
J'espère que cette fonctionnalité sera la priorité maximale.
Je sais que c'est un logiciel gratuit open source, mais cette limitation peut empêcher les nouveaux utilisateurs d'utiliser VS Code.
Nous sommes heureux d'utiliser le nouvel IDE génial, et nous sommes populaires, n'est-ce pas?
Alors oui ... voici un autre développeur souhaitant pouvoir détacher les onglets de VSCode, tout comme travailler avec VS.
Comme la plupart des gens ici:
J'adorerais pouvoir avoir plus d'une fenêtre de code VS pour un seul dossier / projet et pouvoir travailler sur plus d'un moniteur.
Génial IDE quand même 👍
Continuez comme ça, j'adore votre travail.
J'aimerais aussi beaucoup pouvoir ouvrir le même répertoire dans plusieurs fenêtres.
👍
J'aimerais détacher la console du débogueur afin de voir sur le 2ème moniteur
+1
La solution de contournement (ouvrez une nouvelle fenêtre et faites glisser et déposez votre fichier de l'espace de travail / fenêtre actuel vers celui qui vient d'être ouvert) est OK mais je n'ai pas accès à l'espace de travail lui-même; paramètres différents, pas d'accès à d'autres fichiers dans l'espace de travail, etc.
Mais à part ce VSC, c'est génial!
J'ai essayé de vérifier ce que nous pouvions faire avec les fenêtres flottantes dans VSC.
Tout d'abord - Electron prend en charge plusieurs fenêtres. Il est possible d'ouvrir une instance supplémentaire de BrowserWindow mais cela nécessite un fichier HTML lors du chargement.
Dans ce cas, considérons le terminal dans une fenêtre flottante. Je ne parle pas très couramment le code VSC, mais il semble que toutes les applications fonctionnent en tant qu '«application monolithique». Cela signifie que si nous souhaitons avoir quelque chose de l'interface utilisateur VSC dans une fenêtre supplémentaire, nous devons y charger toutes les applications et masquer les parties inutiles de l'interface utilisateur.
Super? Pas vraiment. Dans une fenêtre supplémentaire, nous devons masquer les parties inutiles de l'interface utilisateur, mais aussi ... désactiver la mise à jour d'autres zones d'application lors de modifications de fichiers ou de raccourcis. De plus ... Je ne sais pas comment fonctionne la mémoire Electron mais je crois que si nous chargeons toutes les applications dans la deuxième fenêtre, alors l'utilisation de la mémoire de VSC augmentera considérablement.
Je pense que nous devrions essayer de rendre VSC plus modulaire et préparer une sorte de mécanisme multi-fenêtres avant de commencer à travailler sur des fenêtres flottantes avec des parties d'interface utilisateur uniques.
Chère communauté, essayons d'aider l'équipe VSC.
Un +1 est souvent utilisé pour HAUT la conversation afin que les gars de Microsoft ne perdent pas le problème;)
Non, maintenant ils sont habitués à ignorer le problème. :) C'est comme mettre une note sur le miroir de votre salle de bain. Au début, vous ne pouvez pas l'ignorer, mais après un certain temps, vous ne le voyez même plus.
Je ne suis pas du tout un gars Electron, mais j'ai un peu bricolé. Ne serait-il pas possible de lancer une nouvelle fenêtre et d'établir une communication entre la fenêtre parente et l'enfant via l'API webContents?
@kodipe
@scriptcoded bonne question!
Je viens de trouver ce projet https://github.com/illBeRoy/ElectronScriptWindow qui permet d'utiliser BrowserWindow sans fichier HTML spécifique. Fondamentalement, il crée une chaîne encodée en base64 comme URL pour la fenêtre: https://github.com/illBeRoy/ElectronScriptWindow/blob/master/src/index.js#L76 lors du chargement. Après cela, nous devrions être en mesure de contrôler l'enfant du parent via webContents.
@kodipe Neat! C'est une façon assez intelligente de le faire. Je vais peut-être regarder de plus près les sources et déterminer si ce serait une bonne façon de le faire. Je suppose que cela implique une réécriture lourde d'un tas de fonctionnalités de base.
@scriptcoded ouais ... c'est vraiment difficile d'obtenir une fonctionnalité en ce moment. Je chercherai une solution pour une API FloatingWindow simple et je partagerai avec vous ici si je crée quelque chose d'intéressant sur mon fork.
+1 pour cette fonctionnalité
J'ai atteint cette limitation plusieurs fois par jour, c'est une fonctionnalité manquante assez importante pour moi.
Solution de contournement:
1.) Ouvrez votre dossier de projet
2.) Enregistrer comme espace de travail
3.) Ouvrez l'espace de travail dans une fenêtre et le dossier de projet dans l'autre
J'espère que cela t'aides
Cette fonctionnalité est en retard et essentielle pour la productivité avec plusieurs moniteurs, de combien de réponses avez-vous besoin pour ajouter cette fonctionnalité à l'étendue? Je peux demander à tous mes collègues de répondre si vous le souhaitez.
Qu'en est-il de https://www.npmjs.com/package/electron-window-manager ??
@WNemencha Je suppose que l'équipe ne veut pas de dépendances inutiles. Peut-être l'a dit là-dessus?
J'espère que nous y arriverons éventuellement, c'est un must :)
Pour continuer à innover et faire de VSCode un éditeur moderne et complet, c'est une nécessité. Cela devrait être un objectif majeur à long terme jusqu'à ce qu'il soit fait.
Cette fonctionnalité devrait vraiment être une fonctionnalité hautement prioritaire. Je ne connais aucun développeur qui ne code que sur un moniteur, et avoir la possibilité de faire glisser un onglet vers une nouvelle fenêtre pour une utilisation côte à côte est tout simplement trop utile pour ne pas l'avoir.
Cette fonctionnalité devrait vraiment être une fonctionnalité hautement prioritaire. Je ne connais aucun développeur qui ne code que sur un moniteur, et avoir la possibilité de faire glisser un onglet vers une nouvelle fenêtre pour une utilisation côte à côte est tout simplement trop utile pour ne pas l'avoir.
Hé, @oryandunn, ce dont vous vous plaignez est en fait possible. Voir mon commentaire ajouté sous ce ticket:
"Ouvrez une nouvelle fenêtre et faites glisser et déposez votre fichier de l'espace de travail / fenêtre actuel vers la fenêtre nouvellement ouverte."
Ce ticket concerne l'ouverture de deux fenêtres dans LE MÊME espace de travail.
@kapalkat pour clarifier, ce problème concerne le détachement de parties de l'interface utilisateur, telles que le terminal, l'explorateur et le débogueur, de la fenêtre principale. # 2686 traite de plusieurs fenêtres avec le même espace de travail.
Je pense que ce problème devrait être gelé / restreint jusqu'à ce que quelqu'un puisse réellement y travailler (de l'équipe VSCode).
Je ne pense pas que nous puissions nous attendre à cette fonctionnalité à tout moment dans la fonctionnalité proche. D'après ce que j'ai compris, l'équipe devrait changer une grande partie de l'infrastructure pour que cela fonctionne. Non seulement cela, je ne sais pas combien d'autres seront affectés.
Je doute également que cela ait quelque chose à voir avec Electron (pas une restriction / un problème côté électron). Il est simplement limité par l'architecture actuelle.
Ce fil est rempli de plus de +1 commentaires que de commentaires réellement utiles.
Ce fil est rempli de plus de +1 commentaires que de commentaires réellement utiles.
Cette base d'utilisateurs est frustrée car elle ne prend pas en charge plusieurs moniteurs. Sinon, comment les développeurs devraient-ils obtenir des informations sur ce que veut la base d'utilisateurs?
Sinon, comment les développeurs devraient-ils obtenir des informations sur ce que veut la base d'utilisateurs?
En laissant un 👍 et en gardant l'espace de discussion dégagé pour une discussion constructive, par exemple:
J'aime assez l'implémentation que VS avait, où en faisant glisser n'importe quelle partie de l'interface utilisateur, il pouvait «s'aligner» sur une partie de l'écran. Similaire à la façon dont le fait de faire glisser un onglet maintenant vous permet de titrer la vue principale.
Pour être honnête, la seule chose que je veux vraiment pouvoir faire est de faire glisser les onglets de l'éditeur de code. Je ne me soucie même pas de pouvoir les mettre en mosaïque en dehors de la fenêtre principale, car alors je peux simplement utiliser le gestionnaire de fenêtres du système d'exploitation à la place.
Tout le monde applaudit pour @mrmos et sa solution .
@jayarjo J'ai fait quelque chose de similaire en ouvrant une nouvelle fenêtre vscode et en y faisant glisser mon onglet. Le problème ici est qu'aucune des découvertes ne fonctionne correctement car elle ne contient aucune information sur l '"espace de travail" réel dont elle provient.
Pour contourner le problème, vous pouvez utiliser la commande Dupliquer l'espace de travail dans une nouvelle fenêtre (depuis la version 1.24) pour ouvrir le dossier / espace de travail actuel dans une deuxième fenêtre de code VS qui peut être déplacée vers un moniteur distinct. J'ai attribué le raccourci clavier Ctrl + Shift + N
pour cette commande.
@ n0v1
Comme solution de contournement simple, vous pouvez utiliser la commande Dupliquer l'espace de travail dans une nouvelle fenêtre
Hmm, je ne semble pas avoir cette fonctionnalité dans le dernier macOS - doit-elle être activée?
Cordialement
@ldexterldesign Avez-vous essayé de l'exécuter en ouvrant la palette de commandes ( ⌘ + SHIFT + P ) et en tapant Duplicate Workspace in New Window
?
@ n0v1 le problème
Pour clarifier les choses, ouvrez un fichier dans un espace de travail et ouvrez le même fichier dans l'espace de travail dupliqué. Maintenant, éditez le fichier dans une fenêtre, il ne sera pas reflété dans l'autre fenêtre.
Tout le monde dit maintenant les trucs de l'espace de travail en double, mais c'est sûr que tout le monde le sait maintenant et n'a pas besoin d'être répété si souvent. Et toute cette «solution de contournement» n'est même pas pratique, nous avons besoin d'une véritable fonctionnalité de fenêtre flottante comme elle est implémentée dans d'autres éditeurs.
Veuillez arrêter de suggérer «Espace de travail en double». Ce n'est pas la solution. Nous avons également besoin de dupliquer l'explorateur d'espace de travail. Ce qui n'est pas le cas.
J'adorerais voir la possibilité de détacher la console (et d'autres parties de l'éditeur) et de les pousser sur un écran séparé me permettant d'obtenir l'intégralité de mon écran principal pour écrire et lire mon code lorsque je travaille quelque part avec plusieurs écrans /
Cela me permettrait également de mieux gérer et travailler en déplacement où je n'aurais que mon écran principal disponible pour travailler, comme dans un train ou sur les sites des clients.
Je ne vois aucun progrès sur cette fonctionnalité et ces dernières années. Si nous nous en tenons à des limitations architecturales qui coûtent trop cher pour y arriver, pourquoi ne pas simplement la fermer et aller de l'avant
N'oubliez pas que nous avons la communauté VisualStudio, veuillez envisager de déplacer certaines fonctionnalités vers le plugin VS.
@Nyconing VS Ne fonctionne pas sous Linux ou Mac.
@Nyconing VS Ne fonctionne pas sous Linux ou Mac.
Pas tout à fait vrai ...
OK, communauté.
Quelle est la meilleure façon d'afficher un fichier (avec test unitaire) sur le moniteur gauche et le deuxième fichier sur le moniteur droit?
Veuillez ne pas essayer de recommander d'utiliser Vim, Emacs, Visual Studio Enerprise, Sharp Develop, Eclipse, Jetbrains ou peut-être Notepad.
Quelle est la meilleure façon d'afficher un fichier (avec test unitaire) sur le moniteur gauche et le deuxième fichier sur le moniteur droit?
Ne doublez pas le message s'il vous plaît Le mieux que je puisse offrir serait de redimensionner la fenêtre pour qu'elle couvre vos deux écrans et de diviser l'éditeur en deux tuiles au milieu entre vos moniteurs.
Ne doublez pas le message s'il vous plaît
Il y a des problèmes internes à GitHub lui-même
Pas tout à fait vrai ...
il fonctionne sur mac avec wine ou windows vm
@ hellboy81 @belst Mon mal, je pensais que tu avais dit VS Code. Désolé! De retour sur les rails maintenant ...
Juste mes 2 cents
"Ctrl + K puis O"
est lié à "Ouvrir le fichier actif dans une nouvelle fenêtre"
Juste mes 2 cents
"Ctrl + K puis O"
est lié à "Ouvrir le fichier actif dans une nouvelle fenêtre"
Comme d'autres l'ont dit, ouvrir dans une nouvelle fenêtre n'est pas ce que nous demandions ou voulions.
Nous recherchons la possibilité d'ouvrir une fenêtre et de la déplacer où nous voulons, essentiellement comme premire pro le fait avec les différentes palettes,
Juste mes 2 cents
"Ctrl + K puis O"
est lié à "Ouvrir le fichier actif dans une nouvelle fenêtre"Comme d'autres l'ont dit, ouvrir dans une nouvelle fenêtre n'est pas ce que nous demandions ou voulions.
Nous recherchons la possibilité d'ouvrir une fenêtre et de la déplacer où nous voulons, essentiellement comme premire pro le fait avec les différentes palettes,
Je suis totalement d'accord avec vous. J'essayais juste d'aider avec une solution de contournement temporaire que j'utilise en attendant cette fonctionnalité.
Je veux juste exprimer mon opinion à ce sujet. Je pense que beaucoup de développeurs ont plus d'un moniteur et les utiliser efficacement est une grande victoire pour la productivité.
Je ne sais pas pourquoi cette fonctionnalité ne progresse jamais car elle a un support massif et le code étant donné que le code est une application électronique, c'est parfaitement faisable et dégradable si jamais vous avez couru en dehors de l'électron.
En un mot, veuillez prendre en charge MDI dans vscode.
Jusqu'à ce que VS Code prenne en charge plusieurs affichages, je ne vois pas le passage à cet éditeur par défaut. J'ai récemment commencé à utiliser les outils JetBrains comme alternative. Je regarde ce numéro depuis un an et toujours aucun mouvement à ce sujet. Je ne sais pas pourquoi ce retard?
Xcode autorise plusieurs fenêtres pour un projet. De plus, les fenêtres sont toutes égales, des fenêtres entièrement fonctionnelles, ce qui signifie que vous pouvez ouvrir une deuxième fenêtre et fermer la fenêtre du projet d'origine et vous avez toujours une fenêtre de projet complète.
Cette approche signifie que plusieurs moniteurs sont facilement pris en charge. Cela signifie aussi que je n'ai pas à garder la gestion des fenêtres autant que je n'ai pas à me rappeler quelle est la "vraie" fenêtre du projet.
Cette approche serait grandement appréciée dans VS Code.
Xcode autorise plusieurs fenêtres pour un projet. De plus, les fenêtres sont toutes égales, des fenêtres entièrement fonctionnelles, ce qui signifie que vous pouvez ouvrir une deuxième fenêtre et fermer la fenêtre du projet d'origine et vous avez toujours une fenêtre de projet complète.
Comment? Lorsque j'essaie d'ouvrir le même espace de travail sous Mac OSX, il se concentre toujours uniquement sur la fenêtre déjà ouverte.
Puisque VSCode est écrit avec Electron, les "fenêtres flottantes" sont un peu difficiles à réaliser, mais permettre d'ouvrir le projet deux fois aiderait beaucoup, mais cela ne semble pas non plus fonctionner. Toute aide est appréciée.
Venir et déclarer ma propre expérience: j'ai utilisé avec succès VScode dans le passé pour compiler et déboguer un projet de moteur de jeu auquel je contribue, mais comme je ne peux pas faire de fenêtres détachées avec VScode, je m'en tiens malheureusement à CLion, qui prend lentement mais sûrement sur Visual Studio dans son ensemble.
Comme d'autres qui l'ont mentionné dans ce fil, le codage multi-moniteurs nécessite un peu des détachables.
Xcode autorise plusieurs fenêtres pour un projet. De plus, les fenêtres sont toutes égales, des fenêtres entièrement fonctionnelles, ce qui signifie que vous pouvez ouvrir une deuxième fenêtre et fermer la fenêtre du projet d'origine et vous avez toujours une fenêtre de projet complète.
Comment? Lorsque j'essaie d'ouvrir le même espace de travail sous Mac OSX, il se concentre toujours uniquement sur la fenêtre déjà ouverte.
Puisque VSCode est écrit avec Electron, les "fenêtres flottantes" sont un peu difficiles à réaliser, mais permettre d'ouvrir le projet deux fois aiderait beaucoup, mais cela ne semble pas non plus fonctionner. Toute aide est appréciée.
Vous pouvez le faire dans Xcode en déchirant un onglet ou en utilisant Fichier-> Nouvelle fenêtre. Toutes les fenêtres dans lesquelles vous pouvez naviguer dans votre projet ou modifier le code sont égales. Il n'y a pas de fenêtre "principale" dans Xcode. Voir le gif ci-dessous.
2 ans depuis qu'il a été demandé. Des estimations quand le code VS pourrait être capable de le faire?
Ceci est un OSS . Vous pouvez aider et apporter vos compétences à VSCode. Si vous voulez vraiment que VSCode soit présenté dans plusieurs fenêtres, pourquoi ne pas essayer de le créer et de le rendre possible par vous-même?
Je sais que c'est OSS. C'est pourquoi je n'avais aucune attente à ce sujet. J'ai seulement demandé s'il y avait des estimations de personnes s'occupant de ce repo. «Aucune estimation» est également une réponse. Merci
Demande: veuillez fermer ce numéro pour commentaires.
L'équipe VSCode fait un travail incroyable et fournit continuellement une valeur incroyable à une communauté de développeurs toujours croissante grâce à l'un des meilleurs outils de codage au monde.
Bien que j'exprime autant d'enthousiasme que quiconque ici à propos de la perspective de la multi-fenêtre, je suis heureux d'attendre aussi longtemps qu'il le faudra. Je suis un peu fatigué de tous les me too
, you can duplicate your workspace as an alternative
, but this tool has it
, when will we get this
ou même de quelques commentaires assez exigeants sur cette question. J'attends avec impatience chaque commentaire sur ce problème pour entendre une mise à jour pertinente uniquement pour voir plus des commentaires susmentionnés. Il est difficile de trouver un commentaire pertinent d'un membre de l'équipe étant donné les 363 commentaires ci-dessus.
Je suis sûr que ce problème est sur le radar de l'équipe (c'est la fonctionnalité la plus demandée).
@bpasero a donné ses derniers commentaires dans ce commentaire ci-dessus: https://github.com/Microsoft/vscode/issues/10121#issuecomment -345770248
Cela nécessite un peu de réarchitecture des internes de vscode, alors soyons patients (ou contribuons).
Cette mise à jour de statut me suffit. Ils nous recontacteront lorsqu'il y aura une nouvelle mise à jour.
Veuillez 👍 le problème pour montrer votre soutien.
Commentaire le plus utile
Ce serait vraiment bien si nous pouvions déchirer des onglets pour afficher le fichier / l'onglet dans une fenêtre séparée 😪