> [...] > Right now I prefer a). The main problem with b) is that we would have > three pairs of macros that would mean exactly the same.
I'm sorry to disagree here, but I think b) would be better, all things considered, and as long as it's clearly stated that all those _START boundaries are deprecated as well. That way it will be perfectly explicit which things are deprecated and which ones are not, and would IMHO define a clearer path for apps to migrate to the newer API. > Of course, the > main problem of a) is that we don't have right now a specific schedule > for the API break so that means that we don't yet when the generic > boundary would be added (FWIW, this is another candidate for our list > of ATK3 bugs). Yes, and that would generate IMHO more confusion for implementors that will need to figure out why we have the _START boundary if that's the only one after deprecating the _END ones. Thanks, Mario _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
