14:06:06 <infapi00> #startmeeting
14:06:06 <Services> Meeting started Thu Apr  2 14:06:06 2015 UTC.  The chair is infapi00. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:06 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:33 <infapi00> #topic Progress toward 3.16
14:06:37 <infapi00> #info 3.16 is here
14:07:13 <infapi00> #info only one problematic issue (so far);
14:07:30 <infapi00> #info bug 746670
14:07:41 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=746670 major, Normal, ---, gnome-shell-maint, ASSIGNED , GNOME Shell for Wayland fails to emit accessible window:activate events
14:07:47 <infapi00> #info that prevents gnome-shell to accessible under wayland
14:08:06 <infapi00> #info so instead of the expected "accessible but with regressions" it was a "non accessible at all"
14:08:30 <infapi00> #info joanie triagged the bug and pointed the problem
14:08:40 <infapi00> #info gnome-shell+mutter developers working on the solution
14:09:11 <infapi00> #info mclasen marked it as 3.16, so we can assume that they plan to include the solution on 3.16.1, scheduled next April 13
14:09:16 <infapi00> so done from my side
14:09:22 <infapi00> next?
14:09:46 <joanie> not sure if it's specific to 3.16, but....
14:10:04 <joanie> #info Joanie has been digging into some reported-by-users sluggishness in Orca.
14:10:14 <joanie> #info It was the result of removing some sad hacks.
14:10:59 <joanie> #info The removal, in favor of using pyatspi utility methods, is triggering event floods from Gtk+. Especially with, though she doesn't think limited to, GtkCellAccessible.
14:11:40 <joanie> #info There is some debate with Benjamin about whose job it is to filter this stuff out, i.e. should GtkCellAccessible not emit changed signals for object creation? (This is what Joanie thinks.)
14:12:09 <joanie> #info Alternatively, should the AT-SPI2 ATK bridge stop them from being emitted (which seems to be what Benjamin thinks).
14:12:58 <joanie> #info The "fun fact" is that Joanie found the commit to GtkCellAccessible in which stopping emission of signals upon creation was deliberately removed. This was back in 2011, she thinks.
14:13:27 <joanie> #info And *that*, Joanie thinks, is why we were seeing the crazy-slow Rhythmbox issues. (Because Caribou was listening for events.)
14:13:39 <joanie> #info Joanie is working on patches and negotiation with Benjamin.
14:14:16 <joanie> #info A 3.17 progress issue should include emitting object:state-changed:focused events instead of focus: events. Lots of Gtk+ bugs there. Joanie thinks she may be able to fix them herself and plans to try.
14:14:19 <joanie> (done)
14:14:40 <infapi00> fwiw, the rhythmbox bug was about children-changed signals
14:14:42 <infapi00> here
14:14:47 <infapi00> afaiu
14:14:59 <joanie> was that the only one?
14:14:59 <infapi00> is about creation children
14:15:20 <joanie> The children-changed didn't happen with object creation?
14:15:45 <infapi00> yes, probably they were added at the same time
14:15:49 <infapi00> but they are different events
14:15:54 <joanie> sure
14:15:58 <infapi00> and the rythmbox bug
14:15:59 <infapi00> was fixed
14:16:10 <infapi00> by the container not emitting the event
14:16:14 <joanie> fixed or improved and/or no longer triggered by caribou?
14:16:17 <joanie> but ok
14:16:18 <infapi00> if it has the state MANAGES_DESCENDANTS
14:16:24 <joanie> ah
14:16:27 <joanie> fair enough
14:16:31 <infapi00> at that moment, it was not related with caribou
14:17:03 <joanie> suffice it to say, however, that GtkCellAccessible (and subclasses) are emitting a metric crapton of signals upon creation if anything is listening
14:17:08 <joanie> it's insane
14:17:53 <joanie> so I dunno if the bridge should stop it from ever going over the bus or not
14:18:01 <infapi00> well, in any case, as you said, probably it would be complex to include it on 3.16.1
14:18:08 <infapi00> and just a question
14:18:34 <infapi00> what would be the condition that would allow to know when not to sent that events, or to filter them?
14:18:44 <joanie> in Gtk or in the bridge?
14:18:49 <infapi00> yes
14:18:54 <joanie> hah
14:18:57 <infapi00> I mean that in both cases
14:19:02 <joanie> I can only answer in Gtk+
14:19:15 * infapi00 listening
14:19:27 <joanie> What Gtk+ does, at least with cells, is call an update_cache method (I forget the exact name)
14:19:34 <joanie> update_cache emits the signals
14:19:41 <joanie> update_cache gets called in two places:
14:19:49 <joanie> 1. When something actually changes
14:19:54 <joanie> 2. Cell creation
14:20:18 <joanie> The code Benjamin removed back in 2011(?) was an argument like emit_signals
14:20:28 <joanie> it was false when the method was called upon creation
14:20:37 <joanie> and capt o adds, true when something actually changed
14:20:49 <joanie> post-2011, no argument and always emitted
14:21:08 <joanie> my original patches were trying to not just revert that change
14:21:18 <joanie> and I was able to solve it without doing so for the text cells
14:21:30 <joanie> for the boolean/toggle cells, it's not so easy
14:22:01 <joanie> how the bridge would do it.... Dunno.... Maybe say, "do I know about this object already?" and if the answer is no, don't send the "changed" signals over the bus
14:22:04 <joanie> maybe?
14:22:33 <infapi00> not sure if I follow, as far as I understand the problem is that
14:22:42 <infapi00> a lot of creation events are being emitted
14:22:50 <joanie> no
14:22:54 <joanie> lemme pull up the bug
14:23:07 <joanie> but a lot of text-changed and state-changed are being emitted
14:23:12 <joanie> *upon* creation
14:23:16 <joanie> also name changed
14:23:24 <infapi00> ah ok
14:23:28 <joanie> the thing is, the text didn't change, the name didn't change, and the state didn't change
14:23:46 <joanie> and in a table, things get out of control quickly
14:23:48 <infapi00> so the problem is that is emitting a lot of info of the object, as being an update
14:23:52 <joanie> like 400 events in a tiny table
14:23:57 <joanie> yes
14:24:00 <joanie> and it's a flood
14:24:33 <joanie> https://bugzilla.gnome.org/show_bug.cgi?id=746706
14:24:44 <Services> 04Bug 746706: normal, Normal, ---, gtk-bugs, ASSIGNED , Serious accessible event spewage from Gtk+ table cells
14:24:44 <mgorse> I thought we didn't usually send name-changed events if the original name was null, although that's only a part of what's going on, since there are also state-changed events and such
14:24:45 <infapi00> hmm, so benjamin is arguing that gtk should emit state-change events, even when the state didn't change?
14:24:59 <joanie> yeah
14:25:06 <joanie> I think so anyway
14:25:09 <infapi00> mgorse, yes that is the idea
14:25:16 <infapi00> I even remember a bug on atk related with that
14:25:33 <joanie> his IRC review of my refix patch was that my comment failed to blame atspi2-atk ;)
14:26:21 <joanie> anyhoo, this turned into an unexpected deep dive, but to (maybe) conclude:
14:26:47 <joanie> #info Perhaps it's worth our having a chat with Benjamin about whose job it is to stop these floods, and when event emission should occur.
14:27:21 <joanie> because frankly, I don't give a rat's ass, who stops it. But it needs to stop.
14:27:33 <infapi00> ok, will try to take a look next week
14:27:42 <joanie> it's a huge amount of events for Orca to process just to conclude nothing really changed
14:27:43 <infapi00> at least to add a comment on the bug
14:27:57 <joanie> and I assume hundreds of events over dbus is not especially performant
14:28:07 <joanie> and if those events are unwanted....
14:28:12 <joanie> (end of rant)
14:28:52 <infapi00> #action infapi00 will read the bug and add a comment on the bug, hoping to start a debate that lead with a solution of the problem, being on gtk or at-spi2-atk
14:28:54 <joanie> aren't y'all glad I came today?
14:28:55 <joanie> ;)
14:29:12 <joanie> thanks infapi00! I know you're wicked busy.
14:29:13 <joanie> but this will hopefully help
14:29:17 <infapi00> ok, so anything else on this topic?
14:29:26 * jjmarin has realised that gnome-builder is very far from been keyboard navigabled. Taking into account it will be the prefered/recommended development tool for GNOME, I guess it is good idea ping chergert and open a bug report.
14:29:28 <joanie> not from me
14:30:27 <infapi00> jjmarin, well, but that is a 3.17/18 thing in any case ;)
14:30:44 <infapi00> probably next or following week, it would be good to add a point to plan 3.17 schedule
14:30:44 <jjmarin> ok :-)
14:30:50 <infapi00> so assuming that this topic is over
14:30:59 <infapi00> #topic wec updates
14:31:02 <infapi00> #topic w3c updates
14:31:05 <infapi00> clown, ?
14:31:12 <clown> I've got one thing
14:31:38 <clown> But, most of my W3C time has been spent in IRC and/or email with Joanie regarding the new table ARIA roles/attributes.
14:31:52 <clown> So, I'll say my one thing and pass it over to her.
14:32:09 * joanie doeesn't want to rant any more ;)
14:32:25 <clown> #info The AAPI group have been working on the proper mapping of role="rowgroup" for the past month or so.
14:32:43 * joanie stifles a rowgroup rant too ;)
14:33:09 <clown> #info The current mappings are here, http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-rowgroup
14:33:30 <clown> #info The group's current feeling is to change it to something like the following:
14:33:56 <clown> #info "Regarding an element with role="rowgroup":  if it is focusable (has a tabindex attribute) or it has an ARIA global attribute, it must have an accessible in AAPIs, otherwise it will not be mapped."
14:35:08 <clown> #info The only holdout is FireFox, who want to map it whenever it appears.  Their technique is, "if the element has a 'role' attribute, then an accessible is created"
14:35:38 <clown> #info The only exceptions they have is for role="presentation" or role="none".
14:36:05 <clown> #info Their argument is that this is done for performance reasons:  things run faster is they don't have to check for "rowgroup".
14:36:14 <clown> done, questions?
14:36:28 <infapi00> just to understand where the finger of shame points
14:36:46 <infapi00> this is a "we are discussing because atk/at-spi is not mapped"
14:36:52 <infapi00> or a more general discussion about the role?
14:37:09 <joanie> I personally think we have our mapping solved.
14:37:19 <clown> it's a more general discussion.  The group would like common mappings across platforms.
14:37:27 * clown agrees with joanie
14:37:35 <joanie> I don't like it in the tree, but ATK_ROLE_PANEL seems like the only logical choice.
14:38:12 <infapi00> ok
14:38:27 <infapi00> well, so taking into account that the debate (and rants) are ongoing
14:38:37 <clown> By "common  mappings", we don't want a situation where FF maps it to ATK_ROLE_PANEL, but WebKitGTK doesn't map it.
14:38:38 <infapi00> I guess that it is about waiting for the final conclusion
14:38:48 <clown> yes.
14:39:12 <joanie> I think also it's commonality across platforms, isn't it?
14:39:18 <clown> right, joanie.
14:39:22 <joanie> i.e. Safari and Epiphany should map it
14:39:24 <joanie> or not
14:39:39 <clown> we also don't want different browser/platforms given different mapping resutls.
14:39:53 <clown> *giving
14:40:18 <clown> I should info that...
14:41:09 <clown> #info The goal is common mappings across browser and platforms.  We don't want FF to map it, but WebKitGTK doesn not, nor do we want it mapping under ATK, but not under UIA (for example).
14:41:41 <clown> done, and regrets the typos.
14:42:05 <infapi00> don't worry, typos are common in this channel
14:42:21 <infapi00> so having said so
14:42:22 <jjmarin> sure :-)
14:42:32 <infapi00> more comments, questions doubts on this topic?
14:42:46 <clown> I'm done.
14:42:49 <jjmarin> or better suer ;-)
14:43:00 <clown> lol
14:43:13 <infapi00> #topic Marketing
14:43:16 <infapi00> jjmarin, ?
14:43:27 <jjmarin> #info GNOME 3.16 was released, this time without mentions to any a11y stuff (I was late when I asked the inclusion of the new high contrast theme :/ )
14:43:42 <jjmarin> #info The a11y annual report was delivered for review
14:43:53 <jjmarin> #action Juanjo will update the release version and date in the articles of the wikipedia
14:44:03 <jjmarin> done ! questionsv?
14:44:22 <infapi00> but the annual report will include a11y stuff?
14:44:22 <clown> who did the new high contrast theme?
14:44:38 <clown> I came across this a while ago:  https://github.com/kolanos/gnome-high-contrast-inverse-theme
14:44:39 <jjmarin> jakub AFAIK
14:45:26 <clown> hmmm.  looks like different people.
14:45:38 <jjmarin> http://jimmac.musichall.cz/blog/2015-03-24-high-contrast-refresh/
14:46:17 <clown> that looks nice.
14:48:05 <infapi00> so just in case it was missed
14:48:10 <infapi00> jjmarin, but the annual report will include a11y stuff?
14:48:32 <jjmarin> yes, it will
14:49:03 <infapi00> ok, then I don't think that not having a reference to a11y on this cycle became so relevant
14:49:11 <infapi00> having said so
14:49:15 <infapi00> jjmarin, thanks for tracking all this
14:49:19 <jjmarin> https://wiki.gnome.org/Engagement/AnnualReport/2014/A11yReport
14:49:23 <infapi00> and I don't have more questions
14:49:39 <jjmarin> The same text I presented here some time ago
14:50:00 <infapi00> jjmarin, so they just C&P
14:50:01 <infapi00> ?
14:50:07 <infapi00> I mean, they didn't summarized it?
14:50:32 <jjmarin> No by now, the review, rewritten haven started yest
14:50:37 <jjmarin> yet
14:50:39 <infapi00> ah ok
14:51:27 <infapi00> so, I don't have more questions
14:51:29 <infapi00> anyone else?
14:52:05 <infapi00> #topic Miscellaneous time
14:52:16 <infapi00> something non scheduled to mention?
14:54:08 <infapi00> crickets
14:54:10 <jjmarin> in the post about the high contrast theme http://jimmac.musichall.cz/blog/2015-03-24-high-contrast-refresh/ there is some feedback about it
14:54:50 <clown> the 4 comments, jjmarin?
14:55:16 <infapi00> well, if my memory serves me well
14:55:21 <clown> specifically, the one about inversion?
14:55:28 <infapi00> joanie mentioned something similar
14:55:28 <jjmarin> 'A friend of mine tried to use the shell with a dark background and magnifier using inverted colours and the dark theme of the shell is really disturbing for him, especially the shadows in overview which turn white. Also, the windows lack a clear border, the one in 3.14 are way too thin for him.'
14:55:50 <infapi00> in syummary, there is a high contrast theme, but it is not really well integrated with gnome-shell
14:56:23 <jjmarin> and I don't know how useful is for people who need it
14:56:36 <clown> Yes, I had a couple of users email me to say, that the loved the magnifier inverse function, but hated that it resulted in the wrong thing with respect to the gnome-shell white-on-black UI.
14:57:11 <clown> the trouble is the magnifier inverts the screen.  It doesn't check each "window" and invert individually.
14:57:30 <joanie> the workaround is to get an inverse theme
14:57:50 <joanie> before I got darker, progressive lenses, that is what I did
14:58:27 <clown> can an inverse theme affect the gs UI?
14:58:35 <joanie> that's what I mean
14:58:39 <joanie> there are gnome-shell themes
14:58:42 <joanie> fedora has them
14:58:59 <clown> I see.  (learn something new every day).
14:59:19 <joanie> so you get a black on white gnome-shell them
14:59:31 <joanie> theme too
14:59:42 <joanie> then inverse undoes it ;)
14:59:46 <clown> right.
14:59:51 <joanie> and fixes the blinding rest of the screen :)
15:00:12 * joanie runs to her next meeting
15:00:15 <clown> and how easy is it (user friendly) to get and install new themes?
15:00:24 * clown waves bye to joanie
15:00:30 <jjmarin> bye joanie !
15:00:38 <infapi00> well, probably is a good comment to end the meeting
15:00:39 <jjmarin> you need the gnome-tweak-tool
15:00:40 <infapi00> moment too
15:00:48 <clown> thanks jjmarin
15:00:55 <infapi00> jjmarin, so that goes again to my previous "not really integrated"
15:01:04 <infapi00> and after this gratuitous mini-rant
15:01:08 <infapi00> bye bye everybody
15:01:11 <infapi00> #endmeeting