On 06/24/2013 12:04 PM, Mario Sanchez Prada wrote: >> [...] >> 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.
So, taking into account that you are already working on this, I assume that you would prefer to add the generic boundary now, in order to avoid two updates of the implementation of those APIs. Right? >> 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. See my previous comment. BR -- Alejandro Piñeiro Iglesias _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
