Re: [platform-debug-dev] Launch Configuration Templates

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Thanks John,

First of all, based on some local discussion, I updated the WIKI this 
morning (not sure when you read it...). The main conclusion we came to is 
that templates and default settings can (and should) be separated into 
different features/concerns. It's not even clear that we need to worry 
about default workspace/project settings, as they can be achieved using 
templates. My plan is to move ahead with the simple implementation of 
templates and discuss issues around default workspace/project settings 
further to determine if we need them.

> 1. The transformation of a launch configuration to a template due to 
> a drag-n-drop concerns me. Coming out of a drag is always a bit error 
> prone, and a misplaced drop is ok if you're just moving stuff around, 
> but if the mistake ends up transforming something else, then it makes 
> the mistake more serious. I recommend either prompting the user prior 
> to the transformation or altogether dropping this capability.

Drag & drop provides a convenient way to group configurations under 
existing templates. Since many configurations get created on the fly 
(launch shortcuts), and users have large sets of existing configurations 
it needs to be easy to organize them. Without drag and drop we have to 
have selection dialogs and actions (although, we probably have to have 
such actions/dialogs in addition to drag and drop anyway - to ensure 
accessibility).

> 
> 2. I think a "New template" action in the context menu of the viewer 
> would  be helpful. Context menus are the first place I look to see 
> what sort of operations I can carry out on an object. When enacted on 
> a launch config type, it would create a new empty template. When 
> carried out on a launch config, it would create a template from that 
config.

Yes, this makes sense. The "New" action in the context menu would become a 
cascade, as the toolbar button becomes a drop down. There will be two 
options "New -> Configuration" and "New -> Template".

> 
> 3. I really like the ability to update child configurations by 
> updating the template. I think that will come in really handy for 
> users with lots of configurations (I know our customers wish they had 
> that today).

Good.

> 
> 4. I'm concerned that the "Remove" action will be confused with 
> deleting a template. Perhaps "De-templatize"? (Not crazy about that, 
> either, but can't think of anything better at the moment).

Right... Since we're moving ahead without workspace default 
templates/settings for the meantime, the usefulness of a "templates list" 
on the LCD is questionable. It provided an easy way to select a workspace 
default template. But, just having a list of configs that are templates 
with add/remove options is no longer necessary, as we'll have a "Convert 
to Template" action in the context menu of the LCD. We could offer a 
"Convert to Configuration" action as well (de-templatize.... not sure what 
wording to use).

> 
> 5. I'm unclear on the action of associating a configuration with an 
> existing template. It's not a lasting association, right? In other 
> words, after cross-applying the settings to the target template, 
> there is no association between the two, or is there?

Yes, this is a lasting operation - the configuration maintains a back 
pointer to its template. It bases the configuration on the template and 
displays it as a child in the LCD. It would be updated when the user 
decides to update all child configurations.

> 
> 6. Use of a checkbox for mutual exclusive enablement seems a little 
> unorthodox to me. Radio buttons are the defacto widget for that sort 
> of thing. I looked through a lot of Eclipse GUI searching for an 
> example of what you've proposed but didn't find any. If there is 
> precedent, then I'm not so concerned. If there is no precedent, I'm 
> slightly concerned, though in actuality it seems intuitive enough to me.

Since we plan to show template organization via nesting in the tree, and 
have actions for "Convert to Template" and "Convert to Configuration", we 
no longer need widgets/check boxes to control this in the LCD page.

> 
> 7. Will a decoration be applied to template icons in the viewer to 
> visually differentiate a template from a regular configuration?

We could... if we could agree on one. We assume that some will want to 
contribute their own image.

> 
> 8. There are discrepancies between the interface changes that you 
> committed the other day and the wiki. E.g., see 
> ILaunchConfigurationType. Should we be reviewing the API in the wiki 
> or the changes committed so far? (Not sure if you've abandoned some 
> of the ideas on the wiki)

Likely due to recent changes in the WIKI and catching up with code in 
HEAD.

> 
> 9. I don't know if it's implied, but it seems to me that the GUI for 
> launch configurations should be enhanced to be lax in their 
> validation. A template should not be subject to the same level of 
> validation as a regular config. For example, a user currently has to 
> specify an executable in a CDT launch configuration, or an error is 
> exposed. A template would want to be able to leave that field blank.

This is correct. By default a template will not be validated (as they will 
usually have errors). However, we'll add a method 
AbstractLaunchConfigurationTab#isTemplateValid(ILaunchConfiguration) to 
allow clients to implement validation if they want.

Darin