Re: GTK and ATK

[Piñeiro <apinheiro igalia com>]

On 05/11/2011 02:13 PM, David Zeuthen wrote:
> Hey,
>
> On Wed, May 11, 2011 at 4:14 AM, Piñeiro<apinheiro igalia com>  wrote:
> > So if in the future we change D-Bus for "MyAwesomeIPC" that would be totally
> > broken. On the current state, gail code, cally code and in general any ATK
> > implementation didn't require to be modified at all due those abstraction
> > layers. Those works on both at-spi and at-spi2.
> (Some of this might come across as either hand-wavy or rude or both -
> please just take it for what it is: commentary from the side-line.)

np

> One problem with abstraction layers is that they're just that -
> abstract. Meaning that you often paint yourself into a corner where
> you cannot optimize anything and everything is dogslow, memory usage
> is ballooning and there's no obvious way to fix things. This is often
> the same time people apply band-aids (such as: a dedicated a11y
> message bus router; or: turning the a11y feature off by default) to
> stop the bleeding ... instead of taking a couple of steps back and
> looking more holistically at the problem. For something like
> accessibility, I'd use a hybrid model
Well, it is true that having abstraction layers has their cons and their 
pros, but anyway not sure how the current approach and ATK API is not an 
holistically approach of the problem.

>   1. Shared memory for read-only access to the widget trees in each process
>   2. D-Bus (session bus) for registration, discovery and write
> operations. Probably a central daemon.

Well at-spi2 is right now a central daemon that does all those things 
and uses D-BUS (although with an a11y bus) ... so the only different 
thing to the current implementation is 1.

Although still not sure how that proposal would work here.

> This is similar to how GVfs is using e.g. file-descriptors for bulk
> transfers and D-Bus to orchestrate the hordes of daemons and other
> things. To make things really easy, you can use something like
> GVariant in the readonly part. And you can use the new ObjectManager
> support in GDBus to easily (and very efficiently) synchronize all the
> objects in each client. And you can probably add a lot of client-side
> convenience to make most of this more or less transparent.

Again the problem is that you would have objects of a different nature 
to read/interact to. In any moment someone would require to provide a 
homogeneous API.

At this moment that homogeneous API is ATK, so at the application level. 
Not sure where do you want to do that.

Second, AFAIU your proposal, it is mostly and "read and write" approach, 
while the current approach is more ATs being reactive to the changes on 
the application, so it is also event emission (and the reason we used 
one full day to the event situation on ATK/AT-SPI at the hackfest).

> > D-Bus is just an IPC technology, I wouldn't add a direct D-Bus dependency on
> > Gtk+.
> For the record, GTK+ already has a D-Bus dependency on Linux and other
> platforms where you don't have a native a11y system (e.g. OS X and
> Win32). Additionally, every GTK+ app on these platforms you should
> worry about, will most likely have a message bus connection _anyway_
> thanks to e.g. GtkApplication or other GTK+ features using D-Bus on
> Unix that we will surely add in the future.

Good to know. Thanks.

BR

--
API