[cdt-dev] Adding new build option type: tree

["Hussein, Mohamed" <mohamed_hussein@xxxxxxxxxx>]

Hi all,

I have a proposal for an enhancement in the Managed Build options, that
I would like your opinions on, before opening a bugzilla.

We would like to add a new valueType for the Managed Build tool chain
build options (defined in buildDefinitions.exsd in
org.eclipse.cdt.managedbuild.core)

We have a huge list of options that we want to present to the user.
Those options are currently specified as "enumeration".
The dropdown in the enumeration is very long and unusable, and the list
of items can be easily categorized into a user-meaningful structure.

We would like to present this data to the user in a normal string field
with a "browse" button. 
Clicking the button opens a dialog with a Filtered Tree containing the
options structure to allow the user to select the value.
The dialog can present extra information "description" for values as
well as categories.

-- Proposal

1- Modify schema to add a new possible value for valueType "tree", and
add new elements for the tree structure
2- Modify IOption, its hierarchy, and users to support this new type.
3- Modify BuildOptionSettingsUI to create the new field editor and popup
dialog

-- Some details
1- Schema changes
 1.a- Add new type "tree"
 1.b- Add optional child under "option" : "treeRoot" that contains any
settings specific to the tree 
      (can't think of any right now, so can remove this, I added it for
future expansion so as not to pollute the "option" element with any tree
specific settings)
 1.c- Add hierarchy of "treeOption" under "treeRoot", each "treeOption"
will have: name, id, description, icon.

2- IOption code changes
Here I have more thoughts and questions than solid proposal.
 - Looking at the code, the new "tree" type seems bit similar in usage
to existing "enumeration"
 - Code has many switch cases (personally I would have preferred class
hierarchy) on type distributed among several classes, so adding new type
doesn't seem like an easy task. Would like your input on proper ways to
test and validate this, and whether the new type needs to support all
the capabilities in existing types.
 - IOption has some APIs enumeration specific (e.g. getEnumCommand,
getSelectedEnum, getEnumeratedId, getEnumName, ...) same for other
types, shall we continue doing so and add new APIs for getting tree
value or command?
 - There is an internal enumCommandMap that maps each possible value in
an enum with its command, can this be reused for tree, or shall a new
one be created for tree.
 - shall IManagedOptionValueHandler support trees as well?

3- UI
 - Field editor is a String Field Editor with browse button. Button can
just say "..."
 - Popup dialog will contain: Filtered tree with the tree structure, and
a description section beneath for the selected element in the tree.

Please let me know your thoughts on this. Any comments, suggestions are
most welcome

Best Regards,
Mohamed.