Re: Updaters and default property values

[Ben Abbott]

On Mar 12, 2012, at 4:25 PM, Rik wrote:

> On 03/12/2012 12:52 PM, Ben Abbott wrote:
>> 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 ?
> It's too much for me.  I'm really only a dabbler in the graphics code and
> don't fully understand it.  I think Michael is the best person for it, but
> it may have to wait as he is in the midst of moving
> 
> --Rik

ok. I expect we can fix the problems with producing the images for 
documentation by avoiding setting defaultfigure<property>

I'll take a look.

Ben