On Tue, Aug 06, 2013 at 04:22:40PM +0200, Mario wrote: > Hi Trevor, > > On 6 August 2013 16:05, Trevor Saunders <trev.saund...@gmail.com> wrote: > >> 6. In atspi2-atk bridge, check which version of ATK a specific > >> application is implementing (using atk_get_version()) when > >> implementing this new atk_text_get_text_for_offset(), so we know > >> whether we can call atk_text_get_text_for_offset() or we need to use > >> the old atk_text_get_text_at_offset() and a *_START boundary instead > >> (for implementors of older versions of ATK). > > > > afaik atk_get_version() only tells you what version of libatk-1.0.so you > > are talking to not what version of the atk headers an application was > > compiled against. So I believe that would cause breakage when people > > compile applications against atk pre this change and then run that > > application with a newer libatk-1.0.so. > > > Yes you are right. We already realized a while ago this part was wrong > and were already thinking that a better approach would be to use > ATK_CHECK_VERSION() to know whether we need to use the old API or if > we can use the new one (and maybe with a fallback to the old API in > case the app that is running has not been updated yet to it and it's > still implementing the old functions).
Well, what's important is the version of atk that the application was compiled against not what version of atk you're compiling atk-bridge against. So about the only way I can think of to know what version of atk a an application was compiled with given only its binary is to see if it defines a symbol and then arrange to have atk define this symbol at the same time you add this new virtual function. However having your headers inject symbols feels somewhat rude. I *believe* the symbol approach will work, but changing vtables and not changing abi feels dangerous to me and I would try to avoid it unless I had no other reasonable option. Trev > > Thanks for the feedback in any case, > Mario _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
