Hi Sven,

thanks for your quick reply!

On Sun, Apr 18, 2010 at 10:35:33AM +0200, Sven Neumann wrote:
> On Sat, 2010-04-17 at 17:25 +1000, Roman Joost wrote:
> How much code does the TextView class actually borrow from the Entry
> class?
It would borrow the

    * get_text* (which returns a string if the XMPModel
      changed) and
    * set_text method (which sets the value in the XMPModel in case the
      user entered something in the widget).

I actually thought I would also be able to use some of the setup data
structures or object construction methods. This is almost the same for
the GtkEntry and the TextView and probably for any other widget. For

static void   gimp_xmp_model_entry_set_property  (GObject      *object,
                                                  guint         property_id,
                                                  const GValue *value,
                                                  GParamSpec   *pspec);
static void   gimp_xmp_model_entry_get_property  (GObject      *object,
                                                  guint         property_id,
                                                  GValue       *value,
                                                  GParamSpec   *pspec);

the class_init, the constructor method need to be always re-declared?

> There are certainly ways to share most of
> this code, but probably not by inheritance. Some utility functions
> called from both classes might be sufficient, or you use composition and
> embed a common object in your TextView and Entry objects.
In the case of composition - correct me if I'm wrong - I could use some kind of
a general object in e.g. the private of my entry widget:

    typedef struct
        GIMPXMPBinding *binding;
    } GimpXmpModelEntryPrivate;

and would be able to use all my methods through that binding object?

    typedef struct
        const gchar *schema_uri;
        const gchar *property_name;
        XMPModel    *xmp_model;
    } GIMPXMPBinding;

Although I have to admit - currently there is not much to share (if it really
comes down to three functions). It would almost look like refactoring this code
into utility functions as the better solution.

Roman Joost
www: http://www.romanofski.de
email: romanof...@gimp.org

Attachment: signature.asc
Description: Digital signature

Gimp-developer mailing list

Reply via email to