On Thu, 2013-10-31 at 13:51 +0100, Piñeiro wrote: > On 10/30/2013 11:08 PM, Magdalen Berns wrote: > > Hi Alejandro, > > > > Thanks for starting this thread. My two pence: > > > >> 1. Why can't we just deprecate pyatspi2 and start to use gobject > >> introspected bindings? > >> > >> As far as I know, pyatspi2 adds some wrapping over the pure > >> gobject-introspected calls. Some were done to fix some reentrancy > >> problems (although as far as I see those were moved to libatspi itself) > >> and other bugs. As mentioned yesterday, it is all about moving those > >> fixes to libatspi itself. In any case, there are some python-specific > >> wrapping, "utilities" like the emission of meaningful python exceptions, > >> that probably will be lost. > > Would you be able to provide a practical example of this? > > About bugs that are solved thanks to have a manual wrapping: > https://bugzilla.gnome.org/show_bug.cgi?id=677070 > > But again, something that I always said. There are some uncertain on > this point. Some bugs are solving at the wrapping code, but I don't know > if it is a lot of code. Just saying that we shouldn't do the change > without knowing. > > In any case, the big add-on on the manual wrapping are the utilities I > mentioned. This is also the bigger divergences on pyatspi2 API vs python > gobject introspected API. Some examples: > > * Exceptions querying interfaces: pyatspi2 throw an exception if you > query for an interface but the object doesn't implement it. With python > gobject-introspected code, you will not have it. So current code: > try: > selection = accessible.queryComponent > except NotImplementedError: > <use a fallback to get the selected object> > else: > <get the selected object using the selection interface> > > > Would need to be replaced by > selection = accessible.get_selection_iface() > if (selection): > <get the selected object using the selection interface> > else: > <use a fallback to get the selected object> > > * Registry.registerEventListeners allow to register more than one event > on one call. > * All the utility methods at utils.py > * etc >
Thanks! I think something similar was done to make the javascript bindings work because the name's of some of the interfaces (and maybe their methods - I can't remember off the top of my head) could not share the same names as those already existing in gnome-shell javasscript. > > > >> So as you can see both approaches has pros and cons. So the tricky > >> question: which use? On that specific example, in order to decide, we > >> would need to make some benchmarking, similar to this old one: > >> https://wiki.gnome.org/Accessibility/Documentation/GNOME2/ATSPI2-Investigation/IPCResults > >> > > This is a great idea. In fact, I think a well devised experiment (or > > ten) should be able answer many of the FAQ questions. > > > > One thing though, although those researching for the ATSPI2 > > investigation were clearly very knowledgeable and their tests and write > > up seemed like a great framework to use, but it is important to note > > that there is a costly mistake (or at least it seems that way from > > skimming through) in there. > > > > The study seems to have failed to consider/make note of sources of error > > which would not only tell us the precision of results obtained, but also > > probably explain why the final results so surprising to the author. > > As far as I know, the only surprise that the author found, was that DBUS > was event slower than expected. But in any case, he was already waiting > DBUS being slower. It was a bit more than that, but my main point was that taking errors into account should explain surprises. i.e. if the results are surprising the experimental method is likely to be flawed. > > In any case, those tests are really old. I was not saying re-analyze > them, but doing similar tests with the current environment. I understood that and I thought it was a good suggestion. > >> ========= > >> > >> Reducing the amount of places to update each time the GNOME > >> accessibility spec changes makes sense, would be a good idea, and it is > >> worth investigate it. But taking into account all the still not answered > >> questions, the amount of work that would need, and all the priorities we > >> have right now (like Wayland), probably this is not the best moment to > >> focus on this. Depends what 'this' is? If 'this' is just testing then it may be beneficial to have solved some mysteries. It could perhaps even make things with Wayland less problematic, I cannot say. > >> > >> Comments, questions, doubts, feedback in general? > > Whatever gets decided between those who know about this problem, it is > > great you brought this up here! If any of the ATK/libspi experts are > > keen to construct experiments and need/want some assistance with > > experimental design and analysis side of things, then I have a > > reasonable level of skill and experience in that area and would be very > > happy to get involved, if it could be useful. For now, feel free to rip > > the following to shreds but I thought of a fairly loose/vague possible > > 'plan of action' could follow on nicely from your initiative to talk > > about the issue might be: > > In an abstract way, what we would like to have is a test suite that > would allow us to measure any possible performance bottleneck on the > current environment. But not only to modify what we have, but also to > measure possible changes. For me, the more important is that we would > like this test suite to be easily repeated. That makes sense > > So in relation with the standard steps you list. > > > > > 1. List agree on which specific questions can/should be answered by > > experiment > > > > --time passes-- > Questions are basically time used on atspi calls (not only individually, > but as a whole). > > > > > 2. Experimentalists get together and design appropriate tests in quest > > to answer questions from step 1. > > What I would do is creating some tests that represents usual tasks from > an Orca user. Something like: > test1: Using gnome-shell: launching apps, switching apps, overview, > removing/adding favourites from the dash > test2: Writing, launch gedit, write text, change format, navigate > through menus, > test3. etc Can you elaborate on this or, perhaps narrow it down to a single example? I am a bit confused about how comparisons between the two api's could be implemented using this kind of system. > > Not sure if we should do this tests manually, or using scripts. There > are advangates of using scripts, but could affect the results, and are > somewhat synthetic. > > > 3. Experimentalists calculate & Analyse results > > Well, I guess that ths is the tricky part. Ideally I would like the test > suite to output information about previous tests and really automatic. > Something like. > test1: > atspi calls: getRole xxx times called, yyyy average time per call > getAccessibleName zzzz times called, bbbbb average > time per call > etc > > > > > --time passes-- > > > > 4. Experimentalists present results to list for fresh discussion > > > > --time passes-- > > Probably the first time we run that, could lead to current bottlenecks. > But as I said, another reason if having something to try changes, to > avoid regressions on performance. > > > > 5. Developers decide on the change based on results > > > > --time passes-- > > > > 6. Developers decide how best implement action from step 5. > > > > --time passes-- > > > > 7. Actual codes get written to implement changes decided in 6. > > This is not clear. As I said, one of the ideas of measuring, is testing > a possible change. I just meant at that stage people would finally be able to act on the information discovered by taking tests and analysing the results. Essentially what I was driving at was that without the information there is nothing anyone can be sure of so it is probably worth answering the questions and, if that can be done sooner rather than later it may be worth it in the long run. Thanks, Magdalen _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
