Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-debug-dev] Proposal to change ILaunchConfigurationTab interface


To allow tabs to be more selective in their updating, and ultimately more efficient, we are propsing a change (additional methods) to the ILaunchConfigurationTab interface. Some related bugs are:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=43952
https://bugs.eclipse.org/bugs/show_bug.cgi?id=43387
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37332

Currently, the launch dialog framework inherently supports inter-tab communication by having each tab "apply" its state to a launch configuration when it is exited, and having each tab "initialize" its state when it is entered. This is done with the #performApply() and #initializeFrom() methods. However, these methods can be costly (i.e. in terms of efficiency). As well, a tab is not able to distinguish between displaying the contents of a newly selected configuration (or a reverted configuration), versus a tab exit/enter. To improve this, we are proposing the addition of two new methods to the ILaunchConfigurationTab interface:

public void tabEntered(ILaunchConfigurationWorkingCopy)
public void tabExited(ILaunchConfigurationWorkingCopy)

The framework will call the new #tabExited() method when a tab is exited. Generally, a tab should update the configuration with any of its new values when it is exited. When a tab is entered, the new #tabEntered() method will be called. If the tab relies on values that may have been set elsewhere, the tab needs to update accordingly (but the decision is up to the tab). The framework will continue to call #initializeFrom() whenever a new config is displayed (or a config is reverted to its original state). As well, #performApply() will be called when a config is saved.

The new methods will be implemented in the abstract base class (AbstractLaunchConfigurationTab) as follows.

* the #tabEntered() method will by default, have no action
* the #tabExited() method will by default, call performApply()

Generally, the only breakage that will result from this API change is in the behavior of tabs that perform "inter-tab" communication (i.e. rely on attributes set elsewhere from the tab). The simply fix is to override #tabEntered() to call #initializeFrom(). Ideally, tabs should only update attributes selectively when the #tabEntered() method is called.

Please advise of any concerns on this issue. We'd like to get this change into the Milestone 5 release.

Thanks,

Darin

Back to the top