[Bf-committers] Weekly developer meeting minutes, march 4 2012

[Nathan Vegdahl]

> and it
> looks like there are some pretty major code changes in there
> (admittedly, I only glanced through it).

Looking through it a bit more carefully, "major" is not the right
word.  But there is a fair bit of added code (300+ lines), and it will
be code that later transform features will need to make sure they
interact well with.

I'm not saying that adding code is necessarily bad.  And it doesn't
look to me like your code is bad (it seems well written, from what I
remember of C).  It just seems really unnecessary in this case.

Again, I do not mean to be disparaging of your work at all.

--Nathan


On Mon, Mar 5, 2012 at 12:08 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
> Also, to be clear, I said to deprecate them, not remove them.  I agree
> that, unfortunately, it would be very difficult to remove them and
> their associated complexity without causing loading problems of older
> files.  Although if they are deprecated for long enough, hopefully we
> can then remove them in the future (although at that point one hopes
> we could just develop a more modern transform system anyway, that
> would cover these cases as part of a well thought out and elegant
> design rather than as a mish-mash of corner-case features).
>
> And when I'm speaking of complexity, I'm largely speaking of internal
> complexity.  Code maintenance.  Covering corner cases that weren't
> originally envisioned.  Making it harder to add features that _can't_
> be accomplished already by other means, such that everything works
> together/isn't buggy.  Etc.
>
> I'm not going to kick or scream to keep this out.  As you say, I can
> simply ignore it if I don't want to use it.  But I think there are
> good reasons to leave it out.  Specifically, the benefit provided to
> the user is extremely minor, it doesn't enable anything new, and it
> looks like there are some pretty major code changes in there
> (admittedly, I only glanced through it).
>
> --Nathan
>
>
> On Sun, Mar 4, 2012 at 11:59 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>> (and why not local location, while we
>>> are at it?)
>>
>> Because the effects of local location cannot be achieved at all
>> without that feature, much less as simply as one can achieve what
>> hinge does.
>>
>> --Nathan
>>
>>
>> On Sun, Mar 4, 2012 at 11:26 PM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
>>> I don’t think that feature adds that much complexity… On the user POV,
>>> it changes nothing on a usual use case, just adding some options that
>>> can become handy in some situations. In fact, it makes a quite specific
>>> feature more generic, by just replacing two checkboxes by two « search
>>> data » fields (or dropdown menus)… And it won’t come into your way as
>>> long as you don’t need it!
>>>
>>> Removing hinge/no scale options (and why not local location, while we
>>> are at it?) would make loading old files quite tricky (as we would have
>>> to add constraints to mimic those options).
>>>
>>> PS: And I think I’ve already proven I do can work on the whole armature
>>> subsystem, and not only on my « own little systems »! ;)
>>>
>>> Le 05/03/2012 07:23, Matt Ebb a écrit :
>>>> On Mon, Mar 5, 2012 at 6:05 AM, Nathan Vegdahl<cessen at cessen.com>  wrote:
>>>>> I agree.  But I would still rather see hinge deprecated than improved.
>>>>>   I guess we just have different thresholds for "added back-end
>>>>> complexity" vs "shorter workflow".  To me, this has a very minor
>>>>> workflow benefit, but appears to make quite a lot of changes and add a
>>>>> fair amount of complexity to the transform code base.
>>>> +1
>>>>
>>>> As a general rule, blender is already too far on the 'overcomplicated
>>>> hard-coded special cases' side - it needs more in the way of simple,
>>>> rock solid, generic tools that work capably and reliably, that can be
>>>> adapted to your own usage patterns. This seems harder to achieve in
>>>> open source where volunteer devs like to work on their own little
>>>> systems and portions of code, but it's better for users in the long
>>>> run.
>>>> _______________________________________________
>>>> 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