Community
Participate
Working Groups
3.7 M7. If the user already has a workspace at <chosen default> + "New_configuration" then the 'append' feature won't work. We should update the location if the configuration is newly added.
We should try to find a fix for RC1.
The launch configuration handling in the launch configuration dialog is a bit messy: - as soon as one adds a new one, it gets saved instead of staying a working copy (==> launch configuration stays, even if I cancel the dialog) - the information about whether a launch config is old, new or duplicated is not available - transient attributes on the working copy are not possible: all attributes are considered persistent ones This patch add a new launch configuration attribute (to me made API in 3.8) which is then consumed by PDE to decide whether a launch configuration is new or not. Pawel or Mike: can you check the Debug part of the patch? The only thing I'm not 100% sure is whether saving again on close might do some harm.
Created attachment 195222 [details] Fix
This patch makes the workspace location auto-update more predictable for the user as it now only (but consistently) happens for new (but not duplicated) launch configurations and no longer depends on whether there's already a resource on disk at that location.
> If the user already has a workspace at <chosen default> + "New_configuration" > then the 'append' feature won't work. Some updated steps: 1. create a new Eclipse launch configuration - location correctly has name appended 2. select the new configuration and duplicate it - location is the same as the original and does not have the duplicated name appended
I'm not sure how I feel about the platform debug changes for 3.7. I think, if anything, for 3.7 this should be a PDE-only fix. Perhaps a new attribute to know if the user has edited the location field? If the user has not edited the field (based on the new flag attribute), auto-update the location value in the initializeFrom call-back in WorkspaceDataBlock.
(In reply to comment #6) > I'm not sure how I feel about the platform debug changes for 3.7. > > I think, if anything, for 3.7 this should be a PDE-only fix. We need to know whether the launch configuration is new. I'd be very happy to hear how this can be done with a PDE only code change :-)
(In reply to comment #6) > I'm not sure how I feel about the platform debug changes for 3.7. What part(s) of the fix worries you?
I don't think the extra save should do any harm. In the worst case it would just cause some extra processing by launch listeners. I'm not as familiar with the launch configurations handling as Mike though.
> What part(s) of the fix worries you? I guess the biggest concern is adding a new attribute this late in the game. > We need to know whether the launch configuration is new. I'd be very happy to > hear how this can be done with a PDE only code change :-) What if we added a new attribute like loc_edited=false during the #setDefaults call-back, then if the user manually edits the location we set it to loc_edited=true. Then say you wanted to duplicate the configuration; in the the #initializeFrom call-back you ask "is it the default (loc_edited == false) or has the user changed it (loc_edited=true)?", if it is the default, generate a new location attribute with the current name. The down-side of this fix is that each time #initializeFrom is called you will check this new attribute, but the impact would be minimal.
>I guess the biggest concern is adding a new attribute this late in the game. I don't see a risk with that. The only thing I was not 100% sure is the additional save which can trigger event. Mike, I like your suggested solution. The only difference will be that as soon as the user applies/saves the changes, he locks the launch configuration. One could even see this as a plus.
Created attachment 195319 [details] PDE only fix
Markus, can you try the new patch?
(In reply to comment #12) > Created attachment 195319 [details] [diff] > PDE only fix Good that we took the extra turn. This is much better. +1 for RC1.
Committed patch to HEAD.
Verified for RC1 with I20110514-0800.
