[javascript] add menu item to ribbon UI

[Mathew]

The app.addMenuItem() and app.addSubMenu() functions add javascripts to menus in the classic UI but there's no equivalent for the ribbon UI. The only place we can add anything on the ribbon is to the Addon Tools, as far as I can tell.

Could PDF-XChange add a way to do this? I have a lot of small scripts I use within the Editor, and the Addon tools are getting very congested, plus the tools would fit better into other contexts (such as Comment, Organize, Bookmarks, etc).

[Mathew]

Possible approach: An additional parameter -- such as "cParentRUI" and "nPosRUI"-- that could be ignored by applications that don't support it. If both parameters were supplied, then both UIs would know where to put the menu item if the UI is changed.

[TrackerSupp-Daniel]

Hello, Mathew

Sorry for the long delay in a reply here, The dev team have agreed to have a think about this. But that have also informed me that it is, unfortunately, a low priority item at this time. Nonetheless I have made a formal ticket for you on this.

RT#6655: FR: JS add-tool to other ribbon tabs.

Kind regards,

[Mathew]

Thank you

[TrackerSupp-Daniel]

[Mathew]

The more I bump into this one, the more I think Adobe's old approach to this is in need of an update. They came up with it before anyone had the ribbon, and it also doesn't allow for things like assigning shortcuts, or letting people rearrange their menus the way that suits them.

I know this is a low priority item, but it will add to the overall usability of the software.

When you do start looking at this, I'm thinking that javascript should just be suggesting a location, but that really what javascript would do is add a tool with a default location, but that can be moved or assigned a keyboard shortcut in the same way anything else is changed in Customize...

[TrackerSupp-Daniel]

Hello, Mathew

The difficulty with such actions is that the JS is not "kept in place" or recorded between sessions, it needs to be reloaded each time the application starts. This requirement of reloading the Js files themselves inherently prevents storing any "external" customizations beyond what is present in the JS itself for button customization/naming.
While we may be able to expand placement (as the ticket requests), so you can specify that a tool should appear on, for example, the "home" tab; Other tasks, like allowing manual movement, or hotkey assignment, would not work very well. The moment the software closes, that "instance" of the tool is destroyed, and so subsequent re-opening of the editor would move it back to its initial "home" and the hotkeys would need to be reassigned manually.

Trying to retain these hotkeys and button positions, with something as volatile as the presence of a named JS file that can be removed, replaced, duplicated, etc. at any time would be... "tricky" at best.

Kind regards,

[Mathew]

Hi Daniel,

I don't know what's going on "behind the scenes", but here are my thoughts on this:

• The UI currently allows one to change between Ribbon, Tablet or Classic UI and this happens after all the menus have been shown, so at that time, it is known which javascript tools are loaded.
• When javascript adds a tool it has to include a cName which according to the api is

  "A unique language-independent identifier for the button. The language-independent name is used to access the button for other methods (for example, removeToolButton). Note: The value of cName must be unique."

  Thus there is a way to map this menu item to an internal list of menu item locations and keyboard shortcuts.
• Currently the only properties that are not optional are cName, oIcon (or cLabel), and cExec. Thus the application needs to come up with a place to put the button already, and the provided location is only there as a way for the script to override a default location.
• When the application handles app.addToolButton(): If it has that cName stored, it could ignore the location given in the script and put it where the saved location is; if the cName isn't stored, then js has provided a default location.

I think the methods .addMenuItem() .addSubMenu() .addToolButton() are all out of alignment with how the UI is: In my mind there isn't a difference between them fundamentally. They are just adding a tool, and within the parameters it should be providing default location, icon, etc.

[TrackerSupp-Daniel]

Hello, Mathew

Unfortunately it is precisely because of what happens "behind the scenes" that it is currently not possible to allow lasting customization between application sessions, so they are not enabled for customization at all, to prevent the chance of having that work ignored/reverted every time you re-launch the software.

As before, we should be able to expand the possible locations so that you can place these tools on any Ribbon tab or Classic Toolbar Via the JS, but at this point in time, customizing hotkeys and repositioning these tools after runtime is not possible.

Kind regards,

[Mathew]

Thanks for getting back about it. I still think PDFX-Change is second to none, and I'm continually blown away by the level of customer support. You're all fantastic. Keep up the good work. You all are very much appreciated.

[TrackerSupp-Daniel]