Re: Questions about gnome-mag + orca

[Willie Walker <William Walker Sun COM>]

I agree with David's sentiment.  Kristian, do you have what you need to 
develop a proposal?

Will

On Apr 11, 2008, at 3:06 PM, David Bolter wrote:

> Kristian Lyngstøl wrote:
> > On Thu, Mar 27, 2008 at 8:36 PM, Willie Walker 
> > <William Walker sun com> wrote:
> >
> > >  Having said all that, we have a task for "GNOME Outreach Program:
> > >  Accessibility" for someone to get paid to help take the 
> > > magnification
> > >  solution beyond where we are now.  If someone is interested in this,
> > >  please let us know!
> >
> > I'm unsure of what the plans forward for gnome-mag is. It has been my
> > understanding that it is mostly in maintenance mode?
> >
> > Before I go further into this, I'd like to sum up my understanding of
> > the magnification-related technologies involved (only listing
> > magnification-related tasks).
> >
> > Orca:
> >  - Collects data on what's going on. Mouse movement. Window focus.
> > Cursor movement, etc.
> >  - Controls Gnome-mag (soon to be over DBus?)
> >
> > Gnome-mag:
> > - Just does magnification.
> > - Can be composite manager, but doesn't require it.
> > - Uses XRender
> > - Conflicts with other composite managers (like Compiz).
> > - Has performance issues in may situations.
> >
> > Compiz:
> >  - Must be a composite manager.
> >  - Provides various plugins for accessibility, including "magnifier" 
> > and "ezoom"
> >  - Currently requires OpenGL, plans exist for other rendering engines
> > (including XRender). *
> >  - NOT the default Gnome window manager
> >  - Flexible; adapting plugins or even the core for a11y is easily 
> > accomplished.
> >  - The hardware (driver) requirements seem to be the major blocker for
> > this to really take off.
> >
> > Metacity:
> >  - Default Gnome window manager and also composite manager
> >
> >
> > With regards to Compiz, there is working going on which will make
> > Compiz less hardware dependant and generally better all around,
> > including for a11y. This is a long term effort though.
> >
> > That leaves us with a gnome-mag which, in it's current state, would be
> > by and large useless due to performance issues. I've read Carlo's idea
> > about having the composite manager draw into an off screen window
> > belonging to an other application, but I'm not sure I'm buying it.
> > Might as well just tell the composite manager to magnify to the right
> > place to begin with.
> >
> > However, making textures/window content available between applications
> > is also something that I know there is a lot of interest in. And some
> > work exist (Compatible video players can give Compiz direct access to
> > their textures through the Video plugin).
> >
> > Depending on Compiz entirely is going to be hard to sell. I am also
> > unfamiliar with Metacity code. I still believe that the integration
> > between Orca and eZoom should be finished similar to how it was
> > discussed during the Accessibility Summit, but that still leaves
> > Gnome-mag and metacity.
> >
> > I'm honestly not sure what should be done about gnome-mag. Obviously
> > the compositor in Metacity also complicates things, as metacity does
> > not currently offer any magnification, thus it basically just kills
> > performance for gnome-mag without giving much back.
> >
> > Having gnome-mag interact with Compiz isn't really had, but then I
> > believe we might as well just skip Gnome-mag all together. It's
> > straight forward to make or adjust a Compiz plugin or two to act
> > exactly like Gnome-mag.
> >
> > This introduces some code duplication though, which I see as the major
> > selling point for gnome-mag staying alive. So let's look at what
> > exactly Gnome-mag does, help me fill in the blanks as I have very
> > limited gnome-mag experience.
> >
> > - Allow external control (from orca?)
> > - One area zoomed, an other not zoomed.
> > - Mark the position of the mouse
> >
> > Having gnome-mag control these functions but the compositor actually
> > performing them seems feasable to me. This would allow gnome-mag to
> > retain a lot of it's logic, but the compositor to do the actual work.
> > This way, gnome-mag could also fall back to it's own xrender method
> > without a significant code duplication, and the experience should be
> > consistent across different composited window managers. I'm still not
> > quite convinced this is the way to go though.... It seems too much
> > like we're just striving to keep gnome-mag alive. It would, with a
> > composite manager, basically just filter and relay messages from Orca
> > or other controlling programs.
> >
> > If significant work is to be done on gnome-mag, I believe we need to
> > rethink it's place. And what to do with Metacity. There obviously
> > needs to be SOME sort of interaction between a composite manager and
> > whatever is responsible for triggering or controlling magnification.
> > I'm not sure how much magnification-code would be acceptable in
> > metacity either, or if it's even suited for it at all.
> >
> > So I guess I'm not any closer to answering my own question: What
> > exactly should be done with magnification?
>
> My 2 cents:
>
> I say move forward with composite magnification. Create dbus api for 
> compiz if that makes the most sense. Let's move forward.
>
> cheers,
> D