GNOME.org
 

Re: [g-a-devel] Java ATK Wrapper unimplented methods

Hi Alejandro,

Thanks for the email.
 
For now it would be useful to get some feedback on what might be a good idea to focus on implementing.

 Initially, I will not focus on the deprecated methods. It is true that those could be important if someone is using an old version of pyatpsi2/orca, but if that scenario, it will be really likely to be using an old version of java-atk-wrapper too.


Putting old versions of at-spi2-atk aside for a moment to talk about java: I am testing this stuff on the latest version of java which I would imagine means that anyone using older versions of java is not likely to benefit from this work. Maybe this is a bad decision but I am using 8 and I note that some of the swingset2 test cases really have not been working as bug reports from old, say they should with the latest accessicer to test them with. With all that in mind, I have not really keen to waste time figuring out why deprecated methods aren't working. In other words the rationale has been is to update the methods and make sure they are working properly rather than waste time fixing something that is eventually going to have to be reimplemented anyway. Also because updating deprecated methods is comparatively easy task: I already got the component interface stuff under control, last night. [1] I can't see the value stuff taking long. That said, the text stuff looks a bit awkward because of the AtkTextGranularity implementation that needs to happen though so it might be a fair idea to put that aside for the time being if it's going to prove time consuming.[2]

Alejandro has indicated the text interface as quite important so I am thinking this might be the best place to start but I am a bit concerned about what I am seeing with the focus stuff too.

 I didn't know that there were problems with the focus. If that is also a problem, then it is true that it would be also a good first task.

Yeah it seems to be a problem alight.  That said, I need to develop and up to date test case for it to be sure that what I am seeing is what I should be seeing. I've just been using swingset2.jar and Notepad.jar. I trust Notepad.jar a lot more than I trust swingset2 to be honest since that's using a very old version of java and seems to crash accessicer almost every time I try to run it! Accessiser does not see a lot with more else than Notepad.jar (for that reason if anyone knows where I can get hold of the source code for Notepad.jar this would be a welcome thing!) At the moment it seems like the focus problems could be caused by any number of things. I need to develop a test case, I can rely on.
I am also quite keen to further investigate what's happening with the Windows interface signals in jawobject.c.

Some context from the past (so the situation when java-atk-wrapper was maintained by Sun/Oracle). at-spi defined some window related windows, and expected applications to send those signals. For some reason, there isn't any ATK interface defining those signals. But as I said, they were expected in any case. So what in the end each implementors (like gtk) were defining and sending those events on a specific format, and the atk bridge forwarding them, because it knew the format. Really error-prone and without any documentation at all. After a quick look on java-atk-wrapper, that was also done there, defining those events on jawobject.c

Since Atk 2.2, there is an interface AtkWindow, that only define those signals:
https://developer.gnome.org/atk/unstable/AtkWindow.html#AtkWindow.signals

So, my advice is removing those signals from jawobject.c, and implement/wrap AtkWindow where it makes sense. If you want an example, this is how it was done on clutter:
https://git.gnome.org/browse/clutter/commit/?id=a9690a4a5e8604652048f32e2ea188aa40e0ae95

I really don't like the way that jawobject is set up so I think this is a great piece of advice and thanks for the extra information about Oracles perspective on that work. I agree though java is a means to an end in this, we are best using a structure which is consistent with the ATK API for this work.

Before I go do ahead on messing with signals though I think what I should really do is get a reliable test case together. I am reluctant to start hacking away at stuff that can affect signals without that. I will get on that and add it as an example in your github examples repo so it's there, if you think this would be useful? [3] Any tips on this are very welcome!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]