A script can register a callback through registerUserActionsMenu to be
informed when the UserActionsMenu is about to be shown. This menu calls
the Scripting component to gather actions to add to a Scripts submenu.
The Scripting component now asks all scripts for the actions, which will
invoke the registered callbacks with the Client for which the menu is to
be shown as argument.
The callback is supposed to return a JSON structure describing how the
menu should look like. The returned object can either be a menu item or
a complete menu. If multiple menu items or menus are supposed to be added
by the script it should just register multiple callbacks.
The structure for an item looks like the following:
{
text: "My caption",
checkable: true,
checked: false,
triggered: function (action) {
print("The triggered action as parameter");
}
}
The structure for a complete menu looks quite similar:
{
text: "My menu caption",
items: [
{...}, {...} // items as described above
]
}
The C++ part of the script parses the returned object and generates
either QAction or QMenu from it. All objects become children of the
scripts QMenu provided by the UserActionsMenu.
Before the menu is shown again the existing menu is deleted to ensure
that no outdated values from no longer existing scripts are around. This
means the scripts are queried each time the menu is shown.
FEATURE: 303756
FIXED-IN: 4.10
REVIEW: 106285
All methods and variables related to the User Actions Menu
(rmb window deco, Alt+F3) is moved out of the Workspace class
into an own UserActionsMenu class.
The class needs only a very small public interface containing
methods to show the menu for a Client, closing the menu and
discarding the menu. Everything else is actually private to the
implementation which is one of the reasons why it makes sense
to split the functionality out of the Workspace class.
As a result the methods and variables have more sane names and
the variable names are standardized.
REVIEW: 106085
BUG: 305832
FIXED-IN: 4.10
Martin Gräßlin