Vala owned variables and GTK container floating-reference ownership at widget reparenting

Question

Goal: construct a GTK widget in Vala, assign it to an owned variable, then add it to a container, while preserving the widget's floating-reference contract across the language boundary.
Vala represents owned and unowned references using GObject reference counting, but GTK widgets begin with a floating reference that a container normally sinks. The Vala type system does not encode this contract, so the compiler generally accepts an owned variable passed to a container add operation without diagnosing whether the floating reference is transferred, sunk, or leaked. GTK4 changes container reference semantics, so the sinking behavior depends on the toolkit version.
Does assigning a newly created widget to an owned Vala variable prevent the container from sinking its floating reference? Should the variable be declared unowned, or should the reference be explicitly transferred before container addition? What differences exist in this ownership boundary between GTK3 and GTK4?

Tasadduq Burney · Answer

Direct Answer
p>Assigning a newly created widget to an owned Vala variable does not prevent the container from sinking its floating reference. The container sinks the floating reference regardless of whether the Vala variable is declared owned or unowned. Vala's type system manages strong reference counting but does not natively track the underlying GObject floating-reference state.

Confirmed Behavior

A new GTK widget starts with a floating reference (reference count: 1, floating flag set).
  Assigning it to an owned Vala variable adds a second strong reference (reference count: 2, floating flag still set).
  Calling container.add(widget) (GTK3) or container.append(widget) / container.set_child(widget) (GTK4) sinks the floating reference: the flag is cleared, and the container acquires a strong reference.
  After sinking with an owned variable: the widget has two strong references (variable + container). Removing from container drops the container's reference; your variable keeps the widget alive.
  After sinking with unowned variable: the widget has one strong reference (container only). Removing from container destroys the widget unless another reference is manually acquired.

GTK3 vs GTK4 Differences
The floating-reference contract is identical between GTK3 and GTK4. The only difference is the API surface:

GTK3
      GTK4

GtkContainer.add()
      GtkWidget.append(), prepend(), set_child()

GtkContainer.remove()
      GtkWidget.unparent()

Both versions sink the child's floating reference on addition and release their strong reference on removal. No semantic change exists in ownership transfer.

Practical Recommendation

Use owned (default) when you need the widget to survive container removal (e.g., reparenting to another container or keeping a reference for later reuse).
  Use unowned when the container should be the sole owner and widget lifetime is tied strictly to the container hierarchy.
  Do not manually call ref_sink() in Vala; it is redundant and can cause double-sinking logic errors.

Verification Step
If your widget is unexpectedly destroyed or leaked, connect to the destroy signal and log the event. This distinguishes between premature destruction (missing strong reference) and leaks (extra reference preventing disposal).

Diagnostic Question
Does your code reparent the widget (remove from one container, add to another) or hold the reference beyond the container's lifetime? The answer determines whether owned or unowned is correct for your case.

GTK3	GTK4
`GtkContainer.add()`	`GtkWidget.append()`, `prepend()`, `set_child()`
`GtkContainer.remove()`	`GtkWidget.unparent()`

Vala owned variables and GTK container floating-reference ownership at widget reparenting

1 answer

Direct Answer

Confirmed Behavior

GTK3 vs GTK4 Differences

Practical Recommendation

Verification Step

Diagnostic Question

Your perspective belongs here.

0 question comments