(15:05:09) API: well, we gave 5 gentle minutes
(15:05:16) API: I think that we can start the meeting
(15:05:21) ***clown waves
(15:05:25) API: agenda here:
(15:05:27) API: http://live.gnome.org/Accessibility/Meetings
(15:05:30) ***slee thumbs up
(15:05:44) API: first item
(15:05:47) API: 641869
(15:05:57) API: https://bugzilla.gnome.org/show_bug.cgi?id=641869
(15:06:06) ***clown reads
(15:06:09) API: mgorse, I guess that this is your point
(15:06:41) ***slee still waiting for bug to load
(15:07:30) mgorse: ok
(15:07:52) mgorse: So in at-spi2 we've had an --enable-relocate option, to allow AT-SPI and AT-SPI2 to co-exist
(15:08:09) mgorse: and the version of at-spi could be switched with a gconf option
(15:08:35) mgorse: and pyatspi would load the alternate version of pyatspi of the relocated version was in effect, and GTK_PATH would be set
(15:08:54) fregl [~gladhorn@eckhart-woerner.de] entered the room.
(15:09:05) mgorse: Apparently setting GTK_PATH was causing problems. It may have been some transitional issue with upgrading a package in Fedora. I'm not sure.
(15:09:34) mgorse: Either way, it was intended to be there temporarily to help people test AT-SPI2, so I propose to remove it if no one objects
(15:09:52) joanie: +1
(15:09:56) mgorse: It would allow some gconf-related code to be removed, and I think it would generally make things less confusing
(15:09:57) fer: +1
(15:10:09) mgorse: I've talked with TheMuso and sshaw, and they seem okay with it
(15:10:11) API: mgorse, that would be remove the relocate stuff from both, right?
(15:10:17) API: I mean, from at-spi and at-spi2 too
(15:10:27) fer: yeah, and I guess that most people did for testing: at-spi1 on /usr from their distro, and at-spi2 on /opt from sources
(15:10:45) mgorse: API: That was my next question really. Do people think it is important to preserve the --enable-relocate behavior in AT-SPI?
(15:10:56) API: hmm
(15:11:00) API: well, as you said
(15:11:06) API: most of the people
(15:11:07) mgorse: AT-SPI-CORBA I mean
(15:11:09) API: AFAIK
(15:11:14) API: were not using the relocate thing
(15:11:22) API: (not sure if this is a pity or not)
(15:11:35) API: IMHO, it would be better to remove it from both
(15:11:45) API: and as you said, make things simpler
(15:12:43) mgorse: okay. I'll plan on just removing from both then, since no one is objecting / feeling like it's important to keep it around
(15:12:49) slee: +1 having old options around is only confusing - especially for newcomers
(15:13:27) fer: I know that F14 installed both at-spi and at-spi2, but I don't really know why
(15:13:31) mgorse: so the packages will just conflict with each other
(15:13:39) API: fer, really ?
(15:13:48) fer: yeah, pretty weird
(15:13:53) API: but I guess that one compiled with relocate, right?
(15:13:55) ***joanie chuckles
(15:13:58) fer: yes
(15:14:00) mgorse: unless we made --enable-relocate always-on with AT-SPI (which would mean preserving some code in AT-SPI2 to ensure that it's disabled when necessary)
(15:14:02) API: although thiis is a good point
(15:14:14) fer: there was something depending on at-spi2 package, let me check it
(15:14:14) API: removing relocate would make installing both incompatible
(15:14:35) fer: but I don't know the rationale for having at-spi2 on GNOME2 on F14 :)
(15:14:38) fer: mclassen should know
(15:15:35) fer: oh, at-spi2-core in F14 is a dependency for orca and pyatspi :)
(15:15:58) fer: maybe it was because they picked up a recent version of pyatspi doing the gconf relocation check?
(15:17:33) fer: ok
(15:17:58) fer: <mclasen> because we were aiming to have gnome3 in f14
(15:17:58) fer: <mclasen> and then gnome3 got delayed and we had to quickly shift gears
(15:17:58) fer: <fer> so just a preview, ok
(15:17:58) fer: * _ke se ha marchado (umount /mnt/me)
(15:17:58) fer: <mclasen> and leave behind a few useless packages...
(15:17:58) fer: <fer> is it safe for F15 to remove relocation and at-spi1, right?
(15:18:01) fer: <mclasen> yes, should be
(15:18:30) mgorse: ok
(15:19:50) API: well, so concluding ...
(15:20:04) mgorse: so I'll plan on just removing it. Seems not worth keeping around if most people weren't using it anyhow
(15:20:23) API: well, and in some place it would be required to say that both are incompatible
(15:20:31) API: both at the same time I mean
(15:20:42) API: unless you still plan to maintain relocate stuff on at-spi2
(15:20:43) API: sorry
(15:20:46) API: at-spi1
(15:21:21) fer: we can just add it to the NEWS file
(15:22:01) bnitz: fer:Just a context question here, F14, F15? Are you referring to builds?
(15:22:14) fer: like "at-spi2-*" is incompatible with at-spi, so packagers can notice it and mark their at-spi2 packages with Obsoletes: at-spi
(15:22:24) fer: Fedora 14, Fedora 15
(15:22:26) fer: releases
(15:22:28) clown: bnitz, I think they are release versions of Fedora
(15:22:35) bnitz: That would have been my second guess, thanks!
(15:22:42) mgorse: 15 is the up-coming release
(15:23:32) API: well, anything else in this point?
(15:26:34) API: I guess that the silence means "no" ;)
(15:26:41) API: lets move to the next point
(15:26:43) bnitz: Listinging to John Cage 4'33.
(15:26:48) ***API looking
(15:26:59) API: FOSDEM summary (What was cool? What did those not in attendance miss?) 
(15:27:08) API: well, I was on FOSDEM
(15:27:17) slee: bnitz: that's a bit to repetitive for me
(15:27:20) API: fer planned to go, but I guess that he didn't go
(15:27:38) fer: yup, had to do some stuff here in madrid :(
(15:27:41) ***slee is keen to hear about FOSDEM
(15:27:46) ***joanie too
(15:27:59) API: well, I guess that it is my point
(15:28:00) bnitz: did anyone go?
(15:28:03) API: me
(15:28:08) API: <API> well, I was on FOSDEM
(15:28:13) joanie: :-)
(15:28:21) API: so, there was a devroom about accessibility
(15:28:27) slee: API: one man show?
(15:28:32) API: I missed some of then
(15:28:46) slee: Someone told me about the room
(15:28:46) joanie: slee: aleiva and others were there
(15:28:50) API: and although we have some public
(15:29:04) API: it is clear that we weren0't the most popular devroom
(15:29:08) slee: joanie: thanks
(15:29:22) API: Mario couldn't go there, so they replace him with a 
(15:29:27) API: talk by 
(15:29:28) API: hmm
(15:29:31) joanie: Malte
(15:29:34) API: Openoffice accessibility guy?
(15:29:37) API: yes, that one ;)
(15:29:47) API: explaining more or less the status
(15:29:58) API: and there were some people asking questions
(15:30:03) joanie: Which is what? (the status)
(15:30:06) API: so at least some people get interest
(15:30:16) API: joanie, well, it is more about what they did
(15:30:18) slee: questions are good
(15:30:19) API: and some plans
(15:30:21) API: like IA2
(15:30:25) API: well, yes, but in my case
(15:30:30) API: one guy asked if 
(15:30:38) API: instead of work on specific 
(15:30:42) API: window managers
(15:30:49) API: if it would have sense to directly 
(15:30:55) API: add some a11y support on X
(15:31:12) API: and forgot the specific bits
(15:31:15) API: anyway
(15:31:24) API: I talked with Malte there about the hackfest
(15:31:25) ***slee wishes life was that simple
(15:31:31) API: and he said 
(15:31:42) API: that the atk/at-spi2 hackfest is interesting
(15:31:48) API: but right now he is not sure
(15:31:56) API: if he could go
(15:32:02) API: due company politics
(15:32:12) API: I was also on the LibreOffice presentation
(15:32:16) API: by Michael Meeks
(15:32:25) API: on the question turn, I asked about a11y
(15:32:31) ***clown brb
(15:32:34) API: in summary, OpenOffice has 
(15:32:37) API: a11y support
(15:32:42) API: so LibreOffice also have
(15:32:53) API: "if you are interested in improve it, join us!"
(15:32:57) joanie: heh
(15:33:00) joanie: my question is this:
(15:33:15) joanie: Does Michael and crew plan to continue pulling what OOo A11y does?
(15:33:25) joanie: or are these forks truly separate now?
(15:33:52) API: hmm, good question
(15:33:58) slee: good point - were should the effort go?
(15:33:58) API: anyway, as far as I know
(15:34:16) API: LibreOffice doesn't have any problem to get patches from OpenOffice
(15:34:24) API: so
(15:34:31) API: if there are improvements on OpenOffice
(15:34:42) API: I guess that those could be used for LibreOffice
(15:34:57) API: although no idea if someone is willing to do that
(15:35:00) joanie: meaning they will actively look for them or meaning we (a11y team) need to keep up with what Malte's team does and then ping the LO team to include the change?
(15:35:01) mgorse: The licenses don't conflict then?
(15:35:29) API: well, I don't think so
(15:35:47) API: but no idea about the interrelations between both communities
(15:35:57) API: using my ignorance
(15:36:08) joanie: We need to figure out *exactly* what is going on (or not going on).
(15:36:09) API: I don't think that OpenOffice people notifies LO
(15:36:11) API: people
(15:36:17) joanie: :-)
(15:36:54) API: ok, makes sense
(15:36:56) ***joanie sees becoming an active member of the LO community in her future
(15:36:57) joanie: :-/
(15:37:00) ***fer likes forks like Xorg, where the original project just stops, so there is no need to sync patches :)
(15:37:31) ***clown doubts that Ooo is going to just stop.
(15:37:47) joanie: The problem here (beyond what clown just said) is our users expect to be able to use either
(15:37:47) API: I also doubt that
(15:37:59) joanie: and Michael apparently has that 'patch it or shut up' attitude
(15:38:04) ***slee thinks joanie is slacking if not already a member </ducks>
(15:38:08) API: and in fact some distributions started to move to libreoffice
(15:38:09) API: ie
(15:38:10) joanie: which I would agree with if we had tons of resources
(15:38:16) API: natty uses libreoffice by default
(15:38:16) joanie: but we don't
(15:38:23) ***joanie nods re natty
(15:38:35) joanie: the one good thing is that building LO is super easy
(15:38:41) fer: what do we prefer? to keep OOo and LO compatible? or trying to push changes on LO to get a11y improved and then have separate support for them (like orca stuff)
(15:38:43) joanie: much more open
(15:39:10) joanie: fer: I prefer they each are accessible AND that they make them accessible without us having to do the work to contribute patches
(15:39:15) slee: LO are a doign a great community engagement act - so are likely to win form that point of view
(15:39:17) joanie: I don't mind filing bugs
(15:39:32) slee: always be pretty hard to with OOo
(15:39:43) slee: mind you patch it or shut up is not good
(15:40:12) API: well, so trying to get some conclusions
(15:40:13) slee: if LO OOo diverge much dioing both will be huge effort.
(15:40:14) API: summary?
(15:40:15) API: actions?
(15:40:20) slee: might be OK for the short term
(15:40:22) joanie: I'll add LO to my list
(15:40:33) ***joanie looks at her list and sighs
(15:40:41) ***slee pats joanie on her back
(15:40:55) joanie: mind you I already asked in the LO a11y community
(15:41:09) joanie: time for me to become more visible in the non a11y LO communities.
(15:41:31) joanie: API thanks for attending that session and reporting
(15:42:26) API: I will try it again ;)
(15:42:31) API: <API> summary?
(15:42:31) API: <API> actions?
(15:42:36) joanie: Action
(15:42:43) joanie: I will put LO on my list
(15:42:47) joanie: (see above)
(15:43:36) ***joanie wonders what other actions API is looking for?
(15:43:55) API: well, this "put LO in my list" 
(15:44:00) fer: some guys subscribing to LO mailing list and making noise :)
(15:44:04) API: also include investigate current relation between
(15:44:08) API: LO and OO?
(15:44:11) API: (new code and so on)
(15:44:15) joanie: yes all of the above
(15:44:25) joanie: 1. Making more noise on other LO lists
(15:44:46) joanie: 2. Trying to sort out *exactly* what the relationship between OOo and LO is or is not w.r.t. a11y fixes
(15:45:07) joanie: 3. Trying to sort out the expectations w.r.t. filing a11y bugs (which I assume is file duplicate bugs)
(15:45:21) joanie: 4. Trying to sort out if Michael really does mean patch it or shut up
(15:45:33) joanie: (i.e. what sort of support we can look to from LO)
(15:45:39) joanie: 5. Inform the respective communities
(15:45:56) slee: 6. trying to get them to do the donkey work
(15:46:00) joanie: i.e. if LO's a11y policy is patch it or shut up, that is not consistent with the Ubuntu commitment to a11y
(15:46:11) joanie: aka 'put it on my list'
(15:46:12) joanie: ;-)
(15:46:21) joanie: questions?
(15:46:55) fer: well, I'd like to assume it is "patch it or shut up" for new features, but not for fixing actual bugs on their code :)
(15:47:21) joanie: fer they are ignoring a crasher bug I filed
(15:47:31) ***clown wonders if moving to at-spi2 is a new feature.
(15:47:31) joanie: they responded immediately to say "could not reproduce it"
(15:47:50) joanie: and then when I reopened having built LO from master and provided a stack trace
(15:48:00) joanie: they couldn't be bothered to respond
(15:48:11) ***bnitz likes 5, would be great if "a11y support is too hard to do by yourself" is the catalyst to end the stalemate. 
(15:49:02) API: ok, a lot of conclusions ;)
(15:49:03) API: thanks
(15:49:08) API: lets move
(15:49:20) API: 3. a11y testing towards GNOME3 using Fedora test day approach? ( https://fedoraproject.org/wiki/Test_Day:2011-02-03_GNOME3_Alpha ) 
(15:49:27) API: joanie, I guess that you added this point
(15:49:35) joanie: not I
(15:49:37) fer: no, I did
(15:49:46) ***joanie doesn't care what fedora does
(15:49:47) joanie: ;-)
(15:49:51) fer: ahaha
(15:49:54) fer: it's not about fedora
(15:50:01) fer: it's about the approach for testing
(15:50:16) fer: like having this kind of old bug days but for testing
(15:50:18) joanie: fer I know. I was being snarky
(15:50:20) API: well, yes I agree
(15:50:21) API: I mean
(15:50:33) API: that at least they provide a "gnome 3 compliant" distribution
(15:50:39) API: we can't say that from ubuntu natty
(15:50:45) API: that it is still a mixed thing
(15:50:51) API: it would be good to test
(15:50:54) API: a gnome 3 distribution
(15:51:00) API: and check that a11y is working
(15:51:02) joanie: and they are doing it strictly out of selfless motives, no doubt. :-P
(15:51:13) API: ie: I fear that all this gconf/gseetings thing creates some nightmares
(15:51:22) API: selfless motives?
(15:51:30) API: I thought that this was extinct ;)
(15:51:35) joanie: sorry snark again
(15:51:36) fer: probably try to run a a11y testing day would be hard, but we can try to add a11y testcases to Fedora testing days :)
(15:51:38) ***joanie behaves
(15:51:50) mgorse: gnome-shell a11y is still a work in progress, so I don't know how that effects things. We might have to test the "fallback mode" if anything
(15:52:29) API: mgorse, well, some patches related to gnome-shell a11y
(15:52:32) API: are now on the master
(15:52:37) API: although without solving this
(15:52:40) API: https://bugzilla.gnome.org/show_bug.cgi?id=640057
(15:52:42) ***bnitz wonders how to test gnome-shell magnification.
(15:52:45) API: it is still not really testable
(15:52:51) ***clown hides
(15:53:08) API: bnitz, well right now on gnome-shell you can activate magnification
(15:53:12) API: but you can't configure it :P
(15:53:27) API: at least without orca, although I didn't test it
(15:53:28) bnitz: API:I was wondering about automating that test.
(15:53:34) API: ah ok
(15:53:40) clown: bnitz, there is a patch for a GUI testing various mag settings...
(15:53:58) clown: https://bugzilla.gnome.org/show_bug.cgi?id=622414
(15:53:59) bnitz: clown:Good thanks.
(15:54:10) clown: but, right, that doesn't do auto testing. 
(15:54:17) API: fer, anywat that link was for a testing day on 03-02
(15:54:21) API: I guess that we are late
(15:54:26) API: or I'm missing something?
(15:54:28) clown: bnitz, is there a framework to hook automatic testing into?
(15:54:34) fer: API: it was an example
(15:54:51) bnitz: clown:I'm building one based on mago. 
(15:55:02) API: so your proposal is?
(15:55:07) API: fer, so your proposal is?
(15:55:24) clown: bntiz ETA? (no pressure, but I'm getting some from AEGIS/Peter to hook into your framework).
(15:55:29) bnitz: Right now it can use accerciser plugins and a few tests I've written. I think magnifier would have to be tested by comparing screenshots which mago can do.
(15:55:33) fer: not proposing anything, just asking you guys if you think it is a good idea to try to get some a11y related testcases there
(15:56:24) bnitz: clown:Planning for april but since my platform is on GNOME 2, I'm not focused on testing gnome 3 features such as gnome-shell mag.
(15:56:48) API: fer, for the next one?
(15:56:50) clown: bnitz, well I have toyed with the idea of unit tests like -- setting one of the mag settings, and then reading it back to see if it "took". Of course, that doesn't show one what actually happend on screen.
(15:57:10) fer: API: if we add them now, they would be tested on any future testing day, I guess
(15:57:24) clown: bnitz, good to know re: GNOME3 vs. GNOME2
(15:57:26) clown: thanks
(15:57:27) API: imho it makes sense
(15:57:29) API: but
(15:57:35) API: who have time to track this?
(15:58:01) joanie: and would the Fedora people actually be responsive
(15:58:02) ***fer hides
(15:58:14) fer: redhat people don't care about it
(15:58:21) fer: but community does
(15:58:22) ***clown sees fer behind that tree over there...
(15:58:43) API: well, the issue is that it would not be really "polite"
(15:58:44) fer: I could try to poke someone to check if they are positive about this
(15:58:53) API: to add a a11y thing
(15:59:00) joanie: personally I think that this would be a model to follow for 3.2
(15:59:00) API: and then
(15:59:02) joanie: and beyond
(15:59:06) API: not to test that by ourselves
(15:59:20) joanie: and through some other mechanism than piggy backing onto what Fedora is doing
(16:00:06) joanie: For this cycle I think we might be stuck with testing on our own. But that's just my opinion.
(16:00:34) fer: it makes sense
(16:00:43) fer: as that kind of testing is more focused on regressions
(16:00:44) joanie: For instance, partnering with the Vinux folks might make sense
(16:00:51) fer: rather than "this is not working yet" :)
(16:00:58) API: well, yes, but as say, having a "GNOME 3 compliant" distribution would make our live easier
(16:01:16) API: but, afaik, vinux are still based on ubuntu
(16:01:29) API: see above this "mixture gnome2 and gnome3" thing
(16:01:29) joanie: yup
(16:01:38) fer: what about OpenSuSE?
(16:01:42) joanie: See above the 3.2 reference
(16:02:17) mgorse: 11.4 isn't going to ship GNOME 3. I think there will be an external repository to get it, and there's a GNOME 3 livecd for it
(16:02:30) mgorse: but its release schedule is going to miss GNOME 3
(16:02:34) joanie: mgorse: really re live CD?
(16:02:42) joanie: is it available externally yet?
(16:02:53) joanie: I pulled the dev CD a couple of weeks ago
(16:03:17) mgorse: joanie: I'm not sure off-hand. I'll need to look. I just know that it gets built, since I was asking a question the other day and someone mentioned it
(16:03:28) joanie: the other possibility might be Foresight
(16:03:44) joanie: but I cannot get that to install completely 
(16:03:52) joanie: (not that I've dug into it yet)
(16:04:29) joanie: anyhoo, since API is going to ask for summary and actions soon. :-P
(16:04:35) API: well, 5 minutes over time, so, could we try to 
(16:04:36) API: yep
(16:04:38) API: ;)
(16:04:42) joanie: I propose we add this sort of organized testing to the Roadmap
(16:04:46) API: get some summary, conclusions and actions
(16:04:59) joanie: i.e. to have our own sort of Fedora testing day (but without Fedora, necessarily)
(16:05:01) API: this roadmap?
(16:05:04) API: http://live.gnome.org/Accessibility/Roadmap
(16:05:12) joanie: but emulate their techniques/approach
(16:05:14) joanie: yessir
(16:05:18) joanie: re that roadmap
(16:05:22) mgorse: joanie: http://blog.crozat.net/2011/01/gnome-3-live-cd-usb-test-image.html
(16:06:04) joanie: mgorse: ah thanks. 
(16:07:12) API: ok, makes sense
(16:07:15) API: sooo
(16:07:21) API: as we are over time
(16:07:26) API: can we conclude the meeting
(16:07:35) API: or someone requires miscellaneous time?
(16:07:45) joanie: no. the meeting must continue into perpetuity
(16:07:53) clown: API, I had an agenda item...
(16:07:53) joanie: oops. behaving NOW.
(16:07:54) ***slee just come back at the end
(16:08:17) API: clown, column thing?
(16:08:21) clown: yes.
(16:08:25) fer: yeah
(16:08:29) API: well....
(16:08:31) fer: and I have also an issue
(16:08:40) API: this seems too long for miscellaneous time
(16:08:49) API: lets place that as the first item on the next meeting
(16:08:49) bnitz: In case anyone is interested in a11y testing code within the mago framework, here is the latest: https://code.launchpad.net/~brian-nitz/+junk/a11ytesting 
(16:09:13) clown: API, the working group who asked the question wanted the answer by next Mon...
(16:09:19) fer: well, quick info: about WAI User agent guidelines, some guy from IBM asked me to do a review of it regarding atk
(16:09:29) bnitz: It allows event-triggered running of some of the tests in Accerciser's basic validation plugin.
(16:09:29) clown: but, we don't have to do it now; we can discuss in the #a11y channel.
(16:09:51) clown: fer -- sounds like the issue they asked me.
(16:09:54) joanie: clown: Quick summary?
(16:10:08) joanie: (for the purpose of minutes)
(16:10:13) ***slee waves
(16:10:23) clown: joanie -- look at this table: http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table
(16:10:27) fer: clown: the many of us looking at it, the better the guide would be
(16:10:40) clown: should the column labelled "ATK" be labelled "AT-SPI" instead?
(16:10:42) joanie: oh yeah, that came up in open a11y too
(16:10:46) fer: well, they asked me about progressbar and so on, but I spoted some bugs there
(16:10:48) clown: or ATK/AT-SPI?
(16:11:08) API: fer, well that table already have a ATK column
(16:11:10) clown: and, does the at-spi-corba vs. at-spi-dbus have any relevance here?
(16:11:12) API: so whats missing?
(16:11:17) fer: the ATK / AT-SPI thing is tricky, because sometimes it is not 1 to 1 map
(16:11:41) API: well, in that case, it would make sense two columns
(16:11:43) API: I guess
(16:11:51) API: or a ATK/AT-SPI column
(16:11:58) API: and explain the differences if neccesary
(16:12:31) fer: yup
(16:12:44) fer: example, look at aria-checked (state)="false" / "true" / "mixed"
(16:12:46) clown: API, the question is as a browser developer or an AT developer, what a11y interface(s) should I consult when developing on GNOME with respect to ARIA
(16:12:49) clown: ?
(16:12:55) fer: ATK column
(16:13:15) API: well clown 
(16:13:16) fer: it says nothing about setting/clearing ATK_STATE_CHECK
(16:13:33) API: you mean if you should check ATK or AT-SPI?
(16:13:38) fer: and says Expose ATK_STATE_INDETERMINATE/STATE_SYSTEM_MIXED, and we don't have such a MIXED state
(16:13:41) API: where check==consult
(16:14:25) API: hmm, yes it is true
(16:14:29) clown: API, right -- what GNOME (linux?) documentation/libraries should I look at?
(16:14:32) API: that state is put there
(16:14:33) joanie: but we do have STATE_INDETERMINATE. Where did MIXED come from?
(16:14:50) API: in my opinion at-spi2
(16:14:52) clown: joanie, I know the ARIA motivation for mixed.
(16:14:52) fer: ia2 copys / paste bug probably
(16:15:02) API: hmm
(16:15:04) joanie: clown: not asking about motivation
(16:15:05) clown: API does at-spi2 == at-spi-dbus?
(16:15:07) API: a question
(16:15:08) joanie: asking who put it there
(16:15:09) joanie: ;-)
(16:15:22) API: this table is a guide for browser developers, right?
(16:15:29) clown: joanie -- that may be lost to history ;-)
(16:15:32) fer: conclusion: the whole document
(16:15:32) API: in that case, for GNOME
(16:15:32) clown: aaron?
(16:15:36) API: ATK
(16:15:40) API: as the browsers
(16:15:45) API: would implement ATK roles/states
(16:15:50) clown: API this is a guide for browser AND AT developers.
(16:15:51) API: not at-spi roles/states
(16:15:56) API: urgh
(16:16:02) API: well, in this case
(16:16:03) clown: AT developers since they are using the a11y API.
(16:16:08) API: both
(16:16:26) API: and stating that ATK is for the browser developers and at-spi API is for the AT tools
(16:16:28) fer: yeah, but they implement that trough atk, instead of directly talking to at-spi
(16:17:06) ***clown likes API's "stating that ATK is for the browser developers and at-spi API is for the AT tools".
(16:17:31) joanie: although that won't apply in the Qt world
(16:17:38) ***clown notes that browser write to the a11y API, and ATs read from it (at a first approximation).
(16:17:38) API: well
(16:17:52) API: joanie, right now there isn't a11y support on the Qt world
(16:18:02) joanie: it's coming though. 
(16:18:06) clown: joanie, yes, QT/KDE is another wrinkle.
(16:18:25) fer: what api should linux Qt based browsers use?
(16:18:29) joanie: And documents should, when possible, be flexible enough to continue to be relevant in the near future
(16:18:40) clown: but where there is an a11y api (atk or atk/at-spi) that should be noted.
(16:18:42) API: I mean that we should worry about Qt when we have something to check
(16:18:55) API: in the case of Qt, if the qt-bridge is finished
(16:19:02) API: it would be just about at-spi
(16:19:05) joanie: right
(16:19:10) API: afaik, and after my conversations with fregl
(16:19:21) API: they are not using the internal qt bits related to ia2 or msaa
(16:19:28) API: they are directly using qt api
(16:19:28) joanie: my point is, I'm not suer that we should state explicitly what ATK is for versus what AT-SPI is for
(16:19:36) joanie: do a 'ATK/AT-SPI' and be done with it
(16:19:45) API: why not?
(16:19:50) joanie: if the implementors don't know which is which we have a bigger problems
(16:20:01) joanie: because Qt won't implement ATK
(16:20:03) joanie: (right?)
(16:20:14) clown: joanie, dunno
(16:20:26) joanie: thus your dichotomy would fall apart in that case
(16:20:41) clown: to be really concrete what would Qt use for an aria role of, say "alert"?
(16:20:47) fer: but would QT expose directly at-spi bits? or their own QAccessible classes?
(16:20:49) joanie: if Qt implements AT-SPI
(16:21:06) joanie: I *assume* (always a bad idea) AT-SPI
(16:21:12) joanie: rather than some sort of QAccessible
(16:21:21) ***joanie pokes fregl
(16:21:28) API: yes, AFAIU
(16:21:37) API: qt-bridge is literally that
(16:21:51) API: without a QAccessible implementing any accessibility API
(16:21:58) API: anyway, I think that we are losing the focus
(16:22:06) joanie: therefore, the way to make this document continue to apply is to NOT specify the aforementioned differences between ATK and AT-SPI
(16:22:07) API: as clown initially asked about GNOME world
(16:22:15) ***joanie shuts up
(16:22:17) clown: API, right
(16:22:35) API: well, joanie, IMHO yes
(16:22:42) API: ATK/AT-SPI for GNOME
(16:22:50) API: Qt/AT-SPI for KDE or whatever
(16:23:16) fer: at-spi should be hidden by toolkit bridges
(16:23:29) fer: and toolkit should expose only Atk or QAccessible or whatever
(16:23:57) clown: here was a question posed at the teleconference:
(16:24:28) clown: if I use Accerciser to look at the a11y info, am I seeing ATK info? or more than ATK?
(16:24:46) fer: oh, that is a good point
(16:25:08) fer: people using accerciser for testing do see at-spi interfaces
(16:25:16) API: well, but this is again going to the app vs at
(16:25:21) API: accerciser is a AT tool
(16:25:29) API: so it would be looking for at-spi interfaces
(16:25:34) clown: because the browser/AT developers are going to use Accerciser to "test" if things are properly written/read.
(16:25:37) API: but other equivalent question would be
(16:25:50) fer: that is the only thing implementors implementing ATK interfaces can use :)
(16:25:52) API: "if Im implement a11y support of my_browser, am I seeing ATK info"
(16:25:53) ***clown notes that he is echoing fer.
(16:25:55) API: and the answer is yes
(16:26:31) clown: so the column is properly labelled?
(16:26:36) clown: right now it's "ATK".
(16:26:58) fer: and they are filling it based on testing done with accerciser I guess :)
(16:26:58) slee left the room (quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]).
(16:27:02) joanie: clown: I would (again) call it ATK/AT-SPI
(16:27:06) API: my vote it is still move it to a "ATK/AT-SPI " thing
(16:27:12) joanie: and (again) I would not distinguish what either is for
(16:27:25) clown: joanie, API that's how I'm leaning.
(16:27:33) joanie: I would leave researching that as an exercise for the reader
(16:27:46) fer: and then we have a mess when there is no 1 to 1 map from at-spi and Atk :)
(16:27:58) joanie: fer....
(16:28:01) clown: with a footnote that "AT-SPI" means AT-SPI-2 (Dbus).
(16:28:04) joanie: one of the goals of the hackfest
(16:28:13) joanie: is to bring those two more closely in alignment
(16:28:24) fer: agreed
(16:28:36) joanie: so if we (again) are looking at how to have a document which *remains* relevant for more than 6 months....
(16:29:04) joanie: I don't think that the few differences which currently exist (would be noticed) between the two are all that critical
(16:29:06) joanie: imho
(16:29:54) clown: pardon my ignorance, but why isn't there a 1-to-1 map between at-spi and atk? (perhaps a topic for another time...)
(16:30:12) ***joanie glances sideways at clown and chuckles
(16:30:21) fer: clown: that it the past! look at the future! :)
(16:30:53) clown: fer: the future is all transparent and animated (gnome shell and gnome3).
(16:31:01) joanie: lol
(16:31:07) API: clown, well the easy answer
(16:31:07) API: is
(16:31:13) API: that at-spi
(16:31:19) API: was though to be used not just only with atk
(16:31:26) clown: btw, that raises a related question: what does the ST toolkit a11y publish? ATK info?
(16:31:33) API: so some divergencies were not important
(16:31:40) API: clown, 
(16:31:40) API: yes
(16:31:41) API: ATK
(16:31:53) API: I made some accessibility objects implementing ATK
(16:31:54) clown: API -- good point. at-spi is an a11y broker for any a11y API.
(16:31:56) API: like gail
(16:32:10) API: although it is also true, that right now
(16:32:13) API: due the bonobo thing
(16:32:30) API: ATK is mostly the only "client-side" user of at-spi
(16:32:38) API: although in theory, Qt is near
(16:32:44) fer: dudu, I had almost forgotten about bonobos! those monkeys!
(16:32:45) API: well, 30 minutes over time
(16:32:48) API: something else in this point?
(16:33:14) clown: API, not from me -- I think I have what I need to go back to the aria working group.
(16:33:32) API: well ok
(16:33:35) API: so meeting over