Question about Plugin Development

[taooceros]

A few question about the development of plugin.

Question

1. Is it possible for plugin to utilize some method in Flow.Infructure such as the string matcher?
2. How to debug the plugin without copying the whole folder to the Flow source project?

[jjw24]

hey how's it going.

1. Definitely, and this can be exposed through the IPublicAPI interface. Also another function from Infrastructure that can be useful is the JsonStorage class for saving settings.

2. I can see this being useful, maybe publish Flow as a nuget as well so can be called and run by individual plugins?

[taooceros]

Definitely, and this can be exposed through the IPublicAPI interface. Also another function from Infrastructure that can be useful is the JsonStorage class for saving settings.

Great, I will work around on it and take a look on how to expose that method to IPluginAPI.

I can see this being useful, maybe publish Flow as a nuget as well so can be called and run by individual plugins?

Interesting, but is that means that plugin may need to depend on Flow to debug, which is a bit large, and remove it when publishing? Not familiar with that.

[taooceros]

There is a question when expanding the plugin api. Since IPublicAPI is under Flow.Launcher.Plugin namespace, it is unable to reach back to the class created in Flow.Launcher.Infrastructure namesapce. So if I want to reference to the class from Infrastructure, I may need to create a similar copy of that in Plugin namespace, which is weird....

[jjw24]

Flow.Launcher.Plugin.PluginInitContext class contains IPublicAPI, so I think you can do something similar like ReloadAllPluginData() right?

[jjw24]

I can see this being useful, maybe publish Flow as a nuget as well so can be called and run by individual plugins?

Interesting, but is that means that plugin may need to depend on Flow to debug, which is a bit large, and remove it when publishing? Not familiar with that.

yeah good point, will be large. Maybe a slim down version of it? i guess the goal is allow the plugin to load, start up and run on its own.

[taooceros]

Flow.Launcher.Plugin.PluginInitContext class contains IPublicAPI, so I think you can do something similar like ReloadAllPluginData() right?

Well... I mean if I want to port the FuzzySearch into the IPublicAPI, I may need the MatchResult class as return value type, which is unreachable in Flow.Launcher.Plugin namespace. The reason why ReloadAllPluginData can be done is due to that its return value type is void, and the implementation for IPublicAPI interface is from the Flow.Launcher namespace, which has the access toward those class and method.
So if we want to port method to IPublicAPI, there are two choice.

1. We can port the whole class to shared command folder inside Flow.Launcher.Plugin, so that IPublicAPI will have access to it. (like WebSearch.cs). However, that may confound the boundary of Flow.Launcher.Infrastructure and Flow.Launcher.Plugin. Therefore, class or method that we will allow plugin to access will be in FLP (Flow.Launcher.Plugin) namespace, and those we won't allow plugin to access will be in FLI namespace.
2. It's possible for us to create a result type inside FLP namespace, and keep the implementation for that in PluginAPIInstance class, which has access to those classes and method, and convert original result type to the one insdie FLP namespace.

[jjw24]

I dont think this core search functionality which is mainly used by all plugins should even live in Flow.Launcher.Infrastructure. There is really nothing infrastructure about this core piece of functionality.

I would say move the whole class over to Flow.Launcher.Plugin. Plugins should be aware of the changes made to this search functionality and should be owned by them not vice versa.

Additionally, the usage of IPublicAPI should be to provide plugins the means to alter (to a degree) how flow launcher's certain aspects behave.

[taooceros]

I dont think this core search functionality which is mainly used by all plugins should even live in Flow.Launcher.Infrastructure. There is really nothing infrastructure about this core piece of functionality.
I would say move the whole class over to Flow.Launcher.Plugin. Plugins should be aware of the changes made to this search functionality and should be owned by them not vice versa.

Agree, I will move that to the shared command folder in Flow.Launcher.Plugin.

Additionally, the usage of IPublicAPI should be to provide plugins the means to alter (to a degree) how flow launcher's certain aspects behave.

hmmm, not sure what you mean by that. Should plugin be authorized to change some main aspect in Flow? I think the IPublicAPI do provide some functionality, such as restart flow, reload plugin, etc.

[taooceros]

There is an issue of moving the StringMatcher to Flow.Launcher.Plugin…… It reference too much things, and the referenced thing reference other things, which makes the migration become quite large.

For example, due to checking whether user use pinyin, it reference Usersettings class, which also reference the Logger class and Constant and KeyConstant class. That's kind of weird to move all these class to Flow.Launcher.Plugin since I think it should be lightweight for plugin developer to reference.

I don't think it worth for a result type to move so many things.....

[jjw24]

let me give it a shot sometime this week.

[jjw24]

one of the things that ties it down to the infra is user search precision settings, i have been wanting to get rid of those options and just allow the 'Regular' setting as the default, as stated in issue #16. I dont think the other two are needed. What do you think?

[taooceros]

let me give it a shot sometime this week.

No worry I just put it as pr so that we can show some change based on it. Current change is almost equal to nothing.

one of the things that ties it down to the infra is user search precision settings, i have been wanting to get rid of those options and just allow the 'Regular' setting as the default, as stated in issue #16. I dont think the other two are needed. What do you think?

I do agree we can remove that, since not a lot of people use it. However, user still need to choose whether use pinyin, which require the setting.