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

[Eugene Ostroukhov <eostroukhov@xxxxxxxxx>]

You can use org.eclipse.cdt.managedbuilder.ui. buildDefinitionsUI to create custom field editors.

Best regards,
Eugene

On Sep 11, 2011, at 9:49 AM, Hussein, Mohamed wrote:

> 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.
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev