GNOME Bugzilla – Bug 762754
New GtkGrid/GtkCssGadget warnings have no obvious fix
Last modified: 2016-03-07 13:33:28 UTC
Commit dde33623 fixed a previous problem where Meld's GtkGrid subclass wouldn't render at all, but now we get constant debug spew complaining about missing allocations. The allocations of every child in the GtkGrid are *identical* between both our subclass and a normal GtkGrid itself; removing the size_allocate override gets rid of the warnings. I've tried everything I can think of to get this to work. I would be at the point of reimplementing GtkGrid's calls to GtkCssGadget APIs, but GtkCssGadget isn't exposed via introspection. Since the GtkCssGadget changes seem to have changed the required behaviour for subclasses, can these APIs be exposed, preferably with some docs on what we need to do here?
I think the simple rule in the short term is: if you override size_allocate, you need to override draw as well. The reason for that is that the GtkGrid draw function is using its gadgets to draw, and gadgets require a size allocation in order to be drawn, which they will not get if you override size_allocate (and don't chain up).
The better advice is to chain up in both your size-allocate and your draw handler.
I have updated https://wiki.gnome.org/HowDoI/CustomWidgets to mention chaining up in size_allocate, and I've added a release note in https://git.gnome.org/browse/gtk+/tree/README.in#n87
Sorry for being slow to respond. Thanks for the documentation fixes, that's all good. On a more general level, are there plans to expose the hooks called by GtkCssGadget as vfuncs? and will GtkCssGadget become public API? While I'm happy to have a fix (and yes, chaining up before doing our customer allocation fixes this just fine) it just feels weird that the widget will be doing size allocation calculations twice.
(In reply to Kai Willadsen from comment #4) > Sorry for being slow to respond. Thanks for the documentation fixes, that's > all good. > > will GtkCssGadget become public API? Unknown