Re: Updaters and default property values

[Rik]

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