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

["Kristian Lyngstøl" <kristian bohemians org>]

On 8/30/07, Carlos Eduardo Rodrigues Diógenes <cerdiogenes yahoo com br> wrote:
> 2007/8/29, Peter Korn <Peter Korn sun com>:
> > Hi Carlos,
> >
> > In two places you mention going with Metacity:
> >
> > > ...
> > >
> > >> * Understanding where the masses are going with respect the
> > >>   composite extension manager.  Is it metacity, compiz, something
> > >>   else?  Where/how does gnome-mag fit in this new world?
> > >>
> > >
> > > There was a big discussion about the Metacity compositor and compiz:
> > > http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00011.html
> > > and GNOME appear that will not replace Metacity by Compiz. The
> > > discussion is quite old and things maybe changed, but I didn't saw any
> > > other discussion about a replacement, so the path, IMHO, is metacity.
> > >
> > > If Metacity doesn't introduce composite effects some day (something
> > > that I doubt) we already have basic composite (let's say that the code
> > > to track windows is there :-) being done in gnome-mag.
> > >
> > > 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, that is: 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.
> > >
> > > In this world, gnome-mag doesn't fit.
> > >
> > >
> > > ...
> > > 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.
> > >
> > > The needs for the applications cited by Peter Korn can also be addressed here.
> > >
> >
> > I would like to suggest more study of the Compiz option before making
> > the decision to work with Metacity instead.  While today it seems no
> > desktop UNIX distro is prepared to replace Metacity with Compiz, it does
> > appear that many (most? all?) are looking to have it as a user-available
> > option.  I continue to believe that (a) Metacity is largely in
> > maintenance mode with new sexy development happening in Compiz; (b) we
> > can do a lot more, and do it more naturally and easily in Compiz; and
> > (c) if we do a great job with magnification in Compiz, we will be able
> > to help move folks over to Compiz, either as a default user-choosable
> > option, as a trivially user-installable option, or even as the eventual
> > default window manager.
> >
> > This is clearly something we need to socialize with the desktop folks,
> > the Compiz folks, to determine how much of a..c above are in fact the
> > case.  But I would especially hate it to be the case that we do a lot of
> > work to make Metacity great for magnification, only to see it slowly
> > fade away (or have to argue for folks to keep it when their
> > desire/tendency is to move to the new sexy thing).
>
> This is really a great point to consider. I don't know how is the
> metacity compositor development, but I think that we are not getting
> much on this and that users will move to the new sexy thing, due the
> reaction these things are causing on people. I think that you are
> right, the most sane thing to do will probably extend the
> accessibility resources on compiz. What you propose to we start to
> socialize with destkop and compiz folks?
>
> If some ATs will communicate throw AT-SPI, like in the examples that
> Willie cited, the compositor must support CORBA (something that I
> believe that will never be accepted), or re-implement AT-SPI over
> D-BUS (a work that I think people would like to avoid, or not, as Li
> commented), or create a bridge layer: compiz (dbus) <=> bridge <=>
> at-spi (corba), so ATs can communicate with the accessibility
> resources that reside inside compiz.

Due to the plugin interface in Compiz, there's nothing really stopping
us from creating an AT-SPI plugin (with CORBA), but I'm not sure
that's what we really want or need.

As Willie pointed out, there may be other use cases involved, like
highlighting what is currently being read out, and creating an AT-SPI
plugin (or going further) would mean that this plugin would have to
somehow communicate with other plugins, a task that is possible, but
not something I advice if it can be avoided without too much of an
overhead.

From my point of view, it makes more sense to do all this through
D-BUS instead, even if there is slightly more overhead. The D-Bus
plugin in Compiz is mainly for changing specific settings (or trigger
actions) inside Compiz or Compiz plugins, so it would have to be
adjusted to be able to listen for more general communication, but
that's doable and something I am sure other Compiz developers would
see the use for.

Even though this could indeed create a situation where Orca (or other
smaller apps, a bridge as you say) fetch data from AT-SPI over CORBA
and pass them on over D-Bus, is this really a big deal considering the
benefit? From Compiz' point of view, it would greatly simplify
data-gathering. But it should be more than just ROI changes; that's
not enough to decide whether we are going to care about the
information or not, or how we will treat it. I see something similar
to AT-SPI, where you can tell a text-caret from a focus event.

I also think it makes a lot of sense to move much of the configuration
to the magnifier. Ezoom has already had to do this because the logic
exist inside the plugin, and as such it gets configuration "for free"
along with other Compiz plugins, but even if it could be configured
through Orca, I'm not sure why it would want to be. Specially not if
we create an API as mentioned above which Ezoom would of course use.

I've been following this thread closely, and I think it's a bit of
overkill to start working on a magnifier inside Metacity or doing
major work to Metacity at this point to improve gnome-mag. Compiz does
require GL, and it is not without problems with regards to drivers,
but I do believe that the desktop is moving in the direction of a
composited window manager with GL effects, be it Compiz or something
else.

As such, Metacity should either be turned into something that can
provide the same level of effects that Compiz does, or it should be
left as-is, as a great window manager in maintenance mode. Otherwise
all I see is a lot of work being poured into Metacity that'll be
mostly forgotten in a few years, or considered a fall back for the
people who still don't have a GL card.

- Kristian