Re: [GTK+ hard code freeze] Revert gtk_menu_popup API break

[Martin Pitt <martin pitt ubuntu com>]

Hello Matthias,

Matthias Clasen [2012-03-19  1:06 -0400]:
> In the case of gtk_menu_popup, there was a complaint from bindings
> authors that it takes user data without a destroy notify.
> gtk_menu_popup_for_device fixes that oversight.

Right, no question there. This was already done in GTK 3.2, so there
are now programs which use popup_for_device() from e. g. Python.

> I have no strong opinion on whether the (skip) and Rename-to
> annotations are the best way of going about this, but I am pretty
> sure that reverting them at this point will cause breakage in other
> places.

That's why it should have been reverted right away. But if we compare
the API break against 3.2 (which has been out for almost 6 months)
against a temporary API break within the 3.3.x series (which only
started 1.5 months ago, and did not even affect distros like
Debian/Ubuntu as we reverted it right away), I'd certainly prefer the
latter.

> From my perspective, there is no way to avoid continued api breakage
> for bindings unless we declare the current annotations final,
> including all their warts and brokenness. If that is the collective
> wish of the bindings authors, we have to stop accepting patches that
> correct annotations for existing API.

Fixing annotations to have the correct transfer mode, or the correct
array element type, etc. won't break existing applications, and should
still be done of course.

But this patch was not a fix, it renamed an existing and perfectly
working function to a different name which different arguments. So
popup_for_device() which is documented to be bindable now isn't, and
popup() which is tagged to be not bindable now silently exists, but
the documentation does not match because it takes different arguments.
So why is this considered a "correction"?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)