Vscode: Allow for floating windows

Just adding my support to this. Quite often with the full Visual Studio I'd drag out a tab to my other monitor so that I could view two code files at once. The split pane functionality is nice but not the same.

I see editor tabs as more important than the others. Really hard to utilize two monitors when you can't breakout a tab. This is important when referencing code, but also for things like Markdown Preview.

How is it supposed to work...? I can't get it to work (on 1.11.0-Insider). When dragging a tab outside of the window, it either displays a 🛇 and doesn't let me drop, or, when dropped on top of a Windows Explorer window, it copies the file...

@CherryDT This issue is still open and marked as Backlog. Do you have a reference that says it is supposed to be implemented in 1.11?

@vossad01 You are right I was confused for a sec, because I came from the closed issue #10147 where it said "Already addressed by #10121" and I took "addressed" as "solved". My mistake.

I'd say that undocking tabs (editors more specifically) is a _must have_ rather than _eventually_ type of task. Would love to have it implemented.

@bpasero @aeschli is this a feature that you'd like to get and review as a pull request? It seems to be a bigger task, thus it make sense to ask before going with implementation.

@mlewand this is no area where we expect a PR due to technical limitations. If you have an idea though, let us know.

@bpasero by technical limitation do you say that it's a Electron limitation? Or is it more about VSCode one project <-> one window design?

@mlewand depends, if I could open a lightweight window that shares the same JavaScript context and build some UI in it, that would certainly help. Otherwise we would end up opening a heavy browser window with own context that contains only the UI pieces we want to show, which seems like the wrong direction.

Want to chime in "me-to."

Specifically editor tabs. It is unfortunate that the issue author has the priorities so ass-backwards, but I can't believe nobody at Microsoft has seen this ticket at some point over the past year, recognized the immense value in being able to drag an editor tab from one window to another (your Visual Studio crowd has been doing this for decades) and made this happen by now.

This is a serious deficiency with VSCode as an editor.

I used Visual Studio as my primary editor for about 9 years, and then switched to VS Code after moving to a front-end-only project team. There's a lot to to love about VS Code, but the one significant missing feature for me is the lack of floating editor-tab-only windows (like I've gotten used to having in Visual Studio).

FWIW, I use 4 monitors side-by-side. It feels insane to be stuck on just 1 monitor for code editing, especially when I'm working on several files simultaneously.

I will have to agree with the comments above. The lack of this feature is a huge issue for those with multiple monitors (basically everyone who works with code). Obviously you can work around it by opening specific files in a separate (ctrl + shift + N) Visual Studio Code instance, but it's definitely something that should be addressed as soon as possible.

I want to be able to open files into a new window (for example to put on a different monitor or a different virtual workspace).
If I can't open directly into a new window then I need to be able to tear off a tab into a new window or to be able to drag a tab to a separate VSCode window (as created with File→New Window)

Im using a WYSIWYG viewer plugin for editing AsciiDocs. Separating windows to different monitors is a basic requirement in this case. Hopefully this feature gets prioritized soon

It would be really nice if we could tear of tabs to show the file/tab it in a separate window 😪

I'm trying to move off JetBeans and this isn't an optional or nice-to-have feature. It's fundamental to multi-monitor coding. Not having it is a deal breaker.

+

Looking for this feature. Thank you :)

It's not the cleanest way of supporting multiple monitors/windows, however you can do the following:

• File > New Window

• Now drag a tab in your already existing Visual Studio Code window into the new window you just opened.

I agree that it would be really nice to just be able to drag an existing tab to a second monitor but this is at least a pretty painless workaround until they support dragging tabs to another monitor.

Adding my request for this feature as well. Nice to see others wanting the same.

I love this IDE, otherwise. 😄

All the best.

Highly needed functionality.
Thanks

+1

