Does Gtk+ Still Support Application-Provided Widgets?

[Morten Welinder <mwelinder gmail com>]

Gtk+ used to support custom widgets.  Whenever you were unhappy with
the official
set you would hack up your own.  More often than not, this would start
by copying
an official widget's code and do a mass rename of identifiers.

No more.

More and more of the api needed to created widgets is migrated into
gtk*private.h
headers rendering it inaccessible for applications.  Take GtkButton,
for example.
It includes the following private headers:

#include "gtkbuttonprivate.h"
Just a structure, but it is included also outside gtkbutton.c.  I.e.,
widgets like GtkCheckButton
are allowed special privileges that MyButton is not.

#include "gtkwidgetprivate.h"
Again, there really should not be any API that in-tree widgets are
allowed to use, but
out-of-tree widgets are not.  I can see a case for
"gtkwidgetprotected.h" in the C++ sense,
though.

#include "gtkprivate.h"
No idea.

#include "gtkapplicationprivate.h"
I don't think this one is actually used.

#include "gtkcsscustomgadgetprivate.h"
The whole gadget machinery is private.  Anyone who wants stateful css
nodes gets to
implement the whole css stack themselves.

#include "gtkcontainerprivate.h"
This is just silly.  Either something is useful for containers in
general and it should be public, or
else it is not useful and it should go into gtkcontainer.c

Suggestion:  Only gtkbutton.c should be allowed to include
gtkbuttonprivate.h and similarly
with other private headers.  Create gtkbuttonprotected.h if needed and
install it.  Add needed
API for derivation either to gtkbutton.h or gtkbuttonprotected.h.

Morten