Is someone here related to Gst in some way?

Maybe a year ago someone asked to add Gst support to the Nim bindings, I did it and converted the basic C example to Nim:

But he did not come back :frowning:

Now we have a new Gst issue from someone different, concerning access to type of Gst message.

In C code is like

    switch (GST_MESSAGE_TYPE (msg)) {
        gst_message_parse_error (msg, &err, &debug_info);

I would assume that gobject-introspection should support a way to replace the C macro GST_MESSAGE_TYPE
with a introspection provided function, as most of GTK core does. But we were not able to find something. There are functions to get the error text or a associated quark, but no direct type access. Python bindings seems to be able to extract the type somehow, but maybe they do it not direct by introspection but somehow manually. Do we have to do it for other languages bindings manually too, that is by casting the message and accessing the type field directly?

I think you need to access the GstMessage struct directly to find the type.

By the way, the GStreamer project still uses mailing lists for discussion, you can find them here:

Yes, my impression is also that we have to access the field directly. Is a bit sad as we do not need that for most other GTK libs. Not a big problem if that is only for that single field, but for the case that there are many similar cases in Gst it is some work for me, and maybe useless work when the users vanish again fast.

I know there is a separate mailing list, but I have no idea how active they is. Would I have to subsribe first, or may I just send a mail to it? In the past I always subscribed, but then one can forget to unsubscribe and get messages for many years. And I have not much hope that they may fix it in the next 20 years, Python seems have to manage it in some way, so why should they care.

Perhaps it’s a performance related decision? I don’t know.

Yes, you normally should to subscribe to mailing lists before posting. You can check the archives first to see if it’s really active and which list would be best for your question.

No, I am sure it is not performance related. The point is that C uses a macro, and they forget to provide a function that could be used by other languages supported by gobject-introspection. And I guess languages like Python wanted to get it working fast, so the added a manually fix instead of waiting years for a fix by Gst team. Of course in this way the total amount of work is much larger, we need a fix for Rust, for Java-script and all the other bindings.

These fields are already available in GJS, for what it’s worth:

Seems like it’s a public field, so I don’t see why this would be a problem for gobject-introspection:

Thanks for reporting. So I will have to find a similar solution for the Nim bindings.

The fact is, that it is uncommon for GTK related libraries that we have to directly access fields, for nearly all objects exists accessor functions supported by gobject introspection. The exceptions are only the very basic structs like Rectangle, RGB-Color, TextIter or the plain graphene types and such that are generally allocated on the stack. The GstMessage is a dynamically allocated heap object.

But when it is for Gst only the Gst Message which is different, then it is not that much to provide support for Nim manually.

Last I checked, all the GdkEvent* types in Gtk3 are boxed types without accessor functions.

I don’t really have any plans of using Nim with GLib, but I think it makes sense for you handle boxed types in your bindings. They might be less common, but they are a part of the GNOME platform and gobject-introspection.

Thanks for the tip.

Indeed we have full support for boxed types since maybe a year or so in the Nim bindings. E. Bassi pushed me hard to support boxed types, first I had some problems understanding them, but then I managed it and indeed it is fine. For the GdkEvent I am not sure currently, but what I can remember is that in GTK4 Event handling is simpler than in GTK3 for gobject-introspection bindings. We support Gtk3 and Gtk4 for Nim, Events work fine, but generally GTK4 is not that much tested currently.

GstMessage is a boxed type, so aren’t they just automatically handled by your bindings the same way as GdkEvent* and GdkRGBA?

Yes indeed.

But the fact that an object is a boxed type in first line determines how it is freed/deallocated. It makes not really a difference how we access the fields of structs. In early versions of the Nim bindings we generated all the fields of the structs, so generally we could access the fields directly. But as gobject-introspection supports getter and setter functions for all public fields in GTK3 and GTK 4, we have decided around one year ago that it makes not really sense to generate the fields. Exceptions are the stack allocated primitive types like TextIter, Rectangle, RGB-Color, graphene types and some more. We have already a lot of Nim GTK examples and some user applications, and we have never needed direct field access elsewhere. Of course there may be exceptions that we have not yet discovered.

The GstMessage is an exception, we will generate the fields for that struct and provide manually created accessor functions in the next release.

Note that Nim uses Garbage Collectors, and that we use proxy objects for the heap allocated Gobjects in combination with the GTK toggle references for true GObjects. For GstMessage we do not use toggle references as GstMessage is not a true GObject, but we use gBoxedFree for releasing memory.

So it is all fine really. The question was only if we have in opposition to most other GTK related structs to generate the fields to access the type field, and the answer seems to be that we have to do so, as Gst authors have on some way forgotten to provide a introspectable function.

If you want to know how our bindings code looks, here is a snippet of the Gst Message related code:

  Message00* {.pure.} = object
  Message* = ref object
    impl*: ptr Message00
    ignoreFinalizer*: bool

proc gst_message_get_type*(): GType {.importc, libprag.}

proc gBoxedFreeGstMessage*(self: Message) =
  if not self.ignoreFinalizer:
    boxedFree(gst_message_get_type(), cast[ptr Message00](self.impl))

when defined(gcDestructors):
  proc `=destroy`*(self: var typeof(Message()[])) =
    if not self.ignoreFinalizer and self.impl != nil:
      boxedFree(gst_message_get_type(), cast[ptr Message00](self.impl))
      self.impl = nil

proc gst_message_new_application(src: ptr Object00; structure: ptr Structure00): ptr Message00 {.
    importc, libprag.}

proc newMessageApplication*(src: Object = nil; structure: Structure): Message =
  fnew(result, gBoxedFreeGstMessage)
  result.impl = gst_message_new_application(if src.isNil: nil else: cast[ptr Object00](src.impl), cast[ptr Structure00](structure.impl))
  if result.impl.isNil:
    return nil

Message00 stands for the C struct of the GstMessage, as you can see we have not created fields. But we could, gobject-introspection provides all the fields. The Message without the 00 ending is our Nim Proxy object, that is handled by the Nim GarbageCollector. And the GC uses finalizers or destructors to deallocate the C struct when the NimProxy object is released, for deallocating the C struct the gboxed types functions are used.

But I wonder why you want to know all these details. Are you writing bindings yourself? Are you the author of the JavaScript bindings?

No, I’m not the maintainer of GJS, but I work with them a reasonable amount and I also define boxed types in my own APIs.

The reason I’m curious, is you seem to be convinced that upstream libraries are making a mistake or being forgetful by not including getter/setter functions for their boxed types. I really don’t see it that way.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.