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

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

Hi All,

I have now pushed the change for bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=365718  to Gerrit @ https://git.eclipse.org/r/5556

It would be highly appreciated if someone can take a quick look, at least from a cosmetic/standards/... point of view, as this is my first big submission. 
Thanks in advance for your help.

The steps in http://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT  worked well for me.

Note: I had to sign in for gerrit and used http authentication, generate password, and stored that info in gerrit configuration in eclipse.

Best Regards,
Mohamed.


> -----Original Message-----
> From: Hussein, Mohamed
> Sent: Monday, February 13, 2012 5:39 PM
> To: 'cdt-dev@xxxxxxxxxxx'
> Subject: RE: 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.