[PTRun] Allow preventing usage based ordering results

[CoreyHayward]

Summary of the Pull Request

Implement an additional functionality on the Result model allowing the prevention of selected count retrieval.

PR Checklist

• Closes: PowerToys Run Plugin interface cannot enforce result order #36519
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

This PR adds an additional property to the Result.cs model which allows for disabling the functionality which fetches the SelectedCount data from PowerToys. This enables the ability for plugins to prevent the SelectedCount property from being populated for individual results meaning that the sort order can be manipulated as desired by the Plugin giving more control back to the plugin developers.

Validation Steps Performed

[htcfreek]

Wrote some feedback on the property naming.

But I am wondering about the use case and feature implementation.

• If you like to enforce a fixed oder, wouldn't you need to disable all types of automatic sorting (weighting boost, selecten based sorting, scoring)?
• Have you tested that your implementation doesn't breaks the history (plugin)?

[CoreyHayward]

Wrote some feedback on the property naming.

But I am wondering about the use case and feature implementation.

• If you like to enforce a fixed oder, wouldn't you need to disable all types of automatic sorting (weighting boost, selecten based sorting, scoring)?
• Have you tested that your implementation doesn't breaks the history (plugin)?

@htcfreek Thanks for the feedback!
The aim really is to disable the dynamic ordering for a result based on the number of times it has been selected. I think the updated implementation makes this a bit clearer. By doing this we achieve the goal of having a custom/fixed order result list which can be determined by the plugin developers if desired (the default behaviour acts as if this change was not implemented).
Please correct me if I am wrong but the WeightBoost is scoped to the plugin as a whole and is applied to every single result returned by a single plugin so this does not affect ordering within the scope of a plugin and the Score is already determined by the Plugin creating the result so again this allows for control over the ordering whilst still allowing the plugin developers to control it. The only thing completely out of the plugin developers control is whether the selection based scoring + multiplier is applied to the result which is what this change aims to resolve.

I have tested this manually with one of my own plugins and it does have the desired result when enabled whilst also not causing any affect on results that do not make use of the feature.

[htcfreek]

@CoreyHayward
Thank you for the chages. Now things are much easier to understand.

I wrote a small suggestion for renaming the new method.

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

[moooyo]

LGTM. I'm not familiar with the sort part implementation. But at least in my view it will not break anything and just add a useful setting for plugin author.

[stefansjfw]

The code does not break anything indeed. However, this setting should be on a plugin level, not a result level. That change probably needs a bit more work, but overall it will make more sense

[CoreyHayward]

The code does not break anything indeed. However, this setting should be on a plugin level, not a result level. That change probably needs a bit more work, but overall it will make more sense

I don't necessarily disagree with your point as it makes sense for my plugin (though I don't know if any other plugin dev's may have a weird use case for this where they want only certain results to be affected by selection weight), however I don't believe there is currently a mechanism for this in Plugin system to set dynamic configuration at a plugin level which can then be applied to the result. The only mechanism I am aware of for this currently is the PluginMetadata class but this is pulled from the plugin.json file which can't really be changed or updated.
My goal with this change is to allow users to configure my plugin via a custom PluginAdditionalOption which will allow them to turn this behaviour on or off depending on their preference.

Please do let me know if I am missing something that would help with this.