-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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 - Shell selection #28121
Pt run - Shell selection #28121
Conversation
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Visibility="{x:Bind Path=ShowCheckBox, Converter={StaticResource BoolToVisibilityConverter}}"/> | ||
<ComboBox | ||
Margin="56,0,0,0" | ||
Description="{x:Bind Path=DisplayDescription}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make sure that it is possible to go without description. Current it is optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its optional. Not used
@@ -418,12 +431,17 @@ public List<ContextMenuResult> LoadContextMenus(Result selectedResult) | |||
public void UpdateSettings(PowerLauncherPluginSettings settings) | |||
{ | |||
var leaveShellOpen = false; | |||
var shellOption = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the default before implementing this? I thought it was ShellExecute. We should keep the old default behavior as new default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -13,6 +13,7 @@ | |||
using System.Reflection; | |||
using System.Windows.Input; | |||
using ManagedCommon; | |||
using Microsoft.Plugin.Folder.Sources; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be here. One plugin should not depend on another
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
} | ||
|
||
public enum ExecutionShell | ||
{ | ||
[Description("Run command in Command Prompt (cmd.exe)")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are user-facing strings and have to be localized
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|
||
public bool ShowComboBox => _additionalOption.ComboBoxOptions != null && _additionalOption.ComboBoxOptions.Count > 0; | ||
|
||
public bool ShowCheckBox => ShowComboBox == false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this more flexible by supporting checkbox value (Value
) being not initialized (null
). Then we can show the checkboox if Value
is true or false.
This allows us to have three different settings combinations: DropDown, Checkbox, Checkbox&DropDown
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Value is bool and its non-nullable. So a new bool HideCheckBox added and used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't use bool?
(Nullable<bool>
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After thinking about this some time I am wondering if we it makes sense. 🤔 We have only one name and description and I think it's more common to have different names/descriptions for checkbox and drop-down. Maybe we should revert this change. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. We are saving data in JSON file. One combobox or checkbox only responsible for one field in that JSON file. Changes are reverted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this, I think it's not very flexible to adding new types in the future. Can we add a field that's a sort of enum for the type of option this is? Currently there's two option types we're using, a "BooleanCheckboxOption" type (which would be default, so we don't need to change current code and still support the third party plugins we currently do) and a "SelectionDropDownOption" type.
That way, in the future, someone can add a "SelectionDropDownWithCheckboxOption", if needed?
I imagine some TextBox fields might make sense in the future if people want to add in plugins that may take API keys, for example. (Not to add in this PR)
What do you think @htcfreek ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is the PR #25326 for adding a string type setting which I think we can close. I am waiting for this drop-down feature to merge before implementing the string setting.
In the other PR I mentioned the exact same idea with the enum. And it would make single type (string, checkbox, drop-down, ...) settings easier to implement. (Currently I have the idea to check for stringProperty != null
to decide if we should show the input box or not. And this requires a default value. At least explicit empty string. With a enum this quirk will be obsolete.) But for mixed settings we still have some complexity to implement: Multiple names and descriptions, disable input box/drop-down if checkbox is not checked and so one.
So I don't know if it makes sense to add so complex setting definitions. I mean you still can use two different PluginAdditionalOptions
for two settings. (E.g. option one for "Use ChatGPT Pro" and option two for "Enter api key".) What do you think about this point @jaimecbernardo ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's working well. Thank you! I left comments about changes that need to happen before this can go in.
@@ -418,12 +432,17 @@ public List<ContextMenuResult> LoadContextMenus(Result selectedResult) | |||
public void UpdateSettings(PowerLauncherPluginSettings settings) | |||
{ | |||
var leaveShellOpen = false; | |||
var shellOption = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this the default? cmd.exe was the default behavior before, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its default is 2 (Find executable file and run it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right :)
"Run command in Command Prompt (cmd.exe)", | ||
"Run command in PowerShell (PowerShell.exe)", | ||
"Find executable file and run it", | ||
"Run command in Windows Terminal (wt.exe)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These don't look like they are currently localizable.
|
||
public bool ShowComboBox => _additionalOption.ComboBoxOptions != null && _additionalOption.ComboBoxOptions.Count > 0; | ||
|
||
public bool ShowCheckBox => ShowComboBox == false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this, I think it's not very flexible to adding new types in the future. Can we add a field that's a sort of enum for the type of option this is? Currently there's two option types we're using, a "BooleanCheckboxOption" type (which would be default, so we don't need to change current code and still support the third party plugins we currently do) and a "SelectionDropDownOption" type.
That way, in the future, someone can add a "SelectionDropDownWithCheckboxOption", if needed?
I imagine some TextBox fields might make sense in the future if people want to add in plugins that may take API keys, for example. (Not to add in this PR)
What do you think @htcfreek ?
This PR solves #4283 |
I like to have a review of @niels9001 for the settings ui part and if we need to adjust the ui look and feel. @gokcekantarci |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! It's likely that the Settings UI part may need a refactor as we increase the number of types, but this looks good enough for now.
Thank you! Great work!
Summary of the Pull Request
A combobox added to choose which shell command to run command with
PR Checklist
Detailed Description of the Pull Request / Additional comments
Validation Steps Performed