(BTW.: The Backlog-Link (https://github.com/Microsoft/vscode/milestone/8) here in the right panel does not work?)

Any plans when this will be added to a release-circle? Thanks!

Not sure if anyone has seen this project for electron, but I'm just going to leave this here. Maybe MS could help out, in their copious amounts of time :). I haven't seen commits in awhile, not sure if he hit a snag or just got busy.

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

I've got to admit that I am shocked that an editor as established as VSCode doesn't allow me to drag a tab to a second monitor.

Adding my +1 to this.

Would love to have this feature as well. +1

@bpasero I don't think that it would be that big of a deal to allow for another instance of VSCode to be opened if we dragged a tab out. At least it would be a start.

I'm thinking on changing from Sublime Text to VSC and this limitation is the only thing which keeps me using both of them, I'll certainly be more inclined to VSC once you guys add this!

+1
even if I only need the Explorer and debug

tabs
Explorer / search / debug / git / extensions

So many requests for this, and they are consistently coming in too. I'm glad I'm not alone. Realistically this is my only problem with VS code at the moment.

+1

I’ll chime in along with the comment above — truly this is my only problem/feature wish for VSCode. Otherwise it is an absolute pleasure to work with, and far superior to Sublime and others (in my opinion).

@RoyTinker same here. This is the last thing stopping me from fully switching to VSCode.

Concurring with all above- this is the only fly in the ointment for me after switching from Sublime.

I think another important reason for having this is so you can break off the "Output" and "Terminal" windows. If you're going to run the debugging inside VS Code, you probably want the Output window to be on one monitor and the code on another rather than cramming it all onto one monitor.

@laserbeak I think the complications arise from having to handle window management across several operating systems. There might not be a clean or clear way of doing it across all platforms.

I am struggling to debug a large project despite working on three displays -- I can only have the debug console and the code that I'm stepping through on the one screen. I can't even have them side-by-side on the same screen as the debug console takes the full bottom of the window separate to the code editor.

I do hope this feature can be given higher priority, especially given it has been open for over a year now.

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

Op 5 okt. 2017 2:38 a.m. schreef Luc Shelton notifications@github.com:

@laserbeakhttps://github.com/laserbeak I think the complications arise from having to handle window management across several operating systems. There might not be a clean or clear way of doing it across all platforms.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/vscode/issues/10121#issuecomment-334327742, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD90FFy4E1Ra3EKfLfwh026vvezYp9FJks5spCT2gaJpZM4JckZO.

Apparently guys at JetBrains know the best way to do it.
In every IntelliJ product, every view has a cog icon which has following options:

• Docked Mode
• Floating Mode
• Windowed Mode

Without this feature, developers get in the following cycle which takes at least 20% of developer's time!

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

I call this as Focusing Users' Creativity Killer cycle.

It is a pity that this seemingly has no high priority. Its really a showstopper for this otherwise great editor.

This was the last thing they told me about it @Hypernut

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

Odd that they would ignore the seemingly high demand for this feature.

@Hypernut I thought the same. To me it seems as though it should be a base feature of any modern IDE.

@LoveDuckie @Hypernut You can just about work around it by dragging a file from the explorer into a new window; but that really isn't an acceptable solution. They seem to be dodging the question about it being a limitation of electron and whether or not they are actually ever going to be able to do it sadly.

or maybe they just don't want to make too strong competition for Visual Studio ;-}

@benm-eras I'm aware of that but it seems as though there is support for that functionality already. It's simple a case of MS wanting to integrate it with VS Code.

+1. Required, not a nice-to-have for people with multiple monitors (tabs). Over 14 months and still dead silence? But hey, macOS Touch Bar support is there. 👎 Sad...

I agree with the "let's not make this compete with Visual Studio" comment. Well if I could work on my SPA efficiently and my web api backend in Visual Studio I wouldn't need VS Code either.

+1 need this feature

This feature is on the backlog, but it's ranked #​14 when sorting feature requests by number of upvotes:
https://github.com/Microsoft/vscode/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Areactions-%2B1-desc%20label%3Afeature-request

It needs 104 more votes to make it into the top 10.

THis issue would likely receive a lot more upvotes if the original ask were phrased better.

Title: VSCode Add Multi-Monitor / Multi Workspace Support.

Description:

Support Dragging VSCode Document Tabs, Tool and Extension Windows out of an IDE instance across multiple workspaces/monitors. Windows broken out in this fashion should operate within the same context as they typically do when attached to the IDE.

Current Behavior:

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

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

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

So why don't you just use Visual Studio?

@s952163
I use, but am limited to windows only ;-) while vscode I use on linux, macos, windows

@s952163 Many potential reasons:

• Using Linux or Mac OS X
• Developing against non-MS runtimes/platforms

I'm now a front-end dev on macOS and I wouldn't switch back to Windows and Visual Studio just for multi-window support. I'm currently looking into similar editors to see if any support floating windows: Brackets, Atom, Sublime, JetBrains...

Also want to throw in my support for this feature. At this point, it is the missing feature that is keeping me from using VS Code full time.

Typical dev commenting on this issue: "All other IDEs with bad UI designed in 90s forced me to buy multiple screens to be productive at all, so this new IDE shouldn't try to fix problem differently but replicate same bad UI and support my multiple screens".

I really hope this won't be implemented, focusing on a single window, streamlined, editing focused UX is a strong advantage of VSCode, not disadvantage.

@Krzysztof-Cieslak By the same token, Chrome shouldn't support popping a tab out into a new window. I couldn't imagine anyone arguing that. Multiple monitors are still _really_ helpful because they increase available screen real estate. Apps that support multiple monitors aren't at all clunky for doing so.

See @D1no's illustration above (click to scroll up). This is what I'd like -- just like popping out a Chrome tab. [EDIT: I'm not saying the new tab's window should duplicate the main window's UI. I think all it would need is a tab bar (for multiple code editor tabs) and the tab content.]

@Krzysztof-Cieslak you’re joking right? Believe it or not, there exists a large community of developers who value productivity over locality in a coffee shop, or the top of a tree, or whatever is currently in vogue.

Multi monitor workspaces are not some relic of the 90s. They are an incredible productivity tool that should not be sacrificed at the alter of mobility or hipster lifestyles.

@Krzysztof-Cieslak this is probably the dummest statement I have read in while. FYI: half of the 21st century VR movement is inspired by screen estate limitations for an infinite number of "windows/interfaces" 🙄

So getting back to topic: What can we do?

Wonder how VR is related to heavy text editing and reading activity like programming.... But let's stick to giving unrelated examples, accusing others of being hipsters coding on top of trees or whatever makes you guys feel better. That's easy part.

@Krzysztof-Cieslak, you say old IDE's had a design problem that forced us to have multiple monitors, OK, I'll take that, I don't know enough on that topic to say that's right or wrong (and I was born in 1991 so I didn't really have a chance), but it doesn't matter how you see it, it's more productive to see 2 or more files at the same time than clicking tabs or using some key combinations to change the view, this is specially true when these files have a strong dependency. I don't think I need to explain need this, you should know what I'm talking about. Sorry for the bad English, btw.

Kiddo, do you live behind the moon or are you just trolling?
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
(...)

Maximising exposure to information is what drives everything from multi-threading to pixel density and yes, even multi-screen & cross device applications. IDEs included.

So it's appropriate to _ask_ for an enriched editor to join that established workflow. If you have some contributions to share beside trolling, we are all happy to hear you out. But at this point, the more than one year activity of this issue speaks for itself.

We are beyond _if_, rather at _when_ and _how_ this enhancement hits vscode.

This issue is getting pretty heated, I think those of us that support it should raise awareness for it (tweet, recommend, discuss), so it can make it to the top 10 list of requests. Trolling / name calling / arguing gets us nowhere.

And thanks @D1no, now I want an Oculus Rift so I can have 17 virtual monitors :).

@Krzysztof-Cieslak
This is a feature, not design choice. If this feature gets implemented, you don't have to have multiple monitors to use VS Code. In fact, you don't have to do anything, you just use VSCode as is. I still don't get it why you are against it.
Anyway, I have 2 monitors and I still consider to buy the third one. Why? It is really time consuming to click and resize a window to see the content. Virtual machine, the code you write, the HTML page you design, the browser window you check, the debug output, the terminal and so on. I need to see all of them at once.

BTW using MacOS or Linux is not the only reason not to use VS, If you ever used VS, then you know how bloated it is. The last time I downloaded it was a couple of months ago and it's size was about 7 or 8 GB back then. Yet you don't have an offline uninstaller for an 8GB installer! There are workarounds to make an offline installer out of an online installer on the net!

@tavuntu

it's more productive to see 2 or more files at the same time

You can currently see 3 files, one vertical panel (debugger, git, search, explorer) and horizontal panel at the same time

@D1no,
Well done, linking some unrelated to IDEs (or text editing in general) links to the VR hype articles in such respectable computer science / software engineering medias as Guardian and Bloomberg totally shows your point of view. However, I still don't see in this whole thread one link to the research, study, paper showing productivity gain of using multiple screens for text editing. I don't see any reasonable discussion around possible implications of the different ways of implementing such feature. I bet I won't see any proof of concept implementations. All I can see is bunch of folks happy to +1 some random feature with huge design implications (and bunch of hate for anyone having different opinion)

Anyway, I'm out. Yeah, calling me kiddo living behind the moon won you this discussion! You also demystified me as a random internet troll, well played, sir!

@Krzysztof-Cieslak,
No no don't you run away when you are proven wrong!
Please first point to a study showing that not having multiple monitor support improves productivity or rather is a better choice. All you gave people was your claim, and they gave theirs.

"You can currently see 3 files, one vertical panel (debugger, git, search, explorer) and horizontal panel at the same time", nice try, but you know what I mean, I mean a maximized window with a CSS file in one monitor and a maximized window with HTML in another one... that's far better than having a lot of uncomfortably panels in the same monitor. I'd say that's a personal preference, but hey, this thing has 237 upvotes vs 7 downvotes, so yeah.

@tavuntu @Krzysztof-Cieslak I keep one of my 22" monitors vertically oriented. It's sometimes really nice to edit a JS widget file there, with the corresponding HTML and CSS files in a maximized split pane on an adjacent monitor.

Layout:

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

Ideally, the top-middle and right-hand monitors would be running a single instance of VS Code, with the JS file popped out as a separate, maximized window.

Please don't make this mistake...

You can't read several file at one and keep focus. Split code into one screen is already enough and this kind of decision imply a lot of design implication for the User experience.

There is already much to do on VSCode, to improve the current user experience without adding more complexity. Because a new windows, probably mean VSCode provider need to support it because the context isn't as simple with one window etc.

Possible better focus IMO, fixing word pattern selection and renaming selection, adding drag & drop support into panels, etc...

Also, most of the OS don't support a proper tiling system for you windows so yeah have fun managing each ones...

@MangelMaxime You do realize that new windows would be optional?

@jez9999 Yes I understand that, as I understand also that it's not a simple feature to add and maintain in the future. :) Just giving my opinion after seems like most of the people already have they given with some +1 :)

@MangelMaxime
"You can't read several file at one and keep focus"
If you can click-resize-read several files, then you can surely read several files without, clicking and resizing first.
Besides, it's not always the code you keep watching. Sometimes you watch the output or enter some commands in terminal. This is why I will stick to IntelliJ until this feature comes up to VS code.

@ramazanpolat
That's a good point indeed but for console or command, we already have the console application for example which should do a better job in general IMO.

I give up.
It's a bad idea to have multiple monitor support.
It's expensive, it will make application maintenance harder, it will prevent users focusing code. Additionally one monitor is definitely cheaper than two. You don't have to move your eyes left and right and up and down, you just directly stare at the middle of the screen and use mouse to move relevant content to middle of the screen. This way you may also find smaller size monitors more appealing, because of their compact size and cheaper price.

EDIT: Apparently somebody didn't get the sarcasm.

Since it came out, Code hasn't had multi-monitor support, and I assumed that choice was made intentionally. That said, I don't know if I'd find it useful. I use Code in one monitor and my browsers and emulators in the other screen. -1.

Why vote it down just because you wouldn't use it?

I downvoted to provide feedback on a level of priority I think the feature should be given in the backlog. This is not a feature I'd prioritize, and in fact, I think it goes against the design and intent (see "Since it came out, code hasn't had multiple monitor support, and I assumed that choice was made intentionally.") Thanks for the question!

It's expensive, it will make application maintenance harder, it will prevent users focusing code.
Additionally one monitor is definitely cheaper than two.

Yeah! If I don't like bread, no one should eat it! Just clutters up the stores, makes them harder to maintain. Prevents people from focusing on other, more important food.
Additionally you don't need butter anymore, which makes life definitively cheaper.
What an absurd discussion...

tell me if I am correct. If the feature is built in now. versus if the feature is built in later, when code would have become more complex due to "required features". Would it not be better to build it in now, when the overall system is relatively simpler ?

Got some great news for anyone else who (like me) didn't know: looks like this feature is already (mostly) implemented. Tearing off tabs into separate windows is __already possible__ 🎉 , with some caveats/workarounds required.

Prep steps:

1. Open your project folder or workspace (if not open already)
2. File > New window
3. Close welcome screen in the new window
4. (if the sidebar is visible) With the new window selected, click View > Toggle Side Bar
5. (if the activity bar is visible) With the new window selected, click View > Hide Activity Bar
6. Maximize the new window on monitor #​2

Now drag & drop an editor tab from your project window to the new window.
==> Boom: Workspace is now multi-monitor.
(you'll also have to close the tab you dragged from)

So a minimum viable implementation of this feature wouldn't be intractable if one can automate steps 2-5 (+closing original tab) and trigger the automation when someone drags/drops a tab onto a non-vscode-owned part of the screen.

Hey, yes that is a known workaround (like opening the project multiple times) and is stated above somewhere in the comments. However, it’s tedious and - sometimes - can lead to problems having multiple instances of the project open at the same time (those instances do not communicate with each other directly).

@RoyTinker "I keep one of my 22" monitors vertically oriented. ", that IS a valid argument!

You can't debug in the other editor either. The single most useful reason to have multiple windows is to debug across server (node) and client (Angular). Having it all crammed in a single space is really irritating. I want to have my Angular files in one window, my node files in another, and the Terminal in another full screen so I can see the output of what's going on. All possible in something like Web Storm, but not VS Code. It really aids productivity and for that single reason I still use WS instead of VSC.

Good news - this has moved up to #​13 in feature requests sorted by upvotes. We only need 88 more votes to make it to the top 10.

one more vote from me!

Voted up, this is the only thing that's missing moving from Sublime

One more vote, a much needed feature.

And one more vote!

one more vote!

Would love to have this feature. Upvote.

One more vote.
Do commentaries as votes help? Or just thumbs up main post enough? Otherwise, this thread will become kinda flooded.

Thumbs up on the main post.

Thumbs up on the main post is what we need... let’s not add to this thread unless we have something to add to the discussion. Thanks for the votes!! 😃

+1 Vote from me

I'm starting to need this more as the projects get bigger. It would a great feature, if the performance doesn't go down because of it.

It would be ideal to have this for some text editing as well. For example, I write research papers in VS-Code. I also write lots of Markdown-based documentation in VS Code. It would be very useful if I write the code/text in one screen, and get the preview (still within VSCode) in an external monitor (or, a second screen). I totally need and support this feature!

+1 vote from me! Vscode is awesome and it will be more awesome with this fonctionality!

@amadare42

Thumbs up are always preferred over the popular method of +1. Wish GitHub would make it more obvious with a +1 button at every post than the +[Emoji].

Always loved reddit style too

Hooray, we made it to the top 10 (this is actually # 9 now). Only 68 more votes and this will be in the top 5 feature requests. (To vote, add a "thumbs up" reaction to the top comment.)

A thumbup for this. ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP ASAP

Vote from me

+1 for me. First thing i noticed missing when switching.

My current VS Community Edition setup:
Left screen:

• Solution explorer
• Breakpoints
• Errors
• Properties
• Source control

Right screen:

• Code editor

Closely thing to this right now is "zen mode".. but it's not nearly the same experience.

So please... "float all the things!" 🙏

But I also think, maybe, it not a easy work for vscode developers.
This feature would perhaps require extension developers implement some interface if they want their extension windows to float. The worst case would be that all the old extensions should be rewrite to support floating.

But anyway, if the feature is well done that doesn't require extension developers to care anything more,,,,,,that would be gleit.

Still waiting for this after I switched to Code from Visual Studio :( For now, my only solution is to minimize the application and stretch it manually to fit my monitors.

@nguyenlamlll I suggest you read through https://github.com/Microsoft/vscode/issues/2686#issuecomment-344808761

This is awsome app, and I recently move from Webstorm to vscode.
I really want this feature!!

@bpasero "removed from backlog" -- any comment? I'd be sad to learn the team's response is a "no".

@RoyTinker no it has no specific meaning, I just prefer to have issues that I care about assigned to no milestone unless work is starting. Please see our roadmap for what we plan to work on in the next 6-12 months: https://github.com/Microsoft/vscode/wiki/Roadmap

Please see our roadmap for what we plan to work on in the next 6-12 months

I dont see it there, so it seems you guys continue to ignore the high demand for this feature.
Why?

Yeah, I'd say this feature falls firmly in the "Happy coding" category. 400+ upvotes. Should be on the roadmap.

I fully agree that it would be a great feature, but really guys give the nice folks from vscode some rest. Im pretty sure there are good reasons why its not yet started. We should remind ourselves that this is a free software ;)

Thanks @bpasero good to know.

@zewa666 yes it's free and awesome, I'm thankful about that. The problem is, these guys are not giving an answer and even if they have a good reason not to implement this, their silence tell us they just don't care about this request. We're developers, a lot of us would understand a technical reason. Sometimes silence is worse than a negative answer.

Yes it is free. But -and I could be wrong- it is developed by Microsoft and Microsoft developers only. If thats correct, I am pretty sure that they get payed for working on this. So this is at least slightly different from any community project people do for fun and in their spare time. Because in any other open source project like this, we already would have an answer if and when this get implemented and if not, why.
That is all I am asking for.
The silence is odd for an open source project, but unfortunately typical for a company like Microsoft.

There is a technical reason why this feature is not making a lot of progress: We are using the Electron framework as cross platform UI framework which is based on Chrome underneath. Chrome has a model where each window get's its own isolated context, e.g. each window has its own process and its own JavaScript context. I would not be possible to share the same context between multiple windows.

Now imagine you you have an editor where you type in and you want to drag it out to produce a new window, you would expect that operation to be very fast and lightweight. But instead, it would require us to create a whole new instance of VS Code with separate extension host even in order to have the editor in a standalone window (this would be comparable to doing File > New Window and opening that file in the window).

I only see this feature possible when we find a way to create windows that share the same memory to the "main" window so that this operation is lightweight. Imho it would not work to have each of the floating windows be fully isolated as they are now.

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

@bpasero - being lightweight for this feature is not that essential - it would be very helpful already if two vscode instances are synced and I can simply edit a file on the main screen and see the problems panel or terminals on the second screen update immediately. I typically would open e.g. a panel on a second screen and have this screen setup just sitting open for hours.

Ideally I would like to have a split screen with 1-4 windows on the second screen open side by side to be able to glance over the problems panel and open terminals (e.g. showing unit tests and client and server output) - so I can use the first screen fullscreen without having to open and close the side panel all the time.

I find myself quite often in the situation where you open and close the terminal all the time with cmd+j or have to close all split tabs because you want to diff changes side by side although I have a second screen where these could simply stay open.

Thanks for the reply.
I do not care if it's lightweight either. I just want to be able to move the terminal and debug console to where ever it bugs me the least.

@bpasero

uh, can we not keep the context?

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

I just know about it, since that is one of the main reasons why React v16 portals are so useful..
https://hackernoon.com/using-a-react-16-portal-to-do-something-cool-2a2d627b0202

Thanks for the suggestions and discussion. There is certainly ways of communicating between windows, even if they live in separate processes. There is still the challenge that the one window is not really aware of the other window. Libraries like electron-window-manager seem to make this a little bit easier, but after all there is a ton of work involved, to outline some:

• each piece (editor, panel, view) of the workbench needs to be runnable in a separate browser window, which means that each piece needs to be fully self-contained
• the master window needs to basically multi-plex its workbench layout to multiple windows (e.g. if you open the output panel it should focus the window where the output panel was opened in)
• probably the biggest challenge: all our services that currently live within one window (and that includes all extensions and the extension host) need to move out of the window into a shared backend that each window can talk to. to give an example: you start a debug session in one window but the other window shows the debug console, of course both windows need to talk to the same debug backend

I would not say that this is technically impossible but what I can say is that this feature request is both very challenging because of the UI impact and because of the fundamental change it requires to each aspect of what we have today. I hope that makes sense.

I hope you'll aim for releasing this feature step by step and you won't sit on plans

+1 would love this

@bpasero Sorry for n00b question: could nativeWindowOpen help to solve the problem?

+1 from me and

@Blackbaud-DustinLunsford thanks for a simple workaround

@n9 I think the communication between both windows is solvable but the other issues remain that I stated, specifically the fact that each window has its own DOM and that all our services need to talk to the same backend from every window

This is a great feature as I need!

@bpasero thanks for the answer!

A definitive must have on split screen 1 portrait, 1 landscape.

One of the reason i still use Eclipse over VS code. Window code in portrait - Tools on landscape

+1

I'd love to see this feature coming anytime soon 🙂

Good job; I love the editor

Jesús

+1...! 😃

@bpasero I suspect there's a possible 80/20 (% benefit/effort) intermediate target that wouldn't involve several of the complexities you mentioned.

What if the following features could be added:

• allow multiple windows to point to the same project directory
• add internal API option to open an "editor only" window (i.e. no status bar, no activity bar, only editor tabs)
• allow extensions to register interest/disinterest in "editor-only" windows
• add (internal) API option to open a file in an editor tab with a specified (unsaved) buffer on a newly created window
• when an editor tab is dragged outside the app:
  
  
  
  • create a new window without activity & status bar, with the file and its current (unsaved) buffer (if applicable)
  
  
  • close the editor tab in the original window
  
  
• add hooks for all windows on the same project directory to signal and listen+react on a few UI events:
  
  
  
  • editor tab selected (activity bar explorer updates to point to the file)
  
  
  • editor tab closed (maybe just set explorer to "no tab selected", selecting last tab might be hard to coordinate)
  
  

@RoyTinker I think it can be even simpler.

As a first solution it does not need to be 100% "detachable" windows. The actual APP could just be a "container" for multiple canvas that can be rearranged inside.
With a little luck, It could be a very simple change in the VSCode main window.

@Rouche VSCode is implemented in Electron, which means each window is a separate chromium process, accompanied by some back-end processes as well. The "app" is an OS-specific container that instantiates/orchestrates these processes. Changing that model would be rather fundamental (large) at this point.

I'm a bit disappointed that it was never a design consideration from the
very beginning.

On Fri, Dec 1, 2017 at 9:39 PM, Roy Tinker notifications@github.com wrote:

@Rouche https://github.com/rouche VSCode is implemented in Electron,
which means each window is a separate chromium process, accompanied by some
back-end processes as well. The "app" is an OS-specific container that
instantiates/orchestrates these processes. Changing that model would be
rather fundamental (large) at this point.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/10121#issuecomment-348621220,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqQmoLrUY4l5H5xwroWCytBbgT2LIL_ks5s8HIqgaJpZM4JckZO
.

--

Games Programmer

www.lucshelton.com

+1

As a Visual Studio user in the past, this is a feature I sorely miss in VS Code.

+1

@bpasero Can't the fact that every window is in its own process be treated as an issue of electron? Isn't it an unnecessary overhead to have multiprocessing for each window for such framework as electron?

Well I think then the electron team can just say that the problem is in chrome. Since, chrome creates a new process for every tab. Only solution would be to move electron to work on some other framework entirely.

@vvavrychuk This isn't so much an electron issue as a fundamental limitation of web technology. (electron = chromium + APIs to access underlying OS features)

What if you could init vscode in some mode, "extension mode", for example,
and pass through some parameters. eg. vscode --extended-window --socket-id
((socket-guid)) --root-window ((root-window-guid))

This way you could create a socket or bus of communication between windows
or independent apps.

Each extended window that is created is assigned a root window id, and the
created a UNIX socket id to communicate with.

I think there is a possibility to implement something like this.

If electron has a way to open, read, and write sockets, this approach might
be successful.

@RoyTinker chrome has "single-process" option but electron does not support it https://github.com/electron/electron/issues/11398. They say that we can not have multiple node.js instances in one process. That is for sure. But I don't understand why we need multiple node.js instances for multiple windows? Can't we have Electron=multiple windows+single node.js in one process?

@Jesus-Gonzalez Looks like a variation on what @bpasero said it would take to implement this, although your suggestion sounds easier (to me at least) than item (3) from his list, because the "parent" electron process tree would house the back-end functionality, such as the debugger.

However, items (1) and (2) from @bpasero's list of challenges would remain. Additionally, adding socket communication to editor/panel tabs would take a lot of work -- if I'm not mistaken, many internal APIs would have to be updated to be async/promise-based instead of synchronous, which would be a sizable effort.

@vvavrychuk by "single-process" I'm referring to the web context (sans workers) only. By "electron process" I meant more of a process tree, which would include a single web context accompanied by any number of Node.js processes and some background chromium processes. Otherwise I'm probably not the best person to ask.

+1

Any progress on this? Would love to be able to use VScode on both monitors and split files between them.

+1

Thought everyone would be glad to know -- this feature request just made it to #​4 by upvotes. Only 150 more and it'll be in the top 3!

+1
I strongly support the request of this feature.

+1 Will be very useful for larger or multiple monitors.

+1
I am getting by using a larger 4k monitor in my home office but at my work office desk where I use 4 smaller monitors this is a slowdown. This is the last piece we are missing as others have said from a full move from other editors.

@RoyTinker where do we upvote it?

@pantonis Please click the "thumbs up" icon at the bottom of the first comment.

Adding a comment that only says "+1" doesn't help and only clutters up the discussion area.

+1. Here we work with back-end and front-end at the same time. In main monitor, back-end; in the 2nd, the front-end. It is the same project and the same workspace. It should allow us to open multiple windows with the same workspace/project.

Will this be implemented anytime soon? I think tabs need to be free to move anywhere, just like Google Chrome tabs do. Move between open windows or when dragged to desktop will open a new window for that tab. This is very important.

+1

For God sake please make this happen !

Every time I update my lovely vscode I try to detach a tab and it does not work! come on guys this was already requested from day one.

No roadmap no milestone no promises, whats happening !

800 upvotes now! This is 3rd by thumbs up and is 2nd in number of comments

Would love to have this feature as well.

+1 Agreed, would love to be able to drag out my tabs into their own windows. Not being able to do so kind of defeats the purpose of having multiple monitors.

Only  42   33   22   17   8   2  0 more votes and this issue will be #​1.

+1

@tavuntu The problem with commenting simply with +1 makes useless clutter and spams people who watches this issue with a useless notification.

Want to see this feature being implemented? Add a 👍 reaction to the original post and that'll be enough, no need to comment out the dreaded +1 comment.

Even my comment is meta because it does the same (more clutter) and shouldn't be required. This was already talked about in this very thread.

Nonetheless, coming from Sublime Text, this feature was something I really enjoyed and would want to see in VSCode one day.

@V-ed

That means we're realizing a flaw to GitHub's reaction system. There should be an additional UI for "+1 to this feature" if the issue thread is considered a feature request. But, hopefully someone with more influence can take that up to GitHub.

@ketozhang

Indeed, and I remember seeing someone talk about an idea for GitHub to implement an automatic "+1 to top-post 👍 convertion" system, and that would be great for those still in the mindset of +1'ing to add their vote. Your idea of a proper UI for +1'ing a feature request / "I have this problem!" for issues would be great! Thing is...

This discussion is outside the scope of this thread and could be talked about here (hey, actually, it's already everything we said so far! _however, hopes are getting lower and lower as time moves on..._ _or is it?_) - hopefully something will happen in regards to this problem. By talking about it here, we are only making it worse - see you on the other side of the force and have a good day!

I use vscode to work on a large c# solution, specifically, 19644 c# files. Visual Studio 2017 dies with out of memory exception. Floating tabs/editors is a must especially when working with dual monitor setup.

This feature request is now # 1 by upvotes. We made it! 🥇

I feel that Xcode does this really well if you're looking for inspiration.

This should be done at the beginning, when you start writing this editor. Movable tabs/panels outside the main window (with the possibility of sticking to the main window) is the core function of every real editor, especially with the current large 4k screens and multi-monitor sets (in case of professional programmers).

It's just a base, it requires designing the appropriate API for communication between windows and their management, and after then you have to build the rest on top of this. You are currently in a difficult situation to somehow solve it, without corruption everything that has been created so far, but the earlier you take this challenge the better for everyone, after spends of more time and the writing of more code may be too late for such change.

In real world we need see much more than only left/right/bottom panel, this solution https://github.com/Microsoft/vscode/issues/10121#issuecomment-335013296 is great.

Condescending tone does not fix bugs. Please use 👍to vote.

This feature has been requested for years now...Please implement it.

For those who just want to open files in new windows and were lead to this page by Google, use the keyboard shortcut for "Open Active Files in New Window";
Ctrl + K, O

It's such a basic feature, I first thought the missing of the floating window was a bug :')

Please VS Code Team, we need this !

Full Multi screen support !!

This thread was open 1 Year 6 Months and 4 Days ago ....

Edit: By bad, bpasero answered the thread a year ago, let's just hope the team will take this issue as the reference issue for the Explore UX for flexible workbench layout plan item on February 2018 iteration plan !

@Aetherall and others, please read further up the thread. Benjamin Pasero has responded several times. He’s a core VSCode team member.

Also please remember this is an open-source project. Some comments seem to assume MS owes us something here... not true.

Perhaps VSCode is just so awesome people sometimes assume it’s commercial :-)

@patrys this is the top voted issue and I'm sure you know that, but yes, you're right, this won't magically be fixed, it needs time and effort, and people (as @Aetherall said) seems to think this is commercial software (it started as a nice request but now it seems like a strong exigency)

Tearing the tab out is the behavior I want (the same way it works in Chrome browser). However, I would settle for any ability to quickly move/open something in a new window, such as a right-click menu option. Right now I have to open a new VSCode and manually reopen the file. In neither case do I actually want a floating window such as in Visual Studio. I want it to spawn a new copy of VSCode. Floating windows get lost, I just want a new window...

Nice

@inarius see @christopher-howard's comment above.

Thanks @RoyTinker. I can't find a menu option for that at all and I am guaranteed to forget the shortcut, but it does work! I think it would be a good option to expose on the right-click menu for the active tab and/or items in the Open Editors document explorer.

I also just found issue #8171 seems to be exactly what I want. Perhaps people voting on this should go check that one out!

TIL, dragging tabs onto another vscode window opens the file on that window too. Unfortunately it does not close the older tab which is expected for the floating window idea.

This behavior is baffling to me. This is similar to opening Markdown preview tabs which also duplicates itself at times.

Hey @ketozhang,

Unfortunately it does not close the older tab which is expected for the floating window idea. This behavior is baffling to me.

Oddly I've actually been enjoying this behaviour - useful for referencing from the same document just like when creating a new tile. I'm confident this is the design decision behind it but I'd be interesting to know otherwise.

Regards

Chiming with a motion to undock, especially the watch window

+1
I've been recently looking into ultra wide monitors and with the new screen real estate I'd want to utilize it for maximum productivity. Visual Studio 2017 handles this quite well for dragging out tabs to become new windows so hopefully we see something like that in the near future.

+1. It would be really great to have ability to drag tabs to different monitors making them new window.

++
Really there many people working with two monitors. So i don't like see output info on my code tad.
I must see only code. So, i will be miracle if user can move terminal/output/tab to another monitor, or do this window floating. And later select needed window by Cmd+~ for example or seen results on another screen.

@bpasero why not a complete new instance with their whole context of the browser, I end up doing it anyway when I need to open a second instance of app to fill my second monitor. IMO, this is not what happens when you open two browsers and drag and drop tabs between them? can't vscode do the same with code tabs this way? It would be fantastic to have this ability. I have 2 monitors, an old PC s754 8GiB DDR2 and this lightweight engineering wouldnt benefit much my setup, neither newer more powerful machines.

This window dock-able feature is already is VSCode. But, dont know recently why its not working...

+1. Dragging a tab outside the window should split into a new window like virtually every single other tabbed application out there.

Tabs are not my priority. But detachable debug would be really good.

This issue is now open for almost 1 and a half year. Please give some responses to the current state of that feature.

Dragging tabs outside the VS Code window currently copies the file (or a shortcut to it?) to the drag-target. This is quite unintuitive when comparing to other IDEs.

Come to think of it, the absence of floating windows (like VS proper) is my only real problem with VS Code. It needs to be implemented.

@belst and others see this comment, given the current design it's quite difficult to implement this feature

@Jorilx do you know if there is a related issue on electron somewhere?

It would be really nice to see support for multiple screens or floating windows. For now I have to manually resize window to fit my two monitors (red line is edge of monitor) which is not comfortable.

For me at this moment that is the most needed functionality when it comes to UI/UX.

+1! <3

@kodipe Not ideal, but there is a workaround for your situation at the moment. Save your project as a "workspace," then open up a file, use the hotkey Ctrl+K O (as I see you're on Windows) which is to show active file in new window/instance. Now add the repo root folder into that new window/instance (because this is now effectively a new workspace)... Now you have two windows using the same workspace on two monitors. As I said, It's not ideal by any means, but it's what I've been using as my workaround using the workspaces feature.

This is a must to have UI feature. It cripples the experience and productivity of daily work.

Bump, this is the only thing holding me back from moving to VS Code completely.

I understand the fact that there are technical complexities to implement this feature.
However the fact that there isn't any indication of activity on this request is just ridiculous at this point. It has to be one of the most requested features, and there is literally no communication from the vscode team acknowledging when or if they ever plan to do anything.

This is a free product, and Microsoft owes us nothing. That doesn't mean that I'm not extremely irritated that this feature isn't even on the radar. There are multiple pages of github issues requesting this feature. VsCode is a great IDE, but the lack of this feature in 2018 when we all have multiple monitors is just embarrassing.

To everyone trying to excuse this due to technical limitations: Please remember that someone had the opportunity to evaluate a platform/language to build vscode on, and they decided on a framework that has a very obvious flaw. I'm honestly tired of trying to get some communication from the vscode team.

If this doesn't get added to the vscode roadmap soon, I think I'll find a new IDE.

@BentOnCoding I agree that the lack of this feature is incomprehensible, but as you said they chose a framework that is not completely suitable to building IDEs, so adding this feature would be a major effort and it looks like they are not willing to make it.

Honest question, isn't Atom implemented in Electron too, and don't they support detachable tabs properly? Their implementation isn't suitable to VScode's architecture, is that it?

@ruippeixotog I don't think atom supports detachable tabs. You can move tabs between windows but you cannot create a new window by dragging a tab out

@belst It still does allow multiple windows on the same workspace, which is an improvement on VS Code.
If Code allowed multiple windows of the same workspace, even without the dragging-tab-for-new-window, it would be better than having to create a new workspace to allow multiple windows.

This confusion between tab movement versus detachable windows is exactly why I do NOT support detachable tabs. Tabs movement should spawn a new process in a new window. I want it to work exactly like the Chrome browser.

The VScode team has responded to this topic to discuss the difficulty. Since there are multiple approaches to this that could be taken, and multiple open issues that have been combined into this one, I hope they will at least provide some guidance on what approach they prefer here so this feature request doesn't get bogged down by unproductive discussion.

This issue really only rose to prominence in the last 3 months or so. I imagine there's still internal discussion going on.

I too used to love to rip tabs and windows out from Visual Studio; I'm on a Mac now and using VSCode. Very disappointed to find this feature isn't supported. The experience has been close to Visual Studio and the extension Python Tools for Visual Studio, but still missing some of the nice to haves.

Gonna subscribe to this issue to get ping'd when this great feature is present.

I will just leave my two bits here as well. Following this thread for long time and still not having it late march 2018 (almost 2 years) is such a pitty. Crossing my fingers to have it available hopefully soon.

It's such a basic feature, I first thought the missing of the floating window was a bug :')

@Aetherall 👍 I thought the same thing! Then I came and found this thread... :-(

This is free software. You've paid nothing for it. If not having this feature truly prevents you from using VS Code then you are free to contribute a pull request that implements at least some of the required changes to get this working. Alternatively you can take your zero dollars and spend it elsewhere.

What you should not do is whine and try to guilt trip the great team behind VS Code into feeling bad.

If there was a better alternative you'd be using it instead of wasting your time in this thread so next time say "thanks" instead of "how is this not done yet".

@Nepoxx You could always open a new issue with a title something like "Technical discussion for floating in-process windows" and link to this issue.

@Nepoxx You are here just to give thumbs down opinions and comments from people. Start with the technical and worthy discussion then. We all know the limitations of the platform, we try to give relevance to the topic so Microsoft team gives importance to the issue. We all have different needs and you should not say others opinions are worthless. Why you follow this thread anyway.

@patrys "you are free to contribute a pull request that implements at least some of the required changes to get this working"

That would require the VSCode team to publicly discuss a plan for implementing this highly requested functionality. It's too huge of an issue for any one individual to create some massive PR implementing the _even most basic functionality_—after all, every file dealing with references to the window or process space would require updates if not being thrown out and rewritten. Do you honestly think the vscode team would merge something that changes their product at such a fundamental level when they're not directing it? I wouldn't. The community cannot contribute until such a plan is openly discussed.

_(Most)_ of the people in this thread are not complaining "I want this." or "Do it because I'm too lazy to do it myself." The community is concerned because this is such an important feature and there has been little to no response from core contributors beyond—essentially, "this is a difficult issue."

Imagine: You get in a taxi and tell the driver your destination. He then parks the car. You wait a minute, confused why you're not moving and ask, "can we get going?" No response. An hour you ask the same question, and he replies, "there are a lot of turns needed to get there," and will say no more. Would you not be... confused? frustrated? that is how we feel. But we're not about to just grab the wheel and drive ourselves, it's not our taxi.

Here is a suggestion for everyone requesting this, if undockable tabs has such immense value for you and your company. Why not set up a crowdfunding for it?

If you can afford 4 monitors just for the increased productivity benefit, I assume that you can also afford spending some money on the development of such feature.

SorryNotSorry

@bpasero maybe we should lock this issue for comments, because we're over here arguing about taxi drivers 🤣

Sorry if I'm wrong, but there some kind of support for multiple windows: https://www.npmjs.com/package/electron-window-manager

If VS code's UX functioned like atom's I would make the switch. As is, I keep installing VS code, loving almost everything and eventually uninstalling when I realize the UX still hasn't been updated. Will be watching this issue, please fix.

I would say most of people here misses the point: VS code is not an IDE it's an code editor. With some nice features added in (debug), brilliant support for multiple languages through plugins, cross platform etc, etc. One thing it is not, is IDE.

That's why it is my default for a small screen (i.e. laptop, as it manages real estate in brilliant way) and platforms other than Windows. On a proper workstation I use Visual Studio. That's that.

Proper IDE's are quite expensive tools. Look at JetBrains - they made a successful business of building these things ;)

@mdmnk No. It's an IDE.

notepad.exe is a text editor, notepad++ is a text editor, vscode prior to intergrated terminal, task runners, scm, and debug _was_ a text editor. _What features do other IDEs have that vscode doesn't?_ There are some things I'm sure, but not many.

It is certainly lightweight when you don't install 1000 plugins. I don't mind opening vscode to edit ~/.bash_profile because I don't have to wait for 4 minutes like I might with Visual Studio or WebStorm.

@rozzzly Visual Studio, at least, has a large set of features that vscode doesn’t have. Runtime profiling for .NET, SQL Server tools, a massive test management system, Azure tools (MS’s cloud), built-in task/PR/issue tracking — to recall a few off the top of my head. It’s a truly massive product. By that measure, VSCode is just an editor, despite built-in debugging/etc. — it doesn’t ship with everything you need to develop and ship software at a large scale... not even close.

@rozzzly -even the team building it refers to it as editor rather than IDE so clearly there is no drive to make it fully blow IDE.

These things cost money.

Look at what @RoyTinker mentioned. Add code coverage, team services, merge conflict tooling, full customization of the layout, build in package manager, cloud explorer, sql explorer, server explorer, application insights, class view, object browser, etc etc etc.

VS Code is quite amazing tool. Yet it is free, which from the set off means it will have limitations.
You don't like it, go and pay JetBrains or Microsoft for something that has all the features you require.

I hope we can quit discussing what obligations this tool has to implement certain features. That seems like a quick way to get this topic locked. I will continue to share support for this feature with thumbs up and rare constructive comments.

There are multiple ways this could be approached, I still think we need general guidance from the VSCode team before anyone can direct their support to other forms of constructive help. As others have mentioned, no one can really begin work a feature as significant as this until there is some assurance that the work will be accepted.

@michaljaros84 The fact that VS Code isn't intended to be an IDE like Visual Studio doesn't at all preclude UX enhancements like floating in-process windows.

@RoyTinker Perhaps we can discuss the merits of floating in-process versus separate instances? I don't see a value to dramatically increase complexity if the same functionality can be achieved by spawning a new process.

The fact that Code is an IDE doesn’t mean we need to port all terrible UX choices for VS like floating panels.

I don't see a value to dramatically increase complexity if the same functionality can be achieved by spawning a new process.

The same functionality can't be achieved by spawning a new process, because, AIUI, for languages that have LSP-based tooling, the two processes could not both talk to the same language server, so you'd only have the LSP-based features in one of them.

@inarius Sure, although that has been discussed above already (see my "20% effort/80% benefit" comment). As I understand it, the use case is to support multiple monitors better.

For a variety of reasons (like the one mentioned by @HighCommander) VS Code only starts one workspace per folder (and currently a single workspace can't span multiple instances).

Thanks for the answers. I guess I can understand that. To be honest I am often using VS Code by opening files and not folders. If I were working on a git project, I could see how my current workflow of opening a new window and dragging files there would only allow me to take folder/git actions from the original window.

When I try this now, the new workspace definitely doesn't reopen the folder, but the git actions remaining even if I am working with files below the repository directory.

@Krzysztof-Cieslak Floating panels are built to be entirely optional in Visual Studio (i.e. no feature or workflow requires that you use them), so I don't see how it's a bad UX choice, even from the viewpoint of folks who don't want to use them.

It's a shame that this is still not possible, people with multi monitor setup would profit a lot.
So Vote for feature 💃

Would an acceptable way of allowing usage of multiple windows to store those windows in the workspace configuration? I could envision having some way to track the windows once it's opened. I might do some digging around later in the code to see if I could find a way to at least just have one workspace span multiple windows.

At the least, please remove the very arbitrary restriction on opening the same folder in multiple windows.

@TedYav That restriction has technical reasons behind it - see #2686 for more info & discussion.

So the reference in the Iteration Plan #47369 is just a joke about getting a 4k monitor rather than a plan to support this?

@hosaka Correct, although I didn't intend any sarcasm in my comment there. Hope it didn't come across that way.

@RoyTinker Not at all, just though I'd clarify so others who read don't get their hopes up :)

Bump. I, too would like to drag code tabs to desktop to edit in a new window

Beeing a longtime user of Visual Studio, notepad++, working for years with 3 (21 - 25 inch) monitors it is actually the one single feature that after a few hours using Visual Studio Code stops me using it. Tried it a few times. But for me ergonomically very uncomfortable and tiring to a degree that makes me leaving it be again. Would really be a great to have that.

Wow, This is the most wanted feature by far! :sweat_smile:

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

And surprisingly the next most wanted features are very related :+1:

Right now, I'm using vscode 1.22.0 with multiples monitors and the shortcut CTRL+k o to open a tab in a new window. This works pretty nice for me :sweat_smile:

Which means what exactly? Is there an estimation for when the top 3 features will have been implemented?

Op 9 jan. 2018 3:15 a.m. schreef Roy Tinker notifications@github.com:

Thought everyone would be glad to know -- this feature request just made it to #​4 by upvotes. Only 150 more and it'll be in the top 3!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/vscode/issues/10121#issuecomment-356148693, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD90FPGlliOcLwiQbPIMFB5fITE42-5Tks5tIr3GgaJpZM4JckZO.

People are downvoting because you add nothing to the discussion yet everyone subscribed to this issue gets your comment as an email.

Is there an estimation for when the top 3 features will have been implemented?

Some features have taken 2 years from when they reached prominence to when they shipped.

This is now in high demand for 2 (TWO!) years. I must say, especially considering the fact that Microsoft considers this its "official code editor" this is very disappointing. I keep putting off using it, because every time I try, this (and a few other missing features) slows me down immensely.
I think it is high time, at least for a definitive statement:

• Will this be implemented eventually? If yes: when? If not: why?

@Hypernut Actually the votes for this issue only really started to take off around December last year. Look through the comment history and you’ll see a post from (IIRC) less than 8 months ago saying “Only X more votes and this will be in the top 10.”

EDIT: Comment link here: https://github.com/Microsoft/vscode/issues/10121#issuecomment-339404507
"104 more votes to make it to the top 10" as of October 25, 2017.

I really want this feature too - mainly to just have the debug window on a different monitor.

An easier solution to implement (?) might be to allow a new window (CTRL+SHIFT+N) to open the SAME project (this currently isn't allowed). You could then open any tabs you need in this new window, or if you just want to have the debug console here you can maximise it to fill the window. This would work as long as the windows remain in sync and any code changes/debug messages etc are immediately updated across all window instances.

Please add this feature. I'm having to open both VS codes to mimic this behavior... Which would be awesome if this was built in.

Why the down votes @minajevs, @djm158, and @JustinAddams? I stated the same thing everyone else did in supporting this feature.

@faustinoaq Yes. YES! Thank-you-thank-you-thank-you!

For now, at least, Cmd-K o is good enough for me - opening a source file in a detached window. I saw someone requesting the same for markdown windows... not using that, but shouldn't be too difficult to achieve with the same solution, right? Or maybe it's already possible using Cmd-K o?

Thanks @steinhh for the Cmd-K O keyboard combination. I was not aware of that yet and I am going to use this next week on a multi-monitor system to see how well that works.

Your tip made me found the PDFs below and made me make the lists/screenshots below as well.

Terrific! Thank you, thank you!

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

The bindings (on Mac) I found with their screenshots:

• Cmd-Shift-P: show all commands
  
• Cmd-K O: open current file in new Window
• Cmd-Shift-N: open a new window
  
• Cmd-K Cmd-R: open keyboard shortcuts reference PDF for current OS in the default web-browser
• Cmd-K Cmd-S: open keyboard shortcuts editor
  

The keyboard shortcuts editor has a search which can find bindings on the keybinding name itself or the command name:

When I switched to VSCode, I fell in love with it. It's soo easy to use and fast on my slow computer!
But after using it for first 15 minutes I missed this function. I have 3 monitors and I usually work with 2 files at the same time...

@steinhh That is nice, but it is not at all what is being described in the OP.
"_...floating windows option for:
Terminal
Debug console
Problems
Output_
"
Any new window opened with the shortcut, still has all these sub-windows attached to it.

@RoyTinker
Excuse me for being so careless. I am sure the demand suddenly came into existence "last December". Before that, nobody wanted or even knew about floating windows. :)

Anyway, the point is: there is high demand NOW and it is absolutely being ignored.

@Hypernut I'm not a VSCode team member, nor do I speak for them. I'm just trying to help set expectations based on my observations of their past behavior and when this feature first would have appeared on their "user demand is high" radar.

@algiuxass Same here. I am surprised to see that this still hasn't been added. It is my biggest desire to see added with vscode. I'm not an electron developer so idk if this is a limitation of electron apps or if it can be done.

@RoyTinker
I do know you do not speak for the VSC-Team. But why do you feel the need to "set expectations"?

I think 8 months are more than enough time to at least give us a hint on what to expect. Especially considering the speculation in this thread, that it might not be possible at all.

@Hypernut Since the VSCode team hasn't given _any_ indication of their timeline or plans with regard to this feature, there's a real vacuum of information, which leaves folks very frustrated. I'm trying to help with that using data from the past.

I'm not defending the VSCode team or anything, just acting on my belief that complaints/etc. in the comments won't help much. As I've said before, the best way to get their attention is for a _lot_ of people to add their 👍 vote to the issue.

If you want to spend time helping on this issue, I suggest going to other places online where people who want this feature might end up (Stack Overflow, reddit, etc.) and linking to this issue.

Hey VS team, PLEASE implement this feature. It's not really "much", but this is a feature available in other editors that's sorely missing. In fact, it's the only feature that stops me using VS Code exclusively.

I've been doing some research on the floating windows problem (My knowledge with electron is almost non-existent) . It seems electron supports frameless windows, couldn't this solve the problem by just creating a frameless window when a user drags there file outward like on Visual Studio?
https://github.com/electron/electron/blob/master/docs/api/frameless-window.md

@Trevinlc1997
Yes on the small scale of an application it may be as easy as this
VSCode is a complex program, they cannot patch functionnalities on the core, or it would became a nightmare to maintain and improve ( just clone the repo to see what the hell is happening inside the beast )

My guesses (I may be wrong):
If they want to add this functionnality, they will be wanting to implement it in a way that allow it's full potential
The VSCode Team has taken knowledge of the demand for this feature, and the problem will be easier to handle when some other features will be implemented, so in order to prevent a 500m scrolling of explanations / discussions, they rather not say anything at all

How is this not a feature yet, it's the only feature that stops me from using VS Code exclusively..

It was the Language Server Protocol that attracted me to VSCode in the first place.

As a result of this issue, I have moved on to contributing to Language Server Protocol support in Eclipse instead.

i love VSCode. this is the ONE thing about it that i really don't like. it seems so obvious as a feature, even in the most minimalistic editor. anyone with a multi-monitor setup who tries to drag an editor tab out of the window has felt the pang of disappointment seeing it pop back where it came from. VSCode team, please please please put this higher up on your list!

+1. Would be nice to have similar to PyCharm/CLion.

Seems a new feature has been added to serve as a Work Around for this.
"Duplicate Workspace in New Window".
This seems to share the context / workspace across windows and solves the basic multi-monitor issue.

Thanks VSCode Team (and whoever worked on this).

They are also putting out a new grid feature. https://twitter.com/joaomoreno/status/1004303587755855872?s=19

yes, it is!

Yehya Abouelnaga notifications@github.com schrieb am Fr., 8. Juni 2018 um
12:22 Uhr:

@Deltatiger https://github.com/Deltatiger Is this shipped already?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/10121#issuecomment-395718792,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEVMyNsBaeorg-rczkcZsifgpi-jtPR7ks5t6lB7gaJpZM4JckZO
.

@Deltatiger
If your goal is to be able to freely resize and move around e.g. the terminal or the output (as described in by the OP), this does not solve anything.
Multi Monitor support is by far not the only reason for wanting this feature.

@Hypernut I totally agree.
I used this feature as a Work Around in the sense that I can now have one window (the original window) for all the Output / Git / Terminal and create a new Window for the actual code.
This way I get more real estate while still keeping an eye on the terminal / output, which I believe is one of the main reasons for floating windows. But that is my perspective.

Also there was some amount of discussion on Multi Window coding (original suggestion of Ctrl + K, O to open a new window), so I thought I would just clarify that part here for all the people looking for that feature.

But this will never give the same freedom as freely dragging mini specialized windows (say one for Terminal, one for git and one for say a second terminal).

If this feature can be implemented, it would be awesome.

Out of curiosity, why would you want to separate the terminal into a new window? Wouldn't it be better to just open a new terminal process outside of VSCode?

@iansan5653 Well then why put a terminal in VSCode in the first place? Why not a separate git application? A file explorer? Remove every plugins and just give one code window?

@iansan5653 that's my case:
I often use WebStorm (which has such feature). My workstation is composed by a laptop and an addittional monitor, which is rotated vertically for the sake of better reading. Thus I configure the IDE to appear as follow:

• on vertical screen: IDE's main window with editor, toolbars and (eventually) vertical splitting
• on laptop screen: project's file explorer / outline, terminal / test dashboard / debug dashboard

Could I live without it? Yeah, off course. But I still find it pleasant.

I'd rather the Visual Studio (proper) team become better at supporting client-side application development/debugging. That said, this is ONE of the big reasons I can't use VSCode for debugging.

When using the "Compare file with previous revision" feature, it can be almost impossible to see certain diffs without having to go to the end of line, as the editor is split in two in one screen. Having the option to open the two versions in two windows would be a real saver.

I think it need this function.

Notepad++ has this function to float window. But I can not find vs code has it.

So if i want to float window on my other screen, I still need to open new window then open my file, i think it is too laborious to use.

So please add this function.

And some one who has a good ways to solve it? Please tell me.

Thanks!

PS There are someone only give down emoji but not to try to listen other idea or give some ways about how to sovle it. I think i will look down on these people

某些人就是不喜欢差评和不足，就是会洗地，就是会吹来吹去而无视这些，就是会...
我想这些人大概我们是无法交流的。

I'd like the floating/dock-able windows and the positions saved for the next load. Currently I can stretch the windows across multiple monitors, but the position is reset back to the default on the next open. Mostly I just don't like the default positions of the panes and want to move them around.

@CHN-STUDENT I think people are giving :-1: votes because they agree that we need it (this thread has 270 comments and is the most :+1: voted issue). The topic is no longer about what we want or why, but how we can implement it, so let's try to keep the conversation positive and focussed on how to help implement this feature. :)

This missing feature is the main reason I cant use VS code.

Chiming in with what others have said -- Not being able to dock the various panels is a bit of a deal breaker for me as well. -- It was the third thing I tried to do in VS Code (right after changing the theme to light, so that I could see the menus, and installing the mssql extensions).

To be helpful -- what would be useful to me is not just being able to open files on multiple screens, but being able to dock any kind of panel anywhere in the IDE (including popping them out to new windows which can be moved to new screens). -- My typical setup has me opening code files on the first two of my screens, and having a control panel of all the useful "status" panels docked on the third screen.

I've attached below a typical example of what my third screen looks like (in hopes that it helps) -- apologies for the obfuscated text:

By the way, I was under the impression that most of the panel docking stuff that Visual Studio does was built-in to .NET, is it really that difficult to implement this? -- At any rate, Visual Studio does this amazingly well, perhaps you could reach out to the Visual Studio Prime team and ask to just borrow their code for this bit. ;-)

Edit: huh, it appears that VS Code is an electron app... well, that's an _interesting_ decision... hrmm...

This is the only reason that no-one on my team actually uses VS Code as their primary development platform. We continue to use VS 2017 - even with all of it's obvious fagility.

I have little doubt that VS Code team must realize this is a - nuclear level issues - so obviously they have a major architectural flaw that they simply can't address.

The is a top-three funtionality for a developer environment that Visual Studio (and every other developer environment has supported since Bill Cliniton was Presedent). So this isn't something that is in the catagory of; "Oh, I never thought of that!"

VS Code simply can't pull it off.

Got tired of adjusting the problems/output/terminal window up and down. Would be a great first step to make that detachable.

For ppl wanting a workaround, if you create a symbolic link to the folder of your project and open that folder as a new window. You get your project on both windows. To the VS code team, please never "fix" this bug (unless you add multi-window support ofc)

Isn't the "Duplicate Workspace in New Window" command added to the command pallette a couple of versions ago a better option?

@JustinAddams

It's ok as a workaround. Try accessing projects with multiple configurations of multiple languages, tooling and frameworks (such as .NET (plus tools and libs) for backend and buisness logic + DB abstractions and Angular/VueJS/React for front-end or some other frameworks)

Duplicating a workspace has a really big disadvantage in memory and storage drive usage.
It's essentially a new instance of VSCode in same workspace.
Running duplicate language services and language servers can create racing conditions and heavy HDD/SSD usage with accessing same files, especially with tools that use project wide analysis.
Sure you can disable those tools and stuff, but when working in a large team, it always happens someone commits vscode settings folder (even if it's gitignored - don't ask me how this happens). Then comes the chaos.

Also caching can be issue.
Frameless window from Electron can be a cool solution implemented, but in core. It will take time too. Since it's critical to change core code on that level.
They probably want to implement a functionality to maximum performance/RAM usage ratio but it's very complex because of their custom build of Electron and complex core. Implementing it at core can make all windows capable of frameless 'existence' like in Visual Studio 2015, 2017, WebStorm etc.

It's crititcal functionality, Especially for multi monitor setup. Sharing single workspace processes across multi-window opened files.

_Probable solution: Open new instance of VSCode instead of implementation of frameless windows, but add a command line option to let it use first instance's shared extensions (Problem: Extension host can be shared or is tied to instance?)._

@JustinAddams That what I am doing right now,

Also would be nice to have adjusted view configuration for duplicated workspace view…

For example,

• Select which folders to show
• Which panel to view
• Sidepanel visibility

Etc

Also from main workspace window we as developers could create a bridge service, that would listen from child duplicated workspaces events, and main workspace window could interact with that.

Use case, for example:

1. Open main Workspace window

2. Create subWorkspace by preconfigured template

   like duplicate workspace, but create a child process from main workspace window.
   A template could be named, for example, "Panel only" (it would had only Problems, Output, Debug console, Terminal)

3. In child Workspace terminal tab I can start yarn test --watch,

4. …do the coding, or anything whatever I can do…
5. If one of the tests fail I just do Command+Click on the sub Workspace vscode session
   5.1. Subworkspace targets event to main Workspace window
6. Main workspace handles event, and shows my file where tests was failed
   ……
   kinda profit!!! …would say,

But I see this just a loading a child session of Visual Studio Code but not fully loaded vscode, but a simplified and lighter variant of load… Hope this should not take much resources

Also modules on the VSCode should communicate through some middleware, that can easily connect many instances between each other, so in child Workspace window we can see problem from ESLint for example…………

Maybe this "brainstorm" will be helpful for someone, hope so :)

Cheers! & thx for attention…

For people who suggest opening another window.
The main benefit of this feature is opening terminal/output/problems on another monitor, so you can have a list of errors separately from the code window. So can Ctrl-Click on one monitor, and see corresponding code on another.

I would love to see this feature added. Webstorm/Phpstorm both have this feature, and it is really the main thing that I like about those apps. I use a portrait orientation monitor as my main editor, and having my file tree/explorer panel on a different monitor makes a big difference for me. I also like having my terminal on a different monitor, but I can always just use a terminal that isnt integrated with vs code, but having detachable windows in vs code for these panels would be awesome.

So? 2 years and nothing?
I can't stand integrated "search" panel, because it is always huge and wide.

I do find it odd that although this is now two years old and the most wished for and discussed feature here, this is still being completely ignored by the developers.
I am afraid, they have already deemed it too complicated/too much work a long time ago, decided it's not worth it and keeping it quiet to delay the fallout as long as possible...

And I must say, I am getting a bit pissed off by this non-communication. Maybe I am wrong, but it does smell a lot like Microsoft politics...

I am afraid, they have already deemed it too complicated/too much work a long time ago, decided it's not worth it and keeping it quiet to delay the fallout as long as possible...

I have no idea how this can be so complicated. Countless other software have done this, are doing it and will continue doing it so I'm not entirely sure what is actually stopping them from implementing one of the most requested features.

Is it because no devs are currently enlisted to work on VSCode ? Is it not deemed worthy enough as VSCode cannot be monetized ?

I'm not entirely sure the "this may prove to be too taxing on computers" argument is valid as of late considering most recent computers have much more system resources than previously. Also, if it proves to have this effect on workstations, have the opportunity to turn this feature off entirely.

Having the option to use this or not would be much better than not having a choice at all, quite frankly.

VSCode is used by people who CODE. If coders can't figure out how to toggle a feature on or off, perhaps they are using the wrong software.

Besides actions will be taken to reduce system resources drain but refraining from adding new features such as this based on the age old belief that "most users won't know how to turn it off so it's on by default upon install, the software could be really slow on various computers and it will make us look bad" is the worse possible argument given for the lack of implementation because this would imply that your target user base is less technologically enclined than most.

Last I checked, this wasn't the case.

My best guess is that it's difficult for them to create a new windows with the tab and have the tab keep it's state because of electron. They have to create a new windows each time you drag a tab into it's own window, and obviously this isn't an easy thing to do. Especially for things like the terminal, sidebar, etc.

I still desperately want this feature.

@Penagwin Likewise, but given I don't know what the technical reasoning is for not being able to implement it, I am also going to be polite and reserve judgement and wait patiently like everyone else. 😄

A workaround in the mean time is to open two windows, open a parent folder and a child folder of the same project. For instance, open the directory for your app in one window, and the 'public' folder in the other window. The downside is no drag and dropping tabs between them, but otherwise it works.

To all the people who propose the workaround with 2 windows. That doesnt help AT ALL with the actual problem of being unable to have stuff like debug inspector or terminal/output and so on on a second screen.

Use "Ctrl K, O" to open the current file in a different vscode window for editing. You'll have to set the terminal default directory again for the newly opened window to build. Only works with files; not on terminal windows. I know It's not the same as drag and drop but it should come in handy if you just need to move a few file to another window to make use of the second or third monitor. Nothing wrong with a work around since we don't have a solution. The world isn't perfect, make the best of what we have and get the job done. Hope this helps until we have something better come along. Happy coding!

Its hard to believe that its been 2 years and there has been so little progress on this. I was seriously beginning to fall for VS code as, on the whole, it is an awesome IDE. I cannot, however, consider it a serious contender for professional development without multi-screen support. Looking through these comments, it seems I am not alone in this view.

Back to Webstorm for now =(

Been watching for this feature for a while, just adding another voice saying I really wish this would happen! If VS code could implement this, it would be the perfect editor!!

Why is this still not a thing ! What is the hold up on this feature... VS code is a great editor, but this is a major feature missing...

This really needs to happen! Big oversight on Microsoft's account.

Please guys, do it! This is the most wanted feature ever :dancer:

I'm working with 3 monitors, and I need to have this feature, because sometimes in the code I need to see what functions that I need to implement from one file, and I need to open this in a separate window to copy paste what I want instead of splitting the window inside one monitor that can limit the work space area.
Please implement this feature to float the windows (window detaching).

+1. This would really be super useful for multi-monitor productivity.

This feature request recently celebrated it's second birthday. I doubt it'll ever get implemented :(

+1 Any updates on this feature?

It looks like wanting this feature correlate with not having ability to use GH correctly nor behaving well in the internet discussion. Mindless +1 spam will definitely help your cause.

@Krzysztof-Cieslak There should be a option to disable comments on an issue and only allow reactions to the OP

@Krzysztof-Cieslak I think +1 is related to a vote rather than a discussion.

A +1 is often used to UP the conversation so Microsoft guys do not loose the issue ;)

@SkyzohKey, it's already opened, they will not lose anything.

Any chance since MS owns github and essentially the electron project this will actually see the light of day? I agree that this is a fundamental issue with the editor otherwise it is pretty great.

@napalm684 Good point, nevertheless I think this is not a problem in Electron (https://github.com/Microsoft/vscode/issues/10121#issuecomment-346088717), but with VSCode architecture itself (https://github.com/Microsoft/vscode/issues/10121#issuecomment-346290180).

Ah, I read originally @n9 this was an electron problem. Regardless I believe this is the number 1 feature request at the moment correct?

Will it has this feature next major version?

I know everybody didn't like being urged but,
I hope this feature be the max priority.
I know this is a opensource freeware, but this limitation may stop new users from using VS Code.
We are happy to use new awesome IDE, and we are popular, isn't it?

So yeah... here's one more developer wishing I could detach tabs out of VSCode just like work with VS.

Same as most people here :
I would love to be able to have more than one VS code window for a single folder/project and be able to work on more than one monitor.

Awesome IDE nonetheless 👍
Keep it up, I'm loving your work.

I also would very much like to be able to open the same directory in multiple windows.

👍

i would love to detach debugger console so as to view on 2nd monitor

+1
The workaround (open new window and drag and drop your file from the current workspace/window to the newly opened one) is OK but I have no access to the workspace itself; different settings, no access to other files in the workspace, etc.

But apart from this VSC IS AWESOME!

I've tried to check what we could do with floating windows in VSC.
First of all - Electron supports multiple windows. It's possible to open additional BrowserWindow instance but it require HTML file on load.

In that case, let's consider terminal in floating window. I'm not so fluent when it comes to VSC code, but it seems that all application is running as "monolith app". It means that if we would like to have something from VSC UI in additional window, then we have to load all application there and hide unnecessary parts of UI.

Sounds great? Not really. In additional window we have to hide unnecessary UI parts but also... disable updating other app areas on files change or shortcuts. What's more... I don't know how Electron memory is working but I believe that if we load all application in second window, then memory usage of VSC will dramatically increase.

I think that we should try to do VSC more modular and prepare some kind of multi-window mechanism before we start work on floating windows with single UI parts.

Dear community, let's try to help VSC team.

A +1 is often used to UP the conversation so Microsoft guys do not loose the issue ;)

Nah, by now they are used to ignoring the issue. :) It's like putting a note on your bathroom mirror. At first you can't possibly ignore it, but after a while you don't even see it anymore.

I'm not an Electron guy of any sorts, but I've tinkered around with it a little bit. Wouldn't it be possible to launch a new window, and do communication between the parent window and the child via the webContents API?

@kodipe

@scriptcoded good question!

I've just found this project https://github.com/illBeRoy/ElectronScriptWindow which allow use BrowserWindow without specific HTML file. Basicaly, it creates base64 encoded string as URL for window: https://github.com/illBeRoy/ElectronScriptWindow/blob/master/src/index.js#L76 on load. After that we should be able to control child from parent via webContents.

@kodipe Neat! That's quite a clever way of doing it. Perhaps I'll look closer into the sources and figure out if this would be a good way of doing it. I would suspect this implies some heavy rewriting of a bunch of core features.

@scriptcoded yeah... it's really hard to achieve feature at this moment. I will look for solution for some simple FloatingWindow API and will share with you here if I create something interesting on my fork.

+1 for this feature

I hit this limitation a couple of times a day, it's a pretty big missing feature for me.

Workaround:

1.) Open your project folder
2.) Save as a workspace
3.) Open workspace in one window and project folder in the other

