Re: Additions to GInterfaces

[Federico Mena Quintero <federico ximian com>]

On Thu, 2005-12-01 at 09:55 -0600, Mike Kestner wrote:
> When auditing the new API in 2.8 for Gtk#, I noticed that a property and
> signal were added to the FileChooser interface.  Adding anything to an
> interface is a non-compatible change, because any class implementing the
> interface must be updated to add the new API members.  Whether a C
> compiler would complain or not, conceptually it's a breaking change and
> will most likely cause trouble for any language binding that supports
> interfaces.
> 
> Since we haven't added GInterface registration to Gtk# yet, I'm going to
> just let this break occur in Gtk# as well.  It's only non-compatible for
> implementors, not consumers.  We do plan to support GInterface
> registration in an upcoming release though, so I would like to request
> that interface stability be guaranteed in future releases.

Was that GtkFileChooserIface::confirm_overwrite, by any chance?

Note that GtkFileChooserIface is *not* public.

We *may* have added vmethods to a few public interfaces here and there
(or not?  am I only partially irresponsible as this is a private
interface?).  My understanding was that old apps linking to a new gtk+
would leave the new member untouched, and gtk+ would see that the member
was NULL in the implementation.  Then it can do fallbacks as appropriate
- that's what GtkFileChooser does internally for the semi-private
GtkFileSystemIface.

Or probably you problem is more complex.  I'd love to help :)

  Federico