14:06:12 <API> #startmeeting
14:06:12 <Services> Meeting started Thu Oct 23 14:06:12 2014 UTC.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:12 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:45 <API> this time, to model the subtopics I will use #topic instead of #info, because if not the minutes are somewhat messy
14:07:18 <API> #topic Progress towards 3.16: recap
14:07:26 <API> #info Last week we started to plan this cycle
14:08:00 <API> #info we listed spread of new APIs, new features and other good-to-have features, and also assigning some action items
14:08:45 <API> #info but we also realize that we didn't have enough time (or preparation) for a specific topic
14:08:56 <API> #topic Progress towards 3.16: new APIs
14:09:46 <API> #info Last week we talked about recent ATK APIs that needed to be implemented on toolkits, and we postponed to this week talk about new APIs, outcome of (for example) our collaboration with w3c
14:10:07 <API> #info I personally would like to work on the replacement of AtkUtil
14:10:29 <API> #info in short: current AtkUtil has several problems supporting more than one toolkit, and was poorly implemented
14:10:46 <API> #info that lead to maintained-by-glue solutions
14:11:02 <joanie> s/glue/bubblegum/ ?
14:11:17 <API> #info in fact, during the last cycle, we detected some bugs on gnome-shell that needed to be solved with workarounds
14:11:19 <API> joanie, yes
14:11:24 <joanie> :)
14:11:38 * joanie tries to behave better
14:12:18 <API> #action API will like to work on an AtkUtil replacement on this cycle, or at least have a first draft to be reviewed. As usual the idea is adding something new without breaking the old stuff, so implementations based on AtkUtil would need to still be working
14:12:25 <API> and done
14:12:46 <joanie> #info Joanie is still going through things (these are not one-week-only action items)
14:12:46 <API> so unless someone has questions on this, is the turn for anyone that wants to talk about new APIs for this cycle
14:13:17 <joanie> #info Joanie does want to port a couple of things from IA2 to ATK and AT-SPI2, namely accessibleWithCaret() and groupPosition().
14:13:31 <clown> cool.
14:14:05 <joanie> #info Joanie also wants to begin sorting out the situation with AtkAction (no names; make up what you want. Also AtkAction versus Interfaces. Also some other issues.)
14:14:16 <joanie> #info Joanie will keep on keeping on with this.
14:14:22 <joanie> Done.
14:16:36 <API> ok, so as nobody is raising hands with questions or suggestions
14:16:39 <API> I think that we can move
14:16:52 <API> I didn't plan to revisit any of the items of last week
14:16:58 <API> do someone want?
14:17:31 <jjmarin> I think that that the message by Peter Vágner  "Accessibility issues in gnome 3.14" https://mail.gnome.org/archives/gnome-accessibility-list/2014-October/msg00001.html can be used to try to improve the kayboard navigation in new applications windows
14:17:34 <jjmarin> what do you think ?
14:17:49 * clown looks
14:17:53 <joanie> jjmarin: yes
14:18:08 <joanie> jjmarin: Do you have time to triage the without-Orca; just keyboard nav stuff?
14:18:21 <joanie> i.e. there may also be a11y support issues
14:18:23 <API> #topic Progress towards 3.16: 3.14 analysis on the mailing list
14:18:41 <API> #info Peter Vagner sent an analysis of some accessibility issues of 3.14
14:18:46 <API> #info https://mail.gnome.org/archives/gnome-accessibility-list/2014-October/msg00001.html
14:18:48 <joanie> but if an app is not keyboard navigable, then an Orca user cannot even get to the widgets which may (or may not) have those accessibility issues.
14:18:49 <jjmarin> yes, I think I can find some time do this
14:18:55 <joanie> yay!
14:18:57 <joanie> thanks!!
14:19:06 <clown> jjmarin is the bomb.
14:19:13 <joanie> :)
14:19:13 <API> in any case, I think that he mentioned more than just keyboard navigation, right?
14:19:17 <API> in any case
14:19:30 <API> jjmarin, could you info/action your plan with respect this item
14:19:31 <API> ?
14:19:42 <jjmarin> #action Juanjo will triage keyboard  navigation problems in new applications
14:20:34 <jjmarin> done
14:20:41 <jjmarin> I think :-)
14:20:46 <joanie> :)
14:20:53 <API> ok thanks
14:21:16 <API> and now, changing slightly how the agenda is writtent
14:21:28 <API> #topic caribou & at-spi2-core issues after switching to D-Bus activation
14:21:32 <API> ueno, are you here?
14:23:07 <jjmarin> I wonder which time is in Japan now :-)
14:24:00 <ueno> hi ;-)
14:24:05 <clown> Tokyo is 11:30pm
14:24:14 <jjmarin> ok :-)
14:24:18 <API> ueno, hi, well you added this topic
14:24:21 <API> so the floor is yours
14:24:22 <clown> hi ueno
14:24:33 <API> and sorry, but I personally have those bugs off of my radar
14:25:03 <jjmarin> good afternoon, nearly good night, ueno !  :-)
14:28:15 <ueno> yes, I need some help to fix those bugs... though I think they are not so serious - maybe just a corner case
14:29:20 <API> ueno, looking at those bugs
14:29:23 <API> at least gnome ones
14:29:32 <API> they don't provide too much info
14:29:36 <API> just the symptomps
14:29:56 <API> and it seems somewhat similar to the redthat one
14:30:07 <API> so, do you have an idea of why those bugs are happening?
14:30:17 <API> or in which module you would need help?
14:30:30 <API> I guess that you are asking about "help with at-spi2"
14:30:34 <API> but wanted to confirm
14:30:45 <mgorse> These bugs are filed against AT-SPI?
14:31:59 <ueno> mgorse, I think they are similar to the one you fixed in at-spi2-core before 3.14 release
14:33:08 <clown> mgorse the bugs are against caribou.
14:34:33 <ueno> basically, after the D-Bus activation change, caribou is always started at gnome-shell startup - even for the D-Bus session for the 'gdm' user
14:35:14 <ueno> and when the session is terminated, some race(?) seems to happen
14:35:40 <API> ueno, fwiw, I realized that due the gtktreeview is slow bug, as was caribou the one triggering at-spi2-atk to start to launch events
14:35:44 <API> but I thought that was on purpose
14:36:00 <API> is not caribou always needed in order to get the screen on keyboard?
14:37:41 <mgorse> Is it intended that it always be started at the start of the session, or are you saying that that's part of the bug?
14:38:48 <ueno> I'm not sure, but one idea is to delay the invocation until it is really needed, yes
14:39:03 <API> in any case, just to be curious
14:39:11 <API> why is a problem that caribou is launched?
14:39:43 <mgorse> Or is the race the main bug that you're asking about?
14:41:07 <ueno> I'm wondering which is better - avoiding the unnecessary invocation or fixing races
14:41:51 <API> ueno, well as I asked before, there is also the problem that running caribou is a problem
14:41:56 <API> as bug https://bugzilla.gnome.org/show_bug.cgi?id=738497 is saying
14:42:07 <Services> 04Bug 738497: normal, Normal, ---, caribou-maint, UNCONFIRMED, Caribou memory usage grows out of control and causes slow start of Synaptic
14:42:07 <API> at the expected behaviour:
14:42:07 <API> 3.) Synaptic should be fast even when Caribou is enabled.
14:42:26 <API> do you know why there are those problems when caribou is running?
14:44:54 <ueno> API, well, no, sorry. perhaps it is a different issue than the D-Bus activation
14:45:05 <API> ueno, ok
14:45:13 <API> well thanks for pointing those bugs
14:45:28 <API> but Im afraid that as we are already meeting-time+45
14:45:37 <API> we will not have too much time to discuss there here
14:45:51 <API> ueno, taking into account that some triagging is needed
14:46:08 <API> could you take a look to those bugs, and if any discussion/help is needed, send an email
14:46:14 <API> to gnome-accessility-devel?
14:46:35 <ueno> sure, thanks for the info
14:47:42 <API> ok
14:47:55 <API> so if no ones mind, lets move to next topic
14:48:00 <jjmarin> I've noticed that Martin Gräßlin, KWin maintainer, has posted about libinput integration in KWin/Wayland, just in case is of any interest to any of you  http://blog.martin-graesslin.com/blog/2014/10/libinput-integration-in-kwinwayland/
14:48:29 <mgorse> Thanks; probably worth reading
14:48:31 <API> jjmarin, ok thanks
14:48:38 <API> #topic w3c updates
14:48:41 <API> clown, ?
14:48:49 <clown> Reviewing the two meetings earlier this week, I can think of one topic.
14:48:59 <clown> #info getComputedRole() as a JavaScript function in the browser
14:49:16 <clown> #info useful for developers and testing tools to make sure the role that the author intended is actually what is exposed through the accessibility APIs.
14:49:27 <clown> #info This was discussed at Mon's call.
14:49:38 <clown> #info Generally browser vendors are not averse to adding the function.
14:49:52 <clown> #info But issues are:
14:50:04 <clown> #info 1. Part of the Element interface in the DOM?
14:50:27 <clown> #info 2. Or just function that takes an alement as a argument, and returns info from the a11y tree.
14:50:47 <clown> #info 3. Also, what are the performance hits to adding this function?
14:51:00 <clown> #info 4. And are there security issues?
14:51:07 <clown> #info Reference:  https://www.w3.org/2014/10/20-aria-minutes.html#item03
14:51:28 <clown> #info the plan is to discuss this sometime next week at the face to face meetings during TPAC.
14:51:39 <clown> done. questions?
14:52:04 <API> I think that I miss some context
14:52:16 <API> so right now there is a javascript method called getComputedRole
14:52:26 <clown> no, there isn't.
14:52:27 <API> who and where that javascript method is right now implemented?
14:53:01 <clown> the proposal is to add that method to every browsers javascript engine.
14:53:03 <API> so the proposal is about adding a standard javascript methods for authors?
14:53:13 <clown> authors and testing tools.
14:53:16 <clown> yes.
14:53:43 <API> hmm, well
14:53:58 <API> again I don't have all the context, but that sounds a little like an overkill
14:54:15 <clown> why?
14:54:26 <API> I mean, that is already exposed as part of the accessibility APIs right?
14:54:27 <patryk> :q
14:54:35 <patryk> sorry :)
14:54:42 <API> so it is just a wrapper for that
14:54:47 <clown> right.  but authors don't have access to the a11y API.
14:54:48 <API> or am I missing something?
14:55:17 <clown> they have to run an a11y inspector to see what is going on.  It's very time consuming.
14:55:21 <API> well, don't have access on the html itself
14:55:22 <API> but
14:55:23 <API> yes that
14:55:27 <joanie> and what if you don't have all the platforms?
14:55:35 <API> they can use an a11y inspector
14:55:50 <joanie> how do you use an a11y inspector on Windows if you don't have Windows?
14:55:51 <clown> And, it's impossible to write an automated testing tool.
14:56:44 <clown> or more accurately, it's impossible to write a single testing tool.  You'd have to rewrite it for every OS, a11y API and browser combination.
14:57:08 <API> ok
14:57:23 <clown> eg. FF on windows with IA2.  and another for FF on windows for UIA.
14:57:24 <clown> etc.
14:57:27 <API> well, my next concern is that if the discussion started with getComputedRole
14:57:40 <API> is is planed to provide access to similar functions?
14:57:54 <API> getComputedName, getRelation, getBlah etc
14:58:12 <clown> there has also been proposals for getComputedName and getComputedDesription, yes.
14:58:31 <clown> Because, in most people's experience, those are the things authors tend to get wrong the most.
14:59:21 <clown> The odd thing is that browsers do provide *all* of that access to a11y APIs through JavaScript but only in developer versions of the browser.
14:59:45 <API> ah so then, those methods are already available
14:59:46 <clown> Not something publicly distributed.  Only so the engineers can debug their code.
14:59:50 <API> somehow I mean
15:00:05 <API> so:
15:00:06 <API> <API> who and where that javascript method is right now implemented?
15:00:13 <API> who== browser implementors
15:00:19 <clown> And, it's not publicly available because it's not performant nor secure.
15:00:22 <API> where==developer version of browsers
15:00:33 <API> announced==no
15:00:41 <API> is that correct?
15:00:48 * clown parsing...
15:01:51 <clown> based on conversations, my impression is that there the method is implements in developer/debug versions of the browsers.  But, not in the same way.
15:02:04 <clown> So, the discussion is now, can we move part of this to...
15:02:28 <clown> a secure, performant, interoperable function supported by all the browsers.
15:02:55 <API> "all the browser" seems to suggest a kind of standard
15:03:06 <clown> well, ARIA is a standard.
15:03:08 * joanie has another meeting sorry!
15:03:12 <API> hmm
15:03:17 <clown> getComputedRole() will be part of the ARIA standard.
15:03:24 <API> ARIA also include utility methods?
15:03:42 <API> I thought that was only new markup and implementation guide
15:03:53 <clown> without looking, ARIA doesn't have any methods now.
15:04:23 <clown> So, yes, this is a bit of a radical step.
15:04:30 <API> ok thanks
15:04:40 <clown> And, it might migrate from the ARIA working group to the DOM working group.
15:04:40 <API> well, sorry if I was somewhat dense with my questions/comments
15:04:49 <clown> or, be addressed by both groups.
15:04:59 <clown> Not a problem, API.  Questions are good.
15:05:02 <API> ok, in any case, I don't have more questions
15:05:07 <API> as joanie pointed we are out of time
15:05:13 <API> so
15:05:18 <API> #topic Miscellaneous time
15:05:30 <API> if someone want to add a quick comment
15:05:38 <API> about a new topic or anyone of the previous one
15:05:41 <clown> I likely won't be at next week's meeting due to TPAC.
15:05:42 <API> shot
15:07:18 <API> well nobody is raising their hands
15:07:23 <API> so I will close the meeting
15:07:32 <API> it is finish-time+7 after all
15:07:35 <API> #endmeeting