This feature works well. We have a "Launch Action" mechanism ( |Bug#:
||175538) which should now be in a reasonable state
to hand back (I'll chase this up...) which uses this. Launch
Actions let you specify a sequential list of operations that should be run
before/after firing off the actual launch
platform feature, I've done this without requiring any code change of the
target launch configuration / delegate.
How this works is that the the
plugin registers a new mode type 'Launch Action Mode' and adds a 'Launch Action
Tab' to the target tab group; this tab sets the LaunchAction mode on
the launch configuration.
This means the Launch Actions
integration is delegated to by the platform Launcher. It runs
the users launch actions and calls back to the platform for the
original Launch Delegate that would have been run if
the 'LaunchAction' mode wasn't enabled. This allows this feature to
unobtrusively 'hijack' any launch type.
Even better, if there is no
delegate supporting the 'LaunchAction' launch mode, the platform prompts to
The different launch implementations can contribute their own tabs,
and there can be tabs which are shared.
Marc Khouzam wrote:
you know if we can tweak the UI a bit or it must be completely
Forwarding to CDT
I discovered yesterday that
platform has a mechanism for different debuggers to share the same launch
configuration UI in a clean way. This mechanism may what we need to put
some sanity into managing the launch UI between CDT, DSF, and various
> I finished my test pass and it was definitely a very educational
> experience. One feature I didn't even know about was the ability to
> have multiple launch delegates registered for the same launch
> configuration, and I'm rather curious about its background. Is the
> intention behind it to allow completely different debugger
> implementations to share the same spot in the launch dialog?
Yes - this allows different tooling to be provided for the same feature.
For example, two different Java profilers that can launch Java Application
launch configurations. Not only can they launch/share the configuration,
they can contribute extra tabs to the configuration. The user can decide
which tool to use for a given config type/launch mode in user preferences
(or they will be prompted to choose one at launch time).
> The use case I'm thinking of is the launch configurations in CDT.
> Currently if the user installs both the CDI-based GDB implementation
> and a DSF-based implementation, he will see both launch
> configurations in the dialog, which is rather ugly.
If the configurations contain the same information (i.e. enough common
info that either tool could launch them) then the above feature could be
used. The user would just have to choose a "preferred launcher" in the
platform-debug-dev mailing list
dsdp-dd-dev mailing list