> On 06/24/2013 02:26 PM, Mario Sanchez Prada wrote: > >> [...] > >> 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?
Yes, that would be my preference. However, I just realized that the ATK version bumped in WebKit has been recently raised to 2.8.0 and so I don't think raising it again to 2.10 is something likely to happen in the short term, so I'm afraid we'll have to coexist with the old API for a while anyway (meaning that I will need to provide implementation for those methods anyway in the patches I'm currently working on). > > It's not that I prefer to do that now in order to avoid two updates > of > > the implementation of those APIs, but just because I think it's > > clearer and less confusing from the POV of the new API. > > Ok, that is not a valid reason for you, but in any case you didn't > answer my question. So I will not add the reasons to the question, do > you (as one of the atk implementors) prefer to add the generic boundary > now (so probably for next ATK release) or not? Yes. Still, as I mention above, we will probably not be able to change WebKitGTK+ yet to match the new API because raising ATK dependency up to 2.10 will probably not be a good idea right now. > > Furthermore, I also think it should not be a big deal to have those > > new boundaries co-exist with the old ones as long as it's clearly > > stated in the documentation what is deprecated and what is not. Or > you > > can use some kind of aliases like what Trevor is suggesting. > > Well, it is just less clear, IMHO, having two enums that means the > same. I understand your point, but I see it as a temporary evil while we move to the new API, and not nothing too severe, since we would not be breaking backward compatibility or the like, just preparing for the future. > Anyway I agree with Trevor suggestion (will answer him in short). Me too. Mario _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
