Vscode: Permitir janelas flutuantes

Apenas adicionando meu apoio a isso. Muitas vezes, com o Visual Studio completo, eu arrastava uma guia para o meu outro monitor para poder visualizar dois arquivos de código ao mesmo tempo. A funcionalidade do painel dividido é boa, mas não é a mesma.

Eu vejo as guias do editor como mais importantes do que as outras. É muito difícil usar dois monitores quando você não consegue quebrar uma guia. Isso é importante ao fazer referência ao código, mas também para coisas como visualização do Markdown.

Como deve funcionar ...? Não consigo fazer funcionar (no 1.11.0-Insider). Ao arrastar uma guia para fora da janela, ela exibe um 🛇 e não me permite soltar ou, quando solta na parte superior de uma janela do Windows Explorer, copia o arquivo ...

@CherryDT Este problema ainda está aberto e marcado como Backlog . Você tem uma referência que diz que deve ser implementado no 1.11?

@ vossad01 Você está certo. Fiquei confuso por um segundo, porque vim do problema encerrado # 10147 onde dizia "Já resolvido por # 10121" e considerei "endereçado" como "resolvido". Meu erro.

Eu diria que desencaixar guias (editores mais especificamente) é um tipo de tarefa _deve ter_ em vez de _eventualmente_. Adoraria implementá-lo.

@bpasero @aeschli é um recurso que você gostaria de obter e revisar como uma solicitação pull? Parece ser uma tarefa maior, portanto, faz sentido perguntar antes de prosseguir com a implementação.

@mlewand esta não é uma área onde esperamos um PR devido a limitações técnicas. Se você tiver uma idéia, diga-nos.

@bpasero por limitação técnica você diz que é uma limitação do elétron? Ou é mais sobre VSCode um projeto <-> um design de janela?

@mlewand depende, se eu pudesse abrir uma janela leve que compartilha o mesmo contexto JavaScript e construir alguma IU nela, isso certamente ajudaria. Caso contrário, acabaríamos abrindo uma janela pesada do navegador com o próprio contexto que contém apenas as partes da interface do usuário que queremos mostrar, o que parece ser a direção errada.

Quer gritar "me-to".

Especificamente nas guias do editor. É uma pena que o autor do problema tenha as prioridades tão invertidas, mas não posso acreditar que ninguém na Microsoft tenha visto esse tíquete em algum momento do ano passado, reconheceu o imenso valor de ser capaz de arrastar uma guia do editor de um janela para outra (sua turma do Visual Studio vem fazendo isso há décadas) e já fez isso acontecer.

Esta é uma deficiência séria do VSCode como editor.

Usei o Visual Studio como meu editor principal por cerca de 9 anos e, em seguida, mudei para o VS Code depois de passar para uma equipe de projeto somente front-end. Há muito o que amar sobre o VS Code, mas o único recurso que falta para mim é a falta de janelas flutuantes apenas com guias do editor (como me acostumei a ter no Visual Studio).

FWIW, eu uso 4 monitores lado a lado. É uma sensação de loucura ficar preso em apenas um monitor para edição de código, especialmente quando estou trabalhando em vários arquivos simultaneamente.

Terei que concordar com os comentários acima. A falta desse recurso é um grande problema para aqueles com vários monitores (basicamente todos que trabalham com código). Obviamente, você pode contornar isso abrindo arquivos específicos em uma instância separada (ctrl + shift + N) do Visual Studio Code, mas é definitivamente algo que deve ser resolvido o mais rápido possível.

Quero poder abrir arquivos em uma nova janela (por exemplo, para colocar em um monitor diferente ou em um espaço de trabalho virtual diferente).
Se eu não consigo abrir diretamente em uma nova janela, então preciso ser capaz de abrir uma guia em uma nova janela ou arrastar uma guia para uma janela VSCode separada (conforme criado com Arquivo → Nova janela)

Estou usando um plugin do visualizador WYSIWYG para editar AsciiDocs. Separar janelas para monitores diferentes é um requisito básico neste caso. Esperançosamente, esse recurso será priorizado em breve

Seria muito bom se pudéssemos abrir várias abas para mostrar o arquivo / aba em uma janela separada 😪

Estou tentando sair do JetBeans e este não é um recurso opcional ou interessante. É fundamental para a codificação de vários monitores. Não tê-lo é um problema.

+

Procurando por esse recurso. Obrigado :)

Não é a maneira mais limpa de oferecer suporte a vários monitores / janelas, mas você pode fazer o seguinte:

• Arquivo> Nova janela

• Agora arraste uma guia em sua janela de código do Visual Studio já existente para a nova janela que você acabou de abrir.

Eu concordo que seria muito bom apenas arrastar uma guia existente para um segundo monitor, mas esta é uma solução alternativa bastante indolor até que eles suportem arrastar guias para outro monitor.

Adicionando meu pedido para este recurso também. É bom ver outros querendo o mesmo.

Eu amo este IDE, caso contrário. 😄

Muito bem sucedida.

Funcionalidade altamente necessária.
obrigado

+1

(A propósito: o Backlog-Link (https://github.com/Microsoft/vscode/milestone/8) aqui no painel direito não funciona?)

Algum plano para quando isso será adicionado a um círculo de lançamento? Obrigado!

Não tenho certeza se alguém viu esse projeto de elétron, mas vou apenas deixar isso aqui. Talvez a MS pudesse ajudar, em sua grande quantidade de tempo :). Eu não vejo commits há algum tempo, não tenho certeza se ele encontrou um obstáculo ou apenas ficou ocupado.

https://github.com/electron-utils/electron-dockable

Tenho que admitir que estou chocado que um editor estabelecido como VSCode não me permite arrastar uma guia para um segundo monitor.

Adicionando meu +1 a isso.

Adoraria ter esse recurso também. +1

@bpasero Não acho que seria um grande problema permitir que outra instância do VSCode fosse aberta se arrastássemos uma guia para fora. Pelo menos seria um começo.

Estou pensando em mudar de Sublime Text para VSC e essa limitação é a única coisa que me mantém usando os dois, com certeza estarei mais inclinado a VSC assim que vocês adicionarem isso!

+1
mesmo se eu só precisar do Explorer e depurar

guias
Explorer / search / debug / git / extensions

Tantos pedidos para isso, e eles estão constantemente chegando também. Estou feliz por não estar sozinho. Realisticamente, este é meu único problema com o código do VS no momento.

+1

Eu irei gritar junto com o comentário acima - realmente este é meu único problema / desejo de recurso para o VSCode. Caso contrário, é um prazer absoluto trabalhar com, e muito superior ao Sublime e outros (na minha opinião).

@RoyTinker mesmo aqui. Esta é a última coisa que me impede de mudar totalmente para o VSCode.

Concordando com tudo acima, esta é a única mosca na sopa para mim depois de mudar do Sublime.

Acho que outra razão importante para ter isso é para que você possa interromper as janelas "Saída" e "Terminal". Se você for executar a depuração dentro do VS Code, provavelmente deseja que a janela Output esteja em um monitor e o código em outro, em vez de amontoar tudo em um monitor.

@laserbeak Acho que as complicações surgem por ter que lidar com o gerenciamento de janelas em vários sistemas operacionais. Pode não haver uma maneira limpa ou clara de fazer isso em todas as plataformas.

Estou lutando para depurar um grande projeto, apesar de trabalhar em três monitores - só posso ter o console de depuração e o código que estou percorrendo em uma tela. Não consigo nem mesmo colocá-los lado a lado na mesma tela, pois o console de depuração ocupa toda a parte inferior da janela separada do editor de código.

Espero que seja dada maior prioridade a esse recurso, especialmente porque já está aberto há mais de um ano.

Irrelevant https://www.npmjs.com/package/electron-window-manager

Op 5 okt. 2017 02:38 schreef Luc Shelton [email protected] :

@laserbeak https://github.com/laserbeak Acho que as complicações surgem de ter que lidar com o gerenciamento de janelas em vários sistemas operacionais. Pode não haver uma maneira limpa ou clara de fazer isso em todas as plataformas.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/Microsoft/vscode/issues/10121#issuecomment-334327742 ou desative o thread https://github.com/notifications/unsubscribe-auth/AD90FFy4E1Ra3EKfLfwh026JvezYp9FJckZksOCT2gaJpCT2gaJpCt2gaJpCt2 .

Aparentemente, os caras da JetBrains sabem a melhor maneira de fazer isso.
Em cada produto IntelliJ, cada visualização possui um ícone de engrenagem que possui as seguintes opções:

• Modo Ancorado
• Modo Flutuante
• Modo janela

Sem esse recurso, os desenvolvedores entram no ciclo seguinte, que leva pelo menos 20% do tempo do desenvolvedor!

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();
}

Eu chamo isso como C riatividade ciclo de K Iller F ocusing U SERS.

É uma pena que isso aparentemente não tenha alta prioridade. É realmente um empecilho para este grande editor.

Esta foi a última coisa que me falaram sobre isso @Hypernut

https://twitter.com/TheLoveDuckie/status/916447993594859522

Estranho que eles ignorassem a demanda aparentemente alta por esse recurso.

@Hypernut pensei o mesmo. Para mim, parece que deve ser um recurso básico de qualquer IDE moderno.

@LoveDuckie @Hypernut Você pode contornar isso arrastando um arquivo do explorer para uma nova janela; mas isso realmente não é uma solução aceitável. Eles parecem estar se esquivando da questão sobre isso ser uma limitação do elétron e se eles serão ou não capazes de fazer isso, infelizmente.

ou talvez eles simplesmente não queiram criar uma competição muito forte para o Visual Studio; -}

@benm-eras Estou ciente disso, mas parece que já existe suporte para essa funcionalidade. É um caso simples de MS querer integrá-lo com o VS Code.

+1. Obrigatório, não é bom ter para pessoas com vários monitores (guias). Mais de 14 meses e um silêncio mortal? Mas ei, o suporte do macOS Touch Bar existe. 👎 Triste ...

Eu concordo com o comentário "não vamos fazer isso competir com o Visual Studio". Bem, se eu pudesse trabalhar em meu SPA de forma eficiente e em meu back-end de API da web no Visual Studio, também não precisaria do VS Code.

+1 precisa deste recurso

Este recurso está na lista de pendências, mas é classificado em 14º ao classificar as solicitações de recursos por número de votos positivos:
https://github.com/Microsoft/vscode/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Areactions-%2B1-desc%20label%3Afeature-request

São necessários mais 104 votos para entrar no top 10.

Essa questão provavelmente receberia muito mais votos positivos se a pergunta original fosse formulada de maneira melhor.

Título: VSCode Add Multi-Monitor / Multi Workspace Support.

Descrição:

Suporte arrastar guias de documentos VSCode, ferramentas e janelas de extensão de uma instância IDE em vários espaços de trabalho / monitores. As janelas divididas dessa maneira devem operar dentro do mesmo contexto que normalmente funcionam quando anexadas ao IDE.

Comportamento atual:

https://cloud.githubusercontent.com/assets/2397125/26831065/5b8f145c-4acb-11e7-8f81-fe25512708cd.gif

Comportamento desejado:
https://user-images.githubusercontent.com/3527695/31317649-71a530b2-ac4d-11e7-9531-6fe2d4a2e967.gif

Apoio, suporte:
https://www.npmjs.com/package/electron-window-manager

Então, por que você simplesmente não usa o Visual Studio?

@ s952163
Eu uso, mas estou limitado apenas ao windows ;-) enquanto o vscode eu uso no linux, macos, windows

@ s952163 Muitos motivos potenciais:

• Usando Linux ou Mac OS X
• Desenvolvendo em plataformas / tempos de execução não MS

Agora sou um desenvolvedor front-end no macOS e não voltaria para o Windows e Visual Studio apenas para suporte a várias janelas. No momento, estou pesquisando editores semelhantes para ver se há suporte para janelas flutuantes: Brackets, Atom, Sublime, JetBrains ...

Também gostaria de oferecer meu apoio a esse recurso. Neste ponto, é o recurso ausente que está me impedindo de usar o VS Code em tempo integral.

Dev típico comentando sobre este problema: "Todos os outros IDEs com IU ruim projetada nos anos 90 me forçaram a comprar várias telas para ser produtivo, então este novo IDE não deve tentar corrigir o problema de forma diferente, mas replicar a mesma IU ruim e oferecer suporte a meus telas ".

Eu realmente espero que isso não seja implementado, focando em uma única janela, simplificado, UX focado na edição é uma grande vantagem do VSCode, não uma desvantagem.

@ Krzysztof-Cieslak Da mesma forma, o Chrome não deve suportar abrir uma guia em uma nova janela. Eu não conseguia imaginar ninguém discutindo isso. Vários monitores ainda são _realmente_ úteis porque aumentam o espaço disponível na tela. Aplicativos que oferecem suporte a vários monitores não são nada complicados para fazer isso.

Veja a ilustração de @ D1no acima ( clique para rolar para cima ). Isso é o que eu gostaria - como abrir uma guia do Chrome. [EDITAR: Não estou dizendo que a janela da nova guia deve duplicar a IU da janela principal. Acho que tudo de que precisaria é uma barra de guias (para várias guias do editor de código) e o conteúdo da guia.]

@ Krzysztof-Cieslak você está brincando certo? Acredite ou não, existe uma grande comunidade de desenvolvedores que valorizam a produtividade em vez da localidade em um café, ou no topo de uma árvore, ou o que quer que esteja na moda.

Os espaços de trabalho com vários monitores não são uma relíquia dos anos 90. Eles são uma ferramenta de produtividade incrível que não deve ser sacrificada com a mudança de mobilidade ou estilos de vida hipster.

@ Krzysztof-Cieslak esta é provavelmente a declaração mais idiota que li há algum tempo. Para sua informação: metade do movimento de RV do século 21 é inspirado pelas limitações do espaço da tela para um número infinito de "janelas / interfaces" 🙄

Portanto, voltando ao tópico: O que podemos fazer?

