16:00:35 <API> #startmeeting
16:00:35 <tota11y> Meeting started Thu Jan  9 16:00:35 2014 CET.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:35 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:36 <joanie> oops
16:00:38 <joanie> wait
16:00:49 <API> #topic 5 min waiting
16:00:50 <joanie> our topic is borked
16:01:00 * joanie sighs
16:01:05 <API> yes I realize, it took again the topic from last meeting
16:01:17 <joanie> I'll fix it after
16:03:33 * clown waves
16:05:00 * API mp3es
16:05:18 * joanie rolls her eyes
16:05:28 <joanie> y'all see what I have to work with? :P
16:05:42 * clown undulates
16:06:48 <API> well, 5 minutes
16:06:56 <API> not a lot of people but I guess that enough
16:07:00 <API> so let's start
16:07:11 <API> #topic Focus-tracking deprecation
16:07:17 * joanie sobs
16:07:24 <joanie> shall I start?
16:07:27 <API> yes please
16:07:29 <joanie> k
16:08:20 <clown> wow...
16:08:27 <joanie> #info After having made all the changes needed in Orca (theoretically), Joanie filed bugs for all the instances where Gtk+ 3 was emitting focus: events, but failing to emit state-changed (or similarly appropriate) events.
16:08:50 <joanie> #info Joanie thought that Benjamin would start addressing these issues.
16:09:03 <joanie> #info Matthias instead started looking into them.
16:09:27 <joanie> #info And rather than just fixing them, he said he wants a spec on how all this should work.
16:09:37 <joanie> #info This spec does not yet exist. :(
16:09:47 <joanie> I'll find a sample bug and discussion shortly btw
16:09:55 <joanie> unless API wants to as I info
16:10:24 <API> I wouldn't be able to do that without interrupting you
16:10:41 <API> so go on, and we can discuss a little after that
16:10:43 <joanie> #info Joanie's concern is that if we (implementors) start moving forward with the removal of focus tracking without the appropriate fixes for the above issues, BadThings(tm) will happen.
16:11:03 <clown> probably a good intuition
16:11:23 <joanie> #info Joanie feels the work she did in Orca was worth doing, not just in preparation for this deprecation, but also in terms of associated code clean-up and performance improvements.
16:11:52 <joanie> #info Joanie thinks that we might want to stop (at least in Gtk+) the deprecation for the 3.12 cycle.
16:11:55 <joanie> (done)
16:11:59 * joanie looks for bug
16:12:35 <joanie> (still searching)
16:12:35 <joanie> sorry
16:12:42 <API> well, yes probably that's the best conservative solution
16:12:44 <clown> no problem.
16:12:52 <joanie> this is why I asked api to find it ;)
16:13:12 <API> ah, you asked me to find it but not to write down here
16:13:12 <API> sorry
16:13:16 <API> I misunderstood
16:13:18 <clown> so, why is the focus *tracking* deprecation?  And not just focus deprecation?
16:13:27 <clown> oops.
16:13:35 <clown> so, why is this focus *tracking* deprecation?  And not just focus deprecation
16:13:39 <API> well, we deprecated several focus stuff
16:13:45 <API> we deprecated focus tracking
16:13:53 <API> and also the signal focus
16:13:58 <API> as we had state-changed:focused
16:14:11 <clown> so, no more focus tracking in the magnifier?
16:14:16 <joanie> https://bugzilla.gnome.org/show_bug.cgi?id=715176
16:14:16 <tota11y> 04Bug 715176: normal, Normal, ---, gtk-bugs, UNCONFIRMED, object:state-changed:focused event missing when a text widget regains focus after a menu is closed
16:14:18 <joanie> clown: no
16:14:27 <API> no, is not related at all with the magnifier
16:14:27 <joanie> there's this atk focus tracker
16:14:36 <clown> ah, that makes more sense now.
16:14:36 <API> so background:
16:14:39 <API> at the dawn of the time
16:14:40 <clown> I was missing the atk part.
16:14:48 <joanie> clown: sorry
16:14:50 <API> atk people thought that in order to emit properly when an
16:14:53 <clown> so this is focus tracking deprecatin in atk.
16:14:53 <API> focus changed
16:15:01 <API> they added some atk focus tracked API
16:15:07 <API> and current gtk a11y code is based on that
16:15:25 <clown> thanks for the explanation guys.
16:15:30 * clown looks at bug
16:15:30 <API> with the years we learned that usually toolkits have better ways
16:15:39 <API> to know when a focus changes
16:15:47 <API> and even if you want to use tracking stuff
16:15:59 <API> that's the toolkit problem and not atk
16:16:02 <API> so we deprecated it
16:16:05 <API> the only problem
16:16:08 <API> is that as I said
16:16:19 <API> gtk+ focus emission are based on that tracking methods
16:16:35 <API> code that btw, is a total mess and gtk+ developers want to get rid of for ages
16:16:59 <API> but as joanie said, just removing it will likely mean regressions
16:17:11 <API> sooo
16:17:15 <joanie> well that was a given
16:17:28 <API> joanie made a good work stopping to listen to focus events
16:17:31 <joanie> but to solve those regressions, we need state-changed, etc. where that is missing
16:17:46 <joanie> and now matthias is being.... "particular" shall we say?
16:17:49 <API> and the plan was going slowly with bugs on gtk+ before the total atk_focus_tracking removal
16:18:19 <API> but it seems that matthias prefers to have something written
16:18:24 <mgorse> Is there code committed in orca that stops listening to focus events?
16:18:33 <API> (and now re-read joanie #infos, probably now your will understand them better)
16:18:39 <joanie> mgorse: the changes are made
16:19:01 <joanie> we are still listening for focus:
16:19:03 <joanie> in specific cases
16:19:06 * clown thanks API for the explanation.  Make much more sense now.
16:19:07 * joanie looks for an example
16:19:43 <joanie> https://git.gnome.org/browse/orca/tree/src/orca/scripts/toolkits/gtk/script.py#n61
16:19:53 <joanie> so that's for gtk+ 3
16:20:10 <joanie> and if matthias makes no changes
16:20:19 <joanie> Orca should continue to work as expected with Gtk+ 3
16:20:26 <joanie> though more performantly
16:20:33 <API> ah, and btw
16:20:34 <joanie> because of the associated code clean up
16:20:37 <joanie> my fear
16:20:39 <joanie> (one sec api)
16:20:47 * API shutting up
16:20:54 <mgorse> yeah, makes sense--we'd still need to listen to them for gtk 2 anyhow, since I"m guessing that changes might not be made there
16:20:58 <joanie> is that he's going to *not* fix the bugs I've filed (and cited in the code sample)
16:21:01 <joanie> but
16:21:11 <joanie> he is still going to remove the focus-tracker atk code from gtk+
16:21:33 <joanie> and if he does those that without fixing the bugs, Orca's going to be badly broken by it
16:21:37 <joanie> :(
16:21:38 <joanie> done
16:21:49 <clown> uggh.
16:22:12 <API> fwiw, what I was about to say is exactly what mgorse said
16:22:42 <API> for gtk+2 orca will still listen the deprecated events, at least thats current plan
16:22:44 <joanie> well, Benjamin had told me that he might be able to backport the proper events to gtk+ 2
16:22:51 <joanie> if it were not a major change
16:22:56 <mgorse> oh ok
16:22:58 <joanie> e.g. instead of emitting "focus:"
16:23:05 <joanie> emit "object:state-changed:focused"
16:23:09 <joanie> not sure if that can be done
16:23:20 <joanie> anyhoo, now benjamin seems to not be actively working on a11y
16:23:26 <joanie> and matthias has jumped in
16:23:28 <API> probably yes, but lets Benjamin decide that
16:23:32 <API> (or matthias)
16:23:36 <joanie> of course
16:23:49 <API> in any case
16:23:53 <joanie> but my point is, it's not necessarily a given that orca will have to listen to those for gtk+ 2
16:23:58 <joanie> s/those/focus:/
16:24:06 <API> I agree with not doing the deprecation for 3.12
16:24:11 <joanie> yay!
16:24:18 <API> but probably we should prepare about it
16:24:20 <API> for example
16:24:31 <API> writing "something" similar to the spec that
16:24:34 <API> matthias is waiting
16:24:42 <joanie> I think the ball is in his court
16:25:03 <joanie> https://bugzilla.gnome.org/show_bug.cgi?id=715176#c7
16:25:03 <tota11y> 04Bug 715176: normal, Normal, ---, gtk-bugs, UNCONFIRMED, object:state-changed:focused event missing when a text widget regains focus after a menu is closed
16:25:18 <API> oh yes, he could answer that
16:25:28 <API> but in any case, I think that it would be good to have something written
16:25:34 <joanie> not sure if he's not because he's busy or just doesn't like my answer
16:25:44 <API> after all, gtk+ is not the only implementor
16:25:44 <joanie> or because he expects me to write the gtk+ tests
16:25:59 <joanie> API but other implementors don't give me grief like this ;)
16:26:16 <API> other immplementors just don't do anything anymore :P
16:26:24 <joanie> because as I stated earlier on in that bug
16:26:32 <joanie> we do have docs
16:26:54 <joanie> see my comment #5
16:27:04 <joanie> anyhoo....
16:27:05 <joanie> rant over
16:27:10 <joanie> conclusions/next steps?
16:27:56 <API> btw, the other day
16:28:05 <API> you mentioned that benjamin patch was not working
16:28:11 <joanie> it didn't compile
16:28:11 <API> is that confirmed?
16:28:25 <joanie> and I was too frustrated by the matthias situation
16:28:28 <API> so obviously it will not work
16:28:32 <joanie> :)
16:28:37 <API> well, probably needs an update, or something
16:28:41 <joanie> it might be something simple/dumb
16:28:45 <joanie> but I didn't look
16:28:48 <API> and eventually, as I mentioned (not remember where)
16:28:59 <API> we would need to test orca against that patch, but not in master
16:29:03 <API> so what about this:
16:29:16 <API> 1. ask benjamin to update that patch
16:29:30 <API> 2. mention that it would be good to have it on a wip/focus-something branch
16:29:38 <API> 2.1 so we could test orca agains it
16:29:39 <joanie> orca master can be easily tested with a one line change
16:29:50 <joanie> i.e. I don't feel the need for an orca branch
16:29:57 <API> 3. mention how we could report bugs
16:31:05 <API> that makes sense?
16:31:20 <joanie> I think so
16:31:41 <joanie> as long as it is clear that we don't think it should be committed for 3.12 unless all the issues are resolved
16:31:53 <joanie> and that brings us back to "we need a spec"
16:32:32 <API> well, if matthias think that documentation is not enough, we could use some of th econclusions
16:32:38 <API> of the bug to add something else
16:32:41 <API> in any case
16:33:31 <API> #action API will send a email to Matthias+Benjamin about the focus-deprecation not happening on 3.12, and about having a experimental branch with the wip
16:33:35 <API> having said so
16:33:40 <API> anything else in this topic?
16:33:42 <magpie> sorry i'm late
16:34:07 <joanie> I think I'm set
16:34:12 <joanie> and thanks for taking the action item
16:34:18 <magpie> what's the focus depreciation mean for focus tracking ?
16:34:25 <API> ok, then I will move to next topic
16:34:29 <magpie> deprecation
16:34:38 <API> magpie *atk* focus tracking deprecatin
16:34:53 <API> not related at all with magnifier focus tracking
16:35:01 <magpie> ah in favour of atspi?
16:35:14 <magpie> ok
16:35:15 <API> no, in favour of nothing
16:35:21 * joanie sighs
16:35:26 <API> but as I said
16:35:29 <API> moving to next topic
16:35:36 <API> as we are already past half meeting
16:35:44 <API> #topic Wayland
16:35:48 <magpie> ok
16:35:58 <API> joanie, do you want to start or should I?
16:36:05 <joanie> API go for it
16:36:08 <API> ok
16:36:22 <API> #info We had some extra discussion on the wayland list
16:36:42 <API> #info at the end also some people from input methods related (like maliit) joined
16:37:10 <API> #info somehow, the needs of at-spi2 and input methods (and screen on keyboard) are similar
16:37:25 <API> #info for some input method stuff, some extensions were created and working
16:37:45 <API> #info the main concern right now is about security, as at-spi2 can be used by anyone
16:38:12 <API> #info and one of the design ideas of wayland was not let "anybody" to manage input stuff
16:38:31 <magpie> yeah that's set in the accessibility.conf
16:38:55 <API> #info matthias even proposed screen reader (orca) being launched by the compositor (gnome-shell)
16:39:26 <API> #info I replied that that's is not really practical, and if the main accessibility provider can't be considered as a trusted service, then we have a problem
16:39:48 <API> #info the thread stopped, basically due christmas
16:40:04 <API> so done my report about what happened on the mailing list
16:40:12 <API> so about the at-spi2 and being trusted
16:40:15 <API> as far as I know
16:40:22 <clown> API, what does it mean to be a "main accessibilty provider"?  Who is the main a11y provider?
16:40:31 <clown> or what...
16:40:32 <API> clown, at-spi2
16:40:38 <clown> ah, okay.
16:40:49 <API> after all, orca "asks" at-spi2 for the accessibility information
16:40:55 <API> so as I was saying
16:40:57 <API> as far as I know
16:41:04 <API> DBUS has some security features
16:41:17 <API> and in fact, some services
16:41:30 <API> are managed by DBUS (polkit, etc)
16:41:31 <magpie> #info the accessibility.conf file is set to allow anyone to own anything it's a template used by gjs
16:41:34 <API> and ask you to authenticate
16:42:09 <API> so I was wondering if it would be possible to add some of those on at-spi2
16:42:20 <API> so in order to use at-spi2 you would need to authenticate as an user
16:42:28 <API> mgorse, opinion?
16:42:51 <magpie> the dbus-daemon launches with config=accesibility.conf
16:43:28 <mgorse> good question. I'm not sure off-hand, really
16:43:29 <magpie> and it's already using dbus protocol
16:43:47 <API> magpie, but right now
16:43:53 <API> it allows to do everything
16:44:02 <magpie> yes i know
16:44:21 <API> so mgorse
16:44:23 <mgorse> but it seems worth looking into dbus authentication.
16:44:31 <API> yes, I also think so
16:44:31 <mgorse> to see what can be done with it
16:44:36 <API> so what about an action item for me
16:44:43 <API> to reactivate the conversation on the mailing list
16:44:51 <API> and one action item for you to take a look to that?
16:44:52 <magpie> but we could change that because the dbus protocol is used to allow anyone to own anything
16:45:04 <mgorse> yeah
16:45:09 <API> ok
16:45:19 <mgorse> #action mgorse will investigate D-Bus authentication and what can be done with it
16:45:35 <API> #action API, christmas are over, so API will go back to the wayland-dev mailing list
16:45:39 <API> joanie?
16:45:41 <API> anything else?
16:45:48 <joanie> I don't think so
16:45:52 <joanie> as long as we're on top of it
16:46:01 <joanie> otherwise 3.12 may be a real mess a11y-wize
16:46:44 <API> well, afaik, for 3.12 wayland will not be GNOME ready
16:47:07 <joanie> does that mean we're no longer shooting for that as the first official wayland release?
16:47:11 <joanie> we == GNOME
16:47:56 <API> well, is just a personal feeling
16:48:05 <API> about this not being ready yet
16:48:17 <API> but probably it would be good to have a confirmation
16:48:26 <API> we are almost at half-cycle
16:48:27 * clown wonders how clarivoyant API is.
16:48:30 * joanie nods
16:48:41 <mgorse> yeah, I was curious if the release team had had any discussions about it
16:48:56 <magpie> i heard it somewhere too
16:48:59 <magpie> but not sure where
16:50:11 <API> well, yes, probably the release team should meet about it
16:50:18 <API> will try to ping about that later
16:50:35 <API> in any case
16:50:36 <API> moving?
16:50:44 <joanie> I think so
16:51:26 <API> #topic Other progress towards 3.12
16:51:57 <API> #info As a reaction to Alex Surkov mails, API+joanie has been working on an update for Value interface
16:52:00 <API> done
16:52:03 <API> anything else?
16:52:07 <joanie> :)
16:52:10 <magpie> mousetweaks
16:52:30 <clown> API, that was for the new 'meter' element in html5?
16:52:42 <clown> or, that's what inspired the changes?
16:52:55 <API> well, we wanted to change Value
16:52:57 <magpie> #info Magdalen sent out another reminder email to the list but it's not in the archives to link to
16:53:02 <API> or specifically AtkValue for a time
16:53:11 <API> the new 'meter' element added more reasons to do that
16:53:23 <clown> okay, that's what I thought.
16:53:39 <joanie> clown: it applies to desktop toolkit widgets too
16:53:52 <joanie> like gtk level bars
16:53:53 <clown> good point joanie.
16:54:44 <magpie> ok so nobody is interested in mousetweaks anymore ?
16:55:28 <API> I don't see any new mail on the list
16:55:33 <API> to which list you sent that reminder?
16:55:51 <magpie> the development list, it;s not there but i sent it so not sure why
16:56:44 <clown> FWIW, I don't see mousetweaks here:  https://wiki.gnome.org/ThreePointEleven/Features
16:56:47 <magpie> #action Magdalen will double check her sent mail to see whether it actually sent
16:56:58 <API> clown usually features are for new stuff
16:57:11 <API> mousetweaks is about keeping the same functionality
16:57:14 <magpie> clown we are still deciding whether or not to build into the compositor
16:57:15 <clown> ah, I see.
16:57:38 <magpie> my email was to try to figure out what the decision is
16:57:54 <API> well, and that is my point, I thought that this was being handled by anyone else
16:58:07 <API> or gnome-shell developers or original mousetweaks developers
16:58:10 <API> so thanks for the update
16:58:45 <API> having said so, I'm moving to next topic as we are almost on the one-hour deadline
16:58:52 * joanie nods
16:58:56 <API> #topic W3C updates
16:59:00 <API> clown, ?
16:59:30 <clown> #info Progress to publishing the ARIA User Agent Implementation Guide is going according to plan.
16:59:31 <magpie> ok so it's unlikely do be done then I'll email gerd and francesco to clarify
16:59:59 <clown> #info  Jan 17th is the deadline for any major changes, but it doesn't look like anything is going to happen
17:00:27 <magpie> oh cool. thanks for the info
17:00:42 <clown> #info Thereafter the final publication as a proposed recommendation will commence, the document will come our around the end of the month (not sure of the exact date).
17:01:08 <clown> #info In other news, there is an ARIA face-to-face meeting here in Toronto in two weeks.
17:01:14 * clown looks up an url.
17:01:29 <clown> #info http://www.w3.org/WAI/PF/meetings/2014-01-ftf
17:01:37 <clown> done — questions?
17:02:01 <joanie> no questions, but I'll be in Toronto :)
17:02:05 <magpie> I have one
17:02:08 <clown> \o/
17:02:41 <magpie> there's a bug in the accessibility wave testing tool with headers
17:03:00 <magpie> it doesn't pick up <h2> blalbla</h3>
17:03:11 <magpie> would that throw a screen reader?
17:03:26 <magpie> or is it superficial?
17:04:08 <magpie> this one i mean http://wave.webaim.org/
17:04:49 <magpie> if you view source you'll see their heading is broke on line 28
17:05:05 <magpie> but it doesn't fail the test
17:05:09 <clown> magpie did you purposely set up mistmatched h2 and h3 tags?  Is that the problem?
17:06:17 <clown> brb
17:06:35 <magpie> no i just saw they had mismatched  ones and i wondered why it did not fail it's own test or whether that actually mattered. I emailed them and they said it shouldn't affect functionality but I thought i should ask you
17:06:38 <joanie> anyhoo we're 6 minutes past the meeting
17:06:40 * clown is back
17:06:43 <API> and in any case
17:06:57 <API> that is not related at all with w3c, afaik
17:07:03 <joanie> there's that too ;)
17:07:05 <clown> no, not really.
17:07:12 <API> jjmarin is not here
17:07:15 <magpie> API that's the main testing tool
17:07:18 <API> so I will skip marking
17:07:36 <clown> s/marking/marketing/
17:07:56 <API> is a testing tool not developed at all by w3c
17:08:11 <magpie> it's recommended by google among others
17:08:15 <API> so don't matters if it has a bug
17:08:28 <clown> magpie, the main validator tool that is recommended by w3c is: http://validator.w3.org/
17:08:30 <API> clown can't do anything about it
17:08:41 <clown> the webaim one is another that is useful.
17:09:09 <magpie> this is good for accessibility clown? Does it check for the roles and such? I thought it was only 4.1
17:09:12 <magpie> up to
17:09:16 <clown> I bet the w3c validator would scream about mismatched <h2> and </h3>
17:09:58 <clown> Having valid/proper html is a good start towards good accessibility.
17:10:22 <clown> W3C is working on adding functionality for roles and such to their validator.
17:10:24 <magpie> good point! I shall try that out. I just don't know how it might confuse a screenreader
17:10:54 <API> and with that
17:10:58 <clown> well, the screenreader is not looking directly at the html, but at the a11y layer (atspi) that is produced by the browser.
17:11:06 <magpie> makes sense clown, thanks for clarifying.
17:11:10 <API> and taking into account that webaim is not the same that w3c
17:11:13 <clown> no problem.
17:11:17 <API> I clasify this as miscellaneous
17:11:22 <API> and as we are over time
17:11:26 <API> I will close the meeting now
17:11:34 <clown> ;-)
17:11:38 <API> #endmeeting