-
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
[File Explorer] Added an overall toggle switch (#23723) #33475
base: main
Are you sure you want to change the base?
Conversation
@acekirkpatrick |
@htcfreek |
@acekirkpatrick |
@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.
I did not test it with a local build yet. But I left some comments.
[JsonPropertyName("File Explorer Preview")] | ||
[JsonPropertyName("File Explorer")] |
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.
Does this change breake existing settings that users made?
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.
The property PowerPreview
had no references in the source code before.
src/gpo/assets/PowerToys.admx
Outdated
@@ -19,6 +19,7 @@ | |||
<definition name="SUPPORTED_POWERTOYS_0_78_0" displayName="$(string.SUPPORTED_POWERTOYS_0_78_0)"/> | |||
<definition name="SUPPORTED_POWERTOYS_0_81_0" displayName="$(string.SUPPORTED_POWERTOYS_0_81_0)"/> | |||
<definition name="SUPPORTED_POWERTOYS_0_81_1" displayName="$(string.SUPPORTED_POWERTOYS_0_81_1)"/> | |||
<definition name="SUPPORTED_POWERTOYS_0_82_0" displayName="$(string.SUPPORTED_POWERTOYS_0_82_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.
Will be 0.83.0 . Please update all occurrences.
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.
IsTabStop="{x:Bind ViewModel.IsEnabledGpoConfigured, Mode=OneWay}" | ||
Severity="Informational" /> | ||
|
||
<controls:SettingsGroup x:Uid="FileExplorerPreview_PreviewPane" IsEnabled="{x:Bind ViewModel.IsEnabled, Mode=OneWay}"> | ||
<InfoBar |
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 hide all this info bars that are not related to the overall Module enabled GPO when the GPO is disabled. (We make it on the other pages the same.)
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.
The incompatibility warnings and the reboot required notice should be hidden when the GPO is set to Disabled?
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.
Or should I hide them whenever the switch is off regardless of GPO setting?
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.
The incompatibility warnings and the reboot required notice should be hidden when the GPO is set to Disabled?
yes.
should I hide them whenever the switch is off regardless of GPO setting?
yes
You can implement a view model property "showInfobars" that is false if gpo is disabled or toggle is disabled (overall: if toggle is not enabled).
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 just used IsEnabled
. Is that okay?
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.
If it works as expected, yes. I didn't thought about this solution yet.
src/gpo/assets/PowerToys.admx
Outdated
<policy name="ConfigureEnabledUtilityFileExplorerSVGPreview" class="Both" displayName="$(string.ConfigureEnabledUtilityFileExplorerSVGPreview)" explainText="$(string.ConfigureEnabledUtilityDescription)" key="Software\Policies\PowerToys" valueName="ConfigureEnabledUtilityFileExplorerSVGPreview"> | ||
<parentCategory ref="PowerToys" /> |
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 could move all this File Explorer preview GPOs into a new subcategory "File Previewers". That makes it easier to find the GPOs for the single previewers. 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 was thinking about that when I made the GPO. I think we should. It was hard to find the overall GPO even when I knew exactly what I was looking for.
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.
But the overall gpo has to keep in the main folder.
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.
src/gpo/assets/PowerToys.admx
Outdated
@@ -136,6 +137,16 @@ | |||
<decimal value="0" /> | |||
</disabledValue> | |||
</policy> | |||
<policy name="ConfigureEnabledUtilityFileExplorerPreview" class="Both" displayName="$(string.ConfigureEnabledUtilityFileExplorerPreview)" explainText="$(string.ConfigureEnabledUtilityDescription)" key="Software\Policies\PowerToys" valueName="ConfigureEnabledUtilityFileExplorerPreview"> |
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 need a new description with the addition that disabling also disabled all single previewer. ANd with the info that force enabling it not force enables the toggles of the single previewers.
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 (line 49).
@acekirkpatrick And for your information: We have a policy documentation in our end-user docs that needs an update too. |
Ooh wow. You fixed #29827 too. |
@htcfreek |
@acekirkpatrick
|
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 should rename the Policy group. (See my comment.)
- Tray flyout and Settings dashboard using the wrong name. The should show "File Explorer add-ons" and not "File Explorer". (See your screenshots.)
- If you disable the policy "Configure global utility enabled state" and enable "File Explorer add-ons: Configure enabled state" then you ran into a conflict. (The reason is that the "Configure global utility enabled state" policy affect the individual previewer policies.) - We either have to improve this or explain it in the policy description.
- Regarding hiding the info bars if overall toggle is disabled by user or policy you can add a new property to the view model that is directly linked to the non-gpo info bars and add
&& _isEnabled
as condition to the propertiesSomePreviewPaneEnabledGposConfigured
andSomeThumbnailEnabledGposConfigured
. (Important you have to call OnPropertyChanged() for all three infobar properties in the setter ofIsEnabled
.) - I didn't try the behavior of the previewers itself for the different policies. But looking at the code it seems that you did not update the code:
const auto gpo_rule = fileExplorerModule.checkModuleGPOEnabledRuleFunction();
src/gpo/assets/PowerToys.admx
Outdated
<policy name="ConfigureEnabledUtilityFileExplorerMarkdownPreview" class="Both" displayName="$(string.ConfigureEnabledUtilityFileExplorerMarkdownPreview)" explainText="$(string.ConfigureEnabledUtilityDescription)" key="Software\Policies\PowerToys" valueName="ConfigureEnabledUtilityFileExplorerMarkdownPreview"> | ||
<parentCategory ref="PowerToys" /> | ||
<policy name="ConfigureEnabledUtilityFileExplorerMarkdownPreview" class="Both" displayName="$(string.ConfigureEnabledUtilityFileExplorerMarkdownPreview)" explainText="$(string.ConfigureEnabledFilePreviewerDescription)" key="Software\Policies\PowerToys" valueName="ConfigureEnabledUtilityFileExplorerMarkdownPreview"> | ||
<parentCategory ref="FilePreviewers" /> |
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.
@acekirkpatrick
Should be File Explorer add-ons
.
@jaimecbernardo
Can move the policies into the sub category, even if it breake existing Intune policy configuration sets? (Normal Group Policy configuration won't break.)
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.
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.
Not sure. Think we might need to add a note about that in release notes. we also broke "All utitilities" GPO backcompatibility in Intune. Not sure why Intune needs to be different 🤷
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.
Not sure. Think we might need to add a note about that in release notes. we also broke "All utitilities" GPO backcompatibility in Intune. Not sure why Intune needs to be different 🤷
Side note: And All Experiments GPO is broken too after mofing into sub category. (PR 33529)
@@ -218,56 +230,59 @@ void PowerPreviewModule::apply_settings(const PowerToysSettings::PowerToyValues& | |||
{ | |||
bool notifyShell = false; | |||
|
|||
for (auto& fileExplorerModule : m_fileExplorerModules) | |||
if (m_enabled) |
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.
@htcfreek
For point 5, I added a check that should prevent any preview handlers from running if the module is not enabled.
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.
Sure. But the policy state won't be written into the settings file. You have to explicit query the policy values and evaluate them.
Like here:
.checkModuleGPOEnabledRuleFunction = powertoys_gpo::getConfiguredSvgPreviewEnabledValue, |
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.
Because you shouldn't be able to bypass a force-enabled add-on by turning off all extensions?
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.
But what about force disabled?
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 do you think of powerpreview.cpp
now?
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.
yes, it does look good to me now.
@htcfreek |
@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.
LGTM
Note for reviewers (from the core team):
cc: @jaimecbernardo , @stefansjfw |
@htcfreek |
@acekirkpatrick |
I've merged with main to resolve conflicts. |
@@ -286,47 +287,47 @@ namespace powertoys_gpo { | |||
|
|||
inline gpo_rule_configured_t getConfiguredSvgPreviewEnabledValue() | |||
{ | |||
return getUtilityEnabledValue(POLICY_CONFIGURE_ENABLED_SVG_PREVIEW); | |||
return getConfiguredValue(POLICY_CONFIGURE_ENABLED_SVG_PREVIEW); |
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 are we making these utilities no longer respond to the "All utilities" GPO?
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 was based on how it is working now. We discussed this in the PR discussion. They are handled as sub settings now.
And the new "main" utility GPO is the one for "File Explorer add-ons module". And this new policy is respecting the "all utilities gpo".
If the previewers itself tespect the all utilities gpo they can override the explorer add-ons module gpo. And this can lead to confusing behavior.
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.
@jaimecbernardo (and @acekirkpatrick)
For clarification. The problem is not that individual previewers will override the "All Utilities GPO". The problem is that with "All Utilities GPO" being disabled and "FileExplorer Addons Module GPO" being enabled, the resulting behavior is strange.
Example:
- All Utillities GPO = disabled
- File Explorer Add-ons Module enabled state = enabled
- Individual File Explorer add-ons enabled state = All are not configured.
- Result: The module is enabled and no individual previewer works as they are still disabled by the "All Utilities GPO".
Possible solution 1 for the problem:
If we need a policy to disable new/unknown previewers like the old behavior was, I suggest the following: Add a new policy like we have for unmanaged PT Run plugins. We can name it "Default enabled state for all File Explorer Add-ons" and place it in the "File Explorer" category. (Then we are as flexible as possible.)
The behavior would be:
- Not configured: User takes control.
- Enabled: Add-on is enabled.
- Disabled: Add-on is disabled.
- Overwritten by individual add-on policy: Value of individual policy.
(This solution fixes the conflict we have when using the "All Utilities GPO" while still providing the possibility to handle newly added Add-ons by default.)
Possible solution 2 for the problem:
We revert the gpo related changes to the old behavior. (Maybe except moving the policies into a sub category.)
And then we add code to calculate the global FE Add-on enabled toggle state based on the individual policies:
- At least one add-on is force enabled: Global toggle is force enabled.
- All add-ons are force disabled: Global toggle is force disabled.
(Thi solves the problems we get with a new utility policy while not breaking current policy behavior and keeping the policy configuration flexible and simple.)
7/22/2024 Edit 1: Add not about overwrite behavior to solution 1.
7/22/2024 Edit 2: Add solution 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.
@jaimecbernardo and @acekirkpatrick
What do you think about this? I personally prefer to go with solution 2 as it keeps the administration simple and doesn't break existing policies.
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.
@htcfreek @jaimecbernardo
I would agree that solution 2 is the most similar to how it was before, if we are still considering each previewer to be its own module.
However, they don't appear to be separate once we add the overall toggle. It feels like it would be best to make it like PT Run, where the individual previewers are considered to be part of the same module.
My solution 3:
Make the File Explorer module very similar to PT Run, where the individual previewer policies override the module policy. So you can disable the module policy, which disables any new previewers, but you can force-enable certain previewers so that they still run.
The main problem with this would be that unlike PT Run, the user would have no option to simply stop using the previewers. They would have to stop using PowerToys completely if they didn't want to use a force-enabled previewer.
Co-authored-by: Heiko <[email protected]>
Co-authored-by: Heiko <[email protected]>
ping @jaimecbernardo. And can you please look at our suggestions on this discussion. |
@jaimecbernardo or @stefansjfw I have a conflicting PR #33703 open and need to know how long this Explorer add-ons PR needs to be ready. I like to get my PR in soon which is impossible if I wait on this here. I suggest to get my PR in and update this here with the new info bar icons. |
@acekirkpatrick |
@crutkas |
Summary of the Pull Request
Added an enable toggle switch for File Explorer.
PR Checklist
Detailed Description of the Pull Request / Additional comments
Validation Steps Performed
Setting saved to JSON
Previews were not run if disabled
GPO
Screenshots
Module Policy Not Configured
Module Policy Disabled
Module Policy Enabled