file-seach: improve handling of command

[vince-fugnitto]

What it does

Fixes #7844

This pull-request contributes the following items:

• introduces the workspaceState when context which can ultimately be used by new commands
• improves the handling of the quick-file open:
  • enables the command in all cases (even when no workspace is opened)
  • adds proper handling when no results are found (No matching results)

How to test

1. start the application without a workspace opened
2. execute the file-search command (ctrlcmd+p)
3. the quick-file-open should be properly displayed
4. searching for results will yield the No matching results item
5. open a workspace
6. execute the file-search command (ctrlcmd+p)
7. searching should yield results in the quick-file open
8. search for a random string (ex: adsaasdadsadad) it should yield the No matching results item

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 vincent.fugnitto@ericsson.com

[lmcbout]

Somewhere in the issue, it should stipulate this is for ELECTRON only, not for the browser. If there is no workspace and I do (CTRL + P) in the browser, there is a command attach to it.(Print)

Works as expected BUT if I open the command and remove the ">", it says in the quick open bar "File name to search" , but it is looking inside the workspace and if there is no workspace, it does nothing. (As an end-user, I expect something here) Should we allow to have the quick open search box available in this case?

Second, If I open a file (CTRL + O) with no workspace, it opens the file and then the command (CTRL+P) it opens the quick search , but still, cannot return any files to open.

[lmcbout]

So if not exclusive to ELECTRON, then it does not work properly since the command ( CTRL + P) in a CHROME browser, it tries to print, not opening the quick open file selection

[vince-fugnitto]

So if not exclusive to ELECTRON, then it does not work properly since the command ( CTRL + P) in a CHROME browser, it tries to print, not opening the quick open file selection

@lmcbout the command should not be present without a workspace present (which is the case).
The ctrl+p is a reserved keybinding (ex: chrome) if no command is present.

[vince-fugnitto]

@akosyakov what should the behavior be when we are in the browser and no command is available which uses the browser's print keybinding? At the moment (after these changes), the print dialog from the browser will be prompted to end-users.

[akosyakov]

@vince-fugnitto VS Code shows the quick find always, so no fix? introducing a new context key is nice anyway

[vince-fugnitto]

@vince-fugnitto VS Code shows the quick find always, so no fix? introducing a new context key is nice anyway

I can align to show the context-menu.
The issue of displaying the browser's print will still occur for applications which are not using the file-search however, so I was wondering if there was anything we should do about it.

[akosyakov]

I can align to show the context-menu.

@vince-fugnitto Not sure what you mean. In VS Code they always show the quick search, we should do the same, just fix the error in console. If we show it always then there is no print.

[vince-fugnitto]

I can align to show the context-menu.

@vince-fugnitto Not sure what you mean. In VS Code they always show the quick search, we should do the same, just fix the error in console. If we show it always then there is no print.

Yes I’m currently working on it.
What I meant was that it an application does not include @theia/file-search as an extension then using the ctrlcmd+p keybinding will result in the browser’s print window. I’m asking if in a separate pull-request we should override this behaviour (ex: in core) so the print dialog is not shown.

[akosyakov]

What I meant was that it an application does not include @theia/file-search as an extension then using the ctrlcmd+p keybinding will result in the browser’s print window.

Let's wait for issues from adopters about it. We don't need to fix each possible combination if it never used.

[vince-fugnitto]

@lmcbout do you mind retrying the pull-request?

[lmcbout]

@vince-fugnitto will do in a few minutes.

[lmcbout]

Tested on UBUNtu 18.04
Tested on electron, Firefox and Chrome
When there is no workspace, the "CTRLCMD+P"now open the quick open menu and works as expected
Note: may be on this PR or on another PR: If we use "CTRLCMD+P", -> open the quick view, then I enter the whole path for the file, we should allow to open that file even if there is no workspace.
i.e. "CTRLCMD+P" then enter "/home/lmcbout/.bashrc" (I am on UBUNTU, so this file exist for me), the file should open in the editor

[vince-fugnitto]

Note: may be on this PR or on another PR: If we use "CTRLCMD+P", -> open the quick view, then I enter the whole path for the file, we should allow to open that file even if there is no workspace.
i.e. "CTRLCMD+P" then enter "/home/lmcbout/.bashrc" (I am on UBUNTU, so this file exist for me), the file should open in the editor

@lmcbout this is not the purpose of the quick-file open (it does not search for files outside the workspace nor does it open files on the filesystem by path). This behavior also does not align with vscode so I am not for adding it.

[lmcbout]

@lmcbout this is not the purpose of the quick-file open (it does not search for files outside the workspace nor does it open files on the filesystem by path). This behavior also does not align with vscode so I am not for adding it.

Just did a quick test on VSCODE and the file opens, so I guess it would be aligned with VSCODE 👍

[vince-fugnitto]

@lmcbout this is not the purpose of the quick-file open (it does not search for files outside the workspace nor does it open files on the filesystem by path). This behavior also does not align with vscode so I am not for adding it.

Just did a quick test on VSCODE and the file opens, so I guess it would be aligned with VSCODE 👍

Not in this pull-request.

[akosyakov]

have not tried, but code changes look good