16:01:24 #startmeeting 16:01:24 Meeting started Thu Oct 3 16:01:24 2013 CET. The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:41 #topic on 5 min margin 16:02:02 heh 16:04:31 * clown waves 16:05:11 5 minutes now 16:05:14 so lets start 16:05:22 and move to a real topoc 16:05:25 *topic 16:05:39 #topic "Boston" Summit 16:06:18 #info Alejandro Piñeiro bought their flight tickets, foundation confirmed that will support him, so he will be at montreal 16:06:38 #info mgorse bought a ticket and will be there, too 16:06:40 anyone else want to info to confirm their presence before I continue? 16:06:41 c'est bon 16:06:48 #info Joanie will drive up 16:07:00 I won't be there. Should I info that? 16:07:09 #info Juanjo won't attend 16:07:32 #info Joseph won't attend since he will be returning from the jQuery a11y summit. 16:07:46 a jquery a11y summit, interesting 16:07:54 #info http://www.deque.com/deque-partners-jquery-create-accessibility-summit 16:07:56 anyway a pity you not being there 16:08:20 in any case, I will retake the scepter 16:08:32 about proposals of what to do there 16:08:33 well, the gnome summit always falls on thanksgiving, which makes it difficult for me. 16:09:01 #info IMHO, the main topic will be wayland 16:09:41 #info For that it would be good to do some pre-summit homework 16:10:06 #info basic stuff, like compiling all the stuff using current documentation, and trying at-spi2, orca etc 16:10:19 #info joanie wrote a pretty wiki page with all that stuff: 16:10:24 https://wiki.gnome.org/Accessibility/Hackfests/Montreal2013 16:10:59 #info So as an outcome of that homework, some of the stuff to discuss there could be: 16:11:12 #info a. Comment about the tests outcome 16:11:26 #info b. Identify features needed for X and Wayland 16:11:53 #info c. Determine how open we (and others) are to an API change especially with respect to device events (current API is not really good) 16:12:22 #info The second main topic would be discuss about making at-spi2 API more async 16:12:32 #info a. Can we start looking now at what API changes (if any) are needed? 16:12:43 #info b. Think about how such a change would affect the idea of merge atspi/ATK 16:12:49 (done) 16:13:04 I think that this is enough taking into account that is not a real a11y hackfest 16:13:15 and that probably we would be sucked with other conversations around 16:13:42 in fact next topic on today meeting is 3.12 stuff, so probably we will also discuss some of that 16:13:46 in any case 16:13:53 yeah, makes sense 16:13:53 opinions about my suggestions? 16:14:15 your suggestions make sense to me API 16:15:15 sounds like a plan 16:15:18 :) 16:15:24 sounds like a good plan. 16:16:11 in any case, as there are not a lot of people here 16:16:21 and as others like Company 16:16:32 are also subscribed to gnome-accessibility-devel 16:16:35 I will send a email 16:17:01 #action API will send a email to the -devel ml in relation with the informal agenda for the "Boston" Summit 16:17:31 and taking into account that everybody is agreeing on what to do during this week (aka homework) and on summit 16:17:35 moving to next topic? 16:17:42 * joanie nods 16:17:43 +1 16:18:42 #topic GNOME 3.12 Planning 16:19:30 #info Obviously two of main topic for 3.12 are the already mentioned Wayland + asynchrony on at-spi2 16:19:35 #info but there are others 16:19:52 #info we are right now on feature proposal period. 16:20:10 #info After thinking a little, and talking with joanie we came with an idea: 16:20:21 #info "Make keyboard navigation consistent across our entire platform" 16:20:49 #info Rationale: gtk and gnome-shell focus is slightly different 16:21:02 #info s/focus/focus navigation 16:21:23 #info For example, on gnome-shell, on most cases TAB is the same that Left-Arrow, except that adds also cycle 16:21:47 #info but on gtk, TAB is used to "jump" across containers 16:22:07 #info using TAB on gnome-shell to move from one container to other was already mentioned in tha past 16:22:14 * clown notes that gtk appears to follow the aria best practices. 16:22:19 #info but it would be good to try to have a plan 16:22:51 #info in the same way, during the last weeks of this cycle, we found some key navigation issues/inconsistencies on gtk 16:23:08 #info mostly on new widgets, so it would be good a review of the platform 16:23:42 and that would be the idea 16:23:47 opinions, suggestions? 16:24:59 #info ARIA authoring practices recommends using TAB/SHIFT-TAB to move between containers, and arrows to move within a container. 16:25:27 #info the main reason is to avoid seemingly endless TABing to acquire a widget. 16:25:59 #info So: TAB is for navigating larger parts of the interface. 16:26:01 (done) 16:26:27 I think it is good idea to communicate our plan to the designers to include keyboard navigation notes in their designs 16:26:56 jjmarin, well, the tricky part 16:26:57 you mean like the new universal access panel that was not accessible due to a lack of keyboard navigation? 16:27:00 ;) 16:27:01 is that we are proposing that 16:27:17 but as you said, it heavily depends on designers or gnome-shell maintainers 16:27:44 but as I said, it was (briefly) discussed on the past 16:27:51 so I guess that as far as we provide the patches 16:27:53 I wonder if there are "official" guidelines about keyboard navigation, e.g., from Apple's user interface guidelines. 16:27:56 nobody will complain 16:28:19 clown, I think that there was a guideline on gnome 16:28:29 but was basically, "key navigation is good, have it" 16:28:37 not really a guideline in any case 16:28:42 it went slightly beyond that actually 16:28:44 right. But GUIs are, what, 30+ years old. 16:29:06 Someone must have thought about this and come up witth something more definitive. 16:29:17 I just don't know who or where. 16:29:37 Other than the obvious: Apple. 16:30:22 clown, well, we could mention on the proposal 16:30:34 that we would investigate previous bibliography about that 16:30:46 designers like to have a lot of "how is done in other places" and so on 16:31:19 * clown nods 16:32:24 ok, so as nobody said "that idea sucks" I would assume that everybody thinks that it is worth to propose 16:32:31 :) 16:32:46 #action API will send a feature proposal email to d-d-l, ideally before feature proposal period ends 16:32:57 so next subtopic on 3.12 ... 16:33:00 * API looking notes 16:33:09 ah, our beloved magnifier 16:33:14 hmm, magdalen is not here 16:33:16 in any case 16:33:40 #info Magnifier plans for 3.12 16:33:43 yes, we want to complete the GUI for the new tracking preferences for 3.12, right? 16:33:47 #info a.) Tinting 16:33:53 clown, yes, that is b) ;) 16:34:05 okay (*keeps quiet*) 16:34:42 #info clown already mentioned that he is busy, so if he is not against, API volunteer to take over the task to move forward tinting 16:35:10 fine with me, API. The code is already there, I believe. 16:35:12 #info as in the case of the tracking, as far as I know, this is also about providing a configuration GUI 16:35:19 * clown tries to remember. 16:35:35 #info taking into account clown comments, API will also check that the code is still there 16:35:45 Tintin fans ! :P 16:36:00 * clown groans 16:36:15 #info b.) Tracking preferences GUI 16:36:28 #info in the past, we proposed this kind of things as a new feature 16:36:45 #info now, API thinks that this is too much hassle 16:36:59 #info because after all the functionality is there, and is about providing a GUI 16:37:30 #info and that we should just provide the GUI, and then on the release notes mention that now users has a easy way to do the same that was able to do using terminal 16:37:48 so, nobody against not proposing this as a new feature? 16:37:49 * joanie nods 16:37:55 bad timing 16:38:03 I was nodding that I agree with your statements 16:38:53 :) 16:39:13 I would like to optimize some of the actual tracking code: turn off atspi registration when no tracking is desired. 16:39:21 I love features, I can't be against :-) 16:39:48 That strikes me as a relatively easy fix — responding to when the "none" setting is set. 16:40:00 clown, well, there was some changes on the code 16:40:08 I think that now if the magnifier is not active 16:40:14 atspi is not used at all 16:40:22 although it is true that they make a big change 16:40:31 as is all the magnifier stuff the one not initialized 16:40:32 yes, but once it is active, the tracker is engaged even if it isn't used. 16:40:39 true 16:40:47 in any case, that is bugfixing ;) 16:40:49 that should be fixed. 16:40:51 sure. 16:40:52 having said so 16:41:13 #info people seems to agree, so the tracking preference GUI would be tracked as bugfixing, and ideally it would be solved for 3.12 16:41:29 #action API will contact magdalen, as she is not at the meeting right now 16:41:54 so, anything else about the magnifier before moving to next subtopic? 16:42:00 not from me. 16:42:46 ok, moving then 16:43:39 #info API additions, deprecations, and changes 16:44:08 #info during the end of the previous cycle there was several API deprecations 16:44:26 #info Tinting feature page: https://wiki.gnome.org/ThreePointEleven/Features/TintEnhancement 16:44:26 #info like several AtkText methods and specially focus methods 16:45:07 #info Company already asked about how to proceed with gtk3 16:45:17 #info joanie made recently a good point in relation with gtk2 16:45:24 about that, probably a discussion is worthy 16:45:34 gtk2 is in maintenance mode 16:45:40 and as joanie pointed 16:45:51 there will be several gtk2 applications 16:46:12 maintencane mode basically means that they will not made deep changes there 16:46:30 so all the focus crap and old gtk_text methods will be there 16:46:53 s/gtk_text/atk_text 16:47:07 right now on at_spi there are some code in order to support the new and the old atk_text API 16:47:30 the initial idea was having a temporal fallback 16:47:40 but taking into account that gtk2 will be around for long 16:47:55 probably "temporal" will be upgraded 16:48:03 mgorse, is that ok with you? 16:48:25 for me the need of maintaining old API and new API seems a hassle 16:48:46 Yeah. I don't see how we could immediately delete it, anyway. Probably something like acrobat would stop working, too (although maybe it has already for all that I know) 16:48:55 acrobat isn't accessible 16:48:58 hasn't been for years 16:49:06 ok 16:49:26 and evince is accessible now 16:50:04 anyhoo, I think at some point we need to stop maintaining the old API 16:50:07 question is when 16:50:19 and/or if they can make the changes in gtk+2 16:50:29 well, when I said "upgrade temporal" I was not saying "upgrade to forever" 16:50:33 :) 16:50:46 but what I mean is that initially I was thinking on maintaining the old API for 3.12 only 16:50:58 and about gtk+2 16:51:13 that is also related with the focus crap 16:51:25 likely removing the focus crap on gtk3 16:51:31 will lead to some behaviour changes 16:51:40 in the sense of the timing of the event emission 16:51:46 * clown feels sorry for focus being referred as crap. 16:51:49 or "something" 16:51:59 hmm, yes bad wording 16:52:13 what I meant is that there was a lot of methods related to focus 16:52:16 my fault 16:52:23 I say "crap" a lot 16:52:29 that we decided that makes things more complex and are not useful 16:52:33 and should remove 16:52:39 that is the crap 16:52:49 focus events will be still emitted 16:52:56 but just state-change:focused 16:53:20 so when Im refering crap to the deprecated stuff 16:53:23 in any way 16:53:24 as I was saying 16:53:43 I foresee that likely gtk2 and gtk3 could behave slightly different 16:53:54 maybe this is too detailed for this meeting, but what is the difference between focus and state-changed:focus? 16:53:55 they already do 16:53:59 joanie, do you have a gtk2 script and a gtk3 script? 16:54:03 no 16:54:06 clown, that was the problem 16:54:09 I might have to create one 16:54:09 was basically the same 16:54:16 so we decided to keep just one 16:54:21 API but benjamin redid a11y completely 16:54:25 and the winner was state-change:focused 16:54:34 isn't state-changed:focus confined to the a11y layer (AT-SPI or ATK or both)? 16:54:45 and so gtk+ 2 and gtk+ 3 have certainly diverged already 16:54:58 but focus is what gtk emits? 16:55:16 Im getting lost, lets try to have one conversation at the same time 16:55:28 I will start with joanie 16:55:33 right 16:55:45 joanie, ok, so that means that gtk2 is already different to gtk3 16:55:53 in that sense that makes that a lesser problem 16:55:58 a problem in any way 16:56:13 so we'll try to not forget that 16:56:16 and about 16:56:17 and/or if they can make the changes in gtk+2 16:56:32 #action API will ping Company in order to know how much can be done on gtk+2 16:56:41 joanie, anything else? 16:56:43 thank you API 16:56:45 not from me 16:56:51 clown, now you 16:56:56 but focus is what gtk emits? 16:57:01 well, on the widgets 16:57:07 when a widget get the focus 16:57:15 right now 16:57:22 the same object 16:57:31 emits state-changed:focused 16:57:32 event 16:57:41 (and the previous focused one, but the lost) 16:57:45 and at the same time 16:57:53 it is needed to emit the event "focus" 16:58:18 at the end of 3.10, we deprecated the signal "focus" 16:58:26 because we already have state-changed:focused 16:58:41 we also deprecated some other focus-related methods, that we conclude that were not needed 16:58:45 for example 16:58:51 is what I did on clutter 16:58:59 clutter only emits state-changed:focused 16:59:05 it doesn¡t use the focus trackers 16:59:11 or the "focus" signal 16:59:17 and it seems to be working 16:59:31 so we would like to do the same of gtk 16:59:43 the main issue is that there are *ton* of code using the deprecated methods 16:59:50 so likely we will have regressions 17:00:17 clown, is now the situation clear? morequestions, doubtS? 17:00:36 API That helps but 17:00:51 I can think of one case where the two events (focus and state-changed:focus) might not be in sync. I'm not sure though. 17:01:08 the case is an active descendant scenario. 17:01:51 where "focus" is maintained on a container, and "state-chaend:focused" events are fired as the active descendant is updated. 17:01:56 the parent object claims focus (via object:state-changed:focused). The selected child / active descendant have their own events 17:02:01 emitted by the parent object 17:02:12 clown, yes, as joanie is saying 17:02:15 we are solving that case 17:02:22 by maintaining the focus on the container 17:02:27 but changing the selection on the child 17:02:28 it's already solved afaik 17:02:33 for example 17:02:36 on the alt+tab switcher 17:02:45 or on the search result on gnome-shell 17:03:02 when you start to write on the overview, a list of apps appear, and you start to move 17:03:23 ie, on the alt+tab switcher 17:03:27 each time you press tab 17:03:34 you don't get a state-changed:focus event 17:03:41 but a state-changed:selection one 17:03:56 (so that is one of the reasons the magnifier tracker connects to both) 17:04:07 Right. Hmmmm.... 17:04:30 what about mulit-selection containers? Where you want to move focus without changing the selection? 17:04:45 given that we're 4 minutes over, should we table this discussion? 17:04:47 *multi-selection 17:04:53 sure. 17:05:09 as I said, this might be too specific a question for this meeting. 17:05:27 ok 17:05:41 so just to finish 3.12 17:05:47 #info it would be good to also add new API 17:06:06 #info example: collection at ATK, improvements on AtkDocument (related to FoG) etc 17:06:43 #action joanie already volunteered to review current bugs about API additions and create new ones, with 3.12 target in mind 17:06:47 ;) 17:06:52 :) 17:06:55 sooo 17:07:09 questions, doubts, comments on this (long) 3.12 topic? 17:08:06 as we are over time, you need to be quick when I ask you stuff 17:08:09 because if not 17:08:10 moving 17:08:11 ;) 17:08:12 move on 17:08:17 * clown nods 17:08:20 #topic W3C updates 17:08:25 joanie, clown ? 17:08:35 #info First public draft of ARIA 1.1 was published. 17:08:46 #info Announcment here: http://lists.w3.org/Archives/Public/public-pfwg/2013Sep/0073.html 17:09:09 #info Differences from 1.0 here: http://www.w3.org/WAI/PF/aria-1.1/appendices#changelog 17:09:11 (done) 17:09:20 I have nothing 17:09:21 move on 17:09:22 ;) 17:09:31 * joanie notes that we're late for our next meeting 17:10:30 i'll ai myself though 17:10:50 #action Joanie will review the first public draft of ARIA 1.1 with specific attention to our current API. 17:10:53 done 17:11:07 ok 17:11:10 #topic Marketing 17:11:12 jjmarin, ? 17:11:33 #info Juanjo helped in the release notes. The notes about the focus and caret tracking feature were finally included 17:11:59 questions, doubts, comments on this (short) 3.10 topic? 17:12:42 jjmarin, also evince improvements? 17:13:28 Well, what I meant is that the caret and focus tracking notes were dropped and then again included 17:13:43 ah 17:13:58 curious about the dropped thing, but not a lot as was included 17:14:02 evince improvements didn't have that last minute problem 17:14:08 ok 17:14:10 so 17:14:14 jjmarin, thanks for the work 17:14:24 and good work, as everyithing important got included 17:14:25 np :-) 17:14:34 and as over time is still true 17:14:53 I will close the meeting 17:15:09 sorry, no misc time today 17:15:23 #endmeeting