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

[Piñeiro <apinheiro igalia com>]

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