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



thanks for keeping me in the loop.

[please, if anyone replies to API, keep me Cc'ed in since I'm not
subscribed to the list - though I probably ought to]

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

> On Boston Summit, AFAIU, he thought that it could be a good idea to
> drop the accessibility object, and implement the accessibility
> interfaces directly on the clutter objects. I pointed two reasons on
> the bugzilla to avoid that:
> 
> 1.) Allow to define accesibility objects not related directly with a
> Clutter object (ie: flyweights objects [1])
> 2.) Allow to not expose some objects if it is not interesting from the
> a11y POV.
> 
> 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.

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

ciao,
 Emmanuele.

-- 
Emmanuele Bassi, Open Source Software Engineer
Intel Open Source Technology Center



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