Attachment '20110707_log.txt'
Download 1 14:37:20 <API> #startmeeting
2 14:37:20 <tota11y> Meeting started Thu Jul 7 14:37:20 2011 UTC. The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
3 14:37:20 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
4 14:37:42 <API> #topic Gtk+ 3 a11y branch is merged with master
5 14:38:23 <API> well, didn't have time to test it
6 14:38:42 <API> but afaik, Company joanie and mclasen had a funny time testing the merge
7 14:39:11 * joanie muses that "funny" must be another "false friend"
8 14:39:13 <joanie> ;-)
9 14:39:28 <API> I guess that funny as "smells funny"
10 14:39:55 <API> so, can you give us a summary ?
11 14:40:10 <joanie> me or Company?
12 14:40:23 <API> I don't mind ;)
13 14:40:36 <API> one can do his summary and the other can review
14 14:40:40 <joanie> Company: you want to talk about the merged branch and where things are?
15 14:41:21 <Company> it's still wip, but it works pretty well compared to previously
16 14:41:45 <API> so it is not only that you find issues, you also fixed several of them
17 14:41:47 <Company> and everybody gets to use it and file bugs about it now
18 14:42:11 <joanie> Company: are we at the filing bug (rather than use the list) stage?
19 14:42:31 <Company> joanie: i never file bugs, i always poke people, because that's faster :)
20 14:42:39 <joanie> heh
21 14:42:50 <joanie> okay, and for the purpose of minutes (and the meetbot)
22 14:43:12 <joanie> #info Benjamin and Matthias have merged the Gtk+ 3 'a11y' branch into master
23 14:43:18 <joanie> #info We all need to test it.
24 14:43:34 <Company> it's still way too slow and not emitting signals properly upon changes
25 14:43:38 <joanie> #info It's a lot more stable than one might expect given the enormous nature of the change
26 14:43:41 <joanie> (nice work)
27 14:43:45 <Company> the way too slow part is mostly the tree view
28 14:43:53 <joanie> #info However, there are still bugs - some of which Joanie has found
29 14:44:07 <API> just a question,
30 14:44:10 <API> at first
31 14:44:13 <API> after joanie comments
32 14:44:17 <API> I concluded that
33 14:44:24 <API> that branch was not usable
34 14:44:30 <API> it is more or less usable at this moment?
35 14:44:31 <joanie> #info Because Benjamin (Company) hangs out in #a11y and because he prefers to be poked, Joanie created a list on the A11y Team wiki: https://live.gnome.org/Accessibility/Gailectomy
36 14:44:50 <joanie> #info Team members should add stuff they find there
37 14:45:08 <joanie> API I'm using it now, on this box, and with AT support enabled
38 14:45:43 <joanie> #info Joanie needs to update Orca's gtk-demo regression tests for gtk3-demo anyway. The act of doing so should uncover more bugs (i.e. as she writes the tests).
39 14:45:52 <joanie> (think i'm done logging)
40 14:45:59 <API> ok, thanks
41 14:46:07 <API> so, no more questions from my side
42 14:46:11 <API> other people?
43 14:46:14 <API> questions?
44 14:46:19 <API> Company, joanie other comments?
45 14:46:26 <joanie> Just please, please, please everyone test
46 14:46:32 <Company> nope
47 14:46:40 <joanie> We want 3.2 to be more accessible; not less
48 14:46:46 <joanie> so let's not wait
49 14:47:16 <API> ok, thanks
50 14:47:20 <API> so moving?
51 14:47:28 <joanie> yup
52 14:47:49 <API> ok
53 14:48:09 <API> #topic atk-3 branch, relation with other projects
54 14:48:21 <API> recently li created a new branch
55 14:48:23 <API> atk-3
56 14:48:34 <API> the purpose will add things here that break api
57 14:48:42 <API> hmm
58 14:48:45 <API> I will do it better
59 14:48:52 <API> #info li created atk-3 branch
60 14:49:07 <API> #info use case 1: add there things that break current API
61 14:49:28 <API> #info use case 2: add things that can be added on atk2 but it would be good to test first
62 14:49:37 <API> ie, he added it due a bug that added new signals
63 14:49:54 <API> on the bug comments we were discussing the signal signature
64 14:50:16 <API> so it would be better to try to implement it on
65 14:50:24 <API> gail and then try to use on at-spi
66 14:50:29 <API> to check if the signature is the correct
67 14:50:42 <API> mgorse, I'm talking about that but with the relation change signal
68 14:50:44 <API> *but*
69 14:50:57 <API> probably I'm wrong
70 14:51:02 <API> and this is too conservative
71 14:51:11 <API> so as this doesn't break the API
72 14:51:22 <API> other option is if we are happy
73 14:51:27 <API> just apply it on atk2
74 14:51:30 <API> test it
75 14:51:30 <mgorse> Now I'm thinking I should make an at-spi-3-0 branch
76 14:51:38 <API> and if we found any issue
77 14:51:43 <API> fix it
78 14:52:05 <API> mgorse, and probably I should make an clutter-atk-3-0 branch
79 14:52:09 <mgorse> but I wondered why that change went into a new branch; seemed like an addition and not a break. But I haven't looked at the latest patch
80 14:52:22 <API> I would like to really test new atk things with a real thing
81 14:52:26 <Company> yeah, you guys should be made to implement all those signals you propose :p
82 14:52:28 <joanie> +1
83 14:52:35 <API> the advantage is that atk implementation on clutter is not really big
84 14:53:01 <API> mgorse, as I said, probably I'm being too conservative here, and wanted to avoid
85 14:53:04 <API> do and redo
86 14:53:25 <API> so probably use case 2 is not neccessary and just use case 1 "things that change the API" is required
87 14:53:55 <API> so it seems that most people prefers the other way
88 14:53:56 <API> so
89 14:54:12 <joanie> Well, I'm not sure use case 2 is "not necessary" so much as it is we're approaching the .4 release already. And nothing tests for breakage like using it. (I discovered) ;-)
90 14:54:37 <joanie> People should test their patches thoroughly, maintainers should review thoroughly
91 14:54:54 <joanie> and if it looks sane, we should add it to master. IMHO.
92 14:54:54 <API> #info after a little discussion on the meeting, use case 2 shouldn't be used for all, just for things that people are really not sure about
93 14:55:20 <API> joanie, so you agree with my last #info?
94 14:55:29 <joanie> yeah
95 14:55:34 <API> it can be summarized as "not use use case 2 for all"
96 14:55:36 <API> ok
97 14:55:39 <API> but in summary
98 14:55:50 <API> we have a testing/unstable atk-3 branch
99 14:56:13 <API> so probably the rest of the projects using atk would require a similar branch to test those things
100 14:56:21 <API> questions, doubts, comments?
101 14:56:22 <Company> joanie: the hard part is that you need to change 4 different pieces of software to test for something - the ATK, at-spi, the bridge and the toolkit of your choice - and i'm not sure a lot of people exist that have knowledge in all of those areas...
102 14:56:33 <API> Company, yes
103 14:56:45 <API> this is the sad true on a11y
104 14:56:49 <joanie> but....
105 14:57:01 <API> and as we already concluded on the atk hackfest
106 14:57:01 <Company> also, adding signals is tough
107 14:57:10 <API> atk-3.0 would require a lot of coordination
108 14:57:12 <joanie> we do have several people who have the first three
109 14:57:14 <Company> because it means nobody is going to emit them - at least at first
110 14:57:17 <API> with the implementors
111 14:57:38 <Company> so you can't rely on them being emitted
112 14:57:39 <API> well, the good thing with the signals,
113 14:57:49 <Company> and if you can't rely on them, you just don't use them
114 14:57:52 <API> is that in most cases, it doesn't require a API change
115 14:57:56 <Company> and then nobody implements them
116 14:57:58 <API> if we avoid the default handler on the class
117 14:58:04 <API> so they can be added more easily
118 14:58:15 <joanie> So what do you propose we do Company?
119 14:58:19 <API> so it is just add a new signal and then create bugs on the implementors to use them
120 14:58:50 <Company> joanie: i have no good idea really on how to solve that
121 14:58:52 <mgorse> yeah... I proposed them to help with caching; for now the default will have to be not to rely on them for that, until they're implemented in toolkits, in which case Orca can turn it on or the default can change eventually
122 14:59:22 <joanie> Company: My idea is we do it. We bug implementors. We move forward.
123 14:59:37 <joanie> Otherwise, it will never get done. And then what's the point?
124 14:59:59 <joanie> Besides, every day we learn from you a new way the a11y implementation is borked. ;-) ;-)
125 15:00:02 <Company> joanie: one option would be to make toolkits export an ATK version they conform to
126 15:00:19 <joanie> I don't follow
127 15:00:21 <Company> joanie: and if cally says "conforms to 2.0.0" and the signal is new in 2.2.0, then you can't use it
128 15:00:40 <joanie> Well, from the AT point of view....
129 15:00:44 <Company> joanie: but if cally says "conforms to 2.2.0" you can rely on the signal being emitted properly
130 15:00:50 <joanie> I have to assume that this is all going to take a while
131 15:00:56 <joanie> and we have to sanity check a bunch
132 15:00:57 <joanie> that's a given
133 15:01:06 <joanie> and it's the problem of the ATs to deal with it
134 15:01:13 <Company> dunno
135 15:01:17 <Company> it's incredibly sucky
136 15:01:20 <joanie> the longer we wait on the ATk/AT-SPI/toolkit stuff
137 15:01:26 <joanie> the longer it will be sucky
138 15:01:28 <Company> because you have 2 code paths and one of them is untested...
139 15:02:56 <Company> i don't have a good solution for it unfortunately
140 15:03:18 <Company> i can just see how it leads to lots of bugs and that saddens the engineer in me
141 15:03:37 <joanie> And yet, not fixing things saddens the enginner in you.
142 15:04:09 <joanie> So you can be perpetually saddened, or you can be frustrated in the short-term but happy as things get finally fixed.
143 15:04:19 <API> Company, well we all agree that it is complex
144 15:04:26 <API> but the only path that I see now is
145 15:04:29 <joanie> and honestly, if y'all can merge gail into gtk and break my system
146 15:04:31 <Company> and then someone adds another signal and the circle starts again :/
147 15:04:31 <joanie> ;-)
148 15:04:33 <API> atk can and should be improved
149 15:04:38 <API> so lets improve it and lets
150 15:04:46 <API> try to coordinate the changes on the implementors
151 15:04:49 <API> as best as possible
152 15:04:51 <joanie> +1 API
153 15:04:56 <joanie> I think we can do this
154 15:05:00 <Company> i just think we need a way for atk implementors to indicate their conformance
155 15:05:07 <Company> to the APIs we use
156 15:05:38 <mgorse> yeah; that seems like a good idea
157 15:06:42 <API> yes thats true
158 15:06:46 <API> as far as I see
159 15:06:49 <Company> it could be as easy as toolkit->conformance = "2.0.0" or so
160 15:06:50 <API> I think that on those old times
161 15:06:57 <API> when atk and gail was implemented
162 15:07:03 <API> it was implemented by the same guys
163 15:07:18 <API> so they used just their common sense
164 15:07:31 <API> it is true that it would be good something more formal
165 15:07:51 <API> those gtk tests are a good first step, it would be good to have something more formal
166 15:08:04 <API> or more high level or <insert_fancy_word_here>
167 15:08:12 <API> anyway, lets finish this point
168 15:08:32 <API> any other final comment, suggestion, question?
169 15:10:50 <API> ok, taking into account the silence
170 15:11:03 <API> #topic GNOME 3.2 progress:
171 15:11:22 <API> first topic was more or less a update of this
172 15:11:37 <API> from my case
173 15:12:09 <API> #info last converstations on #a11y seems to clarify how a button should be implemented, API will try to apply it to StButton, probably this weekend
174 15:12:15 <API> so now
175 15:12:18 <API> the rest of the people?
176 15:12:24 <API> any GNOME 3.2 updatE?
177 15:12:29 <joanie> https://live.gnome.org/Accessibility/ThreePointTwo/Issues
178 15:12:37 * joanie prepares to call on people
179 15:12:37 <jhernandez|eee> me
180 15:12:48 <joanie> jhernandez|eee: yay
181 15:13:03 <jhernandez|eee> I have a 'more stable' code of accerciser's pygi migration
182 15:13:17 <jhernandez|eee> in my personal branch: https://github.com/javihernandez/accerciser-mirror/branches/pygtk-pygi-conversion-3.0
183 15:13:33 * alibezz gets happy with Javi's work
184 15:13:39 <jhernandez|eee> alibezz helped me to find bugs
185 15:13:53 <jhernandez|eee> thx alibezz !!
186 15:13:57 <jhernandez|eee> ;)
187 15:14:00 <alibezz> you're welcome ;)
188 15:14:07 <API> jhernandez|eee, could you elaborate "more stable"?
189 15:14:13 <jhernandez|eee> so, it will be great if someone else could give a quick try to this new branch
190 15:14:35 <jhernandez|eee> API: yes, I ported plugins, and things started to work fine
191 15:15:10 <API> ook
192 15:15:12 <API> so
193 15:15:23 <API> can you give us some pretty #info tags ? ;)
194 15:15:32 <jhernandez|eee> ok
195 15:17:09 <jhernandez|eee> #info accerciser's pygi work is working fine. So it will be good if someone give a quick test to this
196 15:17:16 <API> ok, thanks
197 15:17:19 <jhernandez|eee> #link https://github.com/javihernandez/accerciser-mirror/branches/pygtk-pygi-conversion-3.0
198 15:17:24 <API> mgorse, clown ?
199 15:17:34 * clown takes the conch.
200 15:17:39 <jhernandez|eee> :]
201 15:17:48 <clown> there has been some action on 645665
202 15:17:59 <clown> https://bugzilla.gnome.org/show_bug.cgi?id=645665
203 15:18:00 <tota11y> 04Bug 645665: normal, Normal, ---, gsettings-desktop-schemas-maint, UNCONFIRMED, Magnifier: Add brightness and contrast preferences
204 15:18:46 <clown> bastien reviewed it; I modified the schema based on the review, and uploaded a new patch.
205 15:18:52 <clown> and that's where it lies...
206 15:19:02 * clown now to use #info.
207 15:19:36 <clown> #info bastien reviewed clown's initial patch for adding brightness and contrast preferences to gsettings-desktop-schemas.
208 15:19:46 <clown> #link https://bugzilla.gnome.org/show_bug.cgi?id=645665
209 15:19:46 <tota11y> 04Bug 645665: normal, Normal, ---, gsettings-desktop-schemas-maint, UNCONFIRMED, Magnifier: Add brightness and contrast preferences
210 15:20:06 <clown> #info clown responded to review, and uploaded a new patch with the requested modifications.
211 15:20:09 * clown done.
212 15:20:14 <API> thanks, mgorse ?
213 15:20:34 <mgorse> clown: that reminds me; I committed that at-spi patch.
214 15:21:08 <mgorse> #info mgorse made some AT-SPI API changes for compatibility with Javascript
215 15:21:12 <clown> mgorse: I tried the one you sent me yesterday, but I'm still getting the same error.
216 15:21:58 <mgorse> clown: That reminds me that I wanted to look at the way the introspection is generated. I wonder if the .gir is being regenerated. I'll talk to you after the meeting, anyway
217 15:22:01 <clown> but, i forgot to regenerate the gir and typlib files, so maybe that explains it.
218 15:22:12 * clown great minds...
219 15:22:37 <clown> thanks mgorse.
220 15:22:47 <API> ok, thanks
221 15:23:02 <API> so anything else from anyone?
222 15:24:35 <API> well, again the silence
223 15:24:41 <API> so just 5 minutes
224 15:24:43 <API> so
225 15:24:49 <API> #topic miscellaneous time
226 15:24:58 <API> well, in relation with the performance thing
227 15:25:19 <API> I mean performance measures
228 15:25:33 <API> #info we should ask fer about it, as he made some measures in the past
229 15:25:56 <API> #info on the old times, when performance-list@gnome.org was still active
230 15:26:02 <API> #link https://mail.gnome.org/archives/performance-list/2006-October/msg00061.html
231 15:26:04 <API> and related
232 15:26:29 <API> #info next Monday will start a igalian internship
233 15:26:53 <API> #info the main use case is help me with some cally (and pro bably gnome-shell) things that I don't have time to do
234 15:27:11 <API> #info but also other a11y things
235 15:27:26 <API> #info he is a good candidate to check that before-after performance measure
236 15:27:40 <API> of course, it doesn't mean that he will made that measures next week
237 15:27:47 <API> as he needs first some background
238 15:28:00 <API> but, at least we will have one person working on that
239 15:28:05 <API> Im done
240 15:28:26 <API> other comments for this miscellanesous time?
241 15:28:44 <mgorse> I looked briefly at the tree view performance test in gtk and figured out that it's still slow to populate a tree view, since, even aside from atk-bridge responding to signals, it sends a row-added signal when a row is added, and needs to calculate the row number each time to put in the signal, and that takes time
242 15:29:14 * clown hi fer.
243 15:29:23 <fer> hi. am I too late?
244 15:29:29 <API> fer, of course ;)
245 15:29:36 <API> meeting ends in one minute
246 15:29:46 <fer> :(
247 15:29:52 <API> don't be sad
248 15:30:02 <API> I give you the last minute
249 15:30:05 <API> on miscellaneous time
250 15:30:06 <API> shot
251 15:30:23 <fer> ok, I got firefox multiprocess a11y working on linux, and I'm really happy about that
252 15:30:35 <fer> and I would like to thanks mgorse for the AtkSocket stuff :)
253 15:30:54 <API> yep, that stuff is really awesome, you should also ask msanchez
254 15:31:13 <API> well, so this seems to be the end
255 15:31:16 <API> anything else?
256 15:31:18 <mgorse> You should really thank Brad Taylor, who isn't here, but, anyway, is that going into Firefox 7?
257 15:31:55 <fer> mgorse: the plugin atksocket support, for sure, but the multiprocess branch is far away to be finished
258 15:32:00 <fer> probably firefox 8 or 9
259 15:32:04 <mgorse> oh ok
260 15:32:40 <clown> fer, can you say in 1 sentence what "multiprocess a11y" means?
261 15:33:19 <fer> clown: proper logical single tree made of accessible elements coming from different processes
262 15:33:36 <clown> fer: cool (and well said!)
263 15:33:55 <API> fer knows the lesson
264 15:33:59 <API> ok, awesome
265 15:34:03 <API> almost 5 minutes over time
266 15:34:07 <API> so lets end the meeting
267 15:34:15 <API> thanks all people
268 15:34:18 <API> #endmeeting
Attached Files
To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.You are not allowed to attach a file to this page.