This is a rather obscure issue. It is perhaps one for the team in Adobe that have implemented flyout menus of uxp panels in InDesign. As I’ve no idea who they are or how to contact them, I am posting this here. Perhaps someone from Adobe might read this and draw it to their attention.
In trying to find a workaround to the issue of ’sticky’ submenus in the flyout menu (that I wrote about in this thread http://forums.creativeclouddeveloper.com/t/indesign-panel-flyout-menu-sticky-submenus-and-separators/8529), I have discovered a little about how these flyout menus are implemented in InDesign.
If you create a flyout menu in the panel of your uxp plugin, ‘under-the-hood’ a corresponding menu is created in InDesign. This, of course, makes sense – the flyout menu is an InDesign menu like any other.
In extendscript, and now uxp, we’ve always been able to access InDesign’s menus through app.menus.
So if the label of your uxp panel is ‘Abracadabra’, like this in your manifest:
"entrypoints": [
{
"type": "panel",
"label": {
"default": "Abracadabra"
},
you can get to the corresponding InDesign menu like this:
const myFlyoutMenu = app.menus.itemByName('Abracadabra');
Log it to the console, and you’ll see a menu containing all your flyout menu items, submenus, separators, etc.
That does give us a workaround for the ’sticky’ issue. In the destroy lifecycle hook of our plugin we can access the InDesign menu and remove the ’sticky’ submenus and menu separators ourselves. This works, but there is a caveat . . .
As an aside, the real solution for the ’sticky’ submenu/menu separator issue is for Adobe to do the removing in their implementation of these flyout menus. After all, it is as part of their implementation that this menu is created, so it should be part of their implementation that this menu is properly cleaned out when the plugin is destroyed. As a developer I shouldn’t have to go anywhere near this ‘under-the-hood’ menu.
The caveat, and what really surprised about how this has been implemented, is that the name of the ‘under-the-hood’ InDesign menu comes from the label of the uxp panel.
As a developer, it wouldn’t occur to me to think that I needed to come up with a unique label for my panel. After all, the label is just the title that shows up in the panel. I know to make my plugin id unique (so I use the com.wherebysoftware.whatever naming convention), but not the label of the panel.
What happens if the label of your panel happens to be the same as the label of another plugin’s panel? Or what happens if the label of your panel happens to be the same as the name of an existing menu in InDesign.
What happens is that all the menu items get muddled up in one InDesign menu!
If you create two plugins, each with a panel, the two panels labelled the same, what you see in both flyout menus is a menu (an identical menu) that contains all the menu elements from both flyouts.
And, please, DO NOT UNDER ANY CIRCUMSTANCES give your panel the label “Main” – you will seriously mess up the menus in InDesign (because “Main” is the name of the menu that runs across the top of the program).
I don’t know why Adobe have implemented it this way, nor do I know what is involved in implementing it, but it seems to me that with this implementation there is a risk, even if it is a small one, that a developer could write a plugin and quite inadvertently mess up the menu of another developer’s plugin or a menu of InDesign itself. (If, for instance, the ‘under-the-hood’ menu name were instead taken from the plugin id concatenated with the panel id, then I’m pretty sure you would have a unique id and therefore a unique menu, so no risk of cross-contamination.)
Philip
PS BTW if anyone is minded to mess about with this, resetting InDesign’s preferences does clear everything up.
