[Bf-committers] Calling operators when drawing a panel

[Lionel Zamouth - BE]

Hi Campbell,

as I'd like to hide unnecessary properties and avoid any user 
interaction, those workarounds don't fit in my desired workflow.

However, there may be an intermediate solution, propably easier and 
safer to implement than callbacks: if we have an extra function that we 
could override in our subpanel's subclass and that is called each time 
before switching to the 'draw' context, it would probably do the job in 
an elegant way. Unless you choose a name already used by an addon, it 
would not affect at all existing addons.

Such a function could return a flag indicating that it may have changed 
properties from another subpanel, so the process could be restarted. A 
counter of function calls can prevent calling again the function that 
triggered such an event so we don't fall into an infinite loop for a 
single draw sequence.

Is it something realistic?

Cheers,
Lionel

Le 06/02/2011 08:35, Campbell Barton a écrit :
> Hi Lionel, we had this discussion a while ago. for my rationale on why
> writes are disabled on draw see:
> http://markmail.org/message/6sg2clhu3ouap2oc
>
> I was aware this change might not be practicle in some use cases when
> making it, so one line comment can enable write access again if this
> is not workable but Im still not convinced that this should be changed
> back.
> You were able to work around it by calling an operator but this still
> has the same problems as changing the value directly, and if calling
> operators is to be allowed in a draw function we can better just
> remove the limitation altogether (operators may register themselves or
> have an undo push which would be annoying).
>
> In your case I'd suggest to define your own panels which alert the
> user when unsupported settings are selected. (set the red-alert on the
> value or add a text label).
> You could also have an operator which enforces octane compatible
> settings accessed from a button in the render panel.
>
> This is not ideal but even if you enforce the settings within the draw
> function there is nothing stopping someone from loading a blend file
> and pressing render immediately, so relying on the panel to be drawn
> on each material is weak too.
>
>
> You have a valid point that we need python integration:
> IMHO scripts should be able to handle notifiers and ability to define
> update functions for python defined properties.
>
> Python defined update functions I can do but handling notifiers should
> be discussed with Ton first since it may relate to python handling
> events which is a bigger project,
> will ask about it before the meeting tonight.
>
> - Campbell
>
> On Sat, Feb 5, 2011 at 5:03 PM, Lionel Zamouth - BE<lionel at zamouth.be>  wrote:
>> Hi,
>>
>> if you've no alternate method ready, then I kindly suggest you let us do
>> our dirty workarounds in the meantime :-)
>>
>> Cheers,
>> Lionel
>>
>> Le 05/02/2011 15:23, Ton Roosendaal a écrit :
>>> Hi,
>>>
>>> We've had several people who work on render exporters already
>>> complain :)
>>> I think the issue is mostly to get a decent method to send notifiers
>>> (UI updates) and data-updates (depsgraph) in place, as soon as possible.
>>>
>>> I'm quite sure this change by Campbell was done to prevent crashing
>>> and bugreports; but I'm curious to know what his idea is for for a
>>> timely solution?
>>>
>>> -Ton-
>>>
>>> ------------------------------------------------------------------------
>>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>>>
>>> On 5 Feb, 2011, at 14:25, Lionel Zamouth - BE wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm writing here following a chat I had with Campbell about recent
>>>> changes that made impossible to call operators from the 'draw' section
>>>> of custom panels. He suggested I submit here my problems with this
>>>> behaviour.
>>>>
>>>> This technique is used since a previous change where directly writing
>>>> into properties has been forbidden. I understand that bad coding could
>>>> lead to some deadlocks or infinite loops but having the ability for a
>>>> script to react to property changes is quite important and not
>>>> achievable otherwise due to the lack of callbacks (so far I know).
>>>>
>>>> Here's the situation I'm facing: I've written an unofficial (both from
>>>> Blender and Refractive Software point of view) addon to allow smooth
>>>> export of blender scene/anim to the unbiased render Octane. From the
>>>> user perspective it consists of 3 custom panels, replacing the default
>>>> 'render', 'material' and 'texture' ones. I'm proud to say it has
>>>> became
>>>> quite popular and allows a nice workflow to happen.
>>>>
>>>> The need for tracking properties is due to my wish to prevent the user
>>>> accessing or modifying values that can't be taken in account by
>>>> Octane.
>>>> For instance the custom texture panel forces the type to 'Image',
>>>> coordinates to 'UV' and the Projection to 'Flat', as these are the
>>>> only
>>>> values that can work with Octane (and are hidden by the custom panel).
>>>> Another example is the main 'render' panel automatically resetting
>>>> the x
>>>> and y aspect ratio to 1 as Octane only renders square pixels. This
>>>> last
>>>> one is very important for the camera view in Blender to match final
>>>> result in Octane.
>>>>
>>>> Doing those operations in the 'draw' section may have some limitations
>>>> but seems to properly make the job (for instance I don't care if a
>>>> user
>>>> loads an old scene with non proper values, I only expect my script to
>>>> fix these once they're presented to the panel - good enough for me).
>>>>
>>>> According to Campbell it's seems there's no suitable workaround, so
>>>> I'm
>>>> asking you don't prevent anymore operators to be called from the
>>>> 'draw'
>>>> section of panels until callbacks are available (or may be you have a
>>>> working workaround available).
>>>>
>>>> Cheers,
>>>> Lionel
>>>> _______________________________________________
>>>> 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
>>
>
>