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

[Li Yuan <Li Yuan Sun COM>]

Hi,

Just one suggestion. Ideally we should implement the accessibility 
object in the file where its GUI object lies (like GtkIconView). This 
means you can use the internal functions/variables  of that GUI object. 
Sometimes this is very useful.

Li

On 04/ 1/10 01:57 AM, Piñeiro wrote:
> 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)
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>