Gostaria de saber como a RV está relacionada a atividades pesadas de edição e leitura de texto, como programação ... Mas vamos nos limitar a dar exemplos não relacionados, acusando os outros de serem descolados codificando em cima de árvores ou o que quer que faça vocês se sentirem melhor. Essa é a parte fácil.

@ Krzysztof-Cieslak, você diz que o IDE antigo tinha um problema de design que nos obrigou a ter vários monitores, OK, vou aceitar isso, não sei o suficiente sobre esse assunto para dizer que está certo ou errado (e nasci em 1991, então eu realmente não tive chance), mas não importa como você vê, é mais produtivo ver 2 ou mais arquivos ao mesmo tempo do que clicar em guias ou usar algumas combinações de teclas para alterar a visualização, isso é especialmente verdadeiro quando esses arquivos têm uma forte dependência. Acho que não preciso explicar preciso disso, você deve saber do que estou falando. Desculpe pelo inglês ruim, aliás.

Garoto, você mora atrás da lua ou está apenas trollando?
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
(...)

Maximizar a exposição às informações é o que impulsiona tudo, desde multithreading até densidade de pixels e, sim, até mesmo aplicativos de várias telas e dispositivos cruzados. IDEs incluídos.

Portanto, é apropriado _pedir_ para um editor enriquecido se juntar a esse fluxo de trabalho estabelecido. Se você tem algumas contribuições para compartilhar além do trolling, estamos todos felizes em ouvi-lo. Mas, neste ponto, os mais de um ano de atividade desta edição falam por si.

Estamos além de _if_, em vez de _quando_ e _como_ esse aprimoramento atinge o vscode.

Este problema está ficando muito acalorado, acho que aqueles de nós que o apoiam devem aumentar a conscientização sobre ele (tweet, recomendar, discutir), para que ele possa chegar à lista dos 10 principais pedidos. Trollar / xingar / discutir não nos leva a lugar nenhum.

E obrigado @ D1no , agora quero um Oculus Rift para ter 17 monitores virtuais :).

@ Krzysztof-Cieslak
Este é um recurso, não uma escolha de design. Se este recurso for implementado, você não precisa ter vários monitores para usar o VS Code. Na verdade, você não precisa fazer nada, apenas usa o VSCode como está. Ainda não entendi por que você é contra.
De qualquer forma, tenho 2 monitores e ainda considero comprar o terceiro. Por quê? É muito demorado clicar e redimensionar uma janela para ver o conteúdo. Máquina virtual, o código que você escreve, a página HTML que você projeta, a janela do navegador que você verifica, a saída de depuração, o terminal e assim por diante. Eu preciso ver todos eles de uma vez.

BTW, usar MacOS ou Linux não é a única razão para não usar o VS, se você já usou o VS, sabe como ele é inchado. A última vez que baixei foi há alguns meses e seu tamanho era cerca de 7 ou 8 GB naquela época. Mesmo assim, você não tem um desinstalador offline para um instalador de 8 GB! Existem soluções alternativas para fazer um instalador offline de um instalador online na rede!

@tavuntu

é mais produtivo ver 2 ou mais arquivos ao mesmo tempo

Atualmente você pode ver 3 arquivos, um painel vertical (depurador, git, pesquisa, explorador) e painel horizontal ao mesmo tempo

@ D1no ,
Muito bem, vincular alguns links não relacionados a IDEs (ou edição de texto em geral) aos artigos da campanha publicitária de RV em mídias respeitáveis ​​de ciência da computação / engenharia de software como Guardian e Bloomberg mostra totalmente o seu ponto de vista. No entanto, ainda não vejo em todo este tópico um link para pesquisa, estudo, artigo mostrando ganho de produtividade com o uso de múltiplas telas para edição de texto. Não vejo nenhuma discussão razoável sobre as possíveis implicações das diferentes maneiras de implementar esse recurso. Aposto que não verei nenhuma implementação de prova de conceito. Tudo o que posso ver é um monte de gente feliz em marcar com +1 algum recurso aleatório com enormes implicações de design (e um monte de ódio por qualquer pessoa que tenha opiniões diferentes)

De qualquer forma, estou fora. Sim, me chamar de garoto morando atrás da lua ganhou essa discussão! Você também me desmistificou como um troll aleatório da Internet, muito bem, senhor!

@ Krzysztof-Cieslak,
Não, não, não fuja quando for provado que está errado!
Primeiro, indique um estudo que mostra que não ter suporte para vários monitores melhora a produtividade ou é uma escolha melhor. Tudo o que você deu às pessoas foi sua reivindicação, e elas deram a deles.

"Você pode ver atualmente 3 arquivos, um painel vertical (depurador, git, pesquisa, explorador) e painel horizontal ao mesmo tempo", boa tentativa, mas você sabe o que quero dizer, quero dizer uma janela maximizada com um arquivo CSS em um monitor e uma janela maximizada com HTML em outro ... isso é muito melhor do que ter muitos painéis desconfortáveis ​​no mesmo monitor. Eu diria que é uma preferência pessoal, mas ei, essa coisa tem 237 votos positivos contra 7 votos negativos, então sim.

@tavuntu @ Krzysztof-Cieslak Eu mantenho um dos meus monitores de 22 "orientado verticalmente. Às vezes é muito bom editar um arquivo de widget JS lá, com os arquivos HTML e CSS correspondentes em um painel dividido maximizado em um monitor adjacente.

Layout:

                                 +---------+
                                 |         |
                                 | JS File |
                                 |         |
+-------------+ +--------------+ |         |
| Chrome tabs:| | CSS  | HTML  | |         |
| App, docs,  | | File | File  | |         |
| inspector   | |      |       | |         |
|             | |      |       | |         |
+-------------+ +--------------+ |         |
                +--------------+ +---------+
                | Terminal,    |
                | Email,       |
                | Slack        |
                |              |
                +--------------+

Idealmente, os monitores superiores intermediários e direitos estariam executando uma única instância do VS Code, com o arquivo JS exibido como uma janela separada maximizada.

Por favor, não cometa este erro ...

Você não pode ler vários arquivos em um e manter o foco. Dividir o código em uma tela já é o suficiente e esse tipo de decisão implica em muitas implicações de design para a experiência do usuário.

Já há muito a fazer no VSCode, para melhorar a experiência do usuário atual sem adicionar mais complexidade. Como uma nova janela, provavelmente significa que o provedor VSCode precisa oferecer suporte, porque o contexto não é tão simples com uma janela, etc.

Possível melhor foco IMO, corrigindo a seleção de padrões de palavras e renomeando a seleção, adicionando suporte para arrastar e soltar nos painéis, etc ...

Além disso, a maioria do SO não oferece suporte a um sistema de tiling adequado para suas janelas, então divirta-se gerenciando cada um deles ...

@MangelMaxime Você percebeu que novas janelas seriam opcionais?

@ jez9999 Sim, entendo isso, assim como entendo também que não é um recurso simples de adicionar e manter no futuro. :) Só dar minha opinião depois parece que a maioria das pessoas já deu +1 :)

@MangelMaxime
"Você não pode ler vários arquivos ao mesmo tempo e manter o foco"
Se você pode clicar-redimensionar-ler vários arquivos, então certamente você pode ler vários arquivos sem clicar e redimensionar primeiro.
Além disso, nem sempre é o código que você fica observando. Às vezes, você observa a saída ou insere alguns comandos no terminal. É por isso que vou ficar com o IntelliJ até que esse recurso chegue ao código do VS.

@ramazanpolat
Esse é um bom ponto de fato, mas para console ou comando, já temos o aplicativo de console, por exemplo, que deve fazer um trabalho melhor no IMO geral.

Desisto.
Não é uma boa ideia ter suporte para vários monitores.
É caro, tornará a manutenção do aplicativo mais difícil e impedirá os usuários de focar no código. Além disso, um monitor é definitivamente mais barato do que dois. Você não tem que mover seus olhos para a esquerda e direita e para cima e para baixo, você apenas olha diretamente para o meio da tela e usa o mouse para mover o conteúdo relevante para o meio da tela. Desta forma, você também pode achar monitores de tamanho menor mais atraentes, devido ao seu tamanho compacto e preço mais barato.

EDIT: Aparentemente, alguém não entendeu o sarcasmo.

Desde que foi lançado, o Code não tinha suporte para vários monitores e presumi que a escolha foi feita intencionalmente. Dito isso, não sei se acharia útil. Eu uso o Code em um monitor e meus navegadores e emuladores na outra tela. -1.

Por que votar contra só porque você não iria usá-lo?

Eu votei para fornecer feedback sobre um nível de prioridade que acho que o recurso deve ser fornecido no backlog. Esse não é um recurso que eu priorizaria e, na verdade, acho que vai contra o design e a intenção (consulte "Desde que foi lançado, o código não tinha suporte para múltiplos monitores e presumi que a escolha foi feita intencionalmente." ) Obrigado pela pergunta!

É caro, tornará a manutenção do aplicativo mais difícil e impedirá os usuários de focar no código.
Além disso, um monitor é definitivamente mais barato do que dois.

sim! Se eu não gosto de pão, ninguém deveria comê-lo! Apenas bagunça as lojas, torna-as mais difíceis de manter. Evita que as pessoas se concentrem em outros alimentos mais importantes.
Além disso, você não precisa mais de manteiga, o que torna a vida definitivamente mais barata.
Que discussão absurda ...

diga-me se estou correto. Se o recurso estiver integrado agora. versus se o recurso for integrado posteriormente, quando o código teria se tornado mais complexo devido aos "recursos necessários". Não seria melhor incorporá-lo agora, quando o sistema geral é relativamente mais simples?

Tenho ótimas notícias para quem (como eu) não sabia: parece que esse recurso já está (quase todo) implementado. Separar guias em janelas separadas __já é possível__ 🎉, com algumas advertências / soluções alternativas necessárias.

Etapas de preparação:

1. Abra sua pasta de projeto ou espaço de trabalho (se ainda não estiver aberto)
2. Arquivo> Nova janela
3. Feche a tela de boas-vindas na nova janela
4. (se a barra lateral estiver visível) Com a nova janela selecionada, clique em Exibir> Alternar barra lateral
5. (se a barra de atividades estiver visível) Com a nova janela selecionada, clique em Exibir> Ocultar barra de atividades
6. Maximize a nova janela no monitor # 2

Agora arraste e solte uma guia do editor da janela do seu projeto para a nova janela.
==> Boom: O espaço de trabalho agora é multi-monitor.
(você também terá que fechar a guia da qual arrastou)

Portanto, uma implementação mínima viável desse recurso não seria intratável se alguém pudesse automatizar as etapas 2 a 5 (+ fechamento da guia original) e acionar a automação quando alguém arrastar / soltar uma guia em uma parte da tela que não pertence ao vscode.

Ei, sim, essa é uma solução alternativa conhecida (como abrir o projeto várias vezes) e é declarada acima em algum lugar nos comentários. No entanto, é tedioso e - às vezes - pode levar a problemas com várias instâncias do projeto abertas ao mesmo tempo (essas instâncias não se comunicam diretamente entre si).

@RoyTinker "Eu mantenho um dos meus monitores de 22" orientado verticalmente. ", esse é um argumento válido!

Você também não pode depurar no outro editor. O único motivo mais útil para ter várias janelas é depurar no servidor (nó) e no cliente (Angular). Ter tudo amontoado em um único espaço é realmente irritante. Quero ter meus arquivos Angular em uma janela, meus arquivos de nó em outra e o Terminal em outra tela inteira para que eu possa ver o resultado do que está acontecendo. Tudo possível em algo como Web Storm, mas não VS Code. Isso realmente ajuda na produtividade e por esse motivo ainda uso WS em vez de VSC.

Boas notícias - subiu para o 13º lugar em solicitações de recursos classificadas por votos positivos. Precisamos apenas de mais 88 votos para chegar aos 10 primeiros.

mais um voto meu!

Votado, é a única coisa que falta na mudança do Sublime

Mais um voto, um recurso muito necessário.

E mais um voto!

mais um voto!

Adoraria ter esse recurso. Voto positivo.

Mais um voto.
Comentários como votos ajudam? Ou apenas gostei da postagem principal? Caso contrário, este tópico ficará meio inundado.

Gostei da postagem principal.

Polegar para cima no post principal é o que precisamos ... não vamos adicionar a este tópico a menos que tenhamos algo a adicionar à discussão. Obrigado pelos votos !! 😃

+1 voto de mim

Estou começando a precisar mais disso conforme os projetos ficam maiores. Seria um ótimo recurso, se o desempenho não diminuir por causa disso.

Seria ideal ter isso para alguma edição de texto também. Por exemplo, eu escrevo artigos de pesquisa em VS-Code. Também escrevo muita documentação baseada em Markdown no VS Code. Seria muito útil se eu escrever o código / texto em uma tela e obter a visualização (ainda dentro do VSCode) em um monitor externo (ou, uma segunda tela). Eu preciso e apóio totalmente esse recurso!

+1 voto meu! Vscode é incrível e vai ficar ainda mais incrível com essa funcionalidade!

@ amadare42

Gostar sempre é preferível ao método popular de +1. Gostaria que o GitHub tornasse isso mais óbvio com um botão +1 em cada postagem do que + [Emoji].

Sempre adorei o estilo reddit também

Viva, chegamos ao top 10 (na verdade, é o 9º agora). Apenas mais 68 votos e isso estará entre os 5 principais pedidos de recursos. (Para votar, adicione uma reação de "polegar para cima" ao comentário principal.)

Um polegar para isso. ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP

Vote de mim

1 para mim. Primeira coisa que percebi que faltou ao trocar.

Minha configuração atual do VS Community Edition:
Tela esquerda:

• Explorador de soluções
• Breakpoints
• Erros
• Propriedades
• Fonte de controle

Tela direita:

• Editor de código

Bem próximo disso agora é o "modo zen" ... mas não é quase a mesma experiência.