hope this helps

This feature is overdue and critical for productivity with multiple monitors, how many replies do you need to add this feature to scope? I can get all my colleagues to reply if you want.

What about https://www.npmjs.com/package/electron-window-manager ??

@WNemencha I'm assuming the team doesn't want any unnecessary dependencies. Perhaps bade it upon that?

Hope we will get this eventually, this is a must have :)

To continue innovating, and make VSCode a modern full-featured editor, this is a necessity. This should be a major long-term goal until it gets done.

This feature really should be a high priority feature. I don't know any developer who only codes on one monitor, and having the ability to drag a tab to a new window for side-by-side use is just too useful of a feature to not have.

This feature really should be a high priority feature. I don't know any developer who only codes on one monitor, and having the ability to drag a tab to a new window for side-by-side use is just too useful of a feature to not have.

Hey, @oryandunn what you are complaining about is actually possible. See my comment added under this ticket:
"Open new window and drag and drop your file from the current workspace/window to the newly opened window."

This ticket is about opening two windows in THE SAME workspace.

@kapalkat to clarify, this issue is about detaching parts of the UI, such as the terminal, explorer and debugger, from the main window. #2686 deals with multiple windows with the same workspace.

I think this issue should be frozen / restricted until someone can actually work on it (from VSCode team).

