Gtk_no_selection_new()

[StefanSalewski]

Someone tried to make a Nim version based on the first example from

Gtk4-tutorial/sec24.md at main · ToshioCP/Gtk4-tutorial · GitHub

and got some trouble, see

Invalid object conversion [ObjectConversionDefect] gobject.Object to StringObject · Issue #128 · StefanSalewski/gintro · GitHub

Unfortunately I do know not much about the listview/treeview stuff currently, I read about it in 2007 in the Krause book, but forget most.

My current idea is that the function

GtkNoSelection: GTK 4 Reference Manual

      <constructor name="new" c:identifier="gtk_no_selection_new">
        <doc xml:space="preserve"
             filename="../gtk/gtknoselection.c"
             line="214">Creates a new selection to handle @model.</doc>
        <source-position filename="../gtk/gtknoselection.h" line="33"/>
        <return-value transfer-ownership="full">
          <doc xml:space="preserve"
               filename="../gtk/gtknoselection.c"
               line="220">a new `GtkNoSelection`</doc>
          <type name="NoSelection" c:type="GtkNoSelection*"/>
        </return-value>
        <parameters>
          <parameter name="model"
                     transfer-ownership="full"
                     nullable="1"
                     allow-none="1">
            <doc xml:space="preserve"
                 filename="../gtk/gtknoselection.c"
                 line="216">the `GListModel` to manage, or %NULL</doc>
            <type name="Gio.ListModel" c:type="GListModel*"/>
          </parameter>
        </parameters>
      </constructor>

does not increase the reference count on the passed model parameter?

The parameter is an in parameter with transfer-ownership=“full” and is an gobject. I guess not too many functions have that signature.

From Projects/GObjectIntrospection/Annotations - GNOME Wiki! we have for transfer mode full: “the recipient owns a ref on the value.”

But I think my understanding was wrong, I assumed a behavior as for gtk containers like windows with functions like gtk_window_set_child() where the function increases the ref count with g_object_ref_sink() call.

When gtk_no_selection_new() really is not assumed to increase the ref count of the passed gobject, then I have to take care that my Nim proxy object does not call g_object_unref() on the gobject when the proxy object goes out of scope. Well the Nim bindings could ref the gobject, or we could detach the proxy object from the gobject, so that the proxy object is freed when it goes out of scope, but does not unref the gobject.

PS: I think I just found a way how I can use links and avoid that the forum software inserts that page, I can put a few spaces in front of the link.

[ebassi (Emmanuele Bassi)]

@StefanSalewski

Unfortunately I do know not much about the listview/treeview stuff currently, I read about it in 2007 in the Krause book, but forget most.

The GtkNoSelection object has nothing to do with the old GTK2/3 GtkTreeView API; it is part of the new list and tree widget API. You won’t find examples of its use in old books.

@StefanSalewski

does not increase the reference count on the passed model parameter?

No, it does not. It is marked transfer full for a reason: any selection models (GtkNoSelection, GtkSingleSelection, and GtkMultiSelection) are wrappers around a GListModel implementation; as such, you need to ensure that the original list model is always available.

@StefanSalewski

But I think my understanding was wrong, I assumed a behavior as for gtk containers like windows with functions like gtk_window_set_child() where the function increases the ref count with g_object_ref_sink() call.

No, that’s never been the case.

The transfer full annotation means that the ownership of the argument is fully transferred to the callee.

It is, to an extent, the alternative of a floating reference. After the call, you don’t own the object you created any more, so you must not call g_object_unref() on it. The transfer full annotation is the dual of a transfer none: the ownership of the object, in that case, remains with you; if the callee wishes to keep the object around, then in needs to acquire a reference on it.

@StefanSalewski

then I have to take care that my Nim proxy object does not call g_object_unref() on the gobject when the proxy object goes out of scope.

You always had to do that. It’s not like the full ownership transfer is new functionality: it’s part of the existing API contract.

[StefanSalewski]

Thanks for your detailed advice.

@ebassi

The GtkNoSelection object has nothing to do with the old GTK2/3 GtkTreeView API; it is part of the new list and tree widget API. You won’t find examples of its use in old books.

Fine, I got the feeling that I had forgot really all what I learned in 2007 from the old GTK2 book of A. Krause. But when it is new, I have again more stuff to learn.

You always had to do that.

Sure. But on the other hand I have of course to ensure that Widgets and other refcounted entities are destroyed whenever they are not used/needed any more.

[matthiasc (Matthias Clasen)]

@ebassi

No, it does not. It is marked transfer full for a reason: any selection models (GtkNoSelection, GtkSingleSelection, and GtkMultiSelection) are wrappers around a GListModel implementation; as such, you need to ensure that the original list model is always available.

And, to expand on that: this is to facilitate chained constructors in C, like this:

model = gtk_no_selection_new (gtk_filter_list_model_new (filter,  store));