1 16:26:18 <API> #startmeeting
   2 16:26:18 <tota11y> Meeting started Thu May 31 16:26:18 2012 CET.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
   3 16:26:18 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
   4 16:26:43 <API> #topic libatpi, gobject-introspection and atspi+atk
   5 16:26:56 <API> mgorse, yes, when joanie told me about that
   6 16:27:02 <API> I also didn't remember
   7 16:27:08 <API> but then I remember that bug
   8 16:27:28 <API> as I said on the mail, my main concern is doing two
   9 16:27:42 <API> hard-work ports
  10 16:27:56 <API> one to pure-gobject-introspected libatspi
  11 16:28:08 <API> and the other to atk, if finally one API is dropped
  12 16:29:21 <mgorse> I think we need to decide whether we're going to switch to using atk for the AT-side, or figure out if it's feasible, and then decide what to do
  13 16:30:08 <mgorse> It might also need some atk changes. Ie, orca is both an atk implementor and a consumer, and atk_get_root() becomes ambiguous
  14 
  15 [Editor's note: please see comment at the end of this log for clarification regarding the above statement]
  16 
  17 16:31:11 <API> yes, there are some methods that are implementor specific
  18 16:31:21 <API> in fact, and part of the confusion
  19 16:31:26 <API> some methods are atk specific
  20 16:31:35 <API> for example, those focus tracking methods
  21 16:31:42 <API> (that we already planned to deprecate)
  22 16:31:48 <API> as far as I see, are only used on atk
  23 16:32:01 <API> as a way to track the focus object
  24 16:32:12 <API> in the same way, if atk became the API
  25 16:32:23 <API> I guess that some atspi methods would be required to be moved there
  26 16:34:41 <mgorse> Hmm. We have a bug for this, right?
  27 16:34:53 <API> we have a bug for?
  28 16:35:03 <API> deprecate focus tracking methods?
  29 16:35:15 <mgorse> moving the AT-side code to atk, or investigating it
  30 16:35:37 <mgorse> but, yeah, I think there's also one for deprecating focus-tracking methods
  31 16:36:51 <API> well, there is no bug about that movement
  32 16:37:07 <API> we have just that bug about moving IPC stuff to ATK
  33 16:37:19 <API> anyway, as I said in my bug, I'm not sure about that option
  34 16:37:32 <API> I think that probably it would be better to keep ATK as the abstract library
  35 16:37:34 <mgorse> I feel like it's potentially tied in to a lot of things which we've talked about doing (ie, changing AtkUtil)
  36 16:37:40 <API> and just have an ATK implementation on atspi
  37 16:37:54 <API> yes
  38 16:38:22 <API> in that sense, AtkUtil (or any new interface replacing it)
  39 16:38:42 <API> would become an atk implementor only method
  40 16:39:00 <API> sorry
  41 16:39:03 <API> would become an atk implementor only interface
  42 16:39:22 <API> to avoid the abiguoty
  43 16:39:41 <API> well, although that could be done via documentation
  44 16:39:54 <API> again it would be good to see what others framework do
  45 16:40:16 <API> because AFAIK, we are the only case that we have an client-side API and a server-side API
  46 16:43:47 <mgorse> Yeah. I'm not sure in general. I think UIA has both, so in that respect it seems similar to what we have now, but I'm not sure that means anything for us
  47 16:45:04 <API> well, just mention that, to get some kind of reference
  48 16:45:14 <API> or example
  49 16:45:45 <mgorse> I think it makes sense to have the API in one module if possible; the main downside would seem to be that ATs would need to port their code, but, if we're going to do that anyway, then we want to get it right, as best we can
  50 16:47:16 <API> well, in that case as you mention
  51 16:47:32 <API> one of the big cons of changing the client-side library
  52 16:47:38 <API> to just ATK (or just at-spi)
  53 16:47:44 <API> was the need to make the port
  54 16:48:05 <API> if we also have as a reason using object-introspected bindings
  55 16:48:08 <mgorse> but maybe that's the API break. Ie, if we're changing AtkUtil, then we're changing the API for implementors as well
  56 16:48:36 <API> well, that just means that if we change AtkUtil
  57 16:48:53 <API> we need to take into account that ATK could be used by implementors and by consumers
  58 16:49:03 <API> or get a way to avoid being used by consumers
  59 16:50:48 <API> anyway, it seems that we mostly agree, so I think that we can end this point with some infos
  60 16:50:58 <API> in fact some of mgorse sentences are good infos
  61 16:51:00 <API> lets see
  62 16:51:27 <API> #info API bring the concern of making two API ports on the ATs
  63 16:51:36 <mgorse> I think we should have a bug and investigate more over the next week, perhaps specing out some changes to AtkUtil, etc
  64 16:51:46 <API> #info on mgorse words: "I think we need to decide whether we're going to switch to using atk for the AT-side, or figure out if it's feasible, and then decide what to do"
  65 16:52:00 <API> #info on mgorse words: "It might also need some atk changes. Ie, orca is both an atk implementor and a consumer, and atk_get_root() becomes ambiguous"
  66 16:52:37 <API> mgorse, well, in summary we are thinking about dropping one API because they are too similar
  67 16:52:50 <API> so first step is checking the differences
  68 16:53:03 <API> ie: what ATK has that atspi has, and viceversa
  69 16:53:18 <mgorse> makes sense
  70 16:53:38 <API> mgorse, joanie but do you agree that for the moment the plan of deprecate atspi and start to moving ATs should be postponed?
  71 16:53:58 <joanie> API, sorry, I would have to read the scrollback
  72 16:55:45 <mgorse> I think that makes sense, although we should also work on moving atk forward
  73 16:57:26 <API> yes
  74 16:59:05 <API> #info for the moment, deprecate pyatspi2 in favour of object-introspected atspi is postponed, until we investigate more this
  75 16:59:28 <API> and having said so, I think that we can end this intimate a11y meeting
  76 17:01:16 <API> #endmeeting
  77 
  78 Note: Upon preparing the minutes, Joanie asked a follow-up question in #a11y:
  79 
  80 17:32:15 <@joanie> mgorse: in prepping the minutes.... What do you mean by this:                                      
  81 17:32:18 <@joanie>  "It might also need some atk changes. Ie, orca is both an atk implementor and a consumer, and atk_get_root() becomes ambiguous."
  82 17:32:34 <@joanie> I didn't think Orca would be an atk implementor
  83 17:33:35 <mgorse> I guess I should have said that Orca is an atk consumer and also uses a toolkit that implements
  84 17:34:10 <@joanie> aha
  85 17:34:26 <@joanie> I am going to edit the minutes to that effect.
  86 17:34:30 <@joanie> thanks!!