Bug 565549

Summary: Redefine IActionBars updateActionBars semantics to match common usage
Product: [Eclipse Project] Platform Reporter: Rolf Theunissen <rolf.theunissen>
Component: UIAssignee: Platform-UI-Inbox <Platform-UI-Inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3    
Version: 4.16   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard:

Description Rolf Theunissen CLA 2020-07-26 07:21:52 EDT
In the documentation of the IActionBars the following comment is present on almost all methods, where XYZ is specific for the method:
 * <p>
 * Note: Clients who XYZ list are
 * responsible for calling <code>updateActionBars</code> so that the changes
 * can be propagated throughout the workbench.
 * </p>

However, in practice hardly any client calls 'updateActionBars'. Most clients call 'update' directly on the returned IContributionManger. 
This is also in line with the documentation on the class, which doesn't mention 'updateActionBars':
 * Add the action(s) to the target and call <code>update</code> to commit
 * any changes to the underlying widgets.
Basically, the (E3) implemenentations of IActionBars only call 'update' on the provided IContributionManagers, only WWinActionBars might do something more.

In E4, updateActionBars is used to synchronize items added with E3 API back to the the model. However, as it is hardly called, inconsistencies will occur, see for instance Bug 564295). These inconsistencies result in all kind of issues, because the E4 model cannot be used as single source of truth.

Proposition is to make updateActionBars optional, and do the synchronization in the update calls of the provided ContributionManagers.

Only for the global action handlers, I don't know if the updateActionBars call is still required. It sends out a PropertyChangeEvent with 'P_ACTION_HANDLERS', there are only 2 listeners for this event. I can imagine that these calls are obsolete after the move to the command framework long ago.