[Discussion] Plugins API

[KELiON]

I'd like to discuss with plugins creators current plugins API. Do you think it is ok? Do you feel the lack of something? What would you change/add? What would you like to automate?

/cc @Myslik @rafa-acioly @codingmatty @matmunn @JordanAdams @jsantiagoh @adrian011494 @Krbz @tiagoamaro @lubien @BrainMaestro @tenorz007 @ReeSilva @Kageetai @benoitzohar @glja021 @masterperas @adamclark64 @Saleh7 @cades @tobico @hellocreep @klazutin @luisdavim @ocReaper @sibevin @fdivrp

[klazutin]

I was just going to say 'being able to store settings', but I see that has already been included in the latest release, so I'll go and check it out.
Thanks for the great work!

[lubien]

One of the things that hit me right from the beginning was the lack of a standard Preview framework.

Here you can see the preview of the google search (core) plugin.

One of my first plugins was a MyAnimeList.net search plugin and I've wanted to do something like the google plugin but as soon as I realized that I'd need all boilerplating to create a pretty and working UI for the preview (with behind the scenes features like proper keybords interaction) I've dropped the idea and used just the display([xs]).

My plugin works, but it differs from the core google preview. And even if I've made mine, maybe it'd be different looking from the overall cerebro layout.

I think this would be great if cerebro provided not an external library but a core library to display preview results.

Why not external (like cerebro-plugin)? Because if it's core, cerebro could adapt it's design as much as cerebro changes itself.

[lubien]

Ps: by preview I don't mean just a list display, but could be useful displays for different common things like images, videos, file, table values, maybe charts idk, it should be discussed...

[luisdavim]

I agree with @lubien a standard preview framework would be great.

[codingmatty]

I agree, some React components that help with the preview would be awesome.

Also, I tried to look for documentation on "plugin settings" but couldn't find anything.

[codingmatty]

i also want to point out this issue in cerebro-tools: cerebroapp/cerebro-tools#1

[lubien]

Search for debouncing or throttling requests @matmunn

[lubien]

@matmunn nice

[BrainMaestro]

Yeah I think a standard preview framework with community styling is a good idea. Makes everything uniform and would speed up development.

@matmunn instead of the setTimeout, you can use lodash debounce. I implemented something similar in the weather plugin, but you might need to tweak it a little.

[tiagoamaro]

Agreed with @lubien on deboucing/throttling. Depending on the API you're handling, it's not interesting to query for each letter the user is typing.

+1 on a default preview component.

[rafa-acioly]

+1 on a default preview component.
@KELiON This would have prevented the error we encountered when I overwritten the default layout unintentionally.

[KELiON]

I see, that eeeeveryone is missing ui library! Lets move conversation about that to #282.

[Enzime]

Also I think we should potentially standardize some settings, like for example a caseSensitive setting for plugins that could have three options like true, false, inherit (which means it would get it from the global caseSensitive setting which can either be true or false)

[lubien]

With the new preview features in mind, I think we should discuss about the current keyword-based cerebro plugin scoping.

When I type any generic foo query I have two possibilities: google search or translations, two plugins with proper preview systems. So far so good.

But to properly query plugins without proper preview I must use it's keyword. The reason is obvious. Without keyword scopping, every single query would hit all plugins who could do lots of requests/renderings.

But as soon as everyone uses a preview system tha game changes! When I type foo I'd like to not only have the two possibilites (google or translation) but also any kind of plugin who could be useful for that question, my MyAnimeList search plugin or a NPM search plugin for example.

But as soon as the user had too much possibilites it would be hard to, after typing the query, go down until you find the plugin that you want to handle the current query.

So here's my proposal:

1. Keywords are still valid scopping rules for plugins query.

You can continue to type npm (.*) to search specificly on NPM.

2. Users can select which plugins they want to use without the keyword.

Suppose I do a lot of NPM searches and I don't like to start every query with npm.

As a user I can go to some settings on cerebro and select the NPM plugin as a plugin that could be used without keyword (just like google and translator). Now I can type react and a third option to search on NPM displays at cerebro.

3. Plugins selected to be used without keyword could be prefixed with the keyword if wanted.

Even after setting up the things of *2, users should be able to still query npm react and have it's responses.

[ReeSilva]

I'll go with a +1 on the Preview Framework. I believe that, for now, it's a must have. (and a lot of folks talking about the same is an evidence of this).

Maybe a React Component Preview with some childrens components like title, body/description, image, etc.

[codingmatty]

I agree with @lubien about configurable scoping. It could be as "simple" as allowing users to configure their own keywords for each plugin. i.e. configuring npm ... to be n ..., or without the keyword altogether.
I personally would rather only allow google (and maybe wikipedia) to be allowed for all queries. I have opted for the Define plugin over the OSX Define because of the scoping. It's faster for me to type a keyword than to scroll through all of the unrelated results list.

[Enzime]

Another idea I have for the plugins API is to allow other plugins to extend each other, mainly the preview section. This is more specifically about the basic-apps plugin and potentially extending that, but if someone could figure out a way to generalize it, that would be amazing.

I originally got the idea from seeing applications being listed but their preview just being some stats about the actual .desktop file, which isn't very useful to most users.

For example, Firefox and Chrome both have support for different profiles, and I would like the ability to select which one profile I'm launching from Cerebro, so if there were some way I could write a plugin to override the Firefox application's preview from basic-apps.

I realize this could be done by adding NoDisplay=true to the firefox.application and making a plugin that adds a new Firefox entry with the custom preview, but my main issue with this is that a lot of .application files are not modifiable without root, so if we could override these some way with a plugin that would be really good as it would let people drop in the plugin.

[dakaizou]

It'd be nice to have the ability to define (default) results priority.

[ogustavo-pereira]

I will close this discussion issue so we can start using the new github discussion tool