[Bf-committers] Weekly irc meeting, october 4 2009

[Dalai Felinto]

> Now, I don't know what Dalai wanted to use this for exactly, but I
> think it's important he explains it, and we think of how it can fit
> in, rather than assume notifiers are the solution.

My request may even be simpler than what Matt suggested. I have so far
two uses for it. Interesting those are the two scripts I ported to 2.5
so far, and both would take advantage of it:

1) a script that requires a password input [1]. Every time one types a
char I want to store it internally and replace it with a '*'.
2) a script that requires fine tuning of parameters to calculate
something. It's too annoying to (a) change the parameter and then (b)
press "calculate". I can see multiple examples of this being needed.
eg to move an object in scene through this script.

Making long short: Think about how to re-create a "F6" (redo last)
kind of functionality. In cases like that you don't want to set a
parameter and then click in an operator, you want it to change right
away.

Thanks,
Dalai

[1] - http://blenderartists.org/forum/showthread.php?p=1457891
[2] - http://blenderartists.org/forum/showthread.php?t=163341

2009/10/5 Brecht Van Lommel <brecht at blender.org>:
> Hi,
>
> On Mon, Oct 5, 2009 at 7:59 AM, Toni Alatalo <antont at kyperjokki.fi> wrote:
>> Matt Ebb kirjoitti:
>>>> - Dalai prefers to see more advanced support being added for python
>>>> script dependencies, like executing a script on changing a variable in
>>>> the UI. Issue is that this requires an updated dependency graph
>>>>
>>> Couldn't this be done with notifiers  and python listeners? Would be
>>> extremely useful for a lot of other situations too.
>>>
>>
>> Yes I figure many kinds of editing tools or something just working
>> inside Blender would easily benefit from these, like perhaps procedural
>> tools that want to know that their base has been edited.
>
> I think that a good notifier system that python can plug into is
> important, however I also think in most cases it is not the right
> solution. If you have for example a procedural tool that changes a
> mesh each time you modify a parameter, that's an operator or a
> modifier. If you need to re-run the script when a variable changes in
> the UI, that may be the case sometimes, but I don't think that's a
> reliable way to extend Blender. Similarly doing things on frame
> changes may be nice, but it's not really the right thing to do either
> in most cases, since there are other cases updates are needed besides
> frame changes. It may be more appropriate to write a constraint for
> example.
>
> The advantage of being able to listen to such a notifier is of course
> that you can extend Blender in more flexible ways, and for that reason
> we should allow it. But when possible, we should allow scripts to hook
> into existing Blender systems that get correctly handled by the
> dependency graph, undo/redo system, duplicating data, etc. That way
> things work correctly when manipulating data, running on render farms,
> executing as part of macros, etc.
>
> Now, I don't know what Dalai wanted to use this for exactly, but I
> think it's important he explains it, and we think of how it can fit
> in, rather than assume notifiers are the solution.
>
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>