[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Launch Configuration Templates

Hi Darin,

Here are my comments regarding launch configuration templates:

1. Templates and Launch Mode

Do we want to support tying a template to a specific launch mode?  Would there be a case where a template is only applicable to a single mode.  I can have a template created for debugging, with special vm arguments, but the arguments are not applicable in run / profile mode.  I may have special profile settings, that cannot be applied to debug or run mode.  If the template is not tied to a launch mode, would the UI be cluttered to show all tabs that are applicable to a launch configuration type?  Or are you expecting that when the user is working in a template, they would have told us what launch mode they are dealing with?  What happens if I want to create a template for mixed mode:  debug & profile?

2.  UI for managing the launch configuration template

How does the user manage and manipulate the settings in a launch configuration template?  If the user uses the "New Template" action from the toolbar, would the template be shown along with other configurations in the LCD.  If so, how can the user tell whether a configuration is a template or not?  Would it be confusing?  Should we provide a filter to allow the user to filter out the template, or filter out simple configurations?

3.  Create a template from existing configuration

RE:  Select the configuration in the LCD and click the "Template" toolbar button.  
Do we create a new launch configuration that will be treated as a template, or are we converting existing launch configuration as the template?  If we are converting the launch configuration, does this mean the user can no longer launch the config, and must create a new config from the template?  Would it better if we create a new launch config and use that as a template?

RE:  "A configuration will automatically become a template if an existing configuration is dropped on it as a child configuration. As this operation modifies the drop target into a template, the user should be prompted to confirm the operation. "

I don't think this is a natural workflow.  If an existing launch configuration is dropped under another launch config, does this mean the child launch config will copy all attributes from the parent template in this case.  So, this operation changes the drop target and also the existing launch configuration.  It is not obvious to me that I can convert a config to a template this way.  But I can understand why this is a convenient method.  In addition, again if the parent configuration is converted to a template, can it be launched still.

4.  Update all configurations made from a template

I like the idea that we can push changes in the template to the children, but should we allow the user to pick and choose, rather than forcing an update on all children?  

In addition, would it be useful for the user to work in a configuration that was originally created from a template, and push the configuration changes back up to the template?  Once the template has the setting, the changes can be pushed to other launch configurations.  Can we also allow the user to choose what attributes to sync-up?

5.  Nest configurations by template

Can a template be nested inside another template?  If this is useful, what does it mean?

Thanks...
Sam


From: John Cortell <john.cortell@xxxxxxxxxxxxx>
To: "Eclipse Platform Debug component developers list." <platform-debug-dev@xxxxxxxxxxx>, "Eclipse Platform Debug component developers list." <platform-debug-dev@xxxxxxxxxxx>
Date: 16/10/2009 07:36 PM
Subject: Re: [platform-debug-dev] Launch Configuration Templates
Sent by: platform-debug-dev-bounces@xxxxxxxxxxx




At 02:32 PM 10/16/2009, Darin Wright wrote:
> 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).

I wasn't suggesting dropping all of the drag-n-drop suppport. My suggestion was specific to the act of dragging a launch configuration on top of another launch configuration, with the end result being (as I understood it) that the dropped-on config is transformed into a template. That doesn't seem like good behavior to me, for the reasons I mentioned. >From the wiki:

A configuration will automatically become a template if an existing configuration is dropped on it as a child configuration.

>
> 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).

Sounds good to me.
>
> 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.

I'm sorry. I used a wrong word in the first sentence. I meant associating a template with an existing template. From the wiki:

A template can be associated with an existing template using drag & drop (dropping on the template). When this happens, the user will be prompted to apply the template settings to the freshly dropped template (with a "do not ask again" option).


> 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.

Sounds good.

John_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev