Why are there multiple horizontal bars at both the top and bottom of the full-screen display when the single most important activity in the app is scanning very long text files often dozens of times "higher" than the screen. Seriously, every line of text is precious, why must we steal them from the editor with a title bar and a menu bar and a tool bar (thankfully they now have only one toolbar) and a tab bar and a status bar. Why does anyone think this is a good design?
Qt Creator is currently my favourite IDE to develop C++ in (even if it does not use Qt) and it doesn't look like this.
For reference, my emacs window has the gnome 3 panel and the window manager title bar as waste and that's it. And for years I ran a custom metacity theme which turned off the title bars entirely (haven't managed to port that to gnome shell yet).
On the other hand, to my eyes at least, most other IDE's look something like this [6], [7] or very very extreme cases [8]. That is, they lose a lot of vertical space to tool bars.
When I'm developing on Linux and I'm not developing a Qt GUI application in C++, I use a mixture of text-mode vim, geany and gedit in a tiling window manager (that is, the "dock windows" in most IDEs are windows that I have tiled, or vim panels) with no window borders or decorations whatsoever [9].
[1] http://upload.wikimedia.org/wikipedia/commons/4/4d/QtCreator...
[2] http://www.developer.nokia.com/Resources/Library/Porting_to_...
[3] http://linux.leunen.com/wp-content/uploads/2009/03/qtcreator...
[4] http://lists.qt.nokia.com/pipermail/qt-creator/attachments/2...
[5] http://4.bp.blogspot.com/-teVIBJ45OEU/Twbi9_wQd_I/AAAAAAAAAY...
[6] http://www.eclipse.org/screenshots/images/SDK-RedFlag_Linux....
[7] http://www.hanselman.com/blog/content/binary/WindowsLiveWrit...
[8] http://swtswing.sourceforge.net/screenshots/images/EclipseMe...
[9] Not my screenshot, but similar: http://static.milkbox.net/ss/ss-2009-05-06.png
So, most of the time I'm using Qt Creator, some of the time I use geany and the rest I use vim. I probably sholdn't have mentioned gedit as I really don't use it often. I'm planning on dumping geany in favour of vim next time I have to set up my development environment (basically when I get a new laptop, hopefully real soon) as I've been meaning to practice my vim skills for a while now. I was real good at it a few years ago, but then I got a little rusty, which is why I ended up using geany for python and plain text instead...
Actually, to be completely accurate, I use MPLAB too ;) I use it exclusively to program C for the PIC24 microcontrollers. I also used Notepad++ for AVR development a few months ago - if I had been developing on linux, I would have used vim, but I really dislike gvim, so do not use it on windows. I use MPLAB for PIC development because it integrates with the hardware programmer, the remote debugger and saves having to set up paths for a gcc thats not compatible with the one I use for desktop C++ development (though I plan on switching to clang, so I won't have any gcc clashes anymore then).
It's basically impossible to find even the easiest of IDE functions in that mess. One of the purported advantages of GUIs is the discoverability of the interface. When I have to visually search through hundreds of UI elements to find what I need, that is all lost.
The monolithic IDE concept really needs a fresh breath of air. I do like the fact that they come with a lot of integrated tools for a programming environment, but they shouldn't clutter the UI because of it. Ideally I think an IDE would start off looking mostly like a text editor and give you clearly delineated views of different activities once you need them.
Windows in VS10 behave oddly in general around alt-tab and other things, I haven't managed to form a mental model of how/why they do.
One of the really nice things about pair programming is the number of times I've started hunting through a menu for an option and the other dev will say "Oh, just hit <chord>".
If you spend a great deal of time in ANY application you owe it to yourself to take one day a month and force yourself to use it without ever clicking a menu or icon. You'll be delighted at how much more productive you'll be.
In VS 11 we have transitioned to glyph style iconography throughout the product. While we understand that opinions on this new style of iconography may vary, an icon recognition study conducted with 76 participants, 40 existing and 36 new VS users, showed no negative effect in icon recognition rates for either group due to the glyph style transition. In the case of the new VS users they were able to successfully identify the new VS 11 icons faster than the VS 2010 icons (i.e., given a command, users were faster at pointing to the icon representing that command). In this and subsequent studies more developers have expressed a preference for the glyph style icons over the former style, especially after having spent time getting used to the new glyph style icons.
Furthermore...76 participants? That doesn't prove anything.
I don't use either, and I think the 2011 are easier and faster to recognize.
(I do compile with VS, but edit my files in SublimeText)