Então, por favor ... "flutue todas as coisas!" 🙏

Mas também acho que talvez não seja um trabalho fácil para desenvolvedores de vscode.
Este recurso talvez exija que os desenvolvedores de extensão implementem alguma interface se quiserem que suas janelas de extensão flutuem. O pior caso seria que todas as extensões antigas deveriam ser reescritas para suportar a flutuação.

Mas de qualquer maneira, se o recurso for bem feito e não exigir que os desenvolvedores de extensão se importem mais, isso seria gleit.

Ainda estou esperando por isso depois de mudar para o Code do Visual Studio :( Por enquanto, minha única solução é minimizar o aplicativo e estendê-lo manualmente para caber em meus monitores.

@nguyenlamlll Eu sugiro que você leia https://github.com/Microsoft/vscode/issues/2686#issuecomment -344808761

Este é um aplicativo incrível, e recentemente mudei do Webstorm para o vscode.
Eu realmente quero esse recurso !!

@bpasero "removido do backlog" - algum comentário? Ficaria triste em saber que a resposta da equipe é um "não".

@RoyTinker não, não tem nenhum significado específico, eu apenas prefiro que os problemas que me interessam não sejam atribuídos a nenhum marco, a menos que o trabalho esteja começando. Consulte nosso roteiro para saber o que planejamos trabalhar nos próximos 6 a 12 meses: https://github.com/Microsoft/vscode/wiki/Roadmap

Por favor, veja nosso roteiro para o que planejamos trabalhar nos próximos 6 a 12 meses

Não vejo isso lá, então parece que vocês continuam ignorando a alta demanda por esse recurso.
Por quê?

Sim, eu diria que esse recurso se enquadra firmemente na categoria "Codificação feliz". Mais de 400 votos positivos. Deve estar no roteiro.

Eu concordo plenamente que seria um ótimo recurso, mas, realmente, pessoal, dêem um descanso ao pessoal do vscode. Tenho certeza de que existem boas razões pelas quais ainda não começou. Devemos nos lembrar que este é um software livre;)

Obrigado @bpasero. Bom saber.

@ zewa666 sim, é grátis e incrível, estou grato por isso. O problema é que esses caras não estão dando uma resposta e mesmo que tenham um bom motivo para não implementar isso, o silêncio deles nos diz que eles simplesmente não se importam com esse pedido. Somos desenvolvedores, muitos de nós entenderiam um motivo técnico. Às vezes, o silêncio é pior do que uma resposta negativa.

Sim, é grátis. Mas - e posso estar errado - ele foi desenvolvido apenas pela Microsoft e por desenvolvedores da Microsoft. Se isso estiver correto, tenho certeza de que eles serão pagos por trabalhar nisso. Portanto, isso é pelo menos um pouco diferente de qualquer projeto comunitário que as pessoas fazem para se divertir e em seu tempo livre. Porque em qualquer outro projeto de código aberto como este, já teríamos uma resposta se e quando isso fosse implementado e, se não, por quê.
Isso é tudo que estou pedindo.
O silêncio é estranho para um projeto de código aberto, mas infelizmente típico para uma empresa como a Microsoft.

Há uma razão técnica pela qual esse recurso não está progredindo muito: estamos usando a estrutura Electron como uma estrutura de interface de usuário de plataforma cruzada que é baseada no Chrome por baixo. O Chrome tem um modelo em que cada janela obtém seu próprio contexto isolado, por exemplo, cada janela tem seu próprio processo e seu próprio contexto JavaScript. Eu não seria possível compartilhar o mesmo contexto entre várias janelas.

Agora imagine que você tem um editor onde digita e deseja arrastá-lo para produzir uma nova janela, você esperaria que a operação fosse muito rápida e leve. Mas, em vez disso, exigiria que criássemos uma nova instância do VS Code com um host de extensão separado, mesmo para ter o editor em uma janela autônoma (isso seria comparável a fazer Arquivo> Nova Janela e abrir esse arquivo na janela) .

Só vejo esse recurso possível quando encontramos uma maneira de criar janelas que compartilham a mesma memória da janela "principal" para que essa operação seja leve. Imho, não funcionaria ter cada uma das janelas flutuantes totalmente isolada como estão agora.

https://github.com/azain/electron-window-manager

@bpasero - ser leve para esse recurso não é tão essencial - já seria muito útil se duas instâncias do vscode fossem sincronizadas e eu pudesse simplesmente editar um arquivo na tela principal e ver o painel de problemas ou terminais na segunda tela serem atualizados imediatamente. Normalmente, eu abriria, por exemplo, um painel em uma segunda tela e teria essa configuração de tela aberta por horas.

Idealmente, eu gostaria de ter uma tela dividida com 1-4 janelas na segunda tela aberta lado a lado para ser capaz de dar uma olhada no painel de problemas e abrir terminais (por exemplo, mostrando testes de unidade e saída de cliente e servidor) - para que eu possa usar a primeira tela em tela cheia sem ter que abrir e fechar o painel lateral o tempo todo.

Muitas vezes me encontro na situação em que você abre e fecha o terminal o tempo todo com cmd + j ou tem que fechar todas as guias divididas porque deseja diferenciar as alterações lado a lado embora eu tenha uma segunda tela onde estas poderiam simplesmente permanecer abertas .

Obrigado pela resposta.
Eu também não me importo se for leve. Eu só quero ser capaz de mover o terminal e o console de depuração para onde me incomodar menos.

@bpasero

uh, não podemos manter o contexto?

    // 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);

Eu simplesmente sei sobre isso, já que essa é uma das principais razões pelas quais os portais React v16 são tão úteis.
https://hackernoon.com/using-a-react-16-portal-to-do-something-cool-2a2d627b0202

Obrigado pelas sugestões e discussão. Certamente há maneiras de se comunicar entre janelas, mesmo que elas vivam em processos separados. Ainda existe o desafio de que uma janela não está realmente ciente da outra janela. Bibliotecas como electron-window-manager parecem tornar isso um pouco mais fácil, mas afinal há uma tonelada de trabalho envolvido, para resumir alguns:

• cada peça (editor, painel, visualização) do ambiente de trabalho precisa ser executável em uma janela do navegador separada, o que significa que cada peça precisa ser totalmente independente
• a janela mestre precisa basicamente multi-plexar seu layout de bancada para várias janelas (por exemplo, se você abrir o painel de saída, ele deve focalizar a janela onde o painel de saída foi aberto)
• provavelmente o maior desafio: todos os nossos serviços que atualmente residem em uma janela (e que inclui todas as extensões e o host de extensão) precisam sair da janela para um back-end compartilhado com o qual cada janela pode se comunicar. para dar um exemplo: você inicia uma sessão de depuração em uma janela, mas a outra janela mostra o console de depuração, é claro que ambas as janelas precisam se comunicar com o mesmo backend de depuração

Eu não diria que isso é tecnicamente impossível, mas o que posso dizer é que essa solicitação de recurso é muito desafiadora por causa do impacto da interface do usuário e por causa da mudança fundamental que requer em cada aspecto do que temos hoje. Espero que faça sentido.

Espero que você almeje lançar este recurso passo a passo e não vá esperar pelos planos

+1 adoraria isso

@bpasero Desculpe pela pergunta n00b: o nativeWindowOpen poderia ajudar a resolver o problema?

+1 de mim e

@ Blackbaud-DustinLunsford, obrigado por uma solução simples

@ n9 Acho que a comunicação entre as duas janelas pode ser resolvida, mas os outros problemas que declarei permanecem, especificamente o fato de que cada janela tem seu próprio DOM e que todos os nossos serviços precisam se comunicar com o mesmo back-end de todas as janelas

Este é um ótimo recurso, conforme preciso!

@bpasero obrigado pela resposta!

Um definitivo deve ter na tela dividida 1 retrato, 1 paisagem.

Um dos motivos pelos quais ainda uso o Eclipse em vez do código VS. Código da janela em retrato - Ferramentas em paisagem

+1

Adoraria ver esse recurso chegando em breve 🙂

Bom trabalho; Eu amo o editor

Jesus

+1 ...! 😃

@bpasero Suspeito que haja um possível alvo intermediário 80/20 (% benefício / esforço) que não envolveria várias das complexidades que você mencionou.

E se os seguintes recursos pudessem ser adicionados:

• permitir que várias janelas apontem para o mesmo diretório de projeto
• adicionar opção de API interna para abrir uma janela "apenas editor" (ou seja, nenhuma barra de status, nenhuma barra de atividade, apenas guias do editor)
• permitir extensões para registrar interesse / desinteresse em janelas "somente editor"
• adicionar opção de API (interna) para abrir um arquivo em uma guia do editor com um buffer especificado (não salvo) em uma janela recém-criada
• quando uma guia do editor é arrastada para fora do aplicativo:
  
  
  
  • criar uma nova janela sem atividade e barra de status, com o arquivo e seu buffer atual (não salvo) (se aplicável)
  
  
  • feche a página do editor na janela original
  
  
• adicione ganchos para todas as janelas no mesmo diretório de projeto para sinalizar e ouvir + reagir em alguns eventos de IU:
  
  
  
  • guia do editor selecionada (atualizações do explorador da barra de atividades para apontar para o arquivo)
  
  
  • guia do editor fechada (talvez apenas defina o explorer para "nenhuma guia selecionada", selecionar a última guia pode ser difícil de coordenar)
  
  

@RoyTinker Acho que pode ser ainda mais simples.

Como primeira solução, não precisam ser 100% janelas "destacáveis". O APP real pode ser apenas um "contêiner" para várias telas que podem ser reorganizadas dentro.
Com um pouco de sorte, pode ser uma mudança muito simples na janela principal do VSCode.

@Rouche VSCode é implementado em Electron, o que significa que cada janela é um processo de cromo separado, acompanhado por alguns processos de back-end também. O "aplicativo" é um contêiner específico do sistema operacional que instancia / orquestra esses processos. Mudar esse modelo seria bastante fundamental (grande) neste ponto.

Estou um pouco desapontado por nunca ter sido uma consideração de design da
bem no início.

Na sexta-feira, 1º de dezembro de 2017 às 21h39, Roy Tinker [email protected] escreveu:

@Rouche https://github.com/rouche VSCode é implementado em Electron,
o que significa que cada janela é um processo separado de cromo, acompanhado por alguns
processos de back-end também. O "app" é um contêiner específico do sistema operacional que
instancia / orquestra esses processos. Mudar esse modelo seria
bastante fundamental (grande) neste ponto.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/10121#issuecomment-348621220 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAqQmoLrUY4l5H5xwroWCytBbgT2LIL_ks5s8HIqgaJpZM4JckZO
.

-

Programador de jogos

www.lucshelton.com

+1

Como um usuário do Visual Studio no passado, este é um recurso que sinto falta no VS Code.

+1

@bpasero O fato de cada janela estar em seu próprio processo não pode ser tratado como um problema de elétron? Não é uma sobrecarga desnecessária ter multiprocessamento para cada janela para uma estrutura como o elétron?

Bem, eu acho que a equipe do elétron pode apenas dizer que o problema está no cromo. Desde então, o chrome cria um novo processo para cada guia. A única solução seria mover o elétron para trabalhar em alguma outra estrutura inteiramente.

@vvavrychuk Este não é tanto um problema de elétrons, mas uma limitação fundamental da tecnologia da web. (elétron = cromo + APIs para acessar os recursos subjacentes do sistema operacional)

E se você pudesse init vscode em algum modo, "modo de extensão", por exemplo,
e passar por alguns parâmetros. por exemplo. vscode --extended-window --socket-id
((socket-guid)) --root-window ((root-window-guid))

Desta forma, você pode criar um soquete ou barramento de comunicação entre janelas
ou aplicativos independentes.

Cada janela estendida que é criada é atribuída a um id de janela raiz, e o
criou um ID de soquete UNIX para se comunicar.

Acho que existe a possibilidade de implementar algo assim.

Se o elétron tem uma maneira de abrir, ler e escrever soquetes, esta abordagem pode
ser bem sucedido.

@RoyTinker chrome tem a opção de "processo único", mas o elétron não oferece suporte https://github.com/electron/electron/issues/11398. Eles dizem que não podemos ter várias instâncias de node.js em um processo. Isso é de certeza. Mas eu não entendo por que precisamos de várias instâncias de node.js para várias janelas? Não podemos ter Electron = várias janelas + único node.js em um processo?

@ Jesus-Gonzalez Parece uma variação do que @bpasero disse que seria necessário para implementar isso, embora sua sugestão pareça mais fácil (pelo menos para mim) do que o item (3) de sua lista, porque a árvore de processo de elétrons "pai" abrigaria a funcionalidade de back-end, como o depurador.

No entanto, os itens (1) e (2) da lista de desafios de @bpasero permaneceriam. Além disso, adicionar comunicação de soquete às guias do editor / painel daria muito trabalho - se não me engano, muitas APIs internas teriam que ser atualizadas para serem assíncronas / baseadas em promessa em vez de síncronas, o que seria um esforço considerável .

@vvavrychuk por "processo único", estou me referindo apenas ao contexto da web (sem trabalhadores). Por "processo de elétrons" eu quis dizer mais uma árvore de processo, que incluiria um único contexto da web acompanhado por qualquer número de processos Node.js e alguns processos de cromo de fundo. Caso contrário, provavelmente não sou a melhor pessoa para perguntar.

+1

Algum progresso nisso? Adoraria ser capaz de usar VScode em ambos os monitores e dividir arquivos entre eles.

+1

Achei que todos ficariam felizes em saber - esta solicitação de recurso acabou de chegar ao quarto lugar por votos positivos. Apenas mais 150 e estará no top 3!

+1
Eu apoio fortemente a solicitação deste recurso.

+1 será muito útil para monitores maiores ou múltiplos.

+1
Estou usando um monitor 4k maior no meu escritório em casa, mas na minha mesa de trabalho, onde uso 4 monitores menores, isso é lento. Esta é a última peça que estamos perdendo, como outros disseram de uma mudança completa de outros editores.

