Re: [g-a-devel] D-BUS based magnification API

["Carlos Diógenes" <cerdiogenes gmail com>]

Hi Eitan,

2007/8/28, Eitan Isaacson <eitan ascender com>:
> 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.

I didn't think about this possibility. This is very interesting,
although very difficult to implement IMHO, since each application will
have to implement a magnification logic. Maybe this logic can be
implemented in a library, making the problem less relevant, but for me
doesn't appear to be and ideal solution. Maybe, if we can instantiate
more than one magnifier (this is not supported yet), then each
application can create a zoom-region in the place where it want a
magnification, but this still leave problems with stacking order.

I thought in a simpler scenario that can give use the same effect. Now
in the GNOME desktop, and also in KDE, SVG libraries are in spreed
use. In the GNOME desktop cairo is being used in every place. Firefox
3 will also use it. OpenOffice appear to be using it too. So, the way
I thought to have SVG is to wrap cairo and, when the magnifier is
activated, instead of draw (or instead of only draw) in the
application window, an SVG representation is created and the magnifier
is notified about it and about updates in this SVG. I thought in this
in something in the same layer as AT-SPI. Then when the magnifier
compose the final screen it will draw the window pixmap and render the
SVG.

>
> > 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).

Good point Eitan... I take note of this... add an interface so ATs can
enable/disable mouse tracking.

>
> 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.

Yeah... I also think this way. I only don't do this in gnome-mag due
the lack of time and because most time I prefer to do other things in
my free time, since mouse tracking is working with Orca and LSR :-)

>
> > 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

Amazing! BTW, what program do you used to do this screencast?

>
> Cheers,
>         Eitan.
>
>