[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Launch Configuration Templates
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