Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PT Run] Helper for Execute Shells Process Calls #9538

Merged
merged 1 commit into from Feb 23, 2021

Conversation

davidegiacometti
Copy link
Collaborator

Summary of the Pull Request

What is this about:
Common helper for execute shell across PT Run plugins.

What is include in the PR:
Removed most of the Process.Start used for invoking shell across PT Run plugins.
Still have 2 hardcorded explorer.exe in folder and indexer plugin used to focus the file when explorer is opened #7339 (comment)

How does someone test / validate:

  • Folder plugin
    • Open file
    • Open folder
    • Open containing folder
  • Indexer plugin
    • Open containing folder
    • Click on index warning
    • Open file
  • Program plugin
    • Open containing folder UWP app
    • Open containing folder Win32 app
  • URI plugin
    • Open an URI
  • Registry plugin
    • Open registry
  • Service plugin
    • Open services.msc
  • System plugin
    • Shutdown
    • Reboot
  • Report Window
    • Open GitHub URL

Quality Checklist

Contributor License Agreement (CLA)

A CLA must be signed. If not, go over here and sign the CLA.

Log.Exception($"Unable to launch Windows Search Settings: {ex.Message}", ex, GetType());
}

Helper.OpenInShell("ms-settings:cortana-windowssearch");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some cases the returned value of Helper.OpenInShell is not checked and no error is shown.
I haven't check all the places where this is done, consider verifying why is not done and in case add a comment motivating why the error is not shown to the user.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some plugins are checking the result and display a MessageBox.
Should we always display it in case of error? We can consider move the MessageBox inside Helper.OpenInShell.

@enricogior
Copy link
Contributor

@davidegiacometti
thank you for the nice code clean up!

@enricogior enricogior added the Product-PowerToys Run Improved app launch PT Run (Win+R) Window label Feb 8, 2021
@htcfreek
Copy link
Collaborator

htcfreek commented Feb 8, 2021

@davidegiacometti
Is it possible to use third party explorer apps with this helper?
I know we have/had an issue for this and possibly merged a PR to address this in the past.

@davidegiacometti
Copy link
Collaborator Author

@davidegiacometti
Is it possible to use third party explorer apps with this helper?
I know we have/had an issue for this and possibly merged a PR to address this in the past.

Yes, It was already possible but in Program and Indexer plugin are invoking explorer.exe /select for "open containing folder". #7339 (comment)

@@ -71,6 +71,7 @@

<ItemGroup>
<ProjectReference Include="..\..\Wox.Plugin\Wox.Plugin.csproj" />
<ProjectReference Include="..\..\Wox.Infrastructure\Wox.Infrastructure.csproj" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something to ponder about. It feels like plugins should be independent and reference to Wox.Infrastructure violates it. It is okay to have reference to a project that contains plugin interface. What do you think? Does it make sense?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh.. I missed this! Almost all plugin are referencing Wox.Infrastructure. Consider also that ISavable and PluginJsonStorage are in Wox.Infrastructure. Could be a refactoring. Should I open an issue?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can open a separate issue for that and discuss the pros and cons there. It is definitely a low-priority one.

Copy link
Contributor

@mykhailopylyp mykhailopylyp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@davidegiacometti
Copy link
Collaborator Author

List of places where result isn't checked and user isn't notified in case of error:

  • Indexer: open ms-settings:cortana-windowssearch
  • Registry: open regedit.exe
  • Services: open services.msc
  • System: open shudown
  • Report Window: open GitHub
  • URI: open URI
  • Program: open folder

@enricogior any thoughts on this? I think that URI and Program should display a message in case of error.
We can consider moving the MessageBox in Helper.OpenInShell and always display the error.

@htcfreek
Copy link
Collaborator

htcfreek commented Feb 15, 2021

List of places where result isn't checked and user isn't notified in case of error:

  • Indexer: open ms-settings:cortana-windowssearch
  • Registry: open regedit.exe
  • Services: open services.msc
  • System: open shudown
  • Report Window: open GitHub
  • URI: open URI
  • Program: open folder

@enricogior any thoughts on this? I think that URI and Program should display a message in case of error.
We can consider moving the MessageBox in Helper.OpenInShell and always display the error.

What about creating a unified ui (I suggest toast notification) for error/additional info messages by creating a new common helper class for info and error messages?

Possible messages:

  • Error on opening uri in browser.
  • Error on stopping service "name"!
  • The service "name" has started successful.

@enricogior
Copy link
Contributor

@davidegiacometti @htcfreek
we should show the error in the least intrusive way and not a toast notifications (we had so many problems with toast notifications that at this point we should avoid them all together). If we can show the error before closing the search box, we may consider showing the error as we do for the warning that tells the user that not all drives are indexed. Otherwise we show an error dialog.

@htcfreek
Copy link
Collaborator

@davidegiacometti @htcfreek
we should show the error in the least intrusive way and not a toast notifications (we had so many problems with toast notifications that at this point we should avoid them all together). If we can show the error before closing the search box, we may consider showing the error as we do for the warning that tells the user that not all drives are indexed. Otherwise we show an error dialog.

Then we should fix the bug that warning messages like DriveIndexWarning aren't shown as first result. (Don't know the issue at the moment.)

@davidegiacometti
Copy link
Collaborator Author

We should be fine with dialogs at the moment.
I think shutdown, regedit or services.msc not working is remote but possible with a messed path or Windows installation.
Should I move the error dialog inside Helper.OpenInShell?

@enricogior
Copy link
Contributor

@davidegiacometti

Should I move the error dialog inside Helper.OpenInShell?

I let you make the call since you have a better understanding of the code.
Beside that, is there anything else that still need to be done for this PR or can we proceed with the final review?

@davidegiacometti
Copy link
Collaborator Author

@enricogior PR is ready for review.
I have added error handling for URI plugin since user can search for any URL.
Should't be a problem for other plugins since it hasn't been reported yet ans since result wasn't checked before this refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Product-PowerToys Run Improved app launch PT Run (Win+R) Window
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants