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