Overview

This PR refactors how Launcher plugins are handled to support state persistence and asynchronous UI updates. Previously, Launcher plugins were instantiated and destroyed for every single query, preventing them from maintaining internal state or performing async tasks.

Concrete Example: The Qalculate Plugin

This refactoring was driven by the needs of advanced plugins like Qalculate.

• Persistence: The plugin keeps a background qalc process alive for instant performance. Without this PR, the process would be killed and restarted at every keystroke.
• Asynchronicity: When a calculation is sent, the plugin can now immediately return a "Calculating..." item and then signal the UI to refresh with the final result once the background process responds, without freezing or blocking the launcher.

Key Changes

1. Persistent Launcher Instances:

   • Launcher plugins are now instantiated upon loading and stored in PluginService.pluginInstances, similar to Daemons.
   • This allows plugins to maintain a background state (e.g., a long-running process or an active connection).

2. Asynchronous UI Updates:

   • Introduced a requestLauncherUpdate(pluginId) signal in PluginService.
   • AppLauncher now listens to this signal to trigger a refresh. Plugins can now update the items list at any time, not just during the initial query.

3. AppSearchService Optimization:

   • AppSearchService now reuses the persistent instance from PluginService.
   • It maintains backward compatibility by falling back to the old create/destroy behavior if no persistent instance is found.

4. Dependency Injection:

   • The PluginService singleton is injected into plugins during creation (pluginService: root), enabling easier access to shared services and data.

Why this is needed

This architecture is essential for any plugin that interacts with external binaries, APIs, or performs heavy computations. It makes the launcher capable of handling non-instant results while remaining fluid for the user.