I do not think we can expect this feature anytime in the near feature. From my understanding, the team would have to change lot of the infrastructure to make this work. Not just that, I am not sure how much else will be affected.

Also I doubt that this has anything to do with Electron (Not an electron side restriction / issue). It is just limited by the current architecture.

This thread is getting filled with more +1 comments than actually helpful ones.

This thread is getting filled with more +1 comments than actually helpful ones.

That is user base frustrated because they lack multiple monitor support. How else should developers get info on what user base wants?

How else should developers get info on what user base wants?

By leaving a 👍, and keeping the discussion area clear for constructive discussion, such as:

I quite like the implementation that VS had, where on dragging any part of the UI it could "snap" to part of the screen. Similar to how dragging a tab right now lets you title the main view.

To be honest though, the only thing I really want to be able to do is drag code editor tabs out. I don't even care about being able to tile them outside the main window, because then I can just use the OS window manager instead.

Everybody clap your hands for @mrmos and his solution.

@jayarjo I've been doing something similar by opening a new vscode window and dragging my tab in there. The problem here is that none of the finds work properly as it doesn't have any information about the actual "workspace" it came from.

As a simple workaround you can use the command Duplicate Workspace in New Window (since version 1.24) to open the current folder/workspace in a second VS code window that can be moved to a separate monitor. I assigned the keybinding Ctrl + Shift + N for this command.

