Re: GTK and ATK

On 05/11/2011 02:13 PM, David Zeuthen wrote:

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]