14:05:54 <API> #startmeeting
14:05:54 <Services> Meeting started Thu May 29 14:05:54 2014 UTC.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:54 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:28 <API> #topic Progress towards 3.14 (plus a little 3.12)
14:06:45 <API> #info API was taking a look to bug 730118
14:06:45 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730118 normal, Normal, ---, gnome-shell-maint, NEW, GtkTreeView very slow since 3.12
14:07:21 <API> #info he realized that if an application that is listening to accessible events
14:07:29 <API> #info so the bus get accessible events
14:07:40 <API> #info closes, the bus properly stop to receive events
14:07:51 <API> #info but not if the application just deregister the listeners
14:08:12 <API> #info in this specific case, the reason of the event flood was the magnifier
14:08:23 <API> #info but the magnifier was properly deregestering the listeners
14:08:45 <API> #info API added a patch that also calls atspi_exit() when no listeners are registered
14:09:04 <API> #info this solves the issue of the event flood when non accessibility tool is running
14:09:21 <API> #info Jasper (gnome-shell reviewer) showed concern, because this is a partial solution
14:09:41 <clown> yes, there should be something less heavy handed...
14:09:42 <API> #info API mentioned that the patch is small enough to be included on 3.12, as a full solution would be likely too complex to that
14:10:09 <API> #info API suggested to apply this in order to mitigate the problem on 3.12 and working on a full solution for 3.14
14:10:26 <API> #info status: waiting for Jasper review, and also confirmation that solves the problem
14:10:28 <API> done
14:10:34 <API> questions, doubts?
14:10:46 <clown> cool.  vindicates my suspicions from last week.
14:11:02 <mgorse> Okay; thanks for looking into that. I need to go and read the comments on the bug
14:11:16 <API> mgorse, no problem
14:11:30 <API> I assumed that you were busy, as you didn't mention something
14:11:39 <API> all that I found was during this morning
14:11:53 <API> although I agree with Jasper
14:12:01 <API> about that a full solution is needed
14:12:12 <API> I also think that it would be good to have this solution for 3.12
14:12:20 <API> <clown> cool.  vindicates my suspicions from last week
14:12:26 <API> what suspicion?
14:13:05 <clown> When this was raised last week (or the week before?) I said maybe it's gnome-shell itself because the magnfier tracking registers listeners.
14:13:40 <mgorse> Did Benjamin change something in gtk? There's a comment on 723819 saying that it goes away in 3.10.9
14:13:54 <API> clown, ah ok
14:14:16 <API> well, as I said, the magnifier is properly deregestiring listeners if not needed
14:14:20 <mgorse> oh, wait. Wasn't this new to 3.12? Now I'm confused
14:14:21 <API> but that was not enough
14:14:32 <API> mgorse, yes, as I say on one of my comments
14:14:38 <API> this is not a regression caused by gtk+
14:14:43 <API> we thought that was
14:14:48 <clown> right, API, I wasn't completely sure that is was deregistering any more or not.
14:14:49 <API> because benjamin made a change on gtk+
14:15:04 <API> so now gtktreeview would have more children-changed events
14:15:15 <API> but in the end it is because on 3.12
14:15:17 <clown> But, it's interesting that even deregistering does not stop the events on the bus
14:15:23 <API> the magnifier at some point activates itself
14:15:35 <API> and in spite of deregestering the listeners if not needed
14:15:38 <API> that was not enough
14:15:42 <API> <clown> But, it's interesting that even deregistering does not stop the events on the bus
14:15:48 <API> yes, I also mention that on the bug
14:15:52 <API> but as I say
14:15:59 <clown> and you info'ed it here!
14:15:59 <API> even if that is solved on at-spi2
14:16:23 <API> I think that not having atspi initialized if not needed
14:16:31 <API> so less resources
14:16:33 <API> makes sense
14:17:08 <clown> but, we looked into initializing atspi during the google summer of code, and I *thought* we discovered that it didn't do much.
14:17:08 <API> in any case
14:17:23 <API> clown, yes we concluded that
14:17:26 <clown> So, it was okay to initialize it right off the get go.
14:17:30 <clown> What changed?
14:17:30 <API> if you just do an atspi_init
14:17:33 <API> and nothing else
14:17:43 <API> it doesn't do too much
14:17:58 <API> if you add more stuff, it seems that the bus communication gets there
14:18:08 <API> so it is better (imho) to call atspi_exit if not needed
14:18:38 <API> having said so, more questions or doubts here?
14:18:55 <clown> my gut says there  must be a less heavy handed technique, but I don't know enough about at-spi2 to say that with any authority.
14:19:39 * clown notes that the onus is therefore on me to prove otherwise.
14:20:04 <mgorse> As far as events still being sent after deregistering listeners, that is by design at the moment. Ie, an app might still make queries even if it isn't listening for events, so some events are sent no matter what since they update the AT's cache. But maybe it's safe to assume that, if an application isn't listening for any events, then it won't be making queries, so we don't need to worry about updating its cache
14:20:13 <mgorse> or maybe the whole question of how caching works needs to be rethought
14:20:29 <clown> good points mgorse.
14:20:33 <API> well, thats for sure ;)
14:20:38 <API> as we said at the end of the cycle
14:20:45 <API> we need to check
14:20:49 <mgorse> Ie, part of bug 708695 that I never finished implementing
14:20:49 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=708695 normal, Normal, ---, at-spi-maint, NEW, Need a way to avoid synchronous D-Bus calls when processing events
14:20:59 <API> if cache is helping performance or not
14:21:11 <API> and kill it if not needed
14:21:23 <API> having it is complicating a lot the design and interaction
14:21:26 <API> as any other cache
14:21:29 <API> cache coherence is hard
14:21:43 <API> so we should only rely on it if it is really needed
14:21:59 <API> a pity that thre are too many open fronts
14:22:09 <API> <mgorse> Ie, part of bug 708695 that I never finished implementing
14:22:12 <API> indeed
14:22:38 <API> in any case, probably discussing that is material for another moment, not the a11y meeting
14:22:51 <API> but fwiw
14:23:02 <API> mgorse: " But maybe it's safe to assume that, if an application isn't listening for any events, then it won't be making queries, so we don't need to worry about updating its cache"
14:23:21 <API> without thinking it a lot, I think that is safe to assume
14:24:04 <API> in any case
14:24:11 <API> we used a lot of time on this topic
14:24:17 <mgorse> The exception I can think of is a simple pyatspi script that, ie, performs an action, waits, then checks something, but we already don't use the cache if there's no main loop, and the cache can be disabled if needed
14:24:28 <API> so as a summary of the last chat
14:24:59 <API> #info During the meeting it was discussed (or a gentle reminder was send), that it should be good to investigate:
14:25:35 <API> #info a) real advantage of the cache. Discussing the possibility to remove it/improve it
14:25:53 <API> #info b) Advance with the implementation of the solution for bug 708695
14:25:53 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=708695 normal, Normal, ---, at-spi-maint, NEW, Need a way to avoid synchronous D-Bus calls when processing events
14:26:56 <API> #info c) Advance on reduce the amount of events sent to the bus, to avoid event flood similar to the gtktreeview one. This could be done by just filtering the events (ie: not sending so many children-changed) or compressing events
14:27:09 <API> so with that summary in hand
14:27:18 <API> and as we alredy used half meeting for the topic
14:27:22 <API> anything else or moving?
14:27:30 <clown> moving is fine with me.
14:27:57 <mgorse> fine with me
14:28:26 <API> #topic W3C updates
14:28:27 <API> clown?
14:28:33 <clown> #info Holiday in the U.S. on Monday.  There was no general ARIA meeting.
14:28:56 <clown> #info The ARIA documents are very close to being ready for a first public working draft relesase for version 1.1
14:29:13 <clown> #info Hence, on track for this publication in the next week or so.
14:29:42 <clown> that's it.  it's pretty quiet on the ARIA front right now.  questions?
14:29:48 <API> so I guess that the call for fixes was smooth
14:30:06 <API> in the sense that nobody came saying "the doc is wrong here and here"
14:30:32 <clown> Actually, for public workding drafts, more complaints come in after they have been published :-)
14:30:48 <clown> It's the first round since the relase of 1.0 last March.
14:31:02 <API> well, that is normal
14:31:14 <API> most complains for anything comes when in theory is too late to complain ;)
14:31:26 <clown> So, it's an attempt to address suggestions/criticisms that we put on hold in order to have a 1.0 release.
14:32:02 <API> ok, thanks
14:32:07 <API> so no more questions from my side
14:32:10 <clown> your welcome.
14:32:33 <clown> *you're
14:32:50 <API> well, jjmarin is ont here
14:32:50 <API> so
14:32:52 * clown wonders where jjmarin is
14:32:56 <API> #topic Miscellaneous time
14:33:24 <API> #info API made a first review for bug 730505, patryk updated the patches
14:33:24 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730505 normal, Normal, ---, at-spi-maint, UNCONFIRMED, Draft for atspi tests
14:33:37 <API> patryk, sorry if I didn't review your new patches yet
14:33:48 <mgorse> yeah, same for me
14:33:49 <API> I was busy with bug 730118 and others
14:33:49 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730118 normal, Normal, ---, gnome-shell-maint, NEW, GtkTreeView very slow since 3.12
14:34:28 <clown> are these unit tests?
14:34:35 <API> yes
14:34:45 <API> or at least try to be
14:34:47 <clown> all right!
14:34:59 <API> and fwiw, I think that it is a good idea to have tests
14:35:05 <API> this are more near functional tests
14:35:07 <clown> it's now actually possible to detect regressions?
14:35:09 <API> but are good to have too
14:35:20 <API> clown, well, right now is just a starting point
14:35:32 <clown> a starting point is a good point.
14:35:32 <API> but that would be the medium/long term objective
14:35:44 <API> is also good, because it includes a dummy implementation for atk
14:35:56 <API> on atk I have some small atk object implementation at test directory
14:35:57 <clown> it's someting willie walker wanted to do back in 2009.
14:36:13 <API> I had the idea of extending it to  be a kind of default atk implementation
14:36:20 <API> but probably having it on a test suite
14:36:30 <API> so an atk implementation with an objective, makes more sense
14:36:35 <API> and would be easier to maintain
14:36:51 <API> easier to maintain and executed more often
14:36:52 <clown> makes sense
14:36:57 <API> my tests at atk/test
14:37:14 <API> check stuff like if states names are properly got, etc
14:37:17 <API> but is not really formal
14:37:24 <API> btw
14:37:45 <API> #info working on bug 730505 also raised the fact that at-spi2-atk doesn't have documentation at all
14:38:09 <API> #info probably a good small task, or a collateral effect from this work, would be starting the documentation for that module
14:38:36 <API> #info it shouldn't be a lot of documentation, probably only the method to start the bridge, and document that a gmodule is still available if you are a gtk2 app
14:38:57 <API> just mentioning it
14:39:22 <API> because although at-spi2-core documentation can be improved
14:39:27 <API> at least we have some documentation there
14:39:34 <API> and having it was a non-trivial amount of work
14:39:48 <API> was done by and GSOC student
14:39:59 <API> but in this case (at-spi2-atk) the effort would be smaller
14:40:13 <API> and I think that I'm getting the focus
14:40:27 <API> so, this was my misc time stuff
14:40:40 <API> anyone want to share some non included on agenda stuff?
14:41:28 <clown> I have question about ATK buttons.
14:41:40 <clown> Do ATK buttons have children?  Or are they atomic?
14:42:20 <API> that depends on the atk implementor ;)
14:42:32 <API> as far as I remember
14:42:47 <API> some atk implementor represent buttons as an atomic object
14:43:07 <clown> okay, put another way:  is it possible for ATK buttons to have children/descendants.
14:43:08 <clown> ?
14:43:17 <API> and for example, in that case the button also implement AtkImage interface
14:43:19 <API> in other cases
14:43:25 <API> the button is a container
14:43:31 <API> and can have children
14:43:43 <clown> Do the children appear in the accessibilty tree?
14:43:50 <API> in some of those cases, the image (the button's icon) appear as a child
14:43:52 <API> clown, yes
14:43:55 <clown> I guess that's more of an atspi question.
14:44:01 <API> and the poster boy here is gnome-shell
14:44:20 <API> most objects that identify themselves as buttons have children, and those children are exposed
14:44:24 <clown> it's a boy is it?  (sorry).
14:45:07 <API> well, I don't know if the "poster boy" english idiom has the equivalent "poster girl"
14:45:17 <clown> probably not.
14:45:34 <API> in any case, just out of curiosity
14:45:38 <API> why that question?
14:45:53 <API> well, that was a bad worded question
14:46:11 <joanie> I don't want the children in the tree
14:46:15 <API> just asking if the question is related with something in mind (bugs, specific document, etc)
14:46:31 <clown> alex surkhov raised the issue against ARIA.  Currently ARIA role="button" doesn *not* allow accessible descendants.  ARIA buttons are atomic.
14:46:46 <API> joanie, well true, I forgto to mention that although right now we found this two options, the prefered is the atomic one
14:46:47 <API> sorry
14:47:12 <clown> If we go the root of allowing children, one thing to worry about is if that can even be represented in the a11y APIs.
14:47:29 <API> clown, and alex raised that question because firefox has non-atomic buttons or for any other reason?
14:48:17 <clown> He did give a XUL example.  But I don't know if this is a common UI pattern or not.
14:48:34 <clown> The XUL example:  https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/PopupGuide/MenuButtons#The_%27menu-button%27_button
14:49:12 <clown> If you click on the left side of the button, it performs a save.  If you click on the right side of the button, it pops up a menu.
14:49:29 <clown> Personally, I think that is a poor UI.
14:50:07 <API> hmm
14:50:12 <clown> A better UI:  left mouse click = save; right mouse click = menu.
14:50:15 <API> that sound more like two buttons
14:50:21 <clown> Exactly.
14:50:35 <clown> Even though it's drawn as a single button.
14:51:40 <API> well, bt that "drawn as a single button"
14:51:44 <API> is an implementation detail
14:52:00 <API> the theory is that the accessibility tree should expose a user-oriented tree
14:52:06 <clown> I dunno.  I'd say it's a layout detail.
14:52:38 <API> although in the practice, that not always happen (again: gnome-shell, which accessible tree has plenty of useless objects)
14:52:48 <API> in any case, atk per se
14:52:52 <clown> the question for the a11y tree is:  one "parent" button with two children, or two sibling buttons.
14:52:53 <API> doesn't say anything about that
14:53:01 <API> if you ask on the chat
14:53:11 <API> joanie, and anything else will advice to have atomic buttons
14:53:17 <API> but it is not written anywhere
14:53:31 <API> that is part of that "implementation guide" or whatever that we would like to write for atk
14:53:43 <joanie> still in multiple meetings/sessions
14:53:45 <clown> anoter possible consideration:  is GtkButton atomic?
14:53:51 <joanie> but for now: no children of buttons
14:53:57 <joanie> please, thank you, i have spoken.
14:53:59 <joanie> :P
14:54:13 <clown> thus spake the ghost of joanie.
14:54:16 <API> <clown> anoter possible consideration:  is GtkButton atomic?
14:54:21 <clown> thanks, joanie
14:54:24 <API> well, per se, gtkbutton is a container
14:54:36 <API> so it can include whatever you want
14:54:48 <API> I don't remember how the accessible object is being exposed
14:55:23 <clown> yes, but can you left-click on two different regions within a GtkButton and get different actions?
14:55:43 <clown> I suppose if the developer really wanted that, there is probably a way to do it.
14:55:45 <API> well, I think that is doable using horrible hacks
14:55:50 <clown> But, it's not the norm.
14:55:56 <clown> Right, API
14:56:09 <API> but Im pretty sure that if you do that Benjamin will facepalm so hard that his head would explode
14:56:31 <API> and probably one designer around too
14:56:40 <clown> Oh no!  I pity the fool developer who does that to Benjamin.
14:56:48 <API> in any case, as the meeting is going to the end, for minutes sake, I will try to summarize this chat
14:56:58 <clown> Sure, thanks API
14:57:22 <API> #info Joseph asked what are the "ATK policy" with respect of buttons, if they are atomic of they have children
14:57:41 <API> #info API mentions that ATK itself doesn't force anything, and having children or not depends on the implementor
14:57:54 <API> #info right now, in the practice, you can find both approaches
14:58:31 <API> #info having said so, the heavily preferred option is atomic buttons, without children
14:59:38 <API> #info Joseph raised this as was mentioned on one ARIA related thread, as right now, ARIA buttons are atomic, and Alex Surkov raised the doubt about if that is true
14:59:55 <API> #info Alex Surkov used an example that sound more a implementation detail
15:00:14 <API> #info conclusion: atomic buttons please
15:00:14 <clown> #info the example:  https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/PopupGuide/MenuButtons#The_%27menu-button%27_button
15:00:25 <API> and I think that that was all
15:00:33 <API> ddi I forget something?
15:00:33 <clown> that was excellent, API
15:00:34 <API> *did
15:00:37 <API> clown, ok thanks
15:00:43 <API> so is meeting end time
15:00:52 <API> something else? closing the meeting?
15:01:03 * patryk reading
15:01:29 <API> patryk, well that can take a while ;)
15:01:40 <API> don't hesitate to ask on #a11y or via email
15:01:43 <API> and thanks for the patches
15:01:49 <API> having said so, I will close the meeting
15:01:54 <API> #endmeeting