Community
Participate
Working Groups
Users are finding the targets tab confusing (from mailing list and some bug reports). When the user unchecks the "run default target", the target list is populated with all targets. Instead, I propose we populate the list with all targets, but use a checkbox list. By default, no targets will be checked. The user just checks the tasks they want to run. There is no need for add/remove buttons, but the user should still be able to order the tasks. We would need a way to persist this info in the config.
*** Bug 26855 has been marked as a duplicate of this bug. ***
see bug 26858 for more concerns / ideas
I have raised 26683 regarding the use of 'Use default' and 'default' values for both Ant and other parts of eclipse.
I thought about this on the weekend...how do you have a checkbox list that can show ordering when you mix checked and unchecked items? Do you "jump" things around so that all check items are grouped? Do you leave the checked and unchecked items mixed? If so how does move up and move down work? I just don't see it.
Created attachment 2725 [details] Textual approximation to suggested screen Suggested screenshot of how it could look
My thought was to *not* group checked/unchecked items. They are just items that can be checked or not. The user moves them as if they did not have check boxes. (although, now I am starting to see why there were two lists - as we have migrated to in the Ant view).
Another way of representing targets to run is not to use a list, but to use two lists of information. On the left list can be a list of all targets. On the right list can be a list of selected targets with an [Add >>] button and a [<< Remove] button to move the targets from one place to another. When a target is added, it can move to the right list (and not be displayed in the left list any more). Then the user can remove it by highlighting it and clicking 'Remove'. This also gives the opportunity for the user to re-order the selected targets in the right hand side. However, you may want to build in some kind of error detection in the list, since (for example) the 'build' target could depend on the 'compile' target, so you may not want to be able to move 'build' up past 'target'. Should the user then be allowed to reorder them like this? IMHO showing all targets as a table is slightly preferable, because then you can also see a description in the field. The two-list approach doesn't really allow for that, although you could put in the target's description as a hover-text for the item in the table.
I think Alex's idea (and what we used to have :-( ) is the way this should look. BTW Alex, the ordering does not check the dependacy graph for the targets. It is only the ordering of execution. If "build" depends on "compile" and the user moves "build" before "compile", compile will still execute as defined by Ant dependacies.
Created attachment 2727 [details] A suggested look involving a single table instead of lists Another view of how it could possibly look
A table /could/ be provided with a checkbox, and another column indiciating position. As a user checks the boxes, the target gets added to the 'end' of the position, but stays in the same place in the table. Unchecking and then rechecking a box should put it at the end of the position. Changing the position of a target could be done by highlighting the selected target and clicking on 'promote' in which case it would swap positional places with the preceeding target. Repeatedly clicking promote, would therefore position the target as the first item in the ant argument list. NB using this approach, the user can then apply other sorts on the table (such as by position, by target name, by description, by selected/unselected) as appropriate. I would suggest an initial sort of alphabetically increasing on the target name (though I'm not sure my example shows that). I do not recommend a default sort on the position of the item in the ant arguments. I also accept Darin's view that the positioning of the targets makes no difference to how ant actually positions them, but it'd be a nice extra feature that if a user tried to order 'compile' before 'all' that a warning was given. However, I accept that in the general case (esp dealing with 'unless' or 'if', or even 'antcall') this won't be possible.
After mentioning this problem to Erich, we though that good solution may be to follow the example of the Java build path proprties. That is, two tabs can be displayed (within the Targets tab). The first tab is a check box list of targets to run (ordered as they appear in the script, or alphabetically - which ever is more pleasing). The second tab allows the order of selected targets to be adjusted. This is like the "order" tab on the build path page that allows the relative order of all classpath entries to be adjusted. Generally, order will not be adjusted, and thus will not be "prominent" in the UI. Only the selected targets will appear in the order tab. Complaints?
I like this solution. Most Ant build files have there dependancies set so that ordering is not necessary (the established entry points are mutually exclusive). Con: we already have 6 tabs for an Ant launch configuration!
(Yes, but this is tabs within a tab - like the classpath tab in the Java Application launch config).
That works :-)
*** Bug 30061 has been marked as a duplicate of this bug. ***
The targets tab has been reworked. It now has two subtabs. The first tab is for the selection of the targets to execute. It is a checkbox table showing all of the targets. By default, the default target is checked. The order the items are checked is the default ordering of the targets. The order tab presents the user the opportunity to tweak the ordering of the targets. Please verify the changes (DarinW).
Verified.