@n0v1

As a simple workaround you can use the command Duplicate Workspace in New Window

Hmm, I don't appear to have this functionality in latest macOS - does it need to be enabled?

Regards

@ldexterldesign Have you tried running it by opening the command palette (⌘+SHIFT+P) and typing Duplicate Workspace in New Window?

@n0v1 the problem is not opening the a file/workspace in new window. Maintaining the context of the underlying buffer (file) in both these windows is the issue.

To make it clear, open a file in one workspace and open the same file in the duplicated workspace. Now, edit the file in one window, it won't be reflected in the other window.

Everyone now telling the duplicate workspace stuff, but that's sure now known by everyone und doesn't need to be repeated so often. And this whole "workaround" is not even practical, we need a real floating window feature like it's implemented in other editors.

Please stop suggesting "Duplicate workspace". That's not the solution. We need the workspace explorer duplicated as well. Which it is not.

I would love to see the ability to detach the console (and other parts of the editor) and push them across to a separate screen allowing me to get the full real estate of my main screen for writing and reading my code when I'm working somewhere with multiple screens/

This would also allow me to better manage and work whilst on the move where I'd only have my main screen available to work from, like on a train or at customer sites.

I can see no progress on this feature and few years past. If we stuck by architectural limitation that cost too much to make it happen, Why not just close it and going forward？

