[
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
