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

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

> -----Original Message-----
> From: Hussein, Mohamed
> Sent: Tuesday, April 10, 2012 5:00 PM
> To: 'cdt-dev@xxxxxxxxxxx'
> Subject: RE: Adding new build option type: tree
> 
> 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
> 
[mhussein] I wanted to submit an update to remove extra whitespaces as Mikhail noted to me, but seems I didn't do it properly as I pushed a new change instead of updating the old one, so I abandoned the old change in favor of https://git.eclipse.org/r/#/c/5558/

What is the proper way to update a patch? I guess this info should be in the wiki.

Also, is there a way to automatically remove those extra whitespaces?

Best Regards,
Mohamed.

> 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.