Winding down


I’m feeling such low energy right now.  It might be because I’m awake at 4 am after only a few hours sleep, but part of me thinks it’s indicative of what work is like right now.  The end is nigh!  Our goal is in sight, and we’re pretty strict about staying on course and getting VS wrapped up and ready to ship.  Of course, this means we don’t want to be adding radically new features or doing other risky things.  Instead, we want to take what we have and make sure it all works together as you’d expect.  It’s necessary, but as I’m learning, the last 5% seem to be the hardest.  I think it’s just my nature to want to keep working on the new things and not being able to an make you a little stir crazy.  I can do it in my spare time, however, there doesn’t seem to be much of that since there is *plenty* of work right now.


On a good note, we’ve gotten an amazing amount of feedback from the blogs and ladybug.  Because of that we’ve found ourselves making different decisions as to how to allocate resources and to what we should be doing before we ship.  Of the 3 groups I work with (the editor, the compiler and the debugger), the editor is getting the most feedback.  That makes sense to me (although my logic might be totally off).  The compiler is a rather simple tool in the minds of most user.  It’s just a single application that just takes a set of files and produces a library or executable.  For the most part people want it to just do that and nothing much more, and as long as it has good error messages they’re happy.  I think that the debugger doesn’t get hit a lot because people trying out the beta aren’t necessarily using it for large real world tasks, but rather are just playing around with it and so aren’t really living in the debugger and finding issues with it.  Or, alternatively, they’re like me and generally don’t use the debugger 🙂


However, the editor is a different experience.  For many people it’s the primary interface to the IDE and where they spend the most time.  It’s also something that is very “in your face.”  From colorization to our entire interaction model.  If we get anything wrong it’s always almost immediately obvious (and *annoying*) to the user.  The editor is also an area that could be vastly improved over our current offering.  The amount of useful feedback that we don’t give the user is somewhat disappointing and I know it’s an area that we’ll be working hard on in the future.  It’s silly that you *have* to manually invoke a compile to get warning and errors.  I’m unfortunate how many places where intellisense breaks down, or doesn’t provide useful information (like what operators are valid at this location in the code).  A lot is due to our architectural heritage, and a lot is due to the areas we really focused on for this release (like generics and refactorings).


Fortunately, this means that when we do the next version there will be a lot that we can do to make things better.  What really interests me would be to provide a more extensible intellisense/editor model in the future.  You don’t like how intellisense works, or want to see it behaving differently?  Fine, write your own plug-in (or extend ours) and use that instead.  However, I’ve never written an architecture like that so there will certainly be a lot of learning going on at the same time.  When we get to that, I think talking to the community will be absolutely necessary in order to get this right.  After all, how do we give people an extensible model that will serve their needs unless we know what their needs are?  It’s also my perception that people are (rightly) expecting a lot out of IDEs.  The amazing work done across the board by companies like Borland, IBM, Sun and Jetbrains show how drastically the quality and feature set of an IDE can affect ones performance.  Traditionally I think that MS has provided that through a strong integrated experience with some extensibility points for other ISVs to come in and enhance the experience.  In the future I see us shifting balance and working hard on the core services but having them designed with much stronger extensibility in mind so that the community can integrate with ease and can provide more value than today.  This would allow us to release a strong platform with major advancements across the board, and to then provide incremental improvements over time ourselves or through ISVs


It’s also going ot be interesting figuring out what the right path forward is for us with our current code base.  We want to code in C# (yes, we’re incredibly biased), but we have a very large legacy C++ code base.  There are lots of options available as to how to make the transition, but looking forward it’s not clear at all which path we should take.


Well, I’m suddenly all excited thinking about this.  Now it’s just a matter of how do i balance the need to work on getting 2005 done, and the want to start working on VS.NextXPExtremeUltraSuperEdition. 


