Gtk4 decided that some Classes/Object should be final and can’t be subclassed/inherited.
After a question on irc, @ebassi has responded that the proper way to construct custom object is to compose it from Gtk4 Classes.
For the following scenario, what would be the proper process:
I want to create a custom Image, so I inherit my class form GtkWidget, add GtkImage as a member variable and construct it the way I want, implement the measure function, set the image.parent to the class, the question is:
how to deleget the snapshot virtual function to the image? If I just call image.snapshot (snapshot); from inside the virtual function, I get nothing drawn to the surface?
How would one achieve this?
in the init function, create a GtkImage instance and call gtk_widget_set_parent() with parent being your derived widget
in the dispose implementation, call gtk_widget_unparent() on the GtkImage child widget
You don’t need measure() or snapshot() overrides: the size negotiation and allocation are going to be handled by the GtkBinLayout layout manager, and GtkWidget's default implementation of the snapshot() virtual function automatically recurses through all the children of a widget.
If you only override measure() and don’t override size_allocate(), your child widget will have a size of 0×0, unless you also set the expand/align flags on the child widget to always expand and fill. You should use a layout manager, though; it’s easier.
that’s right. this refers to the class instance. but after a few trials, I’ve discovered that this warning occurs only on the first instance. Creating more than one instance works well for the second and thereafter. For example:
box.append (new CustomWidget (param)); // emits warning, don't paint
box.append (new CustomWidget (param2)); // works
box.append (new CustomWidget (param3)); // works
Again, it is often difficult to figure out which mechanism to use to hook into the object’s destruction process: when the last g_object_unref function call is made, a lot of things happen as described in Table 5, “g_object_unref”.
The destruction process of your object is in two phases: dispose and finalize. This split is necessary to handle potential cycles due to the nature of the reference counting mechanism used by GObject, as well as dealing with temporary revival of instances in case of signal emission during the destruction sequence. See the section called “Reference counts and cycles” for more information.