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 <[email protected]> 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 [email protected] 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 >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
