Custom Widgets
gtkmm makes it very easy to derive new widgets by inheriting from an existing widget class, either by deriving from a container and adding child widgets, or by deriving from a single-item widget, and changing its behaviour. But you might occasionally find that no suitable starting point already exists. In this case, you can implement a widget from scratch.

Custom Containers
When deriving from Gtk::Container, you should override the following virtual methods:
get_request_mode_vfunc(): Return what Gtk::SizeRequestMode is preferred by the container.
get_preferred_width_vfunc(): Calculate the minimum and natural width of the container.
get_preferred_height_vfunc(): Calculate the minimum and natural height of the container.
get_preferred_width_for_height_vfunc(): Calculate the minimum and natural width of the container, if it would be given the specified height.
get_preferred_height_for_width_vfunc(): Calculate the minimum and natural height of the container, if it would be given the specified width.
on_size_allocate(): Position the child widgets, given the height and width that the container has actually been given.
forall_vfunc(): Call the same callback for each of the children.
on_add(): Add a child widget to the container.
on_remove(): Remove a child widget from the container.
child_type_vfunc(): Return what type of child can be added.
The get_request_mode_vfunc(), get_preferred_width_vfunc(), get_preferred_height_vfunc(), get_preferred_width_for_height_vfunc(), get_preferred_height_for_width_vfunc(), and on_size_allocate() 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 get_preferred_width_vfunc() might report the maximum of the widths of the child widgets, and get_preferred_height_for_width_vfunc() might report the sum of their heights. 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 all four of the get_preferred_xxx_vfunc() methods must return sensible values.
on_size_allocate() 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. Don't forget to call set_allocation() inside your on_size_allocate() implementation to actually use the allocated space that has been offered by the parent container.
Unless your container is a top-level window that derives from Gtk::Window, you should probably also call Gtk::Widget::set_has_window(false) in your constructor. This means that your container does not create its own Gdk::Window, but uses its parent's window. (Note the difference between Gtk::Window and Gdk::Window.) If your container does need its own Gdk::Window, and does not derive from Gtk::Window, you must also override the on_realize() method as described in the Custom Widgets section. And unless your container draws directly onto the underlying Gdk::Window, you should probably call set_redraw_on_allocate(false) to improve performance.
By overriding forall_vfunc() you can allow applications to operate on all of the container's child widgets. For instance, show_all_children() uses this to find all the child widgets and show them.
Although your container might have its own method to set the child widgets, you should still provide an implementation for the virtual on_add() and on_remove() methods from the base class, so that the add() and remove() methods will do something appropriate if they are called.
Your implementation of the child_type_vfunc() method should report the type of widget that may be added to your container, if it is not yet full. This is usually Gtk::Widget::get_type() to indicate that the container may contain any class derived from Gtk::Widget. If the container may not contain any more widgets, then this method should return G_TYPE_NONE.

Example
This example implements a container with two child widgets, one above the other. Of course, in this case it would be far simpler just to use a vertical Gtk::Box.

Custom Container
Source Code

Custom Widgets
By deriving directly from Gtk::Widget you can do all the drawing for your widget directly, instead of just arranging child widgets. For instance, a Gtk::Label draws the text of the label, but does not do this by using other widgets.
When deriving from Gtk::Widget, you should override the following virtual methods. The methods marked (optional) need not be overridden in all custom widgets. The base class's methods may be appropriate.
get_request_mode_vfunc(): (optional) Return what Gtk::SizeRequestMode is preferred by the widget.
get_preferred_width_vfunc(): Calculate the minimum and natural width of the widget.
get_preferred_height_vfunc(): Calculate the minimum and natural height of the widget.
get_preferred_width_for_height_vfunc(): Calculate the minimum and natural width of the widget, if it would be given the specified height.
get_preferred_height_for_width_vfunc(): Calculate the minimum and natural height of the widget, if it would be given the specified width.
on_size_allocate(): Position the widget, given the height and width that it has actually been given.
on_realize(): Associate a Gdk::Window with the widget.
on_unrealize(): (optional) Break the association with the Gdk::Window.
on_map(): (optional)
on_unmap(): (optional)
on_draw(): Draw on the supplied Cairo::Context.
The first 6 methods in the previous table are also overridden in custom containers. They are briefly described in the Custom Containers section.
Most custom widgets need their own Gdk::Window to draw on. Then you can call Gtk::Widget::set_has_window(true) in your constructor. (This is the default value.) If you do not call set_has_window(false), you must override on_realize() and call Gtk::Widget::set_realized() and Gtk::Widget::set_window() from there.

Example
This example implements a widget which draws a Penrose triangle.

Custom Widget
Source Code