[Run][Plugin Manager] Move plugin specific settings under the plugin settings

[mykhailopylyp]

Link to parent issue #5273

It should be possible for plugins to have different settings.
Now we only have one option Disable drive detection warning for the file search plugin

[mykhailopylyp]

Here are three examples when we have an indirect reference from PowerLauncher project to plugin projects. We should get rid of them.

PowerToys/src/modules/launcher/PowerLauncher/SettingsWatcher.cs

Lines 121 to 127 in 419a143

	// Using OrdinalIgnoreCase since this is internal
	var indexer = PluginManager.AllPlugins.Find(p => p.Metadata.Name.Equals("Windows Indexer", StringComparison.OrdinalIgnoreCase));
	if (indexer != null)
	{
	var indexerSettings = indexer.Plugin as ISettingProvider;
	indexerSettings.UpdateSettings(overloadSettings);
	}

PowerToys/src/modules/launcher/PowerLauncher/SettingsWatcher.cs

Lines 104 to 109 in 419a143

	var shell = PluginManager.AllPlugins.Find(pp => pp.Metadata.Name == "Shell");
	if (shell != null)
	{
	var shellSettings = shell.Plugin as ISettingProvider;
	shellSettings.UpdateSettings(overloadSettings);
	}

PowerToys/src/modules/launcher/PowerLauncher/ViewModel/MainViewModel.cs

Lines 896 to 899 in 419a143

	if (!plugin.Metadata.Disabled && plugin.Metadata.Name != "Window Walker")
	{
	_ = PluginManager.QueryForPlugin(plugin, query);
	}

[mykhailopylyp]

@enricogior
We have two options here:

• The responsibility of rendering plugin settings is taken by the settings app. That means that we would add information about checkboxes, textboxes, etc. to PowerLauncherPluginSettings. So far we only need to add an array of checkboxes. It is easy to implement but it is not very flexible. It is something between small and medium cost.
• The responsibility of rendering plugin settings is taken by the plugin project. More precisely settings xaml file is stored in the plugin project and is loaded dynamically in the settings app. It is definitely a big work item.

[enricogior]

@mykhailopylyp
let's go with option 1.

[htcfreek]

Should we create a spec here how json should be formated and what elements are allowed.

Example (In xml format.):

<settingsGroup name="Result settings">
<checkbox name="test" default="on" settingsJsonString="ShowExampleResult" />
<radioGroup name="Show redults of type">
<radio order=1 name="all" description="test" default="on" settingsJsonString="ShowAllResults" />
<radio order=2 name="games only" description="test" default="on" settingsJsonString="ShowGameResult" />
</radioGroup>
</settingsGroup>

[mykhailopylyp]

Should we create a spec here how json should be formated and what elements are allowed.

@htcfreek
Do you mean spec for the plugin.json file? If yes, it would make a lot of sense when we allow third-party plugins.

[htcfreek]

Should we create a spec here how json should be formated and what elements are allowed.

@htcfreek
Do you mean spec for the plugin.json file?

What I mean is we should strict define what elements are allowed (edit, text, button, ...) and what attributes (name, description, settingValue, ...) can be defined.

I think we should introduce an independent config file for settings and shouldn't integrate them into the general plugin metadata json. (This is more flexible.)

As you see in my example I used a xml for demonstration. Maybe xml is here a better choice.

If yes, it would make a lot of sense when we allow third-party plugins.

Why only for third-party plugins? Why not use it for integrated once too.

[mykhailopylyp]

@htcfreek

I think I am not following.

What I mean is we should strict define what elements are allowed (edit, text, button, ...) and what attributes (name, description, settingValue, ...) can be defined.

You mean to define it for additional plugin settings, right? We agreed above that we go with an array of checkboxes for now.

I think we should introduce an independent config file for settings and shouldn't integrate them into the general plugin metadata json. (This is more flexible.)

If you think about it we have not introduced any new settings to plugin.json. Maybe we can create an issue to reduce the number of settings in the metadata.

[htcfreek]

@htcfreek

I think I am not following.

What I mean is we should strict define what elements are allowed (edit, text, button, ...) and what attributes (name, description, settingValue, ...) can be defined.

You mean to define it for additional plugin settings, right? We agreed above that we go with an array of checkboxes for now.

Yes, thats what I meant.

Okay. This is not much flexible. But let's go with that in the first step. Imo there will come plugins for that a checkbox isn't the best for all settings. (Example: Websearch plugin with selection of search provider.)

I think we should introduce an independent config file for settings and shouldn't integrate them into the general plugin metadata json. (This is more flexible.)

If you think about it we have not introduced any new settings to plugin.json. Maybe we can create an issue to reduce the number of settings in the metadata.

I think we should splitt between plugin metadata definition and complex settings definition. But in the first step we con go with one file.

[htcfreek]

@enricogior
The new issue for the remaining enhancement idea in this issue is created.

[crutkas]

Great news! This was resolved in the newly released 0.33 version of PowerToys! Head to https://aka.ms/installpowertoys to grab latest.