Re: gtkmm affected by recent changes to gtk (GdkNativeWindow, gtk_toolbar_[gs]et_tooltips)

[Damon Register <damon w register lmco com>]

Armin Burgmeier wrote:
> gtkmm is ABI stable, which means that it must be possible to compile a
> program against gtkmm 2.12 and run it with gtkmm 2.14. So if we change
> the signature of a function to have different parameters, then the
> function will not be found anymore by a program linked against the older
> version, and it will refuse to run.
Now I understand more clearly.  Thanks for explaining that.  Perhaps
overloading is a better solution?  What is the best way to handle the
gtk problem?  I could put ifdefs into the gtkmm Toolbar::get_tooltips_object()
to handle this gtktoolbar.h problem

struct _GtkToolbar
{

#ifndef GTK_DISABLE_DEPRECATED
  GtkTooltips     *GSEAL (tooltips);
#else
  gpointer         GSEAL (_tooltips);
#endif

};

but wouldn't that be bad to have gtk defs mixed in with the gtkmm or is
that normal?  I can understand why someone might want to change a data
type but why the member name?  Is that for program readability, so it
is easier to tell which type is being used?  Wouldn't it make more
sense to have a typedef in gtk for tooltips so then it just uses the
typedef?  Perhaps like this?

#ifndef GTK_DISABLE_DEPRECATED
  typedef GtkTooltips* GtkTooltips_type;
#else
  typedef gpointer GtkTooltips_type;
#endif


struct _GtkToolbar
{
  GtkTooltips_type  GSEAL (tooltips);
};


Looking at my own idea, I am not sure if this would have that binary
backward compatibility problem you mentioned :-(
What do you think?

Damon Register