After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 519080 - Provide better integration with COMPOSITE managers
Provide better integration with COMPOSITE managers
Status: RESOLVED WONTFIX
Product: gnome-mag
Classification: Deprecated
Component: API
unspecified
Other All
: Normal normal
: ---
Assigned To: bill.haneman
bill.haneman
gnome[unmaintained]
Depends on:
Blocks: 501426
 
 
Reported: 2008-02-27 15:55 UTC by Willie Walker
Modified: 2011-10-14 10:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Willie Walker 2008-02-27 15:55:38 UTC
This is a "GNOME Outreach Program: Accessibility" task for candidates to help get us on a path for much more compelling support for magnification and other new and innovative ideas for accessibility.

Please refer to the "TASK: Magnification" section of
http://live.gnome.org/Accessibility/GOPA for detailed information on the task.
Comment 1 Kevin Kubasik 2008-05-01 07:31:23 UTC
So, there is currently a plugin for compiz that offers about 80% of the ZoomText functionality, I'm not 100% sure I see what this goal is supposed to accomplish.. integration of that plugin with gnome-mag? Simply making gnome-mag better at determining how it should interact with X? 
Comment 2 Carlos Eduardo Rodrigues Diógenes 2008-05-01 21:16:02 UTC
Hmm, what plugin is this? Do you really test ZoomText?

I know that we have a platform that permits us to develop a magnify as good or better then ZoomText, but this need some man power to do the work.

Your point about this bug is good, maybe it must be renamed, since sometime ago everyone involved in GOPA agreed that gnome-mag must fade-out and future developments must go in COMPOSITE managers.

I think that some work can be done in gnome-mag so it can work better when a COMPOSITE manager is running, since many users will still use it, so make the transaction smooth is a good thing to the user. The kind of work that I'm talking about is not use COMPOSITE when a COMPOSITE manager is already running and give to the user an usefull message.
Comment 3 Willie Walker 2008-05-06 17:40:53 UTC
Hi All:  

See also http://mail.gnome.org/archives/gnome-accessibility-list/2008-May/msg00000.html, which was composed by the eZoom author.
Comment 4 Willie Walker 2008-05-28 01:39:09 UTC
Just to make this official. This comes from Kristian Lyngstøl, who now owns this task:

Background
=======
Magnification under GNOME today is limited to the use of gnome-mag,
optionally enhanced by Orca. It is made difficult by conflicts with
composite window managers which are the new trend.

In addition to this, gnome-mag and Orca integration relies heavily on
ORBIT/Bonobo, which is on it's way out. While it was discussed at
GNOME Boston 2007 to keep ORBIT around for accessibility only, it was
concluded that this would require the accessibility community to
maintain ORBIT, which is not reasonable.

For these reasons, and the wish to generally improve magnification,
the "GNOME Outreach: Magnification" task has come to be.


Summary of Goals
===========
1. Investigate exactly which features exist in gnome-mag and how they
differ from their equivalents in Compiz Fusion. Investigate what
information composite window managers could be interested in getting
from Orca that they currently are not requiring.
2. Create a D-Bus based communication protocol to accommodate
communication between Orca and a Composite Manager.
3. Give Orca the ability to directly configure accessibility parts of
a composite (window) manager with minimum visual changes to the
current UI.
4. Mirror the functionality that gnome-mag has into Compiz.
5. Create a hilight plugin in Compiz Fusion using the new D-Bus interface.


Details
====
1.
We want an interface that can stay stable, simple yet powerful. The
point of the initial investigation is to break down what exactly the
communication protocol needs to accommodate. The goal is to make
information available from Orca without taking full control of the
composite manager.

This investigation will also be a requirement for being able to mirror
gnome-mag functionality in Compiz Fusion.

2.
Creating a D-Bus interface is the true core of this project. The idea
is to avoid locking ourself to a specific application, be it Orca,
Compiz or something else. It should be a fairly straight forward process.

The interface should also allow for discovering what is available. A
composite manager might support magnification but not highlighting,
and allowing this to be discovered would enable us to gray out the
features in a configuration UI (or otherwise indicate that they are
not available).

