Hi Michael, so far I only took a quick look at your patch. Please see my comments below ..
michael meeks wrote: > Still in a very hacked, but semi-functional state; the gaps between the > mapping are quite interesting too; Oliver - is it possible to extend the > OO.o a11y in certain places ? eg. non-localised vs. localised names for > accessible actions ? Hmm, don't think so. The UNO API has been defined as with non localized strings, because at-tools are expected to bring their own (maybe mode dependent) localization for it. If atk defines them as localized strings, we probably need a mapping in the at-bridge somehow. Maybe we can re-use some GAIL stuff here .. > Anyhow - I'd really value your feedback, I've also fallen over a rather > silly problem in the OAccessibleWrapper, a crash (with a custom zoom > combo box we added to the toolbar): I don't know OAccessibleWrapper unfortunately, but I'll try to take a look on this later. However I have some other feedback and a question for you: a) It seems that global focus notification is not working at all - unfortunately it is not implemented in OOo yet, so the java bridge traverses the full a11v hierarchy of a newly opened frame to add a global listener to each object (unless it is below and object having MANAGES_DESCENDANT state), listening for FOCUS and CHILD events. I believe we have to do similar things in the at-bridge because I doubt we get this implemented in the application code in the near future. This may also solve some of the reference counting problems (what is this ->acquire loop good for ?). b) here is the question: since I am not familiar with the glib object system, I originally thought it would take one object per a11y role. It seems you have solved this problem more dynamically - I am just unable to find where ;-). Regards, Oliver _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