Dont forget we have VisualStudio Community, please consider to move some feature to VS plugin.

@Nyconing VS Does not run on linux or mac.

@Nyconing VS Does not run on linux or mac.

Not quite true...

OK, community.

What is the best way to show one file (with unit test) on the left monitor and the second file on the right monitor?

Please do not try to recomend to use Vim, Emacs, Visual Studio Enerprise, Sharp Develop, Eclipse, Jetbrains or may be Notepad.

What is the best way to show one file (with unit test) on the left monitor and the second file on the right monitor?

Don't double post please. The best I can offer would be to resize the window so it covers both your screens and split the editor into two tiles along the middle between your monitors.

Don't double post please.

There are some internal problems bei GitHub itself

Not quite true...

it runs on mac with wine or windows vm

@hellboy81 @belst My bad, I thought you said VS Code. Sorry! Back on track now...

Just my 2 cents
"Ctrl + K then O"
is bound to "Open Active File in New Window"

Just my 2 cents
"Ctrl + K then O"
is bound to "Open Active File in New Window"

Like others have said, opening in a new window isn't what were asking for or wanting.

We are looking for the ability to pop out a window and move it where we want, basically like premire pro does with the different pallets sort of thing,

Just my 2 cents
"Ctrl + K then O"
is bound to "Open Active File in New Window"

