Re: Graphics properties as objects

[Shai Ayal]

On Jan 10, 2008 7:40 PM, Michael Goffioul <address@hidden> wrote:
> On 1/10/08, John W. Eaton <address@hidden> wrote:
> > I think it looks good.  Are you also writing more specific property
> > classes now (bool_property, callback_property, handle_property, ...)
> > and converting everything at once?
>
> For the moment, I have already defined the following property classes:
> - string_property
> - radio_property
> - color_property
> - double_property (scalar)
> - array_property (generic array which stands for an array in octave;
> implement a system of "constraints" that allow to limit the values
> supported by the property; for instance colormap must be a "double
> array with 2 dimensions and the second dimension must be 3")
> - data_property (double NDArray)
> - bool_property (inherits radio_property with "on|off"; exists only for
> convenience, might not be really needed)
> - handle_property (scalar handle)
> - any_property (any octave_value without constraint)
> - callback_property
>
> What I will probably add is a "children_property" that would hold an
> array of handles (-> Matrix) and the would handle the "handlevisibility"
> property in the get-method
>
> Then I think the set will be already quite complete. You may also
> think about adding convenience types like "linestyle_property"
> or "marker_property". Something I also thought about was to
> define some kind of "combined_property" that would combine 2
> property types: supported values would then be of the first type
> or of the second type. For instance, by combining a double_property
> and a radio_property, you could correctly support the FaceAlpha
> property of a surface object.
>
> > Would it be maybe easier/better to
> > get the new genprops.awk script checked in now with generic properties
> > as they are now, then convert existing properties (and check those
> > changes in), then begin adding new properties?  Doing it in steps
> > might allow others to help with this process.
>
> What I had in mind was to
> 1) make the existing code use new property classes: now that we agreed
> on a scheme, this should be rather easy as I already have almost all
> pieces
> 2) check everything still work in the default backend
> 3) add all missing properties to all objects (even if they are not used)
> according to MathWorks documentation
>
> Step 1 should be fast now (I hope), and I guess it's easier if I take of
> it myself completely. Once checked-in, Shai and I (and anybody else
> who's interested) can take care of step 2 and 3.
>
> Once this will be done, I'll be able to get back to my initial goal: 
> converting
> my OpenGL rendering code to C++.
>
> Does this should OK? (Shai?)

Sure.

> > What about Shai's suggestion about pre/post functions?  Are those not
> > needed with this approach?
>
> No. Pre and post functions are easily implemented when they correspond
> to interpreted code (and we'll have to implement that for listeners anyway),
> but it's rather tricky when the "listener" is a C++ class method (at least
> I could not figure out a "good" mechanis). So I stepped back and re-used
> the current system of overloaded <object>::properties::get|set, except
> that the code is now auto-generated (which makes life much easier).
> I also removed the registration of static properties into the property map
> (which is then used only for dynamic properties), because it's not really
> needed if I keep the previous get|set system; it's even a problem if you
> want to implement "get (void)" efficiently.

Actually I now remembered that we though about this some time ago
(July?) and decided that it would not be too much of a limitation to
have the c++ code use only the generic set function (i.e. void
<object>::properties::set(octave_value& val)). This will not incur
much of a performance penalty since the c++ code does not really have
to set a lot of properties -- it is mainly a viewer so it needs fast
read access. This way the listeners (or post/pre functions) would work
for c++ code as well.
Do you agree to have it this way -- i.e. have only the  void
<object>::properties::set(octave_value& val) function public?

Shai