[Feature Request] Support for plugins

czhang03 commented 5 years ago

For both wox and alferd, plug-ins are a essential part of the app and improves usability by a great deal.

Please support developing plug-ins.

czhang03 commented 5 years ago

Here is some documentation on how wox handles plugins:

http://doc.wox.one/en/plugin/create_plugin.html http://doc.wox.one/en/plugin/plugin_json.html

Basically, in each plugin there is a plugin.json specifies all the basic metadata including version, name, etc. There are two things worth noting:

UUID: I don't know whether this is necessary, many modern package managers no longer use UUID as id. For example, npm and choco.
Executable file: This is the file specifying the executable, for example the python file or the compiled executable. In our case I think we can support typescript and javascript plugin first and then explore the possibility of supporting other type of plugins (python plugin or executable plugin).

wox gains all its functionality from plugins. I think this is a really robust and useful idea.

This idea gives user full control of the functionality they want (if they don't want certain functionality, they can just disable or uninstall that plugin), and makes the code much more modularized and extendable.

If we build the plugin system, then all the searcher and builder can be isolated and become plugins. also operating-system-settings and programs-plugin will be in their respective plugin folder. Results in a much cleaner src folder.

czhang03 commented 5 years ago

Some functionality to keep in mind while developing plugins:

Plugins should be able to install external packages if they want. For example when developing a calendar plugin, a library to generate ics file will be really helpful. Therefore, we need to handle installing dependency when installing and updating a plugin.
We cannot simply invoke a command to the main file, because in a plugin, there might be other helper files and dependency. We need to find an elegant way to load in the plugin and then invoke the query and contextMenu function.
Relevance of results. When two plugin have the same activation keyword, we need to sort these results by relevance of these results. This is very hard.
Language options. The ueli should send in a config input or a config global constant to the plugin to tell them about some user options, including languages. There is also privacy concerns, user should be able to control what will sent into the plugin.

alanaasmaa commented 5 years ago

Ueli looks like currently best launcher i have found. But it really needs simple way to create own plugins and features. Currently hain seems to be best option for me, but for some reason I like ueli more.

Maybe I can somehow help with plugins?

oliverschwendener commented 5 years ago

In my opinion implementing a plugin manager is too overkill for now and will complicate stuff too much. If someone wants to implement a new plugin/feature it can be integrated directly to the app by making a pull request. Closing this for now until I really see the need for plugin system or someone else wants to implement this.

NickSeagull commented 4 years ago

Hey @oliverschwendener, +1 to this. My biggest uses of Alfred on Mac were:

Quick search of AWS dashboards
Quick search of GitHub repos
Manage Spotify within the launcher
Fast switch to a Slack channel
Switch between open windows

I think that these features should not be a main part of Ueli, because they are not something that everyone will want to use.

I drafted a possible implementation of a plugin manager, and it could be quite simple in practice. Instead of going with all the full pledged package repo, UI for the packages, etc... We can start with a configuration file where the user can specify github repos for the plugins in the format user/repo.

Ueli would then clone/download the repo and dynamically require the main module on load.

When that module is loaded, it would add itself to the list of built-in plugins. What do you think?

oliverschwendener commented 4 years ago

Ok I totally see the need for a plugin system now. People start to have needs for special usecases and this is where custom plugins come in. It would be really cool if there would be a easy way to develop plugins for ueli and install them. I just have no clue how to implement this. I just really want to avoid compatibility problems when adding updates/changes to the "core" of ueli.

I guess I have to look into this in the nearer future. Maybe this is something for v9.0.0. I'll reopen this issue.

Thanks for the input @NickSeagull

NickSeagull commented 4 years ago

I think that the first step is already well setup, which is setting up an interface, and there is already one called ExecutionPlugin.

The next step would be how to indicate Ueli to load the plugin. The approach that Wox takes is to make all plugins have a class named Main, in order to know how to load them.

We could create an @*Plugin decorator that loads the class of the plugin perhaps?

I'm thinking that making each plugin a separate repo/project makes sense, so it looks like so:

plugin-repo
|- index.ts
|- package.json
|- ... more stuff

The contents of index.ts would be:

@ExecutionPlugin
export class CalculatorPlugin {    // no need for `extends` here, as the decorator can enforce it
  ...
}

in the package.json a main file is specified. so we can make Ueli aware of which file it would load.

Regarding distribution, I'd start with a .ueli.yaml file in $HOME and inside, some contents that look like:

plugins:
  - oliverschwendener/ueli-calculator-plugin@master

When Ueli starts, it would:

Check that file for the plugins
Download the zip from the tag in GitHub
Extract it into the folder where Ueli stores its assets, perhaps to plugins/ueli-calculator-plugin
Run npm run pack (or build, or compile, whatever command to generate the main file)
Check the package.json inside of that folder for knowing where the main file is located
require that main file
The decorator then executes the needed code, where it pushes the class into the appropriate list at search-engine.ts

How does that sound?

s-kerdel commented 4 years ago

What is the progress on this feature? Are there any updates since December 2019?

danielsteiner commented 4 years ago

I have just started working on this at my fork. I will also provide a sample plugin repository that can be used for this purpose.

tonyke-bot commented 3 years ago

Gentle ping on this thread. @oliverschwendener What's our progress here? I'm eager to write some custom plugin for ueli so really want to see the plugin system getting landed.

If you are designing a plugin system, what about putting your idea/specification into the Discussion and together the community finalize the design?

scorgn commented 3 years ago

I wanted to create a custom plugin to play music on Spotify from Ueli. I didn't see any way to do this, so I made a workaround. The workaround might be a little bit over the top just to play music on Spotify, but I use it all the time. It could be used for other things as well.

To achieve this I had to create a couple different things.

First, I created a web application to act as a "Search Engine". I used Laravel but there are definitely better tools for this than Laravel/PHP. This search engine would search Spotify API for results for the query and return the results. However, before returning the results, it saves all the results with their URI's. It hashes the names of the result to use as the key. For example, if one of the results is "Yellow Submarine by The Beatles", it would md5 hash that string and cache the Spotify URI using the md5 hash as the key.

The second thing I had to create was a "Browser" application that handled custom URIs. In this instance the URI is spotify-search:. I used Platypus to turn an sh script into a MacOS application, and register it as the custom URI handler for spotify-search:. I also set it to run in the background.

To hook it up with Ueli I added a "New websearch engine" to Ueli. For the "Suggestion URL" I used the search engine I created, so I entered http://spotify-search-engine.test/api/suggestions/{{query}}. For the URL I used the custom URI mentioned before. So I entered spotify-search:{{query}} The prefix I used is s?.

This means that when you select a result in Ueli, it actually runs the sh script in the background and passes it the query string.

The sh script makes a request to the same Laravel application used before with the query string. The Laravel application will md5 hash it and check the cache to find the URI that was cached earlier, then returns it. The sh script will use osascript to play the Spotify URI in the background.

So in all, the flow goes...

Ueli uses Laravel Application to get suggestions for a query
Laravel application gets suggestions from Spotify API
Laravel application caches all suggestions along with their URI and returns search suggestions
User selects a search suggestion, which uses a custom URI scheme to open the "Browser application" (sh script) in the background
The "Browser" application makes an API request to the Laravel Application with the search query in order to get the URI that was saved
The "Browser" application uses osascript to tell Spotify to play that URI.

It's a pretty complex workaround just to play music on Spotify but it works pretty well. I'm considering hosting the Laravel application publicly, then letting people download the "Browser application" (sh script) so they can set up their Ueli to be able to play Spotify as well.

I'm sure it would work well for other scenarios as well. I'd be happy to help someone build out a similar solution if they want to make it work for a different scenario.