Re: [Bf-committers] Calling operators when drawing a panel
On Mon, Feb 7, 2011 at 10:36 PM, bartius crouch wrote: >> >> Campbell wrote: > 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. Basically we just need to be able to have update/get/set functions for python defined RNA, just like it is in C. I think Cam mentioned this above. Notifiers are related, but probably not really the same thing that people need here - they're more for updates/redraws, rather than executing code on property changes. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
> > Campbell wrote: > > 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. > This is important in my opinion, as we need an alternative for writing properties from within the draw panel. Some background on my opinion: I'm just an enduser who enjoys using the blender python api to extend blender's functionality. I've written several scripts for Blender 2.5 and most use this feature as a workaround to create live-updating interfaces. An example: one of the scripts displays all icons there are in blender (the add-on is in svn trunk and distributed with blender) and I use write-access to properties to enable searching within the icon list. This could be done in a different way, but it would actually make the script slower, having to recreate the list on each redraw, instead of having to recreate it on a change in the search string. I'm aware that allowing to change properties from withon the draw panel is not ideal, and has the potential for sloppy and bug-producing code, as Campbell pointed out*. But currently it's the only way we have to achieve certain things with python. So it would be nice if the proper way (python access to notifiers/listeners) was implemented in addition to just taking away the only current method we have. Cheers, Bart (Crouch) * http://markmail.org/message/6sg2clhu3ouap2oc ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
Le 07/02/2011 06:02, Dan Eicher a écrit : > On Sun, Feb 6, 2011 at 9:54 PM, Lionel Zamouth - BE wrote: >> Hi Campbell, >> >> as I'd like to hide unnecessary properties and avoid any user >> interaction, those workarounds don't fit in my desired workflow. > if some_prop: > > > That doesn't work? > > Dan > ___ > If I hide a property that has a non suitable value, then the user can't correct it (and I can't rely on the user for setting up the good value). I still can display those properties only when I'm unhappy with their values but I've no guarantee the user will make the appropriate change. In addition, stuff like aspect_x/aspect_y must be fixed realtime so the camera view in blender always match the render in Octane. Lionel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
On Sun, Feb 6, 2011 at 9:54 PM, Lionel Zamouth - BE wrote: > Hi Campbell, > > as I'd like to hide unnecessary properties and avoid any user > interaction, those workarounds don't fit in my desired workflow. if some_prop: That doesn't work? Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
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 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 t...@blender.orgwww.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 on
Re: [Bf-committers] Calling operators when drawing a panel
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 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 t...@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@blender.org >>> http://lis
Re: [Bf-committers] Calling operators when drawing a panel
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 t...@blender.orgwww.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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
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 t...@blender.orgwww.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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Calling operators when drawing a panel
I'd like to take this opportunity to re-iterate my request for py callbacks on properties, as I believe this would be the correct way to implement the behaviours needed by several addon developers, myself included. Cheers, Doug Hammond On 5 Feb 2011 13:25, "Lionel Zamouth - BE" wrote: ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Calling operators when drawing a panel
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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