3.
Orca has done a magnificent job uniting the different accessibility
features, and is able to control gnome-mag without requiring the user
to be aware that they are in fact two separate applications. Ideally,
a transition from gnome-mag to Compiz Fusion should not require the
user to configure Compiz using a second tool. Compiz Fusion already
allows for easy configuration through D-Bus, however, this is
application specific. There are a few different ways of solving this;

- Use the application-specific interface in Orca.
- Create a small plugin for Compiz Fusion to relay the necessary
configuration request from a generic bus.
- Something Else.

4.
Most of the features Gnome-mag has are already present in Compiz
Fusion in one way or an other, however, gnome-mag, unlike Compiz
Fusion, has had a significant amount of input from visually impaired
users to get where it is today. Mimicking the features of gnome-mag in
Compiz Fusion should not be tremendous amount of work; it is mostly in
the glue, with some exceptions like split-screen magnification and
cross hair functions.

This is one of the more important success criteria for this project:
At the end of the project period, Compiz Fusion should be able to do
everything Gnome-mag is able to do.

5.
As simple as it sounds.

Concerns, limitations
============
A very common concern is the hardware requirement involved when
dealing with Compiz. Compiz currently requires composite, but more
importantly, OpenGL to work. OpenGL in turn requires moderately recent
hardware, which does pose a problem. However, this project would not
make gnome-mag unusable, it would simply add features to those who
have the recent hardware and prepare for the future.

It can also be noted that there are plans to make Compiz less
dependent on OpenGL, and this can already be seen in the code base as
typical OpenGL commands are being switched for Compiz equivalents
(glTransform versus matrixTransform, etc), and it is a stated goal of
Compiz to someday be able to use different plugins for output. I.e:
XRender when OpenGL is unavailable.

An other concern is that Compiz Fusion is not a GNOME window manager,
and it is only one window manager. The goal of this project is mainly
to create an implementation that can easily be copied to other
composite managers. Metacity in it's current state can not easily
accommodate these needed changes, thus Compiz should make for a good
alternative, specially as it is gaining ground and maturing.

I've been asked where I see Compiz in the future, and I honestly don't
know. There are very ambitious plans for Compiz at the moment. These
plans would make Compiz more flexible with regards to hardware, and
hopefully more robust and mature. At any rate, it is an application
very much alive.

Project schedule
==========
Most of this work would be done during summer, as I am a student. And
this schedule is quite likely to change.

Some of these tasks overlap naturally, specially tasks where I expect
I will need assistance, which is mainly when it comes to Orca.

June:
 - Initial definition of what the protocol needs to accommodate based
on gnome-mag and community discussion
 - Write basic highlight plugin, possibly without remote control.
(Easily done at the side while waiting for feedback, etc)
 - Determine more specific plans for Orca integration.

July:
 - Write and publish a specification draft for the API / Protocol.
 - Start working on basic Orca integration.
 - Determine how to go ahead with split screen zoom in ezoom and
cursor cross hair.
 - Implement cursor cross hair.
 - Decide on how to allow easy configuration.

August 1-15:
 - Working Orca / Compiz integration at a level worthy of demonstration.
 - Ability to configure Compiz accessibility features through the Orca
UI (without cluttering the UI).
 - Split screen zoom in Compiz Fusion.

September 15th:
 - Finish

Beyond this, it'll obviously be bug fixing, tweaking etc in august and
september.


Personal Experience
============
I've already written Enhanced Zoom for Compiz (And several other
plugins and core code), and I don't expect I'll need any technical
assistance on that part of the project. I've also been interested in
magnification for about a year now, and already looked at Orca
integration on a very superficial level.

I'm used to working with others code and I like to believe I have a
high standard when it comes to quality.

I'm familiar with all the technologies involved in the project (some
more than others), the complexities and so on, partially from working
on magnification, partially from participating in discussions
regarding accessibility and magnification.

- Kristian
Comment 5 Akhil Laddha 2011-10-14 10:47:39 UTC
gnome-mag development has been stalled and it has been replaced by gnome-shell
mag [1]. Maintainers don't have future development plan so i am closing all the bugs as WONTFIX.

[1] https://mail.gnome.org/archives/gnome-bugsquad/2011-October/msg00001.html