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