Comments (13)

  1. marklam says:

    A major improvement in the IDE as far as I’m concerned would be to have the old (VC6 and earlier) find-in-files dialog back!

    Maybe I’m biased, but I can’t stress enough the enough stress that folder picker causes me.

  2. drebin says:

    As a general rule, you guys are absolutely, positively heading in the right direction.. every new release has been a huge leap forward.. most things are intuitive and where I’d expect them to be.. keep it up!!

  3. Ivo says:

    I also prefer the Find dialog from VC6 and earlier. In .Net it is modeless and loses focus very easily. Press Ctrl+F, type something, press F3 (or Shift+F3) and it loses focus. So I’m left with this dialog box in the middle of my IDE, and the only way to close it is to press Ctrl+F again and then Esc (or reach for the mouse).

    Another pet peeve of mine is that some useful commands are gone from the editor – go to the beginning of the line, jump between #if and #endif, <Esc> to close the Output window, etc.

  4. Ivo: Personally, I prefer the modeless form of the find dialog. It allows me to always have find open so that I can be searching all the time. What I would really like to see would be an XCode type search mode that was always available and always instantaneous.

  5. Ben Donley says:

    Do you guys eat dogfood for source control? If so, which dogfood?

    I guess you might have mentioned this before.

    I’m just curious.

    No big deal.

    Right.

    Later.

  6. Ivo says:

    I can see the modeless dialog being helpful only if you use the mouse. If I want to use only the keyboard, I have to press Ctrl+F to get to the dialog no matter if it is opened or closed. One solution would be to have a pin button (like the VC6 properties), to toggle between modeless and modal style to accomodate keyboard and mouse users.

  7. Ivo: Why? I often open the find dialog and then go back to the main editor pane to copy some text to then put into the dialog. Having it be modal would drive me nuts. However, I could see someone wanting it to switch "always-on-top" or not.

    Have you tried dragging it to another monitor, or docking it with the other tool windows?

  8. Ivo: Why? I often open the find dialog and then go back to the main editor pane to copy some text to then put into the dialog. Having it be modal would drive me nuts. However, I could see someone wanting it to switch "always-on-top" or not.

    Have you tried dragging it to another monitor, or docking it with the other tool windows?

  9. Ivo says:

    I don’t think I understand. If you go to the main editor and select some text then Ctrl+F will put it into the dialog (no matter if it is open or closed). Unless you start searching for some text and then change your mind and want to search for something different. Anyway, Ctrl+C, then mouse click in the dialog, then Ctrl+V is more inefficient than just Ctrl+F.

    I usually have only the solution explorer and the resource view open and docked to the side. The find dialog will not fit there. Docking it to the bottom and setting it to auto-hide also has its problems:

    When I press Ctrl+F the text to find is not selected, so I can’t start typing the new thing to search for (I believe that’s simply a bug)

    Pressing F3 switches focus to the main window, but doesn’t close the dialog immediately

    I can’t reliably reproduce this, but sometimes after F3 the find dialog doesn’t close at all when the main window gets the focus

    And also the find dialog looks best when it is in its default size. Docking it to the frame just wastes too much space

  10. Ivo: Can you open a bug on those issues at ladybug (http://msdn.microsoft.com/productfeedback) so that hopefully they’ll be fixed before shipping. Thanks!

  11. Ivo says:

    Today I tried VS 2005 Beta and the Find dialog is even worse! MUCH WORSE.

    1) When it is floating. I press Ctrl+F, type some text, press Enter, and start typing, assuming that I’ll replace the text that was just found. But the Find dialog keeps the focus! So I’m typing the new text to find instead… Pressing F3 does switch focus to the main window, but doesn’t close the dialog. So it has the worst of both worlds. I can’t start replacing the found text after Enter, and the dialog stays open, even if it loses focus. Enter and F3 both find the next occurrence, but leave different window as active. It is really confusing. The fact that in XP visual themes the difference between active and inactive dialog caption is just a few shades of blue (or gray) doesn’t help a bit.

    2) When it is docked. I press Ctrl+F, type some text, press Enter. The find window seems to lose focus (its title becomes inactive), but the editbox still has the blinking cursor. If I type some text it appears in the find window. If I press Enter it is captured by the main document and inserts a blank line (replacing the previously found text).

    3) When it is set to auto-hide. Same problems as #2, combined with the bug that the text to find doesn’t get selected, so I have to press Ctrl+A before I start typing a new text.

    4) If I select a whole line of text in the main window (from the very first to the very last character) and press Ctrl+F it doesn’t replace the text in the Find dialog. Instead, it shows the last thing I was searching for.

    Please, please, please fix it… I admit, I have a hard time changing my habits, and "Ctrl+F, type text, Enter, type text to replace it" is a very basic habit of mine. And I am really bothered by the Find dialog not closing itself when I’m done with it. But even regardless, I fail to see how the VS 2003 dialog is any better than the VC6 one. And how the 2005 version is better than 2003. I can’t think of ANY use case that you are trying to optimize with these changes. Everything I’m doing requires more keystrokes and/or mouse clicks to do than in VC6. The Find dialog is used very often, and the user is usually writting code when he needs it. So it should be optimized to work with least keystrokes and no mouse. Also I need the dialog to be visible only when I’m typing text into it. Once I’m done with entering the text, it should better go away.

    Here’s what I’m suggesting. Fix the bugs in #2, #3, #4. These are definitely bugs and not "features". Add a "pin" button to the floating dialog (set it to ON by default if you want). If the pin is down, use the current behavior (or the 2003, which I think is more consistent). If the pin is up, make it work as in VC6 – I press Enter, the dialog hides and finds the first occurrence, I press F3, it finds the next one.

  12. Ivo: Please open these bugs 🙂

    That puts them on record and will allow others to vote for them to have a better chance of getting fixed. I don’t work on the Find Dialog, and I know those that do are looking for this feedback to know what to fix.

    I’m going to send a message to the team that works on this, but opening bugs is a definite so that these will get addressed and won’t get missed before shipping.

Skip to main content