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

[Li Yuan <Li Yuan Sun COM>]

Yes, it is OK for me.

Li

On 04/ 6/10 07:13 PM, Piñeiro wrote:
> From: Li Yuan<Li Yuan Sun COM>
>
>    
> > 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.
> >      
> Ok, thanks for the suggestion, I have already thought that, mainly
> after my experience with gtk/hildon-calendar, where mainly all the
> cell data position is private.
>
> Anyway, as with GAIL, some Cally classes include some virtual methods
> and so on, so I would like to at least have the basic structure in
> Cally, as a different librry, so any clutter-based-toolkit would
> extend that, and in the same way don't require to modify clutter
> headers in order to include the cally classes definition.
>
> But, of course, it would be good to just implement the a11y support
> directly in clutter objects if possible (and this is other reason why
> gtk_widget_get_accessible equivalent is required).
>
> Anyway, with this answer I suppose that you didn't find any other
> technical reason to avoid to use Cally in this way. Right?
>
>    
> > 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
> > >
> > >        
> >