RSS/Atom feed Twitter
Site is read-only, email is disabled

Problem with creating/compiling XMPModel which inherits from GObject

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.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

Problem with creating/compiling XMPModel which inherits from GObject Roman Joost 16 Jul 08:26
  Problem with creating/compiling XMPModel which inherits from GObject Roman Joost 16 Jul 08:49
  Problem with creating/compiling XMPModel which inherits from GObject Martin Nordholts 16 Jul 16:24
   Problem with creating/compiling XMPModel which inherits from GObject Roman Joost 17 Jul 08:55
Roman Joost
2009-07-16 08:26:41 UTC (over 15 years ago)

Problem with creating/compiling XMPModel which inherits from GObject

Hi,

I thought it would be handy, if my XMPModel which stores the XMP metadata could emit it's own signals if properties or schemas change.

The model now inherits from GObject and but most of the data structure is unchanged:

struct _XMPModel {
GObject parent_instance;

GtkTreeStore *treestore; GSList *custom_schemas; GSList *custom_properties;

XMPSchema *cached_schema; GtkTreeIter cached_schema_iter; };

My problem now is, that:

1. to get it some sort to compile is to include header files in my xmp-model.h header file (gtk.h, glib-object.h, xmp-schemas.h) and I don't know why.
2. which actually prevents me from working on that more is the following error:

In file included from /usr/include/glib-2.0/glib/gmacros.h:40, from /usr/lib/glib-2.0/include/glibconfig.h:9, from /usr/include/glib-2.0/glib/gtypes.h:34, from /usr/include/glib-2.0/glib/galloca.h:34, from /usr/include/glib-2.0/glib.h:32, from /usr/include/glib-2.0/gobject/gtype.h:26, from /usr/include/glib-2.0/gobject/gboxed.h:26, from /usr/include/glib-2.0/glib-object.h:25, from /usr/include/glib-2.0/gio/gioenums.h:30, from /usr/include/glib-2.0/gio/giotypes.h:30, from /usr/include/glib-2.0/gio/gio.h:28, from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30, from /usr/include/gtk-2.0/gdk/gdk.h:32, from /usr/include/gtk-2.0/gtk/gtk.h:32, from xmp-model.h:25, from xmp-schemas.c:21: /usr/lib/gcc/i486-linux-gnu/4.3.3/include/stddef.h:152: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’

I'm just wondering what I'm doing wrong here. If there is more code needed, I could probably attach it to a bug or put it on the net somewhere.
Am I mixing some fundamentals of Gtk and GObject programming here?

Cheers,

Roman Joost
2009-07-16 08:49:38 UTC (over 15 years ago)

Problem with creating/compiling XMPModel which inherits from GObject

On Thu, Jul 16, 2009 at 04:26:41PM +1000, Roman Joost wrote:

Hi,

I thought it would be handy, if my XMPModel which stores the XMP metadata could emit it's own signals if properties or schemas change.

The model now inherits from GObject and but most of the data structure is unchanged:

[...]

I'm just wondering what I'm doing wrong here. If there is more code needed, I could probably attach it to a bug or put it on the net somewhere.

Just in case someone needs to look at the patch:

http://amy.gocept.com/~roman/0001-WIP-XMPModel-object-with-custom-signals.patch

Cheers,

Martin Nordholts
2009-07-16 16:24:47 UTC (over 15 years ago)

Problem with creating/compiling XMPModel which inherits from GObject

On 07/16/2009 08:26 AM, Roman Joost wrote:

Hi,

I thought it would be handy, if my XMPModel which stores the XMP metadata could emit it's own signals if properties or schemas change.

I'm just wondering what I'm doing wrong here. If there is more code needed, I could probably attach it to a bug or put it on the net somewhere.
Am I mixing some fundamentals of Gtk and GObject programming here?

Hi,

The errors are due to that header files are included in the wrong order in the translation units (c files). Moving these around a bit solves your compilation problems, I've attached a patch that should be applied on top of your patch. (You can squash the commits together with an interactive git rebase)

There are alternative ways to attack this problem, one is to add a metadata-types.h header file with

typedef struct _XMPType XMPType; ...

and then include that early in the .c files. That way the order of inclusion below does not matter

BR, Martin

From a6793ad5b6c8048bbbdb4678048cfa41d3fc934a Mon Sep 17 00:00:00 2001

From: Martin Nordholts
Date: Thu, 16 Jul 2009 16:19:34 +0200 Subject: [PATCH] Fix compilation for WiP metadata plug-in

