Note: An audio archive of this call in OGG format is available.
JS: the main focus of today's meeting is to discuss Robert Taylor's Overview of DBus ATSPI Design
RT: D-Bus is the way we think the right way forward; strict seperation btw API design and IPC design; a lot of efficiency; should go ahead and have on D-Bus, designed to be efficient, API should be lightweight
WW: 2 questions: 1) impact on existing pyapi bindings for AT-SPI?
RT: behavioral differences
WW: such as things turning into asynchronous calls
WW: 2) keyboard events want to be able to intercept; asynchronous calls wouldn't allow -- what would intercept events and prevent from getting to application
RT: AT making the call?
WW: registry daemon sends out to AT for analysis and AT returns yes/no to "can you handle" -- should be using xvg extention, but not very well supported right now
RT: no reason why alternate input devices can't be accomodated -- linked to change events; 2 options: 1) asynchronous then call back; or 2) AT provide small bit of service to process info through AT
WW: can be seperate paths?
JS: Olaf and Gunnar -- did you have chance to listen to the audio from 18 december 2007 call?
OS: no -- need to catch up on email, too
JS: eager to hear OS and GS' responses / feedback
OS: main question is WW's question: manage to use PyAPI as much as possible; had discussion in past changing things in AT-SPI - work differently on D-Bus? been told by PyAPI users that it is very important so can continue using existing applications; makes sense to serious look at getting better performance; BH used to stress that would be more maintainable if used same protocol/API over the wire for communicatinos -- can be auto-generated, but think tech moving away from that; not fully automatible or
RT: everyone wraps around generated content already
OS: exactly; for me it makes sense to extract data that way -- sometimes things done differently on Labyrinth, etc., but not AT-SPI expert
WW: would like to hear the KDE side of the story
OS: interested in seeing solution supported by as many parties as possible; need GNOME on board; only use accessibility bridge with Qt; goal: get TrollTech, mozilla, and everyone else to agree on standard so KDE acts identically -- important to have unified solution
JS: summarizing from last call, general agreement is that move to D-Bus on GNOME is practicable and achievable in a time frame; RT provided a roadmap; also discussed that all stakeholders with interest are pariticipating in process; need to go back to Trolltech to get participation so that what we create for D-Bus over AT-SPI can be consumed by GTK, interoperable ATs, etc.
RT: thinking point on plan: some logic in dealing with IPC -- would Trolltech use that library or do they want to write themselves? D-Bus different from actual API exposed through PyAPI -- would Trolltech use pyAPI -- would they like a library that implements the API?
OS: short-term and medium-term, user application side which is more important from KDE point-of-view; needs to be simple to implement D-Bus messages in Qt library to write user applicatinos and key servers; then on KDE side, might be some very simple ATs that might be interested in using AT-SPI over D-Bus; as long as possible to get information from D-Bus, that satisfies main programming need
MM: proper caching needed; fast iterators -- requires at least some client code that should be shared; hide protocol, though
RT: written in code -- a difficult fit; did some interesting tests today -- how much info transported via AT-SPI -- every bit of data/AT-interface -- came to 5MB; might be sensible to have 2 trees in a file which would signal changes, very low overhead
JS: would a large OpenOffice document have more interaction?
RT: no -- what is currently on the screen
GJR: on windows there is also what is available via the java accessbridge
RT: not going to work with really large documents
JS: collection mechanisms to move to other parts without waiting for propogation
RT: collection doing another IPC round-trip -- perhaps can communicate data to AT at startup and then communicate changes to it; only call for round-trip when change
JS: trade-off -- someone parsing DAISY document with well marked up structure; can take 25 to 30 seconds to get open, but once opened fast and efficient
RT: can work around overhead problem by only presenting what is on page/screen can be parsed
JS: while processes running in background
WW: Orca wants to get things off screen -- does this proposal allow this?
MD: yes, but changes how works: audio output can only read one piece at a time, tactile display relatively small (smaller than viewable area on text-only screen) -- reasonable to limit to expose to AT what is visible to sighted person; new things become visable as flowed or moved to
MM: document navigation interface -- telling insides "i need x amount of data" - page down, navigate by title, etc.
WW: page summary on web -- how many links, all links, forms, etc. -- would this prevent that?
MD: problem is word "visible" -- reachable? accessible from what is displayed on screen
RT: huge web page may have thousands of links -- do you want to wait until entire page is loaded (entire tree walked) -- can have an interface that allows page summary, rather than exposition of document
WW: what Collection API supposed to do
RT: design decisions that go into collection base don't necessarily drive document/user interface
??: can still ask for infinite collection -- lifecycle of what is handed to AT can cause problems
RT: ajax trick - close down stream -- push more XML -- use same solution -- display what have to display and continue processing in background
??: how does reading an .odf document work using Orca? get scroll bar to move down?
WW: open a document, each paragraph its own object -- get me current paragraph, get me current caret position in paragraph and will read line or surrounding text; moves around document one chunk at a time; if whole thing not visible and do a "say all" operation, need what is not displayed
WW: not a PageDown operation, but one that keeps available to sighted person; when speech stopped, scroll display to where speech stopped; for screen mag, want to highlight chunks as go
??: expose things in bounds of document being accessed
RT: if do want to highlight text currently being spoken (low vision/dyslexic)
JS: very big deal
WW: problably use an extention for that
RT: wow -- a lot of hard work!
MM: not too bad
WW: whole seperate collection -- if MM wants to help, he's more than welcome
RT: can't go about in infinite space if only expose what is visible -- how many links, or whatever contextual info user wants
WW: is this problem any different than ATK? doesn't act differently with different transport mechanism
RT: how remove integer settings in processing -- document reading interface -- this is being exposed at this time
SB: lifecycle issue, then
??: caching useful -- tree navigation needs no round-trip
??: if have document one is reading, could make sense to trransfer entire contents of document to AT and then signal change; problem is current implementation -- expose part of document using an ATK widget
GJR: adobe access module model for acrobat reader very similar
RT: is there a better word than visible?
MM: hidden menus are fine, documents are the real problem
PB: manage descendent there to support this -- when handle on transient state object, not expected to be around forever; everything becomes potentially transient
RT: get notification when document changes
MM: AT has weak references to object in process
PB: access object and hold onto it; can reuse "visible" state from IA2
SB: application chooses to hold onto something, can for as long as it wants; everything should be treated as transient
RT: everything treated as transient -- for the chrome, nothing changes (visible and showing states) -- still have one layer (hidden menus, context/popup menus) -- multilayer, what is within screen, point-of-regard would be shown in a11y tree
PB: performance optimization
JS: outline mode (for example, headers not contents)
MM: provide enough to renderer to enable AT to decide how to process
PB: use cases handled through traditional APIs?
PB: XML API where can do queries
RT: hopefully finding headings and structure of document important for everyone; needs to be extractable for everyone
PB: Jon Gunderson's UIUC accessibility extention for FireFox a model; "SayAll" operation processed in realtime, ensure that point-of-regard (POR) maintained
MM: could do by caret tracking
SB: onscreen keyboard -- GOK has a means of generating list of links (finite)
RT: document interface: here is document, can ask sensible questions of it (small number of links, headers, etc.)
JS: collection API discussions very reminiscent of this discussion
SB: accessible document?
JS: there is an IBM initiative like that, i believe -- quick back-and-forth through D-Bus
PB: indirectly involved -- will fiind out what happened to that and report on list
JS: please do so can discuss in Open A11y workgroup conference call
WW: question for OS and GS -- need for community to work together, but didn't hear commitment to work on AT-SPI over D-Bus -- is that something KDE would be willing to do?
OS: for KDE use Qt code -- Trolltech people need to be included in conversation, so when use Qt library know that Qt will work with everything developed but don't have to write our own support -- fully support this iniatiative, and personally very pleased that it is going on; Trolltech need to implement in library
JS: Harald Fernangle no longer in this area -- has anyone taken ownership?
OS: will contact Knute again -- exciting stuff close to what they are doing -- what is missing is collaborative effort
JS: need to know that what we do accomplishes what they need
SB: contacts at Trolltech -- will dialog with them
JS: we should go as high up the management chain in Trolltech as possible, so can ensure that things are synchronized -- we have a unique opportunity to make this happen now
RT: everyone in agreement with overview? should we push forward?
RESOLVED: Robert Taylor's overview/roadmap for AT-SPI on D-Bus will be basis upon which work will move forward.
SB: next question is "how do we fund it" and "who do we want involved"
RT: well, you have the 2 worker bees at CodeThink, but of course, we would welcome anyone else's participation
SB: begs question if AT-SPI cross platform, should we remove it from GNOME
RT: may be political issues at freedesktop.org
SB: more mature spec needs to be taken out of GNOME space and moved to freedesktop.org
RT: good idea in terms of writing specificiation on how IPC should act
SB: need consensus that this is right thing to do, and then tackle funding
RT: initial investigation funded by Mozilla Foundation; can apply again
WW: all positive -- OS, GS, RT, Mark and everyone thank you
JS: walkaway from today other than contacting contacts at Trolltech to let them know what is occuring here and need to take opportunity to synchronize
JS: accessible document format people's use cases -- don't want to loose what worked so hard on in CORBA
RT: create small window, set alpha channel to background (zero) if draw to it, selection indicated;
PB: one alpha channel then?
JS: what about multiple on-screen panels?
RT: may be unforseen problems
JS: a lot of power in documents for that -- those with dyslexic/LD
JS: thank you all for attending today -- another great meeting; next week can try to have collections conversation; need to continue to invite people to conversation so as to broaden consensus as much as possible
RT: want to hear from Aaron Leventhal
JS: unfortunately aaron wasn't able to attend this afternoon's meeting, but he will be expressly asked to attend the 15 January 2008 meeting