Re: Stable glibmm and gtkmm releases soon

[Murray Cumming <murrayc murrayc com>]

On Tue, 2013-03-26 at 11:30 +0100, Murray Cumming wrote:
> Well, they are listed as "derived Interfaces", because they "require"
> the GTlsConnection type. Or, in other words, it is a "Prerequisite".
> See
> the G_DEFINE_INTERFACE() lines. Looking at all these made me notice
> some
> similar things we should fix some time:
> https://git.gnome.org/browse/glibmm/commit/?id=c43ced750b04b8ae0556e8dfe317a4dbb6da327f
>
> For GTlsConnection it's a bit odd, because GTlsConnection is not an
> interface, though GTlsClientConnection and GTlsServerConnection are. I
> guess the glib developers are aware of the oddness of this, having
> consciously chosen to give their interfaces some default
> implementation.

Some more thoughts:

I think we generally only want to represent the "preequisite" as a C++
inheritance when it's an interface depending on an interface. When it's
an interface requiring an actual type then it doesn't seem useful to us.

For instance:
* GtkActionAble requires GtkWidget (rather than the default GObject).
  We have a TODO to add Actionable as a base class of _all_ derived
Widgets, because they _implement_ that base interface.

* GtkAppChooser requires GtkWidget (rather than the default GObject)
  AppChooserButton derives from, and implements, GtkAppChooser.

* GtkFileChooser requires GtkWidget (rather than the default GObject)
  GtkFileChooserDialog derives from, and implements GtkFileChooser.

Now, TlsClientConnection (an interface) requires TlsConnection (not an
interface), so we could choose to treat this like GtkFileChooser
requiring GtkWidget. To decide, I think we need to see how the types are
used polymorphically, if at all.

But I don't actually see any use of any of these types in the rest of
the API, so it's hard for me to judge. I am tempted to not wrap them for
now.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com