Hi Carlos, > I also would like to now if someone have interest in the concept of an > 'unmanaged' zoom region; that is, a zoom region that have content > defined by the application using the API. Although this is something > that is in gnome-mag API, I don't know if this is working. Maybe we > can remove this from the new API. > I didn't know this was possible, that is very cool. I think there is space for this kind of feature in the future. For example, Firefox 3 has a zoom page capability. Potentially Firefox could draw the zoomed page to the unmanaged zoom region. Talking to some X11 people also gave me the impression that the only way to get zoomed vector data (like scalable fonts and cairo drawing ops) is client-side, since the X server rasterizes stuff fairly early. I have heard more then one X person say that this should probably come in the form of the X client talking directly to the magnifier. So perhaps in the future GTK+ will somehow communicate with gnome-mag directly and provide scaled data. > Today the mouse tracking mode is managed by clients applications, but > appear that the AT developers would like to see this feature moved > inside the magnifier. I don't see problems with this, but I think that > we must also maintaim the possibility to also control the mouse > tracking logic by external ATs, since these applications track more > information about the environment and can alter this mouse tracking > logic. I think the main capabilities that ATs need is to turn on and off mouse tracking quickly. For example a user might choose to track cursor AND focus. When the cursor moves, the tracking should be mouse tracking, when the focus changes the zoom region should go to the focused element. Besides that I see two main mouse tracking modes: 1. Cursor is ALWAYS in the center of the zoom region. 2. Cursor position is relative to zoom region position (the way ezoom behaves by default). All in all I think mouse tracking is simple enough that it really could be done better by gnome-mag then by shooting a zillion IPC calls for moving it. No semantic information about the desktop, like focus or caret position, is needed. > I saw some interesting comments about users that > would like that what they are typing be in the center of the > magnification window. This doesn't appear to be difficult to use in > the actual gnome-mag API. This just appear to be the same logic to > track the mouse in the center of the magnifier window. > This has been done in LSR with it's magnifier perk. I think the AT should be controlling this, since it could do smarter things like, being aware of justification, text direction, etc. I made a screencast of it a while back: http://monotonous.org/files/lsr-gnome-mag.avi Cheers, Eitan.
Attachment:
signature.asc
Description: This is a digitally signed message part