octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Graphics properties as objects


From: Michael Goffioul
Subject: Re: Graphics properties as objects
Date: Thu, 10 Jan 2008 18:40:31 +0100

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?)

> 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.

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]