launch bar launch target not populated into defaultlaunchdescriptors that support targets..

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

launch bar launch target not populated into defaultlaunchdescriptors that support targets..

Tad Adams

Hi All,

 

Have run into a bug with the way the launch bar code interacts with the launch descriptor. Specifically there are two places the launch bar component performs logic on the instance of the LaunchDescriptor:

1) If the launchDescriptor is an instance of DefaultLaunchDescriptor, the launch bar will not relegate the retrieval of the launch configuration to the provider

2) If the launch descriptor is an instance of DefaultLaunchDescriptor, the launch config dialog will label the delete button as delete, otherwise it will label it as “reset”, not “delete”

This has the implicit assumption that if you want the launch target pushed down to your provider to be populated into the configuration, then that launch must also undeletable, which is not always the case. The challenge/bug then becomes how to support injecting the launch target into the launch configuration but still allow the launch configuration to be presented as one that can be deleted.

 

I believe the issues are here:
<a href="https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/launchbar/org.eclipse.launchbar.core/src/org/eclipse/launchbar/core/internal/LaunchBarManager.java#n322 In">https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/launchbar/org.eclipse.launchbar.core/src/org/eclipse/launchbar/core/internal/LaunchBarManager.java#n322

In the method getLaunchConfigurationType, it will return without pushing the request down to the LaunchConfigurationProvider if the launchDescriptor is an instance of DefaultLaunchDescriptor, which then implies only non DefaultLaunchDescriptors are capable of supporting targets. From what I can tell from the source code, this method represents the single mechanism that pushes the target down into the configuration. I would propose rather then look solely at the instance of the DefaultLaunchDescriptor, the type should be introspected, specifically if:

desc.getType().supportsTargets() == true, in that case, the method should not return early, it should proceed on to the third if statement and push the request down to the providers.


The second point of the labelling of the delete button as “reset” or “delete” occurs here:

https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/launchbar/org.eclipse.launchbar.ui/src/org/eclipse/launchbar/ui/internal/LaunchBarLaunchConfigDialog.java#n252

 

Here, I believe something new is required, the ILaunchDescriptor interface would need a “canBeDeleted()”,  method added to it, to determine which label should be selected.


The short version of all of that is currently the launch target on a launch triggered from the launch configuration will only push the target into the configuration if the launch descriptor is not an instance of DefaultLaunchDescriptor, but making the descriptors be an instance other than DefaultLaunchDescriptor will result in the dialog always showing  a “reset” button, rather than a “delete” (while the functionality is always implemented as a delete regardless of the label). Basically those two aspects have been tied together, where they should not have been.

The only other approach I see would be to “pull” the launch target out of the launch bar, but that is problematic because all launches are not triggered necessarily from the launch bar (ie launch could occur from standard Run As… dialog), and an instance of a launch does not know from  which it originated.

 

Has anyone run into the limitation, and implemented any viable workarounds? If not would a pull implementing the suggestions I made here be appropriate?

Regards,

Tad


This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launch bar launch target not populated into defaultlaunchdescriptors that support targets..

Jonah Graham
Hi Tad,

I don't know if anyone has run into this limitation. As Blackberry were the initial developers of this you are probably in the best position to resolve this issue. Therefore I welcome a gerrit with your recommended solution to this problem. Please file a bug containing the below information and submit a gerrit.

If you have any code cleanup recommendations for that part of the code base please provide additional gerrits for that too!

Thanks,
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 25 Feb 2020 at 15:48, Tad Adams <[hidden email]> wrote:

Hi All,

 

Have run into a bug with the way the launch bar code interacts with the launch descriptor. Specifically there are two places the launch bar component performs logic on the instance of the LaunchDescriptor:

1) If the launchDescriptor is an instance of DefaultLaunchDescriptor, the launch bar will not relegate the retrieval of the launch configuration to the provider

2) If the launch descriptor is an instance of DefaultLaunchDescriptor, the launch config dialog will label the delete button as delete, otherwise it will label it as “reset”, not “delete”

This has the implicit assumption that if you want the launch target pushed down to your provider to be populated into the configuration, then that launch must also undeletable, which is not always the case. The challenge/bug then becomes how to support injecting the launch target into the launch configuration but still allow the launch configuration to be presented as one that can be deleted.

 

I believe the issues are here:
https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/launchbar/org.eclipse.launchbar.core/src/org/eclipse/launchbar/core/internal/LaunchBarManager.java#n322

In the method getLaunchConfigurationType, it will return without pushing the request down to the LaunchConfigurationProvider if the launchDescriptor is an instance of DefaultLaunchDescriptor, which then implies only non DefaultLaunchDescriptors are capable of supporting targets. From what I can tell from the source code, this method represents the single mechanism that pushes the target down into the configuration. I would propose rather then look solely at the instance of the DefaultLaunchDescriptor, the type should be introspected, specifically if:

desc.getType().supportsTargets() == true, in that case, the method should not return early, it should proceed on to the third if statement and push the request down to the providers.


The second point of the labelling of the delete button as “reset” or “delete” occurs here:

https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/launchbar/org.eclipse.launchbar.ui/src/org/eclipse/launchbar/ui/internal/LaunchBarLaunchConfigDialog.java#n252

 

Here, I believe something new is required, the ILaunchDescriptor interface would need a “canBeDeleted()”,  method added to it, to determine which label should be selected.


The short version of all of that is currently the launch target on a launch triggered from the launch configuration will only push the target into the configuration if the launch descriptor is not an instance of DefaultLaunchDescriptor, but making the descriptors be an instance other than DefaultLaunchDescriptor will result in the dialog always showing  a “reset” button, rather than a “delete” (while the functionality is always implemented as a delete regardless of the label). Basically those two aspects have been tied together, where they should not have been.

The only other approach I see would be to “pull” the launch target out of the launch bar, but that is problematic because all launches are not triggered necessarily from the launch bar (ie launch could occur from standard Run As… dialog), and an instance of a launch does not know from  which it originated.

 

Has anyone run into the limitation, and implemented any viable workarounds? If not would a pull implementing the suggestions I made here be appropriate?

Regards,

Tad


This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev