We need a setting to define the what double clicking project does

sharwell commented 5 years ago

Version: 16.0 Preview 2

Steps to reproduce:

Open a solution with a CPS-based C# project
Double click to expand the project in Solution Explorer.

Expected results:

The project expands in Solution Explorer.

Actual results:

The project does not expand in Solution Explorer, and instead the project opens.

📝 I was aware of the behavior change but avoided filing this issue until I actually hit it by accident. It happened within 5 minutes of installing Preview 2.

davidwengier commented 5 years ago

Thanks for the feedback! Part of our rationale for shipping this feature, and the rest of project file editing improvements, in a preview release was to gauge the response from our users before the final release. Please keep us updated if your opinion changes at all as you use the preview more and potentially get used to the new experience.

Out of curiosity do you have the "Allow new files to be opened in the preview tab" turned on, and if so do you find that experience with the project file a positive or negative one?

sharwell commented 5 years ago

Out of curiosity do you have the "Allow new files to be opened in the preview tab" turned on, and if so do you find that experience with the project file a positive or negative one?

That was weird but not disruptive. Double clicking was the problematic case, especially in a solution where projects are nested in solution folders (double clicking the folders expands them but then things break when you get to the project).

sharwell commented 5 years ago

I believe the Regression label is accurate regardless of the resolution of the issue. This behavior works in Visual Studio 2005, 2008, 2010, 2012, 2013, 2015, 2017, and 2019 Preview 1.1. It broke in Visual Studio 2019 Preview 2, which is a clear behavior regression relative to the preceding 8 versions.

cartermp commented 5 years ago

Not sure if we have a label for this, but I think the classification would be "Intentional behavior change", since regression indicates something is unexpected. We mention it in two places:

.NET Blog post - where we'll plan to post again at RTW
Release notes

Our aim here is to collect feedback wherever possible - GitHub, Blog comments, Twitter, DevCom - and make a call based on that feedback.

davkean commented 5 years ago

@333fred You had similar feedback, can you +1 above?

333fred commented 5 years ago

Done. I still get frustrated with this several times per week.

srivatsn commented 5 years ago

I find that this disrupts my flow as well. It'll be good to make sure there's an option to change the behavior at least.

davkean commented 5 years ago

@srivatsn Do you mind following up in a week and see if you feel the same way? I found it disrupted too first few times too. Sounds like it still disrupts Fred's usage though.

sharwell commented 5 years ago

I'm still hitting this.

jjmew commented 5 years ago

This issue will track the work for adding a setting to change the behavior of double clicking.

jjmew commented 5 years ago

Updated the title to reflect what we are tracking

srivatsn commented 5 years ago

@srivatsn Do you mind following up in a week and see if you feel the same way?

A week later - still end up double-clicking expecting to open the node.

sharwell commented 5 years ago

Same here

davkean commented 5 years ago

We're looking at exposing an option that will revert to the previous behavior.

ghost commented 5 years ago

Same for me, annoying change.

davidwengier commented 5 years ago

A quick status update: Preliminary work has been completed to add an option to disable the double-click behaviour, we are waiting on the UX review process to confirm exactly where the option should go, and as a consequence how it should work.

davidwengier commented 5 years ago

Internal PR for the functionality: https://devdiv.visualstudio.com/DevDiv/_git/CPS/pullrequest/161623 Internal PR for the option UI (pending review): https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/163306

Tamer-Gamal commented 5 years ago

Is there any update on this request ? we need the option to disable this feature.

eismue commented 5 years ago

Please remove this 'feature', it is absolutely annoying as it interrupts the workflow. For at least 15 years we have been working in such a way that a double click on the project expands it in the Solution Explorer. Now the project file opens for editing. Question: what is probably done more often: extending a project to navigate to the particular files, or manually editing the project file? I clearly think the first one. Please make this at least configurable. The behaviour is absolutely horrible at the moment...

kovachev commented 5 years ago

How often do you edit project files manually? Most probably do it once, yes once, in 6 months. But how often do you expand/collapse projects? Hundreds of times a day?

Here's another "great" idea for the next update - why don't you make double clicking on a folder to open it in explorer, some weird mind might find that behavior useful.

davkean commented 5 years ago

This option is on the cards for 16.1.

This is a reminder to be respectful on this forum, we are all humans here. Please keep the comments constructive.

eismue commented 5 years ago

I'm glad to hear that. Thank you for this information.

stefankip commented 5 years ago

Like I mentioned in https://github.com/dotnet/project-system/issues/1224#issuecomment-477967677, I run into this 'issue' several times per hour.

f135ta commented 5 years ago

Thanks for adding this feature... Its hideous and thoroughly annoying ;-)

davidwengier commented 5 years ago

Internal PRs have been merged, option will appear in 16.1.

effyteva commented 5 years ago

Any estimated release date for 16.1 already? :) This is indeed a very annoying "feature"

cartermp commented 5 years ago

@effyteva There is no estimated release date for 16.1 at this time.

