Re: [g-a-devel] Avoid Cally as a isolated module
- From: Emmanuele Bassi <ebassi linux intel com>
- To: Piñeiro <apinheiro igalia com>
- Cc: gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel] Avoid Cally as a isolated module
- Date: Wed, 31 Mar 2010 13:38:53 -0000
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]