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

Reply via email to