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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list