@RoyTinker, onde podemos aprovar?

@pantonis Clique no ícone "polegar para cima" na parte inferior do primeiro comentário.

Adicionar um comentário que diz apenas "+1" não ajuda e apenas confunde a área de discussão.

+1. Aqui trabalhamos com back-end e front-end ao mesmo tempo. No monitor principal, back-end; na 2ª, o front-end. É o mesmo projeto e o mesmo espaço de trabalho. Deve permitir-nos abrir várias janelas com o mesmo espaço de trabalho / projeto.

Isso será implementado em breve? Acho que as guias precisam ser livres para mover-se para qualquer lugar, assim como as guias do Google Chrome. Mover-se entre as janelas abertas ou quando arrastado para a área de trabalho abrirá uma nova janela para essa guia. Isto é muito importante.

+1

Pelo amor de Deus, por favor, faça isso acontecer!

Sempre que atualizo meu adorável vscode, tento desanexar uma guia e não funciona! vamos lá pessoal isso já foi solicitado desde o primeiro dia.

Sem roteiro, sem marcos, sem promessas, o que está acontecendo!

800 votos positivos agora! Este é o terceiro em aprovação e o segundo em número de comentários

Adoraria ter esse recurso também.

+1 Concordo, adoraria ser capaz de arrastar minhas guias em suas próprias janelas. Não ser capaz de fazer isso acaba com o propósito de ter vários monitores.

Apenas 42 33 22 17 8 2 0 votos a mais e esta questão será a nº 1.

+1

@tavuntu O problema de comentar simplesmente com +1 torna a desordem inútil e envia spam para as pessoas que observam esse problema com uma notificação inútil.

Quer ver esse recurso sendo implementado? Adicione uma reação 👍 à postagem original e isso será o suficiente, não há necessidade de comentar o temido +1 comentário.

Até meu comentário é meta porque faz o mesmo (mais bagunça) e não deve ser necessário. Isso já foi falado neste mesmo tópico .

No entanto , vindo do Sublime Text, esse recurso foi algo que eu realmente gostei e gostaria de ver no VSCode um dia.

@ V-ed

Isso significa que estamos percebendo uma falha no sistema de reação do GitHub. Deve haver uma IU adicional para "+1 para este recurso" se o tópico de problema for considerado uma solicitação de recurso . Mas, espero que alguém com mais influência possa levar isso ao GitHub.

@ketozhang

De fato, e eu me lembro de ver alguém falar sobre uma ideia para o GitHub implementar um sistema automático de " +1 para conversão superior 👍", e isso seria ótimo para aqueles que ainda estão pensando em marcar com +1 adicione seu voto. Sua ideia de uma IU adequada para marcar uma solicitação de recurso com +1 / "Estou com este problema!" para problemas seria ótimo! A coisa é ...

Esta discussão está fora do escopo deste tópico e poderia ser discutida aqui (ei, na verdade, já é tudo o que dissemos até agora! _No entanto, as esperanças estão cada vez mais baixas com o passar do tempo ..._ _ ou não? _ ) - espero que algo aconteça em relação a esse problema. Ao falar sobre isso aqui, estamos apenas piorando as coisas - nos vemos do outro lado da força e tenham um bom dia!

Eu uso o vscode para trabalhar em uma grande solução c #, especificamente, arquivos 19644 c #. Visual Studio 2017 morre com exceção de falta de memória. Guias / editores flutuantes são essenciais, especialmente ao trabalhar com a configuração de monitor duplo.

Esta solicitação de recurso agora é # 1 em votos positivos. Conseguimos! 🥇

Acho que o Xcode faz isso muito bem se você está procurando inspiração.

Isso deve ser feito no início, quando você começar a escrever este editor. Guias / painéis móveis fora da janela principal (com a possibilidade de aderir à janela principal) são a função central de todo editor real, especialmente com as grandes telas 4k atuais e conjuntos de vários monitores (no caso de programadores profissionais).

É apenas uma base, requer projetar a API apropriada para a comunicação entre as janelas e seu gerenciamento, e depois disso você tem que construir o resto em cima disso. Você está atualmente em uma situação difícil de resolver de alguma forma, sem corromper tudo o que foi criado até agora, mas quanto mais cedo você aceitar este desafio, melhor para todos, depois de gastar mais tempo e escrever mais código pode ser tarde demais para essa mudança.

No mundo real, precisamos ver muito mais do que apenas o painel esquerdo / direito / inferior, esta solução https://github.com/Microsoft/vscode/issues/10121#issuecomment -335013296 é excelente.

O tom condescendente não corrige os bugs. Use 👍para votar.

Este recurso é solicitado há anos ... Por favor, implemente-o.

Para aqueles que desejam apenas abrir arquivos em novas janelas e foram conduzidos a esta página pelo Google, use o atalho de teclado para "Abrir Arquivos Ativos em Nova Janela";
Ctrl + K, O

É um recurso tão básico que pensei primeiro que a falta da janela flutuante era um bug: ')

Por favor, Equipe do VS Code, precisamos disso!

Suporte completo para várias telas !!

Este tópico foi aberto 1 ano, 6 meses e 4 dias atrás ....

Edit: Por ruim, bpasero respondeu ao tópico um ano atrás, vamos apenas esperar que a equipe tome este problema como o problema de referência para o Explore UX para item de plano de plano de iteração de fevereiro de 2018 !

@Aetherall e outros, por favor, leia mais adiante no tópico. Benjamin Pasero respondeu várias vezes. Ele é um membro da equipe VSCode principal.

Lembre-se também de que este é um projeto de código aberto. Alguns comentários parecem assumir que a MS nos deve algo aqui ... não é verdade.

Talvez o VSCode seja tão incrível que as pessoas às vezes presumem que é comercial :-)

@patrys esta é a questão mais votada e tenho certeza que você sabe disso, mas sim, você está certo, isso não será consertado magicamente, precisa de tempo e esforço, e as pessoas (como disse @Aetherall ) parecem pensar este é um software comercial (começou como um bom pedido, mas agora parece uma grande exigência)

Retirar a guia é o comportamento que desejo (da mesma forma que funciona no navegador Chrome). No entanto, eu me contentaria com qualquer capacidade de mover / abrir algo rapidamente em uma nova janela, como uma opção de menu do botão direito. No momento, preciso abrir um novo VSCode e reabrir o arquivo manualmente. Em nenhum dos casos, eu realmente quero uma janela flutuante como no Visual Studio. Eu quero gerar uma nova cópia do VSCode. As janelas flutuantes se perdem, eu só quero uma nova janela ...

agradável

@inarius veja o comentário de @ christopher-howard acima.

Obrigado @RoyTinker. Não consigo encontrar uma opção de menu para isso e com certeza vou esquecer o atalho, mas funciona! Acho que seria uma boa opção expor no menu do botão direito para a guia e / ou itens ativos no explorador de documentos do Open Editors.

Também descobri que o problema # 8171 parece ser exatamente o que desejo . Talvez as pessoas que votam nisto devam conferir aquele!

TIL, arrastar guias para outra janela vscode abre o arquivo nessa janela também. Infelizmente, ele não fecha a guia antiga que é esperada para a ideia de janela flutuante.

Esse comportamento é desconcertante para mim. Isso é semelhante a abrir as guias de visualização do Markdown, que às vezes também se duplica.

Ei @ketozhang ,

Infelizmente, ele não fecha a guia antiga que é esperada para a ideia de janela flutuante. Esse comportamento é desconcertante para mim.

Estranhamente, estou gostando desse comportamento - útil para fazer referência a partir do mesmo documento, assim como ao criar um novo bloco. Tenho certeza de que essa é a decisão de design por trás disso, mas seria interessante saber o contrário.

Saudações

Chiming com um movimento para desencaixar, especialmente a janela do relógio

+1
Recentemente, estive pesquisando monitores ultra amplos e, com o novo estado da tela, gostaria de utilizá-lo para obter produtividade máxima. O Visual Studio 2017 lida com isso muito bem para arrastar guias para se tornarem novas janelas, então esperamos ver algo assim em um futuro próximo.

+1. Seria muito bom ter a capacidade de arrastar guias para monitores diferentes, tornando-os uma nova janela.

++
Na verdade, há muitas pessoas trabalhando com dois monitores. Então, eu não gosto de ver informações de saída no meu pequeno código.
Devo ver apenas o código. Portanto, serei um milagre se o usuário puder mover o terminal / saída / guia para outro monitor ou fazer esta janela flutuante. E mais tarde selecione a janela necessária por Cmd + ~ por exemplo ou os resultados vistos em outra tela.

@bpasero por que não uma nova instância completa com todo o contexto do navegador, acabo fazendo isso de qualquer maneira quando preciso abrir uma segunda instância do aplicativo para preencher meu segundo monitor. IMO, isso não é o que acontece quando você abre dois navegadores e arrasta e solta guias entre eles? O vscode não pode fazer o mesmo com as guias de código dessa maneira? Seria fantástico ter essa habilidade. Tenho 2 monitores, um PC antigo s754 8GiB DDR2 e essa engenharia leve não beneficiaria muito minha configuração, nem máquinas mais novas mais potentes.

Este recurso de encaixe de janela já é VSCode. Mas, não sei recentemente porque não está funcionando ...

+1. Arrastar uma guia para fora da janela deve se dividir em uma nova janela, como praticamente qualquer outro aplicativo com guias que existe.

As guias não são minha prioridade. Mas a depuração destacável seria muito boa.

Esta edição está aberta há quase 1 ano e meio. Dê algumas respostas sobre o estado atual desse recurso.

Arrastar as guias fora da janela VS Code atualmente copia o arquivo (ou um atalho para ele?) Para o destino de arrastar. Isso não é nada intuitivo quando comparado a outros IDEs.

Pensando bem, a ausência de janelas flutuantes (como o VS propriamente dito) é meu único problema real com o VS Code. Precisa ser implementado.

@belst e outros veem este comentário , dado o design atual, é muito difícil implementar esse recurso

@Jorilx você sabe se há um problema relacionado ao elétron em algum lugar?

Seria muito bom ver o suporte para várias telas ou janelas flutuantes. Por enquanto, tenho que redimensionar manualmente a janela para caber em meus dois monitores (a linha vermelha é a borda do monitor), o que não é confortável.

Para mim, neste momento, essa é a funcionalidade mais necessária quando se trata de UI / UX.

+1! <3

@kodipe Não é o ideal, mas há uma solução alternativa para sua situação no momento. Salve seu projeto como um "espaço de trabalho", abra um arquivo, use a tecla de atalho Ctrl + KO (como vejo que você está no Windows) que é para mostrar o arquivo ativo em uma nova janela / instância. Agora adicione a pasta raiz do repo a essa nova janela / instância (porque agora é efetivamente um novo espaço de trabalho) ... Agora você tem duas janelas usando o mesmo espaço de trabalho em dois monitores. Como eu disse, não é ideal de forma alguma, mas é o que tenho usado como solução alternativa com o recurso de espaços de trabalho.

Isso é obrigatório para ter o recurso de interface do usuário. Isso prejudica a experiência e a produtividade do trabalho diário.

Bump, essa é a única coisa que me impede de mudar completamente para o VS Code.

Eu entendo o fato de que existem complexidades técnicas para implementar esse recurso.
No entanto, o fato de não haver qualquer indicação de atividade neste pedido é simplesmente ridículo neste ponto. Deve ser um dos recursos mais solicitados e literalmente não há comunicação da equipe vscode informando quando ou se planejam fazer alguma coisa.

Este é um produto gratuito e a Microsoft não nos deve nada. Isso não significa que eu não esteja extremamente irritado porque esse recurso nem está no radar. Existem várias páginas de problemas do github solicitando esse recurso. VsCode é um ótimo IDE, mas a falta desse recurso em 2018, quando todos nós temos vários monitores, é simplesmente constrangedor.

A todos que estão tentando desculpar isso devido a limitações técnicas: Por favor, lembre-se de que alguém teve a oportunidade de avaliar uma plataforma / linguagem para construir o vscode e decidiu por um framework que tem uma falha muito óbvia. Sinceramente, estou cansado de tentar obter alguma comunicação da equipe vscode.

Se isso não for adicionado ao roadmap do vscode em breve, acho que encontrarei um novo IDE.

@BentOnCoding Concordo que a falta desse recurso é incompreensível, mas como você disse, eles escolheram um framework que não é totalmente adequado para construir IDEs, então adicionar esse recurso seria um grande esforço e parece que eles não estão dispostos a fazê-lo .

Pergunta honesta, o Atom não está implementado no Electron também, e eles não suportam guias destacáveis ​​corretamente? A implementação deles não é adequada para a arquitetura do VScode, é isso?

@ruippeixotog Eu não acho que o atom suporta guias destacáveis. Você pode mover as guias entre as janelas, mas não pode criar uma nova janela arrastando uma guia para fora

@belst Ele ainda permite várias janelas no mesmo espaço de trabalho, o que é uma melhoria no VS Code.
Se o Code permitisse várias janelas no mesmo espaço de trabalho, mesmo sem arrastar guia para nova janela, seria melhor do que criar um novo espaço de trabalho para permitir várias janelas.

Essa confusão entre o movimento da guia e as janelas removíveis é exatamente o motivo pelo qual NÃO tenho suporte para guias removíveis. O movimento das guias deve gerar um novo processo em uma nova janela. Quero que funcione exatamente como o navegador Chrome.

A equipe do VScode respondeu a este tópico para discutir a dificuldade. Uma vez que existem várias abordagens para isso que podem ser tomadas, e vários problemas em aberto que foram combinados neste, espero que eles forneçam pelo menos alguma orientação sobre a abordagem que preferem aqui, para que esta solicitação de recurso não seja prejudicada por discussão improdutiva.

Este problema realmente só ganhou destaque nos últimos 3 meses ou mais. Imagino que ainda haja uma discussão interna em andamento.

