Anpassade behållare
When deriving a custom container widget directly from Gtk::Widget, you should override the following virtual methods:
get_request_mode_vfunc(): Return what Gtk::SizeRequestMode is preferred by the container.
measure_vfunc(): Calculate the minimum and natural width or height of the container.
size_allocate_vfunc(): Position the child widgets, given the height and width that the container has actually been given.
The get_request_mode_vfunc(), measure_vfunc(), and size_allocate_vfunc() virtual methods control the layout of the child widgets. For instance, if your container has 2 child widgets, with one below the other, your get_request_mode_vfunc() might request height-for-width layout. Then your measure_vfunc() might report the maximum of the widths of the child widgets when asked to report width, and it might report the sum of their heights when asked to report height. If you want padding between the child widgets then you would add that to the width and height too. Your widget's container will use this result to ensure that your widget gets enough space, and not less. By examining each widget's parent, and its parent, this logic will eventually decide the size of the top-level window.
You are not guaranteed to get the Gtk::SizeRequestMode that you request. Therefore measure_vfunc() must return sensible values for all reasonable values of its input parameters. For a description of measure_vfunc()'s parameters see also the description of Gtk::Widget::measure(), which may be better documented than measure_vfunc().
size_allocate_vfunc() receives the actual height and width that the parent container has decided to give to your widget. This might be more than the minimum, or even more than the natural size, for instance if the top-level window has been expanded. You might choose to ignore the extra space and leave a blank area, or you might choose to expand your child widgets to fill the space, or you might choose to expand the padding between your widgets. It's your container, so you decide.
Your container must unparent its children before the underlying C object (a gtkmm__GtkWidget) is finalized. If your container is used as a managed widget, it shall unparent its children in a Gtk::Widget::signal_destroy() handler (available since gtkmm 4.8). If your container is not managed, that signal handler is not called. Instead the children shall be unparented in the C++ destructor. If you want your container to be useful both ways, unparent the children both in the destructor and in a signal handler. See the example code.
Exempel
This example implements a container with child widgets, one above the other. Of course, in this case it would be far simpler just to use a vertical Gtk::Box or Gtk::Grid.