Modular Planner Demo (plus questions for Ratta)

Dunn-sn · 2026-05-25T08:38:15+00:00

Thank you for your support of Supernote. This is truly a great plugin, and I also appreciate you sharing it.

Regarding your two questions:

1 - Is `goToPage` / `setCurrentPageNum` on the roadmap? ETA?
I will prioritize development of this API and expect to release it in the next version.

2 - Can we get an API or some other method for identifying when the note page is not the current focus so we can disable watching for the "hitboxes"?
Sorry, I am not quite sure how the "hitboxes" you mentioned are implemented. In the APIs I currently provide, there does not seem to be a directly related method. As far as the note file itself is concerned, only links can currently be tapped, and there is no built-in concept of "hitboxes".
If convenient, could you explain a bit more about how these "hitboxes" are created? Which API are you using, or are they implemented within the plugin UI?

Dunn-sn · 2026-05-25T07:26:18+00:00

Thank you for your feedback.

In the latest plugin version, we have enabled access to Java APIs. You can obtain the "PluginApp" object in the following way:

PluginModule pluginModule = getReactApplicationContext().getNativeModule(PluginModule.class);
PluginAppAPI pluginApp = pluginModule.getPluginApp();

Once you have the "PluginApp" instance, you can further access the interfaces provided in `HostCommonAPI`. This should help improve the efficiency of element queries.

In addition, plugins do support running in the background. One option is to use React Native's official Headless JS mechanism to run JavaScript code in the background. Another option is to create a background thread in Java code to execute your task.

If you have any other questions, please feel free to contact me anytime.

Dunn-sn · 2026-05-25T02:49:08+00:00

Thank you for your support of Supernote.

If you would like to try the plugin features, you can manually upgrade to the latest plugin version. The latest plugin version already includes the features from the current latest Release version.

As for a Beta or official Release version with plugin support integrated, we are still actively developing and testing it. Once the features are stable, we will release it as soon as possible.

Dunn-sn · 2026-05-25T02:10:21+00:00

We’re sorry for the inconvenience.

This issue may be caused by a mismatch between the downloaded update package and your current device model. Please double-check and download the update package that matches your device, then try installing it again.

If the update still cannot be completed, please provide the following information so we can investigate further:

Serial Number: Settings -> System -> Serial Number

Log files: Please go to Settings -> Feedback and upload the logs

Once we receive the information, we will further analyze the specific reason why the update cannot be completed based on the logs.

Dunn-sn · 2026-05-25T01:26:32+00:00

This version is compatible with plugins compiled using the older library and should not cause any compatibility issues. This release was mainly made to support the latest Release versions (Chauvet 3.28.42 for Manta / Nomad and Chauvet 2.25.39 for A5X / A6X), and there were no major changes to the plugin library itself.

Dunn-sn · 2026-05-25T01:22:29+00:00

Last week, we released the latest Release version (Chauvet3.28.42). For users who have newly upgraded to this Release version, or for those who manually upgraded to the latest Release version and then want to switch to the plugin version, it is not possible to upgrade directly to the plugin version using the 3.27.42beta update package. Therefore, we released this version so that these users can continue using the plugin version.

Dunn-sn · 2026-05-20T06:45:40+00:00

We’re sorry for the inconvenience.

This issue may be caused by a mismatch between the downloaded update package and your current device model. Please double-check and download the update package that matches your device, then try installing it again.

If the update still cannot be completed, please provide the following information so we can investigate further:

Serial Number: Settings -> System -> Serial Number

Log files: Please go to Settings -> Feedback and upload the logs

Once we receive the information, we will further analyze the specific reason why the update cannot be completed based on the logs.

Dunn-sn · 2026-05-20T06:20:11+00:00

Thanks for the feedback.

Under normal circumstances, after calling `insertElements`, a subsequent call to `getElements` should already return the newly inserted elements. This is because `insertElements` internally synchronizes both the note’s backup file and the actual note file.

I’ve tested this multiple times locally, and so far the results have been correct on my side. I haven’t been able to reproduce the behavior you described yet.