Eu também adorava extrair guias e janelas do Visual Studio; Estou em um Mac agora e usando VSCode. Muito desapontado ao descobrir que esse recurso não é compatível. A experiência foi próxima ao Visual Studio e à extensão Python Tools for Visual Studio, mas ainda faltando algumas das coisas boas de se ter.

Vou me inscrever nesta edição para obter um ping quando esse ótimo recurso estiver presente.

Vou deixar meus dois bits aqui também. Seguir esse fio por muito tempo e ainda não tê-lo no final de março de 2018 (quase 2 anos) é uma pena. Cruzando os dedos para tê-lo disponível em breve.

É um recurso tão básico que pensei primeiro que a falta da janela flutuante era um bug: ')

@Aetherall 👍 Eu pensei a mesma coisa! Então eu vim e encontrei este tópico ... :-(

Este é um software livre. Você não pagou nada por isso. Se não possuir esse recurso realmente o impede de usar o VS Code, você está livre para contribuir com uma solicitação de pull que implemente pelo menos algumas das mudanças necessárias para que isso funcione. Alternativamente, você pode pegar seu zero dólares e gastá-lo em outro lugar.

O que você não deve fazer é reclamar e tentar culpar a grande equipe por trás do VS Code e fazê-la se sentir mal.

Se houvesse uma alternativa melhor, você a usaria em vez de perder seu tempo neste tópico, então da próxima vez diga "obrigado" em vez de "como isso ainda não foi feito".

@Nepoxx Você sempre pode abrir um novo problema com um título algo como "Discussão técnica para janelas flutuantes em processo" e um link para esse problema.

@Nepoxx Você está aqui apenas para dar opiniões

@patrys "você está livre para contribuir com uma solicitação pull que implemente pelo menos algumas das mudanças necessárias para fazer isso funcionar"

Isso exigiria que a equipe do VSCode discutisse publicamente um plano para implementar essa funcionalidade altamente solicitada. É um problema muito grande para qualquer indivíduo criar um grande PR implementando _até a funcionalidade mais básica_ - afinal, cada arquivo que lida com referências à janela ou espaço de processo exigiria atualizações, caso não fosse descartado e reescrito. Você honestamente acha que a equipe vscode fundiria algo que muda seu produto em um nível tão fundamental quando eles não estão dirigindo isso? Eu não iria. A comunidade não pode contribuir até que tal plano seja discutido abertamente.

_ (A maioria) _ das pessoas neste tópico não estão reclamando "Eu quero isso." ou "Faça porque tenho preguiça de fazer sozinho". A comunidade está preocupada porque esse é um recurso muito importante e tem havido pouca ou nenhuma resposta dos principais contribuidores além - essencialmente, "este é um problema difícil".

Imagine: você entra em um táxi e diz ao motorista o seu destino. Ele então estaciona o carro. Você espera um minuto, confuso por que não está se movendo e pergunta: "podemos ir?" Sem resposta. Depois de uma hora, você faz a mesma pergunta e ele responde: "São necessárias muitas voltas para chegar lá" e nada mais dirá. Você não ficaria ... confuso? frustrado? é assim que nos sentimos. Mas não vamos simplesmente pegar o volante e dirigir por nós mesmos, não é o nosso táxi.

Aqui está uma sugestão para todos que solicitarem isso, se as guias desencaixáveis ​​têm tanto valor para você e sua empresa. Por que não criar um financiamento coletivo para ele?

Se você pode pagar 4 monitores apenas para aumentar o benefício da produtividade, presumo que também possa gastar algum dinheiro no desenvolvimento de tal recurso.

Desculpe, não desculpe

@bpasero talvez devêssemos bloquear este assunto para comentários, porque estamos aqui discutindo sobre taxistas 🤣

Desculpe se estou errado, mas há algum tipo de suporte para várias janelas: https://www.npmjs.com/package/electron-window-manager

Se o UX do código VS funcionasse como o do átomo, eu faria a troca. Como está, continuo instalando o código do VS, amando quase tudo e, eventualmente, desinstalando quando percebo que a UX ainda não foi atualizada. Estarei observando esse problema, por favor, corrija.

Eu diria que a maioria das pessoas aqui não entendeu o ponto: o código VS não é um IDE, é um editor de código. Com alguns recursos interessantes adicionados (depuração), suporte brilhante para vários idiomas através de plug-ins, plataforma cruzada, etc., etc. Uma coisa que não é, é o IDE.

É por isso que é meu padrão para uma tela pequena (ou seja, um laptop, pois gerencia os imóveis de maneira brilhante) e outras plataformas além do Windows. Em uma estação de trabalho adequada, eu uso o Visual Studio. É isso.

IDEs adequados são ferramentas bastante caras. Veja a JetBrains - eles fizeram um negócio de sucesso construindo essas coisas;)

@mdmnk Não. É um IDE.

notepad.exe é um editor de texto, notepad++ é um editor de texto, vscode antes do terminal integrado, executores de tarefas, scm e debug _ era _ um editor de texto. _Que recursos os outros IDEs têm que vscode não tem? _ Tenho certeza de algumas coisas, mas não muitas.

Certamente é leve quando você não instala 1000 plug-ins. Não me importo de abrir vscode para editar ~/.bash_profile porque não tenho que esperar 4 minutos como faria com o Visual Studio ou WebStorm.

@rozzzly Visual Studio, pelo menos, tem um grande conjunto de recursos que o vscode não tem. Perfil de tempo de execução para .NET, ferramentas do SQL Server, um sistema de gerenciamento de teste massivo, ferramentas do Azure (nuvem da MS), rastreamento de tarefa / PR / problema integrado - para relembrar alguns da minha cabeça. É um produto verdadeiramente massivo. Por essa medida, o VSCode é apenas um editor, apesar da depuração integrada / etc. - não vem com tudo que você precisa para desenvolver e entregar software em grande escala ... nem perto.

@rozzzly -até mesmo a equipe de criação se refere a ele como editor em vez de IDE, então claramente não há nenhuma unidade para fazê-lo explodir totalmente o IDE.

Essas coisas custam dinheiro.

Veja o que @RoyTinker mencionou. Adicione cobertura de código, serviços de equipe, ferramentas de conflito de mesclagem, personalização completa do layout, gerenciador de pacotes integrado, explorador de nuvem, explorador de sql, explorador de servidor, insights de aplicativo, visualização de classe, navegador de objeto, etc etc etc.

VS Code é uma ferramenta incrível. No entanto, é gratuito, o que desde o início significa que terá limitações.
Se você não gosta, vá e pague a JetBrains ou a Microsoft por algo que tenha todos os recursos de que você precisa.

Espero que possamos parar de discutir quais obrigações esta ferramenta tem para implementar certos recursos. Essa parece ser uma maneira rápida de bloquear este tópico. Vou continuar a compartilhar o suporte para esse recurso com comentários positivos e raros comentários construtivos.

Existem várias maneiras de abordar isso. Ainda acho que precisamos de orientação geral da equipe VSCode antes que alguém possa direcionar seu apoio a outras formas de ajuda construtiva. Como outros mencionaram, ninguém pode realmente começar a trabalhar em um recurso tão significativo quanto este até que haja alguma garantia de que o trabalho será aceito.

@ michaljaros84 O fato de que o VS Code não pretende ser um IDE como o Visual Studio não impede de forma alguma os aprimoramentos de UX, como as janelas flutuantes em processo.

@RoyTinker Talvez possamos discutir os méritos de flutuar em processo versus instâncias separadas? Não vejo valor em aumentar drasticamente a complexidade se a mesma funcionalidade puder ser alcançada gerando um novo processo.

O fato de o Code ser um IDE não significa que precisamos portar todas as escolhas terríveis de UX para painéis flutuantes como VS.

Não vejo valor em aumentar drasticamente a complexidade se a mesma funcionalidade puder ser alcançada gerando um novo processo.

A mesma funcionalidade não pode ser alcançada gerando um novo processo, porque, AIUI, para linguagens que têm ferramentas baseadas em LSP, os dois processos não poderiam se comunicar com o mesmo servidor de linguagem, então você teria apenas o baseado em LSP recursos em um deles.

@inarius Claro, embora isso já tenha sido discutido acima (veja meu comentário "20% esforço / 80% benefício" ). Pelo que entendi, o caso de uso é suportar melhor vários monitores.

Por uma variedade de razões (como a mencionada por @HighCommander), o VS Code inicia apenas um espaço de trabalho por pasta (e atualmente um único espaço de trabalho não pode abranger várias instâncias).

Obrigado pelas respostas. Acho que posso entender isso. Para ser honesto, freqüentemente uso o VS Code abrindo arquivos e não pastas. Se eu estivesse trabalhando em um projeto git, poderia ver como meu fluxo de trabalho atual de abrir uma nova janela e arrastar arquivos para lá só me permitiria executar ações de pasta / git da janela original.

Quando tento fazer isso agora, o novo espaço de trabalho definitivamente não reabre a pasta, mas as ações git permanecem, mesmo se eu estiver trabalhando com arquivos abaixo do diretório do repositório.

@ Krzysztof-Cieslak Os painéis flutuantes são construídos para serem totalmente opcionais no Visual Studio (ou seja, nenhum recurso ou fluxo de trabalho exige que você os use), então não vejo como é uma má escolha de UX, mesmo do ponto de vista das pessoas que não não quero usá-los.

É uma pena que isso ainda não seja possível, pessoas com configuração de vários monitores lucrariam muito.
Então vote no recurso 💃

Seria uma maneira aceitável de permitir o uso de várias janelas para armazenar essas janelas na configuração do espaço de trabalho? Eu poderia imaginar uma forma de rastrear as janelas, uma vez abertas. Eu posso fazer algumas pesquisas mais tarde no código para ver se eu poderia encontrar uma maneira de ter pelo menos um espaço de trabalho abrangendo várias janelas.

No mínimo, remova a restrição muito arbitrária de abrir a mesma pasta em várias janelas.

@TedYav Essa restrição tem razões técnicas por trás dela - veja # 2686 para mais informações e discussão.

Portanto, a referência no Plano de Iteração # 47369 é apenas uma piada sobre obter um monitor 4k em vez de um plano para suportar isso?

@hosaka Correto, embora eu não tenha pretendido nenhum sarcasmo em meu comentário lá. Espero que não tenha sido assim.

@RoyTinker Nem um pouco, mas gostaria de esclarecer para que outros que leem não tenham esperança :)

Colisão. Eu também gostaria de arrastar as guias de código para a área de trabalho para editar em uma nova janela

Sendo um usuário de longa data do Visual Studio, o notepad ++, trabalhando por anos com 3 monitores (21 - 25 polegadas), é na verdade o único recurso que, após algumas horas de uso do Visual Studio Code, me impede de usá-lo. Tentei algumas vezes. Mas para mim ergonomicamente muito desconfortável e cansativo a um grau que me faz abandonar tudo de novo. Seria realmente ótimo ter isso.

Uau, esse é o recurso mais procurado de longe! : sweat_smile:

^^ https://github.com/Microsoft/vscode/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

E, surpreendentemente, os próximos recursos mais procurados estão muito relacionados: +1:

No momento, estou usando o vscode 1.22.0 com vários monitores e o atalho CTRL+k o para abrir uma guia em uma nova janela. Isso funciona muito bem para mim: sweat_smile:

O que significa o que exatamente? Existe uma estimativa de quando os 3 principais recursos serão implementados?

Op 9 jan. 2018 03:15 schreef Roy Tinker [email protected] :

Achei que todos ficariam felizes em saber - esta solicitação de recurso acabou de chegar ao quarto lugar por votos positivos. Apenas mais 150 e estará no top 3!

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/Microsoft/vscode/issues/10121#issuecomment-356148693 ou ignore o tópico https://github.com/notifications/unsubscribe-auth/AD90FPGlliOcLwiQbPIMFB5fITE42- 5Tks5tIr3GgaJpZM4JckZO .

As pessoas estão votando negativamente porque você não acrescenta nada à discussão, mas todos que se inscreveram nesta questão recebem seu comentário por e-mail.

Existe uma estimativa de quando os 3 principais recursos serão implementados?

Alguns recursos levaram 2 anos, desde o momento em que alcançaram o destaque até o momento do envio.

Isso agora está em alta demanda por 2 (DOIS!) Anos. Devo dizer, especialmente considerando o fato de que a Microsoft considera este seu "editor de código oficial", isso é muito decepcionante. Eu continuo adiando o uso, porque toda vez que tento, esse (e alguns outros recursos ausentes) me deixa muito lento.
Acho que é hora, pelo menos de uma declaração definitiva:

• Isso será implementado eventualmente? Se sim, quando? Se não: por quê?

@Hypernut Na verdade, os votos para essa questão só começaram a decolar por volta de dezembro do ano passado. Dê uma olhada no histórico de comentários e você verá uma postagem de (IIRC) há menos de 8 meses dizendo “Apenas mais X votos e isso estará entre os 10 primeiros”.

EDITAR: Link para comentários aqui: https://github.com/Microsoft/vscode/issues/10121#issuecomment -339404507
"Mais 104 votos para chegar ao top 10" em 25 de outubro de 2017.

Eu realmente quero esse recurso também - principalmente para ter a janela de depuração em um monitor diferente.

Uma solução mais fácil de implementar (?) Pode ser permitir que uma nova janela (CTRL + SHIFT + N) abra o MESMO projeto (atualmente não é permitido). Você pode então abrir todas as guias de que precisa nessa nova janela ou, se quiser apenas ter o console de depuração aqui, pode maximizá-lo para preencher a janela. Isso funcionaria, desde que as janelas permaneçam sincronizadas e quaisquer alterações de código / mensagens de depuração, etc. sejam atualizadas imediatamente em todas as instâncias da janela.

Por favor, adicione este recurso. Estou tendo que abrir os dois códigos do VS para imitar esse comportamento ... O que seria incrível se isso estivesse integrado.

