14:37:20 <API> #startmeeting
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.
14:37:20 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:37:42 <API> #topic Gtk+ 3 a11y branch is merged with master
14:38:23 <API> well, didn't have time to test it
14:38:42 <API> but afaik, Company joanie and mclasen had a funny time testing the merge
14:39:11 * joanie muses that "funny" must be another "false friend"
14:39:13 <joanie> ;-)
14:39:28 <API> I guess that funny as "smells funny"
14:39:55 <API> so, can you give us a summary ?
14:40:10 <joanie> me or Company?
14:40:23 <API> I don't mind ;)
14:40:36 <API> one can do his summary and the other can review
14:40:40 <joanie> Company: you want to talk about the merged branch and where things are?
14:41:21 <Company> it's still wip, but it works pretty well compared to previously
14:41:45 <API> so it is not only that you find issues, you also fixed several of them
14:41:47 <Company> and everybody gets to use it and file bugs about it now
14:42:11 <joanie> Company: are we at the filing bug (rather than use the list) stage?
14:42:31 <Company> joanie: i never file bugs, i always poke people, because that's faster :)
14:42:39 <joanie> heh
14:42:50 <joanie> okay, and for the purpose of minutes (and the meetbot)
14:43:12 <joanie> #info Benjamin and Matthias have merged the Gtk+ 3 'a11y' branch into master
14:43:18 <joanie> #info We all need to test it.
14:43:34 <Company> it's still way too slow and not emitting signals properly upon changes
14:43:38 <joanie> #info It's a lot more stable than one might expect given the enormous nature of the change
14:43:41 <joanie> (nice work)
14:43:45 <Company> the way too slow part is mostly the tree view
14:43:53 <joanie> #info However, there are still bugs - some of which Joanie has found
14:44:07 <API> just a question,
14:44:10 <API> at first
14:44:13 <API> after joanie comments
14:44:17 <API> I concluded that
14:44:24 <API> that branch was not usable
14:44:30 <API> it is more or less usable at this moment?
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
14:44:50 <joanie> #info Team members should add stuff they find there
14:45:08 <joanie> API I'm using it now, on this box, and with AT support enabled
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).
14:45:52 <joanie> (think i'm done logging)
14:45:59 <API> ok, thanks
14:46:07 <API> so, no more questions from my side
14:46:11 <API> other people?
14:46:14 <API> questions?
14:46:19 <API> Company, joanie other comments?
14:46:26 <joanie> Just please, please, please everyone test
14:46:32 <Company> nope
14:46:40 <joanie> We want 3.2 to be more accessible; not less
14:46:46 <joanie> so let's not wait
14:47:16 <API> ok, thanks
14:47:20 <API> so moving?
14:47:28 <joanie> yup
14:47:49 <API> ok
14:48:09 <API> #topic atk-3 branch, relation with other projects
14:48:21 <API> recently li created a new branch
14:48:23 <API> atk-3
14:48:34 <API> the purpose will add things here that break api
14:48:42 <API> hmm
14:48:45 <API> I will do it better
14:48:52 <API> #info li created atk-3 branch
14:49:07 <API> #info use case 1: add there things that break current API
14:49:28 <API> #info use case 2: add things that can be added on atk2 but it would be good to test first
14:49:37 <API> ie, he added it due a bug that added new signals
14:49:54 <API> on the bug comments we were discussing the signal signature
14:50:16 <API> so it would be better to try to implement it on
14:50:24 <API> gail and then try to use on at-spi
14:50:29 <API> to check if the signature is the correct
14:50:42 <API> mgorse, I'm talking about that but with the relation change signal
14:50:44 <API> *but*
14:50:57 <API> probably I'm wrong
14:51:02 <API> and this is too conservative
14:51:11 <API> so as this doesn't break the API
14:51:22 <API> other option is if we are happy
14:51:27 <API> just apply it on atk2
14:51:30 <API> test it
14:51:30 <mgorse> Now I'm thinking I should make an at-spi-3-0 branch
14:51:38 <API> and if we found any issue
14:51:43 <API> fix it
14:52:05 <API> mgorse, and probably I should make an clutter-atk-3-0 branch
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
14:52:22 <API> I would like to really test new atk things with a real thing
14:52:26 <Company> yeah, you guys should be made to implement all those signals you propose :p
14:52:28 <joanie> +1
14:52:35 <API> the advantage is that atk implementation on clutter is not really big
14:53:01 <API> mgorse, as I said, probably I'm being too conservative here, and wanted to avoid
14:53:04 <API> do and redo
14:53:25 <API> so probably use case 2 is not neccessary and just use case 1 "things that change the API" is required
14:53:55 <API> so it seems that most people prefers the other way
14:53:56 <API> so
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) ;-)
14:54:37 <joanie> People should test their patches thoroughly, maintainers should review thoroughly
14:54:54 <joanie> and if it looks sane, we should add it to master. IMHO.
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
14:55:20 <API> joanie, so you agree with my last #info?
14:55:29 <joanie> yeah
14:55:34 <API> it can be summarized as "not use use case 2 for all"
14:55:36 <API> ok
14:55:39 <API> but in summary
14:55:50 <API> we have a testing/unstable atk-3 branch
14:56:13 <API> so probably the rest of the projects using atk would require a similar branch to test those things
14:56:21 <API> questions, doubts, comments?
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...
14:56:33 <API> Company, yes
14:56:45 <API> this is the sad true on a11y
14:56:49 <joanie> but....
14:57:01 <API> and as we already concluded on the atk hackfest
14:57:01 <Company> also, adding signals is tough
14:57:10 <API> atk-3.0 would require a lot of coordination
14:57:12 <joanie> we do have several people who have the first three
14:57:14 <Company> because it means nobody is going to emit them - at least at first
14:57:17 <API> with the implementors
14:57:38 <Company> so you can't rely on them being emitted
14:57:39 <API> well, the good thing with the signals,
14:57:49 <Company> and if you can't rely on them, you just don't use them
14:57:52 <API> is that in most cases, it doesn't require a API change
14:57:56 <Company> and then nobody implements them
14:57:58 <API> if we avoid the default handler on the class
14:58:04 <API> so they can be added more easily
14:58:15 <joanie> So what do you propose we do Company?
14:58:19 <API> so it is just add a new signal and then create bugs on the implementors to use them
14:58:50 <Company> joanie: i have no good idea really on how to solve that
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
14:59:22 <joanie> Company: My idea is we do it. We bug implementors. We move forward.
14:59:37 <joanie> Otherwise, it will never get done. And then what's the point?
14:59:59 <joanie> Besides, every day we learn from you a new way the a11y implementation is borked. ;-) ;-)
15:00:02 <Company> joanie: one option would be to make toolkits export an ATK version they conform to
15:00:19 <joanie> I don't follow
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
15:00:40 <joanie> Well, from the AT point of view....
15:00:44 <Company> joanie: but if cally says "conforms to 2.2.0" you can rely on the signal being emitted properly
15:00:50 <joanie> I have to assume that this is all going to take a while
15:00:56 <joanie> and we have to sanity check a bunch
15:00:57 <joanie> that's a given
15:01:06 <joanie> and it's the problem of the ATs to deal with it
15:01:13 <Company> dunno
15:01:17 <Company> it's incredibly sucky
15:01:20 <joanie> the longer we wait on the ATk/AT-SPI/toolkit stuff
15:01:26 <joanie> the longer it will be sucky
15:01:28 <Company> because you have 2 code paths and one of them is untested...
15:02:56 <Company> i don't have a good solution for it unfortunately
15:03:18 <Company> i can just see how it leads to lots of bugs and that saddens the engineer in me
15:03:37 <joanie> And yet, not fixing things saddens the enginner in you.
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.
15:04:19 <API> Company, well we all agree that it is complex
15:04:26 <API> but the only path that I see now is
15:04:29 <joanie> and honestly, if y'all can merge gail into gtk and break my system
15:04:31 <Company> and then someone adds another signal and the circle starts again :/
15:04:31 <joanie> ;-)
15:04:33 <API> atk can and should be improved
15:04:38 <API> so lets improve it and lets
15:04:46 <API> try to coordinate the changes on the implementors
15:04:49 <API> as best as possible
15:04:51 <joanie> +1 API
15:04:56 <joanie> I think we can do this
15:05:00 <Company> i just think we need a way for atk implementors to indicate their conformance
15:05:07 <Company> to the APIs we use
15:05:38 <mgorse> yeah; that seems like a good idea
15:06:42 <API> yes thats true
15:06:46 <API> as far as I see
15:06:49 <Company> it could be as easy as toolkit->conformance = "2.0.0" or so
15:06:50 <API> I think that on those old times
15:06:57 <API> when atk and gail was implemented
15:07:03 <API> it was implemented by the same guys
15:07:18 <API> so they used just their common sense
15:07:31 <API> it is true that it would be good something more formal
15:07:51 <API> those gtk tests are a good first step, it would be good to have something more formal
15:08:04 <API> or more high level or <insert_fancy_word_here>
15:08:12 <API> anyway, lets finish this point
15:08:32 <API> any other final comment, suggestion, question?
15:10:50 <API> ok, taking into account the silence
15:11:03 <API> #topic GNOME 3.2 progress:
15:11:22 <API> first topic was more or less a update of this
15:11:37 <API> from my case
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
15:12:15 <API> so now
15:12:18 <API> the rest of the people?
15:12:24 <API> any GNOME 3.2 updatE?
15:12:29 <joanie> https://live.gnome.org/Accessibility/ThreePointTwo/Issues
15:12:37 * joanie prepares to call on people
15:12:37 <jhernandez|eee> me
15:12:48 <joanie> jhernandez|eee: yay
15:13:03 <jhernandez|eee> I have a 'more stable' code of accerciser's pygi migration
15:13:17 <jhernandez|eee> in my personal branch: https://github.com/javihernandez/accerciser-mirror/branches/pygtk-pygi-conversion-3.0
15:13:33 * alibezz gets happy with Javi's work
15:13:39 <jhernandez|eee> alibezz helped me to find bugs
15:13:53 <jhernandez|eee> thx alibezz !!
15:13:57 <jhernandez|eee> ;)
15:14:00 <alibezz> you're welcome ;)
15:14:07 <API> jhernandez|eee, could you elaborate "more stable"?
15:14:13 <jhernandez|eee> so, it will be great if someone else could give a quick try to this new branch
15:14:35 <jhernandez|eee> API: yes, I ported  plugins, and things started to work fine
15:15:10 <API> ook
15:15:12 <API> so
15:15:23 <API> can you give us some pretty #info tags ? ;)
15:15:32 <jhernandez|eee> ok
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
15:17:16 <API> ok, thanks
15:17:19 <jhernandez|eee> #link https://github.com/javihernandez/accerciser-mirror/branches/pygtk-pygi-conversion-3.0
15:17:24 <API> mgorse, clown ?
15:17:34 * clown takes the conch.
15:17:39 <jhernandez|eee> :]
15:17:48 <clown> there has been some action on 645665
15:17:59 <clown> https://bugzilla.gnome.org/show_bug.cgi?id=645665
15:18:00 <tota11y> 04Bug 645665: normal, Normal, ---, gsettings-desktop-schemas-maint, UNCONFIRMED, Magnifier: Add brightness and contrast preferences
15:18:46 <clown> bastien reviewed it; I modified the schema based on the review, and uploaded a new patch.
15:18:52 <clown> and that's where it lies...
15:19:02 * clown now to use #info.
15:19:36 <clown> #info bastien reviewed clown's initial patch for adding brightness and contrast preferences to gsettings-desktop-schemas.
15:19:46 <clown> #link https://bugzilla.gnome.org/show_bug.cgi?id=645665
15:19:46 <tota11y> 04Bug 645665: normal, Normal, ---, gsettings-desktop-schemas-maint, UNCONFIRMED, Magnifier: Add brightness and contrast preferences
15:20:06 <clown> #info clown responded to review, and uploaded a new patch with the requested modifications.
15:20:09 * clown done.
15:20:14 <API> thanks, mgorse ?
15:20:34 <mgorse> clown: that reminds me; I committed that at-spi patch.
15:21:08 <mgorse> #info mgorse made some AT-SPI API changes for compatibility with Javascript
15:21:12 <clown> mgorse:  I tried the one you sent me yesterday, but I'm still getting the same error.
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
15:22:01 <clown> but, i forgot to regenerate the gir and typlib files, so maybe that explains it.
15:22:12 * clown great minds...
15:22:37 <clown> thanks mgorse.
15:22:47 <API> ok, thanks
15:23:02 <API> so anything else from anyone?
15:24:35 <API> well, again the silence
15:24:41 <API> so just 5 minutes
15:24:43 <API> so
15:24:49 <API> #topic miscellaneous time
15:24:58 <API> well, in relation with the performance thing
15:25:19 <API> I mean performance measures
15:25:33 <API> #info we should ask fer about it, as he made some measures in the past
15:25:56 <API> #info on the old times, when performance-list@gnome.org was still active
15:26:02 <API> #link https://mail.gnome.org/archives/performance-list/2006-October/msg00061.html
15:26:04 <API> and related
15:26:29 <API> #info next Monday will start a igalian internship
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
15:27:11 <API> #info but also other a11y things
15:27:26 <API> #info he is a good candidate to check that before-after performance measure
15:27:40 <API> of course, it doesn't mean that he will made that measures next week
15:27:47 <API> as he needs first some background
15:28:00 <API> but, at least we will have one person working on that
15:28:05 <API> Im done
15:28:26 <API> other comments for this miscellanesous time?
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
15:29:14 * clown hi fer.
15:29:23 <fer> hi. am I too late?
15:29:29 <API> fer, of course ;)
15:29:36 <API> meeting ends in one minute
15:29:46 <fer> :(
15:29:52 <API> don't be sad
15:30:02 <API> I give you the last minute
15:30:05 <API> on miscellaneous time
15:30:06 <API> shot
15:30:23 <fer> ok, I got firefox multiprocess a11y working on linux, and I'm really happy about that
15:30:35 <fer> and I would like to thanks mgorse for the AtkSocket stuff :)
15:30:54 <API> yep, that stuff is really awesome, you should also ask msanchez
15:31:13 <API> well, so this seems to be the end
15:31:16 <API> anything else?
15:31:18 <mgorse> You should really thank Brad Taylor, who isn't here, but, anyway, is that going into Firefox 7?
15:31:55 <fer> mgorse: the plugin atksocket support, for sure, but the multiprocess branch is far away to be finished
15:32:00 <fer> probably firefox 8 or 9
15:32:04 <mgorse> oh ok
15:32:40 <clown> fer, can you say in 1 sentence what "multiprocess a11y" means?
15:33:19 <fer> clown: proper logical single tree made of accessible elements coming from different processes
15:33:36 <clown> fer:  cool  (and well said!)
15:33:55 <API> fer knows the lesson
15:33:59 <API> ok, awesome
15:34:03 <API> almost 5 minutes over time
15:34:07 <API> so lets end the meeting
15:34:15 <API> thanks all people
15:34:18 <API> #endmeeting