[gstreamer-bugs] [Bug 518934] Facilitating wrapping of GstTagList by glibmm

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=518934

  GStreamer | gstreamer (core) | Ver: HEAD CVS

José Alburquerque changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED




------- Comment #15 from José Alburquerque  2008-04-13 12:05 UTC -------
Okay, I was able to find a solution that allows wrapping of GstTagList for now.
 I implemented a custom class macro like the one used for GstStructure but with
an extra parameter to the wrap method so that the ambiguities between
"Gst::TagList Glib::wrap(GstStructure*)" and "Gst::Structure
Glib::wrap(GstStructure*)" disappear.

I might not have explained that the reason for the ambiguities is that
GstTagList is declared with "typedef GstStructure GstTagList" which in essence
makes it a GstStructure and since C++ is strongly typed, it takes GstTagList to
in fact be a GstStructure thus causing the ambiguity above.  This makes it
impossible to use the same class macro for GstTagList as for GstStructure.

Further, I had to have gmmproc generate the TagList.h and TagList.c files from
the TagList.hg and TagList.ccg (the actual source files we edit and work with
to wrap the API) and remove the top section from the *.h file where GstTagList
is declared as "typedef struct _GstTagList GstTagList".  The only way this top
section would not be a problem is if GstTagList is actually declared as
"typedef struct _GstTagList GstTagList" in the C API.

I can no longer rely on the build process for the *.h and *.c files to be
automatically generated.  To make changes, I must re-edit the *.hg and *.ccg
files, add these files again as dependencies in the build process, run the
build process to regenerate the *.h and *.c files, remove the "typedef struct
_GstTagList ..." from the top of the *.h file and remove the *.hg and *.ccg
from the build dependency once again to avoid problems for end users.

As a closing question:  Would the following excerpt from the "How to define and
implement a new GObject" section
(http://library.gnome.org/devel/gobject/unstable/howto-gobject.html) of the
GObject reference where "typedef struct ...." is used to declare types apply to
GstTagList (I'm still trying to fully understand the GType/GObject programming
guidelines)?  If they don't I'll be perfectly happy to continue to use the
above described method to continue wrapping GstTagList; if they do maybe this
can be something considered for future?  Thanks:


...

 The basic conventions for any header which exposes a GType are described in
the section called “Conventions”. Most GObject-based code also obeys one of
of the following conventions: pick one and stick to it.

    * If you want to declare a type named bar with prefix maman, name the type
instance MamanBar and its class MamanBarClass (name is case-sensitive). It is
customary to declare them with code similar to the following:

      /*
       * Copyright/Licensing information.
       */

      #ifndef MAMAN_BAR_H
      #define MAMAN_BAR_H

      /*
       * Potentially, include other headers on which this header depends.
       */

      /*
       * Type macros.
       */

      typedef struct _MamanBar MamanBar;
      typedef struct _MamanBarClass MamanBarClass;

      struct _MamanBar {
        GObject parent;
        /* instance members */
      };

      struct _MamanBarClass {
        GObjectClass parent;
        /* class members */
      };

      /* used by MAMAN_TYPE_BAR */
      GType maman_bar_get_type (void);

      /*
       * Method definitions.
       */

      #endif


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=518934.