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

[Willie Walker <William Walker Sun COM>]

On Wed, 2007-08-29 at 15:14 -0300, Carlos Eduardo Rodrigues Di�es
wrote:
> > * Eliminating the Bonobo dependency from accessibility stuff in GNOME.
> >   Note that this doesn't necessarily equate to eliminating CORBA.
> 
> I really have no idea how much impact this would cause. I learned only
> basic things about Bonobo and understand that it only turn easier the
> IPC work. CORBA appear to be much more low-level and I have no idea
> how it will still be used in GNOME desktop. I'm goingo in D-BUS
> direction, since it's appear to be much more simple for desktop IPC
> and it's also appear to have much more documentation available.

Keep in mind that migrating to D-BUS would end up causing incompatible
changes for gnome-mag users (e.g., Orca would have to now talk D-BUS
instead of CORBA/IDL).  

If the community moves in this direction, this incompatibility
represents an opportune time to really discuss what we think is the
'right' approach given our collective experiences.  As such, it really
is great that you opened this discussion up on the list.  I thank you
for that, even if you might eventually regret it.  :-)

> We must have a compositor and appear that the best path, considering
> the effects cited in the other messages, is to use Metacity, since
> it's still have a good architecture (thanks Sandmann) IMHO. Moreover,
> in reply to Eitan (I send if the wrong e-mail, so it doesn't appear
> yet in the list), I cited about an way to keep the resolution of text
> and SVG images in the magnified image

This brings up a very good point with respect to what we want the beast
to do.  There was some discussion of alpha blending, but I wonder if we
want to be able to support more sophisticated things.  For example, do
we want it to re-render text with a larger/different font and/or with a
different foreground/background?  Do we want to do so for the entire
zoomed area, or do we want to do selective levels of zooming and image
filtering across the area (e.g., the character/word/line around the
caret gets special treatment)?

My mantra for Orca has been "let the user requirements drive the
architecture, not the other way around."  I think the same should apply
here.  I'd really like to encourage the involvement of end users in this
discussion.  If we are going to redo the GNOME magnification world (I
think we should), we really need to take a step back and understand the
user models.

> Yeah, this is something possible from my POV and this is something
> that happened with the introduction of the colorblind-applet. Probably
> we can have a configuration option in System => Preferences where the
> user can adjust magnification options and have the API where ATs can
> tweak the magnifier behaviour on the fly.

Sounds good.  I think the things to think about are what the user models
will be (sorry to be a broken record).  I suspect we will have
magnifier-only users as well as magnifier plus speech and/or braille.
When we get a better understanding of that, we should then work with
users to determine where the best place(s) for magnification
configuration/control should be.  

It very well may be that Orca should configure/control it all, but I'd
still like to discuss the various alternatives.  If we end up going down
the path of Orca configuring/controlling it all, we should also consider
what to do in other spaces (dyslexia, learning disabled, etc.) and where
those things should live.  Do we want separate assistive technologies
for them?  Do we want Orca to turn into a manager of assistive
technology plug ins?  Etc.

>  I think that we must things simple and
> only engineering a complex solution with lots of options with concrete
> use cases that can't be addressed by the current API.

Ha - given the various user requirements I've seen to date, the
complexity will be there.  It just depends where the complexity lives
and whether or not it makes sense to spread it across processes.

> If there is no one oppositing to implement gnome-mag API inside
> metacity I will start this work without further discussions (I think
> that I was the only one against it in the past :-) starting with the
> actual gnome-mag API, since this is the basic that we need, than we
> can start to think how these interaction can be done, since they must
> be carried on by the WCM.

For the path of least resistance, least disruption, and least design by
committee, supporting gnome-mag (as it exists today using Bonobo/CORBA)
in metacity might be the easiest thing to do.  We could then continue
focusing on the current approach where Orca drives gnome-mag and
provides the UI to it.

If the plan is to ditch Bonobo/CORBA and basically rewrite the IPC
mechanism to gnome-mag, however, I think we should take pause and
rethink the approach to the magnification.  BTW, I'm not sure the
concern about metacity rejecting Bonobo/CORBA is truly valid.  Because
Metacity is an application that must be accessible by Orca, it already
participates in the AT-SPI and bears the Bonobo/CORBA requirement for
communicating via the AT-SPI.

> > Are you coming to GNOME Boston 2007?  Magnification is one of the
> > critical things we want to talk about for the accessibility summit.
> 
> Ow... it would be a dream :-), but I don't have passport and don't
> have money, so no :-(, but I really like to know what become
> discussed.

Bummer.  This discussion, however, will be of great use for the summit
and we should continue having it.

Thanks!

Will