> b) About stop to using plugins: some people will not like adding a new > dependency to their projects (this could be irrelevant if the final > solution is add that call on ATK, as randomly suggested on the hackfest) I'm not sure I follow this idea of adding calls in atk. If atk-bridge stops being a gtk plugin that is dynamically loaded then either people need to link directly to some new library, libatk needs to link to that library, or atk needs to include that code in itself. sI tend to think the last of these options is the best since tighter integration between atk and the adaptor should allow a bunch of abstractions to go away. > d) We didn't debated how all this changes would affect GTK2 apps. > Because the fact is that there are apps still not ported. Well, can't distributions just continue to ship the current libatk-adaptor for them, and assuming we don't change the dbus protocol I think everything should just keep working. We also need to consider how this set up would work with non gtk apps, and apps that mostly aren't gtk but embed some gtk widgets. > * For this cycle just propose to change the default value of > accessibility-toolkit. In that case we would still have more runtime > testing, and it would be easy to go back if things are failing. If > things are not failing, it would be a good way to minimize a) if we > propose to remove the gsetting switch. I'd tend to think this is the right path to minimize risk in the case too much stuff doesn't work or performance suffers. Trev
Attachment:
signature.asc
Description: Digital signature