Re: [g-a-devel] Avoid Cally as a isolated module

[Piñeiro <apinheiro igalia com>]

From: Emmanuele Bassi <ebassi linux intel com>

> On Tue, 2010-03-30 at 19:05 +0200, Piñeiro wrote:
>> Right now, as GAIL, Cally is a module, that it is required to load
>> during run-time.
>> 
>> During the discussion of bug 614121 [1] Emmanuele Bassi ask how to
>> integrate what Cally does in Clutter core.
> 
> by "integration" I mean reducing the amount of code that it's actually
> deferred to a run-time loadable module. if we need to start using D-Bus
> to talk to at-spi2 *from within Clutter* I absolutely wouldn't mind.
> AFAIR, the whole separation in GTK+ was done to avoid depending on CORBA
> from within GTK+ itself. since we have a sane remote object system API
> that is already finding its way into GLib (GDBus) I wouldn't see the new
> dependency as a problem (I actually plan to use more DBus in Clutter
> itself for other features).

Well, right now, as I said on the bug, the specific CORBA/DBUS details
aren't implemented on GAIL. I'm not sure if in the past GAIK has any
dependency to Orbit.

They are being implemented on the atk-bridge, provided by the at-spi
package. Yes, as a loadable module, but it abstract the widget
toolkit. GTK uses atk-bridge, as well as Cally. And right now, being a
loadable module has the advantage that you can chose the CORBA or the
DBUS one just modifying the configuration.

So, I think that atk-bridge will being kept as a loadable module.

>> In summary, being able to expose a a11y object hierarchy different
>> from the toolkit object hierarchy if necessary.
> 
> those are pretty valid points for having a separate, A11Y-only hierarchy
> of objects. those are not blockers for having the actual code inside
> Clutter actors providing those objects.

Ok

>> So, other option is just move the code to Clutter core:
>> 
>> 1.) A new directory, as cogl.
>> 2.) Initialize a11y in the clutter_init, to registry the factories[3].
>> 3.) Add a equivalent to gtk_get_accessible in clutter, to allow
>> clutter-extending toolkits/apps to define easily the new accessible
>> factory/object
>> 4.) If this should be done always, and how, it is required to be
>> discussed.
> 
> 1 and 2 are trivial. as 3, I'd assume. 4 is a matter of policy.
> 
> again, thanks for discussing this. I really want to get a consistent
> story from the A11Y developers on how to make Clutter a better citizen
> in the accessibility world. also, remember that Clutter is a low-level
> toolkit, and that has *a lot* less baggage (and users, currently) than
> GTK+; you could consider this starting with a lot cleaner a slate, and
> an opportunity to get things right from the start. :-)

So, I suppose that right now, the only blocker to integrate Cally
inside Clutter is the dependency with GailTextUtil (so a indirect
dependency to Gdk), and the usage of this gdk method to translate the
key event value. Right?

I can start to create a clutter version with cally integrated, to
check if it is required something else (as usual implementing
something shows some details you didn't take into account in the
past).

Thanks for your interest.

===
API (apinheiro igalia com)