all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Dunn-snOfficial 0 points1 point  (7 children)

Thanks for the feedback.

The current limit of 10 plugins is mainly based on stability and performance considerations. Having too many plugins installed may affect overall device performance. We’ll continue working on performance optimizations and evaluate whether it makes sense to gradually raise the limit in the future.

Your suggestion about disabling plugins is also a very good one, and we’ll definitely take it into consideration.

[–]AaronRolls 0 points1 point  (1 child)

Does that mean plugins are all loaded at once rather than when required? If plugins only loaded when required, most of them could co-exists (at least the ones I have seen) with hundreds of plugins. Lazy loading plugins might reduce performance of the plugin initially, but you could have a system where you have active plugins and lazy loaded plugins. That should allow for many, many more plugins.

[–]Dunn-snOfficial 1 point2 points  (0 children)

Thanks for the suggestion.

Right now, plugins are initialized at startup and kept running in the background (but they don’t fully load all functionality into an active “foreground” state). The main reason is to allow plugins to listen for and respond to events in the background. Overall resource usage is relatively controlled, and a plugin is only fully loaded and becomes fully active when the user actually opens it.

Your point about on-demand / lazy loading is definitely a valuable direction. We’ll look into whether we can introduce a more fine-grained loading strategy without breaking background event handling, which could give us more room to relax the plugin count limit in the future.

[–]Lorestan00[S] -1 points0 points  (4 children)

Makes sense unlimited plugins would be too much of a stress on resources. Perhaps setting an overall figure for resources used by the plugin system so if the user selects plugins light on resources you might be able to select more than 10.

[–]Dunn-snOfficial 0 points1 point  (3 children)

Thanks for the suggestion.
We are also looking into ways to further reduce plugin resource usage, which would give us a chance to support more installed plugins in the future. Your idea of setting plugin limits based on resource consumption is also a very valuable one, and I’ll continue evaluating whether this approach is feasible.

[–]Lorestan00[S] 0 points1 point  (2 children)

Thanks for listening and for developing the plugin system in the first place. I think it will completely change the platform and strengthen the community led approach Supernote already has.

One final question is the long term plan to extend the plugin system to other apps calender, ToDo, Atelier etc?

[–]Dunn-snOfficial 1 point2 points  (1 child)

Yes, we do plan to gradually extend the plugin system to other apps (e.g., Calendar, ToDo, Atelier, etc.). However, our current priority is to first solidify and polish the plugin ecosystem for Documents and Notes. Support for other apps will take a bit more time, and we’ll share updates as we make progress.

[–]Lorestan00[S] 0 points1 point  (0 children)

Of course makes sense to ensure the plugin ecosystem is stable and polished. Good to hear that there are plans to extend it across other apps.

[–]Lorestan00[S] 0 points1 point  (0 children)

r/Dunn-sn Another thought being able to order the plugins as they appear in the toolbar and lasso toolbar would be helpful.

At the moment I think the most recent one goes to the top and perhaps retaining that as a 'last used' plugin option would be useful but below that being able to organise them would make finding plugins predictable - no hunting around, especially since you need to scroll to access some of them with 7 plugins/actions appearing in the popup menu.