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? > 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. > ========= > > 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. > > 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: 1. List agree on which specific questions can/should be answered by experiment --time passes-- 2. Experimentalists get together and design appropriate tests in quest to answer questions from step 1. --time passes-- 3. Experimentalists calculate & Analyse results --time passes-- 4. Experimentalists present results to list for fresh discussion --time passes-- 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. Assuming we are now at step 0 and cannot go straight to step 7 (without breaking stuff) then maybe it would be a good idea to not leave steps 1-6 until 7 is urgent (if it would ever become so?). Not sure. Magdalen (Magpie) _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
