1 16:01:24 <API> #startmeeting
   2 16:01:24 <tota11y> Meeting started Thu Oct  3 16:01:24 2013 CET.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
   3 16:01:24 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
   4 16:01:41 <API> #topic on 5 min margin
   5 16:02:02 <joanie> heh
   6 16:04:31 * clown waves
   7 16:05:11 <API> 5 minutes now
   8 16:05:14 <API> so lets start
   9 16:05:22 <API> and move to a real topoc
  10 16:05:25 <API> *topic
  11 16:05:39 <API> #topic "Boston" Summit
  12 16:06:18 <API> #info Alejandro Piñeiro bought their flight tickets, foundation confirmed that will support him, so he will be at montreal
  13 16:06:38 <mgorse> #info mgorse bought a ticket and will be there, too
  14 16:06:40 <API> anyone else want to info to confirm their presence before I continue?
  15 16:06:41 <clown> c'est bon
  16 16:06:48 <joanie> #info Joanie will drive up
  17 16:07:00 <clown> I won't be there.  Should I info that?
  18 16:07:09 <jjmarin> #info Juanjo won't attend
  19 16:07:32 <clown> #info Joseph won't attend since he will be returning from the jQuery a11y summit.
  20 16:07:46 <API> a jquery a11y summit, interesting
  21 16:07:54 <clown> #info http://www.deque.com/deque-partners-jquery-create-accessibility-summit
  22 16:07:56 <API> anyway a pity you not being there
  23 16:08:20 <API> in any case, I will retake the scepter
  24 16:08:32 <API> about proposals of what to do there
  25 16:08:33 <clown> well, the gnome summit always falls on thanksgiving, which makes it difficult for me.
  26 16:09:01 <API> #info IMHO, the main topic will be wayland
  27 16:09:41 <API> #info For that it would be good to do some pre-summit homework
  28 16:10:06 <API> #info basic stuff, like compiling all the stuff using current documentation, and trying at-spi2, orca etc
  29 16:10:19 <API> #info joanie wrote a pretty wiki page with all that stuff:
  30 16:10:24 <API> https://wiki.gnome.org/Accessibility/Hackfests/Montreal2013
  31 16:10:59 <API> #info So as an outcome of that homework, some of the stuff to discuss there could be:
  32 16:11:12 <API> #info a. Comment about the tests outcome
  33 16:11:26 <API> #info b. Identify features needed for X and Wayland
  34 16:11:53 <API> #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)
  35 16:12:22 <API> #info The second main topic would be discuss about making at-spi2 API more async
  36 16:12:32 <API> #info a. Can we start looking now at what API changes (if any) are needed?
  37 16:12:43 <API> #info b. Think about how such a change would affect the idea of merge atspi/ATK
  38 16:12:49 <API> (done)
  39 16:13:04 <API> I think that this is enough taking into account that is not a real a11y hackfest
  40 16:13:15 <API> and that probably we would be sucked with other conversations around
  41 16:13:42 <API> in fact next topic on today meeting is 3.12 stuff, so probably we will also discuss some of that
  42 16:13:46 <API> in any case
  43 16:13:53 <mgorse> yeah, makes sense
  44 16:13:53 <API> opinions about my suggestions?
  45 16:14:15 <joanie> your suggestions make sense to me API
  46 16:15:15 <jjmarin> sounds like a plan
  47 16:15:18 <jjmarin> :)
  48 16:15:24 <clown> sounds like a good plan.
  49 16:16:11 <API> in any case, as there are not a lot of people here
  50 16:16:21 <API> and as others like Company
  51 16:16:32 <API> are also subscribed to gnome-accessibility-devel
  52 16:16:35 <API> I will send a email
  53 16:17:01 <API> #action API will send a email to the -devel ml in relation with the informal agenda for the "Boston" Summit
  54 16:17:31 <API> and taking into account that everybody is agreeing on what to do during this week (aka homework) and on summit
  55 16:17:35 <API> moving to next topic?
  56 16:17:42 * joanie nods
  57 16:17:43 <clown> +1
  58 16:18:42 <API> #topic GNOME 3.12 Planning
  59 16:19:30 <API> #info Obviously two of main topic for 3.12 are the already mentioned Wayland + asynchrony on at-spi2
  60 16:19:35 <API> #info but there are others
  61 16:19:52 <API> #info we are right now on feature proposal period.
  62 16:20:10 <API> #info After thinking a little, and talking with joanie we came with an idea:
  63 16:20:21 <API> #info "Make keyboard navigation consistent across our entire platform"
  64 16:20:49 <API> #info Rationale: gtk and gnome-shell focus is slightly different
  65 16:21:02 <API> #info s/focus/focus navigation
  66 16:21:23 <API> #info For example, on gnome-shell, on most cases TAB is the same that Left-Arrow, except that adds also cycle
  67 16:21:47 <API> #info but on gtk, TAB is used to "jump" across containers
  68 16:22:07 <API> #info using TAB on gnome-shell to move from one container to other was already mentioned in tha past
  69 16:22:14 * clown notes that gtk appears to follow the aria best practices.
  70 16:22:19 <API> #info but it would be good to try to have a plan
  71 16:22:51 <API> #info in the same way, during the last weeks of this cycle, we found some key navigation issues/inconsistencies on gtk
  72 16:23:08 <API> #info mostly on new widgets, so it would be good a review of the platform
  73 16:23:42 <API> and that would be the idea
  74 16:23:47 <API> opinions, suggestions?
  75 16:24:59 <clown> #info ARIA authoring practices recommends using TAB/SHIFT-TAB to move between containers, and arrows to move within a container.
  76 16:25:27 <clown> #info the main reason is to avoid seemingly endless TABing to acquire a widget.
  77 16:25:59 <clown> #info So:  TAB is for navigating larger parts of the interface.
  78 16:26:01 <clown> (done)
  79 16:26:27 <jjmarin> I think it is good idea to communicate our plan to the designers to include keyboard navigation notes in their designs
  80 16:26:56 <API> jjmarin, well, the tricky part
  81 16:26:57 <joanie> you mean like the new universal access panel that was not accessible due to a lack of keyboard navigation?
  82 16:27:00 <joanie> ;)
  83 16:27:01 <API> is that we are proposing that
  84 16:27:17 <API> but as you said, it heavily depends on designers or gnome-shell maintainers
  85 16:27:44 <API> but as I said, it was (briefly) discussed on the past
  86 16:27:51 <API> so I guess that as far as we provide the patches
  87 16:27:53 <clown> I wonder if there are "official" guidelines about keyboard navigation, e.g., from Apple's user interface guidelines.
  88 16:27:56 <API> nobody will complain
  89 16:28:19 <API> clown, I think that there was a guideline on gnome
  90 16:28:29 <API> but was basically, "key navigation is good, have it"
  91 16:28:37 <API> not really a guideline in any case
  92 16:28:42 <joanie> it went slightly beyond that actually
  93 16:28:44 <clown> right.  But GUIs are, what, 30+ years old.
  94 16:29:06 <clown> Someone must have thought about this and come up witth something more definitive.
  95 16:29:17 <clown> I just don't know who or where.
  96 16:29:37 <clown> Other than the obvious:  Apple.
  97 16:30:22 <API> clown, well, we could mention on the proposal
  98 16:30:34 <API> that we would investigate previous bibliography about that
  99 16:30:46 <API> designers like to have a lot of "how is done in other places" and so on
 100 16:31:19 * clown nods
 101 16:32:24 <API> ok, so as nobody said "that idea sucks" I would assume that everybody thinks that it is worth to propose
 102 16:32:31 <joanie> :)
 103 16:32:46 <API> #action API will send a feature proposal email to d-d-l, ideally before feature proposal period ends
 104 16:32:57 <API> so next subtopic on 3.12 ...
 105 16:33:00 * API looking notes
 106 16:33:09 <API> ah, our beloved magnifier
 107 16:33:14 <API> hmm, magdalen is not here
 108 16:33:16 <API> in any case
 109 16:33:40 <API> #info Magnifier plans for 3.12
 110 16:33:43 <clown> yes, we want to complete the GUI for the new tracking preferences for 3.12, right?
 111 16:33:47 <API> #info a.) Tinting
 112 16:33:53 <API> clown, yes, that is b) ;)
 113 16:34:05 <clown> okay (*keeps quiet*)
 114 16:34:42 <API> #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
 115 16:35:10 <clown> fine with me, API.  The code is already there, I believe.
 116 16:35:12 <API> #info as in the case of the tracking, as far as I know, this is also about providing a configuration GUI
 117 16:35:19 * clown tries to remember.
 118 16:35:35 <API> #info taking into account clown comments, API will also check that the code is still there
 119 16:35:45 <jjmarin> Tintin fans ! :P
 120 16:36:00 * clown groans
 121 16:36:15 <API> #info b.) Tracking preferences GUI
 122 16:36:28 <API> #info in the past, we proposed this kind of things as a new feature
 123 16:36:45 <API> #info now, API thinks that this is too much hassle
 124 16:36:59 <API> #info because after all the functionality is there, and is about providing a GUI
 125 16:37:30 <API> #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
 126 16:37:48 <API> so, nobody against not proposing this as a new feature?
 127 16:37:49 * joanie nods
 128 16:37:55 <joanie> bad timing
 129 16:38:03 <joanie> I was nodding that I agree with your statements
 130 16:38:53 <jjmarin> :)
 131 16:39:13 <clown> I would like to optimize some of the actual tracking code:  turn off atspi registration when no tracking is desired.
 132 16:39:21 <jjmarin> I love features, I can't be against :-)
 133 16:39:48 <clown> That strikes me as a relatively easy fix — responding to when the "none" setting is set.
 134 16:40:00 <API> clown, well, there was some changes on the code
 135 16:40:08 <API> I think that now if the magnifier is not active
 136 16:40:14 <API> atspi is not used at all
 137 16:40:22 <API> although it is true that they make a big change
 138 16:40:31 <API> as is all the magnifier stuff the one not initialized
 139 16:40:32 <clown> yes, but once it is active, the tracker is engaged even if it isn't used.
 140 16:40:39 <API> true
 141 16:40:47 <API> in any case, that is bugfixing ;)
 142 16:40:49 <clown> that should be fixed.
 143 16:40:51 <clown> sure.
 144 16:40:52 <API> having said so
 145 16:41:13 <API> #info people seems to agree, so the tracking preference GUI would be tracked as bugfixing, and ideally it would be solved for 3.12
 146 16:41:29 <API> #action API will contact magdalen, as she is not at the meeting right now
 147 16:41:54 <API> so, anything else about the magnifier before moving to next subtopic?
 148 16:42:00 <clown> not from me.
 149 16:42:46 <API> ok, moving then
 150 16:43:39 <API> #info API additions, deprecations, and changes
 151 16:44:08 <API> #info during the end of the previous cycle there was several API deprecations
 152 16:44:26 <clown> #info Tinting feature page:  https://wiki.gnome.org/ThreePointEleven/Features/TintEnhancement
 153 16:44:26 <API> #info like several AtkText methods and specially focus methods
 154 16:45:07 <API> #info Company already asked about how to proceed with gtk3
 155 16:45:17 <API> #info joanie made recently a good point in relation with gtk2
 156 16:45:24 <API> about that, probably a discussion is worthy
 157 16:45:34 <API> gtk2 is in maintenance mode
 158 16:45:40 <API> and as joanie pointed
 159 16:45:51 <API> there will be several gtk2 applications
 160 16:46:12 <API> maintencane mode basically means that they will not made deep changes there
 161 16:46:30 <API> so all the focus crap and old gtk_text methods will be there
 162 16:46:53 <API> s/gtk_text/atk_text
 163 16:47:07 <API> right now on at_spi there are some code in order to support the new and the old atk_text API
 164 16:47:30 <API> the initial idea was having a temporal fallback
 165 16:47:40 <API> but taking into account that gtk2 will be around for long
 166 16:47:55 <API> probably "temporal" will be upgraded
 167 16:48:03 <API> mgorse, is that ok with you?
 168 16:48:25 <API> for me the need of maintaining old API and new API seems a hassle
 169 16:48:46 <mgorse> 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)
 170 16:48:55 <joanie> acrobat isn't accessible
 171 16:48:58 <joanie> hasn't been for years
 172 16:49:06 <mgorse> ok
 173 16:49:26 <joanie> and evince is accessible now
 174 16:50:04 <joanie> anyhoo, I think at some point we need to stop maintaining the old API
 175 16:50:07 <joanie> question is when
 176 16:50:19 <joanie> and/or if they can make the changes in gtk+2
 177 16:50:29 <API> well, when I said "upgrade temporal" I was not saying "upgrade to forever"
 178 16:50:33 <joanie> :)
 179 16:50:46 <API> but what I mean is that initially I was thinking on maintaining the old API for 3.12 only
 180 16:50:58 <API> and about gtk+2
 181 16:51:13 <API> that is also related with the focus crap
 182 16:51:25 <API> likely removing the focus crap on gtk3
 183 16:51:31 <API> will lead to some behaviour changes
 184 16:51:40 <API> in the sense of the timing of the event emission
 185 16:51:46 * clown feels sorry for focus being referred as crap.
 186 16:51:49 <API> or "something"
 187 16:51:59 <API> hmm, yes bad wording
 188 16:52:13 <API> what I meant is that there was a lot of methods related to focus
 189 16:52:16 <joanie> my fault
 190 16:52:23 <joanie> I say "crap" a lot
 191 16:52:29 <API> that we decided that makes things more complex and are not useful
 192 16:52:33 <API> and should remove
 193 16:52:39 <API> that is the crap
 194 16:52:49 <API> focus events will be still emitted
 195 16:52:56 <API> but just state-change:focused
 196 16:53:20 <API> so when Im refering crap to the deprecated stuff
 197 16:53:23 <API> in any way
 198 16:53:24 <API> as I was saying
 199 16:53:43 <API> I foresee that likely gtk2 and gtk3 could behave slightly different
 200 16:53:54 <clown> maybe this is too detailed for this meeting, but what is the difference between focus and state-changed:focus?
 201 16:53:55 <joanie> they already do
 202 16:53:59 <API> joanie, do you have a gtk2 script and a gtk3 script?
 203 16:54:03 <joanie> no
 204 16:54:06 <API> clown, that was the problem
 205 16:54:09 <joanie> I might have to create one
 206 16:54:09 <API> was basically the same
 207 16:54:16 <API> so we decided to keep just one
 208 16:54:21 <joanie> API but benjamin redid a11y completely
 209 16:54:25 <API> and the winner was state-change:focused
 210 16:54:34 <clown> isn't state-changed:focus confined to the a11y layer (AT-SPI or ATK or both)?
 211 16:54:45 <joanie> and so gtk+ 2 and gtk+ 3 have certainly diverged already
 212 16:54:58 <clown> but focus is what gtk emits?
 213 16:55:16 <API> Im getting lost, lets try to have one conversation at the same time
 214 16:55:28 <API> I will start with joanie
 215 16:55:33 <clown> right
 216 16:55:45 <API> joanie, ok, so that means that gtk2 is already different to gtk3
 217 16:55:53 <API> in that sense that makes that a lesser problem
 218 16:55:58 <API> a problem in any way
 219 16:56:13 <API> so we'll try to not forget that
 220 16:56:16 <API> and about
 221 16:56:17 <API> <joanie> and/or if they can make the changes in gtk+2
 222 16:56:32 <API> #action API will ping Company in order to know how much can be done on gtk+2
 223 16:56:41 <API> joanie, anything else?
 224 16:56:43 <joanie> thank you API
 225 16:56:45 <joanie> not from me
 226 16:56:51 <API> clown, now you
 227 16:56:56 <API> <clown> but focus is what gtk emits?
 228 16:57:01 <API> well, on the widgets
 229 16:57:07 <API> when a widget get the focus
 230 16:57:15 <API> right now
 231 16:57:22 <API> the same object
 232 16:57:31 <API> emits state-changed:focused
 233 16:57:32 <API> event
 234 16:57:41 <API> (and the previous focused one, but the lost)
 235 16:57:45 <API> and at the same time
 236 16:57:53 <API> it is needed to emit the event "focus"
 237 16:58:18 <API> at the end of 3.10, we deprecated the signal "focus"
 238 16:58:26 <API> because we already have state-changed:focused
 239 16:58:41 <API> we also deprecated some other focus-related methods, that we conclude that were not needed
 240 16:58:45 <API> for example
 241 16:58:51 <API> is what I did on clutter
 242 16:58:59 <API> clutter only emits state-changed:focused
 243 16:59:05 <API> it doesn¡t use the focus trackers
 244 16:59:11 <API> or the "focus" signal
 245 16:59:17 <API> and it seems to be working
 246 16:59:31 <API> so we would like to do the same of gtk
 247 16:59:43 <API> the main issue is that there are *ton* of code using the deprecated methods
 248 16:59:50 <API> so likely we will have regressions
 249 17:00:17 <API> clown, is now the situation clear? morequestions, doubtS?
 250 17:00:36 <clown> API That helps but
 251 17:00:51 <clown> 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.
 252 17:01:08 <clown> the case is an active descendant scenario.
 253 17:01:51 <clown> where "focus" is maintained on a container, and "state-chaend:focused" events are fired as the active descendant is updated.
 254 17:01:56 <joanie> the parent object claims focus (via object:state-changed:focused). The selected child / active descendant have their own events
 255 17:02:01 <joanie> emitted by the parent object
 256 17:02:12 <API> clown, yes, as joanie is saying
 257 17:02:15 <API> we are solving that case
 258 17:02:22 <API> by maintaining the focus on the container
 259 17:02:27 <API> but changing the selection on the child
 260 17:02:28 <joanie> it's already solved afaik
 261 17:02:33 <API> for example
 262 17:02:36 <API> on the alt+tab switcher
 263 17:02:45 <API> or on the search result on gnome-shell
 264 17:03:02 <API> when you start to write on the overview, a list of apps appear, and you start to move
 265 17:03:23 <API> ie, on the alt+tab switcher
 266 17:03:27 <API> each time you press tab
 267 17:03:34 <API> you don't get a state-changed:focus event
 268 17:03:41 <API> but a state-changed:selection one
 269 17:03:56 <API> (so that is one of the reasons the magnifier tracker connects to both)
 270 17:04:07 <clown> Right.  Hmmmm....
 271 17:04:30 <clown> what about mulit-selection containers?  Where you want to move focus without changing the selection?
 272 17:04:45 <joanie> given that we're 4 minutes over, should we table this discussion?
 273 17:04:47 <clown> *multi-selection
 274 17:04:53 <clown> sure.
 275 17:05:09 <clown> as I said, this might be too specific a question for this meeting.
 276 17:05:27 <API> ok
 277 17:05:41 <API> so just to finish 3.12
 278 17:05:47 <API> #info it would be good to also add new API
 279 17:06:06 <API> #info example: collection at ATK, improvements on AtkDocument (related to FoG) etc
 280 17:06:43 <API> #action joanie already volunteered to review current bugs about API additions and create new ones, with 3.12 target in mind
 281 17:06:47 <API> ;)
 282 17:06:52 <joanie> :)
 283 17:06:55 <API> sooo
 284 17:07:09 <API> questions, doubts, comments on this (long) 3.12 topic?
 285 17:08:06 <API> as we are over time, you need to be quick when I ask you stuff
 286 17:08:09 <API> because if not
 287 17:08:10 <API> moving
 288 17:08:11 <API> ;)
 289 17:08:12 <joanie> move on
 290 17:08:17 * clown nods
 291 17:08:20 <API> #topic W3C updates
 292 17:08:25 <API> joanie, clown ?
 293 17:08:35 <clown> #info First public draft of ARIA 1.1 was published.
 294 17:08:46 <clown> #info Announcment here:  http://lists.w3.org/Archives/Public/public-pfwg/2013Sep/0073.html
 295 17:09:09 <clown> #info Differences from 1.0 here:  http://www.w3.org/WAI/PF/aria-1.1/appendices#changelog
 296 17:09:11 <clown> (done)
 297 17:09:20 <joanie> I have nothing
 298 17:09:21 <joanie> move on
 299 17:09:22 <joanie> ;)
 300 17:09:31 * joanie notes that we're late for our next meeting
 301 17:10:30 <joanie> i'll ai myself though
 302 17:10:50 <joanie> #action Joanie will review the first public draft of ARIA 1.1 with specific attention to our current API.
 303 17:10:53 <joanie> done
 304 17:11:07 <API> ok
 305 17:11:10 <API> #topic Marketing
 306 17:11:12 <API> jjmarin, ?
 307 17:11:33 <jjmarin> #info Juanjo helped in the release notes. The notes about the focus and caret tracking feature were finally included
 308 17:11:59 <jjmarin> questions, doubts, comments on this (short) 3.10 topic?
 309 17:12:42 <API> jjmarin, also evince improvements?
 310 17:13:28 <jjmarin> Well, what I meant is that the caret and focus tracking notes were dropped and then again included
 311 17:13:43 <API> ah
 312 17:13:58 <API> curious about the dropped thing, but not a lot as was included
 313 17:14:02 <jjmarin> evince improvements didn't have that last minute problem
 314 17:14:08 <API> ok
 315 17:14:10 <API> so
 316 17:14:14 <API> jjmarin, thanks for the work
 317 17:14:24 <API> and good work, as everyithing important got included
 318 17:14:25 <jjmarin> np :-)
 319 17:14:34 <API> and as over time is still true
 320 17:14:53 <API> I will close the meeting
 321 17:15:09 <API> sorry, no misc time today
 322 17:15:23 <API> #endmeeting