Multi Monitor Support in VS10
What would a perfect world look like where your using Visual Studio with two or three (or more) monitors? One of the new Visual Studio 10 (Visual Studio 2008 = VS9) I'd like to nail is darn good multi monitor support, but I've got a lot more investigation to do to know what this would really look like.
Some of my favorite techie/VS bloggers are huge multi-monitor fans, like Scott Hanselman and Jeff Atwood. I just got off the phone w/ Jeff and he mentioned a some good points (here are just a few). Thanks Jeff
- Live the Lifestyle, everyone should be using VS multimonitor on the team
- Drag a tab to create a new floating window. This would allow you to take some code or other document and move it wherever you'd like, onto another monitor for instance.
- Nail the defaults. Make the out-of-the-box default window layout experience rock. Users frequently mess up their window layout. If the defaults rocked, there would be less need for customization.
Some of the ideas we (our VS designers, myself, and architects) are thinking about are:
- A Canvas. Being able to view many 'open files' zoomed out as if they were papers spread on your desktop that you could just click to zoom in and edit. Search results would highlight code across the entire canvas of files.
- Special Memory. Ways to group similar files/dialogs/info/etc instead of just docking to the sides of the IDE.
- Drag Zones. Like many of the multi-monitor apps out there, how could this be applied to the VS IDE?
- Tons of other little VS UI enhancements.
Personally, I haven't been bit the multi-monitor bug yet. I love having one PC for everything (my laptop) which I dock and use a single external monitor. I'm a big Alt-Tab & Win-M fan and like viewing simplicity, seeing just what I'm focusing on in view. So my first task is to start trying a multi-monitor setup myself.
The reason for this post is to collect your feedback. Now, early in the product cycle, before our plans are baked. What would make Visual Studio rock on multiple monitors?
Comments
Anonymous
October 10, 2007
The comment has been removedAnonymous
October 10, 2007
The comment has been removedAnonymous
October 10, 2007
I would LOVE to see multi-monitor support in VS. We can already undock windows and drag them to other monitors, but I'd like to see better support for this. I'd like to use all the landscape on my screen and maximize the things on the second monitor without having to drag it out to the size I want. I like the idea of having it "dock" or "snap" to the monitors as I move it around...that would make it easier to move around. I also like the canvas idea. In fact, I think that idea is great...I'd like to hear more about it.Anonymous
October 10, 2007
That looks really cool! It's like manny beautiful pictures put together. -Love ya!Anonymous
October 10, 2007
Yes! Please! Love the snap and canvas ideas.Anonymous
October 10, 2007
You can probably try out the multi-window lifestyle yourself for a bit by getting a laptop stand to place you laptop screen about the same height as your external monitor - then extend your desktop across both monitors, works quite well if not quite as good as having multi-monitors with same screen proportions. In terms of feedback - I have trouble thinking outside my current multi-monitor usuage style. Currently I run my IDE full screen on the center monitor and then use the right monitor for thinks like viewing reference material (i.e. help or a code sample). I keep the third monitor to the left to keep an eye on email / IM etc in a glanceable way without having to hide my editing window to tell if any of that stuff needs higher priority then what I am working on in my IDE window. When debugging an application, I have it on the right screen so that I can easily switch between IDE and app. For some types of application, it would be nice if the console/test results windows were on the right hand side giving me more room to view code and watches etc on the center monitor. On thing I would say is that it is really annoying if your toolbars get too far from the window you need them with - i.e. if the toolbox for a windows forms design session was too far from your windows forms design screen. I tried running Dreamweaver and Adobe Photoshop (which are kinda IDE's of another type) in multi-monitor setup using undocked windows and it just wasn't nice. With all the apps I've used on the market today - keeping the windows associated with that application on one monitor inside a full screen app window prooves to be the way to go - but I think it could be improved. You need only look at Powerpoint for an application that can handle muti-monitors in an innovative way (i.e. display slides fullscreen on one while keeping the slide editor/navigator on the other. Good luck - nice to hear some great imagineering going into VS10!Anonymous
October 11, 2007
Noah, Occasionally I stretch the IDE across two monitors. I like to split the ide into two sets of tabs by creating a new vertical tab group. I'd love to have the tool split at the border of the monitor, automatically. ++AlanAnonymous
October 11, 2007
Lots of great feedback, thanks everyone. If you get any more ideas, post them. I'd love to show mockups or prototypes, but we don't have anything to show yet. But I hope to post ideas when we've got them better sketched.Anonymous
October 11, 2007
I currently use three monitors. The center one runs Visual Studio full screen. All of my commonly used tool windows float in the right hand screen in a layout that makes sense to me. These include Properties, Toolbox, Pending Changes, Server Explorer, Solution Explorer, and Team Explorer. Certain windows are in logical tab groups. I also have several floating windows in the right hand monitor during runtime: Output, Call Stack, Autos, Locals, Command, Immediate, Breakpoints and Watches. Again, these are in a layout that works for me, with some of them tabbed together. I have certain less commonly used tool windows docked in the main IDE window, but always on autohide, code and designers get priority. The left hand monitor is where I keep reference material and other applications. I'd really like to see the ability to have certain window/tab layouts saved as presets so that you can toggle them. This would be useful for some of the scenario's mentioned above where moving between different monitor configurations messes things up. Being able to open files in a floating window, and drag files back and forth between tabs and floating windows would be useful. One thing that would be most useful to me personally would be extra care taken to make sure that the floating windows all behave properly. I've submitted some bugs that existed in VS2005 and were carried over to 2008 that concern the positioning and behavior of floating windows. Unfortunately only the least annoying will be fixed for RTM. The other couldn't be repro'd. Thanks! This sounds like it will be great. I can't wait to be able to move off of crusty old VS2008. ;)Anonymous
October 11, 2007
I am currently running dual wide screen flat panels rotated 90 degrees to give me more lines per screen. I have my editor in one window, and my debugger/shell/cvs/datasheet etc open in the other.Anonymous
October 12, 2007
My friend and VSTS coauthor Noah Code has just posted a great article about the issues and opportunitiesAnonymous
October 12, 2007
I agree with Alan on stretching the IDE across multiple monitors. When you have two code panes side-by-side any little adjustment to the docked windows can throw the splitter bar out of alignment with the monitor edge. It would be neat if the splitter snapped to the monitor edge. The snap would apply when dragging the splitter and when the window layout is recalculated. Doug.Anonymous
October 12, 2007
Multi-monitor is indespensible in my day to day development effort and currently it is easy to drag toolwindows onto different monitors. What would be nice would be the capability of dragging the designers out of the VS IDE and also the capability of creating new named doc containers. This would allow for different toolwindows to be docked or layed out and moved together in a grouped method. For instance I may want a debugging doc container, a ASP.net formatting doc container, and so forth. For me having tons of little windows seems like it would have a higher cost then just draggable grouped containers. MarkAnonymous
October 12, 2007
I've been using three displays for development for several years. Up through CS2, the Adobe apps made my life miserable with their floating palettes. When I'd move the maximized Photoshop window, using UltraMon (or DisplayFusion now), the palettes would remain, making it an unnecessarily laborious task. In CS3, they changed the palettes to a docked interface much like VS uses, and I find myself using Dreamweaver and Photoshop a lot more than before. To me, the most important thing would be that Visual Studio continues to change displays gracefully. I find myself switching it between center and right display at least a few dozen times in a normal day. I would hate if overjealous multi-monitor flexibility actually made it more inflexible to use in practice. That said, the canvas idea sounds excellent. I'm already looking forward to it.Anonymous
October 12, 2007
My main monitor will always be the biggest one, in which I will run VS, but... when I run my app I would like VS to step back and yield the main monitor to my app and move itself to another monitor in case I need to debug. Being able to start my app on another monitor would also be nice.Anonymous
October 12, 2007
I usually stretch the IDE across both monitors but my problem then becomes tool window placement. My toolbox or properties are usually anchored and its either on the far left or right. I would like to see something maybe where you can have duplicate tool windows attached to other windows. So I could have a web page on one monitor with a toolbox and properties toolpane inside that document window to reduce navigation time.Anonymous
October 12, 2007
The comment has been removedAnonymous
October 13, 2007
normally use a laptop with vs in the lappie screen and sql manager or web browser in the other screen but i could see myself wanting to use vs multi screen once in a whileAnonymous
October 13, 2007
Although multi monitor support sounds great, please don't forget really key features that are still missing from VS, such as background compiling for C# and a less fragile form designer!Anonymous
October 13, 2007
My favorite idea from your list is to treat code files as individual windows. Why not treat code windows like toolbars, where they can dock inside VS.Net's parent form, or can be undocked and float by themselves? Or something like squeak, where the layout is up to the user, and there isn't a main work environment?Anonymous
October 13, 2007
I like the idea of finally getting multi monitor support in VS, but what I really do not get is, why do we have to wait until the VS10 release, which is probably not released before 2010 ? I have been using multi-monitoring as long as I got a job as developer, which was in 2001. We are still in beta testing of VS2008 and I tought the feature-freeze always started at the release of RC's. Multi-monitor support is a frequently asked feature for Visual Studio. So why implement it this late? Ok, that was my frustration rant. I would like to at least be able to drag code windows to other screens. Maybe incorperate a compare function between two code screen too ? (like BeyondCompare does?). Also it would be great if we could have one window with HTML layout and the other shows the rendered page.Anonymous
October 14, 2007
Soporte Multimonitor para Visual StudioAnonymous
October 14, 2007
Wow, lots more great feedback. kettch, it sounds like being able to dock those floating tool windows together in a group would help. Doug, good idea about snapping the splitter to natural edges, like between monitors. mdykun, I agree, documents should be able to float too. I like the idea of 'named docking wells'. dm, good point about moving VS or your app when running the app. Josh Bernard, multiple instances of the tool windows isn't something I've thought of yet, thanks! Kirk Clawson, yes I agree and it's something we hear a lot, that it should be easy to switch between layouts. JK, 'squeak'? I haven't heard of that. Funny you should mention the 'all floating' idea, that's what the original VB v1 used and it's better at multi-monitor than VS is today. Wim Haanstra, I agree that it is frustrating. Very few changes were made in VS'08 to the actual VS shell due to other constraints. It's time to make some great improvements. :)Anonymous
October 14, 2007
Many of you mention being able to easily switch layouts. Has anyone tried the VSWindowManager VS addin? I've used it and find it very helpful. http://www.codeplex.com/Wiki/View.aspx?ProjectName=VSWindowManagerAnonymous
October 14, 2007
It'd be great to have multiple sets of tabs for code windows, grouped by project (or perhaps even user definable groups) Then you could just grab a set of tabs and move that set to a different monitor. The grouping by project would also help mentally to keep track of scope.Anonymous
October 14, 2007
How about putting a button near "X" in docable and floating windows to move them over to other screen? My preferred setting for multimotitors would be to have code windows in "Full Screen" mode on one screen and all other windows (Solution explorer, debug, output etc etc) docked in to some container on other monitor. The biggest problem however is "dumb" tab management in VS. As you browse over files very soon there are so many tabs gets and stays open that its pain to keep closing them. It would be nice to have setting for say, keep only 8 tabs open. In that case, when I double click on unopened source file, the tab which I haven't opened since longest time should close. Another handy thing would be to have designer open on one monitor and code on another. In any case it is important to remember that lots of devs dock their laptops on and off several times a day to switch between single and dual monitor environments. VS needs to be smart about that.Anonymous
October 15, 2007
My simple idea: You know how, when you drag tool windows, you get those neat little helper glyphs that float over the UI? Make them multimonitor aware. The current system: Drag a docked tool window and five glyphs pop up within the UI. Left, right, up, down and center (which has five parts). Multimonitor aware system: Drag a docked tool window and the same five glyphs pop up, but each monitor has its own set of glyphs. Within the UI (on the monitor where the UI primarily resides), it behaves like normal. Outside it fullscreens the tool window or snaps it to the selected side of that monitor. If a tool window is already there and snapped to a side (or center) it is adjusted to fit the new tool window in the selected location. Floating tool windows are not resized. This set of behaviors is simple to learn, as it apes the current behavior, but extends it to multiple monitors.Anonymous
October 17, 2007
Get rid of the MDI host environment altogether. Have the "home" of the environment the menu and toolbar plus a "palette" from which you can "grab" editor windows, toolbox, tool window "containers" and allow the user to drag these to any monitor they choose and maxmimise it, snap it to a side of that monitor, stretch it across multiple monitors etc. When they minimise it it should minimise back into an "active palette" on the home window. The home window itself could be stretchable across multiple monitors etc just like all the other windows.Anonymous
October 18, 2007
The comment has been removedAnonymous
October 22, 2007
A few suggestions! What about having multiple "workspaces" (like Linux' multiple desktops) that allow you to open the files/tabs you want so that you can switch from working on feature X to feature Y without opening and closing the relevant files. Also being able to hide files/folders/projects in solution explorer for each "workspace" would be good so your solution explorer isn't cluttered with files you never/rarely open. Also I would love for search results to by highlighted and incremental search. Also the ability to save searches (bookmark them). Another great feature would be the ability to collapse a code region from the bottom of the region rather than just the top. Lastly, when debugging it would be nice if all files/code regions/etc were closed after debugging is finished (a configurable option of course) so that you don't have to close files that you've stepped into while debugging. Looks like you've got plenty of work to do!Anonymous
October 24, 2007
I did a vs survey a while back (thanks for the nice prize btw) and my biggest request was multimonitor support. It would be sooo nice. Having not to do shift-alt-enter all the time would save me a nice chunk of time, and keep me from developing some strange kind of pinky strain.Anonymous
November 20, 2007
ISSUE WITH MULTI-MONITORS AND TABGROUPS: Multiple tabgroups are perfect on my multiple monitor setup. The concept is great - each tabgroup can be resized to take up a single monitor, and this works regardless of how many monitors you have. The problem is that when the IDE flips between debug and code mode, the vertical tabgroup positions are messed up. Try sizing them precisely to fit on dual screens, and you will see exactly what I mean as soon as you run your project in debug mode, and then go back to design/code. I can't seem to find a pattern to it, but it seems to happen when the window is in a non-maximized mode. I have tried many variations, including turning off all toolbox, output, properties, etc windows. I have also added the same sets of tools to the top toolstrip to no avail. This is a royal-pain and makes me feel like I am developing with second-class software on my top tier hardware.Anonymous
November 20, 2007
Use Eclipse for about 10 minutes and you will understand how multiple monitor support for IDEs should work. Eclipse is no where near the development IDE VS.NET is, but it nailed the whole multiple monitor aspect upon it's creation. You can have multiple root windows open in different perspectives (coding, debugging, profiling, source control, etc) All based on the same solution --> completely linked in real-time. Visual studio needs the perspective concept as well as the multiple window support. Thanks for the great tools and btw currently I use several 24 inch LCDs to develop with as well. /rbAnonymous
December 06, 2007
Absolutley. Multi monitor would be very helpful.Anonymous
January 29, 2008
The comment has been removedAnonymous
January 29, 2008
Finally, looking forward to it and it should have been done ages ago.Anonymous
February 13, 2008
I have used 3 monitors for the last 5 years or so. I initially started out with it because i could but being a web app developer, i feel that i benefit hugely from SQL, VS and Browsers on independant monitors, when I am just in VS though I hate the fact that I can't compare different file versions withoug opewning multiple editors.Anonymous
February 25, 2008
My thoughts: When I'm not using VS, I tend to use Eclipse. It has a very simple facility that makes it usable on multiple monitors: a menu item to create a new top level window. Once you've done that, you can put one window maximized on each monitor, set whatever collection of toolbars you want to have on each window, and use them for different purposes. (I actually ended up here by googling to see if Visual Studio had a similar feature. Clearly not.) Now, this isn't perfect. A few flaws I spot in this are:If you're working with a file in one display, but then do something in the other display that references it, you end up with two copies open. I'd prefer it to be brought to the front on the side of the screen I'm working with it on, and some method used to draw my attention to that.
It isn't possible to drag and drop between the two windows, which is a pain.
Only one of the windows switches layout when I start debugging; ideally, both should switch together. This is better than stretching a single window over both desktops (as some of the posters above are clearly thinking) because it copes with unevenly sized desktops (e.g. if you have the taskbar permanently displayed on your primary display, but not on the secondary).
Anonymous
February 26, 2008
I love multi monitor, but rarely use it with VS. When I put the Soln Explr, Schema view, Watch windows or what ever in the second montor and then debug, then stop debugging, all the windows come back into the main window. if they would stay in the window i dragged them to in the first place, that would be great. also being able to detect multi monitor.. i develop all day on three monitors, but then take my laptop home where i only have the laptop screenAnonymous
March 03, 2008
All I really need is a separate top-level window that I can drag tabs to and from, like Jules talks about in Eclipse. If VS had that, and the contents of all windows switched on mode-changes (ie debugging, code editing, etc), life would be nearly perfect. Is it possible for a third party vendor to create something like this?Anonymous
March 12, 2008
I love the idea. VS is just too complex of an app to use on one monitor. But please remember that people using laptops with multi-monitor support sometimes start their laptops up without the second monitor attached. Please support us switching between multi and single montiors easily without having to recofigure my docking preferences every time.Anonymous
March 18, 2008
The comment has been removedAnonymous
April 11, 2008
I thing that possibility to clone main VS window to other monitor and freely move tabs and dockable windows between those main widows is quite enough. Another think I'm interested in is possibility to save multiple VS dockable windows (and dockable windows turned to tabs like Object Browser or Team Eplorer) configurations and switch them quickly.Anonymous
April 21, 2008
It would be really nice to have a. multiple top level windows Each top level window has the full tool bar, a tabbed documented area, and floating windows. The tabbed document area should be able to be disabled so you have a collection of tool windows. This is preferable to the floating tabbed window collection which does not have its own z value. Each top level window should have a layout. VS currently has Design, Debug, FullScreen, and NoToolWindow. There should be Windows commands and a drop down tool bar for naming new layouts. Layouts should store the location of tool windows, and the context of a tool window (memory view layout). There should no longer be limits on the number of watch and memory windows. The settings for each of these windows should be persisted in the layout. Having multiple top level windows allows the user to maximize a window to each monitor. This is preferable to stretching across multiple monitors. Layouts should be data driven, not programmatic. Eclipse perspective are programmatic and very annoying. Top level frames should be able to share documents and tool windows. The user should be able to drag a window from one frame to the other. b. Multi-monitor Debugger Each top level frame should be associated with a debugger context. Per frame the user should be able to specify program, thread, and stackframe. There should be simple rules for defining on which frame a stop event opens. Multiple program and multi-thread debugging is not friendly in current VS. This needs to change.Anonymous
May 07, 2008
Multi-Monitor Visual Studio would rock my socks! I haven't amicably developed without an additional monitor for 5 years; it just opens up productivity at least two fold. If you guys can go so much as to make it 3 fold that would be great, but based on the pool of interest here I'm thinking it may be more like 10 fold. Best of luck, I'm rooting for you. -TheXenocideAnonymous
May 15, 2008
The comment has been removedAnonymous
June 26, 2008
The comment has been removedAnonymous
July 15, 2008
I think this is a good idea, but I wanted to echo Mark W's concerns about support for Remote Desktop. VPNs are pretty common these days. Thanks!Anonymous
August 14, 2008
I use a three monitor setup for development and I love it. Middle monitor is for the code, left monitor for the explorers (solution,... anything tree like) and the right monitor is for toolbox, properties and output windows. This allows me to have maximum coding space while being able to see the bigger picture at the same time.Anonymous
August 14, 2008
The comment has been removedAnonymous
August 15, 2008
Thank you for considering multi-monitor support for VS10. You have no idea how long I've waited for it in Visual Studio - every developer at my current job, as well as my previous one, has had dual 19" LCD monitors. At a very basic level, the only "true" multi-monitor feature in Visual Studio that I need is the ability to drag a window out of the MDI interface and have it become a true, top-level window. I have two ideas on how multi-monitor support could be added to Visual Studio. The first idea would be a "low tech" modification to Visual Studio, while the other would allow for a "rich" multimon experience. Idea 1 - "loose" windowsAllow document windows to be changed to top-level windows and vice-versa
Add a new context menu item for the current document named "Change to Top Level Window" or something similar
Add a new keyboard shortcut to do the same thing
Implement "drag" support to the current document's tab, allowing it to be "dragged out" of the Visual Studio MDI container and "onto" the desktop as a top level window.
Each top-level document window appears in the task bar independently (rationale: Some multi-monitor tools create a taskbar for each monitor)
The windows should act, look, and feel like "normal" windows - show in the task bar, full sized OS drawn title, etc. (Not tool windows) Idea 2 - Multiple Visual Studio MDI windows
Add a new command under the "Window" menu named "New Visual Studio Window", or something similar
Add a new keyboard shortcut to do the same thing
Selecting the command creates a new Visual Studio MDI window.
The new window would have a full copy of the Visual Studio menu (ie/ each top level Visual Studio window gets the same menu)
The new window would not have any toolbars. Each top level Visual Studio window would have a different toolbar configuration, but could have duplicate toolbars. For example, Window 1 could have the "Standard" and "Text Editor" toolbars enabled while Window 2 could have "Standard" and "Debug Location" enabled.
Only one Solution may be loaded (no change to current behavior. Additional solutions can be loaded by opening other Visual Studio instances, the same as current behavior)
If an item is opened using the menu (ie/ File->Open), it opens in the active/current window
If Solution Explorer is docked to a Window, items opened using Solution Explorer open in the same window (same as opening in the active/current window)
If Solution Explorer is not docked to a window, items opened using Solution Explorer open in the "first" window
Document/text child windows can be dragged between Visual Studio windows
Add commands/context menu items for "Move to Visual Studio Window #2", etc.
Once a new Visual Studio MDI window is opened, the title of each window becomes numbered (Project - Microsoft Visual Studio - 2).
Each Visual Studio MDI window appears in the task bar independently Thanks!
Anonymous
August 23, 2008
Multi monitor in Visual Studio 10Anonymous
August 28, 2008
I haven't gone through the entire thread just yet. I think it would be nice to have the ability to add secondary Visual Studio parent windows. Then you could move and dock other screens from one parent window to another. A user with multiple monitors could put a parent window per monitor and arrange their documents and various other windows however they want. Another option would be to drop the main window all together and allow for windows to exist by themselves. The windows should be capable of being grouped. This includes the main menu bar. A user could group their toolbars and source code, while being able to move a single document out of the group to another monitor. Each group of windows should show up on the task bar for easy access. I suppose this would be similiar to SDI mode in Visual Basic 6. Being able to group windows with tabs to move between windows in a group would be an improvement on that design. I can't say I'm a veteran programmer but I thought I'd put out my ideas.Anonymous
September 08, 2008
The comment has been removedAnonymous
September 10, 2008
The comment has been removedAnonymous
September 10, 2008
The comment has been removedAnonymous
October 21, 2008
Better Multimonitor support? I have been utilizing a 4 monitor development system for over two year. Many developers at work have multiple 2 or more monitors. It seems multimonitor support has been going in the wrong direction. Things were fine in 2005 and 2008 degraded. and now 2008sp1 has down right P1 bugs. Yes please get this stuff working again.. cause I like pixels and multiple monitors are the fastest way to more pixels. Honestly, I dont worry about tabs or docking.. just setup most of your views into floating and then drag them to the other monitor.. you can then attach other windows to them.. I have a floating window on each monitor with multiple things attached to it.. ChristopherAnonymous
October 22, 2008
Dreamweaver has had multi monitor support and customizable windows layout since 2003.Anonymous
October 22, 2008
The comment has been removedAnonymous
February 25, 2009
Hi thanks for taking our comments! I would love to see VS support multiple monitors. Personally, I would like to see all the code on one monitor and my solution explorer / tools / properties / output / test results / compile errors and so on in another (or multiple other) windows. If I am editing XAML or something else that has a graphical representation then I would like to see the code I'm editing in one window and the graphic in another window. In a related note I often have two Solution windows open at a time because I write our generator code (using C# to generate C#). It would be nice if in this multiple window world I could have one set of Solution Explorer / tools / etc (see list above) that update as I switch from solution to solution. Again ThanksAnonymous
May 16, 2009
The comment has been removed