Re: D-BUS based magnification API

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

Also, to the extent that Compiz isn't everywhere because of lack of 
video hardware... I think it is worth comparing what we can do without 
GL to what we can do with it; the kind of functionality in products like 
ZoomText (that we can most easily do with GL) that users like and use; 
and the cost impact of requiring what is now essentially a $50 add-on 
video card with GL support (and which can be found in nearly every new 
system being sold today) vs. the $600 software ZoomText. 

I personally believe that making a fantastic magnification (and reading 
assistance) system that requires 5-year old video hardware with a 
minimum of GL support & that the user install a new (and tested) window 
manager is a better alternative to much more limited functionality or 
something that is much harder to develop/maintain/etc. but which works 
at least somewhat with older video hardware and with the window manager 
that comes as a default on the desktop today.


But you are closer to the code than I am.  Perhaps the downsides to 
going the Metacity route are more minimal than I suggest they are...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.