[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=

Martin Poirier theeth at yahoo.com
Tue May 3 04:52:36 CEST 2011


I'd also like to see this reverse. For the reasons that Campbell outlined and others.

Martin

--- On Mon, 5/2/11, Campbell Barton <ideasman42 at gmail.com> wrote:

> From: Campbell Barton <ideasman42 at gmail.com>
> Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=
> To: "bf-blender developers" <bf-committers at blender.org>
> Received: Monday, May 2, 2011, 10:41 PM
> agree that it should use the current
> option.
> also, looked over the changes.
> 
> - Using a timer for loopcut in this case looks like its not
> necessary,
> changing how the events behave should be possible without
> it.
> - Setting the left mouse as an operator property is not
> good either,
> AFAIK no other operators do this (some store events
> internally like
> the ones they are activated by, but they don't expose them
> as operator
> properties).
> - Would prefer changes to the wm & event system be done
> as separate
> commits (macro abort).
> - This also adds 'dsm_maxmem' to the user preferences which
> isn't used anywhere.
> 
> could this commit be reversed?, think it can be implemented
> better or
> just leave trunk as is and focus on bmesh instead.
> 
> On Tue, May 3, 2011 at 2:15 AM, Matt Ebb <matt at mke3.net>
> wrote:
> > weird, here's the original commit from last year:
> > http://lists.blender.org/pipermail/bf-blender-cvs/2010-April/027513.html
> >
> > In any case, i think it might be better to keep it
> with the release
> > confirm preference rather than adding a new one for
> one specific tool
> > only. It goes hand in hand, especially if you're using
> a tablet etc.
> >
> > cheers
> >
> > Matt
> >
> >
> > On Tue, May 3, 2011 at 12:09 PM, joe <joeedh at gmail.com>
> wrote:
> >> It wasn't in the code, and if it was it wouldn't
> have worked (the
> >> launch event isn't recorded when edgeslide is
> executed after loopcut,
> >> so I had to add an RNA property that lets you pass
> it to transform).
> >>
> >> Joe
> >>
> >> On Mon, May 2, 2011 at 7:55 PM, Matt Ebb <matt at mke3.net>
> wrote:
> >>> On Tue, May 3, 2011 at 11:52 AM, Joseph Eagar
> <joeedh at gmail.com>
> wrote:
> >>>
> >>>> I added a new Input user pref, for ending
> edge slide
> >>>> on mouse up after a loop cut.  I can see
> ton's point on
> >>>> the extra strain of click-hold-and-drag
> workflows. This
> >>>> is might only be useful for tablet users.
> >>>
> >>> I thought this already happened if you have
> 'drag immediately' on or
> >>> whatever it's called now, I added that
> behaviour for this reason.
> >>>
> >>> cheers
> >>>
> >>> Matt
> >>>
> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> 
> 
> 
> -- 
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> 


More information about the Bf-committers mailing list