vala has this vapi annotation for the type:

  [CCode (cname = "ClutterFixed",
          cheader_filename = "clutter/clutter.h",
          type_id = "CLUTTER_TYPE_FIXED",
          get_value_function = "clutter_value_get_fixed",
          set_value_function = "clutter_value_set_fixed",
          default_value = "0",
          type_signature = "i",
          marshaller_type_name = "INT")]

and this for the equivalency between a type and the C type (in this case, gint32 has the same rank):

  [IntegerType (rank = 6)]

Appears we need the following:

 get-value-function
 set-value-function
 default-value (why?)
 type-signature
 
What about the vala bindings for GstFraction/GstIntRange etc?

(In reply to comment #2)
> Appears we need the following:
> 
>  get-value-function
>  set-value-function
>  default-value (why?)

I guess for initialization on the stack; it can probably be safely ignored.

>  type-signature
> 
> What about the vala bindings for GstFraction/GstIntRange etc?

there are none; gstreamer-0.10.vapi only exposes ParamSpecFraction.

*** Bug 572420 has been marked as a duplicate of this bug. ***

Okay, I've been looking into this as a way to add support for GstMiniObject, especially in the gjs/pygi context.

Basically we need to extend the <class> tag in GIR and GIObjectInfo in libgirepository to support other fundamental types apart from G_TYPE_OBJECT.

Using GstMiniObject as an example. The headers would need to be annotated like this:

/**
 * GstMiniObject:
 *
 * SetValueFunction: gst_value_set_mini_object
 * GetValueFunction: gst_value_get_mini_object
 */

It would be represented in the GIR as:

  <class name="MiniObject"
         c:type="GstMiniObject"
         abstract="1"
         glib:is-fundamental-type="1"
         glib:type-signature="i"
         glib:type-name="GstMiniObject"
         glib:get-type="gst_mini_object_get_type"
         glib:set-value-function="gst_value_set_mini_object"
         glib:get-value-function="gst_value_get_mini_object"> .. </class>
  
These new apis would be added to GIObjectInfo:

gboolean      g_object_info_is_fundamental_type(GIObjectInfo *info);
GValueSetFunc g_object_info_get_set_value_function(GIObjectInfo *info);
GValueGetFunc g_object_info_get_get_value_function(GIObjectInfo *info);
const char *  g_object_info_get_type_signature(GIObjectInfo *info);

The GValue<->Wrapper routines in language bindings would need to be modified to receive either a set/get function or the GIObjectInfo directly.

Created attachment 163485 [details] [review]
Add support for non-GObject fundamental objects

This patch adds support for instantiable fundamental object types,
which are not GObject based. This is mostly interesting for being
able to support GstMiniObject's which are extensivly used in GStreamer.
Includes a big test case to the Everything module (inspired by
GstMiniObject) which should be used by language bindings who wishes to
test this functionallity.

This patch increases the size of the typelib and breaks compatibility
with older typelibs.

Review of attachment 163485 [details] [review]:

In the big picture, wasn't a lot of the motivation behind recent GObject optimizations is to help GstMiniObject die?  Has anyone asked the GStreamer people to reevaluate performance there?

Actually, can GstMiniObject just be treated as a boxed from a binding perspective?  All we care about is _ref/_unref, and boxeds give us that.  Basically in the scanner just lie and do if (ns = "Gst" and name = "MiniObject) return new Boxed(...)

Otherwise, looks fairly mechanical and I don't have objections.

::: gir/everything.c
@@ +1920,3 @@
+  mo_class->finalize (fundamental_object);
+
+  if (G_LIKELY (g_atomic_int_dec_and_test (&fundamental_object->refcount))) {

Not that this really matters, but this isn't a valid use of G_LIKELY/G_UNLIKELY; as I understand it, missing them can be really quite expensive, and it's totally valid for a refcount to go to 0, in fact quite often.

They were added for implementing g_assert type stuff basically.

(In reply to comment #7)
> Review of attachment 163485 [details] [review]:
> 
> In the big picture, wasn't a lot of the motivation behind recent GObject
> optimizations is to help GstMiniObject die?  Has anyone asked the GStreamer
> people to reevaluate performance there?

GObject will always be larger and slower, unless we plan to break the ABI.
GStreamer uses GstMiniObject in their APIs and its unlikely that they want to break it,
so we'll just have to live with that.

> 
> Actually, can GstMiniObject just be treated as a boxed from a binding
> perspective?  All we care about is _ref/_unref, and boxeds give us that. 
> Basically in the scanner just lie and do if (ns = "Gst" and name = "MiniObject)
> return new Boxed(...)
> 

Well, boxed gives us free/copy which is not quite the same as ref counting.
Fundamentals also support derivation which Boxed doesn't. So it sits in
the middle between GObject and GBoxed.

> Otherwise, looks fairly mechanical and I don't have objections.
> 
> ::: gir/everything.c
> @@ +1920,3 @@
> +  mo_class->finalize (fundamental_object);
> +
> +  if (G_LIKELY (g_atomic_int_dec_and_test (&fundamental_object->refcount))) {
> 
> Not that this really matters, but this isn't a valid use of
> G_LIKELY/G_UNLIKELY; as I understand it, missing them can be really quite
> expensive, and it's totally valid for a refcount to go to 0, in fact quite
> often.
> 
> They were added for implementing g_assert type stuff basically.

This is just copied over from GStreamer, TestFundamentalObject == GstMiniObject but
with unnecessary api stripped. Better to keep the implementation close to that. You should submit
a GStreamer bug if you think strongly about it though.

There are a few small things missing in this patch, but I don't want to updated until I can validate it,
which currently means that I need to finish a proof of concept in gjs to support it.

(In reply to comment #8)
> (In reply to comment #7)
> > Review of attachment 163485 [details] [review] [details]:
> > 
> > In the big picture, wasn't a lot of the motivation behind recent GObject
> > optimizations is to help GstMiniObject die?  Has anyone asked the GStreamer
> > people to reevaluate performance there?
> 
> GObject will always be larger and slower, unless we plan to break the ABI.
> GStreamer uses GstMiniObject in their APIs and its unlikely that they want to
> break it,
> so we'll just have to live with that.

Ok, well I just asked on #gstreamer.  No one has benchmarks, but the real problem is there's no plan for 1.0 in the near future, so they can't break ABI.

So we'll need this patch or something like it.
 
> Well, boxed gives us free/copy which is not quite the same as ref counting.

Boxed is sort of a generalization of refcounting where you just set copy=ref, free=unref.  (It took me a long time to get this).

> Fundamentals also support derivation which Boxed doesn't. 

Good point, yes.

Also I'd like to batch up API/ABI breaks. 

Let's make a 0.8 branch and commit breaks (such as this typelib one) to master, hopefully really getting to 1.0 in time for GNOME 3?

Created attachment 163758 [details] [review]
Add support for non-GObject fundamental objects

This patch adds support for instantiable fundamental object types,
which are not GObject based. This is mostly interesting for being
able to support GstMiniObject's which are extensivly used in GStreamer.
Includes a big test case to the Everything module (inspired by
GstMiniObject) which should be used by language bindings who wishes to
test this functionallity.

This patch increases the size of the typelib and breaks compatibility
with older typelibs.

Review of attachment 163758 [details] [review]:

Looks fine

The following fix has been pushed:
1e9822c Add support for non-GObject fundamental objects

Created attachment 165555 [details] [review]
Add support for non-GObject fundamental objects

This patch adds support for instantiable fundamental object types,
which are not GObject based. This is mostly interesting for being
able to support GstMiniObject's which are extensivly used in GStreamer.
Includes a big test case to the Everything module (inspired by
GstMiniObject) which should be used by language bindings who wishes to
test this functionallity.

This patch increases the size of the typelib and breaks compatibility
with older typelibs.

*** Bug 594236 has been marked as a duplicate of this bug. ***

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]