GNOME Bugzilla – Bug 519080
Provide better integration with COMPOSITE managers
Last modified: 2011-10-14 10:47:39 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.
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?
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.
Hi All: See also http://mail.gnome.org/archives/gnome-accessibility-list/2008-May/msg00000.html, which was composed by the eZoom author.
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
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