Re: GTK and ATK

[David Zeuthen <zeuthen gmail com>]

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.)

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

 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.

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.

Of course shared memory won't work over the network but I think it's
about time to make a stand and just say such applications won't be
accessible - the same way Wayland is already saying "use some
higher-level stuff such as VNC".

> 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.

Hope this helps, Thanks,
David