GNOME.org
 

Re: [g-a-devel] Not so easy: About pyatspi2 deprecationg and the merge of ATK and AT-SPI

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]