Re: Updaters and default property values

[Ben Abbott]

On Mar 12, 2012, at 3:36 PM, Rik wrote:

> 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

What do you mean by "correct values" ?

Since, I don't understand the details .... Does your approach require the 
"default<object><property>" to be consistent ?

What happens if they are not ? 

        close all
        set (0, "defaultfigurepapertype", "usletter")
        set (0, "defaultfigurepapersize" = [3, 5])
        set (0, "defaultfigurepaperorientation", "landscape")
        get (gcf, "papertype")
        get (gcf, "papersize")
        get (gcf, "paperorientation")

Notice the papersize isn't consistent with "usletter" or "landscape".

In any event, I remain too confused by this part of the code to even see where 
to begin. So my questions are motived by a desire to learn/understand. Are you, 
or Micheal, able to take care of this ?

Ben