[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] Adding new build option type: tree
- From: "Hussein, Mohamed" <mohamed_hussein@xxxxxxxxxx>
- Date: Tue, 10 Apr 2012 18:28:45 +0000
- Accept-language: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: Acxworan7nKxg1KXTWCH7WySKlegpx5wjnigCzE8JYAAB0wyYA==
- Thread-topic: Adding new build option type: tree
> -----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 @
[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?
> 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,
> > -----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.