Re: D-BUS based magnification API

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:


Attachment: signature.asc
Description: This is a digitally signed message part

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