Re: Does Gtk+ Still Support Application-Provided Widgets?

[philip chimento gmail com]

Hi,

To a certain, lesser, extent this has always been the case: for example, I filed [1] a long time ago because you can't write your own GtkContainer subclass with an internal layout manager and have gtk_container_add() and gtk_container_remove() still work on it, although GtkAssistant does this and gets special privileges to allow it.

I'm not a core GTK developer so I don't know why things were set up this way, but I assume it's because no-one (yet) wants to guarantee the stability of the API in the private files, and once it's been declared stable it'll be exposed. I hope that particularly the CSS gadget stuff is eventually meant to be public, but if it were public before it was stable, then people's custom widgets would just break on each new release anyway, right?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=699756

Regards,

Philip C

On Sun, May 1, 2016 at 9:20 AM Morten Welinder <mwelinder gmail com> wrote:

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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list