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

[Doug Schaefer <dschaefer@xxxxxxx>]

I don't believe you can update a patch. Submitting a new one seems to be
the way to go.

Thanks!
Doug

On 12-04-10 2:28 PM, "Hussein, Mohamed" <mohamed_hussein@xxxxxxxxxx> wrote:

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