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

[Matthias Clasen <matthias clasen gmail com>]

On Mon, Mar 19, 2012 at 12:40 AM, Martin Pitt <martin pitt ubuntu com> wrote:
> Hello Matthias, hello release team,
>
> I pinged on the bug twice, and the accerciser developer did as well,
> but that didn't work. So let's try mail.
>
> A while ago, the GI annotations for Gtk.Menu.poup_for_device() got
> broken by renaming it to Gtk.Menu.popup() [1]. As I explained on the
> bug [2] this is an API break and causes any application which
> currently calls popup_for_device() to crash because it suddenly ceased
> to exist. Also, it's conceptually wrong: these are two different
> functions, taking different arguments, so a simple rename is
> misleading and also breaks the documentation.
>
> GI programs can just use popup_for_device(), or GI bindings like
> pygobject or gjs are free to add adapters like [3] to emulate popup()
> in terms of popup_for_device().
>
> As hard code freeze will be EOD today, can we please revert this
> before it gets into the official release?
>
> The alternative would be to carry ugly workarounds in pygobject, gjs,
> and friends, like "try to call popup_for_device, if that does not
> exist, call popup with wrong arguments", and we would never be able to
> drop them any more because we don't really know which software
> currently uses that API.

The question of api stability for annotations has already been
discussed, without any clear resolution.

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. 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.

>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.