Por que a rejeição vota em @ djm158 e @JustinAddams? Eu disse o mesmo que todo mundo fez no suporte a esse recurso.

@faustinoaq Sim. SIM! Obrigado, obrigado, obrigado!

Por enquanto, pelo menos, o Cmd-K o é bom o suficiente para mim - abrir um arquivo de origem em uma janela separada. Vi alguém solicitando o mesmo para janelas de markdown ... não usando isso, mas não deve ser muito difícil de conseguir com a mesma solução, certo? Ou talvez já seja possível usar o Cmd-K o?

Obrigado @steinhh pela teclado Cmd - K O . Eu não estava ciente disso ainda e vou usar isso na próxima semana em um sistema com vários monitores para ver se funciona bem.

Sua dica me fez encontrar os PDFs abaixo e também fazer as listas / screenshots abaixo.

Formidável! Obrigado, obrigado!

• https://code.visualstudio.com/docs/getstarted/keybindings ,
• https://code.visualstudio.com/shortcuts/keyboard-shortcuts-macos.pdf e
• https://code.visualstudio.com/shortcuts/keyboard-shortcuts-windows.pdf

As ligações (no Mac) que encontrei com suas capturas de tela:

• Cmd - Shift - P : mostrar todos os comandos
  
• Cmd - K O : abre o arquivo atual em uma nova janela
• Cmd - Shift - N : abrir uma nova janela
  
• Cmd - K Cmd - R : abre o PDF de referência de atalhos de teclado para o sistema operacional atual no navegador padrão
• Cmd - K Cmd - S : abre o editor de atalhos de teclado
  

O editor de atalhos de teclado tem uma pesquisa que pode encontrar ligações no próprio nome do atalho de teclado ou no nome do comando:

Quando mudei para o VSCode, me apaixonei por ele. É tão fácil de usar e rápido no meu computador lento!
Mas depois de usá-lo pelos primeiros 15 minutos, perdi essa função. Tenho 3 monitores e costumo trabalhar com 2 arquivos ao mesmo tempo ...

@steinhh Isso é bom, mas não é o que está sendo descrito no OP.
"_... opção de janelas flutuantes para:
terminalConsole de depuraçãoProblemasSaída _
"
Qualquer nova janela aberta com o atalho ainda terá todas essas subjanelas anexadas a ela.

@RoyTinker
Desculpe-me por ser tão descuidado. Tenho certeza de que a demanda surgiu de repente "em dezembro passado". Antes, ninguém queria nem sabia sobre janelas flutuantes. :)

De qualquer forma, a questão é: há alta demanda AGORA e está sendo absolutamente ignorada.

@Hypernut Não sou um membro da equipe VSCode, nem falo por eles. Estou apenas tentando ajudar a definir as expectativas com base em minhas observações sobre o comportamento passado deles e quando esse recurso teria aparecido pela primeira vez no radar "a demanda do usuário é alta".

@algiuxass O mesmo aqui. Estou surpreso ao ver que isso ainda não foi adicionado. É meu maior desejo ver adicionado com vscode. Não sou um desenvolvedor de elétrons, então não sei se isso é uma limitação dos aplicativos de elétrons ou se isso pode ser feito.

@RoyTinker
Eu sei que você não fala pela equipe VSC. Mas por que você sente a necessidade de "definir expectativas"?

Acho que 8 meses é tempo mais do que suficiente para, pelo menos, nos dar uma dica do que esperar. Especialmente considerando a especulação neste tópico, que pode não ser possível.

@Hypernut Como a equipe do VSCode não deu _qualquer_ indicação de seu cronograma ou planos com relação a esse recurso, há um verdadeiro vácuo de informações, o que deixa as pessoas muito frustradas. Estou tentando ajudar com isso usando dados do passado.

Não estou defendendo a equipe VSCode nem nada, apenas agindo com base em minha crença de que reclamações / etc. nos comentários não vai ajudar muito. Como eu disse antes, a melhor maneira de chamar a atenção deles é _muitas_ pessoas adicionarem seus 👍 votos à questão.

Se você quiser dedicar um tempo ajudando neste problema, sugiro ir a outros lugares online onde as pessoas que desejam este recurso podem acabar (Stack Overflow, reddit, etc.) e criar links para este problema.

Olá equipe do VS, POR FAVOR implemente este recurso. Não é realmente "muito", mas é um recurso disponível em outros editores que está faltando. Na verdade, é o único recurso que me impede de usar exclusivamente o VS Code.

Tenho pesquisado o problema das janelas flutuantes (meu conhecimento com elétrons é quase inexistente). Parece que o elétron oferece suporte a janelas sem moldura. Isso não poderia resolver o problema apenas criando uma janela sem moldura quando um usuário arrasta o arquivo para fora, como no Visual Studio?
https://github.com/electron/electron/blob/master/docs/api/frameless-window.md

@ Trevinlc1997
Sim, na pequena escala de um aplicativo, pode ser tão fácil quanto isso
VSCode é um programa complexo, eles não podem corrigir funcionalidades no núcleo, ou se tornaria um pesadelo para manter e melhorar (basta clonar o repo para ver o que diabos está acontecendo dentro da besta)

Minhas suposições (posso estar errado):
Se eles quiserem adicionar esta funcionalidade, eles vão querer implementá-la de uma forma que permita todo o seu potencial
A equipe do VSCode tomou conhecimento da demanda por este recurso, e o problema será mais fácil de lidar quando alguns outros recursos forem implementados, então, para evitar uma rolagem de 500m de explicações / discussões, eles preferem não dizer nada

Como isso ainda não é um recurso, é o único recurso que me impede de usar exclusivamente o VS Code ..

Foi o Language Server Protocol que me atraiu para o VSCode em primeiro lugar.

Como resultado desse problema, passei a contribuir para o suporte ao Language Server Protocol no Eclipse.

eu amo o VSCode. esta é a ÚNICA coisa que eu realmente não gosto. parece tão óbvio como um recurso, mesmo no editor mais minimalista. qualquer pessoa com uma configuração de vários monitores que tenta arrastar uma guia do editor para fora da janela sentiu a pontada de decepção ao vê-la voltar de onde veio. Equipe VSCode, por favor, coloque isso no topo da sua lista!

+1. Seria bom ter semelhante ao PyCharm / CLion.

Parece que um novo recurso foi adicionado para servir como uma solução alternativa para isso.
"Duplicar espaço de trabalho em nova janela".
Isso parece compartilhar o contexto / espaço de trabalho entre as janelas e resolve o problema básico de vários monitores.

Obrigado VSCode Team (e quem trabalhou nisso).

Eles também estão lançando um novo recurso de grade. https://twitter.com/joaomoreno/status/1004303587755855872?s=19

Sim, ele é!

Yehya Abouelnaga [email protected] schrieb am Fr., 8. Juni 2018 hum
12:22 Uhr:

@Deltatiger https://github.com/Deltatiger Isso já foi enviado?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/10121#issuecomment-395718792 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEVMyNsBaeorg-rczkcZsifgpi-jtPR7ks5t6lB7gaJpZM4JckZO
.

@Deltatiger
Se o seu objetivo é ser capaz de redimensionar e mover livremente, por exemplo, o terminal ou a saída (conforme descrito no OP), isso não resolve nada.
O suporte a vários monitores não é, de longe, o único motivo para querer esse recurso.

@Hypernut concordo totalmente.
Usei esse recurso como uma solução alternativa, no sentido de que agora posso ter uma janela (a janela original) para toda a Saída / Git / Terminal e criar uma nova janela para o código real.
Desta forma, obtenho mais espaço ao mesmo tempo que fico de olho no terminal / saída, que acredito ser um dos principais motivos das janelas flutuantes. Mas essa é minha perspectiva.

Também houve alguma discussão sobre a codificação Multi Window (sugestão original de Ctrl + K, O para abrir uma nova janela), então pensei em esclarecer essa parte aqui para todas as pessoas que procuram esse recurso.

Mas isso nunca dará a mesma liberdade que arrastar livremente mini janelas especializadas (digamos, uma para o Terminal, uma para o git e uma para, digamos, um segundo terminal).

Se esse recurso puder ser implementado, seria incrível.

Por curiosidade, por que você deseja separar o terminal em uma nova janela? Não seria melhor apenas abrir um novo processo de terminal fora do VSCode?

@ iansan5653 Bem, então por que colocar um terminal no VSCode em primeiro lugar? Por que não um aplicativo git separado? Um explorador de arquivos? Remover todos os plug-ins e fornecer apenas uma janela de código?

@ iansan5653 esse é o meu caso:
Costumo usar o WebStorm (que tem esse recurso). Minha estação de trabalho é composta por um laptop e um monitor adicional, que é girado verticalmente para uma melhor leitura. Portanto, eu configuro o IDE para aparecer da seguinte maneira:

• na tela vertical: janela principal do IDE com editor, barras de ferramentas e (eventualmente) divisão vertical
• na tela do laptop: explorador / esboço de arquivo do projeto, painel de terminal / teste / painel de depuração

Eu poderia viver sem isso? Sim, claro. Mas ainda acho isso agradável.

Eu prefiro que a equipe do Visual Studio (adequada) se torne melhor no suporte ao desenvolvimento / depuração de aplicativos do lado do cliente. Dito isso, esse é UM dos grandes motivos pelos quais não posso usar o VSCode para depuração.

Ao usar o recurso "Comparar arquivo com a revisão anterior", pode ser quase impossível ver certas diferenças sem ter que ir para o final da linha, pois o editor é dividido em dois em uma tela. Ter a opção de abrir as duas versões em duas janelas seria uma verdadeira economia.

Acho que precisa dessa função.

Notepad++ tem esta função para flutuar a janela, mas não consigo encontrar vs code tenha.

Então, se eu quiser flutuar a janela na minha outra tela, ainda preciso abrir uma nova janela e abrir meu arquivo, acho que é muito trabalhoso para usar.

Então, por favor, adicione esta função.

E alguém que tem boas maneiras de resolver isso? Por favor me diga.

Obrigado!

PS: Tem alguém que só dá emojis, mas não para tentar ouvir outra ideia ou dar algumas maneiras de dominá-lo. Acho que vou desprezar essas pessoas

Algumas pessoas simplesmente não gostam de críticas negativas e deficiências, elas apenas sabem como lavar o chão, simplesmente soprar e ignorar, apenas saiba ...
Acho que essas pessoas provavelmente não podem se comunicar conosco.

Eu gostaria das janelas flutuantes / acopláveis ​​e as posições salvas para o próximo carregamento. Atualmente, posso esticar as janelas em vários monitores, mas a posição é redefinida para o padrão na próxima abertura. Principalmente, eu simplesmente não gosto das posições padrão dos painéis e quero movê-los.

@ CHN-STUDENT Acho que as pessoas estão dando: -1: votos porque concordam que precisamos (este tópico tem 270 comentários e é o mais: +1: questão votada). O tópico não é mais sobre o que queremos ou por que , mas como podemos implementá-lo, então vamos tentar manter a conversa positiva e focada em como ajudar a implementar esse recurso. :)

Esse recurso ausente é o principal motivo pelo qual não consigo usar o código VS.

Chiming com o que outros disseram - não ser capaz de encaixar os vários painéis é um pouco complicado para mim também. - Foi a terceira coisa que tentei fazer no VS Code (logo após mudar o tema para light, para ver os menus, e instalar as extensões mssql).

Para ser útil - o que seria útil para mim não é apenas ser capaz de abrir arquivos em várias telas, mas ser capaz de encaixar qualquer tipo de painel em qualquer lugar do IDE (incluindo abri-los em novas janelas que podem ser movidas para novas telas). - Minha configuração típica me faz abrir arquivos de código nas duas primeiras telas e ter um painel de controle de todos os painéis de "status" úteis encaixados na terceira tela.

Anexei abaixo um exemplo típico de como é a minha terceira tela (na esperança de que ajude) - desculpas pelo texto ofuscado:

A propósito, eu estava com a impressão de que a maioria das coisas de encaixe de painel que o Visual Studio faz estava embutido no .NET, é realmente tão difícil implementar isso? - De qualquer forma, o Visual Studio faz isso incrivelmente bem, talvez você possa entrar em contato com a equipe do Visual Studio Prime e pedir apenas o código emprestado para essa parte. ;-)

Edit: huh, parece que o VS Code é um aplicativo de elétrons ... bem, essa é uma decisão _interessante_ ... hrmm ...

Esta é a única razão pela qual ninguém em minha equipe usa o VS Code como plataforma de desenvolvimento primária. Continuamos a usar o VS 2017 - mesmo com toda sua óbvia fagilidade.

Tenho poucas dúvidas de que a equipe do VS Code deve perceber que isso é um - problemas de nível nuclear - então, obviamente, eles têm uma grande falha de arquitetura que simplesmente não podem resolver.

Esta é uma das três principais funções para um ambiente de desenvolvedor que o Visual Studio (e todos os outros ambientes de desenvolvedor oferecem suporte desde que Bill Cliniton foi apresentado). Portanto, isso não é algo que está na categoria de; "Oh, nunca pensei nisso!"

O VS Code simplesmente não consegue.

Cansei de ajustar os problemas / saída / janela do terminal para cima e para baixo. Seria um ótimo primeiro passo para torná-lo destacável.

Para ppl querer uma solução alternativa, se você criar um link simbólico para a pasta do seu projeto e abrir essa pasta como uma nova janela. Você obtém seu projeto em ambas as janelas. Para a equipe de código do VS, nunca "conserte" esse bug (a menos que você adicione o suporte a várias janelas ofc)

O comando "Duplicar espaço de trabalho em nova janela" adicionado à paleta de comandos algumas versões atrás não é uma opção melhor?

@JustinAddams

É uma solução alternativa. Tente acessar projetos com várias configurações de várias linguagens, ferramentas e estruturas (como .NET (mais ferramentas e libs) para back-end e lógica de negócios + abstrações de banco de dados e Angular / VueJS / React para front-end ou algumas outras estruturas)

