Window tab management in Visual Studio

msbuild — Fri, 13 Apr 2007 20:35:00 GMT

Greetings MSBuilders!

The way in which Visual Studio inserts and drops document tabs arouses passions in some people - myself included. So much so that I’m going to post about it, even though it doesn’t have anything to do with MSBuild!

Currently, when a new tab is opened and there isn’t space to add it, we drop the right-most tabs until there is enough space. When a tab is activated - because you want to see it or type in it - it doesn't change location. Here's a common scenario: you're working on two or three files. You open a bunch more, perhaps for browsing, or because you were stepping through them in the debugger. You go back to your primary files, which have now moved further to the right, and edit a bit more. Debug or browse some more, more incidental files are opened. Repeat. Now go back to your primary files - hey, they were pushed off the side.

At this point, if you're like me, you fume because Visual Studio chose to hide one of the few tabs you really needed to stay visible. Perhaps you start to get into the habit of dragging tabs to the left periodically to stop them falling off. Now I have a 24" monitor and a 22" monitor side by side, that’s about 3000 horizontal pixels, the tabs move two feet to the right, and I'm moving my head left and right like I'm watching a game of tennis. Enough to make steam come out of my ears.

The team that owns tab management has ruminated over this, but it turns out to be tough to please everyone. To change how tabs are dropped, you have to consider - where does the tab that disappeared re-appear when other tabs are dropped to make room, or if VS is re-sized - where it was dropped, or on the left? As an example, here's one proposal discussed:

- The ordering “A” we already keep track of (created by opening files or the user dragging tabs around) continues to govern the order in which tabs are displayed, left to right.

- The ordering “B” in which tabs were activated now governs which tabs are visible.

The algorithm for drawing tabs becomes this:

- Walk down the list “B” of tabs until you’ve accumulated the most you can that will fit in the space available.

- Now draw these tabs left to right in the order of list “A”

This achieves the following advantages

- Enlarging and then reducing the window size gets back to the same set of tabs in the same ordering as before

- Single algorithm for drawing tabs for any reason: tabs are reordered, files are opened, or window is resized

- New tabs still open on the left, because they naturally enter at the top of list “B”

Unfortunately any changes of this size would have to be prototyped, and usability tested: it turned out they didn't have time for this in Orcas, the existing code is fragile, and there weren’t enough requests from customers to invest in it.

Now here comes the trick. There's a secret unsupported regkey to activate an old prototype that still lingers in the Visual Studio code. It works in both VS2005 and the upcoming Orcas. For VS2005, swap 9.0 for 8.0.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0]

"UseMRUDocOrdering"=dword:00000001

This changes just one thing, and it’s very simple. When a tab is activated, it jumps back to the left. Some people find this unbearable. Some people – myself and half the developers in my hallway – love it. No more head turning, no more dropping of the files you’re working in. Try it out – just remember, it’s unsupported and not guaranteed to continue to work - although I hope it does.

If you like it or want some other behavior, consider posting suggestions on https://connect.microsoft.com/VisualStudio, or better still, voting on existing suggestions, so the team responsible can see how popular they are and prioritize appropriately for the next version.

Have fun!

[ Author: Dan, MSBuild developer ]

MSBuild Team Blog : Visual Studio

Window tab management in Visual Studio