Skip to content

Move away from `GtkContainer` APIs

Arun Mani J requested to merge arun-mani-j/phosh:decontainer into main

In GTK 4, there is no GtkContainer. Instead, the widgets with children are grouped into two categories.

  1. Single-child widgets like GtkButton, AdwStatusPage.
  2. Multi-children widgets like GtkBox.

For the first case, GTK has moved to the style of exposing the child as properties. This way, they are now put inside <property> slots of UI files.

For the second case, the widgets are expected to provide methods to add and remove children. To add them through UI files, the widget has to implement the GtkBuildable interface.

Since there is no GtkContainer, we have to provide methods to add and remove children anyway. This is the first goal of this MR. If A is a container and is used by Xs widgets, then we want all of those Xs to use A's method to add and remove children. This way, when we are doing the actual GTK 4 move, we need to touch only A's code and all other Xs will be left untouched. Thus easy to review and test.

In Phosh, most of the parent widgets belong to single-child widgets. So to stay in consistency with GTK 4 style and be future-proof, I think it's good we adapt this style too. Propertifying child widgets also reduces the code complexity (of now and edge-cases we are yet to see in GTK 4), as we longer no need to hijack base class's add and remove methods to separate internal children and public child. Also with GTK now moving towards composition over inheritance, I think this is a safe bet.

This MR initially migrates the quick-settings section. Based on feedback and suggestions, I will expand it to other widgets too.

CC: @guidog @gautham_x

Merge request reports

Loading