Skip to content
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

[Feature] - add plugin metadata to search result #261

Open
oknozor opened this issue Feb 19, 2025 · 0 comments
Open

[Feature] - add plugin metadata to search result #261

oknozor opened this issue Feb 19, 2025 · 0 comments

Comments

@oknozor
Copy link
Contributor

oknozor commented Feb 19, 2025

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).

Image

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:

  1. Add a global plugin context in the search result.
  2. 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.

{
  "plugin_context": {
    "plugins": ["web_search", "desktop_entries", "pulse"]
    "history_enabled": true,
    "isolated": false,
    "activated_by": "reddit"
  },
  "Update": [
    {
      "id": 0,
      "name": "reddit: silksong",
      "description": "https://reddit.com/search/?q=silksong",
      "icon": {"Name": "/home/okno/.cache/pop-launcher/reddit.ico"},
      "category_icon": {"Name": "system-search"}
    },
    {
      "id": 1,
      "name": "gedit",
      "description": "System - Edit text files",
      "icon": {"Name": "org.gnome.gedit"},
      "category_icon": {"Name": "new-window-symbolic"}
    },
    {
      "id": 2,
      "name": "Volume Control",
      "description": "System - Adjust the volume level",
      "icon": {"Name": "multimedia-volume-control"},
      "category_icon": {"Name": "new-window-symbolic"}
    ...
  ]
}

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.

{
  "Update": [
    {
      "id": 0,
      "name": "reddit: silksong",
      "description": "https://reddit.com/search/?q=silksong",
      "icon": {"Name": "/home/okno/.cache/pop-launcher/reddit.ico"},
      "category_icon": {"Name": "system-search"},
      "plugin_context": {
        "plugin": "web_search",
        "history_enabled": true,
        "isolated": false,
        "activated_by": "reddit"
      }
    },
    {
      "id": 1,
      "name": "gedit",
      "description": "System - Edit text files",
      "icon": {"Name": "org.gnome.gedit"},
      "category_icon": {"Name": "new-window-symbolic"},
      "plugin_context": {
        "plugin": "desktop_entries",
        "history_enabled": true,
        "isolated": false,
        "activated_by": null
      }
    },
    {
      "id": 2,
      "name": "Volume Control",
      "description": "System - Adjust the volume level",
      "icon": {"Name": "multimedia-volume-control"},
      "category_icon": {"Name": "new-window-symbolic"},
      "plugin_context": {
        "plugin": "pulse",
        "history_enabled": false,
        "isolated": false,
        "activated_by": null
      }
    },
    ...
  ]
}

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant