...
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.
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.
Everything that is done in ZoomText can be done in gnome-mag and
without using GL, due the power of the XRender extension. A thing that
I have in mind, but I will not address if we decide to move
magnification inside a compositor, is change how gnome-mag draw the
magnifier image from:
Recevie XDamage and Window related events => Composite the desktop
image in an off-screen drawable => Fetch the desired portion to be
magnified to gnome-mag memory space => Apply filters and magnify =>
Send to the magnifier window the magnified image.
to:
Recevie XDamage and Window related events => Composite the desktop
image in an off-screen drawable => Use XRender to magnifiy in the
magnifier window.
XRender can also be used to apply some filters while magnifying, like
invert colors (maybe brightness and contrast manipulation is also
possible), but if a colorblind filter must be applied we must fetch
the parts of the screen, turning the magnification similar to the one
that we have today.
This will have a great impact in performance IMHO, since various
drivers accelerate the XRender extension.