LeroyK commented 5 years ago

Any way to disable this workflow killer without having to wait for 16.1? Perhaps using an extension?

stijnherreman commented 5 years ago

I honestly don't understand why you wait until 16.1 to make this new behaviour optional, it should have been optional from the get-go. What were you hoping to achieve by asking people to try and get used to it, what do you have to gain from it?

The change doesn't even make sense to me. Expanding/collapsing a project node is an action I frequently perform, especially combined with the 'Collapse All' button, while editing a project file is rarely done.

@davkean with all due respect, it's my first day using VS 2019 and I already wanted to smash my mouse on the desk because of this.

stefankip commented 5 years ago

I’m staying with 2017 because of this...

bording commented 5 years ago

To be a contrary opinion here, I love the new feature! I never double click on Solution Explorer items to expand/collapse them. I always use the arrows next to the item. Being able to easily get to the project file is wonderful.

Considering how important it is now to be able to edit project files in the new project system, I think it makes sense for this to be the default behavior.

effyteva commented 5 years ago

I’m staying with 2017 because of this...

After a day of using VS2019, I have to say, it works a bit slower on my ~80 projects solution, and this "feature" is really making me consider switching back. I'm always switching ASAP to newer versions, but this is really inconvenient...

aventus13 commented 5 years ago

I'm against this change as well and would like to know what was the rationale for making this change non-optional. As it's been mentioned above, developers much more often open projects rather than edit them. It is slowing me down as well because it is harder to hover the cursor over a collapse/expand caret button instead of simply double clicking the project.

TravisTroyer commented 5 years ago

Unless I'm forgetting some different behavior in an earlier version, I've been double-clicking these things for over 15 years now. That's a hard behavior to unlearn.

sagoo33 commented 5 years ago

This change has been very frustrating for me. I'm happy for the ability to Edit the project be on by default, but please make it a setting to revert to "legacy behaviour" to allow us to stay in dinosaur land.

domints commented 5 years ago

This change has been very frustrating for me. I'm happy for the ability to Edit the project be on by default, but please make it a setting to revert to "legacy behaviour" to allow us to stay in dinosaur land.

I wouldn't say legacy behaviour and dinosaur land. As far as I remember editing csproj required unloading the project and it was annoying. Being able to edit / view csproj contents without unloading it is great, but I'd rather keep that feature under the context menu (right click) than change how double-click works, as it worked that way for ages.

Tamer-Gamal commented 5 years ago

I downloaded the 16.1 version and i can't locate the option that turn this option off.

poke commented 5 years ago

@Tamer-Gamal You probably downloaded 16.0.1 which does not have this functionality. 16.1 is not available yet.

Tamer-Gamal commented 5 years ago

@Tamer-Gamal You probably downloaded 16.0.1 which does not have this functionality. 16.1 is not available yet.

Visual Studio Update

it says 16.1.0,check the attached image

Visual Studio 2019 Preview Release Notes

jjmew commented 5 years ago

@Tamer-Gamal You probably downloaded 16.0.1 which does not have this functionality. 16.1 is not available yet.

it says 16.1.0,check the attached image

Visual Studio 2019 Preview Release Notes

It won't be available until a future preview of 16.1

myesn commented 5 years ago

Visual Studio 2019 version 16.1 Preview 1 has been released, has the option to double-click the custom behavior of the project file?

LeroyK commented 5 years ago

Visual Studio 2019 16.1 Preview 2 finally allows you to change this behavior:

Tools => Options => Projects and Solutions => General => Uncheck "Open SDK-style project files with double-click or the Enter key"

maliming commented 5 years ago

Guess what? I have adapted to this. 😅

codematrix commented 5 years ago

I guess this will be coming soon. It is an odd behavior. I think a Ctrl + mouse double click would be great for opening up the project source file and the old default behavor leave as is - i.e. mouse double click.

drewnoakes commented 5 years ago

The option to control this in Visual Studio 16.1 (which is currently in preview):

To disable the new behaviour, uncheck this box.

jrt324 commented 5 years ago

Visual Studio 2019 16.0.3 doesn't exist the "Open SDK-style project files with double-click or the Enter key" option

stefankip commented 5 years ago

@jrt324 ..... it never appeared in the 16.0 releases so how could it disappear?!

BalintFarkas commented 5 years ago

Just installed the release version of VS2019 16.1, can confirm that the option is there and works as advertised.

By the way, the project file still opens in the editor, just like a code file does when you single-click on it, but the project itself also expands/closes. I really like this behavior, it allows for quick editing of the project file while also preserving the navigation experience.

aaubry commented 5 years ago

I've also tested this setting and it indeed expands the project, but still opens the project in the preview pane, which feels weird. I really want to only expand the project. How can I disable opening the project in the preview pane ?

stijnherreman commented 5 years ago

I don't really mind that the project opens in the preview tab, the most important was to re-enable the previous expand/collapse behaviour. Note that Alt+click to avoid the preview works here too, just Alt+double click on the project.

dotnet / project-system