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 _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