--- plug-ins/metadata/exif-decode.c | 2 +- plug-ins/metadata/interface.c | 3 ++- plug-ins/metadata/interface.h | 1 - plug-ins/metadata/metadata.c | 3 +++ plug-ins/metadata/xmp-encode.c | 2 +- plug-ins/metadata/xmp-encode.h | 1 + plug-ins/metadata/xmp-model.c | 6 ++++++ plug-ins/metadata/xmp-schemas.c | 5 ++++- 8 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/plug-ins/metadata/exif-decode.c b/plug-ins/metadata/exif-decode.c index 8123ad0..013d0be 100644
--- a/plug-ins/metadata/exif-decode.c +++ b/plug-ins/metadata/exif-decode.c @@ -28,8 +28,8 @@

#include

-#include "xmp-model.h"
#include "xmp-schemas.h"
+#include "xmp-model.h"
#include "exif-decode.h"


diff --git a/plug-ins/metadata/interface.c b/plug-ins/metadata/interface.c index 12cf001..8cf9614 100644
--- a/plug-ins/metadata/interface.c
+++ b/plug-ins/metadata/interface.c
@@ -48,9 +48,10 @@

#include "libgimp/stdplugins-intl.h"
+#include "xmp-schemas.h"
+#include "xmp-model.h"
#include "interface.h"
#include "metadata.h"
-#include "xmp-schemas.h"
#include "xmp-encode.h"


diff --git a/plug-ins/metadata/interface.h b/plug-ins/metadata/interface.h index efe1ae3..804a36c 100644
--- a/plug-ins/metadata/interface.h
+++ b/plug-ins/metadata/interface.h
@@ -21,7 +21,6 @@
#define INTERFACE_H

#include
-#include "xmp-model.h"

G_BEGIN_DECLS

diff --git a/plug-ins/metadata/metadata.c b/plug-ins/metadata/metadata.c index 8e59a2f..1b3fda3 100644
--- a/plug-ins/metadata/metadata.c
+++ b/plug-ins/metadata/metadata.c
@@ -21,6 +21,8 @@

#include

+#include
+
#include

#include
@@ -28,6 +30,7 @@
#include "libgimp/stdplugins-intl.h"
#include "metadata.h"
+#include "xmp-schemas.h"
#include "xmp-encode.h"
#include "interface.h"
#include "exif-decode.h"
diff --git a/plug-ins/metadata/xmp-encode.c b/plug-ins/metadata/xmp-encode.c index 485dfc0..7d85171 100644
--- a/plug-ins/metadata/xmp-encode.c +++ b/plug-ins/metadata/xmp-encode.c @@ -21,7 +21,7 @@

#include

-#include
+#include

#include

diff --git a/plug-ins/metadata/xmp-encode.h b/plug-ins/metadata/xmp-encode.h index e546730..1959d4f 100644
--- a/plug-ins/metadata/xmp-encode.h +++ b/plug-ins/metadata/xmp-encode.h @@ -20,6 +20,7 @@
#define XMP_ENCODE_H

#include
+#include "xmp-schemas.h"
#include "xmp-model.h"

G_BEGIN_DECLS
diff --git a/plug-ins/metadata/xmp-model.c b/plug-ins/metadata/xmp-model.c index 8f4cccf..9bf9f69 100644
--- a/plug-ins/metadata/xmp-model.c
+++ b/plug-ins/metadata/xmp-model.c
@@ -58,6 +58,12 @@ xmp_model_class_init (XMPModelClass *klass)
klass->property_changed = NULL;
}
+
+static void
+xmp_model_init (XMPModel *xmp_model) +{
+}
+
/**
* xmp_model_new:
*
diff --git a/plug-ins/metadata/xmp-schemas.c b/plug-ins/metadata/xmp-schemas.c index e97b1f8..08a8e02 100644
--- a/plug-ins/metadata/xmp-schemas.c +++ b/plug-ins/metadata/xmp-schemas.c @@ -18,8 +18,11 @@
*/

#include "config.h"
-#include "xmp-model.h"
+
+#include
+
#include "xmp-schemas.h"
+#include "xmp-model.h"

static XMPProperty dc_properties[] = {

Roman Joost
2009-07-17 08:55:29 UTC (over 15 years ago)

Problem with creating/compiling XMPModel which inherits from GObject

Hi Martin,

On Thu, Jul 16, 2009 at 04:27:01PM +0200, Martin Nordholts wrote:

The errors are due to that header files are included in the wrong order in the translation units (c files). Moving these around a bit solves your compilation problems, I've attached a patch that should be applied on top of your patch. (You can squash the commits together with an interactive git rebase)

Thanks a lot! Awesome!

There are alternative ways to attack this problem [...]

Thanks a lot. That sounds very reasonable. I think I go for that solution!

Cheers,