Should you be able to add "Box" widgets as rows to an Expander-Row widget?

[PhilMD]

Heyho, I am once again working on contributing to a nim library that wraps gtk and provides the widgets etc. in a more declarative fashion.

I am currently seeing some unexpected behaviour in our bindings for ExpanderRow and am trying to figure out whether the problem lies somewhere in our code or not.

Explicitly:
We noticed that if you call the add_row proc of ExpanderRow and the Widget you add is not something inheriting from PreferencesRow (e.g. Box ), then we get bugs when we try to remove said widgets later with adw_expander_row_remove.

Specifically, this Warning pops up:
(process:1254433): Gtk-WARNING **: 09:19:59.162: Tried to remove non-child 0x5614565049e0

This shows up even though I can (via copious amounts of debugging and printings pointers to the terminal) see that this exact pointer gets added to ExpanderRow at one point via the add_row proc.

I’m not seeing anything obvious in our code as to why that is, so I’ve started wondering the following:
Is it maybe assumed that you shouldn’t add GtkWidgets such as Box with add_row and therefore it is not intended to function when using a Widget such as Box there?

[alicem (Alice Mikhaylenko)]

Hm, I think i’s supposed to work. Maybe it’s a bug

[PhilMD]

Alrighty in that case I’ll do some more investigating on our end as well and see if I can make more minimalistic examples to make sure it’s exactly that.
I’d chalk it up as far more likely that we made an error somewhere.

[PhilMD]

I was able to make one that cuts through most of our binding’s custom stuff.
The following is nim syntax (that’s the language the bindings are for), but for the most part should look readable… I hope.
This code-snippet gets executed when initially starting the application and instantiating all the various widgets and associating them with one another.
For elaboration:

• Echo is nim’s equivalent to python’s print
• “0.cint” is just an int literal in nim’s int type being converted to C’s int type (called cint)
• State.internalWidget is just a field where we store the pointer to the GTKWidget in, just read it like a variable

      state.internalWidget = adw_expander_row_new()
      let newBox = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 0.cint)
      echo "NewBox Pointer: ", newBox.pointer.repr
      adw_expander_row_add_row(state.internalWidget, newBox)
      adw_expander_row_remove(state.internalWidget, newBox)

This overall prints to the terminal out:

NewBox Pointer: 000056153838E6E0

(process:1269641): Gtk-WARNING **: 10:13:13.780: Tried to remove non-child 0x56153838e6e0

With using the C-procs directly in order like this it should have circumvented any bug we could’ve introduced through custom code in the bindings.

So maybe it’s a bug in adwaita, at least I don’t see where we could’ve introduced a bug there.

I’d be more comfortable with my assumption if I could verify this in a minimal example in C as well but I haven’t written a line of GTK in C ever.

Edit:
Given that everything I find out points towards this being an adwaita bug, I opened issue #758 on the gitlab repository.