Re: Updaters and default property values

[Rik]

On 03/12/2012 11:03 AM, Ben Abbott wrote:
> On Mar 12, 2012, at 1:08 PM, Rik wrote:
>
>> Ben, Michael,
>>
>> We should put some thought into how to address this issue.  The interaction 
>> between default properties and functions with updaters is already broken.  
>> See this bug report (https://savannah.gnu.org/bugs/?35662).
>>
>> Briefly, Octave does traverse down through the C++ code and eventually calls 
>> set_<property>() for each default.  However, at the time the code is called 
>> the axes are not completely set up and therefore the update_<property> 
>> functions can fail when they rely on a second property which has not yet 
>> been initialized.  A second issue is that I don't believe there is any 
>> guaranteed order of execution for the default properties.  Even though the 
>> defaults may have been coded in the order 1,2,3 in an m-file the actual 
>> routines could be called in the order 2,1,3 or whatever.
>>
>> This sort of Catch-22 seems like a common coding problem and maybe there is 
>> a common solution to apply in this regard.
>>
>> My thought had been to preserve the set functionality of set property but 
>> disable updaters while initializing an axis (or figure).  For example, the 
>> code of an average set_<property> function WITH an updater looks like this
>>
>> void set_<property> (const octave_value& val)
>> {
>>   if (! error_state)
>>     {
>>       if (<property>.set (val, true))
>>         {
>>           update_<property> ();
>>           mark_modified ();
>>         }
>>     }
>> }
>>
>> I was thinking of modifying the if conditional to
>>
>> if (<property>.set (val, true) && ! init_axes)
>>
>> where init_axes would choke off the further call to update_<property>.
>>
>> Is there a better way?
>>
>> --Rik
> Rik, thanks for this.
>
> I was suspicious that the updaters weren't working correctly due to the order 
> of initialization, or that some properties had not yet been assigned values 
> when the updating was done.
>
> I like your idea, but am not sure about the details (since my reading of the 
> code is still limited).
>
> Do you mean ...
>
> (1) Disable updating and assign the factory defaults. By "factory defaults" I 
> mean those encompassed in the BEGIN_PROPERTIES/END_PROPERTIES blocks. These 
> would need to be fully consistent. For example, papertype = "usletter", 
> papersize = [8.5 11.0], orientation = "portrait".
>
> (2) Enable updating and assign the default<object><property> values, and as 
> each property is the updaters run their course.
>
> I think that would work provided the order of setting the properties and 
> running the updating doesn't change the result. In the case of the paper* 
> properties, I think this should work.
Ben,

I think your way would work, but I was actually proposing something
different.  In your method, the axes are completely set up with a default
set of values and then all of the user-specified defaults are applied on
top of this.  This could mean a fair amount of work by Octave to set up and
then tear down properties which were supposed to have different values.  Of
course, in the end correctness beats efficiency and I suspect your way
would be easier to code than mine.

What I was proposing was to set the internal variable that keeps track of a
property to the correct value and stop there (no updaters, no rendering). 
After I have set all the correct values, I finish the axis creation with a
single call to have the axis rendered.  In the example I quoted, I am
choking off not only the call to update_<property> but also the call to
mark_modified().  There isn't a reason to tell the half-formed axis that it
needs to be redrawn because it hasn't yet been drawn.  I'm still not
certain this approach will work for entangled properties like papersize and
paperorientation.

I'm also hoping someone has an insightful way to do this better.

--Rik

Wh
> Ben
>  
>
>
>
>