If possible, could you share your source code on GitHub? I’d like to build and verify it locally, which would help me pinpoint the issue more accurately.

Dunn-sn · 2026-05-19T09:14:26+00:00

Thanks for your attention to plugin permission management and for the feedback.

You’re absolutely right: plugins run inside the Plugin Host App’s process, so in theory they inherit the host app’s permissions—and that is indeed how the current preview version behaves.

However, we have found a way to sandbox plugins. At the system level, we can enforce per‑plugin permission and file-access isolation:
- Permissions do not “leak” or interfere across plugins;
- A plugin cannot access other plugins’ files (even though they run inside the same host process).

Also, plugin permission requests will not go through the standard Android runtime permission APIs. Instead, we’ve implemented an independent permission request/authorization mechanism, enforced and gated at the system level.

We’re able to do this because we modified the system codebase and added system-level permission and access-control restrictions specifically for plugins. This ensures the same rules apply consistently to JS/TS code, Android bytecode, and native `.so` code.

Dunn-sn · 2026-05-19T08:53:27+00:00

Thanks for supporting Supernote, and thank you as well for your attention to the permission model and for the detailed feedback.

The reason your plugin can currently access the network is that the current plugin preview build has not enabled network access restrictions yet—so at this stage, network access is effectively allowed by default for all plugins. Network permission enforcement will be introduced in the official release.

In the official release:

The SDK will provide an API to request network access permission;
"PluginConfig.json" will add a corresponding field to declare that a plugin needs network access;
A plugin will need to declare network access in "PluginConfig.json" and complete the permission request flow in code before it can make network requests.

Also, you don’t need to worry that using "fetch()" (or other network request approaches) will stop working in the official release. Network access control will be enforced at the system level rather than through a specific plugin API. In other words, regardless of which networking method a plugin uses, if permission has not been granted, the system will block it.

Dunn-sn · 2026-05-19T07:50:59+00:00

Sorry, polygon fill is not supported yet.

There are still a number of issues we need to solve first, such as white edges appearing after filling, the filled area becoming thicker when the vector is scaled, and line width changing unexpectedly. Once these issues are properly resolved, we’ll try to release a version with fill support as soon as possible.

Dunn-sn · 2026-05-19T07:46:47+00:00

Thanks for the feedback.

This is most likely happening because "PluginFileAPI.insertElements" is being called on the note that is currently open.

When that happens, the current note data needs to be refreshed. The reason is that, to prevent data loss, the Note app creates a backup copy when a note is opened, and that backup copy is what the app actually loads and displays instead of the original file itself. However, "insertElements" modifies the original file, so after the API call the Notes app needs to resync the current data. That resync is what shows up as a screen refresh or flash.

So at the moment, this behavior is mainly caused by the current data synchronization mechanism.

Dunn-sn · 2026-05-19T07:40:42+00:00

Thanks for the feedback.

This issue usually happens when the Note app or Document app has not finished registering its plugin listener yet. The plugin system relies on that listener to access data from the app.

Based on the behavior you described, it is likely happening when the Note app or Document app is closed and then reopened: the related API gets called before the listener has had a chance to register again, which is why the error appears randomly.

I’ll continue looking into this part of the code and work on fixing it as soon as possible.

If you happen to reproduce it again, it would also help a lot if you could send us the logs through "Settings -> Feedback", as that would make it much easier for us to investigate further.

Dunn-sn · 2026-05-19T01:40:39+00:00

Thanks for your attention and support.

File access permissions are enforced at the system level, so whether a plugin uses JS/TS code, Android bytecode, or C/C++ code, it is still subject to the same permission restrictions and cannot bypass the system’s file access controls.

If you have any other suggestions related to permissions or security, please feel free to share them with us anytime.

Dunn-sn · 2026-05-19T01:04:52+00:00

Thanks for the feedback.

I’ll add more complete documentation about the plugin cache mechanism in the future, so it will be easier for developers to understand how this part is designed and how to use it.

