You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, SearchResult does not provide any context about the plugin that produced it. This creates challenges on the client side, as the client may need this information for proper handling of search results.
Specifically, the client
History Tracking: The client needs to determine whether history is enabled for a search result to persist the activated search result.
Plugin Identification: Knowing which plugin produced the search result is essential for saving history correctly.
Plugin Isolation: The client must be aware if a plugin is isolated to handle history tracking accordingly.
Query Activation Context (Optional) – The client may need to know which part of the query triggered the plugin search to enhance UI representation (see image below).
In Onagre, highlighting the plugin hint and saving history currently require loading all plugins on the client side and matching the user query against plugin regexes. This approach works well as long as the activated plugin follows standard matching. However, plugins with custom matching introduce challenges—for example, highlighting the web plugin requires parsing the custom config.ron file and matching against its rules. This becomes frustrating because if Onagre users enable unsupported plugins, the highlight and history features may not function correctly.
Possible solutions:
Add a global plugin context in the search result.
Include per-search-result plugin context.
Here are two examples of how plugin context can be structured within the search results:
**1. Global Plugin Context **
In this approach, a single plugin_context field at the root level provides information about all results.
The first approach is more concise but the second one allow for more UI features such as highlighting the plugin for selected line, tracking history differently for non isolated plugin etc.
Would you accept something like this ? I know this would be a breaking change but I think cosmic launcher may profit from this.
The text was updated successfully, but these errors were encountered:
Currently, SearchResult does not provide any context about the plugin that produced it. This creates challenges on the client side, as the client may need this information for proper handling of search results.
Specifically, the client
In Onagre, highlighting the plugin hint and saving history currently require loading all plugins on the client side and matching the user query against plugin regexes. This approach works well as long as the activated plugin follows standard matching. However, plugins with custom matching introduce challenges—for example, highlighting the web plugin requires parsing the custom
config.ron
file and matching against its rules. This becomes frustrating because if Onagre users enable unsupported plugins, the highlight and history features may not function correctly.Possible solutions:
Here are two examples of how plugin context can be structured within the search results:
**1. Global Plugin Context **
In this approach, a single
plugin_context
field at the root level provides information about all results.2. Per-Result Plugin Context (Added to Each Entry)
Here, each search result has an associated
plugin_context
, providing granular details about which plugin generated it.The first approach is more concise but the second one allow for more UI features such as highlighting the plugin for selected line, tracking history differently for non isolated plugin etc.
Would you accept something like this ? I know this would be a breaking change but I think cosmic launcher may profit from this.
The text was updated successfully, but these errors were encountered: