Re: [g-a-devel] About proposing "accessibility on by default" as feature

[Piñeiro <apinheiro igalia com>]

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