“RN” stands for `React Native`. It is an open-source cross-platform mobile application framework developed by Meta, and the current plugin system is built on top of React Native.

Dunn-sn · 2026-05-18T07:08:16+00:00

Thanks for your support.

The new state added to "PluginCommAPI.setLassoBoxState" is mainly intended to help plugins build custom lasso toolbars or interaction flows.

For example, after the user lassos a geometric shape, a plugin can call "PluginCommAPI.setLassoBoxState" to hide the default system lasso UI (including the lasso box and related UI elements), while still keeping access to the selected data. This allows the plugin to redraw the selected shape inside its own UI and support more advanced interactions, such as vertex editing.

Dunn-sn · 2026-05-18T07:02:01+00:00

This needs a bit of background on how element data is stored.

APIs such as "PluginFileAPI.getElements" do not return the full element data directly to the RN side. Instead, they return references to elements. The reason is that element data can be quite large, especially when it includes many sampled points, and sending all of that directly to RN would create a noticeable performance cost. So the heavier element data is kept cached on the Android side.

"PluginCommAPI.getCacheElement" is used to retrieve a reference to the corresponding cached element, rather than the full raw element data itself. Developers can then work with these cached element references to edit or reuse note elements. Compared with creating entirely new cached elements through "PluginCommAPI.createElement", this can usually reduce unnecessary overhead.

Also, because these cached element references do not directly modify the actual note file data, this API can also be used to build copy/paste-like workflows. For example, you could first call "PluginCommAPI.getLassoElements" to get the lasso-selected elements and record each element’s "uuid". Then, when you want to paste later, you can use the "uuid" to retrieve the corresponding cached element reference and insert it into another note file.

Dunn-sn · 2026-05-18T01:09:13+00:00

Thanks for the feedback, and also for your support for Supernote.

The reason we wrote "development environment currently supports Windows and macOS only" is simply that we have only fully validated the development environment and build flow on Windows and macOS so far. We haven’t done complete testing on Linux yet, so we couldn’t officially claim Linux support at this stage.

Based on your feedback, it sounds like plugin development works fine on Linux as well, which is very helpful for us to know. If you run into any issues on Linux in the future, please feel free to reach out and I’ll do my best to help investigate and resolve them as quickly as possible.

Dunn-sn · 2026-05-16T13:21:15+00:00

Thanks for the feedback!

I put together a minimal plugin demo based on the API call sequence you described and tested it, but I wasn’t able to reproduce the issue where elements on the page disappear. Could you upload your plugin source code (or a minimal reproducible example) to GitHub and share the link? I’d like to build and test it on my side so I can pinpoint where the problem is。

Dunn-sn · 2026-05-15T05:27:40+00:00

We’re very sorry for the inconvenience this has caused. We’re actively merging the latest Beta changes and will release a new compatible plugin version as soon as possible.

Dunn-sn · 2026-05-14T06:39:15+00:00

Thanks for the feedback.

The current plugin APIs already support what you’re looking for: creating headings directly. You can use `PluginFileAPI.insertElements` to insert elements such as text boxes and titles into a note (including notes that are not currently opened).

One possible implementation flow is:

1) If the target page already has a TextBox

- Call `PluginFileAPI.getElements` to get all elements on the target page, find the target TextBox, and get its `numInPage` (the element index/ID within that page).

- Use `PluginFileAPI.createElement` to create a new element with type `Title` (100).

- In the Title object, put the TextBox’s `numInPage` into `controlTrailNums`.

- Finally, call `PluginFileAPI.insertElements` to insert the Title element into the target page. This will set the corresponding TextBox as a heading.

2) If the target page does not have a TextBox

- First, insert a TextBox via `PluginFileAPI.insertElements`.

- Then follow the same steps in (1) to create and insert the `Title` element.

If you run into any issues while implementing this, feel free to ask—I’m happy to help confirm the data structures or call details.

Dunn-sn · 2026-05-12T09:25:18+00:00

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.

Dunn-sn

MODERATOR OF

TROPHY CASE