Like others have said, opening in a new window isn't what were asking for or wanting.

We are looking for the ability to pop out a window and move it where we want, basically like premire pro does with the different pallets sort of thing,

I totally agree with you. I was just trying to help with a temporary workaround that I use while waiting for this feature.

I just want to voice my opinion on this. I think about great deal of developers have more than one monitor and using them effectively is a big win for productivity.

I'm not sure why this feature never gets progressed as it has massive support and given code is electron app it's perfectly doable and degradable if you ever ran outside of electron.

In a word please support MDI in vscode.

Until VS Code has multiple display support I do not see moving to this editor as my default. I recently, started using JetBrains tools as an alternative. I have been watching this issue for year + and still no movement on this. I am not sure why the delay?

Xcode allows for multiple windows for a project. Even more, the windows are all equal, fully functional windows, meaning you can open a second window and close the original project window and you still have a full project window.

This approach means multiple monitors are easily supported. It also means I don't have to babysit the window management as much as I don't have to remember which is the "real" project window.

This approach would be greatly appreciated in VS Code.

Xcode allows for multiple windows for a project. Even more, the windows are all equal, fully functional windows, meaning you can open a second window and close the original project window and you still have a full project window.

How? When I try to open the same workspace in Mac OSX it always just focuses the already open window.

