Contents
1. ATK1 or ATK2?
1.1. No API Change Required
- Should the information about relevant -visible and/or invisible- objects be exposed?
Conclusion: We need significantly improved documentation about STATE_SHOWING and STATE_VISIBLE.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=648260#c1
Person Responsible:
551489: API doc for atk_text_get_text_before/at/after_offset() are not consistent
Person Responsible: Li Yuan
Document AtkHypertext / AtkHyperlink AtkHyperlinkImpl (see bug 650118)
Person Responsible: MarioSanchez
Document AtkSocket / AtkPlug (see also bug 649307)
Person Responsible: MarioSanchez
1.2. API Addition
639486: Table cells should know their index, coordinates, and spans (and possibly the parent table)
Conclusion: https://live.gnome.org/Hackfests/ATK2011/Agenda/table
Person Responsible: Li Yuan (for GAIL)
638924: Improve window-related events management (AtkWindow?)
Conclusion: We will implement AtkWindow
Person Responsible: AlejandroPiñeiro
638378: API change requested: text-selection-added, text-selection-removed, text-selection-updated
Conclusion: We will create AtkTextSelection (https://bugzilla.gnome.org/show_bug.cgi?id=649902) and use property-changed event
Person Responsible:
639466: API change requested: ":system" suffix
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=639466#c1
Person Responsible: Li Yuan (for GAIL)
644508: Debate if a new signal "order-changed" could be useful
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=644508#c3
Person Responsible: Li Yuan
644393: [atk 2]: Consider adding a document:content-changed signal
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=644393#c1
Person Responsible:
649771: Consider adding attributes-changed and relation-changed events
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=649771#c2
Person Responsible: Li Yuan
648259: API change requested: Provide a means to specify a "purpose" hint
Conclusion:: (from workgroup) https://bugzilla.gnome.org/show_bug.cgi?id=648259#c1
Person Responsible:
Question: Are there roles we lack in ATK? (Current Roles)
Conclusion: (from workgroup) https://live.gnome.org/Hackfests/ATK2011/Agenda/Roles
Person Responsible:
649123: Create desktop-agnostic way to identify active/running ATs?
Conclusion: https://live.gnome.org/Hackfests/ATK2011/Agenda/client-registry
Person Responsible:
647351: consider allowing retrieval of only one relation for an object
Conclusion: We will implement the ability to get the relationship by type. Note that this also happens to be included in Mozilla's proposal for IA2.
Person Responsible: Li Yuan
648675: Examine IA2 for items which would improve the user experience if added to ATK
Conclusion: We will implement the items listed in the bug.
Person Responsible:
598952: Implement object attribute to expose toolkit/source
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=598952#c6
Person Responsible:
649805: Would be good to provide a way to invalide the cache
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=649805#c3
Person Responsible: Mike
345750: Add AtkCollection interface for custom implementors and large containers
Person Responsible:
326538: Add AtkTerminal
Person Responsible:
407539: ATK missing ATK_STATE_HAS_TOOL_TIP which at-spi has
Person Responsible:
1.3. API Break
639479: Improve current AtkTable hierarchy, then document best practice
Conclusion: https://live.gnome.org/Hackfests/ATK2011/Agenda/table
Person Responsible:
649577: atk_add_global_event_listener should only accept ATK events
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=649577#c2
Note: Although it is true that it is an API change, it is more about the behaviour as the signature. Probably we can get it before atk2
Person Responsible: AlejandroPiñeiro
649575: Need to clarify focus management status
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=649575#c1 and https://bugzilla.gnome.org/show_bug.cgi?id=649575#c2
Person Responsible:
Clean up the AtkHypertext / AtkHyperlink / AtkHyperlinkImpl stuff (so AtkHyperlink could become an interface, some background 344284, bmo#343150) (see bug 650122)
Conclusion: To go ahead and propose get rid of the AtkHyperlinkImpl implementor interface and makes AtkHyperlink just an interface (instead of a GObject) that would be implemented by subclasses of AtkObject as needed (those instances returned as 'hyperlinks' by AtkObjects implementing the AtkHypertext interface)
Person Responsible: MarioSanchez
363439: Use CSS/XSLT names for text attribute mappings from enums
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=363439#c3
Person Responsible:
642597: Study if it would be good to became AtkObject an interface
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=642597#c2
Person Responsible:
647482: There are some overlapped methods on the ATK namespace
Person Responsible:
551680: in 2.0 fix AtkObjectFactory breakage ...
Person Responsible: Li Yuan
647488: Required to move to a private structure most of the Atk interfaces data
Person Responsible:
648616: ABI maintenance tasks
Person Responsible:
640625: ATK API changes are required to became fully introspectable
Person Responsible:
1.4. To Be Determined
640440: Fine-tuning event listeners
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=640440#c3
Person Responsible:
644747: Debate if AtkObject "property-change" signal should be deprecated and use the current GObject "notify"
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=644747#c3
Person Responsible:
640949: Review the event API and data sent with events
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=640949#c1
Person Responsible:
611507: AtkUtil problems with loading multiple Atk implementations.
Related: Come up with the proper way to expose object toolkit name and object toolkit version for ATK2
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=611507#c3 <-- write me!
Person Responsible: AlejandroPiñeiro
647486 : Analyze accessible instantiation: factories, AtkGObjectAccessible, base object - accessible relation
Conclusion: https://bugzilla.gnome.org/show_bug.cgi?id=647486#c1 <-- write me!
Person Responsible:
Simplifying the way key events are handled and passed from applications to ATs and 649559: AtkKeyEventStruct has several issues to solve
Conclusion: <-- write me!
Person Responsible:
- Standard accessible hierarchies for widgets (menus, combo boxes, trees, ...)
Current work: https://live.gnome.org/Hackfests/ATK2011/Agenda/widgets-best-practices
Person Responsible:
1.5. Postponed/No Additional Action Required
639470: API change requested: Provide a means to "group" events based on trigger
649804: AtkAction would be better with add/remove methods
649556: Need to start to check how eventual Wayland move would affect ATK/AT-SPI2
647357: consider making atkrelationtype a simple C enum
647352: cleanup the atkrelationset interface
648131: Should we (fully) implement or eliminate the desktop abstraction?
2. Performance
- Mission: allow to have the a11y toolkit enabled by default without performance loss
- Fits here or on an gtk hackfest
- From here: ThreePointOne/Features/Accessibility
- "To make headway on a good accessibility story, we need to get to the point where we can turn on toolkit accessibility by default without adverse performance effects. "
One already discussed proposal: https://mail.gnome.org/archives/gnome-accessibility-devel/2011-February/msg00037.html
Related to bug 649123
3. Releasing
- How many thing breaks ATK/AT-SPI2 API?
- Release plan for ATK2?
- As it is a ATK break, it would be required to update implementors ("GAIL2", "Cally2") etc.
- Release plan for GAIL2, Cally2
For gtk3 or gtk4? => we don't know gtk4 dates
For clutter or clutter2? => we don't know clutter2 dates
- Other modules
- Maintain support for both simultaneously?
- Issues related with update at-spi2 API and how know if implementors implements that
- Consider add a AT-SPI2 method to expose the version
- Who will do each thing?
Conclusions
- It is too early to make a final schedule for ATK2
- We have created a target milestone on bugzilla to classify bugs breaking API
- About the modules affected:
- For the case of gtk and clutter it seems that the best idea is targetting gtk4 and clutter2
- In the case of firefox it is not as important
- WebkitGTK probably would do something similar
- Frederik already created a bug to track the "AT-SPI2 exposing the version thing"
- As we said, too early for a final conclusion, mostly because we would start with the non-breaking API tasks