FYI, noting this here because I just discovered it:
The 2nd point below also applies to translated strings. But using the .favourites_menu_unique_name property mentioned would mean that Favourites would not benefit from translated strings.
In practice, I don't think it's a big deal for anyone who chooses one language and sticks with it. But it did surprise me while testing translated language support.
Quote:
Originally Posted by kiwidude
Notes for other plugin developers- As of v1.0.3 Favourites Menu will support a plugin with its menus being rebuilt every time it is displayed (such as to enable/disable items based on the current state of calibre). The pattern for this is that your InterfaceAction class should have a .menu property representing the QMenu, and you will ordinarily have code hooked to the aboutToShow signal. When the Favourites Menu plugin is asked to dropdown will iterate through all of the child plugins it is being asked to display items for and (once per plugin) emit the iaction.menu.aboutToShow signal for any plugins that have such a .menu property.
- If your plugin changes the name of a child item dynamically this can cause a problem for the Favourites Menu plugin (as it uses the text name displayed by a plugin as part of the "key" identifying a menu item). For instance the Reading List plugin includes a count of the items in a child list for some of its actions. To ensure such menu items can be supported by the Reading List plugin, you should simply assign a constant identifying name for the menu item to a .favourites_menu_unique_name property on your qaction at the time you create it. The Favourites Menu plugin will look for such a property being present and use that in preference to the current text name if it is present.
|