Metadata-Browser and Widgets
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Metadata-Browser and Widgets | Roman Joost | 17 Apr 09:25 |
Metadata-Browser and Widgets | Sven Neumann | 18 Apr 10:35 |
Metadata-Browser and Widgets | Roman Joost | 19 Apr 10:15 |
Metadata-Browser and Widgets | Sven Neumann | 20 Apr 20:23 |
Metadata-Browser and Widgets | Roman Joost | 21 Apr 10:35 |
Metadata-Browser and Widgets
Hi folks,
I'm back working on the meta-data browser. Current problem I suppose is to overcome my lack of C knowledge towards inheritance.
I've implemented a GtkEntry widget which is tied to the XMPModel. This means, a user can change the meta-data "title" on the description tab and in the advanced tab (showing a tree of currently set meta-data values) and both widgets stay in sync with the value entered.
I would like to do something similar for the text views. Take the description as an example. Martin gave me a hint towards inheritance, which I'm currently trying to solve.
My understanding so far, if I would inherit from my GtkEntry widget, I wouldn't be able to "overwrite" my implementation so I can display a GtkTextView. I also thought about inheriting from a more basic widget and somehow use a GtkEntry or GtkTextView as a property. That didn't really worked well either.
Now I have a similar implementation working with a GtkTextView as a base class including "borrowed" code from my GtkEntry. I would like to "merge" both to something more flexible, but I can't really think of a better architecture.
Maybe the clue is to overwrite the constructor which returns either a GtkEntry, a GtkTextView or ...?
Any help, pointers, new ideas would be appreciated :)
Cheers,
Metadata-Browser and Widgets
Hi,
On Sat, 2010-04-17 at 17:25 +1000, Roman Joost wrote:
My understanding so far, if I would inherit from my GtkEntry widget, I wouldn't be able to "overwrite" my implementation so I can display a GtkTextView. I also thought about inheriting from a more basic widget and somehow use a GtkEntry or GtkTextView as a property. That didn't really worked well either.
Now I have a similar implementation working with a GtkTextView as a base class including "borrowed" code from my GtkEntry. I would like to "merge" both to something more flexible, but I can't really think of a better architecture.
How much code does the TextView class actually borrow from the Entry class? What does this code do? 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.
Maybe the clue is to overwrite the constructor which returns either a GtkEntry, a GtkTextView or ...?
No, that wouldn't work. The constructor can't change the type of object it returns.
Sven
Metadata-Browser and Widgets
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 example:
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.
Cheers,
Metadata-Browser and Widgets
Hi,
On Mon, 2010-04-19 at 18:15 +1000, Roman Joost wrote:
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 example:
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?
You could use an interface and have your classes implement that interface. GObject allows interfaces to have a default implementation. You can for example implement common properties in an interface. There are few examples of this in GIMP. The GimpSerializable interface is one, GimpRectangleTool is also an interface.
Sven
Metadata-Browser and Widgets
Hi Sven,
On Tue, Apr 20, 2010 at 08:23:44PM +0200, Sven Neumann wrote:
You could use an interface and have your classes implement that interface. GObject allows interfaces to have a default implementation. You can for example implement common properties in an interface. There are few examples of this in GIMP. The GimpSerializable interface is one, GimpRectangleTool is also an interface.
Aw cheers for that. That should get me going. I remember that I've used the GtkTreeStore interface for the XMPModel.
Cheers,