[scm] open 'diff-editors' with a single-click

[vince-fugnitto]

What it does

Fixes #6479

• updated the opening of diff-editors through the scm widget to respect the preference workbench.list.openMode. The following preference describes two possible values singleClick and doubleClick. When singleClick is enabled, clicking the change in the scm widget opens the diff-editor directly while doubleClick preference requires two clicks.
• renamed the preference list.openMode to workbench.list.openMode.

How to test

• start the application using a workspace under Git version control
• verify the behavior of opening diff-editor changes with the preference:
  • "workbench.list.openMode": "singleClick" - diff-editor is opened with one click
  • "workbench.list.openMode": "doubleClick" - diff-editor is opened with two clicks

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: vince-fugnitto [email protected]

[akosyakov]

It looks like:

• single click should open a first change
• double click just opens

I'm not sure, we need to get a version before the scm extension and see how the git widget used to work, then fix that it works like a before. I think it got broken during this refactoring.

[vince-fugnitto]

@akosyakov I've verified by building a v0.6.0 Theia application (pre-scm) and the single-click still does not add much value. When single-clicking, the node is selected only, while double-clicking the node is opened as a diff-editor. I'm wondering what the added value is of having the pre-existing behavior for the single-click or if we should go towards VS Code and open the diff-editor with a single-click like this PR does.

[akosyakov]

@vince-fugnitto agree that we should go VS Code.

I've verified by building a v0.6.0 Theia application (pre-scm) and the single-click still does not add much value.

From code it looked that we used to open a diff-editor and select the first change. Maybe it was broken there as well. Anyway let's do as in VS Code.

[vince-fugnitto]

@vince-fugnitto agree that we should go VS Code.

Okay sounds great, please let me know if anything needs to be adjusted in the pull request.

[akosyakov]

I've just tested with VS Code and it actually based on

theia/packages/core/src/browser/core-preferences.ts

Line 23 in 92c66ba

'list.openMode': {

It also seems that this preference was renamed to workbench.list.openMode in VS Code. We should align it.

[vince-fugnitto]

I've just tested with VS Code and it actually based on

theia/packages/core/src/browser/core-preferences.ts

Line 23 in 92c66ba

'list.openMode': {

It also seems that this preference was renamed to workbench.list.openMode in VS Code. We should align it.

Ahh I see. I might be mistaken but I thought perhaps that preference was more useful for them since they now support the scm widget as a tree while we do not at the moment.

[akosyakov]

Ahh I see. I might be mistaken but I thought perhaps that preference was more useful for them since they now support the scm widget as a tree while we do not at the moment.

How it is implemented does not matter from user perspective, does it? btw it was always a tree in VS Code.

[vince-fugnitto]

Ahh I see. I might be mistaken but I thought perhaps that preference was more useful for them since they now support the scm widget as a tree while we do not at the moment.

How it is implemented does not matter from user perspective, does it? btw it was always a tree in VS Code.

Yes exactly it shouldn't matter from a user's perspective.
I see, we should most likely align as well with having a tree as well, or the option to have a tree.

[akosyakov]

I see, we should most likely align as well with having a tree as well, or the option to have a tree.

I meant for now:

• renaming list.openMode preference to workbench.list.openMode
• use it onClick and onDoubleClick handlers to decide whether they should open

[vince-fugnitto]

I see, we should most likely align as well with having a tree as well, or the option to have a tree.

I meant for now:

• renaming list.openMode preference to workbench.list.openMode
• use it onClick and onDoubleClick handlers to decide whether they should open

Sounds good, I was just wondering if it is possible to inject the corePreferences into a React component which is not injected itself. I assume I will need to pass along the value as a prop.

[vince-fugnitto]

I see, we should most likely align as well with having a tree as well, or the option to have a tree.

I meant for now:

• renaming list.openMode preference to workbench.list.openMode
• use it onClick and onDoubleClick handlers to decide whether they should open

I've updated the PR based on your suggestion :)

[akosyakov]

@vince-fugnitto Please test that when you click (regardless in which mode), a resource is selected.

[vince-fugnitto]

@akosyakov please let me know if everything has been addressed whenever you get a chance :)

[akosyakov]

works nicely now! thank you

[vince-fugnitto]

works nicely now! thank you

Thank you for your help in making it better :)