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 
Ah, I misunderstood. Yes, what Andrew said. Mikhail K has been doing that
with his change request and it just adds a new patch set to the existing
change request.

On 12-04-10 3:02 PM, "Andrew Overholt" <overholt@xxxxxxxxxx> wrote:

>You should use the gerrit Change-Id.  See:
>
>http://wiki.eclipse.org/EGit/Contributor_Guide#To_update_an_existing_chang
>e_with_a_new_commit
>https://git.eclipse.org/r/Documentation/user-upload.html#push_replace
>https://git.eclipse.org/r/Documentation/user-changeid.html
>
>HTH,
>
>Andrew
>
>----- Original Message -----
>> 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
>> 
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> 
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top