Since VSCode is written with Electron "floating windows" is kinda hard to accomplish, but allowing to open the project twice would help a lot, but this doesn't seem to work either. Any help is appreciated.

Coming in and stating my own experience: I've successfully used VScode in the past to compile and debug a game engine project I contribute to, but since I can't do detached windows with VScode, i'm unfortunately sticking with CLion, which is slowly but surely taking on Visual Studio at large.

Like others who mentioned it in this thread, multi-monitor coding kinda requires detachables.

Xcode allows for multiple windows for a project. Even more, the windows are all equal, fully functional windows, meaning you can open a second window and close the original project window and you still have a full project window.

How? When I try to open the same workspace in Mac OSX it always just focuses the already open window.

Since VSCode is written with Electron "floating windows" is kinda hard to accomplish, but allowing to open the project twice would help a lot, but this doesn't seem to work either. Any help is appreciated.

You can do this in Xcode by either tearing a tab off or using File-> New Window. All windows where you can navigate your project or edit code are equal. There's no such thing as a "main" window in Xcode. See the attached gif below.

2 years since it was requested. Any estimates when VS code could be capable to do this?

This is an OSS. You can help and contribute your skills to VSCode. If you really want VSCode featured in multiple windows, why not try to fork and make it possible by yourself?

I know that it is OSS. That is why I did not have any expectations about it. I only asked if there are any estimates from people looking after this repo. 'No estimates' is also an answer. Thanks

Request: Please close this issue for comments.
The VSCode team is doing an amazing job and are continually delivering incredible value to an ever growing community of developers through one of the worlds best coding tools.
While I express as much enthusiasm as anyone here about the prospect of multi-window, I am happy to wait as long as it takes. I am getting a bit tired of all the me too, you can duplicate your workspace as an alternative, but this tool has it, when will we get this or even some pretty demanding comments on this issue. I wait eagerly with every comment on this issue to hear a relevant update only to see more of the aforementioned comments. Finding a relevant comment from a team member is difficult given the 363 comments above.

I'm sure this issue is on the team's radar (it is the number one requested feature).
@bpasero has given his latest feedback in this comment above: https://github.com/Microsoft/vscode/issues/10121#issuecomment-345770248
This requires a bit of rearchitecting the internals of vscode, so let's be patient (or contribute).
That status update is enough for me. They will get back to us when there is a further update.
Please 👍 the issue to show your support.