On 04/29/2012 07:14 AM, Trevor Saunders wrote: >> 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. "atk needs to include that code in itself" is a better phrasing of my poorly written "add that call on ATK". Anyway, you listed some of the options we were talking about on the hackfest:
* link to a new library (old atk-adaptor plugin becames this new library) * atk include that code in itself. * <write here your alternative> And as I said, deciding and implementing the best one is still pending. > 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. This was the idea, and one of the reasons Benjamin Otter (IRC:Company) was interested in this approach. That would also allow to have more control over it. With a plugin you just load it, and start to work. A library approach could allow to add some extra methods. > >> 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. The issue here is "I think". We need to be sure that we don't break things. >> * 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. > Finally, this was what I proposed on desktop-devel-list: https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00107.html BR -- Alejandro Piñeiro Iglesias _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
