octave-maintainers
[Top][All Lists]
Advanced

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

Re: Graphics properties as objects


From: John W. Eaton
Subject: Re: Graphics properties as objects
Date: Thu, 10 Jan 2008 11:57:08 -0500

On 10-Jan-2008, Michael Goffioul wrote:

| Hi again [sorry to bother you so much],
| 
| I'd like to have your opinion about the option I'm using (taking all previous
| comments into account), before completing the changes for the whole
| graphics code.
| 
| I decided to keep the overloaded <object>::properties::get and the like,
| because of the problem I reported earlier. I was reluctant to go that way,
| because it does not scale well when you want to add a property or a
| completely new object. But this can be mostly worked around if you try
| to auto-generate as much as possible. This is what I'm trying now and
| the result is in attachment (for the "figure" example)
| 
| The initial specs are (in graphics.h.in):
| 
|   class properties : public base_properties
|   {
|   public:
|     void close (void);
| 
|     BEGIN_PROPERTIES(figure)
|       any_property __plot_stream__ , Matrix ()
|       bool_property __enhanced__ , "on"
|       radio_property nextplot , "add|replace_children|{replace}"
|       callback_property closerequestfcn , "closereq"
|       handle_property currentaxes S , octave_NaN
|       array_property colormap , jet_colormap ()
|       bool_property visible S , "on"
|       radio_property paperorientation , "{portrait}|landscape"
|       color_property color , color_values (1, 1, 1)
|     END_PROPERTIES
|   };
| 
| This generates graphics.h (the generated portion is in figtest.h)
| *and* an additional graphics-props.cc file (see attachment). This
| file is intended to be simply included in graphics.cc and drastically
| reduces the code that you have write manually.
| 
| What do you think about this scheme?

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?  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 about Shai's suggestion about pre/post functions?  Are those not
needed with this approach?

Thanks,

jwe


reply via email to

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