I found a lot of comments in issue tracker about plugin support but there isn't any specific thread for it.
I think that plugin support is a good way to keep KISS simple and lightweight and at the same time it's a good way to add a lot of functionality.
Moreover plugins would keep a low number of permissions request. These permission would be required for each single plugin (e.g. would be also possible to remove contacts permission and make it available in a Contact plugin).
For example with plugins would be possible to add particular search provider such as:
(I have no skills in this field so I do not know exactly how plugins work. So it's possible I said something wrong).
Some related issues: #592, #592 (comment), #486, #390, #673.
I think this should be a priority feature to add in KISS.
I saw that @alexander255 was working on it some times ago.
Is there still someone who is working on this?
Pls fix title
This could be really useful. Though, it would add much more size to KISS. I suggest, if anyone makes, make it possible as another app on Play Store or FDroid. I really don't know if it would be better or worse.
I'd say this is a great idea! Also wish I was able to be a plugin maker. But I'm not even slightly knowledgeable.
I was going to open a similar issue (mostly about app drawer) see issue: #369 (and some others related to it). The main problem I noticed was the issue of file size, where adding RecycleView would pull libraries that would drastically increase the file size. If a plugin system would be implemented I believe this would be the best way to go about this.
This way, the launcher would still be small (initial install), but would allow for more customization for those that would require it. The user would be able to decide whether to install features they need or not.
I personally am very partial to the near stock look of the app drawer in launchers like Lawnchair, I was imagining the implementation for Kiss being similar, where selecting Grid View would raise the search bar to the top and the apps would be listed bellow.
I have started working on plugin support but I am still quite in the beginning.
So far, KISS can detected installed plugins and extract some info out of the plugin (name, description, url).
The user can enable disable the installed plugins from settings.
Next basic steps to be implemented:
If I finish all the above (I cannot estimate how easy they are), I can open a PR to get some comments.
@nmitsou: I had implemented a system that addresses points 2 & 3 of the above the list back in 2017. Since I'm not following KISS development anymore I do not know if the architecture for handling results has changed a lot since I wrote that code, but it likely didn't.
An interesting property of the system was that providers would not be able to stall the launcher by being slow to respond we displaying messages as everything was asynchronous. It also had the side-effect of making fast scrolling through the history much smother (it appears like the issue has already been resolved in the current codebase however).
Maybe you can take some inspiration from it:
https://github.com/alexander255/kiss-launcher/tree/refactor
Nice!! I will definitely have a look, thanks
Does it exist as an APK file?
thanks @nmitsou, im following this now for a while and the only thing i can say is: plugins would be a killer feature.
have you had a look on the dashclock widget? https://github.com/romannurik/dashclock
@hasantr The plugin should be an apk file that can be installed separately. In the pr, a sample plugin will be provided so that it will be easy to start.
@marunjar thanks I will have a look there too.
How would plugins work from a technical standpoint?
Most helpful comment
@nmitsou: I had implemented a system that addresses points 2 & 3 of the above the list back in 2017. Since I'm not following KISS development anymore I do not know if the architecture for handling results has changed a lot since I wrote that code, but it likely didn't.
An interesting property of the system was that providers would not be able to stall the launcher by being slow to respond we displaying messages as everything was asynchronous. It also had the side-effect of making fast scrolling through the history much smother (it appears like the issue has already been resolved in the current codebase however).
Maybe you can take some inspiration from it:
https://github.com/alexander255/kiss-launcher/tree/refactor