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

[Armin Burgmeier <armin arbur net>]

On Tue, 2008-09-16 at 08:03 -0400, Damon Register wrote:
> Murray Cumming wrote:
> > Are you showing us the problem or the solution? Could you please be
> > clearer about what the problem is. And if you have a solution, could you
> Both, I thought...  I thought it was reasonably clear but I will
> attempt to present differently.
> 
> So far I have run into two problems.  The first is the GdkNativeWindow
> problem.  I found two functions in display.cc that gave compile errors.
> These functions are
> Display::selection_send_notify
> Display::get_drag_protocol
> They appear to be simple wrapper functions for the C versions.
> I changed the parameters and return type of the C++ to match the
> C.  For this I was just wanting a peer review.  Does what I did
> seem to be the correct thing to do?

I can reproduce the problems you mention when compiling gtkmm against
GTK+ 2.14.

I filed a bug for this:
http://bugzilla.gnome.org/show_bug.cgi?id=552513. In short, I think the
problem with changing the types appropriately is ABI compatibility. Feel
free to attach your patch there even if it has some problems yet. It is
easier to discuss such things on bugzilla.

> > submit it as a patch, please?
> If the answer to the above question is yes, then I will submit a
> patch
> 
> > However, I know that Armin has almost finished the new gtkmm Windows
> > installer, so maybe this has already been fixed anyway.
> Though the GdkNativeWindow change to gtk seems to be driven by the
> Windows platform, isn't it reasonable to expect that the types in
> the C++ wrapper should match the C regardless of the platform?
> 
> >> The second tooltip problem seems to be addressed by this one.
> >> http://mail.gnome.org/archives/svn-commits-list/2008-July/msg00245.html
> I get a compile error related to this one too  but I don't understand
> until I looked at it again last night.  I think I solved this one too.
> In the file gtkmm-2.12.7\gtk\gtkmm\toolbar.cc (and .h) there are two
> functions, set_tooltips and get_tooltips.  Their gtk versions
> are wrapped with #ifndef GTK_DISABLE_DEPRECATED and it seems that the]
> all-in-one gtk package has that defined so, when gtkmm compiles,
> the compile fails because the two gtkmm functions are wrapping
> gtk functions that are disabled.
> 
> I solved the tooltip problem by doing two things
> 
> 1. add #ifndef GTKMM_DISABLE_DEPRECATED before functions
>     set_tooltips and get_tooltips
> 
> 2. add --enable-deprecated-api=no to configure options
> 
> Do my analysis and solution for the tooltip problem appear correct?

The problem is not the all-in-one GTK+ package, but these few lines at
the top of toolbar.ccg:

//Define this to make sure that we don't use any of the deprecated
GtkToolbar API.
//Normally we just deprecate it in gtkmm too,
//but the GtkToolbar compatibility system is particularly unpleasant, so
we just removed it in gtkmm 2.4. murrayc.
//In future, this GTK_DISABLE_DEPRECATED might be inappropriate because
it might cover extra GTK+ API. Just remove it then.

#define GTK_DISABLE_DEPRECATED

This has already been fixed in gtkmm 2.13.8, though.

> Damon Register
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list

Armin