On 08/05/15 10:40, Lukasz Stanislawski wrote: > Hello everyone.
Hi, > > I'm currently implementing AT-SPI2 support for EFL library > (Enlightenment Foundation Libraries). > > First, I will explain how my toolkit is implementing a particular > feature that I have trouble with. It's called plug/socket mechanism > and allows to share images across multiple processes. A typical usage > of this feature goes like this: > 1. Process A creates UI's objects and renders them into an buffer. > 2. Process B via socket connection read's proccess A buffer and > displays it as an image. > 3. Process B forwards mouse/key events (if needed) to process A, > allowing process A to change its UI accordingly. > 4. Updated buffer is readed again by process B and image is refreshed. > > Since embeded UI looks like normally created one and can be interacted > with with mouse and keyboard - my first idea was to connect two > accessibility trees from process A and process B. It generally works, > however there are some issues: Yes, in general this mechanism seems really similar to the already existing plug/socket on ATK/at-spi2, although ... > > 1. EFL socket/plug allows one-to-many connections. As far as I > understand atspi Socket/Plug allows only one-to-one connections. The > main problem is what a call like GetParent should return when process > A UI's is embeded by multiple applications? How to solve it in atspi way? ... it is true that is a one-to-one connection. But I don't get this use case. On a multiprocess environment, usually, one-to-many means one parent process and several children processes. For example, on a (simplified) browser, there would be a main browser process, and then one additional process per-tab. So one parent (browser) and several children (each tab). FWIW, this case is properly managed on WebKitGtk using ATK/AT-SPI2. As far as I understand your use case, there is one A-type process, that creates several B-type processes. So GetParent on B's plug would be A's socket, but not a case where GetParent on A has more than one parent. I'm missing something? > 2. How do You deal with returning proper window/screen coordinates of > embeded UI's? Why is this a different case? At the end of the day, the accessibility implementation would rely on the UI object itself. So even if embedded on other UI, the base object should be able to return proper window/screen coordinates, and then forward it to the accessibility object. BR -- Alejandro Piñeiro (apinhe...@igalia.com) _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
