> I've more or less finished the Enhanced Zoom plugin for Compiz, and it > is able to do much of what orca already does.
Yeah! Do you have a pointer for where I can grab an eZoom to play with on Gutsy? In addition, do you have a user base that you've been working with? I'd like to read the archives to get a better understanding of what their questions/requirements are. > I was testing out the dbus interface with orca and realized that the > way orca handles text-caret events is somewhat less than optimal for > ezoom. Do you have a pointer to the DBUS interface? > With mouse events, everything works perfectly. You can use orca > instead of the built in mouse panning to control ezoom over dbus. It's > dead on. However, text caret events are not. If eZoom is getting all that it needs via the AT-SPI, I'm thinking Orca should only reserve communicating with eZoom for things that cannot be gleaned via AT-SPI events. These include things such as Orca's flat review mechanism and SayAll support. > Ezoom uses a rather simple interface for this: ensure_visibility. The > idea is to pass it exactly what you want to make sure is visible, > nothing more or less. An x1/y1 and an x2/y2 pair in screen > coordinates. Ezoom will calculate how much it needs to move and in > which direction by it self. You can also pass "scale: true" to make it > adjust the zoom level (this is somewhat untested except the most basic > technical test). Without having observed what it happening, I'm guessing this seems to go on the principle of least movement. We've had end users request certain behaviors depending upon what they are doing. For example, when typing, some users want the caret to stay in the middle of the magnified region. I suspect they will want the same for the character-by-character movement of flat review. Handling this might require a bit more of a sophisticated communication mechanism between Orca and eZoom. One thing I was thinking about was a more general purpose DBUS broadcast mechanism that clients such as Orca can use to announce where it is listening and why. This would allow plugins such as eZoom to make informed choices about where to move the magnifier. Will _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
