1 14:36:07 <API> #startmeeting
   2 14:36:07 <tota11y> Meeting started Thu Aug  4 14:36:07 2011 UTC.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
   3 14:36:07 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
   4 14:36:30 <API> #topic  possibly add a children-invalidated even
   5 14:36:39 <API> well, this is somewhat a technical topic
   6 14:36:54 <API> mgorse, ?
   7 14:36:58 <API> you added that point
   8 14:37:11 <mgorse> yeah, I added it in response to an email that fregl sent out
   9 14:37:23 <mgorse> since, for kde, when removing a child, it no longer has access to the child's index
  10 14:37:46 <mgorse> so he suggested having an event that would just say that children are invalidated
  11 14:37:53 <fregl> hi, great
  12 14:37:57 <API> insted of children-remove?
  13 14:38:05 <fregl> I was just wondering how to tackle this
  14 14:38:12 <mgorse> but this would mean that ATs might not see children-changed::remove events, for instance, so need to discuss it
  15 14:38:22 <fregl> my problem is mostly that passing the child index along makes things hard
  16 14:38:25 <API> well, fwiw some weeks ago we talked with Company, and he is not sure about the index stuff
  17 14:38:34 <API> as some widgets don't have inherently a order
  18 14:38:38 <mgorse> another option might be for the app-side AT-SPI implementor to send -1 for the detail, and then libatspi would fill in the index if it has the accessible cached
  19 14:38:51 <mgorse> but, at least for MANAGES_DESCENDANTS objects, it won't have the child cached
  20 14:38:59 <fregl> mgorse: that would work for me
  21 14:39:20 <joanie> so would these be MANAGES_DESCENDANTS objects fregl?
  22 14:39:23 <fregl> for manages descendants I would think we shouldn't send child removed/added
  23 14:39:28 <fregl> joanie: no
  24 14:39:47 <fregl> it is a general thing in how object deletion works in the case of Qt in many cases
  25 14:40:00 <API> fregl, so that -1 is an option for you?
  26 14:40:13 <API> I mean, send -1 on the index if it is not possible to send the proper one
  27 14:40:17 <fregl> the parent get's it's pointer to the child removed and the child still knows the parent when I get the notification
  28 14:40:26 <fregl> API: yes, the -1 as detail would be perfect
  29 14:40:43 <fregl> and when it's not cached, all should be fine anyway as far as I understand
  30 14:40:44 <API> ok, so I guess that we can assume that in general:
  31 14:40:46 <joanie> and having at-spi deal with it would be perfect
  32 14:40:48 <API> and update the documentation:
  33 14:40:50 <API> http://developer.gnome.org/atk/unstable/AtkObject.html#AtkObject-children-changed
  34 14:41:06 <API> adding that -1 will be sent if it is not possible to know the index
  35 14:41:19 <API> mgorse, do you agree?
  36 14:41:22 <fregl> sweet
  37 14:41:22 <API> hmm, stupid question
  38 14:41:27 <API> you proposed that ;)
  39 14:41:27 <mgorse> Having AT-SPI fill in the index might not always work or be easy, though
  40 14:41:40 <fregl> well, what is the index used for?
  41 14:41:50 <mgorse> ie, if a children-changed:add event was send for the object, would it include the object path of the added child?
  42 14:41:53 <joanie> mgorse: we can punt in the worst case
  43 14:42:19 <joanie> fregl: depends on the app
  44 14:42:24 <mgorse> if not, then the child won't be cached, unless AT-SPI were to ask for the child, which I'm not sure is what we want, either
  45 14:42:28 <joanie> often we don't care
  46 14:43:14 <joanie> in the case of impress I think the index is going to prove handy in terms of being able to communicate slides and placeholders that were just removed
  47 14:43:22 <fregl> I thought the whole purpose of this function was to just let the app know that the thing is no longer available
  48 14:43:33 <mgorse> I guess we could always do that for now, have KDE send -1 for the detail, and AT-SPI would fill in the index if it has it cached, and deal with it later if it winds up causing problems for someone
  49 14:43:38 <joanie> but what thing fregl?
  50 14:43:51 <joanie> without the index we know that one of the children of the object went away
  51 14:44:08 <joanie> if we care which one (i.e. to say 'slide 5 deleted')
  52 14:44:09 <API> mgorse, as I said Company is not also sure about that index
  53 14:44:10 <fregl> joanie: no, you also get the path of the removed child
  54 14:44:11 <joanie> we don't know
  55 14:44:24 <joanie> the path?
  56 14:44:29 <fregl> joanie: yes, the path
  57 14:44:30 <joanie> but not the index?
  58 14:44:31 <API> although I guess that in the same way that we can document that -1 should be used if not index is available
  59 14:44:34 <fregl> the dbus path
  60 14:44:44 <joanie> who is we?
  61 14:44:45 <API> we should also said that this would be the lesser evil
  62 14:44:49 <joanie> I'm an AT
  63 14:44:59 <fregl> joanie: at-spi dbus
  64 14:45:03 <fregl> so the other side
  65 14:45:14 <mgorse> fregl: When a child is added, do you send the path? I remember you talking about not wanting to instantiate objects unless they're needed, and getting a path requires instantiating an object
  66 14:45:43 <fregl> mgorse: actually we worked around that by patching the qt dbus implementation for this
  67 14:46:16 <fregl> I think it is very silly anyway - right now I send: parentpath children-changed:add index 0 childpath
  68 14:46:24 <mgorse> oh okay. If you send the object path and a children-changed event when an object is added, then it should be cached, unless it has MANAGES_DESCENDANTS
  69 14:46:24 <fregl> so you get redundant information
  70 14:46:52 <fregl> ok
  71 14:47:03 <fregl> I really need to read the atspi code more
  72 14:47:10 <fregl> but all seems fine now
  73 14:47:41 <fregl> right now I send -1 as index for object removed already and that probably doesn't work
  74 14:47:54 <mgorse> Anyway, I guess we can conclude this / add a #info
  75 14:48:00 <fregl> great
  76 14:48:46 <mgorse> #info If an app sends -1 for the detail for a children-changed, we will assume that the index is unknown
  77 14:48:49 <API> yes please
  78 14:49:01 <fregl> my current state is that I want to release a beta and get people to test for real now. I got startup time and memory usage to almost nothing.
  79 14:49:16 <mgorse> #info mgorse will modify libatspi to fill in the index when possible (ie, when it has the child cached, which it will not for trees with MANAGES_DESCENDANTS for instance)
  80 14:49:29 <fregl> mgorse: you rock!
  81 14:49:31 <joanie> (woo hoo fregl! Congrats!!!)
  82 14:49:44 <API> #info AtkObject:children-changed documentation will be updated, as this could be also used on ATK implementors
  83 14:49:54 <API> well, anything else?
  84 14:49:55 <joanie> by whom API?
  85 14:49:59 <API> I can do that
  86 14:50:02 <fregl> tables/trees with millions of lines cause no delay any more, that was what worried me :D
  87 14:50:14 <API> well in fact it is more an action item
  88 14:50:19 <API> but that just a nitpick
  89 14:50:21 <joanie> #action Piñeiro will update the documentation
  90 14:50:21 <mgorse> Oh; that's an improvement over gtk :)
  91 14:50:36 <joanie> API it's a nitpick to you who doesn't deal with minutes :-P
  92 14:50:42 <API> anything else in this point?
  93 14:52:05 <API> ... silence ....
  94 14:52:08 <API> ok, moving
  95 14:52:16 <API> #topic CSUN Speaker Proposals
  96 14:52:24 <joanie> API no
  97 14:52:26 <API> joanie, you added this poing, AFAIK
  98 14:52:27 <API> no?
  99 14:52:35 <joanie> clown: added stuff
 100 14:52:38 <API> hmm, last minute changes ;)
 101 14:52:41 <joanie> I mean we could do this out of order
 102 14:52:45 <joanie> but...
 103 14:52:49 <API> #topic quick update on gs-mag
 104 14:52:52 <clown> sure.  I think I put my addition in the wrong place on the agenda, as it relates to 3.2 progress.  If you want to postpone until we deal with 3.2 progess..
 105 14:53:05 <joanie> clown: please go on
 106 14:53:08 <API> no problem, I just have that page open
 107 14:53:15 <API> we can go in order
 108 14:53:17 <API> clown please
 109 14:53:23 <clown> okay.  it's fairly quick anyhow.  I'll just add some #infos.
 110 14:53:33 <clown> #info Joseph submitted a new patch for the zoom options dialog in universal access.
 111 14:53:40 <clown> #info https://bugzilla.gnome.org/show_bug.cgi?id=643086#c27
 112 14:53:40 <tota11y> 04Bug 643086: normal, Normal, ---, control-center-maint, NEW, Universal access:  add dialog for zoom options
 113 14:53:49 <clown> #info awaiting review.
 114 14:53:53 <clown> and...
 115 14:53:58 <clown> #info Re: Joseph's invert video patch for gs-mag
 116 14:54:04 <clown> #info https://bugzilla.gnome.org/show_bug.cgi?id=639851#c8
 117 14:54:04 <tota11y> 04Bug 639851: normal, Normal, ---, gnome-shell-maint, UNCONFIRMED, Magnifier:  Add brightness and contrast functionality.
 118 14:54:09 <clown> #info suggestion is to move it to Clutter.
 119 14:54:40 <clown> that last one is a bit of a surprise -- it would be cool if anyone who used Clutter had access to it.
 120 14:54:47 <API> brightness and contrast funcionality on clutter?
 121 14:55:02 <clown> yes, and lightness inversion.
 122 14:55:05 <API> something like a property on the actor or the stage?
 123 14:55:14 <clown> yes, exactly.
 124 14:55:25 <clown> there already is, in clutter, various tint and other effects.
 125 14:55:38 <clown> and an abstract class for any effect.
 126 14:55:49 <API> well, the good thing is that would allow to access to those effects to more apps
 127 14:55:55 <API> more easily I mean
 128 14:55:58 <clown> I just implemented a specific object for the effects needed for the magnifier.
 129 14:56:05 <clown> yes, exactly API.
 130 14:56:38 <clown> #action  Joseph to reply on bug to say, "yes, let's move these effects to clutter".
 131 14:56:42 <clown> done.
 132 14:57:08 <API> ok, more questions, comments, doubts in this point?
 133 14:58:30 <API> #topic CSUN Speaker Proposals
 134 14:58:31 <API> joanie, ?
 135 14:58:37 <joanie> Thanks API
 136 14:58:44 <joanie> I'll #info to be efficient.
 137 14:59:14 <joanie> #info While we are still waiting for the budget to be approved, the treasurer and Board have not yet told us we are insane.
 138 14:59:34 <heidi> Just to clarify, are we talking about the conference end of Feb to March in San Diego
 139 14:59:35 <heidi> ?
 140 14:59:39 <joanie> #info We anticipate being able to send two speakers to CSUN, the key being "speakers"
 141 14:59:41 <joanie> heidi yes
 142 14:59:49 <heidi> THanks
 143 15:00:06 <API> heidi, he have been talking about that conference last meeting, we decided to not use the budget for a booth
 144 15:00:07 <joanie> #info CSUN call for papers typically opens in September. It's now August.
 145 15:00:17 <API> but it would be still interesting to send peoople to talk about GNOME
 146 15:00:30 <joanie> #info Now might be the time for anyone who would make a good speaker to consider speaking and thinking about topics.
 147 15:00:33 <joanie> (done)
 148 15:01:37 <API> I will use the "lets use native english speakers" poker ;)
 149 15:01:46 <joanie> hahaha
 150 15:02:01 <joanie> I will suggest that is nonsense.
 151 15:02:16 * clown wonders how many native english speakers are present.
 152 15:02:24 <joanie> exactly
 153 15:02:30 <jjmarin> lalala
 154 15:02:40 <joanie> jjmarin: ;-)
 155 15:02:42 * clown there's a native english singer present.
 156 15:02:54 <prlw1> I'm a tenor :-)
 157 15:03:02 <API> well, it seems that there aren't too many people there
 158 15:03:10 <API> anyway, we don't have all the people here
 159 15:03:13 * heidi looked at this conference last year and it is in direct conflict with the main CS educators conference and can't go
 160 15:03:17 <API> for example, eitan usually goes there
 161 15:03:24 <clown> well, it's something for me to contemplate while on vacation next week.
 162 15:03:33 <joanie> clown: +1
 163 15:03:36 <API> so how about send a mail to gnome-list abou this?
 164 15:04:02 <API> and that clown comment is also a +1 to my proposal of use the ml
 165 15:04:11 <joanie> #action Joanie will send a mail to gnome-accessibility-list suggesting people be thinking about presenting at CSUN.
 166 15:05:03 <joanie> that ai is brought to you by the suffix -ing
 167 15:05:47 <prlw1> I could redo my fosdem talk on dasher/opengazer/nomon/ticker ?
 168 15:06:10 <joanie> prlw1: I've not seen the talk, but potentially, yes.
 169 15:06:25 <joanie> like I said, call for papers is not for a month
 170 15:06:31 <joanie> but time travels quickly
 171 15:06:43 <joanie> so I'm asking people to start pondering the possibilities now
 172 15:07:58 <clown> joanie, so the steps are (1) propose a paper, (2) get confirmed as a speaker, (3) apply to gnome-foundation?
 173 15:08:10 <joanie> yup
 174 15:08:26 <clown> any chance gf will say "no" at step 3?
 175 15:08:41 <clown> or, you could be a confirmed speaker, but not receive funding.
 176 15:08:43 <joanie> assuming our budget gets approved, which I think it will
 177 15:08:52 <clown> ok
 178 15:08:53 <joanie> we have budgeted two speakers
 179 15:08:56 <joanie> from our team
 180 15:09:07 <joanie> including the possibility they might need to travel from Europe
 181 15:09:42 <mgorse> Are we budgeting for people to attend the whole conference? Or just come one night in order to give a presentation?
 182 15:09:46 <joanie> and I cannot imagine our team going crazy and submitting tons of papers that get accepted.
 183 15:10:10 <clown> i can  imagine it.  but I doubt it will happen that way :-)
 184 15:10:10 <joanie> mgorse: more than a night, less than the full conference
 185 15:10:20 <joanie> hah
 186 15:10:59 <joanie> for fy2013 we budgeted much more for CSUN
 187 15:11:25 <joanie> in the hopes that we'll have a real "story to tell" then
 188 15:11:58 * clown once upon a time ...
 189 15:12:07 <joanie> in a galaxy far, far away
 190 15:12:17 <joanie> API the natives are getting restless
 191 15:12:20 <joanie> I think we can move on
 192 15:12:28 <API> yes, we don't have much time
 193 15:12:31 <heidi> On a related note, does anyone know the dates for the GNOME Summit in Boston this fall?
 194 15:12:38 <API> do you want some #infos for the last chitchatting?
 195 15:12:42 <joanie> heidi: almost certainly columbus day weekend
 196 15:12:48 <joanie> API not really
 197 15:12:49 <joanie> lol
 198 15:12:56 <heidi> joanie: Thanks, last year it wasn't for some reason...
 199 15:12:58 <API> ok
 200 15:13:06 <joanie> piggybacking on another event
 201 15:13:15 <API> #topic Testing Distro
 202 15:13:21 <mgorse> heidi: Linux Plombers was in Boston last year, and it looks like it moves around, so it won't be there this year
 203 15:13:26 <API> is there something to talk about it?
 204 15:13:28 <joanie> Yeah, I added that one
 205 15:13:35 <heidi> joanie: Thanks
 206 15:13:41 <joanie> I'm going to be my "direct" self I'm afraid :-/
 207 15:13:48 <joanie> so.... testing distro was super useful
 208 15:13:52 <joanie> and all kinds of awesome
 209 15:14:06 <joanie> but I think most of us (all of us but clown???) are no longer using it
 210 15:14:22 <joanie> and Javi is having difficulties spinning the "last" one
 211 15:14:38 <joanie> so I'm wondering if it is time to move on w.r.t. the testing distro
 212 15:14:48 <clown> yes, I am waiting for the latest spin -- "we" promised it to AEGIS europe for their user testing.
 213 15:14:48 <joanie> clown? others?
 214 15:15:10 <clown> alas, we need it.
 215 15:15:14 <joanie> aleiva: jjmarin: is jhernandez in shouting distance?
 216 15:15:37 <clown> is korn here?
 217 15:15:50 <API> what kind of problems with the testing distro is jhfernandez having?
 218 15:16:08 <clown> he was also very interested in having it as a basis for some other a11y stuff.
 219 15:16:23 <joanie> clown: Is he willing to pay Emergya to do this work?
 220 15:16:24 <jjmarin> joanie: nop. he's a at home. He's a little bit sick I'm afraid
 221 15:16:54 <joanie> clown: because it seems to me that if the "team" who needs it is really AEGIS because Peter wants it
 222 15:17:06 <joanie> and Javi is crazy busy (and sick! :-( )
 223 15:17:11 <joanie> and having build problems
 224 15:17:22 <joanie> clown: aleiva you see the above?
 225 15:18:20 <aleiva> �sorry, rebooting
 226 15:18:35 <joanie> API getting back to your question, it's come up in the minutes of previous meetings. Some of it is, I believe, packaging issues. Others is that the build service goes down a lot.
 227 15:18:46 <joanie> aleiva: meaning you are back now?
 228 15:18:53 <joanie> or going away?
 229 15:18:56 <aleiva> just back now
 230 15:20:03 <joanie> #info Given the amount of trouble Javi has been having with the testing distro "final spin," she questioned who all is using it.
 231 15:20:29 <joanie> #info Joseph indicated that it is required, "promised to AEGIS europe for their user testing."
 232 15:20:55 <aleiva> well, we're volunteers
 233 15:21:05 <aleiva> so, when we "promise" something exactly?
 234 15:21:15 <joanie> #info Joanie thinks that AEGIS user testing, while valuable, goes well beyond the scope of GNOME Accessibility Team needs and what the volunteers (i.e. Javi) can be asked to do.
 235 15:21:19 <joanie> aleiva: patience
 236 15:21:42 <aleiva> the mother of science
 237 15:21:43 <aleiva> :-)
 238 15:22:11 <jjmarin> :)
 239 15:22:20 <API> well, anything else in this point?
 240 15:22:29 <joanie> ugh
 241 15:22:29 <aleiva> anywy, we're open to any talk about this
 242 15:22:31 <aleiva> API: nop
 243 15:22:35 <joanie> everyone just wait ffs
 244 15:22:36 <joanie> ;-)
 245 15:22:44 * API stops to poke people
 246 15:23:06 <joanie> #info Joanie would encourage the AEGIS testing folks to find some other means for achieving their needs/goals in this area.
 247 15:23:16 <joanie> done.
 248 15:23:18 <joanie> sorry
 249 15:23:27 <joanie> language is such a delicate thing
 250 15:23:29 <joanie> ;-)
 251 15:25:57 * API API start to poke people again
 252 15:26:01 <API> ok, anything else?
 253 15:26:25 <aleiva> nope
 254 15:26:28 <jjmarin> nop
 255 15:26:54 <API> ok,
 256 15:27:00 <API> #topic miscellaneous time
 257 15:27:14 <API> so, someone has something to say
 258 15:27:17 <API> short
 259 15:27:20 <API> not scheduled?
 260 15:27:35 <aleiva> see you guys at berlin :-)
 261 15:28:31 <fer> see you!
 262 15:28:54 <jjmarin> \o/
 263 15:30:05 * heidi waves
 264 15:30:23 <API> well as is seems that nobody needs to add anything
 265 15:30:31 <API> I will close the meeting
 266 15:30:35 <API> #endmeeting