16:35:25 #startmeeting 16:35:25 hmm, it seems that the bot doesn't work ;) 16:35:25 anyway 16:35:25 #topic Magnification discussion 16:35:25 tota11y: what's up? 16:35:25 #info people at the meeting has a brief discussion about magnification, after API experience on KDE Sprint 16:35:25 #info API suggested a kind of "high level" guide, in order to have a similar experience on every magnifier 16:35:25 #info specifically about focus tracking 16:35:25 Meeting started Thu Oct 4 16:35:25 2012 CET. The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:35:25 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:35:25 clown: Error: "what's" is not a valid command. 16:35:25 clown, although probably that already exist 16:35:25 clown, what are you using to know what do you want to add to the focus tracking at gnome-shell? 16:35:25 just common sense? 16:35:25 comments from users? 16:35:35 API, mostl duplicating what Orca did. Way back when, WIll Walker advised me: "let orca handle the focus tracking. It does what users want." 16:35:51 hey tota11y woke up! 16:36:22 and suddenly 16:36:22 * API shrugs 16:37:11 but afaik, that pyatspi2 is just a subset of what orca did 16:37:12 and, the default focus tracking scenario in Orca was: "push" tracking, completely decoupled from the mouse. 16:37:12 right? 16:37:40 afaik, magFocusTracker.py in pyatspi2 is exaclty what orca did. The only thing missing is the connection to user preferences. 16:38:38 clown, ok, we could ask joanie later 16:38:49 actually, I don't recall if orca ever linked focus tracking and mouse tracking — it's been a while since I've seen that user preferences dialog (that no longer exists). 16:39:37 ok, 16:39:53 what I mean: there used to be a "Magnifier" tab in Orca's preferences dialog. 16:40:11 yes I know 16:40:22 for that reason some people still think that Orca is a magnifier 16:40:46 anyway, lets keep the feeling of a meeting 16:40:57 clown, something to add on the magnifier discussion? 16:41:26 shall I info some of the stuff I said above about focus and/or mouse tracking? 16:41:42 clown, ok, makes sense 16:41:45 thanks 16:41:51 hang on... 16:42:21 #info With respect to focus tracking and interactions with the mouse, Joseph noted: 16:43:01 #info 1. Currently, the setting is that focus and mouse tracking are decoupled and independent. 16:43:31 #info 2. Some magnifiers provide the option to link them together such that the mouse pointer is moved to the focussed item as focus changes. 16:43:57 #info 3. A third option is to decouple them, and to stop tracking mouse movements when focus tracking is on. 16:44:39 #info We should explore adding these options as preferences after focus tracking is implemented in gnome-shell. 16:45:09 Anything else to add on this? If not, I have other information about the focus tracking work. 16:45:23 not for me 16:45:25 I think that this is enough for the meeting 16:45:47 but as I suggested, it would be good to have something common 16:46:02 or we can just let KDE peole their as they want ;) 16:46:10 anyway, for the sake of meeting 16:46:25 #topic GNOME 3.6: Code Freeze is here. Accessibility is AlwaysOn(tm). Anything critical? 16:46:31 #info aka 3.6.1 is coming 16:46:46 #info Some bugs at the login screen and the lock screen were detected 16:46:53 #info the more relevant related with passwords 16:47:10 #info working on that, as probably they could deserver a code freeze for 3.6.1 16:47:34 clown, anything new about the packaging of that focus tracking script? 16:47:39 #info Joseph noticed that the live ISOs for GNOME 3.6 are using a slightly older version of pyatspi2 (2.5.92). 16:47:55 #info they should have used 2.60 16:48:27 #info the effect is that the focus tracking script is in a different location depending on the version. 16:48:51 but, they should have used 2.60, since that's the one for gnome 3.6 16:49:37 any idea if 3,6.1 will use pyastspi2 2.60? 16:49:50 hmm, it should use 2.60 16:50:01 in fact as you said 3.6 should had 16:50:20 yup 16:50:55 clown, so what was the location used for pyatspi2 2.60? 16:51:31 my client won't let me type slashes... 16:51:41 so: slash-usr-slash-bin 16:51:55 colin walters recommended that. 16:51:59 ok 16:52:14 so, anything else on this point? 16:52:29 not from me. 16:52:40 ok 16:52:45 #topic marketing 16:52:46 jjmarin, ? 16:53:03 hi, not to much to say, anyway 16:54:05 jjmarin, so nothing? 16:54:08 moving ? 16:54:08 #info Juanjo want to revamps the accessibility project page. It means to update some documents. Juanjo will work in a report about the current status of these documents and 16:54:31 #info some posible ways to update 16:54:35 done ! 16:54:37 :-) 16:55:09 jjmarin, ok thanks 16:55:10 so 16:55:17 #miscellaneous time 16:55:29 #info API will be at the Boston Summit this weekend 16:55:51 #info joanie will go first to the grace hopper event, and then she will go also to the Boston Summit 16:55:56 done 16:56:07 anyother one want to use misc time? 16:56:13 yes. 16:56:29 #info Joseph made some progress in terms of the freezing problem in the g-s focus tracking. 16:57:03 reentry? 16:57:04 #info the events are coming thru in a timely manner, regardless of where they come from (inside gnome-shell or some external process). 16:58:07 #info but, any method call on the accessible taken from the event results in a freeze when the event is from within gnome-shell 16:58:30 #info for e.g. accessible.getName(). 16:58:36 well, yes, seems a reentry problem ... 16:58:56 sure, API, but…. 16:59:22 why reentry problem here, but not for the atsp events? 16:59:34 the events are also dbus calls ultimately. 17:01:05 ok 17:01:28 well, this work is good, a pity that mgorse is not here 17:01:37 anyway, anything else for misc time? 17:01:45 one final info... 17:01:46 can we close this short-low-attendance meeting? 17:01:50 * API waiting 17:02:01 yes from my part 17:02:37 #info Joseph is looking very closely at pyatspi2 and atspi-core to see how python solves the rentrancy problem. There might be a need for a JSatspi2 library. 17:02:40 (done) 17:03:05 hmm, so in the end 17:03:22 the idea of using directly the gobject-introspection based bindings 17:03:32 seems that will have some issues 17:03:38 and some wrapping is required? 17:04:50 that's my current hypothesis. Ultimately accessible.getName() becomes a gobject call in atspi-core, which is implemented as a d-bus call to the accesible interface for its name property. 17:05:33 clown, ok thanks, lets see what happens 17:05:38 thanks for the investigation 17:05:50 as as it is already the official end-time for the meeting 17:05:51 you're welcome. 17:05:53 #endmeeting