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

[Nathan Vegdahl]

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