Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Adding new build option type: tree

Hi,

I have submitted a patch implementing the below mentioned proposal to support tree type in build options couple of months ago as https://bugs.eclipse.org/bugs/show_bug.cgi?id=365718 

Is it possible that it is considered for inclusion in cdt.

We have been using it locally for the past couple of months with no problems so far.

Looking forward to your comments. 

Best Regards,
Mohamed.


> -----Original Message-----
> From: Hussein, Mohamed
> Sent: Sunday, September 11, 2011 6:49 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Adding new build option type: tree
> 
> 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.



Back to the top