A duplicação de um espaço de trabalho tem uma desvantagem realmente grande no uso da unidade de memória e armazenamento.
É essencialmente uma nova instância do VSCode no mesmo espaço de trabalho.
Executar serviços de idioma e servidores de idioma duplicados pode criar condições de corrida e uso pesado de HDD / SSD com acesso aos mesmos arquivos, especialmente com ferramentas que usam análise ampla do projeto.
Claro que você pode desabilitar essas ferramentas e outras coisas, mas quando se trabalha em uma equipe grande, sempre acontece que alguém submete a pasta de configurações do vscode (mesmo que seja gitignored - não me pergunte como isso acontece). Então vem o caos.

O armazenamento em cache também pode ser um problema.
A janela sem moldura do Electron pode ser uma solução legal implementada, mas no núcleo. Isso também vai demorar. Uma vez que é fundamental alterar o código principal nesse nível.
Eles provavelmente desejam implementar uma funcionalidade para a relação de desempenho / uso de RAM máxima, mas é muito complexo por causa de sua construção personalizada de Electron e núcleo complexo. Implementá-lo no núcleo pode tornar todas as janelas capazes de 'existência' sem moldura, como no Visual Studio 2015, 2017, WebStorm etc.

É uma funcionalidade crítica, especialmente para configuração de vários monitores. Compartilhamento de processos de espaço de trabalho único em arquivos abertos com várias janelas.

_Solução provável: Abra uma nova instância do VSCode em vez da implementação de janelas sem moldura, mas adicione uma opção de linha de comando para permitir que ele use as extensões compartilhadas da primeira instância (Problema: o host de extensão pode ser compartilhado ou está vinculado à instância?) ._

@JustinAddams É o que estou fazendo agora,

Também seria bom ter a configuração de visualização ajustada para visualização de espaço de trabalho duplicado ...

Por exemplo,

• Selecione quais pastas mostrar
• Qual painel visualizar
• Visibilidade do painel lateral

Etc

Além disso, a partir da janela do espaço de trabalho principal, nós, como desenvolvedores, poderíamos criar um serviço de ponte, que ouviria eventos de espaços de trabalho duplicados filhos, e a janela do espaço de trabalho principal poderia interagir com isso.

Caso de uso, por exemplo:

1. Abra a janela principal do espaço de trabalho

2. Criar subWorkspace por modelo pré-configurado

   como espaço de trabalho duplicado, mas crie um processo filho a partir da janela principal do espaço de trabalho.
   Um modelo pode ser nomeado, por exemplo, "Painel apenas" (teria apenas problemas, saída, console de depuração, terminal)

3. Na guia do terminal do espaço de trabalho filho, posso iniciar yarn test --watch ,

4. ... fazer a codificação, ou qualquer coisa que eu puder fazer ...
5. Se um dos testes falhar, eu apenas faço Command+Click na sessão vscode do sub espaço de trabalho
   5.1. Subworkspace direciona o evento para a janela principal do Workspace
6. A área de trabalho principal lida com o evento e mostra meu arquivo onde os testes falharam
   ……
   meio de lucro !!! …diria,

Mas eu vejo isso apenas como carregar uma sessão filho do Visual Studio Code, mas não vscode totalmente carregado, mas uma variante simplificada e mais leve de load ... Espero que não consuma muitos recursos

Além disso, os módulos no VSCode devem se comunicar por meio de algum middleware, que pode facilmente conectar várias instâncias entre si, portanto, na janela do espaço de trabalho filho, podemos ver o problema do ESLint, por exemplo …………

Talvez este "brainstorm" seja útil para alguém, espero que sim :)

Felicidades! E obrigado pela atenção ...

Para pessoas que sugerem abrir outra janela.
O principal benefício deste recurso é abrir terminal / saída / problemas em outro monitor, para que você possa ter uma lista de erros separadamente da janela de código. O mesmo pode acontecer com Ctrl-Click em um monitor e ver o código correspondente em outro.

Eu adoraria ver esse recurso adicionado. Tanto o Webstorm quanto o Phpstorm têm esse recurso, e é realmente a principal coisa que gosto nesses aplicativos. Eu uso um monitor de orientação de retrato como meu editor principal, e ter minha árvore de arquivos / painel explorador em um monitor diferente faz uma grande diferença para mim. Também gosto de ter meu terminal em um monitor diferente, mas sempre posso usar um terminal que não esteja integrado ao código vs, mas ter janelas destacáveis ​​em código vs para esses painéis seria incrível.

Então? 2 anos e nada?
Não suporto painel de "busca" integrado, porque é sempre enorme e largo.

Acho estranho que, embora agora tenha dois anos e seja o recurso mais desejado e discutido aqui, ainda esteja sendo completamente ignorado pelos desenvolvedores.
Estou com medo, eles já acharam muito complicado / muito trabalhoso há muito tempo, decidiram que não vale a pena e calaram para atrasar a precipitação o máximo possível ...

E devo dizer que estou ficando um pouco chateado com essa falta de comunicação. Talvez eu esteja errado, mas cheira muito a política da Microsoft ...

Estou com medo, eles já acharam muito complicado / muito trabalhoso há muito tempo, decidiram que não vale a pena e calaram para atrasar a precipitação o máximo possível ...

Não tenho ideia de como isso pode ser tão complicado. Incontáveis ​​outros softwares já fizeram isso, estão fazendo e continuarão fazendo, então não estou totalmente certo do que os está impedindo de implementar um dos recursos mais solicitados.

É porque nenhum desenvolvedor está atualmente alistado para trabalhar no VSCode? Não é considerado digno o suficiente, pois o VSCode não pode ser monetizado?

Não estou totalmente certo de que o argumento "isso pode ser muito desgastante para os computadores" é válido ultimamente, considerando que os computadores mais recentes têm muito mais recursos do sistema do que antes. Além disso, se provar ter esse efeito nas estações de trabalho, tenha a oportunidade de desligar totalmente esse recurso.

Ter a opção de usar isso ou não seria muito melhor do que não ter nenhuma escolha, francamente.

VSCode é usado por pessoas que CODE. Se os codificadores não conseguem descobrir como ativar ou desativar um recurso, talvez eles estejam usando o software errado.

Além disso, ações serão tomadas para reduzir o consumo de recursos do sistema, mas evitando adicionar novos recursos como este com base na antiga crença de que "a maioria dos usuários não saberá como desligá-lo, por isso é ativado por padrão na instalação, o software pode ser realmente lento em vários computadores e isso nos deixará mal "é o pior argumento possível dado para a falta de implementação, porque isso implicaria que sua base de usuários-alvo é menos tecnologicamente limitada do que a maioria.

Da última vez que verifiquei, não era esse o caso.

Meu melhor palpite é que é difícil para eles criar uma nova janela com a guia e manter a guia em seu estado por causa do elétron. Eles precisam criar uma nova janela cada vez que você arrasta uma guia para dentro de sua própria janela e, obviamente, isso não é uma coisa fácil de fazer. Especialmente para coisas como o terminal, barra lateral, etc.

Eu ainda quero esse recurso desesperadamente.

@Penagwin Da mesma forma, mas como não sei qual é o raciocínio técnico para não ser capaz de implementá-lo, também vou ser educado e reservar o julgamento e esperar pacientemente como todos os outros. 😄

Uma solução alternativa nesse meio tempo é abrir duas janelas, abrir uma pasta pai e uma pasta filho do mesmo projeto. Por exemplo, abra o diretório do seu aplicativo em uma janela e a pasta 'pública' na outra janela. A desvantagem é não arrastar e soltar guias entre eles, mas, por outro lado, funciona.

A todas as pessoas que propõem a solução alternativa com 2 janelas. Isso não ajuda em nada com o problema real de ser incapaz de ter coisas como inspetor de depuração ou terminal / saída e assim por diante em uma segunda tela.

Use "Ctrl K, O" para abrir o arquivo atual em uma janela diferente do vscode para edição. Você terá que definir o diretório padrão do terminal novamente para que a janela recém-aberta seja construída. Funciona apenas com arquivos; não nas janelas do terminal. Eu sei que não é o mesmo que arrastar e soltar, mas deve ser útil se você precisar apenas mover alguns arquivos para outra janela para usar o segundo ou terceiro monitor. Nada de errado com uma solução alternativa, já que não temos uma solução. O mundo não é perfeito, faça o melhor com o que temos e faça o trabalho. Espero que isso ajude até que algo melhor apareça. Boa codificação!

É difícil acreditar que já se passaram 2 anos e houve tão pouco progresso nisso. Eu estava começando a me apaixonar seriamente pelo código VS, pois, de modo geral, é um IDE incrível. Não posso, entretanto, considerá-lo um candidato sério para o desenvolvimento profissional sem o suporte multi-tela. Olhando através desses comentários, parece que não estou sozinho nessa visão.

De volta ao Webstorm por enquanto = (

Estou observando esse recurso há um tempo, apenas adicionando outra voz dizendo "Eu realmente queria que isso acontecesse!" Se o código VS pudesse implementar isso, seria o editor perfeito !!

Por que isso ainda não é uma coisa! Qual é o atraso neste recurso ... O código VS é um ótimo editor, mas este é um dos principais recursos ausentes ...

Isso realmente precisa acontecer! Grande descuido por parte da Microsoft.

Por favor, rapazes, façam! Este é o recurso mais desejado de todos os tempos: dançarino:

Estou trabalhando com 3 monitores e preciso ter esse recurso, porque às vezes no código preciso ver quais funções preciso implementar de um arquivo e preciso abrir isso em uma janela separada para copiar e colar o que Eu quero em vez de dividir a janela dentro de um monitor que pode limitar a área do espaço de trabalho.
Por favor, implemente este recurso para flutuar as janelas (desanexação de janela).

+1. Isso seria realmente muito útil para a produtividade de vários monitores.

Este pedido de recurso celebrou recentemente seu segundo aniversário. Duvido que algum dia seja implementado :(

+1 Alguma atualização sobre este recurso?

Parece que querer esse recurso está relacionado a não ter a capacidade de usar o GH corretamente nem se comportar bem na discussão na Internet. O spam irracional +1 definitivamente ajudará em sua causa.

@ Krzysztof-Cieslak Deve haver uma opção para desativar os comentários sobre um problema e permitir apenas reações ao OP

@ Krzysztof-Cieslak Acho que +1 está relacionado a um voto e não a uma discussão.

Um +1 é freqüentemente usado para aumentar a conversa para que os caras da Microsoft não percam o problema;)

@SkyzohKey , já está aberto, não vai perder nada.

Alguma chance, uma vez que MS possui o github e essencialmente o projeto de elétrons, isso realmente verá a luz do dia? Eu concordo que este é um problema fundamental para o editor, caso contrário, é muito bom.

@ napalm684 Bom ponto, no entanto acho que isso não é um problema no Electron (https://github.com/Microsoft/vscode/issues/10121#issuecomment-346088717), mas com a própria arquitetura VSCode (https://github.com / Microsoft / vscode / issues / 10121 # issuecomment-346290180).

Ah, li originalmente @ n9 que era um problema de elétrons. Apesar de tudo, acredito que esta é a solicitação de recurso número 1 no momento, correto?

Haverá esse recurso na próxima versão principal?

Eu sei que todo mundo não gostou de ser pressionado, mas,
Espero que esse recurso seja a prioridade máxima.
Eu sei que este é um freeware de código aberto, mas essa limitação pode impedir que novos usuários usem o VS Code.
Estamos felizes em usar um novo IDE incrível, e somos populares, não é?

Então, sim ... aqui está mais um desenvolvedor que deseja desanexar as guias do VSCode, assim como trabalhar com o VS.

O mesmo que a maioria das pessoas aqui:
Eu adoraria ter mais de uma janela de código VS para uma única pasta / projeto e trabalhar em mais de um monitor.

IDE incrível, no entanto 👍
Continue assim, estou amando seu trabalho.

Eu também gostaria muito de poder abrir o mesmo diretório em várias janelas.

👍

Eu adoraria desconectar o console do depurador para ver no segundo monitor

+1
A solução alternativa (abra uma nova janela e arraste e solte o arquivo da área de trabalho / janela atual para a recém-aberta) está OK, mas não tenho acesso à área de trabalho em si; configurações diferentes, sem acesso a outros arquivos no espaço de trabalho, etc.

Mas, além disso, o VSC É INCRÍVEL!

Tentei verificar o que poderíamos fazer com janelas flutuantes no VSC.
Em primeiro lugar - o Electron suporta várias janelas. É possível abrir uma instância adicional do BrowserWindow, mas é necessário um arquivo HTML no carregamento.

Nesse caso, vamos considerar o terminal em janela flutuante. Não sou tão fluente quando se trata de código VSC, mas parece que todos os aplicativos estão sendo executados como "aplicativo monolith". Isso significa que se quisermos ter algo da IU do VSC em uma janela adicional, temos que carregar todos os aplicativos lá e ocultar as partes desnecessárias da IU.

Parece bom? Na verdade não. Na janela adicional, temos que ocultar as partes desnecessárias da interface do usuário, mas também ... desabilitar a atualização de outras áreas do aplicativo na mudança de arquivos ou atalhos. Além do mais ... Não sei como a memória Electron está funcionando, mas acredito que se carregarmos todos os aplicativos na segunda janela, o uso de memória do VSC aumentará drasticamente.

Acho que devemos tentar fazer o VSC mais modular e preparar algum tipo de mecanismo de múltiplas janelas antes de começarmos a trabalhar em janelas flutuantes com partes únicas da IU.

Querida comunidade, vamos tentar ajudar a equipe VSC.

Um +1 é freqüentemente usado para aumentar a conversa para que os caras da Microsoft não percam o problema;)

Nah, agora eles estão acostumados a ignorar o problema. :) É como colocar um bilhete no espelho do banheiro. No início, você não pode ignorar, mas depois de um tempo você nem mesmo vê mais.

Eu não sou um cara do Electron de qualquer tipo, mas eu tenho mexido um pouco com isso. Não seria possível abrir uma nova janela e fazer a comunicação entre a janela pai e a criança por meio da API webContents?

@kodipe

@scriptcoded boa pergunta!

Acabei de encontrar este projeto https://github.com/illBeRoy/ElectronScriptWindow que permite o uso do BrowserWindow sem arquivo HTML específico. Basicamente, ele cria uma string codificada em base64 como URL para a janela: https://github.com/illBeRoy/ElectronScriptWindow/blob/master/src/index.js#L76 no carregamento. Depois disso, devemos ser capazes de controlar o filho dos pais via webContents.

@kodipe Neat! É uma maneira bastante inteligente de fazer isso. Talvez eu olhe mais de perto as fontes e descubra se essa seria uma boa maneira de fazer isso. Eu suspeito que isso implica em uma forte reescrita de um monte de recursos principais.

@scriptcoded sim ... é realmente difícil de obter recurso neste momento. Vou procurar uma solução para alguma API FloatingWindow simples e vou compartilhar com vocês aqui se eu criar algo interessante no meu fork.

+1 para este recurso

Eu atinjo essa limitação algumas vezes por dia, é um grande recurso que falta para mim.

Gambiarra:

1.) Abra a pasta do seu projeto
2.) Salvar como um espaço de trabalho
3.) Abra a área de trabalho em uma janela e a pasta do projeto na outra

espero que isto ajude

Este recurso está vencido e é crítico para a produtividade com vários monitores. Quantas respostas você precisa para adicionar este recurso ao escopo? Posso fazer com que todos os meus colegas respondam, se quiser.

E quanto a https://www.npmjs.com/package/electron-window-manager ??

@WNemencha Estou assumindo que a equipe não quer dependências desnecessárias. Talvez ordenou isso?

Espero que consigamos isso eventualmente, isso é obrigatório :)

Para continuar inovando e fazer do VSCode um editor moderno e completo, isso é uma necessidade. Essa deve ser uma das principais metas de longo prazo até que seja realizada.

Esse recurso realmente deve ser um recurso de alta prioridade. Não conheço nenhum desenvolvedor que codifique apenas em um monitor e ter a capacidade de arrastar uma guia para uma nova janela para uso lado a lado é um recurso muito útil para não ter.

Esse recurso realmente deve ser um recurso de alta prioridade. Não conheço nenhum desenvolvedor que codifique apenas em um monitor e ter a capacidade de arrastar uma guia para uma nova janela para uso lado a lado é um recurso muito útil para não ter.

Ei, @oryandunn , o que você está reclamando é realmente possível. Veja meu comentário adicionado a este tíquete:
"Abra uma nova janela e arraste e solte seu arquivo da área de trabalho / janela atual para a janela recém-aberta."

Este tíquete é sobre como abrir duas janelas no MESMO espaço de trabalho.

@kapalkat para esclarecer, esse problema é sobre como desanexar partes da IU, como o terminal, o explorer e o depurador, da janela principal. # 2686 trata de várias janelas com o mesmo espaço de trabalho.

Acho que esse problema deve ser congelado / restringido até que alguém possa realmente trabalhar nele (da equipe VSCode).

Não creio que possamos esperar esse recurso a qualquer momento no recurso próximo. Pelo meu entendimento, a equipe teria que mudar muito a infraestrutura para fazer esse trabalho. Não apenas isso, não tenho certeza de quanto mais será afetado.

Também duvido que isso tenha algo a ver com o elétron (não é uma restrição / problema do lado do elétron). É apenas limitado pela arquitetura atual.

Este tópico está sendo preenchido com mais comentários +1 do que realmente úteis.

Este tópico está sendo preenchido com mais comentários +1 do que realmente úteis.

Essa base de usuários está frustrada porque falta suporte a vários monitores. De que outra forma os desenvolvedores devem obter informações sobre o que a base de usuários deseja?

De que outra forma os desenvolvedores devem obter informações sobre o que a base de usuários deseja?

Ao deixar um 👍, e manter a área de discussão clara para uma discussão construtiva, como:

Eu gosto bastante da implementação que o VS teve, onde ao arrastar qualquer parte da interface do usuário ele pode "se encaixar" em parte da tela. Semelhante a como arrastar uma guia agora permite que você intitule a visualização principal.

Para ser honesto, porém, a única coisa que eu realmente quero fazer é arrastar as guias do editor de código para fora. Eu nem me importo em poder colocá-los fora da janela principal, porque então posso apenas usar o gerenciador de janelas do sistema operacional.

Todos batem palmas por @mrmos e sua solução .

@jayarjo Tenho feito algo semelhante abrindo uma nova janela do vscode e arrastando minha guia para lá. O problema aqui é que nenhuma das descobertas funciona corretamente, pois não contém nenhuma informação sobre o "espaço de trabalho" real de onde veio.

Como uma solução simples, você pode usar o comando Duplicar Espaço de Trabalho em Nova Janela (desde a versão 1.24) para abrir a pasta / espaço de trabalho atual em uma segunda janela de código do VS que pode ser movida para um monitor separado. Atribuí o Ctrl + Shift + N para este comando.

@ n0v1

Como uma solução simples, você pode usar o comando Duplicar Área de Trabalho em Nova Janela

Hmm, parece que não tenho essa funcionalidade no macOS mais recente - ela precisa ser ativada?

Saudações

@ldexterldesign Você tentou executá-lo abrindo a paleta de comandos ( ⌘ + SHIFT + P ) e digitando Duplicate Workspace in New Window ?

@ n0v1 o problema não é abrir um arquivo / área de trabalho em uma nova janela. Manter o contexto do buffer subjacente (arquivo) em ambas as janelas é o problema.

Para deixar claro, abra um arquivo em um espaço de trabalho e abra o mesmo arquivo no espaço de trabalho duplicado. Agora, edite o arquivo em uma janela, ele não será refletido na outra janela.

Todos agora estão contando as coisas do espaço de trabalho duplicado, mas isso agora é conhecido por todos e não precisa ser repetido com tanta frequência. E toda essa "solução alternativa" nem mesmo é prática, precisamos de um recurso de janela flutuante real como o implementado em outros editores.

Pare de sugerir "Duplicar espaço de trabalho". Essa não é a solução. Precisamos do explorador do espaço de trabalho duplicado também. O que não é.

Eu adoraria ver a capacidade de desanexar o console (e outras partes do editor) e colocá-los em uma tela separada, permitindo-me obter todo o estado da minha tela principal para escrever e ler meu código quando estou trabalhando em algum lugar com várias telas /

Isso também me permitiria gerenciar e trabalhar melhor enquanto estou em movimento, onde só teria minha tela principal disponível para trabalhar, como em um trem ou nas instalações do cliente.

Não consigo ver nenhum progresso neste recurso e alguns anos atrás. Se ficamos presos por limitações arquitetônicas que custam muito caro para que isso aconteça, por que não simplesmente fechá-lo e seguir em frente?

Não se esqueça que temos a comunidade VisualStudio, por favor, considere mover algum recurso para o plugin VS.

@Nyconing VS não roda em Linux ou Mac.

@Nyconing VS não roda em Linux ou Mac.

Não é bem verdade ...

OK, comunidade.

Qual é a melhor maneira de mostrar um arquivo (com teste de unidade) no monitor esquerdo e o segundo arquivo no monitor direito?

Por favor, não tente recomendar o uso de Vim, Emacs, Visual Studio Enerprise, Sharp Develop, Eclipse, Jetbrains ou pode ser Notepad.

Qual é a melhor maneira de mostrar um arquivo (com teste de unidade) no monitor esquerdo e o segundo arquivo no monitor direito?

Não faça postagens duplas, por favor. O melhor que posso oferecer seria redimensionar a janela para cobrir ambas as telas e dividir o editor em dois blocos no meio entre os monitores.

Não faça postagens duplas, por favor.

Existem alguns problemas internos no próprio GitHub

Não é bem verdade ...

funciona em mac com wine ou windows vm

@ hellboy81 @belst Meu mal, pensei que você disse Código VS. Desculpa! De volta aos trilhos agora ...

Só meus 2 centavos
"Ctrl + K depois O"
está vinculado a "Abrir arquivo ativo em uma nova janela"

Só meus 2 centavos
"Ctrl + K depois O"
está vinculado a "Abrir arquivo ativo em uma nova janela"

Como outros já disseram, abrir em uma nova janela não é o que estamos pedindo ou querendo.

Estamos procurando a capacidade de abrir uma janela e movê-la para onde quisermos, basicamente como o premire pro faz com os diferentes tipos de paletes,

Só meus 2 centavos
"Ctrl + K depois O"
está vinculado a "Abrir arquivo ativo em uma nova janela"

Como outros já disseram, abrir em uma nova janela não é o que estamos pedindo ou querendo.

Estamos procurando a capacidade de abrir uma janela e movê-la para onde quisermos, basicamente como o premire pro faz com os diferentes tipos de paletes,

Eu concordo totalmente com você. Eu só estava tentando ajudar com uma solução temporária que uso enquanto espero por esse recurso.

Eu só quero expressar minha opinião sobre isso. Acho que muitos desenvolvedores têm mais de um monitor e usá-los de forma eficaz é uma grande vitória para a produtividade.

Não sei por que esse recurso nunca progride, pois tem um suporte massivo e, dado o código do aplicativo de elétron, é perfeitamente realizável e degradável se você já executou fora do elétron.

Em uma palavra, por favor, suporte MDI em vscode.

Até que o VS Code tenha suporte a vários monitores, não acredito que a mudança para este editor seja meu padrão. Recentemente, comecei a usar as ferramentas JetBrains como alternativa. Tenho assistido a esta edição por mais de um ano e ainda não há nenhum movimento sobre isso. Não tenho certeza do porquê do atraso?

O Xcode permite várias janelas para um projeto. Ainda mais, as janelas são todas iguais, janelas totalmente funcionais, o que significa que você pode abrir uma segunda janela e fechar a janela do projeto original e ainda ter uma janela inteira do projeto.

Essa abordagem significa que vários monitores são facilmente suportados. Isso também significa que não preciso cuidar do gerenciamento de janelas tanto quanto não preciso lembrar qual é a janela "real" do projeto.

Essa abordagem seria muito apreciada no VS Code.

O Xcode permite várias janelas para um projeto. Ainda mais, as janelas são todas iguais, janelas totalmente funcionais, o que significa que você pode abrir uma segunda janela e fechar a janela do projeto original e ainda ter uma janela inteira do projeto.

Quão? Quando tento abrir o mesmo espaço de trabalho no Mac OSX, ele sempre focaliza apenas a janela já aberta.

Como o VSCode é escrito com "janelas flutuantes" do Electron, é meio difícil de fazer, mas permitir abrir o projeto duas vezes ajudaria muito, mas também não parece funcionar. Qualquer ajuda é apreciada.

Entrando e declarando minha própria experiência: Eu usei com sucesso o VScode no passado para compilar e depurar um projeto de motor de jogo para o qual eu contribuo, mas como não posso fazer janelas desanexadas com VScode, infelizmente estou continuando com CLion, que está lenta mas seguramente assumindo o Visual Studio em geral.

Como outros que o mencionaram neste tópico, a codificação de vários monitores meio que requer destacáveis.

O Xcode permite várias janelas para um projeto. Ainda mais, as janelas são todas iguais, janelas totalmente funcionais, o que significa que você pode abrir uma segunda janela e fechar a janela do projeto original e ainda ter uma janela inteira do projeto.

Quão? Quando tento abrir o mesmo espaço de trabalho no Mac OSX, ele sempre focaliza apenas a janela já aberta.

Como o VSCode é escrito com "janelas flutuantes" do Electron, é meio difícil de fazer, mas permitir abrir o projeto duas vezes ajudaria muito, mas também não parece funcionar. Qualquer ajuda é apreciada.

Você pode fazer isso no Xcode removendo uma guia ou usando Arquivo-> Nova janela. Todas as janelas onde você pode navegar no seu projeto ou editar o código são iguais. Não existe janela "principal" no Xcode. Veja o gif anexado abaixo.

2 anos desde que foi solicitado. Alguma estimativa de quando o código do VS poderia ser capaz de fazer isso?

Este é um OSS . Você pode ajudar e contribuir com suas habilidades para o VSCode. Se você realmente deseja que o VSCode seja apresentado em várias janelas, por que não tentar fazer um fork e torná-lo possível sozinho?

Eu sei que é OSS. É por isso que não tinha expectativas sobre isso. Eu só perguntei se há estimativas de pessoas que cuidam desse repo. 'Sem estimativas' também é uma resposta. obrigado

Solicitação: feche este problema para comentários.
A equipe do VSCode está fazendo um trabalho incrível e continuamente entregando valor incrível para uma comunidade cada vez maior de desenvolvedores por meio de uma das melhores ferramentas de codificação do mundo.
Embora expresse tanto entusiasmo quanto qualquer pessoa aqui sobre a perspectiva de múltiplas janelas, fico feliz em esperar o quanto for necessário. Estou ficando um pouco cansado de todos os me too , you can duplicate your workspace as an alternative , but this tool has it , when will we get this ou mesmo alguns comentários bastante exigentes sobre esse assunto. Espero ansiosamente com cada comentário sobre este assunto para ouvir uma atualização relevante apenas para ver mais dos comentários mencionados acima. Encontrar um comentário relevante de um membro da equipe é difícil devido aos 363 comentários acima.

Tenho certeza de que esse problema está no radar da equipe (é o recurso solicitado número um).
@bpasero deu seu feedback mais recente neste comentário acima: https://github.com/Microsoft/vscode/issues/10121#issuecomment -345770248
Isso requer um pouco de rearquitetura interna do vscode, então vamos ser pacientes (ou contribuir).
Essa atualização de status é suficiente para mim. Eles entrarão em contato conosco quando houver outra atualização.
Por favor, 👍 o problema para mostrar seu apoio.