Plugin API: What should `panels.show` and `panels.visible` do on mobile?

Development Plugins
, ,
1

Summary

In the mobile plugin API, joplin.views.panels.show and joplin.views.panels.visible don't work as they do on desktop. At present, when buttons with location ToolbarButtonLocation.NoteToolbar registered by plugins shown on mobile, this leads to non-functional buttons for plugins including Outline, History Panel, and Link Graph UI:

screenshot: The last three items in the note actions menu ("toggle outline", "toggle history panel", and "show/hide graph view" are highlighted and labeled "Unless API changes are made or plugins are updated, these buttons won't work"
screenshot: The last three items in the note actions menu ("toggle outline", "toggle history panel", and "show/hide graph view" are highlighted and labeled "Unless API changes are made or plugins are updated, these buttons won't work"1366×1120 84.7 KB

The goal of this post is to receive feedback on how this API might be changed to better support plugins that show panels on mobile.

Current API functionality

joplin.views.panels.show

  • On desktop, joplin.views.panels.show(panelId, visible) can be used to show or hide a plugin panel.
  • On mobile, joplin.views.panels.show does nothing.

Unlike Joplin desktop, Joplin mobile shows all plugin panels in a tabbed dialog:

screenshot: arrow from puzzle piece icon in toolbar leads to a pop-up window with tabs along the bottom and a close button near the top right.
screenshot: arrow from puzzle piece icon in toolbar leads to a pop-up window with tabs along the bottom and a close button near the top right.1386×1164 126 KB

By default, mobile plugin panels are included in the dialog. Because .show(panelId, visible) does nothing on mobile, these panels can't be removed from the UI without restarting Joplin (or disabling the plugin that created the panel).

If there are no panels, the toolbar button isn't shown.

Problems with the current implementation:

  • The "Toggle Panel" menu buttons shown above currently do nothing because joplin.views.panels.show does nothing.
  • There are cases where it doesn't make sense to allow a user to open a plugin panel. The Outline plugin, for example, has an "autohide" setting.

joplin.views.panels.visible

On both desktop and mobile, panels.visible(panelId) returns true if a panel is currently visible to the user. On mobile, this means that it returns true when the plugin panel viewer is open and the panel is in the currently open tab.

Some plugins use this to determine whether their "toggle panel" toolbar button should show or hide their plugin. Other plugins might use panels.visible to determine whether it's possible to communicate with a panel (or if it needs to be shown first).

Problems with the current implementation:

  • Suppose that .show is implemented to change whether a plugin panel can be opened from the mobile UI. If this is the case, .visible will return false even after calling .show(panelId) because .show only makes it possible for a user to show the panel (and doesn't open the panel dialog).
  • Some plugins rely on .visible to decide what their "Toggle panel" button should do. If .show is implemented to allow adding/removing a panel from the plugin panel window, some plugins' "Toggle panel" buttons will do nothing. For example, this seems to be the case for the History Panel plugin.

Overview & questions

On mobile, I plan to make joplin.views.panels.show show or hide a plugin panel from the UI. With this, .show(panelId, false) will prevent a user from opening a plugin panel in the UI on mobile until .show(panelId, true) is called.

However, I would like feedback on what .visible should do:

  • On mobile, should 1) .visible return true when a plugin panel is visible to the user (and false otherwise)? Instead should it 2) return true when a panel can be shown by the user?
    • Option 2 should allow existing plugins "Toggle panel" buttons to work on mobile (rather than being nonfunctional). Option 1 is a better match for the name of the method (.visible).
  • Would it make sense to add a new .openableByUser (or similar method with a different name) that returns true when a user can open a plugin panel from the mobile UI?

Thanks in advance for any feedback or suggestions!

2 Likes
2

Option 2 is more intuitive to me. Keeping the mobile and desktop plugin APIs and logic similar to one another is a huge advantage. In addition, I think that a common practice (to some extent) for a plugin is to check whether a panel is visible when a note is being opened, before updating the panel content (bcause this may involve an unnecessary nontrivial computation). It makes sense both on mobile and desktop to use the same logic to decide whether to update the panel. As long as a panel can be viewed by the user, and the user intentionally kept the panel on, I would expect its content to be up to date both on mobile and on the desktop (and therefore it makes sense to use the same attribute to make the decision on both platforms). Just my 2 cents.

1 Like