UI Components Shared by Different Debugger Implementations


  1. Every debugger can provide a set of windows and toolbar actions per debugger engine.
  2. For every window and toolbar action it can be specified whether it should be opened by default when that engine is started or not. All engine-related windows and toolbar actions are closed when the engine exits unless they are used by other running engines.
  3. Only windows and toolbar actions provided by running debugger engines are shown, unless explicitly opened by the user.

Current (6.5) Solution

  • Debugger Engine can provide a set of components in it's lookup by registering implementations of BeanContextChildComponentProxy. If the component implements DesignMode, it's asked via isDesignTime() if it should be opened by default or not. It fulfills all requirements for debugger windows, but does not care about Toolbar actions. It does not have an explicit API.
  • When any debugger engine is started, "Debugging" toolbar configuration is opened, which contain "Debug" toolbar. Debug toolbar contains actions from all registered debugger engines. The engines can add actions into the toolbar. But the Debug toolbar shows actions from all engines all the time. Requirements (2) and (3) are not fulfilled.

Possible Solutions

  1. Every engine or session type defines a toolbar configuration with it's own session-type specific debug toolbar. That toolbar contains only actions specific for the given session.
    Although this approach is simple, it has several problems:
  • All session-type specific debug toolbars are visible by default, even when defined in specific configuration. There can easily occur two or more debugger toolbars from different configurations.
  • When there are two or more debug sessions running simultaneously, the toolbar configuration needs to be changed on every change of the current session. This is not a conceptual problem, but the toolbar can be resized do to that change.
  1. Every engine or session type declares a service that defines the specific actions that should occur in the Debug toolbar. When a session is started, the Debug toolbar is opened with the default set of actions (union of all registered actions), but if the service is present, only actions provided by that service are visible.
  • The problem is, that the debugger implementation has to declare the toolbar actions in mf-layer.xml under Toolbar/Debug and also fill the actions it wants to be visible in this service.
  1. We find which toolbar actions the module declares in the toolbar and made all others as not visible.
  • Provided that we'd be able to implement this, it fulfils all requirements. This approach has also an advantage that only core Debugger UI module could define the toolbar content (Toolbars/Debug in mf-layer.xml) and other debugger implementations can only add their actions there, if necessary.

Proposed Solution for 7.0

Based on the solution (3). We can hardly detect which actions are actually declared by the debugger implementation module in mf-layer.xml. But we know which ActionProviders are registered by the engine. If we can match the toolbar buttons to the actions provided by the ActionProvider, we could show only buttons that are used by the engine.

With a piece of luck, we can find what Action is behind the toolbar button. But the only mapping from Action to the action constants (ActionProvider.getActions()) is done by DebuggerAction, which is not in the APIs. DebuggerAction can be handy anyway for debuggers that would need to introduce their own specific action. Therefore DebuggerAction should be added into the API and used to bind the action objects to the Action.

Then spi.debugger.ui module (Debugger Core UI) would define the content of Toolbar/Debug. The content would be actually copied from debugger.jpda.ui. All other debugger modules would not have to define the toolbar content (see Issue 148733) unless they need to add some actions there. And if they do so, they should add instances of DebuggerAction so that they can be removed from the UI for others.

This solution does not handle cases when a DebuggerEngine defines ActionProviders for some actions, but does not want to make them visible in the Debug toolbar. For this case an API change is necessary - ActionProvider will have a method
. DebuggerAction is made public, with the exception of {createXXX()} methods.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo