Attachment '20120531_log.txt'
Download 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!!
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.